第 2 章三条铁律

第 1 章给的是坐标系——FDE 一天的样子、一个项目的四个阶段。但坐标系本身不能告诉你取舍时怎么选。

凌晨两点你刚做完一个紧急修复，客户 CTO 第二天上午八点要看演示。你有两个选择：把修复当晚发到 staging 让客户看真实状态，或者把演示版固定下来明天演完再上 staging。哪个更对？（提示：跟你昨晚修了什么相关——修的是评估集上能跑分的功能，发；修的是客户没要求过的边角优化，等。这一章读完你会明白为什么。）

客户业务负责人在会上当场提了一个新场景，让你”明天就上”。你拒绝吗？怎么拒绝？

客户那边数据格式有 5% 是脏的，你回总部排期还是当场写一段处理代码？

这些是 FDE 每天遇到的取舍。第 1 章的”在哪个阶段、做什么任务”回答不了它们。回答它们靠的是另一组东西——三条铁律。

这三条不是我发明的，是行业里几代 FDE 反复说过、踩过坑总结出来的同一组心法。Bob McGrew 在 Y Combinator 的访谈里讲过第一条；A. Lawrence 在他的 Forward Deployed Engineer Rule Book 里反复写第二条；第三条是 Anthropic、OpenAI 这些做 LLM 应用的团队过去两年公开博客和工程实践里反复推的方法论。

三条之间有先后顺序：

Sell the outcome, not the product   — 决定你做什么
Eval-driven                          — 决定你怎么知道做到了
Fix forward                          — 决定你在哪里修问题

为什么是这个顺序？因为它们的失败方式不一样。第一条违反了，整个项目方向就错——做了 12 周没人要的功能；第二条违反了，项目方向对但你不知道走到哪儿了——客户半年后说”好像不太行”你没法反驳；第三条违反了，项目方向对、进度也清楚，但你救不了客户的火——他三周内丢了三次单子，对你的信任就没了。

排第一的代价最大也最难挽回，所以 outcome 排第一。第二条排第二是因为它的代价是”延迟暴露”——你写了三个月才发现没达标。第三条排第三是因为它的代价是”局部信任”——可以丢一次客户的小单子，但能在丢一两次后追回来。

这一章逐条展开。

2.1 卖结果，不卖产品

客户花钱不是因为想要”一个 Agent”，是因为他想：

把月底报表准点率从 60% 拉到 95%
把客户工单首响时间从 4 小时降到 30 分钟
把销售跟单转化率提 5 个百分点

“Agent” 是手段，那三个数字是目的。FDE 的工作是对目的负责，不是对手段负责。这就是 Bob McGrew 那句”sell the outcome, not the product”的字面意思。

为什么这条这么重要？因为如果你卖的是产品，客户用”产品好不好”评价你——这种评价无法量化、永远没有终点。今天客户觉得”还行”，明天换了对接人觉得”不够智能”，你做什么都没用。如果你卖的是结果，客户用”那个数字达没达成”评价你——可量化、有终点、双方目标一致。

在对话里怎么用这条

每次跟客户对话，你都要做一次小翻译——把客户嘴里的”我要 X 功能”翻译回”X 功能服务的是什么业务结果”。这个翻译动作要变成肌肉记忆。

举三个常见场景：

场景一：客户加新需求

客户说：”你们这个能不能也接邮件？”

错误回答：”可以，我们排到下周做。” 正确反应：先弄清楚客户加邮件是为了什么业务结果。这一步通常一句话就能问出来——”您加邮件主要是想解决哪个事？是销售跟单的回复速度，还是客服首响时间，还是别的？”客户的答案决定你下一步怎么回。

假设答案是”销售跟单的回复中位时间”，你的回话变成：”那我们看一下现在的回复中位时间是多少，加邮件后预计能降到多少，再排进 backlog。”

这一翻，对话从”我要不要接邮件”变成了”我们当前关心的那个数字怎么继续往下推”。客户和你回到了同一个坐标系。

