研路炼钢 | 我把自己外包给 AI 一周后，发现真正不能外包的是判断
研路炼钢 | 我把自己外包给 AI 一周后，发现真正不能外包的是判断
AI 可以替我检索、拆解、执行和校验，但不能替我决定什么值得做。主控的价值不是让更多窗口同时忙，而是把碎片推进成有证据的交付。
前几天我和舍友聊天，他说自己对 AI 的使用程度可能只有 10%，而我已经到了 70%。
他又补了一句：你几乎什么都问 AI，会不会慢慢没有自己的思考？
这句话让我停了一下。
一周前，我刚写完上一篇文章：《我想把自己外包给 AI，最后先搭了一座“控制塔”》。当时我想得很完整：用一个空白项目做主控，再把论文、代码、博文和知识库分发到不同窗口推进。
真正跑了几天以后，我发现设计一个系统不难，难的是给系统装上刹车。
个人主控最重要的能力，不是帮我启动更多事情，而是更早地决定：哪些事情今天不启动。
01｜70% 都问 AI，不等于 70% 没有思考
我确实会把很多问题交给 AI。
查资料、拆任务、读代码、检查引用、生成初稿、排查报错，这些工作如果都靠我一个人串行完成，时间很快就没了。AI 在这些地方像一组可以随时调用的外部进程，能帮我省掉大量机械切换。
但“把问题交给 AI”和“把判断交给 AI”，不是一回事。
我现在更愿意这样分工：AI 负责检索、拆解、执行和校验；我负责目标、取舍、证据和后果。
真正危险的不是我问了多少次 AI，而是我开始默认它给出的优先级就是我的优先级，默认它说“完成了”就真的完成了，甚至连什么值得长期投入也不再自己判断。
可以外包工作，但不能外包判断。
02｜9.76 亿 Token 之后，我发现浪费不在价格
我专门检查了 7 月 11 日的本地调用日志。
原始日志汇总出的 Token 累计是 975,960,853。另按输入字段统计，缓存输入约占全部输入 Token 的 95.4%；把非缓存输入和输出相加，则约为 47.39M。这两项不是同一个分母，不能直接凑成 100%。
这里必须说明：原始 Token 统计不等于实际付费账单。 大量内容来自缓存输入，不能简单理解成“花钱烧掉了 9.76 亿 Token”。
但这个数字仍然暴露出一个问题：我在反复携带过长的上下文。
一个窗口做完整项目审计，另一个窗口又重新读取一遍；今天讨论过的背景，明天继续任务时再次带上；主控为了判断一个下一步，重新回看几小时聊天记录。
屏幕一直在输出，项目却不一定在推进。
后来我把问题压缩成一句话：不是我问 AI 太多，而是我每次都带着整个仓库重新开会。
03｜最大的浪费，不是做得慢，是同时开太多窗口
AI 把启动一件事的成本降得太低了。
一个新想法出现，我几分钟就能开窗口、建文件、搜资料、列计划。过去因为麻烦而不会启动的事情，现在都可以轻易进入“进行中”。
结果不是效率翻倍，而是半成品翻倍。
所以我保留每天的 Top 3，但增加了一条更硬的规则：真正处于 Active 的项目最多只有两个。 第三个项目只是候补，只有前面的项目完成或明确进入等待，才允许启动。
Top 3 负责方向，WIP 上限负责带宽。
那几天，我把“论文形成稳定快照”“竞赛项目给出是否继续投入的结论”“应用项目完成测试并推送”列为三个结果，但同时只推进前两项。新的实验、新功能和新文章先进入 Inbox，不直接抢占主线。
没有空位，就不开新坑。先关一扇门，再开下一扇。
04｜主控不是聊天窗口，而是一条交付流水线
我一开始把主控想成一个更懂我的超级助手。真正运行以后，我反而在不断削弱它的职责。
现在主控只跑一条链路：
1 | 收集 → 排序 → 分发 → 推进 → 验收 → 归档 |
论文、代码、博文和知识库仍然由各自的项目窗口处理。主控不进去改具体文件，也不和项目窗口重复研究同一个问题。
它只要求每个窗口在开始前写清楚四件事：本轮唯一结果是什么、完成标准是什么、证据保存在哪里、什么时候回来验收。
结束时，项目窗口提交一张简短回执。主控读取回执和证据，不重新阅读整段聊天历史。
这样做看起来少了很多“智能”，却更像一个能长期运行的系统。
05｜新的工作单位，不是“聊一次”，而是“闭环一次”
以前我很容易用聊天轮次衡量进度：这个窗口讨论了很久，那个窗口生成了很多文件，好像今天已经做了很多。
现在我把工作单位改成一个固定闭环：
1 | 审核一次 → 修复一次 → 验证一次 → 提交一次 |
论文的闭环，是稳定稿能够编译，实验材料可以复现，关键结论能回到数据；代码的闭环，是测试和构建通过，改动进入 Git；博文的闭环，是每个二级标题都有真实配图，站点构建通过，并且已经推送。
窗口说“完成了”不是证据，生成了文件也不是证据。
没有验证、没有稳定文件、没有提交，就不进入 Done。
06｜项目不是讲出来的，是被证据串起来的
这几天我同时检查论文、比赛材料和代码项目，越来越强烈地意识到：不同项目最后拼的其实是同一件事——证据链。
论文里写了一个提升，就要能找到对应实验和统计结果；代码里说修复了一个问题，就要有测试能把它重新触发；比赛材料里声称系统具备某项能力，就要能在样机或演示中被看见。
需求、实现、测试、演示和提交必须互相对应。
这并不是让自己变得保守。未来能力仍然可以写，但要明确标成规划；已经实现的能力，则必须能够定位到文件、日志、结果或现场动作。
说了什么，就要能验什么。
07｜每天开工前，我只问三个问题
系统最后被我压缩成了三个问题：
- 现在最重要的结果是什么？
- 完成的证据是什么？
- 哪件事今天明确不做？
第一个问题必须写“结果”，不能写“继续推进”。第二个问题必须指向具体的文件、测试、提交或链接。第三个问题最容易被忽略，但它实际上决定了今天有没有带宽。
比如，“继续改论文”不是结果；“形成可提交的匿名 PDF，并通过引用与格式检查”才是。再比如，“优化项目”不是结果；“完整测试通过，形成一个可回滚提交并推送”才是。
写不清这三个问题，就先不要开新窗口。
写在最后｜让 AI 接住那些本来会散掉的事
回到舍友问我的那个问题：70% 的事情都问 AI，会不会没有自己的思考？
我现在的答案是，使用比例本身并不重要。真正需要警惕的是，我有没有把 70% 的判断权也一起交出去。
主控可以替我排序，项目窗口可以替我推进，知识库可以替我记住。但什么值得做、什么不值得做，哪些后果由我承担，哪些决定不可逆，仍然只能由我负责。
我想要的不是让 AI 替我活着，而是让它接住那些本来会散掉的事。
把执行外包，把记忆落盘，把判断留给自己。
研路炼钢，记录一个计算机研究生的真实成长。
