64 lines
2.6 KiB
Markdown
64 lines
2.6 KiB
Markdown
---
|
||
tags: []
|
||
aliases:
|
||
- 🧩 SOP 补丁：MECE 任务拆解协议 (The MECE Protocol)
|
||
date created: 星期三, 十二月 10日 2025, 9:26:43 上午
|
||
date modified: 星期三, 十二月 10日 2025, 9:30:27 上午
|
||
---
|
||
|
||
# 🧩 SOP 补丁：MECE 任务拆解协议 (The MECE Protocol)
|
||
|
||
**适用场景:** 任何代码行数预估 > 200 行，或涉及多个文件交互的大型模块（如：错误处理、RBAC 权限系统、订单状态机）。
|
||
|
||
**插入位置:** 在原有 SOP 的 **[阶段一：契约定义]** 之前执行。
|
||
|
||
---
|
||
|
||
## 阶段 0: 原子化任务拆解 (Atomic Decomposition)
|
||
|
||
**目的:** 将大需求拆解为一组符合 **MECE 原则 (相互独立，完全穷尽)** 的微任务。确保每个微任务的上下文长度都在 AI 的“舒适区”内，且具备清晰的依赖顺序。
|
||
|
||
### 🤖 拆解者 Prompt (复制使用)
|
||
|
||
```Markdown
|
||
你现在是我的 **Tech Lead (技术负责人)**。
|
||
我们要实现 `{模块名称}` 模块。为了防止代码生成中断和逻辑混乱，请不要直接开始写代码。
|
||
|
||
请先执行 **“MECE 任务拆解”**：
|
||
|
||
**1. 依赖分析:**
|
||
分析该模块涉及哪些物理文件？它们之间的依赖关系是什么？(例如：B 依赖 A，则 A 必须先完成)。
|
||
|
||
**2. 原子化切分:**
|
||
将开发工作拆解为 3-5 个“原子任务步”。
|
||
- 每个步骤必须针对**单个物理文件**或**一组紧密相关的函数**。
|
||
- 每个步骤必须是独立的，可执行的。
|
||
|
||
**3. 输出格式:**
|
||
请输出一个 **Markdown Checklist (执行清单)**。
|
||
格式示例：
|
||
- [ ] **Step 1: {文件名}** - {核心职责} (依赖: 无)
|
||
- [ ] **Step 2: {文件名}** - {核心职责} (依赖: Step 1)
|
||
…
|
||
|
||
**模块上下文:**
|
||
{此处粘贴你的需求或 PRD 片段}
|
||
```
|
||
|
||
---
|
||
|
||
## ✅ 你的工作流变更 (Workflow Update)
|
||
|
||
引入此补丁后，你的新工作流变成了：
|
||
|
||
1. **Phase 0 (New):** 发送拆解 Prompt -> **获得清单**。
|
||
2. **Phase 1 (User Action):** 选中清单中的 **Step 1** -> 发送 Prompt：“请执行 Step 1，生成 `code.go`…”。
|
||
3. **Phase 2 (User Action):** 拿到代码 -> 存入本地 -> **锚点确认** ("Step 1 已完成，代码如下…")。
|
||
4. **Phase 3 (User Action):** 选中清单中的 **Step 2** -> 发送 Prompt：“基于 Step 1，请执行 Step 2…”。
|
||
|
||
### 为什么这样做有效？
|
||
|
||
1. **Token 节省:** AI 在生成 Step 2 时，不需要你在 Prompt 里重新描述 Step 1 的需求，只需要把 Step 1 已经生成的代码贴给它作为 Context 即可。
|
||
2. **避免幻觉:** 因为每个 Step 只有一个目标，AI 不会“顾头不顾尾”。
|
||
3. **断点续传:** 如果 Step 2 生成错了，你只需要重新生成 Step 2，而不需要推倒重来。
|