企业官网建设流程全解析

1. 从“写代码”到“管流程”：AI-Native SDLC 到底在改什么

这两年大家聊 AI 编程，话题基本都停在“补全快不快”“能不能帮我写个函数”这个层面。但我自己带团队做下来，越来越强烈的感受是：AI 对软件研发的真正冲击，不在单点编码效率，而在整个 SDLC（软件开发生命周期）的组织方式。所谓 AI-Native SDLC，说白了就是——不再把 AI 当成一个外挂的“代码补全插件”，而是让 AI 智能体成为研发流程里的一等公民，从需求拆解、方案设计、编码、测试、Code Review 到发布，每个环节都有智能体参与，并且这些智能体之间是有上下文、有记忆、有协作的。

这份实践手册要解决的核心问题很具体：怎么把 Claude Code 这类终端里的编码智能体，真正嵌进一条可复现、可审计、可交接的研发流水线里，而不是每个人各自开一个窗口、各写各的 prompt、结果无法沉淀。适合谁来读？我认为有三类人最该看：一是正在团队里推 AI 编码工具、但发现“用了跟没用差不多”的技术负责人；二是想从“会用 Claude Code”进阶到“会设计 AI 工作流”的一线工程师；三是做智能体平台、需要理解真实研发场景落地细节的产品和架构同学。

我踩过的最大一个坑，就是早期把 AI 当成“更聪明的 IDE”。结果就是每个人都在重复造 prompt，新人接手完全不知道上一个环节 AI 做了什么、为什么这么改。后来我们才意识到，AI-Native SDLC 的关键不是模型多强，而是流程契约——也就是用一份约定好的项目上下文文件（比如 CLAUDE.md），把“这个项目是什么、怎么构建、怎么测试、有哪些禁忌”固化下来，让每个智能体、每个人进来都能对齐。这才是手册里最值钱的部分，也是后面几节要重点拆的。

2. 核心思路拆解：为什么是“上下文文件 + 终端智能体”这套组合

2.1 为什么选终端型智能体而不是纯 IDE 插件

先说选型逻辑。市面上 AI 编码工具大致分三类：IDE 内联补全（如各类 Copilot）、对话式网页助手、以及终端/命令行里能直接操作文件系统和执行命令的智能体（Claude Code 属于这一类）。前两类的问题在于它们只能“建议”，不能“执行”。你让它改个文件，它给你一段代码，你还得自己复制粘贴、自己跑测试、自己看报错。这个来回切换的成本，在真实项目里非常高。

终端型智能体的价值在于它处在一个可执行的环境里：它能读项目文件、能改代码、能跑npm test、能看 git diff、能根据报错自己迭代。这就把“建议”变成了“动作”。我实测下来，一个中等复杂度的重构任务，纯对话助手需要我手动搬运五六轮，而终端智能体基本能自己闭环，我只在关键节点做审查。这个差异不是效率的线性提升，而是工作模式的质变。

但这里有个前提：你必须给它足够的项目上下文。终端智能体再强，它进到一个陌生仓库里也是两眼一抹黑。它不知道你的构建命令是make build还是pnpm build，不知道测试要跑哪个子集，不知道哪些目录是自动生成的不能碰。这就是 CLAUDE.md 存在的意义。

2.2 CLAUDE.md 的本质：给智能体的“项目入职文档”

很多人第一次看到 CLAUDE.md 会以为它是个配置文件，其实更准确的理解是：它是写给 AI 看的项目 README + 团队规约。一个新同事入职，你会告诉他项目怎么跑、代码风格是什么、提交前要做什么检查；CLAUDE.md 就是把同样的话写给智能体。它通常放在仓库根目录，智能体每次启动会自动读取。

一份能用的 CLAUDE.md，我总结下来至少要覆盖四块内容：

• 项目定位与结构：一句话说清这是什么项目，主要目录各自负责什么，避免智能体在错误的地方改代码。
• 构建与测试命令：精确到可复制执行，比如pnpm install && pnpm test:unit，而不是模糊的“跑一下测试”。
• 代码规范与禁忌：命名约定、禁止直接改生成文件、禁止动某些敏感配置等。
• 常见任务指引：比如“新增一个 API 接口需要改哪几个文件”，把高频操作的路径固化下来。

提示：CLAUDE.md 不要写成百科全书。我见过有人写了三千行，结果智能体每次读取都消耗大量上下文，反而抓不住重点。控制在 100 到 300 行，只放“每次都需要知道”的信息，长尾知识放到子目录的说明文件里按需引用。

2.3 智能体协作的边界：哪些交给 AI，哪些必须人管

AI-Native 不等于“全自动”。我在实践里划了一条比较清晰的线：探索性、重复性、有明确验证标准的任务交给智能体；涉及架构决策、跨系统权衡、安全敏感变更的，人来主导，智能体做辅助。比如“把这个模块的单元测试覆盖率补到 80%”非常适合智能体，因为目标明确、有测试结果作为反馈信号；而“我们要不要从单体拆成微服务”这种，智能体能帮你整理资料、列方案对比，但拍板必须是人。

