FDE Wiki

深色模式

学术与理论基础 ​

给想把 FDE（Forward Deployed Engineer，前线部署工程师）这件事做扎实的人：当你要向客户、老板或自己解释「为什么这样交付有效」时，这一页给你可查证的学术依据。每条文献都标了作者、年份、发表处、可点开的链接、一句话核心发现，以及对 FDE 工作的具体启示。

FDE 是一个实践先行的岗位，几乎所有流行说法都来自公司博客和从业者经验，学术界并没有「FDE 研究」这个领域。但 FDE 每天做的事——判断哪些任务该交给 AI、把隐性的业务知识变成机器能用的 Context、设计 Eval、推动一个组织改掉旧流程、算清这笔账——每一件都有几十年的成熟研究可查。这一页做的是把这些散在不同学科的证据接到 FDE 的工作流上。

配套页面：机构与行业报告见 industry-reports.md，术语定义见 ../00-start/glossary.md，方法论落地见 ../04-methodology/README.md。

怎么用这一页 ​

这是一页查阅用的索引，不必从头读到尾。九个小节分别对应 FDE 工作的不同环节：一、企业 AI 采纳与生产力｜二、技术采纳与扩散｜三、咨询、变革与社会技术系统｜四、知识管理与隐性知识｜五、LLM 与 agent 的评估｜六、Context engineering 与 agent 架构｜七、精益、持续改进与复盘｜八、软件工程：需求发现、数据就绪与 MVP｜九、10 篇精选。赶时间就直接跳到第九节。

四个提醒。

第一，区分证据等级。 本页文献大致分四档，正文中会标注：

等级含义本页例子
A 随机对照试验（RCT）/ 准实验有对照组、可推断因果Brynjolfsson 等 2025、Dell'Acqua 等 2026、Noy & Zhang 2023、METR 2025
B 大样本观测 / 面板数据有规模但因果推断弱Brynjolfsson 等《Canaries》、Chatterji 等 2025
C 理论框架 / 案例研究提供语言和视角，不提供效应量Rogers、Schein、Nonaka、Orlikowski
D 从业者论述 / 行业博客一手经验，无系统验证Anthropic 工程博客、Karpathy

D 档不等于没价值——Context engineering 这类领域，最好的材料就在 D 档，因为学术界还没跟上。但引用时要说清楚是哪一档。

第二，注意时间。 2023 年的 AI 生产力研究测的是 GPT-3.5/GPT-4 时代的裸模型对话，2026 年的现场已经是 agent + 工具 + 长上下文。结论不能直接跨代搬运——METR 自己就在 2026 年 2 月公开说明了这一点（见下）。

第三，注意口径。 「AI 让人快 55%」和「AI 让人慢 19%」可以同时成立，因为一个测的是新手写全新的 HTTP server，一个测的是资深维护者改自己的大型开源仓库。看到数字先问三件事：谁、什么任务、跟什么比。

第四，「对 FDE 的启示」是本库的推论，不是原文主张。 本页几乎所有文献都不是为 FDE 这个岗位写的，多数作者写作时这个岗位还不存在。每条文献的前半段（作者、年份、发表处、核心发现）是文献实际说了什么，可以直接引用；标着「对 FDE 的启示」的那一段是本 Wiki 把它接到 FDE 工作上的推论，转述时请注明这是推论，不要写成原作者的观点。

文献与 FDE 工作流的对应 ​

一、企业 AI 采纳与生产力 ​

这是 FDE 最需要的一组证据：AI 到底在什么条件下提高生产力，在什么条件下降低。这也是唯一一个已经积累了严格 RCT 的领域。

FDE 的价值主张——「模型能力不是瓶颈，落地方式才是」——如果成立，就必须能在这组文献里找到支撑：同样的模型，不同的部署方式，效应量差异巨大。下面这些研究恰好显示了这一点。

Brynjolfsson, E., Li, D., & Raymond, L. (2025). Generative AI at Work. The Quarterly Journal of Economics, 140(2), 889–942. DOI 10.1093/qje/qjae044。工作论文版 NBER w31161（2023）。证据等级 A（分阶段推广的准实验）。

在一家企业软件公司的客服部门追踪 5,172 名坐席，观察生成式 AI 对话助手分阶段上线的效果。平均每小时解决的问题数提升 15%，但差异极大：低技能、新入职的坐席提升最多，高技能坐席速度略增而质量略降。作者的解释是 AI 把资深员工的隐性知识提取出来传给了新人。附带发现：客户对使用 AI 辅助坐席的态度更礼貌，要求转接主管的比例下降。

对 FDE 的启示：这是「AI 把老师傅的手艺规模化」这一说法最有力的一手证据，也是 FDE 做知识密集型岗位改造时最值得引用的研究。同时它警告——如果你的用户是团队里最强的那批人，效应可能接近零甚至为负，选场景时优先找「能力方差大、底部人数多」的岗位。

Dell'Acqua, F., McFowland III, E., Mollick, E., Lifshitz, H., Kellogg, K. C., Rajendran, S., Krayer, L., Candelon, F., & Lakhani, K. R. (2026). Navigating the Jagged Technological Frontier. Organization Science, 37(2), 403–423. DOI 10.1287/orsc.2025.21838。工作论文版 HBS Working Paper 24-013 / SSRN 4573321（2023 年 9 月）。证据等级 A（预注册现场实验）。

与 BCG 合作，758 名咨询顾问（约占该公司个人贡献者层级的 7%）被随机分配是否可用 GPT-4，完成 18 项真实咨询任务。在能力边界之内的任务上，用 AI 的人多完成 12.2% 的任务、快 25.1%、盲评质量评分高约 40%；但在一项刻意设计在能力边界之外的任务上，用 AI 的人给出正确答案的概率反而低 19%。

对 FDE 的启示：「参差的技术边界」（jagged frontier）是 FDE 最该内化的概念——AI 的能力边界不是一条平滑曲线，相邻的、看起来同样难的两个任务可能一个能做一个做不了，而且从外部看不出来。FDE 的核心手艺之一就是替客户把这条边界摸出来，写进交付范围里。这项研究还提示要防的具体失败模式：用户对 AI 输出过度信任，在边界之外反而比不用更糟。

Noy, S., & Zhang, W. (2023). Experimental evidence on the productivity effects of generative artificial intelligence. Science, 381(6654), 187–192. DOI 10.1126/science.adh2586。证据等级 A（预注册线上实验）。

453 名受过大学教育的专业人士做职业相关的写作任务，随机一半可用 ChatGPT。平均耗时下降 40%，质量评分提高 18%，且能力较弱者受益更多、组内差距缩小。任务结构发生迁移：起草时间减少，构思和编辑时间增加。

对 FDE 的启示：这是「AI 压缩能力方差」证据链的第二根支柱，也提示交付设计的方向——把人的时间从起草挪到判断和编辑，工作流要相应重排，而不是简单地在原流程里插一个「AI 写初稿」按钮。

Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv 2302.06590。证据等级 A（对照实验），但任务高度人工。

招募开发者用 JavaScript 实现一个 HTTP server，有 Copilot 的组比对照组快 55.8%，经验较少者提升更大。

