我更愿意先把检索、记录、校验这些稳定动作交给代码，再让模型做审查。真要写入，也得看 diff、跑验证、能回滚。
self-iteration-safety-notes
自我迭代机器人是一个很容易被写偏的题目。我也不是没动过那个念头：既然它能读日志、能提建议、能写补丁，为什么不先让它把自己改起来？
模型能读日志，能总结问题，能改脚本，能跑检查，甚至能给下一轮自己写计划。把这些能力连起来，纸面上看，仿佛就得到了一套会自己变好的系统。
但我现在越来越不愿意从“让模型自己改代码”开始讲这件事。
我现在更想先处理另一件事：系统里有哪些动作本来就不该继续交给模型。检索、文件管理、状态查询、审计记录，只要能用确定性代码完成，就应该先从模型上下文里搬出去。
模型负责复杂判断，代码负责稳定动作。分清这两件事后，模型就不用反复处理那些固定、重复的工作。
第一层是代码替模型减负
机器人最容易被模型拖慢的地方，常常是那些反复出现、规则清楚、答案不该飘的事情。
比如：
- 查文件索引。
- 查长期记忆。
- 显示索引状态。
- 写入显式记忆。
- 对文件做 hash 去重。
- 给本地材料做摘要和分类。
- 更新全文检索索引。
这些事情不需要每次都让模型重新理解一遍。它们更适合落成命令、脚本、SQLite 表、FTS5 索引和固定输出格式。
如果有人问“有没有某个文件”“记忆里有没有某段内容”“当前索引是否正常”，系统应该先走确定性查询，而不是把全部上下文塞给模型，再让模型凭语感猜一个答案。
让模型做检索入口，系统看起来会更聪明；让代码做检索入口，系统才更容易长期稳定。
这两者的差别，在演示里不一定明显。到真实运行时，它会变成响应时间、资源占用、可解释性和故障排查成本的差别。
第二层才是模型审查
模型仍然很值得用，只是更适合放在第二层。
每完成一个小改动后，模型可以做审查：
这次改动是否符合目标有没有超出资源预算代码是否真的替模型减负下一轮最值得做哪 1-3 个改动这里我最在意的是审查，不是让模型直接接手执行。
子 agent 可以提建议，可以指出风险，可以要求补测试，也可以提醒某个方向已经偏离目标。不过它不该默认拥有直接改主线、改部署、改权限、改凭据处理方式的权力。
审查结果要进入计划或 issue。模型的判断可以保存下来，但下一步怎么执行，还是要走工程流程。
这也是我更能接受的“自我迭代”：模型把问题和风险说清楚，后面的规则再决定能不能继续。
自我修改要有五道门
如果机器人真的要进入自我修改，至少要先过五道门。
第一，有 run 记录。
谁触发了这轮迭代，目标是什么，改了哪些文件，为什么要改，审查结论是什么，都要能回看。没有记录的自我修改，说白了就是无人值守的临时操作。
第二，有 diff 审查。
自我修改不能偷偷碰凭据、权限、部署配置和外部发送路径。哪怕改动很小，也要能看见它动了哪里。模型说“只是优化一下”不够，还是要把 diff 摆出来看。
第三，有验证命令。
索引、检索、健康状态、构建、测试，至少要跑一项和这次改动有关的检查。没有验证的自我迭代，看起来像在进化，实际也可能只是在累积不确定性。
第四，有资源预算。
小服务器不适合为了“更智能”就加常驻向量库、重型后台、多模型循环或文件系统 watcher。能按需运行，就别常驻；能用 SQLite + FTS5 解决，就先别上更重的服务。
第五，有回滚路径。
机器人能改东西之前，必须先知道怎么退回去。备份、版本号、包 hash、恢复命令，这些都比“下一轮让模型修”更可靠。
这五道门听起来朴素，甚至有点慢。不过自我修改最需要的是让每次写入都能查到来源，也能停下或退回。
别把自我迭代写成无限循环
很多自我迭代方案最危险的地方，是把循环画得太顺。
观察 -> 思考 -> 修改 -> 部署 -> 再观察这个图很漂亮，但它省掉了几个上线时绕不开的问题：
- 修改前谁冻结计划。
- 部署前谁看 diff。
- 失败时谁回滚。
- 资源超限时谁拒绝。
- 触碰外部系统时谁确认。
如果这些问题没有回答，自我迭代图画得再顺，也只是把执行权藏进循环箭头里。
我更愿意把它画成窄门：
确定性命令-> 模型审查-> 人或规则确认-> 小范围修改-> 本地验证-> 可回滚发布这个链路慢一点，好处是每一步都能停下来。
小服务器是很好的约束
服务器资源有限不是坏事。
它会强迫系统把“想做”和“该做”分开。很多能力在概念上都能成立，但不一定值得做成常驻服务。
比如长期向量服务、Web 管理后台、多模型后台审查、持续文件监听，这些都很诱人。不过如果机器只有很小的内存余量，第一版就不该追求这些东西。更合适的做法是：
- 索引用 SQLite 和 FTS5。
- 重建索引按需触发。
- 审查在任务结束后运行。
- 状态查询走固定命令。
- 健康检查输出短摘要。
- 复杂后台先不上公网。
资源少不代表做不成，它会逼着设计收窄。
一个在小服务器上跑得稳的机器人，往往比一个看起来很完整、却到处常驻的系统更适合长期维护。限制会逼人把架构做窄，也逼人承认：不是每个“以后可能有用”的能力，都该现在就变成服务。
第一篇先写清楚哪些事不能自动做
如果要公开写自我迭代机器人，我不会先写“它已经能自己做什么”。
我会先写这些限制：
- 哪些事情交给代码。
- 哪些事情交给模型审查。
- 哪些事情必须确认。
- 哪些文件永远不能被自动改。
- 哪些服务不能因为一句建议就上线。
- 每轮修改如何留下记录。
我会把这些限制写在前面。一次自动修复很容易演示。麻烦的是改到第十次、第一百次以后，系统还能说清每一步为什么发生。
说不清为什么拒绝、暂停、回滚的系统，还不适合谈自我迭代。
先别急着让它自己改自己
所以我会把第一步放在代码之外的准备工作上，而不是直接让模型改代码。
第一步是把检索、索引、命令和审计记录做好，先少让模型处理固定动作。第二步再让模型参与审查，提出下一轮可以改什么。真要写文件，就看运行记录、diff、验证结果、资源预算和回滚办法。
我不反对机器人自我迭代；我反对把它讲成一个会自己越跑越好的循环。
继续读