作者：诗唐，蚂蚁集团-工业化数据体系部

一、从 Vibe Coding 到 Spec Coding

使用Vibe Coding 遇到的几个问题

现在做一些需求 或 修复bug的时候，很少再"古法编程"，基本都是通过AI来写的，但是当遇到一个功能需要多次迭代，或者维护业务系统的存量代码时，Vibe Coding还是会存在一些问题，让AI变得不那么好用。例如：

1）可验证性缺失

判断代码好不好全靠"感觉对不对"。没有单测覆盖率、没有接口契约、没有边界条件的硬标准。代码写完了不知道该怎么验证"对不对"，没有规则、没有边界条件、没有回归验证，最后只能靠肉眼看 diff，或者本地点两下页面。这种流程，应对简单任务尚可，但在面对大型任务或存量项目维护时，显然力不从心。

• 例如：让AI改完代码之后，通过人工diff发现修改的代码有一个关联的方法没有修改，在提交代码时发现，需要再次让AI修改

2）上下文衰减——AI 记不住规则

如果在本次任务中提过很多要求和规则，但是过几天做新任务或者继续迭代的时候，换了个工具，就忘记为什么这样设计，一些约束和规则又要重新告诉AI一遍，非常繁琐

• 例如：提前说明了需要使用worktree来写代码，但是AI在执行过程中忽略掉了

3）没有系统性的解决问题或者全面review

提一个需求/问题，AI解决一个，如果有多个问题，需要不断的一轮一轮去追问，来来回回不断的提问->修复->验收，整体效率低，并且Token消耗也不少，没有系统性的解决问题或者全局视角去评判

• 例如：生成代码之后没有对应的验证边界情况，需要一轮一轮的提出诉求才能做的更好

- Q:   SQL查询结果预览要兼容 `[[biz_in_id, 11], [poi_id, 5], [event_id, 8]]` 这种输入。  
- AI： 改好了。现在预览会直接保留原始格式，超出长度时再追加 `...（共N行）`。  
- Q：  你测了哪些输入？空数组、单行、嵌套异常、超长数据都看过了吗？  
- AI： 我主要基于当前给的示例做了兼容，其他边界情况还没有系统验证。
- Q:   请生成不同的case验证代码是否正常工作
- AI:  ......

4）怎么更好的让AI Coding从个人好用到团队好用

当前基本都是AI写代码，工作流和规则如何沉淀为在团队中可以落地的规则，不仅仅一个人好用，并且可以让AI在团队的Vibe Coding时更高效、更可控，通用的规则沉淀下来协作起来效率更高

什么是规范驱动开发(Spec-Driven Development)

规范驱动开发（Spec-Driven Development，以下简称SDD）可以理解为 AI 时代的一种研发方法重构：它将之前Vibe过程中的“需求直接传递到代码”的理念，升级为“需求定义—规范建模—文档沉淀—实现与验证”的闭环。其关键不在于增加文档和规范环节，而在于让结构化、可执行、可验证的规范成为开发过程中的统一依据，作为需求、设计、实现和验收之间的事实基线，减少对零散对话、口头说明和个人经验的依赖。

SDD可以理解为一种把决策前置、把上下文持久化的开发方式，它和过去那种文档流程不太是一回事。

后者常常是为了开发设计存档、流程而写，前者是为了让复杂协作可控而写；后者面向存档，前者面向执行。尤其在 AI 参与开发之后，Spec 的价值更明显：它不只是给人看，也是在给模型“划定工作空间”，在复杂任务或大型需求中，规范越清楚，AI 的输出相对越稳定。

二、Vibe Coding vs Spec Coding

**SDD（Spec-Driven Development）**概念就随之产生 —— 先写规范再写代码，让模型在有约束的空间里工作。

用一句话概括这个转变：

从“我来回提醒 AI 该怎么做”，变成“把规则和目标沉淀成项目资产，让 AI 每次都按同一套约束做”。

• Vibe Coding = 凭直觉写代码，快速开始，"理解"是一次性的
• Spec Coding = 先定规矩再写代码，规范文件是基础

实践中Spec Coding的局限性

于是我尝试在AI Coding的时候加入Spec Coding去实现一些需求和任务，总结下来还是会有很多问题，有些好像体验下来并没有太大的提效，有些反而会降效

通过SDD的流程来写代码的过程也会遇到一些副作用：

