在 AI 编程工程化这个系列文章中，我们一直在讲一件事：

怎么把 AI，从“工具”变成“员工”。

我们给它立规矩（Rule），封流程（Command），补能力（Skill），加检查（Hook），做分工（Subagent），接外部系统（MCP），再把能力打包沉淀（Plugin）。

看起来已经很完整了。

但如果你没有真正从头到尾跑过一遍，你很容易觉得：

“这些概念我都懂，但项目上还是不知道怎么落地。”

说实话，我自己也经历过这个阶段。

每个机制单独看都懂。真到了项目里，却不知道先配哪个、后配哪个，更不知道它们之间到底怎么配合。

这也是很多人现在用 AI 编程的真实状态。

工具装了一堆，命令配了几个，MCP 也接上了，但一到真实项目里，还是想到哪做哪。

这一篇，是这个系列最后一篇，我们不讲概念。

手把手带大家，从 0 到 1，搭一套完整的 AI 编程工作流，把前面学的东西真正用起来。

实战项目设定

为了让整个流程有落脚点，我们来设定一个真实的项目场景：从 0 到 1 开发“AI 提示词资产管理工具（PromptHub）”。

需求不复杂，但足够完整：

• 用户登录：使用账号和密码登录
• 提示词管理：增、删、改、查、收藏、分类、导出
• AI 生成提示词：根据用户的简要描述，生成完善的结构化提示词
• AI 调优提示词：对已有提示词进行优化、改写、补结构、去歧义
• AI 大模型配置：大模型供应商、模型名称、BaseURL、API Key、启用状态、连接测试

流程覆盖：需求分析 → UI 设计 → 前端开发 → 后端开发 → 测试验收 → 部署上线。

如果是以前，这些活基本都得自己手动推进：出需求、画原型、画 UI、写页面、写接口、联调、测试、部署……

从头干到尾，少说也得几周，甚至更长时间。

这次，我们换一种方式。

让 AI 全程参与，并且按“工程化”的方式运作。

不是让 AI 帮你写几段代码。

而是让它像一个真正的开发团队一样，按流程、按规范、按分工来干活。

本文实战项目 PromptHub 已开源在 github.com/XPoet/prompt-hub。如果你想查看最终实现，可以边读文章，边对照仓库里的目录、配置和代码。

整体流程

这里要特别先说明，本文中所有使用 AI 的场景，都是基于 Codex 或 Claude Code 来跑的。如果你用的是其他 AI 工具，思路可以照搬，但具体配置方式会有差异。

在动手之前，我们先把整体流程梳理和拆分清楚。

第一步：创建项目目录
本地创建一个目录，用 AI 工具打开这个目录。后面所有环节和动作全部在这个目录下进行。

第二步：生成产品需求文档
不要一上来就写代码，也不要一上来就画 UI。而是把你的需求发给 AI，让 AI 生成专业的产品需求文档（PRD），这是后面所有工作的源头。

第三步：生成 UI 设计提示词
让 AI 根据产品需求文档生成一份专门给 AI 设计工具（例如：Pencil、Figma Make、Stitch、Open Design）的提示词。

第四步：生成 UI 设计稿
让 AI 设计工具根据 UI 设计提示词生成完整的高保真 UI 设计稿。

第五步：搭建项目骨架
让 AI 根据产品需求文档、UI 设计稿和技术栈方案，把前端、后端、文档等目录结构搭建起来。

第六步：配置项目 Rule，把 AI 管住
开始之前，先定好项目规则。技术栈、代码规范、输出格式、禁止事项，全部写进 Rule。

第七步：配置 Command，定义标准开发流程
把“分析需求 → 制定计划 → 生成代码 → 自我检查 → 提交代码”这一套流程封装成命令。

第八步：配置 Subagent，拆分角色，各干各的
产品、前端、后端、审查，不要让一个 AI 干所有事。拆成多个 Subagent，各自有独立上下文，互不干扰。

第九步：配置 Skill，补充 AI 专项能力
不是所有能力都需要从零写，可以直接安装社区已经沉淀好的 Skill，让 AI 工具装上就能用。

第十步：配置 MCP，打通 AI 外部能力
读设计稿、连数据库、操控浏览器和实时读取官方文档。到这一步，AI 不再只是“写代码”，而是开始操作真实环境。

第十一步：配置 Hook，关键节点加检查
在关键操作节点自动触发检查机制，让每一次输出都经过质量验证。AI 可以快，但不能乱。

第十二步：制作 Plugin，把能力沉淀下来
把上面的 Rule、Skill、Hook、MCP 打包成一个 Plugin。下次开新项目，一条命令装好，不用重新配。

第十三步：让 AI 自主规划，并按开发计划持续推进
让 Codex 或 Claude Code 交叉读取产品需求文档、UI 设计稿、技术栈方案、项目规则和现有代码，自主拆分总开发路线与阶段任务，再按计划逐项实现、运行、测试、审查和提交。

第一步：创建项目根目录

这一步只做两件小事：

1. 在本地新建 prompt-hub 目录
2. 用 Codex 或 Claude Code 打开这个目录

后面所有的产出都会落在 prompt-hub 这个目录里：

• 产品需求文档存放为 prompt-hub/docs/PRD.md
• UI 设计提示词存放为 prompt-hub/docs/design/ui-prompt.md
• 前端 frontend、后端 backend 都放在 prompt-hub/ 下面
• Rules、Commands、Skills、Subagents、Hooks 等配置，根据所用 AI 工具分别放在 prompt-hub/.claude/、prompt-hub/.codex/ 和 prompt-hub/.agents/
• 最后的 Plugin 也是从这个目录里打包出去

第二步：让 AI 生成产品需求文档

很多人用 AI 做项目，一上来就说：“帮我开发一个 AI 提示词资产管理工具。”

这句话不是不能用。但它太粗糙了。

AI 不知道你说的“提示词管理”到底具体包括什么，不知道要不要登录验证，不知道提示词以哪种形态展示，不知道有没有收藏和分类等等。

所以我的第一步，不是让 AI 写代码。

而是先把简单的功能描述，变成一份可开发的产品需求文档。

我会直接在 Codex 或 Claude Code 里这样说：

我需要从 0 到 1 开发一个面向个人使用的 AI 提示词资产管理工具（PromptHub）。

请根据以下的页面及功能描述，帮我整理成一份完整的产品需求文档，并保存为 docs/PRD.md。

页面及功能描述：
- 登录页：支持账号（邮箱）和密码登录
- 注册页：通过邮箱和密码注册新账号
- 提示词展示页：支持分页显示提示词卡片列表（提示词卡片包含删除、修改、复制、收藏、AI 调优等交互功能）、支持搜索和筛选（按收藏和分类筛选）提示词、支持导出（批量导出）提示词
- 提示词创建页：支持手动创建提示词和 AI 自动生成提示词
- 提示词编辑页：支持修改提示词标题、描述、内容、分类等信息
- 提示词分类管理页：支持提示词分类的增、删、改、查
- 提示词 AI 调优页：支持 AI 调优前后对比、保存调优历史记录
- AI 大模型配置页：支持配置大模型供应商、模型名称、BaseURL、API Key、启用状态、测试连接
- 个人设置页：查看个人资料（邮箱、注册时间）、修改密码

要求：
1. 明确项目背景、用户角色、核心功能、页面清单、业务流程、字段定义和验收标准，补充完整产品逻辑。
2. 输出文件保存为 docs/PRD.md，作为后续 UI 设计、前端开发、后端开发、测试验收的共同依据。

这一步看起来像“多绕了一圈”。

但实际开发里，它非常关键。

因为后面所有环节都要根据这份产品需求文档往下走。

如果你对 AI 生成的初稿不满意，直接把反馈发给 AI，继续对话，直至产出最终的产品需求文档，并保存到 docs/PRD.md。

第三步：用产品需求文档生成 AI 设计工具的提示词

需求文档有了，但还不能直接丢给 AI 设计工具。

因为需求文档是给人和开发 Agent 看的。

AI 设计工具需要的是另一种输入：更偏页面、布局、状态、视觉风格的 UI 设计提示词。

所以这一步，让 AI 基于 docs/PRD.md 产品需求文档，生成一份专门给 AI 设计工具用的提示词。

