
> 甲方 FDE 手记 ②｜方法
> 系列主线：AI 落地不是交付一个系统，是建立一套让 AI 能活下来的机制。本篇讲这套机制的方法层。

---

## 开篇：承诺“全对”是条死路

我在内部推 AI 工具这两年，见过一种反复出现的场面。工具做出来了，跑给业务看，几十条数据里有几条不对，当场就有人变脸：“这玩意不行啊”。

这时候解释“大语言模型是概率系统”没有用。业务不关心概率，他关心的是这几条错了会不会算到他头上。

做后端出身的人对“验收”这两个字是有肌肉记忆的。写死的代码，输入 A 就永远输出 B，单元测试跑过几百个用例才敢往生产发。我们习惯了“验收等于全对，错一个 case 就是 bug”。Agent 不是这类东西。同样的输入，它大多数时候对，少数时候跑偏，而且它不会主动告诉你这次跑偏了。

所以企业里做 AI 应用，承诺“全对”是条死路。能承诺的只有一件事，就是错了能被抓住。

抓住它靠的不是更好的模型，是三样工程件：一把尺子，一个刹车，一份权属。换成我们熟悉的名字，就是评测集、兜底层、责任链。三样东西和单元测试、熔断降级、灰度发布是同一类东西，只是这次要拦住的不是服务雪崩，是模型的幻觉。

本篇把这三关拆开讲，每关给出能照着抄的最小交付，以及它要付的代价。

---

## 先看全景：三道关各自管什么

三者的分工可以这样记：评测集是尺子，回答“这次改动有没有让它变差”；兜底层是刹车，回答“不确定的输出怎么处理”；责任链是权属，回答“出错算谁的”。

| 部件 | 回答的问题 | 缺了会怎样 | 主要成本 | 部署顺序 |
|---|---|---|---|---|
| 评测集 | 有没有变差 | 优化全是盲改，验收全靠感觉 | 人工标注 | 1 |
| 兜底层 | 不确定的怎么处置 | 一次事故，项目直接下线 | 复核人力 | 2 |
| 责任链 | 出错算谁的 | 业务不敢用，工具闲置 | 改流程、改 KPI | 3（但要最早启动） |

三样不是并列关系，是一条链。尺子量得出问题，刹车拦得住，权属定得清，最后错误样本还要回流进尺子。少任何一环，另外两环都会退化成摆设。

顺序上有个反直觉的地方：责任链排在第 3，不是因为最不重要，恰恰因为它最慢。改流程要动 KPI、改汇报关系，走完一轮可能几个月。它要最先启动，但不能等它落定才上前两关。

---

## 第一关：评测集，先有尺子再谈效果

### 定位

在回答“这个 Agent 效果好不好”之前，得先有办法回答“这次改动让它变好了还是变差了”。评测集就是这把尺子。

### 被什么痛点逼出来

改 prompt、换模型、调检索参数，这三件事我们每天都在做。没有评测集的时候，判断效果好坏的办法是把几个例子跑一遍，看着“好像顺眼了”就发上线。

这跟没有单元测试就重构代码是一回事。不是不行，是找死。改了三处，可能两处变好、一处变坏，肉眼看不出来。更麻烦的是模型会换代。今天调好的 prompt，半年后换一个模型版本可能就不灵了，而你毫无察觉。

MIT NANDA 2025 年那份《The GenAI Divide》给的根因判断很直接：多数 GenAI 系统不保留反馈、不适应上下文、也不会随时间改进。没有评测集，你连“它变差了”这件事都发现不了，改进更无从谈起。

### 最小可交付物

一个能进 CI 的评测集，两样东西就够：用例的字段结构，以及抽样怎么分层。

字段结构，我用的是这个：

```yaml
# evals/cases/refund-triage.yaml
- id: case-0042
  bucket: production            # production | adversarial | edge | replay
  intent: 判断一笔退款申请是否应自动批准
  role: 客服专员
  retrieval_shape: partial      # full | partial | missing | contradictory
  difficulty: medium            # easy | medium | hard | adversarial
  input:
    user_query: "..."
    context_refs: ["order-8812", "refund-history-77"]
  expected:
    decision: 转人工
    reason_contains: ["超出授权额度"]
  rubric: evals/rubrics/refund-triage.md
  source: trace-20260811-a93f
  replayed_from: null           # 若由 bad case 回流生成，填原 trace id
```

五个字段值得单独说。

`bucket` 决定这条样本在回归里扮演什么角色。`retrieval_shape` 是检索形状，RAG 系统大多数失败不是模型答错，是上下文没捞全、捞到冲突的、或压根没捞到，漏掉这个轴就漏掉了最常见的失败原因。`rubric` 把判定标准外置成文件，不要在用例里写死“应该输出 X”，规则会变，用例不该跟着改。`source` 记录这条从哪条真实 trace 来的，没有来源的样本，半年后没人敢删也没人敢信。`replayed_from` 留给回流用，见后面那节。

