"帮我做一个博客"——这六个字为什么行不通

你有没有试过在 Cursor 或者 Claude 里直接说"帮我做一个博客系统"？

我试过。第一次用 Cursor 做项目的时候，我确实就是这么说的。Cursor 倒是很听话，刷刷刷给我生成了一堆文件。打开一看——确实是一个博客。有文章列表页、文章详情页、还有一个简陋的后台编辑器。

但我想要的是什么？我想要的是一个像 Notion 风格的、支持 Markdown 的、可以按标签分类的、有深色模式的、移动端体验好的个人技术博客。

AI 生成的那个东西，和我脑子里想的，差了十万八千里。

问题出在哪？不是 AI 不够聪明，是你说的不够清楚。

你觉得你说了"博客"，AI 应该懂你要什么样的博客。但"博客"这个词在 AI 的理解里，可以是 WordPress 那样的传统博客，可以是 Medium 那样的阅读平台，可以是 Hexo 那样的静态站点，也可以是 Substack 那样的 Newsletter 工具。你不说清楚，AI 就只能猜一个最"通用"的版本给你——而这个通用版本几乎不可能是你想要的。

这就是 Vibe Coding 里最常见的失败模式之一：你的需求太模糊了，但你自己不觉得模糊。

"我以为我说清楚了"综合征

这种情况有个很贴切的名字，我管它叫"我以为我说清楚了"综合征。你脑子里有一个完整的画面——博客长什么样、有什么功能、给谁用、什么风格——但你嘴上只说了一个词："博客"。你觉得你传达了 100% 的信息，其实你只传达了 5%。

跟 AI 协作的时候，这个问题特别严重。因为 AI 不像你的同事，你的同事可能会追问"你要什么样的博客？给谁看的？"，但 AI 不会。AI 会直接开始做。它会用它觉得最合理的理解去执行你的指令，然后你一看结果，傻眼了——这不是我想要的。

更坑的是，你这时候也说不清到底哪不对。你只能说"不对不对，重新来"，或者"改一下，更好看点"。这种模糊的修改指令又会导致 AI 乱改，然后你再说"不对"，来回改几轮之后，代码已经乱成一团，你彻底失去了对项目的掌控。

我见过太多人是这么放弃一个项目的：不是做不出来，是改着改着自己也不知道要做什么了。

需求拆解：把模糊变清晰的方法

那怎么避免这种情况？答案是需求拆解——在跟 AI 说"帮我做"之前，先花十分钟把自己的想法拆清楚。

需求拆解不是什么高深的方法论，它就是一个从上到下的分层过程。我把它分成三层：

第一层：目标层——这个东西到底是给谁用的、解决什么问题

这是最高层级的问题，也是最容易被跳过的。很多人直接从"我要做一个博客"开始，从来没想过为什么要做这个博客、给谁看。

你至少要回答三个问题：

• 给谁用？ 是给自己记笔记，还是给面试官看，还是给公众读？
• 核心目的是什么？ 是展示技术能力，还是分享想法，还是建立个人品牌？
• 成功的标志是什么？ 是有人看了觉得"这人技术不错"，还是有人订阅了你的更新？

这三个问题的答案会直接决定你需要什么功能。比如，如果博客是给面试官看的，那最重要的就是"文章质量高、阅读体验好、能一眼看到你的技术栈"，评论功能就不重要了——面试官不会在你博客下面评论的。

第二层：功能层——具体需要哪些功能模块

目标定了之后，功能就好定了。继续用"给面试官看的技术博客"这个例子：

看到了吗？同样是"做一个博客"，当你明确了目标层（给面试官看的技术博客）之后，功能的取舍就变得非常清楚。你不再需要纠结"要不要做评论系统"这种问题，因为答案在目标层就已经确定了。

第三层：任务层——AI 可以一步步执行的具体指令

这一层是很多人最缺的。他们知道需要哪些功能，但不知道怎么把功能翻译成 AI 能执行的任务。

关键原则是：每个任务只做一件事，而且这件事有明确的输入和输出。

拿"文章列表页"这个功能来说，拆成任务就是：

1. 创建一个文章列表页面，展示所有文章的标题、日期、标签，按日期倒序排列
2. 每篇文章显示摘要（前 200 字），点击标题跳转到详情页
3. 顶部有标签过滤器，点击标签只显示该标签下的文章
4. 列表支持分页，每页 10 篇

每个任务都是具体的、可验证的。你让 AI 做完第一条，就能立刻看到结果：页面上有没有文章列表？排序对不对？有没有显示标题和日期？如果对了就继续做第二条，不对就当场调整。

这比一句"帮我做一个文章列表页"强太多了，因为那一句话里，你对 AI 隐藏了太多你自己脑子里的细节。

用户动作 vs 技术组件

插一句特别重要的东西。很多有编程基础的人在拆解任务的时候，会不自觉地用"技术组件"来描述任务。比如他们会说"搭一个 MongoDB 数据库"、"写一个 REST API"、"做一个 React Context"。

这些不是任务，这些是技术实现细节。任务应该用用户动作来描述：

为什么用户动作思维更好？因为当你用用户动作描述任务的时候，AI 有更大的自由度来选择最合适的技术方案。你说"搭一个 MongoDB"，AI 就只能用 MongoDB；你说"让文章能被保存"，AI 可能会选择更适合你场景的方案——比如对一个静态博客来说，直接用 Markdown 文件就行了，根本不需要数据库。

这个思维方式在 Vibe Coding 里特别重要，因为 AI 往往比你更知道什么技术方案最适合当前场景。你的工作是告诉它"要做什么"，而不是"怎么做"。