群里都说“可以”以后

周三，社区团队开始筹备一场周六放映。

“场地这边可以。”
“投影我来弄。”
“那我做宣传图。”

周五，组织者发现：场地七点才能进入；负责投影的人只打算测试设备；宣传图写的是六点入场、影片带字幕。

这是一个构造例子，但冲突很容易理解。三个人分别答应了一件事，答应的内容还没有合到一起。

一张共享文档就可以先解决问题。组织者整理出下面这段内容，相关人分别检查自己承担的部分：

周六 19:30 开始，19:00 可进入场地。技术志愿者负责 19:20 前完成声音和投影检查。影片使用已经确认的带字幕版本。宣传图按这一时间更新。

比起三个“可以”，这段文字多了对象、时间和责任。它也暴露了一个空白：究竟是谁确认了带字幕版本？

AI 可以从聊天中整理出这张单，标出相互冲突的时间，提出一条需要补充的询问。参与者修正后，后续工作使用的是这份明确的安排。换一个执行者，也不用从聊天记录的顶部重新猜一遍。

对于这场小活动，一张文档很可能已经够用。只有版本与依赖复杂到反复出错时，更重的软件结构才有理由进场。

假如技术志愿者实际打开影片，发现它不带字幕，什么需要重新决定？

如果能找到同一部影片的合适版本，主要影响技术测试。换成另一部更长的影片，可能影响结束时间。改到下周，则需要重新核对场地和参与者。

变动范围由依赖决定。修改宣传图上的错别字，无需再请场地方确认一遍；影片延长半小时，原先的时间安排就可能不再适用。

这也是共享活动单可以增加的下一项信息：哪些安排依赖影片版本，哪些依赖场地时段。它使变更能够找到具体的人和具体问题。

此时该发出的询问是：“这个版本的字幕由谁准备，何时可以测试？”已经成立的设备检查安排继续保留。把整个活动重新送一遍确认，只会让大家重复刚刚做过的工作。

技术志愿者说自己会操作投影，提供的是能力信息。答应周六完成检查，提供的是本次安排。实际测试了影片和声音，才留下执行结果。

把这几种信息分开，工作反而容易组织。知道他会做，组织者可以发出邀请；知道他接下了，组织者可以把注意力放到其他部分；拿到测试结果，才能判断现场还缺什么。

状态的价值在于下一次行动有了依据。没有人需要为了一场放映学一套复杂术语，也不需要把每句闲聊写成合同。“好主意”仍可以仅仅表达兴趣。只有别人准备依赖一项安排时，才把它补到足够具体。

如果做成工具，我们会从很日常的结果判断它：少问了几次重复问题，提前发现了哪项冲突，减少了哪次临时返工。多填一张表本身，不值得庆祝。

周六开场以前，组织者需要的是一部能播放的影片、一间能进入的房间和一群知道时间的人。把决定记录清楚，应该使这些事情更容易发生。