提示词保存到：docs/design/ui-prompt.md

我会这样说：

基于 @docs/PRD.md 产品需求文档，生成一份给 AI 设计工具（例如：Pencil、Figma Make、Stitch、Open Design）使用的 UI 设计提示词。

要求：
1. 提示词必须包含产品背景、页面清单、设计系统、画布要求、组件要求和输出要求
2. 主色调为蓝色系
3. 所有文案使用中文
4. 输出文件保存为 docs/design/ui-prompt.md

这一步的关键，不是“让 AI 多写一段 Prompt”。

而是把产品需求文档翻译成 AI 设计工具能理解的设计语言。

比如产品需求文档里写的是：“支持提示词收藏”。

到了 AI 设计工具提示词里，就要变成：

• 提示词卡片右上角有收藏按钮
• 收藏状态要有已收藏 / 未收藏两种视觉状态

这就是从“功能描述”到“界面表达”的转换。

如果这一步不做，AI 设计工具很容易只生成一个看起来还行、但开发细节不足的页面。

第四步：用 AI 设计工具生成高保真 UI

有了专门的 UI 设计提示词之后，我们就可以使用 AI 设计工具进行设计，例如：Pencil、Figma Make、Stitch、Open Design 等，这类 AI 设计工具都适合不太懂设计的开发人员。

这里我使用 Pencil：

• 打开 Pencil 桌面端
• 新建一个空白设计文件，命名为 UI.pen，保存到 docs/design/ 目录
• 复制 docs/design/ui-prompt.md 提示词到 Pencil 的 Agent 对话框（如果你有喜欢的风格图片，也可以上传为附件，提醒 AI 参考）
• 选择大模型，等待 Pencil 生成设计稿

这一步的目的不是一次生成完美设计稿，而是先让界面“看得见”。

第一版生成后，我会重点看 4 件事：

• 风格是不是符合预期
• 页面是不是齐全
• 信息层级是不是清楚
• 开发是不是能落地

如果有不满意的地方，直接选中那个画布或模块，可以手动调整，也可以让 AI 按你的反馈来修改。

这一步完成后，项目里至少应该有三个文件：

docs/PRD.md
docs/design/ui-prompt.md
docs/design/UI.pen

产品需求文档、UI 设计提示词、UI 设计稿都有了。

后面再进入项目骨架和工程化配置，才是稳的。

• Pencil 使用示例图：

  

• Figma Make 使用示例图：

  

第五步：让 AI 搭建项目骨架

在写 Rule 之前，先让 AI 把项目的整体骨架搭建出来。

尤其是全栈项目，前端和后端本来就是两套体系。如果一开始目录就乱，后面 Rule、Command、Hook、Skill、Subagent 全都会跟着乱。

所以我会先让 AI 做一件很具体的事：

按照约定的结构，先把项目目录和 README 说明文档生成出来。

给 AI 的提示词

提示词不用把每个目录都解释一遍，但技术栈、最小边界和验收标准必须写清楚。

请为 AI 提示词资产管理工具（PromptHub）创建一个可运行、不含业务功能的 pnpm workspace 全栈项目骨架。

技术栈：
- 前端：TypeScript、Vite、Vue 3、SCSS、Element Plus、Axios、Pinia，部署到 Cloudflare Pages
- 后端：TypeScript、Hono、Cloudflare Workers、D1、Drizzle ORM、Wrangler，部署到 Cloudflare Workers

要求：
1. 根目录包含 README.md、CLAUDE.md、AGENTS.md、docs/、.claude/、.codex/、.agents/、frontend/ 和 backend/。
2. 使用官方模板初始化前后端。前端只保留基础入口和常用目录；后端只保留环境类型、D1 绑定、Drizzle 基础配置和 GET /api/health，不创建业务页面、接口或数据表。
3. 在 wrangler.jsonc 中预留名为 DB 的 D1 绑定，不写入真实 Token、数据库 ID 或其他敏感信息。
4. docs/ 包含 design/、api.md、database.md 和 deployment.md，说明设计文件、接口、数据库与 Cloudflare 部署约定。
5. 根目录、frontend/、backend/ 都要有对应的 README.md、CLAUDE.md 和 AGENTS.md；所有文档、注释和说明使用中文。
6. 安装依赖并实际验证：前端类型检查与生产构建、后端类型检查与本地启动、D1 本地初始化和迁移、GET /api/health。最后列出执行命令和结果。

基于上面的要求，AI 会把目录结构大概规划成这样：

prompt-hub/
├── .agents/                 # AI 代理配置目录
├── .claude/                 # Claude 配置目录
├── .codex/                  # Codex 配置目录
├── backend/                 # Hono 与 Cloudflare Workers 后端
│   ├── migrations/          # Drizzle SQL 迁移
│   ├── src/
│   │   ├── config/          # 配置
│   │   ├── db/              # D1 与 Drizzle
│   │   ├── middleware/      # Hono 中间件
│   │   ├── routes/          # 接口路由
│   │   ├── schemas/         # 输入输出 Schema
│   │   ├── services/        # 应用服务
│   │   ├── types/           # 环境与公共类型
│   │   └── utils/           # 工具函数
│   ├── AGENTS.md            # Codex 后端规则
│   ├── CLAUDE.md            # Claude Code 后端规则
│   ├── README.md            # 后端启动与部署说明
│   ├── drizzle.config.ts    # Drizzle Kit 配置
│   └── wrangler.jsonc       # Workers 与 D1 配置
├── docs/
│   ├── design/              # UI 设计稿与设计说明
│   │   ├── UI.pen           # Pencil 设计稿
│   │   └── ui-prompt.md     # UI 设计提示词
│   ├── api.md               # API 规范
│   ├── database.md          # 数据库规范
│   ├── deployment.md        # 部署说明
│   └── PRD.md               # 产品需求文档
├── frontend/                # Vue 3 与 Vite 前端
│   ├── public/              # Pages 静态资源与重写规则
│   ├── src/
│   │   ├── api/             # 接口客户端
│   │   ├── assets/          # 静态资源
│   │   ├── components/      # 可复用组件
│   │   ├── composables/     # 组合式函数
│   │   ├── router/          # 路由配置
│   │   ├── stores/          # 共享状态
│   │   ├── styles/          # SCSS 全局样式
│   │   ├── types/           # 公共类型
│   │   ├── utils/           # 工具函数
│   │   └── views/           # 路由页面
│   ├── AGENTS.md            # Codex 前端规则
│   ├── CLAUDE.md            # Claude Code 前端规则
│   └── README.md            # 前端启动与构建说明
├── AGENTS.md                # AI 代理项目约束
├── CLAUDE.md                # Claude 项目约束
└── README.md                # 项目入口说明

这里要注意三点。

第一，frontend/ 不是随便建几个目录，而是基于 Vite 初始化出来的前端项目骨架。

第二，backend/ 也不是纯手写目录树，而是基于 Hono 的 Cloudflare Workers 模板初始化出来的 TypeScript 工程。

第三，D1 通过 wrangler.jsonc 中名为 DB 的绑定接入，Schema 和迁移交给 Drizzle ORM 管理。骨架阶段只验证健康检查，不提前创建业务表。

最后别只看目录是否齐全。让 AI 把实际执行的安装、类型检查、生产构建、后端启动命令和健康检查结果逐项列出来。命令没有跑通，就不能算骨架完成。

这样做的好处是，AI 后面不只是“知道目录长什么样”，还知道这些目录分别来自哪套框架初始化结果。

到这一步，项目骨架就清楚了。

目录一旦清楚，后面的 Rule 文件应该放哪里、分别管什么，也就自然清楚了。

为什么选这套技术栈？

核心原因很现实：它适合个人开发者。

• 前端使用 Vue 3、Vite 和 TypeScript，开发体验成熟，生成静态产物后可以直接部署到 Cloudflare Pages。
• 后端使用 Hono 和 Cloudflare Workers，不需要购买或维护服务器，也不用自己处理扩容。
• 数据库使用 Cloudflare D1，配合 Drizzle ORM 管理 Schema 和迁移，可以和后端放在同一个平台。
• 前后端统一使用 TypeScript，AI 在生成类型、接口和数据结构时更容易保持一致。

