腾讯企业微信团队 Skill 流水线：AI代码生成率94%的需求开发全流程¶

📊 Level ⭐⭐⭐ | 9.6KB

来源：腾讯技术工程 - 企业微信团队 gomezlai，2026-07-20 核心命题：AI 不是不会写代码，是不会"按工程规范"开发需求。把需求开发流程化、原子化、可校验化，然后用一个 Skill 串起所有阶段。

背景：企业级移动端开发的六大痛点¶

企业微信团队面临 9000+ 源文件、跨多层调用的企业级移动端项目，AI辅助编码的六大真实堵点：

1. 上下文塞不下 — 整段源码喂不进，跨 5-6 层调用关系无法在单轮对话中表达
2. 物料分散 — PRD/TAPD/Figma/企微文档/Figma Token 之间无统一入口
3. 命名不一致 — 用户语言 vs 代码标识符之间的语义鸿沟
4. 模糊指令 — "按 PRD 改一下"导致 AI 跳过拆解直接改代码，越界漏改
5. 验证不闭环 — AI 自报"完成"但编译失败或逻辑不通
6. 跨会话失忆 — 上次的设计决策、文件改动和改因在下次会话中丢失

8 阶段 Skill 流水线¶

以「阶段·动作」命名约定贯穿，每个阶段有明确输入、产出和机器可校验的退出标准，形成一条严格顺序的流水线。

① 设计稿阶段¶

• 输入：Figma 链接
• 关键动作：脚本化直方图筛选 — 按尺寸规格对设计稿做直方图统计，自动筛选移动端候选稿，绝不允许 LLM "手感"分桶
• 产出：移动端候选稿清单 + PNG 概览

② 拆解阶段¶

• 输入：PRD + 设计稿 + CGI + TAPD
• 关键动作：多源收料 + 归宿校验 — 每张设计稿必须归到三类之一
• 产出：五列需求清单 + subtasks.json 接力台账

③ 定位阶段（五步定位法）¶

• 输入：需求点
• 关键动作：五步逐层收敛
• 配置层 → 2. 基础能力层 → 3. 业务组件层 → 4. 页面展示层 → 5. 事件处理层
• 产出：文件 + 行号 + 调用链

④ 实现阶段¶

• 输入：调用链 + 上下文
• 关键动作：自底向上 — 数据 → 解析 → 枚举 → 业务 → UI → 日志
• 产出：代码改动

⑤ 验证阶段¶

• 关键动作：bazel build + 最多 3 轮自修复
• 产出：编译报告（退出码 0）

⑥ 模拟器验证阶段¶

• 关键动作：人机秒级确认，阶段内重试 ≤ 2 轮
• 产出：装机后截图 + 日志

⑦ 沉淀阶段（TECH_SPEC.md）¶

• 关键动作：生成 TECH_SPEC.md 单一事实源，记录本次改动的设计决策、文件清单、调用链和回退方案
• 意义：跨会话知识传承的载体，打通多会话间的工程记忆

⑧ 提交阶段¶

• 关键动作：三段式 commit + AI 署名 + 代码生成率统计
• 代码生成率：基于 git diff 行级分析，区分 AI 生成行 vs 人工修改行

关键设计原则¶

流程化 > 模型能力¶

我们的解法不是换更大的模型，而是把"需求开发"这件事流程化、原子化、可校验化，然后把每一步都喂给 AI。

脚本化 > LLM 手感¶

设计稿筛选不是靠 AI "觉得哪个像移动端稿"，而是用脚本做直方图统计。只要能用确定性程序解决的问题，就不该交给 LLM 的模糊判断。

外部知识载体 > 模型记忆¶

TECH_SPEC.md 作为跨会话知识传承的外部文件，比依赖模型的内在记忆更可靠。这与 Anthropic Long Running Agent Architecture 6H Retroforge 的"文件系统 > 模型记忆"原则一致。

阶段性验证¶

