一个人 + AI：246 commits 做出设计系统 CLI 的故事

一组数字

246 commits
22 天（5/7 → 5/29）
1 人（我）
产出：设计系统 CLI 工具 + 31 组件协议 + 21 Section 协议 + 3 套设计系统实例 + E2E 测试套件 + Gallery 展厅 + 完整文档

如果有人告诉我两个月前这些东西可以一个人在三周内做出来，我会觉得他在吹牛。

但事实就是这样。这是一个关于"AI 时代，一个人能产出多少东西"的真实实验。

Day 1-3：从移植到独立（5/7-5/9, 57 commits）

起点

项目最初不是从零开始的------它从另一个产品项目（一个感知平台）的设计系统中"毕业"。那个项目里我做了初版的 Section 协议和组件系统，发现协议驱动的思路有独立价值。

于是 5/7 做了一个决定：把设计系统独立成一个完整项目。

当天的 commit 记录：

makefile 复制代码

feat: bootstrap from foresight design-system
feat: SectionHeader canonical implementation (16/16 compliance)
feat: Page Protocol design
feat(E2): Page Validator --- 26/26 checks passing
feat: Gallery shows all 5 sections

第一天就做了 4 件大事：独立仓库 + Section 实现 + Page 协议 + Validator。AI 在这里的角色是"快速脚手架生成器"------我定义协议规范，AI 帮我把规范翻译成代码。

Day 2-3 爆发（39 commits / 天）

到 5/9，token 系统就位了：

基础 Token 体系（颜色/字号/间距/圆角）
双主题系统（dark + white-base）
7 个基础 UI 组件
设计语言页面（品牌 DNA 可视化）
C1 组件协议 + 注册表

timeline title 第一周 (5/7-5/13) 5/7 : 独立仓库 : Section 协议 + Gallery : Page Validator 26/26 5/8 : DevOverlay 标注系统 : Intent Protocol : RankingList 32/32 5/9 : Token 双系统 : C1 组件协议 : 设计语言页面 : 7 组件 canonical 5/10-11 : 组件扩展到 14 个 : L1 Language Schema : 多实例验证 5/12 : 39 commits 疯狂日 : 完整 Gallery 重构 5/13 : 稳定化 + 文档

Day 7-15：CLI 工具的诞生（5/13-5/21, ~100 commits）

为什么需要 CLI

到第 7 天，我有了：协议文件 + Schema + 组件 + Gallery。但每次新建一个设计系统实例，都要手动复制一堆文件、修改配置。

手动流程太重复了。 于是开始做 ds-cli。

设计哲学：

ds init --- 初始化一个设计系统项目
ds add component <name> --- 从协议注册表生成组件骨架
ds add direction <name> --- 生成设计方向配置
ds add scene <name> --- 生成场景配置
ds validate --- 验证所有协议文件的一致性
ds gallery --- 启动可视化展厅

每个命令背后都是协议驱动的------不是随便生成文件，而是从注册表读取协议定义，按协议约束生成合规的代码。

AI 在 CLI 开发中的角色

这是最有意思的部分------CLI 的开发本身就是 AI 协作的实验。

我的工作模式：

写一份命令的 spec（输入/输出/约束）
让 AI 生成初版实现
跑测试，修 bug
迭代到满意

AI 的优势：

生成模板代码极快（一个命令的骨架 5 分钟）
处理 AST 转换、文件生成等机械工作
写测试用例覆盖边界条件

AI 的局限：

不理解整体架构（需要我给 context）
经常生成"看起来对但细节错"的代码（需要审查）
不能自己决定设计取舍（需要我做决策）

结论：AI 把"实现速度"提高了 3-5 倍，但"设计决策"和"质量审查"仍然是人的工作。

Day 15-22：多实例验证 + E2E（5/21-5/29, ~90 commits）

三套组件库样本同时跑

为了验证协议的通用性，我做了三套组件库样本实例：

实例	风格	Token 体系	组件数
Horizon	深色科技感	Dark theme	31
NIO	品牌白底	White-base	31
Shadcn	社区风格	Gray neutral	31

这里的 Horizon、NIO、Shadcn 都是我拿来验证协议层抽象能力的组件库样本，不是三套彼此独立的"设计系统本体"。

同一套协议，三种视觉表现。 这证明了协议层的抽象是正确的------设计意图可以和具体视觉实现分离。

E2E 测试：9 条路径 × 68 步骤

最后一周做了完整的端到端测试：

csharp 复制代码

ds init → ds add component → ds add direction →
ds add scene → ds validate → ds gallery

每条路径都有自动化测试。最终统计：9 条测试路径，68 个断言步骤，全部通过。

graph TB subgraph "CLI 命令全景" INIT["ds init\n初始化项目"] ADD_C["ds add component\n添加组件"] ADD_D["ds add direction\n添加设计方向"] ADD_S["ds add scene\n添加场景"] VAL["ds validate\n验证一致性"] GAL["ds gallery\n启动展厅"] end INIT --> ADD_C INIT --> ADD_D ADD_D --> ADD_S ADD_C --> VAL ADD_S --> VAL VAL --> GAL style INIT fill:#1a1a2e,color:#fff style GAL fill:#0ea5e9,color:#fff

Commit 分布可视化

22 天的开发强度分布：

几个高峰日：

5/12 (39 commits)：Gallery 全面重构日
5/11 (29 commits)：组件协议爆发
5/25 (27 commits)：Exhibition 系统落地
5/27 (28 commits)：CLI 命令完善

中间有几个"0 commit 日"------那些是开会日或在做 spec 设计（思考不产出 commit）。

关键认知

1. 一个人 + AI ≈ 3 人小团队的产出

不是说 AI 替代了两个人------而是 AI 把机械性工作（脚手架生成、模板代码、测试用例、文档格式化）的时间压缩到了原来的 1/5。

人的时间释放给了创造性工作：架构设计、协议定义、取舍决策。

2. Spec-Driven 开发极其适合 AI 协作

因为 spec 文件是给 AI 的完美 context：

结构化（YAML/JSON）
明确（有 Schema 约束）
可验证（有 validate 命令）

你写 spec，AI 帮你实现 spec。 这比"你描述需求，AI 猜你想要什么"可靠 10 倍。

3. 但------没有 AI 替代不了的部分

AI 做得好的	AI 做不了的
按 spec 生成代码	设计 spec 本身
写测试覆盖	决定什么该测
重构代码结构	决定是否该重构
文档格式化	决定文档的信息架构
快速原型	判断原型是否解决了对的问题

4. 高密度 commit 需要纪律

22 天 246 commits = 平均 11 commits/天。这个密度需要：

严格的 commit 粒度------一个功能一个 commit，不混杂
每日明确目标------开始前知道今天要做什么
即时验证------做完一步立刻跑测试/validate

没有纪律，高密度 commit 就会变成一团混乱的 git history。

最终产物

22 天后手里有什么：

维度	数量
CLI 命令	6 个主命令 + 多个子命令
组件协议	31 个
Section 协议	21 个
组件库样本实例	3 套
E2E 测试路径	9 条 (68 步骤)
JSON Schema	Token + Component + Direction + Scene + Page
Gallery 页面	完整展厅（组件 + Section + Direction）
文档	5 份 evolution spec + README

这是一个人在不到一个月的时间里------用 AI 加速、用 Spec 约束、用 Validate 验证------产出的完整工具链。

这个实验证明了一件事：在 AI 时代，一个有清晰方法论的个人开发者，可以产出传统模式下小团队的成果。 关键不是"AI 多强"------而是你能不能给 AI 足够好的 spec 作为约束，让它的产出是可控的、可验证的。