问题一：是否语言密集
工作以读文档、写回复、做归纳为主，模型介入空间大；以搬运数据、核对字段为主，规则与接口更合适。判断错了，投入会变成额外的维护负担，还挤占了真正该做的场景。
问题二：错误成本可控吗
把错误分成可发现与不可发现两类。可发现且有复核环节的场景适合先做；一旦出错就产生不可逆后果的场景，需要更强的流程约束，甚至暂时不做。
问题三：样本是否可得
没有真实输入样本就建不了评测集，也判断不了效果。样本涉及客户信息时，先解决授权与脱敏，否则项目会卡在数据环节，方案再好也无法验证。
问题四：现状真的痛吗
常见伪需求是「同行都在做」。判断标准是现状是否存在可描述的时间损耗、返工或质量波动；说不清现状，也就很难定义改善后的样子。
问题五：是否有人负责
需要一名能定义对错、能调动样本、能承担上线后复盘的业务负责人。只有 IT 推动的项目，通常在第一次业务方质疑时停摆，责任也无人承接。
适用与不适用
适合谁
- 准备立项但不确定优先级的部门
- 需要在多个候选场景之间排序的企业
- 要向决策层说明投入理由的负责人
不适合谁
- 只想跟进概念、没有具体场景的企业
- 期望一套系统覆盖所有部门的项目
典型场景
某建筑企业的数字化部门列了十二个候选场景。用五个问题逐项核对后只剩三个通过：投标文件格式检查、施工日志摘要、供应商资质初筛。团队按错误成本排序，先做可复核的日志摘要，其余进入观察清单。
可执行步骤
- 把候选场景写成一句话任务描述
- 按语言密集程度与错误成本两维排序
- 核查每个场景是否有可用样本与授权
- 确认每个场景有业务负责人
- 只保留同时满足条件的场景立项
常见坑
- 用行业热度代替业务痛点，立项后找不到愿意配合的业务部门。
- 忽视错误成本，把高风险场景放进首批试点，一次事故就叫停全部项目。
- 样本涉及客户信息但未做授权与脱敏，项目在法务环节停滞数月。
- 由 IT 单方面推动，业务方不认评测标准，验收无法完成。
自检与验收清单
- 每个候选场景是否有可描述的现状
- 是否评估过错误的可发现性
- 样本授权与脱敏是否落实
- 是否指定业务负责人
- 是否排出优先级而非同时开工
常见问题
五个问题都要满足才做吗？
前三个是门槛，后两个决定能否持续。样本与错误成本不满足时应换场景，而不是加预算硬推，否则投入越大越难收手。
怎么估投入产出？
不建议先算金额。先算人工环节的时间分布与返工比例，试点后按接管率与实际耗时变化判断，再决定是否扩大范围。
负责人指定要做怎么办？
把五个问题作为立项材料的一部分，用数据说明风险与前置条件。多数管理层接受先小范围验证的提法，而不是直接否定。