企业想做 AI， 第一步到底应该判断什么？
企业内部通常不缺 AI 想法，真正稀缺的是把想法排出优先级，并判断哪一个值得进入验证或开发。
第一步不是选模型、买工具或先做一个聊天机器人，而是找出一个真实、重复发生、正在付出明确成本的业务问题。随后确认它能否被拆成稳定流程、是否有可用数据与系统、哪些动作必须人工负责、结果怎样验收。只有业务价值、实施条件和风险边界同时成立，才决定自助使用、咨询诊断、最小验证或正式开发。
先用四个维度筛掉不值得做的方向
一个场景听起来有未来，不等于现在适合投入；先比较价值、可行性、风险和复用性。
业务价值
是否减少等待、返工、错误或重复劳动，是否改善响应速度、服务质量或订单机会。
实施条件
数据、文档、系统、接口、责任人和测试样本是否能够获得并持续维护。
风险边界
错误是否可被发现和回退，价格、合同、质量、权限等高风险动作能否保留人工确认。
复用潜力
首个场景形成的数据、规则、工具和流程，能否支持更多部门或后续场景。
从真实问题走到可执行项目
先形成业务结论，再选择技术；让每一步都留下可用于继续或停止的判断依据。
- 01本步形成问题定义卡
写清业务成本
描述谁在什么情况下做什么、当前需要多久、哪里容易错、影响哪项业务结果。
- 02本步形成业务流程与卡点图
拆解现有流程
画出输入、判断、资料、系统、动作、审批和异常，找出真正的等待与重复节点。
- 03本步形成数据与系统清单
盘点数据与系统
确认资料在哪里、版本是否可信、能否检索、有哪些接口与权限，避免方案建立在不存在的数据上。
- 04本步形成责任与风险矩阵
划定人工边界
标出建议、草稿、低风险执行和高风险承诺分别由谁负责，定义中止与回退机制。
- 05本步形成验收与基线表
定义验收指标
选择响应时间、错误率、完成率、人工咨询次数、转化等可观察指标，并记录改造前基线。
- 06本步形成优先级与下一步路线
决定项目方式
低风险个人任务可先自助；跨部门或高价值流程进入咨询、验证或正式开发。
这些情况不适合马上进入开发
- 问题只有一句愿景
“做一个企业大脑”无法定义用户、流程、数据和验收，应该先缩小到具体业务节点。
- 数据没有责任人
资料长期无人维护、版本冲突且权限不清时，应先做数据治理。
- 结果无法验收
如果团队不能说明什么叫更快、更准或更有价值，项目上线后也无法判断是否继续。
- 高风险动作要全自动
报价、合同、质量承诺、付款和正式对外沟通应先保留人工确认。
用真实项目与行业路径理解这项判断
案例只呈现能够公开、能够核验的事实与方法，不把规划、样例或阶段观察写成最终结果。
结论需要回到企业的真实条件
AI 项目优先级必须结合企业当前目标、流程、数据和风险判断。高影响场景不一定低成本，低成本试验也不一定值得规模化；咨询结论可以是进入开发，也可以是先治理数据或暂缓投入。
把容易混淆的问题一次说清楚
企业是不是应该先买一个通用 AI 工具？+
通用工具适合低风险个人任务，但跨系统、跨部门和需要企业依据的流程，仍要先判断数据、权限和责任。
第一个项目应该选最有想象力的场景吗？+
更适合选择价值明确、范围可控、数据可获得且业务负责人愿意参与的场景，以建立可复用能力。
没有完整数据能不能开始？+
可以先诊断与整理，但不宜假设系统已经具备可靠依据。项目第一阶段可能就是数据盘点和治理。
PoC 和正式开发怎样区分？+
PoC 验证关键假设；正式开发还要处理权限、系统集成、日志、异常、运营和验收。
咨询最后一定会进入开发吗？+
不一定。咨询的价值是形成真实判断，结论也可能是先补数据、调整流程或暂缓。
本页判断依据
- OpenAI：Identifying and scaling AI use cases
官方建议用影响与投入框架比较场景，并从真实工作问题中寻找高价值机会。
- OpenAI Academy：AI workflow readiness
工作流机会需要同时判断价值、可行性和准备度。