企业官网建设流程全解析

1. 为什么“全程用 Claude 写代码”这件事值得认真聊

先把话说在前头：标题里问的是“现在用 Claude 编写所有代码的工程师们，你们是怎么做到的”，这个问题本身就带着一点挑衅意味。因为在外行看来，“用 AI 写代码”约等于“让 AI 帮我补全几行”，但在真正把 Claude 当成主力开发工具的工程师眼里，这完全是两码事。前者是玩具，后者是一套完整的、可复现的、有纪律的工作流。

我自己从 Claude 的对话式用法，一路迁移到 Claude Code 这种命令行/工程化形态，中间踩过的坑足够写一本小册子。最开始我也觉得“不就是把需求丢进去让它写吗”，结果第一次让它改一个跨五个文件的重构，它给我返回了一堆看起来对、跑起来全崩的代码。后来我才明白，问题不在模型，而在我——我把它当成了一个更聪明的自动补全，而不是一个需要被“管理”的协作者。

这篇文章想解决的核心问题是：一个工程师，如何把 Claude 从“偶尔问一下的助手”变成“日常写代码的主力”，并且保证产出质量可控、可回溯、可交付。关键词会自然散落在各个章节里：Claude、Claude Code、claude.md、LLM、PR 这些概念，我会结合真实工作流讲清楚它们各自扮演什么角色。

适合谁看？如果你已经会用 Claude 聊天、但还没把它接进真正的开发流程，这篇是给你的；如果你已经在用 Claude Code 但总觉得“差点意思”，这篇也能帮你补齐那几块缺失的拼图。我不打算讲什么“AI 将改变世界”的空话，只讲我实际怎么配、怎么写、怎么防坑。

2. 把 Claude 当主力开发工具，整体思路该怎么设计

2.1 先想清楚：你要的是“补全”还是“委托”

这是最根本的分水岭。补全思维是：我写主体，AI 帮我填几行。委托思维是：我定义任务边界和验收标准，AI 去实现，我来审查。全程用 Claude 写代码的工程师，几乎无一例外都是后者。

为什么委托思维更有效？因为 LLM 的强项是“在明确约束下生成大量结构化内容”，弱项是“猜测你没说出口的意图”。你越是把任务描述得像一张工单——输入是什么、输出是什么、边界在哪、不许动哪些文件——它的产出就越稳。我试过同一个重构任务，用“帮我优化一下这个模块”和用“把 user_service.py 里的三个数据库查询合并成一个批量查询，保持函数签名不变，不许改测试文件”，后者的可用率大概是前者的三倍以上。

所以整体设计的第一条原则：把每一次交互都当成一次小型的需求交付，而不是一次闲聊。

2.2 分层使用：对话、CLI、工程化三种形态各司其职

很多人把 Claude 的几种用法混在一起，导致效率很低。我的分层是这样的：

• 对话式（网页/桌面端）：用来做探索性工作。比如“这个报错可能是什么原因”“帮我对比这两种架构的取舍”。这时候不需要它写最终代码，需要的是思路碰撞。
• Claude Code（命令行/客户端）：用来做实际的代码修改。它能读你的项目文件、能执行命令、能跨文件改动，这是“委托”真正落地的地方。
• claude.md 这类项目级约定文件：用来固化规则。把项目的技术栈、代码风格、禁止事项写进去，让每次会话都自动带上这些上下文，省得你反复交代。

这三层不是替代关系，是流水线关系。探索阶段在对话里想清楚，执行阶段交给 Claude Code，规则沉淀到 claude.md。缺了任何一层，工作流都会漏风。

2.3 为什么必须引入 PR 这个环节

这是我最想强调的一点。全程用 Claude 写代码，最大的风险不是“它写不出来”，而是“它写出来了但你不敢合并”。如果没有 PR（Pull Request）这个审查关卡，AI 生成的代码会像洪水一样涌进主分支，等你发现某个隐蔽 bug 时，已经不知道是哪次改动引入的。

