3.8 KiB
《天猫新品营销技术团队AI编码实战指南（上）》
来源： 微信公众号文章
本地存档： C:\Users\Zane\Desktop\我的\天猫新品营销技术团队AI编码实战指南（上）.html
作者： 天猫新品营销技术
标签： #微信文章 #AI编码 #工程实践 #团队方法论
重新总结
这篇上篇文章的核心判断是：AI 编码已经能显著提效，但真正的问题不在“模型会不会写代码”，而在“团队能不能把需求、上下文、工程结构和校验流程组织成 AI 可稳定执行的形态”。作者基于天猫新品团队实践，把 AI 编码常见失败归纳为四类：写不对、写不好、写不了、改不动；再把根因拆到项目知识缺失、用户输入模糊、任务复杂度过高、缺少自检闭环、模型和 Agent 能力边界这五个维度。
文章给出的主线不是追求一次性完美生成，而是通过工程化手段提升“前 80% 的成功率”和“后 20% 的收敛效率”。对应的方法论有三条：最大化复用、自然语言第一、接受二八定律。最大化复用强调把系统拆成可理解、可调用、可组合的模块和工作流，尽量让 AI 做胶水代码而不是重造轮子；自然语言第一强调文档、规范、需求说明和过程记录要先于代码，文档质量直接决定 AI 产出质量；二八定律则提醒团队接受 AI 在 0% 到 80% 阶段很快，但在复杂收尾、边界修复、旧逻辑耦合阶段会明显失速，因此需要人为介入和流程补强。
在执行层面，文章按完整流程给出优化建议：开发前先准备知识库、AGENTS/README、代码规范、目录边界和可检索上下文；需求阶段把模糊 PRD 转成更明确的功能描述，必要时引入 spec 化文档；任务设计上降低复杂度，把大任务拆成可验收的小黑盒；开发中持续维护过程文档和上下文，避免 AI 因窗口限制失焦；完成后补上 code review、测试、前后端验证等自检环节。作者尤其强调，很多 AI 编码问题本质上不是“提示词技巧”问题，而是仓库结构差、耦合重、文档缺、验证弱导致的工程问题。
文章最后通过场景分类说明实践差异：一类是“需求驱动型”，重点在让 AI 准确理解业务目标和验收标准；另一类是“工程主导型”，重点在模块边界、复用能力、视图分离、知识沉淀和工作流建设。整体结论很务实：不要把 AI 当成能脱离工程体系独立完成软件开发的黑盒，而应把它纳入团队的文档、规范、测试、知识库和流程体系中，作为一个高效但不稳定的执行者来管理。
核心要点
- 四大痛点：写不对、写不好、写不了、改不动。
- 五类根因：项目隐性知识太多、需求输入不清晰、任务复杂度过高、缺少 review/test 闭环、模型与 Agent 有天然边界。
- 三条方法论：最大化复用、自然语言第一、接受二八定律。
- 真正的提效点不是“多写 prompt”，而是把需求、文档、知识库、模块边界和测试流程变成 AI 可消费的上下文。
- 复杂项目里，AI 更适合完成高复用、低歧义、边界清晰的 80% 工作；剩余 20% 仍需要工程治理和人工兜底。
对我的启发
- AI 编码的上限，更多取决于仓库可读性、知识显式化程度和验证手段，而不是单次对话技巧。
AGENTS.md、README、Spec、CodeWiki 这类文档不是附属物，而是 AI 开发链路里的输入接口。- 如果一个需求总是“改不动”，优先怀疑任务拆分、模块耦合和上下文组织方式，而不是只怪模型笨。