ARTICLE · 1217317
传统软件教人用,AI 软件主动找人
软件做完了，为什么还要培训用户？
因为功能是程序员写的，活儿是用户干的。
开发团队把业务拆成菜单、按钮、表单和流程，再教用户去哪里点、往哪里填、下一步找谁审批。
系统有自己的逻辑，人要学会配合它。
我认为，企业软件的 AI 化，就应该从这里翻过来。
过去，是人学会使用系统。
以后，是系统读懂业务数据，做好评估，再主动找到需要处理这件事的人。
拿这把尺子去看，很多所谓的 AI 软件，只走到了加一个聊天框。
功能交付了，事情还是得靠人盯
传统 IT 软件的交付逻辑，很清楚。
人提出需求，人写好功能，再培训另一批人使用。
库存查询做好了，采购自己进去查。客户管理做好了，销售自己进去看。项目看板做好了，负责人自己进去盯。
系统负责把数据摆出来，人负责看懂数据、发现问题、决定行动。
没人看，报表就只是报表。没人追，任务就一直挂在那里。没人把几张表、几段沟通、几个部门的进展连起来，问题就藏在各自正常的数据里。
功能验收时，每个按钮都能点通。到了业务现场，一件事能不能推进，还是取决于有没有一个人惦记着它。
企业已经把数据交给了系统，为什么还要让人每天去捞，去翻，去拼，才能知道今天该干什么？
如果软件只是让人换个地方继续盯着工作，最费注意力的那部分，根本没有被接过去。
聊天框换了入口，没有接走这份工作
给系统加上聊天框，操作确实方便了。
以前找菜单，现在打一行字。以前点几次按钮，现在说一句话。
但如果用户不问，系统就不动，驱动工作的还是人。
人要先发现不对劲，才会问哪里出了问题；人要先想到某个客户，才会问最近有没有进展；人要先意识到交付可能延期，才会让 AI 帮忙分析。
发现问题这份工作，依然原封不动地留给了用户。
甚至还多了一门功课，学习怎么向 AI 提问。
从培训用户点按钮，到培训用户写提示词，系统看起来变聪明了，人还是得先伺候好它，它才肯干活。
企业花钱买 AI，不该只是买到一个更容易叫醒的系统。
同样三个客户，系统得先判断该找谁
拿客户跟进，做一个具体的假设。
三个客户，都是七天没有联系。
甲客户约好了下个月预算通过后再谈。乙客户还在初步了解产品，没有提出具体采购计划。丙客户后天做供应商评审，上次要求补一份部署说明，技术部门昨天已经把材料上传，销售还没发出去。
在客户列表里，他们都只是七天未跟进。
销售得逐个点开，翻沟通记录，查内部进度，才能知道今天先处理谁。
加了聊天框，可以问一句，今天优先跟进哪个客户？
AI 化系统应该先完成这轮评估，主动找到丙客户的销售负责人。
为什么是丙？
因为它把三处信息连起来了。客户沟通里有评审时间，待办里有尚未完成的承诺，技术文档里有已经齐备的材料。
甲暂时没有到约定时间，乙还缺少具体采购信号。丙有明确的决策窗口，有尚未补齐的评审材料，而且现在就能推进。
时间紧，影响直接，行动条件已经具备。
评估的结果，应该变成这样一次主动联系。
「客户后天进行供应商评审，目前还缺我们承诺的部署说明。技术材料昨天已齐备，建议今天优先发送。我已整理好说明和回复草稿，请确认。」
销售收到的，已经是一件可以处理的事。
他不用先想起这个客户，再去发现这处卡点。系统已经把为什么现在处理、材料在哪里、下一步做什么，一起送了过来。
如果卡在材料没准备好，系统就先找技术负责人，把缺什么、影响哪次评审、何时需要补齐讲清楚。
评估结果决定找谁，业务进展决定什么时候找。
发一句「你有一项待办」，让用户再去翻完记录、重新分析，交付的只是另一种铃声。
交付标准，也该跟着变了
过去做软件，先问要什么功能，再决定做什么页面，最后教用户怎么操作。
现在做 AI 化软件，应该先问哪些业务值得持续评估，数据变化会影响什么，什么结果需要找人，由谁接下去处理。
前一种思路，把功能交给人，让人组织工作。后一种思路，让系统先组织工作，再把需要人决定的那一步交出来。
所以，不能再只拿登录率和使用时长评价它。
用户每天打开十次系统，可能恰恰是因为它什么都要人盯。
更应该追问的是，系统替用户评估了什么，提前发现了什么，把什么事情交给了谁。
回到刚才的客户。价值就发生在销售还没想起这件事的时候，系统已经评估出它的优先级，把材料准备好，找到了他。
这也是我们看待 Framefly 产品方向时，应该坚持的标准。用户把数据交进来，系统就该承担起从数据走向行动的工作。
软件的 AI 化，要改变谁在主动推进工作。
传统 IT 的交付，是功能做好了，请你来学。
AI 化软件的交付，应该是事情看明白了，现在需要你做这个决定。
