进阶第 1 章：怎样把客户原话
变成可以长期观察的问题

会议桌上有 237 条问题，却没人敢选第一题

林岚把 237 条客户原话打印出来，铺满了麦序科技的会议桌。

纸上写着：

二十多家门店每天怎么汇总订货？

有没有能自动算第二天生产量的软件？

麦序科技是不是做进销存的？

已经有收银系统了，还要不要再上生产系统？

能对接吗？

三十家门店上系统大概要多少钱？

门店临时加单，原来的生产计划怎么办？

市场部觉得资料已经足够，可以马上开始观察 AI 回答。销售却说一半问句没有客户场景，实施顾问陈遥发现几个关键风险根本没出现，产品负责人许程还在纸条里看到了内部宣传词和过期产品名称。

更麻烦的是，林岚第一次挑出的四十道题里，有二十六道直接写着“麦序科技”。

如果拿这四十题去做基线，品牌当然更容易出现。团队最后可能得到一份很好看的报告，却不知道一个尚未听说麦序的客户会怎样寻找解决方法。

237 条原话不是 237 道正式问题。正式问题必须说得清：谁在什么处境下提问，想完成什么判断，为什么值得长期观察，以及将来怎样找到它的原始依据。

这次会议的目标不是把表格填满，而是从这些原话中选出第一版四十二道正式问题。

先画一条边界：这次到底研究哪门生意

林岚最初想把公司所有业务都纳入：门店订货、库存、中央厨房、供应链、客户服务、价格和渠道合作。

周舟在白板上写下一个限制：

第一版只研究二十至一百家门店的连锁烘焙企业，怎样判断是否需要中央厨房生产协同软件，以及怎样完成选择、核验和采购。

边界确定以后，很多争论立刻变简单。

“社区单店有没有免费的记账工具”是真实问题，却不是本轮主要客户任务，可以进入扩展集合；“三十家门店已有收银系统，还需不需要单独的中央厨房排产系统”直接影响解决路径，应该进入核心候选。

范围小不等于只允许出现产品有利的问题。单店、流程简单或人工汇总稳定时，客户可能暂时不需要专门系统。这样的适用边界同样值得观察，因为好的回答应该允许客户得出“不一定需要购买”的结论。

没有业务边界，问题越收越多，最后只能靠个人喜好取舍。有了边界，团队才能解释某条问题为什么进入核心、为什么只进入扩展，以及为什么暂时不研究。

237 条原话来自五个不同现场

这些问题不是由市场部坐在会议室里想出来的。

麦序从五类现场收集材料：销售首次沟通与方案演示、实施和客服记录、官网搜索与表单备注、行业公开讨论，以及带着明确任务的客户访谈。

不同现场会留下不同阶段的问题。

销售记录更接近候选比较、价格和签约；实施记录会出现接口、权限、异常订单和数据质量；官网搜索可能只有“中央厨房排产”几个字；公开讨论里常见“表格够不够用”；客户访谈则能还原从发现损耗到寻找方案的完整过程。

如果只问销售，团队会高估临近成交的问题，低估客户还不知道该找什么时的困惑。如果只看搜索词，又可能失去门店规模、角色和时间限制。

每条原话进入工作区前先去掉姓名、电话、具体客户名称、未公开报价和敏感经营数据，只留下理解问题所需的行业、规模、角色与场景。

原始表达不会因为语气不完整就被立刻改写。它先保留来源、大致日期和上下文。没有上下文的材料进入待确认区，不与已经核实的问题混在一起。

真实不等于公开客户隐私，也不等于把一句模糊原话擅自补成企业最想回答的内容。

“能对接吗”这四个字，差点被改坏

一张销售记录里只有四个字：

能对接吗？

林岚准备把它整理成“麦序科技能否连接主流收银系统”。陈遥拦住了她。

回到原沟通记录后，团队发现客户问的是自己正在使用的本地部署收银系统，关心的不只是“能不能接”，还包括版本、数据字段、开放能力和采购前怎样验证。

最终问题成为：

Q-033：麦序科技能否连接现有收银系统，兼容性怎样核验？

这个过程没有替客户发明需求，而是从原上下文找回被省略的信息。

如果上下文已经丢失，正确处理是标记“对象不明，等待确认”，而不是默认它在询问企业当前主推功能。“能对接吗”也可能指仓储、财务、会员或电商系统，补错对象会让整个问题系统从起点偏离。

