企业官网建设流程全解析

用 Claude Code 写代码，上手门槛很低，真正用好的人却不多。多数人打开终端敲下claude，丢一句“帮我优化一下登录接口”，然后盯着屏幕看它忙活半天，拉出git diff才发现它把不该碰的模块也改了，或者改出来的代码跟项目现有风格完全不是一回事。这不是模型不行，是你还没掌握使用它的正确方式。

Claude Code 本质上是一个跑在终端里的 AI 编程代理，能读项目结构、定位文件、批量修改代码、执行命令、看测试结果，能力上限非常高。但它的输出质量高度依赖三样东西：你给它的信息、你给它的边界、你建立的验证节奏。我在不同规模的项目里持续用了相当长时间，从最开始被它带偏、反复回滚，到后来形成一套稳定可复制的工作流，最后沉淀下来的就是 8 条黄金法则。这篇文章不整虚的，每条法则都会讲清楚解决什么问题、背后是什么逻辑、具体怎么落地。

1. 规则一：把需求嚼碎了再交给它

1.1 一句话需求是翻车的根源

大型语言模型本质上是概率预测器，不是读心术师。“优化登录模块”这句话在不同项目里可以有十几种理解：是改性能？改用户体验？修 Bug？换算法？还是统一代码风格？信息越模糊，模型的猜测空间越大，最终产出就越不可控。

我刚开始用的时候特别喜欢偷懒，一句话甩过去，结果它给我改了一堆文件：把接口响应结构变了，连带改了前端调用，还顺手重构了一个根本不用动的工具函数。单看每一处改动都说得通，合在一起就是一场灾难。从那以后我给自己定了一条死规矩：凡是超过 5 分钟的任务，必须把需求写清楚再交给它。

1.2 一条好提示词必须包含的四个要素

我把完整的任务描述拆成四块，缺一不可：

• 目标：要产出什么结果。不是“优化”，而是“将登录接口的超时时间从 30 秒调整为 60 秒，并记录超时日志”。
• 范围：明确允许修改哪些路径，明令禁止触碰哪些路径。比如“只改动src/auth/login.ts，不要动前端页面和数据库表结构”。
• 约束：沿用什么风格、能不能引入新依赖、是否需要兼容旧接口。比如“保持现有函数签名不变，继续使用项目已有的日志工具，不要新增 npm 包”。
• 验收标准：任务怎么算完成。比如“执行npm run test:unit全部通过，Diff 文件数不超过 3 个”。

这四个要素写进提示词，模型的自由度被收窄到一个可控范围，产出的质量稳定性会立刻提升一个档次。

1.3 一个可以直接抄的任务模板

如果你懒得每次重新组织语言，直接套这个结构：

任务：修复 [具体文件] 中 [具体问题] 背景：目前的现象是 [现状]，期望行为是 [目标效果] 约束：只修改 [路径]，不调整 [无关模块]，保持 [既有约定] 完成标准：执行 [具体命令] 通过，并输出所有修改文件的清单和摘要

举个例子，“修复src/utils/formatDate.ts中月份从 0 开始导致显示错误的问题。目前getMonth()返回值比实际月份小 1，期望格式化后月份显示为 1-12。只修改该文件内部逻辑，不改函数签名。完成后运行npm test，并列出改动摘要。” 这样的提示词，Claude Code 基本不会跑偏。

2. 规则二：管好上下文窗口，别让它读太多没用的东西

2.1 上下文窗口是有限资源

Claude Code 的每一次对话，都会把历史消息、读取过的文件内容、工具返回结果累计进上下文。上下文窗口再大也有上限，而且不是越大越好——关键信息会被无关内容稀释，模型反而容易“忘了”你最开始强调的约束。

最典型的反面操作是，上来一句“先读一下整个项目，了解一下结构”，然后放任它在项目里疯狂搜索。小项目还好，中大型项目动辄几千个文件，它可能把无关模块的源码全塞进上下文，之后你让它改某个函数时，它记得的可能是被无关代码淹没之后的“混合印象”。

2.2 CLAUDE.md 是项目记忆的最好载体

Claude Code 有个机制：会自动读取项目根目录下的CLAUDE.md文件，把它当作全局指令。这个文件就是给 AI 看的项目记忆，也是最值得养成的习惯。

我通常在CLAUDE.md里放这些内容：

• 项目简介与技术栈（框架、语言版本、包管理器）
• 构建、测试、Lint 的完整命令
• 目录结构的关键职责（比如src/api是接口层，src/shared是公共组件）
• 代码风格约定（缩进、单引号还是双引号、命名规范）
• 已知禁区（比如“不要修改db/migrations下已提交的迁移脚本”“不要用any类型”）

只要把这份文件维护好，每次开启新会话时，Claude Code 就等于自带项目记忆，不需要你在提示词里反复重复基础背景。

2.3 一个会话只干一件大事

