为什么 Copilot for M365 对我来说已经没用了——兼谈 Codex + Computer Use 如何重构了我的工作流
序：一个不太礼貌的开场
我得先坦白一件事：我已经记不清上一次主动打开 Excel、Word 或 PowerPoint 是什么时候了。
不是夸张。不是「我尽量少用 Office」。是零次——至少在最近几个月里，我没有主动双击过任何一个 Office 图标。文件照常在产生，报表照常在做，但那个「新建 → 空白工作簿」的手势，已经彻底从我的肌肉记忆里消失了。
然后我再坦白第二件事：Copilot for M365 的付费订阅，我也没再续了。
这篇文章想说的，不是 Copilot 本身「烂」——微软在这个产品上投入了天文数字，它也确实给很多人带来了效率提升。我想说的是：对于我这样一个已经用 Codex + Computer Use 重构了工作流的人来说，Copilot 恰好落在了不再有用的位置上。 而这个位置，可能比很多人想象的要来得更快。
一、Copilot 的核心卖点是什么？（回顾一下）
先让我凭记忆拉一下 Copilot for M365（那个 $30/用户/月的额外付费版本）的卖点清单：
- 在 Office 应用内生成内容——Word 里写文档、Excel 里分析数据、PPT 里做幻灯片
- 接入 SharePoint/OneDrive——搜索和引用你企业内部的文档库
- Teams 会议总结——自动生成会议纪要、待办事项
- 自然语言查询企业数据——「帮我找出上季度华东区的销售额」
- Copilot Studio 创建 Agent——低代码做一个简单的对话机器人来处理业务流程
- Business Chat (BizChat)——跨应用的一次对话完成任务
每个卖点听起来都很有吸引力，尤其在微软的演示视频里。但在我的日常里，它们一个一个地被替代了——不是被另一个 SaaS 产品，而是被一个更原始的范式：给 AI 一个终端和一个浏览器，然后让它自己学。
二、Codex + Computer Use：一个更「原始」但更通用的替代方案
先说明白我的「新工作流」到底是什么：
- Codex CLI——一个能在终端里自主工作的编码 agent。我告诉它要什么，它自己写代码、自己调试、自己运行。
- Computer Use——让 AI 能操作我 Mac 上的任何软件。浏览器、IDE、生产力工具，甚至系统设置。它看到屏幕，移动鼠标，敲键盘。
这两个东西加起来，构成了一个超集：任何需要通过「阅读→思考→操作」来完成的事情，都可以交给它。Office 文件只是其中一类。
下面是 Copilot 卖点和我当前工作流的逐项对比：
2.1 生成 Office 内容
Copilot 的做法： 在 Word/Excel/PPT 里打开侧边栏，用自然语言描述需求，Copilot 在应用内生成内容。
我的做法： 告诉 Codex「帮我生成一份 Q3 项目进度报告，包含以下数据……输出为 .docx」。Codex 直接调用 python-docx 库，写脚本把数据灌进去，生成文件。Excel 同理——openpyxl 或 pandas 直接操控数据。
差别在哪？ Copilot 生成的内容边界由内置 Prompt 和模型能力决定。Codex 的方式没有边界——我不仅能生成表格，还能在生成前执行任意数据清洗、从多个 API 拉数据、做复杂的条件格式化、甚至把生成的 docx 自动上传到某个位置。它不是「帮我写」的辅助工具，而是替我完成整个生产流程的工人。
2.2 接入 SharePoint/OneDrive
Copilot 的做法： 通过 Graph API 直连你的 SharePoint 文档库，在 Copilot chat 里搜索和引用。
我的做法： Codex 直接调用 SharePoint REST API 或 Microsoft Graph——一样的底层接口。或者更简单：用 curl、rclone 或 onedrive-sdk 读取文件。而且 Computer Use 可以直接打开浏览器或 Finder，走到 SharePoint 页面上去操作。
差别在哪？ 这里有两个层次的问题。
第一，SharePoint 本身的搜索能力已经足够好了。它基于微软搜索引擎、支持元数据筛选、内容类型过滤、精确的关键词和属性搜索。真正的问题不是「搜索不够强」，而是「用户不会搜」。不懂 SharePoint 搜索语法和筛选逻辑的人，同样不会用 Copilot 的对话式搜索来找到正确答案——他们描述需求的准确度决定了结果的准确度，而如果一个人连用关键词搜都搜不明白，用自然语言搜也大概率是同样的结果。培训全员成为「高级搜索用户」的成本太高，实际上也做不到。而那些本来就知道怎么高效搜索 SharePoint 的有经验员工，他们早就有不依赖 AI 也能快速找到文档的方法。
第二，当你的工作流从「坐在电脑前翻文档」变成了「AI 代理替你跑任务」时，对话式搜索的价值还会进一步缩水。 我不需要「搜到文档给我看」——我需要的是「搜到文档里的具体数据，然后把它喂到下一个环节里」。Codex 的搜索是一手操作，结果直接进变量，而不是进人类的眼睛。
2.3 Teams 会议总结
Copilot 的做法： 自动转录会议、生成纪要、提取待办。
我的做法： 说实话，这一点 Copilot 做得很好。但替代方案也不难——Teams 本身有 Meeting Transcript 导出功能（.vtt 或 .docx）。拿到转录文本后，Codex 可以生成纪要、分类待办、甚至按项目合并多个会议的要点。或者，一个接入了 Teams Graph API 的定时任务直接拉取转录，做同样的事。
差别在哪？ Copilot 更无缝——不需要手动导出这一步。但如果你已经用自动化 pipeline 做这件事，差异并不致命。
2.4 自然语言查询企业数据
Copilot 的做法： 「帮我找出上季度华东区销售额超过 50 万的所有客户。」Copilot 连接 Dynamics 365 或你的数据源，返回结果。
我的做法： 「Codex，查一下 PostgreSQL 里上季度华东区的销售数据，按客户汇总，给我一个表格。」——Codex 写 SQL、执行、返回结果。或者如果数据在 Excel 文件里，直接读文件、筛选、汇总。
差别在哪？ Copilot 的查询局限于它能连接的数据源（主要是 Microsoft 生态内的）。Codex 可以连接任何东西——SQL 数据库、REST API、CSV 文件、网页爬虫、Odoo、WordPress 数据库——而且可以跨数据源做 join。Codex 不仅有「读」的权限，也有「写」的权限——完成查询后直接更新系统、发邮件、生成报表，一条龙。
2.5 Copilot Studio Agent
Copilot 的做法： 用 Copilot Studio 的低代码界面创建一个 Agent：定义 Topic、添加 Prompt、配置知识库、发布到 Teams 或网站。
我的做法： 写一个脚本。或者更准确地说——告诉 Codex 我想要什么，它自己写脚本、部署、运行。 如果这个 Agent 需要定时执行，就挂到 cron 上。如果需要对外暴露接口，就起一个简单的 HTTP 服务。如果需要用自然语言交互，就让 Codex 自己写一个 CLI 或 Web 界面。
差别在哪？ Copilot Studio 的 Agent 本质上是配置好的 Prompt + 知识库——能处理预设好的问题，但遇到边界外的需求就会说「抱歉我不清楚」。而 Codex 写出来的 Agent 可以接入任意 API、执行任意操作、操作任意软件。它不是「回答问题的玩具」，而是真正能干活的工人。
2.6 BizChat（跨应用会话）
Copilot 的做法： 在一个对话框里，让 Copilot 读取你的日历、邮件、文档、聊天记录，综合后回答问题。
我的做法： Computer Use 可以直接操作 Outlook、Teams、浏览器——它看到了你在屏幕上能看到的一切。再加上文件系统权限，它读到的数据量远超 BizChat 能触及的范围。
三、一个核心差异：AI Agent vs. AI 助手
说了这么多，我觉得真正的区别是两个范式：
Copilot 的范式：AI 助手
- 你干活，它帮忙
- 你在应用里，它在侧边栏
- 它负责生成内容，你负责判断和操作
- 它回答「你需要什么」
Codex + Computer Use 的范式：AI 工人
- 你告诉它活要什么结果，它从头做到尾
- 它操作应用，你做其他事
- 它负责从数据获取到文件生成到部署的全过程
- 它回答「我来搞定」
Copilot 是增强了你作为信息工作者的能力。而 Codex + Computer Use 是直接替你完成了信息工作。
这听起来可能有点极端——但对我来说，区别就是：「写一份周报，Copilot 帮我起了个开头，我还得自己修修改改」VS「Codex 自己去爬 Jira、拉 Git log、整理成了周报，放到桌面上，我检查一遍就发出去。」
一个是加速器，一个是自动驾驶。
四、Copilot 的最新进化——以及对它易用性和实用性的评价
4.1 微软确实在推新东西
微软最近确实有大的动作：
SharePoint Copilot Apps（2026 年 7 月 9 日 public preview） 这不是「对话式搜索文档」了。它允许开发者在 Copilot 画布内构建交互式应用：审批表单、数据网格、多步骤工单——直接在 Copilot chat 里运行。底层用 SharePoint Framework (SPFx) 1.24。微软称之为「from intent to outcome（从意图到成果）」。
Building Agents for Teams（2026 年 7 月 14 日） 把 Agent 嵌入 Teams 对话。
Work IQ Developer Tools（预览中） 开发者工具，用来构建更复杂的工作场景。
4.2 易用性和实用性的真实评价
这些方向听着不错，但落到实际体验上，我不得不打几个问号：
门槛问题。 SharePoint Copilot Apps 要求你掌握 SharePoint Framework (SPFx)、Web Component、TypeScript——这是一套完整的 Web 前端开发技能栈。对普通知识工作者（Copilot 的主要目标用户）来说，这就是不可逾越的门槛。微软的回应是「用 AI 代码工具来生成这些组件」——但这又把球踢回给了 AI Agent 工具，而 Copilot 自己并不提供这种生成能力。这形成了一个悖论：要用好 Copilot 的新功能，你可能需要先有一个比 Copilot 更强大的 AI 工具。
价值密度问题。 一个交互式审批表单真的需要在 Copilot 里跑吗？用户通常的审批流程是：收到 Teams 通知 → 点开链接 → 网页里点一下「批准」就结束了。把它搬到 Copilot 画布里变成 SPFx 组件——多了一层开发和维护成本，但最终用户的操作路径并没有缩短。我理解微软想让 Copilot 变成「工作中心」的战略意图，但从实用主义角度看，很多场景的边际收益非常有限。
租户级别的部署成本。 SPFx 组件需要打包、部署到 SharePoint App Catalog、分配权限——这是企业级 IT 治理的流程，不是一个普通用户能独立完成的。微软说「任何开发者都可以」，但「开发者」和「Copilot 用户」之间隔着整整一个 IT 部门。
Teams Agent 的实际体验。 把 Agent 嵌入 Teams 对话看起来很自然，但如果 Agent 只能回答预设知识库里的问题，它的实用性就等同于一个 Search 功能加上了自然语言包装。真正的 Agent 需要能采取行动——写数据库、发起审批流、操作外部系统。Copilot Studio 的自定义 connector 可以部分做到这一点，但配置的复杂度和维护成本都远高于直接让 Codex 写一个集成脚本。
4.3 这些更新能不能挑战我的结论？
坦白说，能，也不能。
「能」的部分：Copilot 确实在认真解决「Chat 不能做结构化操作」的问题，方向是对的。如果 SPFx 组件的生态做起来，Copilot 会从一个「智能侧边栏」进化成一个「工作台」。
「不能」的部分：这些新能力的本质是把开发复杂性带进了 Copilot——你需要 SPFx、你需要 Web Component、你需要了解 Microsoft Graph。这不是”产品功能增强”，这是把平台功能的开发任务转嫁给了用户。而相比之下 Codex 可以直接生成这些组件，并且不限 SharePoint——它操作一切。
另外，对于我个人的工作流来说，即使 Copilot 做了这些改进，它依然没有解决一个基本问题：它仍然假设「人」坐在电脑前操作 Office 应用。 而我的工作流已经不再依赖这个假设了。
五、一个更深层的矛盾：Agent 应该变得更简单，而不是变得更复杂
你去看 AI Agent 的发展趋势，有几个共识性的方向正在形成：
- 统一的入口：用户不需要知道背后有几个 Agent、哪个 Agent 负责什么——他只需要在一个对话窗口里说出需求，系统自己路由和协调。
- 自然语言即界面：AI 的交互方式在不断收敛到「说话 / 打字即可」，而不是学习新的 UI、新的配置面板、新的开发工具。
- Agent 自主适配：好的 Agent 体系应该自己判断需要什么工具、访问什么数据、调用什么 API，而不是用户手动告诉它「你先去连接 SharePoint，再去找这个，再去配置那个」。
但 Copilot for M365 的最新演进方向，恰恰反着走：
- SharePoint Copilot Apps → 你需要学 SPFx 开发
- Copilot Studio → 你需要学 Topic / Entity / Trigger 的配置模型
- BizChat → 还算简单，但能力有限
- Teams Agent → 又一个独立配置入口
每一个新能力，都在增加产品的表面积——新的术语、新的配置面板、新的开发流程。用户不是在用一个对话助手，而是在经营一个「Copilot 应用生态」。
这让我想到早期 Salesforce 的路径：从一个 CRM 变成了一个需要管理员和开发者的平台生态。对企业来说是好事（扩展性强），对个人用户来说，学习曲线越来越陡。
而我更倾向于一个相反的方向：真正的 AI Agent 应该只有一个入口，你告诉它你要什么，它自己去搞明白怎么做。 我不需要知道它背后用的是 SharePoint API 还是直接读文件系统，是调 SPFx 组件还是开浏览器操作——就像我不需要知道电梯的钢缆是怎么转的一样。
在这个逻辑下，Copilot 的每一次「重大更新」都在把产品推向我越来越不需要的方向。而 Codex + Computer Use 做的事正好是反过来的——入口极其简单（一个终端，一句话），能力边界由 Agent 自己扩展。
Copilot 让用户变强。Codex 让用户不用变强。
这没有对错之分，但谁更能代表 Agent 的未来，我倾向于后者。
六、有些不公平的「降维打击」
我得诚实地说，这个比较有不公平的地方：
- Copilot for M365 是一个面向普通知识工作者的产品。 它的目标用户是每天用 Outlook、Teams、Word 的商务人士——销售、HR、项目经理。对他们来说，「在 Word 里写文档时侧边栏帮我生成一段文字」就是巨大的效率提升。
- Codex + Computer Use 是一个面向开发者（或者愿意用 AI 替代开发者的角色）的范式。 它的门槛更高——你需要能描述清楚需求，需要接受中间产物是代码，需要容忍偶尔的失败。
但我恰好处于一个特殊的位置：我有技术背景，但我大部分时间不做传统意义上的「开发」——我做的是技术营销、内容策略、项目管理。 这个位置让我既能理解 Codex 的能力边界，又有足够的「非开发类」工作让它来干。
而一旦你跨过了这条线，回头再看 Copilot，就会觉得它像是一把瑞士军刀 vs 一台数控机床——做日常小修补很顺手，但真的十几个零件要加工，你不会用军刀。
七、所以结论是什么？
Copilot for M365 对我来说没用了，不是因为它是烂产品，而是因为我换了工具范式。
这就像有人从骑自行车换成了开汽车，然后说「走路对我来说没用了」——对于还在走路的人来说，这是个莫名其妙的结论。但对于已经坐进驾驶座的人来说，这就是事实。
如果有一天 Copilot 变成一个真正统一的入口，不再给你一堆配置面板和开发框架，而是你自己就能直接说出需求、它帮你搞定——那它可能会重新进入我的工具箱。但眼下，它走的是越来越复杂、越来越平台化的路线。
而我，已经走上了后一条路。
P.S. 以上全部基于我个人的实际工作流和个人体验。如果你用 Copilot for M365 感觉很好——那就对了，说明它是为你设计的。它只是不再为我而设计了。
P.P.S. 你可能注意到了，这篇文章是用 Codex 训练的企业微信 Hermes AI 员工辅助写的——我在聊天框里说出想法，它帮我组织、查询资料、排版。而不是在 Word 里用 Copilot 的侧边栏。这大概本身就是最好的脚注。
