天猫新品营销技术团队AI编码实战指南（上）
公众号名称：大淘宝技术
作者名称：天猫新品营销技术
发布时间：2026-05-06 17:42
本⽂是关于AI辅助编码的全⾯实战指南，基于天猫新品团队的实践经验，从问题本质到解决⽅案，从理论框架到实战案例，系统性地介绍如何让AI更好地完成⼤部分需求。
本文分上下两篇，上篇包含：
1. 现状与问题诊断 - 深⼊剖析 AI⽣码的四⼤痛点（写不对、写不好、写不了、改不动），并从项⽬知识、⽤户输⼊、任务复杂度、⾃检机制、模型能⼒等五个维度提供针对性解法。
2. ⽅法论与优化思路 - 提出”最⼤化复⽤、⾃然语⾔第⼀、⼆⼋定律”三⼤核⼼思想，并沿着”前置准备→开发前→开发中→完成后”的全流程，给出每个节点的可落地优化⼿段。
3. 分场景实战案例- 根据验收标准和代码质量要求，将需求分为”需求驱动型”和”⼯程主导型”两类，通过⼩⼆端列表⻚和C端复杂业务的完整案例，展示不同场景下的最佳实践。
下篇包含：
4. 团队建设经验- 分享新品团队在⼩⼆端（后端全栈化）和C端（视图分离、知识库建设、⼯作流沉淀）两个⽅向的探索，包括⼯具建设、⽂档沉淀、知识库⽅案等具体落地内容。
5. 实⽤技巧集锦 - 涵盖 UI重构、复杂 Prompt构建、数据转换、多⽅案选优、⽂档⽣成等常⻅应⽤场景，以及严厉语⽓、合理质疑等提升准确度的技巧。
AI⽣码现状
▐当前AI⽣码的主要问题
写不对： AI没有完全按照⽤户意图完成功能，轻则存在缺陷，重则⽆法运⾏  | 写不好： AI产出的代码不符合要求，包括但不限于代码质量/代码风格/实现方案  |
写不了 项目隐含逻辑太多，文件结构复杂，耦合度高，AI完全无法按预期完成任务
（如一些内部SDK工具库，使用说明都在外部文档，AI 无法直接通过代码理解如何使用，自然无法写出对应的使用代码） | 改不动 在某些迭代场景中，AI一直无法输出正确结果，在错误中不断循环，甚至还可能改坏其他部分，此时只能人工介入
而介入后，想要完成修改则需要面对AI短时间内生成的大量代码，反而导致效率下降，使用者完全丧失了对项目的把控
|
▐导致问题的主要因素与解法
1. 项⽬/需求 隐含信息过多（AI不知道）
由于⼤家都是淘内私有项⽬，代码中不仅包含了专属的业务逻辑，还有来⾃四⾯⼋⽅的SDK⼯具库代码，⾯对⽆处获取的项⽬知识，即使是Cluade40来了也⽆济于事。
解法：
-
使⽤有明确声明的NPM包，或者给其接⼊Artifact7等辅助⽂档⽣成⼯具；
-
提供可访问的外部知识库，包括但不限于MCP⼯具/ 项⽬知识库/ 需求⽂档。
2. ⽤户输⼊不精准，必要信息不⾜（没给AI说）
代码开发就是从模糊的需求转向⽆歧义的代码，模糊部分在实现中必然会被补充，实现不合预期的⼀⼤原因就是模糊部分没有明确说明。
解法：
-
⽤户主动增加输⼊内容/ 辅助⼯具提升输⼊质量
-
对⼀些常⻅的情况提供prompt模版，使⽤时根据实际需求作部分修改；
-
借⽤⼯具进⾏⽤户输⼊扩写，以及对必要的模糊部分进⾏标记与阐明；
-
引⼊ SpecCoding⽅案，以详细的⽂档作为AI输⼊；
-
对⾼频场景做出约定，通过约定来覆盖模糊（如维护⼀份持续更新的AGENT.md）。
-
意图识别，基于项⽬上下⽂⾃动推测模糊部分
-
接⼊MCP⼯具，扩⼤AI感知⼒，使AI能更好地理解⽤户意图；
-
通过 代码索引 / 项⽬⽂档 / CodeWiki等辅助⼿段，使 AI 可以基于项⽬代码快速仿写与推测。
这⾥存在⼀个关于⽂档详细程度的权衡点：到底是使⽤⼤⽽全的⽂档，还是⼩⽽精。
经过实践，最适合的⽅案应该是先给出⼀个可以基本描述清楚需求的⼩⽂档，再根据AI实际产出的偏离情况来进⾏问题补充，因为⼤部分都是⼏个重复出现的常⻅问题（前提是保持⼯具和模型尽可能不变），进⾏⼏次补充以后就可以完成⼀份精准好⽤的输⼊⽂档。
3. 任务复杂度⾼
AI⽣码的成功率会随着任务复杂度的提升⽽在某个节点开始骤降，此时则需要通过合适的⼿段降低任务的难度，最⼤化AI的⽣码成功率，⽽降低复杂度主要有以下两个⻆度。
-
降低任务复杂度
-
识别重复的⼯作流与代码，进⾏针对性优化与封装复⽤，从⽽减少⽣码的代码量与不确定性；
-
复杂任务拆分，将单个不易测试的⼤型任务，拆成多个可验收的⼩型⿊盒；
-
固定实现思路/细节，统⼀思维模型，通过约定来减少思维/选型负担。
-
降低⼯程复杂度（⽂件量、耦合度）
-
借助优秀的⼯程结构设计，实现代码/ 模块 / ⽂件的天然解耦（很多⽣码问题其实归类到底都会⾛到基础的代码⼯程化问题，具有优秀⼯程结构的仓库天然就有较⾼的AI⽣成成功率）；
-
通过代码索引/项⽬⽂档/CodeWiki等辅助⼿段，提⾼AI检索效率，减少因检索困难⽽新增的⽆⽤上下⽂。
4. 缺少⾃检环节
现在的常规⽣码流程，只会进⾏基础的代码规范与语法检测，并没有完整的Review & Test 的流程。此时的AI只是完成了代码⽣成，并不⼀定完成了任务，也不⼀定满⾜实际的代码质量要求。
-
代码质量⾃检
-
在本地引⼊⾃检流程，及时完成代码质量确认；
-
使⽤Code平台的AICR助⼿进⾏发布前预检，可以⾃定义CR规则。
-
功能⾃检
-
前端可以通过接⼊MCP的⽅式让AI可以感知前端⻚⾯，从⽽进⾏部分功能测试；
-
后端可以通过单测直接查看功能正确性；
-
对于⽆法测试的⼤型任务，可以拆分到多个易于验收的⿊盒（如前端进⾏视图分离，对逻辑hooks部分进⾏单元测试）。
5. 模型 / Agent的差异与能⼒限制
模型的不同/ 编码⼯具的不同，都会影响⽣成结果，即使是同⼀个模型，也会因为模型的随机性⽽产⽣不同的结果。要将AI ⽣码运⽤在⼯程中，不仅需要⾯对模型的短板，还需要对抗模型的随机性。
-
上下⽂窗⼝有限
-
留存过程⽂档，实现上下⽂复⽤，跳过收集环节
-
代码上下⽂：仓库信息、接⼝信息
-
项⽬上下⽂：PRD、功能⽂档
-
提供更精准的上下⽂，尽量不让 AI靠⽂件猜测
-
通过⼀些⽤户 Rule 监控注意⼒状态（⽐如：让 AI 每次对话结束都要⽤谢谢结尾，如果没有则说明上下⽂窗⼝已经爆了）
-
随机性 / 模型差异导致⽣成内容的质量不稳定
-
提供更严格的约束⽂档 / SpecCoding⽅案
-
补充⾃检环节
-
修改型问题错误率⾼
-
修改型问题相当于上下⽂更多，正确率要求更⾼的⽣码任务，⽽AI理解⼒弱，所以修改型任务准确率更低，这就是⼤家最常提到的改不动的问题。对于这个问题，主要的解法就是⽤前⽂提到的办法去降低任务复杂度：减少AI理解代码的难度或者降低⽣码任务体量
-
天⽣对某些问题能⼒弱，容易卡在死循环⾥
-
识别常⻅错误场景，ByCase分析积累经验，沉淀对应的解法
核⼼⽅法论与全流程优化指南
这部分主要介绍提⾼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%的效率。
▐ 全流程节点
⼀次 AICoding的执⾏流程⼤概可以概括为：理解⽤户意图 > 查找上下⽂> 设计执⾏⽅案>代码⽣成> 简单校验。由于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在修改代码前先输出⽅案并审阅
-
收集到案例中进⾏ByCase分析
常见陷阱：在一次会话中进行大量任务，这会导致上下文太长太宽泛，模型注意力丢失。
-
对于独立的任务，应该及时新建对话
-
对于大型任务，应该及时生成各类过程文档，当模型成功率显著降低时切换对话并传入过程文档恢复上下文
-
开发中（迭代型需求）
常⻅问题：
场景 | 发⽣了什么 | 后果 |
改⼀个功能，坏了另⼀个 | 添加删除功能时，不⼩⼼影响了添加功能 | 花时间排查，可能越改越乱 |
想回到"昨天那个版本" | 昨天的代码能⽤，今天改了⼀堆，全坏了 | 找不到昨天的版本 |
试了三种⽅案，想回到第⼀种 | 第⼀种⽅案其实最好，但已经被覆盖了 | 要么重写，要么将就 |
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（资产化的AISOP，包含描述、指令、脚本、模版等内容）
-
识别关键模式，沉淀到标准化组件 / 模版
出码准确率 | ⼈⼯介⼊成本 | |
AI⾃由发挥 | 70% | ⾼ |
有语料的三⽅包 | 80% | 低 |
私有包+调⽤规范 | 95% | 低 |
看完以上的内容，有人会说：我只想使用基础的Chat进行代码生成，不想评审AI生成的方案，也不想跳转出去使用额外的工具，怎么让我的Chat生码效果更好？以下是几个快捷可用的调优手段：
-
配置基础的项目规则，并根据实际的问题对其进行一些调优；
-
提前设计较为解耦的项目结构，提高 AI 迭代的成功率；
-
接入一些辅助的MCP工具和已验证过的Skills进行能力辅助；
-
使用一些基础的提示词流程或模版，尽可能描述清楚需求；
当纯对话方式完全陷入瓶颈时，可以参考以下两种实战案例进行优化。
两类实战案例
AI编码过程中，有个⽐较重要的关注点就是：在保证迭代成功率的同时，还要留出⼀定的⼈为可介⼊空间，以及保持对代码的掌控度；对于验收要求越⾼的项⽬，掌控率和⼈⼯可介⼊空间的要求就越⾼，⽽根据验收要求以及实际情况，可以将实际需求分为以下两类。
需求驱动型 | ⼯程主导型 | |
特点 | 强调"要什么功能" AI⾃主决策技术实现 ⼈⼯介⼊少，关注结果 | 强调"怎么实现" ⼈⼯深度参与实现⽅案决策 ⼈⼯介⼊多，关注代码质量 |
代码规范度要求 | 低 | ⾼ |
验收标准 | 低 | ⾼ |
隐含知识量 | 低 | ⾼ |
项⽬复杂度 | 低 | ⾼ |
AI扮演的⻆⾊ | 功能开发者 | 编码辅助员 |
案例 | ⼩⼆后台⻚⾯ / 研发⾃⽤⼯具 | 线上C端⻚⾯ / 商家端⻚⾯ |
▐需求驱动型（DOWHAT）
这⼀场景的主要关注点在于：
-
想办法完全阐明需求点，防⽌ AI臆造或偏离；
-
要有⼀定的辅助⼿段来保证代码质量，从⽽提⾼迭代成功率；
-
留出⼀定的⼈⼯介⼊空间，不要产出⼀堆难以介⼊的代码；
接下来将以⼀个⼩⼆端的需求，从新建⻚⾯到⼆次迭代功能，逐步对⽐不同⽅案产出的⽣码结果。
- 新建⼀个⼩⼆端列表⻚
需求背景：
⼀个常规的列表⻚，按字段展示货品相关信息，并且⽀持按字段过滤。
对于简单的⻚⾯⽣成，提供⾜够信息的⽂档，AI即可完成对应的需求，⽽根据实际需求的验收卡⼝与⽤户需求，还可以分为如下三种实现⻛格。
能⽤就⾏型 | 较有要求型 | 严格型 （已经有⼀份关于常规列表查询⻚的实现模版） | |
实现路径 | 
|  
| 
|
效果 |  |  |  |
样式 | 组件库兜底基本风格 | 组件库兜底基本风格 功能符合用户要求 | 符合视觉稿 / 平台规范要求 功能符合用户要求 |
可迭代性 | 非复杂情况，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也会延续这个⻛格，导致迭代成功率急速下降，且丧失⼈⼯介⼊修改代码的空间。
▐⼯程主导型（HOWTODO）
这⼀场景的主要关注点在于：
-
代码需要严格符合⼯程质量；
-
编写者要保留对代码⼤部分的掌控度，且产出内容⼈⼯可介⼊度⾼；
-
对于这类复杂度⾼/ 隐含知识多的项⽬，怎么让AI可以做/ 知道做。
-
需求背景与实现拆解
需求内容：
需要在⻚⾯Feeds下新增⼆级类⽬配置，且商品卡⽚点击跳转切换到跳转⾃有中间⻚（原来是直接跳转商品详情⻚），完成视觉更新。
实现拆解
服务端 | 前端 |
需要新增⼀个aldsolution，且⽀持⼆级类⽬召回⽀持（be召回时增加参数） |
|
- 前置知识准备
对于这类业务仓库，隐含知识及其多，这些隐含知识有些来⾃业务语义，有些来⾃内部平台的开发模式，也有⼀些来⾃各⾃团队的实现规范。如果没有前置输⼊，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」（天猫新品创新中心）/「淘系新品运营平台」等淘系核心的新品与新客业务，帮助商家连接淘系站内外流量、营销资源与数据，做规模化新品经营与确定性增长。
¤ 拓展阅读 ¤
原创 天猫新品营销技术 大淘宝技术
内容效果不满意？点此反馈