我现在越来越觉得，AI 应用真正难的不是做出来，而是让用户一直用下去

我现在越来越觉得，AI 应用真正难的不是做出来，而是让用户一直用下去

最近刷到了一些 AI 应用的演示，第一眼看上去都挺不错的。输入一段文字，它可以帮你总结；上传一张图片，它可以识别里面的内容；给它一个目标，它还可以自己拆解任务、调用工具，最后给出一个比较完整的结果。

但是我现在越来越觉得，很多 AI 应用的问题也恰恰在这里。第一次演示的时候看起来很智能，真正让用户用上几天以后，却不一定还能继续用下去。

因为用户会慢慢发现，每次使用之前，自己还是要准备很多东西；使用的过程中，需要不断确认 AI 到底做得对不对；使用结束以后，还要重新检查结果，再把内容复制到原来的系统里面。这样算下来，AI 确实帮忙做了一部分工作，但整个过程并没有真正轻松多少。

所以如果让我现在去判断一个 AI 应用有没有价值，我可能不会先去看它背后用了什么模型，也不会先去看它的架构有多少个节点。我会先想一个问题：这个东西到底有没有让用户少做一点事情。

很多时候我们做 AI 应用，第一反应都是先想技术。比如用哪个大模型，要不要做知识库，要不要接工具，要不要使用 Agent，要不要用 LangGraph 把整个流程拆开。这些东西当然都重要，但是它们解决的更多是“这个东西能不能做出来”。

用户真正关心的，可能是另外一件事情。他不会特别关心你用了几个模型，也不太关心你的流程图画得有多复杂。他更关心的是，这个东西能不能解决我现在遇到的问题，结果能不能直接用，如果出了问题我能不能看出来，以及我以后还愿不愿意继续打开它。

我现在会觉得，AI 功能和 AI 应用其实不是一回事。AI 功能可能只是帮你写一段话、总结一份资料，或者生成一个方案。它把结果给你以后，事情基本就结束了。

但是 AI 应用不应该只是把结果生成出来，它还应该知道这个结果在整个事情里面处于什么位置。前面需要什么信息，后面还要接着做什么，什么情况下可以自己继续，什么情况下必须停下来问一下人。

比如现在很多工具都可以自动生成会议纪要。会议结束以后，AI 把讨论内容整理一下，再列出几个待办事项，这件事情本身没有什么问题。

但是真正用起来以后，可能马上就会发现，会议里面有些话只是临时讨论，并没有最终确定；有些事情虽然被提到了，但还没有明确负责人；有些内容当时觉得没问题，过两天项目发生变化以后，又需要重新判断。这个时候，一份写得很漂亮的会议纪要，其实并不能直接解决问题。

如果它能够继续把已经确定的事情、还没有确定的事情、需要谁确认的事情区分开，再把真正的待办事项放到项目管理工具里面，后面还能跟踪进度，那它才算真正帮忙完成了一件事。否则它只是帮用户少打了一些字，剩下的工作还是要用户自己继续做。

所以我觉得，AI 应用有没有价值，不能只看它输出的内容好不好看，还要看它有没有把前后的工作接起来。用户使用它以后，是不是可以直接进入下一步，而不是多了一个需要复制粘贴的地方。

这个问题放到 Agent 里面会更加明显。简单来说，Agent 就是可以根据目标自己判断下一步做什么，必要的时候再调用一些工具。演示的时候，一般会给它一个比较清楚的任务，然后看它怎么一步一步完成。

但是现实里面的任务，通常不会这么干净。用户说一句“帮我跟进一下这个客户”，这句话看起来很简单，实际上里面有很多信息没有说出来。这个客户之前聊过什么，现在到底处于什么阶段，最近有没有购买意向，应该什么时候联系，联系的时候应该说什么，哪些内容不能直接发出去，这些都要判断。

如果 Agent 只是根据这句话生成一段销售话术，那它解决的只是“写一段话”的问题，并没有真正完成“跟进这个客户”。真正有用的 Agent，至少要能结合客户以前的沟通记录和当前的业务情况，先判断现在适不适合联系，再决定联系的方式和内容。

这也让我越来越觉得，做 Agent 的时候，最关键的事情之一就是边界。什么事情可以让它自己判断，什么事情需要按照固定规则做，什么事情可以让它多尝试几种方法，什么事情必须停下来让人确认，这些都需要提前想清楚。