别在一轮对话里连续塞好几个不相关任务：“帮我改完登录接口，顺便把首页样式调一下，再写个 README。”每切换一次任务，模型都要重新理解目标，且前面的任务上下文会持续占用窗口，后面任务的质量往往明显下降。

我的做法是：一个会话只围绕一个任务。任务做完了就/clear清空上下文，重新开一个干净会话做下一件事。如果中途发现方向错了，别将就着继续聊，直接clear换思路重来，代价远小于在错误上下文里硬掰。

提示：/clear清空的是对话历史，不会删除已修改的文件。清空之前只要确认代码已落盘，就没什么好担心的。

3. 规则三：大改动先走 Plan 模式，再进 Build 模式

3.1 两种模式的分工

Claude Code 有 Plan 和 Build 两种核心模式。Plan 模式只做分析和规划：读代码、梳理依赖、给你输出一套详细的实施方案，但不会修改任何文件。Build 模式才是真正动手写代码、执行命令的模式。

很多人不知道这个区别，上来就 Build，等于蒙着眼睛让 AI 开车。尤其是跨文件的重构、新功能开发这类复杂度高的任务，AI 很可能在第一步就选错了架构方向，然后一路错到底，等你发现时已经改了十几个文件。

3.2 评审 AI 方案时的检查清单

Plan 模式输出方案后，你要像评审同事的设计文档一样去审它：

• 它列出的影响文件清单是否符合预期？
• 有没有漏掉你在提示词里强调的约束？
• 实施步骤的先后顺序是否合理？
• 方案里有没有包含验证步骤，还是只写了“改代码”？
• 有没有试图引入不必要的依赖或重写不该动的模块？

如果方案里有任何一点让你觉得不对劲，直接指出来让它修正，不要带着隐患进入 Build。

3.3 从计划到落地的衔接方法

我现在的大任务标准流程是：

1. 在 Plan 模式下让它输出编号步骤。
2. 我自己逐条确认，必要时让它修改方案。
3. 确认无误后切到 Build 模式，让它“严格按上述方案的第 1 步执行，完成后停下等待确认”。
4. 每完成一步就检查、测试、确认，再让它执行下一步。

每一步都卡着节奏走，AI 就没有机会一口气跑偏太远。哪怕真出了问题，回滚范围也被限制在单步以内，排查成本极低。

4. 规则四：权限别全开，让关键命令留在自己手里

4.1 不要迷信“跳过所有权限”

Claude Code 在执行 shell 命令前会请求用户授权，这是它最重要的安全护栏。我知道很多人嫌弹确认烦，直接用--dangerously-skip-permissions跳过所有权限门槛，图省事。这个做法我极度不建议。

跳过权限意味着 AI 可以自由执行删除、覆盖、安装依赖、git 提交推送等操作。模型猜错指令、执行错命令的概率客观存在，一旦犯错就是实打实的破坏。我见过有人让 AI 清理“临时文件”，结果它把构建产物和本地数据库备份一起删了的真实案例。

4.2 我推荐的权限策略

git push、git reset、rm -rf这类操作，我甚至在提示词里直接写明“禁止执行”。给 AI 加写操作权限，事后追责远不如事前限制来得省心。

4.3 一个被坑过的真实场景

有一次我让 Claude Code 修完一个 Bug 后顺手提交代码，它确实执行了git commit，但把我在调试时加的一堆console.log和临时代码一起提交了进去。更麻烦的是它紧接着执行了git push，等我发现问题时错误代码已经推到远端分支。那次之后我立了规矩：模型可以写代码、跑测试，但所有 git 的提交和推送动作都由我在终端手动执行，AI 永远不许碰 git 写命令。这个规矩一直沿用到现在。

5. 规则五：一次只改一件事，每一步都可回滚

5.1 大锅烩式改动为什么可怕

如果你的任务描述里出现“顺便”“以及”“顺便优化一下”，就要警惕了。让 AI 一次改 40 个文件，看似效率高，实际上是把风险集中引爆。一旦测试挂了，你根本不知道是哪一处改动引入的问题，排查的时间往往比重新写一遍还长。

5.2 推荐的小步工作节奏

我的标准节奏是：

1. 确认当前git status干净。
2. 只交给 Claude Code 一个能独立验证的小任务。
3. 让它执行对应的测试或 Lint。
4. git diff逐文件审阅。
5. 手动 commit。
6. 再进入下一个任务。

每轮改动的粒度和影响面都控制在一个可解释、可回溯的范围内。哪怕中途方向错了，回滚成本也只是一个小 commit。

5.3 中间检查点技巧

在每个任务收尾时，我都会加一句：“把你修改过的文件清单列出来，并为每个文件写一行改动摘要。”这一步有两个作用：一是强迫模型回顾自己的操作，减少“改完忘了自己动了哪里”的情况；二是让我拿到一份天然 review 清单，不用自己去git diff猜它到底干了什么。

