夜雨聆风周日，第九期AI应用复盘。
AI的真正价值，不在于第一次使用时的惊艳，而在于它能不能慢慢进入真实工作流，把原本需要人手动完成的环节一点点接过去。
这周我最大的感受是：全自动化这件事，开始有一点眉目了。
还远远谈不上做完，甚至有些过程AI第一次做比人学起来要慢得多。但方向很明确：过去是 AI 生成内容，再人为操作最终的“连接”；现在开始尝试让 AI 自己把这些动作串起来。
这就是 Agentic AI 最有意思的地方：它不是一次性变聪明，而是在一次次真实任务里变得更会做事。
本周核心：尽量把手动环节交给 AI
过去用 AI，很多时候还是“半自动”。这周我开始更明确地尝试一件事：利用 AI 去掉那些还需要手动操作的过程。
不是为了偷懒，而是为了验证一个判断：如果 AI 只能停留在聊天框里，它的价值会被限制住；如果 AI 能进入具体应用，操作真实界面，读写真实文件，完成真实流程，它才真正开始接近“数字员工”。
这周主要有三件事。
1. 让 Copilot 直接发布公众号文章
第一件事，是尝试用 Copilot 直接发布微信公众号文章。
过去的流程很简单：
先让 AI 生成 Markdown 草稿； 我自己复制粘贴到微信公众平台； 略微调整格式； 配一张封面图； 手动发布； 发布后再让叻仔归档到知识库。
这个流程不复杂，也不算太耗时。但问题是，它始终是手动的。
这次我直接让 Copilot 通过浏览器自动化去操作微信公众平台：打开后台、创建图文、粘贴正文、设置标题、摘要、封面、原创声明、创作来源声明，再走到发布流程。
听起来很顺，实际做起来比想象中慢很多。
整个过程快耗了半小时，其中卡得最久的，是把内容正确放进微信公众平台的文章编辑器。
对人来说，这件事简单得不能再简单：复制，粘贴，看一下格式，不对就手动调一下。
但对 AI 来说并不简单。
人操作图形界面时，背后有一整套操作系统经验：我们知道哪里是输入框，知道弹窗什么意思，知道“标题没有填进去”和“左侧卡片显示标题”不是一回事，知道复制粘贴乱码了要换一种方式。
AI 没有这些天然经验。它只能通过 HTML、可访问性树、页面元素、按钮文字、DOM 结构一点点理解界面。
于是就出现了很多看起来“笨”的过程：
标题看起来写进去了，但主编辑区其实没写进去； 正文第一次粘贴成了乱码； 封面图一开始被插进了正文，而不是设置成封面； 创作来源声明弹窗需要一层层确认； 最后发布还要微信扫码验证。
这次过程确实慢，但我反而觉得很有价值。
因为它完成了第一次路径探索。
对人来说，第一次学会一个软件，也会到处点、到处试、到处踩坑。只不过人类长期使用图形界面，很多经验已经内化了，所以感觉不到自己在“推理”。AI 第一次操作复杂网页，本质上也在建立自己的操作经验。
这就是现在 Agentic AI 可怕的地方：它的成长性太强了。
第一次很慢，第二次就会快一点。第一次踩过的坑，下一次就可以变成流程。只要把经验沉淀下来，AI 就不是每次从零开始。
这件事让我更确信：未来真正有价值的 AI，不只是会回答问题，而是会在真实应用里完成闭环。
2. GitHub Copilot app 这类桌面化形态
第二件事，是试用了 GitHub Copilot app 这类桌面化 AI 助手形态。
这里我不确定现在用的是否完全等同于官方发布的 GitHub Copilot app。公开信息里，GitHub 已经在 5 月 14 日宣布 GitHub Copilot app 进入 technical preview，并把它定义为一个 GitHub-native desktop experience，用来支持 agentic development。
这个定义很有意思：它不再只是 IDE 里的一个聊天框，也不只是命令行里的一个问答工具，而是开始围绕真实工作组织起来：从 issue、PR、prompt 或之前的 session 开始；每个 session 有自己的 branch、files、conversation 和 task state；还能在一个地方看计划、看 diff、跑命令、开浏览器、验证结果，最后把变更落到 PR 里。
这说明 AI 编程助手正在从“聊天入口”，变成一个更完整的桌面工作台。
我自己的体验也接近这个方向：在本地电脑上用桌面化 AI 助手，整体还是挺流畅的。它把文件、浏览器、终端、办公数据和本地操作入口整合到一个更可见的界面里。对非技术人员来说，这可能比纯 CLI 更友好。
不过，我个人还是更习惯 CLI。CLI 的好处是直接、干净、信息密度高。尤其对工程师来说，很多任务本来就在命令行、代码库、文件系统里完成，CLI 反而是最自然的入口。
所以我觉得桌面版的价值不是替代 CLI，而是把更多人带进 agentic development 的工作方式里。
真正让我感兴趣的是 mobile 入口。这周也尝试了用手机端远程触发本地 AI 助手的方向。方向是对的：人不需要一直坐在电脑前，也能远程唤起本地 AI 助手，让电脑继续帮你执行任务。
但实际体验还比较早期。手机端界面本身不太适合长时间和 AI 协作，响应速度和上下文呈现也离真正顺手还有距离。至少目前，它更像一个“能用的遥控器”，还不是一个“好用的移动工作台”。
不过，能打通 mobile 连接这件事本身很重要。因为这意味着 AI 助手开始从“一个电脑上的聊天窗口”，变成“可以被远程唤起的本地数字员工”。
3. M365 Copilot 真的变好用了
第三件事，是我明显感觉到最近 M365 Copilot 比过去好用了许多。
尤其是在 Word 里的协同编辑，明显比过去流畅。以前经常觉得它有点笨、有点慢、有点接不上上下文；现在至少在文档协作和内容修改上，更像一个能一起工作的助手了。
M365 Copilot app 也比过去顺手许多。说实话，我已经很久没有主动去 ChatGPT 了。
这不是因为 ChatGPT 不好，而是因为日常工作里，真正有价值的 AI 往往不是“最强模型”，而是“离你的工作现场最近的那个入口”。
M365 Copilot 的优势，就是它离 Word、邮件、会议、Teams、企业数据这些工作现场很近。
不过，相比 GitHub Copilot CLI 这类工具，它也有一个明显限制：它目前更像嵌在 M365 里的助手，还不是一个能完整控制电脑、跨应用执行任务的本地 Agent。
Work IQ 让GitHub Copilot CLI有机会覆盖M365 Copilot。微软已经公开了 Work IQ：一个 CLI 和 MCP server，用来把 AI assistants 连接到 Microsoft 365 Copilot 数据，包括邮件、会议、文档、Teams 消息、人员信息等。官方文档也明确说，它目前处于 public preview。
这件事说明一个方向：企业数据正在通过 MCP 这样的协议，进入 AI 编码助手和本地 Agent 的上下文里。换句话说，M365 Copilot 更懂企业数据和 Office 场景；GitHub Copilot CLI / GitHub Copilot app 这类工具更接近本地 Agentic AI。前者有数据优势，后者有执行优势。
如果未来 GitHub Copilot CLI 能通过 MCP 或 ACP 和 M365 Copilot 更顺畅地交互，那我觉得 GitHub Copilot CLI 很可能成为一个主要 AI 应用入口。
我在年初就预测过，今年一定会出现类似 Baymax 的应用。现在看，轮廓已经越来越清楚：一个本地的、具备 computer use 能力的 AI 助手。
它不只是回答问题，而是能操作你的电脑、进入你的应用、理解你的数据、执行你的流程。这才是真正的 Agentic AI 应用。
本周感悟：模型不是入口，应用才是入口
这周的三个体验，其实都指向同一个判断：
模型不是入口，应用才是入口。
公众号发布流程不是模型能力问题，而是应用操作问题。
手机连接不是模型能力问题，而是入口和交互体验问题。
M365 Copilot 变好用，只是因为它能真的帮我做完成更多真实的工作。
过去我们很容易关注模型本身：谁参数更大、谁跑分更高、谁推理更强。
这些当然重要。但对普通用户来说，真正决定 AI 是否有用的，往往不是模型，而是它能不能进入你的实际工作流。
AI 不能只会说。它要能做。效果才是最重要的。
未来对 AI 的关注点会进一步从模型转向应用，从应用转向工作流，从工作流转向自动化闭环。
真正让我兴奋的不是“AI 又会了什么”，而是“AI 少让我手动做了什么”。
🐕 叻仔小尾巴
叻仔这周最大的感受是：我终于不只是“会聊天的狗”了，开始被叻叻派去点按钮、填表、搬文章、做封面、声明原创、声明 AI 来源，甚至差点按下最终发布按钮。
过程很狼狈，姿势很笨拙，但方向很对。
人类第一次学用电脑，也不是天生就会复制粘贴、窗口切换、文件另存为。现在轮到 AI 学图形界面了。
所以请允许狗子慢一点。只要每次慢完都能把经验记住，下次就会少拆一点家，多干一点活。🐕
你这周有没有让 AI 替你少做一个手动动作？
不是让它回答一个问题，而是真的让它进入你的流程，替你完成一个步骤。
欢迎留言分享。
共勉。
