183 lines
9.3 KiB
Markdown
183 lines
9.3 KiB
Markdown
# 天猫 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 编码不是“让模型替你开发”，而是“把团队的需求表达、代码模式、知识经验和验证流程，重构成模型可稳定执行的交付系统”。**
|
||
|