ByteZhou的个人空间

AI浪潮下的职场重构：普通人如何在变局中找到位置

Sat, 04 Apr 2026 21:59:42 +0800

引言：当技术革命不再是均富机

人工智能正在以前所未有的速度重塑职场生态。这次不一样——它不只是提升效率或创造新需求，而是在压缩存量工作的人力成本。一个设计小组从五人变成两人加一堆算力，被优化的不仅是岗位数量，更是整个中产阶层的生存逻辑。

一、职场竞争逻辑的根本转变

从专业能力到工具使用效率

传统晋升路径建立在专业积累之上——十几年积累的经验、人脉，被视为不可替代的核心竞争力。但AI介入工作流程后，这种认知正在被颠覆。

核心问题是：你的经验、职级、行业积累，如果无法转化为高效的AI prompt，就可能变成"负资产"。因为你比年轻人贵，还比他们慢。

一个刚毕业两个月的本科生，可能因为熟练掌握AI工具，在三天内完成资深工程师两周才能完成的设计方案。这不是危言耸听，而是正在发生的事情。

中间层正在被"精准打击"

传统公司架构是金字塔：顶层决策，中间层负责信息筛选、传递、美化和统筹协调，底层执行。AI在精准打击中间层。

AI可以迅速读完一百二十页报告并提取摘要，自动回复百分之八十以上的邮件，协调日程、生成报表、进行基础代码审查。以人力资源为例，以前需要五个人做的事情，现在一个人加一套系统就够了。

这意味着年薪50万~100万之间的中产岗位正在逐步消失。

二、被"结构"击中的中产群体

谁是中产？不是有矿的人，而是背着贷款的人

这里的"中产"不是有固定资产收租的得利者，而是指那些在大城市里背负两三百万房贷、开三十万的车、孩子上不错学校、每年必须旅游两次的群体。互联网大厂中层管理者、广告公司总监、金融公司项目经理——至少是公司小头目。

他们的共同特点是：高消费建立在对未来收入持续增长的乐观预期之上。

他们敢于消费，是因为相信自己即使今年被裁员，凭过往履历也能找到平级甚至更好的工作。但现在恐惧在于：市场根本没有平跳的机会了。

从"不会变穷"到"变得无用"

更准确地说，不是变穷了，而是变得没用了。

他们手里还有积蓄、房产，但对未来的预期彻底改变了。一旦预期改变，消费行为立即转变：不再换车，不再换房，连楼下人均400的日料店也不去了。

过去十几年，消费引擎正靠这群人的负债型消费——把未来30年的收入在今天花掉。一旦这个群体对未来失去信心，开始缩表还债、主动减少支出，整个市场就很难拉动。

三、AI与资本的双向奔赴

企业的两难选择

很多人认为贸易战是外部压力、AI是内部技术变革，是两码事。但从现实看，他们是同一件事。

外部环境恶化正在逼迫企业与资本以近乎疯狂的速度拥抱AI。原因很简单：成本。

过去十几年，制造业、外贸企业甚至科技公司赚的是全球化红利——人口红利、供应链优势，技术不算最顶尖，但胜在性价比高。现在关税壁垒让"靠人多、靠低价"的薄利模式走不通了。

企业面临两个选择：把工厂搬到东南亚，或用技术把成本降下来。AI替代人工是主力方向。

资本为何"怕死"且"去人性化"？

资本第一反应往往不是"培养更多人才"，而是"减少对人的依赖"。

原因很简单：人有情绪，会罢工，会要求涨薪。AI不会——只要服务器运行、有电，它就能24小时工作，没有怨言，不要求股权，不会因为看了个新闻就愤而辞职。

这种对"去人性化"的强烈需求，直接冲击人力资本重建。首当其冲的，是那些受过良好教育、具有较强专业能力、思想活跃的城市中产群体。

讽刺的是：当这些高收入、有话语权、可能对现状不满的群体，突然发现自己的专业技能在AI面前变得一文不值时，他们除了重新学习做"prompt工程师"，还能做什么？

四、AI平权的双刃剑效应

平权机遇的另一面

必须承认，AI确实带来了某种程度上的"平权"。普通人终于有了进入高门槛行业的机会：以前拍电影需要几百万的设备和专业团队，现在一个人拿着手机加AI工具就能生成一部短片；以前做建筑设计需要科班出身，现在画个小图，AI能帮你生成完整的图纸。

然而，当所有人都能轻易进入时，那条赛道还叫赛道吗？

以设计行业为例。假设你是一个入行10年的设计师，当年熬夜画图5年，又熬了5年改图跑项目，才爬到今天的位置。你的专业技能、审美判断、行业人脉是你吃饭的家伙。

现在AI设计工具出来了。一个刚毕业的本科生，花两个月学会prompt，就能在三天内生成你花两周才能做出的方案。那个方案可能细节不够完善、结构有瑕疵、不符合某些行业的设计规范，但甲方看不出区别。甲方只看效果图，只看快不快、好不好。

