从方法论到工程化：可复制的 AI 协作体系化工作流
聚焦工程化落地——怎么把方法论变成可复制的工程体系：Rules 锁底线、Skills 定流程、审查流水线做检查。
一、为什么需要工程化
上一篇讲了"怎么拆项目"，解决了方法论层面的问题。但现实中你会遇到这些工程问题：
- 团队里有人用 Claude Code，有人用 Cursor，有人用 Trae——每款编辑器的规则格式不同，难道要维护 N 份？
- 不同项目有不同的业务约束——每次开新项目都要从零配置？
- 一个人拆任务、写代码、做检查，效率天花板明显——能不能让审查流程自动化？
这套工程化方案要解决的就是：一次配置，多编辑器复用；一次沉淀，多项目复用；审查流水线按需组合。
本质上，工程化是把上一篇的三层分工从"人的自觉"变成"系统的约束"——领域拆分和宏观编排不再是靠人记得做，而是被 Rules、Skills、配置文件强制加载；微观执行的审查不再靠人一个个看，而是被审查 Skills 系统化检查。
二、统一基准规范，灵活适配多款 AI 编辑器
核心思路：一套 Claude Code 配置 → 生成多编辑器规则
不同编辑器的规则格式各不相同：
| 编辑器 | 规则文件 | 格式 |
|---|---|---|
| Claude Code | .claude/CLAUDE.md + rules/*.md | Markdown |
| Cursor | .cursor/rules/*.mdc | Markdown + metadata header |
| Trae | .trae/rules/*.md | Markdown |
| Codex | AGENTS.md | Markdown |
| CodeBuddy | .codebuddy/rules/*.md | Markdown |
如果每个编辑器各维护一份，工作量大且容易不一致。解法：以 .claude 配置为基准，AI 自动生成其他编辑器规则。
具体操作
第一步：建立 Claude Code 配置体系
.claude/
├── CLAUDE.md # 项目全局规则（入口，所有任务自动加载）
├── rules/ # 全项目通用底层规则
│ ├── project-behavior.md # 项目行为规范 + 安全底线
│ ├── typescript-common.md # TypeScript 通用规范
│ ├── code-format-common.md # 代码格式规范
│ └── security-common.md # 安全通用规范
└── skills/ # 面向具体任务的专项能力
├── 前端开发 Skill # 按技术栈定制
├── 后端开发 Skill # 按技术栈定制
├── 审查类 Skills # code-review / security / performance
├── 测试类 Skills # 单测 / 集成测试
└── 通用工具 Skills # commit / PR / TODO / 文档
Rules 和 Skills 的定位区分：
Rules = 通用底线（所有任务都必须遵守，自动加载）
Skills = 具体岗位的操作指南（按需加载，写前端加载前端 Skill，写后端加载后端 Skill）
第二步：用 AI 生成多编辑器规则
提示词：
根据 .claude 文件夹下的 Claude Code 配置，生成 trae、cursor、codex、codebuddy
原生 IDE 支持的规则。
质量约束：不要丢失任何文件的配置
约束条件：不要随意更改原始内容
不同编辑器的格式差异由 AI 自动适配，比如 Cursor 的 .mdc 需要 metadata header，其他编辑器各有各的约定。核心原则：
- 单一数据源：
.claude/是唯一的 truth，其他都是生成产物 - 内容无损：不丢失任何配置项，不随意修改原始内容
- 格式适配：只做格式转换，不做语义修改
三、Rules：四条底层宪法
Rules 是"底层宪法"——定义所有开发任务都必须遵守的通用规范。每个人的项目不同，具体的 Rule 内容也不同，但需要解决的问题是一样的。
| Rule 文件 | 解决什么问题 | 一句话定位 |
|---|---|---|
project-behavior.md | AI 乱改结构、重复造轮子、扩大影响面 | "AI 的行为边界" |
typescript-common.md | AI 绕过类型检查、any 满天飞、类型定义缺失 | "类型系统的铁律" |
code-format-common.md | 代码风格不统一，协作成本高 | "让所有代码像一个人写的" |
security-common.md | AI 泄露敏感信息、Token 存储不安全、错误信息暴露内部细节 | "安全底线不可逾越" |
3.1 project-behavior.md — 约束 AI 的开发边界
问题：AI 经常做出"看起来对但实际有隐患"的操作——无理由重命名、改公共接口不确认影响面、已有工具函数不用又写一份。这些行为单个看问题不大，累积起来项目就乱了。
这条 Rule 解决：给 AI 划定开发边界——可以做什么、不可以做什么、做了需要确认什么。
核心关注点：
- 优先复用：已有组件、工具函数、API 封装，不要重复造轮子
- 不随意变更：文件、函数、目录名称不要无理由重命名
- 确认影响面：修改公共接口、导出结构、共享包前必须确认影响范围
- 风格一致：新代码与项目已有风格保持一致
- 安全底线：禁止操作生产环境配置、禁止提交敏感信息
3.2 typescript-common.md — 锁死类型安全
问题：AI 最常见的偷懒方式就是用 any 跳过类型检查，或者函数参数/返回值不写类型。短期省事，长期维护成本巨大——类型断链后，后续所有依赖这个函数的代码都失去了类型保护。
这条 Rule 解决：让 AI 无法绕过类型系统，保证整个项目的类型链条不断。
核心关注点：
- 严格模式：不可关闭，禁止随意
@ts-ignore - any 使用原则：尽量零 any → 优先 unknown → 配合类型守卫收窄 → 仅第三方库冲突时例外
- 显式类型要求：函数参数、返回值、async 返回
Promise<T>、类属性、Props——必须显式声明 - null 与 undefined 区分：
field?: Type是"可以不存在"，field: Type | null是"存在但值为空"，语义不同不能混用
3.3 code-format-common.md — 统一代码风格
问题：AI 每次生成的代码风格可能不一致——引号、分号、缩进各不相同。一个人开发还好，多人协作或 AI 反复修改后，代码看起来就像拼凑的。
这条 Rule 解决：让所有代码看起来像一个人写的，降低协作认知负担。
核心关注点：
- 统一缩进、引号、分号、trailing comma 等基础格式
- 配套格式化工具配置，格式化可自动化
- 导入排序规则
- 配套 lint/format/tsc 检查命令
3.4 security-common.md — 安全底线
问题：AI 对安全极不敏感——可能把 Token 存到 localStorage，可能在错误响应中暴露 SQL 和堆栈信息，可能用明文存密码。这些问题上线前不容易发现，上线后就是安全事故。
这条 Rule 解决：把安全检查从"人记得做"变成"AI 被强制加载"。
核心关注点：
- 认证策略：Token 怎么存、怎么传、怎么刷新——不同项目方案不同，但必须有明确规则
- 前端约束：Token 不能存哪里、必须怎么携带
- 密码安全：只存哈希、不存明文、不可逆、必须加盐
- 错误信息安全：对外不暴露 SQL、堆栈、内部路径、环境配置
- 敏感信息：日志不记录完整 Token，API Key 不进代码仓库
四、提炼项目特有的 Rules 和 Skills
上面四条是通用型 Rules，但每个项目还有自己的业务特有规则。
Rules：约束性规则
Rules 是约束性的——"必须这样做""不能那样做"。提炼方法：每当发现 AI 犯了同类错误，就补一条 Rule。
| 规则类型 | 解决什么问题 |
|---|---|
| 业务逻辑规则 | AI 不了解业务约束，做出不符合业务预期的行为 |
| 数据约定规则 | 数据库字段和代码字段映射混乱，前后端不一致 |
| 错误处理规则 | 错误处理不统一，该自动处理的手动处理，该跳转的不跳转 |
Skills：能力性技能
Skills 是能力性的——"遇到这类问题，按这个流程解决"。把高频操作步骤沉淀成技能。
| Skill 类型 | 解决什么问题 |
|---|---|
| 创建新 API 端点 | AI 不知道项目的标准开发流程，每回从头想 |
| 添加新页面 | AI 不知道页面目录结构怎么拆，文件职责不清晰 |
| 认证模式 | AI 不了解项目的认证架构，可能绕过代理直接调用 |
蒸馏流程
- 日常积累：每修复一个 AI 犯的错就补一条 Rule，每完成一个高频操作就沉淀一个 Skill
- 定期 Review：合并重复项，删除过时项
- 团队共创：定期同步，让 Rules 和 Skills 成为团队共同认知
- 新项目复用：通用型直接复用，业务型作为模板调整
五、Skills：按岗位分工的能力库
如果说 Rules 是"什么不能做"，Skills 就是"这类任务应该怎么做"。Skills 按岗位分工，形成完整的能力矩阵：
| 分类 | 解决什么问题 |
|---|---|
| 前端开发 Skill | AI 不知道前端的标准目录结构、状态管理模式、API 封装方式 |
| 后端开发 Skill | AI 不知道后端的分层职责、DTO 校验、数据查询规范 |
| 代码审查 Skill | 人工 Review 容易漏，需要按维度系统检查 |
| 安全审计 Skill | AI 对安全不敏感，需要参考 OWASP 等标准系统扫描 |
| 性能审计 Skill | 性能问题不容易肉眼发现，需要按指标检查 |
| 测试生成 Skill | 写测试是低频高成本的事，AI 可以快速补充 |
| 通用工具 Skill | commit message、PR 描述、模块文档等重复劳动 |
5.1 前端开发 Skill
前端开发主 Skill，解决 AI 写前端时的几个核心问题：
开发前必须确认的约束——AI 写代码前，Skill 要求它先确认：
- 路径别名是否使用
- 样式方案是否使用 CSS Modules
- 状态管理模式和规则
- 是否所有类型都显式定义
- 页面是否按规范拆分文件
页面目录结构——标准页面必须按职责拆分，每个文件职责单一：页面入口不写业务逻辑、状态文件不放跨页面逻辑、组件目录只放组件。
状态管理——关键规则：
- 页面级状态的初始化方式
- 渲染时的订阅方式
- 异步状态修改的包裹方式
- 禁止在
useEffect依赖数组中监听 observable 属性
API 设计——核心规则：
- 所有 API 按业务模块拆分，统一从入口导出
- 请求参数和响应必须定义类型
- 严禁组件内直接使用底层请求库
- 认证按项目安全规范处理
认证数据流——三层各司其职：
| 层级 | 职责 |
|---|---|
| API 拦截器 | 处理认证失败自动刷新、请求队列、失效跳转 |
| 路由拦截器 | 页面级登录校验和 redirect |
| Store | 内存用户信息和权限状态 |
前端功能通用拆解流程：
功能拆分
├── 开发前准备
│ ├── 新增接口
│ ├── 相关枚举
│ └── 公用逻辑判断
├── 绘制页面/组件
│ ├── 定义静态资源文件和页面/组件模板
│ └── 生成基础样式结构
├── 业务功能
│ ├── 展示交互逻辑
│ ├── 页面/组件初始化（接口调用）
│ ├── 页面字段填充
│ └── 点击事件
└── 人工细节
└── UI 细节和逻辑处理
5.2 后端开发 Skill
后端开发主 Skill，解决 AI 写后端时的几个核心问题：
分层职责——这是后端规范的核心，四个层各做各的事：
| 层级 | 该做什么 | 不该做什么 |
|---|---|---|
| Controller | 路由、参数解析、API 文档装饰、调用 Service | 写业务逻辑 |
| Service | 业务逻辑、数据处理、数据查询 | 直接处理 HTTP 请求响应 |
| DTO | 请求响应结构、校验规则、文档描述 | 写业务逻辑 |
| Module | 模块注册、依赖注入配置 | 写业务逻辑 |
Controller 规则——使用装饰器声明路由，显式返回类型，不捕获业务异常（交给全局异常过滤器）。
Service 规则——构造函数依赖注入，依赖用 private readonly，环境配置通过 ConfigService 获取，不直接读取 process.env。
DTO 规则——每个请求和响应都要有 DTO，禁止用 any 替代，每个字段加文档描述和参数校验。
ORM 规则——Model 和数据库字段的命名映射规则、主键策略、写操作使用事务。ORM 已经是数据访问抽象，小型项目不需要再包 Repository，避免过度设计。
后端功能通用拆解流程——通用模版：
后端开发任务拆解
├── 1. 定义与契约 (Design & Contract)
│ ├── 数据库设计（表结构/字段）
│ ├── 接口定义（URL/入参/出参）
│ └── 枚举定义（状态/类型）
├── 2. 核心逻辑 (Core Logic)
│ ├── 数据校验（参数是否合法）
│ ├── 业务计算（核心算法/处理流程）
│ └── 数据持久化（存库/更新/删除）
├── 3. 接口与适配 (Interface & Adapter)
│ ├── 接口编写（Controller/API）
│ ├── 数据转换（DTO/VO 映射）
│ └── 异常处理（错误码/错误信息）
└── 4. 收尾 (Finalization)
├── 接口自测（Postman/cURL）
└── 文档更新（API Docs）
5.3 审查与保障 Skills
开发完成后，靠人工 Review 容易漏。项目配套了一组审查 Skills，按维度分工：
- 前端审查：架构规范、API 层、类型安全、Hooks 规则、状态管理、移动端适配
- 后端审查：架构分层、DTO 验证、类型安全、错误处理、数据查询
- 安全审计：参考 OWASP Top 10，扫描认证授权、输入验证、注入攻击、敏感信息泄露
- 性能审计：前端关注重渲染、长列表、缓存；后端关注 N+1 查询、索引、慢查询
一键完整审查——执行顺序：
code-reviewer → security-auditor → performance-expert → 综合审查报告
六、通用体系化执行流程
把 Rules 和 Skills 串起来，就是一套完整的执行流程：
先计划 → 大功能拆分成小功能逐步计划 → 确认方案 → 完成代码
→ 规范检查（code-review）→ 安全检查（security-audit）
→ 性能检查（performance-audit）→ 测试检查（test-writer）
逐步展开
1. 先计划【领域拆分层】
- 读取任务相关的锚定清单和契约信息
- 识别当前任务属于哪个模块、涉及哪些上下游
2. 大功能拆分成小功能逐步计划【宏观编排层】
- 按五步拆解法拆成原子任务
- 每个原子任务：单目标 + 明确输入 + 可校验验收标准
3. 确认方案【宏观编排层】
- 输出原子任务清单，人工确认可行、无遗漏
- 不能省——AI 规划的方案可能有盲区
4. 完成代码【微观执行层】
- 加载对应开发 Skill
- 每个任务执行前读取三大锚定清单 + Rules
- 每个任务完成后人工验收 + 按需
/clear（参考上一篇的原子化开发节奏）
5. 规范检查（code-review）【微观执行层】
- 加载对应审查 Skill
- 检查架构规范、类型安全、代码质量
6. 安全检查（security-audit）【微观执行层】
- 加载安全审计 Skill
- 检查认证授权、输入验证、敏感信息
7. 性能检查（performance-audit）【微观执行层】
- 加载性能审计 Skill
- 检查查询效率、缓存策略、渲染性能
8. 测试检查（test-writer）【微观执行层】
- 加载测试生成 Skill
- 补充核心逻辑单测 + 边界场景测试
流程弹性
- 改文案/调样式 → 跳过 5-7，直接 code-review + test
- 常规业务功能 → 标准模式（1-4 + 5 + 6 + 8）
- 核心模块 → 完整模式（1-8 全覆盖）
AI 协同开发闭环
把整个流程串起来，就是一个从需求到交付的完整闭环：
需求描述 → Rules 保证底线 → Skills 指导专项开发
→ code-review Skill 审查质量 → security/perf Skill 审计风险
→ test Skill 补充测试 → doc Skill 生成文档
→ commit/pr Skill 完成交付
七、工程化的核心价值
| 维度 | 没有工程化 | 有工程化 |
|---|---|---|
| 编辑器规则 | 各维护一份，容易不一致 | 一套基准配置，AI 自动生成多编辑器规则 |
| 项目经验 | 每次新对话 AI 从零学习 | Rules 和 Skills 沉淀复用 |
| 质量保障 | 自己审自己，容易漏 | 审查 Skills 按维度分工检查 |
| 执行效率 | 每次从头想流程 | 通用流程模板，按需裁剪 |
| 团队协作 | 经验只在个人脑子里 | Rules 和 Skills 是团队共享资产 |
| 安全底线 | 靠人记得检查 | Rules + 安全审计 Skill 强制加载 |
八、一页速记
| 类型 | 关键词 | 核心内容 |
|---|---|---|
| Rules | 通用底线 | 行为、类型、格式、安全 |
| 开发 Skill | 前后端开发 | 按岗位加载，约束开发流程 |
| 审查 Skill | 质量审查 | 架构、类型、安全、性能 |
| 测试 Skill | 测试生成 | 单测、集成测试、边界场景 |
九、快速上手清单
- 建立
.claude/配置体系，把项目规范结构化——先从行为规范和类型规范开始 - 用 AI 生成其他编辑器规则，验证内容无损
- 按岗位沉淀 Skills——前端开发 Skill、后端开发 Skill 先搞定，审查类 Skill 逐步补充
- 开始沉淀 Rules，每发现一个 AI 重复犯的错就补一条
- 跑通审查流水线，先从 code-review 开始，逐步加 security 和 performance
- 跑通通用执行流程，先在一个小模块上完整走一遍
- 团队共创，定期同步 Rules 和 Skills，让它成为团队共同认知
