Files
obsidian-notes/InBox/AI-First产研团队的交付路径.md
Build Bot f7310caea0 同步
2026-05-18 01:20:38 +08:00

4.5 KiB
Raw Blame History

AI-First 产研团队的交付路径

来源: 微信公众号 - 昀启AI+ 作者: 昀启 日期: 2026年4月21日 09:47 标签: #AI-First #上下文工程 #Skill-as-Code #产研协作 #交付路径


核心框架

  • 指标AI 初稿准确率
  • 底座:上下文工程 (L0/L1/L2 三层收敛)
  • 载体Skill-as-Code — 把团队规范和工作方法硬编码为可版本管理的工程资产

初稿准确率是 AI 协作的前置变量

为什么同样使用模型,不同团队的产出质量会出现显著差异?

差异的根源不在模型能力,而在于 AI 所获得的上下文质量。 上下文充分且精准时第一版初稿往往已接近可交付标准上下文残缺或含混时AI 的产出更像基于有限信息的推测,返工成本随之上升。

核心度量: AI 生成的第一版初稿,有多大比例可以进入审查流程,或仅经少量调整后即可交付。

这个指标直接关联 AI 协作的真实 ROI

  • 初稿准确率高 → 人的精力更多用在审查和决策上
  • 初稿准确率低 → 人的精力持续消耗在返工和修补上

很多团队引入 AI 后体感"快了但不稳",本质上就是这个指标波动过大。


六段式交付闭环:上下文逐级收敛与同步更新

六个阶段的核心逻辑不是线性流程编排,而是上下文逐级收敛、阶段持续校验、结果最终回写

阶段 人的职责 AI 的职责 显性资产(给人的) 隐性上下文(给下阶段 AI 的)
业务需求 定义目标、边界、优先级 起草需求内容 需求文档 业务意图、边界约束
PRD 设计write-prd Skill 澄清歧义、确认范围 生成结构化 PRD AI 可执行的 PRD 功能目标、业务规则、验收标准
技术方案设计write-tech-design Skill 评审架构可行性 产出方案初稿 技术方案 + API 契约 模块边界、接口约定、架构约束
任务拆解breakdown-tasks Skill 确认优先级与依赖 拆解为可执行单元 WBS 任务列表 单任务输入/输出/依赖/验收标准
Daily Coding Agent编码/单测/CR Skill 审核关键逻辑与架构边界 编码→单测→CR→修复循环 经验证后可交付的代码 代码变更记录、新增接口与规则
上下文更新update-context Skill 审检沉淀结果 回写知识与上下文 更新后的知识资产 下一轮迭代的全量上下文基线

关键洞察:注意"隐性上下文"这一列——需求阶段提供业务意图PRD 阶段将意图转为结构化约束,技术方案阶段将约束收敛为技术决策,任务拆解阶段再将决策压缩为最小执行单元。到 Daily Coding Agent 阶段AI 拿到的已不是一个模糊需求,而是一份高度收敛的任务上下文。

最后一个阶段"上下文更新"负责闭合整个循环:代码变更后上下文同步刷新,确保下一轮迭代时 AI 的输入不会过时。


上下文工程:知识库与分层加载

系统知识库

业务视角 技术视角
功能清单、业务流程、领域知识、状态规则 架构文档、数据模型、API 契约、技术规范

两者之间通过共享术语表打通,确保 AI 在生成内容时,业务概念与技术实现使用同一套语义。

知识库的完整度,直接决定了 AI 理解业务的深度,也决定了首稿在业务逻辑层面的可用程度。

三层加载模型

  • L0项目级:全局一致性
  • L1文件级:局部适配
  • L2任务级:单次任务准确率

核心原则:只在需要的时候给需要的信息。

上下文工程为什么应被视为组织级投入

  1. 决定了 AI 投入能否产生实际回报
  2. 是团队能力的沉淀载体(人员流动冲击减小)
  3. 具备复利效应——正向循环 vs 负向衰减

Skill 体系:上下文工程的可复用封装

Skill-as-Code把团队的工作方法与质量约束写成可版本管理的文本契约而不是散落在聊天窗口里的一次性指令。

文章中提到的 Skill 包括:

  • write-prd:生成结构化 PRD
  • write-tech-design:产出技术方案初稿
  • breakdown-tasks:拆解为可执行单元
  • update-context:回写知识与上下文