当用户从人类变成AI Agent时，产品设计的底层逻辑正在被颠覆。本文揭示了传统引导设计对Agent完全失效的残酷现实，并深入剖析了稳定性、错误处理、文档规范和权限模型这四大关键领域的认知颠覆。产品经理如何应对这场无声革命？答案或许藏在API的错误日志里。

产品设计有一个正在失效的前提：用户是人。

我观察过的一个团队，他们的 SaaS 产品新手引导做得很用心，进度条、气泡提示、每步完成后的小动画，PM 打磨了差不多大半年。上线后数据不错，新用户完成率明显涨了一截，在内部分享上讲了。

但他们没说的是：差不多同期，一批企业客户开始用 Agent 来操作他们的产品。不经过界面，直接调 API，跳过了所有引导流程。那大半年的引导，对这批用户来说，等于没做。

这不是个极端案例。这是现在越来越多产品正在发生的事情。

问题在于，我们做产品设计的底层默认，是一个从来没有被写进文档、但渗进了所有决策里的假设：用户是有情绪的、会焦虑的、需要被引导的人。所以我们做 onboarding，所以我们写”哎呀出错了”而不是报一个错误码，所以我们设计空状态，所以我们在每一个可能让人困惑的地方放上帮助文字。

Agent 没有这些需要。

但它有另外一套完全不同的需要，而我们几乎还没开始认真对待它。

一、稳定性这件事，被严重低估了

我认识一个做工具产品的朋友，他们 API 的企业用户里有不少是用 Agent 来接的。前阵子跟他聊，他说了一件让我印象挺深的事。

他们做了一次版本迭代，有一个返回字段从字符串改成了数组，在他们内部算是个小调整，照常发了更新通知就上线了。结果没几天，一个企业客户那边 Agent 直接挂掉了，业务跑不起来。排查花了两天，最后定位到这个字段变更。

他说，那次之后他们才意识到，”改 API”这件事的代价，跟以前不一样了。

以前用户是人，字段改了，用户的系统报错了，他们会来找你，骂你一顿，你解释一下，对方修改适配代码，过去了。整个过程有摩擦，但有反馈，能收敛。现在用户里有 Agent，Agent 不会来找你，它会静默地出错，或者更隐蔽的——静默地传错数据，系统表面上还在跑，但跑出来的结果是不对的，而且你不知道从什么时候开始出问题的。

这是一个很不一样的失败模式。

人用产品，有一种天然的适应能力——界面改了，找几下找到了；逻辑变了，摸索一下也明白了。这种适应性，过去被产品经理当成一个隐形的缓冲垫，不声不响地吸收了很多设计粗糙带来的代价。Agent 没有这个缓冲垫，或者准确说，它有，但吸收的方式是出错，而不是适应。

所以对 Agent 友好的产品，第一件要做的事不是新功能，是把接口稳定性当成一等公民来对待。字段要废弃，要提前标注；行为要变化，要明确说明；版本要管理，要有清晰的升级路径。这套东西在开发者工具领域是标准做法，但面向 C 端、面向企业用户的产品，几乎没有这个意识。因为以前不需要。

现在需要了。

二、错误信息，是一个被做烂了的东西

举个小例子，感受一下问题在哪。

“您的操作失败了，请检查网络连接或联系客服。”

对人来说，这句话是合理的。人看完大致知道下一步：先刷新试试，不行就去找客服。这是一个”安抚 + 引导”组合，功能上完整。

把这句话给 Agent 看，它什么都做不了。

它不知道这个错误是网络超时还是权限不够还是参数传错了。它不知道要不要重试，重试多久之后放弃，这个失败是偶发的还是必然的。它只能靠猜——或者在那里反复重试直到超时，把你的服务器日志打满，然后报一个它也不知道是什么意思的上游错误。

我观察过的几个团队，Agent 调用成功率卡在很低的地方，工程师排查了很久，以为是模型能力的问题。后来换了个思路，把失败的调用拉出来逐个看，发现大多数失败集中在几个固定接口上，追进去看，原因是这几个接口的错误返回太粗，Agent 根本无法判断该怎么处理，只能乱试。后来把错误信息改细——分类、是否可重试、建议等待时间——成功率从六七成涨到了九成出头。

