Reins Engineering — 给AI装上缰绳 Image: AI generated

没有缰绳的马

AI编程工具变得很快。30秒完成登录，2分钟搞定支付，三周内交付一个MVP。

三个月后，一切崩塌。

AI"整理"支付逻辑时改变了折扣计算。重构请求修改了公开API的字段名。添加新功能破坏了认证。根据卡内基梅隆大学的研究（MSR 2026），采用AI编程工具后，代码复杂度永久增加41%。Google DORA Report（2025）显示，AI采用率每增加25%，交付稳定性下降7.2%。

问题不在于AI愚蠢。而在于没有缰绳。

围栏只是围栏

业界的回答是"harness engineering"。Linter、格式化工具、CI/CD、项目结构、编码规范。防止代理越界的围栏。

围栏不指明方向。代理在围栏内做什么——覆盖现有逻辑、更改类型、跳过状态转换——linter通过，格式化通过，CI通过。代码到达生产环境时"干净但错误"。

鞍装好了，骑手上马了。但没有缰绳，只能用大腿夹紧，三个月后摔下来。

Reins Engineering

Reins Engineering是一种工程方法，给AI代理提供确定性契约，当契约被违反时阻止推进。

它由三个要素构成：

1. 确定性反馈

给代理事实，而非意见。不是"这看起来有问题"，而是"第41行：字段名不匹配，期望’user_id’，实际为’userId’"。不给阿谀奉承留任何空间的反馈。根据TDAD研究（arxiv 2026），程序性的"做TDD"指令反而加剧回归（6.08% → 9.94%），而在上下文中提供具体测试文件可将回归减少70%（6.08% → 1.82%）。

2. 契约锁定（Ratchet Pattern）

验证通过后，锁定它。Hurl测试以纯文本声明API行为，每次提交时在CI中运行。通过的测试不可删除。代理可以自由修改代码，但不能改变行为。漂移在结构上被抑制。

3. 决策与实现分离

代码中混合的三样东西——用户决策、业务逻辑、实现细节——被分离。决策存在于声明式规范中（OpenAPI、DDL、状态图）。实现由AI自由生成。AI无法将决策误认为细节而覆盖。决策的存续不再依赖模型大小。

演进

Prompt Engineering      → Say it well and it works
Context Engineering     → Give good context and it works
Harness Engineering     → Contain it with structure
Reins Engineering       → Steer it with direction

每个阶段都诞生于前一阶段的局限。仅靠提示词缺乏一致性。上下文无法阻止代理失控。围栏无法防止边界内的漂移。

Reins Engineering不是围栏——是缰绳。它不限制代理的自由，而是确保代理到达目的地。

为什么更大的模型不是答案

“GPT-6会解决一切。”

不会。问题不在于模型智能——而在于介质。代码作为介质无法区分决策与实现。任何模型读代码时都看到决策和细节混在同一段文本中。

一个4.5B的本地模型（Gemma4），配合确定性反馈+示例上下文，可以将SSOT编辑到零错误。前沿模型编辑原始代码则产生漂移。差异在于结构，而非智能。

不要换模型。加上契约。

证据

yongol是Reins Engineering的实现。它用287条规则交叉验证10个声明式规范（SSOT）的一致性并生成代码。

ZenFlow基准测试——一个多租户工作流自动化SaaS。32个端点，14张表，47个Hurl请求。11/11阶段通过。添加功能没有减速。现有测试从未失败。

使用本地4.5B模型成功生成了可工作的后端。成本$0。离线运行。缰绳弥补了模型规模留下的差距。

没有缰绳的围栏只是围栏

AI已经足够强大。缺少的是方向。

围栏建得越高，代理在里面漂移得越快。握住缰绳，代理就会跑向目的地。

Reins Engineering——面向AI代理的结构化确定性验证。

References