最大的好处是：一个 Cloudflare 账号，就能放下前端、后端和数据库。

Pages、Workers、D1 都提供免费计划或免费额度。对于个人项目、学习项目和早期验证，通常可以先以较低成本上线，再根据真实访问量决定是否升级。

第六步：配置 Rule——先把 AI 管住

这一步的核心只有一个：让 AI 知道“你的项目规则”。

但对于一个全栈项目，只写一个 Rule 文件是不够的。

前端有前端的规范，后端有后端的规范，还有一些全局性的协作原则。如果全塞在一个文件里，AI 进前端目录时也会读到一堆后端规范，进后端目录时也会读到一些前端规则。信息一多，它反而容易搞混。

所以我的做法是：分层写 Rule。

项目根目录、frontend/、backend/ 各放一组 Rule。Claude Code 使用 CLAUDE.md，Codex 使用 AGENTS.md，同一层级的两份文件保持相同约束。

根 Rule：全局协作原则

放在项目根目录 prompt-hub/CLAUDE.md，并同步到 prompt-hub/AGENTS.md。

这个文件管的是“整个项目层面的规矩”——目录路由、前后端协作方式、文档同步规则、全局禁止事项。

注意，这里不要写具体技术栈细节。

因为前端怎么写、后端怎么写，应该分别交给前端 Rule 和后端 Rule 去约束。根 Rule 只管所有人都必须遵守的东西。

# 项目规则

## 项目概述
这是一个 AI 提示词资产管理工具的全栈项目，支持用户登录、提示词的增删改查、收藏、分类，以及 AI 生成提示词和 AI 调优提示词。

## 项目结构
- frontend/ → 前端项目，遵循该目录下的 CLAUDE.md 或 AGENTS.md
- backend/ → 后端项目，遵循该目录下的 CLAUDE.md 或 AGENTS.md
- docs/ → 项目文档

## 前后端协作规范
- 接口返回结构统一为：{ code: number, data: T, message: string }
- 所有接口遵循 RESTful 规范
- 接口路径统一前缀：/api/v1/
- 前后端通过 docs/api.md 同步接口定义，修改接口必须先更新文档
- 数据库设计统一记录在 docs/database.md

## 工作方式
- 写代码前，先确认需求和技术方案，再制定开发计划
- 涉及接口变更时，先更新接口文档，再改代码
- 涉及页面开发时，先读取 docs/design/ 下的 UI 设计稿和产品需求文档
- 优先复用已有目录和模块，不要随意新增同类结构

## 全局禁止事项
- 禁止删除任何文件，除非得到明确确认
- 禁止在没有确认技术方案的情况下直接动手写代码
- 禁止读取或修改 node_modules、dist 等依赖或构建产物目录

前端 Rule：前端项目规范

放在 prompt-hub/frontend/CLAUDE.md，并同步到 prompt-hub/frontend/AGENTS.md。

AI 进入 frontend/ 目录工作时，会读取对应工具的前端 Rule。这里面写的全是前端相关规范，后端的事一个字都不提。

# 前端项目规则

## 技术栈

- Node.js
- pnpm
- TypeScript
- Vue 3
- Vite
- Vue Router
- Pinia
- Axios
- SCSS + CSS Variables
- Element Plus
- Cloudflare Pages

## 框架规范

- 统一使用 Composition API + `<script setup>` 语法
- 业务代码禁止使用 Options API
- 页面级组件放 `views/`，可复用组件放 `components/`
- 简单组件内部状态优先使用 `ref` / `reactive`，不要滥用全局 store

## 常用命令

- `pnpm dev`：启动 Vite 开发服务器
- `pnpm type-check`：执行前端类型检查
- `pnpm build`：执行生产构建，产物用于 Cloudflare Pages 部署

## 目录规范

- `src/api/`：接口调用封装
- `src/assets/`：静态资源
- `src/components/`：通用组件
- `src/composables/`：组合式函数
- `src/layouts/`：布局组件
- `src/views/`：页面级组件
- `src/router/`：路由配置
- `src/stores/`：状态管理
- `src/styles/`：全局样式与设计变量
- `src/types/`：通用类型定义
- `src/utils/`：工具函数

## 接口规范

- 接口调用统一放在 `src/api/`
- 页面组件不直接调用 `axios` / `fetch`
- 请求参数和响应结果必须定义 TypeScript 类型
- 请求响应结构应与后端 `ApiResponse<T>` 保持一致

## 样式规范

- 页面开发优先参考 `docs/design/` 下的 UI 设计文件
- 使用 `scoped` 样式，避免全局污染
- 颜色、间距、字体等使用 CSS 变量，不要硬编码
- SCSS 主要用于嵌套、模块拆分、mixin 和函数

## 命名规范

- 文件名：kebab-case
- 变量/函数：camelCase
- 常量：UPPER_SNAKE_CASE
- 类型/接口：PascalCase

## 禁止事项

- 原则上禁止使用 `any`，确需使用时必须说明原因
- 禁止主动读取、修改 `node_modules`、`dist`、`build` 等生成目录

后端 Rule：后端项目规范

放在 prompt-hub/backend/CLAUDE.md，并同步到 prompt-hub/backend/AGENTS.md。

同理，AI 进入 backend/ 目录工作时，会读取对应工具的后端 Rule。

# 后端项目规则

## 技术栈

- Node.js
- pnpm
- TypeScript
- Hono
- Cloudflare Workers
- Cloudflare D1
- Drizzle ORM
- Wrangler

## 架构规范

- 按 `routes → services → db` 拆分职责
- `routes/` 负责路由、参数解析和响应，不堆业务逻辑
- `services/` 负责业务规则和流程编排
- `db/` 负责 D1 连接、Drizzle Schema 和数据访问
- `schemas/` 负责输入输出校验结构
- `middleware/` 负责鉴权、日志、错误处理等横切逻辑
- Hono 的绑定类型必须明确声明，通过 `c.env` 访问 D1 和环境变量
- TypeScript 代码统一使用 2 空格缩进，必要注释使用 JSDoc 风格

## 常用命令

- `pnpm dev`：通过 Wrangler 启动本地 Workers 开发服务
- `pnpm type-check`：执行后端类型检查
- `pnpm exec drizzle-kit generate`：使用 Drizzle Kit 生成迁移
- `pnpm exec wrangler d1 migrations apply DB --local`：把迁移应用到本地 D1
- `pnpm exec wrangler deploy`：部署到 Cloudflare Workers

## 接口规范

- 接口路径：/api/v1/{资源名}
- GET 查询、POST 创建、PUT 更新、DELETE 删除
- 请求参数必须经过 Schema 校验
- 返回统一使用 `ApiResponse<T>` 结构

## 数据库规范

- 表名使用 snake_case（如 `prompts`）
- 字段名使用 snake_case
- 每张表必须有 id、created_at、updated_at 字段
- Drizzle Schema 统一放在 `src/db/`
- 迁移文件由 Drizzle Kit 生成，并通过 Wrangler 应用到 D1
- 业务代码优先使用 Drizzle ORM，不直接拼接 SQL

## 异常处理

- 使用 Hono 的 `app.onError` 统一处理未捕获异常
- 使用 `app.notFound` 统一处理不存在的路由
- 错误响应必须符合 `docs/api.md` 中的错误码规范

## 禁止事项

- 禁止把 Token、数据库 ID、API Key 等敏感信息硬编码在代码或 `wrangler.jsonc` 中
- 禁止从 `process.env` 直接读取 Workers 绑定，统一使用类型化的 `c.env`
- 禁止手工修改 Drizzle 已生成的迁移记录或 Wrangler 本地持久化数据

三层 Rule 的关系

你可能会问：这三层 Rule，AI 怎么知道该读哪个？

其实很简单。

Claude Code 和 Codex 都会根据当前工作目录读取对应的项目规则：

• 使用 Claude Code 时读取对应层级的 CLAUDE.md
• 使用 Codex 时读取对应层级的 AGENTS.md
• 进入 frontend/ 或 backend/ 工作时，根规则和当前目录规则一起约束任务

不需要你手动指定。

这意味着：

• 前端 Agent 干活时，读到的是“全局规则 + 前端规则”
• 后端 Agent 干活时，读到的是“全局规则 + 后端规则”
• 两边互不干扰，各自遵守各自的规范

