AI办公真正缺的,是让软件长成你的样子

半年里，我重复做了两次相同的事

今年我自己做了两个东西。

第一个叫 Utter，是一套属于自己的 AI 语音输入法。最初的原因很简单，市面上的语音输入产品已经不少，识别速度、准确率和文字润色也都做得不错。可真正每天使用以后，我还是会不断遇到一些很细的需求。快捷键应该怎么触发，什么时候保留口语，什么时候整理成书面表达，技术名词怎么识别，当前窗口里的内容要不要成为上下文，不同软件里应该输出怎样的文字。

这些需求很难说有多大的市场。它们太细了，细到一家大公司很难专门为我设计。可当模型和开发工具都变强以后，我发现自己做一个似乎也没有那么难。于是我做了 Utter。

几个月后，同样的事情又发生了一遍。这一次是 AI 编程。

Claude Code、Codex 这些工具已经足够强，我还是做了 Code2。我没有继续使用行业里已经很常见的聊天框。Code2 采用「document-first」的交互，Prompt 本身是一份可以编辑和组织的文档，Skill 可以通过「/」直接插入文档，底下再统一驱动 Claude Code、Codex 和 Grok。

我后来又把它的存储、Agent Loop、Git、记忆、场景和终端逐渐拆成插件。Code2 内部不再是一个固定程序加上一些扩展点，它更接近一张可以重新组合的插件图。插件声明自己依赖什么、提供什么，也可以在运行中被加载、替换和卸载。

回头看时，我才意识到，自己在半年里重复做了两次相同的事情。市场上已经有能用的软件，我仍然想做一个自己的版本。这里缺的并非某个功能，我真正想要的是：

让软件按照我的工作方式工作。

Coding Agent 正在把完整软件拆成可以组合的几层

这几年 AI 编程产品的变化很快。

最早是代码补全。程序员继续控制整个过程，模型负责猜下一段代码。后来有了 Chat。模型开始读取文件、错误信息和项目资料，回答问题并生成修改建议。再后来，模型拿到了文件系统、终端、Git、浏览器和各种开发工具。用户给出一个目标，Agent 自己查代码、改文件、运行测试、读取报错，然后继续修正。

到了 2026 年，新的变化已经不只发生在模型能力上。整个 Coding Agent 开始被拆开。

T3 Code 把自己称为「agent harness control surface」。它不重新实现 Claude Code、Codex、Cursor、Grok Build 和 OpenCode，而是控制这些已经安装在用户电脑里的 Agent，再提供手机、网页和桌面界面。项目甚至明确表示，用户应该始终保留 Fork 并做出自己理想编辑器的能力。

OpenCode 2 又把 Agent Backend 做成了一套可以调用的服务。Agent、Session、Skill、MCP、权限、上下文压缩和模型等能力，都开始拥有相对清晰的接口。

DeepSeek Harness 走得更远。它的核心理念直接叫作「Everything is a Plugin」。模型适配、工具、Session、Agent Loop 和 UI，都可以成为插件。目前项目仍处于开发者预览阶段，接口还会继续变化，可它表达出来的方向已经非常清楚。

把这些项目放在一起看，一个 AI 编程产品大致可以拆成几层：

用户界面个人规则与工作方式Agent运行和任务编排Context、Session与MemorySkills工具、权限与执行环境模型

用户界面在最上面，模型在最下面。中间这些层，决定模型看到什么、会使用什么方法、能操作什么、什么时候需要确认，以及一个任务应该怎样继续执行。过去，这些东西通常被焊在同一个产品里，现在它们开始可以被替换、组合和重新设计。

这就是为什么越来越多程序员会做自己的 Coding Agent。大家使用的底层模型可能相同，最终的软件却会完全不同。有人想让每个 Issue 自动创建一个 worktree，有人想同时运行三个 Agent，有人要求所有修改先运行测试，有人允许自动 commit 却不允许自动 push，有人喜欢在手机上检查任务，还有人只想保留一个终端和一个输入框。

这些差异很难全部归结为「功能」。它们描述的是一个人怎样工作。

当软件开发成本越来越低以后，程序员会自然地把软件改成适合自己的形状。我做 Utter 和 Code2，本质上也在做同一件事。

