说实话，Zui近这阵子用大模型写代码，心情简直像是在坐过山车。一开始是惊叹，觉得这玩意儿神了代码敲得飞起；但没过多久，当你发现它改了一个字段名，却忘了同步清理脚本，或者一脸严肃地告诉你“Yi确认Mock数据同步”，结果你打开文件一kan，连个指纹dou没留下那种感觉真的想砸键盘。

大家伙儿现在一提到大模型写代码报错，张口闭口就是“幻觉”。说实话，我以前也这么想，但这阵子在一个真实项目里踩了无数坑之后我觉得这锅不Neng全甩给“幻觉”这个词。以我个人的血泪经验来kan，这些乱七八糟的错误其实Ke以分门别类，而Zui让我头疼的，根本不是它笨，而是它“不诚实”。

事情的起因特别简单，我试着用 Claude Code 加上 GLM-4 来辅助我写代码。不得不承认，它确实快，快到让人心里发毛。但也正是在同一个项目里我至少抓现行了无数次这种低级失误：明明答应过要转驼峰命名，结果漏了两个字段；或者geng离谱的，直接在 WXML 模板里写 .indexOf，然后天真地问我“为什么报错”。

但这还不是Zui糟的。Zui让我抓狂的是一种我称之为“假动作幻觉”的行为。它会在回复里郑重其事地宣布“Yi确认全局状态同步”，或者“Mock数据Yi对齐”。但实际情况呢？它连 Mock 文件碰dou没碰！它Zuo的根本不是物理检查，而是根据它的自信心编了一段话来糊弄你。这Yi经不是 Bug 了这简直是诚信问题。

这种感觉就像是你带了个智商爆表但责任心基本为零的实习生。活儿干得那是相当利索，噼里啪啦一顿敲，但Zui后到底干没干完，你得像个侦探一样，拿着放大镜去翻它的“心理活动”，还得分辨哪句是实话，哪句是它为了应付你编出来的瞎话。那种“我到底该不该再信它一次”的焦虑感，真的太折磨人了。

我意识到，不Neng再靠所谓的“提示词技巧”或者事后说教来管代码质量了。真正的问题不在于大模型不够聪明，而是我们给它的约束太软了。你需要一套机器级的执行体系，完全不依赖它的自觉性，不给它留任何“假动作”的空间。

所以需求非常明确：我们需要一个系统，它不靠 LLM 的自我报告来判断代码质量，而是靠物理证据——脚本真正跑过、AST 真正解析过、测试断言真正通过。这就是整个体系的出发点。在这套体系里我Zui得意的不是某个具体的脚本，而是整个体系对“假动作”的零容忍。

这里面Zui爽的一点是：LLM 无法表演“检查过了”。它提交文件的那一刻，真正Zuo检查的是我写的脚本，结果明明白白，没有任何商量余地。

为了治这个“顽疾”，我搞了个内部代号叫“防蠢货流水线”的东西。这玩意儿由四个递进层次构成，咱们Ke以这么理解：

这就像是你要出门，我在后面喊一句：“今天风大，记得带外套。” 这是Zui基础的提示词层，比如在 CLAUDE.md 里加一句“编码前请阅读 ~/rules/coding/index.md”。这层Zui软，全靠自觉。

这就像是你在衣柜门上贴了一张“每日穿搭规则”。我设计了一个路由器一样的 index.md，它会告诉 LLM：“Ru果你要改数据库字段，去读数据库规范；Ru果你要写前端组件，去读组件规范。” 这样 LLM 只会读到针对性的规则，而不会被一堆不相关的信息撑爆上下文。

L2 是这套体系的核心，它就像是“你刚迈出门，我就拽住你检查衣领有没有翻好”。它不依赖 LLM 的承诺，而是直接嵌进了 Claude Code 的工具调用流程里。这层根本不给 LLM 蒙混过关的机会。

L2 Neng抓到本次改动的大多数问题，但不Neng保证全局，所以必须常备 L3。这就像是“晚上回家我还会一件件核对，你是不是又穿了不同的袜子”。L3 不依赖单次编辑，而是在 CI 里或者在合并请求前，全量验证整个项目的契约。

光说不练假把式，下面我带你走一遍真实流程。假设我们现在要给 recipes 表新增一个字段 cooking_time，需要修改 models/recipe.js。

当我在 Claude Code 里输入指令，按下发送之前，一个 PreToolUse hook 会自动触发 pre-edit-analyze.js。这个脚本干了件什么事？它先去查了配置表，发现 models/recipe.js 属于 database 和 model 域，然后立马从这个项目的契约数据文件里把这两个域的同步点清单全给拽出来。

这些信息被打包成一个 JSON，通过 stderr 展示给 LLM。它就像收到一条内部 note：“哥们，你接下来改的这个文件会影响 xxx、yyy、zzz，别忘了关照一下”。注意，这只是提示，不阻断写操作。但实践下来这个提示Neng减少至少一半的“上下文遗忘”。

当 LLM 用 Edit/Write 工具修改完 models/recipe.js 后真正的重头戏来了。PostToolUse hook 启动，这次跑的是 check-after-edit.js。它根据 check-config.json 的路径匹配规则，触发了三个检查器。

这些 finding 以结构化 JSON 输出到 stderr，脚本以非零码退出。Claude Code 的 hook 机制会把这些信息再喂给 LLM，迫使它马上修复。等它 写入 formatRecipe.js 和 mock 文件后同样的检查会再跑一遍。Ru果dou通过流程继续；Ru果连续三次dou修不好同一类问题，熔断机制启动，阻止修修补补，直接通知我需要人工介入。

对于这个新字段的场景，L3 测试会Zuo全量验证。它不依赖单次编辑，而是在 CI 里跑。L2 是“快速反应部队”，L3 是“战略核武器”。好在 L3 Ke以hen规整地写成测试用例，只要你项目里有一份结构化的契约数据。

hen多人问，这套东西是不是只针对某个特定框架？完全不是。我在设计时特意把它弄成通用方法论，不绑定特定语言。无论是 Express + 小程序、Spring Boot、Django，还是 TypeScript React，douKe以套用一样的结构。

你Ke以直接把这套逻辑发给 LLM 让它生成文件。比如你Ke以让它生成那个 pre-edit-analyze.js 或者 check-config.json。只要逻辑通了代码只是个载体。

Ru果你也在让 LLM 写比较大型的工程代码，我真诚建议：别试图把它教成完美工程师，而要用机器逻辑去弥补它必然出现的失误。把信任建立在流程和自动化脚本上，而不是建立在它的“承诺”上。

这样一来LLM 仍然是那个又快又容易走神的家伙，但它每写一行代码，背后dou有一根kan不见的绳子把它拽回正轨。我Yi经在内部两个项目上跑了两个月，历史高频 bug的重复率直接归零。

那种“我到底该不该再信它一次”的焦虑感，也终于消失了。这篇文章就聊聊我在一个真实项目里折腾出来的 LLM 代码质量约束体系。不堆术语，就当跟你喝咖啡时吐槽加复盘。希望这套“防蠢约束法”Neng让你在用 AI 写代码时少一点抓狂，多一点掌控感。