每个阶段有独立验证退出标准，验证从编译（阶段⑤）到模拟器（阶段⑥）到知识沉淀（阶段⑦）逐级上升，避免"完成"的虚假声明。

对比¶

→ 原文存档

深度分析¶

94% 的归因：是流水线跑赢了，不是模型变强了¶

文章最有信息量的一个细节是 94% 这个数字的度量方式：它不是模型自评，而是基于 git diff 的行级分析，把 AI 生成行与人工修改行分开统计出来的结果。换句话说，团队把"AI 到底用了多少"也做成了工程上可测量的指标，而不是一句宣传语。支撑这个数字的，是一套把需求开发拆成 8 个阶段、每个阶段都有明确输入产出和退出标准的流水线——作者明确说解法不是换更大的模型，而是把"需求开发"这件事流程化、原子化、可校验化，这与 规格驱动开发 的思路同源：约束先于生成。

确定性与模糊性的分界线：脚本能做的绝不交给 LLM¶

流水线里最值得复制的判断出现在阶段①：设计稿筛选用脚本按尺寸规格做直方图统计，"绝不允许 LLM 手感分桶"。这句话划出了一条清晰的分工线——凡是能写成确定性程序的问题，就不消耗模型判断力；LLM 只被安排在真正需要语义理解的环节（拆解、定位、实现）。同样思路体现在阶段②的"归宿校验"上：每张设计稿必须归到三类之一，用封闭的分类枚举保证拆解不漏不错。把模糊任务改造成封闭校验任务，是该流水线对抗 LLM 不确定性的核心手段，也呼应了 验证器驱动开发 的模式。

双层记忆台账：subtasks.json 与 TECH_SPEC.md¶

这套流水线其实有两层外部记忆。短程一层是阶段②产出的 subtasks.json 接力台账，让阶段间的状态靠文件传递，而不是靠对话上下文硬扛 9000+ 源文件、跨 5-6 层调用的项目；长程一层是阶段⑦的 TECH_SPEC.md，记录设计决策、文件清单、调用链和回退方案，下次会话自动加载，专治"跨会话失忆"。两层共同指向同一个原则：外部知识载体比模型内在记忆可靠，这与 长程 Agent 的文件系统记忆 的结论互相印证——文件系统才是 Agent 的持久记忆层。

把资深工程师的隐性经验编码进阶段指令¶

五步定位法（配置层→基础能力层→业务组件层→页面展示层→事件处理层）和自底向上实现顺序（数据→解析→枚举→业务→UI→日志）表面上是操作步骤，实质是把熟悉大型代码库的资深工程师的隐性经验——先查配置再看底层、先改数据层再动 UI——显式编码成了阶段指令。模型不需要真正"理解"这个项目的架构，只要严格按层收敛，就能表现出接近熟手的行为。这解释了为什么这套方法可以随 Skill 复制：经验写进了流程，而不是留在个别高手的脑子里。

实践启示¶

1. 为每个阶段定义机器可校验的退出标准：编译退出码 0、模拟器截图、归宿校验通过，都优于"AI 自报完成"；验证不闭环是企业级落地最常见的失败点。
2. 先问"这一步能不能写成脚本"：凡是可用确定性程序解决的问题（筛选、统计、校验），不要消耗 LLM 判断力；把模糊任务改造成封闭分类校验任务。
3. 阶段间状态用文件接力：用 subtasks.json 之类的台账文件在阶段间传递产出，不要指望单轮对话装下大型项目的跨层调用上下文。
4. 会话收尾强制沉淀 TECH_SPEC.md：记录设计决策、文件清单、调用链和回退方案，并约定下次会话自动加载，把工程记忆外置到文件系统。
5. 用 git diff 行级分析量化 AI 生成率：区分 AI 生成行与人工修改行，让"AI 用得怎么样"成为可复盘的数字而非感觉。
6. 用「阶段·动作」命名约定组织 Skill：让流水线结构一眼可读，方便团队增删阶段和复用动作。

关联¶

• 相关概念: Harness Engineering