You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

10 KiB

Raw Blame History Unescape Escape

applyTo
Doc/**

AI 辅助开发流程指令

适用于新建应用系统、新增功能模块、需求整理、架构设计等研发全流程任务。

1. 流程总览

需求整理 → 需求评审与拆分 → 技术方案设计 → 任务分解 → 迭代开发 → 集成验证 → 验收回顾

核心原则：大需求必须拆小，每个迭代交付可验证的最小功能单元。禁止"一次性全做完"。

2. 各阶段规范

2.1 需求整理

用户提供原始描述（口语化、列表、草稿均可），AI 整理为以下结构（需求 + 功能清单 + 验收合为一个文件）：

# {项目/模块名}需求

## 1. 背景与目标
- 为什么做（痛点/动机）
- 做到什么程度算成功（可衡量目标）

## 2. 用户角色
| 角色 | 说明 | 核心诉求 |
|------|------|---------|

## 3. 功能需求
### 3.1 {功能模块名}
- **描述**：一句话说明
- **用户故事**：作为{角色}，我希望{操作}，以便{价值}
- **验收条件**（AC）：
  - [ ] 条件 1
  - [ ] 条件 2
- **优先级**：Must / Should / Could / Won't

## 4. 非功能需求
- 性能 / 安全 / 兼容性（三项必填）

## 5. 边界与约束
- 不做什么（明确排除项）
- 已知限制 / 技术债务

## 6. 功能清单与迭代计划
（需求评审拆分后填写，见 2.2）

## 7. 验收记录
（开发完成后填写，见 2.7）

## 8. 术语表
| 术语 | 定义 |
|------|------|

规则：每个功能必须有 AC，无 AC 不可进入开发；优先级用 MoSCoW 四级；非功能需求至少覆盖性能、安全、兼容性。

2.2 需求评审与拆分

按纵向切片（端到端功能，非技术层）拆分，遵循 INVEST 原则，单个功能单元 ≤ 1-2 天工作量，有依赖须标注。

写入需求文档「6. 功能清单与迭代计划」：

## 6. 功能清单与迭代计划

### 迭代 1：{主题}（Must 级别）
| 编号 | 功能点 | 验收条件 | 前置依赖 | 预估工作量 |
|------|--------|---------|---------|----------|
| F001 | xxx | AC1, AC2 | 无 | 0.5d |
| F002 | xxx | AC1 | F001 | 1d |

### 迭代 2：{主题}（Should 级别）
...

2.3 技术方案设计

# {项目/模块名}架构

## 1. 架构概览
## 2. 数据模型
## 3. 接口设计
| 接口 | 方法 | 路径/签名 | 入参 | 出参 | 说明 |
|------|------|----------|------|------|------|
## 4. 技术选型
| 领域 | 选型 | 理由 |
|------|------|------|
## 5. 关键设计决策
| 决策点 | 方案 | 备选方案 | 选择理由 |
|--------|------|---------|---------|
## 6. 任务分解
（见 2.4）
## 7. 风险与缓解
| 风险 | 影响 | 缓解措施 |
|------|------|---------|

规则：优先使用 NewLife 已有组件（XCode、Remoting、Stardust 等）；数据模型考虑 XCode 实体规范；接口遵循现有 API 风格。

2.4 任务分解

单个任务 = 一次 AI 对话可完成的工作量（编码 + 测试 + 自测通过）。写入技术方案「6. 任务分解」：

### 任务 T001：{动词 + 目标}
- **对应功能**：F001
- **输入**：前置条件 / 已有代码
- **产出**：新增/修改哪些文件
- **验收**：怎样算完成

批次编排（用于自治模式，见第 6 节）：按依赖关系编排为批次，每批次 5-8 个任务，同批次内尽量无相互依赖，基础设施任务排在前面，每批次结束设 [检查点 N]，标注本批次产出是下批次哪些输入。

2.5 迭代开发

流程：理解任务 → 检索现有实现 → 编码 → 编译通过 → 测试通过 → 提交说明

严格遵守主指令编码规范，每个任务必须编译通过
常规模式：遇歧义暂停确认；自治模式：记录跳过继续（见第 6 节）
有依赖按顺序执行，不跳跃

2.6 集成验证

全部编译通过 → 单元测试通过 → 端到端主流程走通 → 异常场景覆盖 → 性能符合预期

2.7 验收与回顾

对照需求文档逐条验收，写入「7. 验收记录」：

## 7. 验收记录

### 功能验收
| 编号 | 功能点 | 验收条件 | 状态 | 备注 |
|------|--------|---------|------|------|

### 遗留问题
| 问题 | 影响 | 后续计划 |
|------|------|---------|

### 经验总结
- 做得好的 / 待改进的

3. 文档存放规范

全流程仅产出 2 个文档，扁平存放在 Doc/ 下：

文档	文件名	包含内容
需求文档	`Doc/{项目名}需求.md`	背景目标 + 功能需求 + 功能清单 + 验收记录 + 术语表
技术方案	`Doc/{项目名}架构.md`	架构 + 数据模型 + 接口 + 技术选型 + 任务分解 + 风险

UTF-8 无 BOM；已有文件必须先读取再增量修改，禁止覆盖；各阶段产出追加到对应章节，不新建文件。

4. AI 协作要点

4.1 阶段切换

用户说	进入阶段
"整理需求"/"写需求"	2.1 需求整理
"拆分"/"拆解"/"排优先级"	2.2 需求评审与拆分
"技术方案"/"架构设计"/"怎么实现"	2.3 技术方案设计
"开始开发"/"写代码"/"实现 F001"	2.5 迭代开发
"全部搞完"/"批量开发"/"自治模式"/"一次性做完"/"继续处理"/"接着做"	第 6 节自治批处理
"验收"/"检查完成情况"	2.7 验收与回顾
一大段描述未指定阶段	默认 2.1 需求整理

4.2 主动引导

每阶段完成后提示下一步：需求整理完 → 拆分？ → 技术方案？ → 任务分解 → 开发？

4.3 大需求防护

功能点 > 5 / 实体 > 3 / 跨 2 层以上 / 描述 > 500 字 → 必须先拆分再开发。

5. 常见反模式（禁止）

❌ 跳过需求直接编码
❌ 一次性输出所有代码（大需求必须拆迭代或使用自治模式）
❌ 需求文档没有验收条件
❌ 功能拆分按技术层而非用户价值
❌ 任务没有完成标准就开始编码
❌ 完成后不做验收对照
❌ 自治模式下遇阻塞问题死等用户（应记录跳过，继续后续）
❌ 自治模式下做需要人工决策的架构变更（应记录待确认，现有方案兜底）
❌ 跨批次不做编译验证

6. 自治批处理模式

架构师已确认需求和技术方案后，AI 按任务清单自主执行，最小化人工介入。

6.1 进入条件（全部满足）

需求文档已完成且架构师已确认
技术方案已完成且架构师已确认
任务已分解并编排为批次
用户明确触发（"全部搞完"/"批量开发"/"自治模式"等）

未满足时提示缺少哪些条件。

6.2 计划结构与循环刷新

AI 用 plan 工具创建层次化计划，「前置刷新 + 批次执行」循环：

1. [前置] 读取需求文档与技术方案
2. [前置] 读取任务清单与进度状态
3. [前置] 全量编译确认基线
4. [前置] 识别可并行的批次组
5. [批次1] 执行 T001-T005（子步骤展开各任务）
6. [检查点1] 输出批次1报告
7. [刷新] 重读需求文档与技术方案
8. [批次2] 执行 T006-T010
9. [检查点2] 输出批次2报告
...（循环：刷新 → 批次 → 检查点）
N-2. [后置] 全量编译与集成验证
N-1. [后置] 补完被跳过的任务
N.   [后置] 生成验收报告

要点：

主步骤 15-25 个（不超过 30），子步骤展开具体任务仅供参考不单独追踪
刷新步骤穿插在每两个批次之间，get_file 重读文档对抗上下文漂移
用 update_plan_progress 跟踪主步骤，不为每个子任务调用
无依赖的批次可合并为一个主步骤执行，有依赖的必须顺序执行

6.3 执行协议

情况	处理方式
任务明确无歧义	直接执行：编码 → 编译 → 测试
小歧义可合理推断	执行并在问题日志记录推断依据
重大歧义或多种等价方案	标记 `⏸️ 待确认`，跳过
前置任务被跳过	标记 `⏸️ 依赖阻塞：T0xx`，跳过
编译失败短时间无法修复	回滚改动，记录并跳过
涉及公共 API / 架构变更	标记 `⏸️ 需架构师决策`，兜底或跳过

6.4 检查点报告

每批次完毕后输出：

## 检查点 N 报告

### 完成情况
| 任务 | 状态 | 说明 |
|------|------|------|
| T001 | ✅ 完成 | |
| T003 | ⏸️ 跳过 | 需确认：xxx |

### 编译状态
- 全量编译：✅ 通过 / ❌ 失败（错误详情）

### 问题日志
| 编号 | 类型 | 描述 | 影响任务 | 建议方案 |
|------|------|------|---------|----------|

### 统计
- 本批次 N 个，完成 X 个，跳过 Y 个
- 累计进度：已完成 X / 总计 Z（XX%）
- 上下文预估：{已处理任务数} / {建议上限}

6.5 用户回复与继续

架构师回来后：AI 呈现检查点报告 → 架构师批量回复问题（"Q001 OK，Q002 选 A"）→ AI 修正推断 + 执行跳过的任务 + 继续下批次 → 循环至完成。

触发词："继续"/"继续处理"/"回复完了"/"接着做"

6.6 质量护栏（自动执行）

编译门禁（失败即修复或回滚）/ 命名与技术方案一致 / 编码规范严格遵守 / 新增代码前搜索现有实现避免重复 / 不擅自引入新 NuGet 包

6.7 会话边界处理

每个检查点后、连续完成 15+ 任务后、搜索结果不准确时 → 评估是否需要新会话。

新会话续接模板：

我们在做 {项目名} 的自治批处理开发。
- 需求文档：Doc/{项目名}需求.md
- 技术方案：Doc/{项目名}架构.md
- 当前进度：批次 N 已完成，从批次 N+1 的 T0xx 开始继续
- 待解决问题：{问题编号}
请读取以上文档，从 T0xx 继续执行，自治模式。

上下文即将耗尽时 AI 主动提醒并生成上述模板。新会话前 4 步仍为前置刷新，已完成批次直接标记完成。

6.8 批次大小建议

复杂度	批次大小
简单（CRUD）	8-10
中等（业务逻辑）	5-7
复杂（算法、并发）	3-5

单会话上限：3-4 个批次（约 15-25 个任务）。

（完）

10 KiB Raw Blame History Unescape Escape