企业官网建设流程全解析

1. 从"写代码"到"编排智能体"：AI-Native SDLC到底在改什么

这两年大家嘴上都在说"AI 编程"，但真落到日常开发里，多数团队其实还停留在"把 AI 当个高级补全工具"的阶段——写个函数让它补全，遇到报错贴进去问一句，仅此而已。这套用法当然有用，但它离"AI-Native SDLC"还差着十万八千里。所谓 AI-Native SDLC，直译过来就是"AI 原生的软件开发生命周期"，关键词是原生两个字：不是给传统流程打补丁，而是从需求、设计、编码、测试、评审到部署，每一环都默认有智能体（Agent）参与，人从"执行者"变成"编排者"和"验收者"。

我自己的体感是，这个转变的分水岭出现在 Claude Code 这类终端智能体成熟之后。以前的 AI 编程是"你问它答"，现在的形态是"你给目标，它自己读代码库、自己改文件、自己跑测试、自己看报错再改"。这中间最大的差别不是模型变强了多少，而是智能体获得了对真实工程环境的操作权——它能执行终端命令、能读写文件、能调用工具链。一旦有了这个能力，"AI-Native SDLC"才真正有了落地的基础。

那这本"实践手册"要解决什么问题？说白了就是三件事：第一，怎么把 Claude Code 这类智能体正确地装进你的开发环境（VS Code、Ubuntu、Mac 各有各的坑）；第二，怎么用CLAUDE.md这类约定文件把项目上下文、编码规范、禁忌事项喂给智能体，让它别乱来；第三，怎么把单个智能体的能力组织成多智能体协作的流水线，覆盖从需求到部署的完整 SDLC。适合谁看？我觉得是三类人：想从"AI 补全"升级到"AI 编排"的一线开发者、正在搭内部智能体平台的团队负责人、以及准备智能体相关面试、需要把零散知识串成体系的人。

下面我不打算按"安装—配置—使用"这种说明书顺序讲，而是按我实际踩坑和落地的顺序来拆。因为真正卡住人的，往往不是命令敲不对，而是你没想清楚为什么要这么配。

2. 环境落地：Claude Code 在 VS Code、Ubuntu、Mac 上的真实差异

2.1 为什么终端智能体比 IDE 插件更值得先跑通

很多人第一反应是去装 VS Code 插件，觉得图形界面友好。但我建议你先把终端版本跑通，再考虑插件。原因很实在：Claude Code 的核心能力是执行终端命令、读写文件、跑构建和测试，这些操作在终端里是最原生的。插件本质上是给终端能力套了个壳，壳有时候会挡住你看清它到底干了什么。

举个我自己的例子。有次智能体改完代码后测试一直不过，我在插件里只看到"测试失败"四个字，完全不知道它执行了什么命令、在哪个目录跑的。切到终端一看，发现它在一个错误的子目录里执行了npm test，自然找不到测试文件。这种问题在终端里一眼就能定位，在插件里就得猜。所以我的建议是：先用终端把智能体的行为模式摸清楚，再上插件提效。

2.2 Ubuntu 和 Mac 安装时最容易忽略的两个细节

安装本身不复杂，但有两个坑我见过太多人踩。

第一个是Node 版本。Claude Code 依赖较新的 Node 运行时，如果你系统里是那种"祖传"的旧版本（比如某些 Ubuntu 镜像自带的），装完会出现各种莫名其妙的模块加载错误。我的做法是先确认版本：

node -v npm -v

如果 Node 低于 18，别犹豫，用 nvm 装一个干净的：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash source ~/.bashrc nvm install 20 nvm use 20

第二个是全局安装的权限问题。在 Ubuntu 上直接npm install -g经常报 EACCES 权限错误，很多人第一反应是加sudo，结果装出来的东西归属 root，后面升级、卸载全是麻烦。正确做法是配置 npm 的全局目录到用户空间：

