我的 AI 编程工作流

个人实践总结 · Cursor / Claude Code 大需求开发
核心理念：规划用强模型想清楚，执行用快模型低成本落地，AI 审查 + 人工审查双保险

这套流程在解决什么

我踩过最典型的坑：Vibe Coding 一个大需求，改到第三轮前面写好的接口被动了，一个下午耗在「一句一句掰扯」上。根因不是模型笨，是缺对齐物——Spec Coding 那套 specify → plan → tasks → implement，我用自己的 Skills 落地成 Grill → PRD → Issues → Implement。

Anthropic 40 万会话的研究也印证：人 ~70% 规划、Agent ~80% 执行；成败看领域专业度，不是语法。所以我 Phase 0 不省 Opus，Phase 2 必须人工签字——AI 不能担责。

配套个人总结（桌面同目录）

文档	讲什么
《Spec-Coding规约驱动开发-个人总结》	为什么要分阶段对齐、和 spec-kit 的对应
《AI编程时代你的优势是什么-个人总结》	懂行 > 会写代码，说清/拆活/验收
《CLAUDE.md怎么写-个人总结》	项目常驻记忆怎么写
《Claude-Code七种配置方式-个人总结》	Skills / Rules / Hooks 放哪
《我的AI模型选型对比》	各阶段用什么模型
《MewCode-Agent项目-个人总结》	Agent 架构 mental model（选用）

一、总览

需求分流

类型	特征	推荐流程
小需求	改个 Bug、加个小接口、一次性脚本	直接 Vibe Coding，或单会话 `/implement`
大需求	跨模块、要长期维护、涉及架构决策	走完整 Grill → PRD → Issues → Implement 流水线

本文重点描述大需求流程。

全流程一览

┌─────────────────────────────────────────────────────────────────┐
│  Phase 0 · 规划（单会话，Opus 4.8）                               │
│  /grill-with-docs  →  /to-prd  →  /to-issues                     │
│  产出：决策纪要 + PRD + 可独立执行的 Issue 列表                    │
└────────────────────────────┬────────────────────────────────────┘
                             │ 人工确认 breakdown 后发布
                             ▼
┌─────────────────────────────────────────────────────────────────┐
│  Phase 1 · 实现（每 Issue 新会话，Sonnet 4.6）                    │
│  /implement  →  测试全绿  →  commit（暂不提 MR）                  │
└────────────────────────────┬────────────────────────────────────┘
                             │
                             ▼
┌─────────────────────────────────────────────────────────────────┐
│  Phase 2 · 审查（AI 审查 + 人工审查，两道门）                     │
│  ① 切换其他 AI · /review                                        │
│  ② 人工过 diff（兜底，保证代码对我可控）                           │
│  两道都过 → MR                                                   │
└─────────────────────────────────────────────────────────────────┘

模型 / AI 选型原则

阶段	AI / 模型	原因
规划（Grill / PRD / Issues）	Opus 4.8（Cursor）	思考更全面，擅长权衡架构取舍、发现遗漏边界、梳理依赖
实现（Implement）	Sonnet 4.6（Cursor）	执行快、消费低；Issue 范围已收窄，不需要重推理
AI 审查	切换其他 AI	交叉验证 Standards + Spec，发现 implement 盲区
人工审查	我自己	兜底：审查 AI 漏掉的业务/运行时/安全风险；保证代码对我可控

审查常用组合（AI 审查部分，任选其一，关键是和实现 AI 不同）：

实现 AI	审查 AI	说明
Sonnet 4.6（Cursor）	Opus 4.8（Cursor 新会话）	强模型审弱模型的产出，查遗漏和架构问题
Sonnet 4.6（Cursor）	GPT / Codex（其他 IDE 或 CLI）	跨厂商，审查视角完全独立
Sonnet 4.6（Cursor）	Claude Code（终端）	不同工具链，上下文隔离更彻底

规划阶段省下的返工成本，远大于 Opus 的 token 差价。
AI 审查 + 人工审查的成本，远小于「代码完全不可控」或漏审上线后的返工。
AI 不能担责——最终 merge 的决定权必须在我手里。

二、Phase 0：规划（Opus 4.8 · 单会话）