如果所有步骤都提前写死了，Agent 每一步只能按照规定执行，那它其实更像一个普通的 Workflow，只不过里面调用了大模型。这样做的好处是比较稳定，但是遇到真实业务里面那些没有提前想到的情况时，它可能就不知道怎么办了。

但如果完全放开，让它自己决定什么时候发消息、什么时候修改数据、什么时候执行一个高风险操作，问题也会比较大。模型有时候可以给出一个看起来很合理的判断，但这不代表它就应该直接替用户做决定。

所以我更倾向于把这几类事情分开。数据格式、权限范围、停止条件这些内容，最好用明确的规则限制住；理解文字、整理信息、比较几个方案，这些事情可以让 AI 自己判断；涉及客户、合同、费用、生产环境的操作，最好还是保留人工确认。

这样做出来的系统，既不是每一步都需要人来点，也不是完全把事情交给 AI。人只需要参与那些真正需要负责的判断，剩下的重复工作可以交给系统完成。

我觉得用户不一定要求 AI 永远不出错，但用户一定希望自己知道它为什么这么做，也希望在它可能出错的时候能够把它停下来。如果一个系统每次做完事情以后，用户都不知道它参考了什么，也不知道这个结果是怎么来的，更不知道出了问题应该从哪里改，那就算它平时的成功率还不错，用户也很难真正信任它。

所以在设计 AI 应用的时候，除了最后的结果，过程中的一些依据也应该尽量保留下来。比如这个结论参考了哪些资料，调用了哪些工具，哪些内容是原始信息，哪些内容是 AI 自己推断出来的，哪些地方还存在不确定性。

这些东西不一定要全部放在页面上，也不是说要把模型的每一步思考都展示出来。我的理解是，至少在需要排查的时候，要能够找到对应的来源和过程。这样出了问题以后，我们才知道到底是资料没有准备好，规则没有写清楚，还是某个工具返回了错误结果。

如果这些信息都没有，最后很容易变成一句“这次 AI 答错了”。然后我们再去改 Prompt，再试几次，发现它在这个场景下好了，就以为问题解决了。过几天换一个类似的场景，可能又会出现新的问题。

我自己现在会比较反感一种做法，就是发现什么问题都往 Prompt 里面加一句话。今天发现它漏了一个条件，就加一条规则；明天发现它在另一种情况下判断错了，再加一个限制。这样做短期内可能有一点效果，但规则越加越多，最后连自己都不太清楚它为什么会这样判断。

更好的方式，应该是先把错误分清楚。如果是资料不够，那就补充资料；如果是业务标准没有讲明白，那就把规则说清楚；如果是一个节点负责的事情太多，那就把它拆开；如果是工具本身不稳定，那就去处理工具的问题，而不是一味地修改提示词。

只有先知道问题到底出在哪一层，才知道后面应该改什么。这也是为什么我现在不太会只看某一次回答是不是漂亮，而是会继续看整个事情有没有完成。

一个 Agent 最后输出的内容可能很流畅，但如果用户还要自己重新查资料、确认数据、整理格式，再复制到另一个系统里面，那这件事情其实还没有结束。反过来，有些 AI 输出的内容可能没有那么“惊艳”，但是它能够直接接到下一步流程里面，用户也不需要反复修改，这种应用反而更容易被长期使用。

比如开发团队经常会遇到需求描述不清楚的问题。一个简单的 AI 功能，可以把需求整理成几条任务；但如果它还能把里面没有说清楚的地方列出来，提醒开发人员需要确认什么，分析可能影响哪些功能，再按照团队的习惯生成任务，那它对实际工作就会更有帮助。

它真正解决的，不是“帮我写一份需求文档”，而是把一句比较模糊的话，慢慢变成可以开发、可以跟踪、最后也可以验收的一组任务。这里面有些事情需要 AI 来理解，有些事情必须按照固定格式和流程来做，还有一些事情需要负责人确认。

另外一个比较容易理解的例子，是运维告警。现在让 AI 解释一条错误日志，其实已经不算特别难了。但运维人员真正想知道的，往往不是这句报错是什么意思，而是它现在有没有影响业务，最近是不是刚发布过新版本，相关服务是不是也同时出现了异常，接下来应该先检查什么。

如果这个 Agent 只能把日志翻译成人话，它的作用还是比较有限。它如果能够结合监控、日志、发布记录和服务之间的关系，帮忙判断问题影响，再给出排查顺序，并且在重启服务、改配置、回滚版本这些事情上主动停下来让人确认，那才更接近一个可以真正使用的工具。

