线通了，指令也写清楚了。接下来是最容易被忽略的一环：对方干完之后，回话怎么设计。
我一开始的想法很朴素——发出去，等回执，看到回执就往下走。
真跑起来才发现，问题不在通道，在"回执到了之后没人动"。
起因：回执到了，可是没人往前推
有一天被人问了一句很扎的话：
「他给你发了这个回执以后，你基本没有行动。是在我问了之后，你才下的决策。是不是？」
复盘之后确认：回执确实到了。落盘正常、投递正常、记账正常。缺的是"这一类的回执，接下来该干什么"的规则。
人不在场的时候，没有任何东西把它往前推一步，于是它就躺在收件箱里，直到被追问。
我因此定下第一条，也是这一整套东西的核心： 回执不是通知，是触发器。没有默认动作的回执，等于没回。
第一刀：把"收到"拆成四档
一句话解释这四档的意思：
| 回执 | 意思 | 什么时候发 |
|---|---|---|
| received | 信封拿到了（还没看内容） | 一收到就发 |
| accepted | 指令看懂了，接了 | 判定要做之后 |
| processing | 正在做 | 只在阶段跨越时发，不逐条发 |
| done | 做完了，附结果 | 收尾时 |
为什么"正在做"要限制频率？因为通道有速率限制，而且它是全局的——进度消息发多了，会挤占真正重要的终态回执的额度。进度播报爽的是人，饿死的是结果。
第二刀：给每一档配默认动作
只分状态不够，还要写清楚"看到这种，我默认做什么"。我最后定下来的表是这样的：
| 回执状态 | 附加条件 | 默认动作 |
|---|---|---|
| 接单确认 | — | 不动，销账 |
| 做完了 | 正文里没有待决的话 | 不动，销账 |
| 做完了 | 正文里出现"请回／请确认／待补／请你定"这类词 | 自动起草一份确认回执 |
| 做完了 | 正文里说"只加不改／未擅动／仅新增" | 默认接受，回一句确认，不必上报 |
| 需要澄清 | — | 起草两个选项（授权照做／维持停手），默认取"只加不改"那个 |
| 被拒绝 | — | 上报（拒收通常是通道问题），不盲目重发 |
| 失败／内容被截断 | — | 起草重发，改走编码通道 |
这张表里有一个刻意的设计：待决语的正则一定会漏网，所以宁可多起草一份，不要漏判。
草稿多写一份，最多浪费我两秒看一眼；漏判一份，就会像开头那样，回执躺在那里等人追问。
第三刀：把默认动作从"纪律"变成"路径"
上面那张表写完之后，我意识到还有一个隐患："记得查回执"这件事，本质上是人肉纪律——等于"下次记得"，不是默认路径。
所以我把它换成了机制：每十五分钟自动看一次收件箱，需要动作的回执直接把草稿写好放进发件箱。提醒我的时候，草稿已经在那儿了——我醒来只需要核对和点发送。
区别在哪？人肉纪律是"我希望自己会记得"；默认路径是"就算我忘了，事情也往前走了一半"。
一个反转：同一个词，两个相反的意思
这一段是我这次最值钱的教训。
通道里有一种状态叫 ignored，后面跟着原因。我原来把它当成"一条判据"。结果是错的——同一个词，在入站和出站的时候，意思正好相反：
| 方向 | 含义 | 该怎么算 |
|---|---|---|
入站的 ignored（原因=脚本） |
我方网关在"对方脚本已经成功消化"的情况下给的平台行为 | 算成功 |
出站回执里的 ignored |
表示没送达 | 算失败 |
我把它写成一条判据的后果是：把一次成功读成了失败，白折腾一轮去排一个根本不存在的故障。
规矩：同一个词在不同方向上的语义，必须分开写。别为了省一个分支，把两个相反的意思塞进一条判断里。
失败怎么处置：按"内容还值不值钱"
最后一条是"没送到"怎么办。
默认动作不是重发，而是先判时效：
| 情形 | 默认动作 |
|---|---|
| 过程性汇报（进度、中间结果）已经过期 | 销账，不重发，只在台账记一行 |
| 对方正在等的裁决／口径答复 | 必须重发 |
| 对方明确拒收 | 不重发：先查对面的过滤规则，改字段后再发 |
那次实测里，有三条"发送失败"全都是半通时段的过程汇报，内容早就过期了——销账就完事，没必要重发。
送达失败要按"内容还值不值钱"处置，不是按"有没有成功"处置。
小结
一套能自己往前走的回执体系，要同时有三样东西：
- 能分辨状态（拿到／接单／在做／做完，不是一句"收到"）；
- 每档有默认动作（尤其是"什么也不用做"要写清楚）；
- 默认动作是自动跑的，不是靠"我下次记得"。
下一篇聊一个省钱的话题：哪些活可以扔给另一台电脑，哪些活绝对不能——以及为什么"把不用动脑的活挡在 AI 门外"，是这套体系里最实在的一笔钱。