实战：用 Vibe Coding 做一个最小 Agent

2026-08-16

前面三篇，我们已经做了几件准备工作。

第一篇先把 AI、LLM、Prompt、Agent、RAG、Tool、Memory 这些词听懂；第二篇讲 Vibe Coding 是怎么让不会完整写代码的人也能开始做项目；第三篇整理了动手前要准备的编辑器、GitHub、API Key、项目文件夹和运行环境。

现在可以开始做一个真正的小东西了。

这篇不追求做一个功能很多、界面很漂亮、可以部署上线的完整产品。目标只有一个：用 Vibe Coding 做出一个最小 Agent，让它能接收一个输入，调用模型生成结果，并把结果保存下来。

我们选的案例是：博客选题助手。

它很适合作为第一个实战项目，因为它足够贴近个人博客场景，也足够安全。它不需要登录，不需要数据库，不需要操作别人的账号，也不会删除文件或发送消息。就算第一版输出不好，也只是选题不够有用，风险很低。

先把“最小 Agent”说清楚

一听到 Agent，很多人会想到自动规划、调用一堆工具、自己上网搜索、自己写文件、自己部署项目。那些当然也可以是 Agent 的能力，但第一天不要从那里开始。

我们的最小 Agent 只做一件事：

输入一个写作方向 -> 生成几个博客选题 -> 按固定格式输出 -> 保存到文件

它看起来很小，但已经包含 Agent 项目的几块基本骨架：

有一个明确目标：帮你从写作方向整理出可写的选题；
有输入：你最近想写的主题、读者或限制；
有模型调用：让 LLM 根据要求生成结构化内容；
有工具动作：把结果写入本地文件；
有验收标准：输出是不是具体、可写、不重复，文件是否真的保存成功。

这就够了。

很多新手项目失败，不是因为第一版太小，而是因为第一版太大。你刚想做选题助手，AI 就顺手加上用户系统、历史记录、网页后台、部署脚本和复杂配置。看起来很专业，实际上你还没来得及确认核心输出有没有用，项目就已经变得不好掌控。

所以这次我们故意把范围压住：先做命令行版本，先让它在本地跑起来，先检查输出有没有价值。

这个助手应该做什么

在写代码之前，先写需求。

不要只对 coding agent 说：

帮我做一个博客选题 Agent。

这句话太空了。AI 不知道你要写什么类型的博客，不知道输出几条，不知道要不要保存，不知道第一版该做到什么程度。它会开始猜，而猜测是项目变乱的开始。

更好的需求说明可以这样写：

我想做一个最小版博客选题助手。

使用场景：
我准备写技术博客，但经常只有一个模糊方向，不知道具体从哪个角度切入。

用户输入：
一个写作方向，比如“AI 工具入门”“第一次做 Agent 项目”“如何用 AI 辅助写博客”。

程序输出：
5 个博客选题。每个选题包含：
1. 标题
2. 适合读者
3. 切入角度
4. 3 条大纲
5. 为什么这个题目值得写

第一版范围：
先做命令行版本。
用户在终端输入方向，程序把结果打印出来。
暂时不要做网页界面、数据库、登录、部署和复杂历史记录。

验收标准：
输入一个正常方向时，能输出 5 个结构清楚、角度不重复的选题。
输入为空时，给出友好提示。
README 里写清楚如何安装、运行和验收。

这段说明不复杂，但它已经把项目从“做一个 Agent”变成了“做一个可验收的小工具”。

Vibe Coding 里最重要的一步，往往就是把模糊愿望压缩成这种小任务。任务越清楚，AI 越容易推进；边界越清楚，你越容易验收。

让 coding agent 生成第一版

准备好需求之后，就可以让 coding agent 开始生成项目。

如果你不知道该用 Python 还是 Node.js，可以让它先推荐。但为了降低第一版门槛，这类命令行小工具通常可以先选 Python：文件少，运行方式直观，适合新手观察输入和输出。

你可以这样开工：

请根据上面的需求，帮我生成一个最小 Python 命令行项目。

要求：
1. 代码尽量少，结构清楚。
2. 从 .env 读取模型 API Key，不要把 key 写死在代码里。
3. 提供 .env.example。
4. 提供 README，说明如何安装依赖、运行项目和验收。
5. 第一版只做命令行输入和终端输出。
6. 不要添加网页界面、数据库、登录、部署脚本。

请先告诉我你准备创建哪些文件，再开始修改。

这段话里有两个细节很重要。

第一，让它先说会创建哪些文件。这样你能在动手前确认范围，不至于它一下子生成一堆你看不懂的东西。

第二，明确哪些不要做。对新手来说，“不要做什么”经常比“要做什么”更能保护项目。

一个合理的第一版文件结构可能长这样：