这就是分层 Rule 的价值。

全局的东西写一份，专属的东西各写各的。

很多人一上来就想研究 Prompt 怎么写更高级，模型怎么选更强。

我后来才发现，这些都不是最先要解决的问题。

先把边界定清楚，再谈效率。

第七步：Command——定义标准开发流程

Rule 解决的是“什么能做、什么不能做”。

Command 解决的是“每次怎么做”。

在实际开发里，有一个很烦的问题：

每次给 AI 布置任务，我都要重复说一大堆要求。

“先分析需求，再出设计，然后写代码，写完自己检查一遍，最后生成 commit message……”

这件事非常消耗耐心。

因为你以为自己在开发，实际上有一部分精力一直花在“纠正 AI 的默认动作”上。

所以我把开发中最常重复的操作，封装成了三个 Command：

• /dev —— 标准开发流程
• /commit —— 生成规范的提交信息
• /review —— 代码审查

/dev：标准开发流程

这是用得最多的一个。

每次接到一个开发任务，输入 /dev，AI 就按固定流程走。

创建 .claude/commands/dev.md：

你是一个全栈开发专家。收到开发任务后，严格按照以下流程执行：

## 第一步：需求分析
- 理解任务目标和业务背景
- 列出涉及的功能模块
- 梳理涉及的文件和目录

## 第二步：组件设计（如涉及前端）
- 如已有 docs/design/UI.pen 或导出的预览图，先参考 UI 设计稿，不要凭空设计页面
- 规划页面结构和组件拆分方式
- 明确哪些是页面级组件，哪些是可复用组件
- 列出需要用到的 util、composable 和 store

## 第三步：接口设计（如涉及后端）
- 输出 RESTful 接口定义
- 包含：路径、方法、请求参数、返回结构
- 明确哪些接口需要新增，哪些需要修改

## 第四步：制定修改计划
- 列出需要新增的文件和修改的文件
- 每个文件说明改动内容和改动原因
- 标注改动的先后顺序（先改哪个，后改哪个）

## 第五步：代码实现
- 严格按照计划执行，不要超出范围
- 按照项目 Rule 中的规范编写代码
- 前端组件必须通过 `src/api/` 中的接口层发起请求
- 后端接口必须有参数校验
- 每完成一个文件，简要说明改了什么

注意看这个流程。

它不是“分析 → 写代码”两步就完了。

中间多了组件设计、接口设计、制定计划三个环节。

这三步是我用下来觉得最关键的。

如果跳过设计直接写代码，AI 很容易“想到哪写到哪”，最后改出来一堆你不想要的东西。

如果跳过计划，AI 可能一口气改了 10 个文件，你根本不知道它改了什么、为什么改。

有计划再动手，和没计划就动手，结果差很多。

/commit：生成规范的提交信息

代码写完了，要提交。

每次手动写 commit message 很烦，让 AI 随便写又容易格式不统一。

所以我单独封装了一个 /commit。

创建 .claude/commands/commit.md：

根据当前代码变更，生成一条符合约定式提交规范的 commit message。

!`git diff --cached`

要求：
- 类型：feat / fix / refactor / docs / chore / style / test / ci
- 描述使用中文，不超过 50 个字
- 如有必要，在 body 里补充变更原因（可选）
- 不要加多余的解释，直接给结果

约定式提交格式：<type>(<scope>): <subject>

以后写完代码，输入 /commit，AI 会自动读取当前的代码变更，生成一条格式统一的 commit message。

/review：代码审查

代码提交之前，最好过一遍审查。

但自己审自己的代码，很容易“看不到问题”。

让 AI 来做这件事，效果其实不错。

创建 .claude/commands/review.md：

对当前的代码变更进行 review，检查以下维度：

1. **安全问题**：SQL 注入、XSS、暴露的敏感信息
2. **错误处理**：未捕获的异常、吞掉的错误
3. **类型安全**：any 的滥用、缺少返回类型
4. **性能问题**：不必要的重渲染、缺少缓存
5. **逻辑错误**：边界条件、空值处理

按严重程度分类：Critical / Warning / Suggestion。
每条问题注明文件路径和行号，并给出修改建议。
如果没有问题，直接说“未发现问题”。

这个 Command 我一般在 /commit 之前用。

写完代码 → /review 先过一遍 → 有问题改完 → /commit 提交。

形成一个小闭环。

这三个 Command 在 AI 提示词资产管理工具里怎么触发

光讲定义，还是有点抽象。

我拿 AI 提示词资产管理工具里的一个真实任务举例：开发“提示词展示页”。

开发这个页面要实现三件事：

• 前端新增提示词展示页组件
• 后端新增提示词列表查询接口
• 页面支持按分类和收藏状态筛选

这时候，我不会直接说“帮我把页面写出来”。

我会先输入：

/dev @docs/PRD.md 开发提示词展示页

AI 收到之后，不会立刻开写。

它会先按 dev.md 里的流程往下走：

第一步，需求分析。
它会先把任务拆开：前端要新增组件、页面、路由；后端要新增查询接口、分页参数、筛选条件。

第二步，组件设计。
例如：AI 会告诉你前端大概怎么拆：

• views/prompt/prompt-list.vue → 页面入口
• components/prompt/prompt-filter.vue → 筛选组件
• components/prompt/prompt-card.vue → 提示词组件
• api/prompt.ts → 接口请求
• types/prompt.ts → 类型定义

第三步，接口设计。
AI 会先把后端接口列出来，例如：

GET /api/v1/prompts?page=1&pageSize=20&category=writing

返回结构：

{
  "code": 0,
  "data": {
    "list": [],
    "total": 100,
    "page": 1,
    "pageSize": 20
  },
  "message": "success"
}

第四步，制定开发计划。
它会把准备改的文件一条一条列出来，告诉你哪个是新增、哪个是修改、为什么改。

到这一步，你心里其实已经很有底了。

因为 AI 不是在“闷头写代码”，而是在先给你过方案。

你确认没问题，它才会进入第五步开始实现。

写完之后，我不会直接提交。

我会接着输入：

/review

这时候，review.md 会按预设维度去查。

比如它可能会给出这样的结果：

• Warning：frontend/src/types/prompt.ts:12 使用了 any，建议改成明确的 PromptItem[]
• Suggestion：frontend/src/views/prompt/prompt-list.vue:48 筛选条件变化时缺少防抖，频繁输入可能导致重复请求
• Warning：backend/src/routes/prompts.ts:35 未对 pageSize 做上限校验，可能导致大分页查询

这些问题，有些你自己审代码时未必第一眼能看到。

尤其是边界条件和类型问题，很容易漏。

把这些问题修完之后，我最后再输入：

/commit

AI 会基于当前改动，给出一条提交信息。比如：

feat(prompt): 新增提示词展示页面与分页查询接口

如果这次改动还顺手修了一个筛选参数的边界问题，它也可能生成：

feat(prompt): 新增提示词展示页面并完善筛选查询逻辑

到这里，一个完整的小闭环就跑完了：

/dev 负责把任务拆明白、设计清楚、再动手写。

/review 负责在提交前帮你找问题。

/commit 负责把最后的提交动作标准化。

这就是我说的：

Command 真正有用的地方，不是少打几行字，而是让整套开发动作变得稳定。

三个 Command 的配合

到这里，你可以看到这三个 Command 之间的关系：

• /dev：管“怎么开发”——从需求到代码
• /review：管“写得对不对”——提交前自动审查
• /commit：管“怎么提交”——生成规范的提交信息

一个完整的开发周期就是：

/dev → 写代码 → /review → 修问题 → /commit → 提交

每一步都有标准动作。

不用每次重复说。
也不用担心它跳步骤。

Command 不是为了省几句话。

而是为了把“偶尔做对一次”，变成“默认每次都做对”。

第八步：Subagent——开始分工

到这里，Rule 和 Command 已经把“规矩”和“流程”定好了。

但还有一个问题：一个 AI 干所有事，它会忘事。

AI 的上下文窗口再大，也不是无限的。

你让它分析需求、设计表结构、写后端接口、写前端页面、最后做 Review——塞了一堆东西进去，到后面它很容易丢掉前面的关键信息。

