企业官网建设流程全解析

1. 从“写代码”到“指挥智能体写代码”的范式转移

这两年我参与过不少团队的研发流程改造，最直观的感受是：AI 在软件开发生命周期（SDLC）里的角色，已经从“补全一行的助手”变成了“能独立跑完一个任务闭环的智能体”。这个变化听起来只是程度上的差异，实际却是范式上的断裂。以前我们讨论的是“Copilot 能不能帮我写个正则”，现在讨论的是“我能不能把整个需求拆解、编码、测试、提交这一串动作交给一个智能体去执行，我只做审查和决策”。

这就是AI-Native SDLC要解决的核心问题。它不是简单地在现有流程里塞几个 AI 工具，而是把“智能体”当作研发流程中的一等公民来重新设计协作方式。而Claude Code这类终端智能体的出现，让这个设想第一次有了比较落地的抓手——它不只是聊天窗口里给你一段代码，而是能直接读写文件、执行命令、跑测试、看报错、再改代码，形成一个自主的闭环。

我写这份实践手册，是想把过去一段时间在真实项目里踩过的坑、验证过的流程、以及那些“文档里不会写但实际很关键”的细节整理出来。它适合已经在用或准备用智能体参与研发的工程师、技术负责人，也适合想搞清楚“AI-Native 到底怎么落地”的产品和项目管理者。你不需要是 AI 专家，但需要对软件研发的基本流程有概念，因为这份手册的重点不是模型原理，而是怎么把智能体编排进你的日常研发动作里。

2. AI-Native SDLC 的整体设计与思路拆解

2.1 为什么是“智能体”而不是“更强的代码补全”

很多人对 AI 编程的理解还停留在“补全更快了”。但补全本质上是一个无状态、单轮、局部的动作：你写一半，它猜后半句。而 SDLC 里的真实任务是有状态、多轮、全局的：一个需求进来，要理解上下文、定位相关文件、改代码、跑测试、处理失败、再迭代，最后产出可提交的变更。

这两者的差距，用生活类比就是：补全像“你打字时旁边有人帮你猜下一个词”，而智能体像“你交代一件事，它自己去找资料、动手做、遇到问题自己想办法，做完给你验收”。前者提升的是打字速度，后者改变的是任务分配方式。

所以 AI-Native SDLC 的设计核心，不是“用哪个模型”，而是把哪些环节交给智能体、哪些环节必须留给人、以及人和智能体之间怎么交接。我见过不少团队一上来就想“全自动”，结果智能体改了一堆文件、跑挂了测试、还提交了错误的代码，最后人花更多时间去收拾。这就是没有设计好边界。

2.2 三层结构：上下文层、执行层、审查层

我实践下来比较稳的结构是三层：

• 上下文层：解决“智能体怎么知道这个项目的规矩”。这层的关键是CLAUDE.md这类项目级说明文件，把技术栈、目录约定、代码风格、测试命令、禁止事项写清楚。智能体每次启动都会读它，相当于给新入职的同事发了一份“项目须知”。
• 执行层：解决“智能体怎么动手”。这层是 Claude Code 这类工具的主场，它能读文件、写文件、执行终端命令、跑测试。执行层的关键是权限边界和可回滚，不能让智能体在没有任何约束的情况下乱改。
• 审查层：解决“人怎么验收”。这层是 AI-Native SDLC 里最容易被忽视但最重要的部分。智能体产出的是“候选变更”，人要做的是审查 diff、跑关键测试、决定是否合并。审查层的效率，直接决定了整个流程是提速还是添乱。

这三层缺一不可。只有执行层没有上下文层，智能体会写出“能跑但不符合项目规范”的代码；只有执行层没有审查层，就是前面说的“全自动翻车”。而上下文层和审查层，恰恰是很多团队在引入智能体时最容易跳过的地方。

2.3 为什么选 Claude Code 作为切入点

