97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】

来源：微信公众平台作者：天猫品牌行业前端 / 大淘宝技术日期：2026年3月27日

摘要

本文分享了天猫团队在"胶水编程"场景下的最佳实践，即利用AI高效连接现有业务模块以快速响应需求，实现了高达97.9%的代码采纳率。文章指出，针对业务逻辑组装、接口对接及样板代码填充等"胶水"型任务，通过构建精准的上下文提示策略和标准化的开发流程，能极大发挥AI在理解业务意图和组合代码片段上的优势，显著缩短从需求到上线的周期。

核心认知：别让AI写代码，让它抄代码

试点业务域半年前采纳率 50%——不是AI写不出代码，而是写出来的代码不可控：组件乱用、规范不守、已知的坑反复踩。

核心认知： 把团队已有的开发规范、代码模式、领域知识喂给 Agent，让它组装而非创作——这套方法叫"胶水编程"。SPEC 管意图，物料管执行，两者叠加才是完整的可控编码。

核心理念：AI不应该"写(SPEC)"代码，而应该"抄(GLUE)"代码

中后台业务绝大部分需求以 CRUD 为基础——列表页、表单页、详情页、导入导出，场景高度相似。90%的代码本来就有现成的参照。

胶水编程不是在限制 AI，而是在顺应它的能力结构——让AI做拟合的事。能抄不写，能连不造，能复用不原创。 Agent 的工作不是从零创作，而是从内部物料中组装出新的交付，只在业务差异点写最少量的"胶水代码"——90%抄，10%写，胶水只在缝隙处。

AI编码可控性的三个递进层次

Vibe Coding → 解决"能不能用AI写代码"。用自然语言描述需求，AI直接生成代码。产出完全不可控，不可能直接合入生产仓库。
SPEC Coding → 解决"AI写的代码对不对"。用结构化的技术方案约束AI行为。但管不到具体实现——Agent知道要写列一页，但不知道团队列表页长什么样。
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缺乏真正的理解能力、规范无法完整描述系统、规范比代码更难维护。

5.0 KiB Raw Blame History Unescape Escape