AI 编程进团队：高手经验沉淀为可复用工序¶
Ch04.642 AI 编程进团队：高手经验沉淀为可复用工序¶
📊 Level ⭐⭐ | 5.3KB |
entities/ai-coding-team-expert-knowledge-process-workflow.md
AI 编程进团队：高手经验沉淀为可复用工序¶
核心洞见：团队在 AI 编程上的效果差异，根本原因不是提示词或模型选择，而是隐式工程经验没有被系统化为可复用的工序（Process）。高手真正的价值在于提示词前后——补上下文、设边界、验 diff、留证据、回写规则，这些动作构成了可传授的 Agent 工序。
问题：提示词只是入口¶
当团队引入 AI 编程后，常见的做法是收集提示词："需求分析 Prompt""架构师 Prompt""测试用例 Prompt"。提示词记录的是"向模型说了什么"，但高手经验更大的部分在提示词之外——他说这句话之前做了什么，以及模型回答之后他怎么验证。
一个用 AI 很顺的人，拿到模糊需求时不会直接让模型写代码。他会先看需求改了哪条业务链路、哪些历史兼容不能破、哪些数据口径不能变、哪些地方需要人来拍板。这些动作来自工程经验，而非提示词技巧。
如果这套经验只留在一个人的脑子里，AI 不会变成团队能力，只会变成少数人的个人工具。
方法论：从工作痕迹中发现高手动作¶
与其收集提示词，不如先做一件更笨的事：看工作痕迹。抽几份真实任务，沿着对话记录、diff、文档改动、Review 记录往回看。
四个观察点： - 什么时候补上下文 - 什么时候让 AI 停下来 - AI 改了什么、人又改了什么 - Reviewer 追问了什么，最后靠什么收口
通过"工作痕迹"发现隐式知识，与 知识沉淀实践 中"知识是护城河"的理念一脉相承，但更侧重于可观察、可提取的方法。
核心概念：Agent 工序¶
一道 Agent 工序要说明：什么时候进来，读什么材料，做哪些检查，遇到什么停，输出什么证据，谁来确认。
这不同于 Skill（封装能力单元）或 Workflow（编排流程）。工序是知识传递的原子单位——它编码的是一段具体的工程决策经验。与 腾讯知识沉淀体系 中强调的上下文工程和持续治理一致，但在"工序"这一概念上更具体。
高手经验的内容构成¶
- 补上下文：相关接口、旧系统约束、灰度方式、测试命令、团队代码风格、过去踩过的坑
- 切边界：判断哪些风险不能交给模型判断，设定 AI 的决策范围
- 设停止点：明确 AI 在什么条件下应停下等待人工判断
- 验 diff：不仅看"能不能跑"，还要看 diff、跑测试、查日志、模拟真实路径
- 留证据：让结果留下可供追溯的工程记录
- 回写规则：失败原因写回规则、脚本、Skill 或检查清单
实施路径¶
文章建议的落地路径： 1. 找一个返工高发点——选择团队中反复出错的环节 2. 影子跑 30 天——让 Agent 工序在真实任务中并行运行，观察是否能提前暴露遗漏 3. 不要急于做大平台——先验证工序的有效性，再考虑规模化
这种渐进式思路与 Qoder 团队知识引擎 的"从实践中提炼"的理念一致。
价值衡量标准¶
相比传统的"节省多少小时"指标，文章建议用四个维度衡量价值： - 评审有没有更聚焦 - 返工有没有提前 - 交接有没有更清楚 - 经验有没有进入下一轮
这与 高德 SDD 团队 的 AI 编码范式中"过程评估优于结果评估"的理念类似。
→ 原文存档