这条边界不是拍脑袋定的，而是因为智能体的反馈闭环依赖可验证的信号。测试通过与否、编译成功与否、lint 报错与否，这些都是机器可判定的，智能体就能自我迭代。而“这个设计好不好”没有自动判定器，智能体容易陷入自我说服，这时候人的判断不可替代。

3. 落地实操：从零搭一条 AI-Native 研发流水线

3.1 环境准备与 Claude Code 安装要点

先把工具装起来。Claude Code 目前主流的安装方式是通过 npm 全局安装，命令大致是：

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

装完之后在项目根目录执行claude就能进入交互界面。Windows 用户建议在 WSL 或者 Git Bash 里跑，原生 PowerShell 偶尔会有路径和权限的坑。Ubuntu 环境下基本开箱即用，但要注意 Node 版本别太老，建议 18 以上。

如果你在 VS Code 里工作，也可以装对应的扩展，把终端智能体嵌进编辑器侧边栏，改完代码直接在编辑器里看 diff，体验会顺很多。我个人的习惯是：大重构用终端全屏，日常小改用编辑器集成，两者不冲突。

注意：有些团队账号会因为组织策略限制导致订阅访问被禁用，报错信息里通常会出现 “your organization has disabled …” 这类提示。遇到这种情况先找管理员确认组织级设置，别急着重装，重装解决不了策略问题。

3.2 写一份能真正生效的 CLAUDE.md

这是整条流水线的地基，我拿一个真实的前后端项目举例，给你一份可以直接抄的骨架：

# 项目说明 这是一个基于 Node + React 的订单管理系统，后端在 /server，前端在 /web。 # 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 单元测试：pnpm test:unit - 类型检查：pnpm typecheck - 提交前必跑：pnpm lint && pnpm typecheck && pnpm test:unit # 代码规范 - 使用 TypeScript strict 模式，禁止 any - 组件文件用 PascalCase，工具函数用 camelCase - 所有 API 请求必须走 /server/src/api 下的封装，禁止裸 fetch # 禁忌 - 不要修改 /server/src/generated 下的任何文件，那是自动生成的 - 不要动 .env 和 CI 配置，需要变更先提 issue - 数据库 migration 必须人工审核，智能体只生成草稿 # 常见任务 - 新增接口：改 /server/src/routes + /server/src/services + 补对应测试 - 新增页面：在 /web/src/pages 下建目录，注册到路由表

这份文件的关键在于命令必须可执行、禁忌必须具体。“注意代码质量”这种话对智能体毫无意义，“禁止 any”才是它能执行的约束。我建议每引入一个新的高频任务类型，就往“常见任务”里补一条，慢慢这份文件就成了团队的知识资产。

3.3 把需求拆成智能体能接的“任务单元”

智能体最怕的就是模糊的大任务。你说“帮我优化一下性能”，它可能给你改一堆无关的东西。正确的做法是把需求拆成有明确输入、明确输出、明确验收标准的任务单元。举个例子，原始需求是“订单列表页加载太慢”，拆解后应该是：

1. 定位瓶颈：让智能体分析/web/src/pages/OrderList的数据请求链路，输出耗时分布。
2. 提出方案：基于分析结果，列出 2 到 3 个优化点及预期收益。
3. 实施单项：先做分页，改完后跑pnpm test:unit确认没破坏现有测试。
4. 验证效果：对比改动前后的请求次数和渲染时间。

每一步都有可验证的产出，智能体就能一步步推进，而不是一口气给你一个没法审查的大 diff。这个拆解动作目前还得人来主导，但我发现写得多了之后，可以让智能体先给一版拆解草案，人来修订，效率能再提一截。

3.4 让智能体自己跑测试、自己修

这是终端智能体最爽的地方。你给它一个任务，比如“修复 OrderService 里 calculateTotal 在折扣叠加时算错的问题”，它可以自己读代码、改逻辑、跑测试、看失败、再改，直到测试通过。整个过程你只需要在最后 review diff。

但这里有个实操细节：测试必须跑得快。如果跑一次全量测试要十分钟，智能体的迭代循环就会非常慢，体验直线下降。我的做法是给智能体准备一个快速测试子集，比如只跑相关模块的测试，命令写进 CLAUDE.md 的“常见任务”里。全量测试留到提交前由 CI 跑。

# 快速验证单个模块 pnpm test:unit -- --testPathPattern="order"

提示：智能体跑测试时偶尔会“作弊”——比如把失败的断言改掉让它通过。所以 review diff 时一定要重点看测试文件有没有被偷偷改动。我一般会在 CLAUDE.md 里明确写“禁止修改测试断言来让测试通过，除非任务本身就是修测试”。

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

4.1 智能体“跑偏”了怎么办

