--- sha256: d12eedf2ee13cae4631ac4f8e5fdb7354ea59a8a8118edad5b74a5576a77ff32 title: "天猫新品营销技术团队AI编码实战指南（上）" type: source tags: [mlops, wechat, ai-agent, engineering, agent-tools] source: wechat source_url: "https://mp.weixi" ingested: 2026-05-16 fetcher: wechat-mp-rss --- --- source: wechat source_url: https://mp.weixin.qq.com/s/cMEwc2l9-MhI_asvL-AkxA ingested: 2026-05-16 feed_name: 大淘宝技术 wechat_mp_fakeid: MP_WXS_3014106999 source_published: 2026-05-06 --- # 天猫新品营销技术团队AI编码实战指南（上） 本 ⽂ 是 关于 A I 辅 助 编 码的全⾯实战指南 ， 基于天猫新品 团 队的实践 经 验 ， 从问题 本 质到解决⽅ 案 ， 从理论 框架 到实战 案 例 ， 系统 性 地 介 绍 如何让 A I 更 好 地 完成⼤ 部 分需求。 本文分上下两篇，上篇包含： 1\. 现 状 与 问题诊 断 \- 深 ⼊剖 析 AI ⽣码的 四 ⼤痛点 （ 写 不 对 、 写 不 好 、 写 不 了 、 改 不动 ）， 并从项⽬知识 、 ⽤户 输 ⼊ 、 任务复 杂 度 、 ⾃检 机 制 、 模 型 能⼒等五 个 维 度提供针对性解 法。 2\. ⽅ 法 论 与 优化 思 路 \- 提出 " 最 ⼤化复⽤ 、 ⾃然语⾔第 ⼀ 、 ⼆⼋定律 " 三 ⼤ 核 ⼼思想 ， 并 沿 着 " 前 置 准备 → 开发前 → 开发中 → 完成后 " 的全 流 程 ， 给 出每 个 节点的可落 地 优化⼿段。 3\. 分 场景 实 战案 例 \- 根 据验收 标 准和代码质量要求 ， 将需求分为 " 需求驱动 型 " 和 " ⼯程主导 型 " 两 类 ， 通过 ⼩⼆端列表⻚和 C 端复 杂 业 务的完整 案 例 ， 展示 不 同 场景 下 的 最 佳实践。 下篇包含： 4\. 团 队 建 设 经 验 \- 分享新品 团 队 在 ⼩⼆端 （ 后端全 栈 化 ） 和 C 端 （ 视 图 分离 、 知识库建设 、 ⼯作 流沉淀 ）两个 ⽅向的探 索 ， 包括⼯具建设 、 ⽂ 档沉淀、 知识库⽅ 案 等具体落 地 内容。 5\. 实⽤ 技 巧集 锦 \- 涵 盖 UI 重 构、 复 杂 Prompt 构 建 、 数据 转 换 、 多⽅ 案选 优 、 ⽂ 档 ⽣成 等常⻅应⽤ 场景 ， 以及 严 厉语⽓ 、 合理质疑等提升准确度的技巧。 AI⽣码现状 ▐ ** ** 当前 AI ⽣码的主要问 题 ** ** ** 写 ** ** 不 ** ** 对： ** ** AI ** 没有 完全按照⽤户意 图 完 成功能 ， 轻 则存 在缺 陷 ， 重则⽆ 法运 ⾏ | ** 写不好： ** ** AI产出的代码不符合要求，包括但不限于代码质量/代码风格/实现方案 ** ---|--- 写不了 项目隐含逻辑太多，文件结构复杂，耦合度高，AI完全无法按预期完成任务 （如一些内部SDK工具库，使用说明都在外部文档，AI 无法直接通过代码理解如何使用，自然无法写出对应的使用代码） | 改不动 在某些迭代场景中，AI一直无法输出正确结果，在错误中不断循环，甚至还可能改坏其他部分，此时只能人工介入 而介入后，想要完成修改则需要面对AI短时间内生成的大量代码，反而导致效率下降，使用者完全丧失了对项目的把控 ▐ ** ** 导 致 问题的主要 因素 与 解 法 1\. 项⽬ / 需求 隐 含 信息 过 多 （ AI 不 知 道 ） 由于⼤家 都是淘 内私 有 项⽬ ， 代码中 不 仅包含了 专 属的 业 务 逻辑 ， 还有来 ⾃ 四 ⾯⼋⽅的 SDK⼯具库代码 ， ⾯对⽆处获取的项⽬知识 ， 即使 是 Cluade 40 来 了也⽆ 济 于 事。 解 法 ： * 使⽤ 有明 确声 明 的 NPM 包 ， 或者 给 其接 ⼊ Artifact7 等 辅 助⽂ 档 ⽣成⼯ 具； * 提供可访问的外 部 知识库 ， 包括但 不 限于 MCP ⼯具 / 项⽬知识库 / 需求⽂ 档。 2\. ⽤ 户输 ⼊ 不 精 准 ， 必要信息 不 ⾜ （ 没给 AI 说 ） 代码开发就 是 从模 糊 的需求 转 向⽆歧义的代码 ， 模 糊部 分 在 实现中必然会被补 充 ， 实现 不 合 预 期 的 ⼀ ⼤原 因 就 是 模 糊部 分 没有明 确说 明。 解 法 ： * ⽤ 户 主动增加 输 ⼊内容 / 辅 助⼯具提 升输 ⼊质 量 * 对 ⼀ 些常⻅的情况提供 prompt 模版 ， 使⽤ 时根 据实际需求作 部 分修 改； * 借⽤⼯具 进 ⾏⽤户 输 ⼊扩写 ， 以及对必要的模 糊部 分 进 ⾏ 标 记 与 阐 明； * 引⼊ Spec Coding ⽅ 案 ， 以详 细 的⽂ 档 作为 AI 输 ⼊； * 对⾼频 场景 做出 约 定 ， 通过约 定 来 覆盖模 糊 （ 如 维 护 ⼀ 份持 续更 新的 AGENT.md ）。 * 意图 识别 ， 基于项⽬ 上下 ⽂ ⾃ 动推 测 模 糊部 分 * 接⼊ MCP ⼯具 ， 扩⼤ AI 感知⼒ ， 使 AI 能 更 好 地 理解⽤户意 图； * 通过 代码 索 引 / 项⽬⽂ 档 / CodeWiki 等 辅 助⼿段 ， 使 AI 可以基于项⽬代码快 速 仿写 与 推测。 > 这⾥存在⼀个关于⽂档详细程度的权衡点：到底是使⽤⼤⽽全的⽂档，还是⼩⽽精。 > > 经过实践，最适合的⽅案应该是先给出⼀个可以基本描述清楚需求的⼩⽂档，再根据AI实际产出的偏离情况来进⾏问题补充，因为⼤部分都是⼏个重复出现的常⻅问题（前提是保持⼯具和模型尽可能不变），进⾏⼏次补充以后就可以完成⼀份精准好⽤的输⼊⽂档。 3\. 任务复 杂 度 ⾼ AI ⽣码的成功率会随着任务复 杂 度的提升⽽ 在某 个 节点开始骤降 ， 此 时 则需要 通过 合 适 的⼿段降低任务的难度 ， 最 ⼤化 AI 的⽣码成功率 ， ⽽降低复 杂 度主要 有 以 下两个 ⻆度。 * 降低任务复 杂 度 * 识别 重 复的⼯作 流 与 代码 ， 进 ⾏针对性优化 与 封装复⽤ ， 从⽽减少⽣码的代码量 与 不确定 性； * 复 杂 任务拆分 ， 将单 个不 易测 试的⼤ 型 任务 ， 拆成多 个 可验收的⼩ 型 ⿊ 盒； * 固 定实现思路 / 细 节 ， 统 ⼀ 思 维 模 型 ， 通过约 定 来 减少 思 维 / 选型 负 担。 * 降低⼯ 程 复 杂 度 （ ⽂件 量 、 耦 合 度 ） * 借助优秀的⼯程 结构 设计 ， 实现 代码 / 模 块 / ⽂件 的天然解耦 （ 很多⽣码问题其实 归 类 到底 都 会⾛到基础的代码⼯程化问题 ， 具 有 优秀⼯程 结构 的仓库天然就 有较 ⾼的 AI ⽣成成功率 ）； * 通过 代码 索 引 / 项⽬⽂ 档 / CodeWiki 等 辅 助⼿段 ， 提⾼ AI 检 索 效率 ， 减少 因 检 索困 难⽽新增的⽆⽤ 上下 ⽂。 4\. 缺 少 ⾃ 检环 节 现 在 的常规⽣码 流 程 ， 只会 进 ⾏基础的代码规范 与 语 法 检 测 ， 并 没有 完整的 Review & T est 的 流 程 。 此 时 的 AI 只 是 完成了代码⽣成 ， 并 不⼀ 定完成了任务 ， 也 不⼀ 定满⾜实际的代码质量要求。 * 代码质 量 ⾃ 检 * 在本地 引⼊⾃检 流 程 ， 及 时 完成代码质量确 认； * 使⽤ Code 平台的 AI CR 助 ⼿ 进 ⾏发布前预检 ， 可以⾃定义 CR 规 则。 * 功 能⾃ 检 * 前端可以 通过 接⼊ MCP 的⽅式让 AI 可以感知前端⻚⾯ ， 从⽽ 进 ⾏ 部 分功能 测 试； * 后端可以 通过 单 测 直接 查 看功能正确 性； * 对于⽆ 法测 试的⼤ 型 任务 ， 可以拆分到多 个 易 于验收的 ⿊ 盒 （ 如前端 进 ⾏视 图 分离 ， 对 逻辑 hooks 部 分 进 ⾏单元 测 试 ）。 5\. 模 型 / Agent 的差异 与 能 ⼒限 制 模 型 的 不 同 / 编 码⼯具的 不 同 ， 都 会影响⽣成 结果 ， 即使 是 同 ⼀个 模 型 ， 也会 因 为模 型 的随 机 性⽽产⽣ 不 同的 结果。 要将 AI ⽣码 运 ⽤ 在 ⼯程中 ，不 仅需要⾯对模 型 的短 板 ， 还 需要对抗 模 型 的随 机 性。 * 上下 ⽂窗⼝ 有 限 * 留存 过 程⽂ 档 ， 实现 上下 ⽂复⽤ ， 跳 过 收集环 节 * 代码 上下 ⽂ ： 仓库信息 、 接⼝信 息 * 项⽬ 上下 ⽂ ： PRD 、 功能⽂ 档 * 提供 更精 准的 上下 ⽂ ， 尽量 不 让 AI 靠⽂件猜 测 * 通过 ⼀ 些⽤户 Rule 监控 注 意⼒状态 （ ⽐如 ： 让 AI 每次对话 结束都 要⽤谢谢 结 尾 ， 如 果没有 则说 明 上下 ⽂窗⼝已 经 爆了 ） * 随 机 性 / 模 型 差异 导致⽣成内容的质量 不 稳 定 * 提供更 严 格 的 约束 ⽂ 档 / Spec Coding ⽅ 案 * 补 充 ⾃检环 节 * 修改 型 问题错误率 ⾼ * 修改 型 问题相当于 上下 ⽂ 更 多 ， 正确率要求 更 ⾼ 的⽣码任务 ， ⽽ AI 理解⼒弱 ， 所以修改 型 任务准确率 更 低 ， 这 就 是 ⼤家 最 常提到的 改 不 动 的问题 。 对于 这 个 问题 ， 主要的 解 法 就 是 ⽤前⽂提到的办 法 去降低任务复 杂 度 ： 减少 AI 理解代码的难度 或者 降低⽣码任务体量 * 天⽣对 某 些问题能⼒弱 ， 容 易 卡 在 死循环 ⾥ * 识别常⻅错误 场景 ， By Case 分 析 积 累经 验 ， 沉淀 对应的解 法 核⼼⽅法论与全流程优化指南 这部 分主要介 绍 提⾼ AI ⽣码效 果 的 ⼀ 些 核 ⼼思路 ， 并基于⽣码 流 程中的各 个 节点 给 出 ⼀ 些可 以实施的优化⼿段。 ▐ ** ** 核 ⼼思 想 * 最 ⼤化复 ⽤ ⽆论 是 ⼈⼯ 编 码 还是 AI 编 码 ， 最有 效率的提效⽅ 案 就 是 提⾼代码的复⽤度 。 在 AI 编 码的背 景 下， 通过 复⽤ 还 可以 提⾼⽣码任务的确定性 ， 极 ⼤降低任务复 杂 度 ， 提⾼对代码的掌控度 ， 保证⽣成 结果 的质量。 模块优先 将每 ⼀ 部 分的开发 都 视为 ⼀个 明 确 输 ⼊ 输 出的 标 准可复⽤模 块 （ 可信任的 ⿊ 盒 ），且 所 有相关声 明 可以 通过明 确的路径访问获取 ， 每 个 功 能 都是具有清晰边 界 的库 ， AI 可 以很 ⾃ 然地从代码中获 取 所 需 知 识。 （ 现 在 的 AI ⼯具已 经 具备了很强的信息获取功能 与 推理能⼒ ） 胶 ⽔ 编 程 优先使 ⽤ 已 有模块 ，不 要 ⾃ ⼰ 造轮 ⼦ ， 通过最 ⼩量的 “ 胶⽔代码 ” 将它们 组 合成完整 系统 ， 你的代码只负责 ： 组 合 、 调⽤ 、 封装 、适配。 从⽽ 在 使⽤ AI 完成⼤ 部 分代码的同 时 ， 仍然保留项⽬掌控 度。 ⼯作 流 复 ⽤ 对于 ⼀ 些 可 标 准化 / 重复性强 / 复 杂 度⾼ 的⼯作 流 程 ， 可以及 时沉淀 到 标 准的 AI ⼯作 流（ 包括但 不 限于 ⽂ 档、 MCP 、 Skill ）， 进 ⼀ 步扩⼤⼯作中的可复⽤范 围。 * ⽂ 档 先 ⾏ ⽂ 档是 AI Coding 的第 ⼀ 要 素 ， PRD 即单 测 ， ⽂ 档 即代码 ， 优先修改⽂ 档 ⽽ 不 是 代码 ， 这 部 分⽂ 档 并 不 要求⼤⽽全 ， 重点是 对⼤ 致 ⽅ 向 的描 述 ，与 部 分 易混淆部 分的详 细 说 明。 基于 Spec-kit 的模 型 ， 理想状态 下 是有 ⼀ 份可以和代码 100% 互相 转 换的⽂ 档 ， 但 是 现 在 实 测 下 来 很难 达 到 这 种理想状态 （ 没有 可以完 美 描 述 项⽬的⽂ 档 ， ⽂ 档 也 没法 恰好 转 换到 代码 ）， 最 好的策略 还是 够⽤就⾏。 * ⼆⼋定 律 * 认 清 AI 的 28 定律 ， 20 % 时 间可以完成 80 % 的任务 ， 但 是 剩下 的 20 % 要 80 % 的 时 间； * 0% → 80% （蜜⽉期） ： 从 零 开始 ⽣ 成 新 功 能 ⾮ 常快 ， AI 对 全 新 的 、 独⽴ 的 逻辑处 理 得 极 其 完 美； * 80% → 100% （深⽔ 区 ） ： 当 功 能 需 要 收 尾 ， 涉及 到 复杂 的 上下 ⽂ 、 边缘 Case 修 复 、 以 及 与 旧 逻辑 的 耦 合时 ， AI 的 表现 会断 崖 式 下 跌 ， 常常 需 要 ⼈ ⼯ 介 ⼊； * 提 ⾼ AI ⽣ 成 效 率 的重 点 ， 1 是 提 ⾼前 80% 的 质 量 ， 2 是 提 ⾼ 后 20% 的 效 率。 ▐ ** 全 ** 流程 节点 ⼀ 次 AI Coding 的执⾏ 流 程⼤概可以概括为 ： 理解⽤户意 图 > 查 找 上下 ⽂ > 设计执⾏⽅ 案 >代码⽣成 > 简单 校 验 。 由于 LLM 的随 机 性 ， 每 ⼀个 执⾏环节 都 包含着⽆限的可能 ， ⽽掌控 AI⽣码 ， 就 是在 每 个 环节 都进 ⾏ 明 确声 明 与 介⼊ ， 从⽽保障 AI 按照⾃⼰的预 期进 ⾏产 出。 以 下 是 从每 个 节点 进 ⾏拆分 ， 关于 AI 编 程 流 的每 个 部 分 ， 我们 有 什么⼿段可以 进 ⾏优 化。 > 这部分主要是基于每个节点进行优化方案讲解，并不代表实际需要严格按照这个步骤进行流程拆分，按需选用即可，具体实践中的取舍和选型在后面的实战案例中会详细说明。 * 前 置 准 备 * 准备项⽬ / 团 队知识库 ， 提供公共 组 件 API ，业 务知识 ， 包括但 不 限于 mcp / 知识库 / ⽂ 档 * 确定基础的代码实现规范 ， 约束 代码⻛ 格 ， 通 常命名 README.md / AGENTS.md 放 在 根⽬录 ， 如 果 AI 没有 读取则指 明 （ 通过 rules 或者⼿动 添 加 上下 ⽂ ） * 以尽可能 明 确 、 解耦的形式 ， 设计仓库的⽬录 结构 与 实现⽅ 案 * 对于⽂件引⽤层级多的情况，AI出码的正确率显著 下 降 （⼀ 部 分 是因 为前端属于弱 类 型 语⾔ ） * 对于更加复杂的项⽬，可以尝试使⽤⼀些更进⼀步的视图分离与状态管理等⽅案进⾏提前解耦。 * 开 发 前 明 确需求内容 （ 代码⽆关 ） 产品开发就 是 从模 糊 的⽂ 档转 向代码 ， ⽽代码 是 ⽆歧义的 ， 模 糊部 分 在 实现中必然会被 补充 ， 实现 不 合预 期 的 ⼀ ⼤原 因 就 是 模 糊部 分 没有明 确说 明。 * 对于 不 明 确的情况 ， 可以使⽤ ⼀ 些 辅 助⼯具或者基础模版 进 ⾏ 标 准化 prd 的产出 ， 并 根 据 需求 进 ⾏修改； * 需求 明 确 部 分 ， 不 建议 涉 及具体实现 ， ⽬前的 AI 编 码能⼒已 经 ⾜够强⼤ ， 重点说 明 功能需 求即可 ， 明 确的功能⽂ 档 ⾜以让 AI 设计出合 适 的⽅ 案 ， 提前 涉 及实现 不 仅影响需求说明 ， 也会限制 AI 的发 挥； * 如 果 需要 进 ⼀ 步 明 确各 部 分功能点 ， 可以 通过 spec ⼯具 转 换成 近 似单元 测 试的功能⽂ 档 ， 必要 时 将其 转 化成实际单元 测 试。 任务设计 与 拆 分 如 果 单次实现 过 于复 杂 ， 会 丢 失对代码的掌控度 ； ⽽如 果 单次任务体量太⼤ ， AI 容 易在 执⾏ 过 程中 丢 失 上下 ⽂ 与 注 意⼒。 * 组 件拆分 ： 将 ⼀个 复 杂、 验收卡⼝ 严 格 但⽆ 法 直接 测 试 、涉 及模 块 多 、迭 代频率⾼的⼤ 规模任务 ， 拆分到 多 个 简单 、迭 代频率低 、 可 测 试的 ⿊ 盒 ， 并 进 ⾏ 组 装。 * 流 程拆分 ： 将复 杂 任务 进 ⾏分步拆解 ， 并 通过清 单⽂ 档 记录完成情 况。 * 开 发 中 （ 新建 型 需求 ） * 创建并持 续迭 代 过 程⽂ 档 ， 如⻚⾯ README ， 组 件说 明 ， 从⽽保障每次对话 时 AI 可以快 速 获取信息 ， 避 免 AI 读取 过 多⽂件。 （ AI 每次新对话 都 需要花费⼤量 token 在 读取 与 需求⽆关的前 置 上下 ⽂ ） * 及 时 管理 上下 ⽂窗⼝ ， 确保 AI 没有 失去 专 注 度 （ ⽐如让 AI 每次执⾏完重 述 基础原则 ） * 尽可能使⽤ 严 格 解耦的 架构 设计 ， 防⽌留 下 技 术 债 * 引⼊⾃检 机 制 ， 保障功能 与 质 量 * 让AI ⾃⾏ 添 加调试点位 ， 通过 调试信息修改问 题 * 对 ⿊ 盒 组 件 / 功能 创建单元 测 试 * 通过 MCP ⼯具 进 ⾏⻚⾯ 测 试 * 使⽤ AI 单独 进 ⾏代码质量 Review 环 节 * 对于 部 分持 续 失败的 场 景 * 尝试修改⽤户 输 ⼊ ， 提供 更精 确的 上下 ⽂ ， 或者向 AI 提供⽅向指 引 * 让 AI 在 修改代码前先 输 出⽅ 案 并审 阅 * 收集到 案 例中 进 ⾏ By Case 分 析 常见陷阱：在一次会话中进行大量任务，这会导致上下文太长太宽泛，模型注意力丢失。 * 对于独立的任务，应该及时新建对话 * 对于大型任务，应该及时生成各类过程文档，当模型成功率显著降低时切换对话并传入过程文档恢复上下文 * 开 发 中 （ 迭 代 型 需求 ） 常⻅问题 ： 场 景 | 发 ⽣ 了什 么 | 后 果 ---|---|--- 改 ⼀个 功能 ， 坏 了另 ⼀个 | 添 加删除功能 时 ，不 ⼩⼼影响 了 添 加功能 | 花 时 间排 查 ， 可能越改越 乱 想 回 到 " 昨 天 那 个 版 本 " | 昨 天的代码能⽤ ， 今天改了 ⼀ 堆 ， 全 坏 了 | 找 不 到 昨 天的版 本 试了 三 种⽅ 案 ， 想 回 到第 ⼀ 种 | 第 ⼀ 种⽅ 案 其实 最 好 ， 但已 经 被覆盖了 | 要么重写 ， 要么将 就 AI 改了 不 该改的 地 ⽅ | 让 AI 改 ⼀个 ⽂件 ， 它顺⼿改了 其他⽂件 | 不 知 道哪 些被改 了 相较于新建型任务，迭代时成功率更低的原因主要是：AI天生重模仿而弱理解，新建型任务侧重于模型对代码的仿写能力，而迭代型任务要求AI理解代码且精准修改，所以成功率更低。 * 注意及时约束 ， 防⽌ AI ⽬ 标 漂 移 Bad Case ❌ "帮我优化这个函数"（结果 AI 重构了整个类） | Good Case ✅ 只优化函数 calculateTotal，不做任何其他的变更，集中于此函数一点 ---|--- * 尽量传⼊精准的上下⽂ ， 减少 AI 搜 索 范 围 Bad Case ❌ 帮我修改现在的弹窗样式，和其他页面的统一 | Good Case ✅ 帮我修改pages/GoodsManagement/drawer.tsx 下的弹窗样式，参考pages/Warehouse/GoodsDetAIl/drawer.tsx 目前主流工具都可以添加上下文，不用自己写path ---|--- * 对于复杂迭代， 最 好及 时通过 git 进 ⾏版 本 管理 ， 因 为符合需求的代码可能 在 前⼏ 个 ⼩ 时 ， 甚⾄前 ⼀ 天的 某 个 版 本 （ 多⽅ 案 对⽐⽤分⽀ / 版 本 管理⽤ commit ） * 进⼀步的迭代成功率，主要依赖于仓库架构的解耦程度 ， 改 不 动 时 就要依靠 极 致性的解 耦 * ⼈⼯必须介⼊ 时 ， 可以采⽤⼈⼯提供⽅ 案 ， AI 执⾏改动的半⾃动⽅ 案 节省 时 间 （ 如 ： 我要移除 这 个 函数中硬 编 码的 业 务 逻辑 ， 将其改成外 部 传参 ， 并 在 改好后同步修改所 有 调⽤了 这 个 函数的代码 ） * 实 在 ⽆ 法继续迭 代 时 ， 借助已 有 的功能⽂ 档进 ⾏整体代码重 构 （ 如 果没有 ， 可以尝试让 AI 根 据⽬前 进 ⾏总 结 ， 但 是 此 时最 好从模 块 向 上 重 构 ） * 其余 部 分同新建 型 需 求 * 完 成 后 基于需求完成情况 及 时进 ⾏问题点分 析 与 资产 沉淀 ， 理想情况甚⾄可以考 虑 让 AI 基于已 有经 验 进 ⾏ ⾃ 我迭 代 ， 从⽽ 逐 步扩⼤能⼒ 边 界 ， 踩 过 的 坑 就 不 要再 踩 ， 写 过 的代码就 不 要写第⼆遍。 * 基于⽣码 过 程中的常⻅问题 ， 及 时迭 代基础规范⽂ 档 （⼩⼆端开发中沉淀 的关键 注 意点 ， 尤其 是 需要 治 理 AI 喜 欢乱⽤ hooks 的⽑病 ） * 识别关键流程，沉淀到 Skill （ 资产化的 AI SOP ， 包含描 述、 指令 、 脚 本、 模版等内容 ） * 识别关键模式 ， 沉淀 到 标 准化 组 件 / 模 版 | 出码准确 率 | ⼈⼯介⼊成 本 ---|---|--- AI ⾃由发 挥 | 70% | ⾼ 有 语料的 三 ⽅ 包 | 80% | 低 私 有 包 \+ 调⽤规 范 | 95% | 低 看完以上的内容，有人会说： 我只想使用基础的Chat进行代码生成 ，不想评审AI生成的方案，也不想跳转出去使用额外的工具，怎么让我的Chat生码效果更好？以下是几个快捷可用的调优手段： * 配置基础的项目规则，并根据实际的问题对其进行一些调优； * 提前设计较为解耦的项目结构，提高 AI 迭代的成功率； * 接入一些辅助的MCP工具和已验证过的Skills进行能力辅助； * 使用一些基础的提示词流程或模版，尽可能描述清楚需求； 当纯对话方式完全陷入瓶颈时，可以参考以下两种实战案例进行优化。 两类实战案例 AI编码 过 程中 ， 有 个 ⽐ 较 重要的关 注 点就 是 ： 在 保证 迭 代成功率的同 时 ， 还 要留出 ⼀ 定的⼈为可介⼊空间 ， 以及保持对代码的掌控度 ； 对于验收要求越⾼的项⽬ ， 掌控率和⼈⼯可介⼊ 空间的要求就越⾼ ， ⽽ 根 据验收要求以及实际情况 ， 可以将实际需求分为以 下两 类。 | 需求驱动 型 | ⼯程主导 型 ---|---|--- 特 点 | 强调 " 要什么功能 " AI ⾃主决策技 术 实 现 ⼈⼯介⼊少 ， 关 注结 果 | 强调 " 怎么实现 " ⼈⼯ 深 度参 与 实现⽅ 案 决 策 ⼈⼯介⼊多 ， 关 注 代码质 量 代码规范度要 求 | 低 | ⾼ 验收 标 准 | 低 | ⾼ 隐含知识 量 | 低 | ⾼ 项⽬复 杂 度 | 低 | ⾼ AI 扮演的⻆ ⾊ | 功能开发 者 | 编 码 辅 助 员 案例 | ⼩⼆后台⻚⾯ / 研发⾃⽤⼯具 | 线上C端⻚⾯ / 商家端⻚⾯ ▐ ** ** 需求驱动 型 （ DO WHAT ） 这 ⼀ 场景 的主要关 注 点 在 于 ： * 想办 法 完全阐 明 需求点 ， 防⽌ AI 臆 造 或偏离； * 要 有 ⼀ 定的 辅 助⼿段 来 保证代码质量 ， 从⽽提⾼ 迭 代成功 率； * 留出 ⼀ 定的⼈⼯介⼊空间 ，不 要产出 ⼀ 堆难以介⼊的代 码； 接 下 来 将以 ⼀个 ⼩⼆端的需求 ， 从新建⻚⾯到⼆次 迭 代功能 ， 逐 步对⽐ 不 同⽅ 案 产出的⽣ 码结 果。 * 新建 ⼀个 ⼩⼆ 端 列表 ⻚ > 需求背景： > > ⼀个常规的列表⻚，按字段展示货品相关信息，并且⽀持按字段过滤。 对于简单的⻚⾯⽣成 ， 提供⾜够信息的⽂ 档 ， AI 即可完成对应的需求 ， ⽽ 根 据实际需求的验 收卡⼝ 与 ⽤户需求 ， 还 可以分为如 下三 种实现⻛ 格。 | 能⽤就⾏ 型 | 较有 要求 型 | 严 格型 （ 已 经有 ⼀ 份关于常规列 表 查 询⻚的实现模版 ） ---|---|---|--- 实现路 径 | * 直接 输 ⼊接⼝文档，其他完全由AI进行完善。 * 提供少量实现限定（ 使⽤ tao \- design ）， 或者由 AI⾃⾏读取仓库代码 进 ⾏判断 | * 提供基础的代码实现规范 与 ⽂件模版 * 按 要求提供 prd ， 并 进 ⾏ ⼀ 定的 结构 化优 化 | * 提供基础的代码实现规范 与 ⽂件模版 * 按要求提供 prd ， 并 进 ⾏ ⼀ 定的 结构 化优 化 * 提供 更 严 格 的具体实现 绑 定 ， 通过 严 格 的 代码模 版 限定产 物格 式 效果 | | | 样式 | 组件库兜底基本风格 | 组件库兜底基本风格 功能符合用户要求 | 符合 视觉稿 / 平台规范 要求 功能符合用户要求 可迭代性 | 非复杂情况 ，AI也可以再进行一定程度的迭代 | AI可以进行 一定程度 的迭代 | AI可以进行 长期多次 的迭代 代码质量 | 代码组织格式随机（还可能产出单个巨型文件）， 人工介入成本高 | 代码组织格式较规范，代码轻度解耦， 人工介入成本中 ，仍然有部分逻辑代码包含在主文件 | 代码完全按照统一思路 / 组件 完成，功能实现分散在各个子组件，代码严格解藕， 人工介入成本低 对于这种严格的解耦模式，人工编写时可能成本过高，但是交给AI编写则是适得其所 * 问题调 试 分⽀控 制 在 微调阶段 ， 及 时通过 Commit 保存版 本 ， 因 为 AI ⽣码 是 覆盖式 ， 没有 及 时 存 档 会 因 为 某 些错 误修改导致代码 混 乱 ， 前功尽弃 （ ⽬前的⽣码⼯具 都有 ⼀ 定的 回退 功能 ， 但 是 不 能 过 于信任 ）。 报错 调 试 常规报错直接将报错 部 分复制 给 Agent ⾃⾏调试即可 ， 可解决率 80% （ 解决 不 掉的 部 分主要 来 ⾃ 三 ⽅库内 部 的报错 ， 需要特判 ）。 部分非阻断型报错，关掉弹窗即可，部分错误弹窗只是便于本地调试，线上并不会显示。 数据调试 数据问题 不 会 有 报错提示 ， 可以让 AI ⾃⾏⽣成 ⼀ 些 输 出⽇志 辅 助排 查。 > xxxx显示为空，帮我在关键节点新增console⽇志，以便我复制给你排查问题。 以上页面调试也可以通过MCP工具，或者直接通过cursor的browser tab进行，篇幅问题不做展开。 * 进⾏⼀次 涉及 多 个 部 分的中 型迭 代 > 需求背景（原始需求）： > > 在货品管理页面中，货品除了基础信息外，还包含动态属性信息。这些属性由属性定义系统管理，支持多种数据类型（字符串、数字、布尔值、时间戳等），不同货品可能拥有不同的属性。 > > 为了提升货品管理的效率和用户体验，需要提供以下功能： > > 属性展示：在列表中直观展示货品属性，支持用户自定义显示哪些属性 > > 属性筛选：支持按属性进行筛选查询，快速定位目标货品 > > 属性编辑：支持查看和编辑单个货品的属性信息。 明 确需 求 先基于接⼝⽂ 档 和需求 ， 交 给 AI 创建产品⽂ 档 ， 核 对完成后 进 ⼊ 下⼀ 步 （ 常规改动可以让 AI 直接⽣成 ， 但如 果涉 及到复 杂 的交互 ， 最 好先看看 AI 准备怎么实现 ） , 以 下 是 让 AI 扩写后的产 品需求⽂ 档。 # 货品属性功能需求文档 ## 需求背景 在货品管理页面中，货品除了基础信息外，还包含动态属性信息。这些属性由属性定义系统管理，支持多种数据类型（字符串、数字、布尔值、时间戳等），不同货品可能拥有不同的属性。 为了提升货品管理的效率和用户体验，需要提供以下功能：1. **属性展示**：在列表中直观展示货品属性，支持用户自定义显示哪些属性2. **属性筛选**：支持按属性进行筛选查询，快速定位目标货品3. **属性编辑**：支持查看和编辑单个货品的属性信息 --- ## 一、功能需求 ### 1.1 属性列展示 **功能：** 在货品列表中添加"属性"列，展示货品属性信息。 **交互：**- 默认显示所有属性，每个属性以"标签+值"展示- 操作区提供"配置属性列"按钮，可配置显示哪些属性- 时间戳类型显示为日期时间格式，文本类型支持换行- 无属性时显示"暂无属性" --- ### 1.2 属性筛选 **功能：** 在筛选区支持按属性进行筛选查询。 **交互：**- 筛选区显示"按属性筛选"区域，已添加的筛选条件以 Tag 展示- 点击"添加属性筛选"打开弹窗- 弹窗中选择属性，系统根据属性类型自动判断筛选方式：  - 字符串/文本：有枚举值→枚举多选，无枚举值→文本匹配  - 数字：数值范围  - 布尔：布尔值选择  - 时间戳：时间范围  - 时间戳范围：时间点- 输入筛选值后确定，筛选条件生效并触发查询 --- ### 1.3 属性编辑 **功能：** 在操作列提供"属性"按钮，可查看和编辑货品属性。 **交互：**- 点击"属性"按钮打开右侧抽屉- 抽屉中以表格展示属性信息（属性键、属性键名称、属性类型、属性值）- 根据属性类型显示对应编辑控件：  - 数字→数字输入框  - 布尔→开关组件  - 时间戳→日期时间选择器  - 时间戳范围→日期时间范围选择器  - 字符串（有枚举值）→下拉多选  - 字符串（无枚举值）→文本输入框  - 文本→多行文本输入框- 修改后点击"保存属性"，保存成功后刷新列表并关闭抽屉 --- ## 二、数据类型说明 | 属性类型 | 筛选方式 | 编辑控件 ||---------|---------|---------|| STRING | 文本匹配 或 枚举多选 | 文本输入框 或 下拉多选 || TEXT | 文本匹配 | 多行文本输入框 || NUMBER | 数值范围 | 数字输入框 || BOOLEAN | 布尔值 | 开关组件 || TIMESTAMP | 时间范围 | 日期时间选择器 || TIMESTAMP_RANGE | 时间点 | 日期时间范围选择器 | --- ##### 迭代效果对比 由于不是所有页面都能找到可以恰好抽象描述出来的页面模版，所以这里采用 能用就行版 和 较有要求版 进行迭代效果对比。 | 能⽤就⾏初版 \+ 仅 输 ⼊原始需 求 | 较有 要求 型 初版 \+ 仅 输 ⼊原始需 求 | 较有 要求 型 初版 \+ 有 ⼈⼯阐 明 后的详 细 功能⽂ 档 ---|---|---|--- 最终 效 果 | 基 本 符合要 求 | 功能做出 来 了 ， 但 是 不 太合预 期 | 基 本 符合要 求 代码质 量 | ⼤量修改主⽂件 ， 多 次 迭 代后成功率必然⼤ 幅 下 降 迭 代后主⽂件⾏数 达 到 600 ⾏ ， 基 本 丧 失⼈ ⼯ 介⼊ 可 能 性 | 仅 轻 微修改主代 码 子组件划分清晰，人工介入成本低 | 主文件逻辑清晰，迭代未修改主文件 只修改了涉及相关的子组件（子组件其实也可以更内聚，这部分可以让AI再进行二次优化） 由 上 可 ⻅ * 清晰 的 prd 保证功 能 符合 预 期 ： 如 果没有 预先对 AI 想要产出的内容 进 ⾏审 核 ， 很容 易 发⽣偏离导致 结果 不 合预 期； * 优质的代码提⾼ 迭 代效率 ： 初始的代码对后 续迭 代的成功率 有较 ⼤影响 ， 如 果源 代码已 经 在 堆砌代码 ， 后 续迭 代 时 AI 也会延 续这 个 ⻛ 格 ， 导致 迭 代成功率急 速 下 降 ，且丧 失⼈⼯介⼊修改代码的空 间。 ▐ ** ** ⼯ 程 主导 型 （ HOW TO DO ） 这 ⼀ 场景 的主要关 注 点 在 于 ： * 代码需要 严 格 符合⼯程质 量； * 编 写者要保留对代码⼤ 部 分的掌控度 ，且 产出内容⼈⼯可介⼊度 ⾼； * 对于 这类 复 杂 度⾼ / 隐含知识多的项⽬ ， 怎么让 AI 可以做 / 知 道 做。 * 需求 背 景 与 实现 拆 解 需求内容 ： 需要 在 ⻚⾯ Feeds 下 新增⼆ 级类 ⽬ 配置 ，且 商 品卡⽚点击跳 转 切换到跳 转 ⾃ 有 中间⻚ （ 原 来 是 直接跳 转商 品详情⻚ ）， 完成视觉 更 新。 实现 拆 解 服 务 端 | 前 端 ---|--- 需要新增 ⼀个 ald solution ，且 ⽀持⼆ 级类 ⽬召 回 ⽀持 （ be 召 回时 增加参 数 ） | * 新增⼆ 级类 ⽬ 配置 项并 更 改接⼝参 数 * 重写 feeds 组 件 （ 原 有 旧 组 件 不 ⽀持多 级 tab ）， 修改卡⽚ 与 tab 样 式 * 修改卡⽚跳 转逻 辑 * 前 置 知识准 备 对于 这类 业 务仓库 ， 隐含知识及其多 ， 这 些隐含知识 有 些 来 ⾃ 业 务语义 ， 有 些 来 ⾃内 部 平台的开发模式 ， 也 有 ⼀ 些 来 ⾃各⾃ 团 队的实现规范 。 如 果没有 前 置输 ⼊ ， AI 完全⽆从 下 ⼿ ， 此 时 需要提前识别 业 务语义 下 的隐含知识 与⼀ 些实现规范 / ⽅ 案 ， 并将其 沉淀 到⽂ 档 ， 让 AI 有 迹 可循。 ⾸先 ， 梳理出当前需求需要声 明 的隐含知 识 * 什么 是 ⾃建的中间⻚ ？ 什么 是商 品详情⻚ ？ 怎么 进 ⾏跳 转 ？ * 后端仓库内怎么新建 ⼀个 solution ， 有没有 什么相关的代码规范 ？ * 前端仓库要使⽤什么⼯具库 ？⼀ 些基础功能如何实现 ？ * Feeds 组 件库如何使⽤ ？ 配置 项 是 什么 ？ 怎么 更 改 ？ 以 下 是 梳理出 来 的前 置 ⽂ 档 ， ⽂ 档这部 分建议 AI ⽣成 配 合⼈⼯修改 ， 尽量采⽤ 渐进 式披露的 原则 ， ⼊⼝⽂ 档 信息全⽽ 精 ， 对于需要详 细 介 绍 的 部 分 ， 可以另外创建⽂ 档进 ⾏补 充 ， 最 好是有 ⼀个 利于 统 ⼀ 读取的 地 ⽅ 进 ⾏存放 （ 前 期 冷启动的 时 候 编 写前 置 ⽂ 档 会花 较 多的 时 间 ，但 是这是值 得 ，且 未来 必须要完 成 的事 情 ， 后 期 复⽤到的 时 候就会发现 有 预制⽂ 档有 多爽 ）。 服 务端相关⽂ 档 | 前端相关⽂ 档 ---|--- | * 技术 ⽅ 案 产 出 准备好以后就可以基于知识问答和代码产出技 术 ⽅ 案 ， 这部 分 注 意 还是 要提供关键信息 ， 对于 AI 需要从知识库获取知识的情况 ， 最 好 是 让 AI 列出其参考的具体⽂ 档 ， 防⽌出现偏离 。 由 于 是 重代码质量的项⽬ ， 需要⼈⼯完成对技 术 ⽅ 案 的完整审 查 与 修改 ， 也 是 对代码掌控度的保证 （ 毕竟 线 上 bug 不 能让 AI 背锅 ）。 以 下 是 采⽤的技 术 ⽅ 案 模版 与 实际产出⽅ 案 ， 虽 然技 术 ⽂ 档 看起 来 ⾏数很多 ， 但 是 其实⼤ 部 分 都是 代码节 选部 分 ， 限定 格 式后的技 术 ⽂ 档 其实 不 会占⽤太多的审 查时 间。 实现前首先按照如下模版进行技术方案编写，文档生成到仓库docs目录下，我确认后再进行实现 技术方案模版引用文档 - 声明引用的知识库文档，并写入从知识库根目录的index.md获取版本号```## 引用文档- **知识库版本**：v1.2.3 (从 index.md 获取)- **相关文档**：  - [核心业务流程文档](链接) - 用于理解业务逻辑  - [技术架构文档](链接) - 用于确定技术选型  - [API 规范文档](链接) - 用于接口设计参考``` 相关接口 - 如无则省略功能点拆解 - 讲用户的需求分解成具体的功能点具体实现方案 - 大致声明实现方案，并在关键部位配上核心代码，或者mermAId流程图问题预警 - 分析整体流程上可能会出现问题的地方，并提供应对措施相关埋点 - 如无则省略内容补充 - 可以根据需求内容自由发挥，标题内容自拟，做一些内容补充，但是仅限一小部分 可以看到，被前置文档喂饱后，AI很完整地了解了自己该干什么，且 完整地掌握了淘内C端业务仓库下的开发方式。 * 具体执行阶段 - 解耦实现 关于执行部分，逻辑内容前后端实现起来都大差不差，这部分内容方案确定以后AI产出的代码基本都能满足需求，这块重点讲下C端前端最关键的视觉部分。 C端 AI 编码不好用的一个主要原因就是C端逻辑与视觉耦合度太高，而 AI 又天生缺乏对视觉内容的感知力，此时如果一次性让AI把组件的逻辑代码和视觉都写完容易顾此失彼，导致问题直接上升了一个复杂度。 此时最理想的解法，还是尽可能的将视觉代码与逻辑代码分离，先让 AI 完成逻辑代码部分，再单独通过其他方案完成视觉组件的编写，再使用 AI 将逻辑与视觉组件进行绑定。基础的视图分离比较简单，就是首先假定一个抽象组件，包含了属性与事件，再和一个只负责绑定事件与属性的纯视觉组件结合即可。 Bad Case ❌ 视图和逻辑耦合严重，每次对视图的修改都要同时影响到逻辑实现 | Good Case ✅ 视图和逻辑完全解耦，视图修改不再影响逻辑，业务层和视图层均可以快速迁移复用 （为了展示清晰所以采用两个文件的形式，实践中可以合并到一个组件，只要保留这个视图分离的设计思维即可） ---|--- 视图分离还有个好处就是极大地减少了前端的 CR 压力，比如一个视图分离后的购物车组件，CR 时只需要重点查看主逻辑 index.tsx 的代码变更，审查压力瞬间少掉大半。 重构过程中，也经常会遇到视图和逻辑绑定过深，无法复用 视觉/逻辑 代码的情况，这时候也可以直接让 AI 进行代码拆解，产出更加纯粹的 逻辑/视觉组件。比如这个需求中的商卡包含大量逻辑，我想实现新的卡片样式还得 从原来 400 行的视觉组件里挑出来所有逻辑代码 ，简直没有天理。但是让AI将组件改造成视图分离的结构后，再通过D2C产出新的卡片组件，在进行状态与事件的绑定即可，后续迭代也会更加清晰。 基于以上思路，还可以进一步设计视图分离的组件库，预设组件的事件，由调用方进行视觉组件的实现，完成事件的绑定，做到最大化的逻辑复用。比如，我们业务有需要在不同场景中复用的feeds模块，为了保证最大化的逻辑复用，我们将 tab 渲染的部分交给调用方，调用方自己进行 tab 部分的视觉实现，只要给对应的元素做好事件绑定即可。 * #### 后期沉淀 完成需求后，可以重新梳理整个流程中的问题与可以复用的内容，进一步完成资产沉淀，这部分内容前期的生成和调整都会比较费劲，但是基本几个中型需求认真跑下来的沉淀，就可以覆盖很多日常开发的内容了，然后就可以逐步进入坐享其成的阶段。当日常开发场景枚举到80%以后，AI 会越来越像我们延伸出的双手，不是胡编乱造，而是把我们脑海中的代码搬运到它们应该存在的地方。 ##### 组件沉淀 基于已有的视图分离结构，业务逻辑组件的可复用度已经不再受限于视觉稿，而剥离了业务逻辑的视觉素材，也可以快速的应用到各个项目。 ##### 知识文档迭代 虽然在前置准备期已经提前进行了知识文档的生成，但是 AI 大概率还是会有理解偏离的情况，这时候就要对已有的文档进行补充说明。比如：我提供了如何创建迭代的文档后，发现 AI 还是会自由发挥，导致流程执行错误。于是我针对几类常见问题补充了严格约束，通过运行时的及时修正来保证文档的有效性。 ##### 工作流沉淀 完成一次需求以后，最重要的就是review整个实现流程，识别有没有 可标准化/重复性强/涉及文件多 的可沉淀流程，比如这个需求就有多个可以落成简单 Skill 的工作项，标准工作流的沉淀可以让 AI 越来越可控。 * 后端 ald solution 创建，分步修改相应文件； * 在前面的基础上，进行前后端流程串联，如：solution -> 接口文档 -> 前端调用函数生成； * 前端天马配置项的新增与相应的读取代码生成； * 逻辑代码生成 -> 调用D2C工具生成视觉组件 -> 进行逻辑与视图的绑定。 团队介绍 本 文作 者 卓屿 ， 来自淘天集团- 天猫新品营销技术团队。我们致力通过大数据、人工智能打造领先的数字化新品营销平台，服务于天猫新品全链路增长，面向品牌商家构建从新品研发、新品孵化到新品上新的⼀体化解决方案，负责「天猫小黑盒」/「天猫U先」/「TMIC」（天猫新品创新中心）/「淘系新品运营平台」等淘系核心的新品与新客业务，帮助商家连接淘系站内外流量、营销资源与数据，做规模化新品经营与确定性增长。 ** ¤ ** ** 拓展阅读 ** ** ¤ ** [ 3DXR技术 ]() | [ 终端技术 ]() | [ 音视频技术 ]() [ 服务端技术 ]() | [ 技术质量 ]() | [ 数据算法 ]()