1. 从“能跑就行”到“AI原生”为什么我们需要一套SDLC实践手册如果你最近半年一直在关注研发效能这个圈子大概率已经被两个词反复刷屏一个是AI-Native另一个是SDLC。前者说的是“把AI当成一等公民来设计系统”后者说的是软件开发生命周期Software Development Life Cycle。把这两个词拼在一起就是当下很多团队正在摸索的方向——AI-Native SDLC也就是让AI深度嵌入需求、设计、编码、测试、发布、运维的每一个环节而不是只在某个角落里当个“代码补全插件”。我所在的团队从去年下半年开始逐步把日常研发流程往这个方向迁移。踩过的坑、绕过的弯路、半夜被智能体“自作主张”改坏分支的崩溃时刻加起来能写一本小册子。所以这篇博文我想把这一整套实践整理成一份可复现、可抄作业的实践手册。它适合三类人一是正在评估要不要把AI引入研发流程的技术负责人二是已经用上Claude Code、Coze、各类智能体框架但感觉“用了个寂寞”的一线工程师三是想搞清楚AI-Native到底和传统DevOps差在哪里的产品、测试同学。核心关键词我先摆出来AI-Native、SDLC、Claude Code、智能体、CLAUDE.md。这五个词基本构成了整套方法论的骨架。Claude Code负责“动手”智能体负责“编排”CLAUDE.md负责“立规矩”SDLC负责“定流程”AI-Native则是贯穿始终的设计哲学。下面我会从整体设计思路讲起再拆到每个环节的实操细节最后把常见坑和排查技巧一次性倒出来。2. 整体设计与思路拆解AI-Native SDLC到底长什么样2.1 传统SDLC的痛点与AI-Native的切入点传统SDLC的经典模型是瀑布或敏捷核心逻辑是“人做决策工具做辅助”。需求评审靠人、架构设计靠人、写代码靠人、写测试靠人、Code Review靠人。工具的作用是让人的动作更快一点比如IDE的自动补全、CI的自动化流水线。问题在于当代码量、需求变更频率、系统复杂度同时上升时人的带宽就成了瓶颈。一个中等规模的团队每周可能要处理几十个需求、上百次提交、上千条测试用例。人不可能在每个环节都保持高质量输出于是“技术债”就像滚雪球一样越滚越大。AI-Native的切入点不是“让人更快”而是“让AI承担一部分决策和执行”。具体来说它把SDLC拆成若干个可被智能体接管的任务单元每个单元有明确的输入、输出、约束和验收标准。智能体在这些约束下自主完成工作人只负责定义约束和验收结果。这个转变听起来很激进但实际落地时可以循序渐进。我们团队的做法是先从“编码”和“测试”两个环节切入因为这两个环节的输入输出最明确最容易定义验收标准。等跑顺了再往需求分析和运维扩展。2.2 为什么选Claude Code作为核心执行器市面上能写代码的AI工具不少从IDE插件到独立Agent都有。我们最终把Claude Code作为核心执行器主要基于三个考量。第一是终端原生。Claude Code直接跑在终端里能执行shell命令、读写文件、调用git这意味着它天然具备“操作整个项目”的能力而不是只在一个编辑器窗口里补全代码。对于SDLC来说这个能力很关键因为很多任务比如跑测试、改配置、提交代码都需要跨文件、跨工具操作。第二是CLAUDE.md机制。这是Claude Code的一个核心设计你可以在项目根目录放一个CLAUDE.md文件里面写清楚项目的技术栈、代码规范、目录结构、常用命令、禁忌事项。Claude Code每次启动时会自动读取这个文件相当于给智能体发了一份“项目说明书”。这个机制让“约束”变得可版本化、可复用而不是每次对话都要重新交代一遍。第三是可编排性。Claude Code可以通过命令行调用也可以被其他智能体框架调用。这意味着它可以作为整个AI-Native SDLC流水线中的一个“执行节点”而不是一个孤立的工具。当然Claude Code不是唯一选择。如果你所在的环境有网络或账号限制也可以考虑用其他支持本地模型或第三方API的方案核心思路是一样的找一个能操作终端、能读项目上下文、能被编排的执行器。2.3 CLAUDE.md给智能体立规矩的核心文件很多人用AI写代码觉得“不好用”根本原因是没有给AI足够的上下文。你让一个刚入职的工程师直接改生产代码不给他看文档、不告诉他规范他也会改得一塌糊涂。智能体同理。CLAUDE.md就是解决这个问题的。它本质上是一份面向智能体的项目说明书内容可以包括项目技术栈和版本约束比如“用Python 3.11不要用3.12的新语法”代码风格规范比如“函数名用snake_case类名用PascalCase”目录结构说明比如“所有业务逻辑放在src/core测试放在tests/unit”常用命令比如“跑测试用pytest -xvs格式化用ruff format”禁忌事项比如“不要直接改migrations目录不要动.env文件”验收标准比如“提交前必须通过ruff check和pytest”这份文件的价值在于它把“隐性知识”变成了“显性约束”。团队里老员工知道但没写下来的规矩现在写下来给智能体看同时也给新员工看。一举两得。我们团队的CLAUDE.md大概有200多行分了十几个小节。每次有新的踩坑经验就往里加一条。半年下来这份文件成了项目里更新最频繁的文档之一。2.4 智能体在SDLC各环节的角色分工AI-Native SDLC不是“一个智能体干所有事”而是“多个智能体各司其职”。我们目前把智能体分成四类智能体类型负责环节核心职责典型工具需求解析智能体需求分析把模糊需求拆成可执行任务Coze、自定义Agent编码智能体开发按任务写代码、改代码Claude Code测试智能体测试生成测试用例、跑测试、报bugClaude Code pytest审查智能体Code Review检查代码规范、安全隐患Claude Code 自定义规则这四类智能体之间通过任务队列和产物仓库连接。需求解析智能体输出的任务卡是编码智能体的输入编码智能体提交的代码是测试智能体和审查智能体的输入。每个环节的产物都有明确的格式要求方便下一个环节消费。这个架构的好处是可替换、可观测、可回滚。如果某个环节的智能体表现不好可以单独替换不影响其他环节。每个环节的输入输出都有记录出问题能追溯。3. 核心细节解析与实操要点从CLAUDE.md到智能体编排3.1 CLAUDE.md的编写规范与分层策略写CLAUDE.md不是写README它的读者是智能体所以语言要精确、无歧义、可执行。我见过一些团队的CLAUDE.md写得像散文智能体读完还是不知道该干嘛。下面是我们总结的几条编写规范。第一条用命令式语气不用描述式语气。比如不要写“项目使用ruff进行代码检查”而要写“提交前必须运行ruff check如果有错误必须修复”。前者是描述后者是指令。智能体对指令的响应更准确。第二条分层组织从全局到局部。我们的CLAUDE.md分三层第一层是全局约束技术栈、通用规范第二层是模块级约束每个核心模块的特殊规则第三层是任务级约束特定类型任务的额外要求。这样智能体在处理不同任务时能快速定位到相关约束。第三条禁忌事项单独成节用加粗标注。智能体有时候会“过度发挥”比如自动帮你重构了不该动的代码。所以禁忌事项要写得非常明确并且放在显眼位置。我们的禁忌事项节大概有十几条每条都以“不要”开头。第四条定期更新和代码同步。CLAUDE.md不是写完就扔的。每次Code Review发现智能体犯了新错误就加一条约束。每次技术栈升级就更新对应版本号。我们团队规定任何PR如果修改了项目结构或规范必须同步更新CLAUDE.md。下面是一个CLAUDE.md的片段示例展示一下实际写法## 全局约束 - Python版本3.11不要使用3.12的match语法 - 包管理使用uv不要用pip直接安装 - 代码格式化提交前必须运行 ruff format . - 类型检查提交前必须运行 mypy src/ ## 禁忌事项 - **不要修改 migrations/ 目录下的任何文件** - **不要提交 .env 或任何包含密钥的文件** - **不要删除 tests/ 目录下的现有测试用例** - **不要在没有通过测试的情况下提交代码** ## 常用命令 - 跑全部测试pytest -xvs - 跑单个测试pytest tests/unit/test_xxx.py -xvs - 启动开发服务uv run uvicorn src.main:app --reload3.2 Claude Code的安装与环境配置要点Claude Code的安装本身不复杂但在不同操作系统上有些细节需要注意。我分别在macOS、Ubuntu和Windows上装过下面把关键步骤和坑点列一下。macOS和LinuxUbuntu官方推荐用npm全局安装。前提是Node.js版本不低于18。安装命令是npm install -g anthropic-ai/claude-code。装完之后在项目目录下运行claude就能启动。如果遇到权限问题不要用sudo而是配置npm的全局目录到用户目录下。WindowsWindows上建议用WSL2直接在WSL的Ubuntu环境里按Linux的方式装。原生Windows支持也有但终端交互体验差一些尤其是涉及路径和换行符的时候容易出问题。如果非要用原生Windows记得把git的core.autocrlf设为false避免智能体改文件时把换行符搞乱。Ubuntu配置Claude Code的额外步骤Ubuntu上如果遇到claude: command not found大概率是npm全局bin目录没加到PATH里。可以运行npm config get prefix看看路径然后把这个路径下的bin目录加到.bashrc里。另外Ubuntu的默认shell如果是dash建议切成bash因为Claude Code的一些脚本依赖bash特性。VS Code集成如果你习惯在VS Code里工作可以装Claude Code的VS Code扩展。装完之后在VS Code的终端里运行claude它会自动识别当前工作区。这样你既能在编辑器里看代码又能在终端里和智能体交互。实测下来这个组合比纯终端效率高不少尤其是需要边看代码边给智能体下指令的时候。账号与访问限制有些团队环境会遇到“your organization has disabled claude subscription access for claude code”这类提示这通常是组织层面的账号策略限制。遇到这种情况可以联系管理员确认策略或者考虑用支持第三方API的方案作为替代。核心思路是执行器可以换但CLAUDE.md和智能体编排的逻辑是通用的。3.3 智能体任务编排的核心逻辑智能体编排听起来很玄其实核心就三件事任务定义、任务分发、结果验收。任务定义的关键是“颗粒度”。任务太大智能体容易跑偏任务太小编排开销比收益还高。我们的经验是一个任务最好对应“一个可独立测试的功能点”比如“实现用户登录接口的密码校验逻辑”而不是“实现用户登录功能”。前者有明确的输入输出和验收标准后者太模糊。任务分发的关键是“上下文传递”。编码智能体在开始工作前需要知道这个任务要改哪些文件、依赖哪些现有模块、遵循哪些规范、验收标准是什么。这些信息要结构化地传给智能体而不是让它自己去猜。我们的做法是给每个任务生成一个JSON格式的任务卡包含上述字段然后让Claude Code读取任务卡并执行。结果验收的关键是“自动化检查”。智能体提交代码后自动触发测试智能体和审查智能体。测试智能体跑单元测试和集成测试审查智能体检查代码规范和安全隐患。只有两者都通过代码才能进入人工Review环节。这样人的精力就集中在“业务逻辑是否正确”这种真正需要人判断的事情上。3.4 智能体行为审计与安全边界智能体越自主审计就越重要。我们团队在早期吃过亏一个编码智能体在修bug时顺手把旁边一个不相关的函数也重构了结果引入了新bug。从那以后我们加了几道审计关卡。第一道是文件变更白名单。每个任务卡里明确列出允许修改的文件范围智能体如果试图修改范围外的文件会被拦截并报警。这个拦截是在Claude Code的配置里做的通过自定义的pre-commit hook实现。第二道是命令执行审计。智能体执行的每一条shell命令都会被记录到日志里包括命令内容、执行时间、退出码。如果发现危险命令比如rm -rf、git push --force会立即终止并通知负责人。第三道是产物diff审查。智能体提交的代码变更会生成diff自动发给审查智能体做第一轮检查然后再发给人工做第二轮。审查智能体的规则库会定期更新把新发现的常见错误加进去。这三道关卡加起来基本能保证智能体在“可控范围”内工作。完全放任智能体自主操作生产环境目前阶段还是不现实的。4. 实操过程与核心环节实现从零搭建一条AI-Native流水线4.1 环境准备与项目初始化假设你现在有一个中等规模的Python项目想把它改造成AI-Native的工作流。第一步是环境准备。先确认基础工具链Node.js 18、Python 3.11、git、uv或pip。然后在项目根目录初始化CLAUDE.md内容可以先从最简单的开始后面逐步补充。接着安装Claude Codenpm install -g anthropic-ai/claude-code。装完后在项目目录运行claude如果能看到交互界面说明环境OK。接下来配置项目的自动化检查工具。我们用的是ruff做格式化和lintmypy做类型检查pytest做测试。这些工具要在CLAUDE.md里写明命令并且在CI流水线里配置好。这样智能体提交代码后CI会自动跑检查不通过就打回。最后是任务队列的搭建。我们用的是最简单的方案一个Git仓库里的tasks/目录每个任务一个JSON文件。需求解析智能体负责往这个目录里写任务卡编码智能体负责读取并执行。这个方案很土但足够用而且所有任务都有版本记录方便追溯。4.2 编写第一个可执行的任务卡任务卡是智能体编排的核心数据结构。下面是一个实际用过的任务卡示例{ task_id: TASK-2024-001, title: 实现用户登录接口的密码强度校验, description: 在src/core/auth.py的validate_password函数中增加密码强度校验逻辑。要求长度至少8位包含至少一个大写字母、一个小写字母、一个数字。不满足时抛出ValueError错误信息要明确指出缺少哪类字符。, allowed_files: [src/core/auth.py, tests/unit/test_auth.py], acceptance_criteria: [ validate_password(Abc12345) 返回True, validate_password(abc12345) 抛出ValueError信息包含大写字母, validate_password(ABC12345) 抛出ValueError信息包含小写字母, validate_password(Abcdefgh) 抛出ValueError信息包含数字, 所有现有测试用例仍然通过 ], constraints: [ 不要修改validate_password的函数签名, 不要引入新的第三方依赖, 错误信息用中文 ] }这个任务卡的关键在于验收标准是可执行的。每一条都能直接翻译成测试用例。智能体写完代码后测试智能体直接按这些标准生成测试并运行通过与否一目了然。4.3 编码智能体的执行流程与参数配置编码智能体收到任务卡后执行流程大致如下读取CLAUDE.md加载项目全局约束。读取任务卡解析任务描述、允许修改的文件、验收标准。读取允许修改的文件当前内容理解现有代码结构。生成代码变更方案写入文件。运行CLAUDE.md中定义的格式化、lint、类型检查命令。运行任务卡中验收标准对应的测试。如果全部通过生成diff并提交如果有失败根据错误信息修复后重试。这个流程里重试次数是个关键参数。我们设置最多重试3次超过3次就标记任务失败转人工处理。实测下来大部分任务在1到2次内能通过少数复杂任务需要3次。如果3次还搞不定说明任务定义本身有问题需要人重新拆解。另一个关键参数是超时时间。每个任务设置15分钟超时防止智能体陷入死循环。超时后自动终止任务标记为“需人工介入”。4.4 测试智能体的用例生成与执行测试智能体的工作分两部分生成测试用例和执行测试。生成测试用例时测试智能体读取任务卡的验收标准把每一条翻译成pytest测试函数。比如“validate_password(Abc12345) 返回True”翻译成def test_validate_password_valid(): assert validate_password(Abc12345) is True执行测试时测试智能体运行pytest -xvs收集结果。如果有失败把失败信息结构化后返回给编码智能体让它修复。这个反馈循环是自动的不需要人介入。这里有个细节测试智能体生成的测试用例要写到tests/unit/目录下并且文件名要符合规范比如test_auth_password.py。这些规范都写在CLAUDE.md里测试智能体启动时会自动加载。4.5 审查智能体的规则配置与误报处理审查智能体的规则库是我们自己维护的目前有三十多条规则分三类代码规范类、安全隐患类、业务逻辑类。代码规范类规则比如“函数长度不超过50行”、“不要用裸except”、“不要用可变对象做默认参数”。安全隐患类规则比如“不要拼接SQL字符串”、“不要用eval”、“不要硬编码密钥”。业务逻辑类规则是项目特有的比如“所有数据库操作必须走repository层”、“所有外部API调用必须加超时”。审查智能体跑完规则后会生成一份报告列出每条违规的文件、行号、规则编号、建议修复方式。这份报告会附在PR描述里方便人工Review时参考。误报是审查智能体最常见的问题。我们的处理方式是每条规则都有一个“忽略列表”如果某条规则在特定文件或特定行上误报就加到忽略列表里。忽略列表也要版本化定期review防止规则被滥用。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 智能体“自作主张”改代码怎么办这是最常见的问题。智能体在修一个bug时可能会顺手“优化”旁边的代码结果引入新问题。我们的应对策略有三层。第一层是任务卡里明确写禁忌。比如“只修改validate_password函数不要动文件里的其他函数”。这条约束会写在任务卡的constraints字段里编码智能体启动时会加载。第二层是文件变更白名单。任务卡里的allowed_files字段限定了允许修改的文件。如果智能体试图修改白名单外的文件pre-commit hook会拦截并报错。第三层是diff审查。即使智能体只改了白名单内的文件diff也会被审查智能体检查。如果发现变更范围超出任务描述审查智能体会标记为“需人工确认”。这三层加起来基本能拦住大部分“自作主张”的行为。但偶尔还是会有漏网的所以人工Review这一关不能省。5.2 测试通过但功能不对验收标准的陷阱有一种情况很隐蔽智能体写的代码通过了所有测试但功能实际上是错的。原因通常是验收标准写得太宽松或者测试用例没有覆盖边界情况。比如任务卡里写“validate_password(Abc12345) 返回True”智能体可能写了一个函数对所有输入都返回True。测试通过了但功能完全不对。解决这个问题的关键是验收标准要包含反例。除了“合法密码返回True”还要有“非法密码抛出异常”的用例。而且反例要覆盖各种边界太短、缺大写、缺小写、缺数字、空字符串、None值。我们的经验是一个任务的验收标准里正例和反例的比例至少是1:3。反例越多智能体越难“蒙混过关”。5.3 智能体陷入死循环的排查思路智能体陷入死循环的表现是反复修改同一个文件每次修改后测试都失败然后继续修改无限循环。这种情况通常是因为任务定义有矛盾或者验收标准无法满足。排查思路是先看智能体的操作日志找到它反复失败的那条测试。然后人工分析这条测试为什么失败。常见原因有验收标准本身写错了、任务依赖的某个模块不存在、环境配置有问题。我们遇到过一次任务卡要求“函数返回一个列表”但验收标准里写的是“函数返回一个元组”。智能体怎么改都通不过因为标准本身是矛盾的。修正标准后任务一次通过。所以任务卡在发给智能体之前最好人工过一遍确认描述、约束、验收标准三者一致。5.4 常见问题速查表问题现象可能原因排查方法解决方案智能体不读CLAUDE.md文件不在项目根目录确认CLAUDE.md路径移到根目录或配置自定义路径智能体修改了白名单外的文件pre-commit hook未生效检查hook配置重新安装hook确认权限测试全部通过但功能不对验收标准太宽松检查反例覆盖补充边界用例智能体反复失败同一测试任务定义矛盾人工分析测试逻辑修正任务卡审查智能体误报太多规则太严格查看误报规则编号加到忽略列表智能体执行超时任务太复杂查看操作日志拆解任务增加超时时间代码格式检查不通过格式化命令未运行检查CLAUDE.md命令在任务卡里加格式化步骤5.5 独家避坑技巧从半年实践中总结的五条经验第一条CLAUDE.md要“活”起来。不要把它当成一次性文档。每次Code Review发现智能体犯新错误就加一条约束。半年下来我们的CLAUDE.md从最初的20行涨到了200多行智能体的犯错率下降了大概70%。第二条任务卡要“小”而“准”。一个任务最好只做一件事。我见过有人把“实现用户注册、登录、找回密码”写成一个任务结果智能体做到一半就乱了。拆成三个任务每个任务单独验收成功率高得多。第三条测试智能体和编码智能体要“背对背”。不要让编码智能体自己写测试因为它会倾向于写“能通过”的测试而不是“能发现问题”的测试。让独立的测试智能体根据验收标准生成测试更客观。第四条审查规则要“渐进式”增加。一开始不要写太多规则否则误报会淹没你。先加最关键的几条比如安全隐患类跑顺了再加代码规范类。我们最初只加了5条规则现在慢慢加到30多条。第五条保留人工Review环节。无论智能体多靠谱人工Review不能省。我们的流程是智能体提交代码 → 自动测试和审查 → 人工Review业务逻辑 → 合并。人工Review只看业务逻辑是否正确不看格式和规范因为那些已经被智能体检查过了。这样人的精力集中在最有价值的地方。6. 从工具到习惯AI-Native SDLC的长期演进6.1 智能体框架的选型对比平台化 vs 自建在搭建AI-Native SDLC的过程中绕不开的一个问题是用平台化的智能体比如Coze、各类低代码智能体平台还是用Python自建智能体平台化智能体的优势是上手快、可视化编排、有现成的插件生态。适合快速验证想法或者团队里没有太多工程资源的情况。但劣势也很明显定制能力有限、数据要过平台、和现有工具链的集成可能不顺畅。自建智能体的优势是灵活、可控、能深度集成到现有工具链里。比如你可以让智能体直接调用内部的CI/CD API、直接读写公司的代码仓库。但劣势是开发成本高需要投入工程资源。我们的选择是混合模式需求解析和任务分发用平台化智能体因为这部分逻辑相对标准编码、测试、审查用自建智能体基于Claude Code因为这部分需要深度操作代码库。这个选择背后的逻辑是离代码越近的环节越需要自建离代码越远的环节越可以用平台。因为代码库是团队的核心资产需要最高的可控性和安全性。6.2 智能体行为审计的落地方法智能体行为审计不是“装个日志工具”就完事了它需要一套完整的机制。我们目前的审计体系包括四个部分操作日志智能体执行的每一条命令、每一次文件读写都记录到日志里。日志格式是结构化的JSON方便后续分析。变更追踪智能体提交的每一次代码变更都关联到具体的任务卡。这样出问题时能追溯到是哪个任务、哪个智能体、哪个环节出的问题。异常告警如果智能体执行了危险命令比如删除文件、强制推送或者修改了白名单外的文件立即触发告警通知负责人。定期审计每周review一次智能体的操作日志看看有没有异常模式。比如某个智能体频繁失败、某个任务反复重试、某条审查规则误报率特别高。这套体系跑下来最大的收获是可观测性。以前智能体是个黑盒出了问题不知道哪里错了。现在每个环节都有记录排查问题的效率高了很多。6.3 团队协作模式的调整与适应AI-Native SDLC不只是工具的变化更是协作模式的变化。我们团队在迁移过程中调整了三个地方。第一是Code Review的重点变了。以前Review要看格式、看规范、看有没有明显的bug。现在这些都被智能体检查过了人工Review只看业务逻辑是否正确、架构设计是否合理。Review的时间缩短了大概一半但要求Review者有更高的业务理解能力。第二是任务拆解成了核心技能。以前工程师的核心技能是写代码现在多了一个把需求拆成智能体可执行的任务卡。这个技能需要理解智能体的能力边界知道什么样的任务它能做好什么样的任务需要人来做。第三是文档的重要性上升了。CLAUDE.md、任务卡、审查规则这些都是“给智能体看的文档”。写得好不好直接影响智能体的表现。我们团队现在有个不成文的规定任何新规范、新流程先写成CLAUDE.md里的约束再推广到人。6.4 后续扩展方向从编码到全链路我们目前把AI-Native SDLC的重点放在编码、测试、审查三个环节。后续计划往两个方向扩展。往前扩展需求分析。让需求解析智能体直接读产品文档自动生成任务卡。这个方向的技术难点在于产品文档通常是自然语言歧义多、隐含假设多。智能体需要能识别歧义并主动提问而不是自己瞎猜。往后扩展运维。让运维智能体监控线上告警自动分析日志定位问题甚至自动修复简单问题。这个方向的风险更高因为直接操作生产环境。我们的计划是先做“只读”的运维智能体只分析不操作等信任度够了再逐步放开写权限。这两个方向都还在探索阶段但思路是一致的把SDLC的每个环节都拆成可被智能体接管的任务单元用CLAUDE.md定义约束用任务卡传递上下文用自动化检查验收结果。这个框架是通用的不限于编码环节。我个人在实际操作中的体会是AI-Native SDLC最大的价值不是“省了多少人力”而是“把隐性知识显性化”。CLAUDE.md逼着团队把规范写下来任务卡逼着团队把需求拆清楚审查规则逼着团队把经验固化下来。这些动作本身就在提升团队的工程能力智能体只是让这个过程更快、更可规模化。最后分享一个小技巧如果你刚开始尝试不要一上来就搞全套。先从一个最小的闭环开始——比如只让Claude Code帮你写单元测试CLAUDE.md里只写测试相关的约束。跑顺了再往编码、审查扩展。每一步都确保“智能体能做好人能验收”再走下一步。这样踩的坑最少团队的接受度也最高。