写在前面：这是一篇个人 Agent 搭建 和 Vibe Coding 方法的合集。
过去一个多月，我在 X 上陆陆续续发了一整个系列，从「为什么自己搭」一路写到「双模型互审」，每一篇都是一个独立话题。后台不少朋友说想要一份能一次读完的版本，于是我把这些文章重新梳理、串成了一篇完整的指南，也算给这个系列做一个阶段性收尾。
如果你之前零零散散看过其中几篇，这里是完整版；如果你是第一次看到，这一篇就够。
过去 30 多天，我把自己的个人 Agent EvoPaw（GitHub: https://github.com/hxdflying/EvoPaw）从一个「能跑起来的毛坯房」一点点迭代成了每天都在用的工作系统。我日常七八成的重复劳动都被它接过去了。
这篇合集就是把这 30 多天整个过程拆开、掰碎、毫无保留分享出来。不讲框架、不讲架构图，只讲一个普通人怎么一步一步把自己的 Agent 长出来。
工具可以换，但真正懂你工作流、偏好和方法的系统，只有你自己能慢慢养出来。这是这套合集真正想说的事。
第一章：为什么我劝你自己搭 Agent，这是主权问题
每次我聊 EvoPaw，都会有人问同一句话：OpenClaw、Hermes Agent、Nanobot 已经做得这么好了，为什么还要自己搭？
我的答案就一句：因为用现成框架的那一刻，你就把进化的主动权交了出去。
用现成框架，你永远在追新框架、调 prompt、修兼容。框架升级你就得升级，框架不维护你就得重来。看起来你在用工具，实际是被工具牵着走。
而自己搭这件事，最大的好处其实不是「掌控感」这种空泛的词，它能落到几件非常具体的事情上。
第一件，是模块边界清晰。 想换哪一层就换哪一层——provider、编排、记忆、技能——上层代码基本不动。这种自由度，在现成框架里几乎是不可能的。
第二件，是可以「偷」设计。 读 Hermes 的 Curator 学技能自动演化，读 Nanobot 学依赖预检，读 Pi-mono 学多 provider 抽象。一旦你在自己的系统里跑过一遍，看别人的项目就不再是看「一个整体框架」，而是一堆可以拆下来、拼回去的零件。
第三件，是数据和理解的主权。 Agent 用久了，会慢慢长出对你的「理解」：你喜欢什么格式、你怎么拆任务、你最近在焦虑什么。这些不是文件，是长期互动里涌现出来的「二阶资产」。平台 Agent 很难完整迁移，你花一年喂养出来的默契，换平台可能一夜归零。
第四件，是门槛真的已经低到离谱。*2026 年，有了 Claude Code、Codex 这类 Vibe Coding 工具，你不需要是程序员。改一行 prompt、让 AI 帮你写一个 Skill、加一个记忆文件——一步步就能把这个系统变成只属于你自己的样子。
所以我的建议非常具体：先用现成工具跑两周，感受一下「有 AI 助手在线」是什么体验；然后带着挑剔去用它，把所有别扭的地方都记下来，从这些痛点开始动手。起点不是终点。
第二章：15 天从 0 到日常使用，我跑通的那套流程
如果你下定决心要自己搭，下面这套流程是我自己跑下来觉得最顺的一条路。
基座我推荐 Nanobot。 代码干净、轻量、飞书等通道内置好、多 provider 支持。在我试过的所有项目里，它是最省事的一个。
整套流程其实就五步。
第一步，挑一个轻量基座。判断标准很硬：代码行数最好低于 8000 行，agent loop 一眼就能看明白，能比较容易地接飞书或 Telegram。重不重要看你能不能改得动，能改得动才能长得久。
第二步，用 Claude Code 装好，把飞书顺手跑通。 飞书强烈走长连接模式，不用公网 IP、不用配 webhook，是体验最舒服的一条路。
第三步，建好脚手架文件。 CLAUDE.md 是你这个项目的说明书，docs/ 下面再放 spec.md、prompt_plan.md、todo.md。这些文件是跨会话的持久化记忆，比任何 prompt 技巧都强。
第四步，把模糊需求逼成清晰 spec。 这是整套流程里最关键的一步，单独在第三章展开讲。
第五步，每加一个功能必须配测试。 同样关键，在第四章展开。
跑完这五步，你会从「用别人的 Agent」变成「拥有自己的系统」，这两件事的差别比想象中要大得多。
进阶玩法有两个值得提一句。一个是从 Hermes、OpenClaw 这些项目里「偷」好设计——可以是思想级别的重写，模块级别的抄，甚至文件级别的复用。另一个是装上 Codex MCP，让两个模型互审，效果显著，在第七章我会专门讲。
第三章：Vibe Coding 的命门，是把模糊需求逼成清晰 spec
Vibe Coding 速度优势的前提，是 spec 必须清楚。spec 越糊，AI 跑得越快，你死得越惨。这是我交了无数学费之后才反应过来的事。
我现在自己跑一个新需求，基本是下面这五步，以「飞书群待办总结」为例。
第一步，先填一张表，逼自己说人话。 把痛点写出来、把期望写出来、把自己不知道的地方也老老实实写出来。这一步看起来废，但能拦住 80% 的「想到哪写到哪」。
第二步，开 Plan mode（Shift+Tab），让 Claude Code 反复追问你。 边界条件、错误处理、性能要求、跟现有功能有没有冲突——全问清楚。这一步是把脑子里模糊的东西具象化的过程，越被问越能想清楚。
第三步，输出 docs/spec.md。 用列表、用表格，写得像合同，不要散文。一份能让别人看着实现出来的 spec，才是合格的 spec。
第四步（可选但强烈推荐），让 Codex review 这份 spec。 它能挑出你和 Claude 都意识不到的盲区。
第五步，把 spec 拆成 prompt_plan.md 和 todo.md。 每一步控制在 2 到 5 分钟、可以独立验收。这样后面动手的时候节奏才稳。
懒人神器我也直接推荐了：obra/superpowers（https://github.com/obra/superpowers）。装上之后，你说「加个功能」它会自动触发 brainstorming skill，硬约束你先把 spec 出清楚再动手。新手装上能少踩 70% 的坑。
第四章：测试，是你敢换模型、敢做大重构的胆量
Vibe Coding 时代，测试不再是「防 bug」，而是真相通道。没有测试，你根本不知道 AI 改的这一版到底有没有破坏旧功能。
但要注意一件很反直觉的事：让 AI 给自己写测试，天然会作弊。测试和实现互为镜像，永远绿，看着安心，其实毫无防御能力。
正确的姿势是 TDD 简化版，五步走。
先让 AI 根据 spec 写测试，这时候测试是红的。然后你自己 review 这些测试——只测行为，不测实现细节，这一关一定要把好。接着让 AI 写实现，让测试变绿。再加 boundary case 和 adversarial case，故意给函数喂坏数据。最后让 Codex review 一遍这些测试。
superpowers 里有一个 test-driven-development skill 会强制你跑红 → 绿 → 重构的循环，还带一条「Iron Law」：写了实现但没先写测试，就删掉重写。 听起来狠，但坚持两周之后，你会发现真正的杠杆不是测试本身，而是「敢重构」的勇气。
第五章：Claude Code 和 Codex 的关键配置，改完立竿见影
下面这两套配置我自己跑了几个月，效果非常明显。花 5 到 10 分钟改完，工具会变得更聪明、更便宜、更可靠、也更安静。
Claude Code 8 个关键配置
粘贴进 ~/.zshrc 或 ~/.claude/settings.json：
1. 强制高思考强度（ANTHROPIC_THINKING_BUDGET）
2. 关掉自适应思考，防幻觉
3. 子代理切到便宜的 Haiku 模型，账单能砍到 1/5
4. 主模型默认 Sonnet，遇到硬骨头再切 Opus
5. 拉长单次输出上限
6. 开虚拟视口和 diff 渲染，不闪屏
7. 关所有遥测
8. 把 bash 超时放宽到 30 分钟以上
Codex 10 个 TOML 配置
放在 ~/.codex/config.toml：
默认强模型、reasoning effort 拉到 high；审批策略走 on-request，该问的时候问；沙盒走 workspace-write，默认断网；搜索走 cached；关掉 alternate screen、关掉 reasoning event 的实时显示、关掉长期历史落盘、关掉 analytics。
每一项单独看都不起眼，但叠在一起，使用体验是质变。
第六章：新手必装的 Superpowers 纪律系统
新手做 vibe coding 最大的敌人，不是 AI 不够聪明，而是缺少强制纪律。AI 速度够快，但人控制不住自己想「跳一步」。
装上 obra/superpowers，重点用下面五个 skill 就够了，全部自动触发：
- brainstorming —— 硬约束你出 spec 再动手
- writing-plans —— 把 spec 拆成 bite-sized task
- test-driven-development —— 强制红绿循环 + Iron Law
- systematic-debugging —— 没复现就不许 fix
- verification-before-completion —— 没真跑过验证命令就不许 claim 完成
第一周严格跟着跑，先把肌肉记忆养出来，再考虑魔改。剩下那 9 个 skill（worktree、parallel agents 之类）一个月以后再碰，不然容易心力分散。
第七章：双模型互审，破解自我盲区
Claude 和 Codex 的训练分布不一样，盲区不重合。让它们互相 review，是我目前找到的性价比最高的 QA 方式。
配置方法很简单：用 MCP 把 Codex 注册成 Claude Code 的工具（反过来也行），整个流程在一个会话里跑就行。
最值钱的四个互审场景是：
spec 互审，专门挑边界、歧义、隐含假设；测试互审，只看测试本身，揪出那些「装样子的测试」；debug 二审，让另一方在不看 fix 的前提下独立诊断根因；重要 diff 互审，专门盯破坏接口、吞错、和 spec 不一致这三类问题。
里面有两条铁律必须守住：
- 测试一定要让没写实现的那一方来写。
- Debug 一定要让对方在不看 fix 的前提下独立诊断。
只要这两条守住，互审就不会退化成两个模型互相点头。
结语：行动起来，做属于你自己的系统
整个系列说了这么多，其实就一句话：
用现成框架，你永远是用户。自己搭，你才有可能成为主人。
从今天开始，你可以做这四件具体的事：
1. Fork Nanobot 或类似的轻量项目
2. 装好 Claude Code或者Codex，改完那套配置
3. 装上 Superpowers
4. 挑一个你真实的痛点，按 spec 流程跑一遍
不需要一次做到完美。一天改一行 prompt、一周加一个 Skill、一个月重构一次底层，它就会一点一点地，变成只懂你的那个系统。
EvoPaw 就是这么长出来的。我希望这个合集能给你一点点启发，和动手的勇气。