这是 vibe coding 系列的第 3 篇（系列总览）。工具装好之后（见《安装篇》），决定效果的就是你怎么说。下面的引用全是我开发简单书房时的原话。
一、说目标和原因，不说怎么实现
我的想法是，1. 减少用户的操作，尽量不要在 NAS 上安装额外的服务，2. 利用现有的资源，所以现在 DDNS 可以了，使用绿联自己的设定，HTTPS 证书以及续签能不能做到我的项目中呢？
我不知道证书该怎么实现，但我知道自己在意什么：用户少折腾、别多装东西。Claude 据此对比了几种方案，最后定下来「简单书房只负责用证书提供 HTTPS，申请和续签交给专门的工具」。
- 书库中书本的缩略图中的按钮看着不得劲，「AI 已填充」能不能改成一个图标，比如绿色的点之类的，现在看上去太占地方。整个系统就是小巧但功能强悍，所以尽量让功能符合用户的习惯，界面设计现代简洁但是一目了然
后半句「整个系统就是小巧但功能强悍」比前半句更重要：它让 Claude 在之后无数个小决定上都有了方向。
我想在应用中，增加一个纯粹的 API 模式……如果有需要的用户，可以自己开发手机 App，NAS 端通过这个 API 提供 JSON 数据……这样的功能应该怎么实现好？
想法还不成熟时，直接问「应该怎么实现好」，让它先给方案。
二、报 bug：现象 + 期望，最好举个例子
发现一个 bug，通过桌面进入到阅读器上次阅读的位置之后，点左上角的返回不好使，这里不用定位到阅读器里边的位置，而是定位到上次读的书的书页就可以，比如上次读到西游记第二章，那么再开就进入到西游记那个书页就可以
不用懂原因，说清楚「我做了什么、看到了什么、想要什么」就够了。Claude 查出了根本原因（从桌面打开时浏览器没有「上一页」），改了入口，把「直接打开阅读器时返回无效」这个同根问题也一起修了，并在浏览器里实测了三种打开方式，当天就发了 1.3.1。
如我拷贝所示，现在 EPUB 中的图片都无法查看，能否图片也能正常显示？[粘贴了报错信息]
有报错就整段粘贴过去，比描述有用得多。
三、给参考：网址、截图、别人的意见
（我另一个项目的网址）看看这个网站的样式
[粘贴了一大段] 这个是浏览器插件给的修改意见，按照这个意见修改一下
显示目录的时候，把已经看过的目录，在样式上做区分
「简洁、大气、漂亮」这种形容词，每个人理解都不一样。我一开始说「帮我重新设计这个项目的样式，要求简洁，大气，漂亮」，来回改了好几轮；后来直接给一个喜欢的网站做参考，一次就对上了。
调细节时用「以某个东西为准」比用形容词准：
还是高，再低些，看看常见问题那个卡片，以那个卡片的高度为准
四、做决定：短句就够
Claude 遇到需要你拍板的地方会停下来问，通常会给出几个选项和推荐。回答可以很短：
对，关闭时不提供 HTTPS
两种都做
分两期，先做第一期
最好是跟着管理员设置的网站名走
结构没问题，写设计文档吧
五、控制节奏：一句话决定它走多远
审查完修好再合并
先单独审一遍开关，再合并
发版，版本号 1.3.0
推送好了，查一下 CI
这些话决定了 Claude 做到哪一步停下来等你。推送代码、打标签、部署这类对外的操作，我都习惯自己确认后再做。
几条经验
- 一次说一件事。大功能拆开做，比如 PWA 我说的是「分两期，先做第一期」。
- 边界尽早说。「这个学习版不合并回 main，作为衍生版本管理」这种话影响整个结构，越早说越省事。
- 不确定就问。「这个 ARM64 版本是否需要在官网中说明？」「PWA 做好了怎么发布呢？」它会讲清楚利弊。
- 卡住了直接说。「刚才网络有点问题，解决了，继续」「还没完事么？不行换个源呢？」
- 验收要具体。「验收通过，页面还有些调整，系统菜单下方的用户部分样式调整一下」——通过的部分和要改的部分分开说。
Claude 怎么干活：一个功能的完整流程
装了 superpowers 之后，做一个新功能大致是这样的。以「装到手机桌面（PWA）」为例：
1. 头脑风暴（brainstorming）：Claude 一次只问一个问题。比如「打开后进入哪里？」我答「进入上次阅读的那本书」；「断网时要做到什么程度？」我答「提示没网就行」，又反问「能实现离线阅读么？」它解释了离线阅读的工作量，我决定「分两期，先做第一期」。每弄清一部分，它都会复述给我确认。
2. 写设计文档：把讨论结果写成设计说明，放在 docs/superpowers/specs/。写完还会派一个「审稿人」从实现者的角度挑问题，把只有我能回答的问题一次性拿来问我。我看过同意才往下走。这一步之前不写任何代码。
3. 拆实施计划（writing-plans）：把设计拆成一个个小任务，每个任务写明改哪些文件、测试怎么写、怎样算通过。计划放在 docs/superpowers/plans/。
4. 按计划实现（executing-plans + test-driven-development）：每个任务都是先写测试、确认它失败，再写代码让它通过。失败这一步很重要：能证明测试真的在检查这个功能，而不是怎么写都能过。
5. 整体审查（requesting-code-review）：全部做完后，另开一个「审查员」用最强的模型把所有改动从头看一遍。和 PWA 一起做的 HTTPS 功能，就审出了「证书文件写入失败时整个服务会崩溃」「强度太弱的密钥被当成可用」等问题。每个修复同样先写一个能复现问题的测试，确认测试失败后再修。
6. 收尾（finishing-a-development-branch）：跑完整测试，问我合并、提 PR 还是先留着。我说「审查完修好再合并」，它就合并到 main，再合并进学习版分支。
7. 发版：我说「发版，版本号 1.3.0」，它写更新日志、改版本号、打标签；我推送后，GitHub Actions 自动构建镜像。
遇到 bug 走另一条路：systematic-debugging，先复现、找到根本原因，再写一个失败的测试，最后修复。宣布完成前还有 verification-before-completion：没有测试结果或运行证据，不许说「好了」。
这套流程看起来繁琐，但它解决了 AI 编程最常见的两个问题：没听懂就开干，以及改完说好了其实没好。
让它记住进度和教训
- 任务清单：大任务开工前，Claude 会把计划写进
tasks/todo.md，做一项勾一项。对话断了、换了新会话，说一句「继续」它就从清单接着做。 - 记忆：遇到值得记住的坑，它会自动记下来，比如「WSL 下 Chrome 截图有渲染伪影，不要据此改代码」「临时工作树用完要删，否则用户切不到 main」。你也可以直接说「记住这个」。
- 设计和计划文档：几个月后回头看「当时为什么这么做」，翻文档就知道。
下一篇《浏览器篇》讲怎么让 Claude 用浏览器帮你检查网页、写教程、截图和录视频。