本文是《AI Loop Engineering 系列》的第三篇。
一、本质
AI 不需要被引导，它需要被限制。
引导是"往这边走"，AI 会理解成"附近都行"。
限制是"只能往这边走"，AI 没得选。
约束工程的核心思想：把 AI 的行为边界从"软提醒"变成"硬约束"。
二、三种约束机制
2.1 工具门禁（Tool Gate）
机制：当前阶段能调什么工具，不是 prompt 提醒，是代码拦截。
| 阶段 | 可用工具 |
|---|---|
| Spec 阶段 | read |
| Plan 阶段 | read + bash（只读） |
| Execute 阶段 | read + write + edit + bash |
| Verify 阶段 | read + bash（只跑测试） |
原理：阶段错了，工具不存在。agent 不是"被提醒不能写"，而是"根本调不到写工具"。
2.2 输出契约（Output Contract）
机制：每一步输出必须满足结构约束，不满足就不算完成。
yaml
tasks:
- id: T1
action: fix
verify: "go test ./... exit code 0"原理：不是 prompt 说"检查代码"，是代码里写死"exit code 不是 0 就不算 done"。
2.3 上下文锁（Context Lock）
机制：每轮 agent 调用前，注入当前 spec + 当前阶段 + 已完成任务。超出范围的内容被过滤。
text
每一轮 agent 的上下文 = spec + 阶段 + 已完成 task + 当前 task
其他历史 = 不可见原理：不是"记住你该做什么"，是"你只能看到该做的事"。
三、三种约束的互补关系
| 约束 | 解决什么问题 | 硬约束还是软约束 |
|---|---|---|
| 工具门禁 | agent 做了不该做的事 | 硬约束（做不了） |
| 输出契约 | agent 做了但没做好 | 硬约束（不算完） |
| 上下文锁 | agent 忘了自己该做什么 | 硬约束（看不见） |
三者互补：看不见 → 做不了 → 做不完。
层层收窄，没得跑偏。
四、约束工程 vs 脚手架
RuoYi 类型的框架是脚手架------把一堆技术决策打包成一个不可分割的整体，你要么全要，要么全不要。
约束工程不一样：
| 脚手架 | 约束工程 |
|---|---|
| 定义目录结构 | 只定义思考维度 |
| 绑定工具链 | 不绑定任何工具 |
| 强制生命周期 | 只标注当前阶段 |
| 写死验证方式 | 只说"需要验证"，怎么验由 spec 定 |
| 退出代价大 | 卸载即无痕迹 |
约束工程给的是原则和边界，不是路径和模板。
五、总结
| 核心要点 | 一句话 |
|---|---|
| 本质 | 限制 AI，不是引导 AI |
| 工具门禁 | 阶段错了，工具不存在 |
| 输出契约 | 不满足条件，不算完成 |
| 上下文锁 | 不该看的，看不见 |
| 三者关系 | 看不见 → 做不了 → 做不完 |
| 约束 vs 脚手架 | 给原则，不给路径 |
下一篇：一切皆函数------为什么函数式设计是约束工程、反复对齐、模块化的自然汇聚点。