一、Claude Code 方法论概述

探讨了在AI辅助编程时代，开发者应如何转变角色与认知，以及一套高阶的AI协作方法论。

核心内容归纳总结

1. 终极认知：AI是放大器，不是发动机

• 你的产出 = 你的思考质量 × AI的执行能力。你有方向，AI放大十倍；你没方向，AI放大的是零。
• 工具会死，方法论永生：Claude Code、Cursor等工具迭代飞快且可替代（即使源码泄漏也不影响其核心竞争力，因为壁垒在模型而非客户端工程），但拆解问题、定义边界、做判断的能力永远不过时。掌握底层方法论，才能成为不被工具绑定的人。

2. 角色转变：从“写代码”到“做决策”

• 认知重构：不要再把AI当成聪明的代码补全工具，而要把Claude Code当成你的工程团队，你必须成为架构师。
• 瓶颈转移：用AI做项目的瓶颈不在AI的能力，而在你的思考质量。你没定义清楚产品边界、架构约束和规范，AI就会自由发挥（如过度设计），导致输出不可用。

3. “全链路开发框架”与方法论

课程不教工具的基础操作，而是教如何把复杂系统需求拆解成AI能准确执行的任务链：

• 动手前必做三件事：定义产品边界（做什么/不做什么）、设计核心数据模型（ER图）、写CLAUDE.md（项目上下文和规范）。
• 两种协作模式：
  • 执行模式：你想清楚了，拆解好任务让它做，你验收。
  • 咨询模式：你没想清楚，先让它帮你梳理“应该考虑什么”，你判断取舍后再让它执行。
• 三大核心方法论：
  1. 规范驱动开发（SDD）：让AI永远在你定义的轨道上跑，不自由发挥。
  2. 三问裁剪法：拆解产品边界——做什么、不做什么、做到什么程度。
  3. 三步检查法：审查AI输出——先查意图、再查质量、最后查边界。

Claude Code 提示词提取与构建

根据开篇词的理念，提示词的构建不在于单句的技巧，而在于前置约束和任务拆解。以下是文中展示的关键提示词模式：

1. 错误的提示词（反面教材：模糊、无约束、无边界）

帮我设计一个AI Agent开发平台的后端架构，支持多模型、多Agent、工具调用。

• 结果：AI会给出一个看起来专业但极度过度设计的微服务方案，脱离实际需求。

2. 高质量执行模式提示词（正面示范：有规范、有约束、任务明确）

按照CLAUDE.md中的接口规范，实现模型提供商的CRUD接口，包含连通性测试功能，异常按错误码区分三种情况。

• 心法：指令中必须包含 规范来源 + 具体功能 + 异常处理标准。

3. 咨询模式提示词（用于自己没想清楚时，让AI帮梳理）

我要开发一个支持XXX的系统，但我对前期的组件准备不太确定。请帮我梳理一下：业务开发前需要准备哪些基础组件？每一步需要考虑什么？

• 心法：不直接让AI写代码，而是让AI提供思路和清单，你来做取舍。

4. 核心基础设施：CLAUDE.md 提示词框架

文中强调，花一整个晚上写 CLAUDE.md 是产出质变的关键。一个完整的CLAUDE.md应包含以下提示词结构：

# 项目上下文
[告诉AI这是一个什么项目，面向什么人群，预期规模是多少，比如：这是一个团队内部几十人使用的平台，不是百万用户的生产系统]
# 产品边界
[明确做什么、不做什么。比如：不需要微服务架构，只需要模块化单体]
# 架构约束
[明确技术选型和架构风格。比如：使用Spring Boot + Vue，采用模块化单体架构]
# 开发规范
[接口怎么定义、命名怎么定、错误码怎么处理、代码风格是什么]

💡 提示词核心心法总结：在给Claude Code下达任何编码指令前，先问自己三个问题——我告诉它“好”的标准了吗？我告诉它不做什么了吗？我给的任务粒度足够小且清晰吗？

二、Claude Code设计方法论一

核心内容围绕“如何高效利用AI编程工具”建立了一套认知框架和实操方法论。以下是核心内容总结及对应的Claude Code提示词提取：

