AI-Native SDLC 实战：Claude Code + MCP + CLAUDE.md 研发流程重构指南

1. 为什么“AI-Native SDLC”不是又一个新名词

第一次听到“AI-Native SDLC”这个说法，我本能地有点抵触。做了这么多年研发流程，从瀑布到敏捷，从DevOps到平台工程，每隔两年就冒出一个新词，大部分是把旧酒装进新瓶。但真正把 Claude Code、MCP 这套东西接进日常开发流之后，我改主意了——这次不一样，它不是给流程加一个“AI 助手”的插件，而是把 AI 当成研发流程里的一等公民来重新设计。

先把缩写拆开说清楚，因为很多人搜“ai-native sdlc playbook是什么的缩写”其实是想确认它到底指什么。SDLC 就是 Software Development Life Cycle，软件开发生命周期，涵盖需求、设计、编码、测试、部署、运维这一整条链路。AI-Native 的意思是“AI 原生”，关键在“原生”两个字——不是外挂，是内生。传统做法是人在写代码，偶尔问一下 AI；AI-Native 的做法是流程本身就围绕 AI 的能力边界来设计，人负责定义目标、审查结果、把控方向。

这套实践指南要解决的问题很具体：当你的团队开始用 Claude Code 这类终端里的编码代理，用 MCP 把外部工具接进来，用 CLAUDE.md 把项目上下文固化下来之后，整个研发流程该怎么重新组织？哪些环节可以放手让 AI 跑，哪些环节必须人盯着？工具之间怎么串起来才不打架？这些问题在官方文档里往往只讲单个功能，不讲怎么拼成一条完整的流水线，而这篇就是讲拼装。

适合谁看？如果你已经在用 Claude Code，或者正在评估要不要把 AI 编码代理引入团队，又或者你是那种“工具装了一堆但流程还是老样子”的开发者，这篇会对你有用。我会尽量把每一步的“为什么”讲透，而不是只丢一堆命令让你抄。

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

2.1 从“人写代码”到“人定义意图”的范式转移

传统 SDLC 的核心假设是：代码由人一行行写出来，所以流程设计围绕“如何让人的产出更高效、更少出错”展开。代码评审、单元测试、CI 流水线，本质上都是在给人写的代码兜底。AI-Native SDLC 把这个假设换掉了：代码的主要生产者变成了 AI 代理，人的角色上移到意图定义和结果验收。

这个转变带来的第一个连锁反应是，流程的瓶颈位置变了。以前瓶颈在“写”，现在瓶颈在“审”和“定义”。你让 Claude Code 生成一个模块，它可能三十秒就写完了，但你审查这段代码、确认它符合业务语义、检查边界条件，可能要花十分钟。所以 AI-Native 流程优化的重点，从“加快编码速度”变成了“降低审查成本和提升意图表达的精确度”。

第二个连锁反应是上下文管理成了核心工程问题。AI 代理不像人，人进了项目几天就摸清了代码风格和业务背景，AI 每次对话都是从零开始理解。CLAUDE.md 这个文件就是为解决这个问题而生的——它相当于给 AI 的一份项目说明书，放在仓库根目录，Claude Code 每次启动会自动读取。把项目结构、技术栈、编码规范、常用命令、禁忌事项写进去，AI 的产出质量会有肉眼可见的提升。

2.2 工具链选型：为什么是 Claude Code + MCP + CLAUDE.md 这个组合

市面上 AI 编码工具不少，为什么这套实践指南以 Claude Code 为核心？我的判断依据有三条。第一，它是终端原生的，这意味着它能直接执行命令、读写文件、跑测试，而不是只在一个聊天窗口里给你贴代码。终端原生带来的最大好处是它可以真正“动手”，而不只是“动嘴”。第二，它对 MCP 的支持比较完整，MCP 是 Model Context Protocol，一个让 AI 模型连接外部工具和数据源的开放协议，有了它，Claude Code 就能操作数据库、调 API、读设计稿，能力边界一下子打开了。第三，CLAUDE.md 这种项目级上下文文件的设计，让团队协作成为可能——每个人用的 AI 都读同一份说明书，产出风格才能统一。

MCP 在这里的角色值得单独说。你可以把它理解成 AI 世界的“USB 接口标准”。以前每接一个工具就要写一套适配代码，MCP 把这个标准化了：只要工具实现了 MCP Server，任何支持 MCP 的 AI 客户端都能接。热搜里那些“codex 接入 figma mcp 怎么授权”“idea 插件通义灵码怎么使用 mcp 链接 oracle”，本质上都是在问同一件事——怎么让 AI 够到它原本够不到的东西。MCP 就是那根延长杆。

2.3 流程分层的设计逻辑

我把 AI-Native SDLC 分成四层来设计，从下往上依次是：上下文层、工具层、执行层、验收层。这个分层不是拍脑袋来的，而是根据“哪些东西 AI 能自主决定、哪些必须人介入”来划分的。