目标：在写一行代码之前，把「做什么、为什么、怎么验、拆成几块」全部对齐。

Step 1：`/grill-with-docs` — 压力测试 + 沉淀决策

做什么：对改造方案/大需求进行 relentless interview（逐条追问），同时用 /domain-modeling 把术语和 ADR 写进文档。

输入：

模糊的需求描述、改造想法、或现有方案草稿
可选：相关 issue、会议纪要、.scratch/ 里的讨论笔记

过程要点：

AI 一次只问一个问题，逐条确认后再继续
能读代码库回答的问题，AI 应先去探索代码，而不是问你
每个问题 AI 会给出推荐答案，你可以采纳或修正
讨论中 crystallise 的术语 → 写入 CONTEXT.md / CONTEXT-MAP.md
架构取舍 → 写入 docs/adr/

产出：

决策纪要（范围、优先级、验收标准、Out-of-Scope）
领域词汇表更新（如有）
ADR 记录（如有）

我的检查清单：

范围边界清楚了吗？（In-Scope / Out-of-Scope）
验收标准可量化吗？（不是「做好就行」）
有没有「现在不做但容易误做」的坑被明确排除？
分支策略、部署约束等工程决策是否已定？

示例触发：

/grill-with-docs

我想给 scm-rec-py 做 v1 MVP：搜索兜底推荐 + pgvector 向量编码，
GBDT+LR 先不做。帮我 stress-test 这个改造计划。

Step 2：`/to-prd` — 合成 PRD

做什么：把当前会话（Grill 讨论 + 代码库理解）直接合成 PRD，不再 interview。

输入：Step 1 完成的同一会话上下文

过程要点：

AI 探索代码库，用项目领域词汇写 PRD
AI 草拟测试 seam（优先用现有 seam，越少越好，理想是 1 个）
与你确认 seam 是否符合预期
按模板写 PRD，发布到 Issue Tracker，打 ready-for-agent 标签

PRD 结构：

章节	内容
Problem Statement	用户视角的问题
Solution	用户视角的解决方案
User Stories	详尽编号列表：`As an <actor>, I want <feature>, so that <benefit>`
Implementation Decisions	模块、接口、架构、Schema、API 契约（不写具体文件路径）
Testing Decisions	测什么行为、哪些模块、参考现有测试风格
Out of Scope	明确不做的事
Further Notes	其他补充

我的检查清单：

User Stories 是否覆盖了所有功能面？
Implementation Decisions 里没有过时的文件路径？
Testing Decisions 里的 seam 是我认可的测试切入点？
Out of Scope 和 Grill 阶段的决策一致？

注意：PRD 发布到 GitLab Issues（本项目用 glab CLI，见 docs/agents/issue-tracker.md）。

Step 3：`/to-issues` — 垂直切片拆任务

做什么：把 PRD/计划拆成可独立抓取的 Issue，每个 Issue 是一个 tracer bullet（垂直切片）。

输入：同一会话中的 PRD，或指定 issue 编号/URL

核心原则：垂直切片，不要水平分层

❌ 错误（水平切片）          ✅ 正确（垂直切片）
Issue 1: 写 Schema           Issue 1: 用户能创建项目（Schema + API + 测试）
Issue 2: 写 API              Issue 2: 用户能添加任务到项目
Issue 3: 写前端              Issue 3: 用户能在看板拖拽任务
Issue 4: 写测试

每个 slice：

穿过所有集成层（schema → API → 业务逻辑 → 测试）
完成后可独立 demo 或验证
如有 prefactor 需求，单独作为第一个 slice

过程要点：

AI 草拟 breakdown，列出每个 slice 的：
- Title
- Blocked by（依赖关系）
- User stories covered
Quiz 你：粒度对不对？依赖对不对？要不要合并/拆分？
迭代直到你 approve
按依赖顺序发布 Issue（blocker 先发），打 ready-for-agent

Issue 模板：

## What to build
端到端行为描述（不是逐层实现说明）

## Acceptance criteria
- [ ] 可验证条件 1
- [ ] 可验证条件 2

## Blocked by
- #123 或 None - can start immediately

我的检查清单：

