钠守：我怎样从供电想法走到一个软件实验
十分钟路演讲稿
署名：陈鹏旭
日期：2026年10月16日

使用说明
本稿配合一页PPT讲自己的痛点、做法和思考历程。分段合计10分钟，是排练估计，尚未真人计时；请按自己的语速排练并调整停顿。正文不需要打开网站或现场运行程序。评委可自行查看已有公开网站；如现场管理员允许，问答时可从统一主页进入证据。方括号内容不念，不必逐字背诵。

［0:00—1:00，我最初想解决什么］

各位老师好，我是陈鹏旭，我的项目叫钠守。

我最初想的事情很直接：人在外面用电脑，附近没有插座，手头的事情还没做完，怎么办？当时我先往供电的方向想，后来又想到，能不能把供电和电脑底座结合起来。

顺着这个想法往下做，我才发现，光是把东西组合起来，还没有回答一个关键问题：别人为什么需要它？如果成熟充电宝已经能解决缺电，我多做的部分到底带来了什么？

所以今天我想讲的，是这个想法怎样被追问、怎样收窄，以及我最后实际做出了什么。

［1:00—2:00，我为什么停下底座分支］

老师在公开反馈里提醒我，要考虑与成熟充电宝相比的优势。这让我重新看自己的方案。我没有电池包，没有硬件实测，也没有理由说新底座一定更好。我决定停下这个分支，先处理一个自己能够验证的问题。

即使给定了电量或者时间，也可能做不完所有任务。那先做什么？做到一半中断，哪些成果还有效，重启时能不能少重做一点？

我把钠守收在任务安排和进度恢复上。候选使用者，是需要重复批量处理文件的个人。但我还没有完成访谈，所以先拿具体任务检查自己的判断，再谈别人是否需要。

［2:00—4:00，我怎样比较安排方法，又为什么接受打平］

我先选了容易核对结果的工作：分批备份图片、生成缩略图。AI辅助我实现程序和核对记录；我提出问题、选择方向，也对最后说出的结论负责。

程序运行在本机，用Node处理文件。网站负责把输入、方法和结果展示出来，方便别人复核。为了比较任务安排，我先固定素材、预算和成果质量，几种方法都处理同一批输入。否则，某一组少做了事情或者降低了质量，看起来完成更多，也没有比较意义。

一开始我比较在意优化器能不能安排得更好。后来我觉得，这个问题不能只拿原顺序当对手。普通人很容易想到先做重要的，或者先做价值相对成本高的。如果这些简单方法已经够用，复杂优化器就需要证明自己多出来的价值。

于是我把简单方法也补进实际对照，和精确求解器一起运行。结果是：六个预选诊断情景里，五个满足保护余量、可以安排；另一个连保护余量都不够。五个可行情景中，每个都有至少一种简单方法打平精确求解器。

这与我最初希望看到的优势不一样。但它让我放下了一个过早的判断：不能因为方法复杂，就说它更值得用。哪些条件下简单方法足够，哪些条件下会吃亏，应该让结果回答。打平也要留下，不能再挑几个有利例子，把原来的想法包装成成功。

［4:00—6:00，我把恢复用在自己真正要做的工作上］

接下来，我想让实验接触一项自己已经要做的事情。老师提出过，知识和快速优化的信息，可以低成本地连接现实，形成反馈。我选择让钠守先检查钠守自己的网站。

我冻结了当时的六十七个网站文件，做发布前检查。程序能够检查支持范围内的本地引用、脚本语法和文件完整性。先完整检查一次，留下正常参考，再比较两种中断后的办法。

两组都在第四项完成后，让自己的子进程主动退出，再重新启动。一组从头做，另一组提前保存了有效进度，重启后先核对，再接着做。

从头重跑重复了四项检查；检查点组复用了这四项，重复为零。最后两组都完成相同的六十七项检查，报告与正常参考一致，范围内都是零错误。

我能从这件事里说出的，是这次确实少重做了四项逻辑检查。它仍要重新核对全部输入，保存也有成本，所以还不能直接说省电或者稳定提速。中断也是第四项已经保存后的主动退出，没有做物理掉电。

我还在隔离副本里故意加了一条不存在的资源引用，看程序能不能指出来；再恢复已知原始内容，重新检查。错误从零到一，再回到零。这是受控的修改和复验，没有AI自主修复。

［6:00—7:00，我自己的错误也要留下］