解决办法很直接：拆。

对于 AI 提示词资产管理工具，我是这样拆分 Subagent 的：

• 产品 Agent：负责澄清需求、补齐边界和验收标准
• 前端 Agent：负责前端组件、页面和交互实现
• 后端 Agent：负责 API 接口、业务逻辑和数据库设计
• 审查 Agent：负责代码审查和风险检查

每个 Subagent 都放在 .claude/agents/ 目录下，一个 .md 文件就是一个角色。

文件里包含 front-matter（定义元信息）和系统提示词（定义行为）。

Claude Code 会根据 description 字段自动判断什么时候该调哪个 Agent。当然，你也可以在对话中直接指定使用哪个 Agent 来处理需求。

这样做的好处不是“更高级”，而是更稳。

因为上下文一旦干净，输出质量就会明显提升。

1. 产品 Agent：把需求说清楚

产品 Agent 不是来写代码的。

它的核心价值只有一件事：先把要做什么定义清楚。

例如 AI 提示词资产管理工具里有一个需求：增加“批量导出提示词”功能。

如果你直接把这句话丢给开发 Agent，问题会很多。

导出范围怎么确定？
导出格式是什么？
导出内容包含哪些字段？
没有选中提示词怎么处理？
导出失败后页面怎么反馈？

所以产品 Agent 的定义，应该像这样（.claude/agents/product-manager.md）：

name: product-manager
description: 产品需求分析专家。当用户提出新功能、需求还比较模糊，或者需要输出功能说明、流程、字段定义、验收标准时触发。
tools: Read, Grep, Glob
model: opus
color: purple

你是一个产品分析专家，负责把模糊需求整理成开发可执行的任务说明。

## 你的职责
- 理解用户需求，识别目标、角色、边界条件和异常流程
- 输出功能说明、页面流程、字段定义和验收标准
- 把模糊描述拆成可交付的开发任务

## 你的输入
- 用户的原始需求
- 现有系统功能说明
- 已有页面或接口约束

## 你的输出
- 功能目标
- 用户操作流程
- 字段与状态定义
- 边界情况
- 验收标准
- 待确认问题清单

## 约束
- 不直接写实现代码
- 不擅自决定技术方案
- 遇到需求歧义时，必须明确列出待确认问题

它输出的内容，类似这样：

• 支持导出勾选的提示词，未勾选时按当前搜索和筛选结果导出
• 导出格式只支持 Markdown 文件
• 导出内容包含提示词标题、分类、适用场景、提示词正文和更新时间
• 单次最多导出 500 条提示词
• 导出前展示导出范围和数量确认，导出完成后自动下载 .md 文件

你看，这时候需求才真正变成“可以开发”的状态。

2. 前端 Agent：只管页面和交互

前端 Agent 的目标很明确：把需求说明、UI 设计稿和接口文档，变成能用的组件和页面。

它只需要关心四件事：

• 页面结构怎么组织
• 页面样式怎么编写
• 交互状态怎么处理
• 接口数据怎么正确展示

前端 Agent 的定义可以写成这样（.claude/agents/frontend-developer.md）：

name: frontend-developer
description: 前端开发专家。当用户要求开发组件、页面、交互逻辑，或需要实现 Vue 3 + TypeScript 前端功能时触发。
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
color: green

你是一个前端开发专家，负责实现 Vue 3 + TypeScript 的页面、组件和交互逻辑。

## 你的职责
- 根据需求说明和接口文档实现页面与组件
- 保持组件职责清晰，避免单文件过度膨胀

## 你的输入
- 产品 Agent 输出的需求说明或产品需求文档
- 后端 Agent 提供的接口定义
- 现有前端项目结构和组件规范

## 你的输出
- 页面代码
- 组件代码
- API 调用层代码
- 必要的类型定义

## 约束
- 不修改后端代码和数据库
- 不擅自变更接口字段
- 不跳过交互态和异常态处理

如果让它来做“批量导出提示词”这个需求，它应该关注的是：

• 导出按钮放在哪里
• 批量选择和全选状态怎么设计
• 导出确认弹窗怎么展示范围、数量和格式
• 导出中 loading 怎么表现
• 导出完成后怎么触发文件下载和成功提示
• 无可导出数据或导出失败时怎么提示用户

这些事情交给前端 Agent 很合适。

因为它的上下文里，不会塞进数据库表结构、索引设计、事务处理这些无关信息。

3. 后端 Agent：只管接口、数据和业务规则

后端 Agent 也一样。

它不需要关心按钮长什么样，也不需要参与页面布局。

后端 Agent 的定义，可以这样写（.claude/agents/backend.md）：

name: backend-developer
description: 后端开发专家。当用户要求设计 API 接口、D1 数据结构、业务逻辑实现，或需要 Hono + Cloudflare Workers 开发时触发。
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
color: orange

你是一个后端开发专家，负责设计并实现 TypeScript + Hono + Cloudflare Workers + D1 的接口、数据模型和业务逻辑。

## 你的职责
- 根据需求说明设计 RESTful API
- 使用 Drizzle ORM 设计 Schema、索引和数据约束
- 实现 Hono 路由、Service、数据库访问和中间件
- 处理参数校验、数据一致性、异常和批量操作逻辑

## 你的输入
- 产品 Agent 输出的功能说明和字段定义
- 现有数据库设计与项目代码结构
- 前端需要的接口契约

## 你的输出
- 接口定义（URL、方法、参数、返回结构）
- Drizzle Schema 和迁移方案
- 核心业务代码
- 错误码与异常处理说明

## 约束
- 不修改前端页面代码
- 不输出与项目技术栈不符的实现
- 必须明确说明数据约束和异常处理策略

还是同一个需求。

它要负责的事情是：

• 设计导出接口 POST /api/v1/prompts/export
• 根据选中 ID 或筛选条件查询可导出的提示词
• 按 Markdown 模板组装导出内容
• 控制单次导出数量和文件大小
• 生成下载文件名，并记录导出结果和失败原因

前端 Agent 和后端 Agent 做的是同一个功能，但关注点完全不同。

拆开之后，两个 Agent 都会更专注。

4. 审查 Agent：只负责挑毛病，不负责下场写代码

很多人用 AI 做 Review 时，容易犯一个问题：

一边让它审，一边又让它顺手改。

结果是什么？

它一会儿站在开发者视角，一会儿站在审查者视角，角色混在一起，判断就会变形。

更稳的做法是：让审查 Agent 只负责找问题。

它不参与需求讨论，不负责实现，也不顺手改代码。

它只做审查。

定义可以这样写（.claude/agents/code-reviewer.md）：

name: code-reviewer
description: 代码审查专家。当用户说“帮我 review 代码”、“检查这次改动有没有问题”，或代码改完需要做质量审查时触发。
tools: Read, Grep, Glob
model: sonnet
color: blue

你是一个代码审查专家，负责对现有变更进行问题识别和风险评估。

## 你的职责
- 检查功能是否符合需求
- 检查代码规范、一致性和可维护性
- 识别潜在 Bug、边界问题和安全风险
- 给出明确的修改建议和优先级

## 你的输入
- 变更后的代码
- 原始需求说明
- 项目规范和既有实现模式

## 你的输出
- 问题列表
- 风险等级
- 修改建议
- 可选优化项

## 约束
- 不直接修改代码
- 不重写需求
- 结论必须基于具体代码和具体场景
- 必须按“高风险问题 / 一般问题 / 可优化项”分组输出

比如它在审“批量导出提示词”时，可能会提这些问题：

• 导出范围没有区分“选中项”和“当前筛选结果”，容易导出错数据
• 前端导出中可以重复点击，可能触发多个下载任务
• 后端没有限制导出数量或文件大小，可能导致接口超时
• Markdown 内容没有处理标题层级和空行，可能破坏文件结构
• 导出操作没有审计日志，后续难追踪敏感数据流出

你会发现，Review 一旦独立出来，质量会高很多。

因为它不再想着“怎么尽快写完”，而是专门想着“这里会不会出问题”。

在 AI 提示词资产管理工具里，怎么调用这四个 Subagent？

前面讲的是定义。

真正关键的是：到了项目里，怎么调它们。

