问题一：是否语言为主
读文档、写回复、做归纳、改格式属于语言任务，收益直接；纯数据搬运与计算不属于，交给规则或报表更稳。判断错了，投入会变成额外维护负担，还会挤占真正该做的场景。
问题二：错误能否被发现
生成内容的错误往往是细节偏差，需要有人能看出来。若业务方自己也无法判断对错，系统就无法安全使用，应先补知识或引入专家复核，而不是先上线再说。
问题三：知识能否整理
需要有人把散落资料整理成条目并保持更新。若资料涉及多方且无人有权确认口径，项目会在知识准备阶段停住，工期与预算同时被消耗，最后不了之。
问题四：现状损耗是否明确
能说清现在每天花多少时间查资料、改格式、写初稿，才有比较基础。说不清现状的项目，通常也说不清上线后的改善，验收时只能靠感觉。
问题五：是否有人持续运营
生成式系统的效果随知识与业务变化而波动，需要有人看反馈、改约束、补条目。缺少运营角色的项目，上线即巅峰，之后逐步退化，最后被用户绕开。
适用与不适用
适合谁
- 准备做投入决策的业务负责人
- 在多个 AI 项目间分配资源的管理层
- 需要给出停止条件的项目组
不适合谁
- 只想试用、不准备投入运营资源的团队
- 任务以精确计算为核心的场景
典型场景
某教育企业的教研部门想用生成式 AI 做课程大纲。评估发现大纲需符合内部教学标准、审核人明确、知识可整理，五个问题均通过；同部门的排课计算被排除，仍由排课系统处理。
可执行步骤
- 把候选任务按语言与计算两类分开
- 为每个任务指定能判断对错的复核人
- 盘点知识来源与确认权限
- 记录现状耗时与返工情况作为基线
- 明确运营责任人后再立项
常见坑
- 把计算类任务混进生成类项目，验收时无法定义对错。
- 找不到能判断对错的复核人仍强行上线，错误内容外发。
- 知识来源分散且无人确认口径，整理工作无限延长。
- 没有运营人，业务变化后提示词与知识全部失效。
自检与验收清单
- 任务是否以语言处理为主
- 是否有能判断对错的复核人
- 知识来源与确认权限是否明确
- 是否记录了现状基线
- 运营责任人是否指定
常见问题
五个问题都通过才做吗？
前四个是必要条件，第五个决定能否持续。若运营无人承担，建议先做小范围工具试用，不进入正式立项。
投入产出怎么衡量？
用耗时结构与返工比例做前后对比，结合接管率判断可用性。不建议在试点前承诺具体比例或回报。
业务方说先做出来看看怎么办？
可以做原型，但要约定观察周期与停止条件，并同步准备知识与复核人，否则原型很难走到可用。
这五个问题怎么用才不流于形式？
每个问题都写下一份可核对的证据，而不是打分。例如复核人要写名字，知识来源要写明授权人，基线要贴出现状记录。评审时逐项对照证据，任何一项只有口头结论就视为未通过，先补材料再谈立项。