我不写代码，但我把三个项目做出来了

先说清楚一件事：我不是”让 AI 写了个东西”，我是”让 AI 交付一个能用的东西”。

这两句话看起来差不多，差得很远。前者只要 AI 吐出代码就算完事；后者意味着你得能判断它做对了没有 —— 而判断标准不是代码写得好不好，是你点下去，它到底管不管用。

这个区别决定了整个流程。我把它拆成四步。

第一步：把「不要什么」说清楚

大多数人跟 AI 提需求，说的是”我要一个记账工具，能记收入支出，能按月汇总”。

这句话里没说的是：能不能删记录？能不能改？误操作了怎么退？数据存哪？换浏览器还在不在？要不要能导出？界面是给人看还是给财务看？

AI 会自己决定这些。决定得再好也是它猜的，不是你要的。所以我提需求的时候，花的时间在”不要什么”上比”要什么”上多。

比如记账那个，我第一句是：

每一行一句话加一个数字，能自动认出金额。同时要能看到谁欠谁的 AA 账，数据不许上传到任何服务器，导出只给 CSV 和图片两种，别的一律不要。

“数据不许上传”这一句，直接决定了后面所有技术选型 —— 因为没有后端，就没有数据泄露的可能，很多麻烦事自动消失。

需求里每加一句”不许怎样”，你能省的返工往往比加一句”要什么”更多。

第二步：让它先说方案，别急着写

大改动之前，我一律要求先出方案。

这一步大概就是十几行字，但它挡掉的问题比我想象的多。举个真实的：我说”给我做个任务看板”，AI 二话不说开始写。等我看到成品才发现，它默认了浏览器 tab 当数据源 —— 我关掉页面任务就没了。

如果我当时追一句”这数据打算存哪”，它大概率会先问我要不要持久化。我并没有要求它持久化，但一个任务看板不持久化是不能用的，这是常识。

方案这一步的作用，是让 AI 把它的假设摊开给我看。我不需要懂代码，我只需要判断这些假设对不对。

第三步：我自己点一遍

这一步没有捷径。AI 说做完了，那就是做完了，但我没点过就等于没做。

我的验收方式很土：按用户路径走一遍，每一步问自己”这里会不会烦”。

上面那个记账的，第一次点完我就发现三处不对：删一条记录要点两次确认（烦）、数字靠右对齐了但小数点没对齐（看着难受）、导出按钮藏在三层的菜单里（谁找得到）。

这三处都不是 AI 写错了，是它按”合理默认值”做的，而我对”合理”的定义跟它不一样。说清楚一次就够，第二轮改到位。

第四步：它变成能用的东西

改完这一轮，它才终于能用了。

记账那个现在是我自己在用的东西 —— 每次聚餐完花一分钟录进去，月底 AA 谁该给谁一目了然。这是我第一次完整走完”想法 → 验收 → 真的用起来”的流程。

而这个站，以及站里那些项目，都是这么来的。

不写代码，到底意味着什么

意味着我永远不知道它是怎么实现的。

我说不清那个记账工具的数据结构，也解释不了它为什么在处理超长文本时不会卡。别人问我”你这项目用了什么技术栈”，我只能打开 README 念给你听。

这确实有代价。但我发现一件事 —— 大部分人根本不在乎。他们只问”这东西能干什么、怎么用、在哪能打开”。

而我作为提需求的人，能把注意力全部放在”这东西好不好用”上。这在以前需要一整支团队才能做到的分工：产品、UI、开发、运维。现在一个人（或者说一个人 + 一堆 AI）就能覆盖掉。

这也是我觉得 Vibe Coding 值得玩的原因。它不是”不会写代码也能冒充程序员”，是它让你可以把全部精力放在”这东西到底该是什么样”上 —— 而这恰好是决定一个东西好不好用的唯一变量。

接下来

站里的项目大多是我这么折腾出来的。后面我会挑几个写写具体怎么做的 —— 比如 MiniTools 那十一个单文件工具是怎么做到断网也能用的，SplitLedger 的自动识别金额踩了哪些坑。

如果你也在这么玩，欢迎在关于我里说的渠道找我聊聊，我挺想知道别人是怎么卡住又怎么绕过去的。