PrizmKit, 一套让 AI 写代码不再像开盲盒的框架

写在前面: Prizm AI 系列平台产品, 包括你正在阅读的 Prizm School, 均使用 PrizmKit 开发完成.

一、这是什么（What）

PrizmKit 是一套与平台无关的 Agent Skills 集合，用来把"一个正式软件需求"从一句话想法，按一套固定的、有纪律的流程，做到"本地提交之前"。

它解决的问题不是"让 AI 写代码"，而是：

在 AI 编码会话里，把"规划 / 实现 / 评审 / 测试 / 文档同步 / 提交"这些职责清楚地分开，又让它们彼此衔接、不丢上下文。

PrizmKit 本身不是某个特定 IDE 或平台的私有功能，而是一组平台中立的 SKILL.md 指令文件。你本机的 AI 编码工具（Claude Code、Cursor、Codex、Cline、Windsurf 等 70+ 种）装上它之后，就能用斜杠命令调用。

它一共包含 10 个 skill，分成三类：

• 导航层：prizmkit（告诉你该用哪个）
• 旁路入口：prizmkit-init（首次初始化）、prizmkit-prizm-docs（文档系统维护）、prizmkit-deploy（部署运维）
• 正式需求生命周期（6 阶段）：plan → implement → code-review → test → retrospective → committer
• 编排器：prizmkit-workflow（把上面 6 步串成"一句话搞定"）

二、有什么用（Why / 为什么要用）

AI 编码会话常常把规划、实现、评审、测试、文档、提交混在一起，导致：

• 还没想清楚就开写；
• 写完没评审就当完成；
• 测试被悄悄跳过；
• 文档和代码越走越远；
• 提交范围含糊，还被自动 push 到远端。

PrizmKit 用"职责分离 + 状态衔接"来解决这个问题：

一句话：它让 AI 帮你做完整需求，但把"何时提交、何时上线"的决定权始终留在你手里。

三、怎么用（How）

3.1 安装

PrizmKit 通过 Vercel Labs 的 vercel-labs/skills 工具（npx skills）安装。

# 基础安装（交互式选择要装的 skill + 自动检测本机 AI 工具）
npx skills add lone-yu-cmd/PrizmKit-OpenSource

安装后会发生什么：

1. CLI 扫描仓库里所有含 SKILL.md 的目录，自动发现全部 10 个 skill；
2. 自动检测你本机已安装的 AI 编码工具（检测不到会让你手动选）；
3. 列出技能，让你勾选要安装哪些（想完整跑生命周期就把 6 个生命周期 skill 都装上）。

3.2 起手：你基本只会在 3 种方式里选一种

① 全自动（最省事，推荐日常用）
   /prizmkit-workflow <需求>
        └─ 它自己跑完 plan→implement→review→test→retrospective→committer
           只在"提交前"停下来问你

② 手动分阶段（想每步都自己把关）
   /prizmkit-plan <需求>  →  你看完再  /prizmkit-implement  →  … 逐个手动推进

③ 只做单件事
   /prizmkit-init        (首次接项目)
   /prizmkit-deploy      (上线/运维)
   /prizmkit-prizm-docs  (修文档系统)
   小改错别字/纯格式       → 直接让 AI 改，别走流程

3.3 每个 skill 的"你什么时候用、给它什么、它给你什么"

导航层（不干活，只指路）

旁路入口（不在 6 阶段流水线里）

正式需求生命周期（6 阶段，固定顺序）

编排器（帮你把上面 6 步串起来）

四、调用 / 状态流转图（使用者视角）

                          ┌───────────────┐
      不确定用啥 ───────▶ │  /prizmkit    │  只指路，不干活
                          └───────────────┘

  首次接项目(可选) ─▶ /prizmkit-init ─▶ 生成 .prizmkit/prizm-docs/
                                                │
                                                ▼
  一句话需求 ─▶ /prizmkit-workflow ─▶ 自动编排下面这条链 ↓↓↓
  ────────────────────────────────────────────────────────────────
    ┌──────────┐  PLAN_READY  ┌────────────┐ IMPLEMENTED ┌──────────────┐
    │   plan   │─────────────▶│ implement  │────────────▶│ code-review  │
    │spec+plan │              │  写代码     │             │ 边审边修      │
    └──────────┘              └────────────┘             └──────┬───────┘
                                    ▲   ▲                        │
                                    │   │                 REVIEW_PASS│  NEEDS_FIXES
                                    │   │                        ▼   └──┐
                                    │   │                 ┌──────────┐  │
                                    │   │      TEST_PASS  │   test   │  │
                                    │   └─────────────────│ 出证据    │  │
                                    │  (测试基建问题)      └────┬─────┘  │
                                    │                          │        │
                                    │  TEST_FAIL(动了生产代码)  │        │
                                    └──────────────────────────┘        │
                                    ◀────────────────────────────────────┘
                                       回 implement 重修
                                            │
                                       TEST_PASS
                                            ▼
                                   ┌────────────────┐
                                   │ retrospective  │ 同步文档 / NO_DOC_CHANGE
                                   └───────┬────────┘
                                           ▼
                                   ┌────────────────┐
                                   │   committer    │  预览改动+提交信息
                                   └───────┬────────┘
                                           │
                                    ⏸ 等你确认 (关键人工卡点)
                                           ▼
                                       COMMITTED  ← 不自动 push
  ────────────────────────────────────────────────────────────────
                                           │
                          需要上线时另外单独调 ▼
                                   /prizmkit-deploy

五、使用者必须知道的 5 条规则

1. 提交一定要你点头：committer 会先给你看"改了哪些文件 + 提交信息"，你确认后才 commit，而且永远不自动 push。
2. 失败会智能回退，不是从头再来：
   • 评审没过 → 回 implement 重修，再评审；
   • 测试挂了且只是测试代码问题 → 回 implement → 直接再测；
   • 测试挂了且动了生产代码 → 回 implement → 要重新评审 → 再测。
3. 环境挡住了会暂停，不会瞎改：TEST_BLOCKED（缺依赖、没权限、外部服务不通等）时它停下等你解决环境，而不是乱改代码凑过。
4. 自动修复最多 3 轮：3 轮还不行就停下、给你现场证据和"从哪个 skill 继续"的指令，不会假装成功。
5. 能中断、能续跑：每个阶段的产物和状态都落在 .prizmkit/ 目录里，中途停了之后可以从上次的阶段接着走（用 prizmkit-workflow 的 resume）。

六、最小上手示例

# 1) 安装
npx skills add lone-yu-cmd/PrizmKit-OpenSource

# 2) （可选）首次接手项目，先初始化文档上下文
/prizmkit-init

# 3) 一句话把需求做到"待你确认提交"
/prizmkit-workflow 给登录接口加上刷新令牌(refresh token)的支持

# 4) 流程跑到 committer 会停住，AI 给你看改动和提交信息，你回复"确认"才提交

# 5) 需要上线时，另行单独执行
/prizmkit-deploy

七、总结

日常开发用 /prizmkit-workflow 一把梭；不确定问 /prizmkit；接新项目先 /prizmkit-init；上线单独 /prizmkit-deploy；小修小补直接改，不走流程。