表格较宽时，可以用键盘方向键或触控手势横向滚动查看完整内容。
直接答案
先禁止团队用“做一个 AI 平台”描述需求，改为说明谁在什么任务上遇到什么问题、现在损失多少、希望改善什么、怎样验收。 只有当 AI 比规则、搜索、流程优化或普通软件更适合时，才把它放进方案。
五个反向问题
- 如果不用 AI，这个问题还值得解决吗？
- 当前流程最慢、最贵或最容易错的步骤是什么？
- 有没有真实数据证明问题高频发生？
- 用规则、表单、搜索或系统集成能否更稳定地解决？
- AI 出错时，谁发现、谁确认、怎样回退？
如果第一个问题答案是否定的，项目大概率只是追热点。
AI 适合与不适合的任务
AI 更适合处理非结构化文本、语言理解、资料检索、分类、摘要和草稿生成；明确公式、严格审批、金额计算和稳定规则，通常应由传统程序负责。很多有效方案是两者组合：AI 理解输入，规则校验结果，人工确认高风险动作。
把方案写成业务假设
不要写“建设智能客服平台”，可以写：“针对售后手册覆盖的 80 个高频问题，提供带引用的回答并正确识别转人工场景，希望把人工检索时间降低 30%，错误承诺为零。”
这句话同时限定了资料、用户、范围、目标和风险，能直接用于试点与验收。
设置停止条件
项目开始前约定：数据无法取得、效果低于底线、人工复核成本过高或风险无法控制时，停止扩大。允许小试点失败，比为了证明“AI 战略正确”持续投入更健康。
管理层应该看什么
- 问题基线而不是演示效果；
- 真实员工使用率而不是注册账号数；
- 正确率、转人工和异常记录；
- 完整成本与可验证收益；
- 下一阶段是否仍能独立验收。
可以用AI 项目 ROI 计算方法建立经济口径，再从AI Agent 小范围试点开始验证。技术名称可以变化，业务问题和验收证据应保持稳定。
把问题放进真实业务里
以下情境用于决策演练，不是虚构客户成果：业务部门提出“做一个 AI 助手”时，先拿掉 AI 三个字，追问现在谁在何处等待、重复或出错。如果问题用规则、表单或系统集成更稳定，就先做那些。AI 只在非结构化理解或生成确实降低瓶颈时加入。
开会时不要只谈观点
把下面五项填完，再决定采购、开发或优化动作：
- 要改善的业务指标：__________
- 当前流程和根因：__________
- 不用 AI 的替代方案：__________
- 失败时的损失：__________
- 四周内可验证的变化：__________
最容易踩的坑
把上线模型或演示效果当成项目成功。真正的完成标准应是业务时间、质量、收入或风险发生了可测变化。
什么时候才适合进入下一步
负责人能用一句话描述问题和指标，且证明 AI 相比规则自动化、流程调整或人工培训有更合理的收益风险比。
如果这些信息还无法写清，合理动作不是马上采购工具或签开发合同，而是先补一轮访谈、样本和责任确认。这样做看起来慢半步，通常能减少后面的返工，也让供应商给出的范围、报价和验收更可比较。
复盘时再追问一层
不要在会议结束时只留下“原则同意”。请指定一名负责人，用最近发生的一笔业务验证“要改善的业务指标”和“当前流程和根因”是否有记录，再让另一名实际执行者检查“不用 AI 的替代方案”是否符合现场情况。最后，把“失败时的损失”与“四周内可验证的变化”写成可以在下一次评审中核对的证据，而不是写成“后续优化”。如果两个人对同一项的答案不同，应先解决定义和责任分歧；这类分歧进入系统后，只会变成更难修改的权限、数据或流程问题。