# 第 29 章 知识外循环

## 本章目标

- **O1** 能够追踪“现场发现”“产品反馈”“复用资产”之间的前向与反馈路径（产物：知识外循环台账）
  - 证据: 知识外循环台账画出“现场发现”“产品反馈”“复用资产”的前向路径和返回路径
- **O2** 能够构造知识外循环台账，注明每轮输入、判断和回写证据（产物：知识外循环台账）
  - 证据: 知识外循环台账为每一环写明输入、判断、输出和负责人
- **O3** 能够把现场发现回流成产品反馈与可复用资产（产物：知识外循环台账）
  - 证据: 产物记录一项现场发现、产品决定、复用条件和不可泛化边界

## 学习路径

- **初学者**: 本章迁移任务是：能够把现场发现回流成产品反馈与可复用资产。先按图中的“反馈闭环”关系完成知识外循环台账的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够把现场发现回流成产品反馈与可复用资产。提交知识外循环台账后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: 知识外循环台账
- **图解类型**: knowledge-loop
- **关系语义**: 三环先沿前向路径产生结果，再由返回路径把观察写回；没有回写就不构成闭环。
- **核心概念**: 现场发现 · 产品反馈 · 复用资产

![第 29 章知识外循环台账教学图](/learning/diagrams/zh/chapter-29.svg)

沿前向与返回两条路径检查知识外循环台账，确认结果确实改变下一轮输入。

图先从“现场发现”前向经过“产品反馈”到“复用资产”，再以虚线返回起点。前向箭头产生结果，返回箭头承载观察和修正；若结果没有回写到下一轮输入，流程只是单程而不是闭环。

> **公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。

## 课程讲解

### 29.1 把现场模式 codify 成可复用积木

第 28 章讲的是在客户现场怎么做决策、怎么对人；这一章讲的是做完之后怎么办——把现场收获变成团队资产，而不是留在你的笔记本里发霉。

先看一个教学构造的场景。你驻场三周，踩了一个大坑：客户的数据库字段命名和文档里完全对不上，你花了两天理清映射关系。三个月后，另一个同事去另一个客户现场，遇到几乎一样的问题，又花了两天。你俩坐在同一家公司的同一间会议室里，谁也不知道对方踩过同样的坑。这不是能力问题，是知识没有外循环——现场经验困在个人的脑子里，没有流向下一个需要它的人。

OpenAI 的 FDE 招聘描述把这一职责写得很直白：工程师需要 "Codify working patterns into tools, playbooks, or building blocks that others can use"——把验证过的工作模式 codify（编码固化）成工具、playbook 或可复用积木，让其他人可以直接使用。这条职责不是锦上添花，而是 FDE 区别于"高级驻场外包"的关键分界线——后者只交付客户现场的成果，前者还把现场经验反哺回团队与产品。

codify 的三类载体。以下分类与操作规则是本书的教学方法。载体按自动化程度区分，不意味着工具一定比模板更有价值：

| 载体 | 适用场景 | 产物示例 | 维护成本 |
|------|----------|----------|----------|
| 工具 | 模式已经验证、可以自动化 | 数据源探查脚本、评估集自动化 runner、客户环境诊断工具 | 高：需要工程维护 |
| Playbook | 模式需要人判断、但流程可以标准化 | scoping 访谈 checklist、干系人对接操作手册、上线前自检流程 | 中：定期更新即可 |
| 模板 | 模式是文档或记录、结构可以固定 | 项目 scoping 报告模板、ADR 客户版模板、readout 格式模板 | 低：偶尔迭代 |

三种载体不是互斥的，而是递进的。最轻的入手方式是模板——第 28 章的授权边界矩阵、ADR 客户版结构，本身就可以沉淀成模板，下个项目填一份就是。模板用顺了，发现流程里有些判断点反复出现，就升级成 playbook——一份"面对 X 类型客户时，前 48 小时必须完成的 N 件事"。playbook 用久了，发现其中某一步机械重复，就抽出来做成工具。

