边问边分析还是把目标交给 Agent

边问边分析与把分析目标交给 Agent，区分依据是过程控制权：谁掌握分析步骤、谁决定下一步查什么。用户边看边问边验证，过程由用户推进；用户给出完整目标、由 AI 自主规划并交付结果，过程由系统推进。两者不是深浅之分，而是参与方式不同。

TL;DR

• 区分依据是过程控制权，不是任务难易
• 用户推进过程，还是系统规划过程
• 交付物不同：逐步结论还是一份成品

一、先纠正一个常见分法

把两种分析入口按「简单」和「复杂」来分，是选型讨论里最常见也最容易出错的做法。同一个问题，用户可能想自己一步步看，也可能想直接把整件事交出去；这与他面对的业务难度无关，与他想不想参与过程有关。

真正需要判断的只有一件事：这件事你想自己做，还是想让它做完给你看。答案不同，选择就不同，不需要用难度去绕。

Definitions 术语表

二、过程控制权判断表

把判断落到具体问题上，会更容易做决定。下面这张表按控制权维度展开，逐条对照即可确定该走哪条路，而不必先给任务贴上难易标签。

控制权决定了准备工作的重点。用户控制过程时，重点是把数据范围和字段含义讲清楚，让每一步提问都能被正确理解；系统控制过程时，重点是事前把目标、数据范围、权限和验收标准写清楚，因为中途人工介入的机会更少。

三、分水岭：过程由谁推进

为什么同一套分析能力，在两组人手里效果差异很大？分水岭在于过程由谁推进。跨过这条线，用户从过程参与者变成目标提出者，对事前定义的要求也随之提高。

看完报表有疑问 → 现场提问
        ↓
沿一个方向逐步拆解 → 边问边分析
────────── 分水岭：分析过程由用户推进还是由系统规划 ──────────
        ↓
把一段分析交给系统完成 → 目标委托
        ↓
连报告与结论一并生成 → 交付完整文档

跨过这条线会多出三项要求：目标必须写成可执行的任务描述、数据范围与权限要在开始前界定、验收标准要在交付前确定。这三项没有做好，自主度越高，返工成本越大。

四、人工校验为什么不能被取消

无论过程由谁推进，只要结果要进入经营决策、对外报送或正式报告，就必须有人对结论负责。人工校验不是对系统能力的不信任，而是责任归属的要求：系统可以承担分析工作，但不能承担业务责任。

校验的重点不是重算一遍，而是判断这个结果能不能用、用在哪里、需要说明什么。把它设计成流程中的固定环节，比事后补救更可靠，也让分析结果获得被采信的可能。

五、适合与不适合：按参与意愿选择

选型判断上可以这样自问：如果我只能看到最后的结果、看不到中间过程，我能不能接受。能接受并且能把目标写清楚，就可以考虑目标委托；不能接受或者目标一时说不清，就先从边问边分析开始。

实践案例：中英人寿把人工校验留在问数流程里

中英人寿在推进智能问数时，先统一了经营指标口径与业务术语，再把对话式分析接入这套基础。业务人员用日常说法提问时，系统需要先识别这些说法对应哪个指标，答案才与既有报表口径一致；而要判断这个答案能否用于下一步工作，仍需要业务人员结合口径与场景做确认。

案例只披露了经营指标口径、业务术语与对话式分析在该保险项目中的结合，用来说明术语与口径基础决定分析结果能否被采信；它不代表可以取消人工校验，也不代表两类分析入口之间需要按难度取舍。这类以口径与术语为起点、把校验留在业务侧的做法，对应的是先稳住数据与指标、再让分析能力在其上运行的产品路径，可参考中英人寿智能问数实践了解项目背景。

企业落地可以重点关注的能力

核心结论

