第5课. 有缰绳的AI — Reins Engineering概论

实用技巧 — 知道这些就能指挥AI

AI编程工具的局限在于只有围栏（Harness）没有方向（缰绳）。Linter、格式化工具、CI说的是"不要出去"，但没有说"往这边走"。代码以"干净但错误"的状态到达生产环境。

核心原则：不要换模型，添加契约。 同一个模型根据反馈结构可以停在40个也可以完成527个。等更聪明的模型是人治。添加验证循环是法治。

现在就确认一下：

对智能体说：“把代码整理干净。功能不要变。”

AI完成重构后，检查你定的规则（写在CLAUDE.md里的）是否原封不动。API路径变了吗？DB表名变了吗？响应格式变了吗？

大概率有什么变了。AI在"整理"的时候把你的决策当成细节覆盖了。因为决策混在代码里。

记住Reins的三根支柱：

• 确定性反馈 — 不是"好像有点不对"而是"line 41: 字段名不匹配"
• 棘轮锁定 — 通过就锁定，继续前进
• 决策与实现分离 — 决策在SSOT里，代码是一次性投影

缺一个就无法收敛。

快速体验

用Claude Code打开第1课的应用。然后这样指挥：

对智能体说：“把代码整理干净。功能不要变。”

AI完成重构后，检查第1课定的规则（写在CLAUDE.md里的）是否原封不动。API路径变了吗？DB表名变了吗？响应格式变了吗？

大概率有什么变了。AI在"整理"的时候把你的决策当成细节覆盖了。这就是第5课的核心——因为决策和实现混在代码里才会发生的事。

为什么要这样指挥

上节课回顾

第4课亲身体验了yongol。

• 把决策从代码中分离到10个声明式规范（SSOT）
• 一个operationId贯穿了10个层
• 287条规则捕获了跨层矛盾
• 4.5B模型在validate反馈下也收敛到了0错误

这节课退一步问。为什么这个有效？

yongol是工具。工具背后有原理。理解了原理，即使在没有yongol的情况下也能用同样的思维方式。

四个时代

AI编程经历了四次范式转换。每个时代从上一个时代的局限中诞生。

第一代：提示工程 — “说得好就行”

“用React做个TODO应用。““用FastAPI做个论坛。”

以为写好提示AI就做得好的时代。实际上有效——但只有一次。第二个提示出不同的模式。第三个打破了第一个。

局限：一次性。 提示会消散。下次对话AI不知道你决定了什么。

第二代：上下文工程 — “给好上下文就行”

写CLAUDE.md。写需求文档.md。写进度文档.md。AI在每次对话开始时读这些文件，记住之前的决策。

第1课学的就是这个阶段。提示是一次性的，文件是永久的。把决策外部化后即使会话换了上下文也能保持。

局限：消散。 给了上下文但对话变长后AI还是忘记前面的。一次塞入200个端点的上下文中间信息会遗漏。上下文给了但不强制遵守。

第三代：围栏工程（Harness Engineering） — “用结构围住就行”

代码的拼写检查器（Linter）和自动整理工具（格式化工具）、CI/CD、项目结构、编码规范。围栏防止智能体跑出去。

第3课学的就属于这个阶段的一部分。Hurl测试、Git、CI/CD——这些就是围栏。AI破坏现有功能时CI拒绝。

局限：没有方向。 围栏说"不要出去"但不说"往这边走”。智能体在围栏里做什么——覆盖现有逻辑、改类型、跳过状态转移——Linter通过。格式化工具也通过。CI也通过。代码以"干净但错误"的状态到达生产环境。

第四代：Reins Engineering — “给方向就行”

不是围栏而是缰绳。

第4课体验的就是这个阶段。yongol validate不是说"不要出去"而是说"这里对不上，往这边改”。有方向的反馈。确定性事实。AI不得不遵守的契约。

围栏和缰绳的区别

为了直观理解这个区别，想象骑马。

围栏（Harness）： 在牧场围上栅栏。马在栅栏内自由活动。可以吃草、兜圈子、睡觉。唯一保证的是跑不出栅栏外。但不保证到达目的地。