1. 前期成本高
   • 需要大量时间编写详细规范，对于快速需要执行的任务而言是负担
   • 需求模糊或探索性项目中，过早固化规范会导致方向错误
2. 任务执行慢，
   • 当执行完整的工作流时，整体的流程会很长，并且每一轮需要探索很多上下文，如果是大型需求/复杂的重构，成本可以接受，如果是简单任务，反而会降低效率
3. Token消耗多
   • 同理，当任务流程长，与AI交互次数变多，Token消耗也会随之倍数增长

根据不同的任务、不同的场景选择合适自己的工作流是最重要的

Vibe和Spec如何选择

这些场景我通常直接Vibe Coding来实现：

• 一句话能说清的小需求
• 只改 1～2 个文件
• 很明确的 bug fix
• 临时脚本、demo、探索验证
• 就算写错了，返工成本也很低

下面这些任务，我基本都会进入 Spec 模式：

• 涉及多个模块，不是一处改动
• 需求描述里有歧义，需要先对齐理解
• 旧系统改造，改动边界不容易一下看清
• 需要多人协作，不是单兵作战
• 后续会持续维护，不是一次性交付
• 结果不能只靠“看起来没问题”，必须可验证

所以关键不是“Vibe 还是 Spec 哪个更先进”，而是在合适的场景下使用合适的更优的方式

三、Spec Coding工作流编排实践

过去一段时间社区里已经出现了很多比较有代表性的实现路径，它们名字不同、结构不同，但本质上都在回答同一个问题：怎样把需求、边界和验证方式先固定下来，再让 AI 去写代码。

名称	主要定位	一句话特点	核心关注点	更像什么	更适合
OpenSpec	规范框架	管理需求变更规范化	变更规范化、增量开发	变更管理器	存量系统、通用团队、低侵入
SpecKit	规范框架	先立"宪法"再分阶段执行	架构约束、阶段化设计	项目宪法	复杂项目、前期设计重
GSD	规范 / 上下文框架	讨论-规划-执行-验证四段闭环	上下文工程、任务结构化	上下文控制器	长任务多、上下文容易失控
Superpowers	执行工作流	把工作方法封装成可复用 Skills	计划拆分、TDD、子代理协作	工程执行手册	后端、重构、强调纪律的团队
gstack	角色化工作流	前端+产品化全流程 Skills	评审、QA、浏览器验证、发布链路	虚拟工程团队	前端、产品审查、测试、上线验证

根据社区中不同的AI编程工具，可以分为以下几个层级，不同层级有不同的代表性框架：

看起来工具虽多，但职责有不同的偏好——有的管"需求怎么结构化"，有的管"如何高效执行"，如果按照工程交付流程：需求澄清 → 方案设计 → 实现 → 验证 → 维护的模式来划分，可以分为【规范层】、【执行层】、【工具层】等

我的Spec工作流编排全流程

我的Spec Coding主要是通过三个工具覆盖全流程：

阶段	工具	何时使用
规划	OpenSpec	需求探索、方案设计、任务拆分
执行	Superpowers	TDD、实现计划、并行开发、代码验证
质量	gstack	方案审查、QA 测试、代码审查、部署

完整的9步流程如下：

阶段	步骤	命令	一句话说明
规划	1. 探索需求	/opsx:explore	只读，认知对齐
	2. 生成提案	/opsx:propose	产出proposal + design + tasks + spec文档
执行	3. 细化计划	superpowers:writing-plans	原子步骤 + 依赖图
	4. 开发执行	TDD / SubAgent	顺序或并行
质量	5. 代码审查	/gstack-review	做code review
	6. QA 测试	/gstack-qa	系统化测试、原子修复
	7. 最终验证	verification	再次校验，是否符合规范和任务要求
收尾	8. 提 PR	/gstack-ship	版本号 + CHANGELOG
	9. 归档	/opsx:archive	specs/ 更新，闭环，文档归档

第 1 步：核心是判断任务值不值得走全流程

不是每个任务都配得上完整规范流程。可以先按下面这个标准判断：

任务类型	建议
一句话能说清、只改 1-2 个文件、简单任务	直接做，但保留验证
涉及多个模块、需求有歧义、需要团队对齐	先写 proposal / design
旧系统改造、改造风险高、复杂/模糊任务	一定走完整闭环

这个判断很重要，流程太重，会拖慢节奏；流程太轻，返工会吞掉前面的“快”。