我用 AI 提示词资产管理工具里“批量导出提示词”这个需求，举一个完整例子。

第一步：先调产品 Agent，把需求压实

比如我会这样发任务：

请用 product-manager 这个 agent，先把“批量导出提示词”需求整理成可开发的说明。

这一步的目的不是让它写文档好看。

而是先把歧义消掉。

第二步：把产品输出分别交给前端 Agent 和后端 Agent

产品 Agent 把需求说明整理好之后，我不会再把整段上下文重新讲一遍。

而是把它的结果当成输入，分别交给前后端。

前端 Agent 的调用方式会像这样：

请用 frontend-developer 这个 agent，根据以下需求说明，完成“批量导出提示词”前端开发。

需求说明：[贴入 product-manager 的输出]
设计文件：docs/design/UI.pen
要求：先对照 UI 设计稿拆分页面和组件，不要自行改动整体视觉风格。

后端 Agent 则会这样调：

请用 backend-developer 这个 agent，根据以下需求说明，完成“批量导出提示词”后端实现。

需求说明：[贴入 product-manager 的输出]

这就是 Subagent 真正的用法。

把同一个需求，按职责分发给不同角色处理。

第三步：前后端产出后，再交给审查 Agent 复核

等前端和后端都完成后，再把结果交给审查 Agent：

请用 code-reviewer 这个 agent，审查“批量导出提示词”这次变更。

需求说明：
[贴入 product-manager 的输出]

变更范围：
[贴入 frontend 和 backend 的主要改动]

这一步非常关键。

因为审查 Agent 手里同时有“原始需求”和“最终实现”，它才能判断有没有偏题，哪里有漏网之鱼。

第四步：如果需求变了，只重跑相关 Agent

Subagent 还有一个特别实用的点：变更影响可控。

比如后来你决定把“单次最多导出 500 条提示词”改成“单次最多导出 2000 条提示词”，而且增加“按分类分组导出”功能。

这时候你不需要把整套流程从头再跑一遍。

你只需要：

• 先让产品 Agent 更新导出规则和验收标准
• 再让前端 Agent 补“按分类分组导出”交互
• 再让后端 Agent 调整导出数量限制、Markdown 生成逻辑和查询策略
• 最后让审查 Agent 再检查一遍新增风险

这就是工程化最重要的价值之一：改动是局部可控的。

你不会因为一个需求小改动，就把整个上下文重新搅乱。

为什么这一步重要？

因为它第一次把 AI 从“一个什么都想干的全能助手”，变成了“多个各司其职的协作角色”。

这件事一旦想清楚，你会发现很多问题都自然消失了。

不要让一个 AI 干所有事。

拆开之后，每个 Agent 的输出质量都会明显提升。不是因为模型突然变强了，而是因为上下文变干净了。

这跟真实团队协作是一个道理。

你不会让一个人同时做产品、设计、前端、后端、测试、最后还做 Code Review。

AI 也一样。

第九步：Skill——补充专项技能

Subagent 解决了分工问题。

但每个 Agent 内部还是有一堆高频、重复的动作。

比如：

• 前端 Agent 每次写完页面，都要按同一套规则检查 Composition API、命名、样式
• 后端 Agent 每次加接口，都要按同一套规范处理 Hono 路由、Service、Schema、D1 和错误响应
• 页面设计时，需要有人把“配色、排版、节奏、层级”这些审美维度补齐

这些操作如果每次都靠手写 Prompt 来驱动，效率其实不高。

更好的做法是：优先使用已经沉淀好的 Skill。

很多能力社区已经写好了，直接装就行，不用自己造轮子。

针对 AI 提示词资产管理工具这种“Vue 3 + Hono + Cloudflare Workers + D1”的技术栈，我会装这几个：

给前端 Agent 用：

• vue-best-practices：Vue 3 最佳实践检查，强推 Composition API + <script setup> + TypeScript
• frontend-design：前端设计 Skill，用来补充视觉层级、排版、配色和交互细节
• ui-ux-pro-max：综合型 UI/UX 设计智能，内置大量配色、字体、组件样式、交互规范，可以直接出高完成度页面

给后端和 Cloudflare 工程 Agent 用：

• cloudflare：覆盖 Workers、D1、Pages、存储和部署等 Cloudflare 平台能力
• workers-best-practices：检查 Workers 运行时、绑定、异步任务和可观测性等生产实践
• wrangler：处理 Workers 本地开发、D1 迁移、配置校验和部署命令
• database-schema-designer：辅助设计 D1 表结构、索引、约束和迁移方案

通用能力：

• superpowers：社区沉淀的一套“基础功法”Skill 包，包含 TDD、调试、头脑风暴、协作流程等 10+ 个通用能力，几乎每个项目都用得上

装完之后，这些 Skill 就成了 Agent 的“自带技能”，你不用每次再手把手教一遍。

具体的安装方式、触发方式等操作细节，我在前面的 Skill 那篇文章里已经展开过，这里不再重复。

第十步：MCP——打通外部能力

前面几步，AI 做的事情都还在“代码层面”——读代码、写代码、生成文件。

但一个真实项目不只有代码。

还要看设计稿、查数据库、调浏览器、翻官方文档。

AI 需要去操作这些外部系统。

这就是 MCP 的价值。

这个 AI 提示词资产管理工具使用 Vue 3、Hono、Cloudflare Workers 和 D1，我会优先接入下面四类 MCP：

1. Pencil MCP——从 .pen 设计稿直接生成组件和页面

前面我们已经用 Pencil 生成了 UI 设计稿。

到了开发阶段，最自然的做法就不是先把设计稿搬到别的工具里，而是直接连 Pencil MCP。

以前写页面，我得一边打开设计稿，一边切到 IDE 对着抄。布局、字号、间距、按钮状态，全靠肉眼翻译。

接上 Pencil MCP 之后，流程会变成这样：

把 docs/design/UI.pen 交给 Claude，告诉它：“按这个设计稿生成前端页面”

它会做几件事：

• 直接读取 .pen 文件里的页面结构、组件层级和样式变量
• 如果你指定的是某个节点，它就生成一个组件；如果你指定的是整个页面画布，它就直接生成完整页面
• 对照项目里的组件库，能复用就复用，不重新造
• 把颜色、间距、字号这些设计信息带到代码里，而不是靠手写猜尺寸

这一步的价值很直接：

前面用 Pencil 做 UI，后面就直接用 Pencil MCP 落到组件和页面，中间不用再手动翻译一遍。

如果你的 UI 设计稿在 Figma 里，或者后续设计协作主要发生在 Figma，那就直接用 Figma MCP。

思路是一样的：都是让 AI 去读设计稿结构、提取样式信息，再生成组件或页面。区别只是在于，Pencil MCP 读的是 .pen 文件，Figma MCP 读的是 Figma 节点链接。

2. Cloudflare MCP——让 AI 检查 Workers、D1 和 Pages

前端、后端和数据库都放到 Cloudflare 之后，调试不只是在本地看代码。

还要确认 D1 数据库是否存在、DB 绑定是否正确、Worker 是否部署成功、Pages 构建是否正常。

Cloudflare 官方 MCP 覆盖 Workers、D1、Pages 等 API。授权后，可以让 AI 直接读取这些资源的当前状态。

例如可以这样问：

• PromptHub 的 D1 数据库是否已经创建？
• 后端 Worker 的 D1 绑定名称是不是 DB？
• 最近一次 Workers 部署和 Pages 构建是否成功？
• 当前账号里是否存在名称相近、容易误用的测试资源？

这一步最适合处理三类事情：

• 开发前核对资源：确认 D1、Workers、Pages 的名称和绑定关系
• 部署后检查状态：核对 Worker、Pages 和 D1 的实际配置是否与 docs/deployment.md 一致
• 排查线上问题：结合 Cloudflare 的日志和可观测性能力定位请求失败、绑定缺失或部署配置错误

需要注意：Cloudflare MCP 连接的是真实账号。先给最小权限，任何创建、修改、删除资源的操作都要单独确认。

3. Chrome DevTools MCP——让 AI 自己调浏览器

以前前端联调，我得自己打开浏览器，F12，看控制台报错，截图贴给 AI，它再猜问题。