缰绳（Reins）： 骑上马拉住缰绳。拉右边就往右走。拉左边就往左走。马自由奔跑——但方向你来把控。到达目的地。

现在业界的AI编程工具大多处于围栏阶段。Linter、格式化工具、CI/CD、编码规范——全是说"在这里面做"。智能体在围栏里兜圈子。代码很干净，但没人知道是否在往预期的方向走。

Reins Engineering说"往这个方向走"。validate说"这里对不上"，AI就往那个方向修正。缰绳在不限制自由的同时引向目的地。

研究表明引入AI编程工具后代码复杂度永久增加41%¹，AI采用越多交付稳定性越下降²。仅靠围栏不够的证据。

Reins的三根支柱

Reins Engineering由三个原则构成。

支柱1：确定性反馈

给AI的不是意见而是事实。

坏的反馈：“这个好像有点不对劲” 好的反馈：“line 41: field name mismatch, expected ‘user_id’, got ‘userId’”

区别是什么？坏的反馈AI有谄媚的余地。“我觉得没问题？这个是更好的模式。“好的反馈没有谄媚的余地。数字和位置不是情感。

1000个单词排序实验定量确认了这一点：

只说"错了"导致过度修正反而更糟。给出错误数就有了目标，执着地寻找。给出位置就完美修复。

第4课yongol validate做的正是这个。“SSaC的CancelReservation调用了Reservation.SoftDelete，但sqlc查询中没有SoftDelete方法。“不是意见。是事实。AI唯一能有的反应就是"好的，我来修”。

研究表明"做TDD"这种过程指示反而会恶化回归，而将具体测试文件作为上下文提供则能减少70%的回归³。阻止回归的不是指示而是事实。

支柱2：棘轮锁定（Ratchet Pattern）

验证通过就锁定。

想象一把棘轮扳手。齿只能单向咬合。转就往前走，松手就停住但不会倒转。Ratchet Pattern把这个机制应用到智能体控制。

项目1：机械验证 → PASS → 锁定 → 下一个
项目2：机械验证 → FAIL → 重试（带反馈）
项目2：机械验证 → PASS → 锁定 → 下一个
...
项目N：PASS → 完成。停止。

三条规则：

• 一次只展示一个项目。
• 通过才能解锁下一个。
• 全部通过就停止。

实际差距用数字来看：

自主智能体：  40 / 527  (7.6%)  — 智能体宣布"完成"
棘轮CLI：    527 / 527 (100%)  — 机器宣布"还剩487个"

同一个模型。同一个项目。区别是谁判定"结束”。

自主智能体中LLM判断终止。LLM是乐观的。做了40个就"觉得"够了。棘轮中机器判断终止。机器不会"觉得”。剩余项目到0才宣布"还没完”。

第3课学的Hurl测试就是棘轮的一种形式。Hurl测试通过就锁定。添加新功能时不能删除现有测试。智能体可以自由改代码，但不能改行为。只能前进。

支柱3：决策与实现的分离

第4课亲身体验过的。再整理一次原理。

源代码中混着三样东西：

• 用户决策 — 这个字段是BIGINT。这个API只有所有者能访问。
• 业务逻辑 — 定价策略、工作流、状态转移。
• 实现细节 — 变量名、错误处理、库调用。

AI读这些代码时，看到的是三样东西混在一起的文本。说"重构"它就把你的决策当细节覆盖了。

把决策移出代码，这个问题就消失了。决策住在SSOT里，代码是从SSOT生成的一次性投影。AI不会把决策当成细节。决策的存活与模型大小无关。

三根支柱协同工作

三根支柱不是各自独立的。它们协同工作。

把第4课体验的yongol工作流分解为三根支柱：

AI编辑SSOT                     ← 支柱3：决策与实现分离
  ↓
yongol validate返回错误         ← 支柱1：确定性反馈
  ↓
AI修复错误
  ↓
validate通过 → 棘轮锁定         ← 支柱2：棘轮锁定
  ↓
下一个功能

1. 分离 — AI编辑的不是代码而是声明式规范。只有决策没有细节。
2. 反馈 — validate精确指出矛盾。“这个字段和那个字段不一致。“是事实。
3. 锁定 — 通过就继续。不回头。

