Accept了却不该写——一次动作边界的设计判断

`dialogue accept` 的职责只有一个把状态从"待确认"推进到"进入写作

剑飞
1/14Accept了却不该写——一次动作边界的设计判断

draft ---

01命题

先说清本页判断

02解释

补足为什么

03行动

留下下一步

把“draft ---”落到一个具体项目里看结果
2/14Accept了却不该写——一次动作边界的设计判断

用户说"accept"

但在一个多步骤工作流里"接受"和"写入"之间其实隔着一道该不该跨过去的边界
3/14Accept了却不该写——一次动作边界的设计判断

在一个人机协作系统里

01命题

先说清本页判断

02解释

补足为什么

03行动

留下下一步

把“在一个人机协作系统里”落到一个具体项目里看结果
4/14Accept了却不该写——一次动作边界的设计判断

因为对于简单的流程来说

命题先说清本页判断
解释补足为什么
行动留下下一步
把“因为对于简单的流程”落到一个具体项目里看结果
5/14Accept了却不该写——一次动作边界的设计判断

这不是多余的谨慎

一个流程成熟的标志不是它能跑通一次而是它在每一步都给人留了介

把“这不是多余的谨慎”落到一个具体项目里看结果
6/14Accept了却不该写——一次动作边界的设计判断

不改变任何持久数据

用户的意图被精确地映射到一个狭窄的动作上而不是被一个笼统的"好的我来"稀释掉

命题先说清本页判断
解释补足为什么
行动留下下一步
7/14Accept了却不该写——一次动作边界的设计判断

这里最容易误判的快捷思路是

" 这个想法的问题在于你替用户省了一步也替用户省掉了纠错的机会
8/14Accept了却不该写——一次动作边界的设计判断

最可能出现的场景是

假设 accept 直接触发写入最可能出现的场景是用户 accept 了一个有瑕疵的方

命题先说清本页判断
解释补足为什么
行动留下下一步
9/14Accept了却不该写——一次动作边界的设计判断

当一个工具的副作用超出预期

01问题

决定工具方向

02材料

决定生成质量

03约束

决定结果边界

把“当一个工具的副作用”落到一个具体项目里看结果
10/14Accept了却不该写——一次动作边界的设计判断

write 只管写入

Accept 只管确认write 只管写入不要让一个命令承担两步的职责

把“write 只管写入”落到一个具体项目里看结果
11/14Accept了却不该写——一次动作边界的设计判断

下次设计多步骤工作流

拆的依据不是"能不能省一步"而是"用户在这两步之间有没有可能想改主意"

命题先说清本页判断
解释补足为什么
行动留下下一步
12/14Accept了却不该写——一次动作边界的设计判断

带走四步

找项目

从真实任务开始

出材料

把想法变成可处理内容

做交付

用结果判断能力

可复用

把完成沉淀为流程

13/14Accept了却不该写——一次动作边界的设计判断

让能力长出来

`dialogue accept` 的职责只有一个把状态从"待确认"推进到"进入写作规划"

返回原文
上一篇没有更多文章下一篇没有更多文章