淘宝天猫海外技术的AI Native研发范式升级实践与思考

AI Native研发范式的三级演进路径

AI Coding近两年拐点式迭代和演进，最初是IDE的代码补全，以行级和函数级建议辅助开发者完成既定思路；随后进入对话式辅助阶段，能解释报错、生成片段、执行局部重构，成为开发者的"副驾驶"；随着大模型的推理能力和上下文窗口持续提升，如今已迈向Agent驱动的自主编码，基于SDD可读取整个代码库、拆解任务、调用终端与测试，并依据反馈反复迭代直至交付可运行、可验证的结果。协作模式由"一问一答"转向"交付一个完整可验证的结果"。

SDD驱动：文档即指令，规格即产物

核心思想：以文档驱动前后端代码生成，覆盖完整的开发流程。先用自然语言把设计规格写清楚，再由 AI 依据规格文档与现有代码库生成新代码；规格即"指令"，代码是规格的产物而非起点。

质量保障：流程化卡点 + 分阶段评审。为约束 AI 行为、确保产出质量，团队通过流程设计在关键节点设置检查点，对 AI 在各阶段的产出准确率进行人工评审与逐步放行。目前完整 SOP 由六个阶段构成：

• ① 项目准备→ ② 需求澄清→ ③ 技术提案生成→ ④ 提案执行→ ⑤ 测试执行→ ⑥完结归档

初步结果：AI Coding 占比已从去年的5%提升至85%，整体交付效率持续提升中。

体感误差：编码提效≠端到端交付提效

事实上，淘海外技术AI生码占比前后端都已85%以上，业务和产品还是感觉一直在排期，大家的提效体感并不是很明显。核心原因就是AI生码率这个指标和端到端的实际交付效率之间存在着一个巨大的鸿沟，个体研发快了，组织交付并没有变快。

从上述数据观测，一个需求从提出到上线完整生命周期中，研发人员写代码的时间只占整个周期的大约20%；也就是说研发Coding的提效在整个交付生命周期中占比太低，比如编码200%的提效也只带来10%的真实提效。大量时间花在需求对焦、PRD编写和评审、技术方案编写和评审等各个环节沟通与拉通对齐，以及研发阶段的联调和测试。

同时结合第二章可知，淘海外整体技术体系是构建在整个手淘技术底座之上的，很多新产品能力建设都依赖主站的底座技术开放度和双方组织协同效率，在此前提下整体研发效率还会有部分折扣。

可见，真正的效率瓶颈隐藏在业产技"需求→PRD→实现→验收"的串行流转过程中。这意味着提效的杠杆点不在单一环节提速，而在于协同模式的根本转变——串行协同升级为并行协同，人写+人审 → AI生成+人决策。

Agent驱动：钉群为中枢的AI执行+人决策新范式

整个范式升级的底层逻辑和基本判断如下：

• 研发效能持续提升关键在于：拉齐业产技工作界面，降低业产技沟通和协同时间；
• ChatBox是迄今被大规模、跨人群、跨场景验证过的AI产品范式，钉钉其实就是最大的ChatBox场景；
• 钉钉当前解决了绝大多数的在线沟通和审批等工作，如果给钉钉安装一个Agent大脑，钉钉可以端到端完成协作和执行。

传统互联网公司的业产技的研发流程是业务提需求->产品出方案->技术做交付。本文核心思路是：以钉群为载体拉齐业产技工作界面，实现业产技一体化完成交付。未来排期的性质发生变化：从研发资源排队，变为风险与依赖排队，因为交付的责任已经拉齐在业产技统一视角；同时，未来所有角色都应该一起为业务价值负责。

Agent驱动的核心解决方案

（1）核心思想：把传统“人驱动”的交付链路，重构为"AI执行 + 人决策"的新范式。

• 一句话触发，分身自动接力：运营用自然语言在钉群发起业务方向，无需写正式文档；产品、技术PM、研发、分析师四类 AI 分身随即自动接力，走完从需求澄清、方案设计、编码交付到数据分析的全链路。
• 真人只在关键卡点把关：全流程收敛出三个真人节点——PRD 人工确认、AI 测试验收、真人终验；分身负责"把事做完"，真人负责"判断做得对不对、能不能上"，人力从执行位彻底解放到决策位。
• 具备明确落地路径：从需求澄清到发布上线，各环节均已明确其背后的 Agent 载体、专属知识库及所依赖的工程能力，全链路均有成熟组件承载，是可工程化交付的实施方案而非概念演示。
• 数据回流形成可迭代闭环：需求上线后业务数据自动回流，分析师分身生成策略建议、驱动下一轮迭代启动，让业务从"一次性交付"进化为"可持续运转"。
• 工程保障贯穿始终：通过协作总线、产出留痕、交叉评审、高风险动作强制卡点等具体措施，确保整套体系可控、可信、安全、可演进。

