上个月我在 X 上刷到一条抱怨：一个做播客的朋友说，他每周要花两小时把节目里的某一段翻出来，因为音频不能搜。
这条抱怨我见过七八次，每次都以「要是能搜就好了」结尾。第十一天，我做的小工具上线了：上传音频，转写、切片、按关键词定位到具体秒数，按月订阅。
十一天里，写代码三天。剩下的时间花在：确认这个问题真的存在（一天）、做原型并杀掉三个更差的点子（两天）、修边界情况和部署（三天）、写文档和定价（两天）。
这就是我现在理解的 vibe coding：它不是「让 AI 写代码」，是一条从灵感走到收款的流水线。 代码只是中间一段，而且是现在最不难的一段。下面按我实际用的四段来说，工具都不贵，关键是每段交接的时候别丢东西。
一、灵感收集：不要收集点子，收集抱怨的原文
X（x.com）、Reddit（reddit.com）、YouTube（youtube.com），这三个站我每天都会刷，但刷法不一样。
- X：搜「I wish there was」「why is there no」「someone should build」。这类句式下面藏着真实的不满，而且回复区经常有人说「我也需要」。
- Reddit：去垂直社区的求助帖，关键词是「how do you guys deal with」。注意看最高赞的回复——那里通常写着他们现在用的笨办法，笨办法就是你的产品形态。
- YouTube：视频本身是教程，评论区才是痛点。一个教学视频下面有人说「第 14 分钟那步我每次都做错」，这句话比任何市场报告都具体。
判据我定得很死，三条全过才往下走：
- 同一个痛点，在三个不同来源出现过（不是同一个人反复说）。
- 已经有人用笨办法在解决，并且为它付过钱（Excel 模板、外包、买过竞品）。
- 解决它只需要我已有的能力，加上一到两个 API。
第三条是给自己的约束。凡是需要新增一门专业（比如做硬件、做医疗合规），一人公司都不该碰。
收集的产物不是一句「做个小工具」，是一张痛点卡：谁、在什么场景、现在怎么凑合、愿意付多少钱、原文链接在哪。我用 Notion（notion.so）建了一个表，字段就这五个。三个月攒了四十多张，后来真正动手的只有两张，但那张表让我看清了一件事：大部分痛点是「烦」，不是「疼」。烦的事人们会忍，疼的事人们会付钱。
二、原型：这一段的目的不是做出来，是杀点子
进开发之前，我用两个工具把点子过一遍，总时间控制在两天。
Google AI Studio — aistudio.google.com。它解决的是「这件事模型到底能不能做」以及「数据结构长什么样」。比如音频定位这件事，我要先验证：转写带不带时间戳、长音频会不会被截断、中文口语的识别率够不够。这些在 AI Studio 里贴一段真实音频、调一下参数，一小时就有答案，不用写一行产品代码。
它还有个好处：能直接看到 token 用量。我拿它估过成本，十分钟音频转写大约几分钱，定价才有依据。
Google Stitch — stitch.withgoogle.com。把文字描述或草图变成 UI 骨架，能导出到 Figma 或直接出前端代码。它出的是「能看的壳」，不是设计系统——颜色、间距、组件状态都得你自己收一遍。但对一人公司够了：你需要的是让别人看懂你要做什么，不是一套设计规范。
两天的产出是一页纸，不是设计稿：
1 | 问题：播客内容不可搜索，找片段平均花 2 小时/周 |
那两天我杀掉了三个点子：一个需要爬平台数据（合规风险）、一个需要实时协作（我维护不动）、一个用户愿意用但明确说不会付钱（做公益可以，做产品不行）。原型阶段最贵的错误不是做得丑，是直接开始写代码。 代码一开写，沉没成本就开始替你做判断。
三、开发与审查：Cursor 管局部，Claude Code 管跨文件
工具我分两类用，边界很清楚。
Cursor — cursor.com。看得见的局部改动：一个组件、一段样式、一个函数的逻辑。你在编辑器里，改完立刻看到效果，适合边看边调。
Claude Code — anthropic.com/claude-code。命令行里跑整件事：读整个仓库、改五个文件、写测试、跑迁移、看日志。适合「我知道该怎么做，但不想手动做二十遍」。
GitHub — github.com。分支、PR、CI、预览部署。它不是「代码托管」，是你唯一的回滚机制。AI 写代码的速度会让「改坏了怎么办」从一个小问题变成致命问题。
Copilot — github.com/features/copilot。补全最成熟，但在代理型任务上不如前两个。Trae（trae.ai）、通义灵码（lingma.aliyun.com）、CodeGeeX（codegeex.cn）适合中文环境、内网或成本敏感的项目，隐私条款自己读一遍。
分工的经验值是：改动跨三个文件以上，就从 Cursor 换到 Claude Code。 在编辑器里让模型改五个文件，你会得到五处风格不一致的补丁；在命令行里让它一次改完，再跑一遍测试和类型检查，结果稳定得多。
有些地方不能 vibe
这条线我划得很清楚。以下五类，AI 只能写草稿，人必须逐行读：
- 状态机与并发。定时任务、重试、去重，这类 bug 在测试里几乎不出现，在线上每天都出现。
- 支付与退款。金额、幂等、对账，错一次要赔钱。
- 权限与多租户。谁能看谁的数据，漏一个就是事故。
- 数据迁移。跑错一次，回滚脚本比原脚本更难写。
- 任何「错了要赔钱」的地方。这条是前面四条的概括。
反过来，表单、列表、样式、文档页、脚本、一次性数据清洗——这些让 AI 全写，我只验收。判据是失败的代价，不是代码的难度。
审查 AI 写的代码，重点和审人不一样
风格不用看了，AI 一定是一致的。我看四件事：
- 错误处理。它最常写的是
try/catch里什么都不做，或者把异常吞掉返回空数组。 - 边界条件。空输入、超长输入、重复提交。
- 新增依赖。为了一个函数引入一个包，是 AI 的常见习惯，也是供应链风险的入口。
- 有没有测试。不是覆盖率，是有没有一条测试会在逻辑改错时变红。
这套规则我写过一篇：四个人的团队，怎么做代码评审。一人公司没有「团队」，但流程可以照搬，因为你要防的是自己偷懒。
还有一件小事收益极高：把规则写进仓库。AGENTS.md 或 CLAUDE.md 里写清「不要用 moment.js」「错误统一走 AppError」「不要写 any」，模型每次会话都会读一遍，省掉重复解释。这件事我单独写过：把规则文件当团队规范用。
四、知识沉淀：三个月后能不能复现当时的决策
项目上线后最容易烂尾的是这一段。我的标准只有一个：三个月后，我能不能靠留下的东西复现当时的决策。
- Obsidian — obsidian.md。本地 Markdown、双链、文件永远是我的。用来写决策记录：为什么选 A 不选 B，什么条件下应该推翻。这类内容不适合放云端笔记，因为它要活十年。
- Notion — notion.so。项目台账：需求、发布清单、用户反馈、退款原因。它是「进行中的事」，项目结束可以归档。
- NotebookLM — notebooklm.google.com。把二十篇竞品页面、用户访谈、行业报告丢进去，问「他们共同的抱怨是什么」，回答带引用，能点回原文。
三者的分工是：Obsidian 存「我为什么这么想」，Notion 存「我正在做什么」，NotebookLM 存「别人说过什么」。混在一起用，最后哪个都用不起来。
关于 AI 协作还有个更根本的问题：模型本身不记得你的项目，它的连续性全靠你喂的上下文。这件事比工具选型重要得多，我之前写过一篇：Agent 上线难，难在模型之外。
十一天的账
| 阶段 | 天数 | 主要工具 |
|---|---|---|
| 验证需求 | 1 | X、Reddit、Notion |
| 原型（杀掉 3 个） | 2 | Google AI Studio、Stitch |
| 开发 | 3 | Cursor、Claude Code |
| 修边界、部署 | 3 | GitHub、Claude Code |
| 文档、定价、上线 | 2 | Claude、Gumroad |
订阅成本：Cursor 20 美元、Claude 20 美元，转写 API 按量约 3 美元，域名摊下来 1 美元，部署 0 到 6 美元。合计不到 50 美元。
真正的变化不是省钱，是反馈周期。以前「有个想法」到「能给别人看」要三周，现在三天。三周里我会改主意，三天里不会。这一点比任何模型能力提升都重要——它让「试一下」的成本低到可以随便试。
三个我踩过的坑
一、上下文丢了，它会自己编。 会话变长之后，早期定下的约束（比如「测试库只读」）会被压缩掉，模型继续往下写，看起来完全正常。对策很土：每完成一个能跑的状态就 commit 一次，长任务开新会话，把关键约束重新贴一遍。
二、幻觉 API。 它会很自信地调用一个不存在的参数。对策是让它先读类型定义或官方文档，再写代码，然后把 tsc 和 lint 当成事实校验——类型检查器不撒谎。
三、没有回滚。 第一天就要 git init，每个功能一个分支，部署到预览环境再合。AI 写代码越快，没有回滚的代价越大。
底线只有一句：AI 可以写全部代码，但你要能解释它每一处失败。
最后
vibe coding 的上限不是模型，是你的验收能力。你能验证多少，它就敢替你写多少；你验证不了的部分，它写得越多，你欠的债越多。
所以那四段流水线里，最该花时间的不是第三段。是第二段——把点子想清楚，把范围砍到最小；和第四段——把决策记下来，让下一次不用从零开始。代码这一段，反而是现在最便宜、最不该纠结的。
评论