夜雨聆风摘要:
很多人以为 AI 的价值还停留在“问一个问题，给一个答案”。
但我最近做了一次更接近未来的实验：把 AI 真正接到我的电脑环境里，让它替我操作 Telegram、发送消息和图片、回传执行截图验证，甚至配合电脑的熄屏与防睡眠策略持续运行。
这次最有意思的地方，不是它“会回答”，而是它开始具备了“执行任务、验证结果、持续运行”的能力。
我越来越相信，AI 的下一阶段，不是更会聊天，而是变成真正能替人做事的代理。
_________
这两年大家聊 AI，最常见的场景还是“问它一个问题，它给你一个答案”。
但我最近越来越明显地感觉到，真正重要的分水岭，已经不在“它会不会回答问题”，而在于：
它能不能真正替你做事。
今天，我做了一次很完整的实验。
我不是让 AI 陪我聊天，也不是让它帮我写一段文案，而是把它真正接到了我的电脑环境里，让它替我：
• 操作本机 Telegram
• 给指定联系人发消息
• 把我和机器人的聊天截图发给别人
• 发完以后，再把“发送成功”的聊天界面截图回传给我验证
• 同时还调了电脑的熄屏、防睡眠和后台运行策略
最后，这条流程真的跑通了。
而且跑通之后，我的感受非常强烈：
AI 正在从“回答问题的工具”，变成“可以执行任务的代理”。
───
一、今天这件事，难点根本不是“发消息”
表面上看，我今天让 AI 做的事情很简单：
给黄发一句“你好，这是机器人代发的信息”，再把我和机器人的聊天截图发给他，发完后把成功界面回传给我。
如果把这件事交给人来做，可能三十秒就结束了。
但如果交给 AI，你会发现它背后根本不是“会不会说话”的问题，而是一整套执行问题：
• 它怎么控制 Telegram？
• 它怎么找到指定联系人？
• 它怎么发送文字？
• 它怎么发送图片？
• 它怎么确保不是“说自己做了”，而是真的做了？
• 它怎么把结果再发回来让我检查？
这其实是一套非常典型的 代理系统问题。
也就是说，AI 真正变得有用，不是因为它会写漂亮回答，而是因为它开始进入 执行闭环。
───
二、最先撞墙的地方，是 Telegram 搜索框
一开始，我走的是人类最自然的思路：
• 打开 Telegram
• 搜索联系人
• 点进聊天
• 发消息
结果很快发现，Telegram 桌面端的搜索并不好伺候。
看起来只是一个搜索框，实际上它的行为非常不稳定：
• ⌘F 不一定是全局搜索，有时更像当前上下文搜索
• ⌘⇧F 虽然更接近全局搜索，但搜索结果选中并不稳定
• Tab、方向键、回车，在不同场景下逻辑不一致
• GUI 自动化只能“模拟按键”，却不知道 Telegram 内部到底选中了谁
换句话说，如果继续死磕搜索框，事情很可能永远只能“偶尔成功”，而不是“稳定可用”。
这一刻我突然意识到：
真正有价值的能力，不是会不会写脚本，而是能不能在错误路径上及时掉头。
───
三、真正的突破，不是点对了搜索框，而是绕过了搜索框
后来我换了路，不再依赖 Telegram 的 GUI 搜索。
这次真正的突破点，是用了 Telegram 自带的 deep link。
比如：
• 打开某个用户名的聊天：
tg://resolve?domain=xx
• 打开我自己的机器人聊天：
tg://resolve?domain=xxbot
这一下，事情彻底变了。
因为原本最脆弱的一步——“在搜索结果里点对人”——被彻底绕过去了。
我不再需要 AI 去猜 Telegram 的界面逻辑，
而是让它直接通过协议跳到正确聊天。
这一步的意义其实非常大。
它说明一个很重要的工程原则：
与其在不稳定的界面层上苦修，不如尽快下沉到更稳定的协议层。
这不只是 Telegram 的事。
几乎所有自动化问题，本质上都一样：
• 界面层脆
• 协议层稳
• 能不用纯 GUI，就尽量别只靠 GUI
───
四、连文字发送都被优化掉了
更有意思的是，后来发现 Telegram 的 deep link 不止能打开聊天，连消息文本都能带进去。
例如：
tg://resolve?domain=xx=你好，这是机器人代发的信息。
这意味着，原本的流程：
• 搜索对方
• 打开聊天
• 粘贴文字
• 回车发送
可以被简化成：
• deep link 直接打开聊天并预填内容
• 自动确认发送
这是非常典型的“把 GUI 操作协议化”。
也就是从“模仿人点界面”，变成“直接驱动目标应用进入正确状态”。
这一步让我更确定了一件事：
未来真正强的 AI 代理，不会停留在界面点击层，而会越来越多地利用应用本身的结构化入口。
───
五、最关键的一步，不是发消息，而是“拿回证据”
如果今天只是让 AI 给别人发一条消息，那其实还不够。
真正让我觉得这件事已经进入“可用阶段”的，是后面的这一层：
发完以后，把发送成功的聊天界面截图，再回传给我。
这一步看似只是多截一张图，实际上意义完全不同。
因为很多 AI 自动化都会陷入一个经典问题：
• 它说“做了”
• 但你不知道它到底是真做了，还是只是“感觉自己应该做了”
而一旦加上回执截图，事情就变了。
你不是听它说：
• “我已经发了”
• “应该成功了”
• “脚本没报错”
而是直接看到：
• 当前聊天窗口
• 新发出的消息
• 新发出的图片
• 发送时间
• 实际界面证据
这其实是在给 AI 自动化补上最重要的一层：
可验证性。
如果没有这层，AI 自动化更像魔术；
有了这层，它才像系统。
───
六、然后又碰到了另一个现实问题：熄屏以后，GUI 自动化就不那么听话了
当 Telegram 自动化逐渐跑通之后，我又开始想更进一步：
能不能让电脑熄屏、后台继续运行，同时 AI 还继续干活？
这时又撞到了另一个现实边界。
答案并不是简单的“能”或“不能”。
熄屏后，后台能力通常还在：
• shell 命令还能跑
• 文件还能读写
• 消息还能回复
• OpenClaw 这种宿主还能继续运行
• 后台代理还能继续存在
但熄屏后，GUI 自动化会明显变脆：
• Telegram 前台窗口不一定还能被稳定获取
• 浏览器窗口状态可能变得不可靠
• AppleScript / System Events 可能拿不到窗口索引
• “当前可见界面截图”这种操作容易失败
这件事让我对“AI 接电脑”这件事又多了一层理解：
后台运行，和前台 GUI 可操作，不是同一件事。
很多人会把这两件事混为一谈。
但今天这个实验很清楚地告诉我：
• 代理还能活着
• 不代表它还像亮屏时那样，能随便点一切 GUI
这不是 AI 的问题，而是图形会话本身的边界。
───
七、为了让“龙虾”一直跑，我还调了电脑的电源策略
除了 Telegram 之外，今天还做了另一件很实用的事：
把电脑调整成更适合 AI 后台工作的状态。
最开始为了防止电脑睡死，我开了一条命令：
caffeinate -dimsu
但很快发现副作用非常明显：
碰一下键盘后，屏幕会很久都不灭。
原因是其中的 -d 参数会阻止显示器休眠。
后来我把它改成：
caffeinate -ismu
这版更适合长期运行代理：
• 允许显示器正常熄灭
• 但尽量不让整机睡死
• 让后台能力尽量继续工作
再往后，又把接电模式下的显示器熄屏时间调成了 3 分钟，最后确认已经生效：
• displaysleep 3
也就是说，现在机器已经进入一种更适合 AI 代理长期运行的状态：
• 接电
• 3 分钟息屏
• 尽量保持后台继续跑
• 需要 GUI 时再恢复前台会话
这看起来像一堆系统小细节，但其实很关键。
因为一旦 AI 要从“偶尔帮你一下”升级成“持续陪跑”，
它就必须和你的设备状态、电源策略、图形会话一起被考虑进去。
───
八、这次最让我震撼的，不是 AI 更聪明了，而是它开始更像“同事”了
我今天反复有一种感觉：
它不再只是一个回答问题的模型，而更像一个会自己动手的数字同事。
不是因为它“全知全能”，而是因为它开始具备下面这些特征：
• 能理解模糊需求
• 能拆解成执行步骤
• 会自己动手验证
• 一条路不通，能换一条路
• 能把临时方案收敛成可复用工具
• 最重要的是，它会把结果拿回来给你验收
这已经不是“提示词工程”那个范畴了。
更像是：
一个具备工具能力、执行能力和回执能力的实战代理。
而且它不是停留在概念层面。
今天我们真的现场把它跑通了。
───
九、如果只总结一句话，我会这么说
今天这次实验，真正做成的不是“AI 能发 Telegram 消息”。
而是：
我们把一个本来只会对话的 AI，接到了真实电脑环境里，
让它学会了通过协议直达 Telegram 会话、通过本机能力发送文字和图片、通过截图回传形成证据链，并结合 Mac 的电源策略，开始具备持续运行和执行任务的能力。
这件事看起来不大，
但它已经很像未来个人 AI 的雏形了。
不是“你问它，它答你”，
而是“你交代它，它去做”。
───
十、我越来越相信，AI 的真正革命不在聊天，而在代理
如果只是聊天，AI 的上限大概是：
• 更懂你
• 更会写
• 更会总结
• 更会表达
但如果进入代理阶段，AI 的意义会完全不一样：
• 替你操作工具
• 替你调用服务
• 替你搜集证据
• 替你整理流程
• 替你完成一部分本来要你亲手做的数字劳动
而今天这次实践，让我第一次很明确地感觉到：
这不是“以后会发生”的事，而是“现在已经开始发生”的事。
