选择AI工具时，为什么要把发现、调整、执行、验证分开来看
把AI工作拆分为四个阶段，来审视工具与负责人。整理了使用研究的局限、连接规格的作用，以及更换产品时应留下的记录
商业仅凭模型名称，很难说明工作方式
回想用AI完成工作的那些日子，会发现自己其实在多个工具之间来回切换。用搜索收集资料，整理需求，再用另一个工具修改文件或代码，最后确认结果。可面对“你用的是哪个AI”这个问题，人们却总想用一家公司的名字来回答。
我认为，在选择工具时，把这个过程分为发现、调整、执行、验证四个阶段会有所帮助。这四个阶段是我为了审视工作而做的划分，并不意味着所有工作都只会按这个顺序进行，也不意味着每个阶段都必须购买不同的产品。
只要知道工作在哪个环节被拖慢，就能具体地讨论应该改变什么。因为对于查找资料耗时的组织，和缺乏结果审核标准的组织来说，即便添加相同的工具，效果也会不一样。
在使用研究中，人类更多负责规划，智能体更多负责执行
Anthropic在2026年6月的报告中，分析了2025年10月至2026年4月约23.5万人创建的40万个Claude Code会话。将对话记录用模型分类后发现，约70%的规划决策归属于人类，约80%的执行决策归属于Claude。How Claude Code is used in practice
这里的规划是指决定要做出什么、以什么结果视为完成。执行则是指选择要修改的文件和代码、要使用的命令。这显示出即便在同一场对话中，角色也是分开的。
研究所说的专业性也不是看职称，而是看对该任务的理解程度。分类的标准包括指示的准确性、要求确认的内容、纠正智能体错误的方式等。报告解释说，即便会计人员不懂编程语言，只要能准确指定对账规则和例外情况，也可以是该任务的专家。
按此分类，初级会话的“已验证成功”比例为15%，中级以上为28%至33%。这指的是模型判断为成功，同时也找到了通过测试或用户明确确认等证据的情况。这并非观测到实际公司是否采纳了产出结果、销售额或成本是否发生变化的成功率。
因此，这一数据不能直接套用到所有职业的AI绩效或教育的因果效应上。不过，我留意到一点：懂得工作标准并能说清楚的人，在指挥智能体方面可能更具优势。
把工作拆成四个阶段，更容易找到缺失的角色
我使用的划分方式如下。
| 阶段 | 需要确认的问题 | 所需功能与角色 | 应留下的结果 |
|---|---|---|---|
| 发现 | 需要了解什么 | 检索、资料探索、来源确认 | 候选资料与依据 |
| 协调 | 按什么顺序和范围来做 | 计划、工具连接、权限与负责人指定 | 执行计划与允许范围 |
| 执行 | 实际要改变什么 | 文件撰写、代码修改、业务系统处理 | 文档、代码、工单等成果物 |
| 验证 | 所要求的结果是否正确 | 测试、审查、批准、错误应对 | 判定依据与修改·恢复记录 |
在发现阶段，仅仅资料多是不够的。资料需要与我们的业务相关、保持最新、并且能够确认来源。如果是内部资料，访问权限和信息是否有遗漏也很重要。
在协调阶段，除了连接工具之外，还必须确定责任归属。也就是要决定用哪种信息来做判断、由谁来确认计划、哪些行动需要在执行前获得批准。
在执行阶段，实际状态会发生改变。文件被保存，工单被修改，视情况还可能产生订单或对外发送。在这个阶段，也需要有重新核对结果、防止重复执行的设计。
验证并不是最后才做一次的事情。挑选资料时可以确认来源，执行前可以审查对象和范围，执行后可以检查结果。如果发现问题，也可以退回前一个阶段。
举例来说，如果要制作一款新产品的说明文，可以把工作拆分为：查找价格和条件、确定目标客户和表述范围、撰写初稿、审查事实和可能引起误解的地方。即便全部工作都在同一个工具中完成，这些角色依然存在。
前面提到的研究区分了计划与执行，但这并不意味着这四个阶段已经在统计上得到证实。我这样划分的目的，是同时确认工具擅长做的事，以及组织尚未确定的事。
连接规格各司其职
谷歌 2026 年 3 月的开发者指南用餐厅食材采购的例子说明了多种规格各自扮演的角色。库存查询、与供应商沟通、下单、付款审批、画面显示，这些明显是不同的问题。Developer’s Guide to AI Agent Protocols
| 规格 | 在指南中承担的角色 |
|---|---|
| MCP | 连接工具与数据，用于查询库存等信息 |
| A2A | 寻找其他智能体，交换报价、品质、配送信息 |
| UCP | 以规定格式交换商品与订单、结账信息 |
| AP2 | 连接记录，用以证明是谁在何种条件下批准了购买 |
| A2UI | 表现智能体所呈现画面的构成与数据 |
| AG-UI | 将智能体的进展状态和消息传达到画面上 |
这些规格并不是围绕同一件事竞争的六种产品。但这也不意味着一次采购就必须全部引入这六种规格。这只是一个根据现有系统与所需功能进行组合的示例。
有付款审批记录，也不代表实际付款和订单都已成功。需要确认订单完成状态与付款结果，并规定失败时该如何处理。规格提供的是信息交换的约定，但并不保证业务结果。
MCP 是 2025 年 12 月贡献给 Linux 基金会旗下 Agentic AI Foundation 的项目。这意味着一个公开规格由多个主体共同推进，但并不意味着某家公司使用过的工具和数据就能直接迁移到其他产品上。Linux 基金会关于 MCP、AAIF 的说明
在实际工作中，除了是否支持某个规格之外，还要看别的东西：需要的功能是否以相同方式提供、认证与权限是否能够延续、错误与中间状态是否可以被解读。仅凭“支持 MCP”这样一个标示，很难判断连接工作就此完成。
更换工具时应该一并转移什么
即使出现更好的模型，也可能无法立刻替换产品。对话记录、用户培训、与既有业务的衔接都可能成为成本。我尤其会关注以下四个项目。
第一，结果和历史记录留在哪里。 要确认文档存放在哪个云盘、代码变更记录在哪个仓库。仅仅因为数据在供应商服务器上，并不意味着它就不属于我们、或者无法导出。合同规定的权利、可导出的格式、版本历史的可转移范围，都需要逐一确认。
有可能只能导出当前文件，而修改历史或评论会被遗漏。反过来，也可以把结果留在组织自己的存储库中，并配置多个工具依次接续工作。只有先确定下一步工作需要什么样的上下文，才能判断实际的可转移程度。
第二，访问权限。 新工具要访问相同的资料和系统，可能需要重新对齐认证、组织策略与安全审查。也要看看断开旧工具后权限是否会被回收。更换模型这件事和重新授予系统访问权限这件事，需要分开计算。
第三，评估用例与判定标准。 组织必须自己掌握那些实际经常出错的问题、可接受的答案范围、通过条件。要确认这些标准能否从产品中导出，并在新工具上照样执行或审核。即使有记录，如果执行环境不同，修改评估工具本身也需要成本。
第四，连接规格与实现之间的差异。 使用公开规格，会产生一部分可以通用处理的内容。但供应商专属功能或不同版本之间，可能各自需要额外的工作。“规格是公开的”这一事实和“替换成本低”这一结论，需要区分开来。
组织若能管理好这四个项目，就有更大的空间降低替换成本。但这并不意味着可以在几天之内完成迁移。即便四项都齐备，重新验证、培训、恢复等成本依然会存在。
<<<OZ_BODY>>>
整合成一款产品还是连接多款产品，这也是成本问题
把流程拆成四个阶段后，使用多款产品可能会让人觉得才是正解。但连接点越多，出错的地方和需要管理的权限也会随之增多。而且资料在哪个环节被修改，也可能变得难以追踪。
如果从资料检索到执行、复核都能在一款产品内完成，就能减少传递上下文的成本。反过来，如果某个特定阶段对业务至关重要，那么针对该功能的独立工具也可能会有帮助。我认为应该把各阶段的性能表现和整体运营成本放在一起比较。
举例来说，如果检索质量已经足够好，却因为没有执行权限而导致工作停滞，那么即便加入新模型也未必能解决问题。反过来，如果一直遗漏必要的依据，那么比起提升执行速度，更应该修正资料获取和检索方式。而如果结果本身产出得不错，却没有人来判断是否采纳，那么首先需要的是明确负责人和复核标准。
之所以划分成四个阶段，正是为了区分这些不同的问题。这并不是为了增加产品数量而进行的分类，而是为了确认同样的失败究竟在哪个环节反复发生而做的分类。
<<<OZ_BODY>>>
Oswarld视角
在谈论工具引入的时候，我发现大家的关注点总是集中在模型分数和响应速度上。我也认为这是重要的比较。但仅凭这些讨论，很难回答成果究竟沉淀在哪里、谁被判定为可以使用、以及日后能否迁移到其他工具等问题。
在这次使用研究中，让我思考良久的部分是专业性的定义。抛开职衔不谈，关键在于对该项工作的标准理解和阐释到什么程度。即便组织内部积累了知识，如果只停留在负责人的脑海里，也很难充分传达给智能体。
因此我认为，把标准用句子和案例的方式提炼出来是一件重要的事情。比如写下不能做什么、有哪些例外情况、结果应该和什么进行比较。这些句子本身并不构成一套完整的评估集，但如果再加上案例和判定方法，就能成为可以反复检验的资料。
即便是代码，也不能仅凭通过测试就确认全部质量。如果是战略或写作，就更需要多方面的判断。在这类工作中，同样可以留下依据是否正确、是否遵守了所要求的约束、由谁基于什么理由采纳了结果等记录。即便没有完美的自动评分，也可以明确审查标准。
在上一篇文章中，我曾谈到谷歌的关注功能与测量信息之间的差异。能够使用连接功能，和确保获取所需的使用记录，是两个不同的问题。我认为在AI工具上，也需要确认组织能够掌握哪些记录，并将其用于下一步判断。
在挑选工具时，我更看重的是：我们能否留下用于判断结果、并做出下一步选择的资料。只有记录下哪个环节耗时过长、失败的原因是什么、修改之后结果是否有所改善，才能在下一次引入或续约时展开具体的讨论。
💬 在发现、调整、执行、验证这几个阶段中，你现在最常卡在哪一步？ <<<OZ_END>>>
参考资料
- Anthropic, How Claude Code is used in practice, 2026年6月16日
- Google Developers, Developer’s Guide to AI Agent Protocols, 2026年3月18日
- Linux Foundation, MCP与AAIF的关系, 2026年1月12日
一起阅读：验证工作与负责人设计 · 谷歌的关注功能与测量信息
你的观点会成为下一期的线索
欢迎留下你的经验与看法。