1. 产品介绍
2. 核心使用流程
先让业务事件有可追踪的执行链
以工作室收到咨询为教学情境：工作流补充资料、分配负责人，再发送内部提醒。工作流概览说明，事件触发后可以按条件更新记录、建立任务或通知。同一条链上，每一步对应不同业务结果，不能只用“流程已运行”概括。
工作流面向所有方案开放，但运行会使用工作区额度。配置时先认清触发条件、影响的记录与动作，之后的运行历史才有可以核对的目标。
通知没有到时，沿当次路径找原因
- 定位运行：在 Runs 查看器找到对应时间与客户记录，查看当时的流程与实际经过的分支。
- 检查步骤数据：从异常步骤的输入回查上游输出。并非所有步骤都有输出，因此应按该步骤的职责判断结果。
- 区分生成与写入：涉及 AI 助手（agent）时查看它调用了哪些工具以及使用的额度。区块说明明确 AI 助手输出不会自动写入属性，保存到客户记录需要后续更新动作。
- 确认已经发生什么：客户资料可能已更新、负责人已分配，只是通知失败。先确认这些结果，才能判断下一步是否会重复创建任务或发送消息。
运行图把抽象配置落到这一次客户任务，步骤信息再把“没收到通知”拆成可查的具体原因。
修正以后，选择与问题匹配的重试方式
Attio 区分从头重试、从失败步骤继续，以及用当前发布流程重试。新尝试保留在同一次运行记录下，可以与前次比较。使用当前流程时会保留原触发详情，但其他数据可能取当前值，同时要求保留相同的触发步骤，并让它的设置与原触发信息相容；不能换了触发方式仍当作原来的运行继续。
因此，再试一次不必然重现原输入，也不会自动撤销已完成的业务动作。修改数据、修改流程与重试分别解决不同问题；完成后还要确认客户记录、任务与收件人符合预期。最终值得得到的是一条能解释原因与结果的处理记录，而不是把失败标记换成绿色。
3. 设计亮点与借鉴
把“流程长什么样”和“这次走了哪里”放在一起
编辑器里的流程图描述可能发生的路径；运行记录描述已经发生的路径。把两者对应起来，用户才不用在一长串日志里猜某一步属于哪个分支。
在工作室案例里，通知没到不一定是通知服务坏了：可能更早的条件把客户分到了另一条路径。先看到实际走向，再打开那一步的数据，排查就有了顺序。设计的记忆点是：把抽象规则落到一个具体客户、一次具体运行上。
结果旁边保留过程，帮助判断“成功但不对”
AI 助手返回一段文字，只能证明它给出了结果。工具调用、所用资料和消耗让人有机会继续追问：这份客户摘要依据什么，是否漏掉关键内容，哪些步骤花费较多。区块说明还明确，AI 助手输出不会自动写入属性，需要后续更新动作负责保存到记录。
这处区分很有用。用户不必把“回答生成了”和“客户记录更新了”混为同一件事；生成、写入和业务核对各有可检查的位置。对于自己的产品，也可以把“已经产生结果”和“已经应用结果”分别表达，避免一条成功提示遮住中间缺口。
新的尝试保留旧的证据
修正后再运行，如果覆盖掉第一次失败，团队只能看到现在成功了，却难以确认修正是否针对原问题。Attio 在同一次运行下保留不同尝试，让失败位置与后续结果能够比较。
设计上可借鉴的是“关系连续，记录不覆盖”：新的动作属于同一个待解决问题，但仍有自己的输入和结果。用户因此可以回答两个不同问题——第一次为什么失败，以及这次为何认为已经解决。