前段日子钉钉发布了个人版，充分强调了 AI 的能力，结合最近我个人工作中的一些不太成功的实践，写一个小小的分享，希望能够抛砖引玉。

为了避免信息安全问题，文章中举例不会涉及到我实际负责的或者接触到的一些产品，但是我会尽可能从市面上寻找类似的产品界面作为截图举例说明，确保不会影响表达。

这篇文章将重点探讨怎么在相对成熟的 To B 产品中引入大模型，与 To C 或者 AI 原生的产品之间存在一些思路上的差异，这一点也请各位读者朋友在应用的时候格外注意。

大语言模型实际在应用的时候的缺陷

评论尸曾经写过一篇文章，叫做《鼠巢，AIGC，可颂猫，短视频》（https://1q43.blog/post/520），里面列举了一种理想场景：

考虑到 2022 年在抖音和快手上流行的很多梗本身就「看起来不太像是人类能想得出来的」，所以干脆把人类创作者干掉，用户喜欢看什么视频，给什么视频点赞，大模型负责根据这些受欢迎的视频直接生成面向 C 端的内容，中间略过标签化或者特征工程。

这篇文章里面列举的产品形态是一种非常「端到端」的产品形态，中间几乎已经没有人类的参与了，但是实践的时候发现理想和现实的距离还是非常远的，原因如下：

- 因为本文着重探讨的是怎么在成熟的 To B 产品中引入 LLM 能力，所以首先就要明确一件事情，就是大概率没法用 Open AI 或者微软的 API，因为如果在一个大公司，就得用自研的大模型，如果客户是国企或者央企，考虑到数据安全更没法用，国产的大模型目前能力其实是非常糟糕的，距离 GPT-3.5 差距都很明显，而微软提供的 API 数据存储目前都在境外，数据出境是一个很麻烦的专业领域，能不用尽量别用；

- 目前真的能用上的模型并不是多模态的，但是用户需求往往会出现视频转文字或者文字转视频，图像转文字或者文字转图像，通过标签化来去描述是绕不开的坎，所以关键词打标的能力仍然非常重要，这些关键词很可能会做成不同模态转化时的 prompt 的入参；

- 这种端到端的生成方式中间缺少了人工干预的能力，从使用方的角度更希望输出的不是端到端的内容，而是中间过程的文件。比起直接生成成品视频，客户更希望能生成分镜脚本，然后再通过脚本生成视频。人工干预是刚需，毕竟客户也需要跟自己的老板解释有了 AI 自己还能干嘛，更何况很多场景就是需要强干预的，To B 的客户追求的不是最高分高，而是追求可控可预期；

大语言模型到底能做什么？

我目前看下来比较成熟的用途有如下几种：

一、总结：根据特定的要求分析大段的内容，并且按照内容给出对应的结论；

典型用途：

- 总结一篇文章讲了什么：最典型的产品就是会读 Readflow；

- 把一大段文字中某一个类型的关键词抽取出来：在实践的时候 ChatGPT 经常会被用来作为现有的实体抽取模型的优化参照基准；

- 给脚本打分，判断脚本是否敏感等：这个本质也是在研究一大段文字在讲什么，但是与传统的审核手段相比，大模型在做审核的时候可以非常好的判断文字有没有在「阴阳怪气」；

二、扩写：根据特定的要求和范式，将少量内容扩充成大段内容；

典型用途：

- 广告脚本生成；

- Notion AI；

三、翻译：根据特定要求把一段内容无损的转化成另一段内容；

典型用途：

- Text to SQL：将自然语言翻译成 SQL，但前提是需要明确元数据，同时需要注意的是一些交互式的数据查询能力底层也是通过将自然语言翻译成查询语句，再将查询语句映射成 GUI 实现的；

- 文稿润色：比如把口播的文案转化成书面语，把视频脚本转化成小红书文案等；

四、意图理解：大语言模型有非常强的意图识别能力，可以非常好的理解用户的意图；

典型用途：

- 帮助助手：可以通过大模型实现产品能力的文档，或者在用户找不到功能时提供导航的能力；

但是在实践的时候怎么避免幻觉非常重要，我在实践的时候发现，回答帮助文档的问题仍然会出现幻觉的情况。

五、基于 AI Agent 实现复杂能力：举例两个在工程层面非常难实现的 Case，一个是异动分析，一个是探索魔法数字，这两个应用场景不是说一定得用大模型，但是如果用大模型的话工程难度会下降很多；

典型用途：

- 异动分析：一个指标下滑了，原因是什么？请系统直接给出结论；

- 探索魔法数字：找寻让一个指标上升的关键数字，比如如何让用户留存？主要得通过新用户关注 10 个大 V 来实现，问题是为什么是 10 个大 V？

通过 Agent 实现复杂能力其实通过 GUI 一定也能做，是否使用大模型来做主要还是取决于哪种方案更优，越是容易收敛的问题其实越适合用 GUI 来做，但是异动分析显然是一个很难收敛的问题，所以很适合大模型来做。

这是知名的 BI 产品 Tableau 的围绕 GPT 打造的拳头功能。

产品方案的一些 Tips

入口的选择嵌入式入口 VS 小助手式入口

对于传统的产品来说，增加 AI 赋能就会有一个非常麻烦的问题，那就是怎么设计入口。

微软在 Office 365 的成功让很多人误以为小助手式的入口（比如在页面的左上角有一个固定按钮）是最好的实践，但是从我自己实践的情况来看我认为并不是这个样子。

