团队引入AI助手后，常见的情况是试点开了不少，却说不清它到底该接哪一步、由谁使用、产出交给谁。这类“场景不清”通常可以拆成目标、角色、输入、产出、交接五类缺口。下面按症状界定、原因验证、小切口处置、效果验证与复发预防的顺序，给出一套可执行的诊断路径。
要点总览（TL;DR）
- “场景不清”先拆成目标、角色、输入、产出、交接五类缺口，用症状—角色—环节范围表圈定排查边界，并把工具不好用、数据不足、流程归属缺失等相邻问题单独标注。
- 原因排查按假设逐条验证：目标缺口、角色与交接缺口、输入与数据缺口、选型前置，每条同时准备成立证据和排除证据，未取得证据的写成待验证。
- 处置时把候选场景收敛到1–2个，用场景卡片写清触发条件、使用者、输入、产出物、交接对象和停止条件，并指定负责人与验收人。
- 用目标角色使用率、产出被接手比例、交接返工次数和场景说明可读性判断场景是否理清，区分“场景清晰但价值不足”与“场景仍不清”两种结论。
- 把场景清单纳入需求或迭代评审的固定环节，新增场景须填齐五项要素，定期清理失效场景，防止问题复发。
先界定“场景不清”的具体症状与影响范围
“场景不清”是一种笼统的抱怨，直接讨论原因容易各说各话。第一步是把抱怨转成可观察的事实：谁在什么环节、遇到了什么具体现象。范围界定清楚了，后续排查才有边界，也才能判断问题是否真的出在场景定义上。
常见的可观察症状有以下几类：
- 试点上线一段时间后无人主动使用，或只有发起人自己在用；
- 需求方描述需求时说不清希望AI完成哪一步，只能给出“帮我提效”这类笼统期待；
- 同一个助手被要求同时承担写作、查询、评审、生成测试用例等互相冲突的任务；
- 助手产出了内容，但没有人明确接手，产出停留在对话窗口里；
- 不同角色对同一助手的预期不一致，研发希望它查代码上下文，产品希望它写文档。
界定范围时，建议按角色和环节两个维度标注。角色维度可覆盖研发、测试、产品、项目经理；环节维度可覆盖需求、开发、评审、发布。把每个症状填入对应的格子，就能看出一张症状—角色—环节的范围表，哪些格子集中出问题一目了然。
| 症状 | 主要涉及角色 | 主要涉及环节 | 影响表现 |
|---|---|---|---|
| 试点无人使用 | 研发、测试 | 开发、评审 | 投入的试用时间没有转化为日常动作 |
| 需求方说不清要AI做什么 | 产品、项目经理 | 需求 | 需求描述反复修改，助手输出反复返工 |
| 同一助手承担冲突任务 | 多角色共用 | 需求至发布 | 输出质量不稳定，使用者失去信任 |
| 产出无人接手 | 研发、测试、产品 | 评审、发布 | 生成内容需要人工重新整理，等于多做一遍 |
界定范围时还要注意区分相邻问题。工具响应慢、界面难用属于“工具不好用”；任务所需资料拿不到属于“数据不足”；流程本身没有明确责任人属于“流程归属缺失”。这三类问题都会表现为“用不起来”，但处置方式不同。范围表里如果某格的主要现象是响应慢或资料缺失，应先标注为相邻问题，不并入场景不清的排查范围。
逐条验证原因假设并收集排除证据
范围界定之后，下一步是把可能的原因写成假设，再逐条找证据。原因型排查最容易犯的错误，是把第一个听起来合理的解释当成结论。每条假设都应同时准备“成立证据”和“排除证据”，没有取得证据的写成待验证，不提前下判断。
| 原因假设 | 验证方式 | 成立证据 | 排除证据 |
|---|---|---|---|
| 目标缺口：没有明确要改善的业务结果 | 追问“这个助手替代或加速了哪一步”，看能否得到具体环节和可判断的结果 | 受访者只能回答“提效”“试试看”，说不出前后对比的环节 | 能说清具体环节、当前耗时和期望变化 |
| 角色与交接缺口：不清楚谁触发、谁审核、产出交给谁 | 沿现有流程走一遍，标出触发点、审核点和交接点 | 流程走查中出现无人负责的断点，或产出没有下游接收方 | 每个环节都有明确责任人和接收方 |
| 输入与数据缺口：任务所需上下文不在可获取范围内 | 列出该场景的最小输入清单，逐项核对是否可获取 | 关键输入缺失或需要大量手工搬运 | 所需上下文在现有工具和数据中可直接取得 |
| 选型前置：先买工具后找场景 | 回看需求来源与决策顺序，确认场景是在采购前还是采购后补的 | 决策记录中先有工具选型，场景描述在之后才出现 | 场景需求先于工具评估形成，并有明确业务发起人 |
四类假设之间可能同时成立。例如目标缺口和交接缺口常常一起出现：目标没说清，交接自然无人认领。验证时不必强求只保留一个原因，而应记录每条假设的证据状态，把已确认、已排除、待验证分开标注。待验证项通常需要补充访谈或小范围试运行才能得出结论，可以安排到处置阶段一并观察。
验证过程中有一个实用原则：优先找反例。如果认为“没人用是因为工具不好用”，就去问实际用过的人卡在哪一步；如果认为“需求方说不清”，就请对方当场描述一次完整任务，看卡在目标、输入还是产出。反例往往比正面确认更快暴露真实原因。
按小切口推进的处置步骤
原因基本确认后，处置的重点是收敛而不是铺开。把候选场景压缩到1–2个，用一张场景卡片把关键要素写死，再约定试点周期和停止条件，可以在控制风险的同时拿到可判断的结果。
第一步，收敛候选场景。优先选择高频发生、边界清晰、结果可判断的环节。高频意味着有足够样本验证效果；边界清晰意味着输入输出容易描述；结果可判断意味着验收时有客观依据。三个条件不必全部满足，但至少要满足两个，否则试点结论很难成立。
第二步，为每个场景写清五要素。触发条件、使用者、输入、产出物、交接对象，缺一项就说明场景还没定义完整。可以用下面的场景卡片逐项填写：
| 卡片字段 | 填写要求 | 示例（演示情景） |
|---|---|---|
| 场景名称 | 一句话说明在哪个环节做什么 | 需求评审前生成待澄清问题清单 |
| 触发条件 | 什么事件发生时使用 | 需求文档提交评审前 |
| 使用者 | 具体角色，不写“团队” | 产品经理 |
| 输入 | 任务所需的最小上下文清单 | 需求文档、相关历史反馈 |
| 产出物 | 可交付、可检查的结果形态 | 待澄清问题列表，附出处 |
| 交接对象 | 产出交给谁、进入哪个环节 | 交给需求评审会作为输入 |
| 停止条件 | 什么情况下暂停或退出试点 | 连续两轮产出无法被评审会采用 |
第三步，指定负责人和验收人。场景负责人负责推进试点和记录问题，验收人负责判断产出是否可用。两个角色可以由同一人兼任，但要明确写出，避免出现“大家都在试、没人对结果负责”的局面。试点周期建议以能覆盖若干次完整任务为准，周期结束时无论结果如何都做一次结论评审。
第四步，涉及流程或数据变更时先控制风险。如果试点需要调整现有流程、接入新的数据源或改变文档存放位置，先备份原有资料，先在小范围试运行，并写明回退方式。回退方式要具体到“恢复到哪个版本、由谁执行、多长时间内完成”，不停留在“有问题就回滚”这种表述。
第五步，记录失败案例。试点中出现输出不可用、交接中断、使用者放弃的情况，都应记录下来，注明发生环节和具体表现。失败案例是修订场景卡片的依据，单次失败不足以否定方向，但同类失败重复出现，就说明卡片中的某个要素需要重写。
当场景卡片需要多人共同维护、试点任务需要跟踪进度、验收结论需要留档时，可以把这些内容放进工作项和文档中承载。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等工作上下文，并把自然语言指令转化为可追踪的工作；场景卡片、试点任务和验收记录可以分别落在文档与工作项里，让触发、执行、交接和评审在同一条记录上衔接。
验证恢复效果与防止场景再次发散
场景是否已经理清，不能只看试点期间有没有人夸好用，而要看几个可核验的信号。这些信号同时回答两个问题：场景定义是否清楚，以及这个场景是否值得继续投入。
- 目标角色实际使用率：卡片中写明的使用者，在试点周期内主动使用的比例。使用率低，先回看触发条件是否写得太窄或太隐蔽。
- 产出被接手比例：助手产出被交接对象实际采用的比例。接手率低，通常指向产出形态或交接标准不清。
- 交接返工次数：产出进入下游后被退回或大幅修改的次数。返工集中在哪类问题上，就修订卡片中的对应字段。
- 场景说明可读性：请未参与试点的成员只读场景卡片，看能否说清何时用、谁来用、产出交给谁。读不懂的比例高，说明卡片本身还没写清。
验证时要注意区分两种结论。“场景清晰但价值不足”表现为使用顺畅、交接正常，但节省的时间或改善的质量有限，对应动作是调整目标或更换场景；“场景仍不清”表现为使用率低、返工集中、新成员读不懂卡片，对应动作是回到卡片修订，而不是急着扩大试点范围。两种情况的处置方向不同，混在一起容易得出错误结论。
防止复发需要把场景管理变成常态动作。可以建立一份场景清单，新增场景时必须填写目标、角色、输入、产出、交接五项，缺项的不进入试点；定期清理长期无人使用或目标已失效的场景，避免清单越积越长却无人维护。同时把场景评审纳入需求评审或迭代评审的固定环节，让“先有场景、再谈工具”成为流程的一部分。ONES 在 AI 研发管理的落地建议中也提到，先梳理研发流程、现有数据与高频协作问题，再结合实际场景确定 AI 能力的应用范围和推进路径，这与上述维护节奏一致。
场景清单和评审记录需要有稳定的存放位置和责任人。把清单放在团队共用的文档空间、把评审结论关联到对应需求或迭代上，可以让后续新增场景时有据可查，也便于在复盘时回看每个场景从定义到验证的完整过程。
常见问题
团队对“场景不清”的判断不一致，怎么统一口径？
先不要争论定义，改为让各方分别填写同一张范围表：症状是什么、涉及哪个角色、发生在哪个环节、影响表现是什么。填完后对照差异，通常能发现分歧集中在少数格子。对这些格子补充事实描述，例如使用次数、返工记录、交接中断的具体环节，再形成共同口径。范围表本身不需要一次定稿，可以在排查过程中持续修订。
试点场景已经选定，但使用者仍然不主动触发，应该先改场景还是先换工具？
先回看场景卡片中的触发条件和使用者两项。触发条件写得过于隐蔽、使用者与实际执行任务的角色不一致，都会导致无人触发，这类问题改卡片即可解决。如果触发条件明确、使用者对口，仍然无人使用，再收集具体卡点：是不知道有这个能力，还是产出无法直接使用。工具层面的问题应在场景定义清楚之后再评估，否则容易把场景问题误判为工具问题。
试点需要接入新的数据源或调整现有流程，风险怎么控制？
把变更范围写进试点方案：涉及哪些资料、哪些环节、哪些人。执行前备份原有资料，先在小范围试运行，并写明回退方式，具体到恢复到哪个版本、由谁执行、多长时间内完成。试点期间保留原有流程作为并行路径，确认新方式稳定后再逐步切换。涉及权限调整时，先确认哪些角色需要访问哪些内容，避免试运行期间出现资料不可见或越权访问。
场景清单维护一段时间后条目越来越多，怎么避免变成形式化文档？
给清单设进入和退出规则：新增场景必须填齐目标、角色、输入、产出、交接五项，缺项不进入试点；长期无人使用或目标已失效的场景定期清理，清理时记录原因。清单与需求或迭代评审挂钩，每次评审只检查与本次相关的场景，不做全量通读。这样清单保持可读，也能在复盘时回看每个场景从定义到验证的过程。
场景卡片和试点记录放在哪里比较合适？
关键是让触发、执行、交接和评审落在同一条可追溯的记录上。常见做法是把场景卡片放在团队共用的文档空间，试点任务和验收结论关联到对应的工作项或迭代，评审时直接引用这些记录。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等工作上下文，并把自然语言指令转化为可追踪的工作，场景卡片、试点任务与验收记录可以分别落在文档与工作项中。
