即刻App年轻人的同好社区
下载
周初因为某个用户的流失，心痛不已，焦躁不安。
挑了些在用的用户断断续续做了 1 on 1，看着 ta 们分享的使用场景，觉得我们产品还是挺牛逼的，周中又豁然开朗，想得瑟。
所以焦虑的本质原因是不具体：
1. 不具体地知道发生了什么事
2. 不具体谁遇到了什么问题
3. 不具体方向该往哪走
挑了些在用的用户断断续续做了 1 on 1，看着 ta 们分享的使用场景，觉得我们产品还是挺牛逼的，周中又豁然开朗，想得瑟。
所以焦虑的本质原因是不具体：
1. 不具体地知道发生了什么事
2. 不具体谁遇到了什么问题
3. 不具体方向该往哪走
11 02
公众印象里的武汉人民过早挺潇洒豪迈的，蹲在马路牙，支个小板凳，管它三七二十一，一顿炫。
而我作为非典型湖北人，其实小时候特别痛苦，以至于很不喜欢吃早餐。因为无论是店家的环境还是大家的默契，都只能要么端在手里边走边吃，要么就在店家门口坐小板凳面朝街边吃。
对于我们“i人”来说，这不亚于公众表演节目。
那时车马很慢，没有手机可刷，马路对面来来往往的行人眼神也没有如今这么涣散，对着他们吃面，总给我一种下一秒就要凑过来的错觉。
当然，你可能会问那为什么不打包带回家吃。因为怕坨啊。
而我作为非典型湖北人，其实小时候特别痛苦，以至于很不喜欢吃早餐。因为无论是店家的环境还是大家的默契，都只能要么端在手里边走边吃，要么就在店家门口坐小板凳面朝街边吃。
对于我们“i人”来说，这不亚于公众表演节目。
那时车马很慢，没有手机可刷，马路对面来来往往的行人眼神也没有如今这么涣散，对着他们吃面，总给我一种下一秒就要凑过来的错觉。
当然，你可能会问那为什么不打包带回家吃。因为怕坨啊。
11 135
Sierra 是垂类 Agent 的代表公司，很多人知道它是商业模式比较有代表性：outcome-based pricing，也就是按结果付费。
意思是 B 端客户使用了 Sierra 作为 AI 客服，如果进线的会话被 Agent 端到端 resolved 了而没有转人工，就意味着 Agent 产生了价值，要计费。反之只要人工介入了，本次会话就不收费。
我好奇的是 Sierra 如何定义 resolved，以及具体的实施流程是怎样的，于是从官网 book a demo，然后 Sales 带着我端到端体验了一把客户视角的 outcome-based pricing。
我一开始以为会先看产品 demo，结果真正有价值的部分反而在 demo 前面。他们需要先知道我的客服规模、主要渠道、ticket volume、现在的 automation rate、平均处理时长、转人工比例、CSAT、用什么 CRM / contact center / 订单系统，以及最想先自动化哪几类问题。
这个流程不是传统那种“我给你一个 AI 客服，你接上去试试”。更像是先把我的客服业务拿出来做一次拆账：哪些会话有明确结果，哪些只是咨询，哪些有系统动作，哪些容易扯皮，哪些压根不适合 result-based pricing。
然后就进入最关键的一步：定义 billable resolution。
比如退款，不能写成“Agent 帮用户解决退款问题”。这句话上不了账单。真正能落地的定义要具体到：用户身份验证通过，订单符合退款政策，Agent 成功调用订单系统生成 return_id，退款标签发送成功，CRM 里状态更新，并且整个会话没有转人工。满足这些条件，这一单才算 resolved。
查订单也是一样。只是告诉用户“订单状态”不一定能计费。要看它是不是命中了双方约定的 outcome：识别用户、查到订单、解释异常、给出下一步动作，用户没有继续升级，也没有进入人工队列。
取消订阅更典型。Agent 劝用户留下来不叫结果。它要识别取消原因，给出规则允许的挽留方案，用户接受后，订阅系统里真的完成 pause、discount 或 plan change。这个时候才可能被记成一个 saved membership。
我觉得 Sierra 这里最重的工作，是把“AI 客服觉得解决了”翻译成“系统、运营、财务都承认解决了”。
后面实施会变成很工程化的几步。
先拿历史 ticket 做 intent mapping。比如过去 90 天的会话，按订单查询、退款、地址修改、物流延迟、优惠券、会员取消、投诉升级这些桶切开。每个桶再判断：能不能闭环？闭环需要哪些字段？需要调用哪些系统？失败时什么时候转人工？
接着是系统集成。知识库只是让 Agent 能说话，CRM 和订单系统才让 Agent 能办事。没有 write-back，没有 tool call，没有状态更新，就很难按结果收费，因为结果没有凭证。
然后是 simulation。拿真实历史对话去回放，让 Agent 跑一遍。用户没给订单号怎么办？政策边界不清楚怎么办？接口失败怎么办？用户情绪很差怎么办？Agent 什么时候该继续问，什么时候必须 handoff？这些都要在上线前打出来。
真正上线也不会一把梭。通常会先选少数几个低争议、高频、系统动作明确的场景，小流量跑。比如只开放 web chat 的订单查询和退货，先看 resolved rate、handoff rate、recontact rate、false resolution。
false resolution 这个指标我觉得非常关键。系统判定 resolved，但用户 24/48 小时内又回来找人工，或者质检发现其实没有处理完，这种就不应该算钱。否则 result base 会变成供应商和客户每个月对账吵架。
所以我最想看的不是那个很顺的 demo，而是账单明细。
每一行 billable case 后面，应该有 conversation id、intent、outcome type、工具调用记录、系统返回值、handoff reason、最终判定规则。客户应该可以抽样回放，也应该可以 dispute。比如这条为什么算 resolved？那条为什么不算？用户第二天又来问同一个问题，上一笔还收不收？
跑完这一圈，我对 Sierra 的理解反而更清楚了。
它表面是 AI 客服，实际卖的是一套“可验收的自动化客服 workflow”。result-based pricing 不是换一种收费方式这么简单，它要求产品把业务结果拆得足够细，细到能执行、能记录、能复盘、能对账。
所以 resolved 不是 AI 自己说“我回答完了”。resolved 是一份合同，是一条系统记录，也是一笔可以被客户财务接受的账。
意思是 B 端客户使用了 Sierra 作为 AI 客服，如果进线的会话被 Agent 端到端 resolved 了而没有转人工，就意味着 Agent 产生了价值，要计费。反之只要人工介入了，本次会话就不收费。
我好奇的是 Sierra 如何定义 resolved，以及具体的实施流程是怎样的，于是从官网 book a demo，然后 Sales 带着我端到端体验了一把客户视角的 outcome-based pricing。
我一开始以为会先看产品 demo，结果真正有价值的部分反而在 demo 前面。他们需要先知道我的客服规模、主要渠道、ticket volume、现在的 automation rate、平均处理时长、转人工比例、CSAT、用什么 CRM / contact center / 订单系统，以及最想先自动化哪几类问题。
这个流程不是传统那种“我给你一个 AI 客服，你接上去试试”。更像是先把我的客服业务拿出来做一次拆账：哪些会话有明确结果，哪些只是咨询，哪些有系统动作，哪些容易扯皮，哪些压根不适合 result-based pricing。
然后就进入最关键的一步：定义 billable resolution。
比如退款，不能写成“Agent 帮用户解决退款问题”。这句话上不了账单。真正能落地的定义要具体到：用户身份验证通过，订单符合退款政策，Agent 成功调用订单系统生成 return_id，退款标签发送成功，CRM 里状态更新，并且整个会话没有转人工。满足这些条件，这一单才算 resolved。
查订单也是一样。只是告诉用户“订单状态”不一定能计费。要看它是不是命中了双方约定的 outcome：识别用户、查到订单、解释异常、给出下一步动作，用户没有继续升级，也没有进入人工队列。
取消订阅更典型。Agent 劝用户留下来不叫结果。它要识别取消原因，给出规则允许的挽留方案，用户接受后，订阅系统里真的完成 pause、discount 或 plan change。这个时候才可能被记成一个 saved membership。
我觉得 Sierra 这里最重的工作，是把“AI 客服觉得解决了”翻译成“系统、运营、财务都承认解决了”。
后面实施会变成很工程化的几步。
先拿历史 ticket 做 intent mapping。比如过去 90 天的会话，按订单查询、退款、地址修改、物流延迟、优惠券、会员取消、投诉升级这些桶切开。每个桶再判断：能不能闭环？闭环需要哪些字段？需要调用哪些系统？失败时什么时候转人工？
接着是系统集成。知识库只是让 Agent 能说话，CRM 和订单系统才让 Agent 能办事。没有 write-back，没有 tool call，没有状态更新，就很难按结果收费，因为结果没有凭证。
然后是 simulation。拿真实历史对话去回放，让 Agent 跑一遍。用户没给订单号怎么办？政策边界不清楚怎么办？接口失败怎么办？用户情绪很差怎么办？Agent 什么时候该继续问，什么时候必须 handoff？这些都要在上线前打出来。
真正上线也不会一把梭。通常会先选少数几个低争议、高频、系统动作明确的场景，小流量跑。比如只开放 web chat 的订单查询和退货，先看 resolved rate、handoff rate、recontact rate、false resolution。
false resolution 这个指标我觉得非常关键。系统判定 resolved，但用户 24/48 小时内又回来找人工，或者质检发现其实没有处理完，这种就不应该算钱。否则 result base 会变成供应商和客户每个月对账吵架。
所以我最想看的不是那个很顺的 demo，而是账单明细。
每一行 billable case 后面，应该有 conversation id、intent、outcome type、工具调用记录、系统返回值、handoff reason、最终判定规则。客户应该可以抽样回放，也应该可以 dispute。比如这条为什么算 resolved？那条为什么不算？用户第二天又来问同一个问题，上一笔还收不收？
跑完这一圈，我对 Sierra 的理解反而更清楚了。
它表面是 AI 客服，实际卖的是一套“可验收的自动化客服 workflow”。result-based pricing 不是换一种收费方式这么简单，它要求产品把业务结果拆得足够细，细到能执行、能记录、能复盘、能对账。
所以 resolved 不是 AI 自己说“我回答完了”。resolved 是一份合同，是一条系统记录，也是一笔可以被客户财务接受的账。
35 323
最近不下 3 个朋友转发 Shopify CEO 的这篇文章 echo 我：x.com
嗯，一个组织的速度，取决于它最低带宽的沟通渠道和节奏。会议很慢。邮件很慢。私聊很慢。Slack 的公开 channel 就是大型车间现场，不但人能学，Agent 也有充足的上下文。
嗯，一个组织的速度，取决于它最低带宽的沟通渠道和节奏。会议很慢。邮件很慢。私聊很慢。Slack 的公开 channel 就是大型车间现场，不但人能学，Agent 也有充足的上下文。
Gavin_C.: 很多年前在当时的公司（那会还没自己创业），带的产品部门和设计部门加起来有小 100 号人。 团队协作上我当时定了个规则，别的部门我管不着，但我的部门成员：任何人都不允许私聊业务问题，也不允许设置私有的 channel。所有的业务讨论都必须在公开 channel 里进行，无论是否与其他人直接相关。 背后的思考主要有以下几点： 1. 产品团队的管理特性 产品和设计团队（尤其是产品经理）是最难管理的群体之一。他们的工作不像研发体系那样可以完全标准化。 (a) 他们的工作中包含大量的理念、规划、想法、对错判断和讨论思考。 (b) 这些内容多是非结构化的，产品经理日常大量的时间并不一定是在追求短期结果，但非常重要，值得被频繁、深度地思考。 (c) 当产品经理多了以后，管理大家的想法、确保我的理念能传递给所有人，就成了一件至关重要的大事。 2. 业务域的高度耦合 一个中型项目过去往往按业务域分工，但不同业务域之间的耦合度其实非常高。你以为只是某一块业务的问题，但推进到开发阶段时，往往发现其他业务域的人也必须被 involve 进来。 3. 管理者的掌控感需求 作为管理者，我们需要一种掌控感。这种掌控感并不是说所有关键进度我都要了如指掌或由我确认，而是说： (a) 哪怕你最后只给我一个结果，我也要看到这个结果形成的过程。 (b) 你们是怎么思考的？决策依据是什么？判断优先级的逻辑是什么？ (c) 这个过程我至少要能看得到，这样即便我去纠正，我也能知道你是因为什么原因、在哪种思考方向上走偏了。 如果能让我在关键节点参与进来，我会觉得更踏实，因为人都需要这种掌控感，所以下属有时候利用管理者的这个心理能拿到更好的 “结果”。 那阵子还看到 GitLab 内部的一个 remote playbook，提到他们 CEO 的 OKR 里有一个很重要的 KR，叫作“减少组织内私聊率”，我当时非常有共鸣。 现在大家都在讨论 AI native 时代的组织协作方式，也有蛮多产品，有意思的是，这些产品发布的时候老想制造对立。 比如Slack 是旧世界的，需要一个 AI 时代的 Slack；Notion 是旧世界的，需要一个 AI 时代的 Notion；Linear 是旧世界的，现在需要一个 AI 时代的 Linear。 但你要是真问这些产品的创造者，背后对于组织协作的理念和思考到底是什么，其实也挺难让人买账（buy-in）的。 我们现在创业团队的做法是，日常主要使用两类工具：一类是 Slack，一类是 Linear。 1. Slack：整家公司的“组织面板” (a) 在过去非 AI 时代，Slack 承载的最大价值是人与人之间的交流，价值点比较杂 (b) 现在我们把它更多定义为组织内的面板，它的价值变得更窄，但更深了。首先是“吹水”的价值，聊些乱七八糟有的没的，当成内部论坛也行；其次是资讯聚合器：谁看到了哪篇文章、哪个帖子或哪个有意思的项目，把链接分享出来；再就是“业务讨论”：这些讨论不需要当下立即有结果。当然，所有的讨论还是不能私聊，甚至不能当面聊，哪怕两人对面坐着也得 Slack 公开 channel 里聊。 2. Linear：是在 Slack 这个组织面板下的，它是短期内要有结果事项的触发器。譬如谁在某个地方提到了任何一件事，就创建一个 Issue 给 Linear (a) 配合 Hermes Agent，它会调用每个人本地的 Runtime 来写代码，最后再通过 PR 把结果 push 到 Slack 里面 (b) 在整个过程中，我们不像过去传统方式那样使用 Linear 此外，Slack 存在的另外一部分价值是每个人维护自己 Coding Agent 的 Specs 和 Rules，也算是所谓的 Harness 的一部分吧。 AI Native 的组织协作这个话题很有意思，最近跟人交流比较多，懂得的人自然都懂；不懂的人，心里互道一声傻逼，反正 dddd 吧。😂
4 00
翻了下微信 AI 的官方资料，感觉它做“自动模式”这件事，其实挺非共识的。
前段时间很多人都在讲“要给 Agent 做产品”，意思是 Agent 眼里没有 UI，产品应该更 Agent-native，最好是接口、schema、工具调用、结构化状态，别再让 Agent 像人一样点来点去。
这个判断没错。只是它更适合从零开始的产品，或者没有历史包袱的场景。微信不是这个情况。
微信手里不是一张空白画布，而是一个跑了十几年的服务世界。小程序页面、按钮、表单、登录态、地址、优惠券、支付确认，全都已经在那里了。很多业务规则不在某个干净的接口里，而是藏在这些页面和流程之间。
所以微信 AI 的自动模式，其实是在说：既然这套数字基础设施已经为人建好了，那 Agent 先学会像人一样使用它。
它也不是单纯“看截图点坐标”那么土。微信是小程序宿主，自动模式不是外部手机 Agent 硬读屏，而是在平台内部读取源码、分析页面，再让微信 AI 直接操作小程序。走的是 GUI Agent 逻辑，但不是最低配的 GUI Agent。
还有一点我觉得微信可能想得比很多 Agent-native 讨论更清楚：交易场景大概率不是那种能放心扔给 Agent 自己跑完的任务。
点外卖、打车、买票、下单、支付、开发票、改地址、售后，这些事看起来是“执行任务”，但中间其实全是确认、犹豫、纠错、授权和责任边界。价格变了要不要继续？地址是不是对的？优惠券怎么用？支付前要不要再看一眼？出了问题算谁的？
所以商业场景里的 Agent，很难是大家畅想的 fully autonomous。更常见的状态应该是 Human in the loop，而且 loop 还不浅。Agent 可以帮你推进流程、减少点击、聚合信息，但关键节点人还是要看、要确认、要接管。
这会反过来影响产品形态。如果人一直在链路里，那 Agent 和人共用一套交互层就很自然。GUI 不只是给人看的皮肤，它也是人机协作的交接面，是“你确认一下”和“出事算谁的”的边界。
没有包袱的时候，当然可以很潇洒地说：给 Agent 做产品，不需要考虑 UI。
长期看，Agent-native 当然更优雅。接口清楚，参数明确，状态可控，错误可追踪，也更容易组合。微信官方的开发模式，本质上也在往这个方向走：Skill、原子接口、原子组件、小程序 MCP。
但你不可能要求几百万个小程序开发者明天都重写一套 Agent-native 的服务层。大厂可以，小商家不行；新服务可以，老系统很难；标准流程可以，复杂履约场景更麻烦。
所以自动模式的价值，不是它代表终局，而是它能让服务提供商用最低成本接入 Agent，同时最大化复用已有世界。
微信现在做的其实是迁移路径：先让 Agent 穿上“人的外壳”，使用已经为人建好的小程序基础设施；等高频场景跑出来，再把那些流程拆成原子接口、卡片、半屏页、支付确认和更 Agent-native 的调用。
前段时间很多人都在讲“要给 Agent 做产品”，意思是 Agent 眼里没有 UI，产品应该更 Agent-native，最好是接口、schema、工具调用、结构化状态，别再让 Agent 像人一样点来点去。
这个判断没错。只是它更适合从零开始的产品，或者没有历史包袱的场景。微信不是这个情况。
微信手里不是一张空白画布，而是一个跑了十几年的服务世界。小程序页面、按钮、表单、登录态、地址、优惠券、支付确认，全都已经在那里了。很多业务规则不在某个干净的接口里，而是藏在这些页面和流程之间。
所以微信 AI 的自动模式，其实是在说：既然这套数字基础设施已经为人建好了，那 Agent 先学会像人一样使用它。
它也不是单纯“看截图点坐标”那么土。微信是小程序宿主，自动模式不是外部手机 Agent 硬读屏，而是在平台内部读取源码、分析页面，再让微信 AI 直接操作小程序。走的是 GUI Agent 逻辑，但不是最低配的 GUI Agent。
还有一点我觉得微信可能想得比很多 Agent-native 讨论更清楚：交易场景大概率不是那种能放心扔给 Agent 自己跑完的任务。
点外卖、打车、买票、下单、支付、开发票、改地址、售后，这些事看起来是“执行任务”，但中间其实全是确认、犹豫、纠错、授权和责任边界。价格变了要不要继续？地址是不是对的？优惠券怎么用？支付前要不要再看一眼？出了问题算谁的？
所以商业场景里的 Agent，很难是大家畅想的 fully autonomous。更常见的状态应该是 Human in the loop，而且 loop 还不浅。Agent 可以帮你推进流程、减少点击、聚合信息，但关键节点人还是要看、要确认、要接管。
这会反过来影响产品形态。如果人一直在链路里，那 Agent 和人共用一套交互层就很自然。GUI 不只是给人看的皮肤，它也是人机协作的交接面，是“你确认一下”和“出事算谁的”的边界。
没有包袱的时候，当然可以很潇洒地说：给 Agent 做产品，不需要考虑 UI。
长期看，Agent-native 当然更优雅。接口清楚，参数明确，状态可控，错误可追踪，也更容易组合。微信官方的开发模式，本质上也在往这个方向走：Skill、原子接口、原子组件、小程序 MCP。
但你不可能要求几百万个小程序开发者明天都重写一套 Agent-native 的服务层。大厂可以，小商家不行；新服务可以，老系统很难；标准流程可以，复杂履约场景更麻烦。
所以自动模式的价值，不是它代表终局，而是它能让服务提供商用最低成本接入 Agent，同时最大化复用已有世界。
微信现在做的其实是迁移路径：先让 Agent 穿上“人的外壳”，使用已经为人建好的小程序基础设施；等高频场景跑出来，再把那些流程拆成原子接口、卡片、半屏页、支付确认和更 Agent-native 的调用。
12 211
图 2 的thread 刚好回应了图 1，真实的商业环境里：
1. 处处是细节，而你为了消灭用户可能感知不到但总觉得没有顶级产品那么好用的细节，付出的精力是 vibe coder 们不敢想象的多。你说这是用户体验也好，工程细节也罢，根本原因在于你到底在做的是一款商业产品，还是想发个状态证明你也行（毕竟你一直认为 GUI 不重要）
2. 5 个人的小团队当然能做出一款伟大的产品（比如 Claude Code/Codex），但 5 个人的团队交付不了稳定体验的 Claude Code/Codex。自媒体把你整焦虑的时候，从来就没算上大厂内部已经稳如狗的基建（当然，它们可能不知道什么是基建）
3. 几个人可以很快，所以觉得 slack/linear 不够 AI native，Codex 是一切。一支团队才能走得更远（有点俗），但团队协作就该有团队协作的样子，比如我光喷问题没提 issue，以至于 4 天过去了我的同事居然没有回应…
1. 处处是细节，而你为了消灭用户可能感知不到但总觉得没有顶级产品那么好用的细节，付出的精力是 vibe coder 们不敢想象的多。你说这是用户体验也好，工程细节也罢，根本原因在于你到底在做的是一款商业产品，还是想发个状态证明你也行（毕竟你一直认为 GUI 不重要）
2. 5 个人的小团队当然能做出一款伟大的产品（比如 Claude Code/Codex），但 5 个人的团队交付不了稳定体验的 Claude Code/Codex。自媒体把你整焦虑的时候，从来就没算上大厂内部已经稳如狗的基建（当然，它们可能不知道什么是基建）
3. 几个人可以很快，所以觉得 slack/linear 不够 AI native，Codex 是一切。一支团队才能走得更远（有点俗），但团队协作就该有团队协作的样子，比如我光喷问题没提 issue，以至于 4 天过去了我的同事居然没有回应…
8 02