以 ChatGPT 为代表的 AI 大模型技术，经历一众热捧之后，正在回归该有的冷静。
几个月过去，我司工程师还在乐此不疲地使用 GitHub Copilot，而我已经不怎么打开 ChatGPT 了。新鲜劲过去之后，反而能让人静下来思考到底哪些场景的哪些问题适合用大模型解决。
正好上周，我们和钉钉的开放平台技术总监孙博文连过一次麦，聊到了钉钉在 AI 大模型方面的实践，也有了一些新想法。
钉钉是国内比较早集成大模型的产品，他们总结的经验值得参考。我甚至建议几位正在做企业软件的朋友，可以一个流程一个流程地学习下钉钉斜杠“/”的设计思路。
先说结论吧，大模型是能解决很多问题，但也不是万能的。对业务来说，得理性思考是否刚需，有没有对着自己的核心竞争力做，如果做 ROI 怎么样，是锦上添花还是雪中送炭。毕竟，技术永远是解决问题的手段，而不是目标本身。
另外，提个醒，大模型的落地并没有那么容易。简单写个 Demo 只需要百十来行代码，但想落地到产线层面，真正考验的还是团队的产品能力和工程能力，比如交互层面，AI 以什么样的方式融入到现有产品之中。我见到有的企业，只是硬生生地在页面中集成一个问答助手，这并不是什么高明的做法。
AI 应该润物细无声般融入业务流程。

大模型不是万能的

我很早之前就开始关注大模型、ChatGPT 等技术和产品。作为创业者，我知道求之于势的简单道理。若大模型将开启新的时代，那新时代之下，必然诞生新的产品，这对我们来说是利好。

估计很多人也是这么想的，所以大模型技术初露峥嵘时，大家都很激动，把它比作当年 iPhone 的诞生，或者第四次工业革命的开端。风起于青萍之末，尤其是当它已经极大程度得到行业大佬的肯定，没人敢再忽略这种趋势。

但同时，我也审慎而为之，技术是为产品服务的，不能拿着锤子找钉子。大模型是能解决很多问题，但咱也得冷静下来思索，哪些问题对于用户而言，是锦上添花，哪些是雪中送炭。

如果无法提升核心竞争力，仅仅是锦上添花，就需要考虑当下是否值得投入。我的经验是，对于够用就行的需求来说，花大精力迭代后，用户的感知并不会很强烈，ROI 不一定划得来。比如抖音，推荐流的体验就比对话框要好，用大模型改造完全没有必要。

微软，在这一波浪潮中颇为激进。旗下的产品，从操作系统，到 Office 365、Bing、GitHub 等应用，再到 Azure 云计算都已经全面整合了 GPT 技术。

但站在我的角度看，GitHub Copilot、Microsoft 365 Copilot、Azure 是引领了新方向，但 New Bing 差点意思，像冲动之下的滑稽之举。我不认为它是未来的搜索形态，因底层机制造成的偶尔的胡说八道，总让检索结果的确定性无法得到保证。

相比之下，Google 的方案则成熟和实用很多，并没有改变原有的交互方式，而是在搜索结果顶部空出来一块区域，用以展示 AI 的答案。AI 答案的下方，还是原来链接和摘要式的搜索结果。并且，AI 的答案也不总是会出现。Google 要先行做一层判断，只有当 AI 的答案比较好的时候，才会显示。

大模型并不是在所有的生成式场景中都是利器，它有自己的局限，尤其是需要确定结果的场景。当下，我们需要思考，大模型技术，对自己的业务来说，在什么样的场景中，能够大放异彩。

我觉得大模型在两个方面有着得天独厚的优势。第一，它的理解能力很强，它已经可以很准确地理解人类的自然语言到底是什么意思。第二，它的推理能力很强，听懂了人话之后，它可以据此琢磨接下来要做什么。

优势和局限是并存的。就像我们每个人一样。

找到雪中送炭的场景

具体哪些场景会有机会，我还在不断地学习和摸索。

交个底，到目前为止，我们的产品墨问便签也还未集成大模型。虽然想过一些具体的应用场景，但都一一放弃了，原因还是刚才说的那样，并不刚需，并不迫切。

当下，我的思考框架是这样的：第一，从产品核心竞争力的视角，重新梳理哪些问题是痛点问题。第二，判断问题是否可以被大模型技术较好解决。

比如刚刚结束的 WWDC 上，苹果公司没有怎么提大模型，但可以看到，他们已经把类似的技术融入到具体产品之中，这是偏实用主义的做法。国内比较早集成大模型的协同办公产品钉钉，也是类似。

上周一晚上，我们团队和钉钉的开放平台技术总监孙博文连过一次麦。听下来，我觉得钉钉的问答机器人就是个绝佳的例子，如何用大模型技术，解决原有难以解决的痛点问题。

我稍微解释下这个产品的来龙去脉。最早在钉钉的开放平台中，有一项业务叫做开发者服务，针对开发者的一些疑问进行答疑。最早期，纯人工，每个业务的小伙伴平均每天有 1/3 的时间在答疑。但开发者的问题，有些是技术问题，有些是非技术问题，所以负责答疑的小伙伴还可能需要向运营、产品同学求教，耗时间不说，服务的完结率、满意度都不高。

