企业官网建设流程全解析

1. 从"写代码"到"指挥智能体写代码"：AI-Native SDLC到底改变了什么

过去两年，我参与过三个不同规模的研发团队做 AI 辅助开发的落地，从最初大家把 AI 当"高级自动补全"用，到后来真正把智能体（Agent）嵌进需求、设计、编码、测试、评审、发布的完整链路，中间踩的坑比想象中多得多。AI-Native SDLC这个词听起来很唬人，拆开看其实就一句话：把软件开发生命周期（SDLC）的每一个环节，都重新设计成"人和智能体协作"的形态，而不是"人干活、AI 打下手"。

这个区别非常关键。传统 AI 辅助开发，AI 是一个被动的工具，你问它答，你不问它不动。而 AI-Native 的思路是，智能体是流程里的一个"参与者"，它有上下文、有记忆、有工具调用能力、有明确的职责边界。你不再是一行行敲代码，而是定义任务、约束边界、审查产出、修正方向。说白了，你的角色从"码农"往"技术负责人"的方向偏移了。

这套实践手册要解决的问题很具体：一个团队想真正把智能体用起来，而不是停留在"演示很惊艳、落地很拉胯"的阶段，到底该怎么做。适合的读者是那些已经在用 Claude Code、Coze、或者自研智能体框架，但发现效果不稳定、团队推广困难、质量没法保证的工程师和技术管理者。如果你还停留在"AI 能不能写代码"的疑问阶段，这篇内容可能会有点超前，但提前了解整个链路的全貌也没坏处。

我下面会按 SDLC 的实际阶段来拆，每个阶段讲清楚：智能体在这里扮演什么角色、需要什么配置、我实际踩过哪些坑、怎么判断它干得好不好。核心工具会以 Claude Code 为主线，因为它是我用过把"终端操作 + 代码理解 + 智能体编排"结合得最顺手的工具之一，但思路对所有智能体框架都通用。

2. 环境搭建：Claude Code 的安装、配置与模型接入的真实门槛

2.1 为什么环境这一步就能劝退一半人

很多人以为装个 CLI 工具就是npm install一把梭，实际在 Claude Code 上，环境问题能占到新手求助量的六成以上。原因不复杂：它不是一个纯本地工具，它需要和模型服务通信，涉及网络、认证、系统权限、终端环境等多个层面。任何一个环节出问题，表现都是"命令跑了但没反应"或者"报了个看不懂的错"。

先说安装。Claude Code 本质是一个 Node.js 写的命令行工具，所以第一步是确认你的 Node 版本。我实测下来，Node 18 以下基本别想跑顺，建议直接上 Node 20 LTS。Windows 用户特别注意，原生 CMD 和 PowerShell 对某些交互式终端的支持有差异，我强烈建议用 WSL2 或者 Git Bash，能省掉大量莫名其妙的字符编码和路径问题。Ubuntu 用户相对省心，但要注意 npm 全局安装的权限问题，别动不动就sudo npm install -g，那会把后续的权限搞得一团糟，正确做法是配置 npm 的全局目录到用户空间。

安装命令本身很简单：

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

装完之后claude --version能出版本号，说明二进制没问题。但能出版本号不代表能用，真正的门槛在认证和模型接入。

2.2 认证与模型接入：官方订阅和第三方 API 的取舍

Claude Code 默认走官方订阅认证，登录流程是引导式的，跟着走就行。但实际团队使用中，经常会遇到"组织禁用了订阅访问"这类提示，这通常是因为账号归属的组织策略限制。这时候有两条路：一是用官方 API Key 走按量计费，二是接入第三方兼容 API 或者本地模型。

接入第三方 API 的核心是环境变量配置。Claude Code 支持通过ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY指向兼容的端点。我试过把它接到本地跑的 LM Studio 上，思路是 LM Studio 起一个兼容 OpenAI 或 Anthropic 协议的本地服务，然后把 base URL 指过去。这里有个坑：不是所有模型都能很好地支持 Claude Code 依赖的工具调用（tool use）协议。Claude Code 干活靠的是模型能稳定地输出结构化的工具调用指令，如果模型这方面能力弱，你会看到它"想调用工具但格式总是不对"，表现就是任务卡住或者乱执行。所以本地模型接入，建议选工具调用能力经过验证的模型，别拿一个纯对话模型硬上。

还有一个实用技巧是模型切换工具。团队里不同任务对模型要求不一样，写复杂逻辑用强模型，跑简单重构用便宜模型，手动改环境变量太麻烦。社区有类似 cc switch 这样的工具，能快速在不同模型配置间切换。我自己是写了个 shell 函数，根据当前目录的配置文件自动切换，这个后面讲项目级配置时再展开。

