Posts

这一篇，我们正式进入 Claude Code**（后文简称CC）**的世界。 CC提供了一套简洁强大的交互模型，它的核心交互范式就浓缩在两个异常简单的符号里：@和!。 @：CC"感知"世界的感官，用来获取外部世界的信息。对用户来说，使用@给CC提供上下文信息，把以前的”粘贴复制“操作浓缩成一个@符号。例如，输入@Test.java，意味着告诉CC，“你先把Test.java文件看一遍，我们后面的讨论，都得基于你了解Test.java”。 !：CC”改变“世界的"手"，用来"执行操作"，影响外部世界。这里所说的CC"执行操作"，大多是指执行Shell命令。通过!符号，把执行命令的操作无缝融入对话过程中，减少了用户的割裂感。 下面，让我们深入这两个指令。 @：Claude Code的"眼睛" 在对话流中，@指令可以随时为CC提供上下文信息，让它能"看到”你项目的全局。 @引用单个文件 这是@指令最常用的方式，可以引用任何文件，代码、配置、数据库sql、文档等等，用法如下： @/path/file @文件时，CC支持Tab自动补全（就像补全bash命令一样），@后输入前几个字符，再按下Tab就能自动补全了。下面，我们来看两个@单文件的例子。 解释代码 你拿到一个全新的代码文件，想迅速理解，可以直接@代码文件喂给CC，让它给你逐行解释： @server/src/main/java/com/github/liyue2008/rpc/server/Server.java 请详细解释一下代码 可以看到，CC会读取`Server.java`文件，输出一份"逐行注释"的代码解释，你不用手动复制粘贴代码了。 提取文件核心内容 你拿到一篇复杂的英文论文，想让CC帮你分析并提取核心内容，把提取的内容输出到一个结构化的文件中： @raft.pdf 请分析并提取该文件的核心内容，用中文组织输出，输出篇幅控制在2篇以内，生成一个`result.md`文件并写入当前目录 可以看到，CC会读取`raft.pdf`文件内容，分析后按要求用中文输出提取的核心内容，并尝试生成`result.md`结果文件，在获得我们的授权后，将结果文件写入当前目录下： @引用整个目录 当需要宏观视角时（横跨多个文件），此时，@可以引用整个目录： @/path/directory CC在用@读取目录时，默认能感知Git，它会先找到根目录下.gitignore文件，然后把.gitignore中指定的目录和文件全部忽略掉，不会去加载。这样既减少了token浪费，又避免了无关文件的干扰。我们同样来看一个@目录的例子。 分析新项目 你刚拿到一个全新的项目，对它一无所知，想快速上手，可以直接把整个项目目录喂给CC（不超过上下文最大窗口的前提下），让CC帮你分析新项目的整体架构、主要功能、核心流程等： @./ 请分析当前项目的整体结构、主要功能、核心流程和相关依赖 可以看到，CC扫描了整个项目，把相关Java代码都读了一遍，整体分析理解后，输出了详细的项目结构、核心流程、主要依赖等，堪比资深的研发同事为你做项目简介。 @作为CC的"眼睛"，将真实世界的信息转化为CC能够理解的上下文。掌握@，是掌握Claude Code的第一步。 !：Claude Code的"手" 在对话流中，!指令可以随时执行Shell命令（无需退出CC），打通"想"（云端大模型）和"做"（本地环境）之间的壁垒。 手动执行命令 这是!直接的用法，在对话中手动执行Shell命令，用法如下： ! {shell_command} 我们来看一个例子。 查看当前目录所有文件 你想看一下项目的当前目录中有哪些文件，直接执行： ! ls -alh 终端会执行这个Shell命令，把结果返给CC： !命令的输出，会自动加入当前对话的上下文中，被CC所感知。这个特性很强大，后续对话可以基于!命令的输出，做进一步的操作。 上面的例子中，列出了当前目录下的所有文件，现在我们在README.md文件后加一句话： 在`README.md`文件后追加一句话: "测试!命令的输出能被感知到"。 CC直接在`README.md`末尾加上了这句话。 Claude Code自主执行命令 让CC自主决定执行什么命令（what）、什么时候执行（when），这才是!的AI原生用法。当CC判断需要执行Shell命令来完成任务，它会主动发起Tool Call（工具调用），先找你审批，等你审批通过后，它才执行。 我们来看一个例子，我想知道当前连的局域网的公网ip是多少，可以直接问CC： 请帮我查一下，当前局域网暴露的公网ip是多少？ CC思考之后，想发起一个Bash调用（执行curl命令）查询公网ip，它先来找你审批，你同意后，它才执行Bash调用： 最后查到公网ip，结束本次任务。 以上，就是Claude Code的核心交互范式，掌握了@和!，你就拥有了与Claude Code协作的基础能力。 用户发出指令 -> CC用@看 -> 云端大模型思考 -> CC用!做 -> 执行结果反馈给用户，这个反馈循环，就是我们与Claude Code的协作日常。 ...