从我的角度来看，嵌入式的入口是更好的设计。所谓的嵌入式入口就是指在特定的功能模块的附近增加 AI 助手的入口，比如我这边有一个写 SQL 的文本框，那么最好就在文本框的执行按钮附近增加一个点击之后可以唤起 AI 助手的入口，又或者选中代码的时候悬浮出菜单等等，Notion AI 在这点上其实就做的比较好，没有一个始终有存在感的小助手，而是通过「/」的方式唤起，和自己的产品主流程融合在一起。

如果选择在特定功能模块附近增加 AI 助手的入口，这会带来天然的场景限制。设计成本低，可以借助 AI 有效解决单点问题，而且场景是明确的，可以内置提示词，问题容易收敛，内置提示词其实很重要，因为很多用户根本不会写提示词。

我说这些并不是想表达小助手式的入口不如嵌入式入口，而是小助手这样的入口会给用户一个心智，这个 AI 是针对这整个产品的，是万能的，可以通过和 AI 对话改变左侧的界面结果，比如口播要求 AI 做 PPT，又比如类似 Siri 可以问五花八门的问题，很可能超过设计者的预期。

所以在选择小助手的入口之前，请先问问自己这三个问题：

1. 我们的产品受 Copilot 控制的能力有这么强吗？左侧的 GUI 部分真的能被自然语言调整吗？

2. 我们的业务场景需要复杂多轮对话才能给用户提供满意的结果吗？

3. 我们的用户有能力使用复杂的多轮对话解决吗？

如果这三个回答都是否定的，为什么要用这种交互呢？

数据闭环反馈

所有的 AI 生成的结果都要允许用户进行打分 or 标记，考虑到用户实际点赞或者踩的比例很低的，所以一定要刻意设计一些按钮，比如「复制文案」，比如「重新生成」，比如「错误反馈」等，根据这些与用户工作流实践相结合的按钮来获得用户的反馈。

同时也需要做「复制会话 ID」这样的功能，因为客户的老板也会试用，如果给出了不合理的回答，好歹能根据 ID 找日志排查，不然就是两眼一抹黑不好复现，很尴尬。

通过 GUI 内置 Prompt 并且把这个 Prompt 给明确出来

在和大模型交互的时候会内置很多的 Prompt，这些 Prompt 最好能够有个地方展示出来。

比如广告文案生成的工具，一定需要在 Prompt 中内置广告法相关的提示词，避免生成的文案有最、最佳等字眼，但是用户是不知道点击生成文案这个按钮的时候这些 Prompt 都被内置进去了，最好有地方要能够展示，可以降低解释成本呢。

尤其是在把自然语言翻译成 SQL 的场景，这个很重要，因为可能会涉及到统计口径问题。

数据一致性

AI 给出的结论不能和 GUI 的有冲突，一旦出现会非常难解释，所以涉及到数据口径的回答一定要通过调用统一的 API 获取数据的方式来进行，但麻烦的点在于有的时候大模型会自己胡说八道，而且在实操的时候，如果调用的是外部的 API，其实就变成一个概率问题，让人很头疼。

成本和时效性

个人用户为了解决回答的准确性，通常会在所有的问答上面增加一个二段式的检查，一个 prompt 用于完成任务，一个用于检查任务结果，但是在实践的时候这么搞会导致的结果就是成本至少翻倍，无论是 API 调用费用还是请求时间成本，所以如何写好 Prompt，确保一次性回答的准确率也是很重要的命题，毕竟钱包和服务器真的经不住这么折腾。

分工与协作

分工与协作是一个值得单独拿出来说的事情。

这类 Copilot 项目的落地，到底是公司内的模型团队主导还是业务团队主导是个大问题，因为大部分情况下这是两个团队，而现在大部分公司内的大模型不是基于开源改的就是调用国内可用的公开 API，模型团队可能就会变成 Pormpt 工程师（反正都是调用外部模型），这个会要求他们天然更愿意向前一步，不然就没活干。

但是这个向前一步对于业务团队来说就会比较尴尬，这种分工会有两个问题：

模型团队向前一步，思路就容易变成拿着锤子找钉子，这种思路其实容易走偏，容易自嗨。

模型团队团队如果做的很好，那么业务团队就会沦为入口和数据的提供方。

所以从我的角度看还是业务团队主导，模型提供通用能力是更合适的做法，模型团队应该把精力放在 Agent 的设计以及模型的微训练上面，比较容易解决和收敛的单点问题提供 API，让业务团队自由发挥即可。

为什么要把分工和协作单独拿出来说，主要还是因为康威定律，什么样的协同关系就会设计出来什么样的产品，健康的产品设计应该是模型与具体业务解耦的，但实践的时候并不能完全保证这点。

这是很多脱离一线的人容易忽略的一点。

如果模型团队在分工上介入过于深入，不可避免的将会出现模型团队做功能卡片的情况，但实际上大模型很多时候承载的是 UI 的职能，也就是识别用户的意图，卷入到功能开发里面一方面会让这个团队做他们不擅长的事情，同时还会导致业务团队如果有更换底层模型的意图时也不好操作。如果在一个中大型公司内做这件事情，很可能会有超过 2 个可供选择的模型接口，这种情况下可以支持切换也会成为需要重点考虑的要求。

当然这么做也有好处，就是业务团队可以节省很多人力成本，对于一个相对成熟的 SaaS 产品来说，引入 AI 能力其实短期内并不是刚需，而且有很多问题其实也可以靠 AI 之外的手段解决。

扩展阅读

在 2023 年我写了一篇文章论述关于 ChatGPT 可能对 SaaS 的影响（ChatGPT 会干掉 80% 的 SaaS 公司，连带 Office 一起），现在实践下来算是基本应证了当时的部分想法，可惜的点在于很多时候在公司内做产品，并不能完全按照自己的想法来进行。