一个实用的筛选规则是：第二次遇到，列为候选。同一个数据格式转换的 workaround 在两个客户现场各出现一次，就值得比较共性与差异。出现次数只是线索；高风险的首次失败也应立即记录。真正发布积木之前，写清适用条件、输入输出、已验证环境与不适用情形，请没参与原项目的同事用脱敏样例试一遍。能复现才标记可用；失败则补充边界或保留为待验证笔记。开场的字段问题应沉淀为探查与映射核验流程，不能直接把某家客户的字段映射复制给下一家。

codify 的两个纪律。

第一，保持"现场味"。codify 最常见的失败不是做少了，是做过了——把活生生的现场经验抽象成干巴巴的流程文档，读起来像出厂说明书，没有一个人会在真正遇到问题时去翻它。好的 playbook 读起来应该像一个有经验的同事在跟你说话："你会在第三天遇到这个——别慌，按这三步走。"诀窍是保留具体场景和真实判断，而不是抹掉所有上下文只剩抽象步骤。

第二，指定 owner，定更新节奏。每份积木注明负责人、版本、最近验证日期和失败反馈入口；建议每季度复查，相关接口或模型变更时提前复验。仍适用的更新，失效的标记停用并给出替代路径，无维护价值的归档。第 34 章会把责任机制嵌入优化期；个人交出积木时要同时交出这些维护信息。

### 29.2 向产品与模型方反馈：带着 eval 证据的 readout

codify 解决的是知识向团队内部的流动——从你到队友。这一节讲的是另一条通道：知识向产品与模型团队的流动——从你到产品的演进方向。

这条通道容易被忽视。很多 FDE 把自己定位成"交付的人"，现场经验只沉淀到自己团队，到产品方就断了。但 FDE 的职责还包括：把现场验证过的产品与模型弱点，转化为产品团队可以行动的反馈。OpenAI 的 FDE 团队招聘描述将反馈给产品与研究团队的 eval 驱动反馈质量列为成功度量之一（见第 23 章来源说明）。

关键词是 eval-driven——反馈要带着评估数据、失败案例和量化证据，让接收者能够重现问题。

反馈的格式：readout。第 23 章把 eval 驱动的反馈闭环已经完整地立了起来——变更触发矩阵、基线锁定、四个决策出口——那条闭环的内环是给自己的决策服务，外环就是本节的主题：把 eval 证据包装成产品团队可消费的 readout。

本书把 readout 定义为一份结构化反馈文档，邮件或共享文档都可以承载它。以下为教学假设，数字与案例不代表真实客户或模型表现：

| 要素 | 说明 | 示例 |
|------|------|------|
| 现场事实 | 具体发生了什么，客户怎么说 | "客户医疗团队反馈：病历摘要对缩写词的还原准确率不够" |
| eval 证据 | 固定口径的分子、分母与版本 | "golden set v3、judge v2、同运行口径下，基线配置通过 54/60，新配置通过 40/60；附配置版本与复跑记录" |
| 失败模式与待验归因 | 区分观察与原因假设 | "部分缩写被扩写成无依据的术语；领域词典缺失是待验证假设，尚不能认定是模型根因" |
| 影响面 | 明确样本范围与业务阻碍 | "本测试集专门覆盖缩写，不能外推为全部病历错误率；受影响摘要需人工复核" |
| 建议 | 接收方能执行的下一步 | "请产品负责人安排词典约束对照实验，以第 23 章五维结果决定是否采纳；附最小脱敏复现" |

readout 的节奏。反馈不是项目结束后的"回忆录"，而是贯穿项目生命周期的持续输入。三个固定时间点值得产出 readout：

1. scoping 结束时：产出"第一印象 readout"——数据现状、客户约束、产品覆盖缺口。这些信息对产品团队的优先级排序极有价值，因为它们来自真实客户环境，不是实验室假设。
2. 验证期中期：产出"eval 爬坡 readout"——模型在客户数据上的五维表现（第 21 章的正确性/幻觉率/格式/成本/延迟）、与基线的差距、最大的退化类别。这是产品团队最需要的信号——模型在真实场景里到底哪里不行。
3. 交付期收尾时：产出"生产表现 readout"——上线后的 production adoption 数据（第 26 章 26.3 节）、用户行为模式、新暴露的失败模式。区分观察窗口与正式指标：不足上线后 30 天的记录注明为阶段观察，不冒充该章定义的 30 天采用率。

