Content · 效率工具开发

为什么制作VibeHub

从项目管理器到 AI 辅助开发的协作驾驶舱，记录 VibeHub 随个人需求与工作流演变的开发历程。分享工作流自动化、跨 Agent 任务交接与事件溯源的设计思考，也坦诚复盘 token 开销、工具稳定性和审查验收方面的不足。

主题 VibeHub全流程分享

创建 Sep 6, 2026 / 更新 Sep 6, 2026

浏览 — / 评论 — / 字数 2,833

VibeHub开发分享效率工具

前言（LLM从CV时代到有偿抽奖）

最早是23年接触ai的，那会大语言模型只能输出一些比较简单的编码内容，然后当时也没有agent之类的概念，像是聘请了一位躲在对话框后的知识面比较广泛的“人”。 那时还是以自己为核心，向他提出问题，他在对话框里回复给你；需要代码的修复解决方案，你cv给它，它再输出它改正后的代码你再cv回去。操作权还掌握在自己手上，不然它难道还能主动交互我电脑中的文件、信息不成？ 结果后来cursor出现了开创了一个新的时代，我们亲爱的AI大人就此从副驾的地方成功晋升到了主驾驶，而相对应人们同时也获得了一个伟大的发明——基于token计费的许愿老虎机！在开始前默默许一个愿，投上些许token，而我们的LLM便会不知疲倦地跑起来直至产出最终结果，但成果往往不尽人意，因为当时模型本身的能力还差点意思还有大部分人其实也难以将自己的需求表述与想象保证一致，所以自然抽中大奖的概率比较小。 于是后来就又有了更多的工程设计来提升整个抽中奖的概率，包括但不限于提示词工程、harness工程、skills、loop等，都主要是在模型能力不变的情况下尽可能地让需求、目标在有限的上下文窗口中表述明确，并确保抽中奖才会停下来。然后Vibe便是这个抽奖的过程，而Vibehub就是我交出的抽奖“工程”的答卷。 必须承认他确实挺好看的吧QwQ，除此之外其实工程设计简直就是一坨浆糊……是虚有其表的纸老虎呜呜呜！！！

VibeHub的发展历程

VibeHub项目的推进不仅包含我个人工作流的改进和变化，也反应我个人的需求的变化。我一般都是有了需求之后再在这个的基础上搞增量……

V0&1-在最开始，它只是一个项目管理器 因为接触并熟悉到了ai后我非常热衷于有了想法后直接一拍脑袋就做尝试，反正许愿呗！然后就不知不觉开了很多台老虎机，搞得一团乱麻，每次要找项目，然后又打开对应的claudecode配置之类的会很漫长，感觉很不直观，于是我就做了他！ 在v1时代他就是一个包含标签系统的比较美观的项目中台，可以通过自定义的形式方便快速地辨别各个项目，然后不同的项目也可以使用标签启动对应所需的开发服务器或者claudecode配置。 然后后来因为感觉api去转换协议好不方便，就自己稍微整理个本地的agent的融合网关的小功能（不过后来就烂尾了有些……） V2-不满足固定流程手动反复执行，于是开始设计自己的工作流与“驾驶舱” 因为随着LLM用的越来越多，也逐渐有了自己的思考，然后就形成了一套适合自己的工作流。大概就是分为【需求对齐】→【前置调查】→【计划撰写】→【按序实现】→【验收检验】，当这样比较固化的流程或者行为变得更多时，我已经不再满足于每次都我手动去输入、反复执行，于是就开始着手整理并实现我个人的工作流。主要的目的就是：

