RainFly
明确一个目标，这很重要！
-
SDD 规范驱动开发 + Spec Kit 实战全解 SDD 规范驱动开发 + Spec Kit 实战全解 一、为什么需要 SDD AI 编程目前的主流方式是 Vibe Coding（氛围编程）——给 AI 一段提示词，AI 直接生成代码。这种方式看起来快，但实际上存在根本性问题： 问题 表现 起点模糊 需求藏在脑子里，AI 拿到的是"大概意思"而非精确描述 过程黑箱 AI 一次性生成，无法干预中间方向 结果不可预测 返工频繁，代码与预期常常偏离 迭代成本高 需求变了基本靠重写 不可追溯 为什么这么写？不知道 SDD 的诞生，就是为了解决这些问题。 二、SDD 是什么 SDD（Spec-Driven Development，规范驱动开发）——先定义清楚要做什么（What）、为什么做（Why），再让 AI 基于结构化规范去生成代码，而不是直接丢一段提示词给 AI。 2.1 与其他开发范式的关系 范式 全称 核心关注 回答的问题 DDD 领域驱动开发 业务建模与系统边界 业务是什么？ BDD 行为驱动开发 业务验收与共同理解 如何验证？ TDD 测试驱动开发 代码正确性 如何保证质量？ SDD 规范驱动开发 人定义意图，AI 执行 如何控制 AI？ 这四种范式是层级递进关系，不是替代关系。SDD 站在最顶端，负责把 DDD 的业务模型、BDD 的行为验收整理成 AI 可以精确执行的结构化规范。 2.2 SDD 的哲学 意图是唯一的真理。 规范不是代码的附属品，而是驱动一切实现的源头。 过去 现在（SDD） 文档 = 代码的附属品 代码 = 规范的产物 技术文档 = 参考 规范文档 = 产出代码的精准定义 代码是核心 规范是核心 三、SDD 的 8 步核心流程 ① Constitution ② Specify ③ Clarify（可选） 定团队原则 编写功能规范 澄清模糊需求 ④ Plan ⑤ Checklist（可选） ⑥ Tasks 制定技术计划 生成验收清单 分解任务列表 ⑦ Analyze（可选） ⑧ Implement 一致性分析 执行实现 人类负责：掌舵（定义 What & Why） AI 负责：划桨（基于规范执行 How） 第一步：Constitution — 团队宪法 做什么：建立项目核心价值观、不可违反的原则、标准、质量门槛。 原则核心：只写可执行的约束，不写模糊的理想。 ❌ 模糊理想 → ✅ 可执行约束 模糊理想 可执行约束 写高质量代码 所有函数必须有 JSDoc 注释；所有 API 必须有输入校验 schema 注重性能 列表组件数据超过 100 条时，必须使用虚拟滚动 保证安全 所有 SQL 查询必须使用参数化查询，禁止字符串拼接 代码要可维护 每个函数不超过 50 行，禁止嵌套超过 3 层 产物：.specify/memory/constitution.md 审核重点：原则是否可验证、可执行；AI 后续行为是否足够可控。 第二步：Specify — 编写功能规范 做什么：定义 What（做什么）和 Why（为什么做），专注需求本身，完全不解耦技术实现。 产物：specs/001-功能名/spec.md 规范文档标准结构： 项目概述 用户故事 功能需求 非功能需求（性能、安全、可扩展性） 验收标准（每个标准必须可验证） 约束条件 审核重点（第二个检查点）： 功能是否完整无遗漏？ 优先级是否清晰（MVP vs 后期迭代）？ 边界条件和异常情况是否被考虑？ 验收标准是否足够清晰可验证？ 第三步：Clarify — 澄清需求（可选但强烈推荐） 做什么：让 AI 审视 spec.md 中模糊或未定义的地方，以 Q&A 形式向用户确认。 价值： 在写代码之前就把模糊需求全部确定 强迫开发者在动手前深度思考需求 大幅减少实现阶段的返工 典型 Q&A 场景： "这个功能的并发用户量级是多少？100 还是 10,000？" "如果 AI 生成的内容为空，系统的降级策略是什么？" "移动端的交互和 PC 端是否完全一致？" 第四步：Plan — 制定技术计划 做什么：定义 How（怎么做），提供高层技术方向，不提供具体实现细节。 关键：Plan 阶段才涉及技术选型，Specify 阶段完全不要考虑技术问题。 产物：specs/001-功能名/plan.md 包含：架构总览、目录结构、数据模型、API 契约、模块划分等 审核重点（技术决策关键节点）： 目录结构是否合理、符合团队习惯？ 数据库表设计是否合理、外键关系是否正确？ API 端点是否完整、风格是否一致？ 组件拆分粒度是否合适？ 技术方案是否有不必要的复杂度？ 第五步：Tasks — 分解任务 做什么：将技术计划转换为 AI 可逐个执行的原子化工作项。 产物：specs/001-功能名/tasks.md 结构： Phase 1 T001 - 可并行任务 T002 - 可并行任务 T003 - 依赖 T001 完成 Phase 2 ... 标记 的任务 = 可并行执行，这是 Spec Kit 提升开发速度的核心机制。 审核重点： 依赖关系是否合理，有无循环依赖？ 任务粒度是否足够小，能否在单次 AI 交互中完成？ 需求映射是否完整，每个任务能否追溯到具体需求？ Phase 划分是否合理？ 第六步：Analyze — 一致性分析（可选但推荐） 做什么：对比 spec.md、plan.md、tasks.md 三者之间的一致性，找出潜在遗漏或矛盾点。 产物：一致性分析报告 检查项 说明 覆盖率 每个需求是否都有对应任务？ 一致性 spec 和 plan 之间是否有矛盾？ 完整性 tasks 是否完整覆盖 plan？ 边界条件 异常流程是否被覆盖？ 价值：在动手写代码之前发现文档间的不一致，避免实现阶段大规模返工。 第七步：Implement — 执行实现 做什么：按任务列表顺序执行，生成代码、测试、文档。 AI 在 Implement 阶段会执行 5 件事： 读取所有文档（spec、plan、tasks） 按顺序和依赖关系逐个执行任务 为每个任务生成代码、测试、文档 在 tasks.md 中标记已完成的任务 确保合规 关键节点检查（人类必须介入的三个时机）： 时机 检查内容 Phase 完成后 运行项目，确保基本功能正常 任意时刻 运行单元测试，确保覆盖率达标 全程 审查关键代码文件，确认风格和架构符合预期 如果 AI 生成的代码有问题——不要直接改代码，而是回到 spec.md 或 plan.md 修正规范，再重新 Implement。这是 SDD 的核心优势：系统性修正，而非打补丁。 四、Spec Kit 安装与使用 环境准备 # 1. 安装 UV（包管理器） powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex" # 验证安装 uv --version # 2. 用 UV 安装 Spec Kit uv tool install specify-cli --from git+https://github.com/github/spec-kit.git # 验证安装 specify --help specify check 初始化项目 # 创建独立项目 specify init my-feature --ai claude --script ps # 在当前目录初始化（不创建子目录） specify init --here --force --ai claude --script ps ⚠️ 前提：项目必须已初始化 Git 仓库（git init） 项目初始化后自动生成的目录结构 项目名/ ├── .claude/commands/ # Claude Code 斜杠命令（/speckit.*） ├── .specify/ │ ├── memory/ │ │ └── constitution.md # 团队宪法 │ ├── scripts/ # 辅助脚本 │ └── templates/ # 文档模板 └── specs/ # 功能规范（按编号管理） └── 001-功能名/ ├── spec.md # 功能规范 ├── plan.md # 技术计划 ├── tasks.md # 任务列表 ├── data-model.md # 数据模型 ├── quickstart.md # 快速启动 └── research.md # 研究文档 五、Spec Kit 适用场景判断 场景 推荐方式 快速原型 / 小脚本 / 一次性需求 Vibe Coding（普通 AI Coding） 中大型项目 / 团队协作 / 长期维护 SDD + Spec Kit Bug 修复 Cursor（项目索引 RAG 定位更精准） 一个简单的判断标准：如果项目复杂到在写代码之前就需要考虑架构和数据模型，就值得用 SDD。 六、进阶技巧与最佳实践 1. 规范力度控制（大型项目） 按功能拆分规范，而非把所有功能写在一个巨大的 spec.md 里。 specs/ ├── 001-auth/ # 认证功能，独立走完完整流程 ├── 002-blog-post/ # 博客文章功能 ├── 003-comment/ # 评论功能 └── 004-search/ # 搜索功能 好处： AI 上下文窗口不会被撑爆 每个功能可独立验收 出问题更容易定位根因 2. 迭代开发模式 添加新功能 ≠ 修改旧规范，而是回到 /speckit.specify，Spec Kit 会自动创建新的编号目录（003-新功能），不影响已有功能规范。 3. 用 Checklist 做规范级"单元测试" /speckit.checklist 生成验收清单，相当于给规范做一次完整性检查，确保每个需求都有对应实现。 4. 修改顺序：规范 → 代码 AI 生成的代码不符合预期时： ❌ 直接改代码（打补丁，下次可能又被覆盖） ✅ 回到 spec.md / plan.md 修正规范，重新 Implement（系统性修正） 5. .specify 目录必须提交 Git .specify/ 是项目的重要资产，包含团队的规范和决策上下文，必须版本控制，确保： 团队所有人访问一致的上下文 新加入的 AI 也能获得完整背景 七、常见问题解答 Q1：Spec Kit 只能和 Claude Code 一起用？ 不是。Spec Kit 支持 Copilot、Claude Code、Gemini CLI、Cursor 等多种 AI 编程工具。同样，Claude Code 也不只能用 Spec Kit，也可以配合 OpenSpec 等其他 SDD 工具。 Q2：小型项目用 SDD 是否过于复杂？ 是。SDD 更适合中大型项目。如果复杂到需要先考虑架构和数据模型，就值得用 SDD。简单到几个小时能做完的小脚本，直接 Vibe Coding 更高效。 Q3：规范文件是否需要手动维护？ 可以直接编辑 markdown 文件，但更推荐通过 Claude Code 修改——AI 会确保修改后的文档和其他文件保持一致，避免手动编辑引入的不一致。 Q4：一次 Implement 没跑完所有任务怎么办？ 完全正常。可用 /speckit.implement 继续，或者用提示词指定实现某个 Phase 的任务： 继续完成 Phase 2 的剩余任务 Q5：如何更新模板？ specify init --here --force 加上 --force 会更新模板和命令文件，但不会覆盖已有的 specs/ 目录和源代码。 八、核心总结 SDD 的本质 把软件开发从"直接写代码"转换为"先定义意图，再生成代码"。规范是源头，代码是产物。 人类 vs AI 的分工 角色 职责 人类（掌舵者） 定义意图、审核产出、做最终决策 AI（执行者） 在每个阶段忠实地执行人类意图 完整实践路径 安装环境 ↓ 初始化项目（specify init） ↓ 定义原则（/speckit.constitution） ← 第一个检查点 ↓ 编写规范（/speckit.specify） ← 第二个检查点 ↓ 澄清规范（/speckit.clarify） ← 可选，推荐做 ↓ 制定计划（/speckit.plan） ← 第三个检查点 ↓ 生成任务（/speckit.tasks） ← 第四个检查点 ↓ 一致性分析（/speckit.analyze） ← 可选，推荐做 ↓ 执行实现（/speckit.implement） ← 最终验收 SDD 的核心价值 维度 提升 可控性 每个阶段都有检查点，方向始终可干预 可追溯性 每步都有文档记录，决策有据可查 迭代成本 修改规范即可重新生成代码，无需重写 团队协作 规范作为共同语言，减少沟通偏差 AI 使用质量 从"开盲盒"变为"按图施工" 视频标题：告别盲盒式编程！用 SDD + Spec Kit 让 AI 按图施工｜AI 编程实战 #03 作者：NOVA 平台：Bilibili 原链接：https://www.bilibili.com/video/BV1QvwuzTEoT 字幕字符数：8,318 字 内容深度：★★★★★ 整理依据：Bilibili 视频字幕原文（8,318 字），视频作者 NOVA，AI 编程实战系列第 3 期 -
让 Claude Code 一直干下去 让 Claude Code 一直干下去 三种方案，按安全性从高到低排列 方案一：Auto Mode（推荐） Auto Mode 是介于"每次手动审批"和"完全跳过权限"之间的中间路线。在每个工具调用执行前，分类器会自动审查是否安全，安全的操作自动放行，危险的操作被拦截。 # 启动时开启 claude --enable-auto-mode # 启动后用 Shift+Tab 循环切换模式 # 默认模式 → 自动接受编辑 → Auto Mode → 计划模式 # 非交互模式 claude -p "重构认证模块" --permission-mode auto 安全机制： 如果一个会话中连续触发 3 次拦截，或累计触发 20 次，系统会暂停并重新要求人工确认。 方案二：--dangerously-skip-permissions（YOLO 模式） 完全跳过所有权限提示，Claude 不间断工作直到任务完成。仅推荐在隔离的容器/沙箱环境中使用。 # 基础用法 claude --dangerously-skip-permissions "实现支付功能" # 配合预算限制（防止费用失控） claude --dangerously-skip-permissions --max-budget-usd 5.00 "大规模重构" # 配合命名会话（事后可恢复） claude --dangerously-skip-permissions -n "refactor-sprint" "继续重构" # 非交互流水线模式 claude -p --dangerously-skip-permissions "生成报告" ⚠️ 警告： 有真实生产凭证、SSH key、数据库连接的机器上不要用。 方案三：精细配置 allowedTools 不想完全放权，只对特定操作免审批： # 只允许特定命令免审批 claude --allowedTools "Bash(git *),Bash(npm *),Read,Write" 在 settings.json 中永久配置： // ~/.claude/settings.json { "permissions": { "allowedTools": , "deny": } } 模式对比 模式 自主程度 安全性 适合场景 默认模式 低（每步确认） 最高 敏感操作、生产环境 Auto Mode 高（分类器把关） 较高 日常长任务开发 allowedTools 中（精细控制） 高 指定范围自动化 --dangerously-skip-permissions 最高（无限制） 低 隔离容器/CI 实战组合技 # 先用 Plan Mode 规划，再切换到 Auto Mode 执行 # 1. 启动时进入计划模式（只读，不执行） claude --enable-auto-mode # Shift+Tab 切到 Plan Mode → 让 Claude 分析和规划 # 确认计划后 → Shift+Tab 切到 Auto Mode → 开始执行 # 配合预算上限 + 命名会话，安全地跑长任务 claude --dangerously-skip-permissions \ --max-budget-usd 10.00 \ -n "big-refactor" \ "按照 CLAUDE.md 的规范，完整重构 src/ 目录下所有组件" 核心建议 跑大任务前先 git commit 一次，留好退路。出了问题 git reset 救场。 -
Claude Code 常用命令大全 Claude Code 常用命令大全 整理版本：2026年4月 | 适用：Claude Code CLI & IDE 插件 目录 基础会话命令 文件与上下文管理 代码操作命令 Git 集成命令 项目与任务管理 MCP 服务器命令 配置与权限命令 /loop 软件开发检测命令 /loop 项目构建全套检查命令 一、基础会话命令 命令 说明 claude 启动交互式 REPL 会话 claude "你的问题" 非交互式单次查询 claude -p "提示词" 使用 -p 指定 prompt 直接运行 claude --model claude-sonnet-4-20250514 指定模型版本 claude --version 查看当前版本 claude --help 显示帮助信息 /exit 或 /quit 退出当前会话 /clear 清除当前对话上下文 /reset 重置会话状态 /help 显示可用命令列表 二、文件与上下文管理 命令 说明 @文件路径 将文件内容注入到上下文（如 @src/main.py） @目录/ 将整个目录结构注入上下文 /add 文件路径 添加文件到当前会话上下文 /context 查看当前上下文中已加载的文件列表 /context clear 清空上下文文件 /read 文件路径 读取并显示文件内容 cat 文件 \| claude -p "分析这个" 通过管道传入文件内容 claude < input.txt 从标准输入读取内容 三、代码操作命令 命令 说明 /edit 文件路径 打开文件进行编辑 /diff 查看当前会话中的代码变更 diff /apply 应用 Claude 生成的代码变更 /revert 撤销最近一次代码变更 /run 命令 在 shell 中执行命令并将结果返回给 Claude /test 运行项目测试（自动检测测试框架） /lint 运行代码静态分析 /format 格式化代码文件 /fix 让 Claude 自动修复检测到的错误 /explain 解释选中或当前文件的代码逻辑 /review 对当前代码进行 Code Review /refactor 重构指定代码段 /optimize 对代码进行性能优化建议 四、Git 集成命令 命令 说明 /git status 查看 Git 状态 /git diff 查看未提交变更 /git log 查看提交历史 /git commit -m "msg" 提交变更（Claude 可辅助生成 commit message） /git pr 创建或查看 Pull Request 描述 /commit 让 Claude 自动生成并执行 commit（含 message） /pr-description 自动生成 PR 描述文本 /changelog 基于 git log 生成变更日志 五、项目与任务管理 命令 说明 /init 初始化项目，生成 CLAUDE.md 配置文件 /project 查看当前项目信息 /todo 显示或管理待办任务列表 /todo add "任务描述" 新增一个任务 /todo done 编号 标记任务为完成 /plan "目标" 让 Claude 输出完成目标的步骤计划 /architect "描述" 生成系统架构设计方案 /docs 生成或更新项目文档 /readme 自动生成或更新 README.md 六、MCP 服务器命令 命令 说明 claude mcp list 列出所有已配置的 MCP 服务器 claude mcp add 名称 命令 添加新的 MCP 服务器 claude mcp remove 名称 移除指定 MCP 服务器 claude mcp get 名称 查看指定 MCP 服务器详情 claude mcp add-json 名称 '{"type":"stdio",...}' 以 JSON 格式添加 MCP 服务器 claude mcp add --scope user 添加用户级别的 MCP 服务器 claude mcp add --scope project 添加项目级别的 MCP 服务器 claude mcp serve 将 Claude Code 作为 MCP 服务器启动 七、配置与权限命令 命令 说明 claude config list 查看所有配置项 claude config get 键名 获取指定配置值 claude config set 键名 值 设置配置项 claude config set model claude-sonnet-4-20250514 设置默认模型 claude --allowedTools "Bash,Read,Write" 限制允许使用的工具 claude --disallowedTools "Bash" 禁用指定工具 claude --permission-mode auto 设置权限模式为自动 claude --permission-mode ask 每次操作前询问权限（默认） claude --permission-mode bypass 跳过权限询问（谨慎使用） /permissions 查看当前会话的权限设置 八、/loop 软件开发检测命令 /loop 是 Claude Code 的自主循环执行模式，适合持续检测、自动修复、CI 集成等场景。 以下为软件开发场景下的实用 /loop 检测指令集合。 🔍 代码质量检测 # 持续监控并修复 lint 错误 /loop "运行 eslint . --fix，修复所有报错，循环直到 0 错误" # 循环检测 TypeScript 类型错误 /loop "运行 tsc --noEmit，分析类型错误，逐一修复，直到编译通过" # 检测并修复 Python 代码规范 /loop "运行 flake8 . 和 black --check .，自动格式化并修复，直到无警告" # 循环检测代码复杂度 /loop "使用 radon cc . 分析圈复杂度，对复杂度超过 10 的函数进行重构简化" 🧪 测试自动化检测 # 循环运行测试直到全部通过 /loop "运行 npm test，分析失败用例，修复对应代码，直到所有测试绿灯" # 持续检测测试覆盖率 /loop "运行 pytest --cov=. --cov-report=term，分析未覆盖代码，补充单元测试，直到覆盖率 >= 80%" # 循环检测并修复集成测试 /loop "运行 npm run test:integration，失败时分析日志，逐步修复，直到全部通过" # E2E 测试监控循环 /loop "运行 playwright test，失败时截图分析，修复页面逻辑，直到所有场景通过" 🔒 安全漏洞检测 # 循环扫描依赖漏洞 /loop "运行 npm audit，分析高危漏洞，升级或替换危险依赖，直到无高危警告" # Python 依赖安全扫描 /loop "运行 safety check，修复所有已知漏洞依赖，直到扫描通过" # 代码安全静态分析 /loop "运行 bandit -r . -ll，分析安全问题，修复高风险代码，直到无 HIGH 级别警告" # Secret 泄露检测 /loop "运行 gitleaks detect，找出泄露的密钥或 token，替换为环境变量，直到检测干净" 🏗️ 构建与编译检测 # 循环修复构建错误 /loop "运行 npm run build，分析构建错误日志，逐一修复，直到构建成功" # Docker 镜像构建检测 /loop "运行 docker build .，分析 Dockerfile 错误，修复后重新构建，直到镜像生成成功" # Gradle/Maven 构建检测 /loop "运行 ./gradlew build，分析编译失败原因，修复 Java 代码，直到构建 BUILD SUCCESS" # Go 编译检测 /loop "运行 go build ./...，修复所有编译错误，直到 go vet ./... 无任何警告" 📊 性能检测 # 循环检测 API 响应时间 /loop "运行 k6 run load_test.js，分析响应时间超标的接口，优化对应逻辑，直到 P95 < 200ms" # 数据库慢查询检测 /loop "分析 slow_query.log，找出执行时间 > 1s 的 SQL，添加索引或重写查询，直到无慢查询" # Bundle 体积检测 /loop "运行 webpack-bundle-analyzer，找出超过 500KB 的模块，进行代码分割或懒加载，直到主 bundle < 1MB" # 内存泄漏检测 /loop "运行 node --inspect app.js，使用 heap snapshot 分析内存增长，修复泄漏点，直到内存稳定" 🔄 CI/CD 流水线检测 # 循环修复 CI 失败 /loop "读取 .github/workflows/*.yml 的最新 CI 失败日志，分析原因，修复代码或配置，直到流水线全绿" # 环境变量配置检测 /loop "检查 .env.example 与代码中使用的环境变量是否一致，补全缺失变量声明，直到完全同步" # 依赖版本锁定检测 /loop "对比 package.json 与 package-lock.json，找出版本不一致项，统一锁定版本，直到无冲突" # 容器健康检测 /loop "运行 docker-compose up，检查所有服务健康状态，修复启动失败的服务，直到全部 healthy" 📝 文档与注释检测 # 循环检测缺少 JSDoc 的函数 /loop "使用 eslint --rule jsdoc/require-jsdoc 扫描，为未注释的 public 函数添加 JSDoc，直到无警告" # API 文档同步检测 /loop "对比 OpenAPI spec 与实际路由定义，补全缺失的接口文档，直到两者完全一致" # README 完整性检测 /loop "检查 README.md 是否包含安装、使用、配置、贡献指南四个章节，补全缺失内容" # 代码注释覆盖率检测 /loop "统计项目中公共函数的注释覆盖率，对未注释函数逐一添加说明，直到覆盖率 >= 90%" 🗃️ 数据库与迁移检测 # 循环检测数据库迁移文件 /loop "运行 prisma migrate status，找出 pending 迁移，分析变更是否安全，应用后验证数据完整性" # Schema 一致性检测 /loop "对比 ORM Model 定义与实际数据库表结构，修复不一致字段，直到 schema diff 为空" # 数据完整性检测 /loop "运行自定义数据校验脚本，找出孤立记录或违反约束的数据，修复或清理，直到校验通过" 九、/loop 项目构建全套检查命令 这是一套针对项目构建全生命周期的 /loop 检测命令合集，覆盖从依赖安装到上线前所有常见检查项。 按语言/框架分类，可直接复制使用。每条命令均为持续检测 + 自动修复的循环模式。 ⚡ 通用项目全套一键检查（推荐入口） # 全套项目健康检查 - 通用版（适配大多数项目） /loop " 按以下顺序对项目执行完整检查，每步失败则自动修复后继续： 1. 检查依赖安装完整性（package.json / requirements.txt 与实际安装是否一致） 2. 运行代码格式化检查并自动修复 3. 运行静态分析 / lint，修复所有错误 4. 运行类型检查，修复类型错误 5. 运行全量单元测试，修复失败用例 6. 运行构建命令，修复构建错误 7. 检查环境变量配置完整性 8. 输出最终健康报告：✅ 全部通过 / ❌ 剩余问题清单 " 🟨 JavaScript / TypeScript 项目 依赖与环境 # 依赖完整性检查 /loop "运行 npm ci，若 node_modules 与 package-lock.json 不一致则删除重装，直到 npm ci 零错误退出" # 依赖版本冲突检测 /loop "运行 npm ls 2>&1 | grep -i 'peer\|invalid\|unmet'，逐一解决版本冲突，直到输出干净" # 过时依赖检测 /loop "运行 npm outdated，分析主要依赖的 breaking change，安全升级 patch 和 minor 版本，生成升级报告" # 重复依赖检测 /loop "运行 npm dedupe && npm ls --depth=0，合并重复依赖，直到依赖树最简化" 代码质量 # ESLint 全量修复 /loop "运行 npx eslint . --ext .ts,.tsx,.js,.jsx --fix，分析无法自动修复的错误并手动修复，直到 0 errors 0 warnings" # Prettier 格式化检查 /loop "运行 npx prettier --check .，对不符合规范的文件运行 prettier --write，直到 --check 通过" # TypeScript 严格类型检查 /loop "运行 npx tsc --noEmit --strict，逐一修复类型错误（禁止使用 any 绕过），直到编译 0 错误" # 未使用导出检测 /loop "运行 npx ts-prune，分析并删除确认未使用的导出，直到无残留" # 循环依赖检测 /loop "运行 npx madge --circular --extensions ts,tsx src/，找出循环依赖并重构模块结构，直到无环" 测试 # 单元测试全通过 /loop "运行 npm test -- --watchAll=false，修复失败用例，直到全部 PASS" # 测试覆盖率达标 /loop "运行 npm test -- --coverage --watchAll=false，分析覆盖率报告，补充缺失测试，直到 lines/branches/functions 均 >= 80%" # 快照测试更新 /loop "运行 npm test -- --updateSnapshot --watchAll=false，确认快照变更合理后提交" 构建 # 生产构建检查 /loop "运行 npm run build，分析构建错误和警告，逐一修复，直到构建 0 错误 0 警告" # Next.js 全量构建检查 /loop "运行 npx next build，修复所有页面报错、缺失依赖、无效路由，直到 build 成功并输出 pages 列表" # Bundle 体积分析 /loop "运行 npx next build && npx next-bundle-analyzer，找出超过 200KB 的模块，按需拆分或懒加载，直到首屏 JS < 150KB" # Vite 构建检查 /loop "运行 npx vite build，修复 rollup 打包错误，处理动态导入警告，直到构建产物输出完整" 🐍 Python 项目 依赖与环境 # 虚拟环境依赖检查 /loop "运行 pip check，分析依赖冲突，修复版本约束，直到 No broken requirements" # requirements 同步检查 /loop "对比 pip freeze 与 requirements.txt，补全缺失依赖，移除冗余包，直到两者完全一致" # Poetry 依赖锁定检查 /loop "运行 poetry check && poetry install --sync，修复 pyproject.toml 配置错误，直到锁文件一致" 代码质量 # 全套 Python lint 检查 /loop "依次运行 flake8 . && pylint src/ && mypy .，逐层修复错误，直到三项全部通过" # Black 格式化检查 /loop "运行 black --check .，对失败文件运行 black .，直到 --check 0 files would be reformatted" # isort 导入排序检查 /loop "运行 isort --check-only .，修复导入顺序，直到 isort . --check-only 无输出" # MyPy 严格类型检查 /loop "运行 mypy . --strict，为未标注类型的函数添加类型注解，直到 0 error" # Ruff 快速 lint /loop "运行 ruff check . --fix，处理无法自动修复的规则，直到 All checks passed" 测试 # pytest 全量测试 /loop "运行 pytest -v，分析 FAILED 用例的错误堆栈，修复对应代码，直到 X passed 0 failed" # 覆盖率检查 /loop "运行 pytest --cov=src --cov-report=term-missing --cov-fail-under=80，补充缺失测试直到覆盖率达标" # 异步测试检查 /loop "运行 pytest --asyncio-mode=auto -v，修复所有 async 测试失败，直到全量通过" 构建与打包 # 包构建检查 /loop "运行 python -m build，修复 setup.py / pyproject.toml 配置，直到 dist/ 产物生成成功" # twine 发布前检查 /loop "运行 twine check dist/*，修复 metadata 错误和警告，直到 PASSED" # Docker 镜像构建 /loop "运行 docker build -t myapp:test .，修复 Dockerfile 错误，直到镜像构建成功并 docker run 健康检查通过" ☕ Java / Kotlin 项目（Maven & Gradle） # Maven 全套构建检查 /loop "运行 mvn clean verify，修复编译错误、测试失败、插件报错，直到 BUILD SUCCESS" # Gradle 全套构建检查 /loop "运行 ./gradlew clean build --warning-mode all，修复所有 deprecation 警告和错误，直到 BUILD SUCCESSFUL" # SpotBugs 静态分析 /loop "运行 mvn spotbugs:check，分析 BUG_INSTANCE 报告，修复 HIGH 优先级问题，直到无高危 bug" # Checkstyle 代码规范 /loop "运行 mvn checkstyle:check，修复所有样式违规，直到 0 violations" # JaCoCo 测试覆盖率 /loop "运行 mvn test jacoco:report，分析覆盖率报告，补充测试，直到行覆盖率 >= 80%" # 依赖安全扫描 /loop "运行 mvn dependency-check:check，升级或排除 CVE 高危依赖，直到无 CVSS >= 7.0 的漏洞" 🦀 Go 项目 # Go 全套质量检查 /loop "依次运行 go build ./... && go vet ./... && staticcheck ./...，逐一修复，直到三项 0 输出" # golangci-lint 综合检查 /loop "运行 golangci-lint run ./...，修复所有 linter 报告问题，直到 0 issues" # Go 测试全通过 /loop "运行 go test ./... -v -race，修复竞态条件和失败用例，直到 ok 输出所有包" # Go 覆盖率检查 /loop "运行 go test ./... -coverprofile=coverage.out && go tool cover -func=coverage.out | grep total，补充测试直到总覆盖率 >= 75%" # Go 模块整理 /loop "运行 go mod tidy && go mod verify，修复模块依赖问题，直到两项均 0 错误" # gosec 安全扫描 /loop "运行 gosec ./...，修复 HIGH 和 MEDIUM 安全问题，直到无高危告警" 🐳 Docker / 容器项目 # Dockerfile 最佳实践检查 /loop "运行 hadolint Dockerfile，修复所有 error 和 warning，直到 hadolint 0 issues" # docker-compose 全服务启动检查 /loop "运行 docker-compose up -d && sleep 10 && docker-compose ps，修复 unhealthy 或 exited 的服务，直到所有服务 Up (healthy)" # 镜像体积优化 /loop "运行 docker build -t app:test . && docker images app:test，若镜像 > 500MB 则优化 Dockerfile（多阶段构建、减少层数），直到体积达标" # 镜像安全扫描 /loop "运行 trivy image myapp:latest，修复或排除 CRITICAL 和 HIGH 级别 CVE，直到无 CRITICAL 漏洞" # docker-compose 配置检查 /loop "运行 docker-compose config，修复 YAML 语法错误和配置冲突，直到配置验证通过" ☸️ Kubernetes / 云原生项目 # K8s YAML 配置检查 /loop "运行 kubectl apply --dry-run=client -f k8s/，修复所有 YAML 语法错误和 API 版本问题，直到 dry-run 通过" # Helm Chart 检查 /loop "运行 helm lint ./charts/myapp && helm template ./charts/myapp，修复 Chart 错误，直到 0 error 0 warning" # kube-score 最佳实践检查 /loop "运行 kube-score score k8s/*.yaml，修复 CRITICAL 级别问题（资源限制、健康检查、安全上下文），直到无 CRITICAL" # kubeval Schema 验证 /loop "运行 kubeval k8s/*.yaml --strict，修复 Schema 不符合项，直到 PASS" # 资源配置完整性检查 /loop "检查所有 Deployment 是否配置了 resources.requests/limits、livenessProbe、readinessProbe，补全缺失配置，直到全部完整" 🌐 前端工程项目 # CSS / SCSS 检查 /loop "运行 npx stylelint '**/*.{css,scss}' --fix，修复无法自动修复的样式问题，直到 0 errors" # HTML 可访问性检查 /loop "运行 npx axe-core 对所有页面检测，修复 WCAG AA 级别的可访问性问题，直到无 violations" # 图片资源优化检查 /loop "扫描 public/assets 下图片，对超过 200KB 的 PNG/JPEG 进行压缩优化，直到所有图片 < 200KB" # 死链检测 /loop "运行 npx broken-link-checker http://localhost:3000 -ro，修复所有 404 内部链接，直到 0 broken links" # Web Vitals 检查 /loop "运行 npx lighthouse http://localhost:3000 --output=json，分析 LCP/CLS/FID 指标，优化至 Performance Score >= 90" # PWA 配置检查 /loop "运行 lighthouse --only-categories=pwa http://localhost:3000，修复 PWA 缺失配置（manifest、service worker），直到 PWA 分数 >= 90" 🗄️ 数据库项目 # 迁移文件完整性检查 /loop "运行 prisma migrate status，若有 pending 迁移则 migrate dev，验证数据完整性，直到 Database schema is up to date" # Alembic 迁移检查（Python） /loop "运行 alembic check && alembic upgrade head，修复迁移脚本错误，直到 No new upgrade operations detected" # SQL 语法检查 /loop "使用 sqlfluff lint migrations/ --dialect postgres，修复所有 SQL 风格问题，直到 0 violations" # 数据库索引覆盖检查 /loop "分析所有 ORM 查询，找出缺少索引的 WHERE 和 JOIN 字段，添加索引后运行 EXPLAIN ANALYZE 验证，直到无全表扫描" 📦 Monorepo 项目 # Turborepo 全量构建检查 /loop "运行 turbo run build lint test --force，修复各 workspace 的构建和测试错误，直到所有任务成功" # pnpm workspace 依赖检查 /loop "运行 pnpm -r install && pnpm -r run lint，修复所有工作区的依赖和 lint 错误，直到全部通过" # Nx 影响范围检查 /loop "运行 nx affected --target=test,lint,build --base=main，修复受影响模块的问题，直到 affected 任务全绿" # workspace 版本一致性检查 /loop "检查各 workspace 的公共依赖版本是否一致，统一升级到最新兼容版本，直到无版本不一致" 🔐 安全全套扫描 # 完整安全扫描流水线 /loop " 按顺序执行安全扫描： 1. npm audit --audit-level=high（或 pip-audit / cargo audit）- 修复高危依赖 2. 运行 semgrep --config=auto . - 修复代码层面安全问题 3. 运行 gitleaks detect - 清除泄露的 secrets 4. 检查 CORS、CSP、HTTPS 等 HTTP 安全头配置 5. 检查所有用户输入是否有 SQL 注入 / XSS 防护 输出安全检查报告，直到 0 CRITICAL 0 HIGH " # OWASP 依赖检查 /loop "运行 dependency-check --scan . --failOnCVSS 7，升级所有 CVSS >= 7.0 的依赖，直到检查通过" # Secrets 全量扫描 /loop "运行 trufflehog filesystem . --only-verified，找出所有泄露凭证，替换为环境变量或密钥管理服务，直到扫描无发现" 📋 上线前终极检查 Checklist Loop # 上线前完整检查（全语言通用） /loop " 执行上线前 10 项核心检查，逐项验证并修复： 依赖锁文件是否提交且最新 所有测试通过（单元 + 集成） 代码覆盖率 >= 设定阈值 无 lint 错误 / 类型错误 生产构建成功（无警告） 环境变量 .env.example 完整 数据库迁移文件已就绪 无 console.log / print 调试残留 API 接口文档与实现一致 安全扫描 0 HIGH/CRITICAL 每项输出 ✅ 通过 或 ❌ 问题描述，修复后重新验证该项 " 附录：CLAUDE.md 推荐配置模板 # CLAUDE.md ## 项目概述 ## 技术栈 - 语言：TypeScript / Python / Go - 框架：Next.js / FastAPI / Gin - 数据库：PostgreSQL / Redis ## 常用命令 - 启动开发服务器：`npm run dev` - 运行测试：`npm test` - 构建：`npm run build` - Lint：`npm run lint` ## 代码规范 - 使用 ESLint + Prettier - 提交信息遵循 Conventional Commits - 分支命名：feature/xxx, fix/xxx, chore/xxx ## 禁止操作 - 不得直接修改 main 分支 - 不得提交 .env 文件 - 不得删除迁移文件 文档生成时间：2026年4月 | Claude Code 版本参考：claude-sonnet-4
-
ClaudeCode指定 plan文件的存储位置 方案一：项目级配置（推荐） 在你的项目目录下的 .claude/settings.json 里添加： { "plansDirectory": "./docs/plans" } 这样 plan 文件就会创建在项目根目录的 docs/plans/ 文件夹下，还可以提交到 git。 方案二：全局配置 修改用户级别的配置文件 ~/.claude/settings.json（Windows 上是 C:\Users\用户名.claude\settings.json）： { "plansDirectory": "D:/my-projects/claude-plans" } 路径写法说明 写法效果 "./plans"相对于工作区根目录" ./docs/plans"项目内的 docs 子目录 "D:/my-projects/plans"Windows 绝对路径 推荐把 plansDirectory 加到项目的 .claude/settings.json（而不是用户级别），这样团队成员克隆仓库后，大家的 plan 都会存到同一个位置。 codewithmukesh
-