联系巫彬微
+ +
DECONSTRUCT BINWEI. MAKE IT REAL. WRITE / BUILD. LET’S CONNECT.
一个金融物件，一种产品视角。
解构复杂。 表面之下，
你好，我是
巫彬微. 金融 AI 产品经理
从银行一线，
做过业务，也从风险合规的角度看过业务。
我的工作方式 ↗ 银行业务 × 风险合规 × AI 产品
翻到背面 ⤾
我的工作方式
把问题， 理解业务 角色、信息与每一次交接。 ↗ 保持判断 规则、证据与人工复核。 ↗ 动手构建 从流程到原型，用场景检验。 ↗
查看我的作品集 ↗
个人文章 / Vibe Coding
写下思考。
记录 AI 的变化，也记录自己的实践。
01 个人文章02 Vibe Coding
AI 观察 产品实践 构建手记
卡面 / 身份 每一层都有自己的职责。点击组件，看看表面之下。
01 解构复杂 ↗ 02 认识巫彬微 ↗ 03 工作方式 ↗ 04 个人文章 / Vibe Coding ↗ 05 保持联系 ↗ 银行业务 × 风险合规 × AI 产品
WBW / PERSONAL CONNECTION 微信联系关闭 ×
我的工作方式 · 个人优势 关闭 ×
理解业务
银行业务与风险合规
具备银行信贷、风险合规与不良资产处置经验，理解业务流程、岗位分工和法务复核要求。
能明确使用者、业务环节、AI 能力边界及人工责任，把业务经验转化为清晰的产品定义。
保持判断
金融 AI 质量与迭代
设计金融数据口径校验、规则与模型分工、来源引用及版本关联机制，让判断有据可查。
结合 Langfuse Trace、Bad Case 分析与 Prompt 对照开展复验和回归，依据残留错误做版本取舍。
动手构建
AI 原生构建力｜AI-Native Builder
将银行 SOP 转化为产品流程与验收标准，贯通需求拆解、PRD、原型、AI 工作流及反馈迭代；协同业务与研发开展需求评审和 UAT，覆盖缺件、冲突、退回及重复提交。
将复杂问题拆为可执行任务，组合大模型、业务规则与工具流程，借助 AI 编程和工作流编排，形成可运行、可验证的产品原型。
BINWEI / FIELD NOTES
个人文章 · 目录
OBSERVATION / WRITING / BUILDING
AI 观察笔记.
记录 AI 的变化，也记录自己的实践。
桌面Agent业务，难点在失败之后
dot 可以为你做什么
助贷新规出台，我对银行 AI 产品经理多了几个提醒
深读美团Agent评测漫谈 — 由浅入深讲解Agent评测
听完这场讨论，我重新理解了具身智能
FIELD / 01 观察
先把问题拆开，
记录现场。标出事实、关系与仍待确认的部分。
FIELD / 01 NOTES
从真实业务
BANKING × RISK × AI PRODUCT
FIELD / 02 判断
让证据留在
规则、来源和人工复核，共同构成可靠的边界。
FIELD / 02 METHOD
业务流程里，
理解业务 · 保持判断 · 动手构建
FIELD / 03 构建
把想法做成
WRITE / PROTOTYPE / REVIEW
FIELD / 03 BUILD
持续记录，
BINWEI · 保持好奇，持续构建。
BINWEI / FIELD NOTES
个人文章
OBSERVATION · PRACTICE · BUILDING
思考手记
记录 AI 的变化，也记录自己的实践。
WORKING PRINCIPLE / WBW
从真实业务出发，解构复杂。
银行业务 × 风险合规 × AI 产品
BINWEI / 2026
WBW · FIELD NOTES
让 Agent 打开应用、找到按钮、填完表格，已经越来越容易演示。真正进入业务后，产品经理面对的问题会变成：它点完“保存”却没有收到反馈，此时应该重试、跳过，还是交给人？
这个问题很小，却决定了一次自动化究竟是在节省工作，还是在制造需要人工清理的重复记录。
GitHub 在 2026 年 10 月 1 日发布的两项更新，恰好可以放在一起看：Copilot 的桌面操作扩大了 Agent 能接触的软件范围；动态工作流则让团队用代码规定步骤、交接和检查点。两项能力都处于公开预览阶段。[1][2]
我的判断是：桌面 Agent 的产品价值，要从“成功操作了多少次”转向“可靠完成了多少笔业务”。 下面通过一个假设场景，把这句话拆成能写进需求文档的设计。场景及方案属于本文分析，并非 GitHub 公布的客户案例。
两条更新，分别改变了什么
第一条更新是 computer use。在 macOS 和 Windows 上，Copilot CLI 与 Copilot 应用可以读取应用的可访问内容和视觉上下文，进行点击、输入、滚动等操作，覆盖缺少 API、CLI 或 MCP 接口的旧软件。[1]
不过，GitHub 文档也明确建议：如果直接接口或专用工具能完成任务，它们通常能提供更结构化的信息和更可预测的结果。[3] 因而在产品选型时，值得问的是“哪一段流程必须操作界面”，而不是把整条流程都变成模拟鼠标操作。
第二条更新是 dynamic workflows。工作流以程序定义步骤、调用 Agent 的时机和结果用法；Agent 处理需要分析或判断的部分。它支持串并行任务、结构化结果传递和人工检查点，覆盖 Copilot CLI、应用与 SDK，公告称所有 Copilot 计划均可使用。CLI 需要启用 experimental，应用端无需额外设置。[2]
两者提供了互补的设计方向，但当前资料不能证明任意桌面业务都已被两项能力自动打通。具体组合仍需开发、测试和验收。
从一条客户跟进流程开始
假设销售运营每天要处理客户邮件：提取跟进事项，与客户台账核对，再把记录写入一个没有开放接口的旧 CRM。
第一版可以限定为：只给已有客户创建待审核的跟进记录，正式提交由业务人员完成。 这样就有了清晰的任务终点，也便于判断 Agent 是否真的完成了工作。
流程可以拆成六步：
读取指定邮件 → 提取事项并标明原文依据 → 按客户编号匹配台账 → 生成待审核内容 → 在旧 CRM 保存草稿 → 重新读取并核对结果。
这里至少有三种不同的执行方式：
环节 主要承担者 通过条件 邮件、客户编号与重复记录检查 代码或直接接口 对象唯一、字段完整、没有重复 跟进事项提取与摘要 Agent 结论有原文依据，不确定项显式列出 旧 CRM 填写与保存 桌面操作 目标客户正确，保存后能够回读核对
“总结得很像”不能替代客户编号校验。匹配出两个同名客户，就暂停让人选择；邮件没有说到的信息，就保留缺失，而不是靠模型补齐。
这种拆分让模型的判断能力用在语言理解上，也让业务系统继续负责它擅长的身份、规则和记录管理。
授权界面，要同时表达应用和业务动作
GitHub 的最新文档对桌面权限有一个值得注意的细节：是否弹出应用审批，受当前产品的工具权限设置影响。“始终允许”的决定保存在本地，在同一电脑的 CLI 与应用之间共享；删除它只影响未来会话，不会撤销运行中会话已获得的访问。[3]
这意味着，产品设计不能把一个“允许控制 CRM”的开关当作所有业务操作的授权。
在上述场景里，读取客户信息、保存待审核记录、正式提交记录，是三个不同的业务动作。界面应该让用户知道本次任务将处理哪些邮件、影响哪些客户、允许推进到哪一步，以及什么时候会停下来。
我的建议是：常规读取和已批准范围内的填写可以连续执行；出现客户匹配冲突、输入范围变化，或即将越过原定业务终点时，再请人处理。审批应尽量发生在用户看得见具体对象和结果的位置，避免每次点击都让人点一次“同意”。
检查点之后，还要设计结果未知的状态
动态工作流文档说明，暂停的任务可以继续，已经保存的完成步骤和子 Agent 结果能够复用；尚未保存的工作可能需要重跑。[4] 这有助于减少重复工作，但业务系统里的副作用仍需要单独处理。
回到最初的问题：Agent 点了“保存”，界面卡住了。
此时至少存在两种可能：请求根本没成功，或者服务端已经保存，只是反馈没有显示出来。如果系统把两种情况都归为“失败，重试”，就可能创建第二条相同记录。
因此，我建议在需求里明确区分三种结果：已确认成功、已确认未执行、结果未知。 对于结果未知的写入，先查询目标系统，核对客户编号、来源邮件和实际记录；仍无法确定时交给人，不直接再次点击。
如果目标系统支持幂等键，可以用同一业务标识约束重复提交。如果旧 CRM 没有这类能力，产品就需要查询去重和人工核对路径，也不能承诺绝对不会重复。
一个最小可行的检查点应保留：当前业务对象、输入版本、已经确认完成的步骤、待核对的写入，以及下一步允许执行的动作。用户回来后应能看懂“为什么停在这里”，而不必从整段聊天里重新拼出过程。
还有一个容易忽略的变化：续跑时，原来的输入可能已经过期。 客户台账被修改，邮件又有了补充，旧摘要未必仍然适用。恢复前应检查相关输入是否变化；有变化就重新核对受影响的步骤。
这些是业务产品需要补上的规则。工作流提供暂停与续跑能力，并不意味着已经保存到外部软件里的记录能够自动回滚。
动态工作流支持并行 Agent，但并不是每个步骤都适合并行。邮件摘要和独立规则检索可以同时做；向 CRM 写入之前，必须等客户匹配、内容核验和权限判断都完成。
把日常想法变成可以使用的成果
图 1从零散想法到具体成果的协作场景配图见原文
当你需要写文章、读资料、做表格，或者把一个想法做成小工具时，dot 可以参与这些工作的多个环节。你说明目标并提供材料，它协助组织内容、执行任务、生成文件，再根据你的反馈继续修改。在 Codex/ChatGPT 的工作场景里，你可以把它当作一个用自然语言交流的 AI 工作伙伴。
它能承担哪些事，取决于当前可用的工具、已连接的应用，以及你提供的材料和访问权限。理解这一点，就能把任务交代得更准确：说清最终要拿到什么，也告诉它怎样才算完成。
从一个具体任务开始
比如，你手里有一份访谈纪要，需要做成新员工能看懂的指南。你可以直接要求 dot 提炼重点、调整措辞、补上说明图，并交付可编辑的 Word。拿到初稿后，再指出哪些内容需要展开，哪些表达需要更贴近读者。一次对话，就可以围绕同一份成果持续推进。
把想法写成可以交付的文档
很多写作任务最费力的地方，是把脑海里的想法整理成别人读得懂的内容。dot 可以从零散笔记中提取主线，安排段落，再根据用途调整语气。产品介绍需要具体，项目复盘需要讲清问题和结果，新人指南则需要照顾读者的背景。
在支持文件生成和图像工具的环境里，你还可以要求它排成 Word、制作配图、统一图注。提出要求时，把文章的读者、长度和文件格式一并说清，得到的结果会更接近你真正要用的版本。
可以这样说请把这份访谈纪要整理成面向新员工的入门指南，配两张说明图，交付可编辑的 Word。保留关键事实，语言易懂，步骤要能照着执行。
把搜集来的资料整理成判断依据
当你需要选工具、了解一个行业或准备会议时，可以让 dot 先列出要回答的问题，再围绕问题整理材料。如果当前环境支持网页搜索，它可以查找资料、比较不同来源，并给出便于核对的链接。你也可以直接提供 PDF、网页或笔记，让它从这些材料中提取重点。
一份有用的研究结果，应当说明依据来自哪里、信息是什么时候的，以及哪些结论仍有不确定性。让 dot 按统一标准比较几个选项，你就更容易看清差异，并决定下一步还要补查什么。
可以这样说请比较这三款项目管理工具，优先查官网，按功能、适用团队和限制整理对照表。附来源链接和查询日期，并说明哪些信息还需要确认。
图 2一次完整协作需要清楚的目标和可核对的成果配图见原文
把表格变成看得懂的分析
一张表格可能记录了很多数据，却没有直接回答你的问题。提供工作簿后，你可以让 dot 检查缺失项、统一格式、按月份或类别汇总，再用公式和图表呈现变化。最有价值的部分，是把分析和业务问题连起来：哪个产品退货较多，哪段时间出现异常，接下来应该查看哪些记录。
可以这样说请分析我上传的销售明细，按月份和产品汇总收入与退货率，添加公式和图表，交付 Excel。保留原始数据，注明统计口径，并核对计算结果。
把同一份材料做成不同的成果
一份季度复盘可以写成报告，也可以做成汇报演示稿。dot 可以根据听众调整重点，安排页面顺序，提炼标题，并建议哪些信息适合用图表表达。在支持演示文稿工具时，还可以继续生成可编辑的文件。你提供真实数据和品牌素材，它据此制作，你再核对结论、数字和表达。
可以这样说请根据这些季度复盘材料制作 8 页汇报演示稿，讲清目标、结果、偏差和下一步。图表与原始数据一致，交付可编辑文件，并附逐页讲稿。
图 3根据使用场景选择文档 表格或演示文稿配图见原文
把一个想法做成可以试用的工具
借助 Codex 的代码工作能力，你可以让 dot 制作活动报名页、个人作品展示页，或一个批量整理文件的小脚本。先做出能运行的版本，再测试按钮、检查手机上的显示、调整交互。对于已有项目，也可以让它阅读代码、定位问题和修改实现。涉及实际提交数据或上线时，需要另行安排服务和发布步骤。
可以这样说请把这份活动报名需求做成可本地预览的网站原型，包含首页、报名表单和成功状态。手机上易读，按钮反馈清楚，附运行说明。
跟进需要反复查看的事情
有些任务需要隔一段时间重新检查，比如项目进度、待办变化，或某个页面是否出现新信息。在支持自动化的环境中，你可以把检查频率、资料范围和提醒条件说清楚，让 dot 按约定进行跟进。只有定时任务实际创建后，后续检查和提醒才会按设定运行；执行时也需要能够访问所需资料。
可以这样说请每周核对我提供的三个项目的进度记录，更新待办、负责人和截止日。只在有实质进展或需要我行动时提醒，并说明依据与下一步。请先确认定时任务已创建。
把任务交代清楚的几个要点
你不需要学习一套复杂的提示词。先说明想解决的问题，再提供它要用的材料，最后描述成果的样子。比如，“帮我写一下”还缺少方向；“根据这份产品资料，写一篇面向新用户的介绍，控制在 1500 字以内，配两张说明图，交付 Word”，就给出了清楚的工作目标。
你也可以把质量要求写进去：数字要能核对，研究要附来源，代码要可以运行，文档要可以继续编辑。如果关键信息确实缺失，要求它先提问；如果只是版式或措辞等可以调整的选择，可以让它先完成初稿。
你来决定成果是否适合使用
dot 能协助完成大量整理和制作工作，但你最了解任务的背景、受众与真实目的。核对关键事实和计算结果，试用生成的工具，再提出具体反馈。例如，“把第二段改得更适合初学者”“这张图要解释流程”“请说明这条建议的依据”，都能推动下一轮修改。
开始使用 dot，可以从今天手头的一件事入手：一份迟迟没写完的文档，一张需要重新整理的表格，或者一个反复手动处理的小脚本。把材料交给它，说明你希望拿到的成果。随着反馈越来越具体，这种协作会更贴近你的工作方式。
一、引言
最近看到一段律师讨论助贷刑事案件的视频。视频里提到了不少我们在消费金融、助贷业务里经常听到的词： 0 首付分期购车、AB 贷、包装贷、信用修复、企业信用贷等。但真正让我觉得有意思的，并不是这些业务名称本身。而是视频里反复体现出来的一种处理复杂问题的方法：
不要看到“助贷公司”三个字，就把公司里所有业务、所有员工、所有行为放进同一个框里。
面对一个几百人的案件，真正需要做的是一层一层拆。哪些业务出了问题？一个人到底参与了什么业务？他是普通员工、组长、主管，还是老板、股东？有没有实际管理权限？做了多少笔业务？本人或者公司到底获得了多少收益？这些问题拆开以后，原本看起来非常混乱的一件事，才开始变得可以分析。而这套思路，对今天做银行 AI 产品的人，其实也很值得借鉴。
二、视频里最值得注意的，不只是“哪些业务有风险”
视频一开始提到，这是一个涉及 300 多人的案件，并谈到包括 0 首付分期购车等业务，以及深圳等地已经出现相关案件处理。后面又陆续提到几个关键词：AB 贷、包装贷、信用修复、线上企业信用贷。如果只是截取这些词，很容易产生一个简单的印象：
助贷业务风险很高。
但视频后面的讨论，其实恰恰是在避免这种过度简单化。因为一家助贷公司可能同时存在多种业务。不同业务的具体操作方式不同；不同员工接触的业务不同；即使属于同一家公司，每个人参与的程度也完全不同。所以视频里有一个很重要的思路：先把业务拆开。
图 1｜我理解的视频分析逻辑配图见原文
这看起来只是刑事案件里的分析方式。
但我觉得这里已经出现了第一个对 AI 产品经理很有价值的提醒：
复杂业务问题，不能先让 AI 下结论，而应该先让 AI 帮我们把问题拆对。
三、同一家公司的人，不能因为一个标签就被看成同一种角色
视频后半段花了不少时间讨论公司内部不同人员。里面明显区分了几个层次：普通基层员工；组长、小队长；主管、区长等管理岗位；再往上是公司的老板、股东等。视频里特别提到，基层员工、具有一定管理职能的组长，以及更高层管理人员，所需要讨论的问题并不相同。这其实是一个非常容易被忽略的问题。如果系统里只保留一个字段：
所属公司：某助贷公司
那么 AI 很容易得到一种粗糙的关联：
某公司存在问题 → 这个公司的人都有高风险。
但现实不是这么简单。同样在一家企业里：一个人可能只是做执行工作；另一个人可能负责带团队；再往上的人可能参与业务设计、管理甚至利益分配。组织关系是一回事，实际行为又是另一回事。
图 2｜视频反复强调的“人员分层”配图见原文
视频里有一句话给我的感觉特别明显：
不能只看职位名称。即使一个人在公司里有某个身份，也还要继续追问：他到底做了什么？有没有真的管理？参与到什么程度？这恰恰也是 AI 系统很容易犯的错误。
四、第一个 AI 产品启发：少做“标签判断”，多做“事实拆解”
现在很多 AI 产品都喜欢输出一个非常漂亮的结果：高风险、中风险、低风险；或者：疑似异常。这当然很方便。但看完这个视频以后，我反而觉得，在金融这样的复杂场景里，AI 最重要的能力未必是快速生成一个标签。可能更重要的是：
把形成这个标签之前的事实拆出来。
比如不要直接告诉银行员工：
某客户 / 某企业 / 某合作机构存在较高风险。
而是先帮助人看清楚：涉及什么业务？发生了什么行为？这个行为是谁完成的？这个人的角色是什么？他有没有管理其他人？有没有对应的交易、业务或者获利？这样人才能继续判断。
表 1｜两种 AI 思路的区别
思路 AI 在做什么 最终看到的内容 标签式判断 根据大量信息直接给分类结果 “高风险”“异常”“疑似问题” 事实拆解 把业务、人员、行为、关系分别整理出来 谁、在什么业务里、做了什么、产生了什么结果
如果是普通互联网推荐，“直接给结果”可能很好用。
但金融、法律、合规场景不一样。
因为这里经常会继续追问一句：
为什么？
所以一个结论后面有没有足够清晰的事实结构，可能比结论本身更加重要。
五、第二个启发：AI 不能把“相关性”直接当成“责任”
视频里让我比较有感触的第二点，是它一直在区分：
身份、职位、行为和责任。
比如一个人是“组长”，不意味着分析就结束了。还需要继续看：他究竟多了什么管理职能？是否真的管理别人？做过哪些具体行为？而对于更高层人员，还需要进一步讨论他的实际角色。
这一点其实非常像今天 AI 风险识别里常见的问题：
AI 很擅长找关联。但：
有关联，不代表可以直接得到最终结论。
例如一个主体与某个风险机构存在联系；一个员工属于某个出现问题的团队；一笔业务来自某个异常渠道。这些都可以成为风险线索。但“存在风险线索”和“已经能够认定问题”，并不是一回事。对银行 AI 产品来说，我觉得这是一个非常重要的边界：
AI 可以负责把关系找出来，但不应该偷偷替人完成从“关系”到“定性”的跨越。
AI 可以告诉使用者：
这个人与哪个公司有关；这个人参与过哪些业务；这个客户从哪个渠道进入；不同材料之间有哪些关系。但最终这些关系意味着什么，应该保留足够的依据和人工判断空间。
六、第三个启发：越复杂的业务，越应该“先拆再算”
视频到了后面，又开始讨论一个非常具体的问题：
获利金额。
包括：公司到底取得了多少实际收入；不同业务应该怎么区分；一个人做了多少笔业务；他的实际获利应该怎么对应。这个部分其实非常有产品感。因为它不是在讨论一个抽象的“这个人坏不坏”。而是在不断把问题往可验证的数据上落：
你具体做了什么？
做了多少？
对应哪部分业务？
实际产生了多少金额？
这也是我觉得银行 AI 产品经理可以借鉴的一点：
不要让 AI 一上来就做一个巨大的综合判断。
引言
最近在自己动手做 Agent 的过程中，我一直有一个很朴素的判断标准：流程能不能跑通、结果对不对。如果输入一条客户信息，Agent 最后能按照预期完成分析、调用工具并给出结果，我就会觉得这个 Agent 基本做成了。直到我开始读美团的《Agent评测漫谈》，才意识到这个判断其实只回答了一个很表面的问题——这一次，它做对了吗？但一个真正要投入使用的 Agent，显然不能靠“这一次跑通了”来证明自己可靠。它为什么做对？换一批数据还能不能做对？如果做错了，到底是模型理解错了、Prompt 写得不好、知识库没有召回，还是工具调用和业务流程出了问题？如果这些问题都看不见，那么所谓的优化，很容易变成不断改 Prompt、不断重新测试，却不知道自己究竟在解决什么。所以这次我想以一个 AI 产品经理的视角，把美团这篇 Agent 评测文章重新拆一遍。不是复述里面有多少评测指标和专业名词，而是试着弄明白一个更基础的问题：当我们做出一个 Agent 之后，到底该怎么判断它是真的“能用”，而不只是“能跑”？
1. Agent 评测是什么？
Agent 评测，是通过一套可重复的测试标准，判断 Agent 能不能稳定完成任务，并进一步定位它在哪个环节出了问题，从而指导后续迭代。它评测的不只是模型最后“回答对不对”，而是整个 模型 + Prompt + 工具 + 工作流 + 业务规则组成的 Agent 系统。美团也强调，评测的核心是回答“Agent 好不好、到底哪里好哪里不好”，并据此指导下一轮迭代。他们甚至得出了Agent的研发公式：持续迭代=观测 + 评测
2. Agent 评测发生在什么场景？
原文此处为电子表格，可通过原文入口查看。
Agent 开发的四个典型困境
① 不知道“好不好”
Agent 跑出来一个答案：
看起来不错但“不错”到底是什么意思？
没有明确标准。
② 不知道“哪里不好”
例如客户分配错了。
可能是：
信息抽取错 ↓ 行业识别错 ↓ 候选池筛选错 ↓ Ranking 错 ↓ 模型理由生成错如果只看到最终结果，就不知道问题发生在哪里。
③ 不知道“改完有没有真的变好”
比如你发现一个问题：
DeepSeek 把“AI产品经理”行业识别错了于是修改 Prompt。
这个 Case 修好了。
但可能：
Case A 修好了 同时 Case B Case C Case D 又被改坏了这就是为什么需要：
Regression Test = 回归测试
④ Demo 能跑 ≠ 生产环境稳定
一次跑通只能证明：这一次成功了。
不能证明：换 100 个用户还能稳定成功。
美团文章也特别指出，Agent 不能只看一次 Demo，因为真正的评测必须服务于研发、上线、回归和规模化落地。
3. 产品要提供什么能力？
基于上述场景，可以将 Agent 落地过程中的核心问题归纳为：难衡量、难定位、难统一、难回归、难稳定。因此，评测产品需要针对这些问题建立对应的产品能力与衡量指标。
原文此处为电子表格，可通过原文入口查看。
4. Agent 评测为什么不能只看最终答案？
从传统机器学习、大模型到 Agent，真正发生变化的不是“评测越来越复杂”，而是评测对象发生了变化。
Agent 评测的三次认知升级：
当 Agent 从单纯“回答问题”升级为“执行任务”后，只看最终答案是否正确已经不够。一次成功的结果，可能来自稳定的规划与执行，也可能只是经过多次试错后的偶然命中。因此，Agent 评测需要从单一结果判断，进一步扩展到结果、过程、效率和风险四个层面，才能更完整地判断一个 Agent 是否真正具备上线和规模化能力。美团也明确指出，只看最终结果会掩盖执行路径、成本和安全上的差异。
原文此处为电子表格，可通过原文入口查看。
这四层并不是彼此独立的，而是一层一层递进的：结果层回答“事情做成了吗”，过程层回答“是不是稳定做成的”，效率层回答“是不是以可接受的成本做成的”，风险层回答“是不是在安全、合规的前提下做成的”。对 AI 产品经理来说，真正成熟的 Agent，不应该只是“能完成任务”，而应该做到正确、稳定、高效、安全地完成任务。
1. 能力和业务结果之间的鸿沟
模型能力指标和业务结果指标之间存在天然鸿沟。所以中间必须建立一层“桥梁指标”
模型变聪明了不代表业务一定变好了，中间缺了一层：这个模型能力提升，有没有真正让任务完成得更好？
2. 用美团原文的 AI 搜索例子理解
原文用了 AI 搜索。
业务最终关心：
DAU 留存 点击但是你不能直接说：
模型准确率提高5% ↓ 所以DAU提高中间没有因果解释。
应该拆成：
模型 / Agent能力 ↓ 意图识别更准确 检索更有效 结果整合更可信 ↓ 搜索任务体验提升 ↓ 用户更愿意继续使用 ↓ 留存 / 点击 / DAU变化美团强调，只有把这些层次真正串起来，才能解释“为什么业务指标变差”，以及为什么有时候“模型变强了，业务却没有收益”。
3. badcase
比如一个客服 Agent。
团队汇报：
模型准确率：95% 知识库召回率：90% 工具调用成功率：98%全部很好看。
但是：
用户问题解决率：60%那这个 Agent 依然可能不好用。因为：局部指标好，不等于整体任务完成得好。所以美团才会说：评测体系的核心不是堆很多指标，而是让指标之间存在解释关系。
一、引言
过去一段时间具身智能给人的感受越来越快了，从今年宇树科技人形机器人在春节上大放异彩，到机器人开始学会抓东西、叠衣服，甚至能给你炒一盘麻婆豆腐，通用的大模型也逐渐展现出自己细节的一面——控制机械臂、理解空间关系和执行稍微复杂的指令。单看这一些demo的话，很容易就会形成一种主观感受：机器人是不是离真实世界只剩下时间问题了？外滩大会具身智能讨论会后，反而觉得事情好像不像我们想象中的那么简单。几位大佬把争议放在了数据、智能和场景三个方向，恰好三个方向都在指向一个问题：一个机器人小概率把事情做好和长期在现实世界工作中间还差什么？
二、我如何理解具身智能在当前阶段的问题
机器人面对的不是一个静态的数字世界。在我们生活的真实世界中，能够细微的感觉到环境的变化、物体的重量、材质的差异，有接触也有碰撞。模型在理解“嘿！把那个杯子递给我！”这句话的时候，真正执行的不只是把杯子交到你手上这么简单的步骤。这类似于“把大象放进冰箱”，他需要知道杯子在哪里，应该从哪个角度抓起来（总不能拎着杯口就给我拿过来吧），力度是否合适，万一把我的杯子捏碎了怎么办，以及拿不起来该怎么调整？也就是说，理解问题只是很小的一部分，所有链路拆开在细分到每一个步骤中的话，好像具身智能还有很长的路要走。这改变了我看待具身智能的方式。我现在更关心的不是什么模型又做了多少事情，好像单独拆开来，我们什么都能做，而是要把感知、理解、行动、反馈和修正真正闭环起来，我们还得看他的工作链路是否够稳定、够泛化，他还得足够便宜。也正是在这个前提下，再去看这场辩论中的数据之争、智能之争和场景之争，很多看似分散的问题才开始串在了一起。
三、几场争论，其实都在争同一件事
数据之争询问机器人靠什么认识世界的问题，仿真or显示；智能之争想解决模型理解以后能不能真的处理物理世界？场景之争想把这些能力变成稳定、低成本的生产力。好像大家表面上都在争技术路线，但是背后都是具身智能怎么才能越过“能做”到“能用”这一个关键的节点。
1.先从数据讲起：机器人该从哪里认识世界？真实世界采集数据太慢，成本也高，会受到场地、设备，人工的限制。从这个角度看，仿真似乎是绕不开的。
韩征提到：“他们过去几年一直在重构数据和模拟器管线，希望通过大规模仿真支撑预训练和强化学习”这条线本质上解决的是真实世界数据难以规模化，能不能在仿真世界中先练成熟？但是另一边的问题也很现实：机器人最终不是生活在模拟器中，他需要在生活中和和人交互，和环境交互，外面是不是下雨了，我今天心情怎么样？摄像头有噪声，触觉传感器不稳定等等问题很难在仿真环境下模拟出来。
沈宇军提到：“一个我觉得很有意思的概念：大家过去总在讨论 Sim to Real，也就是怎么把仿真里的能力迁移到现实，但真正困难的可能还有 Real to Sim——我们能不能把现实世界里这些复杂、甚至“不完美”的东西，规模化地搬进仿真。尤其是触觉这样的信号，真实传感器里的频率、幅值和一致性，与模拟器里的结果可能存在很大差别。”
听到这里我反而觉得这个问题有点过于简单，大佬背后真正想问的应该是什么样的信息能够直接影响机器人把事情做成？如果模型只是看到了一个桃子，它会认识桃子的外形，但他不知道桃子是硬的还是软的，他不知道该用多大力帮我拿过来。如果仿真能够把这些真正影响动作结果的因素保留下来，那它同样有很大的价值。所以数据之争在我看来，最后并不是“真”和“假”的选择，而是哪些数据真正有用，以及这些有用的信息能不能被规模化获得。
2.再说智能之争：由于GPT-6的发布最近通用大模型开始直接控制机械臂、灵巧手等硬件了，第一反应是既然大模型已经那么强了，那具身智能公司是不是迟早被降维打击？
王谦在现场说了一句话让我印象很深：“今天智能的本体是存在于数据里面的，模型更多是一个蒸馏器和容器。”这说明大模型的能力不是凭空出现的，他背后一定是经过了海量的数据验证和训练体系，就像大模型不会突然就能够控制机械臂。其实这个观点改变了我长期以往的想法：模型足够强，他就能够做足够多的事情，到了终极形态他就能顺手解决我所有问题了。但如果 Coding 的进步需要 Coding 数据，数学能力需要数学数据，那机器人对真实世界的操作能力，很可能也需要属于它自己的数据和训练过程。通用大模型可以带来更好的理解和推理，但这不意味着它能够直接跳过物理世界这门课。
所以我把这件事情理解为：模型能看懂世界但他能碰撞世界吗？如前文所提，模型知道桌上放着一个杯子，也知道任务是“把杯子递给我”，但它未必知道这是一个很薄的玻璃杯，还是一个结实的塑料杯。前者抓得太重可能会碎，后者抓得太轻又可能在移动过程中滑落。更麻烦的是，杯子里如果还装着水，抓取位置、移动速度甚至手腕姿态都可能要跟着变化。现实世界不是一道只有文字和图片的题，机器人每做一个动作，环境都会给它新的反馈，而这些反馈又会改变下一步的判断。也正因为这样，我不太觉得通用大模型和具身模型最后一定是谁取代谁，它们更可能形成分工：上层负责理解、推理和规划，底层负责感知、动作和持续处理物理世界里的变化。
3.最后的场景之争：到了这一层面的话问题好像突然变得现实了很多，学会以后有没有人愿意用？
这一点我很认同王谦现场提到的标准：“如果非得说一个指标的话，那就是客户能够可持续地付钱，并且这个付钱越来越多。”我们从人工智能发展到今天看过了太多的demo了，机器人会炒菜，会叠衣服，会搬东西，但是一次成功的演示到真正进入生产环境之间还有很大的差距。商业化以后客户到底是因为他偶尔能完成这个任务的新鲜感买单还是为了他能够稳定输出而付费？