抽样分层用四桶，这是 2026 年几家公开的评测工程实践里比较常见的一种分法：

| 桶 | 来源 | 占比 | 证明什么 |
|---|---|---|---|
| 生产流量分层抽样 | 线上 trace 导出 | 60% | 能处理真实流量 |
| 对抗性样本 | 越狱语料、红队测试 | 15% | 攻击下扛得住 |
| 边缘案例 | 领域专家手写 | 15% | 长尾能处理 |
| 失败回放 | 已发生的错误 | 10% | 不为同一个 bug 反复付账 |

四桶里最值钱的是第四桶：它把过去犯过的错固化成资产，让同一个坑不用踩第二次，也是后面回流机制的落点。

### 代价

四条，都不轻。

1. **标注成本是实的。** 想要 300 条能用，通常得从一千多条原始 trace 里挑，还要逐条写判定标准。这笔时间省不掉，也不能外包给不了解业务的人。
2. **评测集会过期。** 业务规则变了、产品流程改了，用例里的期望输出就作废了。见过太多评测集建完半年没人维护，跑出来全绿，实际测的是一个已经不存在的系统。
3. **评测集自己可能有偏。** 样本全来自某一段时间流量，或者全由一个人标注，测出来的就是那个切片，不是你的系统全貌。
4. **团队会开始为评测集优化，而不是为业务优化。** 这条最隐蔽。指标一旦进了考核，人就会去讨好指标。判据很简单：评测分数一直在涨，业务侧投诉量没变，你大概已经掉进这个坑了。

### 判据

什么时候不值得建评测集？低频、低风险、人工本来就很快的场景。一个月跑几次、错了也没后果、人自己看一眼只要几秒钟，这种场景建评测集的成本高于收益，不如直接加一个人工确认。

多大合适？不是越大越好，是分层覆盖够不够。100 条精心标注的样本，比 5000 条模型合成的样本有用得多。

### 常见错

用模型生成的样本当评测集。这等于让考生自己出卷自己判。合成样本可以用来做压力测试、扩充边缘覆盖，不能用来证明效果。

真要评估，判定环节也得留一手：用不同模型家族做裁判，同家族模型有系统偏差；裁判和人工标注的一致率低于 80%，先把裁判 prompt 改好再说；输出要结构化，让裁判同时给出分数和理由，只给分数的裁判没法复盘。

还有一种更隐蔽的错法，我见过别人踩，也差点自己踩：项目刚开始，工程师在文档工具里手写了几十个 case，团队花几天标注完接进 CI，从此每次构建全绿。半年后 rubric 调好了、裁判调好了、阈值校准了，分数一路向上。然后生产着火了。

问题不在 rubric 不够细，在于这套评测从第一天起测的就不是线上那个系统。样本是凭想象写的，不是从真实 trace 里捞的；规则变了没人同步；每次全绿只是说明你越来越擅长通过一场自己出的考试。判断标准很简单：**评测集里有多少条能指出它来自哪条真实请求？** 答不上来，就不是评测集，是一份愿望清单。

---

## 第二关：兜底层，置信度低的不直接对外

### 定位

评测集告诉你整体准不准，兜底层处理的是另一件事：具体到这一条，信不信得过。

一个整体准确率 95% 的系统，意味着每一条都有 5% 的可能出错。整体数字再好看，落到具体某一条上时，你只有信和不信两个选择。兜底层就是做这个选择的机制。

### 被什么痛点逼出来

不确定的输出直接给了业务，就是一个事故。而事故在 AI 项目里的代价特别高。一个智能客服跑了一个月，某一单答得离谱被截图发群里，第二天项目下线。人对人是默认容错的，对机器是默认零容错的。

所以低置信度的输出必须有个去处。机器处理大头，人盯住小头，这套逻辑和熔断降级是同一套，只不过这次熔的是模型的幻觉。

### 最小可交付物

不要用一个阈值切两半，用两条线三个区：

```python
# 双闸门路由：两条线，三个区
UPPER_GATE = 0.90   # 之上：自动执行
LOWER_GATE = 0.70   # 之下：专家升级或直接拒绝

def route(confidence: float, risk_tier: str, reversible: bool) -> str:
    if confidence >= UPPER_GATE:
        # 高置信也要看动作范围：不可逆动作一律不放行
        return "auto" if reversible and risk_tier == "low" else "review"

    if confidence >= LOWER_GATE:
        return "review"          # 真正的不确定区，人能补上模型没有的信息

    # 低于下闸：模型不知道自己不知道
    # 送给没有上下文的普通审核员，比直接拒绝更危险
    return "escalate_or_refuse"
```

