工具装好了，取舍也懂了。接下来见真章的，是「怎么对 AI 请求」。同样是 Claude Code，下指令的方式不同，成果的质量能差上好几倍。这一章，我们围绕与 AI 打交道的两大风格——轻松地边对话边做的氛围编程，与先定好规格再让它精准实现的规格驱动开发，来掌握「会请求」的本领。这里，正是 AI 编程最要紧的门道。
口诀是「小而探索用 vibe，大而精准用 spec」
指令的质量，决定成果
做 AI 编程最先绊倒人的，往往不是「工具操作」，而是「请求方式」。AI 读不到你的脑子里。丢过去一句含糊的话，AI 就会自行揣测、把缺的部分补上，回给你一段看似能跑、却与意图错位的代码。反过来，若你能精准地说清做什么、为什么做、怎么做，它就会做得出奇地准。「指令的质量」直接变成「成果的质量」——这是贯穿本章的第一要义。而这种请求方式，大致有两种风格。
氛围编程 —— 边对话边做
氛围编程（vibe coding），是一种不预先敲定细节设计，而是和 AI 边对话边试错着做出来的风格。你粗略地说「我想要这种感觉的东西」，看它给出的成果，再「再来点这样」「这里改一下」地一轮轮对话，凭「感觉（vibe）」把它捏成形。轻便、探索性强，能一口气把点子落成实物，是它最大的魅力。
🎨 打个比方： 不画图纸，一边揉黏土一边找形状的感觉。「边做边想」，所以哪怕脑子里还没定型的点子，也能先动起手来验证。
把适用场景和要留神的陷阱并排看看。
- 小东西：一次性脚本、简单工具、单页应用。
- 试作·原型：想看到形状再判断时。用完即弃的实验。
- 学习·练手：碰碰新技术、找找手感时。
- 整体设计会漂移：每轮对话方针都在晃，容易失去一致性。
- 规模一大就崩：文件越多，AI 和人都越难把握全局。
- 内容变黑箱：能跑，但说不清为什么能跑的代码越堆越多。
💡 一句话概括： 氛围编程「快速试」时最强，但「养大、长期维护」时不合适。小、用完即弃、探索——把这三个词当标尺，就不容易翻车。
规格驱动开发 —— 先定好再精准地做
规格驱动开发（spec-driven development），是与氛围编程相反的风格。在动笔写代码之前，先把「做什么、怎么做」整理成规格文档，再把规格交给 AI 让它精准实现。不是走到哪算哪地随口对话，而是沿着达成共识的图纸驱动 AI。
做法很简单。先和 AI 商量着做出规格文档，把它（多半以文件形式）放进项目，再让它参照该规格推进实现。
把目的、功能、输入输出、约束写成文字。先让 AI 起草再改，会更快。
实现前自己把规格读一遍，堵住遗漏和矛盾。这里是质量的分水岭。
下达「按这份规格实现」。跑偏了就回到规格来纠正。
- 稍大的东西：跨多功能、多文件的开发。
- 看重质量：日后坏了会麻烦、要长期维护的东西。
- 团队或他人要读：规格成为共享的依据。
- 别一开始就求完美，规格也从小写起再养大。
- 规格你必须亲自读。全甩给 AI 的规格往往漏洞百出。
- 实现跑偏时别在对话里将就着补，先改规格再重来。
📐 为什么有效： AI 只看得到「眼下这段对话」。先放一份随时可回溯的基准——规格文档，即便对话拖长，方针也不会漂移，实现的遗漏和返工都会减少。说穿了不过是「先把图纸交给 AI 再让它做」，但效果奇佳。
如何取舍 —— 小而探索，还是大而精准
这不是谁更优秀的问题。按要做之物的「规模」和「目的」来选才是正解。把两种风格按几条轴对比一下。
| 规模 | 小 |
| 目的 | 试作·探索·学习 |
| 推进方式 | 对话中试错 |
| 速度 | 非常快 |
| 弱点 | 一大就崩 |
| 规模 | 中～大 |
| 目的 | 质量·维护·生产 |
| 推进方式 | 规格→实现 |
| 速度 | 起步较慢 |
| 弱点 | 做小玩意嫌重 |
✅ 实际会「来回切换」。 不必二选一固定。先用氛围编程快速试作，一旦有了「行得通」的手感，就落成规格转入正式实现——这套流程在实战中最强。小的探索用 vibe，养大的阶段用 spec。在同一个项目里，让风格切换起来吧。
好指令的 5 个诀窍
无论哪种风格，只要交给 AI 的指令（提示词）好，成果就会更好。把今天就能用的 5 个基本诀窍，用卡片记下来。想深入的看提示工程实战指南。
别说「弄得好看点」，而要具体说清做什么、怎么做。数值、条件、对象越明确，精度越高。
告诉它所用的语言、框架、相关文件、约束。背景知道得越多，AI 越精准。
别这个那个一次全丢。切小、一个个来，确认和修改都更省心。
先展示想要的形式（函数名、返回值、输出示例、格式）。把目标对齐就不易跑偏。
别指望一次到位。看着输出具体地说「这里这样改」反复打磨，反而更快。
光说不易体会，就把同一个请求，用「坏指令」和「好指令」并排比一比。
「做个登录功能。」
语言、存到哪、成功和失败时的行为都不明。AI 全靠揣测来填，回给你和你设想错位的代码。返工的根源。
「在这个 Laravel 项目里，加一个用邮箱和密码登录的功能。使用已有的 users 表。认证成功跳转到 /dashboard，失败则显示错误消息。密码沿用现有的哈希方式。先只给出 routes 和 Controller 的方案，实现等我确认后再做。」
目的、上下文、成功条件、输出范围、推进方式全都说清。5 个诀窍全包含在内。
🧩 再进一步： 不只是「对 AI 说什么」，而是设计整个项目里该把哪些信息、怎样送达的思路，叫上下文工程；把 AI 工作的环境（工具、权限、指令文件）整体搭建好的思路，叫框架工程（harness engineering）。想进阶时不妨看一看。
当 AI 无视规则时
Claude Code 有一套机制：把每个项目的指令整理进 CLAUDE.md 这样的文件，让 AI 始终遵守。可实际用起来，你会碰上「明明写了规则，AI 却无视」的场面。原因有好几种。
规则一多，重要的就被淹没。精简数量，明确优先级。
有解释空间就守不住。写成具体、可验证的样子。
来回一多，最初的指令就淡了。在要紧处再提醒一遍很有效。
💡 对策要点： 规则要「短、具体、带优先级」地写。重要的规则，在需要的场合于对话中再叮嘱一次。原因的细致排查和具体修法，见AI 无视 CLAUDE.md 规则的原因与对策。
- 指令的质量即成果的质量。AI 会用揣测填补缺口，请求得越精准，回得越准。
- 氛围编程＝边对话边试错。擅长小、用完即弃、探索。做大就崩。
- 规格驱动开发＝先定规格再精准实现。擅长中～大、看重质量。
- 取舍是「小而探索用 vibe，大而精准用 spec」。实际会来回切换。
- 好指令的诀窍有 5 个：具体化、给上下文、一次一个任务、输出示例、迭代。
- AI 无视规则，多因指令太长、含糊、对话太长。要短而具体，并加以叮嘱。
请求方式一旦掌握，AI 编程会一下子稳定下来。但只要真动手，就必定会撞上错误和卡壳。下一章第 5 章「脱困」，我们来系统地梳理常见错误的原因与脱身之道。