Triage

---
name: triage
description: 一堆东西挨个判同一件事（工单分派、简历初筛、反馈归类、内容合规），判得准的自动走，拿不准的挑出来给人看
---

# 批量分拣

一百条工单该派给谁、三十份简历过不过初筛、两百条用户反馈归到哪一类、一批文案有没有越线——
这类活儿的形状都一样：**同一个判断，重复很多遍**。

人做它慢且烦。你自己一条条读着判，慢、贵，而且判完说不出哪几条是拿不准的——
于是要么全都交给人复核（等于没省事），要么全都当定论（等于在赌）。

`decide` 工具就是干这个的：它走判断模型，不产文字，只回「是非 / 单选 / 打分」，
**每条带一个确定度**。这一条改变了整件事的性质：你交出去的不再是一份答案，
而是**一份能直接走的 + 一份要人看的**。

## 什么时候不该用这门技能

- 只有三五条要判——你自己顺手判了，别绕这一趟。
- 判断本身要解释、要推理过程、要写一段话——判断模型不产文字。
- 判错了代价很大且不可逆（封号、打款、删数据）。这时候它只能给「建议 + 确定度」，
  下不下手是人的事，而且**必须由人点**。

手里没有 `decide` 这个工具的话，说明这台机器还没配判断模型——直说一句「这活儿得配上判断模型才划算，去 设置 → 模型 里填一条 OpenRouter 或 TypeSafe 的 Key」，然后照用户的意思办：要么就这么等着，要么你自己硬读一遍（那就得跟他讲清楚这样没有确定度、挑不出哪几条该人看）。

## 第 1 步：先把判准问清楚，别猜

分拣做砸，十有八九不是模型不行，是判准没定清楚。动手前必须落实三件事：

1. **判什么**——一句话说完。「这条工单归哪个组」是清楚的；「这条工单重不重要」不是。
2. **有哪些档**——单选的选项、打分的档位，各自的界线在哪。
   「紧急 / 一般 / 不急」听着清楚，可「客户说 ASAP 但没说损失」算哪档？说不出来就是没定清楚。
3. **判错了会怎样**——分派错了只是转一手，还是会漏掉一个投诉升级？
   这决定门槛定多高，也决定拿不准的那些要不要人看。

用户说不清楚就用 `ask_user` 问，**这一问值得**。判准没定就跑批，跑出来的是一堆看着挺像回事的垃圾。

## 第 2 步：拿十来条试跑，先看判准立不立得住

别一上来就跑两百条。挑 10~20 条——**特意挑上几条边界的**——先跑一遍，把结果摆给用户看：

- 判得对吗？不对的话，是模型的问题，还是判准写得含糊？
- 拿不准的那几条，人看了之后觉得该判成什么？
- 门槛定在哪合适？

判准不对就改 `instructions`，把「什么算」和「什么不算」都写进去。改完再跑这十几条。
**这一轮省不得**：判准错了，跑两百条只是把同一个错误重复两百遍。

判准写法，差别很大：

| 写得含糊 | 写得能用 |
|---|---|
| 判断这条工单是否紧急 | 客户明确说了在造成损失（掉单、停服、要赔钱）算「已在造成损失」；只说「尽快/急」但没说后果算「希望尽快」；纯咨询算「不急」 |
| 这份简历合不合适 | 招后端，要求三年以上 Go 或 Java。写了年限且达标算「过」；写了但不达标算「不过」；没写年限算「看不出来」 |

## 第 3 步：跑批

一份材料一趟 `decide`，一趟最多 32 道题。两种摆法，按活儿挑：

- **一件东西一趟**（默认这样）：`state` 放这一条工单的全文，问 2~5 道题（归谁、多急、要不要升级）。
  干净，条与条之间不会串味。一百条就是一百趟。
- **一趟塞多件**：`state` 里编号列出 20 条，问 20 道题、每道指名「第 7 条……」。
  请求数少二十倍，但条与条之间会互相影响判断。**要用这种就先在第 2 步里对比一下两种摆法的结果**，
  别默认它一样准。

跑的时候：

- 每一趟的结果按条记下来，包括**确定度**。丢掉确定度等于把这个模型最值钱的一半扔了。
- 材料太长会被截断，工具会告诉你截了——截过的那几条要单独标出来，**不能跟没截的混在一起交差**。
- 中途出错（额度满、上游挂了）：把已经判完的先存下来，告诉用户跑到第几条断的，别从头再来。

## 第 4 步：交两份，不是一份

这是整门技能的交付物，也是它跟「让主模型挨个读一遍」的根本区别：

**一、能直接走的**——确定度过了门槛的。一张表，每行：原件 + 判断结果 + 确定度。

**二、要人看的**——没过门槛的，单独一份，**排在前面**。每行除了上面那些，再加一句
「为什么拿不准」（次高的选项是什么、差多少）。这份是用户真正要花时间的地方，
所以它得短、得排好序（最拿不准的在最上面）。

最后给一段话，说清楚三个数：**总共多少条、多少条能直接走、多少条要人看**。
比如「200 条工单判完了：163 条确定度都在 85% 以上，可以直接按分派走；
37 条拿不准，按拿不准的程度排好了在下面这张表里，最上面那 8 条是模型几乎在两个组之间对半开的。」

## 三条红线

1. **拿不准的不许悄悄按定论处理**。宁可多一条进人审队列，也不能让人以为这 200 条都是判准的。
2. **不许把确定度四舍五入成「判准了」**。69% 和 71% 差不多，但门槛就是门槛——
   要调门槛就明说「我把门槛从 70% 降到 60%，多出来这 14 条请你抽查一下」，让人自己拍。
3. **判完要留得下来**。结果写成文件（`write_file` 存成 CSV 或 Markdown 表），
   别只在对话里念一遍——分拣的价值在于下一批还能拿它当基准比。

## 判完之后

用户复核完那份人审队列，问一句：**哪几条模型判错了？**
把这几条连同正确答案记到一个文件里（比如 `分拣-错题.md`）。
下次跑同一类活儿，把这些例子写进 `instructions` 当反面样本——
这是这门技能唯一会越用越准的地方。