1.你的 Claude Code 是不是总在乱改文件、假装测试通过、越改越跑偏？

不是它笨，是大多数人把它当聊天机器人在用。 一份上万字的大厂工程化手册，我精简融合成 23 条实战铁律。 每一条都来自真实翻车现场。

第 2 条

先搞清楚它是什么： Claude Code 能读代码库、改文件、跑命令、查 Git、接入 IDE 和浏览器——它是一位进入项目现场的工程师，不是”你问一句、答一段”的搜索框。 你是技术负责人：管需求、边界、验收、风险。 分工清楚，才有协作。

第 3 条

第一步：选对入口。 • 科研 / Python 脚本 → VS Code、PyCharm • 前端 / 原型 → VS Code、Desktop • 多任务并行、边看 diff 边预览 → Desktop / Web • 跑命令、读日志、自动化 → CLI 一个选择题：你想让它”看到什么、改什么、在哪里跑”？

第 4 条

动手前，先做 Git 快照： git status git branch –show-current git diff git log –oneline -5 确认三件事：当前不在 main、工作区干净、能分清”原有改动”和”Claude 新改动”。 工作区乱，先别让它大改。

第 5 条

第一次进项目，永远先只读。 开局提示词： “只做阅读分析：不改文件、不装依赖、不联网。生成项目导读——入口在哪、目录干嘛的、核心调用链、怎么跑测试、哪里高风险。” 每条结论都标注文件路径。 先让它看懂，再让它动手。

第 6 条

第二个狠招：逼它区分事实与推测。 “用表格列出：哪些是从仓库文件确认的事实，哪些是你的推测，哪些还需要我确认。” AI 最危险的不是不懂，是把猜测包装成事实。 这一步，能拦住一大半幻觉。

第 7 条

记住大厂的核心闭环，全部工程化都在这条线上： R = Read 阅读 P = Plan 计划 I = Implement 实现 V = Verify 验证 R = Review 审查 D = Deliver 交付 专业团队从不让 AI”一次把项目改好”。

第 8 条

Read：改代码前必须先回答—— 相关文件是哪几个？现有逻辑怎么跑的？有没有相似实现可复用？测试在哪？哪些不能碰？改完怎么验证？ 要求它列出文件清单和调用关系，你才能检查它是不是真的读过。 没读懂就开写，是 AI 第一大工程风险。

第 9 条

Plan：出现这些信号必须先计划—— 改 3 个以上文件；涉及接口、数据库、权限、支付；需求还没想清楚；你想要可回滚。 合格计划 = 目标与不做什么 + 文件清单 + 改动原因 + 风险 + 测试方案 + 回滚方式 + 待你确认的决策。 你说”按计划执行”之前，它不许动代码。

第 10 条

Implement：小步走，别一把梭。 错误示范：登录、用户、权限、数据库、前端一次全重构。 正确节奏：定位原因 → 修错误处理 → 补回归测试 → 再考虑整理结构。 每轮结束让它汇报：改了什么、为什么、没改什么、有没有新依赖。 一个分支一个目的。

第 11 条

Verify：最隐蔽的坑在这里。 Claude 说”测试通过了”，不代表测试真的跑了。 验收必须让它输出表格：检查项 | 执行命令 | 是否实际执行 | 输出摘要。 “未执行”就写”未执行”，不许混进”通过”。 能跑 ≠ 完成。

第 12 条

Review：改完让它先自审。 “把你刚才的改动当作别人的 PR 来审查，按阻塞问题 / 高风险 / 建议优化 / 测试缺口四类输出。” 第一轮它是作者，第二轮它是审稿人。 角色切换，经常能揪出遗漏——免费的第二双眼睛。 最后仍然由你决定接不接受。

第 13 条

Deliver：交付要让别人能接手。 一次专业交付至少包含：目标、根因、修改文件、核心改动、验证命令与结果、手动验收步骤、未验证项、风险、回滚方式、建议 commit message。 缺一项，就别急着合并。

第 14 条