于是，你的专业壁垒被砸碎了。

价格战的必然结局

技术门槛降低，必然出现大量非科班出身的人涌入。已得利益者会怎么做？他们会开始强调：专业伦理、职业操守、行业规范。听起来很正当，但实际上会用一套新的考核体系，把那些"只会用AI但没有路子的人"重新挡在门外。

以前看设计质量，现在AI让设计质量拉不开差距了。怎么筛选人？就看能不能搞定甲方、认不认识设计院的人。这些软性资源，AI帮不了你，只能靠关系、靠圈子、靠多年积累。

结果是：技术门槛降低了，但关系门槛提高了。

五、已得利益者的"言行不一"

中产在公开场合怎么说AI？全是拥抱的姿态——“我们要积极推动AI变革”、“不能落后于时代”、“要抓住数字化转型的机遇”。各种场合纷纷表态支持AI发展。

为什么？因为公开反对AI等于公开反对进步，等于承认自己已经被时代抛弃。所以他们的策略是：姿态上比谁都积极。

但落地的时候呢？他们可能把AI拦在核心业务外。

一个设计公司的高级合伙人让员工用AI写通知，让实习生用AI查资料，但涉及核心客户的资料、关键项目的方案，他会用AI吗？大概率不会。

他会用自己的经验与私人关系去摸对方的底牌。这些软性信息，这些靠多年积累的关系优势，才真正值钱。这些东西从来不"上网"，不在任何数据库里，只在他的脑子里。

六、未来职场：两个圈子的分化

技术圈与人脉圈

未来，职场可能会分化成两个圈子：

技术圈全是精通AI、一个人当十个人用的"超级个体"。他们能力强、效率高，但他们是干活的人。

人脉圈全是那些有关系、有资源、能调动各方的人。他们可能技术一般，甚至根本不懂技术细节，但他们掌握着项目的入口、审批的关卡、资源的分配。他们是分钱的人。

记住：干活的人分不到多少钱，分钱的人不干活。

AI是更好的管理工具

已得利益者明面上不会反对AI的，AI对他们来说是更好的管理工具。

AI让技术精英变得"可替代"了。以前一个技术大牛，老板还得哄着他，他敢跟老板拍桌子。现在AI把他的能力复制了N份，公司里有无数个"他"，他还哪有底气？

而那些有关系的人，不管AI怎么变，只要审批权还在他们手里，只要项目还得过他们那一关，他们就很难被替代。

关系从未离开

这看起来像是回到"靠关系吃饭"的时代，但"关系"从未离开过，它只是在技术冲击下变得更隐蔽了。

在"拼能力的时代"，能力本身就是一种门槛，能挡住一部分关系户。但现在AI把能力门槛降低了，关系户的劣势被磨平了——你靠关系进来，AI帮你干活，你一样能把事情完成。关系的重要性反而变大了。

七、谁是AI游戏的真正赢家？

这一轮AI博弈，赢家有两类：

第一类：资源掌控者。 他们掌握着资金、人脉、审批权。AI对他们来说是增效工具——用更少的人赚更多的钱。

第二类：极少数的超级个体。 那些把AI玩到极致、能跨界整合、有个人品牌的人。他们不依附于任何组织，自己就是一家公司。

输家是谁？中间层。那些靠专业壁垒吃饭的设计师、会计师、工程师、律师。他们的技能正在被AI替代，经验正在被AI清零。

还有那些以为"学会AI就安全了"的人。当所有人都会用AI的时候，会用的价值就是零。

基于Claude Code的SDD实战（三）：任务拆解及自动实现

Sat, 21 Mar 2026 19:13:42 +0800

大家好，我是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

【再次提醒：一定要审查！】

基于Claude Code的SDD实战（二）：技术规划

Thu, 19 Mar 2026 22:28:42 +0800

大家好，我是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：

@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文档，包含了各模块的职责描述、核心数据结构定义、主要接口声明、模块间的依赖关系等，项目已经初具"骨架”。

基于Claude Code的SDD实战（一）：定义意图

Thu, 19 Mar 2026 00:28:42 +0800

大家好，我是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提问：

我现在想实现一个小工具`down_issue`。
你是一位经验丰富的产品经理，现在需要你向我提问，帮我澄清需求，最终产出一份高质量的`spec.md`。
我初步想法是:做一个命令行工具，输入一个GitHub的Issue、PR、或Discussion的URL，它就能自动把内容扒下来并将其转换为Markdown文件。

现在请开始提问。

AI作为产品经理，会向你输出一系列高质量问题：

第二轮对话：

基于第一轮对话AI提出的问题，我做出了如下回复：

**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思考后，会进一步帮你"具象化"问题，下面是它给到的回复：

AI原生时代的全新开发范式-SDD方法论详解

Wed, 18 Mar 2026 00:21:42 +0800

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 要扮演的新角色：“编译"人类的意图。