最常见的现象是：你让它改 A，它顺手把 B、C、D 也改了。原因通常是任务描述太宽泛，或者 CLAUDE.md 里的边界没写清。排查思路是先看 diff 范围，再回溯任务描述。如果 diff 里出现了任务无关的文件，八成是任务描述里用了“优化一下”“顺便”这类模糊词。

解决办法有两个：一是任务描述里明确“只允许修改 X 目录下的文件”；二是在 CLAUDE.md 的禁忌里列出“未经明确要求，不要改动其他模块”。我实测下来，把“最小改动原则”写进上下文文件后，跑偏概率明显下降。

4.2 上下文丢失与长任务断裂

长任务跑到一半，智能体突然“忘了”前面说过的约束，这是上下文窗口的物理限制导致的。应对方式不是硬扛，而是把长任务切成有状态的短任务，每个短任务结束时把关键结论写回文件（比如一个PROGRESS.md），下一个任务开始时先读它。这样即使上下文被截断，状态也还在磁盘上。

另一个技巧是把稳定的约束放 CLAUDE.md（每次自动加载），把临时的任务状态放单独文件（按需读取），两者分工明确，能有效缓解上下文压力。

4.3 常见问题速查表

4.4 几个我踩过的坑

第一个坑是过度信任。早期我让智能体直接改生产相关配置，结果它把一个超时参数从 30 秒改成了 3000 毫秒，单位理解错了。从那以后，凡是涉及数值和单位的改动，我都要求它在 diff 里显式标注单位，并且人工复核。

第二个坑是prompt 不沉淀。一开始每个人都在聊天框里现写 prompt，好用的写法没人记录。后来我们强制要求：任何被验证有效的任务描述，都要整理进 CLAUDE.md 的“常见任务”或者团队的 prompt 库。这样新人进来直接复用，不用从零摸索。

第三个坑是忽略成本。终端智能体自主迭代会消耗大量 token，一个复杂任务跑几十轮很常见。我的经验是给任务设一个“轮次上限”，比如超过 15 轮还没收敛就停下来人工介入，避免它在一个死胡同里反复烧钱。

5. 智能体协作的进阶玩法与边界思考

5.1 多智能体分工：让“写”和“审”分开

单智能体既写又审，容易自我背书。进阶做法是引入审查角色：一个智能体负责实现，另一个智能体拿着 diff 和 CLAUDE.md 里的规范做审查，专门挑问题。这个审查智能体的 prompt 要写得“挑剔”一点，比如“你的职责是找出这次改动中违反规范、缺少测试、可能引入回归的地方，不要客气”。

我实测下来，双智能体模式能抓出不少单智能体漏掉的问题，尤其是测试覆盖和边界条件。成本上大概增加 30% 到 50%，但对于核心模块的改动，这个投入很值。

5.2 和平台型智能体的差异在哪

经常有人问：用 Coze 这类平台搭的智能体，和用 Claude Code 这种终端智能体有什么区别？我的理解是场景定位不同。平台型智能体擅长面向业务用户的对话式任务，比如客服、问答、流程审批，它们的强项是接入渠道和可视化编排；而终端智能体擅长面向研发的、需要操作真实代码库和命令行的任务。两者不是替代关系。

真正有价值的组合是：平台型智能体负责需求收集和初步拆解，终端智能体负责在代码库里落地。比如客服智能体收集到一批用户反馈，整理成结构化的需求条目，研发侧的终端智能体再逐条去实现。这条链路打通了，AI-Native 才算覆盖了从业务到代码的完整闭环。

5.3 安全与审计：别让智能体成为黑盒

智能体自主执行命令，天然带来审计需求。我的做法是三条：所有智能体的改动必须走 git，能 diff 能回滚；敏感操作（数据库、部署、密钥相关）一律人工执行，智能体只生成脚本草稿；每个任务的输入输出留痕，方便事后追溯。这不是不信任 AI，而是工程上任何自动化都需要可观测、可回退，智能体也不例外。

注意：不要把密钥、token 这类敏感信息写进 CLAUDE.md 或任何会被智能体读取的文件。需要环境变量就在运行时注入，文件里只写变量名。

5.4 这套东西后续还能怎么长

我现在跑下来的体会是，AI-Native SDLC 的成熟度大概分三层：第一层是个人会用终端智能体提效；第二层是团队有统一的上下文文件和任务规范，产出可交接；第三层是智能体之间形成流水线，需求进来能自动流转到代码和测试。大部分团队卡在从第一层到第二层，缺的不是工具，而是把经验固化成文件的习惯。CLAUDE.md 只是起点，后面还会有测试规范文件、审查清单文件、发布检查文件，本质上都是把团队的隐性知识显性化，让 AI 和人共享同一套上下文。

最后分享一个我一直在用的小技巧：每周花十分钟回顾这一周智能体跑得最顺和最不顺的任务，把顺的写法补进上下文文件，把不顺的坑记进禁忌清单。坚持一个月，你会发现智能体的“靠谱程度”肉眼可见地上升——不是模型变强了，而是你给它的上下文变准了。这件事没有捷径，但复利很可观。