我的做法是：Claude 的每一次实质性改动，都必须走一次 PR。哪怕是我一个人开发的项目，我也会让 Claude 生成改动、我自己开一个分支、提交、然后走一遍 PR 流程再合并。这样做有三个好处：一是强制自己 review 一遍 AI 的产出，二是留下可回溯的记录，三是当改动出问题时能精准回滚。

提示：不要因为“反正是 AI 写的、我信得过”就跳过 PR。我踩过最惨的一次坑，就是让 Claude 直接改主分支的一个工具函数，结果它顺手“优化”了一个它认为冗余的判断，那个判断其实是处理边界情况的，线上直接炸了半小时。

3. 核心细节解析：Claude Code 与 claude.md 到底怎么用

3.1 Claude Code 的安装与基础配置

Claude Code 的安装方式在不同系统上略有差异，但核心逻辑一致：它是一个能访问你本地文件系统和终端命令行的客户端。Windows 上安装时，有朋友会遇到提示需要启用虚拟机平台相关组件的情况，这是因为它依赖某些底层运行环境，按提示开启对应系统功能、重启即可，属于正常步骤，不用慌。

安装完成后，第一件事不是急着写代码，而是配置工作目录和权限边界。我建议：

1. 先在一个独立的、非核心的项目目录里试跑，别一上来就对着生产代码库操作。
2. 明确告诉它哪些目录可以读写、哪些命令可以执行。默认情况下它对危险命令是有拦截的，但你自己心里也要有数。
3. 如果你用的是 VS Code，可以把它接进编辑器工作流，这样改动能直接在编辑器里看到 diff，审查效率高很多。

Ubuntu 等 Linux 环境下安装逻辑类似，主要是确保运行环境和依赖齐全。安装这一步本身不难，难的是装完之后建立正确的使用习惯，这才是拉开差距的地方。

3.2 claude.md：把项目规则写死，别靠记忆

claude.md 是我认为整个工作流里性价比最高的一个东西。它的作用很简单：在项目根目录放一个约定文件，Claude 每次在这个项目里工作时，会自动读取它作为上下文。你可以把它理解成“给 AI 看的 README + 编码规范 + 禁忌清单”。

我自己的 claude.md 通常包含这几块内容：

• 技术栈声明：用什么语言、什么框架、什么版本。比如“Python 3.11 + FastAPI + SQLAlchemy 2.0”，避免它用旧写法。
• 代码风格：命名习惯、注释语言、是否允许用某个库。我明确写过“禁止引入新的第三方依赖，除非我确认”。
• 目录结构说明：哪个目录放什么，让它知道该往哪写。
• 禁止事项：不许改测试文件、不许动配置文件、不许删除日志。这些是血泪教训换来的。
• 常用命令：怎么跑测试、怎么格式化、怎么启动本地服务。

为什么这个文件这么关键？因为 LLM 没有长期记忆，每次会话都是“失忆”状态。你不把规则写下来，它每次都会按自己的默认习惯来，而默认习惯往往和你的项目不匹配。写一次 claude.md，省下的是后面几十次“不对，我们不用这种写法”的重复沟通。

注意：claude.md 要写得具体、可执行，别写“代码要优雅”这种废话。写“函数不超过 50 行”“所有公开函数必须有类型注解”，它才能真正遵守。

3.3 任务拆解：把大需求切成 Claude 能吞下的小块

这是实操中最容易翻车的地方。你让 Claude 一次性实现一个完整功能模块，它大概率会给你一个“看起来完整、细节全是坑”的东西。正确做法是拆解。

我的拆解粒度标准是：一个任务，Claude 能在一次会话里完成，且你能在五分钟内 review 完。比如“实现用户注册接口”太大，拆成“定义注册请求的数据模型”“实现密码哈希工具函数”“实现注册的业务逻辑”“写注册接口的路由”“补测试”五个小任务，逐个击破。

每个小任务我都遵循一个模板来描述：

任务：实现密码哈希工具函数 输入：明文密码字符串 输出：哈希后的字符串 约束：使用项目已有的 bcrypt 依赖，不许新增依赖 位置：写到 utils/security.py 验收：能通过我提供的三个测试用例

