创建仓库
This commit is contained in:
111
Go项目实战/03_基础设施/01_错误处理/SOP 增强补丁:长代码&多文件分步生成策略.md
Normal file
111
Go项目实战/03_基础设施/01_错误处理/SOP 增强补丁:长代码&多文件分步生成策略.md
Normal file
@@ -0,0 +1,111 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 🛠️ SOP 增强补丁:长代码/多文件分步生成策略
|
||||
date created: 星期三, 十二月 10日 2025, 9:21:58 上午
|
||||
date modified: 星期三, 十二月 10日 2025, 9:34:54 上午
|
||||
---
|
||||
|
||||
# 🛠️ SOP 增强补丁:长代码/多文件分步生成策略
|
||||
|
||||
核心原则: 原子化交付 (Atomic Delivery)。
|
||||
|
||||
不要命令 AI “写完这个模块”。要命令 AI “写完这个文件” 或者 “写完这个结构体的具体方法”。
|
||||
|
||||
## 策略一:按物理文件拆分 (File-Level Sharding)
|
||||
|
||||
对于基础设施模块,通常可以自然拆分为多个文件。
|
||||
|
||||
操作动作:
|
||||
|
||||
修改 SOP 的 阶段三,不再一次性要求生成所有文件,而是分轮次请求。
|
||||
|
||||
### 🤖 优化后的 Prompt 序列
|
||||
|
||||
**第一轮:仅生成错误码定义**
|
||||
|
||||
```Markdown
|
||||
我们先处理 `internal/pkg/code` 包。
|
||||
请仅生成 `code.go` 文件。
|
||||
内容包含:
|
||||
1. package 声明。
|
||||
2. const 常量定义(错误码)。
|
||||
3. 暂时不要包含 `GetMsg` 的具体 map 映射逻辑,只定义常量。
|
||||
```
|
||||
|
||||
**第二轮:生成错误码映射**
|
||||
|
||||
```Markdown
|
||||
很好。现在请生成同目录下的 `msg.go` 文件。
|
||||
内容包含:
|
||||
1. `var msgFlags = map[int]string{…}` 映射表。
|
||||
2. `func Text(code int) string` 方法的实现。
|
||||
注意:请确保引用了 `code.go` 中定义的常量。
|
||||
```
|
||||
|
||||
**第三轮:生成响应结构体**
|
||||
|
||||
```Markdown
|
||||
现在进入 `internal/pkg/app` 包。
|
||||
请生成 `response.go`。
|
||||
实现 `Response` 结构体定义、`NewResponse` 工厂函数,以及 `Success` 方法。
|
||||
暂时**不要**实现 `Error` 相关方法,我们下一步单独写。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 策略二:骨架先行,血肉填充 (Skeleton First, Flesh Later)
|
||||
|
||||
如果单文件(如 `service.go`)依然很长(超过 500 行),使用此策略。先生成接口和空方法,再逐个填充逻辑。
|
||||
|
||||
### 🤖 优化后的 Prompt 序列
|
||||
|
||||
**第一轮:生成骨架 (The Skeleton)**
|
||||
|
||||
```Markdown
|
||||
我们要实现 `UserService`。由于逻辑复杂,请先生成**骨架代码**。
|
||||
要求:
|
||||
1. 定义 Struct 和所有 Method 的签名 (Signature)。
|
||||
2. Method 内部留空,或仅写 `panic("implement me")`。
|
||||
3. 包含完整的各种 import 和结构体字段注入。
|
||||
```
|
||||
|
||||
**第二轮:填充核心方法 (The Flesh)**
|
||||
|
||||
```Markdown
|
||||
现在,请给出 `Register` 和 `Login` 这两个方法的完整实现代码。
|
||||
请直接输出这两个函数的完整内容,无需重复输出 Struct 定义。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 策略三:上下文锚点 (Context Anchoring)
|
||||
|
||||
当你完成了第一部分代码(比如 `code.go`),在开始下一部分之前,需要让 AI **“记住但不输出”**,以节省 Token 并防止幻觉。
|
||||
|
||||
### 🤖 关键 Prompt (用于连接两个步骤)
|
||||
|
||||
```Markdown
|
||||
[用户动作]:
|
||||
(将 AI 生成的 code.go 代码复制到本地 IDE,确认无误)
|
||||
|
||||
[发送给 AI 的指令]:
|
||||
已确认 `code.go` 代码无误。
|
||||
现在,请将以下代码作为**“已知上下文”**存入你的短期记忆,**不要重复输出它**,但在后续生成 `msg.go` 时必须严格遵守其中的常量定义。
|
||||
|
||||
[粘贴 code.go 的完整代码]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ✅ 你的工作流修正建议
|
||||
|
||||
回到你当前的 **错误处理模块**,我建议你采用 **“策略一:按物理文件拆分”**。
|
||||
|
||||
因为你的 `code` 包和 `app` 包本身就应该物理隔离,避免循环依赖。
|
||||
|
||||
**推荐的执行顺序:**
|
||||
|
||||
1. **Prompt:** 生成 `internal/pkg/code/err_code.go` (仅包含 const)。
|
||||
2. **Prompt:** 生成 `internal/pkg/code/err_msg.go` (包含 map 和 Text 方法)。
|
||||
3. **Prompt:** 生成 `internal/pkg/app/response.go` (包含 Response 结构体和 Success/Error 方法)。
|
||||
Reference in New Issue
Block a user