如果缺了哪个：

• 只有分离没有反馈：反馈精确但无法阻止AI覆盖决策。
• 只有反馈没有锁定：不知道哪里错了，AI无方向地修。
• 只有锁定没有反馈：AI改了又坏，震荡。

三根支柱缺一不可才能保证收敛。

Symbolic Feedback Loop — 比火车更重要的是铁轨

把到目前为止的内容整理成一个结构：

LLM生成 → 确定性工具判定 → 结果反馈给LLM → 重复

这叫Symbolic Feedback Loop。

为什么叫"Symbolic”？因为反馈由数字、文件名、行号这样的具体符号（symbol）组成。不是"好像有点不对"而是"第41行，应该是user_id但写成了userId”。不是人的自然语言判断而是机器的确定性判定。所以叫Symbolic Feedback Loop。

现在业界的主流方式不同。AI验证AI。一个LLM写代码，另一个LLM审查。这叫LLM Feedback Loop。

打个比方：喝醉的人问喝醉的朋友"我喝多了吗？"。两个都是概率性的，所以错误累积。

Symbolic Feedback Loop不同。go test不会产生幻觉。yongol validate不会谄媚。覆盖率测量不会说谎。确定性工具每次对相同输入给出相同输出。

想想编程智能体为什么有效。在Claude Code中AI写代码，保存到文件系统，运行测试，尝试构建。这个过程中有确定性门控（测试、构建、类型检查）嵌入。这无意中创造了Symbolic Feedback Loop。所以才有效。

那为什么会崩溃？在没有测试的区间崩溃。确定性门控缺失的地方，AI做概率性判断，概率性判断以乘法衰减。

97.7%准确率的步骤连续串联：

• 2步：0.977 x 0.977 = 95.4%
• 5步：0.977^5 = 89.1%
• 10步：0.977^10 = 79.2%
• 100步：0.977^100 = 4.8%

这就是氛围编程在200个端点时崩溃的数学解释。小项目串联步数少所以概率撑得住，大项目乘法灾难性地发挥作用。

棘轮解决这个。每步嵌入确定性门控，衰减就被重置。一次跑10步乘法是灾难性的，但每步用棘轮固定的话准确率在每步独立。

让火车更快不如铺铁轨重要。很多人在造火车。铺铁轨的人几乎没有。

“不要换模型，添加契约”

这是Reins Engineering的核心命题。

同一个模型可以停在40也可以完成527。同一个模型编辑原始代码会漂移，编辑SSOT就收敛到0错误。同一个模型没有反馈停在60-70%覆盖率，有反馈就到100%。

区别不是模型，是反馈拓扑。

“添加验证循环比提升模型IQ便宜10倍。”

用比喻来说：人治 vs 法治。

人治依赖贤明的君王。君王聪明国家运转，愚蠢就垮。等更聪明的模型就是人治。“GPT-6出来就解决了。”

法治依赖法律。君王聪明还是愚蠢，有法律系统就运转。添加契约就是法治。“validate能抓住的话什么模型都收敛。”

人类已经知道这个答案了。用血写的约定。80亿人在一个星球上共存不是因为人性善良，而是因为有法律。

AI也一样。

约束就是契约

法治要运转需要三个条件：

1. 可验证。 是否违规能被机械判定。

2. 违规有定义。 不是"不要写坏代码"，而是"这个字段和那个字段类型不匹配就是违规"。离散的。要么违规要么不违规。

3. 可强制执行。 违规有后果。yongol validate失败就拒绝代码生成。没有后果的约定不是约定而是愿望。

把这三个条件放在一张表里就能看到模式：

所有有效的系统都有约定。约定可验证、违规有定义、可强制执行——系统就收敛。

没有约定就是混乱。AI每次产出不同结果。没有终止条件。漂移累积。

约定过多就是压迫。什么都规定灵活性就没了。3行的函数强加10行的验证规则就本末倒置了。

要找到黄金比例。足够约束但不过度的那个点。yongol的287条规则是"层与层之间不能有矛盾"这个最小约定。层内AI自由编写。只在层间契约起作用。

充分的自由中有充分的秩序。这就是黄金比例。

谄媚偏差不是Bug而是资产

