当你对 AI 说「用 Pythonic 的方式写」或「写一封委婉的拒绝邮件」时，AI 对「Pythonic」和「委婉」的理解可能和你完全不同。
标准不明确，是 AI 协作中另一个常见的效率杀手。
在 悟空技巧一：让 AI 向你提问 中，我们解决了需求模糊的问题；在 悟空技巧二：交付物先行 中，我们解决了格式返工的问题。今天，我们聚焦第三个维度：如何通过「示例驱动」，解决「风格不对齐」和「质量不可控」的问题。
🎯 核心问题：文字描述的局限性
人类擅长通过类比学习，大语言模型（LLM）同样如此。
当你用文字描述期望时，信息在传递过程中会经历严重的损耗：
- 「简洁」对你来说可能是 50 字，对 AI 来说可能是 200 字
- 「专业」对你来说可能是数据驱动，对 AI 来说可能是堆砌术语
- 「优雅」对你来说可能是函数式编程风格，对 AI 来说可能是过度设计
示例是高密度信息载体。 一段 20 行的代码示例包含的约束信息（命名习惯、缩进风格、注释方式、错误处理模式），远超 500 字的文字描述。
🧪 核心理念：示例驱动（Example-Driven）
用示例（Few-shot）替代纯文字描述，让 AI 精准对齐你的审美、风格和标准。
标准 Prompt 模式
"请参考以下示例的风格/格式/质量标准来完成任务：
[粘贴你的示例，可以是代码、文本、表格等]
请按照上述示例的方式，帮我 [具体任务]。"
🛠️ 实战场景
场景一：代码风格对齐
❌ 描述驱动：
“用 Pythonic 的方式写一个数据验证函数”
✅ 示例驱动：
“请参考以下代码的风格来编写数据验证函数：
def validate_user_input(data: dict[str, Any]) -> ValidationResult: """Validate user registration payload. Args: data: Raw JSON payload from request body Returns: ValidationResult with is_valid flag and error messages """ if not data.get("email"): return ValidationResult(is_valid=False, errors=["email is required"]) # ... validation logic请注意：
- 使用类型注解（type hints）
- 函数名用动词开头
- 包含 Google 风格的 docstring
- 错误信息用小写开头
请按照上述风格，帮我写一个订单验证函数。”
结果：AI 生成的代码风格与你团队的规范高度一致，无需重构命名和注释。
场景二：邮件语气对齐
❌ 描述驱动：
“写一封委婉的拒绝邮件，拒绝客户的功能定制需求”
✅ 示例驱动：
“请参考以下邮件的语气和措辞风格：
‘尊敬的张总，
非常感谢您提出的宝贵建议。我们认真评估了您关于 XX 功能的需求，这个想法确实能解决一部分用户的痛点。
考虑到目前产品架构的设计方向，以及我们 Q3 的资源排期，短期内可能无法将其纳入开发计划。但我们会将这个需求记录在我们的需求池中，在未来的版本规划中优先考虑。
同时，我们建议您可以尝试通过 XX 方式来达到类似的效果…
再次感谢您的理解与支持。’
请按照上述风格，帮我写一封拒绝客户关于 API 速率限制提升需求的邮件。”
结果：AI 生成的邮件语气委婉但不失坚定，既表达了拒绝，又给出了解决方案，完全符合你的沟通风格。
场景三：数据分析报告对齐
❌ 描述驱动：
“帮我分析一下这个销售数据”
✅ 示例驱动：
“请参考以下分析报告的结构和呈现方式：
核心发现：Q2 销售额同比增长 15%，但客单价下降 8%
关键数据：
- 总销售额：1,250 万（同比 +15%）
- 订单量：45,000 单（同比 +25%）
- 客单价：278 元（同比 -8%）
归因分析：
- 订单量增长主要来自新用户（占比 65%），新用户客单价普遍偏低
- 促销活动频次增加 30%，折扣力度加大
建议：
- 针对新用户设计阶梯式满减策略，提升首单客单价
- 减少低效促销，聚焦高转化渠道
请按照上述结构，帮我分析附件中的 Q3 用户留存数据。”
结果：AI 生成的报告结构清晰、数据驱动、结论可执行，完全符合你的汇报标准。
🧠 为什么示例驱动有效？
- 信息密度极高：示例中隐含的风格、格式、粒度、语气等约束，AI 都能通过模式匹配捕捉到，无需你逐一用文字描述。
- Few-shot 是 LLM 最强能力之一：大语言模型在 Few-shot（少样本）场景下的表现远优于 Zero-shot（零样本）。示例能激活模型内部相关的模式，显著提升输出质量。
- 示例即规范（Example as Spec）：在测试驱动开发（TDD）中，测试用例本质上也是示例。通过示例定义预期行为，比文字描述更精确、无歧义。
🚀 进阶技巧
技巧一：反例同样重要
给 AI 看「不要这样做」的示例，效果往往比「应该这样做」更强。
"请生成一份代码审查清单。
✅ 正面示例：'[ ] 安全性: 检查 SQL 查询是否使用参数化绑定，避免拼接字符串'
❌ 反面示例：'[ ] 代码要简洁，注意安全'
请按照正面示例的粒度生成，避免反面示例的泛泛而谈。"
技巧二：渐进式示例
对于复杂任务，先给简单示例建立基线，再给复杂示例展示边界。
"请参考以下示例生成数据转换函数。
简单示例（单字段）：
[代码示例]
复杂示例（多字段嵌套 + 异常处理）：
[代码示例]
请按照复杂示例的标准，帮我处理以下数据转换需求。"
技巧三：示例 + 标注
在示例中加注释解释「为什么这里这样做」，AI 能学到更深层的模式。
"请参考以下邮件示例：
'尊敬的客户，
感谢您的反馈。（先肯定对方，建立良好氛围）
我们理解您的担忧，（表达同理心）
经过核实，具体情况如下...（用事实回应，而非情绪）'
请注意括号中的策略说明，在生成新邮件时应用相同的沟通策略。"
🔄 三种技巧的组合工作流
将提问澄清、交付物先行、示例驱动结合起来，我们可以构建一个完整的 AI 协作工作流：
┌─────────────────────────────────────────────────────────┐
│ 高效 AI 协作工作流 │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. 需求提出 │
│ ↓ │
│ 2. 提问澄清（技巧一） │
│ AI 向你提问，确认需求细节、边界条件、隐含假设 │
│ ↓ │
│ 3. 交付物定义（技巧二） │
│ 明确输出格式、结构、长度、禁忌事项 │
│ ↓ │
│ 4. 示例对齐（技巧三） │
│ 提供正面/反面示例，对齐风格和标准 │
│ ↓ │
│ 5. AI 执行生成 │
│ 输出直接可用的交付物，零返工 │
│ │
└─────────────────────────────────────────────────────────┘
三种技巧的对比与互补
| 维度 | 技巧一：提问澄清 | 技巧二：交付物先行 | 技巧三：示例驱动 |
|---|---|---|---|
| 解决的问题 | 需求模糊，AI 猜不准意图 | 格式不对，后期返工成本高 | 标准不明确，风格不对齐 |
| 触发时机 | 需求刚提出时 | 需求确认后，执行前 | 执行前，或迭代优化时 |
| 核心动作 | AI 向你提问 | 你定义验收标准 | 你提供参考样例 |
| 适用场景 | 探索性问题、复杂任务 | 结构化文档、表格、代码 | 风格敏感任务、代码规范 |
| 收益 | 答案更精准，方向不偏 | 格式直接可用，零调整 | 风格高度一致，质量可控 |
🧠 本质思考：AI 协作是管理能力的延伸
很多人把 AI 当作「聊天机器人」，期待它像人类同事一样通过默契理解你的意图。但 AI 的本质是概率模型，它没有长期记忆中的「默契」，也没有对你个人偏好的隐性认知。
高效的 AI 协作，本质上是高效的项目管理。
- 提问澄清 = 需求分析（Requirements Analysis）
- 交付物先行 = 验收标准定义（Acceptance Criteria）
- 示例驱动 = 参考实现（Reference Implementation）
当你能清晰地定义需求、标准和示例时，AI 就能成为你最可靠的执行者。反之，如果你自己都没想清楚要什么，AI 只会放大你的模糊，生成一堆看似正确但毫无用处的内容。
AI 一直都很聪明，只是你需要学会如何给它下达可执行的指令。
你在实际使用悟空或其他 AI 工具时，有哪些「示例驱动」的成功案例？或者有哪些场景你觉得示例特别难给？欢迎留言讨论。