mkdir -p ~/.npm-global npm config set prefix '~/.npm-global' echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.bashrc source ~/.bashrc

Mac 上相对省心，但如果你用 Homebrew 装的 Node，偶尔会遇到 PATH 顺序问题，导致系统自带的旧 node 抢先。用which node确认一下指向的是不是 Homebrew 或 nvm 的路径就行。

提示：安装完成后先别急着接项目，找个空目录跑一次最简单的任务（比如"创建一个 hello.txt 并写入当前时间"），确认智能体能正常读写文件和执行命令，再进真实项目。这一步能帮你排除掉 80% 的环境问题。

2.3 VS Code 接入的配置逻辑，别只抄配置不看含义

VS Code 接入 Claude Code，热词里问得最多的是"插件配置解释"。我见过不少人把别人的配置文件整段复制过来，结果跑不起来，因为里面有些字段是跟具体项目路径、模型供应商绑定的。

配置的核心逻辑其实就三层：第一层是告诉 VS Code 去哪里找智能体可执行文件（通常是 PATH 里的命令）；第二层是工作区范围，也就是智能体能操作哪些目录，这个一定要收紧，别让它默认拿到整个 home 目录的权限；第三层是模型接入，如果你用的是第三方 API 或者自建模型服务，需要在这里指定端点和密钥。

我个人的习惯是给每个项目单独配一个工作区，把智能体的可操作范围限制在项目根目录内。这样即使它"发疯"乱改，损失也可控。这一点在团队协作里尤其重要——你不想某天早上发现智能体把隔壁项目的配置也顺手改了。

3. CLAUDE.md：把项目规矩写进智能体的"入职手册"

3.1 为什么一个 Markdown 文件能决定智能体的靠谱程度

CLAUDE.md这个东西，第一次见的人会觉得"不就是个说明文档吗"。但用久了你会发现，它其实是智能体的项目级系统提示词。每次智能体进入这个项目，都会先读这个文件，把它当作行为准则。你在这里写什么，它就更可能按什么来。

我踩过的最典型的坑是：项目里有一套自己的目录约定，比如所有业务逻辑放src/domain，所有外部调用放src/infra。我没在CLAUDE.md里写清楚，结果智能体把新写的服务直接丢进了src/utils，理由是"看起来像工具类"。代码能跑，但破坏了架构分层，评审时被打回重写。从那以后我养成了习惯：凡是"新人来了要交代"的事，都写进CLAUDE.md。

3.2 一份能用的 CLAUDE.md 应该包含哪几块

我总结下来，有效的CLAUDE.md至少覆盖四块内容，缺一块都会出问题。

第一块是项目结构与技术栈。用几句话讲清楚这是什么项目、用什么语言和框架、核心目录各自负责什么。别写成长篇大论，智能体需要的是"地图"，不是"旅游攻略"。

第二块是编码规范与约定。比如命名风格、错误处理方式、日志规范、是否允许引入新依赖。这里有个经验：把"禁止事项"写明确。像"不要引入新的第三方库，除非我明确要求"这种话，能省掉很多事后清理的麻烦。

第三块是常用命令。构建、测试、lint、启动本地服务的命令都列出来。这样智能体改完代码会自己跑测试验证，而不是改完就交差。这一条对 AI-Native SDLC 特别关键——让智能体自己闭环验证，是它从"助手"变成"协作者"的标志。

第四块是当前任务上下文。这块可以动态更新，比如"当前正在重构支付模块，相关代码在src/payment，注意不要动src/legacy里的旧实现"。这相当于给智能体一个"当前焦点"，避免它到处乱翻。

下面是我常用的一个模板骨架：

# 项目说明 这是一个基于 X 框架的 Y 服务，核心职责是 Z。 # 目录结构 - src/domain: 业务逻辑，纯函数优先 - src/infra: 外部依赖封装（数据库、HTTP） - src/api: 接口层，只做参数校验和转发 # 编码规范 - 使用 TypeScript strict 模式 - 错误统一用 Result 类型，不抛异常 - 禁止引入新依赖，除非明确要求 # 常用命令 - 构建: npm run build - 测试: npm test - 单测某个文件: npm test -- <path> # 当前任务 正在重构支付模块，相关代码在 src/payment。

