tmall ai coding practice team knowledge base npm¶

Ch01.335 tmall ai coding practice team knowledge base npm¶

📊 Level ⭐⭐ | 10.9KB | entities/tmall-ai-coding-practice-team-knowledge-base-npm.md

"tmall ai coding practice team knowledge base npm"¶

天猫新品团队 AI 编码实战指南（下）¶

来源： 天猫新品营销技术团队内部实践 定位： AI 辅助编码全链路实战指南（下篇），含团队建设 + 实用技巧

上篇核心框架回顾¶

三大核心思想	全流程优化
最大化复用	前置准备 → 开发前 → 开发中 → 完成后
自然语言第一
二八定律
需求分类：

需求驱动型 → 小二端工作台（低代码质量要求）
工程主导型 → C 端复杂业务（高代码质量 + 视觉还原要求）

团队建设经验¶

小二端 — AI 主导的对话生码¶

特点： 无视觉还原度要求，页面间独立性强，后端同学主要通过 AI 完成全部需求实现。

初期：统一生成方案¶

小二端开发培训（规范）
页面间完全解耦结构
高频页面提供代码模板

中期：补齐前端经验短板¶

问题：后端同学无法精准描述需求（缺乏前端术语概念）解法：

「AI 案例实践中心」：B 端常见页面 → 标准化 prompt 模板
MCP 速查工具「天猫新品业务编码助手」：输入需求 → 输出标准化页面 PRD → 喂给 AI
图片生成提示词工具（Gemini 3.0 多模态）：参考页面 → 系统化结构化描述词 → 比直接传图给编程工具有更好的页面还原效果 问题：垂类场景 / 复杂问题没有经验 解法：
生码沉淀：详细记录实现过程与踩坑心得
案例分两类：新增型需求 / 更新型需求
每份案例包含：需求背景、实践步骤、功能自测、错误提示

后期：轻量级团队知识库（无感辅助）¶

核心思路：用 npm 包作为知识库资源承载 + 版本管理工具，以类 Skill 形式封装：

git 仓库管理文档
    ↓
npm 包作为资源承载 + 版本管理
    ↓
Skill 形式封装团队规范 + 代码模板
    ↓
AI 通过 curl 直接读取 npm cdn 资源（不依赖具体编码工具）
    ↓
编辑器 Rules 配置接入

关键优势：

及时更新（git → npm publish）
不依赖编码工具（curl 读取）
支持 AI 问答（CodeWiki 集成）
统一收口团队基础开发方案

C 端 — 全栈开发模式下的 AI 辅助¶

挑战：

代码质量要求高，业务隐含逻辑多，无法纯 AI 完成
链路长，涉及仓库多（前后端 + 组件库 + 工具库）
高频高耗时节点需要分析与优化 主要 Action：
代码结构与公共组件设计 → 提高生码效率
高频 workflow 标准化沉淀
基础团队知识库（统一读取方案）
让 AI 基于知识库产出技术方案 + 人工审核
开发流程工具辅助（走查辅助 / 接口查询 / 页面检查 MCP） 未来方向：
知识库自动生成与更新
更 AI 友好的代码架构
整条链路 AI 串联

实用技巧集锦¶

严苛程度分级表¶

严苛程度	典型场景	错误容忍	视觉还原
★★★★★ 最严苛	C 端频道	0容忍	高要求
★★★★ 较严苛	B 端商家平台	0容忍	中要求
★★★ 普通	小二端工作台	0容忍	低要求
★★ 较低	研发自用工具	hack绕过则0容忍	无要求
★ 不严苛	研发 DEMO	能意会则容忍	无要求

UI 布局重构¶

让 AI 解释旧布局 → 区块划分与标记 → 构思新布局 + 迁移方向 → AI 理解布局结构进行重构

复杂 Prompt 构建¶

核心思路：让 AI 操作 AI，开发者只思考需求是什么 案例：neko 智能参数调试面板