市面上智能体工具不少，我选 Claude Code 作为主要实践对象，有几个现实原因。第一，它是终端原生的，能直接在当前项目目录里操作，不需要把代码复制到某个网页里，这对真实项目很重要。第二，它支持CLAUDE.md这种项目级上下文文件，让“项目规矩”可以沉淀下来，而不是每次对话都重新解释。第三，它能执行终端命令，这意味着它可以跑测试、跑构建、看报错，形成闭环。

当然它也有局限，比如在某些环境下安装和登录会遇到问题，这个后面会专门讲。但整体上，它是我目前用下来最接近“能干活”的终端智能体。需要说明的是，工具会迭代，今天的最佳实践明天可能就变了，所以这份手册更侧重“思路和边界设计”，工具细节只作为参考。

3. 核心细节解析与实操要点

3.1 CLAUDE.md：给智能体的“项目须知”怎么写才有效

CLAUDE.md是整个 AI-Native SDLC 里性价比最高的一个文件。它不复杂，就是放在项目根目录的一个 Markdown 文件，智能体启动时会自动读取。但写得好和写得差，效果差很多。

我见过有人把它写成“项目介绍”，洋洋洒洒几千字讲业务背景，结果智能体该犯的错还是犯。问题在于，智能体需要的不是业务故事，而是可执行的约束。一份有效的CLAUDE.md应该包含这几类信息：

• 技术栈和版本：用什么语言、什么框架、什么包管理器，版本号尽量写清楚。比如“Node 20 + pnpm，不要用 npm”。
• 目录约定：哪个目录放什么，新文件应该放哪里。比如“组件放src/components，工具函数放src/utils，不要新建顶层目录”。
• 代码风格：缩进、命名、导入顺序。如果项目有 lint 配置，直接写“提交前必须跑pnpm lint”。
• 测试命令：怎么跑单测、怎么跑集成测试。这是执行层闭环的关键，智能体改完代码要能自己验证。
• 禁止事项：哪些文件不要动、哪些命令不要跑。比如“不要修改package.json里的依赖版本”“不要执行任何数据库迁移命令”。

我自己的习惯是把CLAUDE.md控制在一屏以内，用短句和列表，不写废话。因为智能体的上下文窗口是有限的，写太多反而稀释了关键约束。如果项目复杂，可以拆成多个文件，在CLAUDE.md里引用。

注意：CLAUDE.md不是写完就一劳永逸的。每次智能体犯了“本可以避免的错”，就应该回头补一条约束进去。它应该是一个活的文件，随着项目演进不断更新。

3.2 权限边界：哪些命令可以让智能体自己跑

这是实操里最需要谨慎的地方。Claude Code 能执行终端命令，这既是它的威力所在，也是风险所在。我的原则是：读操作放开，写操作收紧，破坏性操作禁止。

具体来说，像ls、cat、grep、git status、git diff这类只读命令，可以让智能体自由执行，它需要这些来理解项目状态。像跑测试、跑 lint、跑构建这类命令，也可以放开，因为它们是验证性的，不会破坏东西。但像git push、git reset --hard、rm -rf、数据库写操作、部署命令，这些必须禁止或要求人工确认。

实际操作中，我建议在项目里配一个命令白名单的思路：把允许智能体自动执行的命令列出来，其他一律需要确认。Claude Code 本身有权限确认机制，但不同版本行为可能不同，所以更稳妥的做法是在CLAUDE.md里明确写“以下命令不要执行”，同时在流程上要求人在合并前审查所有变更。

还有一个容易被忽视的点：智能体跑测试时可能会产生副作用。比如测试里如果连了真实数据库、发了真实请求，那智能体反复跑测试就可能污染数据。所以测试环境要隔离，或者用 mock。这个坑我踩过，智能体为了修一个测试，反复跑了十几次，结果在测试库里造了一堆脏数据。

3.3 任务拆解：给智能体的指令要“小到能验证”

智能体不是万能的，给它一个“帮我实现用户登录功能”这种大任务，它大概率会给你一个能跑但漏洞百出的实现。问题不在模型能力，而在任务粒度。

我的经验是，给智能体的任务应该满足两个条件：边界清晰和可验证。边界清晰是指它知道要改哪些文件、不动哪些文件；可验证是指改完之后有一个明确的命令能判断对错，比如“跑pnpm test auth应该全绿”。

