兼职AI负责人客户发现电话问题模板：下载可用
一句话总结
客户发现电话的本质不是需求收集，而是权力博弈与认知对齐。正确的判断是：不要试图通过提问让客户告诉你答案，而要通过预设结论逼迫客户做选择。这场电话的胜负不在于你拿到了多少需求，而在于你定义了多少边界。
适合谁看
适合那些接了AI咨询单子、正准备与企业主进行首次Discovery Call，但担心被对方用“我想做一个AI版XX”这类模糊需求牵着走，导致最后方案无法落地且无法拿到全额款项的兼职AI负责人或独立顾问。
为什么大多数Discovery Call在第一分钟就失败了？
大多数兼职AI负责人在电话开始时会问：您希望AI能帮您解决什么问题？这是一个致命的错误。当你问这个问题时，你把自己定义成了一个执行层面的外包供应商，而不是一个定义问题的战略顾问。在硅谷的权力结构中，如果你在第一分钟就进入需求接收模式，你就失去了定义定价权的可能。正确的判断是：客户不需要一个能实现功能的人，而是一个能告诉他哪些功能是浪费钱的人。
在实际的Debrief会议中，我们经常讨论一个现象：那些在Discovery Call中表现得最温顺、最愿意倾听的人，往往在方案评审环节被客户用一句“这不是我想要的”直接否决。因为他们收集的是客户的“愿望清单”，而不是客户的“痛点真相”。客户说的“我想要一个AI自动化客服”，其实不是想要机器人，而是想要降低那20%的重复性投诉处理成本。
如果你记录的是“自动化客服”，你交付的是一个工具；如果你记录的是“降低投诉成本”，你交付的是一个商业结果。
这种认知偏差导致了严重的交付危机。很多顾问在电话里记录了10页的需求文档，结果在开发阶段发现，客户所谓的“自动化”其实需要接入一个极其陈旧且没有API的遗留系统。这就是典型的“需求陷阱”：不是客户在欺骗你，而是客户自己并不清楚自己的技术债。如果你在电话中没有通过压力测试来挖掘这些底层限制，你拿到的不是需求，而是一张无法兑现的支票。
正确的对话逻辑应该是：预设一个极端的失败场景，然后观察客户的反应。例如，不要问“您需要什么样的准确率”，而要说“如果这个AI在10%的情况下会产生幻觉且导致用户流失，您是否依然愿意上线？”。此时，客户的反应会告诉你这个项目的真实风险等级，以及他们对AI的认知底线。一个成熟的AI负责人是在电话中通过“排除法”来定义产品，而不是通过“累加法”来堆砌功能。
> 📖 延伸阅读：Amazon PM 模拟面试指南
如何通过问题模板强制客户暴露真实痛点？
很多所谓的模板只是一个清单，但真正的模板应该是一个引导逻辑。你之前的想法大概是“问得越细越专业”，但正确的判断是“问得越尖锐越高效”。一个合格的发现电话应该分为三个阶段：商业目标验证、技术可行性极限测试、以及交付标准定义。
在商业目标验证阶段，不要问“这个项目成功的标准是什么”，因为客户会回答“提高效率”。这种回答毫无价值。你应该问：“如果这个项目在三个月后被定义为失败，最可能的原因是什么？”。
这个问题将对话从正向的幻想拉回到了负向的风险评估。在一次与某传统零售业CEO的对话中，对方最初坚持要一个“AI导购”，但在问到失败原因时，他承认其实是担心竞品在做类似的事情而产生的焦虑，而非真实业务需求。这时候，你的判断应该是：这个项目不是产品驱动，而是竞争驱动，定价策略应该从“按功能付费”转向“按战略价值付费”。
在技术可行性阶段，不要讨论模型参数或Prompt技巧，而要讨论数据的洁净度。不是问“你们有数据吗”，而是问“你们的数据现在是以结构化表格存储，还是散落在50个不同的Excel文档中？”。
具体到场景，如果对方回答“我们有数据，但需要清理”，这意味着项目周期至少增加4周，成本增加20%。如果你在电话中没能捕捉到这个细节，你在报价单里写的是$50K，但实际成本可能会让你亏损。
交付标准的定义则是最关键的博弈。不要同意“效果好就行”这种模糊描述。正确地定义交付物应该是：在XX数据集上，AI的召回率达到XX%，且人工审核的通过率不低于XX%。在这种具体的数字面前，客户无法在交付时通过主观感受来拒付尾款。你之前的认知是“给客户惊喜”，但正确的判断是“给客户确定性”。
如何在电话中完成定价权的潜意识植入？
定价不是在电话结束时报一个数字，而是在整个对话过程中通过专业判断不断地提高你的权重。如果你在电话中表现得像个求职者，你的价格就是市场平均价；如果你表现得像个审计师，你的价格就是价值定价。
在硅谷的咨询逻辑中，定价权来自于你对风险的掌控力。当客户说“我想试着做个Demo看看”时，如果你回答“没问题，我可以先做一个”，你就把自己降级为了一个廉价的原型开发者。正确的判断是：Demo不是为了证明AI能行，而是为了证明这个方向可行。
你应该说：“我们可以做一个PoC（概念验证），但PoC的目标不是为了好看，而是为了验证那个最核心的风险点——即数据链路是否能跑通。如果跑不通，这个项目应该立即停止，以节省您的资金。”
这种敢于建议“停止项目”的姿态，反而会让客户产生极强的信任感。因为在AI领域，最昂贵的错误就是在一个错误的方向上投入巨大的算力。当你把自己定位为“帮客户省钱的守门人”而非“帮客户花钱的实施者”时，你的议价能力会大幅提升。
具体到薪资和报价的逻辑，如果你是作为兼职负责人切入，你的报价结构不应该是单一的固定费用，而应该是：基础咨询费（Base）+ 里程碑奖金（Milestone Bonus）+ 潜在的股权或分红（Equity/Profit Share）。例如，一个典型的中型AI咨询项目，Base可以是$30K-$80K，每达成一个关键指标（如降低成本10%）获得$10K的Bonus。
这种结构将你的利益与客户的商业结果绑定，从而消除客户对“外包公司只管交付不管结果”的恐惧。
> 📖 延伸阅读：Zoom产品经理行为面试STAR回答范例2026
交付后的Debrief会议如何决定你的续约率？
很多人认为电话结束，需求确认，任务就开始了。这是一个巨大的认知偏差。真正的项目管理始于第一次Debrief会议。这不是一次同步会议，而是一次认知对齐的权力确认。
在Debrief会议上，你不能说“根据之前的讨论，我计划这样做”，而要说“为了达成您提到的那个核心目标，我决定砍掉这三个功能，因为它们会严重拖慢上线速度且对ROI贡献极低”。这不是在请求许可，而是在行使专业裁决权。一个被尊重的产品负责人，是敢于告诉客户“这个想法很糟糕”的人。
在一次真实的HC（Hiring Committee）讨论中，评价一个AI负责人是否成熟的标准，不是看他能实现多少复杂功能，而是看他能拒绝多少不合理需求。如果你在Debrief中接受了所有需求，你最终会陷入一个无法交付的泥潭。
正确的做法是建立一个“需求优先级矩阵”，将需求分为：必须有（Must-have）、应该有（Should-have）和可以有（Could-have）。
具体的对话对比：
BAD: “您提到的这个功能很有意思，我会尝试把它加进去，看看能不能实现。”（潜台词：我是你的执行者，我不敢拒绝你。）
GOOD: “这个功能虽然有趣，但它会增加30%的延迟且不能提升核心转化率，我建议将其移至第二阶段，优先保证核心链路的鲁棒性。”（潜台词：我是这个项目的负责人，我负责控制风险。）
准备清单
- 准备一份包含三个维度（商业、技术、风险）的压力测试问题集。
- 建立一个数据审计清单：确认数据存储位置、访问权限、脱敏要求、API可用性。
- 制定一个明确的PoC定义文档：包含具体的成功指标（KPI）和失败终止线。
- 准备一个分阶段报价模板：Base + Bonus + Equity 的结构，而不是单一总价。
- 系统性拆解面试结构（PM面试手册里有完整的AI产品定义实战复盘可以参考），确保你的沟通逻辑符合硅谷的产品思维。
- 准备一个“拒绝清单”：预先想好哪些需求是绝对不能接的，以及拒绝时的专业措辞。
- 准备一份竞品分析快照：在电话中随口提到一个竞品的失败案例，用事实证明你的前瞻性。
常见错误
案例一：需求采集过度
BAD: 记录了客户提到的所有想法，写了一份50页的需求文档，客户觉得你很勤奋，但开发过程中因为需求冲突导致项目延期。
GOOD: 只记录三个核心痛点，将所有想法分类为“核心路径”和“干扰项”，在电话中直接告知客户哪些将被舍弃。
判断：需求文档的价值不在于完整度，而在于过滤率。
案例二：过度承诺技术能力
BAD: “现在的LLM基本都能实现，只要Prompt调好就行，没问题。”（结果：在处理复杂逻辑时出现不可控幻觉，导致客户信任崩塌。）
GOOD: “目前的模型在处理这类逻辑时有15%的错误率，我们需要建立一套人工审核机制来对冲这个风险。”
判断：诚实地暴露技术局限性，比伪装全能更能赢得信任。
案例三：定价过于保守
BAD: 按照自己的时薪计算，报价$5,000/月，客户认为你只是个兼职程序员，随意指使。
GOOD: 根据预估带来的成本降低额（例如每年省下$200K）的20%来报价，即使总额达到$40K，客户也会认为这是合理的投资。
判断：不要按时间定价，要按价值定价。
FAQ
Q: 如果客户在电话中一直强调“我要像ChatGPT一样”，我该如何回应？
A: 这是一个典型的认知偏差。客户并不想要ChatGPT，他想要的是ChatGPT带来的那种“即时反馈”和“自然交互”的体验。你应该立即将其转化为具体的产品能力。
例如，询问：“您是指希望用户能通过自然语言查询数据库，还是希望AI能生成营销文案？”通过将模糊的类比转化为具体的功能模块，你把对话从“幻想”拉回到了“工程实现”。案例：某金融客户要求“AI版彭博终端”，通过深挖发现他其实只需要一个能快速汇总研报的摘要工具，最终方案将复杂度降低了80%，但客户满意度更高。
Q: 当客户质疑我的报价太高，且对比其他低价供应商时，怎么处理？
A: 不要试图通过打折来挽留客户，因为打折意味着你承认之前的定价是虚高的，或者你的价值是可以被随意削减的。正确的判断是：引导客户对比“失败的代价”。你可以说：“低价供应商能交付代码，但我交付的是一个能产生商业价值的系统。
如果您选择低价方案，最大的风险不是钱，而是三个月后您发现系统无法上线，而此时您已经浪费了三个月的市场机会成本。”将讨论重心从“成本”转移到“机会成本”和“风险成本”上。
Q: 兼职AI负责人的角色边界在哪里？我该负责到什么程度？
A: 很多兼职负责人陷入了“保姆模式”，从写Prompt到帮客户清理数据什么都做。正确的边界应该是：定义产品方向 $\rightarrow$ 选型 $\rightarrow$ 监督实施 $\rightarrow$ 验收。你应该是那个定义“什么是正确”的人，而不是那个执行“怎么做正确”的人。
如果客户要求你写每一行代码，你应该重新定义你的角色为“技术顾问”并提高单价，或者引入一个执行层的人员。在硅谷的架构中，PM负责What和Why，Engineer负责How。如果你承担了How，你就在承担不必要的执行风险且降低了自己的战略权重。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。