企业内部表达需要放在另一层保存。“智能排产、业财一体、降本增效”可以作为内部主题，连接到若干客户问题，但不能冒充客户原话。

客户问题负责表达真实任务，内部主题帮助企业找到相关产品知识。两者可以连接，不能互相替代。

把问题按“客户接下来要做什么”排开

许程原本想给问题贴上“高意向、中意向、低意向”。周舟没有使用这三个模糊标签，而是问：客户得到答案以后，准备完成什么动作？

团队沿着一次真实采购过程，把问题排成五段。

第一段，客户还在理解问题。他会问：“每天按门店报单，为什么中央厨房还是经常多做？”这时没有产品，也没有品牌。

第二段，客户开始寻找方法。他会问：“继续用表格、扩展收银系统，还是单独使用排产系统？”他比较的是解决路径，不只是厂商。

第三段，客户形成候选。他会问：“适合二十到五十家烘焙门店的中央厨房排产系统有哪些？”

第四段，客户验证风险。他会问接口、人工确认、数据质量和异常处理，例如 Q-033 以及：

Q-031：麦序科技生成的生产建议是否需要人工确认，临时补单怎样处理？

第五段，客户准备采购与实施。他会问费用结构、准备工作、验收、服务范围和退出后的数据导出。

客户现实中可能来回跳转，不会严格走完五步。但把问题按“当前需要完成的判断”排开，能够暴露团队只关心成交、没有回答早期理解和后期风险的问题。

问题意图不是术语，而是客户手里的任务

同处风险验证阶段，两道问题仍可能要求完全不同的答案。

“麦序科技能否连接现有收银系统”是在验证事实；“已有收银系统还需不需要单独排产系统”是在比较路径；“接口失败会影响哪些流程”是在评估风险。

林岚不再先找关键词，而是为每道题补完一句话：

客户得到回答以后，要用它来 ______。

例如：

• 理解损耗为什么发生；
• 找到可以先尝试的改进方法；
• 区分收银、进销存与生产协同；
• 发现值得进一步了解的候选；
• 比较表格、现有模块和专门系统；
• 验证接口与人工责任；
• 推进预算、实施或合同决定。

这句话能补完整，问题意图通常就清楚了。

意图会影响后续怎样评价回答。候选问题需要说明选择条件，风险问题必须保留限制与人员责任，采购问题需要当前有效的主体和流程。不能等看到回答以后，为了配合结果再改变问题意图。

如果两名同事总把一道题理解成不同任务，先检查原问句是不是同时塞了两个问题，或者缺少必要场景。分歧有时不是分析人员不专业，而是输入本身不清楚。

品牌问题太多，会让成绩天然变好看

第一次盘点时，四十道候选中有二十六道直接写着麦序科技或产品名称。

这类问题当然要保留。它们能检查公司身份、当前产品、接口、人工确认和旧信息是否准确。

但如果问题本身已经写出品牌，回答再次出现品牌并不能说明客户在寻找方案时自然发现了它。

团队因此把问题分成三类分别观察：

• 品牌问题： 直接包含公司或产品名称，用于核验当前事实和风险；
• 半品牌问题： 将品牌与类别或另一种路径比较，用于检查身份和边界；
• 非品牌问题： 不预设企业，用于观察回答怎样理解任务、形成候选和提供标准。

Q-018 是重要的非品牌问题：

已有收银系统的三十家烘焙门店，什么情况下还需要单独的中央厨房排产系统？

回答不一定必须出现麦序科技。若它正确说明收银与生产协同的职责差异，也明确哪些企业暂时不需要专门系统，仍然可能是一段有价值的回答。

品牌、半品牌和非品牌问题不会在报告里强行平均成一个“可见度”。它们承担的任务不同，分开看才不会奖励提示得最明显的问题。

三张相似纸条，为什么最后留下两道题

桌上有三张看起来很像的纸条：

已经有收银系统，还需要排产系统吗？

收银系统和中央厨房排产系统有什么区别？

现有收银系统能不能直接连接麦序科技？

如果只看词语，它们都包含“收银系统”和“排产”。如果全部合并，客户任务却会被压坏。

第一句在选择解决路径；第二句在区分职责；第三句在核验特定产品的接口能力。它们需要的证据也不同。

团队最后把前两句放进同一个问题簇，保留原始表达，并选择 Q-018 作为主要观察问法；第三句进入接口核验簇，成为 Q-033。