这种描述方式的好处是，Claude 不需要猜，我也不需要反复解释。实测下来，这种“工单式”描述的首次可用率能到七八成，剩下的两三成靠 review 和微调补上。

4. 实操过程：一次完整的 Claude 驱动开发长什么样

4.1 从需求到任务清单

假设我要给一个已有的项目加一个“导出数据为 CSV”的功能。我不会直接让 Claude 写代码，而是先让它帮我拆任务。我会在对话里说：“我要加一个导出 CSV 的功能，涉及路由、业务逻辑、文件生成三部分，帮我拆成可独立实现的小任务，并说明每个任务的依赖顺序。”

它给出的清单通常是这样的：先定义导出请求的参数模型，再实现 CSV 生成工具，再实现业务逻辑组装数据，最后接路由。这个顺序很重要，因为后面的任务依赖前面的产出。我会把这个清单记下来，作为接下来的执行路线图。

这一步的价值在于：让 Claude 参与规划，但由我来拍板。它有时候会漏掉边界情况，比如“导出数据量很大时要不要分页”，这种就需要我补进去。

4.2 逐个任务执行与即时验证

接下来就是逐个任务委托。每完成一个，我立刻验证，绝不留到全部写完再测。验证方式根据任务类型不同：

• 工具函数类：直接跑单元测试。
• 业务逻辑类：写一个最小的调用脚本跑一遍。
• 路由类：本地起服务，用 curl 打一下。

为什么要即时验证？因为 LLM 的错误会累积。第一个任务的输出如果有隐蔽问题，第二个任务基于它继续写，错误就会被放大，到最后你根本不知道是哪一层出的问题。即时验证相当于每步都做一次“断点检查”。

我举个真实的例子。有一次让 Claude 写一个日期解析函数，它用了某个库的一个方法，那个方法在新版本里行为变了。如果我当时没测，直接拿去做业务逻辑，后面所有涉及日期的功能都会错，排查成本会高十倍。即时验证花的那两分钟，省下的是后面两小时。

4.3 提交、开 PR、审查、合并

所有任务完成后，我会让 Claude 帮我生成一个改动摘要，然后我自己开分支、提交、开 PR。PR 描述我会写清楚：这次改了什么、为什么这么改、测试覆盖了哪些场景、有没有已知的遗留问题。

审查环节我会重点看几类东西：

审查通过才合并。整个过程听起来繁琐，但熟练之后，一个中等功能的完整流程也就一两个小时，比我自己从头写快得多，而且质量更稳定，因为每一步都有验证。

4.4 参数与配置的选择逻辑

有人会问，Claude Code 里那些配置项怎么选？我的原则是：能用默认就用默认，只在明确遇到问题时才调。比如上下文长度、温度这类参数，默认值对代码任务通常是合适的。温度调高会让输出更“有创意”，但代码要的是稳定，不是创意，所以我一般不动它。

真正需要你花心思配置的，是权限和目录边界。哪些目录可写、哪些命令可执行，这个必须按项目实际情况收紧。我见过有人图省事全放开，结果 Claude 执行了一个清理命令，把临时文件连同一些没提交的改动一起删了。这种坑，配置阶段多花五分钟就能避免。

5. 常见问题与排查技巧实录

5.1 为什么 Claude 写的代码“看着对、跑起来崩”

这是最高频的问题。原因通常有三个：一是它对你的项目上下文理解不全，用了不存在的函数或字段；二是它假设了某些数据格式，而实际数据不是那样；三是它漏了边界情况。

排查思路：先看报错信息定位到具体行，然后问自己“这行代码依赖了什么假设”。如果假设来自 Claude 的臆测，就回到 claude.md 或任务描述里把这个假设明确写出来。我现在的习惯是，凡是涉及外部数据的地方，都在任务描述里附上真实的数据样例，这样它就不会瞎猜。

5.2 上下文丢失导致它“忘了”之前的约定