这个过程里，真正让我印象深的，是复核发现了我自己的统计错误。

独立审查有九项通过，一项发现保存开销重复相加。原来逐任务已经累计过一次，结束时的小计又被加进去了。程序自检通过，也没覆盖到这个问题。

我的处理是把原始代码、结果和事件留下，另外给出更正和依据。它没有改变少重做四项、最终结果一致的结论，但也不能因此说它无所谓。

如果只留下好看的结果，别人就很难判断我到底改了什么。我希望这个项目至少能让人看见，判断是怎样形成的，错误又是怎样被改正的。

［7:00—8:30，我现在怎样理解这个项目］

回头看，钠守已经从一个供电产品想法，变成了软件研究原型。它与赛题的联系，是把AIDC里的预算、任务优先级、保护余量、检查点和恢复验收这些思想，放到个人电脑能够验证的任务里。

这些思想本身已经成熟，现有检查工具和持续集成也能解决很多问题。我不能把它们说成自己的新发明。现在值得继续检验的，是把具体任务接入以后，整条工作流程是否真的比原有办法更合适。

我也把边界收清楚了：目前没有钠电硬件、真实能耗测量或者AI模型推理。钠电是未来可能研究的供能选项，不能因为名字里有“钠”，就假定它优于其他电池。AI在这个阶段帮助我实现、整理和批评方案，实验程序处理的是文件。

我现在觉得，把一个想法变成能够运行、能够被别人反驳的实验，是这阶段已经得到的东西。至于用户能不能获得净收益，还没有证明。

［8:30—10:00，接下来我需要怎样的帮助］

下一步我会先找一种确实有中断和重做成本的批处理任务，比较普通重跑、频繁保存和较少保存。成果质量保持相同，核验、保存、接入和维护的成本都算进去。直接重跑更合适，也应该接受。

同时，我需要了解真实使用者现在怎么做，成熟工具已经解决了什么，以及他们愿不愿意多接入一套流程。这些问题比再加一个展示功能更能决定项目该怎么走。

所以我希望得到的帮助很具体：如果您有适合拆分、确实会中断的任务，可以帮助我确定下一种任务适配；如果您熟悉现有工具，希望指出应该比较的替代方案。合作方如果已有电池包参数，也可以帮助我判断怎样把可用能量和功率约束接进模型。现阶段先利用已有设备和资料。

今天我带来的，不是已经证明省电或商业成功的产品。是我怎样从一个想法出发，做对照、接受打平，再把自己的工作接进去，并保留错误和更正的过程。谢谢各位老师。

——正文结束——

核对信息，不念
1. 本稿是展示材料整理，不新增实验，不将旧结果计为新进展，未代发1836。正文只依赖一页PPT，无现场网站演示环节。
2. 进展09来源：work/scheduling-v2/handoff-summary.json。六个预选诊断情景，五个可行，一个保护余量不可行；五个可行均有至少一种已执行简单方法打平精确求解器。逐情景最好规则是事后参照，未实现自动预知最佳规则。
3. 进展11来源：work/reality-loop/results-corrected.json及outputs/钠守_进展11独立复核_2026-10-16.md。相同冻结自有网站67文件；普通组71次检查、4项重复；检查点组67次检查、0项重复、4项复用；最终都是67项、0个范围内错误，与正常参考一致。
4. 两组均在第4项完成后由自有子进程主动exit 75，检查点组第4项已提交。这是预先指定的有利边界，不是OS强杀或物理掉电。每次仍读取并计算全部输入哈希；只有一次固定顺序比较，不推断净提速或Wh。
5. 独立审查9项通过、1项发现开销汇总重复，不能说10项全过。更正累计写入1,789,132字节、相关序列化/write/rename调用71.1873毫秒；最终检查点文件38,368字节。原始代码、结果和事件保留，更正另附来源依据。
6. CSS故障仅在隔离副本主动注入，修复为已知原始字节恢复。新检查模板的恢复不代表旧多批次调度器已支持整体异常恢复。
7. 当前未完成用户访谈，未证明愿用、愿付或用户净收益；没有实测Wh、钠电硬件、物理掉电或真实AI推理。不声称独自手写全部代码，AI辅助研发，我负责问题、方向和结论。
8. 统一公开主页：https://frost-guard-d3gw4cry5916d32c4-1503361620.tcloudbaseapp.com/naguard/