企业官网建设流程全解析

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

这两年大家嘴上都在说"AI 编程"，但真正落到日常开发流程里，多数团队其实还停留在"把 AI 当高级补全工具"的阶段——写个函数让它补全，报错了贴给它看看，仅此而已。而AI-Native SDLC（AI 原生软件开发生命周期）说的完全是另一回事：它不是给现有流程打补丁，而是从需求、设计、编码、测试到交付的每一环，都默认"有一个能读写文件、能执行命令、能调用外部工具的智能体参与其中"来重新设计。

我最早接触这套思路，是从Claude Code这类终端智能体开始的。它和网页版聊天最大的区别在于：它能直接在你的项目目录里读文件、改代码、跑测试、执行 git 操作，甚至通过MCP（Model Context Protocol，模型上下文协议）去连接数据库、浏览器、设计稿、内部系统。换句话说，它不再是一个"问答窗口"，而是一个坐在你工位旁边、能动手的协作者。

这篇文章我想聊的不是"AI 有多强"这种空话，而是把一套能真正跑起来的 AI-Native SDLC 实践拆开讲：CLAUDE.md 怎么写才有用、MCP 到底解决了什么工程问题、本地模型怎么接、多工具协作时怎么不打架、以及那些官方文档不会告诉你的坑。适合已经在用或准备上手 Claude Code、Codex、各类 MCP 服务的开发者，也适合想把 AI 真正嵌进团队流程的技术负责人。哪怕你之前只听说过这些名词，跟着往下看也能搭出一套自己的最小可用流程。

2. CLAUDE.md：把"团队默契"写成 AI 能读懂的契约

2.1 为什么一个 Markdown 文件能决定 AI 干活的质量

很多人第一次用 Claude Code，上来就丢一句"帮我重构这个模块"，然后抱怨它改得乱七八糟。问题往往不在模型，而在于它不知道你的项目规矩。CLAUDE.md 就是解决这个问题的——它是放在项目根目录（或子目录）的一个约定文件，Claude Code 在启动时会自动读取，把它当作这个项目的"上下文宪法"。

你可以把它理解成新员工入职时拿到的那份《团队开发规范》。没有它，AI 只能靠猜：这个项目用 pnpm 还是 npm？测试跑pytest还是vitest？提交信息要不要遵循 Conventional Commits？目录结构里src/core和src/utils的边界在哪？这些猜错的成本，最后都变成你 review 时的时间。

我自己的经验是：CLAUDE.md 写得越具体，AI 的返工率越低。一份好的 CLAUDE.md 通常包含这几块内容：

• 项目定位与技术栈：一句话说清这是什么项目，用了哪些框架、语言版本、包管理器。
• 目录结构与职责边界：哪些目录是核心逻辑，哪些是自动生成的（明确告诉 AI 别乱改）。
• 常用命令：构建、测试、lint、类型检查、启动开发服务器的确切命令。
• 代码规范：命名习惯、错误处理方式、日志规范、注释语言。
• 禁区：不允许改的文件、不允许引入的依赖、不允许执行的命令。

2.2 一份可直接抄的 CLAUDE.md 骨架

下面这份是我在多个项目里迭代出来的模板，你可以按需删减：

# 项目说明 这是一个基于 TypeScript + Node.js 的后端服务，使用 pnpm 管理依赖。 ## 技术栈 - 运行时：Node.js 20 - 语言：TypeScript 5.x（strict 模式） - 框架：Fastify - 测试：Vitest - 数据库：PostgreSQL + Prisma ## 常用命令 - 安装依赖：pnpm install - 开发启动：pnpm dev - 运行测试：pnpm test - 类型检查：pnpm typecheck - 代码格式化：pnpm lint:fix ## 目录约定 - src/modules/：业务模块，每个模块独立目录 - src/shared/：跨模块共享工具，改动需谨慎 - prisma/：数据库 schema 与迁移，禁止手改生成的 client - dist/：构建产物，禁止编辑 ## 编码规范 - 所有导出函数必须有 JSDoc 注释 - 错误统一用 AppError 类抛出，不要直接 throw new Error - 日志使用 logger 实例，禁止 console.log - 提交信息遵循 Conventional Commits ## 禁区 - 不要修改 .env 和任何密钥文件 - 不要升级主版本依赖，除非我明确要求 - 不要执行 git push

2.3 分层放置：根目录与子目录的 CLAUDE.md 怎么配合

一个容易被忽略的细节是：CLAUDE.md 支持分层。根目录放全局规范，子目录放局部规范。比如src/modules/payment/CLAUDE.md里可以写"支付模块涉及金额计算，所有金额用整数分表示，禁止浮点运算"。当 AI 在这个目录下工作时，它会同时读到根级和目录级的约定。