如果客户答不上来”为了什么业务结果”——那是个红灯。说明这个需求不是从工作流里长出来的，是从某个 demo 或某个会议讨论里脑补出来的。这种需求做了大概率没人用。

场景二：客户问技术指标

客户说：”你们这个 RAG 准确率到底多少？”

错误回答：”测试集上 0.83，生产 0.78。” 正确反应：准确率本身对客户没意义。回话变成：”RAG 召回 0.78 这个数字本身意义不大。您当初想解决的是客户经理找一份保单条款要 4 分钟太慢——现在用 RAG 平均 28 秒。这个 28 秒和您定的’30 秒以内’对得上。”

这一翻，对话从”模型有多准”变成”业务问题解决到什么程度”。前者是技术参数，后者才是 outcome。

场景三：客户给宽泛目标

客户说：”我们想要 AI 驱动的全公司知识库。”

错误回答：”好，我们做架构方案。” 正确反应：宽泛目标永远做不出。回话变成：”全公司知识库这个目标太大。我建议先选一个具体的：是新员工上手时间从 30 天降到 15 天，还是客服解决率从 65% 升到 80%？选定一个先做一版给您看，其他的下一期再说。”

这一翻是最难的，因为你在拒绝客户的原始需求，但同时给了一个更可达成的版本。如果客户接受，你的项目就有了清晰边界；如果客户坚持要”全部”，那你应该意识到他还在 Discovery 阶段，第 1 章 1.2 的判断框架告诉你不该开始写代码。

团队和老板的拉扯

这条最难的不是面对客户，是面对你自己公司的产品和销售。他们会反复把”卖产品”灌输给你——”客户问能不能做 X，先答能”，”先签合同再聊 outcome”。

抵抗这个有一个简单的办法：不要让任何对话停在”功能讨论”上。客户提需求、销售要承诺、产品定 roadmap，你都把话题拉回”这件事服务的 outcome 是什么、怎么量化”。

如果你新接手一个项目第一周连不上一个 outcome 数字，那是个红灯——你大概率不在 Scaffolding 而在 Discovery。这时候停下来跟客户对齐 outcome 的成本，远低于做错一个项目的成本。

2.2 评估驱动

有了 outcome，下一个问题是怎么知道你正在接近它。这就是第二条铁律。

LLM 系统和传统软件最大的区别：输入相同，输出不一定相同；今天工作的 prompt，模型升级后可能就坏了。

这件事的工程后果是——你不能再靠”我看了一眼觉得不错”来判断系统好坏。你需要一个固定样本集 + 一份能跑分的脚本，每次改动都跑一遍。这就是评估驱动（Eval-driven）。

它不是”写完代码顺便跑一跑”，是反过来——先有评估，再有代码。具体的工程意义是这五件事：

第一周就建评估集 v0。20-50 条样本，覆盖典型场景和你能想到的边角情况。第一周就建，不是上线前补。
每个 PR 跑评估。CI 里跑、本地跑都行，关键是”改完代码必须有数字”。
定一个过线分。客户 sign-off 写在合同里的那个数字，对应评估集上的具体阈值。低于阈值不上线。
生产持续采样回流。线上真实出现的失败 case，每周抽一些加进评估集。这是评估集的活水来源。
模型升级、prompt 大改、依赖换——重跑评估。每一次大改之前先跑一遍现状基线，改完跑一遍变更后的，差异自然出来。

评估集 v0 怎么从零冷启动

入门者最常卡在这一步：客户连 outcome 都还没想清楚，我哪来 30 条样本？

我自己用过的从 0 到 30 条流程，第一周内能跑完：