Cui, Z. K., Demirer, M., Jaffe, S., Musolff, L., Peng, S., & Salz, T. (2025). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. Management Science. DOI 10.1287/mnsc.2025.00535。预印本 SSRN 4945566。证据等级 A。

在 Microsoft、Accenture 和一家匿名的财富 100 强公司做三组 RCT，合并 4,867 名开发者，完成任务数提升 26.08%，经验较少者采纳率和收益都更高。一个常被忽略的发现：三家公司一年后的平均采纳率只有约 60%——即使工具好用、公司推动，采纳本身也需要时间。

对 FDE 的启示：把 Peng 2023、Cui 2025 和下面的 METR 2025 放在一起读，就能看清 FDE 面对的真实局面——同一类工具，在人造任务上 +55.8%，在企业真实任务上 +26%，在资深开发者的大型开源仓库上 −19%。任务越接近「有大量隐含约束的存量系统」，AI 的净收益越低。而 FDE 的战场恰恰全在存量系统里。「一年后采纳率 60%」这个数字则直接说明了为什么交付不能在上线日结束。

METR (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv 2507.09089，官方说明页。证据等级 A（RCT），但样本小（16 名开发者、246 个任务）。

16 名资深开源开发者在自己的仓库（平均 22k+ star、百万行量级）上做 246 个真实任务，随机分配是否允许用 AI（主要是 Cursor Pro 配 Claude 3.5/3.7）。结果：允许用 AI 时实际慢 19%，而开发者事前预计会快 24%、事后仍认为自己快了 20%。

METR (2026). We are Changing our Developer Productivity Experiment Design. metr.org/blog/2026-02-24-uplift-update/。证据等级 D→A 之间（方法学说明）。

METR 在 2025 年 8 月启动了更大规模的续作，但在 2026 年 2 月公开承认数据不可用：越来越多开发者拒绝参加「不许用 AI」的对照组，30%–50% 的参与者会跳过某些任务因为不愿意不用 AI 做，选择效应把估计值系统性压低。METR 表示据与参与者的交流判断，2026 年初的加速效果很可能已经高于 2025 年初，但自己的数据只能作为「非常弱的证据」，并转向按开发者随机化、更短实验和观测数据。

对 FDE 的启示：这一对研究是本页最重要的方法论教材，有三层价值。一是「主观感受与客观测量可以反向」——这直接说明了为什么 FDE 必须建立 Eval 和基线测量，不能靠客户满意度问卷验收（见 ../04-methodology/evaluation.md）。二是这个 19% 常被断章取义为「AI 让程序员变慢」，实际口径极窄（资深维护者、熟悉的大型代码库、2025 年初的工具）。三是 METR 主动撤回自己续作结论的做法，本身就是一份关于「怎么诚实地报告交付效果」的示范。

Kim, H., Kim, D., & Koning, R. (2026). Mapping AI into Production: A Field Experiment on Firm Performance. SSRN 6513481，HBS Working Paper 68814。证据等级 A（现场实验）。

依托 INSEAD 的三个月全球创业加速器（AI Founder Sprint）做实验，515 家高成长初创公司（中位数 4 人、2024 年成立）全部获得约 2.5 万美元 API credits 和合作方工具。随机分配的处理组额外收到一批案例研究，讲 AI 原生公司如何重组生产流程、团队和商业模式；对照组上通用创业方法工作坊。处理组多发现 44% 的 AI 用例（集中在产品开发和战略），多完成 12% 的任务，获得付费客户的概率高 18%，收入高 1.9 倍。

对 FDE 的启示：这可能是目前对 FDE 这个岗位存在意义最直接的学术支撑。作者把核心摩擦命名为「映射问题」（the mapping problem）——发现 AI 在本企业生产流程中的哪里、以何种方式创造价值。实验证明，光给算力和工具不够，给「别人怎么重组流程」的具体知识就能显著改变结果。FDE 干的正是这份把外部映射知识带进客户组织的活。注意：样本是初创公司而非大企业，外推到大型组织时要谨慎。

Brynjolfsson, E., Rock, D., & Syverson, C. (2017). Artificial Intelligence and the Modern Productivity Paradox: A Clash of Expectations and Statistics. NBER Working Paper 24001。配套的 Productivity J-Curve（Brynjolfsson, Rock & Syverson）见 NBER Working Paper 25148 及 MIT IDE 简报。证据等级 B/C。

通用目的技术需要大量互补性的无形投资——流程重设计、组织重构、技能培养——这些投资在统计上被系统性地误计，导致先出现一段测得的生产力下降，然后才加速上行，即「生产力 J 曲线」。作者用电力（1890–1940）和 IT（1970 年后）两次转型佐证：都有大约四分之一世纪的低速期。

对 FDE 的启示：这是回答「为什么我们买了模型却没看到 ROI」最好的框架，也是 FDE 岗位的经济学理由——J 曲线底部那段沟里填的东西（流程重设计、领域知识编码、组织配套）正是 FDE 的产出。同时这也是一把双刃剑：它可以解释真实的滞后，也可以被用来无限期地推迟兑现承诺。FDE 引用它时必须配上可测的里程碑，否则就成了免责话术。

Brynjolfsson, E., Chandar, B., & Chen, R. (2025/2026). Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence. Stanford Digital Economy Lab，项目页，2026 年 8 月修订版 PDF，另有 Canaries Dashboard 持续更新。证据等级 B（大样本观测）。

用 ADP 的高频个体薪资数据，把数百万工人记录连到职业 AI 暴露度指标上。截至 2026 年 8 月版本：22–25 岁年轻工人在高 AI 暴露职业中的就业，比「跟上低暴露同龄人步伐」的反事实低 19%；有经验的工人没有相应缺口；机制主要是减少招聘而非增加解雇；没有证据显示全经济范围的大规模替代。

对 FDE 的启示：与 ../08-career/job-market-and-jds.md 直接相关——入门级岗位在收缩，而 FDE 这类需要同时具备领域理解和工程能力的岗位在扩张，这是转行者做判断时应该看的一手数据，而不是自媒体转述。

Chatterji, A., Cunningham, T., Deming, D. J., Hitzig, Z., Ong, C., Shan, C. Y., & Wadman, K. (2025). How People Use ChatGPT. NBER Working Paper 34255。证据等级 B（企业内部数据，第三方无法复现）。

基于 2024 年 5 月至 2025 年 6 月的 110 万条去标识化消息，用分类器在隐私保护环境内分析。到 2025 年 7 月每周约 180 亿条消息、7 亿用户；非工作类消息占比从 53% 升到 70% 以上；受教育程度高、专业岗位的用户更可能用于工作。

对 FDE 的启示：注意这是厂商自己发布的数据，独立方无法复核，属于需要交叉验证的一类来源。它的用处在于说明消费级使用与企业级使用是两条曲线——个人用得很爽，不等于组织拿到了 P&L 上的收益，这一点在 industry-reports.md 里的 MIT NANDA 报告中被推到极致。

二、技术采纳与扩散 ​

FDE 交付失败最常见的原因不是模型不行，而是没人用。这一组是几十年积累的成熟理论，效应量和边界都被反复检验过。

Rogers, E. M. (2003). Diffusion of Innovations (5th ed.). Free Press。出版社页。证据等级 C（综合数千项实证研究的理论体系）。

创新扩散的经典框架：采纳者分为创新者、早期采纳者、早期大众、晚期大众、落后者；影响扩散速度的五个属性是相对优势、兼容性、复杂性、可试性、可观察性。

对 FDE 的启示：这五个属性可以直接做成交付前的检查清单。特别是「可试性」和「可观察性」——FDE 圈内常说的「做一个能在会议室里当场跑给业务看的 demo」，在 Rogers 的框架里就是同时拉高这两个属性。而「兼容性」解释了为什么最优雅的方案经常输给最贴合现有流程的方案。

Davis, F. D. (1989). Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology. MIS Quarterly, 13(3), 319–340. DOI 10.2307/249008。证据等级 A/B（量表开发与验证，152 名用户、四个应用）。

技术接受模型（TAM）：感知有用性和感知易用性共同决定使用意愿，其中感知有用性与实际使用的相关性更强（研究一 r=.63，研究二 r=.85），而易用性更多是通过影响有用性起作用。

Venkatesh, V., Morris, M. G., Davis, G. B., & Davis, F. D. (2003). User Acceptance of Information Technology: Toward a Unified View. MIS Quarterly, 27(3), 425–478. DOI 10.2307/30036540。MISQ 官方页。证据等级 A/B。

UTAUT 整合了八个既有模型，归纳出四个决定性构念：绩效期望、努力期望、社会影响、便利条件。

对 FDE 的启示：TAM/UTAUT 给了一套可以直接做成问卷的采纳诊断工具。实践含义很明确——「感知有用」比「好用」权重更高，所以把用户第一次接触时的价值做足，比把 UI 打磨得更顺滑更重要；「社会影响」和「便利条件」两项则说明单靠工具本身不够，需要主管公开背书和真实的支持通道。注意这两个模型都是在传统信息系统时代建立的，对生成式 AI 这种输出不确定的系统是否完全适用，学界尚在检验。

Moore, G. A. (2014). Crossing the Chasm (3rd ed.). Harper Business。出版社页。证据等级 D（从业者理论，无系统实证）。

在 Rogers 的采纳曲线上，早期采纳者与早期大众之间存在一道「鸿沟」，两类人买东西的理由完全不同：前者要变革优势，后者要参考案例和完整方案。跨越的方法是选一个足够窄的滩头阵地做到彻底可靠。

对 FDE 的启示：这本书解释了企业内部推广的典型死法——第一个部门试点成功，推第二个部门时发现对方要的是「已经有人用过并且不出事」的证据。所以 FDE 的第一个项目不只是交付，还是在生产可复用的参考案例。参见 ../05-practice/demo-to-production.md。

Argyris, C. (1991). Teaching Smart People How to Learn. Harvard Business Review, 1991 年 5–6 月号。HBR 页面，ERIC EJ428042。相关的双环学习概念另见 Argyris 于 1977 年在 HBR 发表的《Double Loop Learning in Organizations》【期号待核实】。证据等级 C。

单环学习是在既有目标下纠错，双环学习是回头质疑目标和背后的假设本身。Argyris 的反直觉发现是：越是高学历、高绩效的专业人士越不擅长双环学习，因为他们很少经历失败，遇到批评时会启动防御性推理，把问题归到外部。

对 FDE 的启示：这解释了 FDE 在客户现场最难的一类阻力——不是能力不足的人反对，恰恰是最专业、最资深的那批人最难接受「你的流程本身可能是错的」。也解释了为什么 AAR/复盘（见第七节）必须有明确的规则和主持人，否则默认会退化成单环。

三、咨询、变革与社会技术系统 ​

FDE 与传统 IT 交付最大的区别在于介入方式：不是接需求文档做实现，而是进到客户的工作现场重新定义问题。这套关系怎么建立，咨询学派研究了半个世纪。

Schein, E. H. (1999). Process Consultation Revisited: Building the Helping Relationship. Addison-Wesley，ISBN 9780201345964。Internet Archive 借阅。证据等级 C。

Schein 区分三种帮助模式：专家模式（客户知道问题，买答案）、医生模式（客户交出症状，顾问诊断开方）、过程咨询模式（顾问帮客户自己看清问题并建立解决能力）。他的主张是前两种在复杂组织问题上大多失败，因为顾问永远不可能比客户更了解自己的处境，真正的杠杆在于建立一段能让客户说真话的帮助关系。

对 FDE 的启示：FDE 岗位描述里那句「和客户坐在一起」在 Schein 的语言里就是从医生模式切换到过程咨询模式。三种模式的区分也给了 FDE 一个实用的自检——当你发现自己在写「解决方案建议书」而不是在客户的工位边上看他们怎么干活时，你已经滑回医生模式了。

Block, P. (2011). Flawless Consulting: A Guide to Getting Your Expertise Used (3rd ed.). Pfeiffer/Wiley，ISBN 9780470620748。Wiley 页面。证据等级 C/D。

核心是「缔约」（contracting）：在动手之前把双方的期待、各自要投入什么、成功标准是什么、什么情况下叫停，明确谈清楚并留下书面记录。Block 的观点是绝大多数咨询失败在缔约阶段就已经注定，而不是在执行阶段。

对 FDE 的启示：这是 FDE 最容易跳过也最贵的一步。AI 项目的缔约还多了几件传统项目没有的事——数据可用性由谁负责、模型不确定输出的验收标准怎么定、Eval 集由谁来标、上线后谁维护。缔约模板见 ../06-toolbox/templates.md。

Kotter, J. P. (1995). Leading Change: Why Transformation Efforts Fail. Harvard Business Review。HBR 页面。文献引用中该文常被标为 1995 年 3–4 月号第 59–67 页，而 HBR 官网的 URL 归档在 1995 年 5 月，引用时注意这一差异。证据等级 C（基于 100 多家公司十年观察，非受控研究）。

变革失败的八类错误：紧迫感不足、指导联盟不够有力、缺少清晰愿景、愿景沟通量少了一个数量级、没有清除障碍、没有系统地制造短期胜利、过早宣布胜利、没有把变革锚进文化。

对 FDE 的启示：「没有系统地制造短期胜利」和「过早宣布胜利」这一对，正好对应 AI 交付里最常见的两种死法——demo 惊艳但半年没有第二个用例，以及试点成功后团队撤离、系统在六个月内腐烂。

Trist, E. L., & Bamforth, K. W. (1951). Some Social and Psychological Consequences of the Longwall Method of Coal-Getting. Human Relations, 4(1), 3–38. DOI 10.1177/001872675100400101。证据等级 C（田野研究，社会技术系统学派奠基作）。

Tavistock 学派研究英国煤矿引入长壁采煤法的后果：技术上更先进的新方法反而降低了产量、增加了缺勤，因为它拆散了原有自主小组的社会结构。由此提出社会系统与技术系统必须联合优化，只优化其中一个会让整体变差。

对 FDE 的启示：这是 1951 年就写清楚的道理，七十多年后 AI 落地在重演同一件事——把一个环节自动化，往往破坏了上下游之间原本靠人际沟通维持的隐性协调。FDE 做流程改造前应该问：这个环节现在除了产出物，还在传递什么信息、维持什么关系。

Orlikowski, W. J. (2000). Using Technology and Constituting Structures: A Practice Lens for Studying Technology in Organizations. Organization Science, 11(4), 404–428. DOI 10.1287/orsc.11.4.404.14600。INFORMS 页面。证据等级 C。

技术的结构不是内嵌在软件里、等着被「采纳」的固定物，而是人在日常实践中反复使用时「演绎」（enact）出来的。同一套系统在两个部门会长成两种不同的东西。

对 FDE 的启示：这给了「同样的产品，在 A 客户成功在 B 客户失败」一个理论解释，也说明为什么 FDE 的交付物不能只是软件——真正决定结果的是使用实践，而实践是在现场共同长出来的。这也是「产品化能不能取代 FDE」这场争论的理论焦点，相关立场见 ../01-lineage/debates-and-critiques.md。

四、知识管理与隐性知识 ​

FDE 工作里最不可替代的那部分——把客户脑子里说不清楚的东西变成模型能用的 Context——在知识管理领域有一整套成熟语言。

Polanyi, M. (1966). The Tacit Dimension. University of Chicago Press（有多个重印版）。证据等级 C（哲学论述）。

「我们知道的比我们能说出来的多」（We can know more than we can tell）。隐性知识不是尚未被写下来的显性知识，而是在结构上无法被完全言明的——你能认出一张脸，但说不清凭什么。

对 FDE 的启示：这一条直接决定了 Context 工程的方法论。如果领域知识本质上部分不可言明，那么「让专家写一份文档给模型看」注定不完整，必须靠观察实际操作、看专家改模型输出的痕迹、从错误样本反推规则。也就是说，Context 只能通过共同工作提取，不能通过访谈一次性取到——这正是 FDE 必须在现场的原因。

Nonaka, I. (1994). A Dynamic Theory of Organizational Knowledge Creation. Organization Science, 5(1), 14–37. DOI 10.1287/orsc.5.1.14。另见 Nonaka & Takeuchi (1995), The Knowledge-Creating Company, Oxford University Press。证据等级 C。

SECI 模型：知识在四种转化中螺旋上升——社会化（隐性到隐性，靠共同经历）、外化（隐性到显性，靠隐喻和类比）、组合（显性到显性）、内化（显性到隐性，靠做中学）。

对 FDE 的启示：SECI 几乎可以逐格映射到 FDE 的工作流。社会化对应跟着业务专家跑一遍真实流程；外化对应把规则写成 prompt、Ontology 和 Eval 用例；组合对应把多个部门的规则合并成统一的 Context 体系；内化对应用户在日常使用中形成新的工作直觉。SECI 强调这是循环而非线性，这也解释了为什么一次性交付的 Context 会过期。

Wenger, E. (1998). Communities of Practice: Learning, Meaning, and Identity. Cambridge University Press。wenger-trayner 官方介绍，infed 综述。证据等级 C。

学习发生在实践共同体中。Wenger 特别指出，真实工作中充满了默会的临场发挥、情境化知识和社会关系，流程手册上的工作和实际的工作之间存在重要的落差。

对 FDE 的启示：「手册上的流程」与「实际怎么干」的落差，就是 AI 项目最常踩的坑——按 SOP 文档建的 Context，上线后发现现实里 40% 的情况走的是文档里没有的例外路径。这也给了「企业内部长出 FDE」路线一个理论支撑：内部人本来就在实践共同体里面，不需要从零建立情境知识。相关路线对比见 ../04-methodology/frameworks-compared.md。

五、LLM 与 agent 的评估 ​

Eval 是 FDE 区别于「会调 API 的人」的关键手艺。这个领域 2023 年后论文爆发，但方法论共识还在形成中。

Zheng, L., Chiang, W.-L., Sheng, Y., Zhuang, S., Wu, Z., Zhuang, Y., Lin, Z., Li, Z., Li, D., Xing, E. P., Zhang, H., Gonzalez, J. E., & Stoica, I. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. arXiv 2306.05685，NeurIPS 2023 Datasets & Benchmarks。证据等级 A/B。

系统检验用强模型给开放式回答打分是否可行。结论：GPT-4 作为评委与人类偏好的一致率超过 80%，与人类之间的一致率相当。同时明确列出了三类偏差——位置偏差（偏好排在前面的回答）、冗长偏差（偏好长回答）、自我增强偏差（偏好自己生成的内容），以及推理能力有限的问题，并给出缓解方案。

对 FDE 的启示：这是 LLM-as-a-judge 的奠基文献，也是引用「80% 一致率」时必须一并说明的前提——那是在 MT-Bench 这样的通用对话任务上，不是在你客户的合同审核任务上。领域任务上的一致率必须自己测。三类偏差是搭建评委时必做的对照检查：交换位置重测、控制长度、避免用生成模型自评。

Liang, P., Bommasani, R., Lee, T., 等 (2022/2023). Holistic Evaluation of Language Models (HELM). arXiv 2211.09110，DOI 10.48550/arXiv.2211.09110，发表于 TMLR。证据等级 B。

主张评估不能只看准确率，对 16 个核心场景同时测 7 个指标——准确率、校准度、鲁棒性、公平性、偏见、毒性、效率，并覆盖 30 个模型。

对 FDE 的启示：HELM 的真正贡献是「多维度 + 场景矩阵」这个结构，可以直接搬到客户交付的验收表上。企业场景里那 7 个维度要换成自己的——准确率、延迟、成本、可解释性、失败时的降级行为、合规性——但「一个分数不够，必须是矩阵」这个原则是通用的。

Jimenez, C. E., 等 (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? arXiv 2310.06770，ICLR 2024。榜单见 swebench.com。证据等级 B（基准）。

2,294 个来自 12 个 Python 仓库真实 GitHub issue 与对应 PR 的任务，模型要在给定代码库上做出能通过测试的修改。后续的 SWE-bench Verified 由人工筛选出可靠子集。

Mialon, G., Fourrier, C., 等 (2023). GAIA: a benchmark for General AI Assistants. arXiv 2311.12983。证据等级 B。

466 道真实世界问题，需要推理、多模态处理、网页浏览和工具使用，按步骤数和工具复杂度分三级。发布时人类得分 92%，带插件的 GPT-4 为 15%。

Yao, S., Shinn, N., Razavi, P., & Narasimhan, K. (2024). τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv 2406.12045。后续 τ²-bench 见 GitHub。证据等级 B。

模拟用户与 agent 的多轮对话，agent 有领域 API 工具和政策规则，评估方式是比对对话结束时的数据库状态与标注的目标状态。提出 pass^k 指标衡量多次尝试的稳定性。发布时即使 gpt-4o 这类顶级函数调用 agent 成功率也不足 50%，且很不稳定。

对 FDE 的启示：这三个基准分别对应 FDE 会遇到的三类任务形态——改存量代码、多工具长链路调研、按企业规则与人交互办业务。τ-bench 的 pass^k 是三者中对企业交付最有价值的一个指标：客户不关心「最好的一次」，只关心「十次里有几次不出事」。把 pass^k 的思路移植到自己的 Eval 里，通常比提高单次准确率更能改变验收结果。另外要留意基准被过拟合的风险——industry-reports.md 中提到 SWE-bench Verified 上的分数在一年内从 60% 涨到接近 100%，这时候基准分数与现场表现的相关性已经很弱。

Cemri, M., Pan, M. Z., Yang, S., 等 (2025). Why Do Multi-Agent LLM Systems Fail? arXiv 2503.13657，代码与数据 GitHub。证据等级 B。

对 150 条多 agent 系统运行轨迹做专家标注（标注者间一致性 κ=0.88），建立首个多 agent 失败分类法 MAST：14 种失败模式，归为三类——系统设计问题、agent 间失配、任务验证不足。后续扩展为跨 7 个主流框架的 1600+ 条标注轨迹数据集 MAST-Data，并用 LLM-as-a-judge 流水线做规模化标注。

对 FDE 的启示：这是目前最实用的多 agent 排错清单。关键结论是失败大多不在模型能力，而在系统设计和验证环节——这两块正好是 FDE 的责任范围。κ=0.88 这个数字也是一个好示范：任何声称「我们做了人工评估」的交付，都应该报告标注者间一致性。

Cohen, J. (1960). A Coefficient of Agreement for Nominal Scales. Educational and Psychological Measurement, 20(1), 37–46. DOI 10.1177/001316446002000104。证据等级 A（统计学方法奠基）。

Cohen's kappa：扣除随机一致后的名义尺度一致性系数。

对 FDE 的启示：当你和客户的业务专家对同一批模型输出打标签时，先算 κ。如果两个人类专家之间的 κ 都只有 0.4，那么「模型准确率 85%」这个数字没有意义——问题出在任务定义不清，应该回去重写标注规范，而不是继续调 prompt。这是 FDE 现场最常被跳过、代价最高的一步。

Hubbard, D. W. (2007/2014). How to Measure Anything: Finding the Value of "Intangibles" in Business. Wiley，初版 2007，第三版 2014，ISBN 9781118539279。（Wiley 官网对自动抓取返回 403，链接未在本次核实中打开，书目信息按 ISBN 给出。）证据等级 C/D（方法论著作）。

三条核心主张。一是「澄清链」——如果 X 值得在乎，X 必然以某种方式可被观察；可被观察就必然表现为某个量；有量就能测。二是任何测量都必须先说清它支持的是哪一个具体决策，说不出决策，测量就没有价值。三是测量不必消除不确定性，减少不确定性就算测量，而且信息的价值往往远高于测量成本。

对 FDE 的启示：这本书填的是 Eval 与「算账」之间的缝。FDE 最常卡住的地方不是不会做 Eval，而是客户说「我们这个业务的价值没法量化」。澄清链是应对这句话的标准工具。「先定决策再定测量」这一条还能反过来用——如果客户说不出这个指标会改变哪个决策，那这个指标不该做，省下的时间放到真正影响决策的地方。

评估领域 2025–2026 的进展。 相关综述包括 Li, D., 等《From Generation to Judgment: Opportunities and Challenges of LLM-as-a-judge》arXiv 2411.16594；以及《Reliability without Validity: A Systematic, Large-Scale Evaluation of LLM-as-a-Judge Models Across Agreement, Consistency, and Bias》arXiv 2606.19544（2026）。另有一篇被广泛引用的综述《LLMs-as-Judges: A Comprehensive Survey on LLM-based Evaluation Methods》，配套资源库见 GitHub，arXiv 编号 2412.05579【待核实】。

从这批工作能读出的共识：即使最强的评委模型也存在系统性偏差和过度自信——它对「自己与多数人类标注者一致」的估计偏高；人机一致率随任务而剧烈变化，临床问答等结构清晰的任务可达 75% 左右，主观性强的领域则低得多。实践含义是把 LLM 评委当成需要校准的仪器，用一小批人工标注做校准集，在评委没把握时升级给人判断，而不是全盘信任。

六、Context engineering 与 agent 架构 ​

这个领域最好的材料目前在 D 档——公司工程博客和从业者论述，学术化程度低但离现场最近。引用时要说清楚这是实践总结不是受控研究。

Anthropic (2024). Building effective agents. anthropic.com/engineering/building-effective-agents，2024 年 12 月 19 日。证据等级 D。

区分「工作流」（workflow，按预定代码路径编排 LLM 和工具）与「agent」（模型自己决定流程和工具使用），并给出从最简单的增强型 LLM 到 orchestrator-workers 的一组组合模式。核心建议是从最简单的方案开始，只有在简单方案确实不够时才增加复杂度。

Anthropic (2025). Effective context engineering for AI agents. anthropic.com/engineering/effective-context-engineering-for-ai-agents，2025 年 9 月 29 日。证据等级 D。

把 context engineering 定位为 prompt engineering 的演进——不再是写一段好指令，而是在推理过程中持续管理「哪些 token 应该在上下文窗口里」这个有限资源，包括系统提示、工具定义、检索结果、历史压缩和长期记忆。

Anthropic (2025). How we built our multi-agent research system. anthropic.com/engineering/multi-agent-research-system，2025 年 6 月 13 日。证据等级 D。

orchestrator-worker 架构的工程实录：主 agent 分析查询、制定策略、派出拥有各自上下文窗口的子 agent 并行探索，再汇总。文中给出内部评估结果——Claude Opus 4 主 agent 配 Claude Sonnet 4 子 agent 的组合，在内部研究评测上比单 agent Opus 4 高 90.2%。另有一篇讨论何时不该用多 agent 的后续文章，见 claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them。

Karpathy, A. (2025). 关于 context engineering 的表述，X 原帖，2025 年 6 月。证据等级 D（个人论述）。

主张用「context engineering」取代「prompt engineering」，把它定义为「用恰好合适的信息填充上下文窗口，以支撑下一步」这门精细的艺术与科学。相关的「Software 3.0」框架把上下文窗口类比为 RAM、模型权重类比为 CPU。

对 FDE 的启示（本节合并）：这四份材料合起来是目前 Context 工程最好的公开教材，也构成 FDE 的核心技术栈。三条最实用的原则——先用最简单的工作流，别一上来就上 agent；把上下文当稀缺资源经营，而不是往里塞更多；多 agent 的收益要用内部 Eval 证明，因为 token 成本会成倍上升。同时要清醒：这些都是厂商发布的自家实践，效应数字（如 90.2%）来自内部评测，无法独立复现。具体工具与实现见 ../06-toolbox/agent-dev-stack.md，方法论落地见 ../04-methodology/context-engineering.md。

Lewis, P., Perez, E., Piktus, A., 等 (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. arXiv 2005.11401，NeurIPS 2020。证据等级 A（原始方法论文）。

RAG 的原始论文，提出把参数化记忆（预训练模型）与非参数化记忆（可检索的外部文档索引）结合。

Gao, Y., 等 (2023/2024). Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv 2312.10997。证据等级 B（综述）。

梳理 RAG 从 Naive RAG 到 Advanced RAG 再到 Modular RAG 的演进，以及检索、生成、增强三大技术支柱。

对 FDE 的启示：RAG 是把客户私有知识接进模型最常用的路径，但这两篇也说明它不是万能的——检索质量、切分策略、重排序每一环都会决定最终效果，而这些恰恰高度依赖领域理解。「文档丢进向量库就完事」是 FDE 现场最常见的失败起点。

七、精益、持续改进与复盘 ​

FDE 的交付是一轮轮迭代，每轮都要有结构化的学习。这套方法丰田和美军各自独立发展了几十年。

Sobek II, D. K., & Smalley, A. (2008). Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System. Productivity Press，ISBN 9781563273605，2009 年 Shingo 研究与专业出版奖。Routledge 页面。证据等级 C。

A3 报告（一张 A3 纸上完成背景、现状、目标、根因分析、对策、计划、跟进）不是模板，而是 PDCA 管理哲学的载体。PDCA 循环本身源自 Shewhart 并由 Deming 战后带入日本企业。

对 FDE 的启示：A3 是把「这次交付到底解决了什么问题」压到一页纸的强制约束，特别适合作为 FDE 每个 sprint 与客户对齐的界面。它逼你先写清「现状」和「目标」的量化差距，再谈方案——这正好挡住 AI 项目最常见的病：方案先行，问题模糊。模板见 ../06-toolbox/templates.md。

U.S. Department of the Army (1993). TC 25-20: A Leader's Guide to After-Action Reviews. 公开 PDF。以及 U.S. Army Research Institute, Current Practice and Theoretical Foundations of the After Action Review，DTIC ADA544543。证据等级 C/D（军方条令 + 研究综述）。

AAR 的四问结构：预期发生什么、实际发生了什么、为什么有差异、下次怎么做。ARI 的研究综述指出 AAR 已成为美军训练文化的基础部分，在教官和受训者层面都被认可有价值，同时提出通过「引导式发现学习」（guided discovery learning）改进 AAR 效果的路径——即主持人不给答案，而是引导参与者自己发现。

对 FDE 的启示：AAR 的四问结构可以直接用在每次 Eval 结果评审和每次上线后复盘。「引导式发现」这条与 Schein 的过程咨询和 Argyris 的双环学习是同一个道理——FDE 在复盘会上直接给结论，短期高效，长期会让客户团队永远学不会自己做。

Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press。证据等级 B（大样本调查 + 结构方程建模）。

基于四年 State of DevOps 调查、23,000 多份回复、2,000 多家组织，用结构方程建模和心理测量学方法验证，得出四个关键指标：部署频率、变更前置时间、变更失败率、服务恢复时间，并论证软件交付绩效是组织绩效的领先指标。

对 FDE 的启示：DORA 的方法论价值大于指标本身——它示范了怎么把「我们交付得好不好」这种模糊问题转成可测量、经过效度检验的构念。FDE 在给客户建交付看板时，与其自创指标，不如借鉴这套「少量、正交、有理论支撑」的设计思路。注意 DORA 的数据来自自我报告的调查，存在共同方法偏差，且样本偏向愿意参与调查的组织。

八、软件工程：需求发现、数据就绪与 MVP ​

Zowghi, D., & Coulin, C. (2005). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. 收于 Aurum & Wohlin (eds.), Engineering and Managing Software Requirements, Springer, 19–46. DOI 10.1007/3-540-28244-0_2。公开 PDF。证据等级 B（综述）。

系统梳理需求获取的技术（访谈、观察、原型、工作坊、场景等）、方法与工具，以及各自的适用条件和已知问题。

对 FDE 的启示：FDE 圈里被当作独门心法讲的很多做法——跟班观察、拿原型去引出需求、开跨部门工作坊——在需求工程里是有名字、有适用条件、有已知失败模式的成熟技术。这篇综述能帮 FDE 在面对一个新客户时，系统地选方法而不是凭习惯。同一作者后续还有关于需求获取工作坊的情境化方法研究，见 Coulin (2006), Software Process: Improvement and Practice, DOI 10.1002/spip.288。

Lenarduzzi, V., & Taibi, D. (2016). MVP Explained: A Systematic Mapping Study on the Definitions of Minimal Viable Product. SEAA 2016, 112–119. DOI 10.1109/SEAA.2016.56。证据等级 B（系统映射研究）。

对 MVP 的既有定义做系统梳理，发现学界与业界对 MVP 的界定并不统一，并归纳出帮助创业者定义 MVP 的关键因素。

对 FDE 的启示：FDE 语境里的 MVD（Minimum Viable Delivery，最小可用交付）与 MVP 是近亲但目标不同——MVP 验证市场是否要这个产品，MVD 验证这套 AI 工作流在这个客户的真实数据和真实约束下能不能跑通。这篇研究的用处是提醒：连 MVP 的定义都不统一，所以在客户那里必须逐字写清「最小」的边界和「可用」的判据，否则范围一定会漂。MVD 的定义见 ../00-start/glossary.md。

Beyer, H., & Holtzblatt, K. (1998; 2nd ed. 2014). Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann / Elsevier。证据等级 C/D（方法论著作）。（该书方法综述有一份广为流传的 PDF 镜像位于 iihm.imag.fr，截至 2026 年 9 月该站 TLS 证书已过期，本页不作为链接给出。）

情境访谈（contextual inquiry）的四条原则：Context——到现场看真实工作，而不是隔着会议桌问；Partnership——建立师徒关系而非问答关系，让受访者边做边讲；Interpretation——当场把观察翻译成含义并请对方确认；Focus——带着明确焦点观察，而不是漫无目的地记录。

对 FDE 的启示：这四条几乎就是「FDE 要坐在客户身边」这句口号的操作化版本。特别是 master/apprentice 这个手法——让业务专家像带徒弟一样边做边解说，是提取 Polanyi 意义上隐性知识最有效的现场技术之一，比结构化访谈能挖出多得多的例外规则。

Lawrence, N. D. (2017). Data Readiness Levels. arXiv 1705.02245。证据等级 C/D（框架提案）。

提出一套数据就绪度分级，为「这批数据到底准备好了没有」建立甲乙双方的共同语言。论点是数据准备耗时通常被严重低估，而缺乏共同术语让项目管理无从谈起。

对 FDE 的启示：这是缔约阶段最实用的一件工具。AI 项目最常见的返工来源是双方对「数据可用」的理解不同——客户说数据都有，FDE 到现场发现字段含义没人说得清、历史数据格式变过三次。用一套分级把「有数据」「能读」「能用来训练或检索」拆成不同等级写进合同，能挡掉大量后期争议。与 Block 的缔约模型配合使用效果最好。

Ries, E. (2011). The Lean Startup. Crown Business；Blank, S. (2013). Why the Lean Start-Up Changes Everything. Harvard Business Review, 2013 年 5 月号，HBR 页面。证据等级 D（从业者理论）。

构建—测量—学习循环、经证实的认知（validated learning）、顾客开发（customer development）。

对 FDE 的启示：这两本是 MVD 和迭代交付话术的直接来源，读的时候要清楚它们是实践论述而非实证研究，学界对精益创业主张的检验并不充分。

九、10 篇精选 ​

如果只读十份材料，就读这十份。列表跨本页与 industry-reports.md 两页，最后一列标出对哪类读者最要紧。

#材料一句话理由最相关的读者
1Dell'Acqua 等 2026《Navigating the Jagged Technological Frontier》「参差边界」是 FDE 每天要做的判断，也是最该写进合同范围的东西全部
2Brynjolfsson, Li & Raymond 2025《Generative AI at Work》最有力的价值证明：AI 把老师傅的手艺规模化，低技能者受益最多业务人、企业内部推动者
3METR 2025 + 2026 更新主观感受与客观测量可以反向，以及怎么诚实地报告效果工程师、创业者
4Kim, Kim & Koning 2026《Mapping AI into Production》「映射问题」——FDE 这个岗位存在意义的学术支撑全部
5MIT NANDA《The GenAI Divide》（见 industry-reports.md）外部合作 67% vs 内部自建 33%，以及这个数字的口径与争议创业者、企业内部推动者
6Zheng 等 2023 LLM-as-a-judge + Cohen 1960 κEval 的地基：先算标注者一致性，再谈模型准确率全部
7Anthropic《Effective context engineering for AI agents》FDE 的核心技术栈，目前最好的公开教材工程师、应届生
8Schein《Process Consultation Revisited》从「医生模式」切到「过程咨询模式」，工程师最缺的那部分能力工程师、业务人
9Polanyi《The Tacit Dimension》+ Wenger 1998为什么 Context 只能靠共同工作提取，不能靠访谈一次取到全部
10Palantir FY2025 10-K（见 industry-reports.md）82% 毛利、4,429 人、财报里没有「FDE」这个词创业者、企业内部推动者

如果只有一个下午，按身份走这条最短路径：

  • 想转 FDE 的工程师：4 → 1 → 8 → 6。先明白这活为什么存在，再明白技术判断的边界在哪，再补上你最缺的关系能力和评估能力。
  • 想转 FDE 的业务人 / 产品 / 顾问：2 → 6 → 7。先拿到价值证明，再补技术判断力，读完能听懂工程师在说什么。
  • 应届生与在校生：Brynjolfsson, Chandar & Chen《Canaries》2026 年 8 月版 → 9 → 7。先看清就业市场的真实数据，再明白你相对资深者真正缺的是什么，然后开始建技术地基。
  • 企业内部推动者：5 → 4 → Kotter 1995。先正面回应「内部自建成功率只有一半」这个数字，再解决映射问题，再用八类错误逐条自查。
  • 想做交付生意的人：10 → 5 → Gartner 40% 预测（见 industry-reports.md）。先看清模式的财务真相，再拿到市场论证，再把三个失败原因做成自己的差异化。

中文读者补一份：腾讯研究院《前线共创，双向赋能：FDE 模式行业观察与实践》（2026 年 8 月），目前唯一一份中国机构的 FDE 专题报告，原文链接，详见 industry-reports.md 第五节。它不是学术研究，但对理解中文语境下的 FDE 讨论是最短路径。

缺口与待补 ​

诚实标注这一页现在的薄弱处，供后续补充。

  • 没有关于 FDE 岗位本身的学术研究。 截至 2026 年 9 月，未找到任何以 Forward Deployed Engineer 为研究对象的同行评议论文。所有关于 FDE 有效性的说法目前只有公司论述、机构报告和从业者经验支撑，证据等级最高到 D。这是本领域最大的证据空白。已知最接近的机构级材料是腾讯研究院 2026 年 8 月的 FDE 专题报告，属机构智库出品而非同行评议，见 industry-reports.md 第五节。
  • 中国场景的实证研究缺失。 本页的 RCT 全部在欧美企业开展，中国企业的组织结构、数据治理和采购流程差异很大，结论外推需谨慎。目前能找到的中国一手数据以问卷调研为主（如信通院 2026 年 3 月对 6,000 余家中小企业的调查），不是实验设计，见 industry-reports.md 第五节。
  • 2026 年的企业级 RCT 仍然稀少。 现有严格实验大多测的是个人任务生产力，测「整个组织的交付方式改变后发生了什么」的研究只有 Kim 等 2026 一项，且样本是初创公司。
  • Context engineering 尚无学术共识。 该领域最好的材料在公司博客，缺少独立复现和对照研究。
  • Argyris 1977 年 HBR 那篇《Double Loop Learning in Organizations》的具体期号页码未能核实，本页只保留了已核实的 1991 年文章。

延伸阅读 ​

来源 ​

按正文引用顺序。

  1. Brynjolfsson, E., Li, D., & Raymond, L. "Generative AI at Work." The Quarterly Journal of Economics 140(2), 889–942, 2025. https://doi.org/10.1093/qje/qjae044 ；NBER WP 31161, 2023. https://www.nber.org/papers/w31161
  2. Dell'Acqua, F. 等. "Navigating the Jagged Technological Frontier." Organization Science 37(2), 403–423, 2026. https://doi.org/10.1287/orsc.2025.21838 ；HBS WP 24-013 / SSRN 4573321, 2023-09-15. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4573321
  3. Noy, S., & Zhang, W. "Experimental evidence on the productivity effects of generative artificial intelligence." Science 381(6654), 187–192, 2023-07-14. https://doi.org/10.1126/science.adh2586
  4. Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot." arXiv:2302.06590, 2023-02-13. https://arxiv.org/abs/2302.06590
  5. Cui, Z. K. 等. "The Effects of Generative AI on High-Skilled Work." Management Science, 2025. https://doi.org/10.1287/mnsc.2025.00535 ；SSRN 4945566. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4945566
  6. METR. "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity." arXiv:2507.09089, 2025-07. https://arxiv.org/abs/2507.09089 ；官方说明 https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
  7. METR. "We are Changing our Developer Productivity Experiment Design." 2026-02-24. https://metr.org/blog/2026-02-24-uplift-update/
  8. Kim, H., Kim, D., & Koning, R. "Mapping AI into Production: A Field Experiment on Firm Performance." SSRN 6513481 / HBS WP 68814, 2026. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6513481 ；https://www.hbs.edu/faculty/Pages/item.aspx?num=68814
  9. Brynjolfsson, E., Rock, D., & Syverson, C. "Artificial Intelligence and the Modern Productivity Paradox." NBER WP 24001, 2017. https://www.nber.org/papers/w24001 ；"The Productivity J-Curve." NBER WP 25148. https://www.nber.org/system/files/working_papers/w25148/w25148.pdf
  10. Brynjolfsson, E., Chandar, B., & Chen, R. "Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence." Stanford Digital Economy Lab, 2025；2026 年 8 月修订版. https://digitaleconomy.stanford.edu/app/uploads/2026/08/Canaries_August2026.pdf ；https://digitaleconomy.stanford.edu/news/canariesaug26/
  11. Chatterji, A. 等. "How People Use ChatGPT." NBER WP 34255, 2025. https://www.nber.org/papers/w34255
  12. Rogers, E. M. Diffusion of Innovations, 5th ed. Free Press, 2003. https://www.simonandschuster.com/books/Diffusion-of-Innovations-5th-Edition/Everett-M-Rogers/9780743258234
  13. Davis, F. D. "Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology." MIS Quarterly 13(3), 319–340, 1989. https://doi.org/10.2307/249008
  14. Venkatesh, V., Morris, M. G., Davis, G. B., & Davis, F. D. "User Acceptance of Information Technology: Toward a Unified View." MIS Quarterly 27(3), 425–478, 2003. https://doi.org/10.2307/30036540
  15. Moore, G. A. Crossing the Chasm, 3rd ed. Harper Business, 2014. https://www.harperbusiness.com/book/9780062293008/Crossing-the-Chasm-3rd-Edition-Geoffrey-A.-Moore/
  16. Argyris, C. "Teaching Smart People How to Learn." Harvard Business Review, 1991-05. https://hbr.org/1991/05/teaching-smart-people-how-to-learn
  17. Schein, E. H. Process Consultation Revisited: Building the Helping Relationship. Addison-Wesley, 1999. ISBN 9780201345964. https://archive.org/details/processconsultat0000sche
  18. Block, P. Flawless Consulting, 3rd ed. Pfeiffer/Wiley, 2011. ISBN 9780470620748. https://www.wiley.com/en-us/Flawless+Consulting:+A+Guide+to+Getting+Your+Expertise+Used,+3rd+Edition-p-9780470620748
  19. Kotter, J. P. "Leading Change: Why Transformation Efforts Fail." Harvard Business Review, 1995. https://hbr.org/1995/05/leading-change-why-transformation-efforts-fail-2
  20. Trist, E. L., & Bamforth, K. W. "Some Social and Psychological Consequences of the Longwall Method of Coal-Getting." Human Relations 4(1), 3–38, 1951. https://doi.org/10.1177/001872675100400101
  21. Orlikowski, W. J. "Using Technology and Constituting Structures." Organization Science 11(4), 404–428, 2000. https://doi.org/10.1287/orsc.11.4.404.14600
  22. Polanyi, M. The Tacit Dimension. University of Chicago Press, 1966.
  23. Nonaka, I. "A Dynamic Theory of Organizational Knowledge Creation." Organization Science 5(1), 14–37, 1994. https://doi.org/10.1287/orsc.5.1.14
  24. Wenger, E. Communities of Practice: Learning, Meaning, and Identity. Cambridge University Press, 1998. https://www.wenger-trayner.com/introduction-to-communities-of-practice/
  25. Zheng, L. 等. "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena." arXiv:2306.05685, NeurIPS 2023 D&B. https://arxiv.org/abs/2306.05685
  26. Liang, P., Bommasani, R., Lee, T. 等. "Holistic Evaluation of Language Models." arXiv:2211.09110, TMLR. https://arxiv.org/abs/2211.09110
  27. Jimenez, C. E. 等. "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" arXiv:2310.06770, ICLR 2024. https://arxiv.org/abs/2310.06770 ；https://www.swebench.com/verified.html
  28. Mialon, G., Fourrier, C. 等. "GAIA: a benchmark for General AI Assistants." arXiv:2311.12983, 2023. https://arxiv.org/abs/2311.12983
  29. Yao, S., Shinn, N., Razavi, P., & Narasimhan, K. "τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains." arXiv:2406.12045, 2024-06-17. https://arxiv.org/abs/2406.12045 ；https://github.com/sierra-research/tau2-bench
  30. Cemri, M. 等. "Why Do Multi-Agent LLM Systems Fail?" arXiv:2503.13657, 2025. https://arxiv.org/abs/2503.13657 ；https://github.com/multi-agent-systems-failure-taxonomy/MAST
  31. Cohen, J. "A Coefficient of Agreement for Nominal Scales." Educational and Psychological Measurement 20(1), 37–46, 1960. https://doi.org/10.1177/001316446002000104
  32. Li, D. 等. "From Generation to Judgment: Opportunities and Challenges of LLM-as-a-judge." arXiv:2411.16594. https://arxiv.org/pdf/2411.16594
  33. "Reliability without Validity: A Systematic, Large-Scale Evaluation of LLM-as-a-Judge Models Across Agreement, Consistency, and Bias." arXiv:2606.19544, 2026. https://arxiv.org/pdf/2606.19544
  34. Anthropic. "Building effective agents." 2024-12-19. https://www.anthropic.com/engineering/building-effective-agents
  35. Anthropic. "Effective context engineering for AI agents." 2025-09-29. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
  36. Anthropic. "How we built our multi-agent research system." 2025-06-13. https://www.anthropic.com/engineering/multi-agent-research-system ；"When to use multi-agent systems." https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them
  37. Karpathy, A. 关于 context engineering 的帖子，X，2025-06. https://x.com/karpathy/status/1937902205765607626
  38. Lewis, P. 等. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." arXiv:2005.11401, NeurIPS 2020. https://arxiv.org/abs/2005.11401
  39. Gao, Y. 等. "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv:2312.10997, 2023-12-18. https://arxiv.org/abs/2312.10997
  40. Sobek II, D. K., & Smalley, A. Understanding A3 Thinking. Productivity Press, 2008. ISBN 9781563273605. https://www.routledge.com/Understanding-A3-Thinking-A-Critical-Component-of-Toyotas-PDCA-Management-System/SobekII-Smalley/p/book/9781563273605
  41. U.S. Department of the Army. TC 25-20: A Leader's Guide to After-Action Reviews. 1993-09. https://nick.groenen.me/attachments/public/gitignored/TC 25-20 A Leader's Guide to After-Action Reviews.pdf ；U.S. Army Research Institute, "Current Practice and Theoretical Foundations of the After Action Review," DTIC ADA544543. https://apps.dtic.mil/sti/pdfs/ADA544543.pdf
  42. Forsgren, N., Humble, J., & Kim, G. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.
  43. Zowghi, D., & Coulin, C. "Requirements Elicitation: A Survey of Techniques, Approaches, and Tools." In Aurum & Wohlin (eds.), Engineering and Managing Software Requirements, Springer, 19–46, 2005. https://doi.org/10.1007/3-540-28244-0_2 ；https://web.eecs.umich.edu/~weimerw/2025-481F/readings/requirements.pdf
  44. Coulin, C. "A situational method engineering approach to requirements elicitation workshops." Software Process: Improvement and Practice, 2006. https://doi.org/10.1002/spip.288
  45. Lenarduzzi, V., & Taibi, D. "MVP Explained: A Systematic Mapping Study on the Definitions of Minimal Viable Product." SEAA 2016, 112–119. https://doi.org/10.1109/SEAA.2016.56
  46. Hubbard, D. W. How to Measure Anything: Finding the Value of "Intangibles" in Business. Wiley, 初版 2007，第三版 2014. ISBN 9781118539279.
  47. Beyer, H., & Holtzblatt, K. Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann, 1998（第二版 Elsevier, 2014）.
  48. Lawrence, N. D. "Data Readiness Levels." arXiv:1705.02245, 2017-05-05. https://arxiv.org/abs/1705.02245
  49. Ries, E. The Lean Startup. Crown Business, 2011 ；Blank, S. "Why the Lean Start-Up Changes Everything." Harvard Business Review, 2013-05. https://hbr.org/2013/05/why-the-lean-start-up-changes-everything

内容采用 CC BY 4.0 许可，商用请注明出处。欢迎 投稿与纠错。

© 2026 FDE Wiki · 维护者任鑫（公众号「AI 炼金术」）