CabloyJS 的 AI 轉型：從 TypeScript 全端框架邁向 AI 規格驅動開發

AI coding assistants have turned "having AI write code" into a mainstream conversation over the past two years. From Cursor's tab completion, to Claude Code's agent mode, to the more radical "Vibe Coding" — describing an idea in natural language and letting AI turn it into a running app.

But the real difficulty appears when a Vibe Coding project outgrows "hello world" and becomes an actual business system.

AI "hallucinates." It modifies modules you didn't ask it to touch, assumes interfaces and data structures that don't exist, and turns an entire repository into a mess. This is not about prompts being imprecise enough — it is a deeper problem: AI lacks explicit, machine-readable global constraints. It can only guess from context what the correct boundaries are, and once that guess drifts outside the business scope, the cost of repair grows exponentially.

The series of pivotal iterations CabloyJS made in the second half of 2026 is a systematic answer to exactly this pain point. No longer satisfied with being a TypeScript fullstack framework that helps developers scaffolding CRUD faster, CabloyJS has been proactively restructuring itself into an AI Spec-Driven Development (AI-SDD) framework purpose-built for AI Vibe Coding.

This evolution can be organized into three clear threads.

Thread One: Turn "having AI write code" into "having AI deliver against a specification"

Most AI coding assistants follow this model: give a description, AI generates a chunk of code based on context. This model works well for local tasks, but inside complex systems that span multiple modules and both frontend and backend, AI faces a fundamental dilemma — it does not know where its boundaries are.

CabloyJS's answer is a set of built-in Claude Code Skills that splits the development workflow into two strict phases.

Phase One: Establish "specification authority" inside the repository

The first Skill, cabloy-spec-generation, does not write code. Its job is to establish explicit specification files inside the repository so that both AI and humans read the same source of truth. A typical output is a set of mutually referencing Spec files covering product requirements, technical contracts, delivery plans, acceptance criteria, and architecture decision records.

The key is not merely "having a pile of documents on disk." It is separated authority: each file owns one kind of fact, and other files refer to it through stable IDs. Product requirements do not prescribe table names; technical contracts do not redefine business rules; delivery plans do not rewrite upstream authority. AI never has to guess "what is the boundary of this module?" — it goes and reads the Spec that is already there.

Phase Two: Let AI execute bounded increments

Only after the specification is in place does the second Skill, cabloy-spec-execution, start touching code. It does not "look at a prompt and change things randomly." It follows a strict execution chain:

Read specs → confirm boundaries → generate execution dossier → make source changes → run verification → save evidence → update progress

Every step has a confirmation gate. AI does not automatically expand the task scope, does not skip verification steps, and does not pretend "it's done" when verification fails. The final deliverable is not just a chunk of code — it is source changes plus an auditable Evidence record plus updated progress state.

Putting these two phases together, CabloyJS is doing something deliberately simple: it prevents AI from jumping straight from a vague prompt to writing code. Instead, it inserts a Spec-based middle layer that gives AI clear behavioral boundaries within that layer.

What distinguishes this from traditional "spec-driven development" is that in the traditional model, specs are documents written for humans. In CabloyJS, specs are machine-readable authority written for both AI and humans. AI does not merely "consult" the Spec — its entire execution flow is driven by it.

Thread Two: A side effect of AI-SDD — charts are automatically derived from Specs

When every AI operation is constrained by the Specs and updating the same progress file, a natural question emerges: can we directly derive agile visualization charts from this structured data?

The answer is yes. CabloyJS's Spec system ships with a small toolchain that automatically derives two charts from the WBS (Work Breakdown Structure) and progress files:

Gantt: shows delivery phases, task order, dependencies, and current status
Burndown: shows the approved scope task counts and remaining items

These charts are not hand-drawn pictures — they are direct visualizations of the Spec data. When AI finishes a WBS task and updates the progress file, running the generation script once more updates the charts automatically.

On the surface this looks like a "cool small feature," but in the AI-SDD context its significance is completely different. It means: while AI is writing business code, it is also automatically maintaining the agile progress visualization of the entire project.

You ask AI to build a CRM system. AI is not just helping you write the customer-management CRUD — it is simultaneously updating task dependencies on the Gantt chart and marking completed work items on the Burndown. The entire development pipeline becomes one continuous flow instead of the split state where "AI writes code, humans manually update Trello/Jira."

One sober expectation is worth keeping: auto-generated charts are structural views, not calendar schedules or velocity forecasts. They tell you what delivery packages exist, their approximate ordering, and which ones have been verified — but they will not tell you whether everything can ship by next Wednesday. That is intentional. AI should not be held responsible for calendar commitments until it truly has business understanding. Until then, treating the charts as "real-time snapshots of structure and state" is the more pragmatic choice.