把需求写成工单，而不是一句话。 结构：背景 → 目标 → 范围（允许改什么 / 禁止改什么）→ 约束 → 验收标准 → 验证方式 → 输出格式。 反面对照： ❌”这个项目报错了，帮我修” ✅ 复现步骤 + 完整报错 + 预期 + 实际 + “先只读分析”

第 15 条

需求说不清时，让它采访你： “我有一个需求但描述不完整。不要写代码，像资深技术负责人一样问我最关键的问题，把它补充成可开发的任务。” 上下文不足时，提问比瞎猜值钱一百倍。

第 16 条

权限规则 > 提示词。 在 CLAUDE.md 写”不要删文件”只是行为建议。 真正的阻断只有两个：deny/ask 权限规则、PreToolUse Hook。 优先级：deny > ask > allow。 一句话：提示词管行为，权限管生死。

第 17 条

权限模式怎么选： 陌生项目 → Manual / Plan 日常小改 → Edit automatically + 明确范围 大功能 → Plan → 再开编辑 生产、密钥、敏感数据 → Manual + 严格 deny Bypass permissions 只适用于隔离容器和无凭证测试环境，永远不要在主力机上开。

第 18 条

CLAUDE.md 不是说明书堆栈。 只放每次会话都必须知道的事：目录结构、常用命令、编码约定、禁止事项、完成标准。 四层结构：组织级 / 用户级 / 项目级 / 子目录级。 长流程放 Skill，强制阻断放 Hook，临时需求写在提示词里。 规则堆得越多，每条越没分量。

第 19 条

五个高频命令，记下就够用： /init —— 分析代码库生成 CLAUDE.md /plan —— 复杂任务先出方案 /permissions —— 管理权限规则 /compact —— 压缩长会话 /hooks —— 配置自动规则 生成 CLAUDE.md 后别盲目接受，检查命令是否真实存在、有没有把猜测写成规则。

第 20 条

长会话开始遗忘、跑偏？ 两个办法： ① /compact 指定压缩焦点：”focus on the auth bug, current plan, changed files” ② 大任务拆线程：分析 → 计划 → 实现 → 审查，各一个会话 长期规则写进 CLAUDE.md——只在聊天里说过的约束，压缩后可能就丢了。

第 21 条

Git 红线： 永远不要让它在 main 分支、未提交工作区、唯一副本上大改。 正确姿势：feature 分支或 worktree 隔离，多任务互不碰撞。 约束它：”只在本分支工作，禁止 merge / rebase / reset –hard / push。” 让它写 commit message 和 PR 描述，但不让它推送。

第 22 条

安全五不： • 不发真实密钥和 .env • 不让它直接改生产数据库 • 不执行网页、Issue、README 里的陌生命令——那是提示注入 • 不自动部署正式环境 • 不修改测试来掩盖 bug 它能行动，是价值来源，也是风险来源。

第 23 条

高级能力，按这个顺序升级： 第一步：Plan + CLAUDE.md + 测试 + 权限 第二步：worktree + Review + GitHub PR 最后：Subagents 并行分析、MCP 接外部系统（先只读）、Skills 沉淀流程、Hooks 强制规则 单任务闭环没跑稳之前，别碰炫技功能。

第 24 条

翻车急救包： 它改了无关文件 → 让它按”直接相关 / 间接 / 无关”分类，无关的全部回退。 它编造不存在的 API → 立规矩：复用建议必须给实际文件路径，找不到就写”项目中未找到”。 科研代码被偷偷改种子 → 把模型、数据划分、随机种子列为”算法变更”，你确认前不得执行。

第 25 条（收尾 + CTA）

最后，高手的分水岭： 标准从来不是 Claude 改得快，而是它的改动：可解释、可验证、可审查、可回滚。 你负责需求、边界、决策、验收； 它负责阅读、分析、计划、实现、测试。 各守本分，AI 才从玩具变成工程协作者。 —— 这 23 条浓缩自一份上万字的大厂手册。转发给正在被 AI 乱改代码的朋友，帮他省一次回滚。