第 2步：探索，根据任务需求把问题讲清楚

/opsx:explore 这一阶段的目标不是产出代码，而是把问题说清楚：

• 用户真正要的是什么
• 这次改动边界到哪
• 哪些是必须项，哪些是可选项
• 当前系统里有哪些限制

这一步常见错误是，问题还没澄清，AI 已经开始写实现了。

第 3 步：把需要做的变更固化到文件中

/opsx:propose 这一步的关键不是“写很多字”，而是把下面三件事写明白：

• proposal：为什么做、改什么、不改什么
• design：技术方案、关键权衡、风险点
• tasks：可执行任务拆分
• 这阶段的项目结构：

your-project/
├── openspec/
│   ├── config.yaml              # 配置文件
│   ├── specs/                   # 当前系统的规范基线（事实来源）
│   │   └── <能力名>/
│   │       └── spec.md
│   └── changes/                 # 变更提案（增量开发区）
│       ├── <变更名>/            # 进行中的变更
│       │   ├── proposal.md      # 为什么做 + 改什么 + 影响范围
│       │   ├── design.md        # 技术方案 + 决策记录 + 风险
│       │   ├── tasks.md         # 结构化任务清单
│       │   └── specs/<id>/
│       │       └── spec.md      # 本次变更的需求规范

第 4 步：让AI根据需求规范写详细的执行计划

superpowers:writing-plans 让AI根据上一步定义的需求规范制定更细粒度的执行计划

• 做什么：把 tasks.md 拆成 2-5 分钟的原子步骤，确定执行顺序、依赖关系、涉及文件，每步附带验证标准
• 产出：docs/superpowers/plans/<日期>-<name>.md（完整实现计划，含架构、文件结构、每个 Task 的步骤 + 代码骨架）
• 要点：原子步骤的粒度很重要——太粗 AI 容易跑偏，太细又浪费时间
• 这一阶段的项目结构如下：

your-project/
├── openspec/
├── docs/
│   ├── superpowers/                     # superpowers文档
│   │       └── plans/                   
│ 	│   │       └── <日期>-<name>.md`     # superpowers执行计划md

第 5 步：开始执行代码变更

可以用一个简单判断：

• 有明显依赖关系的任务，顺序推进 -> superpowers:executing-plans
• 彼此独立、写入范围不冲突的任务，交给子代理并行 -> superpowers:subagent-driven-development

这一步是真正执行开发，可以选择不同的方式来执行。

第 6 步：执行完成之后再次 Review 和 QA

/gstack-review 、 /gstack-qa 主要是做改动的code review和代码实现相关能力，让AI再次校验是否还问题并给出修复建议

• 产出：审查意见（会话内输出）
• 要点：这是 gstack 的强项，28 个专业角色视角的审查比自己肉眼看更全面

第 7 步：归档，把本轮经验沉淀到文件中

/opsx:archive 将完成的 Spec中的change 移入archive目录，保持工作区整洁

• 产出：openspec/changes/archive/<日期>-<name>/（完整的变更快照）
• 要点：归档后 specs/ 基线已更新，下一轮迭代的起点更准确
• 本轮的项目结构概览

your-project/
├── docs/
│   ├── superpowers/                     # superpowers文档
│   │       └── plans/                   
│ 	│   │       └── <日期>-<name>.md`     # superpowers执行计划md
├── openspec/
│   ├── config.yaml              # 配置文件
│   ├── specs/                   # 当前系统的规范基线（事实来源）
│   │   └── <能力名>/
│   │       └── spec.md
│   └── changes/                 # 变更提案（增量开发区）
│       ├── <变更名>/            # 进行中的变更
│       │   ├── proposal.md      # 为什么做 + 改什么 + 影响范围
│       │   ├── design.md        # 技术方案 + 决策记录 + 风险
│       │   ├── tasks.md         # 结构化任务清单
│       │   └── specs/<id>/
│       │       └── spec.md      # 本次变更的需求规范
│       └── archive/             # 本轮已完成的变更归档
│           └── <日期>-<名称>/
│               └── ...          # 完整快照（只读）

通过CLAUDE.md / AGENTS.md编排自己的工作流

OpenSpec 有自己的命令，Superpowers 有自己的 Skills，Gstack 有自己的角色命令。这三套东西各自有各自的"下一步建议"。如果不做统一编排，你每次做完一步都要自己想"下一步该执行哪个指令"反而绕晕自己

