# 天猫 AI 编码实践四文对照整理 ## 原笔记引用 - [[天猫新品营销技术团队AI编码实战指南（上）]] - [[天猫新品团队AI编码实战指南（下）]] - [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] - [[AI-First产研团队的交付路径]] --- ## 一句话结论 这四篇文章虽然切入点不同，但核心结论高度一致：**AI 编码的上限，不主要取决于模型本身，而取决于团队能否把需求、规范、代码模式、领域知识、任务拆解和验证闭环，组织成 AI 可消费、可复用、可持续更新的工程资产。** --- ## 共同点 ### 1. 都在反复强调：问题核心不是 prompt，而是上下文工程 - [[天猫新品营销技术团队AI编码实战指南（上）]] 强调，AI 写不对、写不好、写不了、改不动，根因大多来自隐性知识、需求模糊、任务复杂、缺少验证和工程结构问题。 - [[AI-First产研团队的交付路径]] 进一步把这件事抽象为“初稿准确率”问题，指出模型差异不是主要矛盾，上下文质量才是。 - [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 则把上下文具体化成四层物料：开发规范、代码模式、领域知识、任务规格。 共同认识是：**AI 不是因为不会写代码才失效，而是因为拿到的上下文不完整、不准确、不可执行。** ### 2. 都主张“最大化复用”，而不是追求从零生成 - [[天猫新品营销技术团队AI编码实战指南（上）]] 把“最大化复用”列为核心方法论。 - [[天猫新品团队AI编码实战指南（下）]] 从代码复用、知识复用、工作流复用、工具复用、人机分工五个层级展开。 - [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 进一步提出“能抄不写，能连不造，能复用不原创”，本质是让 AI 做胶水而不是原创主体。 共识非常明确：**团队真正要建设的不是“更强提示词”，而是可复用的物料体系。** ### 3. 都认为自然语言文档和结构化规格是核心输入接口 - [[天猫新品营销技术团队AI编码实战指南（上）]] 直接提出“自然语言第一”。 - [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 用 `Task Spec` 承载当前需求意图。 - [[AI-First产研团队的交付路径]] 则把 PRD、技术方案、任务拆解都 Skill 化，形成逐级收敛的上下文链路。 - [[天猫新品团队AI编码实战指南（下）]] 还提出“视图分离”，把同一份 PRD 分成人读版和 AI 执行版。 这说明：**文档不是代码的附属物，而是 AI 时代的软件输入层。** ### 4. 都强调必须有验证闭环，不能把 AI 当黑盒执行器 - [[天猫新品营销技术团队AI编码实战指南（上）]] 明确要求补上 review、测试、前后端验证。 - [[AI-First产研团队的交付路径]] 把 Daily Coding Agent 定义成“编码→单测→CR→修复”的循环。 - [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 的目标不是生成代码，而是提升生产可采纳率。 共同点是：**衡量标准不是“写出来了”，而是“能否稳定进入交付流程”。** ### 5. 都在把团队经验沉淀成可版本化资产 - `AGENTS.md` - `spec.md` - 样板代码 - 团队知识库 - Skill / 工作流脚本 - 上下文回写机制 四篇文章都在做同一件事：**把本来只存在于熟手脑子里的隐性经验，外化为 AI 能稳定读取的长期资产。** --- ## 关键差异 ### 1. 关注层级不同 - [[天猫新品营销技术团队AI编码实战指南（上）]] 更偏总论，解释为什么 AI 编码会失败，以及团队应如何补足工程基础设施。 - [[天猫新品团队AI编码实战指南（下）]] 更偏场景化落地，讨论不同业务严苛度下的人机分工与复用策略。 - [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 更聚焦中后台“胶水需求”的高采纳率打法。 - [[AI-First产研团队的交付路径]] 更像组织级方法论，强调交付链路、Skill-as-Code 和上下文持续回写。 ### 2. 对“AI 最适合做什么”的判断重心不同 - [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 最鲜明，认为 AI 最适合做“90%抄 + 10%写”的胶水型工作。 - [[天猫新品营销技术团队AI编码实战指南（上）]] 认为 AI 适合高复用、低歧义、边界清晰的 80% 工作。 - [[天猫新品团队AI编码实战指南（下）]] 则进一步按 C 端、B 端、小二端、工具端区分 AI 的适用边界。 - [[AI-First产研团队的交付路径]] 关注点不在某类代码，而在整个交付链是否能把任务收敛到 AI 可执行粒度。 ### 3. 物料结构的表达方式不同 - [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 是“四层物料体系”。 - [[AI-First产研团队的交付路径]] 是“L0/L1/L2 三层加载 + 六段式交付闭环”。 - [[天猫新品团队AI编码实战指南（下）]] 是“代码/知识/工作流/工具/人机分工”五级复用。 - [[天猫新品营销技术团队AI编码实战指南（上）]] 则是更通用的工程治理视角。 虽然结构不同，但都在回答同一个问题：**该给 AI 什么信息、以什么时机给、给到什么粒度。** ### 4. 适用对象和目标不同 - [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 更像“如何提高业务出码采纳率”。 - [[AI-First产研团队的交付路径]] 更像“如何让整个产研团队围绕 AI 重组交付方式”。 - [[天猫新品团队AI编码实战指南（下）]] 更像“不同业务场景应该怎么设计 AI 工作流”。 - [[天猫新品营销技术团队AI编码实战指南（上）]] 更像“AI 编码问题诊断与总策略”。 --- ## 可以合并出的统一框架 如果把四篇文章压缩成一套统一模型，大致可以整理成下面这条链路： 1. **先显式化需求** 把模糊业务目标转成结构化需求、边界、验收标准。 2. **再补齐静态底座** 提前准备 `AGENTS.md`、代码规范、样板代码、领域术语表、知识库索引。 3. **按任务粒度动态加载上下文** 不全量塞资料，而是按项目级、文件级、任务级逐层注入。 4. **优先让 AI 做复用型工作** 组件拼装、页面搭建、CRUD、接口对接、样板代码延展、文档生成。 5. **复杂任务拆黑盒** 把大任务拆成边界清晰、可独立验证的小任务，降低“改不动”的概率。 6. **以验证闭环替代一次生成幻想** 编码、单测、CR、修复、回写知识，形成迭代闭环。 7. **把过程沉淀为下一轮资产** 当前需求完成后，不只交代码，还更新 spec、知识库、样板和工作流。 这条链路本质上就是：**显式化 -> 结构化 -> 复用化 -> 校验化 -> 资产化。** --- ## 最值得吸收的几个强观点 ### 1. AI 编码的 ROI 关键指标不是速度，而是“初稿准确率 / 采纳率” - [[AI-First产研团队的交付路径]] 强调初稿准确率。 - [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 直接用采纳率来证明方法有效。 这比“生成了多少代码”更接近真实业务价值。 ### 2. 关键规则必须静态在场，不能赌 AI 主动查文档 这个观点在 [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 里特别尖锐：如果规范只放在可检索文档中，AI 可能根本不会主动去看；关键约束应该放进 `AGENTS.md` 或类似的强注入入口。 ### 3. 好的 AI 协作不是减少文档，而是提高文档的执行性 四篇文章都在证明，AI 时代不是“不写文档”，而是要写**更能驱动执行的文档**： - 人看得懂 - AI 也能直接消费 - 能版本管理 - 能逐轮更新 ### 4. AI 更像高效但不稳定的执行者，不是自动化替代品 这也是四篇文章最一致的现实主义立场：**不要神化模型，要工程化地驯化模型。** --- ## 对我自己的可落地启发 ### 适合立即做的事 - 给常做任务建立固定 spec 模板。 - 把仓库中的关键规范上提到 `AGENTS.md` 或固定入口。 - 为高频页面/模块准备“样板代码”而不是只写原则。 - 把易踩坑知识整理成可检索知识库，而不是散落在聊天记录里。 - 每次做完需求后，回写实现经验，让下一次不是从零开始。 ### 需要避免的误区 - 只优化 prompt，不治理仓库结构。 - 把复杂需求整包扔给 AI，不做任务拆分。 - 以“生成速度”代替“可采纳质量”。 - 希望 AI 从零原创一切，而不是基于现有资产复用。 - 做完代码后不回写知识，导致上下文长期失真。 --- ## 适合作为总纲的理解 如果只保留一句总纲，可以是： > **AI 编码不是“让模型替你开发”，而是“把团队的需求表达、代码模式、知识经验和验证流程，重构成模型可稳定执行的交付系统”。**