所以我会把大需求拆成小任务，每个任务对应一次智能体会话。比如“实现登录功能”拆成：

1. 在src/api/auth.ts里加一个login函数，调用已有的post工具函数，先写单测。
2. 在src/components/LoginForm.tsx里实现表单，调用上面的login，先写组件测试。
3. 把登录状态接入全局 store，更新相关测试。

每个任务都小到智能体能在一次会话里完成，而且有明确的验证命令。这样即使某一步出错，影响范围也有限，回滚成本低。

实操心得：给智能体的指令里，验证命令要写进去。比如“改完后跑pnpm test auth，确保全绿再结束”。这样它会自己迭代，而不是改完就交差。

4. 实操过程与核心环节实现

4.1 环境准备：安装与配置的常见路径

Claude Code 的安装在不同系统上路径不太一样。我分别在 macOS、Ubuntu 和 Windows 上试过，整体思路是：先装 Node 环境，再通过包管理器装 Claude Code，最后配置项目。

macOS 和 Ubuntu 上相对顺，用 npm 全局安装即可：

npm install -g @anthropic-ai/claude-code

装完之后在项目目录里跑claude就能启动。Windows 上我遇到过一些路径和权限问题，建议用 WSL 或者确保 Node 版本较新。如果遇到“无法下载”或“不支持当前地区”的提示，通常是网络环境问题，这个需要自行解决，不在本文讨论范围。

VS Code 里也有对应的扩展，装完之后可以在编辑器里直接调用。我个人的习惯是终端和编辑器结合用：终端里跑智能体做批量修改，编辑器里做人工审查。这样分工比较清晰。

配置方面，除了CLAUDE.md，还要注意模型选择。Claude Code 默认用 Anthropic 的模型，但也支持接入其他模型。如果项目对成本敏感，可以考虑用更便宜的模型做简单任务，复杂任务再用强模型。这个切换在配置里可以调，具体看官方文档。

4.2 一个完整任务的执行记录

我拿一个真实的小任务来演示：给一个已有的 React 项目加一个“复制到剪贴板”的按钮。

第一步，写清楚任务。我在终端里启动 Claude Code，输入：

在src/components/ShareButton.tsx里实现一个复制按钮，点击后把当前页面的 URL 复制到剪贴板。用项目已有的Button组件和useToasthook。改完后跑pnpm test ShareButton，确保测试通过。

第二步，观察它的动作。它会先读CLAUDE.md，然后读ShareButton.tsx、Button组件、useToasthook，理解现有模式。接着它写代码，写测试，跑测试。如果测试挂了，它会看报错、改代码、再跑，直到通过。

第三步，人工审查。它跑完测试后，我用git diff看它改了什么。重点看：有没有引入不必要的依赖、有没有改到不该改的文件、测试是不是真的在测行为而不是测实现。确认没问题后，我再决定是否提交。

这个流程里，智能体承担了“写代码 + 跑测试 + 迭代”的循环，我承担了“定义任务 + 审查结果”的决策。实测下来，这种小任务它通常一两轮就能跑通，比我手写快不少，而且测试覆盖往往比我手写还全，因为它不会偷懒。

4.3 参数与配置的取舍逻辑

在配置智能体时，有几个参数需要权衡。上下文窗口决定了它能“记住”多少项目信息，窗口越大越贵，但太小又容易丢上下文。我的做法是：CLAUDE.md精简，具体文件按需读取，不一次性塞太多。

温度参数影响输出的随机性。写代码任务我倾向低温度，让输出更确定；但做方案探索时可以适当调高，让它给更多可能性。这个没有绝对标准，看任务性质。

超时和重试也要设。智能体跑测试可能卡住，或者网络请求超时。设置合理的超时，避免它无限等待。重试次数也不宜太多，否则可能反复跑同一个失败命令，浪费资源。

注意：不要盲目追求“全自动”。我试过让智能体连续跑多个任务不中断，结果它在某个任务上理解偏了，后面几个任务全跟着错。每个任务之间留一个人工检查点，是更稳的做法。

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