所以，我直接把~~~~想组合的工作流放到CLAUDE.md / AGENTS.md中，一个典型的项目根目录长这样：

project/
├── CLAUDE.md              # 项目级约定（架构、规范、禁忌）
├── .claude/
│   ├── rules/             # 硬性约束（必须做 / 不能做）
│   ├── commands/          # 自定义命令
│   ├── agents/            # 自定义 agent
│   └── skills/            # 项目级 skill
├── specs/                 # OpenSpec 归档
├── changes/               # 进行中的变更
└── src/

• CLAUDE.md 完整开发工作流内容如下：

## Development Workflow

### 是否触发完整工作流

收到任何涉及方案讨论、想法探索、问题分析或代码变更的请求后（不仅限于明确的编码任务），先评估改动规模、复杂度和需求清晰度，决定是否需要走完整工作流：

| 规模 | 判断标准 | 执行方式 |
|------|---------|---------|
| **Trivial** | 单文件小改动、修 typo、简单配置调整 | 直接实现，不触发工作流 |
| **Small** | 2-3 个文件、逻辑简单、需求明确、无架构影响 | 跳过规划阶段，直接写代码（可选 worktree） |
| **Medium+** | 多文件、新功能、涉及架构或跨模块 | 触发完整工作流（规划→执行→质量→交付） |
| **模糊/探索性** | 需求不明确、需要讨论方案、涉及多种可能的实现方向 | 触发工作流，从 `/opsx:explore` 开始梳理需求 |

评估后向用户说明判断结果和理由，让用户确认。如果用户明确要求走/不走工作流，以用户为准。

### Phase 1: 规划 (在 main 分支上)

| 步骤 | 命令 | 说明 |
|------|------|------|
| 1 | `/opsx:explore` | 探索需求、明确问题 |
| 2 | `/opsx:propose` | 生成 proposal + design + tasks |
| 3 | `superpowers:writing-plans` | 根据 `openspec/changes/<name>/tasks.md` 细化实现计划 |

### Phase 2: 执行

执行阶段需要做两个独立决策：**是否隔离** 和 **执行模式**。

#### 决策 1: 是否使用 worktree 隔离

| 任务规模 | 隔离方式 | 说明 |
|---------|---------|------|
| **Small** | 直接在 main 开发 | 改动小、风险低，无需隔离 |
| **Medium+** | 使用 worktree + feature 分支 | 改动大、需要隔离保护 main |

#### 决策 2: 选择执行模式

| 任务特征 | 执行模式 | 说明 |
|---------|---------|------|
| 单个任务或少量简单改动 | `superpowers:test-driven-development` | 直接 TDD 写代码，不涉及任务编排 |
| 多个任务、有先后依赖 | `superpowers:executing-plans` | 单会话按计划顺序执行 |
| 多个独立任务 | `superpowers:subagent-driven-development` | subAgent 并行，各自独立上下文，自带 review |

#### 两个决策的组合

Small 任务:
└── 在当前分支直接 TDD

Medium+ 任务:
├── 单任务 → 手动调用 using-git-worktrees 创建隔离环境，然后 TDD
├── 多任务紧耦合 → executing-plans（自动创建 worktree）
└── 多任务独立 → subagent-driven-development（自动创建 worktree）

**说明**:
- `executing-plans` 和 `subagent-driven-development` 内置了 worktree 生命周期（自动创建 + `finishing-a-development-branch` 合并），无需手动管理。
- `test-driven-development` 是纯编码方法论（红→绿→重构），不管理 worktree 和分支。如果 Medium+ 任务只用 TDD，需要**先手动调用 `superpowers:using-git-worktrees`** 创建隔离环境。
- 提示用户时说明推荐的组合和原因，让用户确认或调整。

### Phase 3: 质量 (在合并前)

| 步骤 | 命令 | 说明 |
|------|------|------|
| 5 | `/gstack-review` | 代码审查 |
| 6 | `/gstack-qa` | QA 测试 |
| 7 | `superpowers:verification-before-completion` | 最终验证 |

### Phase 4: 交付

| 步骤 | 命令 | 说明 |
|------|------|------|
| 8 | `/gstack-ship` | 提 PR 部署 |
| 9 | `/opsx:archive` | 归档完成的 change |

### 步骤衔接

每个 skill 完成后，**必须按此工作流提示下一步**（而非使用 skill 内置的默认提示），并说明输入来源。示例：