现在 AI 自己就能打开 Chrome，看控制台、查网络请求、读 DOM 结构、跑性能审计。

AI 提示词资产管理工具里几个典型场景：

• 「调优按钮点了没反应」：AI 打开页面，点按钮，看 Network 面板发现 POST 请求 500，再看 Console 的跨域报错，继续检查 Hono 的 CORS 中间件和 Worker 路由配置
• 「提示词列表页加载慢」：AI 跑一次 Performance 分析，检查列表渲染、重复请求和主线程阻塞
• 「样式没对齐」：AI 读取计算后的 CSS，发现是 flex 的 align-items 写错了

它不是在「猜」问题，是在「看」问题。

4. Context7 MCP——实时拉官方文档

Vue、Hono、Drizzle ORM、Wrangler 的 API 和配置方式都会更新，不能只靠模型记忆写代码。

比如 D1 绑定类型应该怎么生成，Drizzle 迁移目录怎么配置，当前版本都应该先看文档。

Context7 解决的就是这个问题。

它在 AI 写代码前，先去拉最新的官方文档，确保用的 API 是当前版本的。

MCP 是一个关键转折点

之前的 Rule、Command、Subagent、Skill，解决的都是“AI 怎么写代码”的问题。

MCP 解决的是“AI 怎么干活”的问题。

而真实开发里，占时间最多的，往往还真不是写代码。

是查数据、对接口、调浏览器、翻文档、反复验证。

MCP 一接上，AI 才算真正开始进入生产环境。

第十一步：Hook——增加检查站

AI 干活速度很快，但速度快，也意味着出错的速度也会更快。

你不盯着，根本发现不了。

所以需要 Hook。

Hook 的本质，就是“自动检查站”——在 AI 的关键操作前后，自动插一段校验逻辑。

本文中的 AI 提示词资产管理工具是全栈项目，前端和后端都得管。我配了下面这套 Hook，写在 .claude/settings.json 里。

1. 代码自动 Lint（PostToolUse）

前后端都是 TypeScript，用一个 PostToolUse Hook 判断文件路径，再进入对应目录执行 ESLint：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "FILE=\"$CLAUDE_TOOL_INPUT_FILE_PATH\"; case \"$FILE\" in *frontend/*) cd frontend && pnpm eslint --fix \"${FILE#*frontend/}\" || echo '前端 ESLint 自动修复失败，请在验收阶段处理' >&2 ;; *backend/*.ts) cd backend && pnpm eslint --fix \"${FILE#*backend/}\" || echo '后端 ESLint 自动修复失败，请在验收阶段处理' >&2 ;; esac"
          }
        ]
      }
    ]
  }
}

这里有三个细节：

• 修改 frontend/ 下的文件时，使用前端项目的 ESLint 配置
• 修改 backend/ 下的 TypeScript 文件时，使用后端项目的 ESLint 配置
• 自动修复失败时，把原因写到 stderr 提醒 AI；完整 Lint 和类型检查仍放在验收阶段执行

Hook 只有一份，前后端规则仍然分开。这样既减少重复配置，也不会把浏览器和 Cloudflare Workers 的运行时规则混在一起。

2. 拦截危险的删除命令（PreToolUse）

这个最关键。AI 执行 rm -rf 或者 DROP TABLE 之前，直接拦死。

{
  "PreToolUse": [
    {
      "matcher": "Bash",
      "hooks": [
        {
          "type": "command",
          "command": "INPUT=$(cat); CMD=$(echo \"$INPUT\" | jq -r '.tool_input.command'); echo \"$CMD\" | grep -qE 'rm\\s+-rf|DROP\\s+TABLE|DROP\\s+DATABASE|TRUNCATE|git\\s+push.*--force' && echo '已拦截危险命令: '\"$CMD\" >&2 && exit 2 || exit 0"
        }
      ]
    }
  ]
}

几个关键点：

• 拦截原因写到 stderr（>&2），AI 能看到为什么被挡，会自己换一种方式
• 顺手把 DROP TABLE、TRUNCATE、git push --force 一起拦了，避免误删 D1 数据或覆盖远程分支

3. AI 干完活的桌面通知（Stop）

AI 跑一个长任务（比如生成 10 个接口、改 5 个组件），你不可能一直盯着屏幕。

Stop Hook 在 AI 结束响应时触发，正好用来发桌面通知。

{
  "Stop": [
    {
      "hooks": [
        {
          "type": "command",
          "command": "osascript -e 'display notification \"任务完成，请查看结果\" with title \"Claude Code\" sound name \"Glass\"'"
        }
      ]
    }
  ]
}

macOS 用 osascript 调系统通知，带「叮」的一声。

我现在常用的姿势：让 AI 跑后端接口生成，自己切到浏览器看文档、喝水。叮一声响，回来 review。

4. 修改接口后自动同步文档（PostToolUse）

AI 提示词资产管理工具前后端是通过 docs/api.md 同步接口定义的（这点在根 Rule 里就约定了）。

但 AI 经常改完 Hono 路由或接口 Schema 后忘了改文档。配个 Hook 强制提醒：

{
  "matcher": "Write|Edit",
  "hooks": [
    {
      "type": "command",
      "command": "FILE=\"$CLAUDE_TOOL_INPUT_FILE_PATH\"; case \"$FILE\" in *backend/src/routes/*.ts|*backend/src/schemas/*.ts) echo '检测到后端接口变更，请同步更新 docs/api.md' >&2 ;; esac"
    }
  ]
}

这个不拦截，只提醒。AI 看到 stderr 输出，会主动去改文档。

5. SessionStart 自动加载最新接口和表结构

每次新开一个会话，AI 都要重新摸一遍项目。我让它启动时自动读最新的 api.md 和 database.md。

{
  "SessionStart": [
    {
      "hooks": [
        {
          "type": "command",
          "command": "echo '当前接口定义:'; cat docs/api.md; echo '当前数据库结构:'; cat docs/database.md"
        }
      ]
    }
  ]
}

SessionStart Hook 的 stdout 会直接进入 AI 的上下文。这意味着 AI 一开始就知道：现在有哪些接口、表里有哪些字段。

不用每次让它先 cat docs/。

Hook 的真正价值

Hook 最有价值的地方，不是帮你多做了一步检查。

而是把“原本靠人记住的事”，变成“默认一定会发生的事”。

人会忘。AI 也会忘。

但 Hook 不会。

AI 可以快，但不能乱。

Hook 就是那个负责踩刹车的。

第十二步：Plugin——把能力沉淀下来

到这里，AI 提示词资产管理工具的整套 AI 工作流已经跑起来了。

回头看前面铺垫的需求文档、UI 设计和项目骨架，再加上 Rule 到 Hook 这几步，其实已经形成了一条完整生产线，问题也随之出现：

这些配置都散落在项目各个地方。

下次你再开一个新项目，这些东西还得重新配一遍。

这就是 Plugin 要解决的问题。

Plugin 不是再给 AI 加一个新能力。

它更像一个收纳箱：把前面已经跑顺的 Rule、Command、Subagent、Skill、MCP、Hook，整理成一个可以安装、分发、升级的能力包。

先说清楚：Plugin 不是必做项。

如果你只是一个人在当前项目里用，或者这套流程还在不断试错，做到前面十一步已经够用了。不要为了“看起来完整”硬做 Plugin。

什么时候值得做 Plugin？

• 你已经在两三个项目里反复复制同一套配置
• 团队里不止一个人要用这套 AI 工作流
• 你想把某个成熟工作流发给团队内部，甚至发布到社区

到了这个阶段，再做 Plugin 才有意义。

Plugin 就是把上面所有东西打包成一个目录：

prompt-hub-plugin/
├── .claude-plugin/
│   └── plugin.json
├── CLAUDE.md
├── commands/
├── skills/
├── agents/
├── hooks/
└── .mcp.json

这里最关键的是 .claude-plugin/plugin.json。

它是插件的“名片”。

它不负责存放具体规则，也不负责写命令逻辑。它只负责告诉 AI 工具：这个插件叫什么、解决什么问题、当前是什么版本、由谁维护。

比如 AI 提示词资产管理工具这套工作流，可以这样写：