当前的 AI 办公产品依然主要是厂商搭好积木

再看今天的办公 AI，情况就有意思了。

Codex 已经支持多个 Agent 并行工作、Skills 和 Automations。用户可以把重复任务保存下来，按照时间执行，再回来检查结果。WorkBuddy 企业版也在强调专家 Agent、团队协作、企业知识和 Skills 资产，希望把员工经验沉淀成组织可以管理和复用的能力。千问也在开放第三方 Agent 和 Skill，希望让更多能力进入自己的产品体系。

这些产品都在快速进步。可从用户看到的形态来看，它们大多仍然遵循一个熟悉的结构：

厂商设计Agent + 厂商准备Skill + 厂商制作模板+ 厂商规定界面 → 用户从中挑选

以前有 App Store，现在开始有 Agent Store、Skill Store 和各种专家套件。用户想做投研，就启用一个投研专家；想分析数据，就选择一个数据 Skill；想每周生成报告，就创建一个自动任务。

能力确实多了很多，真正的编排权依然集中在产品团队手里。AI 明明非常灵活，最终却经常被装进一套相对固定的软件中。聊天框放在哪里，任务怎么展示，哪些信息长期保留，Agent 怎样协作，结果以报告、表格还是页面呈现，这些通常已经被厂商决定。

这也是今天很多 AI 产品给我的感觉。它们像一张摆满了高级食材的桌子。材料越来越丰富，用户依然只能点菜单上已经写好的菜。

用户说不清工作流程，不等于用户不知道怎么工作

这时候会出现一个很现实的反驳。普通用户真的有能力编排自己的软件吗？很多人连自己的工作流程都讲不清楚。

你问一个销售：「你是怎么判断客户优先级的？」他可能想一会儿，然后回答：「就看情况啊。」

这句话听起来像是什么都没说。可你给他十封真实邮件，他马上就能判断：「这个现在回复。」「这个可以晚一点。」「这个客户不能用模板。」「这个订单虽然不大，但人是老板介绍的。」「这封邮件先让我自己看。」

他写不出完整的判断规则，却能在真实情境里做出选择。大量工作经验本来就留在人的行动和判断里，没有被整理成流程图。

所以，让普通用户打开一个空白页面，然后要求他配置 Trigger、Condition、Branch、Agent 和 Skill，大概率走不远。那仍然是一种编程，只是节点变成了方块。

用户更擅长的事情其实很有限，也很明确：他说出目标，做一次示范，看到结果后进行修改，遇到特殊情况时告诉系统「这次不同」。

ALLOY 这项 2025 年的研究就在探索类似方向。研究者发现，用户很难单靠 Prompt 描述包含个人偏好的过程要求，于是让用户直接演示任务，再由系统生成透明、可以编辑和复用的工作流。在一项 12 人参与的实验中，演示式方法在捕捉用户意图和过程偏好方面优于纯 Prompt 与手工工作流。样本规模不大，可它指出了一个很重要的方向。

用户不需要先理解自己的全部工作方式。他只要在真实工作里不断表达：「这里不对。」「下次直接做。」「这个人例外。」「超过这个金额先问我。」「报告别写那么长，我只看这三个数字。」剩下的形式化工作，应该交给 AI。

「养虾养马」已经走到了个人 Harness 的门口

OpenClaw 和 Hermes 这类产品，已经开始接近这个方向。

OpenClaw 不再只是一个聊天机器人。它有统一 Gateway、持久 Session、Memory、Skills、定时任务、工具、多 Agent 路由和多个消息入口。用户可以在聊天软件、网页、命令行和其他设备上调用同一个 Agent。

这也是「养虾」这个说法很传神的地方。用户给它接工具，装 Skill，调整规则，让它记住一些事情。时间久了以后，每个人的「虾」都会有点不同。

Hermes 又往前走了一点。它可以在完成复杂任务、经历错误、收到用户纠正以后，把可复用的方法保存成 Skill。Memory 用来保存较短的长期事实，Skill 用来保存更长的过程经验，用户还可以要求所有写入先经过审批。