（2）核心流程：以钉群为中枢，AI执行、人决策为原则，Agent驱动需求→设计→澄清→交付全流程自闭环，业产技以钉群为统一工作界面，一体化端到端完成需求交付；同时群里所有的文档和听记等都可以直接沉淀为领域知识体系，持续迭代和优化交付效率和质量。

具体落地关键路径：① 工作界面统一 ② AI流程驱动协同 ③ 自动化交付验证。

（3）关键路径：

• 通道：钉群作为唯一工作界面和上下文载体，所有的"文档/邮件/会议"等都直接在钉群沉淀；
• 角色：AI负责产出（起草、检索、汇总、编码），人负责决策（澄清、取舍、放行、灰度）；
• 流程：需求→设计→澄清评审 GATE→交付→发布上线 GATE整条链路在项目群执行完成。

（4）达成目标：围绕需求端到端交付效率提升，从结果和过程两层设定目标。

• 结果指标（整体目标的量化，按照需求复杂度分类，更快、更多、守质量底线）：
• 更快——端到端交付周期缩短：小需求（≤5 人日）零研发投入，Agent 端到端交付、当天上线；中大型需求较基线压缩 20%~30%；
• 更多——需求吞吐量提升：团队人数不变下，月度交付需求数较当前提升40%，验证小需求零研发投入后研发容量的释放；
• 质量底线守住：千行代码bug数不劣于当前阶段，线上故障率与回滚率不劣于现有基线；
• 过程指标（衡量范式实际真实落地情况）：
• 范式渗透率：用本范式交付的需求占比，按"单域试点→全域"扩展；一阶段商家供给域小需求渗透率 100%、复杂需求渗透率 50%，后续扩展至全域；
• AI 初稿采纳率：MRD/PRD 由 AI 生成初稿、并在初稿基础上迭代定稿，判定口径为文档版本历史中定稿版本由 AI 初稿迭代演进而非推翻重写，目标 ≥ 80%+，防止绕开 AI 人工重写；
• 澄清评审效率：试点期内建成群埋点自动度量（单需求澄清轮次、各 GATE 节点评审时长自动采集），产出基线并设定下降目标；MRD/PRD 当前仍为人工生成，实现 AI 辅助生成后纳入度量；
• AI Coding 占比：小需求（≤5 人日）由当前约 90% 提升至 99%~100%，接近全自动化交付；中大型需求由当前 60% 提升至 90%。

三大关键能力项落地

工作界面统一

以钉群为载体，集成插件、知识库及数据库能力，实现信息沉淀与初始化 。一项目一群，立项即建群，业务、PD、PM、研发、测试与 AI Agent 全员入群；群消息流、群文件、群卡片自动构成项目记忆；Agent 以群机器人身份与真人对等协作。

AI流程驱动协同

AI 驱动 + 人决策，流程拉回群里

业务、PD、研发在钉群中并行协作，AI Agent 负责澄清需求、生成 MRD/PRD 初稿和技术方案，再把讨论中的取舍与结论自动归档。核心节奏不再是“开会—等文档—再开会”的低频大评审，而是“AI 起草 → 人随手评审 → AI 立即迭代”的高频小循环。实际用下来，群里收敛需求、评方案很顺，真要写复杂代码还是回 IDE 快；为保证效率最优，面对相对复杂的需求时，优先引导开发回到 IDE 编写。

按照需求复杂度划分为两种流程：

• ≤5人日：编码、测试、验收全部在群内完成，AI 直接生成 Diff 与 Test Report，追求一次性成功率。
• >5人日：群内聚焦 MRD/PRD/技术方案评审、上下游协同和进度同步，vibe coding 回到本地 IDE，完成后再回群更新。

统一原则

无论哪种流程，需求推进、产出物和关键决策都留在群内，以卡片消息流转并即时留痕。

自动化交付验证

在 SDD 范式下，PRD 与技术方案不再只是给人读的文档，而是合并成机器可执行的 Spec；AI 自动跑完编码、单测、回归、部署、校验、发布，人只守住方案放行、核心 CR、灰度放行三个 GATE。

按照需求复杂度划分为两种流程：

• ≤5 人日的小需求全程在钉群闭环，不切换环境、不排队；
• >5 人日的大需求把钉群当作流程驾驶舱，vibe coding 与深度测试回归本地 IDE，既保留自动化的快，也保留复杂工程的控。

每一段流水线都挂在客观质量门禁上——单测、Lint、安全、回归、线上指标——异常自动回滚；人工卡点再按风险分级，从 L1 轻量闭环到 L4 完全人工决策，AI 只负责把影响面算清楚，把决策权交还给人。

实践路径与阶段性成果

实践路径

新范式按"场景 → 协同 → 度量"三步逐步铺开，每一步都在真实业务里跑通再放大。

