63 lines
5.0 KiB
Markdown
63 lines
5.0 KiB
Markdown
# 97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】
|
||
|
||
> 来源：[微信公众平台](https://mp.weixin.qq.com/s/G3aKbzdGUyD2h1aVjvbr2g)
|
||
> 作者：天猫品牌行业前端 / 大淘宝技术
|
||
> 日期：2026年3月27日
|
||
|
||
## 摘要
|
||
|
||
本文分享了天猫团队在"胶水编程"场景下的最佳实践，即利用AI高效连接现有业务模块以快速响应需求，实现了高达97.9%的代码采纳率。文章指出，针对业务逻辑组装、接口对接及样板代码填充等"胶水"型任务，通过构建精准的上下文提示策略和标准化的开发流程，能极大发挥AI在理解业务意图和组合代码片段上的优势，显著缩短从需求到上线的周期。
|
||
|
||
---
|
||
|
||
## 核心认知：别让AI写代码，让它抄代码
|
||
|
||
试点业务域半年前采纳率 50%——不是AI写不出代码，而是写出来的代码不可控：组件乱用、规范不守、已知的坑反复踩。
|
||
|
||
**核心认知：** 把团队已有的开发规范、代码模式、领域知识喂给 Agent，让它组装而非创作——这套方法叫"**胶水编程**"。**SPEC 管意图，物料管执行**，两者叠加才是完整的可控编码。
|
||
|
||
## 核心理念：AI不应该"写(SPEC)"代码，而应该"抄(GLUE)"代码
|
||
|
||
中后台业务绝大部分需求以 CRUD 为基础——列表页、表单页、详情页、导入导出，场景高度相似。90%的代码本来就有现成的参照。
|
||
|
||
> **胶水编程不是在限制 AI，而是在顺应它的能力结构——让AI做拟合的事。能抄不写，能连不造，能复用不原创。**
|
||
> Agent 的工作不是从零创作，而是从内部物料中组装出新的交付，只在业务差异点写最少量的"胶水代码"——**90%抄，10%写**，胶水只在缝隙处。
|
||
|
||
## AI编码可控性的三个递进层次
|
||
|
||
1. **Vibe Coding** → 解决"能不能用AI写代码"。用自然语言描述需求，AI直接生成代码。产出完全不可控，不可能直接合入生产仓库。
|
||
2. **SPEC Coding** → 解决"AI写的代码对不对"。用结构化的技术方案约束AI行为。但管不到具体实现——Agent知道要写列一页，但不知道团队列表页长什么样。
|
||
3. **Glue Coding** → 解决"AI写的代码像不像我们的"。在SPEC基础上，给Agent三样东西：**开发规范（规矩）、代码模式（骨架）、领域知识（经验）**。产出的代码风格统一、组件正确、CR一次通过。
|
||
|
||
> **Vibe让AI能写代码，SPEC让AI写对代码，Glue让AI写出"你的"代码。**
|
||
|
||
## 四层物料体系
|
||
|
||
Agent写代码时背后有四个彼此独立的决策，每一层物料恰好堵一个漏洞：
|
||
|
||
| 物料层 | 加载方式 | 技术机制 | 触发时机 |
|
||
|--------|----------|----------|----------|
|
||
| **开发规范** | 静态注入 | 云端配置→AGENTS.md→注入system prompt | 打开仓库时自动加载 |
|
||
| **代码模式** | 静态注入 | 样板间代码文件通过提示词引用注入Agent上下文 | 打开仓库时自动加载 |
|
||
| **领域知识** | 动态检索 | Agent通过MCP协议调用Knowledge Server按需检索 | 编码过程中按需触发 |
|
||
| **任务规格** | 动态生成 | 开发者选择SPEC模板→填写→生成spec.md作为初始上下文 | 每次需求启动时生成 |
|
||
|
||
**为什么开发规范必须静态加载？** 56%的场景中AI根本不会主动调用文档工具；将同样内容直接写入AGENTS.md静态加载后，通过率从53%提升到100%。**关键规则必须始终在场**，不能依赖AI的主动调用。
|
||
|
||
**为什么不能全量塞进去？** Anthropic上下文工程博客："一个精准的300 token上下文，往往胜过一个混杂的113,000 token上下文。" 上下文越长，安全特性实现反而下降了47%。
|
||
|
||
## 这个转变意味着什么
|
||
|
||
- **投资方向变了**：核心投资不再是prompt工程或等待更强的模型，而是建设内部物料体系（让单次交付可控）和需求规格的持久化管理（让长期迭代可控）。
|
||
- **质量标准变了**：好的AI编码不是"生成了多少代码"，而是"原创了多少代码"——在可标准化的部分，**原创越少，说明物料体系越完善**，产出越可控。
|
||
- **团队资产观变了**：已有项目代码是可复用的样板间资产，已完成的需求规格是后续需求的决策上下文——每一次交付都在积累物料和上下文，形成**复利效应**。
|
||
|
||
## 关键设计原则
|
||
|
||
- **开发规范**（AGENTS.md）：仓库级别的编码约束，是写代码的底线。定义不可逾越的约束，而非可选的建议。
|
||
- **代码模式**（样板间代码）：具体的、经过评审的已有实现文件，作为Agent的"抄写范本"。
|
||
- **领域知识**（Knowledge Server）：通过MCP协议提供的内部组件坑点、接口注意事项等长效知识点。
|
||
- **Task Spec**（任务规格）：当前需求的完整上下文描述。
|
||
|
||
> 相关阅读：《Spec Coding 不是银弹》（内部文章）——SPEC编码的三个结构性局限：AI缺乏真正的理解能力、规范无法完整描述系统、规范比代码更难维护。
|