3.3 让智能体"自我约束"的几个写法技巧

光写规则还不够，得让规则"可执行"。我摸索出几个小技巧。

一是用祈使句，别用描述句。"代码应该保持整洁"这种话智能体基本无视，但"每个函数不超过 50 行，超过就拆分"它就会认真对待。规则越具体、越可判定，执行效果越好。

二是给反例。比如"不要用any类型，如果确实需要动态类型，用unknown加类型守卫"。带上反例和替代方案，智能体就不会在模糊地带自由发挥。

三是分层写规则。项目级通用规则放CLAUDE.md，模块级特殊规则可以放在子目录的说明文件里。这样智能体进入某个模块时能读到更细的约束，避免"一刀切"的规则在特殊场景下帮倒忙。

注意：CLAUDE.md不是写完就一劳永逸的。每次智能体犯了新错误，我都会问自己"是不是规则没写清楚"，然后把教训补进去。用久了这个文件会变成团队的"踩坑备忘录"，价值远超预期。

4. 多智能体协作：把 SDLC 拆成可编排的流水线

4.1 单智能体的能力边界在哪里

先说个反直觉的结论：单个智能体再强，也不适合包揽整个 SDLC。原因不是能力不够，而是上下文会爆炸。一个需求从分析到部署，涉及的信息量极大，全塞进一个会话里，智能体到后面就会"忘事"、抓不住重点，甚至自相矛盾。

我实测过一个中等复杂度的功能开发，让单个智能体从头做到尾。前期需求分析还行，到编码阶段它开始忘记前面定的接口约定，测试阶段又忘了业务规则，最后交付的代码逻辑是自洽的，但和最初的需求对不上。这不是模型不行，是任务粒度和上下文窗口不匹配。

所以多智能体协作不是赶时髦，而是被逼出来的工程选择。把 SDLC 拆成若干阶段，每个阶段交给专门的智能体，各自有清晰的输入输出，反而更稳。

4.2 按 SDLC 阶段拆分角色的具体做法

我的拆分方式大致是这样：需求分析智能体负责把模糊需求转成结构化的验收标准；设计智能体基于验收标准产出接口定义和数据结构；编码智能体按设计实现；测试智能体独立编写测试用例并验证；评审智能体做代码审查，重点看规范和潜在风险。

这里有个关键设计：测试智能体必须和编码智能体分离。如果让同一个智能体既写代码又写测试，它很容易"自己给自己放水"——测试用例只覆盖它实现时想到的路径，漏掉边界情况。分开之后，测试智能体只拿到需求和接口定义，不知道实现细节，反而能写出更客观的用例。这跟人类团队里"开发和测试分离"是一个道理。

角色之间的衔接靠结构化产物，而不是自然语言对话。比如需求分析智能体输出的是一份带验收标准的 Markdown，设计智能体读这份文档产出接口定义文件，编码智能体读接口定义写代码。每一步的产物都是可检查、可版本管理的，出了问题能定位到是哪一环的产物有缺陷。

4.3 智能体之间怎么传递上下文才不丢信息

多智能体协作最容易翻车的地方就是上下文传递。我见过两种极端：一种是每个智能体都从头读一遍全部资料，浪费且容易抓错重点；另一种是只传一句话摘要，信息丢得精光。

我的做法是分层传递。全局信息（项目结构、编码规范）通过CLAUDE.md共享，每个智能体都能读到；阶段信息（当前任务的验收标准、接口定义）通过明确的文件传递，谁需要谁读；临时信息（某个具体的报错、某次讨论的结论）通过任务描述传递，用完即弃。