跟着我一起玩转Claude Code！ 1、基本介绍 Claude Code是Anthropic公司推出的CLI AI Agent（命令行AI智能体），最初锚向的是AI Coding工具，但发展到现在，我对它的理解，已经不仅仅只是一个"编程Agent"了。 纵观市面上主流的 AI Coding 工具，GitHub Copilot、Windsurf、Cursor等，百花齐放。“御三家” Codex（OpenAI的）、Gemini（Google的）、Claude Code（Anthropic的）均有各自的特点和擅长的赛道，但个人体验后，我愿称Claude Code为"最强"（纯个人观点，非引战）。 Claude Code的核心设计理念就是一个**“自主自治的工作流引擎”**，它能从整体上理解项目全局上下文，自主规划并执行复杂的端到端任务，拥有Hooks、Commands、Skills、MCP等丰富的自定义扩展能力，是团队中不可或缺的"自己搬砖的虚拟成员"。 缔造了"事实标准"：Claude Code可以说是CLI AI Agent领域的开创者，许多"游戏规则"都是它定的，比如 “@“注入上下文、”!“执行shell命令、”/“发起斜杠命令等，后续的工具大多都借鉴效仿了其设计。 实现了完整方法论：Claude Code将SDD方法论实现得最完整、最体系化，包括上下文管理、安全限制、MCP扩展等。掌握了它，也就掌握了底层的使用思想，可以无缝切换到其他工具。 拥有最繁荣的生态：Claude Code凭借其强大的先发优势形成了正向的生态循环，吸引大量用户使用，催生出更多第三方工具和更多模型的支持，国内的主流模型都提供了对Claude Code的支持，比如minimax、GLM、Kimi等。掌握了它，你就接入了一个不断发展的AI生态。 AI时代，我认为每个开发者都要掌握Claude Code的使用。但相比开发者而言，我更推荐产品经理来学习Claude Code，一旦你掌控了它，就拥有了一支由"架构师”+“技术leader”+“资深研发者们"组成的专业"虚拟研发团队”，配合你强大的产品思维，完全可以"一人成军”，踏上OPC（一人公司）之路。 2、环境搭建 现在正式开始搭建环境，总体思路就是：Claude Code Agent + 国产大模型。 Anthropic公司原生的大模型真的太贵了，另外，它也封禁了国内ip（通过香港的vpn跳过去好像也不行）。国内用户一般做法是，给Claude Code这辆"超跑"换一个"国产引擎"（国产大模型），它的"驾驶操作"是一样的，无非就是"驾驶体验"要稍差一点，一旦你学会了如何"驾驶"，可以无缝切回它的原生"引擎"。 2.1 安装Claude Code 我的环境是macOS，以macOS为例来说明如何安装Claude Code。 我在macOS中采用Homebrew来安装Claude Code，先安装Homebrew，再用Homebrew来安装Claude Code。 打开终端，先安装xcode： xcode-select --install xcode安装后，用官方脚本安装Homebrew： /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" Homebrew安装后，根据终端的提示，把Homebrew的环境变量写到用户的配置里，M芯片的Mac用户执行以下命令： echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zshrc source ~/.zshrc Intel芯片的Mac用户则执行以下命令： echo 'eval "$(/usr/local/bin/brew shellenv)"' >> ~/.bash_profile source ~/.bash_profile Homebrew安装好后，可以验证一下是否能用： ...

