用千问点了一次外卖，顺利，然后呢

千问能点外卖了。我自己试了一次，一句话下去，单就下了，挺顺利。用户终于不只是从 AI 那里拿一段建议，还可能接着把事情办完。

顺利的这一次没什么可写。我更好奇的，是一句“帮我点个午饭”之后，哪些信息被带了出来，哪些选择仍然留给人，以及订单产生以后，事情怎么继续。

按阿里 1 月 15 日的官方说明，千问接入了淘宝、淘宝闪购、支付宝、飞猪和高德等服务。初期购物能力有测试范围，对话内支付需要用户明确确认，当时首先支持淘宝闪购；任务助理也有邀请测试的限制。这些条件比“全都打通了”更值得读仔细。

下面沿着这件事整理几个产品层面的想法。业务上下文、服务化、垂直工具、企业知识和 Agent 的检查机制，都是同一条线上的问题。售后、团购和企业工具是推演，不是千问已经开放的完整功能。

能生成内容，为什么还未必能留下来

我做跨境电商文案相关产品，会比较在意“写得好”和“能用”之间的差别。一款瑜伽裤，模型可以很快写出通顺的介绍。可这一次上新，是为了建立品牌印象，还是清掉积压库存？发到哪个平台，有没有不能使用的表达，规格和卖点以哪份资料为准？这些条件会改变文案。同一句“帮我写一下”，可能对应很不同的工作。用户每次都要从各处复制信息，再把生成结果搬回表格、检查、修改，工具只减轻了中间的写作，其他负担还在。

哪些上下文真的会改变判断？不只是几轮聊天，还包括当时有效的业务条件和之前作过的决定。商品库存、订单状态、客户已收到的承诺、当前适用的活动规则，以及这次由谁授权处理。设想客户问货为什么没到，只有通用知识，模型大概只能说可能受物流影响；能读取这笔订单的状态、承运信息和有效处理规则，就能给出更具体的说明。但“知道客户是某等级”不等于可以擅自免运费，“查到延误”也不等于能直接补发。判断要依据业务权限，执行要有可追溯的结果。

记录系统和模型之间，还缺哪些连接

ERP、CRM、WMS 这些系统保存了业务数据，也有自己的规则和计算逻辑。模型擅长理解和组织语言，却不天然拥有这些系统的实时状态和执行权限。把一个对话框挂在系统旁边，只是接入方式。要参与业务，还得回答更细的问题：哪些数据可以读，身份和权限怎样校验；同一个客户、商品、订单在不同系统里怎样对应；规则冲突时按哪一个版本处理；一次操作成功或失败，结果回写到哪里；人改了决定以后，Agent 能不能知道。

千问接入生活服务让我觉得有参考价值的地方，在于对话开始触及这些实际流程。用户的意图需要对应可调用的服务，服务又受自己的规则约束。我会想到“业务操作系统”这个比喻，模型参与判断，数据、工具和工作流程连接起来。这是我理解方向的一种方式，不是这次发布了一个叫 B-OS 的产品。一个方向值得期待，不代表开发者今天已经拿到了所有接口和权限。

用售后处理推一遍。假设做一个智能售后助手，先读取情况，找到当前订单、客户身份和物流状态，注明来源和查询时间；再对照规则，读取适用的退款、补发和赔付条件，分清正式规则和某个人在聊天里的建议；然后形成处理方案，超出权限的不自动承诺；获得确认后调用业务接口，核对结果，把状态写回系统，重复请求不能重复退款；最后留下依据，为什么按这条规则处理，谁确认了。仅仅发出退款调用，不代表用户已经到账；通知了主管，也不等于业务系统更新成功。在这里做产品，工作量不会只剩写 Prompt。

入口会变化，App 不一定消失

一句话连接多个服务，确实可能减少切换 App 的次数。可是减少操作，不意味着所有界面都该去掉。我想买午饭，可能愿意直接说要求；要比较价格、规格和配送时间，仍然想看清单。确认地址时，希望有个方便修改的地方；退单出了问题，也需要找到状态和处理入口。有些阶段适合对话，有些适合卡片、表格或明确按钮。“意图成为入口”，我更愿意理解为多了一种表达任务的方式，不是界面的终结。