2019 年，钉钉用了一个基于 FAQ 对话机器人的方案，在机器人的后台界面或者 Excel 里维护常用的问答内容。机器人对问答内容进行匹配，自动地做一些问题回复。算是完成了第一步的自动化。现在很多客服机器人也是这个做法。
但效果非常一般。因为同一个问题，不同的用户会有不同的问法，并且由于问答内容的维护仍是手工维护，所以知识库很难及时更新。

你看，老的技术，在一个老的痛点问题面前，无能为力。但这不，大模型来了。

问答机器人跟大模型的结合，第一，从根本上解决了人工维护知识库的问题。只要将信息给到问答机器人，它就可以自动学习，在一个群里以人类友好的方式，回答用户问题。

第二，问答机器人使用简单，学习成本显著降低。对于机器人的训练已经不需要专门到后台进行了，只需要像发送文件一样将文档（知识）发送给机器人，机器人就可以自动学习。另外如果后续文档有更新或者有新文档，问答机器人也可以自动进行学习。

落地大模型考验的是工程能力

前两天，我们大模型集训班开课。我跟着助教做了一个简单的案例。案例不算复杂，有点像刚刚提到的钉钉问答机器人，或者 ChatPDF。把文档喂给大模型，然后再通过提问的方式，请大模型根据文档内容来回答我的提问。

做一个简单的案例，很容易，大概有三步：

第一步，先把 PDF 的内容，按照段落分块，然后 Embedding 后存入向量数据库。第二步，根据问题到向量数据库做相似度匹配，找到对应的 PDF 文本块。第三步，把问题和文本块一起组装为 Prompt，调用大模型的接口拿到答案。

但案例终归只是案例，如果想要进一步迭代为可用的产品时，还要考虑很多问题。比如段落的检索直接决定问答的质量，这一部分怎么做优化？不同的 Prompt 对于结果的影响很大，怎么做评测？怎么保证大模型的输出是安全的？
所以做一个 Demo 容易，想把 Demo 产品化可没那么简单。就像那天和钉钉孙博文的连麦，我听他讲问答机器人的架构，还挺复杂的。总共有三层，第一层是 UI 交互，第二层是调度，第三层是大模型和基础设施。

UI 交互好理解，就是用户访问的入口。调度层保证核心流程的执行，包括学习流程和问答流程，学习流程包括数据加载、数据处理、数据索引、数据存储，问答流程包括上下文组装、改写、召回、Prompt 组装。大模型和基础设施层包括智能检索、权限系统等等。

总之，从我的实践来看，落地大模型并没有大家传的那么简单，什么 100 行代码就搞定了。100 行代码搞定的只是玩具，想做一个可用的产品，更考验的是团队的工程能力。

钉钉给我的启发

不仅是专属训练的问答机器人，钉钉前阵子面向部分企业用户定向开放了钉钉斜杠“/”的能力，包括了文生文、文生图、会议摘要、群消息摘要、应用生成等多个生成式 AI 能力，我也受邀参与了体验。

现阶段，AI 是 Copilot 不是 Autopilot，这意味着它不可能完全独立于人而存在，只能充当助理的角色。那这就引出一个新问题：在应用中，AI 该如何和人交互？我注意到，钉钉所有交互的起点都是“/”，这很有意思。

在文档中，在聊天窗口中，只要输入“/”，便可以呼出 AI 的能力。在 PC 端，它以浮层的方式出现于界面右侧；移动端，则以浮层的方式出现于屏幕下方。这个看起来颇为朴素的设计，其实很重要，它意味着 AI 无处不在，并且不需要额外的跳转——来也可以匆匆，去也可以匆匆。

举个例子，拍照生成应用。群聊内，我们公司昨天就遇到一个这样的场景：“最近大家都有什么困惑，读过什么有意思的书，我们收集下，然后准备 Q3 的内容规划。”

我们并不想让大家直接发消息到群聊，因为难以整理汇总。惯常的做法是切出群聊，找到表单类的应用，根据刚才的需求生成一个表单，然后再发链接到群内。这是过去的做法，让人烦的是它需要在应用间来回切换。

现在，钉钉不需要这么复杂了。理解了需求后，我作为负责人，只需要快速在纸上画出一个表格，然后在群聊窗口中通过“/”唤起智能助手，即可拍照生成应用，并将应用快速安装在群里直接使用。如果生成的应用不合适，也可以通过对话的方式修改选项和字段，非常方便。

应用安装到群聊之后，其实就是之前钉钉一直在推行的酷应用。也就是说，我们不再需要纷繁的跳转以及配置，简单的应用，结合 AI，只要几步，便能生成酷应用，一站式地在群聊内完成对应的工作。

AI 的能力，融入到应用中，如润物般细无声。无迹可寻，又无处不在。

钉钉早几年一直在宣传酷应用。但我觉得，前几年酷应用最大的挑战是它仍需要企业 IT 人员的介入，这对于很多企业而言，是一个鸿沟。现在，基于大模型的能力，业务人员可以很轻松地完成大部分酷应用的生成，不需要代码，不需要额外的学习...... 大幅度降低了使用门槛。

“/”呼起 AI -> 拍照生成应用 -> 群内酷应用，这条新链路，就是一个很好的大模型应用场景。如果你正在思考自己的产品（特别是 ToB 的产品）该如何融入大模型，那建议你可以参考下钉钉的设计。