大家好，我是bytezhou，上一篇进行了SDD第二步-技术规划，今天将进入本次SDD实战的收尾-任务拆解及自动实现。 1、任务拆解 AI技术规划后输出 plan.md，距离代码，中间还缺少一步：把宏观的plan.md，拆分成一系列带依赖关系的、原子化的具体开发任务 tasks.md。技术细节已经齐全，但这个阶段要注意拆分的任务粒度和执行顺序。输入以下Prompt： @specs/spec.md @plan.md 你现在是技术leader，请根据`spec.md`和`plan.md`，**将`plan.md`中的技术方案，拆分成原子化的、详细的、带依赖关系的、可被直接执行的任务列表。** 核心要求： 1. 任务粒度：每个任务只实现最小化的功能（只涉及一个文件的变更）。**务必禁止："实现所有功能"的大任务。** 2. TDD：必须遵守"测试先行"，先生成测试、再去实现。 3. 并行标记：对没有依赖关系的任务，标记【P】。 4. 执行顺序（以下面的为准）： **1: 数据结构定义** **2: Github数据获取（请遵循TDD）** **3: 生成Markdown文件（请遵循TDD）** **4: 程序入口集成（请遵循TDD）** 完成后，将生成的任务列表写入到项目根目录下的tasks.md文件中。 下面是AI拆分任务的过程： 最终，AI会生成一份详尽的任务列表 tasks.md，我把它贴出来： # down_issue 任务列表 ## 执行顺序 1. 数据结构定义 (types.go) 2. GitHub 数据获取 (parser + github) 3. 生成 Markdown (markdown) 4. 程序入口集成 (cmd) --- ## 阶段一：数据结构定义 ### 1.1 【P】创建 github/types.go - 定义数据结构 **文件**: `internal/github/types.go` **内容**: 定义 Issue、PullRequest、Discussion、Comment 结构体，以及 ItemType 枚举和 Content 接口 **依赖**: 无 **任务**: 实现以下数据结构和接口 ```go // ItemType 表示 GitHub 内容的类型 type ItemType int const ( TypeIssue ItemType = iota TypePullRequest TypeDiscussion ) // Issue 表示 GitHub Issue type Issue struct { Number int Title string Body string Author string CreatedAt time.Time URL string Comments []Comment } // PullRequest 表示 GitHub Pull Request type PullRequest struct { Number int Title string Body string Author string CreatedAt time.Time URL string Comments []Comment } // Discussion 表示 GitHub Discussion type Discussion struct { Number int Title string Body string Author string CreatedAt time.Time URL string Comments []Comment } // Comment 表示评论/回复 type Comment struct { Body string Author string CreatedAt time.Time } // Content 统一的内容接口 type Content interface { GetTitle() string GetBody() string GetAuthor() string GetCreatedAt() time.Time GetURL() string GetComments() []Comment } ``` --- ## 阶段二：GitHub 数据获取 ### 2.1 【P】创建 parser/parser_test.go - URL 解析测试 **文件**: `internal/parser/parser_test.go` **依赖**: 无 **任务**: 编写表格驱动测试，覆盖以下用例： - 有效的 Issue URL (`https://github.com/owner/repo/issues/123`) - 有效的 PR URL (`https://github.com/owner/repo/pull/123`) - 有效的 Discussion URL (`https://github.com/owner/repo/discussions/123`) - 无效 URL 格式 - 缺失关键部分 ### 2.2 【P】创建 parser/parser.go - URL 解析实现 **文件**: `internal/parser/parser.go` **依赖**: 无 **任务**: 实现 `Parse(url string) (*ParseResult, error)` 函数 - 解析 GitHub URL，识别类型（issue/pull/discussions） - 提取 owner、repo、number - 返回 ParseResult 或错误 ### 2.3 【P】创建 github/github_test.go - GitHub API 测试 **文件**: `internal/github/github_test.go` **依赖**: types.go **任务**: 编写表格驱动测试，使用 HTTP test server mock GitHub API - 测试 FetchIssue - 测试 FetchPullRequest - 测试 FetchDiscussion - 测试 404 错误处理 - 测试网络错误处理 ### 2.4 【P】创建 github/github.go - GitHub API 客户端 **文件**: `internal/github/github.go` **依赖**: types.go **任务**: 实现 `Client` 接口和 `NewClient(token string) Client` - FetchIssue(owner, repo string, number int) (*Issue, error) - FetchPullRequest(owner, repo string, number int) (*PullRequest, error) - FetchDiscussion(owner, repo string, number int) (*Discussion, error) - 使用 net/http 调用 GitHub REST API - 支持 GITHUB_TOKEN 认证 ### 2.5 【P】创建 parser/parser.go 的 GetFilename 函数测试 **文件**: `internal/parser/parser_test.go` (追加) **依赖**: parser.go **任务**: 追加测试用例测试 GetFilename 函数 - Issue: `{owner}_{repo}_issue_{number}.md` - PR: `{owner}_{repo}_pr_{number}.md` - Discussion: `{owner}_{repo}_discussion_{number}.md` ### 2.6 【P】创建 parser/parser.go 的 GetFilename 函数实现 **文件**: `internal/parser/parser.go` (追加) **依赖**: parser.go **任务**: 实现 `GetFilename(itemType ItemType, owner, repo string, number int) string` ### 2.7 创建 fetcher/fetcher_test.go - fetcher 测试 **文件**: `internal/fetcher/fetcher_test.go` **依赖**: parser, github **任务**: 编写表格驱动测试 - 测试 Fetch 成功获取 Issue - 测试 Fetch 成功获取 PR - 测试 Fetch 成功获取 Discussion - 测试无效 URL 错误 ### 2.8 创建 fetcher/fetcher.go - 数据获取实现 **文件**: `internal/fetcher/fetcher.go` **依赖**: parser, github **任务**: 实现 `Fetch(url string, client github.Client) (Content, error)` - 组合 parser.Parse 和 github.Client.Fetch* - 返回统一的 Content 接口 --- ## 阶段三：生成 Markdown ### 3.1 创建 markdown/markdown_test.go - Markdown 生成测试 **文件**: `internal/markdown/markdown_test.go` **依赖**: github/types.go **任务**: 编写表格驱动测试 - 测试 GenerateIssue 生成正确格式 - 测试 GeneratePullRequest 生成正确格式 - 测试 GenerateDiscussion 生成正确格式 - 测试 GetFilename 返回正确文件名 ### 3.2 创建 markdown/markdown.go - Markdown 生成实现 **文件**: `internal/markdown/markdown.go` **依赖**: github/types.go **任务**: 实现以下函数 - `Generate(content github.Content) string` - `GenerateIssue(issue *github.Issue) string` - `GeneratePullRequest(pr *github.PullRequest) string` - `GenerateDiscussion(discussion *github.Discussion) string` - `GetFilename(itemType parser.ItemType, owner, repo string, number int) string` --- ## 阶段四：程序入口集成 ### 4.1 创建 cmd/down_issue/main.go - CLI 入口 **文件**: `cmd/down_issue/main.go` **依赖**: parser, github, fetcher, markdown **任务**: 实现 CLI 入口 - 解析命令行参数 (flag) - 处理 -o/--output 输出目录参数 - 调用 fetcher.Fetch 获取内容 - 调用 markdown.Generate 生成文件 - 错误处理和退出码 ### 4.2 创建 Makefile - 构建脚本 **文件**: `Makefile` **依赖**: 无 **任务**: 定义以下目标 - `go build` - 构建项目 - `go test` - 运行所有测试 - `go vet` - 代码检查 - `clean` - 清理构建产物 ### 4.3 创建 go.mod - 模块定义 **文件**: `go.mod` **依赖**: 无 **任务**: 定义模块名 `github.com/user/down_issue`，Go 版本 >= 1.26 --- ## 任务状态汇总 | 序号 | 任务 | 文件 | 依赖 | 状态 | |------|------|------|------|------| | 1.1 | 创建 github/types.go | internal/github/types.go | 无 | ⬜ | | 2.1 | 创建 parser/parser_test.go | internal/parser/parser_test.go | 无 | ⬜ | | 2.2 | 创建 parser/parser.go | internal/parser/parser.go | 无 | ⬜ | | 2.3 | 创建 github/github_test.go | internal/github/github_test.go | types.go | ⬜ | | 2.4 | 创建 github/github.go | internal/github/github.go | types.go | ⬜ | | 2.5 | 追加 parser GetFilename 测试 | internal/parser/parser_test.go | parser.go | ⬜ | | 2.6 | 实现 parser GetFilename | internal/parser/parser.go | parser.go | ⬜ | | 2.7 | 创建 fetcher/fetcher_test.go | internal/fetcher/fetcher_test.go | parser, github | ⬜ | | 2.8 | 创建 fetcher/fetcher.go | internal/fetcher/fetcher.go | parser, github | ⬜ | | 3.1 | 创建 markdown/markdown_test.go | internal/markdown/markdown_test.go | github/types | ⬜ | | 3.2 | 创建 markdown/markdown.go | internal/markdown/markdown.go | github/types | ⬜ | | 4.1 | 创建 cmd/down_issue/main.go | cmd/down_issue/main.go | 所有模块 | ⬜ | | 4.2 | 创建 Makefile | Makefile | 无 | ⬜ | | 4.3 | 创建 go.mod | go.mod | 无 | ⬜ | --- ## 并行执行分组 **【P】第一组（无依赖，可并行）**: - 1.1, 2.1, 2.2, 2.3, 2.4 **【P】第二组（依赖第一组，可并行）**: - 2.5, 2.6, 2.7, 3.1 **第三组（依赖第二组，顺序执行）**: - 2.8, 3.2, 4.1, 4.2, 4.3 【再次提醒：一定要审查！】 ...