核心内容

1. 核心认知框架：你是架构师，AI是工程团队

• 输入决定输出（阶梯式跃升）：给AI的提示越模糊，AI越需要猜测，错误会叠加；当输入质量足够清晰时，输出质量会发生质的飞跃。瓶颈不在AI，而在人的思考质量。
• 精力重新分配：AI辅助的最大价值不是单纯写代码变快，而是将人从琐碎的修bug、写测试中解放出来，把精力集中在架构设计和核心决策上。
• 技术判断力是前提：你必须懂技术，看不懂代码就无法验收，给不出精确描述就无法激活AI。

2. 实操工具一：三层分工模型

• 第一层：必须你做（决策层）。产品边界、架构决策、技术取舍。AI可提供方案对比，但必须你拍板。
• 第二层：AI做你验收（执行层）。业务代码、接口、测试用例、文档。硬标准：每一行代码你都要能说清楚它在干什么。
• 第三层：AI全权处理（机械层）。格式化、样板代码、简单重构、启动脚本。扫一眼即可。

3. 实操工具二：三步检查法（验收标准）

• 第一步，查意图：它做的是不是你让它做的？有没有自作主张扩大范围？意图错了，后两步白查。
• 第二步，查质量：风格、规范、一致性是否与项目现有标准统一？
• 第三步，查边界：错误处理、异常、并发风险是否覆盖？（可以让AI自己再排查一遍）。
• 防坑提醒：连续验收通过容易让人放松警惕，必须靠机制（如强制跑测试）兜底。

Claude Code 提示词提取与构建

根据文章内容，提示词的质量直接决定了输出的质量。以下是文中对比展示的低质量提示词与高质量提示词，以及基于“三步检查法”提取的验收提示词：

1. 低质量提示词（反面教材，输出结构模糊、缺失规范）

帮我用Spring Boot实现一个模型提供商管理的CRUD接口。

2. 高质量提示词（正面示范，输出结构完整、有错误码、有连通性测试）

按照CLAUDE.md中的接口规范，实现模型提供商的CRUD接口，使用MyBatis-Plus，错误码按规范定义，连通性测试的异常区分网络超时（2001）、认证失败（2002）、模型不存在（2003）三种情况。不需要工厂模式，用最简单的方式实现。

3. 精确功能实现提示词（文中用于“删除接口”的示例）

实现删除模型提供商的接口，路径DELETE /api/v1/providers/{id}，删除前检查是否有Agent正在使用该提供商，如果有则拒绝删除。

4. 边界排查提示词（基于“三步检查法-查边界”提取）

请检查你刚才输出的代码，重点排查以下边界问题：1. 是否处理了并发场景（如检查通过后、删除前有新数据绑定）？2. 传入的ID不存在时，是否正确抛出了404而不是500？请列出潜在的异常和风险点，并给出修复代码。

💡 提示词编写核心心法提取：

在给Claude Code下指令前，应在提示词中明确包含以下要素（写入CLAUDE.md或直接在指令中说明）：

1. 规范约束：遵循什么接口规范、代码风格。
2. 技术选型：用什么框架/组件（如MyBatis-Plus）。
3. 明确不做什么：避免过度设计（如“不需要工厂模式”）。
4. 异常与边界定义：具体的错误码、特定的异常分支处理。

三、Claude Code设计方法论二

核心内容介绍了贯穿全课的核心方法论——规范驱动开发（SDD），旨在解决AI输出缺乏长期记忆和全局一致性的问题。以下是核心内容总结及对应的Claude Code提示词提取：

一、 核心内容归纳总结

1. 为什么需要SDD？（单次Prompt vs 规范体系）

• AI没有长期记忆：单次对话中指令再清晰，也只对当次有效。新开对话时，AI会“从零开始”，导致不同模块的命名风格、返回格式、错误码、设计模式大相径庭。
• 本质区别：写好Prompt是一次性的技巧，SDD是贯穿项目生命周期的方法论。规范写下来并自动加载，让AI在任何模块、任何阶段都在同一套规矩下工作。

2. SDD的完整工作流（四步闭环）

