因为AI笔试，尤其是牛客网的AI笔试， Agent性能非常拉，一定要在提示词上下功夫，它会有如下问题
- 短上下文容量导致注意力涣散： 一定要将关键信息持久化为md文档，比如事实维护一个code.md保存工作上下文中的关键信息。 tips:agent又笨又没权限，一定要明确让它创建文档，否则它可能试图读文件，然后没有权限，然后找你要一个不存在的文件的读权限
- Agent个性古怪，喜欢过度发挥，默认会发散要求，做一些要求之外的事，而且往往不可控，哪怕方向蒙对了也效果很差: 每一次发消息都要有围栏信息,明确不让它做的事
- AI没脑子，跟它说话不要带感情带情绪，要高效明确地指挥它做事
1. 明确任务
，先不要写代码，先把任务明确
1
2
3
4
5
6
7
8
9
10
11
12
13
| 切换你的角色为问题研究员，**不要写代码，也不要给实现方案**。先把这个任务整理成一份可执行的问题定义，只输出：
1. 最终交付产物
2. 硬约束
3. 隐含要求
4. 什么叫完成
5. 容易翻车的风险点
要求
- 尽量短
- 不要做实现假设
- 不明确的地方标出来
- 输出结果到你创建的`question.md`中
|
然后不要急着往下走,一定要看一眼question.md有没有不明确的点，这些往往是AI做不了的决策，要把这些决策清空了再往下走，否则会严重影响质量
2. 选择方案
先让AI多给2~3种方案，防止AI按自己的理解一条道走到黑，最后翻车。给出多个方案后可以再和AI讨论选择的问题
1
2
3
4
5
6
7
8
9
10
11
12
13
| 切换你的角色为方案设计师，不要写代码，基于刚才的问题定义，给2到3条执行方案，每个方案有如下内容：
1. 大致怎么做
2. 主要优点
3. 主要风险
4. 实现复杂度
5. 可测试性
要求:
- 最后请明确推荐一条方案，并说明为什么不选择另外几条，
- 要求首要考虑稳定交付，而不是炫技
- 输出结果到你创建的`design.md`中
|
3. 确定骨架
这里对骨架的定义是模块，接口，数据,这个是后面代码开发的重要依据，可以每一轮代码开发都把这个文件发过去，保持注意力
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| 切换你的角色为架构工程师，基于已选定的方案，先不要展开实现细节，请先输出一份足够支持编码开发的系统骨架，至少包括
1. 模块拆分
2. 目录结构
3. 各模块职责和能力边界
4. 核心接口或API
5. 关键数据结构
6. 主链路时序
7. 权限、隔离和、边界
要求：
- 足够支撑编码
- 简洁精炼，不要写成长篇设计文档
- 如果有边界还不稳，请明确标出来
- 结果输出到你创建的`skeleton.md`中
|
4. MVP实现循环迭代
为了稳定交付，最好是先做出MVP实现，然后循环迭代和验证
为了保持注意力，可以每轮迭代都发送@question.md和@skeleton.md，然后为了减少重复劳动，可以把下面的提示词都写到pxx.md中，
比如这一步第一轮发的提示词写到p1.md或者mvp.md中
bug反馈: AI往往做不到一次性写好，要将编译报错和测试报错返回给它，但别忘了执行一下题目的样例自测和提交自测（总共可以提交20次），次数其实挺多的，而且也有反馈提示，可以告诉AI有哪些最基本的接口约束没做好，可以有效防止AI注意力发散
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| 切换你的角色到代码开发工程师，现在开始编码实现，先完成MVP闭环
请先回答：
1. 什么事这套系统最小可运行闭环
2. 应该按什么顺序实现
3. 哪些东西现在必须做
4. 哪些东西现在明确先不做
然后只围绕这个最小闭环开始写代码
要求：
- 不要提前铺满所有功能
- 每完成一部分，都给出最短验证方式/ （如果没提供终端就写这个: 每完成一部分，就自行执行最短验证测试）
- 如果发现规格有冲突，先指出，不要默默改掉
- 每一阶段开发都维护同一个`code.md`，要求尽量短，只记录关键信息，过期/低价值信息及时删除
|
然后后面循环迭代就可以复制粘贴这个文件，改名成pxx+1.md，写入如下内容
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| 切换你的角色到代码开发工程师，现在开始编码实现，在已有代码的基础上实现下一阶段开发
请先回答：
1. 什么是添加新功能后的最小逻辑闭环
2. 应该按什么顺序实现
3. 哪些东西现在必须做
4. 哪些东西现在明确先不做
然后只围绕这个最小闭环开始写代码
要求：
- 不要提前铺满所有功能
- 每完成一部分，都给出最短验证方式/ （如果没提供终端就写这个: 每完成一部分，就自行执行最短验证测试）
- 如果发现规格有冲突，先指出，不要默默改掉
- 每一阶段开发都维护同一个`code.md`，要求尽量短，只记录关键信息，过期/低价值信息及时删除
|
最后再来个收尾提示词
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| 切换你的角色到代码开发工程师，现在开始编码实现，在已有代码的基础上实现下一阶段开发
请先回答：
1. 什么是添加新功能后的最小逻辑闭环
2. 应该按什么顺序实现
3. 哪些东西现在必须做
4. 是否完成收尾的全部工作
然后只围绕这个最小闭环开始写代码
要求：
- 不要额外添加新功能
- 每完成一部分，都给出最短验证方式/ （如果没提供终端就写这个: 每完成一部分，就自行执行最短验证测试）
- 如果发现规格有冲突，先指出，不要默默改掉
- 每一阶段开发都维护同一个`code.md`，要求尽量短，只记录关键信息，过期/低价值信息及时删除
|
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. 演示顺序： 如果只有几分钟，应该按什么顺序战士
要求：
- 不要重新编故事
- 文档必须和真实实现一致
- 用最短路径让人看懂
|
