AI 应用技巧：把上下文、约束、判断和验证放在提示词前面

很多人谈 AI 应用技巧，第一反应都是：

• 提示词怎么写
• 角色怎么设
• 语气怎么调
• 要不要多给几个例子

这些当然有用，但如果只停留在这一层，效果通常很不稳定。

真正决定 AI 好不好用的，往往不是“提示词修辞”，而是四件更底层的东西：

1. 上下文是否完整
2. 约束是否清楚
3. 人能不能看出 AI 的错误，并做出有效决策
4. 验证机制是否存在

如果这些事没有做好，再会写 prompt，最后也很容易变成“看起来说得通，但实际不可靠”。

一、先给完整上下文，不要让 AI 在空白里猜

很多低质量结果，并不是模型能力不够，而是因为输入上下文太薄。

常见问题包括：

• 只给一句模糊目标
• 不给现有代码、文档或数据结构
• 不说明当前改动范围
• 不说明哪些约束不能破坏
• 不说明成功结果应该长什么样

这时候模型只能自己补全上下文，而一旦开始补全，就会引入猜测。

更稳的做法是把上下文拆清楚：

• 当前目标是什么
• 当前已有实现是什么
• 哪些文件或模块相关
• 哪些行为是既有契约
• 哪些地方允许改，哪些地方不能动

如果是做代码任务，我更推荐把输入至少补到下面这几层：

1. 需求目标
2. 相关代码或接口
3. 现有报错或失败现象
4. 期望行为
5. 验证方式

上下文越完整，AI 越不需要靠猜。

二、把约束讲清楚，比多写几段提示词更重要

很多人和 AI 协作时，问题不是目标没说，而是约束没说。

比如：

• 需要 fail-fast，还是可以兜底
• 能不能改 public API
• 是否必须兼容旧数据
• 测试要补在哪一层
• 是否允许引入新依赖
• 如果是参数错误，能不能自己猜接口用法

这些东西如果不提前说清楚，AI 往往会默认选一个“看起来最省事”的路径。但省事不等于对。

所以在真实项目里，我更看重这种约束表达：

• 如果是参数不对、接口不兼容、SDK 用法不确定，不要猜
• 优先去查官方文档或权威资料
• 如果项目里有 Context7 这类文档工具，就直接用它核对
• 没证据的前提下，不要自己脑补“应该这么用”

这条非常重要，因为参数类错误是最容易被“经验主义修复”误导的。

模型看到一个函数名、一个看起来熟悉的 API，很容易直接按记忆拼一个调用方式。问题在于：

• 库版本可能变了
• 参数名可能变了
• 必填项可能变了
• 返回结构可能变了

这类错误如果靠猜修，有时表面能过一关，后面会继续炸。

三、修 bug 时，先复现，再改代码

这是我最看重的一条 AI 协作原则之一：

修 bug 之前，先用测试把 bug 抓住。

原因很简单。你如果没有一个稳定复现方式，就很难判断：

• 当前改动到底有没有修到点上
• 修的是根因，还是只压住了一个表象
• 有没有顺手引入新的回归

很多时候，AI 最容易犯的错不是“完全不会修”，而是：

• 先改了一堆实现
• 看起来逻辑变复杂了很多
• 但其实没有稳定证明 bug 被复现过，也没有证明 bug 已经消失

更稳的流程应该是：

1. 先定义复现条件
2. 先补一个失败测试
3. 跑测试，确认它现在确实失败
4. 再修改实现
5. 再跑测试，确认它转为通过
6. 最后补必要的回归验证

四、把 AI 放在“候选方案生成器”位置，而不是最终裁判位置

AI 很适合做这些事：

• 提出候选思路
• 展开初版实现
• 整理文档
• 总结差异
• 根据已有约束快速补测试样例

但它不适合在缺少验证机制时直接充当最终裁判。

更准确地说，AI 的最佳位置通常是：

