夜雨聆风最近接触到一家企业的“飞行员测试”。主要过程是：企业提供 Claude 使用资源，再给出一个具体场景和问题，由被测试人使用 Claude 完成分析和处理。
来来回回折腾了几轮，觉得这个过程有意思，也值得做一次复盘和记录。
AI工具已进入很多人的工作、生活场景。国内的“豆包”、“DeepSeek”，国外的“Claude”、“Chatgpt”，各有优劣，但各个工具都有一个共同点：在与AI交互时，似乎它的回答有理有据，无懈可击，并且它的“向上管理”是做得极好的。
材料给进去以后，AI很快会回答：它会列标题，给结构，做分类，写建议。有时候还会补上表格和总结。第一眼看过去，答案并不难看，甚至比很多人工整理的初稿更完整。
于是真相可能被掩盖，决策也被所谓的论据所动摇。
那么，是否有办法可以降低、甚至规避这样的情绪化的回答、或者是假理性的回答？
或者说，能不能让 AI 少一点迎合，多一点被约束？
也许我们可以尝试从交互指令入手。
答案来得太快以后，问题容易被盖住
在工作场景没有使用 AI 时，做一份方案，常常要先查资料、搭框架、写提纲、补内容。这个过程很慢，所以人在写之前，多少会先想一想：我到底要解决什么问题？
现在不一样。
工作场景引入 AI 后，材料刚放进去，它就已经把答案铺开了：它会把零散材料整理成几个部分，把问题分成几类，把建议写得很顺，会在结尾加上一个看起来合理的总结。
这当然提高了效率。
但也带来一个新的问题：答案出现得太快，容易让人以为问题已经被处理过了。
有些 AI 输出，看起来完整，但往里看会发现一些空处：
它说要提升效率，但没有说提升多少；
它说要优化用户体验，但没有说是哪一类用户、哪个使用环节；
它说要降低风险，但没有说明风险发生在什么条件下；
它说建议采用某个方案，但没有比较为什么不选另一个方案；
它说要持续迭代，但没有说多长时间复盘一次，达不到什么结果就要停止。
这样的答案不是没有价值，它可以作为初稿，也可以帮助人快速看见问题的大致形状。但如果直接把它当成最终方案，很多真实约束就会被埋掉。
在过去，我们常常缺的是答案，现在，答案不难出现。
难的是判断这份答案有没有把问题讲清楚。
交互指令不是话术，而是工作思路的实体化
一开始，我在琢磨怎么给出合理的“交互指令”。
比如开头加一句“你是一名资深专家”；比如要求“请用表格输出”；比如让 AI “逐步思考”；比如规定字数、格式、风格。这些技巧有用，但只能解决一部分问题。
一个人如果只问：“请帮我分析一下。”AI 通常也能回答。
但这个指令没有目标，没有边界，也没有判断标准。AI 只能按常见路径生成一份看起来完整的分析。
另一个人可能会这样问：“请先不要给解决方案。请基于材料识别问题，并将问题分为用户需求、产品功能、业务流程、团队执行、成本交付、市场竞争和风险约束几类。同时区分表象问题和可能根因。”
这两句话之间的差别，不只是提示词写得长一些。
后者已经把工作顺序定下来了：先不急着解决，先定义问题。
再往后，还可以继续问：“请对这些问题按用户影响、业务影响、紧急程度、解决成本、执行难度和长期价值进行评分，并给出优先级排序。”
这时，AI 不再只是整理材料，而是在被要求协助判断轻重缓急。
再进一步：“请不要只给一个方案。请分别给出保守稳定型、效率优先型、进攻增长型三个方案，并比较它们的目标、适用场景、优点、缺点、成本、风险和资源需求。”
这时，AI 被带入了方案权衡。
最后还可以问：“请基于上述比较，明确当前采用哪个方案，哪个作为备选，哪个暂不采用。不要给模糊建议。”
这时，交互进入了决策。
从这个角度看，指令不是几句好看的话，它是一个人工作思路的实体化。
你怎么给 AI 下指令，往往就说明你怎么理解这件事。
你是否先定义问题；
是否要求排序；
是否会追问依据；
是否知道方案需要比较；
是否要求设置里程碑和退出线。
这些都会体现在指令里。
这一系列指令背后，映射的是一个人处理复杂问题的方式。
先要答案，还是先定义问题
复杂材料，表面上像是一个问题，实际往往混着好几类问题。
用户说不好用，可能是功能问题，也可能是流程太长；
项目推进慢，可能是资源不足，也可能是优先级没有排清楚；
团队觉得方案难落地，可能不是方案本身错了，而是验证路径设计复杂；
产品转化不好，可能不是用户不需要，而是价值表达没有说到用户心里。
如果这些问题混在一起，直接让 AI 给方案，就容易得到一套看似全面、但实际偏移的回答。
比如它会建议“优化功能、加强运营、完善流程、提高转化”。这些话没有错，但也没有真正回答：到底哪个问题最先处理？哪个问题只是表象？哪个问题卡住了后续动作？
所以，与 AI 交互时，第一步先慢一点。
不是马上问：“怎么办？”
而是先问：“现在有哪些问题？”
更准确一点，是要求 AI 把问题拆开：“请先不要直接给解决方案。请基于材料识别所有主要问题，并将问题分为用户需求、产品功能、业务流程、团队执行、成本交付、市场竞争和风险约束几类。同时区分哪些是表象问题，哪些可能是根因。”
这个动作看起来不像是在“生成答案”，但它很关键。因为一个没有被定义清楚的问题，很容易被一个看起来完整的方案带偏。
AI 让生成方案变快了，但它不会自动替人判断：你问的那个问题，是不是一开始就问错了。
目标感：不是写一个目标，而是知道什么时候算成功
在给出指令之前，先问自己一件事：这件事最后要做到什么程度？
方案会写目标，比如：提升效率、优化体验、降低成本、提高转化。
那在提供交互指令时，是否可以将指令数据化。
提升效率，是从多少提升到多少？
优化体验，是优化哪一类用户的哪一个环节？
降低成本，是降低人力成本、沟通成本，还是试错成本？
提高转化，是在什么周期内提高多少？
如果这些问题没有回答，目标只是方向，不是标准。
里程碑也是一样。方案写“分阶段推进”。但如果继续问下去，就会发现“阶段”并不清楚。
当天要完成什么？第 1 周要看到什么？第 2 周要验证什么？第 1 个月要交付什么？
每个阶段有没有具体交付物？交付物由谁判断合格？如果不合格，下一步怎么调整？这些问题都需要在方案里出现。
更容易被忽略的是退出机制。一个方案不能只说怎么开始，也要说什么时候停。
如果两周后核心指标没有变化，要不要继续？如果用户反馈和预期相反，要不要调整方向？如果成本超过预算，要不要切换轻量方案？如果关键假设被证伪，要不要重新定义问题？
指令不愿意谈退出，觉得退出像是失败。
在真实项目里，没有退出线的方案，往往最容易消耗资源。因为只要没有明确红线，项目就可以一直“再试试”。
与 Claude 交互时，可以把这件事直接写进指令：“请将推荐方案拆成当天、第 1 周、第 2 周、第 1 个月的执行里程碑。每个阶段都要有交付物、验收指标、风险点和调整机制。”
还可以继续问：“请补充退出机制。什么情况下说明当前方案不可继续推进？请设置时间、成本、用户反馈、技术可行性四类红线，并说明触发红线后切换到哪个备选方案。”
这样的指令不是为了显得复杂。
它是在提醒 AI：方案不是写完就结束，方案要被执行，也要允许被停止。
不要把流畅答案当可靠答案
和 AI 对话时，有一个很容易忽略的风险：它的语言太顺了，顺到问题不容易被看见。
它会把假设写得像事实，会把建议写得像结论，会把没有验证过的判断写得很完整，也会把一个复杂问题整理得像已经被解决了一样。
这不是 Claude 独有的问题。很多生成式 AI 都会有类似特征。它擅长把材料组织成一段完整表达，但完整表达不等于可靠判断。
所以，使用 AI 时，人需要保留一点不信任。不是怀疑一切，而是不把“写得顺”直接等同于“说得对”。
可以追问：
“你这个判断的依据是什么？”
“这里有哪些隐含假设？”
“如果这些假设不成立，方案会在哪里失败？”
“这版方案中最空泛、最难落地的地方是哪几个？”
“请从资源有限、时间有限、用户反馈不稳定的角度重新评估。”
这些问题并不是为了为难 AI，它们是在把 AI 的输出从文字拉回现实。
很多方案在纸面上都能成立，到了执行时才发现，成本不够、用户不买账、团队做不动、数据不可得、关键假设从一开始就没有验证。
如果这些问题在第一轮交互里没有被提出，后面就会变成执行中的麻烦。
面对一份看起来完整的 AI 答案时，需要我们继续找缺口。
大局观：不是所有问题都要现在解决
复杂问题里，几乎不会只有一个问题，但也不是所有问题都值得现在解决。
有的问题声音很大，但并不影响核心结果；
有的问题看起来不起眼，却卡在关键路径上；
有的问题解决起来很贵，但收益有限；
有的问题短期不显眼，拖久了会把后面的工作全部拖住。
这时候，需要的不只是罗列，而是排序。
AI 的答案可能太平均。它会把每个问题都写出来，也会给每个问题配一个建议。看上去很全面，但没有回答：现在最应该做什么？
真实工作里，资源总是有限的。团队注意力有限、时间有限、预算有限、用户耐心也有限。
所以，方案必须区分先后，可以这样要求 Claude：
“请对上述问题按用户影响、业务影响、紧急程度、解决成本、执行难度和长期价值进行 1–5 分评分，并给出优先级排序。请说明哪些问题必须优先解决，哪些可以暂缓，哪些看似重要但不是当前关键问题。”
这种评分不一定绝对精确，但它能逼迫 AI 把判断说出来：为什么这个问题优先于那个问题？为什么某个动作现在不做？为什么某个问题虽然存在，但不是当前主战场？
能不能把一堆问题收束到几个关键矛盾上，常常决定后面的方案是否有重心。
用户不只是被提到，而是要进入方案
AI 生成的方案里，经常会出现“用户体验”“用户需求”“用户反馈”这些词。
但这些词出现了，不代表用户真的进入了方案。
很多方案仍然是从产品功能出发。
功能不够，就加功能；使用率不高，就加提醒；转化不好，就降价；反馈不多，就加入口。
这些动作可能有用，也可能只是绕开了真正的问题。
用户真正需要的，未必是更多功能：
可能是更低的理解成本；
可能是更快完成某个任务；
可能是减少一次沟通；
可能是降低出错风险；
也可能只是想更确定地知道下一步该做什么。
所以，在和 Claude 交互时，可以把问题拉回用户：
“请不要从产品功能出发，请从用户真实需求出发重新分析。”
“请对用户进行分层，说明不同用户群体的核心诉求、价格敏感度、使用场景和付费动机。”
“请判断用户真正愿意为哪个价值付费。”
这些问题会改变方案的方向。
因为产品提供的是功能，用户购买的往往是结果。
如果一个方案只围绕内部动作展开，比如流程怎么改、功能怎么加、团队怎么分工，而没有说明用户真正获得了什么，那么它仍然是内部自洽的方案。
真正能落地的方案，通常要回答一个更朴素的问题：
用户为什么要在意这件事？
多方案不是为了全面，而是为了取舍
同一个问题，如果目标不同，方案就会不同。
如果更看重稳定性，方案会偏保守；如果更看重速度，方案会偏快速验证；如果预算有限，方案会偏轻量；如果需要争取竞争优势，方案会更进攻。
产品处在不同阶段，方案也不会一样。初创期可能更需要快速试错；成长期可能更需要放大有效路径；成熟期可能更需要稳定交付和精细管理。
因此，只让 Claude 给一个方案，往往不够。
可以这样问：
“请不要只给一个方案。请分别给出保守稳定型、效率优先型、进攻增长型三个方案，并比较它们的目标、适用场景、优点、缺点、成本、风险和资源需求。”
但多方案只是前半步，后半步是取舍。
当前阶段选哪个？
哪个作为备选？
哪个暂时不做？
触发什么条件后切换？
为什么这样选？
如果最后只是说“可根据情况选择”，判断就又退回去了。
方案比较的目的，不是把所有可能都留下来，而是让人更清楚地知道现在应该走哪一条路。
所以还可以继续问：
“请基于用户价值、成本、风险、执行可能性和长期收益，明确当前采用哪个方案，哪个方案作为备选，哪个方案暂不采用。不要给模糊建议。”
这个指令很重要，真实工作里，问题不是没有选择，而是迟迟不做选择。
AI 可以帮人列出选项，但选择仍然需要人来推动。
方案不是写出来的，是一轮轮推出来的
AI 的第一版回答，常常只是一个起点。
它能帮人把材料铺开，把结构立起来，把一些常见动作列出来。但如果停在这里，方案通常还不够硬。
让方案变好的，是后面的追问。
可以问：
“请指出你刚才方案里最可能失败的 5 个地方。”
“请补充这些方案各自的验证方式。”
“请基于资源有限的情况重新调整。”
“请把所有抽象表达改成可检查的动作。”
“请把推荐方案拆成当天、第 1 周、第 2 周和第 1 个月的里程碑。”
这些追问看起来细碎，但它们会把方案往可执行方向推。
有些问题只有追问到第二轮、第三轮才会出现。
第一轮看到的是方向，第二轮看到的是漏洞，第三轮才开始接近真实约束。
这也是 AI 协作里很重要的一点：不要把第一版答案当终点。
它只是一个可以继续加工的材料。
这和过去写方案、做评审、开项目会并没有完全不同。区别只是在于，现在那个能快速生成初稿的人，变成了 AI。
但初稿之后，仍然需要有人追问、删减、重排、修正、判断。
几组问法实例
如果把上面的观察落到操作上，可以保留几组常用问法。
它们不一定适合所有场景，但在面对复杂材料时，可以作为起点。
1. 先定义问题
请先不要给解决方案。请基于材料识别问题，并将问题分为用户需求、产品功能、业务流程、团队执行、成本交付、市场竞争和风险约束几类。同时区分表象问题和可能根因。
2. 做优先级排序
请对上述问题按用户影响、业务影响、紧急程度、解决成本、执行难度和长期价值进行 1–5 分评分，并给出优先级排序。请说明哪些问题必须优先解决，哪些可以暂缓。
3. 提出多个方案
请不要只给一个方案。请分别给出保守稳定型、效率优先型、进攻增长型三个方案，并比较它们的目标、适用场景、优点、缺点、成本、风险和资源需求。
4. 质疑第一版答案
请自我审查你刚才的方案，指出其中最空泛、最缺少依据、最难落地的 5 个地方，并逐一修正。
5. 补充用户洞察
请不要从产品功能出发，请从用户真实需求出发重新分析。请对用户进行分层，说明不同用户群体的核心诉求、价格敏感度、使用场景和付费动机。
6. 设置里程碑
请将推荐方案拆成当天、第 1 周、第 2 周、第 1 个月的执行里程碑。每个阶段都要有交付物、验收指标、风险点和调整机制。
7. 设置退出机制
请补充退出机制。什么情况下说明当前方案不可继续推进？请设置时间、成本、用户反馈、技术可行性四类红线，并说明触发红线后切换到哪个备选方案。
8. 做出明确取舍
请基于用户价值、成本、风险、执行可能性和长期收益，明确当前采用哪个方案，哪个方案作为备选，哪个方案暂不采用。不要给模糊建议。
这些问法的重点，不是让 AI 输出更长，而是让 AI 输出更受控。
它们把对话从“生成内容”带向“处理问题”。
AI 进入工作场景以后，人要留下什么
AI 工具进入工作场景以后，很多事情会变快。
资料整理会变快、初稿生成会变快、表格、方案、汇总、复盘都会变快。
但快不等于事情被解决，目标仍然需要人来定。
用户是谁，仍然需要人来判断。
哪个问题更关键，仍然需要人来排序。
哪个方案该选，仍然需要人来承担取舍。
什么时候继续，什么时候停止，也仍然需要人给出边界。
AI 可以帮人把答案写出来，但它不能替人承担判断的责任。
从这个角度看，面对一个不确定的问题，一个人能不能把它慢慢变清楚，并将这个过程形成有效的交互指令，会更加体会到AI带来的效能。
有些人用 AI，会更快得到一份普通答案；有些人用 AI，会更快组织一次完整的思考。区别不一定在工具上，更多时候，区别在于人有没有把目标、约束、判断和责任带进对话里。
AI 出现以后，答案变得很快。有时会让人误以为，只要答案出现了，问题就已经被处理了。当一个看起来完整的答案摆在面前时，人还会不会继续追问。
目标是什么？
用户是谁？
依据在哪里？
哪个问题最关键？
为什么选这个方案？
失败以后怎么办？
这些问题以前就在工作里，现在只是被 AI 重新照了一遍。
工具变快以后，人也许更需要慢一点。
慢一点定义问题；
慢一点判断答案；
慢一点做取舍；
慢一点给方案设边界。
不是为了拖慢工作，而是为了不被一份顺滑的答案带走。