从技术上来看，这类应用可能会比普通问答复杂一些，但最难的地方还是你到底懂不懂这个业务。你要知道什么情况算正常，什么情况可能有风险，哪些操作可以自动做，哪些操作做错以后会造成更大的问题。

所以现在如果让我去做一个 AI 应用，我可能不会一开始就打开编辑器写代码。我会先跟真正使用这个东西的人聊一聊，看看他现在到底是怎么完成这件事的。

他从哪里开始，需要准备什么资料，中间要做哪些判断，最浪费时间的是哪一步，最容易出错的是哪一步，最后的结果还要交给谁继续处理。只有这些东西先搞清楚以后，才知道哪些工作适合交给 AI，哪些工作应该固定下来，哪些地方必须让人参与。

这个过程可能比直接接一个模型慢很多，但它决定了最后做出来的到底是一个演示功能，还是一个能够真正放进业务里面使用的东西。很多时候技术反而是后面的事情，前面最难的是你有没有真正理解用户每天在做什么。

还有一个问题我现在也越来越关注，就是这个 AI 应用能不能形成反馈。用户用完以后，系统能不能知道这次结果有没有被采用，用户具体改了哪些地方，哪些建议总是被拒绝，哪些任务经常需要人工接手。

这些信息其实比用户最后点一个“满意”或者“不满意”更有用。因为用户愿意修改一处内容，和用户完全不用修改，表达的是两种不同的情况；某个功能偶尔被拒绝，和每次都被拒绝，也不是同一个问题。

当然，用户的每一次修改也不能直接拿去当成新规则。有些修改只是因为当时情况特殊，有些修改才代表这个用户长期的习惯，还有一些可能只是用户自己操作错了。所以反馈不是简单地收集越多越好，而是要知道这次反馈对应的到底是什么任务、什么场景，以及它有没有必要影响后面所有的判断。

从这个角度来说，AI 应用的能力其实不是第一天就设计完成的。它更像是在真实使用的过程中一点一点跑出来的。第一版先解决最明确、最重复的问题，后面再根据用户真实遇到的情况去补充边界。

这和做一个 Demo 的思路不一样。Demo 主要看第一次展示的时候有没有效果，真正的应用要看用户第十次、第一百次使用的时候，还愿不愿意继续打开它。

所以我觉得，评价一个 AI 应用，不能只看某一次回答准不准，也不能只看模型的分数。还要看用户完成一件事情的时间有没有减少，结果是不是可以直接使用，用户需要修改多少次，出了问题以后能不能找到原因，以及过了一段时间以后，用户还愿不愿意继续用。

这些指标可能不一定都能被特别准确地统计出来，但是至少可以提醒我们，AI 应用最后要服务的是一个一直在发生的工作过程，而不是一次孤立的对话。

我现在越来越觉得，很多 AI 应用没有真正落地，并不一定是因为模型能力不够，也不一定是因为技术方案有问题。很多时候，它只是完成了“AI 能做什么”，却没有继续回答“用户为什么要一直用它”。

一个很复杂的 Agent，如果每次使用都要用户重新解释背景、重新上传资料、重新确认结果，那它可能只是把原来的工作换了一个入口。反过来，一个技术上没有那么复杂的应用，如果它记得必要的上下文，知道什么时候应该介入，能够把结果接到后面的流程里，并且在不确定的时候及时停下来让人确认，它反而更有机会变成用户真正依赖的工具。

所以以后再做 AI 应用，我觉得思考方式可能需要反过来。不是先问“我能不能做一个 Agent”，而是先问“这个行业的人每天到底在哪件事情上浪费时间”。然后再继续往下想，这件事情里面哪些部分可以交给 AI，哪些部分必须按照规则，哪些地方需要人来负责，出了问题以后又应该怎么找到原因。

这些问题想清楚以后，最后到底使用 LangGraph 还是其他框架，使用一个模型还是多个模型，可能就只是实现方式的区别了。真正决定一个 AI 应用能不能长期使用的，还是它有没有理解用户原来的工作方式，有没有减少真实的操作成本，以及有没有把不确定性控制在用户能够接受的范围里面。

我觉得这可能才是 AI 应用从“看起来很智能”走向“真的有人愿意一直用”的关键。