背景
用 AI 最常见的翻车，不是模型笨，而是没说清。一个模糊的需求喂进去，一个模糊的结果吐出来，然后反复来回改——来回的次数，几乎等于提示词缺失的信息量。
提示词工程不是“背咒语”，而是信息组织：把你脑子里那些理所当然的前提，显式地交给 AI。它没有你的上下文，你得替它补上。
核心矛盾：你以为说清楚了，其实只说了结论，没说约束、边界和评判标准。
分析
把“意图”和“实现”分开说
最常见的问题是只说怎么做，不说要什么。比如“写个函数处理串口数据”——处理成什么样？过滤噪声？组帧？校验？
更好的写法是先交代意图（要达成什么），再给约束（在什么条件下），最后才说实现（倾向怎么做）。顺序很重要：
- 意图 → 让 AI 选对方向，不至于南辕北辙。
- 约束 → 框定边界，运行环境、性能预算、不能碰什么。
- 实现 → 只在你确实有偏好时才写，否则交给 AI 发挥。
给足四类上下文
一个高质量提示词通常显式覆盖：
- 背景：这是什么项目、跑在什么硬件、当前在哪个环节。
- 目标：成功的样子是什么，用什么衡量。
- 约束：代码风格、内存/延迟预算、依赖限制、不能改的部分。
- 示例：一两个“输入→期望输出”的对照，比千言万语管用。
示例尤其关键。给一个“对的”样例，AI 就有了校准锚点；只靠文字描述，它只能猜你的标准。
让边界显式化
模糊指令最危险的地方是默认行为不可控。AI 会用训练数据里的最常见模式填空——但那未必是你想要的。
几个让边界清晰的做法：
- 说不做什么往往比说做什么更省事：“不要引入新依赖”、“不要改函数签名”、“先给方案别写代码”。
- 给终止条件：“到此为止停下等我确认”、“改到测试通过为止”。
- 标明确定性要求：“这里必须按 datasheet 第 X 页的时序”、“这里你可以自由发挥”。
实现
一个反例 → 正例的对照。
模糊版（容易翻车）：
帮我优化这段 DMA 收发的代码。
AI 不知道你优化的是速度、内存还是可读性，也不知道能不能动 ISR 结构，多半会给你一个“看起来更漂亮”但没解决真问题的版本。
结构化版：
[背景] STM32H7 上一个 UART + DMA 的接收链路，idle 中断组帧，
目前在 921600 波特率下偶尔丢帧。
[目标] 消除丢帧，单帧延迟不超过 2ms。
[约束] - 不能换 HAL 为 LL（量产固件，改动面要控）
- DMA 缓冲已在 SRAM4，别动内存段
- ISR 优先级保持 5
[请做] 1. 先分析最可能的丢帧原因（不超过 3 条）
2. 给最小改动的修复方案，先别写完整代码
3. 等我确认方向后再实现差别不在字数，在信息密度：背景、目标、约束、分步、终止点全齐了。AI 的第一版回答就大概率可用，省掉好几轮来回。
一个经验法则：如果你写完提示词，发现“其实还有三件事我没说但默认它得知道”——那就把那三件事写进去。AI 读不到你没写的。
几个高频反模式
- 只下结论不给标准：“做得好一点” → 好的标准是什么？
- 把约束藏在闲聊里：关键限制混在长段落中，容易被 AI 忽略，建议单列。
- 一次塞太多：一个提示词里塞五个独立任务，AI 容易顾此失彼，拆成多轮更稳。
- 不给反馈机会：要求一次性产出最终成品，不如让它先出大纲/方案再细化。
结论
- 提示词的本质是信息组织：意图、约束、示例、边界，缺一不可。
- 顺序很重要：先说要什么，再说在什么条件下，最后才说怎么做。
- 来回返工的次数 ≈ 提示词缺失的信息量；写清楚一次，胜过改十次。
把 AI 当成一个聪明但没有上下文的新同事：你能给他交代得多清楚，他就能还给你多准的结果。