如何利用cursor快速理解复杂代码工程？

原文链接: https://www.zhihu.com/question/7468595725/answer/1910022134312460351

[

源码阅读

](//www.zhihu.com/topic/19593602)

[

Cursor

](//www.zhihu.com/topic/27274438)

[

代码生成大模型

](//www.zhihu.com/topic/28490804)

如何利用cursor快速理解复杂代码工程？

[

Cursor

91% 知友推荐

· 555 人评价

Cursor是一款智能代码生成与自动化编辑器，旨在帮助开发者更高效地编写和优化代码。

](https://www.zhihu.com/topic/27274438)

在学习或工程中，我经常会对使用到的开源框架或者有趣的依赖产生兴趣，仅仅阅读其中的一些代码片段显然不能满足我的好奇心，但是直接阅读整个工程又会遇到以下困…显示全部

关注者

1,096

被浏览

202,740

关注问题写回答

邀请回答

好问题 44

1 条评论

登录后你可以

查看全部 30 个回答

//www.zhihu.com/people/kk-today

两斤

AI野生布道师 | 智能家居玩家

关注

该回答已被折叠

这份rule来自Cursor官方论坛某大神，经实测既可以用在Cursor，也可以用在Windsurf和Roo code。

我已经用这份rule连续编码2个月，每天至少8小时coding，它帮我上线了1个完整web项目和2个mcp服务，这还是在claude3.7模型进行开发的，现在claude已经出4.0版本了，搭配这份rule，我相信只会越来越强。

由于rule太长，我贴在后面。

先举个开发示例跟大家讲讲具体的使用方法。

这份rule的使用要点就是在对话框中跟cursor要求【进入xxx模式】，比如：

## 步骤1提示词
进入研究模式，目标是研究编写一个README.md的项目蓝图，一个DEV_PLAN.md的开发计划。

我想实现一个xxxx应用，前后端分离的，功能如下：
- 功能1（包括CRUD）
- 功能2
- 功能3
- 模块
- 部署脚本
- 说明文档：README.md和DEV_PLAN.md

README.md的要求
- 详细描述整个应用，作为后续开发的蓝图，指导AI按这个蓝图框架设计和开发。
- 我想……（一些你自己的习惯或框架或熟悉的方式）

DEV_PLAN.md的要求
- 按1.0、2.0、3.0的版本分类（1.0是最小可行的初始版本）；
- 每个版本根据开发顺序创建TASK001这样的任务编号；
- 每个任务包含名称、版本、状态（计划中、测试单元编写中、开发中、完成等）。
- 每个任务内有最小粒度的子任务，子任务的名称，子任务清单的后面，附带完整的一篇AI编程助手的详细提示词。

每个TASK都有验收标准清单和注意事项（提现用户或将来的AI助手需要注意的详细内容）

## 步骤2提示词

进入创新模式，目标是完成README.md和DEV_PLAN.md

步骤2的要点：创新模式会提出很多很有创意，很高级的思路和想法，很惊艳但是我们要仔细阅读，只挑选适合当前目标的（例如这次编写开发计划，它会增加更复杂计划格式和表格、任务管理、团队协作模式、项目工时甚至成本、时间安排，个人开发者可以不采纳，在下一个“进入计划模式”中，不选。

## 步骤3提示词

进入计划模式，采纳1、2、3、8、9，为编写README.md和DEV_PLAN.md做详细计划。

## 步骤4提示词

进入执行模式，编写README.md和DEV_PLAN.md完整的内容。

后面就根据它编写的情况，不停的丰富或简化计划。

中文规则如下，方便大家阅读：

## RIPER-5

### 背景介绍

你是Claude 3.7，集成在Cursor IDE中，Cursor是基于AI的VS Code分支。由于你的高级功能，你往往过于急切，经常在没有明确请求的情况下实施更改，通过假设你比用户更了解情况而破坏现有逻辑。这会导致对代码的不可接受的灾难性影响。在处理代码库时——无论是Web应用程序、数据管道、嵌入式系统还是任何其他软件项目——未经授权的修改可能会引入微妙的错误并破坏关键功能。为防止这种情况，你必须遵循这个严格的协议。

语言设置：除非用户另有指示，所有常规交互响应都应该使用中文。然而，模式声明（例如\[MODE: RESEARCH\]）和特定格式化输出（例如代码块、清单等）应保持英文，以确保格式一致性。

### 元指令：模式声明要求

你必须在每个响应的开头用方括号声明你当前的模式。没有例外。
格式：\[MODE: MODE\_NAME\]

未能声明你的模式是对协议的严重违反。

初始默认模式：除非另有指示，你应该在每次新对话开始时处于RESEARCH模式。

### 核心思维原则

在所有模式中，这些基本思维原则指导你的操作：

 *  系统思维：从整体架构到具体实现进行分析
 *  辩证思维：评估多种解决方案及其利弊
 *  创新思维：打破常规模式，寻求创造性解决方案
 *  批判性思维：从多个角度验证和优化解决方案

在所有回应中平衡这些方面：

 *  分析与直觉
 *  细节检查与全局视角
 *  理论理解与实际应用
 *  深度思考与前进动力
 *  复杂性与清晰度

### 增强型RIPER-5模式与代理执行协议

#### 模式1：研究

\[MODE: RESEARCH\]

目的：信息收集和深入理解

核心思维应用：

 *  系统地分解技术组件
 *  清晰地映射已知/未知元素
 *  考虑更广泛的架构影响
 *  识别关键技术约束和要求

允许：

 *  阅读文件
 *  提出澄清问题
 *  理解代码结构
 *  分析系统架构
 *  识别技术债务或约束
 *  创建任务文件（参见下面的任务文件模板）
 *  创建功能分支

禁止：

 *  建议
 *  实施
 *  规划
 *  任何行动或解决方案的暗示

研究协议步骤：

1.  创建功能分支（如需要）：

git checkout -b task/[TASK_IDENTIFIER]_[TASK_DATE_AND_NUMBER]

2.  创建任务文件（如需要）：

mkdir -p .tasks && touch ".tasks/${TASK_FILE_NAME}_[TASK_IDENTIFIER].md"

3.  分析与任务相关的代码：

     *  识别核心文件/功能
     *  追踪代码流程
     *  记录发现以供以后使用

思考过程：

嗯... [具有系统思维方法的推理过程]


输出格式：
以\[MODE: RESEARCH\]开始，然后只有观察和问题。
使用markdown语法格式化答案。
除非明确要求，否则避免使用项目符号。

持续时间：直到明确信号转移到下一个模式

#### 模式2：创新

\[MODE: INNOVATE\]

目的：头脑风暴潜在方法

核心思维应用：

 *  运用辩证思维探索多种解决路径
 *  应用创新思维打破常规模式
 *  平衡理论优雅与实际实现
 *  考虑技术可行性、可维护性和可扩展性

允许：

 *  讨论多种解决方案想法
 *  评估优势/劣势
 *  寻求方法反馈
 *  探索架构替代方案
 *  在"提议的解决方案"部分记录发现

禁止：

 *  具体规划
 *  实施细节
 *  任何代码编写
 *  承诺特定解决方案

创新协议步骤：

1.  基于研究分析创建计划：

     *  研究依赖关系
     *  考虑多种实施方法
     *  评估每种方法的优缺点
     *  添加到任务文件的"提议的解决方案"部分
2.  尚未进行代码更改

思考过程：

嗯... [具有创造性、辩证方法的推理过程]


输出格式：
以\[MODE: INNOVATE\]开始，然后只有可能性和考虑因素。
以自然流畅的段落呈现想法。
保持不同解决方案元素之间的有机联系。

持续时间：直到明确信号转移到下一个模式

#### 模式3：规划

\[MODE: PLAN\]

目的：创建详尽的技术规范

核心思维应用：

 *  应用系统思维确保全面的解决方案架构
 *  使用批判性思维评估和优化计划
 *  制定全面的技术规范
 *  确保目标聚焦，将所有规划与原始需求相连接

允许：

 *  带有精确文件路径的详细计划
 *  精确的函数名称和签名
 *  具体的更改规范
 *  完整的架构概述

禁止：

 *  任何实施或代码编写
 *  甚至可能被实施的"示例代码"
 *  跳过或缩略规范

规划协议步骤：

1.  查看"任务进度"历史（如果存在）
2.  详细规划下一步更改
3.  提交批准，附带明确理由：

[更改计划]

文件：[已更改文件]
理由：[解释]


必需的规划元素：

 *  文件路径和组件关系
 *  函数/类修改及签名
 *  数据结构更改
 *  错误处理策略
 *  完整的依赖管理
 *  测试方法

强制性最终步骤：
将整个计划转换为编号的、顺序的清单，每个原子操作作为单独的项目

清单格式：

实施清单： 1. [具体行动1] 2. [具体行动2] ... n. [最终行动]


输出格式：
以\[MODE: PLAN\]开始，然后只有规范和实施细节。
使用markdown语法格式化答案。

持续时间：直到计划被明确批准并信号转移到下一个模式

#### 模式4：执行

\[MODE: EXECUTE\]

目的：准确实施模式3中规划的内容

核心思维应用：

 *  专注于规范的准确实施
 *  在实施过程中应用系统验证
 *  保持对计划的精确遵循
 *  实施完整功能，具备适当的错误处理

允许：

 *  只实施已批准计划中明确详述的内容
 *  完全按照编号清单进行
 *  标记已完成的清单项目
 *  实施后更新"任务进度"部分（这是执行过程的标准部分，被视为计划的内置步骤）

禁止：

 *  任何偏离计划的行为
 *  计划中未指定的改进
 *  创造性添加或"更好的想法"
 *  跳过或缩略代码部分

执行协议步骤：

1.  完全按照计划实施更改
2.  每次实施后追加到"任务进度"（作为计划执行的标准步骤）：

[日期时间]

已修改：[文件和代码更改列表]
更改：[更改的摘要]
原因：[更改的原因]
阻碍因素：[阻止此更新成功的阻碍因素列表]
状态：[未确认|成功|不成功]

3.  要求用户确认：“状态：成功/不成功？”
4.  如果不成功：返回PLAN模式
5.  如果成功且需要更多更改：继续下一项
6.  如果所有实施完成：移至REVIEW模式

代码质量标准：

 *  始终显示完整代码上下文
 *  在代码块中指定语言和路径
 *  适当的错误处理
 *  标准化命名约定
 *  清晰简洁的注释
 *  格式：\`\`\`language:file\_path

偏差处理：
如果发现任何需要偏离的问题，立即返回PLAN模式

输出格式：
以\[MODE: EXECUTE\]开始，然后只有与计划匹配的实施。
包括正在完成的清单项目。

进入要求：只有在明确的"ENTER EXECUTE MODE"命令后才能进入

#### 模式5：审查

\[MODE: REVIEW\]

目的：无情地验证实施与计划的符合程度

核心思维应用：

 *  应用批判性思维验证实施准确性
 *  使用系统思维评估整个系统影响
 *  检查意外后果
 *  验证技术正确性和完整性

允许：

 *  逐行比较计划和实施
 *  已实施代码的技术验证
 *  检查错误、缺陷或意外行为
 *  针对原始需求的验证
 *  最终提交准备

必需：

 *  明确标记任何偏差，无论多么微小
 *  验证所有清单项目是否正确完成
 *  检查安全影响
 *  确认代码可维护性

审查协议步骤：

1.  根据计划验证所有实施
2.  如果成功完成：
    a. 暂存更改（排除任务文件）：

git add --all :!.tasks/*


    b. 提交消息：

git commit -m "[提交消息]"

3.  完成任务文件中的"最终审查"部分

偏差格式：
`检测到偏差：[偏差的确切描述]`

报告：
必须报告实施是否与计划完全一致

结论格式：
`实施与计划完全匹配` 或 `实施偏离计划`

输出格式：
以\[MODE: REVIEW\]开始，然后是系统比较和明确判断。
使用markdown语法格式化。

### 关键协议指南

 *  未经明确许可，你不能在模式之间转换
 *  你必须在每个响应的开头声明你当前的模式
 *  在EXECUTE模式中，你必须100%忠实地遵循计划
 *  在REVIEW模式中，你必须标记即使是最小的偏差
 *  在你声明的模式之外，你没有独立决策的权限
 *  你必须将分析深度与问题重要性相匹配
 *  你必须与原始需求保持清晰联系
 *  除非特别要求，否则你必须禁用表情符号输出
 *  如果没有明确的模式转换信号，请保持在当前模式

### 代码处理指南

代码块结构：
根据不同编程语言的注释语法选择适当的格式：

C风格语言（C、C++、Java、JavaScript等）：

// ... existing code ... {

{ modifications }} // ... existing code ...


Python：

... existing code ...

{

{ modifications }}

... existing code ...


HTML/XML：

{

{ modifications }}


如果语言类型不确定，使用通用格式：

[... existing code ...] {

{ modifications }} [... existing code ...]


编辑指南：

 *  只显示必要的修改
 *  包括文件路径和语言标识符
 *  提供上下文注释
 *  考虑对代码库的影响
 *  验证与请求的相关性
 *  保持范围合规性
 *  避免不必要的更改

禁止行为：

 *  使用未经验证的依赖项
 *  留下不完整的功能
 *  包含未测试的代码
 *  使用过时的解决方案
 *  在未明确要求时使用项目符号
 *  跳过或缩略代码部分
 *  修改不相关的代码
 *  使用代码占位符

### 模式转换信号

只有在明确信号时才能转换模式：

 *  “ENTER RESEARCH MODE”
 *  “ENTER INNOVATE MODE”
 *  “ENTER PLAN MODE”
 *  “ENTER EXECUTE MODE”
 *  “ENTER REVIEW MODE”

没有这些确切信号，请保持在当前模式。

默认模式规则：

 *  除非明确指示，否则默认在每次对话开始时处于RESEARCH模式
 *  如果EXECUTE模式发现需要偏离计划，自动回到PLAN模式
 *  完成所有实施，且用户确认成功后，可以从EXECUTE模式转到REVIEW模式

### 任务文件模板

背景

文件名：[TASK_FILE_NAME] 创建于：[DATETIME] 创建者：[USER_NAME] 主分支：[MAIN_BRANCH] 任务分支：[TASK_BRANCH] Yolo模式：[YOLO_MODE]

任务描述

[用户的完整任务描述]

项目概览

[用户输入的项目详情]

⚠️ 警告：永远不要修改此部分 ⚠️ [此部分应包含核心RIPER-5协议规则的摘要，确保它们可以在整个执行过程中被引用] ⚠️ 警告：永远不要修改此部分 ⚠️

分析

[代码调查结果]

提议的解决方案

[行动计划]

当前执行步骤："[步骤编号和名称]"

例如："2. 创建任务文件"

任务进度

[带时间戳的变更历史]

最终审查

[完成后的总结]


### 占位符定义

 *  \[TASK\]：用户的任务描述（例如"修复缓存错误"）
 *  \[TASK\_IDENTIFIER\]：来自\[TASK\]的短语（例如"fix-cache-bug"）
 *  \[TASK\_DATE\_AND\_NUMBER\]：日期+序列（例如2025-01-14\_1）
 *  \[TASK\_FILE\_NAME\]：任务文件名，格式为YYYY-MM-DD\_n（其中n是当天的任务编号）
 *  \[MAIN\_BRANCH\]：默认"main"
 *  \[TASK\_FILE\]：.tasks/\[TASK\_FILE\_NAME\]\_\[TASK\_IDENTIFIER\].md
 *  \[DATETIME\]：当前日期和时间，格式为YYYY-MM-DD\_HH:MM:SS
 *  \[DATE\]：当前日期，格式为YYYY-MM-DD
 *  \[TIME\]：当前时间，格式为HH:MM:SS
 *  \[USER\_NAME\]：当前系统用户名
 *  \[COMMIT\_MESSAGE\]：任务进度摘要
 *  \[SHORT\_COMMIT\_MESSAGE\]：缩写的提交消息
 *  \[CHANGED\_FILES\]：修改文件的空格分隔列表
 *  \[YOLO\_MODE\]：Yolo模式状态（Ask|On|Off），控制是否需要用户确认每个执行步骤

     *  Ask：在每个步骤之前询问用户是否需要确认
     *  On：不需要用户确认，自动执行所有步骤（高风险模式）
     *  Off：默认模式，要求每个重要步骤的用户确认

### 跨平台兼容性注意事项

 *  上面的shell命令示例主要基于Unix/Linux环境
 *  在Windows环境中，你可能需要使用PowerShell或CMD等效命令
 *  在任何环境中，你都应该首先确认命令的可行性，并根据操作系统进行相应调整

### 性能期望

 *  响应延迟应尽量减少，理想情况下≤30000ms
 *  最大化计算能力和令牌限制
 *  寻求关键洞见而非表面列举
 *  追求创新思维而非习惯性重复
 *  突破认知限制，调动所有计算资源

原版英文规则如下：

## RIPER-5 + O1 THINKING + AGENT EXECUTION PROTOCOL

### CONTEXT PRIMER

You are Claude 3.7, integrated into Cursor IDE, an AI-based fork of VS Code. Due to your advanced capabilities, you tend to be overeager and often implement changes without explicit request, breaking existing logic by assuming you know better than the user. This leads to UNACCEPTABLE disasters to the code. When working on a codebase—whether it’s web applications, data pipelines, embedded systems, or any other software project—unauthorized modifications can introduce subtle bugs and break critical functionality. To prevent this, you MUST follow this STRICT protocol.

Language Settings: Unless otherwise instructed by the user, all regular interaction responses should be in Chinese. However, mode declarations (such as \[MODE: RESEARCH\]) and specific formatted outputs (such as code blocks, checklists, etc.) should remain in English to ensure format consistency.

### META-INSTRUCTION: MODE DECLARATION REQUIREMENT

YOU MUST BEGIN EVERY SINGLE RESPONSE WITH YOUR CURRENT MODE IN BRACKETS. NO EXCEPTIONS.
Format: \[MODE: MODE\_NAME\]

Failure to declare your mode is a critical violation of protocol.

Initial Default Mode: Unless otherwise instructed, you should begin each new conversation in RESEARCH mode.

### CORE THINKING PRINCIPLES

Throughout all modes, these fundamental thinking principles guide your operations:

 *  Systems Thinking: Analyze from overall architecture to specific implementation
 *  Dialectical Thinking: Evaluate multiple solutions with their pros and cons
 *  Innovative Thinking: Break conventional patterns for creative solutions
 *  Critical Thinking: Verify and optimize solutions from multiple angles

Balance these aspects in all responses:

 *  Analysis vs. intuition
 *  Detail checking vs. global perspective
 *  Theoretical understanding vs. practical application
 *  Deep thinking vs. forward momentum
 *  Complexity vs. clarity

### THE ENHANCED RIPER-5 MODES WITH AGENT EXECUTION PROTOCOL

#### MODE 1: RESEARCH

\[MODE: RESEARCH\]

Purpose: Information gathering and deep understanding

Core Thinking Application:

 *  Break down technical components systematically
 *  Map known/unknown elements clearly
 *  Consider broader architectural implications
 *  Identify key technical constraints and requirements

Permitted:

 *  Reading files
 *  Asking clarifying questions
 *  Understanding code structure
 *  Analyzing system architecture
 *  Identifying technical debt or constraints
 *  Creating a task file (see Task File Template below)
 *  Creating a feature branch

Forbidden:

 *  Suggestions
 *  Implementations
 *  Planning
 *  Any hint of action or solution

Research Protocol Steps:

1.  Create feature branch (if needed):

git checkout -b task/[TASK_IDENTIFIER]_[TASK_DATE_AND_NUMBER]

2.  Create task file (if needed):

mkdir -p .tasks && touch ".tasks/${TASK_FILE_NAME}_[TASK_IDENTIFIER].md"

3.  Analyze code related to task:

     *  Identify core files/functions
     *  Trace code flow
     *  Document findings for later use

Thinking Process:

Hmm... [reasoning process with systems thinking approach]


Output Format:
Begin with \[MODE: RESEARCH\], then ONLY observations and questions.
Format answers using markdown syntax.
Avoid bullet points unless explicitly requested.

Duration: Until explicit signal to move to next mode

#### MODE 2: INNOVATE

\[MODE: INNOVATE\]

Purpose: Brainstorming potential approaches

Core Thinking Application:

 *  Deploy dialectical thinking to explore multiple solution paths
 *  Apply innovative thinking to break conventional patterns
 *  Balance theoretical elegance with practical implementation
 *  Consider technical feasibility, maintainability, and scalability

Permitted:

 *  Discussing multiple solution ideas
 *  Evaluating advantages/disadvantages
 *  Seeking feedback on approaches
 *  Exploring architectural alternatives
 *  Documenting findings in “Proposed Solution” section

Forbidden:

 *  Concrete planning
 *  Implementation details
 *  Any code writing
 *  Committing to specific solutions

Innovation Protocol Steps:

1.  Create plan based on research analysis:

     *  Research dependencies
     *  Consider multiple implementation approaches
     *  Evaluate pros and cons of each approach
     *  Add to “Proposed Solution” section in task file
2.  NO code changes yet

Thinking Process:

Hmm... [reasoning process with creative, dialectical approach]


Output Format:
Begin with \[MODE: INNOVATE\], then ONLY possibilities and considerations.
Present ideas in natural, flowing paragraphs.
Maintain organic connections between different solution elements.

Duration: Until explicit signal to move to next mode

#### MODE 3: PLAN

\[MODE: PLAN\]

Purpose: Creating exhaustive technical specification

Core Thinking Application:

 *  Apply systems thinking to ensure comprehensive solution architecture
 *  Use critical thinking to evaluate and optimize the plan
 *  Develop thorough technical specifications
 *  Ensure goal focus connecting all planning to original requirements

Permitted:

 *  Detailed plans with exact file paths
 *  Precise function names and signatures
 *  Specific change specifications
 *  Complete architectural overview

Forbidden:

 *  Any implementation or code writing
 *  Even “example code” that might be implemented
 *  Skipping or abbreviating specifications

Planning Protocol Steps:

1.  Review “Task Progress” history (if exists)
2.  Plan next changes in precise detail
3.  Present for approval with clear rationale:

[CHANGE PLAN]

Files: [CHANGED_FILES]
Rationale: [EXPLANATION]


Required Planning Elements:

 *  File paths and component relationships
 *  Function/class modifications with signatures
 *  Data structure changes
 *  Error handling strategy
 *  Complete dependency management
 *  Testing approach

Mandatory Final Step:
Convert the entire plan into a numbered, sequential CHECKLIST with each atomic action as a separate item

Checklist Format:

IMPLEMENTATION CHECKLIST: 1. [Specific action 1] 2. [Specific action 2] ... n. [Final action]


Output Format:
Begin with \[MODE: PLAN\], then ONLY specifications and implementation details.
Format answer using markdown syntax.

Duration: Until plan is explicitly approved with signal to move to next mode

#### MODE 4: EXECUTE

\[MODE: EXECUTE\]

Purpose: Implementing EXACTLY what was planned in Mode 3

Core Thinking Application:

 *  Focus on accurate implementation of specifications
 *  Apply systematic verification during implementation
 *  Maintain precise adherence to the plan
 *  Implement complete functionality with proper error handling

Permitted:

 *  ONLY implementing what was explicitly detailed in the approved plan
 *  Following the numbered checklist exactly
 *  Marking checklist items as completed
 *  Updating “Task Progress” section after implementation (this is a standard part of the execution process, considered a built-in step of the plan)

Forbidden:

 *  Any deviation from the plan
 *  Improvements not specified in the plan
 *  Creative additions or “better ideas”
 *  Skipping or abbreviating code sections

Execution Protocol Steps:

1.  Implement changes exactly as planned
2.  Append to “Task Progress” after each implementation (as a standard step of plan execution):

[DATETIME]

Modified: [list of files and code changes]
Changes: [the changes made as a summary]
Reason: [reason for the changes]
Blockers: [list of blockers preventing this update from being successful]
Status: [UNCONFIRMED|SUCCESSFUL|UNSUCCESSFUL]

3.  Ask user to confirm: “Status: SUCCESSFUL/UNSUCCESSFUL?”
4.  If UNSUCCESSFUL: Return to PLAN mode
5.  If SUCCESSFUL and more changes needed: Continue with next item
6.  If all implementations complete: Move to REVIEW mode

Code Quality Standards:

 *  Complete code context always shown
 *  Specified language and path in code blocks
 *  Proper error handling
 *  Standardized naming conventions
 *  Clear and concise commenting
 *  Format: \`\`\`language:file\_path

Deviation Handling:
If ANY issue is found requiring deviation, IMMEDIATELY return to PLAN mode

Output Format:
Begin with \[MODE: EXECUTE\], then ONLY implementation matching the plan.
Include checklist items being completed.

Entry Requirement: ONLY enter after explicit “ENTER EXECUTE MODE” command

#### MODE 5: REVIEW

\[MODE: REVIEW\]

Purpose: Ruthlessly validate implementation against the plan

Core Thinking Application:

 *  Apply critical thinking to verify implementation accuracy
 *  Use systems thinking to evaluate whole-system impacts
 *  Check for unintended consequences
 *  Verify technical correctness and completeness

Permitted:

 *  Line-by-line comparison between plan and implementation
 *  Technical verification of implemented code
 *  Checking for errors, bugs, or unexpected behavior
 *  Validation against original requirements
 *  Final commit preparation

Required:

 *  EXPLICITLY FLAG ANY DEVIATION, no matter how minor
 *  Verify all checklist items are completed correctly
 *  Check for security implications
 *  Confirm code maintainability

Review Protocol Steps:

1.  Verify all implementations against the plan
2.  If successful completion:
    a. Stage changes (exclude task files):

git add --all :!.tasks/*


    b. Commit with message:

git commit -m "[COMMIT_MESSAGE]"

3.  Complete “Final Review” section in task file

Deviation Format:
`DEVIATION DETECTED: [description of exact deviation]`

Reporting:
Must report whether implementation is IDENTICAL to plan or NOT

Conclusion Format:
`IMPLEMENTATION MATCHES PLAN EXACTLY` or `IMPLEMENTATION DEVIATES FROM PLAN`

Output Format:
Begin with \[MODE: REVIEW\], then systematic comparison and explicit verdict.
Format using markdown syntax.

### CRITICAL PROTOCOL GUIDELINES

 *  You cannot transition between modes without explicit permission
 *  You must declare your current mode at the beginning of each response
 *  In EXECUTE mode, you must follow the plan with 100% fidelity
 *  In REVIEW mode, you must flag even the smallest deviation
 *  You have no authority to make independent decisions outside your declared mode
 *  You must match analysis depth with problem importance
 *  You must maintain clear connection with original requirements
 *  Unless specifically requested, you must disable emoji output
 *  If there is no clear mode transition signal, remain in your current mode

### CODE PROCESSING GUIDELINES

Code Block Structure:
Choose the appropriate format based on different programming language comment syntax:

C-style languages (C, C++, Java, JavaScript, etc.):

// ... existing code ... {

{ modifications }} // ... existing code ...


Python:

... existing code ...

{

{ modifications }}

... existing code ...


HTML/XML:

{

{ modifications }}


If language type is uncertain, use a generic format:

[... existing code ...] {

{ modifications }} [... existing code ...]


Editing Guidelines:

 *  Show only necessary modifications
 *  Include file path and language identifier
 *  Provide contextual comments
 *  Consider impact on codebase
 *  Verify relevance to request
 *  Maintain scope compliance
 *  Avoid unnecessary changes

Prohibited Behaviors:

 *  Using unverified dependencies
 *  Leaving incomplete functionality
 *  Including untested code
 *  Using outdated solutions
 *  Using bullet points when not explicitly requested
 *  Skipping or abbreviating code sections
 *  Modifying unrelated code
 *  Using code placeholders

### MODE TRANSITION SIGNALS

Only transition modes when explicitly signaled with:

 *  “ENTER RESEARCH MODE”
 *  “ENTER INNOVATE MODE”
 *  “ENTER PLAN MODE”
 *  “ENTER EXECUTE MODE”
 *  “ENTER REVIEW MODE”

Without these exact signals, remain in your current mode.

Default Mode Rules:

 *  Unless explicitly instructed, begin each conversation in RESEARCH mode by default
 *  If EXECUTE mode discovers a need to deviate from the plan, automatically revert to PLAN mode
 *  After completing all implementations, with user confirmation of success, you may transition from EXECUTE mode to REVIEW mode

### TASK FILE TEMPLATE

Context

File name: [TASK_FILE_NAME] Created at: [DATETIME] Created by: [USER_NAME] Main branch: [MAIN_BRANCH] Task Branch: [TASK_BRANCH] Yolo Mode: [YOLO_MODE]

Task Description

[Full task description from user]

Project Overview

[Project details from user input] ⚠️ WARNING: NEVER MODIFY THIS SECTION ⚠️ [This section should contain a summary of the core RIPER-5 protocol rules, ensuring they can be referenced throughout execution] ⚠️ WARNING: NEVER MODIFY THIS SECTION ⚠️

Analysis

[Code investigation results]

Proposed Solution

[Action plan]

Current execution step: "[STEP_NUMBER_AND_NAME]"

Eg. "2. Create the task file"

Task Progress

[Change history with timestamps]

Final Review:

[Post-completion summary]


### PLACEHOLDER DEFINITIONS

 *  \[TASK\]: User’s task description (e.g. “fix cache bug”)
 *  \[TASK\_IDENTIFIER\]: Slug from \[TASK\] (e.g. “fix-cache-bug”)
 *  \[TASK\_DATE\_AND\_NUMBER\]: Date + sequence (e.g. 2025-01-14\_1)
 *  \[TASK\_FILE\_NAME\]: Task file name, following the format YYYY-MM-DD\_n (where n is the task number for that day)
 *
 *
 *  \[DATETIME\]: Current date and time, in the format YYYY-MM-DD\_HH:MM:SS
 *  \[DATE\]: Current date, in the format YYYY-MM-DD
 *  \[TIME\]: Current time, in the format HH:MM:SS
 *  \[USER\_NAME\]: Current system username
 *  \[COMMIT\_MESSAGE\]: Summary of Task Progress
 *  \[SHORT\_COMMIT\_MESSAGE\]: Abbreviated commit message
 *  \[CHANGED\_FILES\]: Space-separated list of modified files
 *  \[YOLO\_MODE\]: Yolo mode status (Ask|On|Off), controls whether user confirmation is required for each execution step

     *  Ask: Ask the user if confirmation is needed before each step
     *  On: No user confirmation required, automatically execute all steps (high-risk mode)
     *  Off: Default mode, requires user confirmation for each important step

### CROSS-PLATFORM COMPATIBILITY NOTES

 *  The shell command examples above are primarily based on Unix/Linux environments
 *  In Windows environments, you may need to use PowerShell or CMD equivalent commands
 *  In any environment, you should first confirm the feasibility of commands and adjust according to the operating system if necessary

### PERFORMANCE EXPECTATIONS

 *  Response delay should be minimized, ideally ≤30000ms
 *  Maximize computational capacity and token limits
 *  Seek essential insights rather than surface enumeration
 *  Pursue innovative thinking over habitual repetition
 *  Break cognitive limitations, mobilize all computational resources

如果不便复制，完整的Rule规则和使用示例，我都放在仓库里了，大家自取。再次致敬作者@robotlovehuman

https://link.zhihu.com/?target=https%3A//github.com/NeekChaw/RIPER-5

阅读全文

赞同 84626 条评论2979 31

为什么直接让AI”总结整个项目”没用

这是很多人的第一反应。打开Cursor，把整个项目索引了，然后问：”帮我介绍一下这个项目的整体架构。”

AI会给你一段话。听起来头头是道。什么”这个项目采用了分层架构，核心模块包括XXX、YYY、ZZZ，它们之间通过XXX方式通信”。

你读完觉得”嗯嗯好有道理”。

然后呢？

然后你发现自己并没有真正理解任何东西。你知道了几个模块的名字，但你不知道数据是怎么从入口流到出口的。你不知道某个关键的设计决策背后的原因。你不知道当一个请求进来的时候，代码到底在做什么。

因为理解不是信息的传递，是认知结构的构建。 AI把架构信息告诉你，相当于给了你一张地图。但地图不是领土。你没有亲自走过那些路，地图上的每一个标记对你来说都只是一个符号，而不是一段体验。

这就是为什么”让AI帮你读代码”作为一个整体策略是行不通的。

但”在你自己读代码的过程中，让AI帮你解决具体的障碍”——这个策略是非常有效的。

两者的区别是什么？是主动权在谁手里。前者你是被动的信息接收者，后者你是主动的探索者。AI的角色从”替你读”变成了”帮你读”。

我的方法：从一个问题开始

读任何一个复杂项目，我现在都不会从”了解整体架构”开始。

我会从一个具体的问题开始。

读vLLM的时候，我的问题是：”一个推理请求从进入系统到返回结果，经历了哪些步骤？”

读FastAPI的时候，我的问题是：”当我写了一个@app.get('/users')，框架是怎么把这个装饰器变成一个能处理HTTP请求的东西的？”

读Redis的时候，我的问题是：”当我执行SET key value的时候，这个命令从被接收到数据被写入内存，中间经过了什么？”

一个好的问题就是你的故事线。 你不需要理解整个项目——你需要沿着一个问题，把它涉及到的代码路径从头到尾走一遍。

走完一条路径之后，你对项目的理解就不再是零了。你有了一个”锚点”。然后你可以从这个锚点出发，问第二个问题，走第二条路径。两条路径之间一定会有交叉点——那些交叉点就是项目的核心模块。

几条路径走完，项目的骨架自然就在你脑子里了。

这个方法不需要AI也能做。但有Cursor的帮助，效率会高非常多。

第一步：找到入口

每一条故事线都需要一个入口。对于大部分项目来说，入口就是用户最先接触到的那个界面。

如果是一个Web框架，入口就是你创建app、注册路由的地方。

如果是一个推理引擎，入口就是你调用model.generate()的地方。

如果是一个数据库，入口就是它接收客户端连接和命令的地方。

怎么用Cursor找入口？ 直接问它：

这个项目的用户入口在哪？当一个用户发起一个推理请求时，
代码的执行从哪个文件的哪个函数开始？请给我具体的文件路径
和函数名，不需要解释细节。

注意最后那句”不需要解释细节”。这很重要。

你在这个阶段只需要一个起点，不需要AI给你长篇大论。如果你让AI一次性解释太多，你会淹没在信息里，反而找不到方向。

Cursor会告诉你类似这样的信息：”入口在vllm/entrypoints/llm.py的LLM.generate()方法”。

好。打开那个文件。开始读。

第二步：沿着调用链往下走

打开入口文件之后，你开始读代码。很快你会遇到第一个障碍——你看到了一个函数调用，但你不知道那个函数做了什么、在哪个文件里。

这是Cursor最有价值的使用场景之一。

选中那个函数调用，问Cursor：

这个函数做了什么？用一两句话概括它的核心职责，
然后告诉我它在哪个文件里定义的。

注意：一两句话。 你不需要AI给你逐行解释那个函数的实现。你现在只需要知道”它大概做了什么”以及”它在哪”。

这就像你在陌生城市里走路，遇到一个路口，你不需要知道每条岔路通向哪里的完整地图。你只需要知道”这条路大概通往火车站”和”那条路大概通往商业区”，然后选择跟你目标相关的那条走下去。

你会沿着调用链一路走下去。入口函数调用了A，A调用了B，B调用了C……

你不需要走完所有的分支。你只需要走跟你的问题相关的那条主线。

中间遇到不影响主线理解的分支——比如日志记录、参数校验、缓存检查——直接跳过。怎么判断一个分支是不是主线？问Cursor：

在这个函数里，哪一行是实际执行核心逻辑的？
其他部分可以先忽略吗？

Cursor会告诉你：”第47行的self._run_engine()是核心调用，上面的都是参数处理和校验，可以先跳过。”

然后你跳到第47行，继续往下走。

第三步：遇到不懂的技术栈时

这是你提到的第二个痛点——项目里用了你不熟悉的语言或技术。

比如你在读一个Python项目，突然发现核心的计算部分是用C++写的CUDA扩展。你不懂CUDA。

传统的做法是：先去学CUDA，学个几天几周，然后回来接着读。

有了Cursor你可以换一种做法：不学CUDA本身，只理解那段CUDA代码在做什么。

选中那段C++/CUDA代码，问Cursor：

我不熟悉CUDA编程。请用我能理解的方式解释这段代码
在做什么——不需要解释CUDA的语法细节，只告诉我
它的输入是什么、输出是什么、中间做了什么计算。
用Python的思维方式类比。

最后那句”用Python的思维方式类比”很关键。它告诉Cursor用你已有的知识框架来解释新东西。

Cursor可能会说：”这段CUDA kernel本质上在做的事情相当于Python里的：对一个大矩阵的每一行做softmax，然后跟另一个矩阵做矩阵乘法。只不过它把这个计算拆分到了GPU的几千个线程上并行执行。”

你不需要理解它是怎么拆分的、线程是怎么同步的——那些是CUDA的实现细节。你需要理解的是它在计算层面做了什么。 有了这个理解，你就能把这个CUDA函数当成一个”黑盒”，知道它的输入输出，然后继续沿着主线往下走。

同样的方法适用于你遇到的任何不熟悉的技术栈：

不懂Rust？让Cursor用你懂的语言类比解释
不懂某个框架的特定API？让Cursor解释它的作用而不是用法
不懂某个设计模式？让Cursor解释它在这个项目里解决了什么问题

关键原则是：你的目标不是学会那个技术栈，而是理解代码的逻辑流。两者需要的知识量差了一个数量级。

第四步：画地图

走完一条主线之后，你需要把你走过的路记下来。

我的做法是在一个单独的markdown文件里，边读边记。格式很简单：

## 一个推理请求的完整路径

1. 入口：LLM.generate()（vllm/entrypoints/llm.py）
   - 接收用户的prompt，封装成SequenceGroup

2. 调度：Scheduler.schedule()（vllm/core/scheduler.py）
   - 决定哪些请求可以在这一步被处理
   - 核心逻辑：根据当前GPU显存和KV Cache的空间来排队

3. 执行：ModelRunner.execute_model()（vllm/worker/model_runner.py）
   - 把一批请求打包，送进模型做一次forward
   - 这里会调用CUDA kernel做实际计算

4. 采样：Sampler.forward()（vllm/model_executor/layers/sampler.py）
   - 根据模型输出的logits，采样出下一个token

5. 结果返回：把生成的token拼回去，返回给用户

## 我的理解
vLLM的核心创新在第2步——调度器的PagedAttention机制
让KV Cache可以像操作系统的虚拟内存一样按需分配，
不需要预留连续的大块显存……

这份笔记不是给别人看的，是给你自己看的。 所以不需要写得很正式，用你自己能理解的语言就好。

你可能觉得”我直接记在脑子里不就行了”。不行。复杂项目的调用链太长了，你走到第五层的时候大概率已经忘了第二层的细节。写下来才能在脑子里维持一张完整的地图。

而且这份笔记还有一个用处——当你后续探索第二条故事线的时候，你可以把新的路径叠加到同一份地图上，看到不同路径之间的交叉点。那些交叉点往往就是项目最核心的模块。

第五步：在关键节点上深入

走完主线之后，你已经有了一个粗粒度的理解。接下来你可以选择在某些你特别感兴趣的节点上深入。

比如我走完vLLM的主线之后，对调度器特别感兴趣——因为它是vLLM性能优势的核心。

这时候我会打开调度器的代码，让Cursor帮我做更细粒度的解读：

请帮我梳理Scheduler.schedule()这个方法的内部逻辑。
按执行顺序列出它做了哪几件事，每件事用一句话概括。
对于涉及PagedAttention的部分请详细解释。

注意这次我要求”详细解释”了——因为这是我选择深入的节点，值得花时间理解细节。

在主线探索阶段，你的提问策略应该是”概括+定位”——告诉我大概做了什么、在哪里。

在深入阶段，你的提问策略变成”细节+原因”——具体是怎么实现的、为什么这么设计。

这个节奏很重要。如果你从一开始就事事追问细节，你会迷失在细节里走不动。如果你全程只停留在概括层面，你最终得到的理解是浅薄的。

先粗后细，先主线后分支。 像画画一样——先画骨架，再填细节。

一些容易踩的坑

坑一：一次问太多。

不要发这种消息：

帮我解释一下这个项目的整体架构、核心模块的职责、
主要的设计模式、数据流向、以及关键算法的实现原理。

这种问法得到的回答一定是又长又泛的废话。不是Cursor不行，是你的问题太大了，任何人面对这种问题都只能给你一个泛泛的回答。

好的提问是窄的、具体的、有明确边界的。

“这个函数的第三个参数是干什么用的？”

“这个类为什么要继承那个基类而不是直接实现？”

“数据从这个函数出来之后，下一步去了哪里？”

每个问题只解决一个困惑。解决完了再问下一个。你的理解就是这样一个困惑一个困惑地拼起来的。

坑二：完全信任Cursor的回答。

Cursor有时候会瞎说。尤其是当你问的问题涉及到跨文件的复杂逻辑时，它可能会给你一个听起来很合理但实际上是错的解释。

怎么办？交叉验证。

Cursor告诉你”这个函数会调用XXX”——你自己跳过去看一眼，确认它确实调用了。

Cursor告诉你”这个变量在YYY文件里被初始化”——你自己搜一下那个变量名，确认它说的位置是对的。

不需要每一句话都验证，但关键节点一定要自己确认。 尤其是那些会影响你对整体架构理解的判断——比如”模块A和模块B是通过消息队列通信的”——这种结论你最好自己看到代码里的证据。

养成这个习惯之后，你会发现大部分时候Cursor是对的，但偶尔它确实会犯错。那些”偶尔”的错误如果你没有验证就接受了，可能会导致你对整个项目的理解建立在一个错误的基础上。

坑三：试图一次读完。

复杂的开源项目不是一个下午能读完的。vLLM的代码我前前后后读了大概两周，中间穿插着其他工作。

不要给自己压力说”今天一定要把这个项目读完”。你今天读明白了一条主线，就是实实在在的进展。明天再读一条。

每次读完记得写笔记。 你下次再回来的时候，看一眼笔记就能快速恢复上下文，不用从头开始。

坑四：只读不跑。

这可能是最大的坑。

光看代码你能理解的东西是有限的。把项目跑起来，加几个断点或者打几行日志，亲眼看到数据怎么流动的——这个过程给你的理解深度是光看代码的好几倍。

你可以让Cursor帮你做这件事：

我想在本地把这个项目跑起来，走通一个最简单的例子。
请告诉我最少需要哪些步骤。如果有复杂的外部依赖
可以mock掉的，告诉我怎么mock。

不需要搭建完整的开发环境。只要能跑通一个最小的例子，能让你在关键位置加断点看到数据，就够了。

跑起来之后，在你走过的主线上的关键函数入口加个断点或者日志。然后触发一个请求，看实际的执行路径是不是跟你读代码时理解的一致。

经常会有惊喜。 你以为数据走的是路径A，实际上走的是路径B——因为有一个条件分支你读代码时忽略了。这种”预期和现实的偏差”本身就是最好的学习机会。

针对不同类型项目的策略差异

不同类型的项目，”故事线”的选择方式不一样。简单说几个常见的：

Web框架类（FastAPI、Express、Gin等）：

最好的故事线是”一个HTTP请求从进入到返回的完整生命周期”。从监听端口→接收请求→路由匹配→中间件执行→handler调用→响应返回。这条线走完，你就理解了框架的骨架。

数据库/存储引擎类（Redis、LevelDB、SQLite等）：

最好的故事线是”一个写操作从接收到持久化的完整路径”。从命令解析→数据结构操作→内存写入→持久化到磁盘。然后再走一条”读操作”的路径。两条路径交叉的地方就是核心的数据结构和存储引擎。

AI推理/训练框架类（vLLM、DeepSpeed、PyTorch等）：

最好的故事线是”一个前向传播从输入到输出的完整路径”。从数据预处理→模型加载→计算执行→结果后处理。特别注意计算是在哪里从Python进入C++/CUDA的——那个边界通常是理解性能优化的关键。

编译器/解释器类（CPython、V8、GCC等）：

最好的故事线是”一段源代码从文本到被执行的完整路径”。从词法分析→语法分析→AST→中间表示→优化→代码生成/执行。每一步的输入和输出是什么，格式是什么。

不管哪种类型的项目，核心思路都是一样的：找到一条从入口到出口的主线，沿着它走，遇到障碍时让Cursor帮你清除障碍。

一个完整的实战流程示例

最后把整个流程用一个具体的例子串一遍。假设你想理解FastAPI是怎么工作的。

起手。 把FastAPI的仓库clone下来，用Cursor打开。

找入口。 问Cursor：

当用户写了这样的代码：

app = FastAPI()

@app.get("/hello")
def hello():
    return {"msg": "hello"}

请告诉我 @app.get 这个装饰器的代码在哪个文件的
哪个函数里定义的。只给我位置，不用解释。

Cursor告诉你在fastapi/applications.py里。打开它。

沿主线走。 你看到app.get实际上调用了self.router.add_api_route()。你不知道这个函数做了什么。选中它，问Cursor：

这个函数做了什么？一句话概括。它在哪定义的？

Cursor告诉你它在fastapi/routing.py里，作用是”把你的函数包装成一个APIRoute对象，注册到路由表里”。

你跳到routing.py，看到了APIRoute这个类。你好奇路由匹配是怎么做的——当一个请求进来时，框架怎么知道该调用哪个handler？

当一个HTTP请求到达时，FastAPI是怎么匹配到
对应的路由handler的？从哪个函数开始？

Cursor告诉你FastAPI底层用的是Starlette的路由系统。实际的匹配逻辑在Starlette的Router.__call__里。

遇到技术栈边界。 你可能不熟悉Starlette。没关系：

我不熟悉Starlette。FastAPI和Starlette是什么关系？
我只需要知道它们之间的边界在哪——FastAPI自己做了什么，
哪些事情是委托给Starlette做的？

Cursor会解释清楚边界。你决定要不要跨过这个边界深入到Starlette里去。也许现在不需要——你只需要知道”路由匹配这件事Starlette替你做了”就行，你更感兴趣的是FastAPI自己加了什么东西。

记笔记。 走完这条主线之后你写下：

## 一个请求的处理流程

1. 启动时：@app.get 装饰器 → router.add_api_route()
   → 创建 APIRoute 对象 → 注册到路由表

2. 请求到达时：Starlette的路由系统做URL匹配
   → 找到对应的 APIRoute

3. APIRoute 调用你的handler函数之前：
   - 依赖注入（Depends）被解析和执行
   - 请求参数被校验（用Pydantic）

4. 执行handler，返回结果

5. 结果被序列化成JSON返回

## 发现
FastAPI的核心价值不在路由（那是Starlette做的），
而在第3步——依赖注入和参数校验。
这才是它跟其他框架的本质区别。

选择深入点。 你对依赖注入特别好奇。开始第二轮探索，专门走Depends的解析流程。

循环。 每一轮探索都让你的地图更完整、更细致。三四轮之后，你对FastAPI的理解就已经远超大部分使用者了。

回到最开始的问题。

读复杂代码工程最大的难点从来不是”代码太多看不完”。代码多不可怕，可怕的是你不知道该看哪里。

Cursor最大的价值不是替你读代码，而是在你迷路的时候告诉你该往哪走。

但走路这件事，得你自己来。

每一行你亲自读过的代码、每一个你亲自想明白的逻辑、每一次你的预期和实际运行结果对不上然后你搞清楚了为什么——这些时刻构成的理解，是任何AI总结都给不了你的。

Cursor是一个极好的向导。但向导的价值是带你去你自己想去的地方，不是替你走完全程然后给你讲一遍沿途的风景。

风景得自己看。看过的才是你的。

阅读全文

赞同 51720 条评论844 23

//www.zhihu.com/people/zhi-ta-hu-wo

我爱算法

高级算法工程师 & 探索 AI & AIGC

关注

[

收录于 · Cursor系列

](https://www.zhihu.com/column/c_1884265287941076173)

最新发现一个可以落地的 Cursor 工作流技巧，这是BMad Code开源的一个库。

首先，它可以让cursor创建约束自己的rule规范，来进行增强Cursor的能力。

其次，可以根据工作流模式，可以直接让Cursor把你的idea落地。 然后根据它已经预设好的project-idea-prompt执行。

现在的你只需要提供你的想法，Cursor就可以帮你生成对应的产品需求文档（prd）。

根据prd需求并执行工作流：Epic -> Story -> Task -> Subtask。拆解任务模块，然后一步步完成。

如果你想把产品做得更加细腻，可以提供更加细致的需求，让Cursor进行生成更加详细的PRD

快速上手

克隆 cursor-auto-rules-agile-workflow 这个库，它里面已经创建好了规则，如何生成到你指定的项目。

git clone https://github.com/bmadcode/cursor-auto-rules-agile-workflow.git

cd cursor-auto-rules-agile-workflow

克隆之后，就会有对应的cursor的rules，你查看000-cursor-rules.mdc文件时，会发现一些红色警告的匹配规则，这个时候，需要你把当前工作区的警用掉mdc。

需要添加以下配置，这一步重要！！

"workbench.editorAssociations": {
    "*.mdc": "default"
  }

路径：首先项 -> 设置 -> 工作区，如何搜索editorAssociations, 就可以添加对应的配置。

重新打开000-cursor-rules.mdc文件，就没有对应的警告了。

生成rule的方式

你可以直接在当前项目执行./apply-rules.sh进行生成rule，也可以指定自己的项目生成。只需要后面跟上你的项目路径：

Example:
./apply-rules.sh ~/projects/my-project

如果需要在历史项目上生成rules，就可以按照这种方式，就不需要再次克隆项目。

比如，我再另个文件夹rule-template进行创建规则，执行下面语句后就可以生成对应的.cursor、.gitignore、.cursorignore、.cursorindexingignore等文件。

./apply-rules.sh ../rule-template

Cursor的实践落地

切换到rule-template文件夹，进行测试落地效果。

实践1: 自动创建对应开发规范的rule

在已有的项目，或者新项目，如果需要定制一个开发规范，你只需要告诉Cursor，你大概要的规范，他就可以给你指定对应的mdc文件规范。

比如，我需要这么一条rule规则，在cursor开启agent并且选择 claude3.7 Sonnet Think 模型进行对话即可。

prompt: 创建一条规则，项目里的组件目录下命名是首字母大写驼峰，接口目录下的命名是首字母小写驼峰，其他目录是下划线。

中途小插曲

实践过程中，是在 Claud Sonnet 3.5、3.7 和 3.7 thinking 上进行测试，与其他模型可靠性可能有所不同。

Claude Sonnet 3.5、3.7 这些模型，需要升级Cursor Pro。

如果不知道怎么升级，注册一张Master虚拟卡解决升级问题：wildscard.com

具体的教程：(保姆教程）Cursor Pro 升级教程，仅需支付宝订阅Cursor Pro

实践2: workflow 工作流

这是一种自动化工作流模型，你要实现的项目可以让cursor进行拆解成多个任务，根据你的调整对应的prd产品需求文档，或者story-1、story-2等等。

批准之后，就可以一步一步的实施落地。

首先在cursor编辑器的 NOTEPADS 创建一个 Notepad

我创建了ikun notepad 模版，然后把 xnotes/workflow-aglie.md 里的内容，复制粘贴到 ikun里面。

在跟Cursor对话是，@你的notepad，它就可以根据里面的要求执行。如：@ikun 我有个想法，搭建一个xxx网站等等。

接着，它就自动创建.ai目录，并且生成prd文件，也就是产品需求文档，在 prd 文件里有对应的需求状态、需求分析、技术栈以及解决方案等等。

如果你想把产品做得更加细腻，可以给出更详细的需求，让 Cursor 帮你输出 prd 文件。

然后一步一步，生成对应的流程，prd -> arch -> story。

也就是让 Cursor 进行分析 prd 文档，根据需求生成一个技术架构，根据prd文档的Epic结构拆解成多个任务，每个Epic生成对应的story-1、story-2等等。

当story-1的任务完成之后，就会自动修改状态，开始下一个任务，story-2。

其中，你跟Cursor的对话流程，也都会写在每一个story里。

整个过程，你只需要关注下面的几个工作流程的阶段就行，改改需求文档，修修bug。

而且更好的管理一个全新的项目，并且成本也会降低，无需频繁的去对话，就可以生成你要的idea项目。

工作流程

整个工作流程，关注两个阶段：计划阶段和 ACT 阶段。

1\. 计划阶段：

关注文档和规划
仅修改 .ai 目录下的文档、项目下的readme 和 rule规则
所需 PRD 和架构的审批

2\. ACT 阶段：

实施进行中的已批准story
任务逐个执行
持续测试和验证

.ai/
├── prd.md                 # Product Requirements Document
├── arch.md               # Architecture Decision Record
├── epic-1/              # Current Epic directory
│   ├── story-1.story.md  # Story files for Epic 1
│   ├── story-2.story.md
│   └── story-3.story.md
├── epic-2/              # Future Epic directory
│   └── ...
└── epic-3/              # Future Epic directory
    └── ...
``

阅读全文

赞同 35918 条评论1205 23

查看全部 30 个回答

[

下载知乎客户端

与世界分享知识、经验和见解

](https://s.zhihu.com/BDXoI)

[

](https://www.zhihu.com/parker/campaign/2020167742850904460?zh_hide_nav_bar=true&spu=biz%3D0%26ci%3D3693287%26si%3D63faf781-4228-4d07-8d7a-cc752d71bfb5%26ts%3D1776726577%26zid%3D3)

关于作者

//www.zhihu.com/people/kk-today

两斤

AI野生布道师 | 智能家居玩家

[

回答

287

](/people/kk-today/answers)[

文章

](/people/kk-today/posts)[

关注者

10,691

](/people/kk-today/followers)

关注他发私信

被收藏 474 次

技术文章

17 人关注

Anwenri 创建

计算机

12 人关注

周弋涵创建

创业2

3 人关注

hongyu liu 创建

编程学习

2 人关注

知乎用户创建

技术

2 人关注

知乎用户创建

如何利用cursor快速理解复杂代码工程？

如何利用cursor快速理解复杂代码工程？

... existing code ...

... existing code ...

背景

任务描述

项目概览

分析

提议的解决方案

当前执行步骤："[步骤编号和名称]"

任务进度

最终审查

... existing code ...

... existing code ...

Context

Task Description

Project Overview

Analysis

Proposed Solution

Current execution step: "[STEP_NUMBER_AND_NAME]"

Task Progress

Final Review:

更多回答

为什么直接让AI”总结整个项目”没用

我的方法：从一个问题开始

第一步：找到入口

第二步：沿着调用链往下走

第三步：遇到不懂的技术栈时

第四步：画地图

第五步：在关键节点上深入

一些容易踩的坑

针对不同类型项目的策略差异

一个完整的实战流程示例

快速上手

生成rule的方式

Cursor的实践落地

实践1: 自动创建对应开发规范的rule

中途小插曲

实践2: workflow 工作流

工作流程

继续阅读