社区团购的例子吸引我的是流程连起来。假设要组织一次水果团购，原来要选品、整理信息、做海报、发群、统计、收款和核对，工具之间搬运容易漏项。一个助手能根据预算和配送条件准备候选商品，把资料整理成草稿，生成订单汇总，确实可能省事。但每一步都有前提：供应商信息能否获取，群消息是否允许自动发送，收款和订单能否对应，临时缺货由谁处理。我会先做一个范围较小的版本，只整理已选商品、收集确认信息和汇总订单，海报先给人检查，群发和支付由用户确认。

被调用，不等于自然获得流量。自己的服务能更方便地被接入，可能减少获客门槛，可“接入生态”不等于立刻触达全部用户。是否开放、如何审核、按什么规则被推荐、收益怎样分配，都需要实际条件支持。产品仍然要回答，自己提供的这一段服务为什么值得选，以及用户在什么情况下会重复用它。

我会继续看的三个方向

一段垂直流程里的连接工作。以跨境内容为例，商品资料、平台规则、语言习惯和素材处理，分散在不同工具里。把这些连接起来，减少重复输入和来回检查，是一个可以研究的问题。这里值得积累的是有来源的规则、实际失败案例和修改记录。规则会更新，判断有例外，最终发布的责任也不能凭一次自动审核消失。至于卖家愿意付多少钱，得靠访谈和使用验证。

把企业知识整理到可用。制造工厂、连锁门店、售后团队，都可能有分散在文档和人员经验里的知识。产品经理在这里能做的，不只是一句“搭私有知识库”。要先选一个具体任务，比如维修人员查某类故障，把 Word、记录和口头经验整理成可核对的条目，标明适用条件、例外和负责人；检索时保留来源，回答不了时有办法转给人。也不是所有企业都要训练自己的模型。

检查 Agent 做过什么。当系统开始执行动作，记录和复核会变得更重要。可以设想一个检查层，先用确定规则拦住越权动作，再用模型辅助发现需要人工关注的内容。模型审模型也会漏，不该成为唯一控制。对于金额上限、账号权限、允许执行的动作，最好由业务系统明确约束。误报过多也会让人疲劳，不能只追求拦得越多越好。

三个方向，先碰哪一个？我会先选一段能观察到前后变化的工作，确认材料、权限和使用者都在。以跨境内容为例，先选一个平台、一类商品，手工做一遍，记下在哪些地方要来回问人、查资料，再看模型能否帮助提取、对照或生成草稿。没有清楚的原流程，很难判断到底省了什么。判断是否值得继续，我会问几个问题：这件事最近真的发生过吗，谁在处理？已有工具解决到了哪一步？必需的信息拿不拿得到？做错以后谁发现，能不能恢复？使用者愿不愿意把下一次同类任务也交给它？其中一个前提不成立，先停在一个辅助功能也可以。

数据、规则和决策记录，分别放在哪里。“懂业务”听起来像一种整体能力，实际做时最好拆开。订单当前状态属于事实，退款条件属于规则，某次特批属于决策记录，它们的更新方式和权限都不同。上次某个客户获得补偿，只能说明当时作过这个决定，不能据此自动给所有相似客户同样的补偿。接口越多，当然可能做更多事，但数据不一致、规则过期和状态没有回写，也会沿着连接传播。一个范围小、能解释清楚的流程，可能更适合先交给真实用户。

下单以后，我还想继续看

这次更新让我有兴趣，是因为它把模型能力和一些日常任务连到了一起。我那一单很顺。但让我决定是否长期用的，也许是一次并不顺利的操作。商品临时缺货、地址要改、支付未完成，产品怎样告诉我，能不能把事情接下去？

这些部分没有一句话点单那么好展示，却更接近日常。做 AI 产品时，除了关心模型能生成什么，还得认真看它准备进入的那段业务。