LLM 的上下文窗口是有限的，会话太长时，早期的约定会被挤出去。表现就是它突然开始用你不喜欢的写法，或者忘了某个约束。

解决办法有两个：一是把关键约定写进 claude.md，这样每轮都会重新加载；二是长任务拆成多个短会话，每个会话开始时用一句话重申核心约束。我个人的经验是，单个会话别超过它处理能力的七八成，留点余量，稳定性会好很多。

5.3 它总想“顺手优化”不该动的地方

这是 Claude 的“热心”带来的副作用。它看到一段它认为冗余的代码，会忍不住改掉，但那段代码可能是有意为之的边界处理。

对策很直接：在 claude.md 里明确写“只修改我指定的文件，其他文件一律不动”。如果它还是改了，PR 审查时一定要揪出来。我现在的做法是，每次提交前用 diff 工具过一遍所有改动，确认没有意外修改。

5.4 常见问题速查表

5.5 几个我踩过的坑，你可以直接避开

第一个坑：别在没版本控制的情况下让 Claude 改代码。我有一次在一个没初始化 git 的目录里操作，它改崩了之后我连回滚都做不到，只能手动重写。从那以后，任何让 Claude 动手的目录，第一件事就是 git init 并提交一次初始状态。

第二个坑：别把敏感信息放进上下文。配置文件里的密钥、令牌这类东西，不要让它读到，也不要在任务描述里贴出来。用环境变量或者占位符代替。这是安全底线，不是可选项。

第三个坑：别指望它一次写对复杂算法。涉及复杂逻辑时，先让它写伪代码或思路，你确认思路对了再让它落地成代码。直接要代码，它可能给你一个逻辑有微妙错误的实现，而这种错误最难查。

第四个坑：别忽略它的“我不知道”。有时候它会说“我不确定这个 API 的用法”，这时候千万别让它硬写。让它先查文档或者你直接给它文档片段，比它瞎编一个不存在的 API 强得多。

6. 把 Claude 接进团队协作时要注意什么

6.1 统一约定，别各写各的

如果团队里多个人都在用 Claude，claude.md 必须是共享的、统一的。否则每个人给 AI 的约束不一样，产出的代码风格就会分裂。我们的做法是把 claude.md 纳入版本控制，谁要改规则就提 PR 讨论，跟改代码一个流程。

6.2 PR 审查标准要针对 AI 产出做调整

传统的 code review 关注逻辑和风格，针对 AI 产出，我会额外加几条：有没有引入未声明的依赖、有没有改动任务范围外的文件、边界处理是否完整、注释是否准确（AI 有时会写和代码不符的注释）。这几条加进去之后，AI 代码的合并质量明显提升。

6.3 知识沉淀：把好用的提示词和任务模板存下来

我们团队维护了一个内部的小知识库，专门存那些“实测好用”的任务描述模板和提示词。比如“重构某个函数的模板”“写单元测试的模板”“排查报错的模板”。新人进来直接套用，上手速度快很多。这个东西的价值会随着时间累积，越用越值钱。

7. 我个人的一些真实体会

说到底，全程用 Claude 写代码这件事，核心不在于模型多强，而在于你有没有建立一套让模型稳定发挥的工程纪律。我见过太多人抱怨“AI 写的代码不能用”，但仔细一问，他们的用法就是丢一句话然后期待奇迹。这不是 AI 的问题，是用法的问题。

我自己最大的转变，是从“问它”变成“管它”。问它，得到的是随机的灵感；管它，得到的是可控的产出。claude.md 是管它的规则手册，任务拆解是管它的工单系统，PR 是管它的验收关卡。这三样东西搭起来，Claude 才真正从一个玩具变成了生产力工具。

最后分享一个我最近在用的习惯：每次让 Claude 完成一个稍微复杂的任务后，我会让它自己总结“这次改动里最容易被忽略的风险点是什么”。它给出的答案经常能提醒我一些 review 时没注意到的角落。这个自检动作花不了几秒钟，但帮我挡掉过好几次潜在的线上问题。你可以试试，挺好用的。