三个时间点是本书建议的节奏，scoping 尚无 eval 时明确标为待验证假设。重大失败及时进入项目升级通道，同时准备 readout。向产品或模型方发送前，按第 28 章授权矩阵确认披露范围、接收人和数据去向；脱敏不等于自动获得授权。不能外传原始样本时，提供获准的合成复现或留在客户环境内核验。

反馈通道本身也需要维护。每份 readout 记录接收负责人、待作决策、约定回复日期与状态。产品团队说"暂时不改"，保留原因和现场替代方案；接受修改后，由 FDE 在相同口径下复验，再向客户更新结论。第二家客户遇到同类问题时，补充边界一致的证据，不能仅凭客户数量声称根因相同。闭环的完成是结论回流，不只是文档发出。

### 29.3 团队级机制：从个人习惯到组织能力

前两节讲的是 FDE 个人的两项知识外循环职责：codify 成积木，带着 eval 证据反馈产品方。但这两件事如果只靠个人自觉，结果是可以预见的——能力最强的人偶尔做，其他人从不做，团队的知识库永远是碎片化的。

要让知识外循环从个人习惯变成组织能力，需要三个团队级机制。这三个机制的建制化细节（怎么搭、怎么运营、怎么嵌入导入流程）是第 34 章和第 35 章的内容——那两章讲团队导入路线图和培训方案，会在优化期一节具体展开 bootcamp 式训练营的搭建方法和"一次性课程→常态化节奏"的运营方案。本节只讲这三个机制是什么、为什么需要，以及 FDE 个人在其中的职责，为后续两章的建制化落地做铺垫。

机制一：Field Notes 频道。它是现场笔记的共享入口，可以用团队频道或内部文档空间承载。FDE 记录一句事实、适用场景、证据链接和是否待验证；只有已获准共享的内容才进入对应权限空间。客户原始数据和私下信息不因"内部频道"而自动可披露。个人负责准确记录和回应追问，轮值维护者负责聚合同类条目；模式需要有人比较、验证，不会因笔记堆积而自动成立。

机制二：双周分享。它让现场笔记接受同伴追问：证据能否复跑？换一个客户还成立吗？哪些条件被省略了？FDE 轮流带来一条发现和失败边界，也可以讲试用别人积木时遇到的问题。分享应留下一个结论或下一步验证任务；暂未定论就保留分歧。第 35 章给出排班、时长与归档模板，本章强调个人要带证据参与，而不是只作进度汇报。

机制三：bootcamp 式训练营。集中实操让团队在同一组案例上校准判断：能否复现失败、用积木解决问题、说出不可复用的边界。据 The Pragmatic Engineer 2025 年 8 月对 OpenAI FDE 负责人的采访，团队通过季度 bootcamp、双周分享和 Field Notes 进行知识交流。这里借鉴的是持续交流的机制；本书建议的训练时长、运营方式以及按需加密频次，均为教学设计。FDE 参加训练后应把试用问题交回资产 owner，并在下个项目记录使用结果；组织者如何选题和验收，见第 35 章。

三个机制的关系是一条从碎片到共识的流水线：Field Notes 是原料采集，双周分享是初步加工，bootcamp 是精炼与交付。FDE 个人在这条流水线上的职责清晰——日常往 Field Notes 扔碎片，定期轮流做分享，参加 bootcamp 并带回校准后的实践。第 34 章会把这些职责嵌入导入路线图的优化期，第 35 章会给出运营细节，这里只需要记住一句话：知识外循环不是额外工作，是 FDE 工作的内在组成部分。

【自检清单】知识是否真的流出去了

- [ ] 积木有适用边界、复现样例、版本与负责人吗？
- [ ] readout 的数字具有相同基线口径，并区分事实与根因假设吗？
- [ ] 共享内容和接收对象都在客户授权范围内吗？
- [ ] 反馈有人接收、有人跟进，修改结果已回到现场复验吗？

### 【练习】把口腔诊所项目的现场经验推入知识外循环

题目：接续第 27、28 章的虚构口腔诊所项目，进入交付期第三周。以下为教学假设：①已有 ADR 和"提议而非询问"邮件；②同版本的 100 条术语用例中，新配置出现无依据扩写 18 条，基线为 6 条，golden set、judge 与运行口径固定；③IT 主管私下告知兼容问题，但尚未确认可向产品团队披露。请产出：一份五要素 readout、一条不超过三句话的 Field Note、一份 bootcamp 五分钟分享大纲。注明证据版本、待验假设、接收人、下次跟进日期与披露边界；未给出的信息标为待补，不能编造已获授权或已确认的根因。

