前五篇我们已经把几件事讲清楚了先从小任务开始用prompt就能做的先做任务变复杂后再加Harness任务继续推进后引入状态状态机负责描述转移SIADOS负责把一轮任务推进串起来这一篇要继续往前走讲的是一个更关键的问题AI 编程的控制不能永远停留在“人盯着它跑”的阶段而要逐步走向“预先把规则写好再让系统按规则推进”。这就是本章的主题从实时监督到预先控制。1. 为什么不能一直靠人实时监督很多 AI 编程流程表面上已经自动化了实际上还是靠人盯着走AI 走一步人看一眼发现偏了人立刻纠正AI 再走一步人再看一眼这种方式短期内能工作但它的问题很明显第一人的成本太高任务一长人就不能一直盯着。越是复杂任务越不能依赖“随时在线的人肉修正”。第二规则不稳定如果很多约束都靠现场提醒那它就不是稳定规则而是临时反应。今天人记得提醒明天人忘了系统行为就会变。第三任务越大越容易漏人工监督适合小范围、低频率的纠偏。一旦任务开始跨文件、跨步骤、跨轮次靠现场盯就很容易漏掉关键问题。所以本书不把“实时监督”当成理想状态。它只能作为起点不能作为最终方案。2. 什么叫预先控制预先控制的意思不是“提前把所有事情都管死”而是先把边界写清楚先把规则写清楚先把验收写清楚再让系统按这些前提去推进换句话说不是边做边想规则而是先把规则准备好再让 AI 在规则里工作。这就是 Harness 和状态的意义。它们不是临时补丁而是预先准备好的控制层。3. Harness 和 Loop 不是固定脚手架而是反馈驱动的控制层这一点很重要。Harness 和 Loop 不是一开始就固定不变的模板它们会随着任务反馈持续变化初始边界只负责启动执行中的测试负责暴露问题失败轨迹负责告诉系统哪里不能再走人类判断负责决定边界要不要收紧任务稳定后控制层可以适当降级也就是说边界本身也是循环的一部分。这和“永远固定一套控制方式”不一样。本书强调的是控制力度要跟着反馈走。4. 三层控制模式当任务开始变复杂时控制层可以分成三档。这不是为了把系统做得更复杂而是为了让控制力度和任务风险匹配。4.1 第一层轻量模式这一层适合低风险、一次性、范围很小的任务。比如改一句话补一个注释解释一段代码调整一处措辞做一次局部修改这类任务的特点是范围明确风险低出错影响小不需要长期维护状态这时直接prompt往往就够了。没必要一开始就把任务搞得很重。4.2 第二层受控模式当任务开始跨文件、开始反复修改、开始需要验证时就要进入受控模式。这一层的核心是Harness。Harness做的事情是把模型的动作限制在一个明确边界内当前任务是什么哪些文件可以改哪些文件不能改做完以后怎么检查失败以后怎么记录这一层适合跨文件修改需要明确范围需要检查结果需要记录失败需要让下一轮继续推进如果没有这一层系统很容易把局部任务改成扩散任务。也就是说本来只想修一个点最后却把整个项目带偏。4.3 第三层状态约束模式当任务开始出现以下情况时就要进入更强的状态约束反复失败跨文件影响明显需要恢复需要长期协作需要更严格的验收和记录这时只有Harness还不够必须把状态也引进来。因为系统不能只知道“这一轮怎么做”还要知道之前已经走到哪一步哪些路径已经试过哪些失败不能再重复哪些问题必须单独保留下一轮是否还能继续这就是状态约束的意义。它不是为了把系统变重而是为了让系统知道自己到底走到了哪一步。5. 为什么不能一上来就上最重控制因为重控制有成本。5.1 维护成本高如果每个小任务都配很多状态文件、很多规则、很多验证系统就会越来越重。5.2 小任务会被复杂化本来一句话能改完结果流程太重反而没人愿意用。5.3 控制失去弹性任务风险还没上来控制层已经过重系统就不再“渐进”。所以本书反对的是一开始就全量上状态一开始就上最复杂的控制层一开始就把轻任务也做成重任务更合理的做法是先轻后重按风险加层。6. 什么时候控制层可以降级控制层不是只会加重它也要会降级。这一点很重要。如果任务已经稳定临时状态不必长期保留重复验证不必一直执行过重的控制可以退回到更轻的模式但这里要注意降级不是回到混乱。它的意思是该保留的长期状态保留该删除的临时状态删除该放松的控制放松但已经确认的规则不能丢也就是说系统不是“放掉所有约束”而是只保留当前任务真正需要的最小约束。7. 把纠错语言编译成规则这一章后半部分最重要的一点是把人的纠错语言转成可执行规则。人类在屏幕前经常会说“别改摘要只改引言。”“不要动结论。”“这里只能改这一段。”“别顺手扩展到别的章节。”这些话如果只停留在口头上就很容易失效。更好的办法是把它们编译成规则allow_sectionsdeny_sectionsacceptancescopestate_update这样系统就不是靠记忆人说过什么而是直接按照规则执行。例子论文修改如果当前任务是修改引言那么控制规则就可以写成允许引言禁止摘要、方法、结论验收只检查引言的 diff状态更新记录本轮修改和未决问题这样一来控制就不再依赖“现场提醒”而是变成了可执行规则。8. 静态部分和动态部分要分开这一章还要强调一个很关键的分工静态部分文件格式规则接口职责边界验收格式这些东西应该尽量稳定便于维护。动态部分当前允许什么何时收紧何时扩展何时停下这些东西要跟着反馈变化。也就是说静态部分保证可维护动态部分保证会收敛如果把两者混在一起系统就会变得又重又乱。9. 本章小结这一章想说明的核心很简单AI 编程不是一直靠人实时监督而是要逐步把控制前移变成预先控制。它的路径可以概括成低风险任务先用prompt任务复杂后加Harness再复杂就引入状态状态更新后系统进入更稳定的推进任务稳定后控制层可以适当降级已经验证过的规则和经验要沉淀下来这也就是本书第六章真正想表达的东西控制不是一次性加满而是在任务变复杂时逐步把边界、规则和验收提前写好让 AI 在这些前提下推进。下一章我会继续讲项目地图、当前任务、修改日志和开放问题怎么把状态真正落到文件系统里。
AI渐进编程之六：从实时监督到预先控制
前五篇我们已经把几件事讲清楚了先从小任务开始用prompt就能做的先做任务变复杂后再加Harness任务继续推进后引入状态状态机负责描述转移SIADOS负责把一轮任务推进串起来这一篇要继续往前走讲的是一个更关键的问题AI 编程的控制不能永远停留在“人盯着它跑”的阶段而要逐步走向“预先把规则写好再让系统按规则推进”。这就是本章的主题从实时监督到预先控制。1. 为什么不能一直靠人实时监督很多 AI 编程流程表面上已经自动化了实际上还是靠人盯着走AI 走一步人看一眼发现偏了人立刻纠正AI 再走一步人再看一眼这种方式短期内能工作但它的问题很明显第一人的成本太高任务一长人就不能一直盯着。越是复杂任务越不能依赖“随时在线的人肉修正”。第二规则不稳定如果很多约束都靠现场提醒那它就不是稳定规则而是临时反应。今天人记得提醒明天人忘了系统行为就会变。第三任务越大越容易漏人工监督适合小范围、低频率的纠偏。一旦任务开始跨文件、跨步骤、跨轮次靠现场盯就很容易漏掉关键问题。所以本书不把“实时监督”当成理想状态。它只能作为起点不能作为最终方案。2. 什么叫预先控制预先控制的意思不是“提前把所有事情都管死”而是先把边界写清楚先把规则写清楚先把验收写清楚再让系统按这些前提去推进换句话说不是边做边想规则而是先把规则准备好再让 AI 在规则里工作。这就是 Harness 和状态的意义。它们不是临时补丁而是预先准备好的控制层。3. Harness 和 Loop 不是固定脚手架而是反馈驱动的控制层这一点很重要。Harness 和 Loop 不是一开始就固定不变的模板它们会随着任务反馈持续变化初始边界只负责启动执行中的测试负责暴露问题失败轨迹负责告诉系统哪里不能再走人类判断负责决定边界要不要收紧任务稳定后控制层可以适当降级也就是说边界本身也是循环的一部分。这和“永远固定一套控制方式”不一样。本书强调的是控制力度要跟着反馈走。4. 三层控制模式当任务开始变复杂时控制层可以分成三档。这不是为了把系统做得更复杂而是为了让控制力度和任务风险匹配。4.1 第一层轻量模式这一层适合低风险、一次性、范围很小的任务。比如改一句话补一个注释解释一段代码调整一处措辞做一次局部修改这类任务的特点是范围明确风险低出错影响小不需要长期维护状态这时直接prompt往往就够了。没必要一开始就把任务搞得很重。4.2 第二层受控模式当任务开始跨文件、开始反复修改、开始需要验证时就要进入受控模式。这一层的核心是Harness。Harness做的事情是把模型的动作限制在一个明确边界内当前任务是什么哪些文件可以改哪些文件不能改做完以后怎么检查失败以后怎么记录这一层适合跨文件修改需要明确范围需要检查结果需要记录失败需要让下一轮继续推进如果没有这一层系统很容易把局部任务改成扩散任务。也就是说本来只想修一个点最后却把整个项目带偏。4.3 第三层状态约束模式当任务开始出现以下情况时就要进入更强的状态约束反复失败跨文件影响明显需要恢复需要长期协作需要更严格的验收和记录这时只有Harness还不够必须把状态也引进来。因为系统不能只知道“这一轮怎么做”还要知道之前已经走到哪一步哪些路径已经试过哪些失败不能再重复哪些问题必须单独保留下一轮是否还能继续这就是状态约束的意义。它不是为了把系统变重而是为了让系统知道自己到底走到了哪一步。5. 为什么不能一上来就上最重控制因为重控制有成本。5.1 维护成本高如果每个小任务都配很多状态文件、很多规则、很多验证系统就会越来越重。5.2 小任务会被复杂化本来一句话能改完结果流程太重反而没人愿意用。5.3 控制失去弹性任务风险还没上来控制层已经过重系统就不再“渐进”。所以本书反对的是一开始就全量上状态一开始就上最复杂的控制层一开始就把轻任务也做成重任务更合理的做法是先轻后重按风险加层。6. 什么时候控制层可以降级控制层不是只会加重它也要会降级。这一点很重要。如果任务已经稳定临时状态不必长期保留重复验证不必一直执行过重的控制可以退回到更轻的模式但这里要注意降级不是回到混乱。它的意思是该保留的长期状态保留该删除的临时状态删除该放松的控制放松但已经确认的规则不能丢也就是说系统不是“放掉所有约束”而是只保留当前任务真正需要的最小约束。7. 把纠错语言编译成规则这一章后半部分最重要的一点是把人的纠错语言转成可执行规则。人类在屏幕前经常会说“别改摘要只改引言。”“不要动结论。”“这里只能改这一段。”“别顺手扩展到别的章节。”这些话如果只停留在口头上就很容易失效。更好的办法是把它们编译成规则allow_sectionsdeny_sectionsacceptancescopestate_update这样系统就不是靠记忆人说过什么而是直接按照规则执行。例子论文修改如果当前任务是修改引言那么控制规则就可以写成允许引言禁止摘要、方法、结论验收只检查引言的 diff状态更新记录本轮修改和未决问题这样一来控制就不再依赖“现场提醒”而是变成了可执行规则。8. 静态部分和动态部分要分开这一章还要强调一个很关键的分工静态部分文件格式规则接口职责边界验收格式这些东西应该尽量稳定便于维护。动态部分当前允许什么何时收紧何时扩展何时停下这些东西要跟着反馈变化。也就是说静态部分保证可维护动态部分保证会收敛如果把两者混在一起系统就会变得又重又乱。9. 本章小结这一章想说明的核心很简单AI 编程不是一直靠人实时监督而是要逐步把控制前移变成预先控制。它的路径可以概括成低风险任务先用prompt任务复杂后加Harness再复杂就引入状态状态更新后系统进入更稳定的推进任务稳定后控制层可以适当降级已经验证过的规则和经验要沉淀下来这也就是本书第六章真正想表达的东西控制不是一次性加满而是在任务变复杂时逐步把边界、规则和验收提前写好让 AI 在这些前提下推进。下一章我会继续讲项目地图、当前任务、修改日志和开放问题怎么把状态真正落到文件系统里。
