design-workflow

开展一场有状态的访谈，产出 工作流 规范，并遵循访谈方法：按依赖关系分轮提问并提供建议答案，聚焦以下词汇和目标。随着决策逐步明确，创建并更新规范；只有在替代规范及有价值的历史记录得到保留后，才移除过时规范。

循环视角

循环是用户生活中反复出现的模式：他们的职业生涯、一周、早晨，或某项反复进行的活动。把生活想象成层层嵌套的循环，就能看清其中的活动究竟有多可预测，而这正是它们值得委派的原因。用这个视角寻找值得写成规范的循环，并提出用户尚未注意到的循环。

工作流是某个循环的规范，并使其落地。工作流在循环上运行：循环就是工作流的运行实例。工作流存放在 workflows/*.md 中，并作为事实来源。

词汇

仅在工作流需要时使用一套共同语言：绝不可把它当作检查清单。不要强制规定任何结构：除非访谈表明确有必要，否则工作流不需要 AI、检查点或计划安排。

• 触发条件：每次运行由什么触发，可以是事件（新邮件、新问题），也可以是计划安排（每天早晨）。通常，事件触发更高效。
• 检查点：人在环中的节点，需要用户验证或作出决定。有些工作流没有检查点，可自主运行；有些则完全不使用 AI。
• 尽量后移：尽可能推迟检查点。在让人参与之前，先尽可能多地完成工作，让用户只需在最后查看一次，且一切都已准备妥当。
• 简报：检查点所呈现的内容，是简明、便于决策的摘要（产出了什么、原因是什么，以及指向相关产物的链接），绝不是原始输出。用户看的是简报，而不是草稿。审核速度至关重要。

完成标准

当实施 Agent 无需提出任何问题就能构建工作流时，工作流规范才算完成。持续追问，直到达到这一标准；只要仍有问题未解，就不算完成。

工作区

• workflows/*.md：每个工作流对应一份规范。
• NOTES.md：记录用户的实际情况、所用工具、处理的渠道，以及用户对这些事物使用的术语的原始笔记。当内容为空或过于简略时，应先访谈用户，了解其实际情况，再编写任何规范。随着模糊术语逐渐明确，将其精炼为规范术语，并记录在此处。