MBB 顾问在 discovery 阶段常做的 5 件事，大多数 agent 构建都跳过了

我们一直在访谈 20 多位 MBB 顾问，了解他们在给出任何建议之前如何进行内部访谈。我们正围绕一个 AI 面试官来构建 Plexo，它的作用是映射工作的实际运转方式，因此我们想先掌握这套方法论的人工版本。以下是五个反复出现的发现，也解释了许多 agent 试点失败的原因： **先有假设，再做访谈，并且允许推翻它。** 没有初始假设，你就不知道该问什么。如果无法证伪它，你只会收集到印证它的引语。前两次对话之后就修订访谈提纲；不要在整个调研过程中冻结脚本。 **访谈真正干活的人，而不只是流程负责人。** 负责人描述的是设计出来的流程；一线员工描述的是上周实际存活下来的流程。运营问题 → 找靠近交接环节的人；战略问题 → 找资深人员。两个角色对同一步骤说法不一致，通常就是 agent 应该（或不应该）介入的地方。 **信任胜过精巧的 prompt。** 人们会认为流程梳理意味着自己的饭碗不保。匿名处理、报告中不做姓名归属，并将对话定位为增强他们的工作——而非「消除低效」——这才是获得真实回答的关键。没有这些，你的 agent 就是在政治噪音上训练。 **机会 = 文档化的流程 vs 实际流程。** 量化业务量、耗时和错误率。抱怨声最大的不一定是瓶颈。有方向性的金额估算胜过虚假的精确模型。agent 适合低政治色彩的运营问题；重组、裁员编制和跨部门甩锅仍然要由人来处理。其余的事项：先映射一个工作流，在一个交接环节上交付一个 agent，在该 agent 上线之前，清单上的其他事项先放着。 **以速度和有边界的诊断能力竞争——而不是以取代完整的战略咨询项目竞争。** 如果你为客户构建 agent：你的项目边界通常在哪些地方出错？你通常如何梳理客户的流程以确定该自动化什么？