这个机制的价值在于上下文精准投放。你不需要把所有规则都堆在根文件里让 AI 每次都读一遍，而是把领域知识放在它真正需要的地方。我见过一个团队把数据库迁移的注意事项写在prisma/CLAUDE.md里，结果 AI 每次改 schema 都会自动遵守他们的命名和回滚策略，省了大量 review 沟通。

提示：CLAUDE.md 不是越长越好。超过几百行后，关键规则容易被淹没。建议根文件控制在 100 行以内，把细节下沉到子目录。

3. MCP：让 AI 从"读代码"进化到"操作系统"

3.1 MCP 到底是个什么协议，为什么突然到处都是

MCP 全称 Model Context Protocol，是一个软件层面的通信协议（不是硬件协议，很多人第一次听到会联想到硬件总线，其实它是应用层的）。它定义了一套标准接口，让 AI 客户端（比如 Claude Desktop、Claude Code、各类 IDE 插件）能够以统一的方式连接外部"能力提供方"——这些提供方就叫 MCP Server。

在没有 MCP 之前，每接一个新工具都要单独写适配：接数据库写一套，接浏览器写一套，接设计稿再写一套。MCP 把这个过程标准化了：只要工具方实现一个 MCP Server，任何支持 MCP 的客户端都能直接调用。这就是为什么你最近会看到"某某接入 MCP""某某 MCP 教程"满天飞——它正在变成 AI 工具生态的通用插座。

从工程角度看，MCP Server 通常提供三类能力：

3.2 浏览器类 MCP 的选型：Browser Use 与 Playwright 的差异

热词里有个很实际的问题："browser use mcp 跟 playwright mcp 有什么区别"。这俩确实容易混，我按实际使用体验说下区别。

Playwright MCP本质是把 Playwright 的自动化能力暴露给 AI。它的强项是确定性操作：打开指定 URL、点击某个选择器、填写表单、截图、抓取 DOM。适合做端到端测试、页面数据提取、固定流程的自动化。它的行为可预测，适合写进 CI。

Browser Use MCP更偏向让 AI 自主决策浏览。你给它一个目标（比如"帮我在这个网站找到定价页并总结套餐差异"），它会自己规划点击路径、判断页面元素。灵活但不确定性更高，适合探索性任务。

选型建议很直接：

• 流程固定、要稳定复现 → 选 Playwright MCP
• 目标模糊、需要 AI 自己找路 → 选 Browser Use MCP
• 两者可以共存，按任务类型切换

3.3 从零接一个 MCP Server 的完整过程

以最常见的本地 MCP Server 为例，配置通常写在客户端的配置文件里。Claude Desktop 的配置大致长这样：

{ "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/dir"] }, "postgres": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-postgres"], "env": { "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb" } } } }

几个实操要点：

1. npx -y里的-y别省。不加的话首次运行会卡在交互式确认，AI 客户端等不到响应就超时了。
2. 路径要写绝对路径。相对路径在不同工作目录下解析结果不一样，很容易出现"文件明明在却读不到"。
3. 改完配置必须重启客户端。MCP Server 是在客户端启动时拉起的，热改配置不生效。
4. 权限最小化。filesystem server 只暴露你真正需要的目录，别图省事把整个用户目录挂进去。

3.4 MCP 排查：为什么"codex 无法找到 mcp"

这类问题我踩过不止一次，排查链路基本固定：

• 先看客户端日志。MCP 连接失败几乎都会在日志里留下痕迹，比瞎猜快得多。
• 确认命令能在终端独立跑通。把配置里的command和args复制到终端手动执行，如果这里就报错，问题在 Server 本身而不是客户端。
• 检查 Node 版本。很多 MCP Server 要求 Node 18 以上，版本太低会静默失败。
• Windows 上的路径与转义。Windows 下command有时需要写成cmd /c npx ...，否则找不到可执行文件。
• 环境变量没传进去。像数据库连接串这种，如果没在env里声明，Server 启动就会因为缺配置而退出。

注意：MCP Server 崩溃时，客户端往往只显示"工具不可用"，不会告诉你具体原因。养成先看日志的习惯，能省掉一半排查时间。

4. 本地模型与多工具协作：把成本和隐私握在自己手里

4.1 Claude Code 调用本地模型的现实路径

有些场景下你不想把代码发到云端：内部项目、敏感数据、或者单纯想省 token 成本。这时候可以让 Claude Code 走本地模型。常见做法是通过 LM Studio 或类似工具在本地起一个兼容 OpenAI 接口的服务，然后通过环境变量把 Claude Code 的请求指向本地端点。

大致流程是：

1. 在 LM Studio 里加载一个支持工具调用的模型（比如 Qwen 系列的 coder 版本），启动本地服务，记下端口。
2. 设置环境变量，把 API base 指向http://localhost:端口/v1，并填入本地服务要求的 key（通常随便填）。
3. 启动 Claude Code，验证它能否正常读写文件。

