我手里有个挺烦人的需求：这几年试过的 AI 工具太多，什么能干嘛，全靠脑子记，记到最后全混了。想着让 AI 帮我做个网页，把自己的工具清单整理出来，能搜能看就行。
结果同一句话，喂给两个 AI 方法论，走出来的路完全不一样。
一个问了我十来分钟，最后交给我一个搜索框加几张卡片。另一个闷头干了两个多小时，git 仓库建好了，测试写了 54 个，验证清单列了 16 项，几十个文件码得整整齐齐，端出来一个正经八百的网页应用。
我的需求，自始至终都只是"能搜能看"。
一个需求，两条路，差距大到离谱
先看第一个。它不干活，先盘问我：这网页是自己快速找着用，还是要公开分享给别人？工具都是干什么用的？你需不需要增删改，还是光看看就行？
问到第三个问题的时候我愣了一下——我连手动整理的需求都没有，就想要个搜索框，能搜到每个工具是干嘛的就行。
它没给我写多漂亮的代码，但它帮我发现了一件事：我根本不需要那么复杂的东西。五分钟收工，一张卡片页，完了。
再看第二个。它倒是也先问了问题，四五个，全是选项式的：数据从哪来？用什么方式呈现？怎么找工具？怎么判断好不好用？问完把需求写成一份正式设计文档，存进了项目目录。
然后它就进入了自己的流程：git init，自己写提交信息，把工作拆成十份，每一份先写失败测试再写实现。54 个单元测试，16 项人工验证清单，还调了子 agent 来驱动整个执行。
两个多小时之后，我拿到一个很复杂的网页，目录里几十个文件。我的需求，还是那个"能搜能看"。
差别到底在哪？是问了没问，还是问到什么程度
很多人看到这儿会总结成"一个工具好，一个工具差"。我不这么看。其实这两个工具都没有错，错在我一开始没说清自己要什么。关键在于，两个工具对"完成"的定义完全不一样：一个的标准是"你真正要的东西到手了"，另一个的标准是"一套规范的工程交付了"。
两个工具都问了问题，差别在于问完之后干嘛。第一个是把需求逼到最简单——它用一连串追问，帮你把"我以为我要的"和"我实际要的"之间的水分挤掉，最后你会发现，原来只要一个搜索框。
第二个是把需求做成项目——问完四个问题，用默认值把剩下的补全，然后按完整工程的标准去交付：有 git 历史，有测试，有验证清单，有文档。这套流程对一个正经项目是福利，对一个"能搜能看"的小需求，就是灾难。
"干大事是真行，干小事是真苦。"这句评论我记到现在。方法论越重，越要匹配需求的重量。拿大炮打蚊子，不是炮不好，是用错了地方。说到底，工具只是把你的判断放大——判断对了，轻量工具也够用；判断错了，工具越重，返工越贵。
这套逻辑我自己天天在跑，但也是踩坑踩出来的
看到这两个工具的对比，我第一反应是：这不就是我自己的日常吗。
我的工作流里有一条铁律：需求模糊的时候，先追问再动手。我有个专门的追问流程，用户丢给我一个模糊需求，我先用一连串问题把它逼清楚，确认完了才碰代码。跟 grill-me 一个思路——本质上都是同一件事：干活之前，先让人搞清楚自己到底要什么。
我还有一条纪律叫"只做计划不执行"：接到任务，先只读分析、写方案，不动手改任何东西，等拍板了才执行。当时定这条规矩，就是因为吃过亏——需求没说清就冲上去干，干一半发现方向错了，返工的钱全白花。
最小改动优先也是这么来的。能用现成的东西就绝不新建一套，能改一行就不动十行。不是懒，是每一次多余的动作都在给系统加复杂度，复杂度攒多了，改一个小东西都得走整个流程——Superpowers 那个"改变一个小东西也要跟着走一遍全过程"的毛病，就是这么来的。
判断需求简不简单，其实三个问题就够
那问题来了，你怎么知道手里的需求是"一个搜索框"还是"一套正式项目"？
我自己用三个问题过一遍，全过就是小需求，追问几句直接干：
第一，能不能一句话说清？说不清的，要么是需求本身糊涂，要么是你还没想明白，先追问，别急着让 AI 开干。
第二，做完之后会不会频繁变？一个自己用的小工具，今天加个字段明天换个样式，那就别上重型流程，轻一点，改起来才不心疼。
第三，有多少人依赖它？只有你自己用，出问题你自己兜着，简单方案就够了。一旦要给别人用，要对接别的系统，那才轮到测试、文档、验证清单上场。
这三个问题过完，再选工具：小需求，找那种招之即来挥之即去的，问清楚就收工，不落文件也不改流程；大项目，才上完整管线，让流程替你兜底。
我现在就是简单的需求用前者，复杂的项目用后者。下次再想甩需求给 AI，可以试试先问自己那三个问题，值得花这十秒钟。别再问"哪个 AI 更强"了，先问自己一句：这个需求，配得上那么重的工程吗？
配不上，就让它轻一点。干小事，别用大炮。
热门跟贴