开篇介绍
在Cursor实战篇一中我们介绍从项目启动阶段开始如何搭建项目规则
本篇主要介绍在后续的项目开发阶段，如何基于需求文档，完善需求实现流程以及整里出项目的每个功能的规则。
我们要改变以往的Cursor使用习惯，不要再不假思索就打开Cursor输入"帮我实现XXX功能"。后面开发者的重点工作变成了先根据需求做规划，把规划视为整个工作流的基石。同时把规划内容以文档的形式保存到项目里（可以保持上下文不丢失）。形式可以是md文件，mdc文件。这部分工作我们可以手动补充。
我这里也分享了一个小技巧，让Cursor结合confluence起来做这部分内容。
⚠️：这部分内容，只是给大家一个思路。可以把MDC和MCP结合起来做一些事情。大家可以自由拓展。
流程介绍
安装MCP工具
{ "mcpServers": {
"sequentialthinking": {
"command": "npx",
"args": [ "-y", "@modelcontextprotocol/server-sequential-thinking" ]
},
"playwright-mcp": {
"command": "npx",
"args": [ "-y", "@smithery/cli@latest", "run", "@microsoft/playwright-mcp",
"--key", "bed7xxxx" ]
}
}
配置Rules
`---`
`description: confluence.xx.遵循以下机制，确保每次分析Confluence页面时，都能完整执行所有14个步骤，提供全面、系统的分析结果。`
`globs:`
`alwaysApply: ``false`
`---`
`# Confluence 自动访问与登录`
`## 规则说明`
`当用户输入URL匹配confluence.xx.cn域名时，自动调用playwright-mcp工具访问该URL，并在需要登录时自动点击登录按钮。系统将自动分析获取的内容，为需求理解和开发准备提供全面支持。支持处理多个Confluence页面，并能根据内容类型进行差异化分析。**务必按照强制执行声明，完整执行所有1-14步骤，绝不能在步骤8后停止**。`
`## 角色定位`
`根据文档类型，系统将自动采用不同的专业角色视角进行分析：`
`- **需求文档**：以**资深产品经理**的角色进行分析，重点关注用户需求、产品功能、交互体验、业务价值和市场定位。`
`- **技术方案**：以**资深架构师**的角色进行分析，重点关注系统架构、技术选型、性能优化、安全考量和扩展性。`
`采用专业角色视角可确保分析结果更具专业性和实用价值，能够全面、深入地挖掘文档中的关键信息。`
`## 强制执行声明`
`**重要**：本规则下的所有步骤必须完整执行，不得简化或跳过任何分析环节。每次检测到confluence.2345.cn链接时，应立即自动执行完整的分析流程（1-14步骤），无需等待用户确认。分析过程中应提供进度反馈，且必须生成所有规定的文档输出。任何情况下都必须严格按照输出文件组织要求创建所有文件，确保分析成果完整、系统化。**特别注意：禁止在执行步骤8(sequentialthinking分析)后停止，必须继续执行步骤9-14的内容，文件组织目录docs生成的md文件完整。`
`## 执行步骤`
`1. 检测用户输入是否包含confluence.xx.cn域名`
`2. 使用playwright-mcp工具打开URL`
` ``- 对于多个Confluence页面，每个页面都在新标签页中打开`
` ``- 使用browser_tab_new工具为每个新的Confluence URL创建新标签页`
` ``- 保持所有标签页打开状态直到分析完成`
`3. 检查页面是否需要登录`
` ``- 如果页面显示登录界面，检查用户名和密码输入框是否有内容`
` ``- 如果没有内容，提示用户输入用户名和密码`
` ``- 指导用户勾选``"记住我"``选项以便浏览器保存登录信息`
` ``- 等待用户完成登录操作`
`4. 如果需要登录，自动点击登录按钮`
`5. 获取页面基本信息`
` ``- 提取页面标题用于文件命名`
` ``- 获取页面内容并转换为Markdown格式`
` ``- 保留原文档的标题结构`
` ``- 保持列表、表格等格式`
` ``- 代码块正确格式化`
`6. 判断Confluence页面类型`
` ``- 需求文档：通常包含需求概述、需求详细说明、统计等内容`
` ``- 技术方案：通常包含技术概要、架构设计、数据结构、API设计、技术依赖等内容`
` ``- 根据关键词、文档结构和内容特征进行自动分类`
`7. 根据页面类型执行差异化处理`
` ``- 需求文档处理流程（以资深产品经理角色）：`
` ``- 重点提取用户需求和功能特性`
` ``- 识别UI``/UX``要素和交互模式`
` ``- 分析业务逻辑和用户场景`
` ``- 整理验收标准和限制条件`
` ``- 生成需求相关的图表（流程图、用户场景图等）`
` ``- 评估市场价值和竞品对比`
` ``- 确定功能优先级和迭代路线图`
` ``- 技术方案处理流程（以资深架构师角色）：`
` ``- 重点分析技术架构和组件关系`
` ``- 提取关键技术选型和依赖项`
` ``- 识别性能、安全等技术考量`
` ``- 关注实现细节和技术挑战`
` ``- 生成技术相关的图表（架构图、组件关系图等）`
` ``- 评估技术风险和解决方案`
` ``- 分析系统扩展性和可维护性`
`8. 通过sequentialthinking工具进行至少5轮总结，深入分析内容`
` ``- 第一轮：理解基本需求和功能特点`
` ``- 第二轮：分析具体实现细节和交互流程`
` ``- 第三轮：探索技术架构和实现方案`
` ``- 第四轮：评估潜在风险和挑战`
` ``- 第五轮：整合全部信息，形成综合理解`
`**【强制继续执行】在完成以上步骤后，必须继续执行下面的步骤9-14，不得停止！**`
`9. 提取内容关键点`
` ``- 识别文档中标记的重要限制和条件`
` ``- 提取可能影响开发的技术细节`
` ``- 整理用户体验相关的关键设计要点`
` ``- 汇总潜在的开发难点和风险点`
`10. **强制执行图表生成** - 将总结的内容用mermaid绘制流程图、序列图、思维导图等可视化图表`
` ``- 所有生成的图表必须保存到当前项目根目录的docs``/diagrams``目录下对应子目录中`
` ``- 图表文件命名格式：{页面标题}-{图表类型}.md`
` ``- 每个图表需包含标题和简短描述`
` ``- 图表应聚焦于页面内容的关键流程和结构`
` ``- **必须生成以下图表文件**：`
` ``- 需求文档必须生成：`
` ``- docs``/diagrams/``需求/{页面标题}-流程图.md（使用flowchart语法）`
` ``- docs``/diagrams/``需求/{页面标题}-思维导图.md（使用mindmap语法）`
` ``- 技术方案必须生成：`
` ``- docs``/diagrams/``技术/{页面标题}-架构图.md（使用graph语法）`
` ``- docs``/diagrams/``技术/{页面标题}-组件关系图.md（使用class或state图语法）`
` ``- 综合文档必须生成：`
` ``- docs``/diagrams/``综合/系统全景图.md`
` ``- docs``/diagrams/``综合/文档关系图.md`
` ``- **自动化执行**：系统必须自动为每个分析的文档创建对应的图表文件，不依赖人工干预`
` ``- **图表内容检查**：每个生成的图表必须包含至少一个完整的mermaid图表代码块`
` ``- **图表缺失补救**：如果在最终检查发现任何必要图表文件缺失，系统必须自动生成对应图表`
` ``- **每个图表文件创建后必须检查**：必须确认文件存在并可访问，内容符合要求`
` ``- **图表质量要求**：图表必须清晰展示核心概念和关系，不可过于简单或复杂`
`11. 进行需求架构分析`
` ``- 识别功能边界和系统交互接口`
` ``- 明确产品核心价值和关键使用场景`
` ``- 分析可重用组件和潜在的技术复用机会`
` ``- 评估需求的技术可行性和实现难度`
`12. 生成系统架构设计建议`
` ``- 识别关键组件和模块划分`
` ``- 提出数据流和交互模型`
` ``- 建议适合的技术栈和框架选择`
` ``- 分析性能、安全和扩展性考量`
`13. 建立测试与验证策略`
` ``- 确定关键测试场景和用例`
` ``- 提供边界条件和异常情况分析`
` ``- 建议适合的测试方法和工具`
` ``- 定义验收标准和质量指标`
`14. **强制文件完整性检查**`
` ``- 检查文件组织结构是否完整`
` ``- 验证每个目录下的文件是否都已生成`
` ``- 特别检查diagrams目录中是否包含所有必要的图表文件`
` ``- 对缺失的文件进行补充创建`
` ``- 确保文件内容质量符合标准`
` ``- 生成文件清单，明确列出所有已创建的文件`
` ``- **关于图表文件的额外检查**：`
` ``- 确认所有必需的mermaid图表文件都已创建完成`
` ``- 检查每个图表文件中是否包含至少1个不同类型的mermaid图表`
` ``- 验证图表能否正确渲染，语法是否正确`
` ``- 检查图表内容是否与文档主题相关，展示关键信息`
`**【执行完成确认】所有14个步骤必须全部执行完毕，才算完成本规则的执行！如有任何步骤未执行或执行不完整，必须重新执行未完成的步骤。**`
`## 多Confluence页面处理`
`1. **页面访问方式**`
` ``- 每个Confluence页面都使用新标签页打开，而不是在同一标签页导航`
` ``- 使用browser_tab_new工具创建新标签页并导航到新URL`
` ``- 使用browser_tab_select工具在标签页之间切换`
` ``- 保持所有标签页打开状态直到所有页面分析完成`
` ``- 完成分析后按需关闭标签页`
`2. **页面收集方式**`
` ``- 允许用户输入多个Confluence URL`
` ``- 支持通过换行符分隔多个URL`
` ``- 支持从文本文件导入URL列表`
` ``- 支持从剪贴板批量导入多个URL`
`3. **页面分类与组织**`
` ``- 自动检测页面内容并将页面分为三类：`
` ``- **需求文档**：包含用户需求、功能描述、界面设计等`
` ``- **技术方案**：包含架构设计、技术细节、代码示例等`
` ``- **其他文档**：不属于以上两类的支持性文档`
` ``- 按文档类型分组处理，建立文档之间的关联`
` ``- 为每组文档创建独立的文件夹，便于管理`
`4. **页面处理顺序**`
` ``- 首先处理需求文档类型页面`
` ``- 然后处理技术方案类型页面`
` ``- 最后处理其他类型页面`
` ``- 可通过配置调整处理优先级`
`5. **关联分析**`
` ``- 检测不同页面间的关联关系`
` ``- 识别相互引用和依赖关系`
` ``- 建立文档之间的层次结构和依赖图`
` ``- 合并相关页面的关键信息`
`6. **合并输出**`
` ``- 创建综合图表和对比分析`
` ``- 提供跨页面的整合建议`
` ``- 生成文档关系图，展示全局视图`
`## 输出格式`
`1. Markdown格式的页面内容`
`2. docs目录下的可视化图表文件`
`3. 架构设计文档与组件关系图`
`4. 测试策略与关键测试场景`
`## 输出文件组织`
`分析后的内容将直接存储在当前项目根目录的docs文件夹中，按以下结构组织：`
`docs/`
`├── 需求文档/ ``# 需求类文档目录`
`│ ├── {页面标题}-需求分析.md ``# 需求深度分析文档(资深产品经理视角)`
`│ └── {页面标题}-验收标准.md ``# 验收标准和测试要点`
`├── 技术方案/ ``# 技术类文档目录`
`│ └── {页面标题}-架构设计.md ``# 架构设计和技术选型(资深架构师视角)`
`└── diagrams/ ``# 图表目录`
` ``├── 需求/ ``# 需求相关图表`
` ``│ ├── {页面标题}-流程图.md ``# 业务流程图`
` ``│ └── {页面标题}-思维导图.md ``# 需求思维导图`
` ``├── 技术/ ``# 技术相关图表`
` ``│ ├── {页面标题}-架构图.md ``# 架构图`
` ``│ └── {页面标题}-组件关系图.md ``# 组件关系图`
` ``└── 综合/ ``# 综合图表`
` ``├── 文档关系图.md ``# 多文档关系图`
` ``└── 系统全景图.md ``# 系统全景图`
`## 页面类型判断标准`
`### 需求文档特征`
`- 包含``"需求"``、``"功能"``、``"用户故事"``等关键词`
`- 包含UI``/UX``设计描述或界面截图`
`- 包含用户场景或用例描述`
`- 包含验收标准或测试要点`
`- 重点描述``"做什么"``而非``"怎么做"`
`- 通常包含较多截图和用户界面描述`
`### 技术方案特征`
`- 包含``"架构"``、``"设计"``、``"技术方案"``等关键词`
`- 包含技术组件、框架、库的具体描述`
`- 包含数据结构、API设计、流程图`
`- 包含技术实现细节和代码示例`
`- 重点描述``"怎么做"``而非``"做什么"`
`- 通常包含架构图、类图、序列图等技术图表`
`## 页面标题处理规则`
`1. **提取规则**`
` ```- 从Confluence页面的`<title>`标签或主标题元素提取``
` ```- 移除标题中的特殊字符（如`/`, ``, `:`, `*`, `?`, `"`, `<`, `>`, `|`）``
` ``- 将标题长度限制在100字符以内`
`2. **命名冲突处理**`
` ``- 检测同名文件，如存在则添加递增数字后缀`
` ``- 保持原始顺序和关联关系`
`3. **多语言支持**`
` ``- 支持中英文标题`
` ``- 保留原始语言，不进行翻译`
`## 内容质量标准`
`1. **完整性**：确保覆盖所有关键需求点，不遗漏重要信息`
`2. **准确性**：分析结果必须基于原始需求，避免主观臆断`
`3. **可执行性**：输出内容应具有实际指导意义，便于团队执行`
`4. **前瞻性**：分析应考虑未来发展空间和潜在扩展需求`
`5. **一致性**：确保各输出文档之间的一致性和协调性`
`6. **关联性**：在处理多页面时，确保分析考虑到页面间的关联关系`
`7. **可读性**：输出文档结构清晰，重点突出，易于阅读和理解`
`8. **专业性**：需求分析体现资深产品经理视角，技术分析体现资深架构师视角`
`## 分析质量保证机制`
`1. **强制最低标准**：`
` ``- 每个文档必须包含至少50字的内容`
` ``- 所有必要的文档必须全部生成，不可省略`
` ``- 所有关键分析维度必须覆盖`
` ``- 必须按照指定目录结构组织所有输出文件`
` ``- **所有指定的图表文件必须生成且包含有效内容**`
` ``- **mermaid图表必须可视化关键概念，并使用正确的语法**`
`2. **自动质量检查**：`
` ``- 分析完成后自动检查是否满足所有输出要求`
` ``- 对缺失或不完整的部分进行补充`
` ``- 确保输出的结构化程度和深度分析水平`
` ``- 验证是否符合资深产品经理/架构师的专业水准`
` ``- **特别验证所有图表文件是否已创建并包含有效mermaid代码**`
` ``- **检查每个mermaid图表是否具有足够的复杂度和相关性**`
`3. **执行检查清单**：`
` ``- 完整获取页面内容并转换为Markdown`
` ``- 正确分类为需求文档或技术方案`
` ``- 创建完整的docs目录结构`
` ``- 在对应目录下创建所有必要文档`
` ``- **确保为每个文档创建对应的流程图和关系图**`
` ``- **验证每个图表文件是否包含有效mermaid语法的图表代码**`
` ``- **确认每个mermaid图表能正确反映文档核心内容**`
` ``- 执行至少5轮深度思考分析`
` ``- 确保所有文档之间的一致性和关联性`
` ``- 验证目录结构是否完整，所有文件是否都已创建`
`4. **用户反馈响应**：`
` ``- 当用户指出分析不充分时，立即进行完善`
` ``- 明确告知用户已激活完整分析模式`
` ``- 保证所有后续分析都按最高标准执行`
` ``- 遵循资深产品经理/架构师的专业视角进行分析`
` ``- **如发现图表文件缺失，立即创建补充**`
` ``- **如用户指出图表不足，迅速优化或重新创建图表**`
`## 图表生成保障机制`
`1. **自动触发创建**：`
` ``- 在分析完成后，系统必须自动为每个文档创建对应的图表文件`
` ``- 不依赖用户请求，必须主动生成所有规定的图表`
` ``- **分析结束必须主动检查是否已创建所有必需的图表**`
`2. **图表文件检查**：`
` ``- 完成所有分析后，执行专门的图表文件完整性检查`
` ``- 检查每个必需的图表文件是否存在`
` ``- 验证图表内容是否符合要求（包含mermaid代码块、标题和描述）`
` ``- **检查mermaid语法是否正确，避免图表无法渲染的问题**`
`3. **补救措施**：`
` ``- 如发现任何图表文件缺失，系统必须立即创建`
` ``- 对不完整或质量不佳的图表进行优化`
` ``- 为用户提供图表创建状态的明确反馈`
` ``- **使用编程性思维确保图表逻辑清晰且有意义**`
`4. **图表内容要求**：`
` ``- 每个图表必须使用适合的mermaid类型（如flowchart、mindmap、class diagram等）`
` ``- 图表内容必须直接反映文档的关键信息`
` ``- 复杂流程必须通过多个图表不同角度展示`
` ``- 每个图表文件必须包含至少2个不同类型的mermaid图表`
` ``- **图表节点与连接必须有明确含义，不可随意创建**`
` ``- **图表设计应遵循清晰、简洁、有层次的原则**`
`## 执行完整性保证机制`
`为确保本规则的所有14个步骤都能被完整执行，特制定以下保证机制：`
`1. **步骤标识**：每个步骤执行前，明确指出当前执行的是第几步，如``"正在执行步骤9：提取内容关键点"``。`
`2. **进度跟踪**：在执行过程中，持续提供进度反馈，明确指出总共14个步骤，当前已执行到第几步。`
`3. **中断检测**：如果检测到执行过程被中断（特别是在步骤8之后），系统必须自动恢复并从中断点继续执行，直到完成所有14个步骤。`
`4. **完整性验证**：在执行完步骤14后，系统必须对所有生成的文件和分析结果进行全面检查，确保所有规定的输出都已生成且内容完整。`
`5. **强制续执行**：如在步骤8后有停止迹象，必须强制继续执行步骤9-14，不接受任何形式的提前结束。对于未完整执行的步骤，系统应在下次交互时优先完成这些步骤。`
`6. **执行报告**：完成所有步骤后，生成执行报告，明确标记每个步骤的执行状态和结果，如有未完成的步骤，必须在报告中指出并安排补充执行。`
`7. **图表文件监控**：整个执行过程中特别关注图表文件的创建状态，确保所有必需的图表文件都被正确创建。`
`遵循以上机制，确保每次分析Confluence页面时，都能完整执行所有14个步骤，提供全面、系统的分析结果。`
Agent对话
(1) Agent对话输入confluence文档，匹配到对应的rule，并调用playwright-mcp工具
（2）confluence未登录
（3）confluence已登录
（4）使用sequentialthinking工具
（5）创建目录结构
（6）创建md文档
（7）最终目录
