7
0### p01 AI 不懂业务？先补企业认知底座
AI连公司的审批和客户规则都弄不清，问题可能不在模型，而在企业认知底座。它能回答问题，不代表已经理解你们的业务。今天讲清楚：如何把业务对象、规则和操作整理出来，让AI有据可查，也知道行动的边界。
### p02 文件都有，为什么仍然理解错？
企业里经常出现这种情况：员工手册、审批制度和客户资料都放进知识库了，AI仍然给出不适用的答案。因为找到文字，只解决了信息检索。它还要知道当前客户是什么状态，合同适用哪一版规则，谁有权处理例外。同一个客户，在销售、财务和运营的系统里还可能是不同的定义。
### p03 先认清对象，再认清关系与动作
可以参考Palantir对本体的官方说明：它既包含对象、属性和关系，也包含支持业务行动的机制。用管理者的语言说，就是客户、订单和合同分别是什么，它们如何关联，允许进行哪些操作，以及谁能操作。这里是借用一种建模思路，不是要求每家公司都购买同一套平台。
### p04 用线索分配，检验业务是否说清楚
用线索分配举个例子。先定义线索和客户，弄清楚状态及关联。再写明地区、行业和客户归属规则，标出版本和生效条件。接着明确谁能查看、谁能修改。遇到重复客户或归属冲突，应该交给谁确认。把这些问题说清楚，AI才有机会给出可解释的分配建议，而不是凭一句提示词猜测。
### p05 隐性经验，要变成可核验的规则
隐性经验很重要，但不能把老员工脑子里的所有习惯都直接交给AI执行。先通过访谈和现场观察，把判断条件和例外记录下来。再请业务负责人核验：这条规则是否仍然有效，有没有制度依据，适用于哪些情况。涉及权限、个人信息或不合理的潜规则，还要先纠正。认知底座的价值，是让经验变得可解释、可检查。
### p06 先形成可运行的小闭环
落地时，我建议先做一个小闭环。整理实际流程和规则，把它们映射到数据、接口和权限。用正常情况与例外样本验证，先让业务人员核对AI的建议。验证通过后，再在允许的范围内处理任务，复杂情况继续人工复核。最后建立更新机制。规则变了，业务描述和测试也要一起更新，不能整理一次就永久不管。
### p07 认知底座是否有用，要看业务验证
怎么验收这套底座？不要只数整理了多少条规则。先看答案能否追溯到正确对象、数据来源和规则版本。再看例外是否处理正确，以及操作有没有遵守权限和审批要求。最后观察流程质量和处理效率。收益要在你自己的业务中验证，不能用一个来历不明的ROI倍数替代。
### p08 今天先把一个流程说明白
今天可以先找业务负责人和一位熟悉实际操作的员工，把一个小流程说明白。列出对象、规则、例外和责任人，再拿真实案例检查是否漏了东西。这张表不是完整的技术本体，但它能帮助你判断，业务究竟清不清楚。关注AI落地实践，我们继续把这些方法落到具体的企业场景里。