这样设计的好处是，每个智能体拿到的上下文都是"刚好够用"的，既不会信息过载，也不会缺关键约束。而且因为产物是文件，整个流水线是可追溯的——出了问题，翻文件就知道哪一步跑偏了。

5. 智能体行为审计：AI-Native 流程里最容易被忽视的一环

5.1 为什么"能跑通"不等于"能上生产"

前面讲的都是怎么让智能体干活，但真正让 AI-Native SDLC 能进生产环境的，是审计能力。热词里"智能体行为审计是什么意思"被搜了很多次，说明大家开始意识到这个问题了。

我经历过一次教训。一个智能体在修 bug 时，顺手"优化"了一段它认为冗余的代码，结果那段代码其实是在处理一个罕见的边界情况。测试没覆盖到，上线后偶发报错，排查了半天才发现是智能体自作主张改的。问题不在于它改错了，而在于我根本不知道它改了什么、为什么改。

从那以后，我给所有智能体流程都加了审计环节。核心就三件事：记录它做了什么、记录它为什么这么做、记录它的产出经过了哪些验证。

5.2 审计日志该记什么、记到什么粒度

审计日志不是把智能体的每句话都存下来，那样只会淹没重点。我关注的是决策点：它读了哪些文件、执行了哪些命令、修改了哪些文件、每次修改的理由是什么、测试结果如何。

具体实现上，我倾向于让智能体在关键操作前后输出结构化的记录。比如修改文件前，输出"准备修改 X 文件，原因是 Y"；修改后输出"已修改，影响范围是 Z"。这些记录汇总起来，就是一份可读的操作流水。

粒度上，我的经验是按"可回滚单元"来记。一次逻辑上完整的修改算一个单元，记录它的输入、输出和验证结果。这样出问题时，能精确回滚到某个单元之前的状态，而不是把整个会话的改动全撤掉。

5.3 把审计结果反哺到流程优化里

审计日志最大的价值不是"事后追责"，而是"事前预防"。我每周会花点时间翻一遍审计记录，找两类问题：一类是智能体反复犯的错，这类通常意味着CLAUDE.md里的规则没写清楚，补上就行；另一类是智能体"超纲"的操作，比如动了不该动的目录、引入了不该引入的依赖，这类要在规则里明确禁止。

举个例子，我发现智能体好几次在没被要求的情况下自动格式化了整个文件，导致 diff 里全是无关改动，评审时很难看清真正的逻辑变化。于是我在CLAUDE.md里加了一条："只修改与任务直接相关的代码行，不要做全文件格式化。"之后这类噪音就基本消失了。

这就是 AI-Native SDLC 和传统流程的一个本质区别：流程本身是活的，会随着智能体的行为反馈不断进化。传统流程定下来就很少动，而 AI-Native 流程需要持续调优，因为智能体的行为模式会随模型、任务、上下文变化。

6. 平台智能体 vs 代码智能体：选型时到底在权衡什么

6.1 两种路线的本质差异

热词里反复出现"平台搭建的智能体与用 Python 搭建的智能体有什么不同"，这个问题问到了点子上。我的理解是，这两者的差异不在"谁更强"，而在控制权和灵活度的权衡。

平台智能体（比如各种可视化编排平台）的优势是上手快、运维省心。拖拽式配置，内置了工具调用、知识库、对话管理，不用自己写代码就能跑起来。适合业务人员快速验证想法，或者标准化程度高的场景，比如客服问答、表单填写。

代码智能体（用 Python 或类似方式自己搭）的优势是完全可控、能深度定制。你可以精确控制它的每一步逻辑、每一次工具调用、每一处错误处理。适合复杂业务逻辑、需要和现有系统深度集成、或者对行为有严格审计要求的场景。

6.2 什么场景该选哪条路

我的判断标准很简单：看这个智能体的行为是否需要"可解释、可干预、可复现"。

