最近折腾 AI 编程的时候，我越来越觉得一件事情挺有意思：AI 越来越会写代码了，但我们好像也越来越容易返工了
以前不会用 AI 的时候，一个功能可能要写两三个小时。现在好了，打开 Claude Code，甩过去一句“帮我做一个用户登录”，它几分钟就能把页面、接口、数据库、鉴权逻辑一股脑整出来。看着进度条刷刷往前跑，那感觉确实挺爽
但真正麻烦的事情，往往从这里才刚刚开始
你仔细一看：“登录页面不是我要的这个样子。”“用户到底是用手机号还是邮箱登录？”“管理员和普通用户的权限呢？”“密码怎么存？”“登录失败要不要限制次数？”于是你开始让 AI 一遍遍修改。改着改着，你会发现一个很尴尬的问题：AI 从头到尾可能都没有真正写错什么，它只是把你没有说清楚的地方，替你做了决定
而这，可能才是 Vibe Coding 最大的坑
一、AI 写错代码，可能不是最贵的错误
很多人聊 AI 编程的时候，第一反应都是：“AI 写的代码不靠谱，所以我要仔细 Review”
这当然没错，但我觉得还有一种错误，比代码 Bug 更贵：方向错了
代码写错了，可能改几行就行；一个接口参数设计得不合理，改一下也不是什么大事。但如果架构选错了，可能需要重构一下午；如果产品需求本身就理解错了，那就更麻烦了，因为前面写的页面、接口、数据库和业务逻辑，可能全部都得推倒重来
所以 AI 编程真正应该解决的问题，不只是“怎么让 AI 写对代码”，还应该包括另外一个问题：
怎么防止 AI 在我们自己都没意识到的时候，替我们做了一堆决定？
我最近看到 grill-me 这个 Skill，觉得它有意思的地方就在这里
它没有教 AI 更多的编程技巧，也没有搞一堆复杂的配置。它干的事情反而特别简单：在 AI 开始写代码之前，先把你的需求审一遍
二、Vibe Coding 最大的问题，是你以为自己在提需求，其实只是在描述一个念头
我们平时给 AI 下任务，经常是这样的：
“帮我做一个自动整理热点的工具”
“帮我做一个知识库”
“给这个项目加一个登录功能”
“帮我做一个后台管理系统”
这些话能不能让 AI 开始干活？ 当然可以
但问题是，它们严格来说根本算不上完整需求，更像是一个“需求种子”
比如你说：
“我想做一个自动整理热点的工具”
这句话后面其实藏着一大堆问题：热点从哪里来？抓哪些平台？针对什么领域？一天运行几次？什么叫“热点”？按照热度排序，还是按照潜在选题价值排序？同一个热点连续出现怎么办？历史数据保存多久？需要人工确认吗？最后推送到哪里？如果某个平台抓取失败怎么办？
这些问题你不回答，AI 也不会停下来
它会怎么办？ 自己猜
而大模型最厉害、同时也最危险的地方就在这里：它特别擅长把这些没说清楚的地方自然地补上
所以你会产生一种错觉：
“哇，这 AI 真聪明，我只说一句，它什么都懂”
实际上，它可能只是替你做了二十个你根本没有意识到自己正在做的决定
三、真正危险的不是 AI 会猜，而是它猜得太自然
如果 AI 每次遇到模糊需求，都停下来告诉你：
“这里存在 27 个未确定的问题，请逐一回答”
我们反而会很警惕，但现实里的 AI Agent 往往不是这么工作的
你说“帮我做一个聊天系统”，它可能顺手就选了 React、Node.js、WebSocket、MySQL、JWT，然后开始创建用户表、消息表和接口
整个过程非常丝滑，但问题来了：这些决定是谁做的？
很多时候不是你，是 AI
更麻烦的是，等代码写到一半，你才发现技术路线或者业务逻辑不是自己想要的，这时候修改成本已经上来了
所以我现在越来越觉得，在复杂 AI 编程任务里，有一个原则特别重要：
AI 越能干，越应该让它晚一点开始写代码
不是让 AI 变慢，而是让它在真正动手之前，把那些影响后续工作的关键决定先确认下来
四、grill-me 有意思的地方：它不是帮你回答，而是逼你做决定
grill-me 这个名字其实挺形象
Grill 有盘问、拷问的意思，它的核心思路也非常直接：不要急着实现我的想法，先把我的想法审一遍
它的核心指令其实非常简单，主要就是三个意思
第一，把方案里的每一个决策都翻出来，一直问到双方真正理解一致。不是只问“你想做什么”，而是继续往下追问这个决定为什么这么做、还有没有其他选择，以及这个选择会影响后面的哪些事情
第二，一次只问一个问题。问完等你回答，再根据你的回答继续往下走，而不是一次甩给你十几个问题
第三，如果问题可以通过查看代码库自己找到答案，就不要来问你。比如项目现在用了什么 ORM、有没有现成的鉴权模块、某个接口现在是什么结构，这些东西 AI 自己查代码就能知道，没必要浪费你的时间
你会发现，这三句话其实没有教 AI “怎么写代码”，它改变的是 AI 和人的工作关系
平时是：人提需求 → AI 执行
用了 grill-me 之后更像是：
人提出想法 → AI 发现模糊点 → AI 提问 → 人做决定 → AI 继续追问 → 需求逐渐明确
也就是说，AI 不再只是一个“执行者”，而是先变成了一个需求审查员
五、为什么“一次只问一个”反而更聪明？
第一次看到“一次只问一个问题”这条规则，我其实也觉得有点多此一举
一次问五个、十个问题不是更快吗？
后来想想，还真不是
因为复杂需求里面的问题往往不是平行的，而是有上下游关系的
比如你准备做一个知识库系统：
你还没确定这个系统到底是给一个人用，还是给一个团队用，就开始讨论权限系统；权限系统都没确定，就开始讨论数据库表；数据库都没确定，又开始讨论 API
这样做的问题是：你很可能在回答一堆建立在错误前提上的问题
所以 grill-me 强调的其实不是“慢慢问”，而是按照决策之间的依赖关系来问
这就是它里面一个很重要的概念：Design Tree，也就是“设计树”
六、所谓设计树，其实就是一棵“决定的树”
你可以把一个软件项目想象成一棵树
最上面是几个非常大的决定，下面不断分叉出更多具体决定
比如你要做一个知识库：
知识库系统
│
├── 谁使用？
│ ├── 单用户
│ └── 多用户
│ └── 是否需要权限？
│
├── 数据从哪里来？
│ ├── PDF
│ ├── Word
│ ├── 网页
│ └── 数据库
│
├── 怎么检索？
│ ├── 关键词
│ ├── 向量
│ └── 混合检索
│
└── 怎么回答？
├── 普通 RAG
├── Agentic RAG
└── 多 Agent
真正关键的是：越靠近树根的决定，影响范围越大
如果你连“这个系统到底给谁用”都没想明白，就开始讨论 Embedding 模型用哪个，其实意义并不大
因为上面的决策一旦发生变化，下面很多东西都可能跟着变
这也是为什么很多项目会出现一种很熟悉的情况：
“当初只是想加个小功能，怎么最后整个系统都要改？”
因为你以为自己是在改一个叶子节点，实际上碰到了树根
所以需求澄清真正重要的，不是把所有细节一次性想完，而是先把那些会影响大量后续工作的上游决策确定下来
七、这也是为什么“一次只问一个”反而更快
假设 AI 一次问你：
要不要 Redis？
登录用 JWT 还是 Session？
数据库用 MySQL 还是 PostgreSQL？
要不要 RBAC？
要不要做缓存？
是否支持多租户？
看起来效率很高，但你很可能会回答到一半就懵了，因为很多问题的前提其实还没确定
更合理的方式是：
“这个系统是单用户还是多用户？”
你回答：
“多用户”
AI 再问：
“那不同用户之间需要权限隔离吗？”
你回答：
“需要”
AI 再问：
“那更接近角色权限，还是资源级权限？”
这样一路往下走，上游决定确定以后，下游问题的范围自然就缩小了
所以“一次只问一个”真正解决的不是阅读体验，而是决策依赖问题
八、我觉得 grill-me 最厉害的一点，其实不是“会问问题”
还有一个细节我特别喜欢：能自己查到的，它不问你
比如 AI 想知道：
“这个项目现在用什么数据库？”
这种问题根本不应该问人，自己翻代码就知道了
想知道：
“项目里有没有现成的登录模块？”
也应该自己查
想知道：
“现在这个接口返回的数据结构是什么？”
还是自己查
只有当问题涉及你的意图、偏好或者业务决策时，才真正需要问你
所以一个比较成熟的 AI 编程 Agent，应该把问题分成两类：
我觉得这其实是一个非常重要的 Agent 思维：
不要把“未知”全部甩给用户，能自己解决的，自己解决
只有真正需要人拍板的地方，才把问题交给人
九、实操一下：让 AI 审一个模糊的需求
比如我突然冒出一个想法：
“我想做一个每天自动给我整理 AI 热点的工具”
如果直接开始 Vibe Coding，可能很快就变成：
看起来 AI 写得特别快，但实际上一直在做一件事情：
一边实现，一边猜需求
如果先让 grill-me 介入，流程就会变成：
这时候你可能会发现一个反直觉的现象：前面看起来慢了，后面反而快了
因为真正费时间的东西已经被提前解决了
十、比如“每天整理 AI 热点”，里面到底藏了多少问题？
我们最开始可能只会说：
“每天帮我整理 AI 热点”
但 AI 真正开始追问以后，你可能才会发现，里面其实有很多东西需要自己做决定
比如第一层：
你到底关注什么？
是整个 AI 行业，还是 AI 编程、大模型、Agent、Claude Code 这些技术方向？
这个决定一旦确定，后面的信息源就不一样了
如果确定主要关注 AI 编程，那么下一步可能就会涉及：
哪些平台值得抓？
X、GitHub、Hacker News，还是国内平台？
再往下：
什么样的内容算“值得写”？
纯粹看热度，还是考虑技术价值、讨论度、时效性？
再往下：
同一个热点连续几天出现怎么办？
如果系统每天独立运行，却没有历史记忆，那么一个热点可能连续推三天
这个问题你在一开始可能根本想不到，但一旦真正运行起来，你才发现：
“怎么今天又给我推这个？”
这就是典型的隐藏决策，它不是代码 Bug，代码完全按照要求运行了
只是你当初根本没告诉 AI：
“同一个热点不能连续推荐”
所以 grill-me 真正有价值的地方，就是帮你在代码写出来之前，把这些“我以为不用说，其实必须说”的东西挖出来
十一、它和 Plan Mode 到底有什么区别？
看到这里，可能有人会问：
Claude Code 本身不是有 Plan Mode 吗？
让 AI 先分析项目、制定计划，再开始写代码，不也一样？
我觉得两者其实解决的是两个不同的问题，可以简单理解成：
grill-me** 解决“我们到底要做什么”**
Plan Mode 解决“既然知道要做什么，那应该怎么做”
还是拿刚才那个热点助手举例
grill-me 更关注：
什么叫热点？→ 针对什么领域？→ 哪些平台？→ 每天多少条？→ 如何去重？→ 如何筛选？→ 推送到哪里？→ 什么时候推？
最终得到的是一份明确的需求和决策
然后进入 Plan Mode：
技术架构 → 模块拆分 → 数据结构 → 接口设计 → 任务调度 → 异常处理 → 实施步骤
最终得到的是一份实现计划，所以我更愿意把它们理解成：
grill-me 是需求阶段的审讯官，Plan Mode 是设计阶段的架构师，Coding Agent 才是最后真正干活的人
十二、再往前一步，它其实和 Spec-Driven Development 是一条路
如果把这个流程再往前推一步，你会发现，它和现在越来越多人讨论的 Spec-Driven Development，其实是连在一起的
以前我们习惯的开发流程是：
想法 → 代码 → 发现问题 → 修改
AI 编程之后，这个流程甚至变得更加极端：
一句话想法 → AI 疯狂生成 → 几分钟得到 Demo → 发现方向不对→ 疯狂返工
而 Spec-Driven Development 想做的是把中间这些关键决策显式化：
想法 → 需求 → 规格 → 设计 → 任务 → 代码
那么 grill-me 做的事情，其实可以看成是这条链路最前面的一个环节：
模糊想法 → grill-me → 发现隐藏决策 → 明确需求 → Spec → Plan → Tasks → Implementation
所以我觉得，AI 编程发展到现在，真正值得关注的可能已经不只是 Prompt Engineering 了
我们还需要一种新的能力：
Decision Engineering，也就是决策工程
以前我们研究的是：
“怎么告诉 AI 写出我要的代码？”
现在更值得研究的问题可能是：
“怎么让 AI 帮我发现，我自己到底还有哪些东西没有决定？”
十三、Vibe Coding 并没有错，错的是所有事情都 Vibe
我其实并不反对 Vibe Coding，恰恰相反，我觉得它是 AI 编程最大的价值之一
一个小功能、一张页面、一个 Demo、一个简单脚本，如果每次都搞完整的需求分析、技术设计、任务拆分，那确实有点过度工程化。
这种场景就应该：
想法 → AI → 代码
快速试，快速改，快速验证，但问题在于，有些事情真的不适合这么干
比如一个需要改数据库结构的功能、一个新的 Agent 工作流、一个权限系统、一个长期运行的自动化任务、一次比较大的架构重构
这些事情有一个共同特点：
前面的决定会影响后面的很多东西
这种情况下，如果还坚持“想到哪写到哪”，很容易出现一种情况：
Demo 做出来了
功能也跑了
但你突然发现整个东西不是自己真正想要的
所以真正成熟的 AI 编程，不应该是：永远 Vibe，也不是：永远 Spec
而应该是：该 Vibe 的地方 Vibe，该严谨的地方严谨
十四、什么时候应该把 grill-me 叫出来？
其实不用记复杂的规则，我觉得只需要问自己一个问题：
如果这个决定错了，后面是不是要返工很多东西？
如果答案是“是”，那就值得先让 AI 盘一遍
比如：
-
做一个新系统
-
设计一个 Agent
-
搭建 RAG
-
增加权限体系
-
修改数据库结构
-
设计自动化工作流
-
做一个长期运行的定时任务
-
做比较大的重构
-
设计一个新的产品功能
这些事情都有一个共同特点：
它们背后都有一棵比较复杂的决策树
反过来，如果只是改个颜色、修一个错别字、调一下 CSS、修一个一眼就能看出来的 Bug，那就别折腾了
这种事情你把 grill-me 叫出来，AI 可能一本正经问你十几个问题，最后你会觉得：
“我到底是在写代码，还是在参加答辩？”
最后：别让 AI 猜得太勤快
以前我们觉得：
AI 编程效率 = AI 写代码有多快
但现在我觉得这个公式应该稍微改一下：
AI 编程效率 = 写代码的速度 × 一次做对的概率
如果 AI 每小时能写 1000 行代码，但这些代码大量建立在错误的需求理解上，那么它写得越快，你返工得也越快
反过来，如果在真正动手之前，先花二三十分钟把几个关键决策问清楚，后面的代码反而可能会写得更快
所以我现在越来越喜欢这样一种 AI 编程节奏：
第一步，先别让 AI 写
先让它问：
“你到底想要什么？”
第二步，再让 AI 想
“既然确定了需求，那应该怎么实现？”
第三步，最后才让 AI 干
“好，现在开始写代码”
这可能才是 Vibe Coding 之后，更值得掌握的一种能力：
不是让 AI 少写代码，而是让 AI 少猜东西
因为代码写错了，可以改；实现方式选错了，可以重构
但如果一开始方向就是错的，AI 写得越快，返工来得就越快
所以，下次你准备对 Claude Code 说：
“帮我做一个……”
不妨先别急着让它动手，先让它问你几个问题
说不定真正需要修的，不是代码，而是你脑子里那个还没想明白的需求
