面向谁

团队内已有少数人用 AI 用得明显更好、但这种好无法解释也无法传授的组织; 以及希望把协作过程沉淀为团队资产而非个人技巧的负责人。

解决什么问题

这是一个容易被误判为培训问题的处境, 但它不是。

• 用得好的人说不出自己做了什么——"感觉这样问比较好"。既然说不出, 就传不下去。
• 团队各自摸索, 同一问题的做法差异很大, 而差异的好坏无法比较, 因为没有共同判据。
• 每一次协作都是一次性的, 上一次的判断与教训不进入下一次。★ 于是团队的能力停留在个人水平, 不随人数增长。

通用的提示词培训解决不了这个——它教的是技巧, 而缺的是判据与沉淀机制。

我们怎么做

1. 观察真实工作, 而非访谈。请用得好的人实际做一遍, 我们记录他实际做了什么——多数关键动作他自己不会提。
2. 提取判据。把"他凭什么认为这个产出可以用"显性化, 这通常是整个过程中最有价值也最难获得的部分。
3. 写成可检查的步骤, 基于人机共创框架裁剪到该团队的实际场景。
4. 在真实任务上试跑, 由未参与提取的人执行, 检验方法是否真的可传递。
5. 建立沉淀机制: 判据、否决理由、失败案例的记录方式与维护责任人。

若其中有环节适合固化为 Agent, 按 Agent 设计方法处理。

交付什么

• 团队专属的协作方法文档: 步骤、判据、完成标志、典型失败
• 失败案例库的初始版本与后续维护规范
• 试跑记录: 由非提取者执行的结果与差异分析
• 沉淀机制: 记录模板、维护责任与复查节奏
• 视情况: 若干固化为 Agent 的环节及其契约

什么情况下不适合

★ 以下情况不适合:

• 团队里还没有人用得好。 没有可提取的隐性技巧时, 这是培训需求而非方法导入需求。
• 不愿意付外化的成本。 把隐性判断写出来对个人是额外负担、收益归团队; 若组织不认可这个交换, 方法不会被采用。
• 只想要速度。 本方法前期一定更慢, 收益出现在复用之后。
• 没有人负责维护沉淀。 无人维护的记录三个月内就会失效, 那样整个导入是浪费。