天猫新品沉淀AI编码和报错处理流程

淘天团队把 AI 生码痛点归纳为写不对、写不好、写不了、改不动四类，并从项目/需求隐含信息过多、用户输入不精准、任务复杂度高、缺少自检环节、模型与 Agent 差异与能力限制五个维度给出解法，形成三大核心思想：最大化复用（模块优先、胶水编程、工作流复用）、文档先行（PRD 即单测、文档即代码，优先改文档而非代码，实践结论是先给小文档再按 AI 产出偏离情况补充）、二八定律（20% 时间完成 80% 任务，剩下 20% 要 80% 时间，重点在提高前 80% 质量与后 20% 效率）。并沿前置准备、开发前、开发中（新建型/迭代型）、完成后四个节点给出可落地手段，包括项目/团队知识库与 AGENTS.md 规范、组件与流程拆分、过程文档与上下文管理、自检与单测、git 版本管理、问题分析与资产沉淀。量化对比方面，团队按代码供给形态给出出码准确率与人工介入成本：AI 自由发挥 70%（人工介入成本高）、有语料的三方包 80%（人工介入成本低）、私有包+调用规范 95%（人工介入成本低）；报错调试方面，常规报错直接复制给 Agent 自行调试的可解决率为 80%（解决不掉的主要来自三方库内部报错，需要特判）。 针对 C 端逻辑与视觉耦合度太高、AI 天生缺乏视觉感知力，一次性让 AI 写完逻辑代码和视觉代码容易顾此失彼的问题，团队的解法是尽可能把视觉代码与逻辑代码分离：先让 AI 完成逻辑代码部分，再单独完成视觉组件编写，最后用 AI 将逻辑与视觉组件绑定（先假定一个包含属性与事件的抽象组件，再与只负责绑定事件与属性的纯视觉组件结合）。实践案例为页面 Feeds 下新增二级类目配置、商品卡片点击跳转切换到自有中间页并完成视觉更新：团队先梳理隐含知识（什么是自建中间页与商品详情页、后端仓库如何新建 solution 与相关代码规范、前端仓库用什么工具库、Feeds 组件库如何配置）并沉淀为前置文档（建议 AI 生成配合人工修改，采用渐进式披露），再基于知识问答与代码产出技术方案并按模版写入仓库 docs 目录、由人工完整审查（模版含引用文档并声明知识库版本、相关接口、功能点拆解、具体实现方案、问题预警、相关埋点）。执行阶段对视觉部分做视图分离改造：文中举例商卡包含大量逻辑，原先需从 400 行视觉组件里挑出所有逻辑代码，改为让 AI 把组件改造成视图分离结构后，再通过 D2C 产出新的卡片组件并完成状态与事件绑定；视图分离还大幅减少 CR 压力（如购物车组件 CR 时只需重点看主逻辑 index.tsx 的变更）。团队进一步设计了视图分离的组件库，把 tab 渲染等交给调用方做视觉实现并绑定事件，以最大化逻辑复用。 团队在完成一次需求后，会 review 整个实现流程，识别可标准化、重复性强、涉及文件多的流程并沉淀为 Skill（文中定义为「资产化的 AI SOP，包含描述、指令、脚本、模版等内容」）。本篇案例中识别出的可沉淀工作项包括：后端 ald solution 创建，分步修改相应文件；在此基础上做前后端流程串联（solution → 接口文档 → 前端调用函数生成）；前端天马配置项的新增与相应的读取代码生成；逻辑代码生成 → 调用 D2C 工具生成视觉组件 → 进行逻辑与视图的绑定。同时完成组件沉淀（视图分离后业务逻辑组件的可复用度不再受限于视觉稿，剥离业务逻辑的视觉素材可快速应用到各项目）与知识文档迭代（针对 AI 常见偏离补充严格约束，通过运行时及时修正保证文档有效性）。团队给出的经验是：前期生成和调整较费劲，但基本几个中型需求认真跑下来的沉淀即可覆盖很多日常开发内容，当日常开发场景枚举到 80% 以后，AI 会越来越可控。