夜雨聆风
标题备选
- 1. 别再把 AI 工具做成一个聊天框
- 2. 客户问谁负责时，聊天框回答不了
- 3. AI 接进业务后，最该补的是这张交接表
- 4. 你的 AI 看起来很聪明，为什么一验收就露馅
- 5. 小团队上 AI，别只盯模型，先盯权限和交接
摘要
Google 最近讲了 A2UI 和 MCP Apps 的结合，技术细节很多。小团队真正该借走的不是名词，而是一个提醒：AI 进入销售、客服、内容和交付流程后，界面不能只剩聊天框。客户要验收，老板要追责，团队要交接，系统就必须把权限、账号、数据和责任边界摆在台面上。
正文
上周我陪一个客户验收 AI 客服流程，项目群里刚发完演示视频，老板就追了一句：
“这个退款口径，是谁批准让 AI 这么回的？”
我当场把后台打开，想从聊天记录里往回查。结果越查越尴尬。
客服同事说，这是之前训练资料里的话术。
运营同事说，知识库是她上传的，但退款规则不是她定的。
技术同事说，AI 只是调用了客服系统接口，权限本来就开着。
老板接着问我：“那客户真退了钱，算谁的？”
这个问题，聊天框答不上来。
很多团队现在接 AI，第一反应是做一个对话窗口。客户问一句，AI 回一句。员工输入一句，AI 出一个方案。Demo 看起来很顺，截图也好看。
可一进真实业务，问题马上变了。
谁能让 AI 读取客户资料？
谁能让 AI 改订单状态？
谁能让 AI 发出承诺？
谁能修改它用的知识库？
谁在客户投诉时负责解释这一次回答？
这些不是模型能力问题，是交付系统问题。
Google Developers Blog 最近发了一篇文章，讲 A2UI 和 MCP Apps 怎么结合。它提到一个方向：MCP server 不一定只返回文本，也不一定每次都塞一个完整 Web App。它可以返回 application/a2ui+json 这种结构化 UI，让宿主应用用自己的方式渲染卡片、表单、步骤和操作界面。
技术细节不用急着追。对小团队老板来说，真正有价值的提醒是：AI 不是只有聊天这一种界面。
聊天框适合演示理解能力。
业务现场需要的是可操作、可复查、可交接的界面。
我后来让客户停掉了“让 AI 自动处理退款”的演示，先补了一张很土的表。
表里只有五列：动作、所需数据、允许角色、确认方式、责任人。
比如“给客户承诺退款”，所需数据是订单号、付款记录、服务交付状态和历史沟通。允许角色不是 AI，也不是所有客服，而是客服主管确认后由客服执行。确认方式是工单里点选退款原因，系统保留审批记录。责任人写到具体岗位，不写“系统自动”。
再比如“修改客户标签”，AI 可以建议，但不能直接写回 CRM。它只能把建议放在客户卡片旁边，由运营确认。确认后谁改的、什么时候改的、引用了哪条对话，都要留下记录。
这张表一点也不酷。
但客户看完反而松了一口气。因为他终于知道，AI 接进来以后，每个动作卡在哪里，谁有权点下去，出了问题找谁。
很多老板现在对 AI 的焦虑，不是它不够聪明。
是它太像一个随时能越界的员工。
销售想让它跟进客户，它可能替销售承诺优惠。
客服想让它减少重复回复，它可能把未确认的补偿方案发出去。
内容团队想让它批量出稿，它可能把内部案例写成公开素材。
交付团队想让它整理项目资料，它可能把客户 A 的流程迁移到客户 B 的方案里。
这些问题如果只在聊天框里发生，追责会非常痛苦。你只能翻一段一段对话，猜它当时读了什么资料，猜谁给了它权限，猜哪个员工把错误信息喂了进去。
所以，AI 界面真正要解决的，不只是“怎么让用户更好看”。
它要帮团队把业务动作拆开。
能读什么，界面上要写清楚。
能改什么，按钮上要有边界。
需要谁确认，流程里要卡住。
出了结果，记录里要能回放。
我更愿意把这种界面叫做“交接界面”。
它不是给 AI 展示才华的舞台，是给团队交接责任的桌面。
你可以把它想成一个客户卡片。
左边是客户原始信息，哪些字段来自 CRM，哪些字段来自聊天记录，哪些字段是员工补录。
中间是 AI 建议，建议跟进什么、引用了哪条证据、信心为什么够或不够。
右边是人工动作，确认发送、改标签、建工单、升级主管、放弃跟进。
底部是日志，谁点了确认，谁改了规则，AI 当时调用了哪个工具，结果写回了哪里。
这样的东西，当然没有一个万能聊天框省事。
但它更像业务。
因为老板追责时，问的从来不是“模型当时怎么想”。老板问的是：谁让它这么做，谁看过，谁承担。
这也是我看 A2UI 和 MCP 这类方向时最关注的地方。它们背后透露出来的趋势，不是把界面做得更花，而是让 agent 的能力从“说话”走向“可控动作”。
MCP 负责连接工具和数据，A2UI 这类结构化界面负责把动作摆出来。对小团队来说，不需要马上照着技术架构重做系统，但可以马上改自己的 AI 落地方式。
别再只问：
“这个 AI 能不能自动回复？”
要改问：
“它回复前看了哪些资料？”
“它能不能触碰客户资产？”
“哪一步必须人工确认？”
“确认记录在哪里？”
“客户投诉时，谁能在五分钟内复盘？”
我见过很多 AI 项目，前期都死在一个小地方。
老板买工具时，以为买的是效率。
员工使用时，以为用的是助手。
客户验收时，看到的却是一套没有边界的承诺机器。
这中间少的不是一个更强模型，而是一张交接表、一套权限按钮、一份日志记录。
如果你现在已经把 AI 接进销售、客服、内容或交付流程，可以今天就做一次检查。
找一个真实客户动作，不要找内部测试。
比如改客户标签、发送报价、承诺交付时间、处理退款、导出客户名单、发布一篇内容。
然后沿着这个动作往回问五件事：
一，AI 用了哪些数据。
二，谁给了它这些数据。
三，它能不能直接改业务结果。
四，哪一步有人确认。
五，出错以后谁能复盘完整过程。
这五个问题答不清，先别急着加模型、加 API、加自动化。
先把界面从聊天框改成业务桌面。
让每一次 AI 动作都有入口、有边界、有确认、有日志、有责任人。
AI 真正进入业务，不是从它会说漂亮话开始。
是从客户追责那一刻，你能打开后台，把每一步交代清楚开始。
配图锚点
- 1. 封面图：办公室项目群大屏，老板追问 AI 客服退款责任，桌面上有权限表和后台界面，氛围紧张但不恐吓。
- 2. 首屏图：我打开客服后台和聊天记录，三位同事分别指向知识库、接口权限、退款工单，突出责任不清。
- 3. 正文图一：一张五列表格，列名为动作、所需数据、允许角色、确认方式、责任人，表里有退款、改标签、发报价三个业务动作。
- 4. 正文图二：客户卡片式业务桌面，左侧数据来源，中间 AI 建议，右侧人工确认按钮，底部操作日志。
- 5. 结尾图：老板在验收会上看一条 AI 动作回放链路，从客户问题到工具调用、人工确认、结果写回。
来源清单
- 1. Google Developers Blog, “A2UI + MCP Apps: Combining the best of declarative and custom agentic UIs”, 2026-06-17, https://developers.googleblog.com/a2ui-and-mcp-apps/
- 2. 父任务来源包 WX10-20260620-04, 本地文件：wx10-20260620-source-packet.md
给 Sophia 的配图 brief
主题：AI 从聊天框进入业务交付系统，重点画权限、交接、责任和后台复盘。
视觉风格：真实小团队办公室，不要科幻机器人，不要黑客攻击氛围。用项目群、客服后台、CRM 卡片、工单、权限表这些业务物件表达冲突。
必须出现的元素：客户聊天记录、退款工单、权限表、责任人字段、人工确认按钮、操作日志。
避免：数据泄露恐吓画面、红色警报、锁链、机器人统治人类、夸张的网络安全视觉。
给 Athena 的发布说明
文章定位：技术信号转业务管理稿。来源是 Google A2UI + MCP Apps 官方文章，但正文不写技术教程，重点落在小团队 AI 接入后的权限、账号、数据和责任边界。
事实边界：只引用 Google 文章中的 A2UI、MCP Apps、application/a2ui+json、结构化 UI 与宿主渲染方向。不宣称 Google 已定义行业标准，不宣称聊天框会消失，不涉及政策条款。
发布前检查：标题可在 1、2、3 中选一个；正文无破折号；禁用句式已避开；若需要配图，优先画“后台权限和交接表”，不要画抽象 AI 大脑。
我是大熊
我是大熊，长期陪小团队做 AI 落地、Agent 工作流和训练营交付。
如果你现在也在卡这几件事：客户从哪里来、加微信后怎么承接、训练营 SOP 怎么跑、AI 怎么真正用进业务里，可以加我微信聊聊。
备注：AI落地
