这篇文章系统梳理了我在“用嘴编程”过程中总结出来的一套可复用提示词原则，用来显著降低 AI 编程时的“抽卡概率”。核心结论很明确：多数失败并不是模型不行，而是需求表达存在歧义、颗粒度不一致，或者一次性塞了太多任务。通过消除歧义、明确实现细节、控制任务规模，以及在写代码前先对齐理解，可以把 AI 编程从“碰运气”变成“可控流程”。

不少人在用 AI 写代码时，都会有类似体验：

• 有时一次就写对
• 有时来回改十几轮
• 有时干脆整段代码都不能用

很多人把这个问题归因于“模型不稳定”，但从我自己的使用经验来看，更常见的原因在我们自己身上。

一句话总结：

抽卡，往往不是 AI 在乱来，而是我们的表达不够清晰。

---

第一原则：需求必须没有歧义

这是所有提示词技巧里，最重要的一条。

什么叫“没有歧义”

标准非常简单：

任何一个人看到这段需求描述，都只能得出同一种理解。

如果不同的人会理解出不同意思，那 AI 也一定会。

一个典型的歧义示例

比如这句话：

界面设计要高端大气上档次

这句话的问题在于：

• “高端”是什么
• “大气”怎么体现
• “上档次”有没有可衡量标准

不同的人，脑子里的画面完全不一样。

AI 也是一样。

歧义什么时候可以用

需要强调的是：

• 如果你是想让 AI 发挥创造力
• 想通过“抽卡”看不同方案

那这种模糊、歧义的描述是可以接受的，甚至是有价值的。

但如果你的目标是：

• 可复用代码
• 可上线功能
• 可控结果

那歧义描述一定会拉高失败概率。

---

第二原则：必须明确实现细节

AI 写代码，本质上不是“猜你想要什么”，而是“根据你给的上下文做实现”。

要具体到什么程度

至少要包含以下几类信息：

• 使用什么 API
• API 的官方文档链接或核心说明
• 示例请求和示例返回
• 你最终希望实现的功能行为

如果你只是说：

帮我接一个支付接口

那 AI 只能靠猜。

正确的做法

更有效的方式是：

• 明确指定 API
• 提供接口文档
• 给出示例代码
• 描述你期望的完整流程

如果是 UI 或交互逻辑：

• 可以直接给截图
• 或者明确描述页面结构和交互细节

你给的信息越具体，AI 需要“脑补”的部分就越少。

---

第三原则：一次不要做太多事情

这是另一个非常容易被忽略的问题。

AI 是有上下文限制的

不管模型多强，都存在几个现实限制：

• 上下文长度有限
• 你的描述本身可能有偏差
• 多任务叠加会放大理解误差

当你一次性让 AI 做太多事情时：

• 任何一个小理解错误
• 都可能导致整体代码不可用

更稳妥的做法

把任务拆小：

• 一次只解决一个明确问题
• 一次只写一块功能
• 一次只改一个模块

这样即使出错：

• 影响范围也有限
• 回滚和修复成本很低

---

第四原则：先和 AI 对齐“理解颗粒度”

这是一个非常实用，但很多人不用的小技巧。

写代码前先让 AI 复述需求

在正式让 AI 写代码之前，我通常会先做一件事：

让它用自己的话，再描述一遍它理解的需求。

比如：

• 让 AI 先总结需求
• 或列出它准备实现的功能点

为什么这一步很关键

通过这一步，你可以快速发现：

• AI 理解偏了
• 关键点被忽略
• 实现路径不符合你的预期

如果在“文字阶段”就发现问题：

• 改一句话就能修正
• 成本极低

如果直接让它写代码：

• 问题往往在几百行代码之后才暴露
• 修复成本会高很多

对齐之后再写代码

当你确认：

• AI 的理解
• 和你脑子里的需求

在同一个颗粒度层级上时，再让它动手写代码。

这一步，能显著降低抽卡概率。

---

核心结论

把上面的经验压缩成几句话，就是：

• 抽卡不是玄学，是沟通问题
• 消除歧义，比换模型更重要
• 实现细节不清楚，AI 一定会乱猜
• 一次做太多事，是失败的放大器
• 写代码前先对齐理解，是性价比最高的一步

当你把“用嘴编程”当成一套可控的工程流程，而不是“看运气的对话”， AI 才会真正成为稳定的生产力，而不是随机数生成器。

最后再说一句：最好是用Gemini3、Claude4模型