vibecode-pro-max-kit：给 AI 编码代理套上 RIPER-5 阶段流程与 /goal 自动驾驶
Your AI forgets. This remembers. Spec-driven coding harness for vibecoders, product owners, CEOs and real builders — self-improving context memory, 15 agents, 33 skills working with /goal, agent-team, & workflow on autopilot loops with 0 need for human gate. Kills context rot, ships features, not spaghetti. Claude Code & Codex. Any stack
秒懂
- 它是什么？
- 它把「先研究、再写规格、最后才动代码」的七阶段流程、PVL/EVL 自愈循环和可恢复的进度笔记固化成一个可安装的 kit，目标是压住长会话里的上下文漂移。代价是流程本身的仪式感，以及你必须在安装前看清 install.sh 与 vc-update 的边界。
- 适合谁用？
- 适合已经在用 Claude Code 或 Codex 做多阶段功能开发、并且被上下文漂移反复咬过的人：先在一份可以丢弃的仓库里跑一遍安装命令，确认 .claude 之类目录里生成的文件清单，再检查 vc-update 是否按 v3.2.4 的说明把内容目录交还给它自己管理。不适合两类人：只想让代理补一个函数、不想背七阶段仪式的；以及无法接受安装脚本写文件、必须逐行审计每一次磁盘改动的团队。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 87 天前。
- 用什么语言写的？
- 主要是 JavaScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它想解决的不是「AI 不会写代码」，而是「AI 写着写着就忘了自己写到哪」
README 的开头一句话很直白：Your AI forgets. This remembers. 这不是营销修辞，而是对当前编码代理工作方式的准确描述。一次长会话里，代理会先读文件、再改文件、再跑测试，中间任何一次上下文压缩或会话重启都可能让它丢掉「我们为什么选这个方案」这类信息，然后开始重复劳动或者推翻自己刚做的决定。
vibecode-pro-max-kit 的定位是给这类代理加一层流程外壳。README 把它描述为 spec-driven coding harness，目标读者写得很宽：vibecoders、产品负责人、CEO 以及 real builders。这个读者范围本身就是一条信息：它假设使用者不一定愿意自己设计流程，所以流程被预先定死并打包。
它不改变模型能力，也不接管你的构建系统。它做的事情是把「先研究、写规格、再计划、再执行」的顺序固化下来，并且把每一步的进度写到磁盘。对单人开发者来说，这层外壳的价值取决于你是否真的被上下文丢失困扰过；如果没有，它带来的主要是额外步骤。
RIPER-5 的七个阶段与 PVL、EVL 两个自愈循环
README 给出的流程名字是 RIPER-5，包含七个带门禁的阶段：Research、Spec、Innovate、Plan、Validate、Execute、Update-Process。门禁的含义是代理不能从 Research 直接跳到 Execute，必须先产出规格和计划。这是这套 kit 最核心的机制，也是它区别于「一个 system prompt 让 AI 好好写代码」的地方。
两个循环负责自我修正。PVL 是 plan-check-fix，EVL 是 test-check-fix，README 说明它们各自最多迭代 10 轮。这里的「自愈」不是指代理能修复任意故障，而是指它会在计划或测试层面反复找缺口、补缺口、再检查，直到达到上限或者没有新问题。10 轮这个上限值得注意：它说明作者预期循环会终止，而不是无限打磨。
另有一个叫 vc-autoresearch 的可复用循环，README 说它可以指向 plans、tests、specs、docs 或 evals。换句话说，同一套「找缺口、修、重复」的机制被抽出来，不绑定在某个特定阶段上。这个抽象是否好用，取决于这些目标产物的格式是否统一，而 README 没有展开说明。
在写代码之前还有一个环节：feasibility probes，给出 VIABLE 或 NOT-VIABLE 的判定。这是一个二值结论，不是打分。它的用途是在方案还没落地时先排除明显走不通的路线，代价是代理需要先做一轮探索性工作。
/goal 与 autopilot：把「继续」这件事从人手里拿走
README 把 /goal 称为 run-until-done token，描述为「一段可复制粘贴的块」，让代理一个阶段接一个阶段地跑下去而不停下，并且能在新会话里恢复这次运行。autopilot 提供 quick、fast、full 三档，README 的说法是三档用来让「仪式感与风险匹配」，也就是小改动走轻流程，大改动走完整流程。
配套的还有 smart strategy picker，在进入每个阶段前权衡「一个代理、多个代理、还是协调好的团队」，并附带成本估算，选择最便宜且够用的方案。这里有一个隐含前提：多代理协作比单代理贵。这个前提在多数代理计费模型下成立，但 README 没有给出任何具体数字，所以成本估算的可信度只能靠实际运行来验证。
Smart model use 是另一条省钱策略：贵的模型只写代码，其余工作交给便宜模型。这条策略的合理性依赖于「规划、检查、写文档这些环节对模型能力的要求确实低于写代码」这个假设。对复杂重构来说，这个假设未必成立，因为架构判断往往比敲代码更吃模型能力。
进度笔记每阶段写盘，是 autopilot 能跨会话恢复的基础。README 说它「在内存重置后仍能接上」，这意味着恢复机制不依赖模型记忆，而依赖磁盘上的文件。这是个务实的做法，但也意味着这些文件成为流程状态的一部分，需要纳入版本控制或清理策略的考虑。
安装与升级：一条 curl 命令，以及 v3.2.4 修掉的那个数据丢失问题
README 说安装是一条 curl 命令，脚本会检测新用户与回访用户，并且「从不覆盖你的文件」。发布记录里能看出这句话经历过修正：v3.2.4 的标题是 install.sh data-loss fix (defer content dirs to vc-update)，也就是安装脚本曾经会碰内容目录，修复方式是把这部分职责推迟给 vc-update。v3.2.3 则让 vc-update 在版本号相同的安装上也运行 adaptive migration。
这两条放在一起读，能推出一个实际的使用约束：安装和升级是两条不同的路径，内容目录的归属权在 vc-update 那边。如果你手动改过 kit 生成的内容目录，升级时的迁移行为就值得先看清楚。
v3.2.5 的标题是 Windows install guidance，说明 Windows 上的安装此前存在需要专门写指引的摩擦。README 正文里没有给出 Windows 的具体命令，所以 Windows 用户应当先读该版本的发布说明，而不是照搬 Unix 的 curl 行。
README 提到的生命周期命令包括 install、setup、update、publish，各自「一条命令」。但正文里没有列出这些命令的完整参数或配置文件键名，仓库结构里可见的组件是 15 个 agents、33 个 skills、10 个 hooks 和 36 个 validators。README 把 validators 描述为机械正确性检查而非主观意见，用于守护 kit 自身的结构。这是一条自我约束机制：它检查的是 kit 有没有被改坏，不是你的业务代码对不对。
它的边界：什么时候这套流程是负担
最明显的不匹配是任务规模。改一个错别字、加一个日志行、修一处拼写错误的配置键，这些改动放进七阶段流程里，产出的规格文档和计划比代码本身长。README 承认这一点，所以给了 Quick Fix 和 Fast Mode 这样的轻量通道，但轻量通道的存在本身说明完整流程并不通用。
第二个边界是模型与代理的兼容性。README 声称支持 Claude Code、Codex、Cursor、Windsurf、Copilot 等，但流程依赖的机制（阶段门禁、可恢复的进度文件、技能自动发现）在不同代理里的实现深度不可能一致。README 没有按代理逐一说明差异，所以「支持」在这份材料里是一个未经细分的说法。
第三个边界是自动化程度本身。README 描述的是 autopilot 可以「无需人工门禁」地跑完全程。对探索性任务来说这有风险：如果 SPEC 阶段理解错了需求，后面六个阶段会沿着错误方向一致地推进，而且因为有自愈循环，错误可能被反复加固而不是被暴露。SPEC 被描述为「最便宜地发现误解的地方」，这句话反过来也说明，SPEC 写错时代价最高。
第四个边界是仓库成熟度信号。从发布记录看，v3.2.3 到 v3.2.5 集中在三天内发布，其中包含数据丢失修复和迁移行为调整。这说明项目迭代很快，也说明近期版本里出现过会影响用户文件的缺陷。
和 Spec Kit、BMAD 这类方案相比，差别在流程的强制程度
同类思路里，GitHub 的 Spec Kit 也走规格先行的路线，但它的重心在规格文档本身以及由规格生成任务清单，流程阶段相对少，对代理的约束偏软。vibecode-pro-max-kit 的重心在阶段门禁和循环次数上：七个阶段、PVL 与 EVL 各最多 10 轮、36 个 validators 检查 kit 自身结构。前者的产物是文档，后者的产物是流程状态。
BMAD-METHOD 走的是另一条路，用多个角色化的代理（分析师、产品经理、架构师、开发）模拟一个团队，通过角色切换来产生不同视角。vibecode-pro-max-kit 也有 15 个 agents，但 README 强调的是 smart strategy picker 按成本选择「一个还是多个」，也就是代理数量是成本决策，不是角色分工。
Cursor 自带的 rules 和 Claude Code 的 CLAUDE.md 是更轻的替代：它们只提供持久化的指令上下文，不提供阶段门禁、循环上限或跨会话恢复。如果你的问题只是「代理不知道项目约定」，规则文件就够了；如果问题是「代理跑到一半忘了为什么这么设计」，才需要 vibecode-pro-max-kit 这类带状态管理的方案。
值得说清楚的是，这套 kit 的差异化来自把流程状态写到磁盘并且允许恢复，而不是来自它支持多少个代理或技能。15 和 33 这两个数字本身不构成选择理由。
许可与维护成本：MIT 之下，你要维护的是被生成的文件
许可证是 MIT。这意味着你可以把它放进商业项目、修改、再分发，义务主要是保留版权与许可声明。这里不构成法律意见，具体条款以仓库里的 LICENSE 文件为准。
真正的维护成本不在许可证，而在安装后进入你仓库的那些文件。README 说安装脚本不覆盖你的文件，v3.2.4 又把内容目录的职责交给 vc-update，这两条合起来意味着：kit 生成的内容目录由 vc-update 管理，你手改它们就要承担升级时被迁移逻辑覆盖或调整的风险。使用前应当先确认哪些路径属于「内容目录」。
升级频率也需要纳入考量。三天内三个版本的节奏对上游是正常的快速迭代，对下游意味着如果你把 kit 的文件提交进版本控制，合并冲突和迁移噪音会成为日常。一个可行的做法是把 kit 生成的目录与业务代码在提交历史上分开，但 README 没有给出推荐做法，这一点需要你自己决定。
另外，36 个 validators 检查的是 kit 自身，不是你的项目。如果你的团队期待安装后得到一套代码质量门禁，那是对这套工具的误读：它守护的是流程结构不被改坏。
编辑结论
适合已经在用 Claude Code 或 Codex 做多阶段功能开发、并且被上下文漂移反复咬过的人：先在一份可以丢弃的仓库里跑一遍安装命令，确认 .claude 之类目录里生成的文件清单，再检查 vc-update 是否按 v3.2.4 的说明把内容目录交还给它自己管理。不适合两类人：只想让代理补一个函数、不想背七阶段仪式的；以及无法接受安装脚本写文件、必须逐行审计每一次磁盘改动的团队。上手前要验证三件事：你的代理版本是否被 kit 明确支持、autopilot 的 quick/fast/full 三档在你项目里各触发哪些阶段、以及 SPEC 阶段的产物是否真的被后续阶段回读。
社区笔记