大家好，我是bytezhou，上一篇给大家实践了SDD第一步-定义意图，接下来进入SDD第二步：技术规划。 传统范式下，产品经理输出PRD后，架构师拿着这份PRD进行技术选型（用Java还是Go）、架构设计（整体流程、分层设计）、模块划分（微服务拆分、数据建模）、API设计（前后端交互接口等）等，产出项目概要设计、详细设计文档等。 SDD范式下，“业务"映射在澄清后的、结构化的需求规范spec.md中，AI作为"架构师”，我们开发者则作为"工作流设计者"，指挥引导"AI架构师"把高层级的spec.md，“编译"成一份详尽的、结构化的技术规划方案 plan.md。废话不多说，我们进入正题。 切回项目目录，打开Claude Code（关闭plan mode），我们先来根据spec.md，指定技术栈，生成项目结构，同时让AI生成一份API声明（不一定严格遵守），作为后续输入（指导它思考）。输入以下Prompt： 1 2 3 4 5 @specs/spec.md 你是一名资深的Go语言架构师，请严格参考Go语言最佳实践（特别注意包内聚原则），根据`spec.md`，规划并创建整体的项目目录结构。 生成目录后，请在项目根目录下创建`api.md`文件，描述一下各个包对外暴露的主要接口（Interface/Function签名），作为后续开发的指导。 AI会迅速执行以上操作，按照Go最佳实践来生成项目结构，下面是它的执行过程： 可以看到，AI不仅创建了项目目录、生成了api.md，还进行了go mod初始化和makefile的生成，一气呵成。 以下是生成的 api.md： # API 文档 本文档描述 `down_issue` 项目各包对外暴露的主要接口，作为后续开发的指导。 --- ## 1. `internal/parser` - URL 解析 ### 职责 解析 GitHub URL，提取 owner、repo、number 及类型信息。 ### 接口签名 ```go // ItemType 表示 GitHub 内容的类型 type ItemType int const ( TypeIssue ItemType = iota TypePullRequest TypeDiscussion ) // ParseResult 解析结果 type ParseResult struct { Type ItemType // 类型：Issue、PR、Discussion Owner string // 仓库所有者 Repo string // 仓库名 Number int // 编号 } // Parse(url string) (*ParseResult, error) // 解析 GitHub URL，返回解析结果 // 支持格式： // - https://github.com/{owner}/{repo}/issues/{number} // - https://github.com/{owner}/{repo}/pull/{number} // - https://github.com/{owner}/{repo}/discussions/{number} // 错误：URL 格式不正确时返回错误 ``` --- ## 2. `internal/github` - GitHub API 客户端 ### 职责 封装 GitHub REST API 调用，获取 Issue、PR、Discussion 及其评论。 ### 接口签名 ```go // Issue 表示 GitHub Issue 数据结构 type Issue struct { Number int Title string Body string Author string CreatedAt time.Time URL string Comments []Comment } // PullRequest 表示 GitHub Pull Request 数据结构 type PullRequest struct { Number int Title string Body string Author string CreatedAt time.Time URL string Comments []Comment } // Discussion 表示 GitHub Discussion 数据结构 type Discussion struct { Number int Title string Body string Author string CreatedAt time.Time URL string Comments []Comment } // Comment 表示评论/回复 type Comment struct { Body string Author string CreatedAt time.Time } // Client GitHub API 客户端接口 type Client interface { // FetchIssue 获取 Issue 及其评论 FetchIssue(owner, repo string, number int) (*Issue, error) // FetchPullRequest 获取 PR 及其评论 FetchPullRequest(owner, repo string, number int) (*PullRequest, error) // FetchDiscussion 获取 Discussion 及其评论 FetchDiscussion(owner, repo string, number int) (*Discussion, error) } // NewClient(token string) Client // 创建 GitHub API 客户端 // token: 可选的 GITHUB_TOKEN，用于私有仓库或提高 API 速率限制 ``` --- ## 3. `internal/fetcher` - 数据获取逻辑 ### 职责 组合 parser 和 github 包，提供高层的数据获取接口。 ### 接口签名 ```go // Content 统一的内容接口 type Content interface { GetTitle() string GetBody() string GetAuthor() string GetCreatedAt() time.Time GetURL() string GetComments() []github.Comment } // Fetch(url string, client github.Client) (Content, error) // 根据 URL 自动识别类型，获取对应内容 // 返回 Content 接口，支持 Issue、PR、Discussion 的统一处理 ``` --- ## 4. `internal/markdown` - Markdown 生成 ### 职责 将获取的内容转换为格式化的 Markdown 文件。 ### 接口签名 ```go // GenerateIssue(issue *github.Issue) string // 将 Issue 转换为 Markdown 格式字符串 // GeneratePullRequest(pr *github.PullRequest) string // 将 PullRequest 转换为 Markdown 格式字符串 // GenerateDiscussion(discussion *github.Discussion) string // 将 Discussion 转换为 Markdown 格式字符串 // Generate(content github.Content) string // 统一生成接口，根据 content 类型自动选择对应生成函数 ``` ### 输出文件名格式 ```go // GetFilename(itemType parser.ItemType, owner, repo string, number int) string // 返回格式： // - Issue: {owner}_{repo}_issue_{number}.md // - PullRequest: {owner}_{repo}_pr_{number}.md // - Discussion: {owner}_{repo}_discussion_{number}.md ``` --- ## 5. `cmd/down_issue` - CLI 入口 ### 职责 命令行接口，协调各模块完成下载任务。 ### main.go 逻辑 ```go // 用法： // down_issue <url> # 下载到当前目录 // down_issue <url> -o <path> # 下载到指定目录 // 主要流程： // 1. 解析命令行参数（url, -o output-dir） // 2. 调用 parser.Parse() 解析 URL // 3. 创建 github.Client（可选使用 GITHUB_TOKEN） // 4. 调用 fetcher.Fetch() 获取内容 // 5. 调用 markdown.Generate() 生成 Markdown // 6. 调用 markdown.GetFilename() 获取文件名 // 7. 写入文件到指定目录 ``` --- ## 模块依赖关系 ``` cmd/down_issue/main.go │ ├── parser.Parse() │ └── 返回 ItemType, Owner, Repo, Number │ ├── github.NewClient(token) │ └── 返回 github.Client 接口 │ ├── fetcher.Fetch(url, client) │ ├── 调用 parser.Parse() │ ├── 调用 github.Client.Fetch*() │ └── 返回 Content 接口 │ └── markdown.Generate(content) └── markdown.GetFilename() ``` --- ## 错误处理约定 - 所有错误使用 `fmt.Errorf("包名: 描述: %w", err)` 包装 - 网络错误、解析错误、API 错误直接透传 - 不存在的资源返回标准 error，由 main.go 输出到 stderr 并以非零状态码退出 这是一份非常详尽的api文档，包含了各模块的职责描述、核心数据结构定义、主要接口声明、模块间的依赖关系等，项目已经初具"骨架”。 ...

