我观察过很多工程师用 Claude Code。
同一个工具，改同一类老项目，结果分化得很明显。有人越用越顺，改造完上线，稳，睡得着觉。有人越用越不对劲，改完不知道动了哪里，不敢上线，或者上线出了事，连夜回滚。
你可能想说，那肯定是提示词写得不一样，或者用法不对。
反正我觉得，这两个答案都不是核心。
差别在一件大多数工程师从来没想清楚的事，给 AI 搭没搭骨架。
先说说「越用越不敢用」这件事。
我觉得这个感受很正常，甚至是你开始真正理解 AI 的信号。
刚开始用 Claude Code 的时候，你容易对它抱有一种模糊的信任，感觉这玩意挺聪明的，改个东西应该没问题。然后你真的让它改，它给了你一段代码，跑起来了，你觉得 OK。
但用着用着，你开始见识到它出错的各种方式。
你让它加一个字段，它加完顺手把同一个类里的几个老方法也「优化」了，因为觉得那几个方法「写得不够规范」。你根本没让它碰那里，那里还是核心业务逻辑。
你让它帮你梳理接口清单，它梳理完给了你一份看起来很漂亮的文档，但你后来发现，有个对接方在生产上悄悄在用的一个老接口，那份文档里压根没有，因为那个接口从来没写进任何文档，只存在于某个老工程师的脑子里。
你让它改一个功能，改完跑测试，全过了，你松了口气准备上线。然后你想起来，那个测试是它自己写的。
。。。
这些经历叠加在一起，就会产生一种说不清楚的不安感，用得越多，越不敢放手让它干。
这个感受是对的。因为你在用一个每次上班都失忆的实习生，但你从来没给它搭过任何骨架，然后把一把钥匙丢给它，让它自己进去改核心机房。
改出事是迟早的。
搭骨架这件事，有个名字，叫三层控制，理解、约束、验证。
三层对应三个问题，AI 看不见、AI 自作主张、AI 产出没法验。这三个问题，大多数人翻车的根源都在这里，只是表现形式不一样。
先说第一层，理解，让 AI 看见。
你把 README 和几个核心文件扔给 Claude Code，让它帮你梳理架构，它会给你一份看起来很专业的文档。
但我问你，那份文档里，有没有那个「某个对接方三年前开始用的、从来没写进文档的老接口」？
大概率没有。
因为 AI 只能看见你给它的东西，它看不见的，它不会告诉你它没看见，它会直接基于它已知的东西给你答案，给得还很自信。
老项目的上下文来自三个地方，代码本身、文档和 wiki、还有人脑。第一层你还好搞定，第二层靠 README 能覆盖一部分，但第三层，那些只活在老工程师记忆里的隐性约定，AI 永远看不见，除非你主动搬出来给它。
「这段不要删」，「这个接口对接方 A 在用，动了他们就挂」，「这个字段名看着奇怪，是当年为了兼容旧版本故意这么写的」，这些东西，你不说，AI 永远不知道。
修复这一层的基础动作，是建两个文件。一个是 ARCHITECTURE.md，让 AI 先帮你画一遍架构全景，你在上面标注哪些模块是核心的、哪些已经废弃、哪些地方动了会出事，把这些标注保存下来。另一个是 CLAUDE.md，这是 Claude Code 每次启动都会自动读取的指令文件，你把项目的隐性约定、禁止修改的地方、命名规范统统写进去。
今天可以做的第一步，打开你的项目，问自己，有没有哪个地方「动了一定出事但从来没写成文档」，把这条写进 CLAUDE.md。就这一条，先开始。
说到这块，第二层的问题其实更隐蔽，约束，让 AI 听话。
我觉得「AI 犯错」和「AI 好心帮你」是两件完全不同性质的事。
AI 犯错，你发现了，修就是了，还好。但 AI「好心帮你」，你可能根本不知道它帮了什么，等出了问题才往回查，才发现它在你没注意的地方动了一堆东西，全是它自认为的「最佳实践」。
这比 AI 犯错难防多了。
AI 的本能，是按它训练数据里理解的「规范写法」去处理代码。老项目里很多东西不是按规范写的，是有历史原因的，AI 不知道这些原因，它就按它的判断改，改出来的东西你不想要，但它完全没意识到自己做错了什么。
约束层解决这个问题，分两种。
静态约束是写进 CLAUDE.md 的长期规则，比如「只动你要改的文件，不要顺手重构其他文件」，「这个类的方法签名不能改，是对外兼容用的」，「命名用下划线风格，不用驼峰」。写一次，后面反复用。
动态约束是每次给 AI 任务时的即时指令，比如「只改这三个文件，其他一律不动」，「改之前先跟我确认方案」，「有任何不确定的地方停下来问我，不要猜」。这些每次都要给，不能省，不能指望 AI 记住上次说的。
Anthropic 官方把给 AI 搭约束框架这件工程工作叫 Harness Engineering，Harness 原意是马具，套在马身上让马按你的方向跑。这个比喻很准确，AI 不是天然就往你要的方向跑的，你得给它套上马具。
今天可以写进 CLAUDE.md 的第一条规则，「改动代码时，只修改任务明确要求的文件，不对其他文件做任何改动，包括重构和格式整理。」把这条粘进去，先有第一条。
第三层，验证，让 AI 可信，这层是大多数人完全没有的。
AI 给你一段代码，跑起来没报错，测试也过了，你觉得可以用了。
先问一个问题，那个测试是谁写的？
如果是 AI 写的，你刚才验证的，只是 AI 对它自己产出的判断。
这是一个封闭的圈，AI 用它自己不知道的盲区，去测试它自己的盲区。它能写出一个逻辑完整的函数，同时没意识到某个并发边界，而它写的测试，天然就覆盖不到它没意识到的问题。
你以为测试通过了就安全了，其实只是在一个封闭的圈里转了一圈，圈外的问题还在那里。
打破这个圈，需要一套独立于 AI 的基准。
改造之前，让 AI 先写一套覆盖核心链路的集成测试，锁住项目现在的实际行为。改完之后跑一遍，看什么被破坏了，被破坏的地方就是需要关注的地方。
对于那些说不清逻辑、也没有文档的老代码，还有一种叫 Characterization Test 的做法，让 AI 根据代码的当前实际行为写测试，不是测「代码是不是对的」，是测「改之前和改之后行为是不是一致的」，防止你在不知情的情况下改变了老代码的行为。这个概念来自 Michael Feathers 的《修改代码的艺术》，做老系统改造的工程师可以去翻一下。
改完还有一步，接口改造的话，最后用 curl 跑几个真实场景，对比改造前后的响应，有没有格式变了、字段少了、状态码不对了。
今天可以做的第一步，下次让 AI 改代码之前，先让它写一套集成测试把核心流程的行为锁住，再动代码。就这一个动作，安全感会明显不一样。
说完三层，有个误解要讲一下，这可能是大多数人三层转不起来的真正原因。
很多工程师读到这里会想，OK，那我以后改项目之前，先做理解层，再做约束层，再做验证层，走完一套流程再开始。
不是这样的。
三层不是一个按顺序走一遍的流程，是一个时刻在工作的骨架。
你在改代码，过程中 AI 问了一句「这个字段什么含义」，你回答了，这一句进了理解层，应该沉淀到 CLAUDE.md 里。你在提示词里加了一句「不要改测试文件」，这一句进了约束层，以后同类任务可以复用。你改完补了两个测试 case，这进了验证层，安全网又密了一点。
理解、约束、验证，不是三件你要专门花时间「建立」的事，是每次你和 AI 协作的时候都在同时做的三件事。
稳定用 AI 的工程师，每次协作都是在给三层添砖加瓦，积累越来越厚，AI 表现越来越稳。混乱用 AI 的工程师，每次从零开始，用完就扔，下次还是同样的混乱，甚至更混乱，因为项目越来越复杂但骨架还是空的。
回到开头那两种工程师。
一个越用越稳，一个越用越不敢用。
差别就在这里，不是提示词，不是模型，是有没有在每次协作里给三层添砖加瓦。
你知道该怎么选了。
觉得有收获，点个赞、在看、转发支持一下；想不错过更新，记得星标⭐。下次见。
本文由mdnice多平台发布