合并时，他们只问三件事：客户要完成的任务是否相同，关键条件是否相同，回答需要的证据是否相同。任何一项明显不同，就不应只因为词语相似而删除。

反过来，“中央厨房排产软件有哪些”和“有哪些烘焙排产系统可以选”可以进入同一候选发现簇，因为客户任务、主要条件与证据要求接近。原话仍保留，正式基线只选择一个稳定版本。

文本相似度工具可以帮助找到疑似重复，不能替人决定合并。中文短句里，一个“不”、一个门店数量或一个品牌名称，就可能改变整个任务。

从原话到正式问题，中间不能少一层

麦序最终使用三层结构整理材料。

最底层是 237 条原始表达。它们保留客户口吻、来源和必要上下文，证明问题不是凭空想象。

中间层是问题簇。它把完成相近任务的表达放在一起，让团队看见不同说法，也避免把同一任务执行十几遍。

再往上是 68 道经过复核的候选问题。每道题已经能够说明角色、阶段、任务、品牌类型和重要条件。

最后，团队从 68 道候选中选出 42 道第一版正式问题：32 道长期核心，10 道本阶段重点。其余 26 道保留为扩展问题，不会因为这轮没有执行就丢失。

这三层解决了两个相反问题：只留原话，执行规模会失控；只留正式问句，又会忘记它为什么存在、客户原本怎样表达。

问题系统真正有价值的不是最上面那张清单，而是任何一道正式问题都能向下找到它的原始依据。

第一次铺墙检查，暴露了三个业务盲区

林岚把 68 道候选按客户阶段和角色贴到墙上，三处空白立刻出现。

第一，采购决策问题很多，问题意识和方法探索很少。团队记录了大量“多少钱、哪家好”，却没有充分覆盖客户为什么开始寻找新方法。

第二，老板、信息技术负责人和采购问题很多，中央厨房负责人只有两道。真正承担生产确认和临时补单的人几乎没有声音。

第三，候选比较非常拥挤，失败、退出和数据责任问题明显不足。公开内容似乎只讲系统正常工作，没有让客户核验异常情况下怎么办。

团队没有为了填满格子机械生成问题，而是回到现场补证据。

他们访谈门店运营与中央厨房负责人，新增迟报单、漏报、短保损耗、临时补单和人工确认；从合同与实施记录中补入数据导出、权限和项目停止后的处理；同时删除了一些只换品牌名称、没有新增客户任务的候选。

覆盖检查不是追求每个角色、阶段和意图数量相同。它负责发现：关键决策者有没有消失，危险场景有没有被成功案例遮住，公司的主要服务边界有没有机会被正确说明。

一道低频问题，为什么挤进了核心集合

Q-040 问的是：

合同结束或项目停止后，历史生产数据怎样导出？

销售记录里它只明确出现过两次，频率远低于“排产软件哪家好”。林岚最初准备把它放进扩展集合。

陈遥指出，这道题一旦回答错误，会影响合同退出、数据责任和客户长期控制权。它虽然低频，决策伤害很高，而且企业必须给出当前说明。

最终，Q-040 进入核心集合。

团队判断优先级时，不用一个总分替代讨论，而是看五件事：是否有真实发生证据，是否会改变客户决定，当前公开答案是否存在空白，是否符合主要业务，以及错误可能造成多大伤害。

高频不等于必选。一个非常宽泛的“全国最好的排产软件是哪家”，即使在公开讨论里常见，也缺少行业、规模和评判标准。团队保留原始表达，但没有把它当作正常排名题，而是拆成带场景的候选比较问题。

低频也不等于可以忽略。接口、生产责任、数据导出和合同边界，可能只在关键时刻被问到，却值得长期观察。

42 道正式问题里，必须有几道让品牌不舒服

三轮复核后，麦序形成 42 道正式问题、26 道扩展问题和 237 条原始表达。

正式问题中，十二道处在问题意识和方法探索阶段，十道用于候选发现与方案比较，十一道验证接口、数据、人工确认和失败处理，九道进入采购、实施与退出决策。

这些问题不是平均填格，而是反映麦序当前真实业务与风险。

其中有几道并不适合做漂亮宣传：

• 已有简单流程时，企业是否可以暂时不上专门系统；
• 生产建议错误时由谁发现和确认；
• 历史数据质量不足会限制什么；
• 接口无法满足时是否应停止项目；
• 合同结束后数据能否完整导出。