注意：环境变量里如果同时存在多个认证相关的配置，优先级容易搞混。我的经验是，明确只保留一套认证方式，别官方 Key 和第三方 Base URL 混着放，否则排查问题时你会怀疑人生。

2.3 编辑器集成：VS Code 里用还是终端里用

Claude Code 有 VS Code 扩展，也有纯终端模式。我的实际体会是：探索性任务用终端，聚焦编码用编辑器集成。终端模式下，智能体对文件系统的操作更自由，适合做"帮我把这个模块重构一下"这种大范围任务；编辑器集成模式下，你能实时看到它改了哪些文件、光标在哪，适合做精细的局部修改。

VS Code 配置的关键是让扩展能找到你的 CLI 和认证信息。常见问题是扩展装了但一直转圈，八成是 CLI 路径没配对，或者终端环境和 GUI 环境的环境变量不一致（macOS 上尤其常见，GUI 启动的 VS Code 读不到你.zshrc里的变量）。解决办法是在 VS Code 的 settings 里显式指定 CLI 路径，或者从终端里用code .启动 VS Code，继承终端环境。

3. CLAUDE.md：给智能体写"项目说明书"的学问

3.1 为什么一个 Markdown 文件能决定智能体的表现上限

CLAUDE.md是 Claude Code 体系里最被低估的东西。很多人第一次看到它，觉得不就是个说明文件吗，随便写两句。但实际用下来，这个文件的质量直接决定了智能体是"懂你项目的老员工"还是"每天失忆的新人"。

原理很简单：大模型没有持久记忆，每次对话都是从零开始。你不可能每次都把项目背景、代码规范、目录结构、常用命令重新讲一遍。CLAUDE.md就是那个"每次自动加载的上下文"，它会在会话开始时被注入，让智能体一上来就具备项目认知。这就像你给新同事一份入职文档，写得好他上手快，写得烂他天天问你同样的问题。

我见过效果最好的CLAUDE.md，通常包含这几块：项目一句话定位、技术栈和版本、目录结构说明、构建和测试命令、代码风格约定、以及"绝对不要做的事"。最后这条特别重要，比如"不要修改 migrations 目录下的历史文件"、"提交前必须跑 lint"，这些约束能避免智能体好心办坏事。

3.2 一份能直接抄的 CLAUDE.md 结构

我把自己项目里用的模板简化了一下，你可以直接拿去改：

# 项目概述 这是一个 [业务描述] 的后端服务，核心职责是 [一句话]。 # 技术栈 - 语言：TypeScript 5.x - 框架：NestJS - 数据库：PostgreSQL 15 - 测试：Jest # 目录结构 - src/modules：业务模块，每个模块独立 - src/common：公共工具和中间件 - test：集成测试 # 常用命令 - 安装依赖：pnpm install - 启动开发：pnpm dev - 跑测试：pnpm test - 类型检查：pnpm typecheck # 代码规范 - 所有函数必须有返回类型标注 - 禁止使用 any，用 unknown 加类型守卫 - 提交信息遵循 Conventional Commits # 禁止事项 - 不要修改 src/migrations 下的历史文件 - 不要直接改 package.json 的依赖版本，先讨论 - 不要跳过测试直接提交

这份文件不用写得多漂亮，关键是准确、具体、可执行。我踩过的坑是早期写得太笼统，比如"遵循良好代码规范"，这种话对智能体等于没说，它不知道你的"良好"是什么标准。改成"所有函数必须有返回类型标注"之后，它生成的代码质量立刻上了一个台阶。

3.3 分层配置：全局、项目、目录三级怎么配合

Claude Code 支持多级CLAUDE.md，这个设计非常实用。全局的放在用户目录下，管你所有项目的通用偏好，比如"回答用中文"、"解释代码时先讲思路再给代码"。项目级的放在仓库根目录，管这个项目的具体约定。目录级的放在子目录里，管某个模块的特殊规则。

我实际的分层策略是这样的：全局文件只放个人习惯，比如语言偏好、输出格式偏好；项目文件放技术栈和命令；目录文件放模块特有的约束，比如某个老模块还在用旧规范，就在那个目录下单独说明，避免污染整个项目。这样智能体在不同目录下工作时，加载的上下文是精准的，不会拿 A 模块的规范去套 B 模块。

提示：CLAUDE.md不是写完就完事的，它应该跟着项目演进。我养成的习惯是，每次发现智能体犯了重复性错误，就回头看看是不是CLAUDE.md里缺了对应的约束，补上之后同类问题基本不再出现。这个文件是"活的"。

4. 把智能体嵌进 SDLC：需求、编码、测试、评审各阶段的实操

4.1 需求与设计阶段：让智能体做"提问者"而不是"执行者"