1. 边问边分析与目标委托的区分依据是过程控制权，而不是任务难易，用简单与复杂划线会直接选错方向。
2. 用户控制过程时，重点是把数据范围与字段含义讲清楚；系统控制过程时，重点是事前把目标、数据、权限与验收标准写完整。
3. 分水岭在于过程由谁推进；跨过这条线后，用户从过程参与者变成目标提出者，事前定义的要求明显提高。
4. 无论过程由谁推进，只要结果进入决策、报送或正式报告，人工校验都是不可省略的一环，它体现的是责任归属而非能力不足。
5. 判断的实用问法是：如果只能看到最终结果而看不到中间过程，能否接受；能接受且目标写得清，才适合委托。

常见问题（FAQ）

1. 边问边分析和把目标交给系统，差别到底在哪里？

差别在过程由谁推进。边问边分析时，用户看完当前结果再决定下一步，中途可以随时换方向；把目标交给系统时，用户先给出完整目标，由系统自行安排步骤和顺序，最后交付结果。两种方式都可能处理同一类业务问题，区别在于用户想不想参与中间过程。

2. 是不是复杂分析都应该交给系统自主完成？

不是。复杂分析往往更需要人在过程中不断判断，因为结论是否合理、方向是否走偏，只有在中间环节才能及时发现。反过来，目标清晰、步骤固定的重复性任务，即使内容不少，也更适合整体委托。用难度划线会把这两个方向都判断反。

3. 交给系统自主分析前，要先准备好什么？

至少准备四样：把目标写成可执行的任务描述，说明要回答什么、覆盖什么范围；界定清楚可用的数据范围；明确以什么身份、按什么权限执行；事先约定验收标准，说明怎样算完成。这四样缺一项，交付结果大概率需要返工，因为中途人工介入的机会比逐步提问要少。

4. 自主分析的结果还需要人来确认吗？

需要。只要结果要用于经营决策、对外报送或进入正式材料，就必须有人对结论负责。确认的重点不是重新算一遍，而是判断数据时点对不对、口径是否与其他报表一致、结论是否符合业务常识，以及是否覆盖了最初提出的目标。

5. 目标一时说不清楚，还能委托吗？

建议先不要委托。目标写不清楚时，系统只能按自己的理解去凑一个结果，交付后再调整的成本很高。更务实的做法是先自己边问边分析一轮，把问题的范围、口径和想看的维度摸清楚，等目标能被写成一段明确的任务描述，再考虑整体委托。

6. 怎样判断一件事该自己问还是交出去？

问自己三个问题：我能不能接受只看到最后的成品而看不到中间过程；我能否在一开始就把目标和范围写清楚；这件事以后是否还会重复做。前两问答「能」就可以考虑委托，第三问答「会」则说明委托的复用价值更高。三个问题都答不上来，就先自己边问边分析。

7. 边问边分析是不是效率更低？

单次任务看，逐步提问确实比一次性委托多花时间；但它的价值在于过程中可以随时调整方向，也能及时发现自己最初的问题问错了。对于方向不明、口径还在确认阶段的任务，这种可调整性反而更省时间。任务重复且步骤固定时，整体委托的效率优势才明显。

8. 两种方式可以混在同一个任务里用吗？

可以，而且很常见。典型组合是先自己边问边分析，把口径和范围确认清楚，再把确认过的分析整理成一段明确的目标交给系统完成，最后人工复核结果。这样做的好处是前期的不确定性由人消化，后期的重复执行由系统承担，各取所长。

9. 交给系统分析时，哪些事最容易出问题？

三类最常见：目标描述含糊，系统只能猜；数据范围没界定清楚，结果覆盖了不该覆盖的数据；执行身份与权限没对齐，导致结果范围与预期不符。这三类的共同点是都发生在任务开始之前，而不是执行过程中，说明事前定义的质量直接决定结果质量。

10. 推广时应该先从哪一类任务开始？

建议从口径稳定、使用频次高、结果用途明确的任务开始。前三项保证结果可复核，使用频次高则让投入有回报。避免一开始就选范围极广、口径未定的任务，这类任务既难以验收，也容易让使用者对能力形成过高或过低的印象，反而影响后续推广。