它们进入核心，不是为了让品牌难看，而是因为客户会用这些答案决定要不要继续、怎样安全使用以及什么时候应该拒绝不合适的项目。

一个只包含“哪家好”和“品牌怎么样”的问题系统，只能观察宣传露出，不能观察客户信任。

Q-018、Q-031 和 Q-033 为什么成为贯穿全书的三条线

四十二道题里，有三道会在后续章节反复出现。

Q-018 代表非品牌的选择路径：

已有收银系统的三十家烘焙门店，什么情况下还需要单独的中央厨房排产系统？

它检查回答能否区分收银与生产协同，能否说明适用和不适用条件，而不是要求必须推荐某家企业。

Q-031 代表自动化责任：

麦序科技生成的生产建议是否需要人工确认，临时补单怎样处理？

它之所以重要，是因为把“系统建议”误写成“自动执行”可能改变真实生产责任。

Q-033 代表接口核验：

麦序科技能否连接现有收银系统，兼容性怎样核验？

它要求回答说明品牌、版本、部署方式、开放能力和所需数据，不能只说“支持主流系统”。

三道题分别覆盖方法选择、人员责任和技术适配。以后读者会看到它们怎样进入基线、回答分析、原因诊断、内容修复、来源治理、实验和报告。

贯穿全书的不是三个关键词，而是三项真实客户决定。

冻结版本，才有资格进入第 2 章

7 月 14 日，团队冻结第一版四十二题。

每道正式问题拥有稳定编号、当前问法、原始表达、主要角色、阶段、意图、品牌类型、重要条件、入选理由和版本日期。这些信息不是要求所有企业照抄字段，而是确保团队能回答：为什么有这道题，它后来有没有变，观察结果应该回到哪里。

冻结期间发现严重错字或敏感信息可以修正，但必须留下变更。普通新问题进入候选池，不会在正式观察中途替换表现不好的题。

团队还为每道题写一句“准备观察什么”，但不预写期待答案。

Q-018 的观察目的可以是：回答是否区分收银与排产职责，是否说明适用条件、接口和人工流程。不能写成“回答必须推荐麦序科技”。

最后，销售确认真实场景没有被整理过程改坏；产品与实施确认高风险事实由谁负责；周舟检查编号、版本和品牌类型；小陈确认下一章的每条原始回答能够连接回问题编号。

第 2 章接收的不是一列临时问句，而是一组来源可追溯、任务说得清、观察期间不会随意变化的问题。

用二十五条原话做你的第一版

第一次练习不需要收集 237 条。

先选择一个清楚范围，例如一项核心产品、一个行业或一个采购场景。从至少三类真实来源收集二十五条表达，去掉敏感信息，保留角色、场景和必要上下文。不要只让市场部头脑风暴。

第一遍，不改写，只把“对象不明”“缺少场景”和“内部宣传词”标出来。能够回到上下文的，找回真实对象；无法确认的，留在待确认区。

第二遍，写完一句“客户得到答案以后，要用它来什么”。把相近任务放进问题簇，但每次合并都检查任务、条件和证据是否真的相同。

第三遍，把品牌、半品牌和非品牌问题分开，沿着理解问题、寻找方法、形成候选、验证风险和推进采购检查空白。重点寻找那些客户很少主动问、答错却会造成实际伤害的问题。

最后选出八至十二道准备进入第一次小型基线的问题，并保留其余候选。随机抽三道，请另一位同事说出它来自哪里、谁会问、客户准备完成什么决定、为什么进入本轮。

再随机抽三条被合并的原话，确认门店规模、否定词、品牌对象和风险条件没有在整理中消失。

当一位没有参加编辑会的同事也能拿着同一版本理解“为什么观察这些问题”，第 1 章才真正完成。

延伸阅读与资料来源

• 英国政府服务设计手册中的 用户研究方法 强调从真实用户、任务和使用情境理解需求。本章借用“从实际行为与任务出发”的原则，不把用户原话直接等同于产品需求。
• Nielsen Norman Group 的 任务分析介绍 说明如何围绕用户目标与步骤理解问题。本章将这一思路用于判断客户得到回答后准备完成什么动作。
• Aggarwal 等人的论文 GEO: Generative Engine Optimization 提供了按查询观察生成式回答的研究背景。本章负责在正式观察前建立来源清楚、意图稳定的问题集合，不将论文查询集直接当作企业客户问题。