这两年 AI 编程助手几乎把"让 AI 写代码"变成了一个大众话题。从 Cursor 的 Tab 补全，到 Claude Code 的 Agent 模式，再到更激进的 "Vibe Coding"------用自然语言描述一个想法，AI 帮你把它变成可运行的应用。
但当一个 Vibe Coding 项目从 "hello world" 长成真正的业务系统，困难才真正出现。
AI 会"胡言乱语"。它会在你没让它动的模块里改东西，会假设不存在的接口和数据结构，会把整个仓库搅得一团糟。这不是 prompt 不够精确，而是AI 缺乏明确的、可机器读取的全局约束------它只能从上下文中猜哪些是对的，而这个猜测一旦偏离业务边界，修复成本就会指数级增长。
CabloyJS 在 2026 年下半年的一系列关键迭代，正是针对这个痛点做出的系统性回答。它不再满足于做一个"帮人更快写 CRUD"的 TypeScript 全栈框架，而是开始主动重构自己，成为一套专门为 AI Vibe Coding 设计的 AI 规范驱动开发（AI-Spec-Driven Development，AI-SDD）框架。
这条演进路线可以串成三条清晰的主线。
第一条主线：把"让 AI 写代码"变成"让 AI 按规范交付"
大多数 AI 编程助手的工作模型是这样的：你给一段描述，AI 根据上下文生成一段代码。这个模型在局部任务上表现很好，但在跨模块、跨前后端的复杂系统里，AI 面临一个根本困境------它不知道自己的边界在哪里。
CabloyJS 的解法是一套内置的 Claude Code Skills，把开发流程严格拆成两个阶段：
阶段一：在仓库里建立"规范权威"
第一个 Skill cabloy-spec-generation 的任务不是写代码，而是在仓库内建立明确的规格文件，让 AI 和人类都能读取同一份真相。典型的产物是一套互相引用的 Spec 文件，包括产品需求、技术契约、交付计划、验收标准和架构决策记录。
关键不在于"有一堆文档"，而在于分域权威：每份文件负责一种事实，其他文件通过稳定的 ID 引用它。产品需求不直接指定表名，技术契约不重新定义业务规则，交付计划不修改上游的权威定义。AI 不需要猜"这个模块的边界在哪"------它去读仓库里已经写好的 Spec 就行。
阶段二：让 AI 在有界范围内执行增量
有了规范之后，第二个 Skill cabloy-spec-execution 才开始动代码。它不是"看看 prompt 然后随便改"，而是严格遵循一条执行链：
text
读取规范 → 确认边界 → 生成执行 dossier → 执行源码变更 → 运行验证 → 保存证据 → 更新进度每一步都有确认门。AI 不会自动扩大任务范围，不会跳过验证步骤，也不会在验证失败时假装"已经完成"。最终交付的不是一段代码，而是源码变更 + 可审计的 Evidence 记录 + 更新后的进度状态。
把这两个阶段串起来，CabloyJS 实际上做的是一件很朴素的事：不让 AI 从一个模糊的 prompt 直接跳到写代码，而是先通过 Spec 建立一个中间层，让 AI 在这个中间层里有明确的行为边界。
这和传统"Spec 驱动开发"的区别在于------传统做法里 Spec 是人写给人看的文档，而 CabloyJS 的 Spec 是写给 AI 也写给人看的机器可读权威。AI 不只是"参考" Spec，它的整个执行流程就是被 Spec 驱动的。
第二条主线：AI-SDD 的副作用------图表自动从 Spec 派生
当 AI 的每一步操作都被 Spec 约束、都在更新同一份进度文件时，一个自然的问题出现了：我们能不能直接从这些结构化数据里生成敏捷开发的可视化图表？
答案是可以的。CabloyJS 的 Spec 体系内置了一个小工具链，能从 WBS（Work Breakdown Structure）和 progress 文件里自动派生两张图表：
- 甘特图（Gantt）：展示交付阶段、任务顺序、依赖关系和当前状态
- 燃尽图（Burndown）：展示批准范围内的任务计数和剩余量
这些图表不是"手工画图"------它们是 Spec 数据的直接可视化。当 AI 执行完一个 WBS 任务、更新了 progress 文件后，重新跑一次生成脚本，图表就自动更新了。
这件事看起来像是一个"很酷的小功能"，但放在 AI-SDD 的语境里，它的意义完全不同。它意味着：AI 在写业务代码的同时，也在自动维护整个项目的研发进度可视化。
你用 AI 开发一个 CRM 系统，AI 不只是帮你写客户管理模块的 CRUD------它边写代码、边自动更新甘特图上的任务依赖关系、边在燃尽图上标记已完成的工作量。整个研发链路变成了一条完全连通的流水线，而不是"AI 写代码、人类手动更新 Trello/Jira"这样的分裂状态。
当然，这里需要保持一个清醒的预期：自动生成的图表是结构视图，不是日历排期或速度预测。它告诉你有哪些交付包、它们的大致先后关系、哪些已经被验证完成------但不会告诉你"下周三之前能不能上线"。这是有意的设计，因为只有在 AI 真正具备业务理解能力之后，它才应该承担日历排期的责任。在那之前，把图表定位在"结构和状态的实时快照"，是更务实的选择。
第三条主线：双引擎架构------为什么 Cabloy 的 Vona + Zova 天然适合 AI-SDD
CabloyJS 的底层是两个独立演进的引擎：后端 Vona 和前端 Zova 。它们不是"一个大项目里的前后端目录"，而是各自拥有自己的 IoC 容器、Bean 体系和 CLI，靠构建产物 和双向契约环咬合在一起。
这个架构在 AI-SDD 场景下有一个巨大的天然优势：后端真相和前端真相是分开的，不会出现 AI 同时瞎改两边的混乱。
后端真相：Vona 的 OpenAPI 契约
Vona 的 Controller、DTO 和 Zod Schema 通过装饰器元数据自动产出 OpenAPI 文档。这份 OpenAPI 是前端 SDK 生成的唯一真相源。改后端接口时，正确的顺序永远是：
text
改 Vona 的 DTO/Controller/Zod → 产出新的 OpenAPI → 重新生成 Zova 的 $api SDK 和 $apiSchema helperAI 不会在前端代码里"发明"一个后端接口，因为它知道------契约真相在 Vona 那边，前端只是消费方。
前端真相：Zova 的路由、组件和元数据
反过来，Zova 的路由、组件、图标和类型定义是前端真相。构建后，这些元数据会通过一条反向链喂回 Vona，让后端工具链拥有完美的 IDE 类型提示。正确顺序同样是强制的：
text
改 Zova 的路由/组件 → 构建 Zova（生成 rest 产物）→ 运行 deps:vona 同步给 Vona仓库本身在 git hooks 里挂了 contract-loop-gate，提交时自动检查这条链是否被破坏。这意味着"双向契约"不是一句文档口号------它是工程化护栏。
为什么这对 AI 重要
当 AI 知道后端真相在 Vona、前端真相在 Zova，而且两边的同步有明确的命令和护栏，它就不会同时在前后端随意添加字段、随意猜测接口名、随意复制粘贴 schema 定义。AI 只需要回答：
- 这个能力属于后端还是前端？
- 我需要改哪一侧的真相？
- 改完之后跑什么命令把变更同步给另一侧？
这三个问题的答案都是框架已经定义好的，不需要 AI 去猜。
一个新的版本划分：两条 MIT Baseline
2026 年的另一个重要变化是 CabloyJS 的开源版本正式划分为两条 V5+ 架构的 MIT baseline：
Cabloy Basic（基础参考版）
- UI 层：DaisyUI + Tailwind CSS 现代化轻量级前端
- 内置演示 ：完整的电商套件（
a-commerce），包含后台管理、Web 前台、购物车和支付流程 - 定位：学习全栈模式、做原型、或者需要一个轻量 UI 层的项目
- 许可证：MIT
Cabloy Start（全功能启动版）
- UI 层：Vuetify UI 组件库
- 内置演示：完备的系统管理、部门管理、菜单授权以及基于数据范围的 RBAC（Data-scope-based RBAC）
- 定位：需要企业级权限、菜单和部门体系的项目起点
- 许可证：MIT
这个划分本身就是 AI-SDD 理念的延伸------先选好适合自己业务起点的 baseline，再在这个边界内用 AI 做增量交付，而不是从一个空项目开始让 AI 从零猜起。
所以 CabloyJS 现在到底是什么？
总结一下 2026 年下半年的关键变化：
它不再只是一个帮你快速搭建前后端的 TypeScript 全栈框架。它是一套让 AI Vibe Coding 变得可追溯、有边界、可验证的工作系统：
- AI-SDD 双阶段工作流让 AI 在规范权威下工作，而不是在模糊 prompt 下猜测
- 自动化图表派生让 AI 的每一步进度都可视化，研发链路不再分裂
- 双引擎 + 契约环让前后端各有真相源，AI 不会同时瞎改两边
- 两条 MIT baseline 让你从适合自己业务的起点出发，而不是从零搭建
它的野心很明确：做 AI 时代最好用的全栈 Vibe Coding 框架------不是靠"把 prompt 工程再卷一层"，而是靠严格的类型机制、仓库内的规范权威、工程化的护栏，把原本不可控的"盲目让 AI 写代码"变成一条"规范驱动、有据可查、自动生成报表"的工业级流水线。
从一个小增量开始试试
如果你想亲身感受一下这套工作流，可以从公开脚手架开始：
bash
npm create cabloy
npm run dev
npm run dev:zova:admin
npm run dev:zova:web然后选一个边界清楚的业务需求，比如"给商品加一个分类筛选"，走一遍 cabloy-spec-generation → cabloy-spec-execution 的完整链路。你会发现，当 AI 不再需要猜边界、猜契约、猜完成标准时，它的行为质量会有一个非常明显的跃升。