> `/opsx:propose` 完成 → "执行 `superpowers:writing-plans` 根据 `openspec/changes/fix-report-localization/tasks.md` 细化实现计划"

> `writing-plans` 完成 → "任务间相互独立，推荐使用 `subagent-driven-development` 并行执行。是否确认？"

### Worktree 与分支

- **目录**: `.worktrees/`（需在 .gitignore 中）
- **分支名**: `feat/<change-name>`（与 openspec change name 一致）
- **生命周期**: `using-git-worktrees`（创建）→ 执行 → `finishing-a-development-branch`（合并/PR/保留/丢弃）
- **合并冲突**: 自动尝试解决，展示方案让用户确认后再提交。不静默合并，不跳过冲突文件。
- **执行完成后检查**: Phase 2 完成后，执行 `git worktree list` 检查本次变更是否在 worktree 的 feature 分支上开发。如果是，提示用户通过 `finishing-a-development-branch` 选择合并方式（合并到 main / 推送创建 PR / 保留 / 丢弃），确保代码不会遗留在未合并的 feature 分支上。如果本次变更不在 worktree 中（如 Small 任务直接在 main 开发），则跳过此步。

### 可选技能 (按需在任意阶段穿插)

| 技能 | 触发时机 |
|------|---------|
| `/gstack-plan-ceo-review` | proposal 完成后，需要从产品/商业角度审查方案 |
| `/gstack-plan-eng-review` | design 完成后，需要从技术架构角度审查方案 |
| `/gstack-plan-design-review` | 涉及 UI/UX 变更，需要从设计角度审查方案 |
| `/gstack-investigate` | 遇到复杂 bug，需要深入调查根因 |
| `/gstack-retro` | 一个 change 完成后，回顾总结经验教训 |

四、Spec Coding案例实践

这一节介绍~~~~在业务需求中使用案例，完整的工作流实践和灵活按需使用两种方式，目的是更好的使用来提升效率，而不是为了使用而使用

案例一：从0到1的新功能，创建NL2SQL Skill

背景：需要创建一个DeepInsight 的NL2SQL Skill发布到Skill市场，提主要是通过将用户基于数据集的自然语言转换为SQL并提交查询并轮询结果展示。

这种任务的特点是：

• 需求不算一句话能说清，有一些上下文知识和我自己的想法
• 需要让AI根据我的想法和知识对齐，尽量减少返工，避免改动内容相差较大
• SKILL如何优化能够更好的触发并且遵循完整的工作流程
• 涉及提示词、查询安全、结果解释、错误处理、接口如何调用
• 后面还会不断迭代和优化

Step 1. 探索阶段

/opsx:explore

这一步我和 AI 花了约 10~15 分钟对齐这个项目如何来做，其中有哪些规范和具体的流程：
- 依赖什么环境？→ 依赖DeepInsight MCP中哪些工具
- 整体的流程 -> step1->step2->step3->step4等
- 轮询策略？→ 因为是异步查询，当前轮询间隔2～3s
- 核心规则是什么 -> 1. 先查找数据集，如果找不到那么再搜索用户有权限的数据集 2. 什么时候需要反问澄清等等逻辑
- 返回结果处理 -> 用什么方式表示，如果结果太多的边界条件等等
- 关键约束 -> 多轮对话的上下文约束、超时处理等

Step 2. 生成变更规范

/opsx:propose

AI 一次性生成了四个文件：

• proposal.md：NL2SQL Skill 的价值定位、功能范围、影响面分析
• design.md： 具体的目标有哪些、有哪些关键功能设计、错误码设计
• tasks.md：每个功能具体的任务任务，分几个阶段
• specs/nl2sql/spec.md：完整的 WHEN-THEN 场景定义

审查重点：在 design.md 和task.md上花了最多时间——逐步审查是否符合需求，不符合的可以和AI进一步交互修改。并且重点是产出了验收规范

Step 3. 细化计划

superpowers:writing-plans 根据上述的规范生成执行计划

这一步生成的执行计划文件中，把每一步任务被拆成 N 个原子步骤，并且每个任务非常详细的说明代码和工作流如何写，SKILL中的每个模块如何拆分

Step 4. 开发执行

根据依赖图采用组合模式：

• 阶段 A（并行）：用 SubAgent 并行执行 3 个独立模块——SQL 生成器、Schema 加载器、输出格式化器
• 阶段 B（顺序）：用 TDD 顺序处理集成逻辑——模块串联、端到端测试、错误处理