{
  "name": "prompt-hub-workflow",
  "description": "AI 提示词资产管理工具 AI 编程工作流：包含项目规则、标准开发命令、前后端 Subagent、专项 Skill、MCP 配置和自动检查 Hook。",
  "version": "1.0.0",
  "author": {
    "name": "XPoet"
  }
}

Plugin 本身是可选的，但只要你决定做 Plugin，plugin.json 就是必需的。

其他目录可以按需放。你只有 Skill 和 Hook，就只放 skills/ 和 hooks/。你没有 MCP，就不需要 .mcp.json。不要为了凑完整，把没用的东西也塞进去。

打包好之后，下个项目只要安装这个 Plugin，就能把整套工作流带过去。

甚至你还可以发布到团队内部，或者直接发到社区，让别人也用你的工作流。

第十三步：让 AI 自主规划，并按开发计划持续推进

前面十二步，已经把需求、设计、项目规则和工具准备好了。

最后一步，是让 Codex 或 Claude Code 读取这些真实资料，自主拆分路线，并持续完成开发、验证、修复和提交。

核心流程很简单：

读取项目 → 盘点现状 → 制定计划 → 按业务闭环开发 → 验证并修复 → 提交 → 继续下一项

为了避免长任务只留在聊天记录里，我们让 AI 把路线和进度维护在 docs/development-plan.md 中。

1．先让 AI 基于项目事实生成计划

不要直接说“把整个项目开发出来”，也不要替 AI 手工拆完所有任务。

让它先读取 PRD、UI 设计、项目规则、接口文档、数据库文档和现有代码，再根据依赖关系规划顺序。

可以直接使用下面这段提示词：

你是 PromptHub 全栈项目的主开发 Agent。

请先读取并交叉检查：
- docs/PRD.md 和 docs/design/UI.pen
- 根目录及 frontend/、backend/ 下的 README.md、CLAUDE.md、AGENTS.md
- docs/api.md、docs/database.md、docs/deployment.md
- frontend/、backend/ 的现有代码与配置
- Git 状态、提交记录和项目脚本

先盘点已完成、部分完成、未开始和被阻塞的能力，再创建或更新
docs/development-plan.md.

计划要求：
1. 按可独立验收的业务功能拆分任务，不要只按前端、后端、数据库分层。
2. 每个任务写清目标、依据、依赖、涉及文件、验证方式、验收标准和提交范围。
3. 保留用户已有修改，不读取或修改 node_modules、dist 等生成目录。
4. 涉及接口时先更新 docs/api.md；涉及数据库时先更新 docs/database.md 和迁移。
5. 自行审查任务覆盖范围、顺序和验证方式，修正后直接开始第一个任务。

重点只有一句：计划必须来自当前项目，而不是凭空生成一份通用清单。

2．按业务闭环持续推进

任务不要拆成“先写完数据库、再写完后端、最后写前端”。

更合适的拆法是：

• 用户注册与登录
• 提示词分类管理
• 提示词列表、搜索与筛选
• 提示词创建、编辑与删除
• 大模型配置与连接测试
• AI 生成与调优
• 全流程联调与部署验收

一个任务通常会同时涉及文档、数据、接口、页面和验证。做完之后，用户应该能实际使用这个功能。

计划生成后，让 AI 按下面的闭环持续执行：

请按 docs/development-plan.md 持续推进。

每个任务都要：
1. 检查 Git 状态并确认本次范围。
2. 读取对应需求、设计、文档和代码。
3. 先更新接口或数据库文档，再实现功能。
4. 运行匹配的类型检查、测试、构建、接口或浏览器验证。
5. 根据失败信息继续修复并重复验证，不能把失败留给我。
6. 自审需求、边界、安全、类型、文档同步和改动范围。
7. 更新计划状态和验证证据。
8. 只暂存当前任务文件，验证通过后创建一次独立提交。
9. 提交后继续下一个任务，不等待我回复“继续”。

这里真正重要的，不是让 AI 一口气写更多代码。

而是把“实现、验证、修复、提交”绑定在同一个任务里。每完成一个业务功能，就留下可检查、可恢复的计划状态和 Git 提交。

3．只在真正需要决策时暂停

减少人工确认，不等于取消安全边界。

遇到下面这些情况，AI 必须暂停：

• PRD 与 UI 存在会改变用户行为的冲突
• 需要删除文件、清空数据或执行其他不可逆操作
• 需要真实账号、密钥、付费资源或生产权限
• 需要执行远程迁移、生产部署、Git push 或创建 Pull Request
• 用户已有修改与当前任务直接冲突，无法安全合并
• 外部服务、网络、权限或环境问题持续阻塞

除此之外，目录选择、代码复用、任务拆分、测试修复和计划更新，都应该由 AI 自己处理。

如果会话中断，下次只需要告诉它：

请读取 docs/development-plan.md、Git 提交记录和当前工作区状态，
从第一个未完成且依赖已满足的任务继续执行，并沿用原有验证和提交规则。

这就是第十三步的价值。

让主 AI 基于项目事实规划路线，按业务闭环持续执行，并且只在真正需要人做决定时停下来。

前后对比

说了这么多，到底差别有多大？

对比项	没有工程化	有了工程化
UI 设计	页面边写边猜，做到一半才发现信息层级不对	用 AI 设计工具生成 UI 初稿，页面结构和组件边界提前看见
任务启动	每次开新任务，都要重新解释背景、技术栈和禁忌	Rule 自动加载基础约束，AI 一开始就在正确边界里工作
开发流程	想到哪做到哪，需求分析、设计、实现经常混在一起	/dev 按固定流程走，先分析、再设计、再实现、再自检
角色分工	一个 AI 同时想产品、写前端、写后端、做审查，上下文很快混乱	Subagent 各管一块，产品、前端、后端、审查职责清楚
需求变更	改一个点，常常牵动一大片，只能让 AI 重新读完整上下文	只重跑相关 Agent，其他产出保持稳定
专项能力	每次都要重新教 AI 怎么生成接口、文档、导出模板	Skill 把高频能力封装起来，直接按标准调用
风险控制	AI 可能误删文件、乱跑危险命令，发现时已经晚了	Hook 可以提前拦截高风险操作
跨项目复用	换个项目，配置重新复制，漏一个文件就掉一块能力	Plugin 可选打包，成熟工作流可以一键迁移
开发计划	一句话让 AI 开发完整项目，过程容易失控	主 AI 读取项目现状，自主拆分总路线和业务闭环任务，并持续维护计划状态
验收方式	AI 写完代码，你凭感觉看有没有问题	AI 按任务验收标准运行检查、修复问题、记录验证证据，通过后再提交
团队协作	每个人都有自己的提示词和习惯，产出质量不稳定	Rule、Command、Skill、Hook 统一沉淀，团队按同一套标准协作

你会发现，真正的变化不只是“更快了”。

而是整个开发过程开始变得稳定、可控、可复用。

不是 AI 变聪明了，是你让它系统化了。

同样的模型能力，有工程化和没有工程化，产出质量完全不是一个量级。

总结

到这里，这个系列写了 9 篇，说实话也超出了我的预期。

一开始，我只是想把 Claude Code 里的几个概念讲清楚。

从第一篇讲“为什么需要工程化”，到这一篇把所有概念真正串成一条生产线，整个体系的核心其实还是这几件事：

• Rule：让 AI 不乱来
• Command：让 AI 有流程
• Skill：让 AI 有能力
• Hook：让 AI 可控
• Subagent：让 AI 能协作
• MCP：让 AI 能接入外部系统
• Plugin：让能力沉淀、可复用
• 自主规划：让主 AI 基于项目真实状态拆分路线，并持续执行、验证、修复和提交

单拿出任何一个，都只是一个功能点。

但把它们串起来，你得到的就不再是一个“工具”。

而是一套可以持续进化的 AI 开发系统。

每做一个项目，你的 Rule 会更完善，Command 会更顺手，Skill 会更丰富，Hook 会更稳，Plugin 会越来越成熟，AI 制定路线、拆分任务、验证结果和控制提交边界的能力也会越来越贴近你的团队节奏。

AI 的能力也许变化很快。

但真正能长期积累下来的，是你的工程体系。

真正拉开差距的，不是谁用的模型更强，而是谁先把 AI 放进了自己的工程系统里。