• 试点场景选择：优先在"所见即所得"的简单需求上验证全链路：页面文案/按钮调整、排序规则修改、配置项变更等。这类需求PRD简单、技术方案可枚举、验收门槛低，最容易完成"一句话 → 上线"的群内闭环，跑通后再扩展到中等复杂度的功能需求。
• 群内卡点机制：把"权限校验、风险识别、产出质量"做成 AI 在群内的标准化卡点：每次 Yes/No 放行必须校验确认人身份；初稿生成后AI先做一轮自检（完整性、矛盾点、依赖缺失）再提交人审；高风险变更强制升级为人决策。
• 度量与反馈闭环：每条群链路都埋点记录，阶段耗时、AI 初稿采纳率、人工返工次数、最终交付质量。数据回流到Skill提示词与流程模板，形成“用真实业务跑数据→数据反哺AI能力→能力提升再扩大试点范围”的正向循环，也为后续的数字分身方案提供数据基础。

阶段成果

新范式已在供给、支付和营销三个业务域完成真实项目验证，能力从辅助写代码扩展到需求分析、方案生成、研发执行和项目协同，验证了端到端交付与跨角色协作的可行性。

• 研发交付：供给域小需求已实现从 MRD、PRD、技术方案到编码、部署、测试到发布的群内交付，实践需求AI通过代码分析纠正技术方案，将整体研发估时降低50%；巴拿马等复杂需求则形成“群内协同、IDE研发”的组合模式，支持多模块CR推进、测试用例生成、流水线跟踪和预发问题定位。
• 项目协同：支付域、供给域等业务打通了会议听记、PRD澄清、待办跟进、技术方案和研发交付，会议结论能够直接转化为责任人、截止时间明确的行动项，并继续推进到技术方案、CR和代码交付，实现了进展、风险和待办的持续同步，减少了信息分散和重复对齐。
• 需求分析：营销域在真实需求中完成业务现状梳理、方案可行性判断和上下游影响面分析，并据此生成PRD初稿和交互Demo，使产品、业务和研发能够基于同一份分析结果进行讨论，减少需求前期反复确认。

范式演进与未来方向

AI时代的研发范式以AI参与程度划分为以下L1～L3三个级别，目前淘海外经过一个月的需求交付实践取得初步成果：

• 完成全流程交付论证，业产技各角色拉齐认知，并认可整个协作流程；
• 业产技在沟通和协同全面提效，完全避免因以前的碎片化信息导致的信息差；
• 研发交付范式升级，≤5人日需求从编码、部署和测试均在钉群完成。

从实践效果看小需求基本完成L3级别交付，但大部分需求还停留在L2级别交付。未来的重点是把 L3 从小需求扩展到中大型需求，主要推进四件事：

• 流程规约：以SDD规约为输入，融合 AAIC 的 Skill 托管与调度能力驱动「编码&联调&测试」，把中大型需求中现阶段仍需回到本地IDE的部分逐步演进至自动执行，人工按风险分级只保留必要卡点。
• 文档质量：持续迭代提示词与示例库、沉淀项目与领域知识库，让MRD/PRD/技术方案的AI初稿达到可直接评审定稿的水平，减少推翻重写。
• 工程底座：打磨链路Skill编排、机器人响应耗时与群内卡片交互，补齐每步 Yes/No 的确认人身份校验与跨组织授权。
• 资产迭代：以群内埋点度量各阶段耗时、AI 初稿采纳率与人工返工次数，并将群内信息沉淀数字资产可回流、可追溯、可沉淀，持续丰富和校准知识库。

四件事跑通后，L2与L3的分界才真正落在调度权上：环节流转由流程引擎接管，AI 的自治边界从单环节内扩展到跨环节全程，人只在风险发生时仲裁而不再参与流转。同时衡量口径也从 AI 生码率转向端到端交付周期——交付吞吐不再线性依赖人力规模，而取决于知识库质量、领域 Skill 覆盖度与权限、边界管控的可信度。

JOTO 企业落地观察

• 将钉群作为统一工作界面，本质是把异步协作沉淀为可计算、可回溯的结构化数据资产；这对RAG知识工程提出新要求：需支持群聊上下文、文档版本、决策留痕等非标准文本的实时索引与语义关联。
• Agent驱动的“AI执行+人决策”模式，对AI安全治理构成新挑战：当AI分身自动完成MRD生成、技术方案输出、代码编写与测试报告，需建立覆盖全链路的权限校验、风险分级卡点与行为审计机制，而非仅依赖最终人工终验。
• 从“分身”到“数字员工”的演进，标志着智能体工程重心从单次任务交付转向长期域内自治；这要求企业构建清晰的职责边界定义、跨系统授权体系与异常升级路径，否则易陷入“AI越权”或“人工兜底过载”两难。