下闸之下那一区是最容易漏的。直觉上“不确定就给人看”是对的，但如果模型连自己哪儿不知道都不知道，把它丢给一个同样没有上下文的审核员，他大概率会盖章通过，这比直接拒绝更糟。

### 代价

复核队列要人盯，这是实打实的人力成本，省不掉。设计目标不是消灭这个队列，是让它稳定在一个班组能吸收的规模。

阈值定高定低都是两难。定高，人工量大，工具价值被稀释；定低，漏网多，出一次事全场皆知。没有标准答案，只能靠数据调。

### 判据

阈值靠数不靠猜。取两百条标注样本跑一遍，记录每条置信度，看准确率在哪个点断崖下跌，那个拐点就是阈值。公开实践里两个分类器的拐点分别落在 0.72 和 0.55，差得很远。不存在通用默认值，别抄。

校准不是一次性的。按月重校准，看两个信号：自动执行区被人工推翻的比例如果明显高于复核区，说明上闸定低了；复核区被推翻的比例接近 0，说明上闸定高了，审核员只是在盖章。行业实践给的经验区间是复核区推翻率稳定在 8% 到 25% 之间，说明人确实在改模型的判断，而不是在执行一个橡皮图章。

不可逆的决策必须同步复核。涉及资金、合同、对外承诺的动作，让人等几分钟的代价，远低于做错的代价。异步复核只适用于做错了还能撤回的场景。

置信度也不该是唯一的信号。纯靠一个分数路由，会把大量其实很确定的样本也送进人工队列，因为模型自评本来就偏保守。多信号路由的做法是同时看几样：模型置信度、这个领域的风险分级、涉及实体的历史风险画像、这次请求跟训练集比有多新颖、这个类别过去一段时间的实际准确率。公开实践里，多信号的升级率比纯置信度低三到五成，缺陷检出率还相当或更好。人工队列少了，但没放过该拦的。

### 常见错

全局一个阈值。分错一条评论和分错一笔交易，后果差几个数量级，阈值不该一样。至少按领域风险分级拆成几档。

信模型自评的置信度。这是最贵的一个坑。2026 年公开的一个理赔分类案例里：模型自评 0.92 判为常规，实际批错了一笔金额不小的赔付。后来改成用平均 logprobs 而不是让模型自己打分，并在低分区加人工层，次月自动批准的错误归零，人工队列稳定在一个班组二十分钟能处理完的规模。

说到底，模型对自己答案的置信度，告诉我们的不比答案本身多多少。

低置信的时候也别急着送人工，先走便宜的路径：更锐利的 prompt 重试一次，再不行换更强的模型，最后才到人。重试要设上限，通常两次，否则你只是把失败变慢变贵了。

---

## 第三关：责任链，出错算谁的

### 定位

前两关解决能不能抓住错，这一关解决的是：抓住了之后，谁为它负责。

### 被什么痛点逼出来

工具把一段活压到原来的零头，省下来的时间去哪了？这是我在现场反复遇到的问题。答案不是省掉了，是转移到了别的地方：谁来确认、出错了算谁的、KPI 怎么算上。

责任不清的时候，业务不敢用。不是不想用，是不敢签那个字。很多 AI 项目不是被技术杀死的，是被责任真空饿死的。

这一条在金融行业尤其硬。证监会科技监管司在 2026 年 6 月公开讲过行业面临的四类挑战，治理层面就点了“主体权责界定模糊”。这不是我们自己的观察，是监管机构点名的问题，本系列第三篇会展开。

### 最小可交付物

责任链模板，三层就够：

| 层 | 内容 | 谁签字 |
|---|---|---|
| 建议层 | AI 输出，标注置信度与依据 | 不签字 |
| 定稿层 | 人工确认后的结果 | 业务岗 |
| 追责层 | 出错时的归属规则 | 事先约定，不事后议 |

关键在第二层。AI 输出只是建议，人工确认才是定稿。这行字写进流程文件，比任何技术方案都管用。业务部门一看，这东西不让我背锅，还能提效，才真的会用。

质检角色要独立于执行角色。这是我做研发交付智能体时最坚持的一条。把研发流程拆成七个角色之后（PM、业务分析师、方案设计师、方案评审员、开发工程师、代码审查员、测试工程师），有三个角色专门干一件事：检查别人的产出。方案评审员审方案，代码审查员审代码，测试工程师独立验证，谁都不审自己。