大多数人在需求阶段用智能体的方式是错的——直接让它"根据这个需求写代码"。正确的做法是让它先当"提问者"和"拆解者"。我现在的流程是，把需求文档丢给它，让它输出三样东西：一是需求里的模糊点和矛盾点清单，二是技术方案的可选路径对比，三是任务拆解和依赖关系。

这个阶段智能体的价值不在于给答案，而在于帮你发现你没想到的问题。我做过一个统计，让智能体审需求，平均每个需求能揪出三到五个我漏掉的边界情况，比如并发场景、权限校验、数据一致性。这些如果等到编码阶段才发现，返工成本高得多。

具体操作上，我会用这样的提示结构：先给它项目背景（靠CLAUDE.md自动加载），然后明确说"你现在是资深架构师，请审阅以下需求，列出所有你认为需要澄清的问题，不要给解决方案"。这个"不要给解决方案"很关键，否则它会急着给方案，反而掩盖了问题。

4.2 编码阶段：任务粒度决定成败

编码阶段是智能体用得最多、也最容易翻车的地方。我总结下来，任务粒度是决定成败的第一因素。让智能体"实现整个用户模块"，结果通常是它写了一堆看起来对但跑不通的代码；让它"实现 UserService 的 createUser 方法，输入是 CreateUserDto，返回 User 实体，需要校验邮箱唯一性"，成功率就高得多。

我的经验法则是：一个任务对应一个可独立验证的产出。什么叫可独立验证？就是做完之后能立刻跑一个测试或者命令确认它对不对。任务太大，验证周期长，错误会累积；任务太小，来回沟通成本高。一般一个任务控制在"改三到五个文件、能跑通一个测试"这个量级比较合适。

另一个关键点是让智能体先读后写。我习惯在任务开始前，让它先读相关文件并复述它理解的结构，确认无误后再动手。这一步能过滤掉大量"它以为它懂了其实没懂"的情况。Claude Code 在这点上做得不错，它能主动读文件、搜索代码，但你需要明确引导它"先探索再修改"。

关于直接执行终端命令，这是 Claude Code 的强项也是风险点。它能直接跑测试、跑构建、看报错，然后根据报错自我修正，这个闭环非常高效。但前提是你要给它一个安全的执行环境。我的做法是在容器或者隔离的分支里让它跑，涉及数据库迁移、部署这类危险操作，一律要求人工确认。

4.3 测试与评审阶段：智能体最被低估的战场

测试阶段是智能体价值被严重低估的地方。写测试这件事，重复性高、逻辑清晰、有明确的对错标准，简直是为智能体量身定做的。我现在的做法是，功能代码写完后，让智能体基于代码和需求生成测试用例，然后我重点审查它有没有覆盖边界情况，而不是逐行看测试代码。

这里有个技巧：让智能体生成测试时，明确要求它列出"这个功能可能出错的场景"，然后针对每个场景写用例。这样比单纯说"写测试"效果好得多，因为它会主动思考异常路径，而不是只写 happy path。

代码评审阶段，智能体可以当"第一道筛子"。我配置了一个评审用的提示模板，让它从几个维度检查：类型安全、错误处理、资源泄漏、并发安全、命名规范。它跑一遍之后，把发现的问题分级，我再决定哪些必须改、哪些可以放过。实测下来，它能拦下大概七成的低级问题，让我能把精力放在架构和业务逻辑上。但要注意，智能体的评审意见不能全信，它有时会过度保守或者误报，尤其是涉及业务语义的判断，最终还是人来拍板。

4.4 发布与运维：智能体的边界在哪里

发布和运维阶段，我的原则是智能体可以建议，但不能自主执行。它可以帮你分析日志、定位问题、生成修复方案、写回滚脚本，但真正执行发布、改生产配置这些动作，必须有人把关。这不是不信任技术，而是这个阶段的错误代价太高，一次误操作可能影响线上所有用户。

我实际用得比较多的是"故障分析"场景。线上出问题，把相关日志和监控数据喂给智能体，让它做初步的根因分析，列出可能的原因和验证方法。它能很快地梳理出排查路径，省去大量人工翻日志的时间。但最终的判断和修复，还是靠人。

5. 智能体行为审计：怎么知道它到底干了什么、干得对不对

5.1 为什么"审计"是 AI-Native 落地的必修课

智能体越自主，审计就越重要。这不是不信任，而是工程上的基本要求。你想想，一个能自主读写文件、执行命令的智能体，如果它某次理解错了任务，改了一堆不该改的文件，你怎么发现？如果它生成的代码有隐蔽的安全问题，你怎么追溯？

智能体行为审计的核心是记录和可追溯。至少要能回答三个问题：它读了哪些文件、改了哪些文件、执行了哪些命令。Claude Code 本身有会话记录，但团队协作场景下，你需要更系统的审计机制。我的做法是把智能体的操作日志纳入版本控制流程——它每次改动都走正常的 Git 流程，提交信息里标注是智能体生成的，这样 review 和追溯都有据可查。

