1. 从能跑就行到AI原生SDLC到底在变什么大多数团队现在的开发流程本质上还是人写代码、人审代码、人写文档、人跑测试的老四样AI只是被塞进某个环节当个高级补全工具。而AI-Native SDLCAI原生软件开发生命周期要激进得多——它把AI当成流程里的一等公民从需求拆解、方案设计、编码实现、测试验证到文档沉淀每个环节都默认AI先上人来把关。这不是给旧流程贴个AI标签而是重新设计整条流水线的分工方式。我最初接触这个概念时也犯嘀咕不就是用Claude Code写代码吗能有多大区别真正上手跑了两三个项目之后才发现区别在于上下文的管理方式。传统模式下上下文散落在每个人的脑子里、聊天记录里、零散的文档里AI原生模式下上下文被显式地写进项目根目录的配置文件比如CLAUDE.md变成AI每次开工前必读的项目宪法。这个转变听起来小实际影响极大——它逼着团队把那些只可意会的隐性知识显性化。这篇内容适合三类人看一是已经在用Claude Code、Codex这类工具但感觉没发挥出威力的开发者二是想给团队引入AI工作流但不知道从哪下手的技术负责人三是对MCPModel Context Protocol、Agent Skills这些新概念好奇、想搞清楚它们在实际项目里怎么落地的工程师。我会尽量把原理讲透同时给出可以直接抄的配置和踩过的坑。需要先明确一点AI-Native SDLC不是让AI替你做所有决定而是让AI承担重复性的上下文搬运和初稿生成人专注于判断和取舍。搞反了这个主次关系要么变成甩手掌柜导致质量失控要么变成事事亲力亲为、AI形同虚设。2. CLAUDE.md把项目上下文写成AI能读懂的入职手册2.1 为什么一个Markdown文件能决定AI的输出质量Claude Code这类工具的工作方式是每次你给它一个任务它会先扫描项目结构然后读取根目录下的CLAUDE.md如果存在把它作为系统级上下文注入。这意味着这个文件里的内容会直接影响AI对这个项目是什么、用什么规范、有哪些禁忌的理解。我做过一个对比实验同一个需求给一个React组件加表单校验在没有CLAUDE.md的项目里AI给出的方案用了yup在写了CLAUDE.md明确表单校验统一用zod禁止引入yup的项目里AI直接用了zod。差别就是这么直接。没有这个文件AI只能靠猜猜错了你还得返工。所以CLAUDE.md的本质是降低AI的猜测成本。你写得越具体AI的第一次输出就越接近可用状态来回修改的次数就越少。这不是玄学是纯粹的上下文工程。2.2 一份能直接用的CLAUDE.md骨架下面这份骨架是我在多个项目里迭代出来的你可以根据自己项目的情况删改# 项目概述 这是一个[项目类型]核心功能是[一句话描述]。 技术栈React 18 TypeScript Vite Zustand Tailwind。 # 目录约定 - src/components/ 存放通用组件每个组件一个文件夹 - src/features/ 存放业务模块按功能域划分 - src/lib/ 存放工具函数和第三方封装 - 测试文件与被测文件同目录命名 *.test.ts # 编码规范 - 所有函数必须显式标注返回类型 - 禁止使用 any必要时用 unknown 类型守卫 - 状态管理统一用 Zustand禁止引入 Redux/MobX - 样式统一用 Tailwind 类名禁止写独立 CSS 文件除非是全局主题 # 常用命令 - 开发pnpm dev - 测试pnpm test - 类型检查pnpm typecheck - 构建pnpm build # 禁忌事项 - 不要修改 vite.config.ts 里的 alias 配置 - 不要升级 package.json 里的依赖版本除非我明确要求 - 提交前必须跑通 pnpm typecheck 和 pnpm test这份骨架的关键在于具体。用TypeScript是废话禁止使用any必要时用unknown类型守卫才是有效约束。同理写测试是废话测试文件与被测文件同目录命名*.test.ts才是AI能直接执行的指令。2.3 维护CLAUDE.md的几个实操心得第一个心得这个文件要跟着项目一起演进不是写完就扔。我习惯在每次code review发现AI反复犯同一个错误时就把对应的约束补进CLAUDE.md。比如有段时间AI总喜欢在组件里直接写fetch我就在禁忌事项里加了一条所有网络请求必须走src/lib/api.ts封装禁止在组件内直接调用fetch。加完之后这个问题基本没再出现过。第二个心得文件别写太长。我见过有人把整个架构文档塞进去结果AI反而抓不住重点。控制在200行以内比较合适核心是AI容易搞错的地方和项目特有的约定通用的编程常识不用写。第三个心得可以分层。Claude Code支持在子目录放CLAUDE.md子目录的配置会覆盖或补充根目录的。我一般把全局规范放根目录把某个复杂模块的特殊约定放在那个模块的目录下。这样AI处理那个模块时能读到更精准的上下文。3. MCP让AI从聊天框走进你的工具箱3.1 MCP解决的到底是什么问题MCP全称Model Context Protocol直译是模型上下文协议。在它出现之前AI要访问外部工具数据库、文件系统、第三方API基本靠两种方式要么你把数据复制粘贴给它要么你写一堆胶水代码把工具包装成它能调用的函数。前者效率低后者每个工具都要单独适配换个AI客户端就得重写。MCP的思路是定义一个标准协议工具提供方按协议实现一个MCP ServerAI客户端按协议实现一个MCP Client两边一对接就能用。这就像USB接口——以前每个设备一个专用接口现在统一成USB插上就能用。你写一个PostgreSQL的MCP Server那么所有支持MCP的AI客户端Claude Desktop、Claude Code、各种IDE插件都能直接连上你的数据库。这个协议的价值在于解耦。工具的实现和AI客户端的选择互不依赖你可以今天用Claude Code明天换别的客户端MCP Server不用改。3.2 配置一个MCP Server的完整过程以最常见的文件系统MCP为例配置流程大致是这样{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /path/to/your/project ] } } }这段配置写在Claude Desktop的配置文件里不同系统路径不同macOS一般在~/Library/Application Support/Claude/claude_desktop_config.json。配置完重启客户端AI就能通过这个Server读写你指定目录下的文件了。几个容易踩的坑路径必须是绝对路径相对路径会失败。我第一次配的时候写了./project折腾了半小时才发现问题。npx首次运行会下载包如果网络环境不好会卡住。可以先手动npx modelcontextprotocol/server-filesystem跑一次确认能下载下来再配。权限范围要收窄。别把整个用户目录都暴露给AI只暴露项目目录。这是安全底线。3.3 MCP在实际项目里的几种用法数据库查询配一个PostgreSQL的MCP ServerAI就能直接查表结构、跑查询验证数据。我在做数据迁移脚本时特别依赖这个——写完SQL直接让AI跑一下看结果对不对不用来回切终端。浏览器自动化有些MCP Server能控制浏览器AI可以自己打开页面、点击、截图。做前端调试时很有用AI能自己验证我改的这个样式到底生效没有。逆向工程工具热词里提到的IDA MCP、x64dbg MCP属于这个范畴让AI能读取反汇编结果辅助分析。这类用法比较专业普通业务开发用不上但思路是一样的——把专业工具的能力通过MCP暴露给AI。设计稿对接Figma MCP能让AI读取设计稿的图层信息直接生成对应的组件代码。这个在还原度要求高的项目里能省不少事但要注意生成的代码通常需要人工调整别指望一键完美。提示MCP Server的质量参差不齐用之前先看它的权限声明。一个需要读取你整个硬盘的MCP Server和一个只读指定目录的风险完全不同。4. Agent Skills把一次性提示变成可复用能力4.1 Skills和普通提示词的本质区别大部分人用AI的方式是每次遇到问题现写提示词。写得好的一次性解决写得不好的来回改。问题是这些提示词用完就散了下次遇到类似问题还得重写。Agent Skills要解决的就是这个——把验证过的提示词固化成可复用的技能包。一个Skill本质上是一个带元数据的Markdown文件里面写清楚这个技能是干什么的、什么时候触发、具体怎么做。AI在处理任务时会根据当前上下文自动判断该不该调用某个Skill。这比手动复制粘贴提示词高级的地方在于自动匹配——你不需要记住我有个处理CSV的提示词AI自己会判断当前任务需要它。4.2 写一个Skill的实操结构一个典型的Skill文件长这样--- name: api-error-handler description: 当需要为API请求添加统一错误处理时使用此技能 --- # API错误处理规范 ## 触发条件 当用户要求为fetch/axios请求添加错误处理或代码中出现未捕获的网络请求时。 ## 处理步骤 1. 检查是否已有 src/lib/api.ts 封装有则复用 2. 错误分类 - 网络错误无响应→ 提示网络连接失败请检查网络 - 4xx → 提取后端返回的message字段展示 - 5xx → 提示服务暂时不可用请稍后重试并上报 3. 所有错误必须走统一的 toast 提示禁止 console.error 了事 4. 关键请求失败要触发重试逻辑最多重试2次间隔1秒 ## 示例 [附上一段正确实现的代码]关键在于description字段——AI靠它判断什么时候该用这个Skill。写得模糊比如处理错误会导致误触发写得具体为API请求添加统一错误处理才能精准匹配。4.3 Skills的维护策略我的做法是从重复劳动中提炼Skill。具体来说如果我发现自己在最近一周内对AI说过三次以上类似的话比如记得给这个函数加JSDoc注释那就说明这该固化成一个Skill了。Skill不是越多越好。我目前项目里常驻的Skill不超过十个覆盖的都是高频场景API错误处理、组件创建模板、测试用例生成、数据库迁移脚本、日志埋点。每个都是经过多次迭代、验证过效果的。有个细节要注意Skill里写的步骤要可执行不能是要保证代码质量这种空话。AI需要的是第一步做什么、第二步做什么的具体指令不是原则性要求。5. 把工具串起来一条完整的AI-Native工作流5.1 从需求到提交的完整链路说了这么多工具实际跑起来是什么样我拿最近做的一个功能举例——给后台管理系统加一个批量导出用户数据的功能。第一步需求拆解。我把需求描述丢给Claude Code它读了CLAUDE.md知道项目用ReactTSZustand然后给出一个实现方案新增一个导出按钮组件、一个导出状态store、一个调用后端导出接口的service函数。方案里还标注了导出是异步任务需要轮询状态这个我差点漏掉的点。第二步编码实现。我确认方案后让它生成代码。因为CLAUDE.md里写了网络请求走src/lib/api.ts封装它生成的service直接复用了现有封装没有自己造轮子。这一步省了我至少半小时。第三步验证。我配了PostgreSQL的MCP Server让AI直接查了一下用户表的结构确认导出字段和实际表结构对得上。这个检查如果靠人工翻文档容易漏。第四步测试。我触发了一个测试用例生成的Skill它按项目约定的命名和目录规则生成了测试文件覆盖了正常导出、空数据、接口超时三种情况。第五步提交前检查。CLAUDE.md里写了提交前必须跑通pnpm typecheck和pnpm testAI自己跑了这两个命令发现一个类型错误并修复了。整条链路走下来我的实际工作量是确认方案、review代码、处理AI搞不定的一个边界情况。相比传统方式重复性的部分基本被AI吃掉了。5.2 哪些环节AI还不靠谱必须诚实地说有几个环节AI目前还容易翻车复杂的业务逻辑判断。涉及多条件组合、历史遗留的特殊规则时AI容易给出看起来对但实际不符合业务的方案。这类地方我现在都会人工过一遍。跨模块的重构。改动涉及三个以上模块时AI容易顾此失彼改了这个忘了那个。我的做法是拆成小任务逐个处理不一次性丢给它。性能敏感的场景。AI生成的代码通常能跑但不一定跑得快。涉及大数据量、高频调用的地方需要人工优化。安全相关的代码。权限校验、输入过滤这类AI写的只能当草稿必须人工审查。这不是AI能力问题是责任问题。5.3 团队协作时的注意事项如果要把这套工作流推广到团队有几个坑要提前避开CLAUDE.md要统一维护。别让每个人自己改否则AI在不同人机器上表现不一致。我建议指定一个人负责改动走review。Skill要版本化。把Skill文件纳入git管理这样能追溯为什么这个Skill是这么写的也方便回滚。别指望零学习成本。团队里总有人觉得AI写的代码不可信或者我自己写更快。我的经验是先用一个具体项目做示范让大家看到实际效率提升比讲道理管用。建立review机制。AI生成的代码必须走正常review流程不能因为是AI写的就降低标准。恰恰相反AI容易犯一些人类不会犯的错比如幻觉出不存在的APIreview时要特别留意。6. 几个我踩过的坑和对应的解法6.1 上下文污染导致AI越改越乱有次我让AI改一个函数改完发现它顺手把旁边几个不相关的函数也优化了结果引入了新bug。原因是CLAUDE.md里没写清楚改动范围。解法在CLAUDE.md里加一条只修改我明确指定的文件/函数不要顺手改动其他代码。另外给任务时尽量具体比如只修改src/features/user/export.ts里的handleExport函数而不是优化一下导出功能。6.2 MCP Server超时导致任务卡死配了一个查询量比较大的数据库MCPAI查询时经常超时然后整个任务就卡在那里。后来发现是查询没加limitAI默认查全表。解法在MCP Server的配置里加查询超时和行数限制同时在CLAUDE.md里写明查询数据库必须加limit默认100条。双保险。6.3 Skill误触发有个生成测试用例的Skilldescription写得太宽泛结果AI在我只是想让它在代码里加个注释时也触发了生成了一堆用不上的测试。解法把description改具体从生成测试改成当用户明确要求为某个函数或模块生成单元测试时使用。触发条件越明确误触发越少。6.4 不同AI客户端配置不互通我同时在用Claude Code和另一个客户端发现CLAUDE.md两边都认但MCP配置格式不一样得配两遍。解法目前没有完美方案只能各自维护。但Skill文件是通用的都是Markdown所以我把精力主要花在Skill上MCP配置按客户端分别维护。7. 关于这套工作流我目前的真实看法跑了几个月下来我的结论是AI-Native SDLC的收益不在写代码更快而在上下文管理更清晰。CLAUDE.md逼你把项目约定写下来Skill逼你把重复劳动固化下来MCP逼你把工具接口标准化。这些事就算没有AI也该做只是AI让它们的收益变得立竿见影。但它不是银弹。我现在的实际效率提升大概在30%到40%之间不是某些宣传里说的十倍。提升主要来自重复性工作的减少和上下文切换的降低而不是AI能替我做架构决策。那些需要判断力的部分该花的时间一点没少。如果你刚开始尝试我的建议是从CLAUDE.md开始别一上来就搞MCP和Skill。先把项目上下文写清楚感受一下AI输出质量的变化再逐步引入更复杂的工具。工具是为人服务的别本末倒置。最后分享一个我最近在用的技巧每周花十分钟回顾一下这周对AI说过的重复指令挑出最高频的一两条固化成Skill或补进CLAUDE.md。这个习惯坚持下来你的AI工作流会自己进化越用越顺手。