Step 5-7. 质量闭环

/gstack-review  → superpowers:verification

• 在这一步还是有一些优化，AI发现SKILL的descrption表达可以进一步优化

Step 8-9. 收尾

/gstack-ship → /opsx:archive

代码提交，变更归档，specs/ 基线更新。

下一次优化SKILL的内容和功能，就可以依赖归档的进一步优化，能够更好的理解本次的设计和逻辑

案例二：已有功能优化：优化NL2SQL Agent评测链路切换模型逻辑

再看另一类更常见的场景：已有系统里已有一个功能模块，现在要做优化。

这种任务是比较常见的：在现有的工程链路下修改某个功能，并且功能改动不算大，改动需要可控并且不影响其他功能

Step 1. 逻辑明确，直接生成规范

/opsx:propose 读取这个dima：https://xxx.com/mock_000001/detail?id=mock_0001&status=status
目标是：text2SqlChat在评测链路下调用模型的时候判断是否需要兜底
逻辑如下：
1. 评测链路 + 开关配置打开则切换到备用模型
2. 根据开关配置决定是否切换
3. 只在text2sql链路下生效

• 中间讨论了很多细节，例如：
  • 配置项使用哪个
  • 参数应该从哪个对象获取才是正确的
  • 应该限制在什么链路下才生效

Step 2. 生成执行计划计划

superpowers:writing-plans

• 这一步生成详细的执行计划

Step 3. 开发执行

superpowers:subagent-driven-development

• 因为改动比较小，所以直接使用推荐的执行方式即可

Step 4 Review 和 归档

/opsx:archive

这个任务的代码改动相对可控，方案审查没问题之后，很多中间步骤就跳过了。

不用每次都跑完全套流程，根据任务选合适的工作流，才是最高效的。

---

五、经验与踩坑

5.1 什么时候该写 Spec，什么时候不用

Spec Coding 不是银弹，什么时候要定义Spec，我自己的判断标准是：__任务复杂度 × 出错代价 x 执行效率。

• 任务复杂/不明确 + 长周期 + 高代价 → 写 Spec更优
• 简单任务 + 快速执行 + 低代价 → Vibe Coding 照样好用

不是所有任务都需要 Spec，而是需要根据合适的任务选择合适的工作流，选择合适的才是最好的，使用错了反而会降低效率。毕竟使用AI的目的是提效，而不是为了用而用

我个人理解Spec也只是在现阶段对模型能力不够强的妥协

5.2 规范粒度怎么控制

Spec 的边际收益递减：每个 change 只解决一个明确问题。如果你发现一个 Spec 写了 很多 还没写完，说明粒度太粗

遵循 OpenSpec “iterative not waterfall” 哲学：

• 每个变更只解决一个明确问题
• Spec 过度设计 = 浪费时间
• Spec 不足 = 返工更浪费时间
• 平衡点在"能指导 AI 正确执行"——如果 AI 看了你的 Spec 还要猜，说明不够；如果 Spec 比代码还长，说明过了

5.3 工具服务于目标

不是所有的工具全上效果更好，而是根据项目实际情况组合：

• 新项目标配：OpenSpec + Superpowers（覆盖规范 + 执行）
• 需要质量审查时加 gstack（Code Review + QA + 浏览器测试）
• 简单项目可以只用 Superpowers/Gstack等单一框架都行
• 快速原型可以直接Vibe
• 不要为了"用全"而用全，工具服务于目标

5.4 其他的一些问题说明

问题	症状	应对
代码风格冲突	AI 有自己的规范，老项目也有原本的风格/自己的代码风格	在 specs/rules 或 .claude/rules/ 中明确标注风格要求
老旧依赖不兼容	AI 引入新版本 API，但项目锁定旧版本	系统规范中标注依赖版本约束，explore 阶段提前约束
上下文溢出	对话越来越长，AI 回答越来越差	分批执行或用 SubAgent 并行

六、写在最后

以上只是我个人的阶段性实践，不代表最佳实践。AI 编程还在快速演进，现在的经验到下个月可能就过时了 或者被更好的东西替代掉。

但有一点还是比较确定：不管工具怎么变，"先把需求讲清楚再动手"这件事永远不会过时。区别只在于你是跟人讲清楚，还是跟 AI 讲清楚。

如果有更好的实践，欢迎一起交流～