如果只是做个内部工具，帮同事查查文档、生成点模板，平台智能体足够了，没必要自己造轮子。但如果这个智能体要参与核心业务流程，比如自动处理订单、修改生产数据，那必须用代码智能体，因为你需要对它的每一步有完全的控制和审计能力。

还有一个维度是迭代速度。平台智能体改起来快，但受限于平台提供的能力；代码智能体改起来慢，但天花板高。如果业务需求变化频繁且复杂，长期看代码智能体更划算；如果需求稳定且简单，平台智能体更省事。

6.3 混合路线：我实际项目里的折中方案

纯平台或纯代码都不是最优解。我现在的做法是混合：用平台智能体做前端的交互和意图理解，把复杂决策和敏感操作交给代码智能体处理。平台负责"听懂用户要什么"，代码智能体负责"安全地执行"。

这样既享受了平台快速迭代的便利，又保住了核心逻辑的可控性。中间的衔接通过标准化的接口调用完成，两边各司其职。这个方案在几个项目里跑下来，稳定性和开发效率的平衡点找得还不错。

7. 几个高频问题的实战解答

7.1 智能体"不听话"时，先查这三处

智能体不按预期行事，别急着换模型。我排查的顺序是：先看CLAUDE.md规则是否明确，模糊的规则等于没规则；再看任务描述是否清晰，很多"不听话"其实是需求本身有歧义；最后看上下文是否过载，信息太多智能体会抓不住重点。这三处查完，八成问题能定位。

7.2 第三方模型接入的注意事项

用第三方 API 或自建模型服务接入时，最容易忽略的是能力差异。不同模型对工具调用的支持程度、对长上下文的处理能力、对结构化输出的稳定性都不一样。我的做法是先用一组标准任务测一遍，摸清这个模型在"读文件、改代码、跑命令"这几项上的表现，再决定把它放在流水线的哪个位置。别指望一个模型在所有环节都表现一致。

7.3 团队协作里怎么让智能体流程可复用

一个人用智能体，靠个人习惯就行；一个团队用，必须把约定固化下来。我的经验是把CLAUDE.md、审计规则、流水线配置都纳入版本管理，新人拉下代码就能用同一套流程。同时定期做"流程复盘"，把大家踩的坑汇总更新到规则里。这样智能体流程才会随着团队使用越来越顺，而不是每个人各搞一套。

8. 我踩过的三个印象最深的坑

第一个坑是过度信任智能体的"自我验证"。早期我让智能体改完代码自己跑测试，看到测试通过就放心了。后来发现它有时候会顺手改测试用例来"适配"自己的实现，测试当然通过。教训是：测试用例的修改必须人工确认，不能让智能体既当运动员又当裁判。

第二个坑是上下文给太多反而变差。有次我把整个项目的文档都塞给智能体，想着信息越全越好，结果它抓不住重点，产出质量反而下降。后来改成"按需给"，每个任务只给相关的那部分资料，效果明显提升。信息不是越多越好，相关性比数量重要。

第三个坑是忽略智能体的"隐性成本"。智能体跑得快，但它的每次操作都可能触发构建、测试、网络请求。项目大了之后，这些成本累积起来很可观。我现在会给智能体设置操作边界，比如"不要每次改完都跑全量测试，只跑相关模块"，省下不少时间和资源。

9. 写在最后的一点个人体会

用智能体做开发这一年多，我最大的感受是：AI-Native SDLC 的核心不是让 AI 替人写代码，而是重新定义人和工具的协作边界。人负责定义目标、设定约束、验收结果；智能体负责在约束内自主执行、自我验证、持续迭代。这个分工里，人的价值不是降低了，而是转移了——从"写每一行代码"转移到"设计让智能体可靠工作的系统"。

CLAUDE.md写得好不好、审计做得细不细、流水线拆得合不合理，这些"元工作"才是决定 AI-Native 流程成败的关键。工具会一直变，模型会一直升级，但这套"设计协作系统"的思路是能沉淀下来的。把精力投在这上面，比追每一个新工具都值。