夜雨聆风
AI MODEL CENTER · BUSINESS PRACTICE 012
真正的企业AI项目，不是从选模型、买算力或搭聊天页面开始，而是从一个可验证的业务任务开始。十二个问题的目的，不是增加沟通成本，而是判断这笔预算能否形成真实业务价值。
客户：“我们想做一个企业AI助手，能够查资料、写报告、回答员工问题，最好还能接ERP和CRM。”
我们：“可以。先不急着谈模型，能否先回答十二个问题？”
这类对话几乎每天都在发生。模型能力越来越强，做出一个能聊天、能搜索、能调用接口的原型并不困难。真正困难的是：这个助手究竟替谁完成什么任务？它依赖的数据是否可信？它能动哪些系统？做错以后谁负责？企业准备怎样验收？
如果这些问题没有答案，项目越快进入开发，越容易把不确定性推到后面。Demo可能很漂亮，业务却没有改变；系统可能能够运行，员工却不愿意使用；接口可能已经接通，权限、责任和异常处理却没有设计。
核心观点
AI助手不是一个完整需求，“可执行任务”才是需求。业务诊断不是项目的前置闲聊，而是决定技术路线、交付范围、预算结构和验收标准的第一项工程。
企业真正需要的不是“一个什么都懂的聊天框”，而是一个在明确边界内稳定完成任务的业务系统。
图：智算AI实验室原创知识图
一、为什么今天不再从模型开始谈？
前几篇文章，我们已经依次讨论了模型、工具工程、记忆工程、企业第一笔AI预算、PoC和生产验收。走到今天，问题应该继续向业务现场推进：当一家企业真的准备启动项目，第一周到底应该做什么？
近期企业AI研究也在反复强调同一件事。McKinsey在2025年全球AI调查中指出，企业已经广泛使用生成式AI，但真正形成规模化财务影响的组织仍然有限；领先者与普通采用者之间的差异，更多来自工作流重构、领导责任和规模化机制，而不是有没有拿到某个模型。OpenAI面向企业的研究同样把重点放在业务上下文、数据连接、工具、权限、评测和持续改进上。
换句话说，模型决定能力上限，但项目能否落地，取决于企业是否把“想要一个AI助手”翻译成“让AI在什么流程里，以什么权限，完成什么可验收任务”。
一次有效的项目诊断，至少应冻结十二个关键问题、一个业务闭环和三类结论：进入试运行、继续优化或停止项目。
图：智算AI实验室原创知识图
二、第一组问题：业务——它到底替谁完成什么工作？
“企业AI助手”只是产品形态，不是业务定义。我们会先把它放回真实流程中，找到明确的使用者、触发条件、输入、动作和结果。
问题1：谁是第一批真实用户？
是售后工程师、客服、销售、采购、设备运维人员，还是所有员工？不同岗位对答案深度、响应速度、权限和操作界面的要求完全不同。“全公司都能用”通常不是第一阶段的有效用户定义。
问题2：他们现在怎样完成这个任务？
要看真实流程，而不是流程图：资料在哪里找、需要问谁、需要切换几个系统、平均耗时多久、哪一步最容易返工。没有当前基线，就无法证明AI带来了价值。
问题3：助手要交付什么明确结果？
“回答问题”过于宽泛。更可执行的描述是：根据设备型号和故障代码检索手册与历史工单，给出带来源的排查建议；根据客户沟通记录生成符合模板的拜访纪要；根据合同和制度完成条款核对并标出风险。
问题4：结果之后，业务还会发生什么？
如果员工看完回答仍要手工登录系统、复制内容、创建工单、填写字段，AI只缩短了一个信息环节。需要判断它是给建议、生成草稿，还是在审批后完成动作。下游流程决定工具集成与风险等级。
先把“做一个AI助手”改写成：
让某类用户，在某个场景中，更快、更稳地完成一项可检查任务。
三、用一个典型场景，看看需求是怎样被重新定义的
以下为典型场景示例，用于说明诊断方法，不对应具体客户。
一家制造企业希望做“工业售后AI助手”。初始需求是：把设备手册、维修记录和产品资料放进知识库，工程师输入问题后，由AI给出答案。
经过业务访谈后，需求被改写为：工程师在现场输入设备型号、故障代码和现象；系统检索有效版本手册、备件清单和历史维修记录，输出带来源的排查顺序；如需备件，查询库存并生成工单草稿；涉及停机、控制参数和安全风险的建议必须由指定人员确认。
这两段描述看似只差几句话，技术范围却完全不同。前者是一个问答Demo，后者才是包含身份、数据版本、检索、工具、权限、人工确认、日志和验收的业务系统。
知识助手进入生产后，数据摄取、检索服务、模型、前后端和真实用户共同进入一条业务链路。问题不再只来自模型。
图源：Google Cloud Architecture Center · RAG infrastructure for generative AI
四、第二组问题：数据——AI到底可以相信什么？
问题5：完成任务需要哪些数据？
列出真实数据源：制度文件、产品资料、设备台账、历史工单、CRM记录、合同、邮件、表格、图片或实时传感器数据。不要先说“做知识库”，先说完成任务需要哪些事实。
问题6：谁对这些数据的正确性负责？
生产系统必须知道权威来源、内容责任人和更新周期。多个版本冲突时，不能让模型自己选择；制度废止、产品升级和人员调岗后，也要有明确的同步与失效机制。
问题7：不同用户能够看见哪些内容？
权限要在检索前生效。部门、岗位、项目、客户和保密级别都可能决定可见范围。模型读过敏感文件后再要求它“不要泄露”，不是可靠的权限设计。
问题8：数据质量足以支撑哪类结论？
扫描件是否可识别、表格字段是否统一、历史记录是否有缺失、标签是否可靠、少数困难场景是否被覆盖，都要在项目初期抽样验证。数据数量不是唯一标准，和任务的匹配程度更重要。
生产RAG并不是“文档切片＋向量库”。它包含数据摄取、处理、元数据、索引、检索、服务、工具和持续更新，每一层都需要责任和监控。
图源：Google Cloud Architecture Center · RAG infrastructure for generative AI
数据诊断应该交付什么？
不是一份“已有多少GB文档”的统计，而是数据源清单、样本质量报告、版本与权限规则、更新方式、缺口与风险，以及哪些数据能够进入第一阶段。
五、第三组问题：系统——它只读，还是会真正行动？
问题9：助手需要连接哪些系统？
ERP、MES、CRM、工单、OA、邮件、文件系统和数据库的接口成熟度不同。要逐项确认认证方式、字段、频率、超时、限流和负责人，而不是在方案里写一句“支持系统集成”。
问题10：哪些动作允许自动执行？
查询库存与修改库存不是同一风险；生成工单草稿与直接派单也不是同一风险。建议把动作分成三类：低风险自动执行，中风险人工审批，高风险默认禁止。所有写操作都要考虑幂等、重试、回滚和审计。
一旦AI能够调用工具，它就不再只是内容生成器，而成为业务执行角色。接口成功不等于任务完成；超时以后状态未知、重复提交、字段变化、权限过期和外部系统不可用，都必须有明确处理路径。
端到端企业架构需要把数据、构建、验证、注册、部署、服务、监控和制品管理连接起来。一个聊天页面只覆盖了其中很小的一部分。
图源：Google Cloud · Enterprise GenAI and MLOps blueprint
六、第四组问题：验收与责任——怎样证明它值得上线？
问题11：什么结果算成功？
需要把“效果不错”改成可复核指标。知识助手可以看有来源答案率、任务解决率、无答案识别率和平均查找时间；客服看一次解决率、转人工率、处理时长和错误操作；工业场景还要单独看漏报、误报和高风险建议。
问题12：做错以后，谁发现、谁接管、谁负责？
必须明确业务负责人、数据负责人、技术负责人和风险负责人。系统要知道何时停止、怎样转人工、如何携带上下文、怎样撤回或回滚，以及什么情况必须暂停服务。
风险不是一句“增加人工审核”就能解决。应按影响程度与发生可能性分类，再决定自动执行、审批、限制或禁止。
图源：Microsoft Learn · Agent risk impact and likelihood map
正式验收还需要冻结测试集和基线。开发过程中反复优化过的演示问题不能作为唯一证据；测试集应覆盖正常、困难、边界、异常和安全样本，并记录检索来源、工具调用、最终结果和失败类型。模型、知识库、Prompt或接口升级后，都要回到同一套样本做回归。
可重复评测应固定测试问题、成功标准和运行记录，让不同版本能够比较，也让失败样本进入下一轮改进。
图源：Microsoft Learn · Run evaluations and view results
七、十二个问题问完，我们不会立即给出“做或不做”
业务诊断的价值，不是用一场会议得出武断结论，而是把未知项变成可以验证的工作。对一个有潜力的场景，项目启动第一周至少应该交付五份材料。
场景说明、数据样本报告、当前业务基线、PoC验证边界和验收与停止条件，决定后续技术投入是否有依据。
图：智算AI实验室原创知识图
01 场景与边界说明
用户、任务、输入、输出、允许动作、禁止动作，以及第一阶段明确不解决的问题。
02 数据样本报告
真实样本、权威来源、质量缺口、权限和更新规则，不用理想化数据代替现场。
03 当前业务基线
处理量、平均耗时、人工成本、返工和错误，让价值改善可以被计算。
04 PoC验证计划
测试用户、数据范围、功能边界、工具范围、时间和预算，防止PoC无限扩张。
05 验收与停止条件
达到什么标准进入试运行，哪些问题继续优化，哪些结果意味着应停止项目。
真正的输出
不是一个“看起来什么都能做”的承诺，而是一份可执行、可验收、可控制风险的项目定义。
八、我们更愿意按五个阶段推进，而不是一次做大
每一阶段都有退出条件。先冻结场景，再验证数据、完成PoC、进入受控试运行，最后才决定生产运营。
图：智算AI实验室原创知识图
阶段一：场景诊断
梳理流程、用户、任务、基线、风险和价值，选择一个高频、可检查、影响边界清晰的业务闭环。这里可能得到的结论也包括“当前不适合做”。
阶段二：数据验证
用真实数据抽样，不先做大规模知识库。验证数据是否可获得、可处理、可授权、可更新，以及困难样本是否足以支撑目标。
阶段三：PoC验证
在冻结样本和明确边界内，把模型、RAG、工具、权限和日志连成端到端原型。PoC证明的是技术路径和业务假设是否成立，不是直接证明可以全量上线。
阶段四：受控试运行
选择小范围真实用户，限制数据、动作和流量。重点观察采用率、任务完成、异常、成本和人工接管。没有真实使用，就无法知道系统是否真正进入工作流。
阶段五：生产运营
完成持续评测、权限审计、版本管理、故障恢复、成本监控和责任分工。上线不是项目结束，而是开始获得真实反馈和持续优化的起点。
如果只有30天，验证节奏应该怎样安排？
第1周冻结问题。业务负责人和一线用户共同确认用户、任务、输入、输出、风险、人工基线和成功条件。技术团队同时抽查真实数据，确认接口和权限是否具备基本条件。第一周结束时，应该能够用一句话说清项目解决什么、不解决什么。
第2周建立基线。整理一批未经开发团队挑选的真实样本，记录人工处理结果，建立第一版冻结测试集。知识类任务要标注权威来源和版本，动作类任务要列出允许、审批和禁止的边界。此时如果数据不可获得或结果无法判断，应暂停开发，而不是用模拟材料掩盖问题。
第3周做端到端原型。把模型、检索、工具、权限、日志和人工确认串起来。重点不是把页面做得多漂亮，而是跑通一个完整任务，并让每一步都能够被追溯。接口失败、无答案、低置信、越权和重复提交等异常路径也要在这一周主动测试。
第4周用真实任务压测。让小范围真实用户在受控环境使用，比较任务完成率、处理时长、人工复核、错误类型、响应速度和单位成本。最终结论只应该有三种：进入试运行、继续优化或停止项目。不是所有PoC都应该上线，及时停止一个价值不足或风险不可控的项目，同样是在保护企业预算。
30天验证的正确产物
不是一场领导演示，而是一组可以复核的证据：业务指标是否改善，真实数据是否可用，系统异常是否可控，关键风险是否有责任人，以及下一阶段为什么值得继续投入。
九、什么样的企业AI助手值得优先做？
更适合优先验证
任务高频、流程相对稳定；输入和输出清晰；结果能够人工检查；已有可用数据；错误影响可限制；业务负责人愿意参与验收。
不适合急着启动
目标是“所有员工都能问”；没有权威数据源；希望AI替代尚未理顺的流程；高风险动作无法审批；没有业务负责人；无法定义成功和停止条件。
一个项目是否启动，不取决于模型演示有多惊艳，而取决于业务、数据和系统三个前置条件是否成立。验收与治理则必须从第一天设计，而不是上线前临时补材料。
业务价值可验证、数据可治理、系统与权限可集成，是项目值得进入PoC的三个前置条件。
图：智算AI实验室原创知识图
十、我们怎样把业务诊断转化为可交付项目？
智算AI实验室更愿意从一个可验证的业务闭环开始，而不是先销售一个“万能AI平台”。根据场景需要，我们可以协助企业完成：
- AI场景诊断：
业务流程、价值、风险、优先级和项目边界； - 数据与知识工程：
清洗、切分、版本、权限、更新和知识库建设； - 模型工程：
模型选型、提示策略、微调、量化、推理优化和正式评测； - RAG与智能体开发：
检索、记忆、工具调用、工作流和人工协同； - 系统集成：
ERP、MES、CRM、工单、OA与企业内部接口； - 安全与治理：
身份、权限、审批、日志、监控、回退和审计； - PoC与生产部署：
受控验证、私有化部署、上线验收和持续运营。
我们的项目判断标准
我们不会把“聊天页面可以运行”作为项目完成，也不会把所有PoC都推向生产。真实任务能否稳定完成、数据是否可信、异常能否处理、责任是否清晰、价值能否量化，才是是否继续投入的依据。
如果您正在考虑企业知识助手、工业智能体、售后助手、客服助手或内部办公助手，第一次沟通可以先准备三样东西：谁使用、要完成什么任务、数据现在在哪里。很多关键判断，会从这三项开始。
结语：好的企业AI项目，第一步不是写代码
当客户说“想做一个企业AI助手”，立即讨论大模型参数、向量数据库和算力配置，看起来很专业，却可能跳过最重要的工作：把真实业务问题定义清楚。
十二个问题不是标准答案，也不是故意把项目复杂化。它们是在帮助企业提前发现：价值是否存在、数据能否支撑、系统能否连接、风险能否控制、结果怎样验收。越早暴露这些问题，越能减少后期返工和无效投入。
模型越来越强以后，企业AI竞争不会只发生在“谁先用上模型”，而会发生在谁能更快地把模型、数据、工具、权限和人，组织成一个长期运行的业务系统。
从一个可验证的业务闭环开始，让AI真正进入工作，而不是停在演示。
图：智算AI实验室原创知识图
今天记住三句话：
AI助手不是需求，可执行任务才是需求。
先冻结业务与数据，再选择模型与技术。
没有验收和退出条件，就没有可控的AI项目。
智算AI实验室 · 让AI进入真实业务流程