这里有个关键前提：本地模型必须支持function calling / tool use，否则 Claude Code 的文件操作、命令执行这些能力全都用不了，只能当普通聊天。我试过几个不支持工具调用的模型，表现就是"它一直在描述要做什么，但从不真正动手"，非常迷惑。

另外，本地模型的上下文窗口和推理能力通常弱于云端，复杂重构任务容易半途跑偏。我的建议是：简单任务、隐私敏感任务走本地，复杂架构任务还是用云端，别硬扛。

4.2 多 MCP 同时挂载时的冲突与隔离

当你同时挂了文件系统、数据库、浏览器、设计稿好几个 MCP Server，会出现几个典型问题：

• 工具名冲突：两个 Server 都提供了叫search的工具，AI 调用时可能选错。
• 上下文膨胀：每个 Server 的工具描述都塞进上下文，token 消耗飙升，模型反而变笨。
• 权限交叉：数据库 Server 能删表，文件 Server 能删文件，AI 一次误操作可能造成连锁反应。

我的处理原则是按任务场景分组挂载，而不是一次全开。做后端开发时只挂文件系统和数据库；做前端联调时挂文件系统和浏览器；做设计还原时挂文件系统和设计稿 MCP。这样既省 token，又降低误操作面。

如果确实需要同时挂多个，给每个 Server 起语义清晰的名字，比如db_readonly、fs_project，让 AI 在工具选择时有更明确的线索。

4.3 用 Agent Skills 把重复流程固化下来

Claude 的 Agent Skills 机制值得单独说一句。它允许你把一套固定的操作流程（比如"发布前检查清单""新模块脚手架生成"）写成可复用的技能，AI 在需要时自动加载。这本质上是把团队 SOP 变成了 AI 可执行的资产。

举个我实际用的例子：我写了一个"新增 API 端点"的 Skill，里面规定了要同时改路由、加测试、更新 OpenAPI 文档、写迁移。以前每次都要口头交代一遍，现在 AI 一触发这个 Skill 就按全套流程走，漏项率大幅下降。这是 AI-Native SDLC 里最被低估的一环——流程知识的结构化沉淀。

5. 把 AI 嵌进交付链路：从单点工具到完整工作流

5.1 一个可落地的日常开发闭环

说了这么多工具，最终要落到"每天怎么用"。我现在的日常闭环大致是这样：

1. 需求理解阶段：把需求文档丢给 AI，让它先复述一遍理解，并列出它认为模糊的点。这一步能提前暴露需求歧义。
2. 方案设计阶段：让 AI 基于 CLAUDE.md 里的项目约定，给出实现方案和涉及的文件清单，我确认后再动手。
3. 编码阶段：AI 按方案改代码，每改完一个模块就跑一次测试，而不是全部改完再测。
4. 自检阶段：让 AI 自己 review 一遍改动，重点看边界条件和错误处理。
5. 提交阶段：AI 生成符合规范的提交信息，我确认后提交。

这个闭环的核心思想是小步验证。AI 一次性改十个文件然后全崩，排查成本极高；改一个验一个，问题定位快得多。

5.2 团队协作时最容易翻车的地方

个人用 AI 和团队用 AI 是两码事。团队场景下我见过几个高频翻车点：

• CLAUDE.md 各写各的：每个人本地一份，规范不统一，AI 行为不一致。应该把 CLAUDE.md 纳入版本控制，像代码一样 review。
• MCP 配置散落：有人挂了数据库写权限，有人挂了生产环境连接串。应该统一配置模板，敏感连接串走环境变量，不进仓库。
• AI 生成的代码没人 review：这是最危险的。AI 写的代码看起来对，但可能藏着安全漏洞或性能陷阱。AI 可以写，但必须有人签字。
• 过度依赖导致能力退化：团队里如果没人真正理解底层逻辑，出问题时连排查方向都没有。保持核心成员的手写能力很重要。

5.3 成本与效率的真实权衡

最后聊点实在的。AI-Native SDLC 不是免费的午餐，它的成本体现在几处：

我的体会是：AI-Native 的收益不在"写代码更快"，而在"把重复的、结构化的、有明确规范的工作自动化掉"。真正省时间的是那些你本来就要做、但每次都要重复交代的事——脚手架、测试、文档、提交规范。把这些固化进 CLAUDE.md 和 Skills，收益才稳定。

至于那些需要判断力、需要权衡取舍的架构决策，AI 目前还是辅助角色。把它当"执行力极强的初级工程师"来用，而不是"能替你做决定的架构师"，心态会稳很多。我在实际项目里最有效的一条经验就是：让 AI 干它擅长的确定性工作，把不确定性留给自己。这条线划清楚了，整套流程才跑得顺。