上下文层就是 CLAUDE.md 加上项目里的各种配置文件，它决定了 AI 对项目的理解程度。工具层是 MCP Server 的集合，决定了 AI 能操作哪些外部系统。执行层是 Claude Code 实际干活的地方，写代码、跑命令、改文件都在这一层。验收层是人介入的地方，代码评审、测试确认、合并决策都在这一层完成。

这样分层的好处是，每一层可以独立演进。你今天加一个新的 MCP Server，不影响上下文层的设计；你明天调整 CLAUDE.md 的写法，也不影响工具层的配置。各层之间通过明确的接口交互，整个系统就不会因为某个环节的变化而崩掉。

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

3.1 CLAUDE.md 到底该怎么写才有用

CLAUDE.md 是整套实践的基石，但很多人写不好。我见过最常见的错误是把 README 的内容复制一遍，或者写一堆“请写出高质量代码”这种正确的废话。AI 不需要你告诉它要写好代码，它需要的是你告诉它这个项目的“潜规则”。

一份有效的 CLAUDE.md 应该包含这几块内容。项目概览用三五句话讲清楚这个项目是干什么的、给谁用的、核心业务流程是什么。技术栈说明要具体到版本号和关键依赖，比如“使用 Vue 3.4 + TypeScript 5.3 + Vite 5，状态管理用 Pinia，不要用 Vuex”。目录结构说明要标注哪些目录是核心业务代码、哪些是自动生成的不要改、哪些是废弃的别碰。编码规范要写那些 lint 工具管不到的约定，比如“API 请求统一走 src/api 下的封装，不要在组件里直接调 axios”。常用命令要列出开发、构建、测试、部署的具体命令，AI 需要知道怎么验证自己的产出。

提示：CLAUDE.md 不要写太长，控制在 200 行以内。太长了 AI 反而抓不住重点，而且维护成本高。把最关键的约束写在前面，细节可以放到子目录的 CLAUDE.md 里。

还有一个进阶技巧：在子目录里放额外的 CLAUDE.md。Claude Code 读取上下文时会从当前目录往上逐级查找，所以你可以给前端目录写一份前端专属的规范，给后端目录写一份后端专属的，互不干扰。这个机制让大型项目的上下文管理变得可行。

3.2 MCP Server 的接入与配置要点

MCP 的接入方式取决于你用的客户端。Claude Desktop 是通过配置文件接入的，Claude Code 则是通过命令行或者配置文件。不管哪种方式，核心都是告诉客户端“去哪里启动这个 MCP Server”。

以最常见的文件系统 MCP Server 为例，配置大概长这样：

