我最初上手Claude Code的时候一度觉得自己请了个“人工智障”。让它改个函数它能把整个文件重写一遍让它加个功能它非要顺手把旁边的老模块也“优化”一通同一个错误今天纠正完明天换个会话它原样再犯。那段时间我对它的评价就四个字不如自己写。后来我花了不少时间去观察它到底在什么情况下会“犯蠢”又做了大量实验调整协作方式才慢慢摸清楚一件事Claude Code的绝大多数“智障”行为根源不在模型能力而在于我没给它足够的上下文、清晰的边界和持续的反馈。把这三个问题补齐之后它才真正从一个需要逐行盯防的实习生变成了能连续好几个小时不掉链子的结对搭档。这篇文章就把我总结出来的三招完整写出来每一招都可以直接照抄进日常工作流先建持久化知识库再定编码约定最后搭反馈闭环。适合正在用Claude Code、或者刚准备把AI辅助编程引入日常开发的工程师参考。1. 先搞懂“人工智障”是怎么来的1.1 三个让人血压升高的翻车现场先说场景一改一个bug引入三个新bug。当时我在做一个某内部管理系统的前端页面列表页有偶发白屏的问题。让Claude Code去修它定位倒是快给入口参数加了一层判空但顺手把另一个分支的返回逻辑改错了。我review的时候只盯着它最初说的那几行没注意它还动了上面的公共函数结果上线当晚就有同事反馈页面打不开。那次之后我养成一个习惯每次让它改代码前先限定范围明确要求“只允许改哪几个文件、禁止碰哪些区域”同时还要求它输出完整的改动diff。这个习惯帮我挡掉了至少一半的乱改问题。再说场景二不懂项目分层自作主张。另一个某Web应用项目里约定得很清楚views放页面组件、services放接口请求、utils放纯工具函数。结果Claude Code在改一个弹窗组件的时候直接往views里塞了一段接口请求逻辑。代码能跑但项目分层全被打破了。这种事不是偶发的因为对一个没有项目背景的AI来说所有代码看起来都差不多同一个位置放什么都行。它不会天然理解“为什么views不能直接发请求”除非有人提前把这个约定写清楚。然后是场景三重复犯同一个错。这个最让人崩溃。我昨天刚告诉过它“时间字段一律用UTC存储展示层再转换成本地时间”今天新开会话让它写导出功能它又用回了本地时间。不是它不想学而是它确实记不住。每一次会话对Claude Code来说都相当于第一天报到前一天的约定全在终端关掉那一刻归零。这种“反复横跳”的行为刚开始会让人觉得是模型在犯蠢其实只是记忆机制的限制。1.2 不是模型笨是协作方式出了错把上面三个场景拆开看其实都指向同一批底层原因。第一上下文断层。Claude Code的单次会话能力很强但它只能看到当前窗口内的信息。你之前跟它说过的所有约定、所有纠偏一旦会话结束就全部丢失。第二指令模糊。像“你看一下这个问题”这种话对人来说可以靠默契补全对AI来说等于没给范围。它不知道该看哪个文件、以什么标准判断、最后要交什么结果。第三缺少验证信号。它改完代码之后没有人告诉它“测试挂了”或者“风格不对”它自然会在错误方向上继续走直到你把代码拿回来自己跑一遍才发现问题。想明白这三点之后我心态好了很多因为这些问题全是可解的而且解法都在流程里不在模型参数量里。模型能力固然有上限但在大多数日常开发场景里我们根本还没到碰模型上限的程度问题几乎都出在输入太草率、边界不清晰、反馈缺位这三个环节上。1.3 把Claude Code当成新来的实习生我一直觉得理解“人工智障”最好的类比是实习生。一个很聪明的实习生第一天进公司你不给他技术文档不告诉他代码规范不让他跑测试就丢一句“把这个模块优化一下”他大概率也会干出让你血压升高的事。反过来如果你给他一份项目手册、一张评审清单、一套自动验证命令他的表现会迅速变得靠谱。Claude Code和这个实习生的唯一区别是它的学习速度极快只要你把知识沉淀成文件它就能稳定复用。所以接下来的三招本质上就是给这个“实习生”补资料、划边界、建反馈。把功夫下在流程上比期待模型某天突然变聪明可靠得多。接下来我按“知识→约定→反馈”的顺序一条条展开每一条都有可以直接复用的模板和经验。2. 第一招给Claude Code植入项目知识库2.1 为什么Claude Code总是“记不住事”先明确一个概念Claude Code的记忆是会话级的不是持久级的。简单说每次你在终端里启动一次新会话它面对的就是一个全新项目、没有任何历史包袱。它唯一能“翻阅”的长期记忆是你项目里真实存在的那些文件。也就是说你想让它记住项目约定不能靠“多聊几句”只能靠“把约定写进文件里”。这就像开会讨论出来的结论如果不落到文档里下周一所有人都会忘。项目的知识库就是那个文档系统。Claude Code每次开工前都会先读项目里的关键文件相当于给新来的实习生发了一本“员工手册”。问题是大多数项目并没有这样一本手册至少没有为AI专门整理过所以AI的表现就只能靠碰运气。2.2 写一份能落地的CLAUDE.md项目记忆的骨架Claude Code在启动时会自动读取项目根目录下的CLAUDE.md文件这基本上是它最基础、也最有效的长期记忆载体。我强烈建议每一个用Claude Code的项目都把CLAUDE.md当成一等公民来维护而不是随便写两行就完事。CLAUDE.md应该写什么我的经验是覆盖五类信息项目一句话说明让AI知道自己在做什么业务是后台管理、电商小程序还是数据处理工具。技术栈清单框架、语言、包管理器、数据库、ORM、关键库的版本。目录结构和职责哪些目录放UI、哪些放请求、哪些放工具函数边界要写明白。常用命令install、lint、test、build、dev以及每个命令的预期结果。编码约定和禁止事项命名风格、错误处理模式、时间/时区处理、禁止修改的文件、禁止引入的依赖。下面是我某次给一个内部数据项目写的CLAUDE.md简化版可以直接参考这个结构# 项目某数据报表后台内部工具 ## 技术栈 - 前端Vue 3 TypeScript Vite - 图表ECharts - 后端Node.js Express PostgreSQL - 包管理pnpm ## 目录约定 - src/views页面组件只负责渲染 - src/api所有HTTP请求统一封装 - src/utils纯工具函数禁止引入业务依赖 - src/hooks组合式逻辑禁止放组件 ## 常用命令 - pnpm install安装依赖 - pnpm dev本地开发 - pnpm lint代码检查提交前必须通过 - pnpm test单元测试改动后必须通过 ## 核心约定 - 时间统一UTC存储展示层再转本地时间 - 接口请求必须走 src/api禁止在组件里直接fetch - 图表配置统一从 src/config/chart.ts 读取禁止散写 - 前端错误统一用 Result 结构接收禁止裸throw ## 禁止事项 - 禁止修改 src/vendor 目录下任何文件 - 禁止新增未在 package.json 中登记的依赖 - 禁止把ECharts的option直接写在组件里注意几个细节。第一规则要具体到“机器可判断”比如“时间用UTC存储”比“处理好时间问题”有用得多。第二禁止事项比正向约定更容易挡住越界行为因为模型在生成时拼命往“合理”方向靠明确的负向清单能直接拦住它。第三全文一定要短核心内容控制在几十行以内超过一屏模型就会开始选择性忽略。如果你的规则很多建议拆分出多个主题文件而不是全塞进一个文件里。2.3 用决策记录和踩坑日志让知识库持续生长CLAUDE.md是骨架但项目的知识远不止这些。很多“隐性知识”藏在历史决策和踩坑记录里Claude Code根本不知道。所以我建议再搭两个配套文件。第一个是docs/decisions/目录放决策记录。每个重要技术决策写一页背景、可选方案、为什么选A不选B、影响范围、涉及的模块。当Claude Code需要理解一个旧模块的设计意图时先让它读对应决策记录它的改动会明显更贴合项目原本的思路。举个例子如果项目早期决定“所有导出功能统一走异步任务队列”后来的人看代码可能觉得绕但读了决策记录就能明白这是为了不阻塞主线程。第二个是docs/pitfalls.md放踩坑日志。这个文件按“问题-原因-解法”的格式记条目每次因为某个细节返工就追加一行。比如## 列表白屏 - 问题订单列表切换分页偶发白屏 - 原因pagination组件在当前页超出总页数时未重置current导致渲染异常 - 解法在数据返回后校验current超过totalPage时重置为1 - 关联src/views/order/List.vue这个文件最有价值的地方在于当Claude Code处理相关功能时你只需要在任务描述里带一句“先读docs/pitfalls.md”它就能避开你曾经踩过的坑。等于你过去的所有经验都在持续给它供血。我自己的维护节奏是每次会话结束前花两分钟把这次对话里新发现的约定或者错误追加到对应文件然后告诉Claude Code“请把这条规则追加到CLAUDE.md”。两周后你会明显感觉到同一个项目的Claude Code行为规范程度完全不一样了。这一步不需要任何额外的工具只需要养成习惯但回报非常稳定。3. 第二招把编码约定变成AI的“自动驾驶边界”3.1 代码评审清单把人的标准前置给AI知识库解决了“知不知道”的问题但接下来的问题是“按什么标准做”。我发现CLAUDE.md能管住大的方向却管不住生成习惯。有时候Claude Code生成的代码完全符合项目约定但一眼看上去就不是这个项目该有的样子组件里塞了逻辑、函数写得过长、能复用的地方非要重写。这些不是规则能枚举的更像是一种“品位”。你要么接受要么想办法约束它。我用的办法是把平时人肉review时候会问自己的问题整理成一份代码评审清单放在docs/review-checklist.md。内容类似这样# 代码评审清单Claude Code 自查用 - 是否只修改了任务指定的文件有没有顺手改动其他模块 - 是否保持了现有抽象层次有没有突然做不必要的重构 - 是否新增了重复代码能否复用已有工具函数 - 错误处理是否符合项目标准数据结构是否保持一致性 - 是否补充了必要的测试测试是否覆盖了关键路径 - 代码风格是否符合现有文件命名是否与项目习惯一致 - 是否运行了 lint 和 test结果是否全部通过然后在每次任务prompt的最后加一句“完成后请按照docs/review-checklist.md逐项自查并说明每项结论。”这一句话成本极低但效果非常明显。它等于把评审标准提到生成之前让Claude Code在输出之前先过一遍自己的“品控”。如果它自查说“没有运行lint”你就能立刻要求它补上而不是等人肉review发现。3.2 任务验收三件套目标、约束、检查项除了全局评审清单每个具体任务本身也需要一个清晰的结构。我现在的任务描述几乎固定用三件套目标、约束、检查项。任务修复订单列表切换分页偶发白屏 目标定位并修复 src/views/order/List.vue 中分页切换触发的渲染异常不做其他改动 约束 - 只允许修改 src/views/order/List.vue - 禁止改动 src/api 和 src/store 模块 - 禁止新增依赖 检查项 - 先阅读 docs/pitfalls.md 中“列表白屏”条目 - 完成后运行 pnpm test全部通过 - 运行 pnpm dev手动验证进入订单列表连续切换5次分页无白屏、无控制台报错 - 输出改动文件清单及diff说明这套结构把“模糊意图”变成了“可执行工单”。尤其约束那一栏很关键它直接拦截了大部分越界行为。很多人觉得写这么多prompt很麻烦但实际算下来写三行约束比回头收拾一个乱改的文件要省时间得多。特别是一些涉及多模块联动的任务如果没有显式的约束Claude Code经常会把“顺手”当成“改进”改完你还得自己扫一遍diff才能发现。3.3 一次纠正一次沉淀让规范和项目磨合最后我想强调这套约定不是写在纸上就完了它是一个需要迭代的活物。我见过太多人写完CLAUDE.md就再也不管结果规则和项目实际脱节后来Claude Code的表现照样拉胯。真正让规范发挥作用的是持续迭代。我的建议有三条。第一当场沉淀。每次发现Claude Code生成越界、风格不对、或者违反约定在回复里直接指出来并且补一句“把这条规则追加到CLAUDE.md/评审清单”。当场不改过后基本就忘了。第二定期轻量复盘。每周花十分钟翻一遍最近几天的对话记录把重复出现的错误提炼成一条规则。不用把每句话都记录只沉淀那些“值得再来一次也能避坑”的内容。第三规则宁缺毋滥。规则加到某个量级之后模型会开始选择性忽略。我自己的体感是核心规则控制在30条以内最合适多了不如少要把位置留给真正高价值的边界约束。这套磨合过程本质上就是在把项目里的人肉review经验翻译成AI能理解的约束。翻译得越精细Claude Code的表现就越接近一个老手。4. 第三招搭建让Claude Code自我进化的反馈闭环4.1 先让它跑起来用命令执行代替肉眼Review前两招都是在输入侧下功夫第三招要讲的是输出侧的进化。我最大的一个转变是让Claude Code自己跑测试和lint。Claude Code本身能执行终端命令也就意味着验证环节完全可以交给它自己完成而不是等它把代码交给你之后再由你手动去跑。我现在每次任务的prompt里都会带上类似这句“任务完成后运行 pnpm lint pnpm test如果失败就继续修复直到全部通过再汇报最终结果。”这一个习惯直接把返工率降了一个层级。背后的原理很简单模型在生成代码时天然缺少执行反馈它只能靠“想象”来判断代码能不能跑。一旦允许它运行命令、读取报错信息、再修正“想象”就变成了“实证”整个流程从“一次生成”变成了“生成-反馈-修正”的多轮闭环。这个差距基本就是“看起来能用”和“真的能用”之间的差距。如果你一直把它输出的代码拿回来自己跑、自己看报错那就等于把最有价值的反馈信号截断了。4.2 小步快跑把大任务拆成多轮短链路另一个让Claude Code进化的重要实践是改变任务粒度。它处理“大而全”任务时特别容易翻车因为任务链越长每一步的偏差累积就越严重。我现在把所有任务都改成小步快跑的模式。举例来说修一个bug我不会直接说“把它修好”而是拆成三步。第一步只分析。让Claude Code读相关文件输出对问题原因的理解此时禁止改任何代码。这一步能确认它有没有找对方向。第二步给方案。让它列出要改哪些文件、具体改动点、可能影响什么等确认后再动手。第三步执行验证。确认方案之后才让它改改完立刻跑测试和lint。这套流程看起来比原来多了几个来回但实际上总时长反而更短。原因很简单方向错了多轮重来的成本远高于中途确认的成本。对Claude Code来说每一步都有明确的人类确认关口它就不会在错误方向上越走越远。也可以把反馈信号做得更细比如让Claude Code在方案阶段输出“如果采用另一个方案风险点在哪”这会逼着它在动手之前想清楚取舍。4.3 每次翻车都值钱反馈沉淀的复盘机制第三招的终极目标是让Claude Code在你的项目里真正实现“持续进化”。而这需要一台引擎把每次协作中产生的反馈沉淀成下一次协作的输入。我自己维护一份REVISION.md内容很简单就是一个表格记录每个阶段AI协作的表现和改进点。大致是这样的结构日期任务类型表现改进动作3月第1周修bug稳定一次通过无3月第1周新增列表页越界改了store返工在任务模板中强化约束栏3月第2周重构工具函数方向偏了重来一次先分析后动工的流程收益明显每周花十分钟更新一次这个表你就能清楚地看到Claude Code在哪个环节进步了、在哪个环节还需要补。这个机制最大的作用是让“和AI合作”本身变成一个可以持续优化的项目而不是每天碰运气。说直白点前两招解决的是“让它懂你”第三招解决的是“让它越来越懂你”。三招叠加之后Claude Code的表现会从“可用的工具”慢慢变成“懂项目规矩的老员工”。它不再是一段无状态的会话而是被你的知识库、约定和反馈持续塑造出来的项目专属助手。5. 常见问题与避坑速查表5.1 四个高频问题的定位与解法问题一Claude Code乱改无关文件。这不是它调皮而是指令范围太松。对策是任务描述里写死“只允许修改哪些文件、禁止碰哪些文件”并且在动手前让它先输出改动清单。只要范围收紧越界行为会立刻减少。问题二越跑越偏、方向完全不对。这通常是因为任务太大、链路太长缺少中间检查点。对策是拆成小步先分析、再方案、后动手每一步都确认。别心疼那几次额外的交互比返工划算得多。问题三代码看起来对一运行就报错。这是模型缺乏执行反馈的典型表现。对策是把“跑通测试”交给它自己让它反复看报错、反复改直到通过。不要替它当测试员。问题四同一个错误反复犯。这不是它蠢而是知识没有沉淀。对策是每次纠正后补一句“把这条规则追加到CLAUDE.md”把“记住”的责任从对话转移到文件。文件在知识就在。5.2 快速速查表现象可能原因快速对策乱改无关文件指令范围模糊在prompt中写死允许/禁止文件代码没问题但方式怪异缺少项目背景让它先读CLAUDE.md和对应决策记录大任务容易翻车链路太长、偏差累积拆成分析-方案-执行三步改了不验证缺少执行反馈要求它自己跑lint/test并修复到通过同类错误反复出现知识未沉淀把规则追加到CLAUDE.md/pitfalls.md回答模棱两可指令不够具体要求输出diff、文件清单、验证结果这张表我贴在很多项目的工作文档里每次和Claude Code配合出问题先对照一下再决定怎么调指令。大部分问题根本不需要苦想就是上面这几个原因。5.3 三条压箱底的独家经验最后分享三个我在实战里觉得最值钱的技巧。第一少用模糊词。像“优化一下”“看一下”“整理一下”这类表述对Claude Code来说等于什么都没说。每一次请求都要有明确的输入提示和输出格式比如“读X文件分析Y函数的问题输出三行结论先不要改代码”。指令越具体产出越稳定。第二永远要求“先给方案再给代码”。尤其是涉及多个文件改动的时候这一个小改变能挡住至少一半的翻车。你可以先让它列一个改动计划你花三十秒扫一眼再放行。这个确认成本极低但收益极高相当于给它的思路装了道闸门。第三把验证命令当作任务结尾的固定格式。每次任务结束都写明“完成后运行xxx结果如何如果失败继续修”。这样Claude Code的输出就不只是一个代码文件而是一个已经被执行环境验证过的结果。长期坚持下来它的产出质量会稳定很多你也不用再拿着代码自己跑一遍才敢放心。最后说一点我自己的体会。把Claude Code从“人工智障”调教成“持续进化的代码搭档”核心心态就一句话把它当成一个需要培训的菜鸟同事而不是全知全能的神器。前两招把功夫下在“输入侧”让它每次开工都带着项目知识上路第三招把功夫下在“反馈侧”让每一次翻车都变成下一轮进化的养料。两边的投资看起来不直接写业务但回报非常稳。如果你现在正被Claude Code气到血压升高我的建议是从一件最小的事开始把你最近一次纠正它的话原样追加到项目的CLAUDE.md里。然后让它在下次任务前读一遍。坚持两周你会回来告诉我这个变化比你想象的大得多。