大家好，我是bytezhou，今天实践SDD研发范式，直观感受一下SDD的强大威力！ 环境： macOS：14.8.4 Claude Code：v2.1.26 模型：MiniMax-M2.5（非广告，它的Coding Plan套餐性价比高，这儿有邀请链接https://platform.minimaxi.com/subscribe/token-plan?code=9BE5kxxIhC&source=link，刚在码字时，MiniMax-M2.7发布了…） （另外，关于Claude Code的安装配置和基本使用，这里就不详细展开了，后面打算单独出一个Claude Code系列，给大家分享一下我的使用心得） 需求的萌芽： 每次逛github的时候，对于一些我感兴趣的开源项目，它的Issues、PR、Discussions我都会去看，里面一些讨论挺有价值的，有时候就想能不能把它们留个档，但打开github页面一个个去复制也太傻了，此时，做个小工具的想法油然而生。 模糊的想法： “我要做个小工具，给它一个github的URL链接，就能把对应的Issues、PR、或Discussions的内容扒下来，不用存数据库，转成一个带格式的markdown文件就行。这个小工具就做成命令行的形式吧，简单方便。” 传统范式中，这种模糊的想法，需要产品经理和"用户"反复沟通、来回掰扯、深度挖掘，最终达成一致，输出一份PRD（需求文档）。 SDD范式下，由AI作为产品经理，开发者作为"用户"，我们开发者和AI通过多轮的探索式对话，来进行"需求澄清"，把"模糊的想法"转化成结构化的需求规范spec.md，这就是SDD的第一步，意图定义。下面，我们进入正题。 第一轮对话： 打开终端，创建一个目录，切进去 启动Claude Code，输入下面的Prompt，向AI提问： 1 2 3 4 5 我现在想实现一个小工具`down_issue`。 你是一位经验丰富的产品经理，现在需要你向我提问，帮我澄清需求，最终产出一份高质量的`spec.md`。 我初步想法是:做一个命令行工具，输入一个GitHub的Issue、PR、或Discussion的URL，它就能自动把内容扒下来并将其转换为Markdown文件。 现在请开始提问。 AI作为产品经理，会向你输出一系列高质量问题： 第二轮对话： 基于第一轮对话AI提出的问题，我做出了如下回复： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 **1. 关于输出：** - 文件默认保存在当前目录。**可选** 可通过命令行参数 -o 来指定输出目录。 - 文件名采用 {user}_{repo}_{issue_number}.md，或者 {user}_{repo}_{pr_number}.md **2. 关于内容范围：** Issue/PR/Discussion都必须包含：标题、作者、创建时间、主要内容、所有评论。 **差异处理**： - 对于PR：不用下载diff。 **必须**：保留原始URL链接。 **3. 关于认证与权限：** 默认支持公开仓库即可。 **认证方式（可选）：**仅支持通过环境变量 `GITHUB_TOKEN`传入PAT。 **4. 关于媒体处理：** - 仅保留图片的引用（URL引用）即可，无需下载图片。 **5. 关于错误处理：** - 如果Issue不存在，直接报错退出即可，错误信息打在标准输出上。 - 超时直接透传错误信息即可，不用重试。 AI思考后，会进一步帮你"具象化"问题，下面是它给到的回复： ...