6. 规则六：强制测试闭环，让 AI 自己证明没改坏

6.1 在 AI 编程里，测试是第一安全网

模型写代码的 Bug 率客观存在，你不能指望它每次输出都是对的。在传统开发里，代码审查和经验判断还能兜底，但 AI 生成的代码量大且快，靠肉眼审查根本看不过来。这时候唯一可靠的验证手段就是自动化测试：能跑通就是没改坏，跑不通就是有问题，不需要争论。

我见过很多开发者让 Claude Code 改完代码后不跑测试直接交付，结果上线才暴露问题。用 AI 编程的最大前提，就是项目里必须有一层测试保护网。如果项目目前没有测试，第一件事不是开发新功能，而是让 AI 先把核心模块的测试补上。

6.2 明确要求 AI 写测试

在任务提示词里加上一段话，效果立竿见影：

请为 [函数/模块] 添加单元测试，覆盖正常流程、边界值、异常输入这三类场景。 完成后运行 [项目测试命令]，确保所有用例通过。如果有用例失败，修复代码直到全绿为止。

关键是要把“运行测试”也囊括进来，而不仅仅是“写测试”。写出来但没跑，等于默认它写的就是对的，这恰恰是问题所在。

6.3 重构前的基线测试技巧

做重构或大改动前，先让 Claude Code 把现有测试完整跑一遍，记录结果作为基线。之后每次它改完代码，再重跑测试，和基线对比。这个方法非常朴素，但能有效防止 AI 在“优化”过程中悄悄改变接口行为或者弄坏原有功能。

7. 规则七：让 AI 做完活先自检，再交给你审

7.1 追问变更影响面

Claude Code 完成一个任务后，不要急着让它收尾走人。我通常会追加几个问题：

• “这次改动会影响哪些现有调用方？”
• “有没有破坏性变更？旧代码还能不能兼容？”
• “如果想回滚这次改动，最小操作是什么？”

这几个问题会强制模型进入一种“自我 review”的状态。它往往会重新检查一遍自己的代码，然后发现之前忽略的问题。这个技巧带来的正确率提升非常明显，甚至比单独提示“请检查你的代码”更有效。

7.2 先自查 Lint 和类型再交差

写完代码先别急着给我看，我会要求它：“先跑一遍类型检查和 Lint，有问题先修完，再汇报最终结果。”这样一来，很多低级错误在它内部就已经被消化掉了，交到我手上的代码干净程度明显提高。

7.3 最终的代码审查应该由人来做

模型自检再认真也有盲区，尤其涉及业务语义、数据安全、用户体验这类需要领域判断的地方。我习惯把 Claude Code 当成一个执行力很强的初级工程师，而我是那个负责把关的资深开发者。AI 负责快速产出和自验，我负责方向判断和最终审查。两者角色一旦混淆，风险就会失控。

8. 规则八：把经验沉淀进 CLAUDE.md，让工具越用越顺手

8.1 每次踩坑都是可沉淀的资产

如果你发现 Claude Code 对同一个问题犯了第二次错，这就是写入CLAUDE.md的信号。比如它连续两次用了一个项目里已经废弃的 API，那就把“本项目禁止使用 XXX 库/API，改用 YYY”写进项目记忆。写进去之后，后续所有新会话都会自动遵循这条规则，你不需要反复在提示词里强调。

我现在的CLAUDE.md已经积累了几十条这类约束，每一条都对应一次真实翻车。这些约束让 Claude Code 在项目里的表现越来越像一个“熟悉团队规矩”的老人，而不是一个每次都从零开始猜的陌生开发。

8.2 让规范随仓库共享给整个团队

CLAUDE.md是跟着仓库走的文件，提交到 git 之后，团队里所有人用 Claude Code 时都会自动加载同一套项目规范。这点非常关键。市面上那些靠个人习惯形成的提示词技巧，很难在团队里复制；但把规范写进仓库文件，就等于把个人经验变成了团队基础设施。

我在团队里推了一段时间后，新加入的同学用 Claude Code 的首次产出质量明显高于没有这套文件时的表现。这就是沉淀的价值。

8.3 把常用任务流程模板化

如果你发现某些任务反复出现在工作中，比如“修复接口超时问题”“给新模块补测试”“重构某类样式代码”，可以把对应的提示词模板存成文档，或者用 Claude Code 的自定义斜杠指令来固化。这样就不需要每次重新组织语言，直接调用模板，再根据具体情况微调即可。

8 条法则全部讲完了，但如果只让我选一条最想强调的建议，我会说：从一开始就把 Claude Code 当成一个需要“项目背景 + 明确边界 + 验证闭环”的协作对象，而不是一个会读心术的许愿池。你越舍得花时间把任务描述清楚、把项目记忆沉淀下来、把测试和审阅环节卡住，它回报给你的效率提升就越可观。这套方法我也是踩了无数坑才换来的，希望你不用再踩一遍。