把 AI 从聊天框里“放出来”：我用 OpenClaw 跑通了 3 条真正省时间的自动流水线

这两天我脑子里一直卡着一个细节。

“mcp 已废，skill 当立” ，很多讲 MCP 的文章里提到，只接 GitHub、Slack、Sentry 三个服务，40 个工具定义就可能先吃掉 55,000 tokens。AI 还没看用户消息，先把上下文烧掉四分之一。

我看完的第一反应不是“MCP 不行”。

而是：我们太习惯把 AI 关在聊天框里了。

过去一段时间，我用 ChatGPT、Claude、Cursor 的方式其实都差不多：问一个问题，拿到一段答案，然后自己去开浏览器、复制文案、建 issue、筛数据、发消息。

AI 负责说，我负责跑腿。

后来我开始用 OpenClaw 做另一件事：不再只让它回答，而是让它挂到时间、事件和规则后面，直接把一段重复动作做完。

说人话就是：我不想再拥有一个更会聊天的机器人，我想要一个能接工作流的助手。

···

一条像样的 AI 流水线，最少得有 4 个零件

我现在判断一条 AI 流水线值不值得搭，只看四件事：

第一，谁触发它。 是每天早上 8 点自动跑，还是有新 GitHub issue 才跑，还是我在 Telegram 发一句话它才跑。

第二，它先读什么。 不是把所有资料一股脑塞进上下文，而是先给它该读的那几份：项目文件、当天日志、Skill 规则、目标约束。

第三，它能动什么。 能不能读文件、改代码、开浏览器、发消息、起草 PR。没有动作能力，它还是个会总结的聊天机器人。

第四，结果落到哪儿。 是给我一篇草稿、一个 PR，还是一条固定时间发到手机上的摘要。以及，哪一步必须我确认。

这四个零件写清楚之后，AI 才会从“这题我会”变成“这事我做”。

workflow-framework

下面这 3 条，是我现在真正跑起来，而且明显帮我省时间的流水线。

···

1）内容写作流水线：先把“找、筛、起稿”这段体力活接走

我现在有一条写作管线，节奏基本固定：先采集、再评分、再写作、最后审核。

它搜集当天值得看的 AI、Agent、开发者工具资讯，再跑去重、评分，最后给我一份个性化技术报告和建议选题。

这件事最省时间的地方，不是“AI 替我写完文章”。

而是我不用每天从空白页开始了。

以前最烦的是三段活：找选题、排除重复、起第一稿。尤其是第一稿，脑子刚醒的时候最容易卡住。现在这三段先被工作流做掉，我只需要判断两件事：这个角度对不对，这个语气像不像我。

而且这条管线不是“写个 prompt 就结束”。今天凌晨我还在排一个很小、但特别真实的坑：采集跑完了，评分也出来了，报告写得没毛病——但我一看就发现，排名第一的选题三天前刚写过。 根因不是 AI 判断力差，而是去重那一步只对比了前一天的文章，没覆盖更早的历史。修法跟 prompt 完全无关，就是把去重窗口从 1 天扩到 7 天。

这个细节很小，但它特别能说明问题。

工作流不是“把提示词写长一点”，而是把环境、状态、出口一起管起来。你只要有一个环节没设计好，AI 再会写，也只会卡在最后一米。

所以我现在对内容工作流的期待很明确：AI 先帮我把 80% 的体力活做掉，最后 20% 的判断和修改还是我来。

这比“让 AI 直接写一篇爆款文给我”靠谱得多。

···

2）issue 流水线：不要让 AI 替你拍板，让它先把维护活接住

第二条我很常用的，是 issue 跟进。

以前我对 AI 的用法是：把报错贴给它，问“这个 bug 怎么修”。

现在我更愿意把它改成一个小工作流：

新 issue 进来，先做分拣； 边界清晰的小 bug，交给 agent 生成修复草案； 最后把 PR 链接、改动说明和风险点推给我，我只做 review 和拍板。

这个变化听起来不大，实际差很多。

