因为AI笔试有上下文的限制，一旦任务量太大，容易出现注意力涣散等问题，因此必须一步一步执行调用AI来保证质量，并且在必要时清理或者压缩上下文，我们做如下分步，以及每一步都有md文档落盘，防止上下文丢失
1. 明确任务
先不要写代码，先把任务明确
1
2
3
4
5
6
7
8
9
10
11
12
| 1.我们先明确问题，不要写代码，也不要给实现方案。先把这个任务整理成一份可执行的问题定义，只输出：
1.最终交付产物
2. 硬约束
3. 隐含要求
4. 什么叫完成
5. 容易翻车的风险点
要求
- 尽量短
- 不要做实现假设
- 不明确的地方标出来
|
2. 选择方案
先让AI多给2~3种方案，防止AI按自己的理解一条道走到黑，最后翻车。给出多个方案后可以再和AI讨论选择的问题
1
2
3
4
5
6
7
8
9
10
11
12
| 现在不要写代码
基于刚才的问题定义，给2到3条执行方案，每个方案有如下内容：
1. 大致怎么做
2. 主要优点
3. 主要风险
4. 实现复杂度
5. 可测试性
最后请明确推荐一条方案，并说明为什么不选择另外几条，
要求考虑稳定交付，而不是炫技
|
3. 确定骨架
这里对骨架的定义是模块，接口，数据
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| 基于已选定的方案，先不要展开实现细节
请先输出一份足够支持编码开发的系统骨架，至少包括
1. 模块拆分
2. 目录结构
3. 各模块职责和能力边界
4. 核心接口或API
5. 关键数据结构
6. 主链路时序
7. 权限、隔离和、边界
要求：
- 足够支撑编码
- 简洁精炼，不要写成长篇设计文档
- 如果有边界还不稳，请明确标出来
|
4. MVP实现循环迭代
为了稳定交付，最好是先做出MVP实现，然后循环迭代和验证
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| 现在开始编码实现，先完成MVP闭环
请先回答：
1. 什么事这套系统最小可运行闭环
2. 应该按什么顺序实现
3. 哪些东西现在必须做
4. 哪些东西现在明确先不做
然后只围绕这个最小闭环开始写代码
要求：
- 不要提前铺满所有功能
- 每完成一部分，都给出最短验证方式
- 如果发现规格有冲突，先指出，不要默默改掉
|
5.补充异常和边界
完成的主流程MVP实现，还缺少如下内容
1
2
3
4
5
6
7
8
9
10
| 现在先不要继续推进新功能
请你切换成“安全审查员+质量工程师”的视角，只看一下几件事
1. 哪些异常路径还没覆盖
2. 哪些权限边界还没卡住
3. 哪些输入还缺校验
4. 哪些失败现在会让系统行为很差
5. 哪些风险必须修，哪些可以作为已知限制留下
请先列问题，再按优先级排序，再给出最小必要修改建议
|
6.用证据验收
1
2
3
4
5
6
7
8
9
10
11
| 请你切换成AQ 和 reviewer，不再默认当前结果是对的
基于已确认的问题定义，系统骨架和当前实现，请做一次系统性自检
请输出：
1. 主链路应该有哪些测试
2. 关键异常路径应该有哪些测试
3. 当前最值得跑的测试命令
4. 哪些地方还没有证据证明它是对的
5. 按严重程度列出当前缺口
6. 给出一个明确结论，现在能不能交，如果不能，卡点在哪
|
7. 把交付写清楚
1
2
3
4
5
6
7
8
9
10
11
12
13
| 现在请你切换成交付负责人，不再增加新功能，只做最后收口
请把当前结果整理成一套别人接的住的交付材料
1. README: 怎么启动，怎么跑，怎么验证
2. 设计说明：为什么这么设计，核心结构是什么
3. 测试说明： 验证了什么，还有什么没验证
4. 风险与限制：哪些问题是已知的，为什么对当前仍可接受
5. 演示顺序： 如果只有几分钟，应该按什么顺序战士
要求：
- 不要重新编故事
- 文档必须和真实实现一致
- 用最短路径让人看懂
|
