模型变聪明就能解决问题吗？
AI编程工具的主流叙事是这样的：等模型足够好了，它就能自己写代码、写测试、做重构。GPT-4做不到的，GPT-5能做到。Claude搞不定的，更大的Claude能搞定。
真是这样吗？
我让Claude Opus 4.7执行filefunc重构。无需人工审查，一小时完成。validate通过，pytest通过，coverage保持。仅看结果，似乎印证了"模型好就行"的叙事。
但如果让同一个模型在没有filefunc规则的情况下做同样的重构呢？没有validate？没有coverage反馈？结果截然不同。它陷入doom loop——修一个bug引出另一个bug，修那个又破坏别处。
同一个模型。改变的是环境。
“都做完了”——智能体的过早终止本能
同一个模型的另一个实验。我让智能体自主处理一个有527个函数的项目。“给每个函数写测试。“智能体完成后报告：“已完成。”
实际写了测试的函数：40个。 527个中的40个。
智能体没有说谎。它做了40个之后判断"够了”。LLM的默认倾向是乐观的过早终止。遇到困难的函数就跳过，再做几个，然后得出结论：“剩下的也是类似的模式，差不多了。”
用CLI工具强制循环后：
自主智能体: 40 / 527 (7.6%) — 智能体宣布"完成"
CLI loop: 527 / 527 (100%) — 机器宣布"还剩487个"
同一个模型。同一个项目。差别在于谁来决定"结束”。
环境塑造模型
两个实验指向同一个结论。Opus 4.7能完成，不是因为它聪明，而是因为specification surface是machine-checkable的。
filefunc validate → 代码结构是否满足规则？
pytest → 既有行为是否保留？
coverage → 哪些分支缺失？
这三者在每次修改后都即时返回反馈。模型接收反馈、修正、再接收反馈、再修正。self-correcting loop。
关键在这里：
决定结果的是反馈拓扑，而非模型IQ。
LLM生成能力强，但correctness保障弱。然而当存在deterministic verifier时，性能会急剧稳定。lint、typecheck、test、coverage——这些成为修正模型输出的gradient signal。
“模型足够聪明就能解决"是一个错误命题。准确地说是：”反馈足够快，当前模型就能解决。"
broad exploration vs local correction
LLM的强项不是broad exploration，而是local correction。
“给这个项目写测试”——这是broad exploration。LLM会迷失方向。
“line 41未被覆盖”——这是local correction。LLM会精准地写出覆盖那一行的测试。
在实际项目中验证的数据：
无反馈: coverage停滞在60~70%
有反馈: 达到100%（限可达函数）
同一个模型。“line 41 not covered"这一行充当了gradient signal。这个反馈将LLM的修正引导到精确的方向。
Symbolic Feedback Loop
贯穿所有观察的是一个结构。
LLM生成 → 确定性工具判定 → 结果反馈给LLM → 重复
我称之为Symbolic Feedback Loop。
当前业界主流是LLM Feedback Loop——AI验证AI。就像一个醉汉问另一个醉汉：“我醉了吗？“双方都是概率性的，所以错误不断累积。
Symbolic Feedback Loop不同。pytest不会产生幻觉。go test永远不会醉。coverage测量不会说谎。规范验证不会漂移。
这个结构适用于correctness可以被机械判定的领域——代码、测试、规范、类型。API设计的优雅性或UX的自然感，目前还无法用符号化工具来判定。扩展这个边界是下一个课题。我相信存在一条路径，能将自然语言也纳入可验证的边界之内。
与其让模型更聪明，不如让返回给模型的反馈更精确。
决策的委托
不应把决策委托给AI，这是不言自明的。但让人类检查和决定一切是极其辛苦的。某些重复性、结构化的决策，可以由符号化工具代替人类执行。
“这些测试是否覆盖了所有分支？"——人不需要逐行阅读。coverage工具来判定。“这段代码是否满足结构规则？"——人不需要审查。validate来判定。“还有未处理的函数吗？"——人不需要去数。CLI来声明。
不能委托给AI的决策，可以委托给符号化工具——因为它们是确定性的，不是概率性的。这就是Symbolic Feedback Loop存在的理由。
比起让火车跑得更快，铺设铁轨更重要。
很多人在造火车。铺铁轨的人几乎没有。