AI 辅助开发方法论：轻量追问 vs 全流程框架

2026/07/01

背景与目标

AI 辅助开发有两条典型路径：

用一套现代 AI 编程工具（如 TRAE）复现这两条路径、换一个熟悉的领域做试验，可以验证方法论是否通用。走完一遍后，应该能回答四个问题：

核心思路：两条路径

轻量追问型（grill-me 模式）

只问不做。核心机制是把需求拆成一棵"设计决策树"，像走迷宫一样沿着每个分叉问下去：

它在每一层决策确认之前，绝不跳到下一层。问完之后，你得到一份清晰的需求说明书，而不是一堆假设错误的代码。

工具等价方案：无需任何额外工具。只需要在提示词里告诉 AI"不要写代码，先把需求追问清楚"。如果想让这个过程更体系化，可以提前写一条规则放进 AGENTS.md。

全流程框架型（SuperPowers 模式）

从需求到交付。Brainstorming 澄清需求 → Spec 出方案 → Plan 拆任务 → subAgent 并行执行 → Review 验证。每个阶段都有 HARD-GATE（硬闸门），不通过就无法进入下一阶段。

工具等价方案：Plan Agent（出方案+拆任务）+ TodoWrite（可视化进度）+ Task/general_purpose_task（子代理执行）+ RunCommand（构建验证）。

何时选哪条路径

场景推荐路径
需求只有一两句话，自己都没想清楚轻量追问型
个人项目、原型验证、快速试错轻量追问型
涉及多个模块的移植/改造，差异项 ≥ 3 类全流程框架型
需要模块隔离、零侵入的工程约束全流程框架型
有明确 Spec 需要 Review 的正式交付全流程框架型

两条路径不互斥——完全可以在一个项目里先用轻量追问把需求澄清，再把澄清后的需求丢给 Plan Agent 走全流程执行。

试验前准备

选一个合适的试验项目

项目筛选标准：

  1. 你熟悉但不会心疼——代码逻辑心里有数，能一眼看出 AI 做对还是做错；就算被 AI 改乱了也不会影响真正的工作。
  2. 有明确的"移植"或"改造"性质——不是从零新建，而是基于已有代码做差异化修改。
  3. 差异项 ≥ 3 类——太少测不出工作流的价值，太多则第一次试验成本过高。

几个推荐的试验方向：

方向基准代码差异项示例
把 CLI 工具移植到新平台某个 Go/Rust 写的命令行工具配置文件格式从 JSON 换成 YAML；输出增加 CSV 导出；新增子命令；模块隔离
给已有 Web 应用加一套主题一个 React/Vue 项目CSS 变量体系替换；布局差异；组件变体；主题切换自测页
把一个数据处理脚本适配新数据源一个 Python 数据处理脚本输入 schema 变化；新增清洗规则；输出格式变化；自测用例
给一个库写新后端适配某个有插件机制的库新 backend 模块；接口适配层；配置注册；集成测试

选好项目后，把基准代码放到 workspace 下。

准备项目上下文文件

在项目根目录新建 AGENTS.md，写入 AI 需要知道的全局信息，它会被工具的 workspace rules 自动加载：

# 项目概述

## 目录结构
（画出关键目录树，标注每个目录的职责）

## 构建/运行入口
（编译命令、启动命令、测试命令）

## 关键约束
- 新增代码收拢到独立模块，不动原有代码
- 所有改动必须有对应的自测
- （领域特有的工程约定）

## 术语表
（领域缩写、专有名词解释）

如果涉及外部规格文档（PDF 手册、协议规范等），提前用脚本转成 Markdown 放在项目目录下。AI 读取 Markdown 的准确率远高于直接读 PDF。

路径 A：轻量追问型（grill-me 模式）

适用场景：需求模糊、快速澄清思路、个人项目或原型阶段。

核心理念：设计决策树

把需求看作一棵树。根节点是核心目标（“我要加一个用户登录”），每个分支是一个决策点（用什么方式登录？Session 怎么存？错误处理策略？）。AI 的职责是从根节点出发，逐层向下，在每个分叉点追问，直到所有分支都被确认。

操作步骤

第一步：设定规则

在对话开头或 AGENTS.md 中加入以下约束：

在处理任何开发需求时，遵循以下规则：

  1. 先追问，后动手：在完全澄清所有需求细节之前，不写一行代码。
  2. 设计决策树：将需求拆解为决策树，从根节点（核心目标）开始逐层向下。在上一层决策确认前，不跳到下一层。
  3. 主动搜索代码库：能通过阅读现有代码回答的问题，不要问用户。
  4. 给出推荐并请用户确认：当有多个合理选项时，给出推荐方案并说明理由，而不是让用户面对空白选择。

第二步：描述你的需求

用一两句自然语言描述要做什么。故意写得模糊一些——这样才能测出追问的质量。例如：

我想在我的 [项目] 里加一个用户登录功能。

如果 AI 直接开始写代码，说明追问规则没生效，检查规则是否写进了 AGENTS.md 或在对话开头明确强调了。

第三步：逐一回答追问

AI 会连续追问，每个问题都应该是选择题或判断题（而不是开放式问题）。典型的好问题长这样：

登录方式有三个选项：A) 手机号+验证码 B) 邮箱+密码 C) OAuth（微信/Google）。考虑到你的用户主要在国内，推荐 A+C 组合，你觉得呢？

而不是：

你想怎么做登录？

第四步：确认需求摘要

追问结束后，让 AI 输出一份需求摘要。逐条确认，这就是后续开发的 Spec 基础。

追问质量判断标准