被认为是AI最大缺陷的谄媚偏差（Sycophancy）——“用户说什么就同意的倾向”——在Reins结构中反而成为资产。给意见就谄媚，但给确定性事实就乖乖接受并实际修复。这个谄媚偏差在棘轮结构中反而有帮助。原因在第7课详细讲。

编程智能体有效的真正原因

第2课学了"为什么会崩溃"。现在该理解"为什么有效"了。

同一个模型。在网页聊天中产生幻觉的那个模型，在Claude Code里能一次性搞定200行的功能。模型没有突然变聪明。变的是结构。

对话式AI的循环：

LLM → 人 → LLM → 人

反馈全是自然语言。概率性生成接概率性评估。

编程智能体的循环：

LLM → 代码生成 → 文件保存 → 测试运行 → pass/fail → LLM

循环中嵌入了确定性门控。文件系统按写入的原样保存。测试要么pass要么fail。编译器错就说错。

AI是每次产出不同结果的不稳定组件。但在不稳定组件上放置稳定规则是工程一直在做的事。

大海翻涌但灯塔不动。快递偶尔丢失但有追踪号就找得到。在不稳定之上建立稳定体系不是什么特别的事，而是工程一直在做的事。

编程智能体有效的原因相同。在不稳定的AI上放了确定性验证器。

Reins Engineering是把这种偶然变成意图。不是"恰好有测试所以能用"，而是"有意识地设计验证门控以保证收敛"。

总结 — 本课要记住的

1. 四个时代。 提示→上下文→围栏→缰绳。每个时代从上一个时代的局限中诞生。围栏（Harness）不定方向。缰绳（Reins）定方向。

2. 三根支柱。 确定性反馈、棘轮锁定（Ratchet Pattern）、决策与实现分离。三者齐全才能保证收敛。

3. Symbolic Feedback Loop。 LLM生成，确定性工具判定，结果反馈给LLM。铁轨比火车重要。

4. 不要换模型，添加契约。 同一个模型根据反馈拓扑可以停在40也可以完成527。不是人治而是法治。

5. 谄媚偏差是资产。 给意见就谄媚，给事实就接受。确定性反馈 + 谄媚LLM = 保证收敛的循环。

实操：区分决策和细节

目标： 在脑中打开你的项目，找出决策和细节在哪里混在一起。

基于上面体验中的感受来思考。

问题1：你的项目中"决策"是什么？

回想你让AI"做"的那些东西。其中"这个必须这样"的就是决策。比如：

• “登录用邮箱” — 决策
• “密码至少8位” — 决策
• “变量名叫userEmail” — 细节

写下3个决策和3个细节。

问题2：写在CLAUDE.md里的决策有没有在代码中被覆盖过？

第1课创建了CLAUDE.md。里面应该写了规则。AI有没有忽略那些规则、做出不同的东西？有的话那正是决策和细节混在一起导致的漂移。

问题3：如果那些决策放在代码外面呢？

如果那些决策不在代码里而在单独的规范中，AI能覆盖吗？第4课yongol做的正是这个。把决策移出代码，从根本上阻止AI把决策当细节覆盖。

这次思想实验应该体会到的：

• 决策和细节是不同的东西这个感觉
• 在代码中这两者无法区分的认识
• 第4课的工具（yongol）和第5课的原理（Reins Engineering）是同一个结构的理解

下一课预告

第5课理解了Reins的原理。第6课深入探讨Ratchet Pattern。把停在40的智能体推到527的具体方法。棘轮原理、大批量作业中的应用、以及Symbolic Feedback Loop的实战实现。

相关文章

• Reins Engineering — 有缰绳的AI
• 反馈拓扑比模型IQ更重要
• 约束就是契约

Reins Engineering 全部课程

参考资料来源

1. 卡内基梅隆大学，MSR 2026 — AI编程工具引入后代码复杂度永久增加41%。
2. Google DORA报告，2025 — AI采用率每增加25%，交付稳定性下降7.2%。
3. TDAD，ACM AIWare 2026 — “做TDD"过程指示（6.08%→9.94%）恶化回归，提供具体测试文件作为上下文（6.08%→1.82%）减少70%回归。