这意味着 Agent 的工作经历已经开始反过来修改 Agent 自己。

以前是：人配置Agent → Agent执行任务现在逐渐变成：Agent执行任务 → 用户纠正 → Agent总结经验→ 形成或修改Skill → 下次继续使用

这离我们讨论的方向已经很近。可它们还需要用户认真地「养」。用户仍要安装、配置和维护大量东西。系统形成的能力主要还是 Skill 和 Memory，界面也通常是固定的聊天、控制台或桌面应用。它们证明了个人 Agent 的需求存在，也证明用户愿意培养一套属于自己的系统。普通办公用户真正需要的版本，还应该再往前走一步。

AI 应该把人的工作逐渐编译成软件

假设一个运营每周一都要做销售报告。

第一周，他对 AI 说：「整理一下上周销售情况。」AI 做完以后，他开始改。「取消订单不要算。」「华东单独放一块。」「同比变化超过 10% 的地方提醒我。」

第二周，他又补充：「新开的门店没有去年数据，不要计算同比。」

第三周，他说：「杭州上周做了促销，这个增长不能直接解释成经营变好了。」

半年以后，这个用户可能从来没有打开过工作流编辑器，也没有写过 Skill。可系统背后已经逐渐形成了一套稳定结构：数据来自哪里，指标怎样计算，什么情况属于异常，哪些门店需要特殊处理，什么时候自动执行，什么结果需要人工确认，最终应该怎样展示。

用户没有编程。他只是在正常工作。

AI 把一次次修改、拒绝和确认，逐渐编译成 Context、Skill、Workflow、权限和自动任务。这才是我觉得 AI 办公真正缺少的那一层。

而且它最终还应该包括 UI。今天很多 Agent 无论完成什么任务，最后都会回到聊天框里。可一个老板早上真正需要看到的，可能只是一个页面：

今天有3件事情需要你决定Acme合同报价等待确认[查看背景] [批准]华东销售昨日下降12%[查看原因]候选人李某终面已经完成[查看反馈] [确认Offer]

他没有必要先打开聊天框，然后问一句：「今天有哪些事情需要我处理？」

这个页面本身就是工作流程的一部分。换一个人，页面可能完全不同。所以未来的编排引擎不能只决定 Agent 怎么调用工具，还要决定工作以什么形式出现在用户面前。聊天、表格、报告、卡片、审批页面、通知，都应该根据任务和个人习惯重新组合。

AI 办公下一场竞争会围绕「谁能让软件适应人」

现在的 AI 产品还在增加材料。更多模型，更多 Agent，更多 Skill，更多 MCP，更多连接器，更多自动任务。这些能力都很重要，也是下一阶段必须具备的基础。

可材料越来越丰富以后，真正稀缺的会变成中间那个编译器。它观察用户怎样工作，理解用户的修改和拒绝，把隐含的习惯变成可以检查的规则，再不断调整 Context、Skill、Workflow、权限和 UI。

程序员已经开始手工做这件事情。我做 Utter，是因为现有输入法离自己的习惯还差一点。我做 Code2，是因为聊天框和现有 Coding Agent 的组织方式，无法完全表达我想要的工作环境。T3 Code、OpenCode 2 和 DeepSeek Harness，则把这件事从个人折腾变成了更清晰的行业趋势。

OpenClaw 证明用户愿意「养」一个属于自己的 Agent。Hermes 开始尝试让 Agent 从经验中修改自己。接下来真正值得等待的，是一套面向普通人的编排引擎。

它不会要求用户学习 YAML，也不会要求用户理解 Agent、Context 和 Skill。用户只需要工作。说一句，改一次，拒绝一次，批准一次，示范一次。软件在这个过程中慢慢改变。

到了那时，两个人即使订阅同一个办公产品，最后使用的也可能已经是两套完全不同的软件。

今天的软件公司先设计产品，再让几百万人适应同一套界面和流程。AI 给了我们一次把这个关系倒过来的机会。

下一代 AI 办公产品真正需要完成的事情，是把「AI 能做什么」，逐渐变成「软件应该怎样为这个人工作」。

软件终于开始适应人，这可能才是 AI 对软件行业最深的一次改变。