Thread Three: Dual-Engine Architecture — why Cabloy's Vona + Zova is naturally suited for AI-SDD

The foundation of CabloyJS is two independently evolving engines: Vona for the backend and Zova for the frontend. They are not "a backend folder and a frontend folder inside one big project." Each has its own IoC containers, Bean systems, and CLI. They mesh together through build artifacts and a bidirectional contract loop.

This architecture gives CabloyJS a tremendous natural advantage in AI-SDD: backend truth and frontend truth are separate, so AI cannot randomly mess with both sides at once.

Backend truth: Vona's OpenAPI contract

Vona's Controllers, DTOs, and Zod schemas automatically produce an OpenAPI document through decorator metadata. That OpenAPI document is the single source of truth for frontend SDK generation. When changing a backend interface, the correct order is always:

Change Vona's DTO/Controller/Zod → emit new OpenAPI → regenerate Zova's $api SDK and $apiSchema helper

AI will not "invent" a backend interface on the frontend, because it knows the contract truth lives on the Vona side — the frontend is only a consumer.

Frontend truth: Zova's routes, components, and metadata

Conversely, Zova's routes, components, icons, and type definitions are the frontend truth. After building, this metadata flows back into Vona's tooling through a reverse chain, giving the backend tooling perfect IDE type hints. The correct order here is likewise enforced:

Change Zova's routes/components → build Zova (emit rest artifacts) → run deps:vona to sync into Vona

The repository itself wires a contract-loop-gate into git hooks, which automatically checks whether this chain has been broken at commit time. That means "bidirectional contract" is not a documentation slogan — it is an engineering guardrail.

Why this matters for AI

When AI knows that backend truth lives in Vona and frontend truth lives in Zova, and that syncing them has explicit commands and guardrails, it will not freely add fields on both sides, guess interface names, or copy-paste schema definitions. AI only needs to answer three questions:

Is this capability backend or frontend?
Which side's truth do I need to change?
Which command do I run to propagate the change to the other side?

All three answers are defined by the framework. AI does not have to guess.

A new edition split: two MIT baselines

Another important change in 2026 is that CabloyJS's open-source editions have been formally split into two V5+ architecture MIT baselines.

Cabloy Basic (reference edition)

UI layer: DaisyUI + Tailwind CSS, a modern lightweight frontend
Built-in demo: A complete e-commerce suite (a-commerce) including Admin back-office, Web storefront, shopping cart, and payment flows
Positioning: Learn the fullstack pattern, build prototypes, or start projects that need a lightweight UI layer
License: MIT

Cabloy Start (full-featured edition)

UI layer: Vuetify, a UI component library
Built-in demo: Complete system management, department management, menu authorization, and data-scope-based RBAC
Positioning: Starting point for projects that need enterprise-grade permissions, menus, and department structures
License: MIT

This split itself is an extension of the AI-SDD philosophy: choose a baseline that fits your business starting point first, then let AI deliver bounded increments within that boundary — instead of starting from an empty project and asking AI to guess everything from scratch.

So what is CabloyJS now?

Putting the 2026 changes together:

It is no longer just a TypeScript fullstack framework that helps you scaffolding frontend and backend faster. It is a working system that makes AI Vibe Coding traceable, bounded, and verifiable:

The AI-SDD two-phase workflow makes AI work under specification authority instead of guessing under vague prompts
Auto-derived charts visualize every step of AI progress, so the development pipeline is no longer split in two
The dual-engine plus contract loop architecture gives frontend and backend each their own source of truth, so AI will not mess with both sides simultaneously
Two MIT baselines let you start from the right point for your business instead of building everything from zero

Its ambition is clear: be the best fullstack Vibe Coding framework in the AI era — not by "layering prompt engineering on top," but by using strict typing, repository-internal specification authority, and engineering guardrails to turn the previously uncontrolled "blind AI code generation" into an industrial pipeline that is specification-driven, evidence-backed, and automatically reportable.

Start with a small increment

If you want to feel this workflow yourself, begin from the public scaffolding:

npm create cabloy
npm run dev
npm run dev:zova:admin
npm run dev:zova:web

Then pick a clearly bounded requirement — say, "add a category filter to products" — and run through the full cabloy-spec-generation → cabloy-spec-execution flow. You'll notice that when AI no longer has to guess boundaries, contracts, or the definition of done, its behavior quality jumps up visibly.