• 帮你加速推进
• 帮你降低机械劳动
• 帮你快速铺开候选实现

而不是：

• 替你决定哪个方案一定对
• 替你判断哪个参数一定合法
• 替你确认哪段代码一定不会回归

一旦把它放到“最终裁判”的位置，就会出现一个常见问题：

它给出了一个非常流畅的答案，但团队没有建立程序化验证，所以没有人真正知道它是否可靠。

五、用好 AI 的关键，是你能看出它哪里错了

很多人会把“会用 AI”理解成会提问、会写 prompt、会让模型多输出几版。

这些当然有用，但还不是最关键的部分。

更关键的是：

你能不能看出 AI 的错误，并且在关键节点做出有效决策。

因为 AI 的很多错误并不会长得像明显错误。

它常常是：

• 表达很流畅，但前提错了
• 方案看起来完整，但漏了关键约束
• 代码能跑一部分，但破坏了边界行为
• 总结听起来合理，但把事实源看错了
• 给出的选择都有道理，但优先级判断不对

如果人看不出这些问题，AI 输出越快，风险反而越大。

因为你会在一个看起来顺滑、实际上已经偏掉的方向上继续投入。

所以真正有用的 AI 工作流，不能只设计“怎么让 AI 产出更多”，还要设计“人在哪里判断、按什么标准判断、发现偏差后怎么收口”。

这里人的作用不是事事亲自做，而是守住决策点。

例如：

• 哪个方案更符合当前目标
• 哪个风险不能接受
• 哪个结果只是表面通过
• 哪个地方需要回到事实源核对
• 哪些内容可以继续交给 AI 展开
• 哪些内容必须停下来人工确认

说到底，用好 AI 的关键不是把判断权让出去，而是用 AI 放大自己的判断力。

当你能识别它哪里错、为什么错、错了之后该怎么调整，它才是协作者。

如果你看不出它的错误，也做不了关键决策，那它就很容易从生产力工具变成噪音放大器。

六、优先把验证做成程序，而不是靠人反复看

如果一个问题能被程序稳定校验，就尽量不要反复依赖人肉检查。

例如：

• 用测试校验功能行为
• 用类型系统校验契约
• 用 lint 或脚本校验结构规则
• 用 examples 校验对外用法
• 用快照或固定输入输出校验格式类结果

这是 AI 应用里非常关键的一点：

凡是传统程序能稳定做的，尽量交给传统程序。

因为 AI 擅长的是：

• 补充候选
• 做启发式推进
• 在不完整信息里给出方向

而程序更适合：

• 做确定性检查
• 做一致性验证
• 做批量回归
• 做可重复执行的质检

把这两者分工清楚，AI 才会真正变成增益，而不是噪音来源。

七、真正实用的 AI 应用技巧，通常长这样

如果让我把“AI 应用技巧”压缩成一组更可执行的原则，我会更推荐下面这些：

1. 先补上下文，再提要求。
2. 先讲边界和禁区，再讲目标。
3. 参数或接口不确定时，不要猜，先查官方文档。
4. 修 bug 先补测试复现，再改实现。
5. 能程序化校验的，就不要只靠人眼复核。
6. 人要能看出 AI 的错误，并在关键节点做决策。
7. 把 AI 当高效协作者，不要当自动正确机器。

这些原则听起来并不“炫技”，但它们往往比更复杂的 prompt 技巧有效得多。

八、最后的判断标准

一个 AI 工作流到底好不好，不是看它一次生成了多少内容，而是看它是否具备下面这些特征：

• 不依赖大量猜测
• 关键约束清楚
• 错误能被快速定位
• 行为能被测试验证
• 回归能被程序发现
• 人能看出 AI 输出里的偏差
• 人能在关键节点做最终判断

如果这些条件成立，AI 才真正开始成为生产力。

否则，它更像一个会高速输出的随机放大器。你输入的边界越模糊，它放大的噪音就越多。