blog-topic-agent/
  README.md
  .gitignore
  .env.example
  requirements.txt
  outputs/
  src/
    main.py

不用迷信这个结构。重点是职责清楚：

README.md 告诉你怎么运行；
.env.example 告诉你需要哪些配置；
.gitignore 避免把真实 API Key 提交出去；
src/main.py 放主程序；
outputs/ 放生成的选题结果。

第一版越朴素越好。你现在要验证的是“选题助手这个想法能不能跑通”，不是验证目录结构有多漂亮。

第一次运行：不要只看 AI 说“完成了”

coding agent 生成代码后，最重要的动作不是继续让它加功能，而是运行。

你可以按 README 执行类似这样的步骤：

安装依赖 -> 配置 .env -> 运行命令 -> 输入一个写作方向 -> 查看输出

比如输入：

我想写给新手看的 AI Agent 入门文章

一个有用的输出应该不是泛泛地说“写 AI Agent 很重要”，而是给出可以直接判断的结构：

1. 标题：第一次做 Agent 项目，应该从哪里开始
   适合读者：想用 AI 做项目但还不会完整写代码的新手
   切入角度：先做一个低风险、可验收的小工具
   大纲：
   - 为什么不要一开始做复杂 Agent
   - 如何定义输入、输出和验收标准
   - 如何用 Vibe Coding 迭代第一版
   值得写的原因：它能降低读者的第一步心理门槛

你不需要第一眼就判断代码写得好不好。先判断几件更直观的事：

程序能不能跑起来；
输出是不是 5 个选题；
每个选题是不是都有标题、读者、角度、大纲和理由；
标题之间有没有明显重复；
内容是不是具体到能继续写文章；
输入为空时有没有提示，而不是直接报错。

如果这些都过了，第一版就已经成功了一半。

注意，“成功了一半”不是客套话。很多项目卡住，是因为人和 AI 一直在讨论架构，却从来没有得到一个可观察的结果。只要你能运行、能看到输出、能指出哪里不对，项目就进入了可以迭代的状态。

输出不好时，先改 prompt

第一次运行后，最常见的问题不是程序崩溃，而是输出不够好。

比如它可能会生成这样的标题：

AI Agent 入门
AI Agent 教程
AI Agent 实战
AI Agent 学习
AI Agent 总结

它们没有明显错误，但太像了，也不够具体。这个时候不要急着重构代码。对这种内容质量问题，优先让 coding agent 调整 prompt。

你可以这样反馈：

程序能运行，但输出太泛，5 个标题之间差异不明显。

我的输入是：
我想写给新手看的 AI Agent 入门文章

当前问题：
1. 标题都像教程标题，没有具体场景。
2. 适合读者写得太笼统。
3. 大纲里缺少可操作步骤。

请优先调整 prompt，不要重构项目结构。
目标是让每个选题都有不同切入角度，并且更适合个人博客写作。

这就是 Vibe Coding 的日常节奏：不是“AI 一次写完”，而是你观察结果，把问题描述清楚，再让它做最小修改。

如果你希望输出更稳定，可以继续把格式要求写细一点：

请把每个选题固定输出为 Markdown 格式：

## 标题

- 适合读者：
- 切入角度：
- 文章大纲：
  1. 
  2. 
  3. 
- 值得写的原因：
- 可能的开头：

要求：
5 个标题不能只是替换同义词。
至少包含一个偏概念解释、一个偏实战步骤、一个偏常见误区的角度。

这段要求的作用不是让 prompt 变得神秘，而是把你的验收标准写进任务说明里。AI 不需要猜“什么叫有用”，它会看到你定义的结构。

加一个简单保存功能

当终端输出已经基本可用后，再加一个很小的工具动作：把结果保存到文件。

这一步会让项目更像 Agent，而不只是一次聊天。因为它开始对本地环境产生可控的结果：生成一个 Markdown 文件，放到 outputs/ 目录里，方便你后面整理、复制或继续加工。

可以这样要求 coding agent：

现在请加一个最小保存功能。

要求：
1. 每次生成结果后，保存为 Markdown 文件。
2. 文件放在 outputs/ 目录。
3. 文件名包含当前时间，避免覆盖旧结果。
4. 终端里提示保存路径。
5. 如果 outputs/ 不存在，就自动创建。
6. 不要添加数据库或复杂历史记录。

这一步的验收也很简单：

运行一次程序；
输入一个方向；
终端能看到生成结果；
outputs/ 里出现一个新的 Markdown 文件；
文件内容和终端输出一致；
再运行一次不会覆盖上一份结果。

你会发现，项目开始有一点“工作流”的感觉了：输入、生成、保存、复用。它仍然很小，但已经不只是聊天窗口里的一段答案。

让 AI 帮你写验收清单

