与 AI 对话的提问
📍 位置:提问的艺术 / AI 交互
📌 核心发现:问题质量决定 AI 输出上限——清晰的意图表达、结构化的上下文、迭代式追问三者共同构成高质量 AI 对话的基础;从”写关键词”到”描述意图”的范式转变正在发生
📥 输入:Anthropic/OpenAI/Google 官方文档、prompt 工程社区、MIT Sloan 研究、AI Fluency Index 研究
📤 流向:→ findings.md AI 提问部分
目录
- 三大厂商的官方提问原则
- AI 对话中的高级提问技巧
- 不同 AI 工具的提问差异
- AI 时代的提问范式转变
- 常见提问反模式
- 实战提问模板库
1. 三大厂商的官方提问原则
1.1 Anthropic(Claude)的核心原则
来源:Anthropic 官方 Prompt 最佳实践
Anthropic 提出了一个核心隐喻,极其精准地描述了 AI 提问的本质:
把 Claude 想象成一个极其聪明但刚入职的新同事——他缺少你的上下文和工作规范。你解释得越精准,结果就越好。
黄金法则:把你的 prompt 给一个对任务缺乏背景的同事看,让他按指示操作。如果他会困惑,Claude 也会困惑。
六大核心原则
原则一:清晰直接(Be Clear and Direct)
不要指望 AI 从模糊指令中”猜”出你的意图。
| 差的提问 | 好的提问 |
|---|
创建一个数据分析面板 | 创建一个数据分析面板。尽可能包含相关的功能和交互。超越基础功能,创建一个功能完整的实现。 |
帮我写个总结 | 帮我写一个 300 字以内的总结,重点突出三个核心发现,面向非技术背景的管理层读者,使用简洁的商业语言 |
关键:
- 用编号列表或项目符号提供指令步骤,明确顺序和完整性
- 具体说明输出格式和约束条件
- 想要”超越预期”的表现?明确说出来,而非靠暗示
原则二:提供上下文(Add Context to Improve Performance)
解释”为什么”比只说”做什么”更有效——Claude 能从动机中泛化理解。
| 差的提问 | 好的提问 |
|---|
永远不要使用省略号 | 你的回答会被文本转语音引擎朗读,所以永远不要使用省略号,因为转语音引擎不知道如何发音 |
用简单的语言回答 | 我是一个高中生,正在准备生物考试,请用高中水平的语言解释光合作用,避免大学级别的专业术语 |
原则三:用示例引导(Use Examples Effectively)
Few-shot 示例是控制输出格式、语气和结构最可靠的方式。
最佳实践:
- 提供 3-5 个示例效果最好
- 示例要多样化——覆盖边缘情况,避免 AI 只学到某个不期望的模式
- 用
<example> 标签包裹示例,让 AI 能区分示例和指令
- 可以让 Claude 评估你的示例是否够多样,或基于已有示例生成更多
原则四:用 XML 标签结构化(Structure Prompts with XML Tags)
当 prompt 混合了指令、上下文、示例和输入时,XML 标签能消除歧义。
<context>
我们是一家 B2B SaaS 公司,主要客户是中小企业的 HR 部门
</context>
<task>
分析以下客户反馈,提取关键痛点并按紧急程度排序
</task>
<output_format>
以表格形式输出,列:痛点 | 严重程度(高/中/低)| 出现频次 | 建议优先级
</output_format>
<customer_feedback>
{{反馈内容}}
</customer_feedback>
原则五:赋予角色(Give Claude a Role)
即使一句话的角色设定也能显著聚焦 AI 的行为和语气。
你是一位有 20 年经验的 Python 后端架构师,专注于高并发系统设计。
原则六:长文档放在前面(Long Context at Top)
处理长文档时,将文档放在 prompt 顶部,查询和指令放在底部。测试表明这能提升高达 30% 的回答质量,特别是在复杂的多文档输入场景中。
1.2 OpenAI(ChatGPT/GPT)的核心策略
来源:OpenAI Prompt Engineering Guide、OpenAI Help Center
OpenAI 的指南围绕六大策略展开:
策略一:写清晰的指令(Write Clear Instructions)
- 在查询中包含细节:越具体越好
- 要求模型采用某个角色(persona)
- 用分隔符清晰标注不同部分(如
###、"""、<tag>)
- 指定完成任务所需的步骤
- 提供示例(few-shot)
- 指定输出长度
| 差的提问 | 好的提问 |
|---|
帮我写一封邮件 | 帮我写一封给供应商的邮件,语气礼貌但坚定,要求在本周五之前确认发货日期。邮件不超过 150 字。 |
总结一下会议内容 | 用以下格式总结会议:1) 关键决议(每条一句话)2) 待办事项(谁/做什么/何时完成)3) 遗留问题 |
策略二:提供参考文本
当需要准确引用时,告诉模型基于提供的文本回答,并引用原文。这减少了幻觉(hallucination)。
基于以下三引号内的文章回答问题。如果文章中找不到答案,请回答"文章中未提及"。
"""
{{文章内容}}
"""
问题:作者对气候变化的主要论点是什么?
策略三:把复杂任务拆成子任务
不要把所有事情塞进一个 prompt。复杂任务应该拆解为流水线(pipeline)。
策略四:给模型”思考时间”
要求模型先推理再给答案,而非直接跳到结论。
回答之前,请先:
1. 列出你的推理步骤
2. 检查有没有遗漏的角度
3. 最后给出结论
策略五:使用外部工具
告诉模型可以调用搜索、代码执行等工具,让它知道自己的能力边界。
策略六:系统性地测试变更
对 prompt 的修改应该有评估标准——不是”感觉好了”就行。
1.3 Google(Gemini)的提示设计策略
来源:Google AI Prompting Strategies
Google 的策略与前两家有共识,但也有独特之处:
核心结构三要素
每个 prompt 应包含:
- 输入(Input):问题、任务、实体或补全请求
- 约束(Constraints):什么不要做
- 输出格式(Response Format):想要什么格式的回答
Google 特有建议
- 始终包含 few-shot 示例——没有示例的 prompt 效果普遍更差
- 关键指令放在最前面——Gemini 对开头的指令更敏感
- 海量上下文放前面,问题放后面——利用 Gemini 的百万 token 窗口
- 用过渡短语连接:如”基于以上信息……”
- 别指望模型生成事实性信息——始终提供参考资料
- Meta Prompting(元提示):让 AI 帮你写更好的 prompt,它会生成长达数页的详细提示来优化输出
1.4 三家共识提炼
| 维度 | Anthropic | OpenAI | Google |
|---|
| 核心主张 | 把 AI 当聪明新人,给足上下文 | 写清晰指令,拆分复杂任务 | 结构化输入 + 始终给示例 |
| Few-shot | 3-5 个,用 XML 标签包裹 | 强调 one-shot/few-shot | 认为没示例的 prompt 效果差 |
| 思考链 | 内置 adaptive thinking,也支持手动 CoT | ”给模型思考时间” | 建议拆分复杂任务 |
| 角色设定 | 系统 prompt 中一句话即可 | 要求模型采用 persona | 不特别强调 |
| 长文档 | 文档放顶部,查询放底部 | 提供参考文本 | 上下文在前,问题在后 |
| 结构化 | XML 标签 | 分隔符(###、""") | XML 或 Markdown 标题 |
| 反幻觉 | 引用原文,先调查再回答 | 基于参考文本回答 | 别指望模型生成事实 |
三家的核心共识:
- 清晰 > 简短——详细的指令永远优于简洁但模糊的指令
- 给示例比给规则更有效
- 结构化能消除歧义
- 让 AI 先思考再回答能提升复杂任务的质量
- 拆分复杂问题为子问题
2. AI 对话中的高级提问技巧
2.1 Chain of Thought(思维链提示)
原理:引导 AI 展示中间推理过程,而非直接跳到答案。对数学、逻辑、多步推理任务效果显著。
来源:Prompt Engineering Guide - CoT、IBM - Chain of Thought
三种变体
Zero-shot CoT(零样本思维链)——最简单:
以下数学问题,请一步一步地思考再回答。
一个商店打 8 折出售一件原价 200 元的商品,之后又在折后价基础上打 9 折。最终价格是多少?
仅仅加上”一步一步地思考”就能显著提升准确率。
Few-shot CoT(带示例的思维链):
问题:Roger 有 5 个网球,又买了 2 盒网球,每盒 3 个。他现在有多少个网球?
思考过程:Roger 一开始有 5 个球。2 盒 x 每盒 3 个 = 6 个新球。5 + 6 = 11 个。
答案:11
问题:食堂有 23 个苹果。用了 20 个做午餐,又买了 6 个。还剩多少苹果?
Auto-CoT(自动思维链):让模型自动生成和选择有效的推理路径,减少人工构造示例的成本。
使用建议
| 场景 | 是否用 CoT | 原因 |
|---|
| 简单事实查询(“法国首都是哪”) | 否 | 过度思考反而降速 |
| 多步数学/逻辑推理 | 是 | 显著提升准确率 |
| 代码调试 | 是 | 帮助 AI 定位问题根因 |
| 文本摘要 | 通常不需要 | 除非需要判断取舍 |
| 复杂决策分析 | 是 | 暴露推理盲点 |
Anthropic 特别提醒:Claude 4 系列模型内置了 adaptive thinking(自适应思考),在大多数情况下无需手动触发 CoT——模型会根据问题复杂度自行决定是否深度思考。手动 CoT 作为 fallback 仍然有效。
2.2 角色设定提问(Role-Based Prompting)
原理:给 AI 一个身份,让它从特定专业视角回答。
基础角色设定
你是一位有 15 年经验的分布式系统架构师,曾在 Google 和 Netflix 任职。
请评估以下微服务设计方案的优缺点。
多角色辩论
请从以下三个角色的视角分析"是否应该将单体应用拆分为微服务"这个问题:
1. 【CTO 视角】:关注技术演进和团队能力
2. 【CFO 视角】:关注成本、ROI 和风险
3. 【一线开发者视角】:关注日常开发体验和工作量
每个角色分别陈述立场后,给出综合建议。
反直觉角色设定
你是一个刻意挑毛病的代码审查者(Devil's Advocate)。你的任务是找出以下代码中所有可能的问题,包括安全漏洞、性能瓶颈、可维护性风险。不要客气。
| 差的角色设定 | 好的角色设定 |
|---|
你是专家 | 你是一位有 10 年经验的 iOS 开发者,专注于 SwiftUI 和性能优化,曾负责日活 500 万的社交 App |
帮我看看这段代码 | 以高级代码审查者的身份审查这段代码,重点关注:1) 安全性 2) 性能 3) 可读性。对每个问题给出严重程度和修复建议 |
2.3 多轮对话中的追问策略
来源:Anthropic AI Fluency Index
Anthropic 的 AI Fluency 研究发现了一个关键数据:
迭代式对话中的用户质疑 AI 推理的概率是单轮对话的 5.6 倍,发现上下文缺失的概率是 4 倍。 85.7% 的高质量对话都展现了迭代和优化行为。
漏斗式追问法
第一轮:宽泛探索
"帮我梳理 React 状态管理的主流方案有哪些?"
第二轮:聚焦比较
"在 Redux Toolkit、Zustand、Jotai 三者中,对于中型 SaaS 应用(20-50 个页面),哪个更合适?请从学习曲线、性能、生态三个维度比较。"
第三轮:深入实践
"如果选 Zustand,在一个已有 Redux 的项目中渐进式迁移,你建议的步骤是什么?有哪些常见的坑?"
第四轮:质疑验证
"你提到 Zustand 不需要 Provider 包裹——但如果需要 SSR 支持呢?这是否会成为问题?"
”推回去”策略
Anthropic 的研究发现只有 30% 的用户会设定交互偏好。高阶用户会主动要求 AI 挑战自己:
在接下来的对话中,如果你发现我的假设有问题,请主动指出并挑战我的思维。
不要因为礼貌而回避争议性观点。
“停下来想”策略
在回答之前,先花 30 秒想想:
1. 我的问题有没有隐含的错误假设?
2. 有没有我没考虑到的重要维度?
3. 如果有,先指出再回答。
2.4 约束性提问(Constraint-Based Prompting)
原理:通过添加限制条件,缩小回答空间,提高输出质量。
格式约束
用以下格式回答,不要偏离:
## 技术方案
[2-3 句话概述]
## 优点(最多 3 条)
- ...
## 风险(最多 3 条)
- ...
## 建议
[1 句话决策建议]
长度约束
用一条推文的长度(280 字符以内)解释量子计算。
用三句话总结这篇文章:第一句说主题,第二句说核心发现,第三句说实际意义。
受众约束
向一个 10 岁的孩子解释区块链——不使用任何技术术语,只用日常生活的比喻。
为 C-level 高管写一份 AI 投资建议——假设读者对技术没有深入了解,但对商业指标(ROI、市场份额、竞争优势)非常敏感。
否定约束 vs 肯定约束
重要原则:用肯定语言描述你”要什么”,而非”不要什么”。
| 否定约束(效果差) | 肯定约束(效果好) |
|---|
不要用列表 | 用流畅的段落散文体写作 |
不要用 Markdown | 输出纯文本,句与句之间用自然段落分隔 |
不要举 2000 年之前的例子 | 只使用 2000 年之后的例子 |
不要太长 | 控制在 200 字以内 |
2.5 Few-shot 提问(示例提问法)
原理:通过给出输入-输出的示例对,让 AI 学会你想要的模式。
基础 Few-shot
请按以下示例的风格,将技术概念翻译为通俗解释:
示例 1:
技术概念:API(Application Programming Interface)
通俗解释:API 就像餐厅的服务员——你(应用程序)不需要走进厨房(服务器),只需要告诉服务员(API)你想要什么,服务员会帮你从厨房拿来。
示例 2:
技术概念:缓存(Cache)
通俗解释:缓存就像你把常用电话号码写在便利贴上贴在桌边——你不用每次都翻通讯录(数据库),瞟一眼便利贴就行了。
现在请翻译:
技术概念:负载均衡(Load Balancing)
Few-shot + 反例
我需要你写产品描述。以下是好例子和坏例子:
<example type="good">
输入:无线降噪耳机
输出:告别通勤噪音。30 小时续航让你整周不用充电,40dB 主动降噪把地铁变成图书馆。
</example>
<example type="bad">
输入:无线降噪耳机
输出:这是一款采用先进技术的无线蓝牙降噪耳机,具有优秀的音质和舒适的佩戴体验,适合各种场景使用。
</example>
坏例子的问题:太笼统、没有具体数据、没有场景感。
现在请为以下产品写描述:
输入:便携投影仪
2.6 Ask Before Answer(先问再答法)
来源:Tutorials Point - Ask Before Answer Prompts
原理:让 AI 在回答之前先向你提问,收集缺失的上下文。
基础版
我想做一个个人网站。在给我方案之前,请先问我 5 个关键问题,帮你了解我的具体需求。
AI 会问出类似:
- 网站的主要目的是什么?(作品展示/博客/简历/商业?)
- 你有技术背景吗?能接受多少编码?
- 预算范围是多少?
- 需要哪些核心功能?
- 有喜欢的网站风格参考吗?
进阶版:元提问
我要写一份 AI 战略报告给 CEO。
请你先分析:如果你是一个资深的 AI 战略顾问,你需要知道哪些信息才能写出一份高质量的报告?
列出你的信息需求清单,然后逐个问我。
2.7 苏格拉底式提问(Socratic Prompting)
来源:Socratic Prompting Guide、Towards AI - Socratic Prompt
原理:不让 AI 直接给答案,而是通过反复追问引导它暴露推理过程、标记不确定性。
核心价值:苏格拉底式提问迫使模型展示哪里是在”猜”,把不确定性转化为问题,并创建结构化的路径让你提供模型无法推断的约束条件。
我在考虑是否应该学 Rust。
不要直接给我建议。
请用苏格拉底式追问帮我理清思路——每次只问我一个问题,根据我的回答再问下一个,直到你觉得信息足够了再给出你的分析。
对话示例:
- AI: “你目前主要使用什么编程语言?你对它最大的不满是什么?”
- 用户: “Python,太慢了”
- AI: “慢在哪个环节?是 CPU 密集计算、I/O 等待、还是启动时间?”
- 用户: “CPU 密集的数据处理”
- AI: “你考虑过 Cython 或 NumPy 这类不换语言的加速方案吗?如果考虑过但不满意,具体原因是什么?”
- …
2.8 反转提问法(Reverse Prompting)
请你先阅读这段代码,然后不要给我评价。
而是告诉我:如果你是这段代码的面试官,你会问求职者哪些问题来测试他对这段代码的理解深度?
我刚学完 "Attention Is All You Need" 这篇论文。
请扮演面试官,用 5 个由浅入深的问题测试我是否真的理解了 Transformer。
3. 不同 AI 工具的提问差异
来源:Claude vs ChatGPT vs Gemini Prompting Practices
3.1 各模型的”性格”与适配策略
| 维度 | Claude | ChatGPT (GPT) | Gemini |
|---|
| 擅长 | 长文档分析、细致推理、写作润色、指令遵循 | 结构化输出、代码生成、格式控制 | 多模态研究、大量上下文处理、带源引用 |
| 上下文偏好 | 喜欢丰富的上下文,放在前面 | 喜欢简洁的分步指令 | 百万 token 窗口,适合海量资料 |
| 提问风格 | 像和资深同事讨论:给背景 → 给约束 → 要方案 | 像给助手下达指令:先格式 → 再步骤 → 附示例 | 像做研究:定问题 → 设范围 → 要出处 |
| 角色设定 | 效果极好,一句话即可改变行为 | 效果好,需要更具体的描述 | 效果一般,更依赖任务描述 |
| XML 标签 | 原生支持,强烈推荐 | 不特别需要,用 Markdown 即可 | 支持 XML 和 Markdown |
3.2 同一需求的不同提问方式
需求:分析一份 50 页的财报,找出风险点
给 Claude 的最优提问:
<context>
你是一位有 CFA 资质的财务分析师,专注于科技行业。
我需要你分析这份年报中的潜在风险。
</context>
<document>
{{50页财报内容}}
</document>
<task>
1. 先引用报告中与风险相关的关键段落
2. 按以下维度分析风险:财务风险、运营风险、市场风险、合规风险
3. 对每个风险给出严重程度(高/中/低)和你的判断依据
4. 指出报告中可能在"美化"的数据
</task>
给 ChatGPT 的最优提问:
角色:CFA 财务分析师,科技行业专家
任务:分析附件财报的风险点
输出格式:
| 风险类型 | 具体风险 | 严重程度 | 证据(引用页码) | 被美化的可能性 |
步骤:
1. 通读全文
2. 提取风险相关段落
3. 分类填入表格
4. 最后写一段 200 字的风险总结
语言:中文
给 Gemini 的最优提问:
研究任务:分析以下财务报告的风险因素
范围:2024 财年数据,重点关注与行业趋势不一致的指标
对比基准:同行业上市公司平均水平
要求:
- 每个风险点标注原文出处(页码/段落)
- 与公开的行业报告交叉验证
- 标记置信度(确定/可能/推测)
输出:结构化报告 + 风险热力图描述
{{财报内容}}
3.3 推理型模型 vs 标准模型的提问差异
重要发现:对于 OpenAI 的 o1/o3 等推理型模型(Reasoning Models),以及 Claude 开启 extended thinking 时,提问策略有显著不同:
| 维度 | 标准模型 | 推理型模型 |
|---|
| CoT 提示 | 需要手动加”请一步步思考” | 不需要也不应该加——模型自带推理链 |
| 指令风格 | 越详细越好 | 直接说目标即可,过度指导反而干扰 |
| 角色设定 | 有用 | 效果有限,模型更关注问题本身 |
| 示例 | 3-5 个最佳 | 1-2 个或零个即可 |
# 给标准模型(如 GPT-4、Claude Sonnet)的提问
请一步一步分析以下代码的时间复杂度:
1. 先识别每个循环的迭代次数
2. 然后分析嵌套关系
3. 最后给出总复杂度
# 给推理模型(如 o3、Claude Opus with thinking)的提问
分析以下代码的时间复杂度。
4. AI 时代的提问范式转变
4.1 从”搜索关键词”到”描述意图”
来源:Unite.AI - From Prompt Engineering to Intent Engineering
旧范式:关键词思维
搜索引擎:React state management comparison 2025
你需要自己组合关键词、筛选结果、综合判断。
新范式:意图描述
AI 对话:我们团队有 3 个前端开发者,都熟悉 React 但没用过状态管理库。
项目是一个中型 B2B SaaS,大约 30 个页面,需要处理复杂的表单状态和 API 缓存。
哪个状态管理方案最适合我们?
请从学习成本、长期维护性、社区生态三个维度分析。
关键转变:
| 搜索时代 | AI 对话时代 |
|---|
| 优化关键词组合 | 描述完整意图和约束 |
| 筛选链接 → 自己综合 | AI 综合 → 你验证和追问 |
| 一次性查询 | 迭代式对话 |
| 去噪是人的工作 | 去噪可以交给 AI,但验证是人的工作 |
| 问”是什么” | 问”怎么选”、“为什么”、“对我来说呢” |
4.2 从”意图工程”到累积式协作
来源:Intent Engineering - Medium
传统 prompt 工程把每次交互视为独立事件。意图工程(Intent Engineering)把交流视为累积的:
- 持续上下文:现代 AI 系统维护用户画像和对话历史,理解你的累积目标
- 上下文推理:当模型知道你是一个有特定监管约束的医疗产品经理时,请求自动携带更丰富的含义
- 澄清对话:高级系统不会沉默地执行请求,而是主动识别歧义并提出限定性问题
这意味着:最好的提问不是工程化的 prompt,而是清晰地表达你想达成什么以及为什么。
4.3 AI 作为思考伙伴
来源:MIT Sloan - Question Burst Catalyst
MIT Sloan 的 Hal Gregersen 开发的 Question Burst Catalyst 工具揭示了一个深刻洞察:
不要向 AI 要答案——向 AI 要问题。
LLM 倾向于给出”平均的、模因型的”回答,走阻力最小的路径。真正高价值的人机协作不是 AI 给你答案,而是 AI 帮你提出更好的问题。
Question Burst 四步法:
- 定义挑战:AI 帮你精炼问题陈述
- 人先提问:你先快速产生自己的短问题——刻意在 AI 介入之前,防止人类的”催化性追问能力”萎缩
- AI 变换视角:给 AI 分配一个角色(历史人物、虚构角色、非人类视角)来突破惯性思维
- 洞察与行动:AI 按主题分类问题,帮你找到最可行动的一个
实操示例:
我正在思考一个问题:我们的 AI 产品如何避免在采纳过程中挤掉对核心人力能力的投入?
请你以以下视角各提出 3 个尖锐的问题:
1. 一位反对 AI 的人文主义哲学家
2. 一位纯粹追求利润的华尔街投资人
3. 一位在一线被要求使用 AI 工具的初级员工
然后综合这些问题,找出我可能忽视的盲点。
4.4 “问题质量决定输出上限”的底层逻辑
为什么问题质量如此重要?
这不仅是 AI 时代的现象,而是信息处理的底层规律:
- AI 的输出空间极大:一个模糊的问题对应的”合理回答”有无数个,AI 只能选一个”平均最优解”——这通常是泛泛而谈的废话
- 约束创造价值:每一个具体的约束条件都在缩小输出空间,把 AI 推向更精确、更有用的角落
- 上下文 = 压缩包:好的上下文相当于把你的知识和需求”压缩”传递给 AI,AI 解压后就能在你的思维框架内工作
- 追问 = 梯度下降:每一轮追问都在帮 AI 做”梯度下降”——不断逼近你真正需要的答案
形象比喻:
问 AI 问题就像是用语言画一个靶子。你的靶子画得越精准,AI 的箭就射得越靠近靶心。模糊的问题 = 没有靶子 = AI 只能朝大致方向射箭。
5. 常见提问反模式
来源:14 Prompt Engineering Mistakes - ODSC、Common Prompt Mistakes - Treyworks、Prompt Mistakes - mxmoritz
反模式 1:太模糊,没有锚点
❌ "帮我写个营销方案"
✅ "帮我写一个针对 25-35 岁女性用户的小红书营销方案,产品是一款售价 299 元的智能体脂秤,
预算 5 万元/月,目标是首月获取 1000 个种子用户。"
问题本质:缺少目标受众、预算、渠道、成功指标等关键约束,AI 只能给出泛泛的”万能方案”。
反模式 2:预设答案的问题
❌ "React 是不是比 Vue 好?"(暗示你期望听到 "是")
✅ "在以下场景中,React 和 Vue 各有什么优劣?
场景:3 人小团队、中型 B2B SaaS、需要快速迭代"
问题本质:预设答案的问题触发 AI 的”迎合倾向”(sycophancy),会倾向于同意你而非给出平衡分析。
反模式 3:一次问太多(Overloading)
❌ "帮我分析这个项目的技术选型,顺便写个项目计划,再估算一下成本,
最后帮我起草一封给投资人的邮件。"
✅ 拆成 4 轮对话:
第 1 轮:"帮我分析这个项目的技术选型。背景是..."
第 2 轮:"基于上面的技术选型,帮我写项目计划..."
第 3 轮:"估算上述方案的实施成本..."
第 4 轮:"起草给投资人的邮件,重点突出..."
问题本质:多个不相关任务塞进一个 prompt,AI 对每个任务的注意力都会被稀释。
反模式 4:缺少上下文
❌ "这个代码有 bug,帮我修一下"
✅ "这段 Python 代码在调用 API 时报 ConnectionTimeout。
环境:Python 3.11,requests 2.31,网络正常(curl 可以访问)。
错误日志:[贴出完整错误信息]
我已经试过:增加 timeout 到 30 秒,但没用。"
问题本质:就像告诉医生”我不舒服”而不描述症状。
反模式 5:把 AI 当搜索引擎
❌ "Python 怎么用?"
✅ "我有 Java 基础,现在需要用 Python 处理 CSV 数据。
请对比 Java 和 Python 在文件处理上的核心差异,
然后给我一个读取 CSV、过滤特定列、输出结果的完整示例。"
问题本质:把 AI 当 Google 用是浪费。AI 的优势在于理解你的具体情境并给出个性化的综合回答。
反模式 6:一次成型思维(One-Shot Mindset)
❌ 写了一个 prompt → 结果不好 → 放弃或从头来
✅ 写了一个 prompt → 结果不好 → 分析哪里不好 → 追问优化:
"上面的回答太笼统了。请更具体地分析第二点,
并给出 2 个真实公司的案例来佐证。"
问题本质:prompt 工程是迭代的,不是一次性的。初始 prompt 是起点,不是终点。
反模式 7:把 AI 当真理来源
❌ "GPT-4 的参数量是多少?"(然后直接引用 AI 的回答)
✅ "GPT-4 的参数量是多少?请标注你的信息来源。
如果你不确定,请明确说明而不是猜测。"
问题本质:AI 基于模式生成回答,不是基于”知道事实”。具体数据、引用、法律条文等必须回原始源验证。
反模式 8:否定指令陷阱
❌ "不要用术语" → AI 有时仍然用术语
❌ "不要太长" → AI 不知道多长算"太长"
✅ "用日常用语解释,假设读者没有技术背景"
✅ "控制在 200 字以内"
问题本质:告诉 AI “不要做什么”的效果远不如告诉它”要做什么”。
反模式速查表
| 反模式 | 症状 | 修复方法 |
|---|
| 太模糊 | AI 回答泛泛而谈 | 加上:受众、场景、约束、格式 |
| 预设答案 | AI 附和你的偏见 | 改为开放式问题,要求多角度分析 |
| 塞太多 | 每个部分都不够深入 | 拆成多轮对话 |
| 缺上下文 | 回答与你的情况不符 | 提供背景、已尝试的方案、环境信息 |
| 当搜索引擎 | 回答像百科词条 | 加上个人情境和具体需求 |
| 一次成型 | 对结果不满但不追问 | 分析不足 → 追问 → 迭代 |
| 当真理源 | 引用了不存在的数据 | 要求标注来源,回原始源验证 |
| 否定指令 | AI 忽视限制 | 改为肯定描述 |
6. 实战提问模板库
6.1 通用提问框架:CRISPE
| 要素 | 含义 | 示例 |
|---|
| Capacity | 角色/能力 | 你是一位资深产品经理 |
| Request | 请求/任务 | 帮我分析这个功能的 PRD |
| Insight | 背景洞察 | 我们是 B2B SaaS,核心用户是中小企业 HR |
| Statement | 约束声明 | 分析维度:用户价值、技术可行性、商业影响 |
| Personality | 语气/风格 | 直接坦率,不要过于乐观 |
| Experiment | 实验/迭代 | 先给一个初步版本,我会追问细化 |
6.2 技术问题模板
## 问题描述
[用 1-2 句话描述你遇到的问题]
## 环境
- 语言/框架版本:
- 操作系统:
- 相关依赖版本:
## 期望行为
[应该发生什么]
## 实际行为
[实际发生了什么]
## 已尝试的解决方案
1. [方案1] → [结果]
2. [方案2] → [结果]
## 错误日志/截图
[贴出关键信息]
6.3 决策分析模板
我需要在 [选项A] 和 [选项B] 之间做出选择。
背景:
- [你的具体情况]
- [约束条件]
- [优先级]
请从以下维度对比分析:
1. [维度1,如:短期成本]
2. [维度2,如:长期维护]
3. [维度3,如:团队学习曲线]
最后给出你的推荐,并说明在什么情况下你会改变推荐。
6.4 学习提问模板
我刚学完 [概念/课程],自认为理解了 [具体内容]。
请你:
1. 问我 3 个递进难度的问题来检验我是否真的理解
2. 根据我的回答,指出我的理解偏差
3. 用一个我没想到的角度帮我加深理解
6.5 写作协助模板
我需要写一篇 [类型] 的文章。
目标读者:[谁]
核心观点:[你想表达什么]
语气:[专业/轻松/说服性/...]
长度:[大约多少字]
参考风格:[像 XX 作者/媒体 的风格]
请你先给我一个大纲,我确认后再展开。
不要使用以下套路:[你讨厌的写作陈词滥调]
6.6 Anthropic 的”打光提示”对话范式
Anthropic AI Fluency 研究中发现的高阶用户行为模式,可以归纳为一个”打光”隐喻:
第一轮:打基础光 — 给出上下文和初始问题
第二轮:打侧光 — 追问 AI 遗漏的角度
第三轮:打反光 — 质疑 AI 的推理,要求辩护或修正
第四轮:打聚光 — 聚焦到最重要的部分深挖
第五轮:拍板 — 要求综合所有讨论给出最终建议
示例:
第一轮:
"我在考虑用 Rust 重写我们的 Python 数据处理管道。背景是处理 10TB/天的日志数据,
目前 Python 管道的延迟是 45 分钟,目标降到 5 分钟。团队 5 人,都是 Python 背景。"
第二轮:
"你提到了性能收益和学习曲线,但没有提到以下方面——迁移期间的双系统维护成本、
招聘 Rust 工程师的市场难度、以及 Python 生态(Polars/DuckDB)近期的性能进步。
请补充这些维度的分析。"
第三轮:
"你建议先用 Polars 优化。但如果 Polars 只能把延迟降到 15 分钟呢?
在什么条件下,直接上 Rust 反而是更经济的选择?"
第四轮:
"好的,聚焦到 Polars 方案。给我一个具体的 2 周 PoC 计划,
包括测试基准、成功标准、以及如果失败的回退方案。"
第五轮:
"综合以上所有讨论,给我一份 1 页的决策备忘录,
我可以直接发给 CTO 做决策参考。"
附录:提问能力自检清单
在发送消息给 AI 之前,快速过一遍这个清单:
参考来源