5.1 智能体“改错文件”或“改多了”怎么办

这是最常见的问题。智能体有时候会“顺手”改一些你没让它改的文件，比如格式化整个目录、更新依赖版本。原因通常是CLAUDE.md里的约束不够明确，或者任务描述里没写清楚边界。

排查思路：先看git diff，确认它改了哪些文件。如果改了不该改的，用git checkout回滚那些文件，保留正确的部分。然后回头在CLAUDE.md里补一条约束，比如“只修改任务指定的文件，不要格式化其他文件”。

预防措施：任务描述里明确写“只改 X 文件”，并且在CLAUDE.md里写“不要执行全项目格式化”。另外，每次任务前确保工作区是干净的，这样出问题容易回滚。

5.2 测试跑不过，智能体反复改还是不过

这种情况通常是任务本身有问题，而不是智能体能力问题。可能的原因：测试环境没配好、依赖没装、测试本身写错了。

排查思路：先自己手动跑一遍测试命令，确认环境是好的。如果手动能过、智能体过不了，可能是它跑命令的方式不对，比如工作目录不对。如果手动也过不了，那就是环境问题，先修环境。

还有一种情况是智能体“为了过测试而改测试”，把断言改松了。这个要特别警惕。审查时重点看测试文件的 diff，确认它没有削弱测试强度。

5.3 常见问题速查表

5.4 几个我踩过的坑

第一个坑是让智能体跑数据库迁移。有次我图省事，让它跑了一个迁移命令，结果它在测试库上跑了，把测试数据清了。从那以后，所有写操作命令我都要求人工确认。

第二个坑是没写验证命令。早期我给任务不写“跑什么测试”，智能体改完就交差，我以为它验证过了，结果一跑就挂。后来我强制自己在每个任务里写清楚验证命令。

第三个坑是一次给太多任务。我试过把五个小任务一次性丢给它，结果它做着做着就乱了，上下文里混了多个任务的信息。现在我坚持一次一个任务，做完审查再下一个。

6. 把智能体编排进团队流程的几点经验

6.1 从个人试点到团队推广的节奏

我建议不要一上来就在团队里全面推。先在一两个愿意尝试的工程师身上试点，跑一两个月，积累出适合自己项目的CLAUDE.md模板和任务拆解规范。等流程稳定了，再逐步推广。

推广时，重点不是“教大家怎么用工具”，而是“教大家怎么定义任务和审查结果”。工具操作半小时就能学会，但任务拆解和审查判断需要练习。可以组织小范围的案例分享，把好的任务描述和翻车案例都拿出来讲。

6.2 审查环节不能省，但可以优化

审查是 AI-Native SDLC 里最耗人的环节。如果每个变更都要人逐行看，那智能体省下的时间又被审查吃回去了。优化思路有几个：一是让智能体自己写变更说明，把改了什么、为什么改、验证结果列出来，人看说明再抽查 diff；二是把审查分层，小改动快速过，大改动重点看；三是用自动化检查兜底，lint、类型检查、测试这些能自动跑的就自动跑，人只看自动化过不了的部分。

6.3 关于“智能体会不会取代工程师”的看法

我自己的判断是：短期内不会，但会改变工程师的工作内容。写代码这件事本身会变少，定义问题、拆解任务、审查结果、做技术决策这些会变多。这其实对工程师的要求更高了，因为你需要有足够的判断力，才能看出智能体哪里做错了。

所以我的建议是，与其焦虑，不如把智能体当成一个“执行力很强但需要明确指令的初级同事”。你带过新人就知道，给新人派活，最重要的是把任务说清楚、把验收标准定明白。这个能力，在 AI-Native 时代会越来越值钱。

最后分享一个我自己的小习惯：每次智能体完成一个任务，我会花一分钟想一下“这次它的表现哪里好、哪里不好、下次怎么改进指令”。这个复盘动作看起来小，但积累下来，你对智能体的“脾气”会越来越了解，用起来也越来越顺。工具会变，但“把问题定义清楚、把结果验证到位”这个底层能力，是不会过时的。