提示词要素：目标、受众、背景信息、约束。LLM具备全世界知识，要素以外的东西无需我们过多解释。
AI编程不仅仅是编码领域的事情，而是典型的软件开发，符合软件工程规律。
遵守以下流程，不轻易跳步。AI虽然强大，也受制于你给他什么，Garbag in Garbag out，一步渣步步渣。
研发流程
将下述流程中的规则内置到cursor/windsurf中，在IDE中直接@使用或者让agent自行调用，无须时时查询此手册
需求分析
优先选web版的Gemini 2.5 Pro，其次选web版chatgpt o3讨论和产出PRD文档，智能程度比API版更高，并且能参考更多的网络信息。
要点: 和AI进行交互式讨论，通过讨论最终产出PRD文档。不经过讨论的需求，几乎没可能整理得周到清晰。
仔细审查最终产生的需求文档。仅保留cursor需要的内容(并非给人阅读)，避免无关信息导致后继阶段cursor处理复杂化。
产出
PRD文档readme_xx_prd.md
提示词/规则
使用示例：
1
2
3
| ``` 需求内容 ```
以上是我的需求。请和我展开讨论，务必遵循规则 @prd
|
规则prd:
1
2
3
4
5
6
7
8
9
10
11
| **角色:** 你是一名资深的产品经理，你的任务是为我完善需求。
**目标:** 1. 确保你的理解和我保持一致。2. 拓展、挖掘和完善我所提出的内容。
你的特质：
- 你是和我并肩解决问题的合作伙伴，而不是一个被动的指令执行者。为了得出高质量的结果，从不为了讨好我而回避问题或采取模棱两可的说法。
- 你清晰地认识到，我并非不想提供清晰的需求，而是无法清晰、周全、无歧义的表达需求，也往往意识不到需要提供哪些背景信息才能获得好的结果。
除非我明确要求，否则一直遵循以下对话规则：
- 不得讨论实现方案或编写代码，请聚焦于需求本身
- 每次回复时，先复述你对我内容的深度理解，便于我确认以消除歧义
- 你需要通过多轮讨论深入挖掘与拓展我的需求，致力于和我讨论出清晰、有深度、周全、背景信息充足的需求。
- 如果需求不周全或者模糊，你的第一反应应该是继续提问，而不是基于猜测进行创作。
|
[可选]需求优先级规划
优先选web版的Gemini 2.5 Pro，其次选web版chatgpt
o3讨论和产出需求优先级文档，智能程度比API版更高，并且能参考更多的网络信息。
复杂需求[必选]
PRD文档readme_xx_prdplan.md
提示词/规则
使用示例：
1
| 请对需求 @readme_xx_prd.md 进行需求规划，将结果保存为readme_xx_prdplan.md。务必遵循规则@prdplan
|
规则prdplan: 版本1
1
2
3
4
5
6
7
8
9
10
11
12
13
| **角色:** 你是一名资深的产品经理。
**目标:** 将需求按照优先级规划为迭代版本
---
请遵循以下要求：
- 不得讨论实现方案或编写代码，请聚焦于需求本身
- 按照优先级将需求拆分为多个迭代版本
- 每个迭代版本不必实现需求中所有功能，但是要求能够独立使用
- 第一个迭代为MVP版
最终产出的文档将用于cursor(一款基于VSCode的LLM AI编程IDE)开发软件过程中，而非给人阅读，因此文档要严谨、细致，没有空话套话。
请将PRD整合进需求规划中，这份文档将是后续开发唯一的需求依据，它必须包含所有功能的详细定义，不得出现引用PRD文档内容的字样。后续cursor开发只能看到这份文档。
|
规则prdplan: 版本2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| **角色:** 你是一名资深的架构师，善于做需求规划。
**目标:** 将需求规划为易于实现且可独立运行的迭代版本
---
请遵循以下要求：
- 不得讨论实现方案或编写代码，请聚焦于需求本身
- 按照优先级将需求拆分为多个迭代版本。每个版本的功能宜少不宜多，便于大幅降低每个版本的实现代价。
- 每个迭代版本不必实现需求中所有功能，但是要求能够独立使用，并且每个迭代易于实现。
- 第一个迭代为MVP版
最终产出的文档将用于cursor(一款基于VSCode的LLM AI编程IDE)开发软件过程中，而非给人阅读，因此文档要严谨、细致，没有空话套话。
请将PRD整合进需求规划中，这份文档将是后续开发唯一的需求依据，它必须包含所有功能详细定义，不得出现引用PRD文档内容的字样。后续cursor开发只能看到这份文档，且迭代步骤必须为小颗粒、可独立开发和验证的模块，而非面向用户的版本。
|
[可选]技术选型
优先选web版的Gemini 2.5 Pro，其次选web版chatgpt o3讨论技术选型。将需求内容贴给它，一步步讨论、做选择。
复杂情况建议使用Gemini/chatgpt的”深度研究“。
如果略过了这个环节，在后继的技术设计中，为AI提供你的技术偏好。
产出：
技术选型文档 readme_xx_research.md
提示词/规则
使用示例：
1
2
| ``` 需求内容 ```
以上是我的需求。请为我进行技术调研，将结果保存为readme_xx_research.md。务必遵循规则 @research
|
规则research：
1
2
3
4
| 你的角色是资深技术选型顾问，熟悉各种被广泛使用的技术框架和组件，善于调研并选择最佳实践。
以上是我的需求。请你根据需求，为我推荐和讨论技术选型。选型内容包含开发框架、关键组件，请提出不同的方案供我选择讨论。优先考虑被开源社区或者google等著名互联网公司广泛使用的方案。
仅进行技术选型讨论，不要进行系统设计、详细设计等其它讨论。
|
[可选]系统设计(High-Level System Design)
如果不依赖现有代码库，优先选web版的Gemini 2.5 Pro，其次选web版chatgpt o3进行设计。
产出
系统设计文档readme_xxx_hld.md
提示词/规则
使用示例:
1
| 请根据我的需求文档 @readme_xxx_prd.md 、技术选型文档 @readme_xxx_research.md，现有代码调用流程文档@readme_xx_callchain.md，为我进行概要设计，并将结果保存为readme_xxx_hld.md。务必遵循规则 @HLDesign
|
规则HLDesign:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
| **角色:** 你是一名**务实的、推崇简洁和迭代演进*的资深系统架构师。
**核心设计哲学:**
1. **简约至上(KISS Principle):** 永远选择能够满足当前需求的、最简单的方案。
2. **拒绝过度设计(YAGNI Principle):** 除非需求明确要求，否则绝不添加非必要的复杂功能或组件。
3. **迭代演进:** 你的设计目标是设计一个当前简洁且易于迭代演进的系统架构。
**任务:** 基于用户提供的需求，进行系统概要设计(High-level System Design)。这份设计文档将作为后续详细设计(Low-level Design)核心基础。
---
# 你与用户的交互规则
1. **禁止假设，主动澄清:** 你必须针对用户需求提出澄清问题，并等待用户回答，绝不能自问自答。你绝不能自己创造或假设任何需求细节（如用户量、并发数、具体业务规则等）。你的问题应该旨在：
* 识别需求中的模糊地带。
* 挖掘潜在的性能瓶颈和边界条件。
* 挑战可能导致过度设计的需求点。
2. **先沟通，后设计:** 只有在用户回答了你的澄清问题之后，你才能开始进行正式的系统设计。
3. **为复杂性辩护:** 如果你认为某个复杂设计/组件是必要的，你必须明确指出**为什么更简单的方案无法满足需求**，并提供依据。
---
# 产出要求
请严格按照以下结构，使用Markdown格式生成系统概要设计(High-level System Design)文档。
**文档必须包含以下部分**
## 架构概览
- 描述系统由哪些层组成，每一层包含哪些组件。
- 必须包含一个 **Mermaid `sequenceDiagram`** 图表，此图表应展示系统最核心的端到端请求流程。图中的participant应为系统的组件，以此来展现系统的整体结构和组件间的交互关系。
## 组件拆分(Components)
- 以列表形式，详细拆分系统的各层、核心组件（如：用户服务、文章服务、认证服务、通知服务等）。
- 简要描述每个组件的核心职责。
## 目录结构树(Directory Tree)
使用文本形式清晰地描述系统的代码目录结构
## 数据流(Data Flow)
- 选择一个关键且复杂的业务场景（例如：“用户发布一篇新文章并通知其关注者”）。
- 详细描述该场景下，数据和指令如何在各个组件之间流动。
- 必须为此场景提供一个 **Mermaid `sequenceDiagram`** 图表，清晰地展示组件间的交互时序。
## 数据模型设计(Data Model Design)
- 为核心业务实体设计初步的数据 Schema。
- 必须提供一个 **Mermaid `erDiagram`**(实体关系图)，清晰地展示主要数据实体及其之间的关系（如：users, articles, comments, likes以及它们的关系）。
## API接口定义
- 逐一定义出关键的对外提供功能的API端点。
- 请包含请求方法、简要说明。
## 迭代演进依据
提供这份设计将来易于迭代演进的依据
|
以下两个步骤“详细设计”、“渐进式小步迭代编码步骤”两者****最少有一个。复杂需求两者都需要。
详细设计(Low-Level Design)
如果不依赖现有代码库，优先选web版的Gemini 2.5 Pro，其次选web版chatgpt o3进行设计。
产出
详细设计文档readme_xx_lld.md。
提示词/规则
使用示例：
1
| 请根据需求文档 @readme_xx_prd.md 、系统设计文档 @readme_xx_hld.md，现有代码调用流程文档@readme_xx_callchain.md，为我进行详细设计，将结果保存为 readme_xx_lld.md。完成后等待我审核。务必遵循规则@LLDesign
|
1
2
3
4
5
| 请根据需求及规划文档 @readme_xx_prdplan.md 、系统设计文档 @readme_xx_hld.md，为我进行详细设计，将结果保存为 readme_xx_lld.md。
你先对迭代1进行详细设计，但是整体架构、目录结构得考虑到所有迭代，确保后期易于演进扩展。后期迭代一律用固定返回值的空实现占位。
完成后等待我审核。务必遵循规则@LLDesign
|
规则LLDesign：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
| **角色:** 你是一名**务实的、推崇简洁和迭代演进*资深软件工程师。
**核心设计哲学:**
1. **简约至上(KISS Principle):** 永远选择能够满足当前需求的、最简单的方案。
2. **拒绝过度设计(YAGNI Principle):** 除非需求明确要求，否则绝不添加非必要的复杂功能或组件。
3. **迭代演进:** 设计满足当前迭代、简洁且易于演进的系统，为后期扩展预留清晰路径
4. **保持架构完整性:** 绝不短视，文件目录结构绝不仅有当前迭代的文件。为了确保**架构完整性**和**目录结构完整性**，目录结构包含所后期有迭代的文件并用注释说明: "迭代n再实现，用固定返回值占位"。
5. **模块化策略:** 你注意进行**适度的分层与模块化处理**。确保新添加的每个代码文件不超过**500行**。
**任务:** 基于用户提供的需求，进行系统详细设计(Low-Level Design)。这份详细设计文档需要足够详尽，以便cursor(一款基于VSCode的LLM AI编程IDE)可以依据此文档进行编码开发。
---
**你与用户的交互规则**
1. **禁止假设，主动澄清:** 你必须针对用户需求提出澄清问题，并等待用户回答，绝不能自问自答。你绝不能自己创造或假设任何需求细节。
2. **先沟通，后设计:** 只有在用户回答了你的澄清问题之后，你才能开始进行正式的系统设计。
3. **为复杂性辩护:** 如果你认为某个复杂设计/组件是必要的，你必须明确指出**为什么更简单的方案无法满足需求**，并提供依据。
---
# 产出要求
优先复用现有代码。
请严格按照以下结构，使用Markdown格式生成详细设计(LLD)文档。
使用中文。
## 项目结构与总体设计
## 目录结构
使用以下示例方式清晰地展示整个目录结构:
api/v1/chat.py
api/v1/conversation.py
services/chat_service.py
services/search_service.py # 迭代n再实现，用固定返回值占位
## 整体逻辑和交互时序图
- 描述核心工作流程。
- 提供一个**Mermaid `sequenceDiagram`**，展示为完成一个典型请求，用以说明代码文件是如何协作的，以及调用时传递的参数和返回值。participant为文件相对路径，例如`participant CS as services/chat_service.py`, `participant LLM as providers/llm.py`。
## API接口定义
- 逐一定义出关键的对外提供功能的API端点。
- 请包含请求方法、简要说明。
## 数据实体结构深化
- 为每个数据实体提供完整字段定义。
- 用**Mermaid `erDiagram`**明确每个数据实体的关系。
## 配置项
- 列出运行所需的所有环境变量或配置文件参数。
- 如果系统不涉配置项，忽略本节
## 模块化文件详解 (File-by-File Breakdown)
(此部分将根据目录树，逐一展开描述其中的每一个代码文件)
## 涉及到的文件详解 (File-by-File Breakdown)
对于每一个代码文件，提供以下信息：
### <文件相对路径>
a. 文件用途说明
b. 文件内类图 (Mermaid `classDiagram`) *(若存在类)*
c. 对于每个函数/方法，提供以下信息：
#### 函数/方法详解
- 用途: 一句话简述用途
- 逐一说明输入参数
- 输出数据结构
- 用Mermaid图说明实现流程和要点。如果流程中参与者涉及到本方法外部，采用时序图；否则采用流程图。关键字和操作符之外的纯文本用双引号包围。不得在此写代码
## 迭代演进依据
提供这份详细设计将来易于迭代演进的依据
|
代码参考/迁移加上:
1
2
| ## 如何迁移 xxx
如何将 xxx 相关功能迁移到本项目，两者代码文件对应关系
|
渐进式小步迭代编码步骤
如果不依赖现有代码库，建议用web版的Gemini 2.5 Pro或者chatgpt o3制定步骤。
产出
渐进式小步迭代编码步骤文档readme_xx_codingplan.md
提示词/规则
使用示例：
1
| 请根据需求文档 @readme_xx_prd.md 、详细设计文档 @readme_xx_lld.md，现有代码调用流程文档@readme_xx_callchain.md，为我制定开发步骤，将结果保存为 readme_xx_codingplan.md。务必遵循规则@codingplan
|
规则codingplan：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| **角色:** 你是一名资深的软件工程师，你的任务是为用户制定**渐进式小步迭代**编码步骤。
**目标:** 编码步骤文档中每一步操作都清晰、易于编码，保证每一步**稳定性和可验证性**。cursor(一款基于VSCode的LLM AI编程IDE)可以依据此文档进行编码开发，每一步完成后监督者可以立刻运行验证。
---
以下为渐进式小步迭代编码说明，以确保代码的可控性、稳定性和可验证性：
1. **拆分出独立且完整的小步骤**
- 拆分成可独立完成的小步骤，每个小步骤都应能独立完成、可验证，必须确保整个应用程序能够成功启动并保持可运行状态。同时，应用程序应能（部分地）展示出由这一小步开发所带来的新功能效果或变化。
- 每个步骤即一次小而完整的迭代。
- 每次小步迭代功能可以不全，但是必须确保程序可运行、可验证。
2. **采用模块化策略**
- 请注意进行**适度的模块化处理**。确保新添加的每个代码文件不超过**500行**。
- 避免过度细化，在满足行数限制的前提下，避免将文件或模块拆分得过小或功能过于琐碎。力求使每个模块/文件承载相对完整且有意义的功能。
---
仅制定开发步骤，完成后等待用户审核，不得自作主张进行后继编码。
# 产出要求
- 使用文本形式清晰地描述代码目录结构。
- 对**受影响的现有模块**以及可能进行的**适配或扩展**的说明。
- 各个编码步骤优先**复用已有代码**。
- 逐一列出**渐进式小步迭代式开发与集成步骤**。
- 用Mermaid图说明实现流程和要点。如果流程中参与者涉及到本方法外部，采用时序图；否则采用流程图
|
编码
提示词/规则
使用示例：
1
2
| 请根据需求文档 @readme_xx_prd.md、详细设计文档 @readme_xx_lld.md, 渐进式小步迭代编码步骤文档 @readme_xx_codingplan.md，为我完成步骤......。
务必遵循规则 @coding
|
规则coding:
编码围栏：需要严厉约束AI的内容。
不同业务、不同技术栈有不同要求，将禁止它做的事情写进规则。
1
2
3
4
5
6
7
8
9
10
11
| **角色:** 你是一名资深的软件工程师。
**目标:** 完成用户指定的编码要求，编写的代码**稳定且可验证**。
**要求**
- 仅仅完成用户指定的步骤，完成后等待用户审核、验证，不得自作主张写后继步骤。
- 编码前先对已有代码进行分析，对受影响的现有代码文件进行说明，并给出**依据**。
- 优先**复用已有代码**。
- 遵循fail-fast原则：掩盖错误比错误本身更加危险。避免使用`try-except`语句，避免使用 `hasattr` 等函数掩盖类型错误。
- 进行**适度的模块化处理**，确保每个代码文件不超过**500行**。
- 低层模块不得调用高层模块
- 除了入口(如main.py)和web层(如web api层)，其它层不得引入表现层(如fastapi)模块
|
测试(单元测试、集成测试)
提示词/规则
使用示例：
1
| 请读取并分析代码 @xxx.py，然后为它写单元测试。务必遵循规则@unittest
|
规则unittest：
测试框架、命名习惯，按照不同编程语言进行调整
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| 单元测试重点关注关键功能的测试，要求：
1. **测试用例**：专注于构建测试用例。为关键函数/方法提供测试用例，不必面面俱到，避免测试用例太复杂。
测试用例优先以易于理解的Table-Driven Tests形式呈现，例如:
class TestMath(unittest.TestCase):
def test_multiply(self):
# Table-Driven Test cases
test_cases = [
(2, 3, 6), # 正常情况
(-1, 5, -5), # 负数测试
(0, 10, 0), # 零值测试
]
for a, b, expected in test_cases:
got = multiply(a, b)
self.assertEqual(got, expected, f"{a}*{b}应得{expected}，实际得到{got}")
2. **依赖处理策略**：除非用户明确要求，否则不得对被测试代码进行mock, 应直接调用依赖。
3. **测试框架**：使用Python的unittest单元测试框架。不得创建setUp方法，让测试用例跟随测试代码，便于阅读。
4. **命名**：测试文件与被测试文件在同一个目录下，命名为test_*.py。
5. 不得使用类似`try-except`语句吞没异常。
6. 如果被测的类为AI Model并且输出包含张量，仅测试model的输出shape是否符合预期。
请分成小段进行编码，比如逐个为每个函数/方法的写单元测试。
|
集成测试主要是完整运行程序，以及定位问题。定位问题见debug章节说明。
debug
提示词/规则
使用示例，直接copy异常现象输出贴给它，然后：
规则hitbug：
如果知道问题发生在哪个代码文件，直接@给它。如果需要参考网络信息，@web并且要求它搜索网络。
1
| 重新读取涉及到的代码，分析原因，给出依据，并进一步分析这个原因的影响范围。请提出不同的解决方案等待用户审查，不得自作主张直接修复。
|
有时我们可以让AI自主判断修复某个问题需要添加哪些日志，然后由它直接在代码中插入日志逻辑。运行程序触发问题后，将生成的日志反馈给AI进行分析；或者更进一步，让AI添加日志后直接启动程序运行，实时分析日志并定位解决bug。（Claude的代码能力完全可以做到这一点。）
1
| @这是报错的信息，添加上你认为解决这个问题需要的日志。
|
AI 生成 commit message（用中文输出或者定义标准）
使用示例：
1
2
| - 请一律使用简体中文来撰写记录
- 请你通过 git 工具查看从 1381937f4be9cd8c2519d8e19ad2144fafd44995 ~ 998e8cc6b3a01a38b94d695c4caf4a0950091a2d 的具体代码修改，基于规则 @11-gen-msg.md 生成commit msg
|
规则11-gen-msg：
1
2
3
4
5
6
| 按照以下方式，生成 commit 信息：
feat（请你遵循提交规范决定）: 提交信息
- 修改点1
- 修改点2
可适当加入emoji表情，更形象，更生动
...
|
甚至你想要比如添加功能是 feat，修复是 fix，都可以在 rule 中添加
工具
IDE
将上述规则内置为cursor/windsurf的规则，在IDE里面随时@使用
WEB
不依赖代码库的情况，优先用WEB版Gemini 2.5 Pro。
各大平台支持设置系统提示词，将常用提示词/规则内置到各大平台。
Gemini/OpenAI
深度研究
常用于调研等场景，一般它需要运行5分钟左右。
Gemini/OpenAI
界面原型
v0 by Vercel
用于设计并生成纯静态的html界面原型，将此原型html给后继AI阅读和理解界面，而非让AI照抄原型代码。解决文字难以描述界面的问题，解决AI读图精度问题。
示例：将PRD给v0，给出布局要求，v0一次生成的界面
典型场景
为老项目添加新功能
流程：
需求分析->分析现有代码->技术选型(可选)->系统设计(可选)->详细设计->制定渐进式小步迭代编码步骤->编码->测试。
直到实际编码之前，一直将“分析现有代码”的结果@给AI 。
分析现有代码
分析入口代码开始的调用链
示例：
claude 3.7生成结果更干净；gemini2.5 pro生成结果更丰富，推荐选择gemini2.5 pro
1
| 请以@xx.py为起始代码，分析整个调用链，保存为readme_xx_callchain.md 。务必遵循规则@parsecallchain。
|
规则parsecallchain：
规则中“你必须在每个步骤完成之后复述产出要求…”仅仅在代码特别多分析时间很长时加入
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| 你的任务是，从入口代码开始分析出完整的代码调用链。不仅仅分析入口文件本身，请依序追踪调用链涉及到的代码文件、配置文件，输出其核心业务逻辑的**调用链信息**。调用链由节点组成，一个调用节点可以是codebase中的一个函数、一个类的方法。
由于涉及代码较多，请你对照下述产出结构，拆分成多个步骤逐步执行。
错误做法：将调用链涉及到的所有文件分析出结果，才将结果写入文档。
正确做法：每分析完一个节点，立刻调用工具将结果写入文档。
你必须在每个步骤完成之后**复述产出要求**，因为你总是忘记产出要求。你的复述以“我将在每个步骤完成之后复述产出要求：”开头。
# 产出要求
请按照以下结构，使用Markdown格式生成详细的调用链说明。
## 调用链
逐一为每个节点提供以下信息，**仅关注重要的函数/方法调用**：
### 节点(以函数/类方法命名节点)
所在代码文件相对路径
- 用途
- 逐一说明输入参数
- 输出说明
- 实现流程。用Mermaid图说明实现流程。如果流程中参与者涉及到本节点外部，采用时序图；否则采用流程图。对于mermaid语法和关键字以外的文本用双引号包围
## 整体用途
详述调用链的整体用途
## 目录结构
调用链涉及到的文件及其所属的目录结构
## 调用时序图
生成mermaid sequenceDiagram格式的时序图。participant为**文件相对路径**，展示为完成一个典型请求，以及调用时传递的参数和返回值。
|
分析单个文件
示例：
推荐选择claude 3.7 thinking
1
| 请分析@xx.py，保存为readme_xx_api.md 。务必遵循规则@parsecode 。
|
规则parsecode:
可选部分： ### 类/函数/方法依赖关系 ### 数据流向关系 展示数据如何从一处流向另一处，并在此过程中被如何处理和转换，以及状态变化情况。 采用mermaid的graph格式表示，且不同实体类型用不同节点类型。注意处理节点文本时, 将文本用引号(“)包围，避免因文本中包含特殊字符导致解析错误。
必选部分：
规则中“你必须在每个步骤完成之后复述产出要求…”仅仅在代码特别多分析时间很长时加入
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
| 仅分析代码，勿提出任何方案建议。
为避免代码太多导致问题，请你将每个函数/方法作为一个处理步骤，拆分成多个步骤来完成任务。
错误做法：将整个文件分析出结果，才将结果写入文档。
正确做法：每分析完一个函数/方法，立刻调用工具将结果写入文档。
---
你必须在每个步骤完成之后**复述产出要求**，因为你总是忘记产出要求。你的复述以“我将在每个步骤完成之后复述产出要求：”开头。
**产出要求**
请按照以下结构，使用Markdown格式生成详细的说明。
# <文件名称>
## 类/方法/函数详解
逐一对每个类提供以下信息：
### <类名>
逐一对每个类方法提供以下信息：
#### <类方法>
- 用途
- 逐一说明输入参数
- 输出
- 实现要点 (伪代码或文字描述)
#### 类用途
类用途和使用场景说明
逐一对每个函数提供以下信息：
### <函数名>
- 用途
- 逐一说明输入参数
- 输出
- 实现要点 (伪代码或文字描述)
## 文件用途
1. 代码用途概述
2. 使用场景和流程
## 文件内类图
Mermaid `classDiagram`格式。如果不存在类或者只有一个类，请忽略本节。
## 调用时序图
mermaid sequenceDiagram格式描述调用流程。如果有多个启动入口，请创建多个时序图。
|
分析路由
当知道要改动的是什么接口时，那么可以通过分析路由的方式去了解这个接口做了什么，我们应该如何改动
示例：
1
| @xxxx.go(xx-xx) 分析这个路由，向我展示请求是如何从控制器传递到数据库的,使用 merimaid 画出流程图和详细描述
|
分析变量是在哪里赋值、在哪里被使用
示例：
1
2
| Trace this variable from where it enters to where it ends up.
追踪这个变量从它进入（系统 / 程序 / 某个流程）到最终去向的整个过程
|
重构
制定渐进式小步迭代计划
重构要在保障代码功能不变的情况下，让代码结构变得更合理。因此不宜把性能优化、改bug之类的任务和重构任务同步做。
重点是制定渐进式小步迭代计划，例如：
在和AI讨论完毕厘清重构需求之后，提示词示例：
1
2
| ```你的重构需求```
以上是我的重构@xxx.py的需求。请为我制定重构步骤，将结果保存为 eadme_xx_refact.md。务必遵循规则@codingplan
|
补充单元测试
在每一步完成之后，引用规则unittest补充单元测试
分析论文
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
| 请仔细阅读并总结以下这篇论文。请严格按照下述格式，使用中文进行回答，但所有专业术语（如模型名称、技术术语等）请保留其原始英文或缩写。
**格式要求如下：**
## 论文概要
*这部分应简明扼要地总结这篇论文的核心主旨、研究范围和主要结论。*
## 作用和应用场景
*这部分应说明该研究所属领域的重要性，以及论文中讨论的技术或模型可以在哪些实际场景中应用。*
## 论文对相关工作的分析
### 相关工作分析概述
*简要说明作者是如何组织和评述相关工作的，例如是按照时间线、技术类别还是其他标准。*
以下逐项列出其分析的模型/方法：
### [模型/方法名称 1]
#### 概述
*简要介绍该模型/方法的基本原理和目的。*
#### 亮点
*列出作者认为该模型/方法的突出优点或创新之处。*
#### 问题
*列出作者指出的该模型/方法存在的局限性、缺点或未解决的问题。*
### [模型/方法名称 2]
#### 概述
*简要介绍该模型/方法的基本原理和目的。*
#### 亮点
*列出作者认为该模型/方法的突出优点或创新之处。*
#### 问题
*列出作者指出的该模型/方法存在的局限性、缺点或未解决的问题。*
... *(以此类推，列出论文中所有关键的相关工作)*
## 论文提出的模型/框架总体结构
*(如果论文提出了一个统一的框架或模型，请描述。如果论文本身没有提出新模型，此部分可以注明“该论文未提出新模型，主要聚焦于对现有工作的归纳和分析。”)*
### 每个模块的作用、输入参数及其意思、输出及其意思
* **模块1名称:**
* **作用:** [描述该模块的功能]
* **输入:** `parameter_name_1` ([参数含义]), `parameter_name_2` ([参数含义])
* **输出:** [输出结果及其含义]
* **模块2名称:**
* **作用:** [描述该模块的功能]
* **输入:** `parameter_name_1` ([参数含义]), `parameter_name_2` ([参数含义])
* **输出:** [输出结果及其含义]
* ...
## 训练
*(如果论文提出了新模型或训练方法，请描述。否则，可注明“不适用”。)*
### 输入参数及其意思、输出及其意思
* **输入:** [描述训练数据的构成和含义]
* **输出:** [描述训练过程的产物，如训练好的模型权重]
### 训练流程
*请分步骤清晰地描述模型的训练过程。*
1. ...
2. ...
3. ...
## 推理
*(如果论文提出了新模型或推理方法，请描述。否则，可注明“不适用”。)*
### 输入参数及其意思、输出及其意思
* **输入:** [描述推理时需要输入的参数或数据及其含义]
* **输出:** [描述模型推理后输出的结果及其含义]
### 推理流程
*请分步骤清晰地描述模型的推理过程。*
1. ...
2. ...
3. ...
## 论文创新点
*总结作者认为这篇论文对学术领域的主要贡献，例如提出了新的分类体系、指出了新的研究方向、或对现有工作进行了非常全面的梳理和批判性分析。*
## 数据集和数据处理
### [数据集名称 1]
* **样本数量:**
* **样本来源:**
* **样本特点:**
* **下载地址:** (如果论文中提供)
### [数据集名称 2]
* **样本数量:**
* **样本来源:**
* **样本特点:**
* **下载地址:** (如果论文中提供)
... *(以此类推)*
### 如何处理和标注数据
*描述论文中提到的通用的数据预处理方法、增强技术或标注规范。*
## 遗留问题
*总结作者指出的该领域目前仍然存在哪些挑战、悬而未决的问题或未来的研究方向。*
## 代码、模型下载地址
*如果论文或其引用的工作提供了代码或预训练模型的链接，请在此处列出。*
|
服务端脚手架
FAQ
AI实现的需求不如预期
按以下优先级检查可能的原因
遗忘/幻觉
遗忘幻觉通常发生在过多轮次的对话记录，或者读取了太长太多的代码时，或者它不停编码停不下来时
对话过程中忘了项目信息。定期@相关文档，尤其是prd、开发计划
AI基于虚构或者过时的背景信息乱答。提示词加入”重新读取xx代码文件”、”请分析并给出依据”之类的要求
AI持续疯狂输出。提示词“每完成一步之后，等待用户审查和验证结果”
它忘了指令
重申指令：如”以下是之前我给你的指令，依照此指令继续: …”
让AI自己不断重申指令：“你必须在每个步骤完成之后复述产出要求，因为你总是忘记产出要求。你的复述以”我将在每个步骤完成之后复述产出要求：”开头”
AI只遵守部分指令
尽早打断AI执行，指出它未遵守哪些指令然后继续。提示词示例：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| 你未遵守规则中以下几条:
```由于涉及代码较多，请你对照下述产出结构，拆分成多个步骤逐步执行。
错误做法：将调用链涉及到的所有文件分析出结果，才将结果写入文档。
正确做法：每分析完一个节点，立刻调用工具将结果写入文档。```
务必遵守规则中每一条:
```你的任务是，从入口代码开始分析出完整的代码调用链。不仅仅分析入口文件本身，请依序追踪调用链涉及到的代码文件、配置文件，输出其核心业务逻辑的**调用链信息**。调用链由节点组成，一个调用节点可以是codebase中的一个函数、一个类的方法。
由于涉及代码较多，请你对照下述产出结构，拆分成多个步骤逐步执行。
错误做法：将调用链涉及到的所有文件分析出结果，才将结果写入文档。
正确做法：每分析完一个节点，立刻调用工具将结果写入文档。
你必须在每个步骤完成之后**复述产出要求**，因为你总是忘记产出要求。你的复述以“我将在每个步骤完成之后复述产出要求：”开头。
# 产出要求
请按照以下结构，使用Markdown格式生成详细的调用链说明。
## 调用链
逐一为每个节点提供以下信息，**仅关注重要的函数/方法调用**：
### 节点(以函数/类方法命名节点)
所在代码文件相对路径
用途
逐一说明输入参数
输出说明
## 整体用途
详述调用链的整体用途
## 目录结构
调用链涉及到的文件及其所属的目录结构
## 调用时序图
生成mermaid sequenceDiagram格式的时序图。participant为**文件相对路径**，展示为完成一个典型请求，以及调用时传递的参数和返回值。```
|
后期迭代越来越慢怎么办
项目初期AI完成任务顺畅、很快，越到后期越慢
原因
迭代功能拆分过大，或者它依赖的详细设计文档越来越长，或者越来越乱，对它造成了负面影响
方案
需求/需求迭代作为最重要的基础，详细设计文档作为最重要的编码蓝图，是我们vibe coding过程中核心把控的重点。
将需求拆分成需求迭代
让AI从易于实现角度将需求拆分成多个迭代版本，逐字审核：
后期给AI需求相关内容只此一份，因此需求迭代文档应包含所有需求内容，不应出现“见需求文档第x节”字样
仔细推演每个迭代版本，确保实现的代码规模大小合适，宜小不宜大。对于代码少但是难度高的情况，应单独列为一个迭代版本。
如无特殊情况，需求迭代版本文档严禁出现技术设计甚至代码。需求文档中的设计/代码更像鸡肋，有而不精，严重干扰后期技术设计和实现。对于需要多次迭代的项目而言，技术/实现的变化可能性远大于需求变化的可能性，需求文档中的设计/代码动辄过时，对后期造成严重误导。
每个迭代单独一份详细设计文档
需要多次迭代的项目，详细设计文档作为编码的实现蓝图，在编码环节起核心主导地位，重要性不言而喻。
为每个迭代创造一份详细设计文档。为每个技术栈(后台、前端、客户端)单独创造一份详细设计文档
在多次迭代开发项目中，如果只有一份详细设计文档，随着迭代进展，详细设计文档越来越长，从几百行增长到几千行，AI越来越难利用
AI存在很大概率将详细设计文档越改越冗余，冲突越来越多
每个迭代有专属的设计文档，编码蓝图更加聚焦
仔细审核详细设计文档
流程图、调用时序图是设计文档的核心。反复推演和修改流程图/时序图，直至合理。流程问题是APP开发中最大的BUG
详细设计文档中尽量不要写代码，代码冗长且容易过时，而且不易审核。优先用流程图/时序图表达实现逻辑，避免文档冗长
流程
对于大任务、长时间编码的任务，按以下步骤
将需求文档规划为需求迭代。需求迭代要包含所有需求细节，下一步不再需要需求文档
根据需求迭代文档制作迭代1详细设计文档。要求迭代1详细设计中整体考虑所有迭代，但是后继迭代以空实现占位
根据需求迭代文档和迭代1详细设计文档，完成迭代1编码
根据需求迭代文档和迭代1详细设计文档，制作迭代2详细设计文档
根据需求迭代文档和迭代2详细设计文档，完成迭代2编码
回到第4步，即根据需求迭代文档和迭代2详细设计文档，制作迭代3详细设计文档、完成迭代3编码，如此循环往复，直至完成所有迭代编码
示例
1
| 请完成需求规划 @readme_xx_prdplan.md 中的迭代4后端详细设计。目前已完成了迭代1~3设计和编码，迭代3的详细设计见 @readme_xx_lld_it3.md 。技术选型为xxx。严格遵守设计规则 @LLDesign.md 。目录结构务必包含后期迭代文件，并注释为用固定的空返回值占位。如有疑惑请提出并等待我回答，你切勿自问自答。
|
AugmentCode 出现任务理解偏差或缺乏任务规划的应对策略
背景
在实际使用 AugmentCode（AI 编码助手）过程中，常出现如下问题：
原因
方案
方案一：引入提示词，强制任务规划优先执行
1
| 做任何任务前，一定要先进行任务规划！先生成任务清单（task list）后再开始任何编码！
|
- 效果：AugmentCode 将始终从 目标分解与步骤规划 开始任务，有助于生成合理的任务流与执行路径，并提高后续编码的连贯性与正确性，甚至当你发现有出入时，可立即中断或者介入修改任务信息
方案二：将核心实现逻辑写入 AI 可读的 Task List 中
- 对于结构复杂、步骤繁多的任务，建议将实现逻辑显式写入如下格式的 Task List 中
迁移代码
步骤1
讨论你的迁移需求。示例
1
2
3
4
5
6
| 我需要将服务端所有用到公式识别的地方替换为texteller。代码仓库下的texteller目录为第三方，我不希望直接引用第三方，而是通过迁移代码的方式在app目录下实现texteller推理代码。
具体要求：
1. 迁移方式：不直接引用第三方 texteller 目录，而是在 app 目录下重新实现推理代码
2. 架构设计：完全遵循 app 下的当前目录组织方式和架构设计
3. 模型处理：遵从 texteller 的模型文件处理方式
仅仅讨论需求，切勿编码 @prd.md
|
步骤2
分析代码。示例
1
| codebase下的TexTeller是第三方公式识别源码。请为我搜索它的推理代码入口，并以此为起点分析推理调用链，将结果保存为readme_texteller_infer.md。务必遵守规则 @parsecallchain.md
|
如果现有代码由vibe coding流程生成，那么已经有了详细设计文档，详细设计文档留作下一步使用。否则，需要让AI分析现有代码
步骤3
生成迁移蓝图，示例
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
| 请根据当前codebase的详细设计文档 @readme_xx_lld.md、第三方代码调用链 @readme_texteller_infer.md、迁移需求 @readme_mig_prd.md，完成迁移蓝图设计，并将结果保存为 texteller_migration_bluprint.md。
你必须牢记并遵从以下优先级设计迁移方式：
1. 优先直接复制代码，迁移风险最低
2. 复制部分代码次之
3. 参照源码重新实现逻辑风险较高
蓝图文档内容结构：
## 文件映射关系表
源文件(texteller目录下)和目标文件(app目录下)映射，迁移方式(copy还是重新实现逻辑)
## 逐个文件说明
逐一对每个目标文件说明：
目标文件用途
逐一对目标文件每个类中的方法说明：
详细的输入参数说明
输出结构说明
实现逻辑：
对于修改或者重新实现的代码，用Mermaid图说明实现流程和要点。如果流程中参与者涉及到本方法外部，采用时序图；否则采用流程图。关键字和操作符之外的纯文本用双引号包围。不得在此写代码。
对于复制操作，详述操作步骤、需要处理的风险。不得在此写代码。
|
步骤4
迁移代码
1
| 务必根据@texteller_migration_bluprint.md制定任务规划，然后完成texteller公式识别迁移
|
多AI验证编码编码方向
背景
很多时候，AI Agent给出的实现可能带来隐患，在AI提出思路或者实现代码的时候，可以换个AI来验证思路与边界条件。
举例：
例子一：
提问：
1
| 因为我的模型在多卡训练过程中存在显存不均衡问题。我让claude code给我生成了一个解决方案。claude code给我分析是因为one-hot矩阵的问题。我不知道one-hot矩阵是否会带来显存不均匀和占用显存较大的问题。同时，claude code给我修改了这部分代码，如图所示。claude code认为这个修改，是正面优化，是无副作用的。请你帮我检查看下，图中删除代码的片段，是否完全等价于新增代码的部分？是否真的是完全无作用的？请你深度思考。
|
例子二：
提问：
多AI验证编码优化边界情况
背景：
单个AI AGENT，经常由于上下文的原因，认为其代码编写的已经尽善尽美了。这时候代码优化进展就困难了。
使用多个AI AGENT来完成代码审视和解决方案的提出，交由写代码的AI AGENT来完成代码修复。这样相当于拥有了新思路和旧的上下文代码。
不同AI AGENT之间，需要在明确地传递所有需要的上下文消息。
举例
单个AI AGENT（后续命名为同事B）觉得已经完美修复了，也检查不出问题。输出文档报告1.md扔给 另一个 AI AGENT检查。（后续命名为同事A）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| 项目U（ @UniMERNet） 是一个公式识别算法的项目。我之前实现了一个 "序列长度动态优化"的优化方法，来让我的模型训练过程更佳流畅更佳快速。
为此，我在其中还实现了一个长度分桶采样的功能，以让我模型训练的数据加载更佳平滑，避免出现OOM的情况。
实现的细节相关信息，我已经总结到文档 @readme_unimernet_dynamic_seq_length.md 中了。
但是你的同事觉得那份代码有问题，所以进行了“长度分桶采样”功能的修复工作。
你同事的修复工作总结报告为 @DISTRIBUTED_FIX_REPORT.md,你可以进行参考。
虽然我没有验证，但我觉得应该相对可靠的。但还需要进一步彻底排查问题。
现在，我们进行下一轮排查任务。工作目录在 @UniMERNet 中。
你需要深入代码，从训练入口脚本 @UniMERNet\scripts\train.sh 出发，以代码的实际数据流向和调用流程为依据，
（1）检查 "长度分桶采样"的优化代码 是否存在潜在风险和错误问题。
（2）检查模型训练管道过程中，是否存在可优化的空间或未想到的错误、以及是否存在一些代码隐患。
请你 ultrathink , 你需要为我分析问题，定位出了原因之后，再帮我解决它。
|
让另一个 AI AGENT分析问题和提供解决方案本身，个人认为是大于直接修复代码的。
第一次，直接修改代码，修改幅度和思路让我觉得隐患太大了。再扔给另一个不同的 AI AGENT（后续命名为同事C）。【实际上一大段的文字，就是描述背景，一次性把所有需要的上下文补齐】
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| 项目U（ @UniMERNet） 是一个公式识别算法的项目。我之前实现了一个 "序列长度动态优化"的优化方法，来让我的模型训练过程更佳流畅更佳快速。
为此，我在其中还实现了一个长度分桶采样的功能，以让我模型训练的数据加载更佳平滑，避免出现OOM的情况。
实现的细节相关信息，我已经总结到文档 @readme_unimernet_dynamic_seq_length.md 中了。
但是你的同事A觉得那份代码有问题，所以进行了“长度分桶采样”功能的修复工作。
你同事A的修复工作总结报告为 @DISTRIBUTED_FIX_REPORT.md,你可以进行参考。
但同事B发现同事A的修复工作不完善，所以同事A被我给开除了。
同事B对同事A的工作结果进行了新一轮的补充和修复，并且对于整个训练管道也进行了以此排查，解决和提出了一些问题。
同事B进一步的修复工作总结为 @COMPREHENSIVE_FIX_REPORT.md.
现在，由你来检查同事B的工作完成情况，对于同事B在文档提到的一些优化建议，我们可以暂时不理会，现专注于问题修复工作。
现在，我们进行下一轮排查任务。工作目录在 @UniMERNet 中。
你需要深入代码，从训练入口脚本 @UniMERNet\scripts\train.sh 出发，以代码的实际数据流向和调用流程为依据，
（1）检查 "长度分桶采样"的优化代码 是否存在潜在风险和错误问题。
（2）检查模型训练管道过程中，是否存在可优化的空间或未想到的错误、以及是否存在一些代码隐患。
请你 ultrathink , 你需要为我分析问题，定位出了原因之后，再帮我解决它。
任务结束后，将你的分析，你的工作内容，你的总结，输出到文档 COMPREHENSIVE_FIX_REPORT_v2.md 中
|
写代码工作交回给主体写代码的****AI AGENT，保持代码的编程思路一致。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| 刚刚，我将你修复的工作内容，将代码和你的工作报告交给了你的同事C进行代码检查及代码修复。
你的同事C从你的代码发现了一些问题，进行了分析，给了他的解决方案。他的分析和解决方案，总结了一份工作文档 @COMPREHENSIVE_FIX_REPORT_v2.md .
现在，请你对同事C的工作结果进行交叉验证。
同样地，工作目录仍是 项目U（ @UniMERNet）， 是一个公式识别算法的项目。
你需要深入代码，从训练入口脚本 @UniMERNet\scripts\train.sh 出发，以代码的实际数据流向和调用流程为依据，
（1）检查 "长度分桶采样"的优化代码 是否存在潜在风险和错误问题。
（2）检查模型训练管道过程中，是否存在可优化的空间或未想到的错误、以及是否存在一些代码隐患。
请你 ultrathink , 你需要为我分析问题，定位出了原因之后，再帮我解决它。
|
后续进行迭代的解决方案和编码的交叉验证即可。