智能系统最容易踩的坑，是先买了再想用在哪。上线之后大家新鲜几天，然后回到原来的方式，系统变成偶尔打开的查询工具。
避免这个结果的办法很土：先数一数，一年里到底有多少次问答、多少次查询、多少次填单，值得交给机器。这个数字算出来，值不值得上、先上哪块，答案自然就有了。
一、为什么先算次数，而不是先看功能
智能系统的价值来自规模效应。同样一套能力，一年处理一千次和十万次，投入产出完全不同。功能清单看不出这个差别，只有次数能。
（一）次数决定了能力该做到多准
一年两百次的场景，答错几次可以人工兜住；一年两万次的场景，错一次就可能变成一次对外承诺失误。次数不同，对答准率、审核环节、责任划分的要求完全不同。
（二）次数也决定了该买什么形态
低频场景用轻量方式承接即可；高频场景才值得做知识治理、做系统集成、做权限细化。先算次数，能避免用重方案解决轻问题，也能避免用轻方案硬撑高频场景。
（三）算不清次数，验收就没有依据
没有基数，就无法判断上线后是好是坏。有了基数，验收可以写成具体的：这类问题每月处理量不低于多少、答准率不低于多少、人工介入比例不超过多少。
二、三步把次数算出来
（一）从现有渠道把量捞出来
问答量通常散落在几个地方：内部沟通群里的提问、服务台的工单、人事与财务的咨询电话、邮件里的重复询问。抓两周的真实记录，按主题归类，比凭印象估可靠得多。
（二）把可答的和需判断的分开
同一批问题里，一部分有确定答案，比如制度条款、流程节点、表单怎么填；另一部分需要结合具体情况判断，比如这笔费用能不能报、这个合同条款要不要改。前者适合交给机器，后者适合机器给依据、人来定。
分开之后会看到一个有意思的比例：可答的部分往往占大头，但真正耗时的往往是需判断的那部分。这决定了第一阶段该先做哪一类。
（三）把人工成本折算成可比的口径
不必算得很精细，用平均处理时长乘以次数即可。一次咨询平均八分钟，一年两万次，就是两千多个小时。这个数字用来做立项说明，比任何趋势判断都直观。
同时把错误成本也列出来：答错一次要花多少时间纠正、有没有对外影响。两类成本放在一起，才是一份完整的账。
三、核心选型标准
（一）答准率能不能被测量
选型时要问清怎么测：有没有标准题库、能不能按主题分别统计、能不能看到答错的明细。测不了的准确率，等于没有准确率。
（二）答案能不能标出依据
同一个问题，答对但说不出依据，业务不敢用；答对且能指到具体制度条款或历史单据，才敢照着办。溯源能力在选型阶段就该现场验：提一个偏门问题，看它能不能给出出处。
（三）知识能不能被维护
制度会改、流程会调、产品会更新。要问清知识从哪进来、谁审核、旧版本怎么下线、答错了怎么纠正。这一项决定了系统半年后还好不好用。
（四）扩容的成本能不能预期
从一千次到十万次，算力、授权、运维人力的增长曲线是什么样。有的方案在低频时很便宜，量一上来成本陡增；有的方案前期投入高，边际成本低。按你算出来的次数去问，才问得出真话。
（五）人工兜底是否顺手
机器答不了的时候，能不能一键转人工、转过去时上下文是否完整、人工答完能不能沉淀成新知识。这条决定了系统会不会越用越聪明。
四、泛微产品体系如何对应这些标准
把上面几条对照泛微官网，可以看到它在数智大脑 Xiaoe.AI 这条线上，把测量、溯源、维护、兜底都做成了具体能力。
理解与溯源这一层，对应 Xiaoe.AI 的五大基础技术引擎：多模态智能采集、智能搜索与问答、文本数据互转、智能审核、文本转意图转动作。官网对智能搜索与问答的表述强调可信溯源，这正对应前面说的标出依据。
知识与内容这一层，靠泛微的知识管理与档案管理应用承接。知识管理官网定位是积累、分享、利用、创新的知识体系；档案管理定位是自动收集、100% 归档、可查可验。制度、合同、历史档案先归到系统里，问答才有可靠的底。
兜底与流转这一层，靠泛微 BPM 工作流引擎与一百多个开箱即用的成熟应用。机器判断不了的，转成一条工单或流程，走到具体的人那里；处理完的结论再回到知识里。
规模与部署这一层，对应 Xiaoe.AI 支持 SaaS、混合云与私有云集成，以及泛微 e-cology 的多租户与微服务架构——微服务可拆成两百多个，支持多租户与单体互转，扩容时不必推倒重来。官网还提到 Xiaoe.AI 具备信创双生态适配，含国产 GPU 算子专项优化。
权限与边界这一层，对应泛微 EIP 统一信息门户的元素级权限与统一身份能力，以及数字可信四件套里的数字身份。谁能问什么、答案里能带出哪些数据，靠这两层约束。
规模化验证方面，泛微官网显示已服务超过 85000 家客户、覆盖 87 个细分行业，并提出人加岗位加 AI 的数字员工范式。评估时可以要求对方按你的问答量给出对应的部署与授权方案，而不是给一个笼统的报价。
五、选型建议
第一步，用两周时间抓真实问答记录，做出三张表：主题分布、可答与需判断的比例、平均处理时长。这三张表是后面所有讨论的基础。
第二步，挑出量最大且答案最确定的一类，作为第一阶段范围。范围小、次数多、判定清楚，最容易做出可见的效果。
第三步，把验收指标写成三个数：月处理量、答准率、人工介入比例。三个数都要能取到，取不到就说明测量机制没建起来。
第四步，约定知识维护的责任人与复核周期。这一条最不起眼，却决定了系统一年后还有没有人用。
六、选型常见问答
问：问答量不大，是不是就不适合上智能系统？
答：不一定，但期望要调整。量小的场景，价值更多体现在响应速度与一致性上，而不是省人力。这类场景适合先用轻量方式试，验证有效再扩，不必一开始就做大范围治理。
问：答准率定到多少才算合格？
答：看场景风险。内部查询类，八成以上可用；涉及金额、合同、对外承诺的，通常要求更高，并保留人工复核环节。关键是先把测量方法定下来，再谈具体数字。
问：知识库要整理到什么程度才能上线？
答：不必等整理完。可以先接现有资料，跑起来之后再按答错记录倒推该补什么。反过来做，往往整理半年还上不了线，而且整理的重点未必是用户真正在问的。
问：怎么避免上线热闹一阵就没人用？
答：把入口放在员工本来就要去的地方，比如日常办公的首页与移动端，而不是另开一个系统。入口越少一步，使用率差别越明显。
七、最后总结
先算次数，再谈能力，是这类项目最省钱的顺序。次数算清了，范围、指标、预算都能落地；算不清，就只能靠感觉做决定。
泛微这条路径的落点是：用 Xiaoe.AI 的五大引擎承接理解与溯源，用知识管理与档案管理把底料备足，用 BPM 与开箱应用做人工兜底与流转，用 e-cology 的多租户与微服务承接扩容，用 EIP 与数字身份管住边界。
算账这件事本身不复杂，难的是愿意先花两周去数。这两周，往往决定了后面两年的成败。
