9.3 KiB
天猫 AI 编码实践四文对照整理
原笔记引用
一句话结论
这四篇文章虽然切入点不同，但核心结论高度一致：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.mdspec.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 编码问题诊断与总策略”。
可以合并出的统一框架
如果把四篇文章压缩成一套统一模型，大致可以整理成下面这条链路：
-
先显式化需求 把模糊业务目标转成结构化需求、边界、验收标准。
-
再补齐静态底座 提前准备
AGENTS.md、代码规范、样板代码、领域术语表、知识库索引。 -
按任务粒度动态加载上下文 不全量塞资料，而是按项目级、文件级、任务级逐层注入。
-
优先让 AI 做复用型工作 组件拼装、页面搭建、CRUD、接口对接、样板代码延展、文档生成。
-
复杂任务拆黑盒 把大任务拆成边界清晰、可独立验证的小任务，降低“改不动”的概率。
-
以验证闭环替代一次生成幻想 编码、单测、CR、修复、回写知识，形成迭代闭环。
-
把过程沉淀为下一轮资产 当前需求完成后，不只交代码，还更新 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 编码不是“让模型替你开发”，而是“把团队的需求表达、代码模式、知识经验和验证流程，重构成模型可稳定执行的交付系统”。