{ "mcpServers": { "filesystem": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/directory" ] } } }

这里有几个坑要注意。第一，command和args的写法取决于你的操作系统和安装方式，Windows 上可能需要用cmd /c npx这种形式。第二，路径权限要控制好，MCP Server 能访问的目录就是 AI 能操作的目录，别把整个磁盘都开出去。第三，npx 方式每次启动会检查包版本，如果网络不稳定会卡住，生产环境建议全局安装后用绝对路径。

热搜里有人问“claude mcpservers npx”相关的问题，大概率是卡在 npx 的执行上。我的建议是先用npx -y @modelcontextprotocol/server-filesystem --help在终端里手动跑一下，确认能正常启动再写进配置。如果手动跑都报错，那问题不在配置，在环境。

3.3 上下文窗口的管理策略

Claude Code 的上下文窗口是有限的，虽然现在动辄 200K token，但一个大型项目随便读几个文件就满了。上下文管理做不好，AI 会开始“忘事”，前面说过的约束后面就不遵守了。

我的策略是“按需加载，及时清理”。不要让 AI 一次性读整个项目，而是让它按任务需要去读相关文件。Claude Code 本身有文件搜索能力，你告诉它“参考 src/utils/format.ts 里的日期格式化函数”，它会自己去读，不需要你手动贴代码。任务做完之后，如果对话很长了，开一个新会话比在旧会话里继续更高效，因为旧会话里积累了大量已经不需要的上下文。

另一个技巧是把稳定的知识放进 CLAUDE.md，把临时的信息放在对话里。CLAUDE.md 的内容每次都会加载，但不会占用对话历史的额度。所以那些“永远成立”的约束放文件里，那些“这次任务特有”的要求放对话里。

3.4 权限与安全边界的设计

让 AI 直接执行终端命令这件事，兴奋之余也得冷静。Claude Code 默认会在执行敏感操作前询问你，但你可以配置成自动批准某些操作。我的建议是：读操作可以放开，写操作和删除操作必须人工确认。

具体来说，ls、cat、grep、git status、git diff这类只读命令可以设为自动批准，节省确认时间。rm、git push、npm publish、数据库写操作这类必须每次确认。这个边界不是不信任 AI，而是因为 AI 对“破坏性操作”的后果判断不如人准确——它不知道这个文件删了之后有没有别的服务在依赖。

注意：千万不要在 CLAUDE.md 或者对话里写任何密钥、密码、token。AI 的上下文可能被记录、被传输，写进去就等于泄露。需要 AI 访问敏感配置时，用环境变量或者专门的密钥管理工具，让 AI 通过命令去读取，而不是把值直接告诉它。

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

4.1 环境搭建：从零到能跑通第一条命令

先把基础环境搭起来。Claude Code 的安装方式根据平台不同有差异，macOS 和 Linux 上通常用 npm 全局安装，Windows 上除了 npm 还需要确认一些系统组件。热搜里有人遇到“claude's workspace requires the virtual machine platform on windows”这个报错，这是 Windows 上 WSL2 相关组件没启用导致的，需要在“启用或关闭 Windows 功能”里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”，然后重启。

安装完成后，第一步是验证。在终端里跑claude --version，能输出版本号就说明装好了。然后进入你的项目目录，跑claude启动交互界面。第一次启动会要求你登录或者配置 API key，按提示走就行。

接下来是配置 CLAUDE.md。在项目根目录创建这个文件，先写最基础的内容：

# 项目说明 这是一个基于 Vue 3 + TypeScript 的后台管理系统。 # 技术栈 - 框架：Vue 3.4 - 语言：TypeScript 5.3 - 构建：Vite 5 - 状态管理：Pinia - UI 库：Element Plus # 编码规范 - 组件文件用 PascalCase 命名 - 工具函数用 camelCase 命名 - API 请求统一走 src/api 目录 - 不要直接修改 node_modules 里的文件 # 常用命令 - 开发：npm run dev - 构建：npm run build - 测试：npm run test - 类型检查：npm run type-check

这份文件不用一次写完美，用起来之后发现 AI 哪里理解错了，就补一条进去。它是活的文档，跟着项目一起演进。

4.2 用 MCP 把外部工具接进来

环境跑通之后，下一步是扩展 AI 的能力边界。假设你的项目用 PostgreSQL，你希望 AI 能直接查表结构来辅助写代码，那就需要接一个 PostgreSQL 的 MCP Server。

配置写进 Claude Code 的 MCP 配置文件里，然后重启 Claude Code。启动后可以用/mcp命令查看已连接的 Server 列表，确认 PostgreSQL 那个显示为 connected。然后你就可以在对话里说“帮我查一下 users 表的结构，然后根据这个结构写一个用户列表的查询接口”，AI 会通过 MCP 去读表结构，再基于真实结构生成代码。

这里有个实操细节：MCP Server 返回的数据也会占用上下文。如果表结构很复杂，几十个字段，那读一次就吃掉不少额度。所以查表结构时尽量只查需要的表，别一次性把整个 schema 拉出来。

4.3 一个完整的任务流程演示

我拿一个真实场景来走一遍：给现有项目加一个“导出 Excel”的功能。

第一步，定义意图。我在 Claude Code 里输入：“在用户列表页面加一个导出按钮，点击后把当前筛选条件下的用户数据导出成 Excel 文件。参考 src/utils/export.ts 里已有的导出逻辑。”

第二步，AI 探索。Claude Code 会自己去读用户列表页面的组件文件、读 export.ts、读相关的 API 定义，然后给出一个实现方案。它会告诉你打算改哪几个文件、加哪些代码。

第三步，人工确认方案。我看一下它的方案合不合理，比如它说要在前端直接生成 Excel，但项目里其实有后端导出接口，那我就纠正它：“用后端的 /api/user/export 接口，不要前端生成。”

第四步，AI 执行。确认方案后，Claude Code 开始改文件。改完之后它会跑类型检查和测试，如果有报错它会自己修。

第五步，人工验收。我看 diff，确认改动符合预期，然后提交。

这个流程里，人介入的节点只有两个：确认方案和验收结果。中间的探索和执行都由 AI 完成。相比传统方式，省掉的是“我自己去翻代码找参考实现”和“我自己写代码”这两步，留下的是“判断方案对不对”和“确认结果对不对”这两步——而这两步恰恰是最需要人的经验和判断力的。

4.4 参数选择与配置调优

Claude Code 有一些可调参数，用好了能明显提升体验。模型选择上，复杂任务用能力最强的模型，简单任务可以用快一点的模型省钱。上下文窗口方面，如果项目很大，可以配置让它优先读取最近修改过的文件。

MCP Server 的超时时间也值得调。默认超时可能比较短，如果某个 MCP Server 连接的是远程数据库，网络慢的时候容易超时。在配置里加一个timeout字段，单位是毫秒，根据实际情况调整。

还有一个容易被忽略的配置是工作目录。Claude Code 默认以当前目录为工作目录，如果你在 monorepo 里，可能希望它固定在某个子包目录下工作。启动时用--cwd参数指定，或者在 CLAUDE.md 里写清楚“本项目是 monorepo，主要工作在 packages/web 目录下”。

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

5.1 安装与启动阶段的典型问题

Windows 上的问题尤其多，因为 Claude Code 底层依赖一些 Unix 工具链。我的建议是 Windows 用户直接用 WSL2，在 Linux 环境里跑，能避开大部分平台兼容性问题。热搜里“claude code windows”相关的搜索量一直很高，说明这个痛点很普遍。

5.2 MCP 连接失败的排查思路

MCP 连不上是最常见的问题之一。排查顺序应该是：先确认 MCP Server 本身能独立运行，再确认客户端配置格式正确，最后确认两者之间的通信没有阻碍。

独立运行测试就是手动执行配置里的 command 和 args，看能不能启动。如果手动都启动不了，那问题在 Server 本身，可能是包没装、版本不对、依赖缺失。如果手动能启动但客户端连不上，检查配置文件的 JSON 格式有没有语法错误，路径有没有写错，环境变量有没有传对。

还有一个隐蔽的坑：有些 MCP Server 启动后会往 stdout 打印日志，而 MCP 协议用 stdout 传数据，日志混进去就会导致协议解析失败。遇到这种情况，看 Server 的文档有没有把日志重定向到 stderr 的选项。

5.3 AI 产出质量不稳定的应对

用久了你会发现，AI 有时候表现很好，有时候像换了个人。这通常不是 AI 的问题，是上下文的问题。产出质量下降时，先检查这几项：CLAUDE.md 是不是被改乱了，对话是不是太长了导致前面的约束被“挤出去”了，任务描述是不是太模糊了。

我的经验是，任务描述里包含这三个要素时，AI 的产出最稳定：明确的输入（改哪个文件、参考哪个实现）、明确的输出（要什么效果、符合什么规范）、明确的验证方式（怎么确认做对了）。缺了任何一个，AI 就容易自由发挥。

提示：如果 AI 反复在同一个地方出错，不要一直让它重试，而是把正确的做法写进 CLAUDE.md。这样下次它就不会再犯同样的错。这比在对话里反复纠正高效得多。

5.4 团队协作中的注意事项

多人用同一套 AI-Native 流程时，CLAUDE.md 的维护就成了协作问题。我的做法是把它当成代码来管理：改动走 PR，有争议就讨论，定期回顾更新。不要让每个人按自己的习惯改，否则 AI 的行为会变得不可预测。

另外，每个人的对话历史是独立的，但 CLAUDE.md 是共享的。所以那些“团队共识”放 CLAUDE.md，那些“个人偏好”放自己的对话里或者个人的配置文件里。这个边界划清楚了，协作就不会乱。

6. 我踩过的坑和几条实在建议

先说一个我印象最深的坑。早期我在 CLAUDE.md 里写了一大段业务背景介绍，觉得写得越详细 AI 越懂。结果发现 AI 经常把背景介绍里的举例当成真实需求，在代码里实现一些根本不存在的东西。后来我把背景介绍压缩到三句话，只保留最核心的业务定义，问题就消失了。AI 需要的是约束，不是故事。

第二个坑是关于 MCP 的。我一开始接了很多 MCP Server，觉得能力越多越好。但实际上每接一个 Server，启动时就多一个连接，上下文里也多一份工具描述，AI 选择工具时的决策成本也上去了。后来我精简到只留三四个真正高频使用的，整体体验反而更流畅。工具不是越多越好，够用就行。

第三个坑是权限配置。我有一次图省事，把git push设成了自动批准，结果 AI 在一个实验性分支上改完代码直接推了，虽然没造成什么后果，但吓出一身冷汗。从那以后，所有涉及远程操作和不可逆操作的命令，我都设成必须人工确认。省那几秒钟的确认时间，不值得冒那个风险。

最后分享一个提升效率的小技巧：给常用任务写“提示词模板”。比如“新增一个 API 接口”这个任务，我固定用这个模板：“在 src/api/ 下新增一个接口，路径是 XXX，方法是 XXX，请求参数是 XXX，返回结构参考 src/api/user.ts 里的写法，写完后在 src/types/ 下补充对应的类型定义。”每次只改中间的具体参数，AI 的产出质量非常稳定。模板化是让 AI 产出可预测的最简单方法。

这套流程我用了几个月，最大的感受是：AI-Native 不是让 AI 替你做决定，而是让 AI 替你做执行，你专注在做决定上。决定做对了，执行快不快是 AI 的事；决定做错了，AI 执行得越快，你返工越惨。所以这套实践的核心竞争力，最终还是落在人的判断力上。工具在变，这条没变。