一位 Claude Code 重度用户用一年时间在生产项目里得出结论：让 AI 老实干活的瓶颈不在模型——把注意力从"让模型更聪明"转到"让约束更硬"，效果比换三次模型加起来都明显。核心思路是把 AI 当概率性执行系统管，通过三层约束把概率压成确定性。

这是什么

文章把工程实践拆成三层：

规则层（弱）：把项目规矩写进 CLAUDE.md、.claude/rules/、Skills、Commands。关键：规则必须可被脚本检查——"高质量"这种话对模型几乎没有约束力。

分工层（中）：用 SubAgent（子代理）隔离角色。经典三角色：planner（只出计划不写代码）、coder（按计划实现）、reviewer（独立小模型只读审查）。核心：让"写的人"和"审的人"不在同一上下文，避免自我审查。

反馈层（强）：用 Hooks（自动触发的脚本钩子）、MCP（连接外部工具的协议）、Checkpoint（自动校验点）、验收脚本做运行时强制——做不到就走不掉。这才是真正有强制力的一层。

最反直觉的发现：让 AI 审查自己写的代码，等于让考生给自己阅卷；改用小一档、不同系列模型审查，反而能打破过度认同且更便宜。

行业怎么看

这呼应了 AI 工程圈过去半年的共识转向：从"调 prompt 调模型"转向"做工程约束"。LangChain、Anthropic 都在强调类似观点——Agent 项目失败 70-90% 卡在工程化阶段，不是模型不够强。

反对声音同样明确：把 AI 当"必须严管的初级程序员"成本不低——维护 200 行 CLAUDE.md、配置 Hooks 的人力，可能比雇一个初级工程师还贵。这套打法只适合对质量有持续高要求的团队，对一次性脚本或个人项目属过度工程。

另有一种观点："把概率压成确定性"的提法过于乐观。同样的 prompt 产出不同结果，本就是大语言模型的工作方式，工程约束只能降低方差、无法消除它。

对普通人的影响

对企业 IT：部署 AI 写代码工具时，重点不是选哪家模型，而是工程团队能否维护这套约束体系——否则大概率卡在"demo 惊艳、生产翻车"。

对个人职场：会用 AI 与能用 AI 交付可靠产出之间，隔着一道工程约束的门槛。这道门槛正在成为程序员的新分界线——不是会不会写代码，而是会不会给 AI 立规矩。

对消费市场：普通用户短期内接触不到这套玩法，但 SaaS（软件订阅服务）会逐步把类似约束封装进产品。未来"一键 AI 写代码"的体验差距，可能就藏在这类看不见的工程细节里。