引导：重点体验三个转化。①把观察变成可复跑证据：18/100 是本用例集的发现，不是全部病历的风险率，也不证明根因。②把个案变成候选模式：设计一个对照实验，验证词典或上下文是否影响无依据扩写。③把候选模式送入持续机制：分享后由谁补证据、何时回看、什么结果足以发布为 playbook？

参考方向（供讲师参考）：评阅看证据可比性、事实与假设的区分、共享授权和后续责任四项。Field Note 应能引导队友找到证据，不能只是复制整份 readout；训练大纲应包含复现与边界讨论。兼容问题即使对产品有用，也需先核实并确认披露授权；暂不获准时，只在客户授权空间跟进，不把私下信息放入全员频道。

---

> 本章业界事实的来源说明：工作模式沉淀为工具、playbook 与积木的英文引文出自 OpenAI FDE 公开招聘描述；eval 驱动反馈作为成功度量的表述沿用第 23 章所引 OpenAI FDE 团队招聘描述。季度 bootcamp、双周分享与 Field Notes 的出处为 The Pragmatic Engineer 2025 年 8 月对 OpenAI FDE 负责人 Colin Jarvis 的采访，均沿用本书已核验的业界材料。载体分类、维护规则、readout 五要素与反馈时点、练习数据均为本书教学设计，不代表特定公司的内部流程或实测效果。

---

> 第九部分完成。你已经掌握了客户交付的三条主线：第 27 章给了项目级的三阶段节奏和四套流程模型的统一映射，第 28 章给了与客户干系人分层协作和模糊授权下自主决策的方法，本章把现场经验推入知识外循环——codify 成可复用积木、带着 eval 证据向产品方反馈、通过团队机制让个人发现变成组织能力。贯穿三章的主线只有一句话：方法论的终点不是一套能跑的系统，而是客户的工作流真的因此改变——并且你的经验能让下一个客户的工作流更快地改变。下一部分（第 30–33 章）进入团队协作与交付文化：异步优先、高信任、高自主与任务生命周期——那是 FDE 与自己团队协同的底层操作系统，与本部分面向客户的交付协作形成对偶。

---

## 独立练习

使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 `chapter-29.md`，写上版本、决定、证据和缺项。

从一次未知类别误判中提炼模板、工具和产品需求各一项，写来源脱敏、主责、版本和复用验证方式。

<!-- chapter-artifact-requirement -->
### 本章必交产物：知识外循环台账

以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。

- O1: 知识外循环台账画出“现场发现”“产品反馈”“复用资产”的前向路径和返回路径
- O2: 知识外循环台账为每一环写明输入、判断、输出和负责人
- O3: 产物记录一项现场发现、产品决定、复用条件和不可泛化边界

<details>
<summary>查看参考反馈（先独立作答）</summary>

## 参考反馈

模板记录未知处理问题；工具添加可复用拒猜检查；产品需求描述跨项目共同限制并附授权证据。删除客户标识和原文并确认可分享性；脱敏不自动等于可公开。复用需另一个任务验证，不能把整理文档当采用成效。

### 自评与下一步

对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。

</details>

## 来源与边界

登记来源只支持本章涉及的外部事实；知识外循环台账、示例数字和练习情境属于课程内部教学设计，必须在实际项目中重新验证。

- [Forward Deployed Engineer 旧金山职位说明](https://openai.com/careers/forward-deployed-engineer-(fde)-sf-san-francisco/) — OpenAI, 2026-09-28. 该岗位涵盖发现、技术定界、系统设计、构建、上线、采用和现场反馈；这是 OpenAI 的岗位说明，不是行业统一标准。
- [FDE 的起源、角色区分与 OpenAI 工作阶段访谈](https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers) — The Pragmatic Engineer, 2026-09-17. 该访谈报道 FDE 起源脉络、OpenAI 的 SA/FDE 区分、客户项目三阶段及团队知识分享节奏；属于二手访谈材料，不代表行业通用标准。