每个 Issue 能独立验收吗？
依赖关系正确吗？（不会 circular block）
第一个 Issue 是 prefactor 吗？（如需要）
Issue 粒度：一个会话能做完吗？（太大就拆，太小就合并）
父 Issue（PRD）没有被关闭或修改？

Phase 0 结束标志：Issue 列表发布完毕，你可以从「无 blocker 的 Issue」开始执行。

三、Phase 1：实现（Sonnet 4.6 · 每 Issue 新会话）

目标：每个 Issue 在干净上下文中实现、自测通过、提交代码。审查不在此阶段做。

为什么要「一 Issue 一会话」？

好处	说明
上下文干净	不会混入上一个 Issue 的残留讨论
成本可控	Sonnet 消费低，短会话比长会话更省
失败隔离	一个 Issue 跑偏，不影响其他
可追溯	会话 ↔ Issue ↔ Commit 一一对应

Step 4：`/implement` — 实现

做什么：根据 Issue 或 PRD 描述实现代码。

操作：

切换模型 → Sonnet 4.6
新开 Cursor Agent 会话
附上 Issue 链接或编号
调用 /implement

Implement 内置行为（skill 定义）：

在 PRD 预定义的 seam 处使用 /tdd（先测后写，垂直 RED→GREEN）
定期跑 typecheck、单测文件
全部完成后跑完整测试套件
提交到当前分支

注意：Implement 完成后不要在同一会话里自审。进入 Phase 2，切换其他 AI 做 /review。

我的操作习惯：

新会话 · Sonnet 4.6

/implement

请实现 GitLab Issue #I-14：pgvector ANN 查询优化
Issue 链接：https://gitlab.xxx/issues/14
当前分支：feat/I-14-pgvector-ann

分支策略（参考 scm-rec-py）：

1 2	lmy/v1-mvp（集成线） └── feat/I-xx-简述（单 Issue 短分支）

我的检查清单：

当前在正确的 feat 分支上？
Issue 的 Acceptance Criteria 逐条满足？
/tdd 在预定义 seam 上用了吗？
测试全绿？
代码已 commit，准备进入审查？

四、Phase 2：审查（AI 审查 + 人工审查）

目标：两道门都过才提 MR——AI 交叉验证 + 人工兜底，避免代码对我完全不可控。

审查分工：AI 审什么，人审什么

维度	AI 审查（`/review`）	人工审查（我自己）
编码规范	✅ 对照 CODING_STANDARDS	扫一眼风格是否顺眼
Spec 对齐	✅ 对照 Issue/PRD 逐条核验	✅ 确认「做的是我要的」
scope creep	✅ 发现多做/少做	✅ 有没有「顺手改」我不想要的
业务逻辑	部分（靠 spec 描述）	✅ 领域经验判断对不对
并发/性能/资源	容易漏	✅ 高并发、OOM、热点 key 等运行时坑
安全/权限/敏感数据	容易漏	✅ 鉴权、密钥、日志脱敏、危险命令
可维护性	部分	✅ 我能不能看懂、以后能不能改
部署/配置影响	容易漏	✅ 环境变量、Nacos、启动项变化
测试是否真验到了	看有没有测试	✅ 测试是否覆盖关键场景（如压测）

AI 审查是「自动化质检」；人工审查是「负责人签字」——两道都过才能 merge。

为什么要换 AI + 还要人工？

风险	只有 implement AI 自审	只有 AI 审查	AI 审查 + 人工审查
实现偏见	高	低	低
审查 AI 漏检	—	有	人工兜底
代码不可控	高	中	低——人必须看懂 diff
业务/运行时 bug	高	中	低——人凭领域经验拦截

Step 5：`/review` — AI 双轴审查

操作：

切换 AI（见上方选型表，必须和 implement 不同）
新开一个会话（不要复用 implement 会话）
只提供审查所需的最小上下文：
- Issue 链接 / PRD 路径
- 固定点（如 lmy/v1-mvp 或 merge-base）
- 命令：/review since lmy/v1-mvp（或具体 commit / 分支名）

示例触发（Opus 审查 Sonnet 的实现）：

新会话 · Opus 4.8（或 Codex / Claude Code）

/review since lmy/v1-mvp