SDD（Spec-Driven Development），规范驱动开发，是AI原生时代一种全新的开发范式。 很多人初识SDD可能是通过Vibe Coding，刚入行的工程师、缺少技术背景的使用者或许仅仅把SDD当成一种工具，其实不然，在从业多年的工程师看来，SDD这种范式对软件工程领域来说是一次巨大的突破和革新，也是AI原生时代研发工作的＂第一性原理＂。 下面，跟着我进行一次思维升维之旅，为你全面拆解SDD方法论！ 一、AI驱动的研发范式演进过程 首先，请让我带你回顾一下，AI爆发带来的研发范式演进过程，看看SDD是在什么背景下诞生的。 开发者都感受过 AI 的高效，但也有点感觉别扭，究其根源，在于目前我们与AI的协作模式，这种协作模式的演进，大致分为三个阶段： Phase 1：AI作为外部知识引擎 这是最初的协作模式，比如网页版的DeepSeek等。在这个模式下，我们把AI当做外部知识库，手动把问题或代码复制给它，再把它吐出的答案＂搬＂回来（这也是大多数普通用户的使用方式）。 每次交互，我们都是“人肉序列化器”，将复杂的场景上下文，“压缩”成文本再与AI交互。 Phase 2：AI作为嵌入式辅助 这是当前最主流的协作模式，比如VS Code中的AI插件、或者Cursor这样的"AI原生IDE"。 AI “嵌入”到我们的IDE里，能“看到”打开的文件、能智能补全、能在侧边栏与你对话。这相比于 phase 1 是一个飞跃，极大地减少了"人肉切换"的摩擦。 但是，这个"辅助"依然有着局限性： 视野受限：它的上下文，局限在"当前工作区"，对当前打开的文件理解透彻，但对整个项目架构、服务间的依赖等认知不足，缺少全局视野。 环境绑定、行动受限：它的行动被囚禁在IDE上下文环境中，无法作为一个独立代理被部署到任意环境去执行任务，如CI/CD流水线、远程服务器环境等。 phase 2极大增强了我们的编码能力，但本质上仍未脱离“辅助开发者”的范畴，是许多人停留的"局部最优解"。 Phase 3：AI作为原生工作流的智能体 这个阶段，AI从"被动辅助"变成了能"主动"工作的智能体，它能够感知项目全局、能理解人类意图并自主分解成一系列具体执行步骤（如重构这个包）、能利用工具与环境交互（跑shell命令、写文件等）。 AI成为了将人类意图转化为一系列实际行动的"执行者"，典型代表，就是以Claude Code为首的CLI AI Agent（命令行AI智能体）。 SDD正是在Phase 3背景下提出的人机协同研发的一种全新范式。 二、软件工程中"信息的丢失"问题 深入 SDD 之前，我们先看一个软件行业几十年来的根本矛盾：人类意图与代码实现之间的巨大鸿沟。 通常在开发中，各角色是这样协作的： 产品经理 把业务过程 翻译成 用人类语言描述的PRD（需求文档）。 架构师 把PRD 翻译成 技术设计方案。 开发者 再把技术设计方案 翻译成 一行行代码。 这个逐步"翻译"的过程，充满了"信息的丢失"，人类语言的歧义、主观臆断等。比如，产品说"这个按钮点了要立马能显示"，开发者可能理解成"API响应时间小于200ms"，也可能忽略了这句话。 更麻烦的是，文档（PRD、技术方案等）与最终的代码，基本上是脱节的。项目在迭代，代码飞速向前，而文档的更新"看心情"，最终文档在角落慢慢腐朽，成为"代码考古"的障碍。 数十年来，人们发明了UML、敏捷、Scrum等各种方法和工具，想缝合这条鸿沟，收效甚微。我们始终认为：**文档只是"指南"，代码才是"真理"！ ** AI时代的爆发，给了我们颠覆这个"真理"的机会。 三、SDD：规范(Spec)成为"真理之源" SDD实现了一次**“权利反转”**，其核心思想就一句话：规范才是"真理之源"。 SDD范式，是代码服务于规范，那份无歧义、可被机器理解的、结构化的"规范"，成为项目唯一的至高无上的"真理之源"。而代码，则降级为"真理之源"在某种特定技术栈（如Java + SpringBoot + Mysql）下的编译产物。如下图所示： 在这场"权利反转"中： 项目的核心：“修改代码” 变成 “维护规范”。 重构的核心：“大规模迁移代码” 变成 “基于同一份规范，生成另一个技术栈的全新实现方式”。 解决bug的核心：“修正错误代码” 变成 “修正错误的规范”。 要实现上述"权利反转"，“规范"必须具备一个特性：能被机器理解和执行。这就是 AI Agent 要扮演的新角色：“编译"人类的意图。 ...