这一年半时间里，我一直在思考AI时代里我们正在做的产品未来的形态是什么样的。去年参加一些AI创业大赛的时候，我想到了一个词：“知识交付”。去年“赢在AI+”比赛之后，我专程请教了担任评委的檀林老师。他说我们做的是一种类似“专家即服务”的业务，不过对于这种新业态的交付模式，依然不是很清晰。其实要做什么样的产品，有一个最简单的答案：“做客户需要的产品”。这个答案似乎有点无厘头，不过确实是最为正确的答案。那么客户需要什么样的产品呢？客户买一个产品买的是什么呢？是源代码？是UI？是软件中带有的管理思想？仔细想来似乎都不是。客户买某个软件，是希望通过购买这个软件中的能力来提升他们的业务或者管理，达成了此类目标，客户买软件的目的才算达到了。客户买某个软件或者服务的本质是购买交付物背后的能力给他们带来的实际结果，但是他们只能通过购买某个套装软件或者购买定制化开发服务来达到这个目的。定制化开发服务虽然更加灵活，不过成本也更高，而且因为需求描述的不准确，以及ISV的能力存在缺陷，因此客户其实很难购买到特别好用的软件产品。

以前交付一套定制开发软件的时候都要求交付源代码，不过对于大多数企业来说，交付源代码的意义并不大，虽然要求ISV交付了源代码，但是自己也是没有能力在此基础上维护和发展这套系统的。购买定制开发系统与买套装软件差别其实并不大，如果要持续改进，哪怕调一个很小的小功能，加一张报表也必须继续给ISV付钱，没办法真的对着源代码自己搞定的。AI时代开启之后，未来的大部分软件都不是直接给人使用的，而是给AI使用的。因此软件的形态与软件的交付形态也必将发生颠覆性的变化。未来的软件可能不仅是交付一套可执行的代码和源码，而是交付一个可持续构建业务能力的平台。系统本身不仅包含了数据采集、处理的关键组件，还包含了使用和分析数据的工具和知识库，并包含了一整套如何使用这些工具的说明书（skills）。在这套软件中，必须有一个规划专业任务的大脑-PlanEngine。甚至今后企业的IT系统中必须有一个独立的PlanEngine，可以将企业中的数据通过工具，在PlanEngine的调度下高效地利用起来。围绕这个核心，购买了某个软件后经过简单的集成就可以融入企业已有的系统中，成为企业基础能力的一部分。

在前阵子我有了这个初步构想之后，就着手在公司实践，基于这个构想，在我们即将发布的BIC-IA v9.1中增加了这样的一个PlanEngine，围绕PlanEngine我们发布了一种新的软件功能-“运维场景”。实际上运维场景是一系列预制的Skills（可以出厂自带，也可以用户自定义），描述了如何使用BIC-IA内置的数千个工具，或提取数据、或分析数据、或验证推理结果，最后利用AI大模型的推理能力来完成特定的运维工作。比如你可以定义一个场景：“找出当前系统中健康分低于80分的数据库系统，逐一做健康检查，如果发现存在IO方面的问题，则分析存在IO问题的数据库之间是否有某些关联性（比如使用相同的存储、相同的SAN交换机等），如果发现存在TOPSQL方面的问题，则进一步做一下TOPSQL分析，最后生成一份分析报告，发送到某些相关人员的邮箱里。”。这个场景原本利用系统中的各种工具和功能，依靠人工是可以完成的，不过点击界面的工作量不小。而在软件出厂的时候，很难根据用户的需求穷举这类的运维场景，定制化开发则增加了客户的成本，对于产品厂商来说，也是不小的负担。

如上图所示，基于AI时代软件产品的新特性，用户拿到BIC-IA产品的时候，获得了软件本身的功能的同时，还拿到了一个数据库运维工具箱。CLI-TOOL是PlanEngine为客户预留的能力扩展界面，用户可以利用这个工具充分挖掘BIC-IA的潜在能力，构建适合自己的运维工具。场景工具则支持用户按需扩展自己的运维场景需求，知识工具可以让客户输入新的知识和案例，自动更新知识库。

一些规模较小，自身研发能力不足的用户可以使用我们的产品和已发布的“运维场景”工具来完成自己的运维工作，未来我们也将会不断发布新的“运维场景”，通过下载就可以获得。而对于一些规模较大，自主运维能力较强的用户则可以借助工具箱来定制更加符合企业运维工作模式的智能工具。通过将自己的运维意图和思路编写成一种特殊的Skills-“运维场景”，以此更好地利用平台的基础能力来服务于自己的日常工作。