审查 feat/I-14-pgvector-ann 分支上的改动。
Spec 来源：GitLab Issue #I-14

做什么：从固定点审查 diff，Standards + Spec 两个维度并行：

轴	审查什么
Standards	是否符合仓库编码规范（CODING_STANDARDS、CONTRIBUTING 等）
Spec	是否忠实实现了 Issue/PRD 的要求（不多不少）

典型结论组合：

Standards ✅ + Spec ✅ → 进入 Step 6 人工审查
Standards ✅ + Spec ❌ → 回 Phase 1 修
Standards ❌ + Spec ✅ → 回 Phase 1 修

AI 审查发现问题后的处理：

回到 Sonnet 4.6 · 新会话修代码
修完 commit → 重新 AI 审查 → 再进入人工审查

AI 审查检查清单：

审查 AI 和实现 AI 不是同一个？
审查会话里没有 implement 过程的历史？
Spec 来源（Issue / PRD）已提供给审查 AI？
Standards + Spec 两轴都 OK？

Step 6：人工审查 — 兜底签字

什么时候做：AI 审查两轴都通过之后，提 MR 之前。

怎么做（建议 15–30 分钟，视 diff 大小）：

# 1. 看完整 diff
git diff lmy/v1-mvp...HEAD

# 2. 对照 Issue Acceptance Criteria 逐条勾选
# 3. 重点文件逐段读，确保「我看得懂、我敢 merge」

人工审查重点（按优先级）：

我是否理解每一行关键改动？
看不懂的 → 要么让 AI 解释，要么要求重写，禁止「AI 写的应该没问题」式 merge
业务/领域是否正确？
例如：秒杀扣库存有没有超卖风险、推荐链路降级顺序对不对
运行时会不会炸？
内存、连接池、并发、超时、重试、幂等
有没有动到我不期望的地方？
顺手 refactor、改配置、删日志、动其他模块
测试真的验到了吗？
不能只有 happy path；关键边界、失败路径有没有覆盖
上线后我能不能排障？
日志够不够、错误信息清不清楚、开关能不能回滚

人工审查结论：

结论	动作
✅ 通过	提 MR
⚠️ 有小疑问但可接受	在 MR 描述里记一笔，或补一条 follow-up Issue
❌ 不通过	回 Phase 1 修，或新开会话让 AI 按我的反馈改

人工审查检查清单：

diff 全看过一遍（至少所有非测试的关键文件）？
Issue Acceptance Criteria 逐条确认？
关键业务逻辑我理解且认可？
并发/性能/安全敏感点检查过？
测试覆盖我关心的场景？
我敢为这个 merge 负责？

Step 7：MR + Issue 闭环

前提：AI 审查 ✅ 且人工审查 ✅

Commit（Phase 1 完成时）：

