1. 诊间助手让医生点了两百次确认
一家三甲医院的门诊上了一台诊间助手。医生问诊的时候，助手一边听一边整理，实时生成一份病历摘要，医生点确认，摘要写进病历系统。
第一版用了两天就被关掉了。原因有三个。
确认太碎。助手把摘要拆成十几处，每处都要点一下：主诉确认一次、现病史确认一次、既往史确认一次、每一条体格检查确认一次。一位医生一天门诊六十位患者，平均每位患者点三点五次，一天下来两百多次。一次八秒，累计二十八分钟，比手写还慢。
交接不够。医生发现摘要里有一处不对，点开想改，界面上只有一句「已生成摘要」。要看原文得切回病历系统翻，翻完回来又找不到刚才那一处在哪儿。
它不会说不知道。有位患者第一次来，系统里没有既往史。助手跳过了「既往史不详」这个写法，从患者说的「前两年血压有点高」里推出了一条「高血压病史」，写进了摘要。这句话医生没注意就点了确认，事后才发现那是猜的。
毛病出在三个地方：确认点摆得太密，交接界面给的信息不够，以及它没有「不会」这个状态。
2. 三个档位：全自动、人工确认、必须人接手
2.1 三个档位各管什么
人机分工（Human-AI Task Allocation）指的是把一条流程里的每个动作，归到三个档位中的一档。
全自动：它自己做完，不用人管。适合读数据、算数、整理格式、生成草稿这类不改变别人东西的动作。
人工确认（Human-in-the-loop）：它做完了等人点一下才生效。适合会改变系统数据的动作，比如写病历、改派送时间、发通知、改价。
必须人接手：它做到某一步停下来，剩下的全部交给人。适合判断依据不足、情况超出预设范围、或者后果严重到不能由它决定的事。
2.2 一个动作放哪一档
按两个问题判。
这个动作会不会改变系统里的数据、或者对外发出去？是的话至少进第二档。上面那台诊间助手写病历这个动作属于改数据，必须人确认；助手读病历原文、算指标属于第一档，不用人管。
判断本身站不住脚的时候怎么办？答案只有两个：进第三档，或者在界面上明确标出不确定的地方。第三种做法最危险：不明说，直接给一个说得通的结论。那条凭「前两年血压有点高」推出来的高血压病史，就是这么来的。
同一个动作放在哪一档，行业不同，结论也不同。改一条收货地址（零售电商）属于第二档，点一下就能生效；改一条用药医嘱（医疗）属于第三档，必须由医生重新判断，助手不能给建议；改一条交易对手的账户信息（金融），在有些机构直接按第三档处理，需要双人复核。档位的高低跟这个动作本身无关，跟在这个行业里改错的后果有关。
2.3 一条流程里三档并存
同一条流程里，三个档位是混着用的。诊间助手改版之后是这样：读取和整理全自动；生成摘要草稿全自动；写入病历前停一次等人确认；摘要里凡是带推测的字段，自动标上「待医生确认」并进第三档，由医生决定写不写。
定分工的时候，最容易犯的错是拿整条流程当单位来定，要么整条全自动，要么整条都确认。按动作来定，才知道该在哪儿停下来。
3. 确认点摆在哪一步
3.1 写操作怎么设卡
写操作的确认点摆在动作发出之前，不在之后。动作已经发出去了再通知「已执行」，那只能算通知。
确认框里必须能看清这次要改什么。改病历的确认框里，至少要显示改动前后的差别；改派送时间的确认框里，显示原时间和新时间两行。只写一句「确认执行」的确认框，医生、客服、调度这些人点两次就会开始盲点，那才是真正危险的时刻。
3.2 对外发送怎么设卡
发给客户的内容比写进自己系统的内容更麻烦，因为它收不回来。
这一类确认点要比写操作更严，多两道。第一道是内容确认：这次要发的是哪一段文本、发给谁、通过哪个渠道。第二道是抽检：批量发出的内容，按比例抽几条给人过目，抽检记录留档。
客服、营销、通知这几类场景，量一大就有人想跳过抽检。跳过之后一旦发出有问题的内容，代价会从一次沟通直接升级成一次投诉。
3.3 批量动作要拆小
一次要改两百条数据的动作，不能做成一个确认框。人看不完两百条，也担不起这个责任。
拆法有两种。按范围拆，比如一次只处理一个网点的客户；按批次拆，比如一次五十条、分四批确认，每批确认完可以看到这一批的结果再决定要不要继续。
拆小之后还有个附带好处：出问题的时候影响面小，回滚也好做。
4. 交给人手上的时候，给他什么
4.1 确认界面上要有什么
医生、客服、调度这些人每天要看几十次确认框，界面给的东西不够，他们会宁可关掉整个功能。
一个够用的确认界面给四样：改前改后的差别、这次判断依据的是哪几段原文、它自己标出的不确定项、以及一键退回的入口。
那台诊间助手的第二版按这四样重做：摘要里改动过的字段用下划线标出来，每处都能看到它在原文里的位置；带推测的字段前面加一个黄色标记，标「依据不足」；下方一个「退回重写」的入口，点了直接回到生成那一步。
同一份摘要，两种确认框摆在医生面前
左边 · 第一版的确认框
- 摘要正文患者主诉上腹隐痛三天，考虑慢性胃炎，建议胃镜
- 可点的按钮只有「确认」和「取消」两个
- 医生能看到的摘要本身，改动在哪、依据是哪几段都看不到
- 一天的确认量60 位患者，平均 8 秒点一次
没有依据可看，人只能照着点。
右边 · 第二版的确认框
- 改动过的字段「三天」「慢性胃炎」两处带下划线，点一下展开原文位置
- 带推测的字段「慢性胃炎」前面一个黄色标记，标「依据不足」
- 依据原文门诊记录第 2 段、检验单第 1 项，各带出处
- 下方入口「退回重写」，点了回到生成那一步
改了什么、依据是哪几段、哪处是猜的，一眼都能看到。
确认框里要摆依据，人才真的在确认。
4.2 人改完怎么回到流程
人改完之后有两条路：接着往下走，或者退回去重做。
接着往下走在多数场景里更合适。医生只改了摘要里的一句话，后面的步骤不用重来。做法是把人改过的内容当成本次的正式结果，往下传。
退回去重做适合改动大的情况：改完之后结论变了，后面几步的前提也不成立了。这时候要明确退到哪一步，不能只退一格又带着旧结果往下走。
4.3 改动要留痕
人改过什么，要记下来。记录三样：改前是什么、改后是什么、谁改的、什么时候改的。
这份记录有两个用处。一是出纠纷的时候查得到谁最后定的；二是改得多了能看出问题在哪：如果某个字段医生十次里有八次都要改，说明这个字段的生成逻辑有问题，而不是医生太挑剔。
5. 确认环节不拖慢流程
5.1 把确认点收到一次操作的最后
诊间助手第一版之所以被关掉，是因为把一次写入拆成了十几处确认。改成一整份摘要在最后确认一次，次数从 210 次降到 60 次。
原则很简单：一次动作只设一个确认点，放在这个动作真正生效的前一步。 中间过程可以实时显示给用户看，但不用每步都停下来点。
5.2 一次确认花多少时间算合理
没有统一答案，但有个判断办法：看它比人工做这件事快多少。
如果一次确认要花 12 秒，而这件事人手做要 40 秒，那还是划算的；如果确认要 30 秒，人手做只要 35 秒，这个功能等于白做。
改版后的诊间助手一次确认 12 秒，一天 60 次，累计 12 分钟，比手写病历快了一半，医生才愿意继续用。
5.3 怎么看到它每一步在干什么
用户愿意点确认，前提是他大概知道助手在干什么。三种做法按投入从低到高排：显示当前在做什么（正在检索历史记录）、显示已经做完哪几步（已读取本次问诊、已生成草稿）、把每一步的输入输出都摊开给人看。
多数场景用第二种就够。第三种只在专业场景用，比如金融的合规审查，审查员需要看到每一段的出处。
6. 让它知道自己不会
6.1 元认知说的是什么
元认知（Metacognition）在这里指的是：它知道自己不知道什么，并且把这件事说出来。
模型的默认行为是给一个答案。资料里没有就直接编一个说得通的，这是它最容易出的事故，也是最难被发现的事故，因为编出来的东西读起来和真的一样。
6.2 三种求助方式
不确定的时候，用哪种方式应对，按不确定的程度分三种。
追问：差一个关键信息就能答，就停下来问一句。诊间助手第一次遇到「既往史」这一栏是空的，应该问医生「本次问诊没有提到既往史，是填写『不详』还是您补充」。
打标记：能答但依据不足，就给出答案并标出来。写「既往史：患者自述前两年血压偏高，未在院内就诊」，前面加一个黄色标记。
转人工：判断不了，整段交回人。诊断有分歧、依据缺失、涉及处分或赔付的场景都属于这一档。
6.3 三种做法各写在哪里
追问写在提示词里，明确列出哪些字段缺失时必须先问、不许自己推断。
打标记写在输出格式里，规定哪几类内容必须带「依据不足」标记，标记的字段由界面渲染出来。
转人工写在流程里，设成一条明确的分支，触发之后停下来等人。
三样都要落在实处。只在提示词里写一句「不确定时请说明」，模型十次里有九次会照常给出答案，因为它的默认倾向就是把话说圆。
7. 写操作要额外满足三个条件
7.1 幂等
幂等（Idempotent）指的是同一个操作执行一次和执行多次，结果一样。
网络抖动、超时重试、用户连点两下，都会让同一个动作发出去两次。不带幂等处理的写操作会留下两条记录：两条病历、两条通知、两笔退款。
做法是给每次操作带一个唯一标识，服务端看到同样的标识就不再执行第二次。产品经理在需求里要写清这个标识从哪来，以及重复提交时界面给用户什么反馈。
7.2 回滚与补偿
回滚是把动作撤销，补偿是动作撤不回来时做的补救。
改病历可以回滚，把上一版盖回来就行。已经发出去的短信撤不回来，只能补一条更正说明。区分这两类，在需求里分别写清。
还有一类动作不能只回滚一步：改价之后订单金额变了，如果只把价格改回去，订单总额还是错的。这类动作要按「一组动作」来处理，出问题整组回退。
7.3 测试数据与正式数据隔离
调试期间的写操作如果打在正式数据上，会直接产生真实的错误记录。诊间助手刚上线时有人在测试环境里连了正式库，生成了一批测试病历，花了两天才清理干净。
做法是环境分开：测试环境用测试库，正式环境用正式库，两边的凭据分开管。上线前的验收在测试环境跑，不在正式环境试。
8. 验收标准怎么定
8.1 人工介入率
人工介入率是「需要人处理的次数，占全部处理次数的比例」。它衡量的是这个功能省了多少人力。
算法要写清口径：是把「点过确认的」算作介入，还是只把「改过内容的」算作介入。两种口径算出来的数会差很多，跟业务方对指标之前先把口径写死。
8.2 一次通过率
一次通过率是「人没有改动就确认通过的比例」。它衡量的是它自己干得准不准。
这个数要按字段或按类型拆开看，只看整体容易被平均数盖住：整份摘要看起来 85% 一次通过，可能主诉这一栏是 98%，而初步意见那一栏只有 40%，后面的改进方向完全不同。
8.3 定多少算合格
没有通用数字，按场景的容错程度分三档给参考。
| 场景 | 人工介入率 | 一次通过率 |
|---|---|---|
| 内容只给自己人看，错了能改（内部草稿、会议纪要） | 10% 以下 | 90% 以上 |
| 内容要进正式系统或对外流转（病历、工单、报价） | 30% 左右 | 85% 左右 |
| 内容涉及处分、赔付、对外正式承诺 | 必须 100% 人工确认 | 不作为主指标，看漏检率 |
这三个区间是起点，不是标准答案。定的时候跟业务方一起对着真实数据谈，谈完写进验收清单。
两个数落在哪一档，验收条件就跟着定
- 内容只给自己人看、错了能改（内部草稿、会议纪要）· 人工介入率 10% 以下，一次通过率 90% 以上
- 内容要进正式系统或对外流转（病历、工单、报价）· 人工介入率 30% 左右，一次通过率 85% 左右
- 内容涉及处分、赔付、对外正式承诺必须 100% 人工确认，人工介入率不作为主指标，改看漏检率
- 这个案例的底数一天 60 位患者，一次确认 8 秒，确认次数从 210 次降到 60 次，一天累计从 28 分钟降到 12 分钟
两个数按场景的容错程度分档，不套通用标准。
- 结论落在参考区间内，验收条件写「改动率不得超过 15%，超过要复盘」
落在区间内，验收条件可以照这一档写。
- 结论介入率低于这一类场景的参考区间，先确认改动的监测是不是漏记了（比如退回重写没有统计进去）
数偏低先查监测，别急着庆功。
- 介入率 75%确认点可能设得太密，先把确认点收到一次操作的最后一步
- 一次通过率 40%按字段拆开看哪一栏最差；整份看起来 85%，主诉那一栏可能 98%，初步意见那一栏只有 40%
一个数不对，先拆开看是哪一栏拖的。
- 主指标换成漏检率一次通过率一栏不再显示
- 这一档的要求必须 100% 人工确认
进了赔付这一类，看的指标就换了。
这三个区间是起点，定完要跟业务方对着真实数据谈。
9. 诊间助手改到第二版
那台诊间助手的第二版按四件事重做。
动作分了档。读取问诊记录、检索历史、算指标、生成摘要草稿这几步全自动；写入病历前停一次，等医生确认；摘要里凡是带推测的字段，进第三档，标成「待医生确认」，由医生决定写不写。
确认点从十几处收到一处。整份摘要在写入前确认一次，中间过程在右侧实时显示，不打断医生问诊。确认次数从每位患者 3.5 次降到 1 次，一天从 210 次降到 60 次。
交接界面给了四样。改动过的字段加下划线，悬停显示原文位置；带推测的字段前面挂黄色标记，标明依据不足；每条结论下面给出出处；底部一个「退回重写」的按钮。
不会就说不说清也定了规矩。既往史这一栏在系统里查不到历史病历时，先追问「本次问诊没有提到既往史，是填写不详还是您补充」；医生没回就填「不详」，不写任何从口述里推出来的病史。
写操作那边补了幂等和留痕。确认动作带唯一标识，医生连点两下只写一次；每次改动记录改前值、改后值和操作人。
验收指标按两个月的数据定：「人工介入率不超过 30%」，「主要字段一次通过率不低于 85%」，并按字段拆开看，初步意见这一栏单独定在 60%。月度复盘的时候，如果哪一栏的一次通过率掉到目标线下，就去查那一栏的生成逻辑。
复诊那件事没再发生。医生点确认之前，能看到每一条的依据，也能看到哪一条是它自己都拿不准的。
10. 确认点定规前的自查清单
| 问题 | 答「否」的时候怎么办 |
|---|---|
| 这个动作会不会改变系统里的数据？ | 会改的，进第二档，动作发出前停下来等人点确认 |
| 这个动作会不会对外发出去？ | 会发的，确认之外加一道抽检，抽检记录留档 |
| 确认框里能不能看到改前和改后的差别？ | 看不到的，先补上差别展示，否则人会开始盲点 |
| 这次确认后面还有没有别的确认点？ | 有的话先合并，一个动作只设一个确认点，放在生效前一步 |
| 判断依据不足的时候，它会不会说出来？ | 不会的，把追问、打标记、转人工三种方式分别写到提示词、输出格式和流程里 |
| 这个动作重复发两次会不会产生两条记录？ | 会的话加幂等标识，并在界面上写明重复提交的反馈 |
| 这个动作撤不回来的时候有没有补偿？ | 没有的，按「一组动作」处理，写成整组回退，或者补一条更正说明 |
11. 确认点定错的三种典型
所有环节都要人确认。 一次操作拆成十几处确认，用户点两天就关掉了功能。确认点要收到「一次动作一处」，中间过程实时显示但不打断。
写操作没有幂等和回滚。 网络抖一下、用户连点两下，就多出一条记录；出了错只会往前重跑，不知道怎么退回去。这两件事在需求阶段就要写，事后补的成本高得多。
请示界面给的信息不够，人还得回去翻系统。 确认框里只写「已生成摘要」，医生要切回病历系统查原文，查完回来又找不到那一处。界面上没给出来的信息，等于让人自己承担这部分工作。
12. 确认点定好之后，还要看喂进去的数据
分工这一块要能答上五个问题：动作分几档、确认点摆在哪儿、交到人手上时给什么信息、确认环节会不会拖慢流程、它不会的时候怎么开口。写操作还要补上幂等、回滚和测试数据隔离这三样。
它干得准不准，还有一半取决于喂给它的东西。同一台诊间助手，如果历史病历写得不规范、术语口径前后不一，再好的确认流程也只能一次次把错误拦在最后一道关口。下一份材料讲三类数据各干什么、什么算高质量、谁来标，以及脏数据会把后面哪几步一起拖垮。