第 12 章 PoC 到生产：哪些过线，哪些卡死
苏州合昇精密重工，海外业务部。第 10 周周三下午。
工单 Agent 在 staging 上跑了快五周。第 6 章那张选型纸还贴在我工位上，第 8 章的 eval-v1（200 条）每天 CI 跑一次，第 11 章那四件事（SSO/SCIM/IAM/审计）顾建国上周三在他的 A4 清单上一项一项打了勾。陈雪带老师傅试了 60 多条真实工单，分诊准确率 94%。董事会十一月底要看上线效果——还剩八周。
那天下午我以为是来对一下”上线时间表”的。周明远把会议室门关上，桌上摆了三张纸：合同附件、IT 委员会的”上线准入清单”、海外业务部的 SLA 草案。他说：”Agent 我看够好了。但我下周一要在执委会上回答三个问题。一，我怎么知道它真的能上？二，万一上了出事，我怎么往回切？三，第一年合同我们到底付多少钱、按什么付？”
这三个问题分别对应这一章三件事——过线条件（什么算”够好”）、回滚剧本（出事怎么办）、合同条款（钱怎么走）。我那天下午没有当场答全。下面写的是我接下来一周做完的事，以及上线之后回头看，哪些是对的、哪些差点出事。
12.1 PoC 不是生产的预演，是生产的招贴画
Lawrence 在 FDE Rule Book 里有句话我反复用：”The PoC is not the project — it’s the trailer for the project.” 这句的实操含义是：PoC 阶段的工程指标和生产阶段差一到两个数量级，你不能指望”这个 demo 跑得好，照搬上去就行”。
我自己经历过把 PoC 当生产用的事故，也见过 Conikeec 在 FDE Playbook 里描述的同类场景——demo 阶段没接监控、没做压测、没和客户 IT 对过架构，签了合同之后 IT 列出几十条修改意见，重做花掉项目大半时间。这件事每个老 FDE 都能讲一个版本。
但合昇这个项目我没让它发生。原因是 Discovery 阶段（第 3 章）我画过一张”PoC 和生产差什么”的对照表。这张表在第 6 章选型时帮我把”primary 选 haiku 不是 opus”这个决定稳住了，第 11 章帮我把”安全准入”提前 4 周拉进议程，到第 12 周这里它要回答的是周明远第一个问题——“够好”的定义。
PoC 标准 生产标准
───────── ─────────
并发 单用户 ~100 QPS（合昇的目标）
可用性 "demo 能跑" 99.5% 月度
延迟 P50 5 秒可接受 P95 < 3 秒
容错 出错重启 自动重试 + 隔离 + fallback
可观测 console print 全链路 trace + cost
权限 FDE 手里 admin RBAC + 离职 24h 收回
发版 "我手改 prompt" CI/CD + 灰度 + 回滚
客户 FDE 在现场 客户运维独立 oncall
这张表不是给客户看的——是给我自己看的。每两周我对一遍，看 staging 上的现状离生产标准还差多少。第 10 周对完，差距落在四块：没做过压测、没有金丝雀、没演练过回滚、SLA 数字客户那边没拍板。剩下八周，我得把这四块补完。
12.2 五项硬阈值：什么数字达到才算过线
我把”够好”的定义在合同附件里写成了五条，每条一个数字、一个测量办法、一个签字方。这五条没达到，我不签 GA（General Availability）。这件事 Anthropic 在他们的 Building Effective Agents 里的态度是一致的——上线前你必须有可量化的过线条件，否则团队会一直在”再调一调”里漂着。
┌────────────────────────────────────────────────────────────────┐
│ 维度 过线阈值 测量办法 │
├────────────────────────────────────────────────────────────────┤
│ 准确率 eval-v1 派工 ≥ 0.92 CI 每日跑, 三天滚动平均 │
│ 故障类型 ≥ 0.80 │
│ │
│ 性能 P95 < 3s @ 100 QPS 生产场景压测, 30 分钟稳定 │
│ 冷启动后第一次调 < 5s │
│ │
│ 成本 单工单 ≤ ¥0.05 按月推算 ≤ 合同预算 90% │
│ │
│ 可观测 调用 100% 落 CloudTrail Bedrock invocation logs │
│ prompt/response 抽样 10% 接 staging 30 天可查 │
│ │
│ 灰度 1/10/50/100% 可切 演练过一次完整往回切 │
└────────────────────────────────────────────────────────────────┘
每一行都得拍一个具体数字。0.92 是怎么来的？陈雪和王师傅给的——他们说一线老师傅自己派工，错误率大概在 7-8%。Agent 至少要打平。3 秒是怎么来的？调度员在 ERP 里手动派工平均 2.5 秒，Agent 慢 0.5 秒以内体感是”差不多”，超过 3 秒就开始抱怨。¥0.05 是怎么来的？第 6 章选型表上 primary+fallback 混合的模型成本量级，再叠加 KB 检索 + 应用层日志的额外开销，留 10% 缓冲拍 ¥0.05。
数字不是从空气里抓的，每一行能讲出来源。客户可以挑战你的数字，但他不能说”你没数字”。
写进合同附件之后，这五项的归属就清楚了：准确率和成本归我（FDE 团队），性能和灰度归我和顾建国共担，可观测归顾建国。哪一项过不了线，对应的人出来解释。这件事比”大家一起对项目负责”具体得多。
我以前犯过的错是把这五项写成”上线前 review 一次”。结果上线前一周才发现 eval 上不去，临时加塞优化两周，团队都熬大夜。这次我把五项写进 CI——每天都跑，每天都看离过线还差多少。过线条件不是 ship 前的检查项，是项目从第 4 周开始的日常仪表盘。
12.3 灰度发布的四档与一次回滚演练
周明远第二个问题——出事怎么往回切。这一节就是答案。
灰度的目的不是”分阶段上线”那么简单。它的真正价值是给你一个可回退的渐变：1% 出问题不会伤客户，10% 能看出真实流量下的边角，50% 能验证容量。每一档之间得有”留观”的时间——不是”切完就走下一档”。
合昇这一期我设计的四档是这样的：
┌─────────┬────────┬──────────────┬─────────────────────────┐
│ 档位 │ 留观 │ 路由策略 │ 升档条件 │
├─────────┼────────┼──────────────┼─────────────────────────┤
│ 1% │ 48 小时 │ 随机抽样 │ 错误率 < 1%, P95 达标 │
│ │ │ │ 业务方人工抽查 20 条无差错 │
│ │
│ 10% │ 5 个工作日 │ 按地区, 雅加达先 │ eval CI 三天稳定 │
│ 成本曲线在预算内 │
│ │
│ 50% │ 1 周 │ 加上吉隆坡 │ 客户运维独立处理过 1 次告警 │
│ │ │ │ 没回滚 │
│ │
│ 100% │ - │ 全量 │ - │
└─────────┴────────┴──────────────┴─────────────────────────┘
为什么从雅加达开始？陈雪挑的。雅加达站点工单量中等、调度员资历最浅、以前出过几次派工差错——意思是这个站点对 Agent 的容错最高（反正人工也会错），出问题”显得不那么离奇”。这种”先在哪个客户口袋里灰度”的判断不是技术决定，是业务方决定，FDE 不能替客户拍。
回滚剧本得演练，不能光写在文档里。第 11 周我和顾建国约了一个晚上，在 staging 上做了一次完整的”假装出事”：
T+0:00 人为把 KB 检索的超时调到 200ms（正常 800ms）, 注入失败
T+0:02 告警触发: 错误率从 0.4% 跳到 19%
T+0:03 on-call 收到 PagerDuty
T+0:05 顾建国看 dashboard 定位到"KB 调用 timeout"
T+0:07 决定: 1% → 0%, 全量切回旧版（手工派工）
T+0:08 切回完成, 错误率回落
T+0:30 根因复盘, 写 5 行 incident note
这次演练我们发现了三件事：一，PagerDuty 的告警规则有个漏洞——错误率算的是 5 分钟滑动平均，从 0.4% 到 19% 触发要 90 秒，比我估的快不了多少。我们改成 1 分钟窗口 + 3% 阈值就告警；二，”切回旧版”按钮我们一开始放在了一个需要 SSO MFA 的 console 里，凌晨两点 oncall 翻 token 翻了 4 分钟。我们后来把回滚做成了一条 Slack /rollback 命令，背后是一个签好的 Lambda，回滚到 0% 不需要再走 console；三，”切回旧版”等于回到全人工派工，海外站点夜班调度员只有一个人，他的工作量翻倍——这件事我们之前没想过。
第三条最让我心里一沉。回滚不是”切个开关那么简单”，回滚是把客户的运营状态切回到一个旧版本——那个旧版本得真的能扛得住此刻的流量。我和陈雪重新算了一遍，把 100% 灰度推迟到了印尼当地白天班次足够覆盖的时间窗。这件事课本里不会写，但每个老 FDE 都遇过一次。
回滚演练这事我觉得不亚于压测重要。FDE 圈子里把这种”故意打坏一次系统”叫做 chaos drill，Anthropic 在自己的 agent 文档里也建议你”假装一次告警发生”完整跑一遍。光写文档没用——文档里你能写”5 分钟内回滚”，演练里你才会发现凌晨两点登 console 翻 MFA 用了 4 分钟。
12.4 客户 IT / 法务 / 安全的三道审视
PoC 期间业务方满意 ≠ 项目能上。第 11 章顾建国那张准入清单已经替我把”安全”这一道处理完了。但 IT 和法务这两道，是我在第 10 周才补的课。
IT 委员会评审。合昇的 IT 委员会每月一次，我赶了第 10 周的最后一次。需要交三份材料：架构图（Bedrock VPC endpoint + Identity Center + ECS dispatcher）、变更影响分析（这次上线影响哪些现有系统）、灾难恢复方案（RTO < 30 分钟、RPO < 5 分钟）。第一次评审我栽在变更影响分析上——我没注意到工单 Agent 调 ERP 时会触发 ERP 那边的一个旧 webhook，在某个边角场景下会重复创建一条派工记录。IT 委员会让我两周后再来。
这件事老 FDE 应该早就提防的，我也写进自己的失误清单里：任何”我们就调一下你们的 API”，都要在客户那边的系统里做一次完整的端到端验证。客户的 webhook、事务幂等性、消息重投策略，是 FDE 经常踩的坑。
法务评审。合同附件的”AI 服务条款”是法务最关心的部分。三件事必须写清：
- 数据归属——客户工单数据进 Bedrock 训练吗？答案是不会（Bedrock 的数据保护文档写得很清楚——客户的 prompt 和 completion 不被 AWS 用于训练基础模型）。这一行我直接抄到合同里，附 URL。
- 错误责任边界——Agent 派工错了导致的损失谁担？我们定的是”Agent 错误导致的直接成本（重新派工的差旅、备件二次配送）由我们承担，间接损失（客户停产、商誉）双方协商”。这一条我和合昇法务来回改了 5 遍。
- 数据驻留——客户工单数据走 cross-region inference 到 us-east-1（4.6 模型）会不会出新加坡？会。这一条我没法改。我能做的是把它写明白，让客户法务看完拍板”接受”还是”不接受”。合昇法务接受了——条件是 Bedrock invocation logs 在新加坡区落盘可查。
法务评审给我的最大教训是——不要试图”绕过”或”含糊”任何一条客户能问出来的问题。法务最敏感的是”含糊”，明明白白的”我们做不到 X”远好过含糊其辞。
安全评审。这一步顾建国第 11 章已经替我跑完。我额外补了一件事：把 Anthropic 的 Responsible Scaling Policy 摘要附到合同里——客户安全问”模型有没有红队测试过”，这是公开能引用的依据。
12.5 合同里钱怎么走
周明远第三个问题——第一年合同到底付多少钱、按什么付。这一节是 FDE 真实做项目最容易”不舒服”的一节。但如果你不和客户对清楚钱的逻辑，上线第一个月账单出来吵架，没法善后。
合昇这一期我用的是”三段式”：实施费 + 月度服务费 + 用量阶梯。
实施费 一次性 ¥X 覆盖 12 周交付（Discovery → 上线）
里程碑付款: 30% kickoff + 40% staging + 30% GA
月度服务费 每月 ¥Y FDE on-call、Eval 维护、月度 review
首年含 4 次现场支援
用量阶梯 按月工单量计费 < 5k 单/月: 包含在月度服务费内
5k-20k: ¥0.05 / 单
> 20k: ¥0.04 / 单（递减）
超 50k 触发架构 review
这三段每一段我都能解释为什么这样切。
实施费——合同期内不变。客户怕的是”做着做着加钱”。FDE 这一侧怕的是”做着做着加需求”。两边博弈的解法是把里程碑写死、每个里程碑挂一个清单（Discovery 5 件物料、staging 通过五项硬阈值、GA 是灰度到 100%）。哪个清单没达成，那一笔钱不付。
月度服务费——保住 FDE 团队的 oncall 能力。这一笔不能省，省了就是”上线即抛弃”。但这一笔也得对得起客户——所以把”4 次现场支援”写明白。客户知道自己买的是什么。
用量阶梯——这是新模式。传统软件按 license 卖，AI 应用按调用量卖才合理（成本本来就是 per-call 的）。三段式有两个用意：一是低用量不让客户感觉”花钱没用”（包含在月度费内），二是高用量主动触发架构 review（超 50k 单/月可能要重新选型，比如全量上 haiku 不再用 opus fallback）。
我自己在过去几个项目里栽过的坑是没把 fallback 比例的浮动写进合同。上线之后客户那边出了一波”奇怪的工单”（比如某个新设备型号刚导入），fallback（opus）被触发的比例从预期的 5% 涨到 22%，单工单成本飙到 ¥0.13，月底账单超预算 60%。客户老板看到账单火很大，FDE 团队两边解释。这次合昇这一期我把”fallback 触发比例 > 12% 时自动告警 + 暂停服务等待人工确认”写进了合同附录——给我一个紧急刹车，给客户一个心理上限。
我把这三段拍成 Excel 给周明远，他看了五分钟。”实施费比 ISV 报的贵 20%。月度服务费比 ISV 便宜 30%。用量阶梯没人这么算过。” 我说：”实施贵是因为我们 12 周里嵌着客户做，不是按需求单交付。月度便宜是因为我们的边际成本主要在 Bedrock 用量上，不在 license 上。用量阶梯按 per-call 算是因为这就是 AI 应用的真实成本结构。”
他签了。
这套定价我不是发明的，是从 Palantir 早年的”驻场顾问 + 平台费”模式（Nabeel Qureshi 在 Reflections on Palantir 里提过类似结构）和现代 AI 应用的 per-call 计费模式拼出来的。原理是把”FDE 的人工时间”和”AI 的可变成本”分开算。混在一起算，要么客户觉得贵，要么我们做亏。
12.6 上线前最后两周的节奏
第 11 周到第 12 周这两周是合昇这个项目最紧张的两周。回头看节奏大概是这样：
W11 周一 雅加达 1% 灰度启动
W11 周二-三 留观, 业务方抽查 20 条
W11 周四 回滚演练（12.3 那次）
W11 周五 复盘 + 把演练发现的三件事修掉
W12 周一 10% 灰度（雅加达全量）
W12 周二-三 留观, eval CI 看三天
W12 周四 50% 灰度（加吉隆坡 + 曼谷）
W12 周五 100% 灰度
下午 3 点 周明远 / 陈雪 / 顾建国 在合同上签字 GA
W13 周一 Handoff 启动（第 17 章）
我开始把工作交给客户运维
这两周里我每天的标配是：早上 9 点看 dashboard 半小时（错误率、P95、成本曲线、eval 滚动平均），上午陪顾建国处理上一晚的告警（不接电话，看他怎么处理），下午陪陈雪做工单抽查（她抽 30 条，我们一起看 Agent 派工的依据是不是合理），晚上把当天的 incident（如果有）写 5 行 note 进项目文档。
FDE 在 GA 前两周的角色不是”加班 fix bug”，是”陪客户运维上岗”。Bug 这时候应该已经被 eval 和压测洗得差不多了。这两周真正的工作是把”客户能不能不依赖你独立维护”这件事压实。
这一点和第 1 章我反复强调的”判断自己在哪个阶段”是同一件事——上线前两周如果你还在写新功能，说明你之前的阶段没做完，这个项目大概率走不长。
12.7 一些不那么显眼但救过命的细节
写完上面六节，我回看自己上线前 dashboard 的 watchlist，发现有几件事不在任何”上线检查清单”模板里，但每一件都救过我至少一次。
第一，cold start 的延迟。Bedrock 第一次调用某个模型有冷启动延迟，凌晨低流量时段尤其明显。我们的 dispatcher 加了一个”每 5 分钟空 ping 一次 primary 模型”的 keep-warm，单独算下来一个月几十块钱，省掉了凌晨调度员的一次次”卡住”投诉。
第二，prompt 版本号写进每一条日志。我们 prompt 改过 14 个版本。CloudTrail 落的是 modelId，但 prompt 是哪一版只能在我们应用层日志里看。把 prompt_version=v14 直接写进结构化日志，事后查”为什么这条工单当时派错了”能回到那一版的 prompt。
第三，灰度比例自己记账，不依赖路由层。我们的灰度是在 dispatcher 层做的——按 ticket_id hash 分桶。但客户那边的负载均衡器看到的不是”百分比”，是请求数。dispatcher 自己写一个 routing_decision_log，每天对账：今天应该 50%，实际打过去多少。有一次发现实际只有 38%，根因是某一类工单 ID 哈希不均。这是路由层不会告诉你的事。
第四，fallback 不是只挂 opus。我们的”全挂”兜底是把工单原样转人工排队 + 给客户发一个”AI 不可用，已转人工”的通知。技术上很简单（一个 SQS 队列 + 一封邮件），但这一件事是合昇 IT 委员会签字的硬条件。Agent 全挂时不能”返回 500”，必须有一个面向最终用户的优雅降级。
第五，第一周值班 FDE 必须在客户时区。合昇海外站点雅加达比新加坡早 1 小时、胡志明市同新加坡、吉隆坡同新加坡，最早一班调度员 7:30 到岗。GA 第一周我让自己 7:00 起床盯 dashboard 到他们午休。这件事技术上没必要（监控会告警），但客户运维第一次独立处理 AI 系统的那一周，他们需要知道”我在群里 @ 一下马上有人”。这一周过完，他们就接住了。
这五件事都没写进我的”五项硬阈值”，但都该写进我的项目个人 runbook。每个 FDE 做几个项目都会攒出自己的版本，互相之间的差异比共同点大——这才是这份工作有意思的地方。
12.8 上线那天
W12 周五下午 3 点，会议室。周明远、陈雪、顾建国，三个人。
合同附件最后一页是 GA 签字栏。三个签字栏对应三件事——周明远签”业务过线”（陈雪和老师傅抽查 100 条工单 OK），陈雪签”业务方接收”（她确认这个 Agent 可以从下周一开始进入海外业务部的日常工作流），顾建国签”运维接收”（他确认 oncall 流程、监控、回滚剧本他能独立操作）。
三个签字栏一起签，少一个不算 GA。
签完之后周明远问了我最后一个问题：”你下周开始做 Handoff，我们这边的人接得住吗？”我答：”顾建国和陈雪过去六周已经在做 90% 的事了。我下周往后基本上是观察员。”他点头：”那好。董事会下周三我会汇报上线了。”
下午 5 点我离开合昇苏州办公室。第一年合同生效。
但这一章不是终点。下一章讲的是上线之后那些没人提前告诉我的事——监控的 noise floor 怎么定、成本超预算 30% 的某天我怎么处理、第一次真实回滚出现在第几周。
本章引用的公开资料
- A. Lawrence, Forward Deployed Engineer Rule Book (2025) — “PoC 是项目的招贴画” 一节的来源
- Conikeec, The FDE Playbook: A Practitioner’s Field Manual (2025, Substack) — PoC 阶段失败模式
- Anthropic, Building Effective Agents (2024) — 上线前可量化过线条件的工程实践
- Anthropic, Responsible Scaling Policy — 安全评审引用
- AWS Bedrock 文档, Data Protection in Amazon Bedrock — 客户数据归属条款
- Bob McGrew @ Y Combinator (2025) — “卖结果不卖产品”在合同三段式里的体现
- Nabeel Qureshi, Reflections on Palantir — 三段式定价里”驻场顾问 + 平台费”模式的原型