我见过两类工程师。
第一类，用 Claude Code 改一个老项目，改完上线，稳。第二类，用同一个工具，改完发现 AI 顺手动了核心业务逻辑，回滚，重来。
工具一样。差别在哪？
不在提示词写得好不好。不在模型聪不聪明。在于一件大多数人从来没想清楚的事：AI 不是一个员工，是一个每次上班都失忆的实习生。
你不给它上下文，它什么都不知道。你不给它边界，它按自己的"最佳判断"乱改。你不验证它的产出，你永远不知道它什么时候悄悄画了一张错的图、漏了一个关键接口、把两张表的关系搞反了。
这篇文章要给你一套框架，解决这三件事。名字叫三层控制。
先说一个反直觉的结论
大多数人以为，用 AI 越多、越熟练，就越放心。
实际上恰好相反。用得越多、越不敢用。 因为你开始见识到它出错的各种方式：它能写出一段逻辑完美的函数，同时悄悄忽略了一个并发边界；它能认认真真读完你给它的文档，同时对文档之外的隐性约定一无所知；它能给你一张漂亮的架构图，同时把一个废弃模块画成核心模块。
这不是模型的问题。这是一个结构性问题：你没有给 AI 一个稳定工作的骨架。
三层控制就是这个骨架。
第一层：理解——你以为 AI 看见了，它其实是瞎的
有一个实验你可以做：把你们项目的 README 和主要源码文件扔给 AI，让它梳理系统架构。它会给你一份看起来很像样的文档。
然后问自己：这份文档里，有没有那个"某个对接方在生产环境悄悄在用的、三年前写的、从来没写进任何文档的老接口"？
大概率没有。因为那个接口只存在于某个老工程师的脑子里。
这就是上下文缺失的真实后果。AI 不是一个能自己去探索项目的工程师，它是一个只能看见你给它的东西的实习生。 你给它什么，它就能看见什么；你没给的，它看不见，但它不会告诉你它没看见——它会直接基于它看到的那些东西给你答案。
所以理解层要做的，是一件主动的事：把分散在代码、文档、wiki、人脑里的项目知识，整理成 AI 能读到的形式。
具体包括：架构全景（核心模块是什么、怎么组织）、风险地带（哪些地方动了会出事）、隐性约定（"这段不要删"、"这个接口对接方 A 在用"），最后翻译成一份 AI 每次启动都会读的指令文件——CLAUDE.md。
理解层没做扎实，后面两层都是空中楼阁。AI 都没看见完整的项目，你怎么让它听话？你怎么验证它的产出？
第二层：约束——AI 的"好心"比它的失误更危险
AI 乱改代码，很多时候不是因为它在偷懒，是因为它在"帮你"。
它看到一段老代码，命名不规范、逻辑冗余，按它理解的最佳实践，应该重构。所以它重构了——哪怕你根本没让它碰那段代码，哪怕那段代码是核心业务逻辑，哪怕那段"不规范"的写法背后有三年的历史原因。
这是比 AI 犯错更难处理的情况：AI 做了一件它认为正确的事，而你根本不知道它做了。
约束层要做的，是把"不要改什么、该怎么改、改成什么样"写清楚，让 AI 在你画的框里干活。
约束分两种。静态约束是写进 CLAUDE.md 的长期规则——"只动你要改的文件，不要顺手重构其他文件"、"这个类保持方法签名不变"——写一次，长期复用。动态约束是每次任务的即时指令——"只改这三个文件"、"改之前先跟我确认方案"、"有任何不确定的地方停下来问我，不要猜"——这些每次都要给，不能省。
Anthropic 把这套给 AI 搭约束的工程工作叫 Harness Engineering。Harness 是马具——套在马身上让马听话干活。这个比喻很准确。AI 不是天然就往你要的方向跑的，你得给它套上马具。
第三层：验证——"看起来没问题"是最危险的感觉
AI 给你一段代码，跑起来没报错，逻辑看起来对，测试也过了。
你要不要上线？
先问一个问题：那个测试是谁写的？
如果是 AI 写的，你刚才验证的，只是 AI 对它自己产出的判断。AI 能生成代码，但它对自己代码的"正确性判断"没那么强——它不知道那个没被测试覆盖到的并发边界，它不知道那个它没意识到的边角场景。所以它写的测试，天然就覆盖不到它没意识到的问题。
这是一个封闭的圈：AI 用它不知道的盲区，测试它自己的盲区。
验证层要打破这个圈：建立一套独立于 AI 的基准。
动手改之前，先让 AI 写一套覆盖核心链路的集成测试，锁住现在的行为。改完跑一遍，看什么被破坏了。对那些说不清逻辑的老代码，让 AI 根据实际行为写 Characterization Test——不保证代码"是对的"，但保证改前改后行为一致。改完了，除了自己看，再让 AI 从攻击者视角审一遍自己的产出。接口改造，最后用 curl 跑几个场景对比改造前后的响应。
验证不是事后补票，是动手前就建好的安全网。这张网越密，你越敢放手让 AI 做事。
三层之间有一个正循环，大多数人不知道
三层不是三件独立的事，是一个链条：理解决定约束，约束决定验证，验证反过来补理解。
连模块关系都没理清，写不出"这个模块不能依赖那个模块"的约束。约束里没写"核心接口响应格式不能变"，验证就不会去校验这一点。验证跑出了一个边角场景的问题，这个发现回补进理解层，以后的 CLAUDE.md 多一条规则。
这个循环转几圈，AI 就从"看起来能用"变成"真的可信"。
但这里有一个陷阱：大多数人把三层当成一个按顺序走一遍的流程——先建理解、再建约束、再建验证。
不是。三层是时刻在工作的骨架，不是一次性的流程。
你在改代码，AI 问了一个字段的含义，你回答了一句——这一句进了理解层，应该沉淀到 CLAUDE.md。你在提示词里加了一句"不要改测试文件"——这一句进了约束层。你改完补了两个测试 case——这进了验证层。
理解、约束、验证，不是三件要专门安排时间"建立"的事，是每次你和 AI 协作时同时在做的三件事。
最后一个问题
回到开头：为什么有人用 AI 越用越稳，有人越用越不敢用？
稳定用 AI 的工程师，每次协作都在给三层添砖加瓦。理解更深一点，约束更准一点，验证更密一点。
混乱用 AI 的工程师，每次从零开始，一次性用完就扔。没有积累，没有骨架，下次还是同样的混乱。
AI 能力的上限不在模型，在你给它搭的骨架。
三层控制，就是那个骨架。
搜索公众号:"知悟之旅"关注我看更多
