夜雨聆风
AI 编程:从工具到方法论的进化之路
一、认识 Claude Code
1.1 Claude Code 的工作方式
给 Claude 一个任务，它大致经历三步：收集上下文 、采取行动 、验证结果 。这三步不是严格串行的，而是交替进行。Claude 会自己搜索文件、读代码、改代码、跑测试，整个过程你随时可以打断、纠偏、补充信息。
你可以在任何时刻中断以引导 Claude 朝不同的方向发展、提供额外的上下文或要求它尝试不同的方法。Claude 自主工作但会对你的输入保持响应。
你需要做什么
|
|
|
|
|
|
|
|
|
|
|
|
@ 和 ! 速览
|
|
|
|
|
|
|
|
|
|
|
|
Effort Level
Opus 4.6 引入了 Adaptive Thinking（自适应思考）——Claude 会根据任务复杂度自动调整推理深度，在 Claude Code 里你通过 effort level 来手动控制。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1.2 使用环境与工具推荐
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
终端 CLI 功能最全，VS Code 扩展适合习惯 IDE 的同事，两者可以同时用。
终端 CLI 功能最全，VS Code 扩展适合习惯 IDE 的同事，两者可以同时用。
1.3 几个需要了解的概念
Agent 与 Sub-Agent
Agent 是 Claude Code 的主要工作模式——它不只是问答，而是自己规划任务、搜索代码、写代码、跑测试、修问题，整个循环自动完成。
Sub-Agent 是主 Agent 派出去的独立工作单元，每个 Sub-Agent 拥有自己独立的上下文窗口，不占用主 Agent 的上下文空间。Claude Code 支持 Agent Team 模式，可以同时启动多个 Sub-Agent 并行干活，比如前端、后端、架构师各跑各的，互不阻塞。
Agent Team 模式下各 Sub-Agent 可以相互通信交流，在完成任务后会将结果汇报给主 Agent，主 Agent 再统一协调和整合，整个过程 Token 消耗非常快。实际使用中要根据任务复杂度选择合适的方式——简单任务用单个 Sub-Agent 就够了，只有多模块并行开发这类场景才值得启动 Agent Team。
Context Window（上下文窗口）
AI 一次能”看到”的信息总量，类似工作记忆。当前 Opus 支持最大 1M tokens（中文约 50 万字），容量已经很大，但上下文窗口不只装代码——你的每一轮对话、AI 的每一次思考、搜索结果、工具输出都在消耗这个空间。
所以上下文管理是 AI 编程最关键的能力之一。Claude Code 的策略是按需加载——根据当前任务智能搜索和读取相关文件，而不是一次性塞入所有代码。但随着对话轮次增加，早期消息会被自动压缩甚至丢弃，AI 会”忘记”之前的决策和约定。
MCP（Model Context Protocol）
Anthropic 推出的开放协议，让 AI 能连接外部工具和数据源。可以理解为标准化的插拔接口。
Claude Code ──MCP──→ 数据库查询工具 ──MCP──→ Playwright 浏览器自动化 ──MCP──→ 你自己写的任何工具通过 MCP，Claude Code 可以直接查数据库、操作浏览器、调用内部 API，不再局限于读写本地文件。
值得关注的趋势是：越来越多的工具开始提供原生CLI 支持 （如 Playwright CLI），AI 可以直接通过命令行调用，无需 MCP 中间层。CLI 方式更轻量、Token 消耗更低、调试也更直观。未来 CLI 可能会在很多场景下取代 MCP，成为 AI 连接外部工具的主流方式。
Skills（技能扩展）
Skills 是 Claude Code 的插件机制，一组预定义的 Prompt + 工作流程，约束 AI 在特定场景下的行为。
比如：没装 TDD Skill 时，你说”帮我写个功能”，AI 可能直接开写。装了之后，AI 会自动走”先写测试 → 再写实现 → 测试通过才算完”的流程。
Skill 的作用： 不是给 AI 新能力，而是给 AI 加约束。 让输出更可控、更符合工程规范。Skills 可以社区共享，也可以团队自研，后面介绍的 BMAD 和 SuperPowers 都是通过 Skills 机制实现的。
-
• https://skills.sh/
Rules（项目规则文件）
写在项目根目录或rules下的规则文件（如 CLAUDE.md，code-style.md），AI 每次启动时自动读取，相当于项目级的行为约束。
# 项目规则- 后端使用 Java 17 + Spring Boot 3.x- 数据库操作必须使用 MyBatis-Plus，禁止手写 SQL- API 返回格式统一使用 Result<T> 包装- 所有新增接口必须编写单元测试- 禁止在 Controller 层写业务逻辑- 变量命名使用 camelCase，常量使用 UPPER_SNAKE_CASEAI 模型是通用的，它不知道你们团队的技术栈偏好和编码规范。Rules 文件就是把这些约定显式化，让 AI 从第一行代码开始就遵守团队规范。
实际体会：Rules 写得越具体越好。
❌：”代码要规范”没用
✅：”Controller 层只做参数校验和结果包装，业务逻辑放 Service 层”才有效。
Hooks（钩子机制）
Claude Code 的事件回调机制，在特定时机自动执行 Shell 命令。
可用的 Hook 时机：
PreToolUse：工具调用前（如写文件前自动备份）PostToolUse：工具调用后（如代码修改后自动格式化）Notification：AI 发出通知时实际用途：
-
• AI 修改代码后自动跑 eslint –fix -
• AI 写入文件前检查是否符合目录规范 -
• AI 完成任务后自动触发构建检查
1.4 Claude Code 项目配置结构
一个完整的项目配置长这样：
your-project/├── CLAUDE.md # 项目级指令（团队共享，提交到 Git）├── .claude/│ ├── settings.json # 项目设置（团队共享）│ │ └── 包含 Hooks 配置、权限设置、环境变量等│ ├── settings.local.json # 个人项目设置（gitignore）│ │ └── 个人 API 密钥、本地路径等敏感信息│ ├── rules/ # Rules：模块化规则文件│ │ ├── code-style.md # 代码风格规范│ │ ├── testing.md # 测试规范│ │ ├── security.md # 安全要求│ │ └── performance.md # 性能要求│ ├── agents/ # Agent：自定义子代理配置│ │ ├── code-reviewer.md # 代码审查 Agent│ │ ├── qa.md # 调试 Agent│ │ ├── frontend-dev.md # 前端开发 Agent│ │ └── backend-dev.md # 后端开发 Agent│ ├── skills/ # Skills：自定义技能│ │ ├── tdd-workflow/ # TDD 工作流技能│ │ │ └── SKILL.md│ │ ├── fix-issue/ # Bug 修复技能│ │ │ └── SKILL.md│ │ └── prd-reverse/ # PRD 逆向生成技能│ │ └── SKILL.md│ ├── hooks/ # Hooks：事件钩子脚本│ │ ├── pre-tool-use.sh # 工具调用前执行│ │ ├── post-tool-use.sh # 工具调用后执行│ │ └── notification.sh # 通知事件处理├── .mcp.json # MCP：项目级 MCP 服务器配置│ └── 配置数据库、浏览器、API 等外部工具连接二、 AI 协作框架推荐
工具解决”能不能做”，框架解决”怎么做好”。下面介绍两个我实际在用的框架。
2.1 BMAD：管流程、管记忆
BMAD 是一套让 AI 按敏捷流程工作的方法论，主要解决两个问题：上下文持久化 和流程结构化 。
它要解决什么问题
用 AI 写代码最常遇到的情况：
早上：让 Claude 帮忙做一个项目管理模块，聊了半天，方案定了，代码写了一半中午：关掉对话去吃饭下午：重新打开 Claude，它完全不记得之前做了什么，接下来要做什么BMAD 的做法是把 AI 的”记忆”写到文件里。每个阶段的产出都落盘成文档，下次启动时 AI 读这些文档就能接上。
Agent 角色体系
BMAD 不是让一个 AI 干所有事，而是定义了多个角色，每个角色有明确的输入输出：
每个角色的输出就是下一个角色的输入，形成文档链。任何时候重启 AI，读这些文档就能从断点继续。
文件持久化结构
项目根目录/├── .bmad/│ ├── PRD.md # 产品需求文档│ ├── architecture.md # 架构设计文档│ ├── user-stories/ # 用户故事集合│ │ ├── US-001.md│ │ └── US-002.md│ ├── sprint-plan.md # Sprint 计划│ ├── tech-stack.md # 技术栈决策记录│ └── progress.md # 开发进度追踪这套文件结构的价值：
-
• 对 AI：每次启动读取这些文件，立刻恢复项目上下文 -
• 对人：随时可以审查 AI 的决策过程，发现问题及时纠偏 -
• 对团队：新人接手时，这些文档就是现成的项目说明书
工作流程
第一阶段：需求分析（Analyst Agent） └── 在头脑风暴教练的引导协助下进行项目想法头脑风暴，帮你理清需求边界 └── 产出：需求分析文档第二阶段：产品规划（PM Agent） └── 基于需求分析，编写 PRD 和用户故事 └── 产出：PRD.md + 用户故事文件第三阶段：解决方案设计（Architect Agent，Scrum Master Agent） └── 基于 PRD，设计技术方案 └── 将需求分解为可实施的工作 └── 产出：architecture.md，sprint-plan.md第四阶段：实施（Developer Agent） └── 按任务清单逐个实现 └── 产出：可运行代码 + 进度更新快速流程：（Quick Flow Solo Dev Agent） └── 对于小型、易于理解的工作，跳过阶段 1-3。 └── 统一快速流程 — 澄清意图、规划、实现、审查和呈现优缺点分析
2.2 SuperPowers：管质量、管纪律
AI 写代码最大的问题不是”写不出来”，而是默认不遵守工程纪律 ——不分析需求就动手、不写测试就交付、遇到 bug 就猜着改。SuperPowers 用 Skill 机制在每个阶段强制插入流程约束，让 AI 必须按纪律走完整个开发循环。
五个技能模块
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
优缺点分析
2.3 两个框架的共同点
不管用哪个框架，都在强调同一件事：
-
1. 先想清楚（Brainstorm）：不要一上来就让 AI 写代码，先理清需求、探索方案 -
2. 做好计划（Plan）：把大任务拆成小步骤，明确每步的输入输出和验收标准 -
3. 再去执行（Execute）：在清晰的方向和计划下，让 AI 按纪律执行，而不是自由发挥
这三步是 AI 编程质量的基本保障。
2.4 BMAD + SuperPowers整合方案
两个框架各有所长，实际使用中我对他做了整合：
-
• BMAD 负责”流程”：需求分析 → 产品规划 → 架构设计 → 任务拆解 -
• SuperPowers 负责”纪律”：TDD → 系统化调试 → 代码审查 
整合的几个关键点：
-
• 在 BMAD 的编码阶段，强制使用 SuperPowers 的 TDD 和调试技能 -
• SuperPowers 的开发进度写入 BMAD 的文件体系
三、AI编程之路：从裸用 AI 到形成方法论
在实际使用 Claude Code 的过程中，大致会经历五个阶段，每个阶段都会产生不同的经验教训。
兴奋期 — AI什么都能做
刚开始用 Claude Code 的时候，确实很兴奋——让它写个功能，居然能跑。于是开始大量让 AI 写代码，感觉效率提升了好几倍。
但很快发现问题：
比如让 AI 写一个项目管理系统的后端→ 一口气生成了 20 个文件，看起来很完整，跑起来也没报错→ 数据量变大出现各种问题，查代码发现缺少异常处理、没有分页、关联查询全是循环调用→ 改一个 Bug 引入三个新 Bug，因为没有测试经验：AI 生成的代码”能跑”不等于”能用”，AI 每次对话风格都不一样，没有测试兜底。
破壁期 —
发现 AI 太随意之后，我们开始在项目里写 Rules 文件，此时AI 的输出开始收敛，至少不会再随意切换技术栈了。
CLAUDE.md- 使用 Java 17 + Spring Boot 3.x- ORM 框架使用 MyBatis-Plus，禁止手写原生 SQL- API 统一返回 Result<T>，异常统一在 GlobalExceptionHandler 处理- 禁止在 Controller 层写业务逻辑- 新增接口必须有对应的单元测试- 数据库字段命名使用 snake_case，Java 属性使用 camelCase经验： Rules 能约束”怎么写”，约束不了”写什么”和”按什么顺序写”。AI 还是会跳过需求分析直接写代码，还是会忘记之前的上下文。
探索期 — 想清楚再动手
意识到 Rules 不够之后，需要找更系统的方式来管理 AI 的工作流程。这个阶段最大的转变是：从”让 AI 写代码”变成”让 AI 先帮我想清楚，然后再写代码”。
之前：你帮我写一个任务管理的 CRUD 接口现在：我要做一个任务管理模块，你先帮我分析一下： - 任务有哪些状态？状态之间怎么流转？ - 需要支持哪些查询维度？ - 权限怎么控制？ - 和现有模块有什么关联？这个阶段我们接触了 BMAD、SuperPowers 、Everything-Claude-Code等框架，开始把流程编排和工程纪律引入 AI 协作。
整合期 — Agent 检查 Agent
单一框架用熟了，发现每个框架都有短板。于是开始整合：
整合方案： BMAD 管流程 + SuperPowers 管质量Agent 互检机制： 开发 Agent 写完代码 → 测试 Agent 运行测试套件（SuperPowers） → 审查 Agent 检查对抗审查（Bmad）
这个阶段的几个体会：
-
• 没有万能框架，每个框架解决一类问题 -
• Agent 之间互相检查比单个 Agent 自检更可靠 -
• 框架整合要根据项目特点调整，不能照搬
沉淀期 — 团队工具链
把实践经验沉淀成团队可复用的 Skill 和 Rules：
团队级 AI 工具链： ├── 项目 Rules 模板（按技术栈分类） ├── 自研 Skills │ ├── prd-reverse（代码逆向生成 PRD） │ ├── playwright-e2e（自动化 E2E 测试） │ └── code-standard-check（编码规范检查） │ └── architecture-iflytek（符合公司规范的架构设计） │ └── common-list（对账中心列表页Skill） ├── BMAD + SuperPowers 整合配置 └── 团队 AI 编程最佳实践文档到这个阶段，从”个人摸索”变成”团队开箱即用”，新项目可以直接套用。
四、创新调研分享
多个已上线系统的历史 PRD 文档已丢失或严重过时，业务逻辑长期依赖代码和口头传承。为此自研 prd-reverse Skill，基于现有代码库进行自动化逆向分析，生成标准化 PRD，实现”代码即文档”——让历史系统中的业务逻辑以结构化、可阅读、可维护的方式沉淀下来。目前正与产品侧协同验证 PRD 内容的准确性与完整性。
-
2、基于 Playwright Cli 的自动化测试流程
基于 Playwright-CLI 组件，已实现由测试人员通过自然语言描述测试意图，系统自动驱动浏览器完成端到端测试的能力。在此基础上，下一步需要解决的是：如何将已有测试用例结构化，并自动生成可复用、可维护的自动化测试脚本，以进一步提升测试效率。
视频涉及敏感信息,就不放了·
五、AI编程观点
AI 时代对人的要求更高了，不是更低了
AI 写代码的速度是人的几十倍，但方向错了，只会更快地走向错误。
-
• 对开发者而言，核心能力从”写代码”转向了方案判断、风险识别、架构决策和需求拆解。 -
• 对产品/业务侧而言，同样需要升级。AI 遵循 “Garbage In, Garbage Out”的铁律——模糊的需求只会换来跑偏的输出。产品/业务侧必须提供 结构化、无歧义、可量化 的需求描述，并通过 AI 辅助校准与补全细节，确保输入准确，才能获得稳定可靠的输出。