1. 自动生成对应所需的规则文件（AGENTS.md、Claude.md等），介绍我个人的开发偏好，阶段偏好
2. 能够更加工整地记录目前的开发状态（我和agent都可以方便地阅读）
3. handoff友好，随时随地，任何agent工具之间都可以随便handoff并且不会丢失任务进度，且不需要再繁琐地自己手动复述一遍当前状况 这就是后来的V2版本，但是因为自己的工程能力确实不足，后来几乎完全被AI拖着走更新了好一段时间，过分地采取保守型策略，过分严格规范agent（比如一定要实时更新状态文件、在xx状态一定要xx，任何的过程都要详细地记录）导致一个常规的200k左右的上下文中单纯我工作流程就占了近乎50%甚至更多，agent花费过多时间去应对一个过分严苛、不够弹性的流程内容导致整体的效率极其低下……

   V3-轻量化！加速！可视化！直观！ 此前的v2工作流的所有版本我因为也知道太过于大粪，所以都只是发的preview版本没公开。 后来我思来想去就做出了伟大的v3版本！让一切都走上正轨……？主要的优化就是将后端核心再完善了，并且接口更加明确，然后做出了对应的cli和mcp工具，并秉持该宽泛的内容要相信agent的智能给予足够多的自由度，该细致的流程记录内容就得用硬性的条件来确保agent能够正确完成的思路。 然后因为考虑到agent的智能程度越来越高，很多场景下vibe的也越来越多，在闭眼飙车的路上愈行愈远，总想要一些”心理慰藉”（因为这方面做的真的还是不够好，目前可能真的只剩下浪费的token+主观上的自我安慰了）所以就做了一个协作驾驶舱。 我希望在一个项目下能够明确地看出目前有哪些正在进行的任务（task），然后还能清晰地看出这些任务都完成到什么程度了。而且我希望agent做的这些决策、判断都能够以“事件流”的形式记录下来，这样在之后发现agent出现问题的时候我们也有办法去溯源。因为git虽然能够完成代码层面的溯源，但是却没办法完成需求、想法层面的溯源，比如我对agent的一次错误的需求传达导致了某些问题，也能够通过事件流快速定位，然后再利用git或者session记录做更加细致的确认。 左侧的点显示的就是验收门槛，验收门槛也就算是判断这个task的完成进度的重要指标，绿色代表通过，橘色代表阻塞。 实现计划不仅是给人看的进度情况，也是给ai看的。同时也是ai的执行的步骤参考 这个是一直做的不太好的结构架构功能，理论上我本来期望的是类似archify的那种效果的结构图

VibeHub目前存在的问题

VibeHub在我将近大半年的维护下仍然存在很多很多的问题，我本来还打算v3版本进行大规模的宣传，但是后来自己感觉用的都不那么舒服……流程的token占用还是高、mcp工具不稳定、工程设计不够严谨等都导致Vibehub还是像是一个脆弱的玩具一般，尽管确实已经迭代了好几次。
VibeHub的更新大概不会终止，除非AGI出现……？比起一个给其他人使用的产品，它其实更类似于我自己对于整个agent辅助开发流程的学习、还有软件工程、软件设计方面的个人的探究的产物，也希望未来它也会随着我的个人探究变得越来越完善或者更加稳固，能够作为infra满足更多人的工作流需求……但愿吧 至少目前该优化的点还有很多很多！！！比如……

• mcp工具依旧不够agent友好，容易耗费过多token
• 渐进性披露的设计做的不够好，导致agent的输入token过多，整体效率降低
• 审查和验收机制依旧过分依赖agent智能且目前默认为执行模型自审查，很多情况下无法真实确保验收 还有很多想要做的……（太贪心了XD） 能够更加放心脱手
• 单次交互，复杂需求自动拆分多任务 * 单task多阶段可匹配多session，并行推进提高效率 * 单task内多阶段的多session的上下文传递 * 项目级or Task级的重要上下文注入系统（比如相关成熟解决方案、对应的详细文档） 交互易用性提升
• 审查、验收的标准需要人工手动完成的应该单独划分出来，模型应该提前了解自己是否有能力获得相关证据……？（避免搞得好乱，总是出现各种阻塞，然后堆了可能有不少同类的tasks，而一切原语同一个task的阻塞点）
• 节点详细视图优化兼顾快速阅览与详细记录
• 活跃 task 视图与归档 task 视图切换按钮
• 事件流升级，兼顾快速阅览与详细记录并保持轻量 * 证据系统升级，显示风格兼顾快速阅览与详细记录 * agent与vibehub的交互流程更加具体、流程化，使得agent交互更加可控，防止出现先提交（比如提交证据、通过审查、提交事件流更新等）后遗忘的情况，比如没有实际做或者在做之前就交 * 更加方便易用的过程检索（涉及到的关键词之类的）* task基本结束可以展示当前task的整体walkthrogh，到时候归档也是展示这种（类似反重力那种） 审查效果更加好、精确
• 确保审查并不会出现自认为就好于是通过的情况 经济与审计
• 【开发】token效率测试脚本，提升整体token效率 * 【开发】科学的工作流评估测试集，判断当前工作流是否真的达到以下要求：经济、高自由度、流程可溯源……
• dag节点图session系统完善 * task下的session相关数据统计更加完善 多端同步与多人协作
• 多端同步session、vibehub tasks等信息 * 跨设备跨系统协作
• 云端模式，可以直接将任务全都上云，用特定的云端服务静默持续在跑 个人偏好及成长
• 个人的偏好设定 * 辅助个人成长，构建规划、架构、设计能力（以经历为教材，以实践为阶，随使用巩固能力、拓展边界）