这本书不是一次性 Prompt 的技巧集，而是讲一套让 AI 在真实项目中逐步推进、逐步收紧、逐步收敛的方法。

为什么需要渐进控制？

LLM擅长处理文字之间的变化。

同一个问题换一种说法，它仍然可能正确回答；面对没有出现过的题目，也能根据已有知识生成合理解释。

但这种泛化主要发生在：

文字输入 → 文字输出

AI编程不只需要回答问题，还要真正改变项目状态。

Agent能够正确修改一个文件，不代表它理解了文件之间的关系；能够完成一次演示，也不代表它可以长期稳定执行。

表述正确，不等于执行可靠；局部修改正确，也不等于项目整体正确。

任务越接近现实，涉及的状态、关系和风险就越多，模型也越容易到达泛化边界。

因此，AI编程不能一直依赖模型自己判断，而要随着任务复杂度逐步增加控制。

它的核心顺序很简单：

• 先让 AI 做得动；
• 再让它做得稳；
• 最后让它能够在项目中长期延续。

全书按以下顺序展开。

---

第一部分：先让 AI 动起来

第 1 篇：从最轻的方式开始

先把最轻的任务做掉。
小任务直接 prompt 就够了，不必一开始就上重控制。

第 2 篇：什么时候给 AI 编程加一层 Harness？

当任务开始变复杂，就需要 Harness。
它负责把任务范围、允许动作、验收条件和失败反馈组织起来。
这一篇也会把全书后续章节的路线先铺开。

---

第二部分：让任务有状态、有转移

第 3 篇：什么时候需要引入状态？

当任务不再是一轮结束，而是要持续推进时，就需要 state。
状态负责记录下一轮真正需要的事实。

第 4 篇：状态机如何约束 AI 的动作？

状态有了，还要知道状态之间怎么转。
状态机负责说明：现在在哪、下一步能做什么、什么算通过。

第 5 篇：SIADOS 状态转移方法

把一轮任务拆成六步：

• State
• Input
• Analysis
• Driver
• Output
• State Update

这一篇把单轮推进写成一个完整循环。

第 6 篇：从实时监督到预先控制

控制不能永远停留在“人盯着它跑”。
更合理的方式，是先把边界、规则和验收写好，再让系统按规则推进。

---

第三部分：Agent 如何进入项目

第 7 篇：Agent 启动协议

Agent 进入项目时，应该先看什么、后看什么、怎么确认自己进入了正确的上下文。
这一篇讲的是入口，而不是内容本身。

第 8 篇：项目地图

用 project_map.md 记录长期稳定的项目认知。
让 AI 先知道项目是什么，再决定怎么做。

第 9 篇：当前任务

用 current_task.md 写清这一轮到底做什么。
它是当前任务的契约，不是聊天记录。

第 10 篇：通过修改日志帮助收敛系统

用 revision_log.md 记录为什么这么改、改了什么、验证如何。
它帮助下一轮从已记录状态继续，而不是重新猜。

第 11 篇：开放问题

用 open_issues.md 保存暂时不能解决、但不能忘掉的问题。
它让不确定性有地方安放，也让任务边界保持清楚。

---

第四部分：把验收和工作台搭起来

第 12 篇：如何把验收变成 Agent 的正反馈？

通过不是结束。
通过以后，要把结果写回状态，让下一轮能继续使用。

第 13 篇：AI 编程的本质，是 Reward 工程

验收只是 Reward 的一种。

AI 编程中的反馈，不只发生在最后，也发生在每一轮纠偏过程中。

当 Agent 改对一部分、改错一部分，或者改过头时，系统需要更细的反馈信号：

哪里对了，哪里错了，哪里不能动，哪里需要保留，下一轮应该怎样验证。

这一篇讲的是：Reward 不只是奖励分数，而是帮助 Agent 判断方向、发现偏差、限制范围和持续收敛的工程信号。

第 14 篇：程序项目的工作台怎么摆？

把代码、状态和人类视图分开摆。
这样项目会更清楚，也更容易接手。

第 15 篇：一轮程序修改是怎么跑完整个循环的？

把状态、输入、分析、执行、输出和回写串起来。
这一篇讲完整的一轮闭环。

第 16 篇：程序通过以后，怎么把修复变成规则？

有些修复不能只停在“这次通过”。
要把它变成长期规则、回归测试和项目认知的一部分。

---

第五部分：长期维护与反模式

第 17 篇：长期维护里，控制层怎么松紧？

稳定的地方可以放松，反复出问题的地方必须收紧。
控制层要跟着风险变化，而不是一刀切。

第 18 篇：一次性任务怎么演进成长期项目？

很多小修补会慢慢变成长项目。
一旦开始涉及测试、日志、兼容、回写和后续边界，就要按长期项目来处理。

第 19 篇：控制层最容易变坏的几种方式

长期运行后，控制层最容易出现几种坏法：

• 规则膨胀
• 状态老化
• 日志空心化
• 任务漂移
• 人工过载
• Harness 肥胖

第 20 篇：Agent 为什么也会制造技术债？

Agent 可以降低代码生成成本，但不会自动降低工程复杂度。

项目变大以后，Agent 常常依赖关键词和局部上下文定位问题，却不一定真正理解函数调用、数据流、组件依赖和历史兼容关系。

因此，它可能修好当前问题，却破坏其他路径。

同时，Agent 还有一种常见倾向：为了避免删错，保留旧代码，再追加新逻辑。

短期看，这样比较安全；长期看，项目会越来越臃肿。

这一篇重点讨论两类 Agent 技术债：

关系债：看见关键词，却看不见代码关系；
残留债：不断追加，却不主动清理。

---

结语

这本书想留下的，不是一次性的提示词技巧，
而是一条适合真实项目的渐进路径：

• 小任务先用 Prompt
• 复杂任务加 Harness
• 持续任务引入状态
• 多轮推进用状态机和 SIADOS
• 文件系统保存项目认知
• 验收、反馈和回写形成闭环
• 证据包支持人类审查
• 长期维护不断调整控制强度

固定内容沉淀到 md 里，prompt 保持轻盈。

模型负责提出候选方案，控制层负责限定边界，项目状态负责保存已经确认的事实。

AI渐进编程，不是假设 Agent 可以完成一切，而是让它在明确的边界内，一步一步完成真实项目。