从客户已有数据里抽 10 条真实样本。客服工单、历史问答记录、客户经理常用查询——任何客户日常工作里已经在产生的请求。如果客户连这 10 条都给不出，他们大概率还在 Discovery 阶段，本身就不该开始建系统。
自己写 10 条边角情况。这 10 条不是”典型”，是”故意刁难”——口语化表述、缩写、错别字、长句、需要多步推理、答案是”我不知道”的样本（很多系统在这种样本上幻觉最严重）。
跑一次让客户业务方看分布。这一步是关键。让客户看你测试集里有什么，他大概率会说”这个不是我们的典型场景”或者”你漏了 X 类问题”。让他挑刺。
根据客户挑刺的方向再加 10 条。这 10 条是客户认账的代表性样本。

到这里你有 30 条。第一周内可以完成。

这套流程的关键不是”30 条数量到位”，是让客户参与样本选择。客户参与过样本选择的评估集，他后面看分数时不会说”这评估集本身不对”——这是项目交付时最不想踩的雷。

一个最小评估集长什么样

假设你做的是保险条款问答。评估集 v0 大概这样：

# evals/insurance_qa_v0.jsonl
// min_score = 关键词命中比例阈值 (0-1)。例: 0.8 = 期望至少命中 80% 的 keywords
{"input":"重疾险等待期一般是多少？",
 "expected_keywords":["90","180","等待期"],
 "min_score":0.8}

{"input":"我去年体检发现甲状腺结节，现在能投保吗？",
 "expected_keywords":["核保","告知","结节"],
 "min_score":0.7}

{"input":"被保人犹豫期内退保能退多少？",
 "expected_keywords":["全额","犹豫期"],
 "min_score":0.9}
# ... 30-50 条

跑分两层：机器自动跑关键词召回（30 秒出分数），业务专家每周抽 10 条人工打分。两个数字一起看。机器分能说”这次改动有没有把存量样本搞砸”；人工分能说”我们离客户真正满意还差多远”。

更复杂的评估方式（LLM-as-judge、配对偏好评估、agent trajectory 评估）后面第 8 章展开。第一周不需要那么复杂，30 条 + 关键词匹配就够你和团队建立起”改动 → 跑数字 → 决定上不上”的肌肉记忆。

在 AWS 平台上做评估

如果你的项目跑在 AWS Bedrock 上，平台自带几种评估能力，能省掉一些自己造轮子的时间：

Bedrock Evaluations：在 Bedrock 里直接对模型 / RAG / Agent 跑评估，支持机器评估、LLM-as-judge、人工评估三种模式
Knowledge Bases Evaluations：专为 RAG 系统的召回质量和生成质量设计的评估流程
AgentCore Evaluations（属于 Amazon Bedrock AgentCore）：针对 agent 的多步推理路径做评估，支持自定义维度

实操建议：PoC 阶段用控制台版——成本几乎为零，10 分钟跑通基线，能让你和客户当天就有第一份数字。进入 Scaffolding 后迁到代码版——pytest 或 deepeval 这类开源框架，CI 跑得动、版本可控、能 diff 不同分支的得分。上线后用 CloudWatch 收集线上真实样本定期回流评估集。具体 API 和控制台入口随产品迭代变化，以 docs.aws.amazon.com 为准。

没评估的项目和有评估的项目差什么

最直观的差别是这些场景里的对话：

场景	没评估的项目	有评估的项目
周一站会	“上周改的那版，感觉好像还行”	“上周 0.81，这周 0.83，提了 2 个百分点”
客户问”系统好不好”	主观打分，每周飘	客户每周看数字，可解释
模型供应商升级	不敢动，怕坏	一晚上跑一次评估即可决断
上线 sign-off	靠演示运气	靠数字达成
项目交接后	客户不知道好坏	客户能自己跑评估监控

最后一行特别重要——评估集不只是开发工具，也是 Handoff 的核心交付物。客户接手系统时拿到的”是不是工作”的能力，不是看你的代码漂不漂亮，是手里有没有评估集和跑分脚本。

2.3 在客户那边修

知道了做什么，也知道了怎么衡量做到没做到，剩下的问题是：当事情出错时，你在哪里修？

第三条 Lawrence 在书里反复写：Don’t carry the problem back to HQ. Fix it at the customer site.