需求：生成一个能理解 HTTP GET/POST 参数、字段业务语义、重构表单面板（原生 JS 无构建过程）、iframe 联动（postMessage 实时同步）
技巧：让 AI 先理解朴素诉求，再让 AI 自己生成对应复杂 prompt

数据转换¶

给出原始数据格式 + 目标数据格式（尽量全，覆盖所有字段）
端到端边缘 case 测试
让 AI 负责协议转换，人只负责验收

多方案选优¶

对不熟悉的项目
    ↓
让 AI 给出多种方案（附带优劣分析）
    ↓
人工选出倾向方案
    ↓
确认方案对当前项目的改动大小
    ↓
开始实施

文档生成¶

从功能代码反推使用文档（AI 生成，人只审核）

页面信息总结¶

基于 MCP 或内置工具访问页面 → AI 总结 + 举一反三多语言转义

未来待解决问题¶

精细化微调无法达到效果 → AI 对话场景下难以完成精细化页面操作
开放式场景如何保证统一 → 未枚举页面的视觉一致性无法保证

深度分析¶

天猫团队的这篇实战指南揭示了AI 辅助编码的核心矛盾：不同场景对 AI 的依赖度和质量要求存在巨大差异。 关键发现一：npm 包作为知识库载体是一个巧妙的工程选择。传统知识库方案（如 CodeWiki、文档站）依赖特定平台，而 npm 方案利用已有的包管理基础设施，实现了"技能即包"的类 Skill 封装。这种思路的精髓在于：让 AI 获取知识的方式与人类开发者获取依赖的方式一致，从而实现真正的"无感辅助"。 关键发现二：需求分类决定 AI 依赖度。天猫将需求分为"需求驱动型"（小二端）和"工程主导型"（C 端），本质上是按错误成本和视觉还原要求对任务分级。低错误成本场景可以高比例依赖 AI，高错误成本场景则需要 AI + 人工审核的混合模式。 关键发现三：Prompt 构建的"让 AI 操作 AI"思路值得深思。传统的 Prompt 工程是"人写 Prompt 给 AI 看"，而这里的思路是"让 AI 先理解朴素诉求，再让 AI 自己生成复杂 Prompt"。这实际上是将 Prompt 生成本身变成一个 AI 辅助任务，某种程度上是在用 LLM 自身的推理能力来弥补它对复杂指令理解的局限。 架构演进趋势：从"统一生成方案"→"补齐经验短板"→"轻量级知识库"的演进路径，揭示了一个规律——AI 辅助编码的成熟度取决于团队知识沉淀的形态，而不是工具本身。

实践启示¶

建立场景分级意识：在引入 AI 辅助编码前，首先对团队任务进行错误成本和视觉还原要求的分级。低要求场景（内部工具、DEMO）可以激进使用 AI，高要求场景（C 端业务）则需要建立完善的 AI + 人工审核流程。
知识库封装优先考虑 npm/Skill 模式：相比独立知识库平台，利用已有的包管理基础设施封装团队规范和代码模板，可以实现更低的接入成本和更高的复用度。关键是确保 AI 可以通过 curl 方式直接读取包内资源。
Prompt 构建采用分层策略：对于高频场景（UI 布局、数据转换、文档生成），预先构建"Prompt 模板库"；对于低频场景，让 AI 自己生成复杂 Prompt，再人工审核优化。
C 端场景的 AI 辅助重心在架构层：代码质量和视觉还原要求高的场景，AI 的价值不在于直接生成代码，而在于提高公共组件复用度和标准化高频 workflow——这些是"让人做人的事，AI 做 AI 的事"的有效分工。
重视"案例沉淀"而非"规则堆砌"：相比罗列大量行为规范，将典型需求的实现过程、踩坑心得记录为案例，对后端同学等 AI 经验不足的开发者更有实际帮助。

评审：Value 7 × Confidence 7 = 49 | ★★★ | 边界通过，入库原因：知识库 npm 包管理 + 类 Skill 封装模式有参考价值