/implement 完成后 commit 到 feat 分支
commit message 引用 Issue 编号（如 feat: pgvector ANN query (#I-14)）

MR（AI 审查 + 人工审查都通过后）：

从 feat/I-xx → lmy/v1-mvp（或项目集成线）
如果单个 Issue 改动过大，用 /split-to-prs 拆成多个小 MR（先出方案，你 approve 后再执行）

Issue 闭环：

1	glab issue close <issue-id>

五、Skill 速查表

阶段	Skill	AI / 模型	触发	产出
压力测试	`/grill-with-docs`	Opus 4.8	大需求启动	决策纪要 + CONTEXT/ADR
写 PRD	`/to-prd`	Opus 4.8	Grill 完成后	PRD Issue
拆任务	`/to-issues`	Opus 4.8	PRD 完成后	多个垂直切片 Issue
实现	`/implement`	Sonnet 4.6	每 Issue 新会话	代码 + 测试 + commit
测试驱动	`/tdd`	Sonnet 4.6	implement 内	行为测试
AI 审查	`/review`	其他 AI（Opus / Codex / Claude Code）	implement 后 · 新会话	Standards + Spec 报告
人工审查	—	我自己	AI 审查通过后 · 提 MR 前	签字确认，代码可控
拆 MR	`/split-to-prs`	Sonnet 4.6	改动过大时	多个小 MR 方案
调试	`/diagnosing-bugs`	按需	测试失败/回归	诊断报告
领域建模	`/domain-modeling`	Opus 4.8	grill 内自动	CONTEXT/ADR
架构设计	`/codebase-design`	Opus 4.8	需要定 seam 时	接口/seam 方案

六、与小需求流程的对比

	大需求	小需求
起点	`/grill-with-docs`	直接描述需求
文档	PRD + Issues	无 / 口头
实现 AI	Sonnet 4.6	Sonnet 一把梭
审查	AI 审查 + 人工审查	改动大时至少人工过 diff
会话	规划 1 + 实现 1 + AI 审查 1 + 人工审查（每 Issue）	通常 1 会话
验收	AI `/review` + 人工签字	手动看一眼
适用	跨模块改造、新功能、架构变更	Bug fix、小改动、探索性原型

七、实践原则

1. 规划阶段不要省

前面一行代码都没写，全在规划——理清楚了，implement 才是一次跑通。Grill + PRD + Issues 对应 Spec Coding 的 specify → plan → tasks；/speckit-specify 强调需求阶段零技术词，我的 /grill-with-docs 更重读代码库和写 ADR，但「先对齐再写码」是同一件事。

Opus 一个 Grill 会话的 token 成本，通常远低于 implement 完发现方向错了的返工。

2. 人的价值在「懂行」

AI 负责 ~80% 执行决策（怎么写）
人负责 ~70% 规划决策（做什么、约束是什么）
Prompt 质量 = 领域专业度，不是语法能力

3. 垂直切片 > 水平分层

每个 Issue 端到端可验证
/tdd 也在垂直 slice 内 RED→GREEN，不要先写完全部测试

4. 重要规则落文件

项目规范 → CLAUDE.md / AGENTS.md
架构决策 → docs/adr/
领域词汇 → CONTEXT.md
不要只在对话里说，压缩上下文后会丢

5. AI 审查 + 人工审查，两道门

Implement 和 AI Review 必须不同会话、不同 AI
AI 审查通过后，人工必须过 diff——不能 AI 说 OK 就 merge
人工审查的核心问题：「我看得懂吗？我敢负责吗？」
看不懂 → 让 AI 解释或重写，禁止盲 merge

6. 会话管理

场景	做法
换 Issue	新开会话
换阶段	规划 Opus → 实现 Sonnet → AI 审查 → 人工审查
AI 审查	新开会话，不带 implement 历史
人工审查	自己看 diff，不依赖 AI 会话
上下文太长	不要 `/compact` 后继续 implement，开新会话
一个 Issue 做不完	拆 Issue，不要硬撑一个会话

一 Issue 一会话还有一层原因：Skills 压缩后按预算重注入，最早触发的先被踢——规划、implement、review 挤一个会话里，后半段容易「选择性失忆」。

7. 配置层：Skills 承载流程，CLAUDE.md 只放事实

内容	放哪	例子
构建命令、技术栈、目录	CLAUDE.md / AGENTS.md	`uv run pytest`、Nacos 约定
工作流 SOP	Skills	`/grill-with-docs`、`/implement`、`/review`
路径级规范	`.claude/rules/` + paths	API 层 Zod 校验
格式化 / 危险命令拦截	Hooks（待配）	PostToolUse Prettier、PreToolUse 拦删 migration

流程写进 CLAUDE.md = 每次说「你好」也带着 deploy runbook；我的 Skills 就是 Spec Coding 工序的代码化。

八、Checklist 模板

大需求启动前

需求足够大，值得走完整流程？（否则直接 implement）
当前分支策略清楚？
Issue Tracker 可用（glab auth OK）？

Phase 0 完成

Grill 决策纪要确认
PRD 发布，seam 确认
Issues 发布，breakdown approve
切换 Sonnet 4.6

每个 Issue · Phase 1 实现完成

Sonnet 4.6 · 新会话 + /implement
Acceptance Criteria 全满足
测试全绿，代码已 commit

每个 Issue · Phase 2 AI 审查完成

切换其他 AI · 新会话 + /review
Standards + Spec 两轴通过
有问题则回 Sonnet 修完 → 再 AI 复审

每个 Issue · Phase 2 人工审查完成

git diff 全看过，关键文件逐段理解
Acceptance Criteria 逐条人工确认
业务逻辑 / 并发 / 安全敏感点检查过
我敢为这个 merge 负责
MR 提交 + Issue close

全部 Issue 完成

集成线（如 lmy/v1-mvp）测试通过
需要时 /split-to-prs 整理 MR
更新 CONTEXT.md / ADR（如有新决策）

九、示例：一次完整大需求

以 scm-rec-py v1 MVP 改造为例：

1. [Opus 4.8 · Cursor · 会话 A] 规划
   /grill-with-docs → v1 范围、验收标准、分支策略定稿
   /to-prd          → Epic PRD 发布到 GitLab
   /to-issues       → I-10 ONNX、I-11 OOM、I-12 索引性能… 

2. [Sonnet 4.6 · Cursor · 会话 B] feat/I-10-onnx · 实现
   /implement #I-10 → 测试全绿 → commit

3. [Opus 4.8 · Cursor · 会话 C] feat/I-10-onnx · AI 审查
   /review since lmy/v1-mvp → Standards ✅ Spec ✅

4. [我 · 人工] feat/I-10-onnx · 人工审查
   git diff 过一遍 → 业务/并发/测试确认 → ✅ 签字

5. 提 MR → merge → close #I-10

6. [Sonnet · 会话 D] feat/I-11-oom · 实现
   /implement #I-11 → commit

7. [其他 AI · 会话 E] · AI 审查 → [我 · 人工审查] → MR → close

8. … 逐个 Issue：实现 → AI 审查 → 人工审查 …

9. 全部完成后 lmy/v1-mvp 集成验收

十、还没做好的 / 待改进

项	现状	计划
Hooks	格式化、lint 还靠 CLAUDE.md 建议	PostToolUse format + PreToolUse 危险命令拦截
CLAUDE.md 审计	部分 repo 可能超标、混入了流程	流程迁 Skills，200 行内 + 索引
spec-kit 对比	用自定义 Skills，未跑过官方 spec-kit	挑一个 demo 项目 A/B 对比
Stop Hook 验证	靠 implement 内跑测试	考虑 Stop hook 做确定性 gate（待验证 ROI）
审查 DeepSeek 初筛	省 token 但漏检过	仅小改动用，大改动 Opus/Codex

最后更新：2026-07-03 · 和桌面其他「个人总结」配套使用

我的 AI 编程工作流

这套流程在解决什么

配套个人总结（桌面同目录）

一、总览

需求分流

全流程一览

模型 / AI 选型原则

二、Phase 0：规划（Opus 4.8 · 单会话）

Step 1：/grill-with-docs — 压力测试 + 沉淀决策

Step 2：/to-prd — 合成 PRD

Step 3：/to-issues — 垂直切片拆任务

三、Phase 1：实现（Sonnet 4.6 · 每 Issue 新会话）

为什么要「一 Issue 一会话」？

Step 4：/implement — 实现

四、Phase 2：审查（AI 审查 + 人工审查）

审查分工：AI 审什么，人审什么

为什么要换 AI + 还要人工？

Step 5：/review — AI 双轴审查

Step 6：人工审查 — 兜底签字

Step 7：MR + Issue 闭环

五、Skill 速查表

六、与小需求流程的对比

七、实践原则

1. 规划阶段不要省

2. 人的价值在「懂行」

3. 垂直切片 > 水平分层

4. 重要规则落文件

5. AI 审查 + 人工审查，两道门

6. 会话管理

7. 配置层：Skills 承载流程，CLAUDE.md 只放事实

八、Checklist 模板

大需求启动前

Phase 0 完成

每个 Issue · Phase 1 实现完成

每个 Issue · Phase 2 AI 审查完成

每个 Issue · Phase 2 人工审查完成

全部 Issue 完成

九、示例：一次完整大需求

十、还没做好的 / 待改进

Step 1：`/grill-with-docs` — 压力测试 + 沉淀决策

Step 2：`/to-prd` — 合成 PRD

Step 3：`/to-issues` — 垂直切片拆任务

Step 4：`/implement` — 实现

Step 5：`/review` — AI 双轴审查