5.2 一套可落地的审计清单

我整理了一份实际在用的审计清单，按风险等级分：

这份清单的关键是分级，不是所有操作都要同等对待，否则审计成本会高到没人愿意用。高风险操作卡死，低风险操作放行，这样既安全又高效。

另外，我强烈建议定期做"智能体产出复盘"。每周抽时间看看这周智能体生成的代码里，哪些被回滚了、哪些引发了 bug、哪些质量特别好。这个复盘能帮你优化CLAUDE.md和提示模板，形成正向循环。我坚持做了两个月，智能体的首次通过率从大概五成提到了七成多。

6. 多智能体协作与框架选型：什么时候该上，什么时候别折腾

6.1 单智能体够用吗？先别急着上多智能体

多智能体（Multi-Agent）是现在很热的概念，但我得泼盆冷水：大部分团队连单智能体都没用好，上多智能体只会让问题更复杂。多智能体的核心价值在于任务可以并行、角色可以专业化，但代价是协调成本、通信开销、以及"多个智能体互相甩锅"的风险。

我判断要不要上多智能体的标准很简单：如果任务能清晰地拆成几个独立子任务，且子任务之间依赖少，那可以考虑；如果任务本身是高度耦合的，多智能体只会增加混乱。比如"同时重构三个互不依赖的模块"适合多智能体，"重构一个核心模块的内部逻辑"就不适合。

6.2 平台智能体 vs 代码智能体：本质区别在哪

经常有人问，用 Coze 这类平台搭的智能体和用 Python 自己写的智能体有什么不一样。我的理解是，平台智能体是"配置驱动"，代码智能体是"逻辑驱动"。

平台智能体（比如 Coze、扣子这类）把工作流、插件、知识库都做成了可视化配置，上手快，适合业务人员快速搭一个客服、问答、流程自动化之类的应用。它的边界是平台提供的能力，你想做平台没提供的功能就比较难。代码智能体（用 Python 配合 Agno、LangGraph 这类框架）灵活度高，能深度定制，但开发和维护成本高，需要工程能力。

选型的判断标准是：需求是否在平台能力范围内，以及团队有没有工程能力维护。如果只是做个内部问答助手，平台智能体一周就能上线；如果要做深度集成业务系统、有复杂状态管理的智能体，代码智能体更合适。我见过不少团队为了"技术先进"硬上代码框架，结果维护成本压垮了小团队，得不偿失。

6.3 智能体安全：OWASP 那套东西为什么值得看

2026 年智能体应用的 OWASP Top 10（ASI01–ASI10）出来后，我认真读了一遍，发现它把智能体特有的风险梳理得很到位。传统 Web 安全的那些问题在智能体场景下依然存在，但多了几类新风险：提示注入、工具滥用、权限越界、记忆污染等。

我实际最关注的是工具滥用和权限越界。智能体有工具调用能力，如果权限给太大，它可能执行你意想不到的操作。我的做法是最小权限原则——智能体需要什么工具就给什么工具，绝不给"万能执行"的权限。比如它只需要读文件，就别给写权限；只需要跑测试，就别给部署权限。这个原则听起来简单，但实际配置时很容易图省事给大了，后面出事就晚了。

7. 团队推广：从个人玩具到团队基础设施的最后一公里

技术再好，推不动团队等于零。我参与过两次智能体工具的团队推广，第一次失败了，第二次相对成功，差别主要在几个点上。

第一次失败的原因是，我上来就给大家演示"智能体多厉害"，结果大家试用后发现效果不稳定，反而失去了信心。第二次我换了策略：先找一两个愿意尝鲜的同事，一起把CLAUDE.md和提示模板打磨好，等他们用出效果了，再让他们去影响其他人。这种"种子用户"策略比自上而下推有效得多。

另一个关键是降低使用门槛。我把常用的提示模板、环境配置脚本、审计清单都整理成了团队文档，新人照着做就能跑起来，不用从零摸索。同时我明确划定了"哪些场景推荐用、哪些场景别用"，避免大家在不适合的场景硬用然后失望。

最后是建立反馈机制。我建了个小群，大家遇到智能体翻车的情况就丢进来，每周一起看看怎么优化。这个机制让CLAUDE.md和模板持续进化，也让团队成员有参与感。推广这件事，本质是让大家觉得"用了确实省事"，而不是"被要求用"。

我个人在实际操作中的体会是，AI-Native SDLC 不是一次性的技术升级，而是一个持续调优的过程。工具会变、模型会变、团队习惯也会变，唯一不变的是"明确边界、持续审计、小步验证"这几个原则。把这几个原则守住，剩下的就是耐心打磨了。