一次好的追问应该满足：

路径 B：全流程框架型（SuperPowers 模式）

适用场景：多模块移植/改造、需要模块隔离的正式项目、需要 Spec Review 的交付场景。

阶段 1：需求对齐（Brainstorming）

目标：让 AI 理解"要做什么"和"为什么这样做"，而不是直接动手。

做法：用自然语言描述需求，但不要一次性把细节全倒出来。采用对话式递进——先给主干差异，等 AI 提问后再补细节。

示例提示词：

我有一个 [项目名]，代码在 src/ 下，当前能在 [原环境] 正常运行。现在要把它移植到 [新目标]。

主要差异：

  1. [差异一]
  2. [差异二]
  3. [差异三]

先把你的理解复述一遍，列出你觉得需要澄清的问题。暂时不要改代码。

质量判断标准：

你的把关动作：确认 AI 的理解与你一致。不一致就纠正，缺漏就补充。

阶段 2：出方案（Spec）

目标：把对齐后的需求转化为一份结构化的方案文档。

让 AI 输出 Spec，包含以下要素：

关键原则：模块隔离（HARD-GATE）

最值得学的一课来自一次失败：第一版 Spec 被驳回，因为 AI 把改动散落在了原有 package 里；第二版要求所有新代码收拢到独立的板级 package，对原代码零修改。在试验中同样要强调：

所有新代码必须在独立模块中，通过注册/挂载机制接入原有系统，不得直接修改原有文件。如果无法做到零侵入，先说明理由。

你的把关动作：逐条检查 Spec 中的落点。一旦发现 AI 把改动塞进了不该动的地方，驳回重写。这是全程最重要的把关点。

阶段 3：拆任务（Plan）

目标：把 Spec 拆成可独立执行的 Task 列表。

做法：使用 Plan Agent，给它 Spec 内容，让它输出 TodoWrite 格式的任务列表；或直接让 Plan Agent 从需求对齐开始全流程规划。

一份合格的 Plan：

阶段 4：执行（Execute）

目标：按 Plan 顺序执行每个 Task。

使用 Task（general_purpose_task）派发每个 Task。每次只派一个，等它返回结果后再派下一个。

为什么用 subAgent 而不是在主对话里直接改：

执行期间注意事项：

阶段 5：验证与收尾（Review）

  1. 构建验证：跑完整的编译和测试命令
  2. 功能验证：运行项目，手动验证差异项是否生效
  3. 代码审查：让 AI 输出改动总结，与 Spec 逐条对照

收尾检查清单：

双路径组合试验（推荐）

最完整的试验是两路径串行：先用轻量追问澄清需求，再用全流程框架执行。

  1. 故意写一段模糊需求（一两句话）
  2. 启动轻量追问模式，让 AI 把需求追问清楚，输出需求摘要
  3. 把需求摘要 + Spec 要求 + 模块隔离约束，一起喂给 Plan Agent
  4. Plan Agent 输出 TodoWrite 任务列表
  5. 审核 Plan，确认通过后逐个派 Task（subAgent）执行
  6. 构建验证，审核收尾

这样在一轮试验里同时测了两条路径。

试验记录建议

走完一遍后，记录以下信息：

## 试验记录

- 项目：
- 领域：
- 使用路径：轻量追问 / 全流程框架 / 组合
- 差异项数量：
- 新建文件数 / 修改文件数：
- 总耗时（人类参与时间 / AI 执行时间）：
- 追问次数（轻量路径）：
- Spec 被驳回次数（全流程路径）：
- AI 自行踩坑次数及类型：
- 编译/运行报错次数及是否 AI 自行修复：
- 最终产物是否可用：

## 路径对比感受
（轻量追问的追问质量如何？追问深度够不够？全流程框架的 Task 拆分粒度是否合理？subAgent 执行是否可靠？）

## 关键收获
（最大的价值在哪里？最大的痛点在哪里？）

## 下一步
（是否值得沉淀为 Skill？哪个环节最需要自动化？）

常见问题

Q: AI 总想把改动塞进原有模块怎么办？

在 Spec 阶段明确约束，在 Plan 阶段再次强调。如果执行阶段仍然犯规，说明 Spec 写得不够硬。可以在 AGENTS.md 里把模块隔离写成铁律。

Q: 轻量追问模式下 AI 追问太少/太浅怎么办？

在规则中补一句：「对每个技术决策，至少追问到数据模型和接口契约层面再停止」。如果 AI 追问的粒度偏粗，在回复里主动引导：「这个点还可以追问得更细，比如 X、Y、Z 这几个维度你还没问到」。

Q: AI 对领域的专业概念理解有偏差怎么办？

给文档。把关键规格书、接口定义、术语表转成 Markdown 喂进去。文档质量直接决定 AI 的理解质量。如果某个概念 AI 反复理解错，单独写一段解释放在 AGENTS.md 或项目 README 的显眼位置。

Q: Task 工具派发的 subAgent 返回后，发现结果不对怎么办？

回到 Spec 确认需求有没有歧义。如果 Spec 没问题，检查 Task 的描述是否把验收标准写清楚了。如果都对了还是出错，可能是 AI 能力边界问题——考虑把大 Task 拆成更小粒度，或者在关键步骤增加人工确认点。

Q: 编译链/运行环境怎么配？

常见工具链（GCC、Python、Node.js 等）可以直接用。如果是特殊工具链，需要提前在本地编译安装好。

进阶：沉淀为 Skill

试验成功后，如果发现这套流程在自己的领域里可复用，可以把它沉淀为一个领域专属 Skill。一个领域 Skill 至少包含：

参考