因为真正耗时间的，往往不是“想不出修法”，而是这些碎动作：看 issue、归类、补上下文、建分支、跑一遍检查、把改动整理成能 review 的形式。

这部分很适合交给工作流。

但我也给它留了很硬的边界：

• 不自动 merge
• 不碰大重构
• 问题描述含糊的 issue 不放进去
• 涉及线上风险的改动，最多给草案，不直接执行

说白了，我不是让 AI 接管工程决策。

我只是先把“维护活的第一公里”交给它。

这个边界一旦画清楚，稳定性会高很多。你会发现，AI 最适合接的，不是那些模糊又巨大的任务，而是高频、重复、可验证的维护动作。

聊天框给你的，是一个修 bug 的答案。

工作流给你的，是一个可 review 的产物。

这两个东西不是一个量级。

···

3）晨间摘要流水线：主动推送，才是聊天框里最难获得的体验

第三条是我最近最依赖的一种模式：晨间摘要推送。

它不对应某一个垂直场景。股票只是其中一个例子。更本质的，是把“每天都要先扫一眼的东西”压成一条主动送达的消息。

我现在会让它在固定时间把几类值得先看的信息收成一条摘要：有时是北交所标的的筛选结果，有时是内容后台的异常波动，有时是今天要先处理的待办和 issue。

以前这类事都得我自己开几页后台，一项项过。每件事都不难，但特别碎，而且最容易在早上把注意力切得很散。

现在我把它改成了一条定时流水线：

定时拉取数据 → 按规则过滤 → 压缩摘要 → 在固定时间主动推到我手机上。

这里最重要的不是“摘要写得多漂亮”，而是主动。

聊天框有个天然限制：它总得等你先问。

但很多重复工作，根本不应该等你想起来再问。你需要的是它先替你看一遍，再把值得你花时间的那一小撮东西推过来。

这个模式其实非常通用。

你完全可以把它换成：

• 每天的待办清单
• 新客户线索
• 服务器异常
• 内容后台数据波动
• 市场或价格观察

本质都一样：定时拉取、规则过滤、主动推送。

一旦你开始用这个思路搭工作流，就很难再满足于“我打开聊天框，问 AI 今天该看什么”。

因为最省时间的，不是多一个答案，而是少做一次重复动作。

three-workflows

···

我真正学到的，不是怎么写 prompt，而是怎么留闸门

这 3 条流水线跑下来，我最大的感受不是“AI 更聪明了”。

而是我终于把一件事想清楚了：

先定义结果落点，再定义 prompt。

如果最后要的是草稿，就围绕草稿设计。 如果最后要的是 PR，就围绕 PR 设计。 如果最后要的是一条固定时间到达的提醒，就围绕提醒设计。

不要一上来先问“提示词怎么写”。

第二个感受是，高频重复动作最值得自动化，低频复杂决策别急着交出去。

凡是每天都要做、步骤差不多、结果又容易验证的事，最适合先做成工作流。

反过来，那种目标含糊、边界会变、出错成本高的事，宁可慢一点，也别一股脑扔给 AI。

最后一条是，对外发布、合并代码、花钱动作，都要留人工闸门。

我现在对 AI 自动化的态度挺务实：内部的读、筛、整理、起草，能放就放；真正会产生外部后果的那一步，我自己按确认。

这不是保守。

这是把工作流搭稳的代价。

···

最后

所以现在再有人问我，AI 工具到底怎么才能真正省时间，我的答案已经不太一样了。

不是去找一个更会聊天的模型。

而是想办法把 AI 从聊天框里放出来，让它接住一条真实的工作流：有触发器，有上下文，有动作能力，有明确出口，还有该留给你的那道闸门。

OpenClaw 对我现在最有用的地方，不是它回答得多像人。

而是它终于能在文件、脚本、浏览器和消息频道之间来回跑，把那些我本来每天都要亲手做一遍的碎活，先做掉。

这才是我想要的 AI。

不是陪我聊天。

是替我跑腿。

你现在最想先把哪件事从聊天框里“放出来”？写作、代码维护，还是每天都会重复的一段小动作，欢迎留言，我也想看看还有哪些事值得被做成工作流。