Every 的新提醒：别再为不存在的问题搭 AI 工作流
Every 7 月 20 日文章复盘 Attention Desk、Margot 与 compound writing，提出判断 AI 工作流该保留、重做还是淘汰的四个检查项和三个试运行规则。
先说结论
AI 工作流能不能留下，和它第一次演示有多惊艳关系不大。Every staff writer Katie Parrott 在 7 月 20 日的文章里复盘了自己搭过又放弃的几个系统，结论很具体：工作流要解决一个真实、反复出现的问题，能适应现有习惯，并且尽快让人拿回一点时间或精力。维护成本一旦超过收益，再漂亮的方案也会被搁置。1
这篇文章值得关注的地方，是它把「AI 工作流失败」从个人自律问题拉回了产品问题。一个系统没被使用，不一定说明使用者不够聪明或不够坚持，也可能是触发条件太少、输出还要返工，或者它解决的根本不是这个人的问题。
Attention Desk 解决了一个不存在的问题
Parrott 看到 Every CEO Dan Shipper 演示 Tend。Tend 是一个接收邮件、Slack、会议记录和公司更新的 Codex 原生系统，帮助 Dan 统一处理高密度的公司沟通。通话结束后，她把录音转给 Codex，让它做了一个自己的版本，名字叫 Attention Desk。1
问题在于，Dan 的工作日确实需要一个系统来汇总大量沟通，而 Parrott 平均每天只收到六到八条 Slack 消息。她自己已经形成了频繁检查 Slack 的习惯，一天大约看 40 到 50 次。Attention Desk 想提供的「集中处理、减少打扰」，既没有填补她的真实缺口，还要和原本能带来即时反馈的行为竞争。结果很快变成了置顶聊天里的一个蓝点，提醒她曾经确信这会改变工作方式。
这也是文章的第一个判断：很多 AI 工作流是在照搬别人的工作条件。看到 CEO 的系统有效，就把它搬到自己的桌面上，默认自己也拥有同样的沟通量、触发频率和紧迫感。工具本身没坏，问题却不在这里。
三个失败案例，指向同一件事
1. 为理想中的自己造工具
Parrott 还用 Codex 做过一个自动生成 X 和 LinkedIn 发帖建议的流程，原本想达到每周固定发布的节奏。她一次也没有发出去，因为自己更习惯临时想到什么就说什么，不想再多背一个待办队列。
文章用「symbolic self-completion」解释这种冲动：人会通过购买工具、学习技能或搭建系统，短暂地获得「我正在成为那种人」的感觉。这个概念并不是 AI 工作流研究的直接结论，但它能解释为什么搭工具本身会让人产生一种已经改变的错觉。2
2. 值得搭，不值得养
她曾经做过一个叫 Margot 的 AI 助手，用来管理其它工作流。最初的新鲜感过去后，每次更换底层模型都可能让它停止工作，修复它花掉的时间逐渐超过它省下的时间。
Margot 最终被放弃，但搭建记忆系统的过程留下了一个可复用的认识：代理能不能找到正确上下文，常常比再加一个功能更重要。Parrott 后来把这个认识带进了新的桌面工作流。失败有残余价值，但这不等于失败的工具还应该继续运行。1
3. 真正留下来的流程，会很快回报你
作为对照，她的 compound writing plugin 留了下来。这个工具把写作拆成一组连续步骤，帮助她从想法推进到成稿。它同样借鉴了别人的方法，也需要维护，还要和她拖延写作时反复查看 Slack 的习惯竞争。
差别在于，它很快就给出了可感知的回报：一个可以继续修改的段落、一个能解开论证的问题，或者下一步的入口。它解决的是 Parrott 已经在做的工作，而且回报发生在当下。原文引用的行为研究也指向这一点，立即奖励比延迟奖励更能预测一个行为是否会持续。3
作者给出的四个检查项
把这些案例放在一起，Parrott 将失败的工作流归为四类：忘了它存在、没有正常运行、输出需要过多维护、没有解决一个反复出现的问题。1
她进一步把分类写成了几条暂定规则：
- 新自动化先手动运行三次，再考虑设为定时任务。
- 输出必须产生一个自己会使用的结果，而且人工检查少于五分钟。
- 自动化连续四次没有被使用，就要决定修改它，或者退休。
这几条不是通用的行业标准，而是作者根据自己的失败案例写出的试运行门槛。它们的价值在于把「感觉这个流程应该有用」改成了几个可以观察的动作：有没有稳定触发，结果有没有进入工作，维护时间是否正在吞掉收益。
Every 这次真正写的是采用成本
过去几期 Every 的文章分别写过业务运营团队如何组合模型和工具、编辑如何用 Codex 推出赠阅链接，以及 skills 为什么可能让 AI 变差。这一篇没有再增加一种工具用法，而是补上了一个更容易被忽略的成本表：搭建只是开始，记住它、让它稳定运行、检查输出、维持上下文，才是长期使用的部分。
对 AI 原生团队来说，评估一个工作流时可以先问四个问题：
- 它是否对应一个已经反复发生的问题，而不是某个更理想的自己？
- 它的输出是否能在几分钟内进入实际工作？
- 它是否稳定到值得交给定时任务，而不是每次都要人工救火？
- 如果它连续几次无人使用，团队是否有明确的修改或删除动作？
这会改变团队看待「失败」的方式。没有留下来的流程，可能教会团队怎样组织上下文，也可能只是把一次演示变成了更昂贵的待办事项。两者都叫实验，但账不能混在一起算。
原文在这里继续提供一个用于审计 AI 工作流的提示词，但该部分属于订阅内容。上面的判断和规则仅基于页面公开可读部分，没有把未公开提示词当作已读内容。
Contenido relacionado
- Inicia sesión para comentar.