每完成一个小功能，都可以让 coding agent 帮你更新 README 里的验收清单。

比如：

请更新 README，加入一段“如何验收”。

验收清单包括：
1. 正常输入时能生成 5 个选题。
2. 每个选题包含标题、适合读者、切入角度、3 条大纲和理由。
3. 输入为空时给出提示。
4. 结果会保存到 outputs/ 目录。
5. 连续运行两次不会覆盖旧文件。

这一步看起来像写文档，其实是在帮你保护项目。

没有验收清单时，你只能凭感觉说“好像能用了”。有验收清单时，你能明确告诉 AI 哪一条没过。比如：

第 4 条没过。
程序打印了结果，但 outputs/ 目录里没有新文件。
我执行的命令是：python src/main.py
请先判断可能原因，再给最小修改方案。

这样的反馈非常有效。它把问题限定在一个可检查的范围里，AI 不需要乱猜，也不容易把无关部分改坏。

什么时候算完成第一版

这个最小 Agent 的第一版，不需要做到“智能得像真人编辑”。只要满足下面几条，就可以先停下来保存版本：

可以从命令行运行；
可以读取 API Key，而不是把 key 写死在代码里；
可以接收一个写作方向；
可以生成 5 个结构化选题；
输出角度不完全重复；
输入为空时有提示；
可以把结果保存成 Markdown 文件；
README 写清楚安装、运行和验收方式。

做到这里，你就已经完成了一个很小但完整的闭环。

它有输入，有模型，有输出，有文件保存，有验收。更重要的是，你经历了一次真实的 Vibe Coding 工作流：描述目标，让 AI 生成第一版，运行，观察，反馈，修改，再验收。

这比一开始做一个“全能写作 Agent”更有价值。因为你真的掌控了它。

不要急着加这些功能

第一版完成后，你很可能会想继续加东西：

做一个网页界面；
保存历史记录；
支持选择不同写作风格；
读取已有博客文章，避免重复选题；
一键生成完整文章；
自动发布到博客；
接入搜索或资料库。

这些方向都可以做，但不要在第一轮全做。

一个简单判断是：如果你还不能稳定解释当前项目每个文件的作用，就先别急着扩大范围。如果你还没有几组真实输入输出样例，也先别急着做界面。界面会让项目看起来更完整，但不会自动让核心能力更好。

下一步更稳的做法，是先收集 5 到 10 个真实输入，看看输出质量如何：

AI 工具入门
第一次做 Agent 项目
如何用 AI 辅助写博客
Vibe Coding 常见误区
新手如何准备 API Key

把这些输入跑一遍，保存结果，然后挑出你觉得不满意的地方。是标题太泛？大纲太空？角度重复？读者定位不清？这些反馈会比“加一个漂亮页面”更能推进项目。

这次实战真正练的是什么

表面上，我们做的是博客选题助手。

实际上，你练的是一套更通用的能力：

把一个想法缩小成最小版本；
写清楚输入、输出、限制和验收标准；
让 coding agent 先生成可运行版本；
通过真实输入观察结果；
区分是 prompt 问题、代码问题还是需求没说清楚；
让 AI 做最小修改；
把输出保存成可以复用的文件；
用 README 和验收清单稳住项目。

这些能力比某一段代码更重要。

因为下次你不一定还做博客选题助手。你可能想做学习计划助手、资料整理助手、会议纪要助手、简历修改助手。具体功能会变，但这套循环可以复用：

定义小目标 -> 生成最小版本 -> 运行观察 -> 反馈问题 -> 小步修改 -> 保存结果

这就是 Vibe Coding 最适合新手的地方。你不用等自己学完整套工程知识，才开始做项目；你可以先从一个小闭环开始，在每次运行和反馈里补上真正需要的知识。

结尾

第一个 Agent 不需要酷。它需要小、清楚、能跑、能验收。

博客选题助手只是一个入口。它让你第一次看到：一个模糊想法可以被拆成输入、输出、prompt、代码、文件和验收标准；coding agent 不只是陪你聊天，而是真的能帮你把一个小工具搭起来；你也不是旁观者，而是在用运行结果一点点校准它。

当这个最小版本跑通后，你就可以慢慢往前走：让它读取文件，记住偏好，整理历史选题，甚至做一个简单界面。

下一篇，我们会继续沿着这个小工具往前推进：让 Agent 更像一个项目，看看工具、记忆、文件读写、简单界面，以及 MCP 这类连接外部工具和资源的协议，分别应该放在什么位置。

本系列目录

这是「AI / Vibe Coding 新手系列」的第 4 篇，全系列共六篇：

延伸阅读（比本系列更偏工程化，建议跑通第一个 Agent 后再看）：从 Demo 到可交付：如何做一个 Agent 项目