• 第一步：定规范。写业务代码前，先覆盖AI最容易跑偏的4个地方：命名风格、返回格式、错误码体系、设计原则（如禁用过度设计）。规范写在项目根目录的 CLAUDE.md 中，AI每次启动自动读取。
• 第二步：AI按规范执行。下达任务时明确引用规范，提醒AI关注约束。
• 第三步：人验证输出。用“三步检查法”对照规范清单进行客观核查，把主观判断变为客观打勾。
• 第四步：迭代规范。最关键的一步。每次AI跑偏，不要只改代码，要问“规范是不是没覆盖到？”，然后补上该条规范。跑偏一次补一条，规范在开发中长出来，越磨越锋利。

3. 有效规范的三条标准

• 具体不模糊：不能写“代码要简洁”，要写“不引入工厂模式，用最简单方式实现”。判断标准：AI看到后还需不需要“猜”？
• 有优先级不贪多：AI反复跑偏的地方写细，不跑偏的不写。避免上下文窗口被无效规范稀释。
• 带原因不只是规则：涉及工程权衡的规范（如“不全量删除再插入”），不仅要告诉它“不要做”，还要告诉它“为什么”（会导致并发读取空列表），AI理解原因后才能举一反三。

4. 规范的分层管理

• 全局规范（地基）：写在 CLAUDE.md，全项目通用（命名、接口格式、设计原则等），很少改动。
• 模块规范（补充）：特定模块的契约（如对话模块的数据流定义），写在模块目录或任务指令里。
• 任务规范（微调）：单次任务的临场补充（如“这次不需要分页”），不落文档。优先级：任务 > 模块 > 全局，但任务规范不能违反全局规范。

二、 Claude Code 提示词提取与构建

根据SDD方法论，提示词的构建不再是单次对话的技巧，而是基于 CLAUDE.md 的体系化约束。以下是文中展示的关键提示词模式：

1. 避坑型提示词（反面教材：无规范约束的单次指令）

实现Agent的CRUD接口。

• 结果：AI会自由发挥，导致实体类乱加后缀、错误码撞号、滥用Builder模式。

2. 规范驱动型提示词（正面示范：引用规范体系）

按照CLAUDE.md中的规范，实现Agent的CRUD接口。

• 心法：通过明确引用规范文件，强制AI在既定轨道（命名、返回格式、错误码分段、禁用设计模式）内执行。

3. CLAUDE.md 核心规范提示词框架（文中迭代出的具体规范）

# 命名规范
实体类大驼峰，不加前缀后缀。例如 Provider、Agent、ChatMessage。
字段小驼峰。例如 apiKey、baseUrl、modelName。
接口路径：/api/v1/{资源复数名}。
# 接口规范
所有接口统一返回 Result<T>：{ code, message, data }
列表字段空时返回空数组 []，不返回 null。
字符串字段空时返回空字符串 ""，不返回 null。
分页参数：page（从 1 开始）、pageSize（默认 20）。
# 错误码
四位数字，按模块分段：
1000-1999 通用 | 2000-2999 Provider | 3000-3999 Agent
4000-4999 Chat | 5000-5999 MCP
# 设计原则
不引入不必要的设计模式（工厂、策略、观察者等），除非明确要求。每个功能用最简单直接的方式实现。
不做过度抽象，一层能解决的不要拆成两层。
不引入技术栈以外的依赖，需要时先确认。
# 行为约束（防跑偏迭代补充）
修改已有代码前，先理解相关模块的设计意图。
不要为了实现新功能破坏已有模块的接口契约。
Controller 只做参数校验和调用 Service，不写业务逻辑。
跨模块调用走 Service 接口，不直接引用其他模块的 Mapper。

4. 带原因的约束提示词（针对复杂工程权衡）

不要全量删除再全量插入。因为全量删除再插入会导致并发场景下Agent瞬间失去所有工具关联，如果此时有对话正在读取工具列表，会拿到空列表。请使用差异比对的方式更新。

• 心法：对于涉及并发、数据一致性等工程判断的约束，加上 因为...会导致... 的原因解释，AI的遵循度和举一反三能力会大幅提升。