模型没动。Agent 没动。产品的错误信息改了一下，事情就不一样了。

我觉得这才是大多数团队现在还没意识到的：错误处理，不只是用户体验问题，也是系统决策信息问题。面向人的错误提示讲究”怎么说让用户不崩溃”，面向 Agent 的错误信息讲究”给的信息够不够让 Agent 做出正确判断”。这两件事的要求，几乎相反。

（顺便说一句——这块最容易被 PM 忽略，因为以前这块出了问题，代价主要由工程师和用户承担，PM 感知不到。现在 Agent 进来之后，这个代价变得直接很多，也更难绕开。）

三、文档比我想象中是个更深的坑

写给人看的文档，可以有歧义。

这句话听起来像是批评，但其实是在描述一个现实：人类开发者在文档模糊的时候，会去翻 issue，会去找社区里的例子，会凭经验猜，再不行就试——他有一套靠经验补全歧义的能力，而且这套能力大多数时候有效。

Agent 没有这个。准确说，它补全歧义的方式，很可能跟你预期的不一样。

我见过一个挺典型的情况：某产品有一个接口参数，文档注释写的是”用户偏好配置”，就这五个字，没有数据格式说明，没有示例。人类开发者看到这个会去找示例代码。Agent 直接按字面意思构造了一个它觉得合理的 JSON 传过去，运气好是服务端报参数错误，运气不好是被接受了，但结果不对，调用方完全不知道。

这不是 Agent 的问题。这是文档的问题。

但更深的问题是：谁来负责让文档对 Agent 可消费？这件事以前没有人想过。它不是纯技术写作的活，它需要有人知道 Agent 会怎么理解这份文档，会在哪里误读，然后有针对性地补信息、加约束、写示例。

这个角色，我觉得只能是产品经理来扛，不能把文档扔给技术支持了事。

四、权限这块，我说实话，我还没完全想清楚

但有一点是比较确定的：现有的权限模型，设计前提是”用户是人，在关键操作前会停下来确认”。

你要删账号，系统弹”你确定吗”，人会停一下，想一想，然后点。这个停顿，是有意义的，它在做决策的最后一道缓冲。

Agent 不会停。它被给了权限就会用，而且可以很快地用，大规模地用。

我听说过的一个案例：某个团队给 Agent 配了”操作员”权限，以为没问题，结果 Agent 在执行任务链的过程中，把某些本不该批量操作的记录批量改了一大批。权限级别是对的，但操作的速度和规模完全不在原来权限模型的考虑范围里。

这提示了一个之前没人想过的维度：权限不只是”能不能做”，还得有”能做多大量”。速率限制、单次影响范围上限、高危操作的二次确认——这些在针对人的产品里，靠人自己的谨慎来兜底。在针对 Agent 的产品里，得显式地设计进去。

至于怎么设计，这事我真的没有一个成型的答案，网上也没看到什么好文章在认真讲这个。如果你有想法，欢迎来聊。

五、PM 的工作，要多一块

带我入行的前老板做了十几年产品，他说过一句话我一直记着：PM 本质上是个翻译，把用户需要什么翻译成工程能实现什么，再把工程能做什么翻译成用户能理解的体验。

现在来了一个新的用户类型，翻译的工作就要多一块。

做 AI 产品的这 2 年里，我越来越觉得，”研究 Agent 的行为”应该是 PM 的职责，不能完全甩给工程师。Agent 在哪些步骤上容易出错？它的理解在什么情况下会和人的理解出现分叉？某个接口的 Agent 调用成功率很低，是模型能力不够，还是产品设计不友好？

这些问题，问工程师会得到技术层面的答案，但产品层面的判断，还是得 PM 来做。

我认识一个做 AI 基础设施的朋友，他说了一句话我觉得说到点子上了：”让 Agent 更聪明，是有瓶颈的。但产品对 Agent 有多不友好，上限是无限的。”

你现在做的产品，你知道有没有 Agent 在调它吗？

如果有，你看过那些失败请求里，有多少是 Agent 在反复重试？你们的错误信息，能不能让 Agent 自己判断下一步？你们的接口文档，如果一个 Agent 按字面意思理解，会不会走错？

今天可以去查一下 API 的错误日志。不需要做什么，先看看里面有什么。

我不保证看了就有答案，但看了至少知道问题在哪。