任务交接标准：把「派单」写成契约

我见过（也亲手制造过）绝大多数「AI 干得不对」的场面，根因都不在执行，而在派单。

派单最常见的三种写法：

1. 「帮我把它做好」——没有完成标准；
2. 「参考上次那个」——没有事实基准；
3. 「注意质量」——这句话等于没说。

于是执行方只能猜。猜对了叫运气，猜错了你不能怪它。

一、一张交接单最少要有什么

我把每一次下发固定成四块，缺一块就不发：

• 做什么 + 交付物：产物落在哪，别人怎么读到它；
• 不做什么：一句边界。这一句最容易漏，也最省钱——它挡住 80% 的「顺手扩范围」；
• 验收：一条能跑出来的判据。写不出命令，就写「我回读哪个文件、看哪一项」；
• 停止条件：撞到预设之外的情况，停下来上报，不许自己换方案。

二、轻活和重活两套档

不是每件事都值得写满一页。

• 轻档：单件、一轮能完、没有不可逆操作——一段话讲清上面四块就够；
• 重档：涉及不可逆操作/对外发布/凭据、跨系统、多执行方、要返工——才展开完整模板。

判档的意义不是省事，是让风险高的活自动获得更多约束。

三、最硬的一条：停手上报

「撞到假设冲突就停手，不许自己换方案」——这条我写在最前面。执行方最危险的冲动，是遇到障碍后自作主张找个替代路径，最后交回来一个你根本没要的东西。停手三行说清「卡在哪 / 证据 / 出路」，比强行交付便宜得多。

四、回执要短，证据要全

报告落盘，回话不超过三行：一行结论、一行关键证据、一行阻塞。 但不接受「已完成」「测试通过」这类无证据结论——少一条证据，回执就退化成「信我」。

五、用了一周后的修正

• 「不做什么」必须在下发方这边写死，不能指望执行方自觉；
• 同一个任务被退回一次，下一次自动升档——被退回本身就证明边界没讲清；
• 验收永远由派单方独立做。这一条最费时间，也最不能省。