夜雨聆风
导读：很多人做 AI 自动化，第一反应是让它自动读、自动点、自动发。但真正跑进日常工作以后，问题会变得很具体：它会不会误发？会不会卡住？会不会把“能做”误当成“该做”？这篇文章想讲清楚一件事：个人 AI 助手必须从“会自动”升级到“可控自动化”。
这几天我对 AI 自动化有一个更明确的判断：
自动化不是终点，可控自动化才是。
一套系统刚跑起来的时候，最容易让人兴奋：它能读消息、能生成 PPT、能跑定时任务、能调用工具、能写回 Notion。看起来像是终于有了一个全天候小助理。
但真正进入日常后，问题马上就来了：
- 它能做，不代表它应该做；
- 它能自动，不代表它应该无人值守；
- 它能跑完，不代表它真的闭环；
- 它没报错，不代表结果可信。
所以我最近把几个系统都往同一个方向收：不是更猛，而是更稳；不是更自动，而是更可控。
01 别把“能执行”当成成功
很多自动化的起点都很像：
我有一个重复动作 → 让 AI/脚本自动做 → 做成了 → 认为成功
但这只是最低级的自动化。
真正的问题通常发生在后面：
- 输入不完整时怎么办？
- 权限不够时怎么办？
- 页面状态变了怎么办？
- 模型卡住时怎么办？
- 消息要外发时谁负责？
- 写入 Notion / IMA / 草稿箱前有没有复核？
如果这些问题没解决，自动化越强，风险越大。
我现在更愿意把自动化分成两类：
一种叫“会跑”。
另一种叫“能交付”。
前者只是把动作做出来，后者要能解释输入、控制风险、验证结果、留下记录。
真正能进入工作流的，只能是后者。
02 PPT 工厂：不是生成 PPT，而是生产线
PPT 工厂最开始看起来像“AI 生成 PPT”。
但真正值得沉淀的不是生成，而是生产线。
它现在更像这样一条链路：
资料摄取 → 预检门禁 → 叙述生成 → 证据映射 → PPT 生成 → QA → 交付
关键不是模型写了几页，而是每一步都有门禁：
- 表格缺失，要拦；
- sheet 重复，要拦；
- 数据未归类，要提示；
- 叙述没有证据，要回查；
- PPT 要可编辑，要能渲染检查；
- 公司真实资料不能外泄。
这里的判断很简单：
能生成只是起点，有门禁、有证据、有 QA，才进入生产。
这也是我现在看很多 AI 工具的标准：
不是看它 demo（演示）多惊艳，而是看它能不能进入一条稳定链路。
如果只能偶尔做出一张好看的图、一页好看的 PPT，那叫效果。
如果能稳定摄取资料、识别风险、产出可编辑文件、留下证据链，那才叫能力。
03 Peekaboo GUI：能点屏幕之前，先分级
GUI 自动化最容易给人一种错觉：既然 AI 能看屏幕、能点击、能输入，那就让它自己操作电脑吧。
这很危险。
桌面自动化的问题是，它操作的不是沙盒，而是真实环境。
点错一个按钮、输错一个窗口、发错一条消息，影响都不是模型自己承担。
所以我后来把 Peekaboo 这类桌面自动化拆成几层：
L0：只读观察
L1：本地低风险操作
L2：可能外发 / 影响别人 / 改状态
L3：高风险、不可逆、公开发布
不同级别，权限不同：
- 只读可以自动；
- 本地低风险可以在明确场景里执行；
- 消息外发、公众号草稿箱、配置保存必须确认；
- 不确定就不做。
这不是保守。
这是把自动化从“会动手”变成“知道什么时候不能动手”。
一个个人 AI 助手，如果只会执行命令，其实不够。
它还必须知道哪些事要停下来问人。
04 微信群自动回复：从自动发送退回只读建议
微信群自动回复是这几天最典型的反面教材。
一开始目标很简单：
读取微信群 → 判断低风险闲聊 → 自动回复
后来发现问题不在读取，而在发送链路：
- 锁屏判断会误拦截；
- System Events 权限会报 `-1743`；
- GUI 输入法和窗口焦点会出问题；
- 一旦误发，影响的是群里真实的人。
所以最后我把它降级成：
只读读取 → 生成建议 → 写入 Mac 剪贴板 → 私聊提醒 → 人手动发送
这一步看起来像“自动化程度下降了”，但系统价值反而更高。
因为它把风险最高的最后一步交还给人，把 AI 放在更适合的位置：
- 它负责观察；
- 它负责总结；
- 它负责建议；
- 它负责准备；
- 人负责最终外发。
外发类动作，不追求无人值守；先追求低风险辅助。
这句话很重要。
很多 AI 自动化项目出问题，不是因为能力不够，而是因为太急着把最后一步也交出去。
05 cron 定时任务：跑了不等于交付了
今天早上一个 Notion 复核 cron 报了 `Cron failed`。
细查后发现，它不是完全没执行。它跑了几分钟，部分工具也执行了，但最后模型侧出现 `LLM idle timeout`，导致任务整体被标成失败。
这个案例说明：
- 定时任务启动了，不等于完成；
- 工具调用成功了，不等于最终交付；
- 没有清晰摘要，不等于任务没做；
- 长任务需要拆解，不然一个环节卡住，整条链路都会被判失败。
所以定时任务也要有可控设计：
小任务化 → 中间状态可查 → 失败通知 → 人工补救 → 结果回写
这也是为什么我越来越不喜欢“一个巨大 prompt（提示词）跑到底”的自动化。
它看起来省事，但失败时很难定位。
更稳的方式，是把任务拆成小段：
先取事实，再判断；先写中间结果，再写最终结论；先能人工补救，再谈无人值守。
06 我现在认可的自动化标准
一套自动化，至少要回答 7 个问题：
1. 输入从哪里来？
2. 判断标准是什么？
3. 哪些步骤可以自动？
4. 哪些步骤必须确认？
5. 出错时怎么停？
6. 结果怎么验证？
7. 经验怎么沉淀成下一次的规则？
如果回答不了，它就只是一个“会跑的脚本”。
如果回答得了，它才是一个“可控工作流”。
我现在做系统，会更关注这些东西：
- 是否只读优先；
- 是否有权限分级；
- 是否有中间状态；
- 是否有失败通知；
- 是否能人工接管；
- 是否能回写到知识库 / Notion / IMA；
- 是否能沉淀成下一次的规则。
这些听起来没有“自动生成一切”那么刺激。
但真正能长期用的系统，靠的就是这些不刺激的东西。
结尾：自动化解决效率，可控自动化解决信任
我现在对个人 AI 助手的判断更明确了：
未来真正有价值的，不是一个什么都敢自动做的 AI，而是一个知道边界、能复核、能交接、能沉淀的 AI 工作系统。
自动化解决的是效率问题。
可控自动化解决的是信任问题。
没有信任，效率越高，风险越大。
所以接下来，我会继续让 AI 参与更多工作，但原则不变：
- 先只读，再操作；
- 先建议，再外发；
- 先门禁，再生产；
- 先复核，再闭环；
- 先沉淀成资产，再谈更高程度的自动化。
AI 助手真正有用的那一天，不是它终于可以替你乱点一切。
而是它知道：什么时候该做，什么时候该停，什么时候该把决定权交还给人。