这条听起来像废话——”在哪修不都一样吗？”——但背后是工程哲学的根本差异。FDE 不是”前线的售前 + 后方的研发”两段式工作。FDE 在前线就既是售前，也是研发，也是运维。

如果你遇到问题第一反应是”我回去开个 Jira，让总部排期”，你已经退回到了”实施工程师”的位置。那个角色是有的，但不是 FDE。

怎么算”在现场修”

两个最有代表性的场景，能讲清”在现场修”和”回去排期”的差距。

RAG 召回突然掉了。某天客户运营反馈”系统答非所问越来越多”，你打开 trace 发现昨晚召回率从 0.82 掉到 0.61。

回去排期的处理方式：发个邮件给总部，加 ticket 进 backlog，说”下个迭代修复”。客户接下来一周用着越来越糟的版本，每天都有人吐槽。第二周你迭代上线，客户已经在心里给你打了零分。

在现场修：当天看 trace 找到归因（比如客户上周加了一批新数据没同步进知识库）。当晚写一行重新 ingest 的脚本+一个 5 分钟的 SOP，给客户运维群里发出去。第二天召回回到 0.81。同时把这个 ingest 流程的修复（自动监听数据源变化）作为正式 PR 排进下周开发。当下救火 + 长期修复并行，客户体验上感受不到那一周的恶化。

客户合规问到一个你架构里没明确处理的细节。比如 PII 数据流过哪几个组件、有没有日志、保留多久。

回去排期：你说”我回去问安全团队，下周给您回复”。下周客户开了三轮内部会，你下周回话时他们已经在认真考虑要不要换供应商。

在现场修：当场把架构图打开，把客户问的那一条数据流路径在图上画出来。能确定的就直接讲明白，不确定的当场标”我回去 24 小时内确认”。会议结束前邮件里就把修订版本架构图发出来，包括对那条数据流的具体说明。不让客户带着不确定性走出会议室。

这两个场景的共同点：问题都不是当场就有完美方案，但你都在客户视野里立刻动了起来。客户对 FDE 的信任不是建在”问题永远不发生”上的，是建在”问题一发生你就在场处理”上的。

一个反例

Lawrence 书里讲过一个客户案例：FDE 在客户处部署时发现数据有 5% 是脏的（编码混合）。他选择写工单回总部排期，等了三周。研发回复”通用方案要重构”，到第四周客户失去耐心，项目停滞。

接手的同事第一天写了 30 行 transformer 处理这 5%，第二天数据全过，项目重新启动。

教训不是”不要写工单”，是工单和当场修要并行：脏数据处理的小补丁先把客户的数据流救回来，正式的通用方案 PR 同时进 backlog。客户的容忍度是有限的，每多等一周，他们对整个项目的信心就掉一点——不是对那个 bug 的信心，是对”这个团队能不能搞定我们的问题”这件事的信心。

你需要哪些”现场修”的能力配置

为了能”在现场修”，FDE 必须有几样工具配置。任何一项缺失，都会把你从 FDE 变回实施工程师：

客户环境的部署权限（至少 staging）。如果连 staging 都要客户 IT 走流程才能动，你的修复永远赶不上客户的耐心。
自己仓库 main 分支的直接 push 权限（受 CI 保护）。如果你修一行代码要等 CTO review，你的 hot fix 永远是”明天的事”。
至少一个能 hot fix 上线的发版通道：Lambda、边车容器、配置中心、feature flag——任选其一。
一个简单的”补丁脚本目录”。一些当天写、一周后可能扔掉的 Python 小脚本和 shell one-liner。这些不是”正式代码”，但是 Fix Forward 的肌肉。

如果上面任何一条没配齐，你的 FDE 工作里相当一部分是不可能 Fix Forward 的。第一周如果没拿到这些权限，第一周就要主动跟客户和你公司里负责的人争取——这件事拖到第三周再要，对方会觉得”这本来就不是 FDE 该有的权限”，沟通成本翻倍。