这跟责任链是同一件事在架构层的对应物：质量把关不能自己说了算。人和人之间是这样，智能体和智能体之间也得是这样。让生成代码的那一个顺手给自己打分，评分一定好看，也一定没有意义。

### 代价

三关里这一关最难。改流程就要改 KPI、改汇报关系，会得罪人。这是组织成本，不是技术成本，也没有技术解法。

### 判据

哪些环节必须人工确认，哪些可以放行？判据是错误的不可逆程度：

- 错了能撤回、代价低：可以放行，事后抽检
- 错了要外部沟通、要走流程撤回：抽检加兜底
- 错了不可逆、涉及资金或对外承诺：必须人工确认，且同步

### 常见错

把责任推给“AI 还在学习”。这句话说出口，意味着没人负责。而在业务看来，还在学习和不可用是同一个意思。

---

## 把三关串起来：bad case 回流

三样东西各自都能起作用，但真正让系统变好的是把它们接成一条链，让线上出错的样本自动回到评测集里。

```
线上 trace
   │
   ├─ 触发（人工推翻 / 用户投诉 / 兜底层拦截且复核判定为错）
   │
   ├─ 人工确认：这条确实是错的，期望输出是什么
   │
   ├─ 入集：写入 bucket=replay，replayed_from=原 trace id
   │
   └─ 门禁：进入回归，下次改动必须过这一条
```

最后一步是关键。回流进来的样本如果只是躺在目录里，等于什么都没做。它必须进 CI，成为下次发版的一道门槛：这次错了，下次就不许再错。

有句话说得挺准：只是把日志存下来，没有人看、没有人处理，AI 不会因为用得多了就自动变好。日志的价值不取决于存了多少，取决于有没有回流机制，以及有没有人守着它。

这套结构有个好记的对照：把 AI 当成一个新来的实习生来管理。

实习生交上来的东西不能直接发给客户，得有师傅先过一遍，这是兜底层。师傅改出来的那些错要整理成带教笔记，下一个人不再犯，这是回流机制。至于这个实习生什么时候能独立干活，不看他自己说行不行，看师傅定期抽查的结果，这是评测集。

带一个新人，和上一个 AI 系统，要操心的事情其实差不多。

---

## 部署顺序，与四个自检问题

部署顺序：先建评测集。没有尺子，后面两关的调优全是盲改。再上兜底层，先保证不出事。责任链最后落，但要最早启动，因为它最慢。

自检四问：

1. 最近一次改 prompt 或换模型，有没有一个数字能告诉你效果变好还是变差？
2. 置信度低的输出，有没有一个明确的去处，而不是直接给了业务？
3. AI 的产出和人工确认的结果，在流程文件里有没有分开写？
4. 线上犯过的错，有没有变成下次必须通过的测试？

四问里任何一问答不上来，对应的那一关就还没建起来。

这套东西不是 AI 技术，是工程方法论。模型每年换代，今天的最强模型明年就是地平价，但尺子、刹车、权属这三样不换。你在这一关投入的东西，可以跨模型复用。

还有一点我的体会：确定性交付的方向，可能不是让 AI 更强，而是让 AI 更懂你，也就是把约束、上下文、角色边界做扎实。这份投入比等下一个模型版本更可控。

本篇讲的是方法。下一篇讲底线：在金融行业，有哪些东西是买不来的。


甲方 FDE 手记 ②｜方法 系列主线：AI 落地不是交付一个系统，是建立一套让 AI 能活下来的机制。本篇讲这套机制的方法层。

甲方内部 FDE（二）：从 demo 到上线要补的三道工程关

企业里做 AI 应用，承诺“全对”是条死路，能承诺的只有一件事：错了能被抓住。这篇讲从 demo 到上线要补的三道关：评测集是尺子，回答有没有变差；兜底层是刹车，回答不确定的输出怎么处置；责任链是权属，回答出错算谁的。三样是一条链，线上犯过的错要回流进尺子。每关都给了最小可交付物、代价和判据。这套不是 AI 技术，是工程方法论，模型年年换代，这三样不换。

后端

人工智能

架构设计

甲方FDE手记②｜方法主线：AI落地不是交付系统，是建机制。核心三件套：评测集做尺子、兜底层当刹车、责任链定权属，靠badcase回流闭环。先建评测集，再上兜底层，责任链最早启动但最慢落地。四自检：改动有效果数字吗？低置信有去处吗？AI与人工产出分写了吗？线上错误回流成测试了吗？

单元测试

压力测试

代码解释

智能体

路由

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

甲方内部 FDE（二）：从 demo 到上线要补的三道工程关-腾讯云开发者社区-腾讯云

甲方内部 FDE（二）：从 demo 到上线要补的三道工程关

甲方内部 FDE（二）：从 demo 到上线要补的三道工程关

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