title: Accept 了却不该写——一次"动作边界"的设计判断 date: 2026-06-14 status: draft
用户说"accept"，助手就写——这似乎是天经地义的逻辑。但在一个多步骤工作流里，"接受"和"写入"之间其实隔着一道该不该跨过去的边界。
事情起因
在一个人机协作系统里，有一个 dialogue accept 命令。表面上看，用户发出这个命令，就意味着认可了某个方案，接下来就该执行。但真实场景是：accept 只代表用户同意进入下一个阶段（writing-plan），并不意味着授权直接写入最终内容。
这件事表面上是命令语义的问题，实际上是人机协作中"意图粒度"的问题。 用户的每一个操作，都有自己的作用范围。Accept 是"我同意这个方向"，不是"我授权你走到底"。
为什么容易搞混
因为对于简单的流程来说，accept 和 write 确实是同一件事。你说"好，就这么干"，助手就干了，皆大欢喜。但当流程变复杂——从对话到方案、从方案到草稿、从草稿到发布——每一步都需要独立的确认。如果 accept 自动触发 write，用户就失去了一个关键的控制点：在方案和成稿之间再检查一次的机会。
这不是多余的谨慎。一个流程成熟的标志，不是它能跑通一次，而是它在每一步都给人留了介入的空间。
我怎么设计这个边界
核心原则：让工具只做该做的事。
dialogue accept 的职责只有一个：把状态从"待确认"推进到"进入写作规划"。它不触发写作、不生成内容、不改变任何持久数据。用户的意图被精确地映射到一个狭窄的动作上，而不是被一个笼统的"好的我来"稀释掉。
这里最容易误判的快捷思路是："反正用户最终也要写，不如 accept 时就顺手写了，省一步。" 这个想法的问题在于：你替用户省了一步，也替用户省掉了纠错的机会。如果方案有问题，用户在 writing-plan 阶段还能调；一旦直接写入，错误就变成了需要回滚的操作。 回滚的成本远高于多一步确认。
如果不处理会怎样
假设 accept 直接触发写入，最可能出现的场景是：用户 accept 了一个有瑕疵的方案，助手立刻把有瑕疵的内容写进了系统，然后用户发现不对，需要手动撤销。如果写入还触发了下游流程（比如发布、通知、同步），错误的影响面会更大。
更隐蔽的问题是：用户会逐渐不再使用 accept，因为他不信任这个命令的安全边界。当一个工具的副作用超出预期，用户的第一反应不是适应，而是回避。
可复用的判断方法
这次设计让我确认了一个判断框架：
- 每个命令只负责一个状态转换。 Accept 只管确认，write 只管写入，不要让一个命令承担两步的职责。
- 问"这个动作的副作用是什么"。 如果 accept 会改变持久数据，那它就不只是确认，而是一个隐含的写入。这需要拆开。
- 宁可多一步确认，不要省一步犯错。 确认的成本是点击一下，犯错的成本是回滚和信任损失。
- 把用户的意图粒度和动作粒度对齐。 用户说"好的"和用户说"写吧"是两个不同的授权级别。
下次我会怎么做
下次设计多步骤工作流，我会先画出每个用户操作对应的状态转换图，然后检查：有没有哪个操作同时推进了两个状态？如果有，就拆开。拆的依据不是"能不能省一步"，而是"用户在这两步之间有没有可能想改主意"。 答案如果是"有"，那两步就不能合并。