如果你刚转岗成 FDE，发现这四项目前一个都没有——不要慌，这是常见状态，不是你失败。这四项权限的边界谈判（怎么让客户安全地给你 staging 部署权、怎么让你公司给你 main push 权）涉及组织信任建设，第 11 章会展开。本章你需要做的是把这四项写下来当作”第一个月内必须解决的事”，不是当作”已经该有的”。

2.4 三条的关系

三条不是平铺的，是一个判断链。

    Sell the outcome   →   决定你做什么
           ↓
      Eval-driven      →   决定你怎么知道做到了
           ↓
     Fix forward       →   决定你在哪里修问题
           ↓
       outcome 达成
           ↓
      （下一个 outcome）

第一条决定”做什么”——没有 outcome，做什么都是浪费。第二条决定”做到没做到”——没有评估，你和客户都靠感觉，最后谁都说不清。第三条决定”在哪里修”——不在现场修就不叫 FDE。

回到第 1 章的四阶段：每个阶段最容易违反的铁律不一样。Discovery 阶段最容易违反第一条，把客户嘴里的”功能”当成 outcome 直接做。Scaffolding 阶段最容易违反第二条，把演示版当成”完成”，没有评估集就 sign-off。Production 阶段最容易违反第三条，把生产问题往总部推，让客户等。

知道自己在哪个阶段，就知道当前最该重点防哪条。这是第 1 章那个”阶段判断”为什么重要的真正原因。

2.5 怎么向团队和客户讲清这三条

实际工作里你需要把这三条”销售”给好几个角色：

你自己公司的产品和销售（他们会把”卖产品”灌输给你）
客户的项目经理（他们会把”做功能”压给你）
客户的 CTO（他会把”AI 战略”压给你）

每个角色面前都说一遍，避免最常见的误解。一个可以照搬的中文话术：

“我接手这个项目第一件事是先敲定一个数字——比如客户经理找一份条款的中位时间从 4 分 30 秒降到 30 秒。然后我会建一个 80 条的评估集，每周跑分。所有 PR 没过评估不进 main。3 个月后我交付时您看到的不是’AI 系统’，是’中位时间从 4 分 30 秒到 27 秒’这个数字。”

讲完客户基本会同意。如果不同意，问题更大——客户自己不知道要什么 outcome，那你应该先做 Discovery（第 4 章），不是开始写代码。

收尾

回到本章开头的三个场景：

凌晨修复要不要发 staging？ 看修的是评估集上能跑分的功能（发，让客户看真实状态），还是客户没要求过的边角优化（等，别给演示加风险）。这是第一条+第二条的合用：你为评估集上的进步负责，但对超出 outcome 的”自我感动改进”克制。
客户当场加新需求要不要接？ 不正面接。先翻译成”这服务什么 outcome”，然后用数据回答。这是第一条加上”用数据反对”的工程动作。
5% 脏数据当场修还是回总部排期？ 当场修一个 30 行补丁救急，同时把通用方案的 PR 排进 backlog。两条线并行。这是第三条。

三条铁律不是抽象戒律，是 FDE 每天具体取舍时的判断标尺。

下一章把镜头再退一步——同一个 FDE 角色，在做”LLM 应用项目”和做”数据交付项目”（前者对模型负责，后者对数据 schema 和管道负责）时具体动作差很远，但三条铁律的内核是一样的。理解两种形态什么时候切换，从你第一个项目的第一周就开始用得上。

本章引用的公开资料

Bob McGrew @ Y Combinator (2025) — “Sell the outcome, not the product” 的来源访谈（brgr.one 的 The FDE Playbook for AI 给了文本化整理）
A. Lawrence, Forward Deployed Engineer Rule Book (2025) — Fix Forward 的最早系统化表述
Anthropic / OpenAI 工程博客 — 关于 LLM 应用 evaluation-driven 开发的公开材料

完整书目和链接见全书末尾的 参考文献。

← 上一章：FDE 的真实工作流 · 下一章：两种 FDE 形态 →

第 2 章 三条铁律