# ⚙️ 标准修复/开发工作流（铁血流程）

> 来源: OpenAI Codex Best Practices + Google Cloud Code 官方文档
> 核心思想: **流程比记忆更可靠。先走流程，再调经验。**

---

## 一、Codex 标准 4 步修复流程

### Step 1: 收集素材（这里决定 90% 成败）

```
目标 (Goal)     → 要修什么？期望行为是什么？
上下文 (Context) → 哪些文件/日志/错误信息相关？ @ 提及具体文件
约束 (Constraints) → 不改什么？API保持？架构不变？
完成条件 (Done when) → 测试通过？Bug不再复现？行为变了？
```

**好的 prompt：**
```
Goal: 修复登录后重定向循环
Context: src/middleware.ts, src/lib/auth.ts, /login 流程
Constraints: 不改数据库schema，保持JWT策略，不做无关重构
Done when: 已登录用户刷新/dashboard不再重定向到/login
```

### Step 2: 先计划，再动手

```
/plan 模式 → Codex 先探索代码库 → 出方案 → 你确认后再执行
```

跳过规划步骤是导致"改了一个地方坏了三个"的头号原因。

### Step 3: 改 + 验证

```
改 → 运行测试 → lint检查 → typecheck → 确认行为
```

### Step 4: 追加测试（防止回退）

```
"针对刚才的修复，加一条防止回归的测试"
```

---

## 二、通用故障排查流程

任何时候遇到问题，按这个顺序走：

```
1. 看状态（健康检查/logs/进程状态）
2. 收集证据（错误信息/复现步骤）
3. 对比正常环境（diff配置/diff代码）
4. 定位根因（不是表象）
5. 修复最小改动
6. 验证（测试/行为确认）
7. 记录（写进经验库，下次不用重查）
```

---

## 三、修改代码的标准流程（防手贱）

```
1. 先读文件（cat/Read 确认当前内容）
2. 保存备份（git commit 或 cp）
3. 改最小范围（只改需要改的）
4. 运行 lint + typecheck + test
5. 确认行为符合预期
6. 如果没用上 → git checkout 恢复干净
```

---

## 四、Google Cloud Code 调试流程（Kubernetes）

```
1. 配置 skaffold.yaml + Dockerfile
2. 点击 Run on Kubernetes → 自动构建/推送/部署
3. 端口转发 + 附加调试器
4. 设断点 → 发请求 → 命中断点
5. 检查变量 → 步进 → 定位根因
6. 热重载（改代码 → 秒级生效）
```

---

## 五、GitHub PR 标准流程

```
1. 创建分支（feature/fix-xxx）
2. 改代码 + 本地验证
3. 提交（遵循 commit message 格式）
4. push → 创建 PR
5. 触发 CI 自动测试
6. Code Review
7. Merge → 部署
```

---

## 六、铁律：什么时候该查 vs 什么时候该信

| 场景 | 做法 |
|:-----|:------|
| 配置项/服务器信息 | 先查知识库(60%)，再 SSH 确认(40%) |
| 代码修改 | 先读当前文件，不信记忆 |
| 踩坑经验 | 知识库可靠，但先确认环境没变 |
| 流程步骤 | 流程100%可靠，照做就行 |
| 有多个智能体工作过 | **必须核查**，知识库可能已过时 |