Cursor 的 Plan New Idea 设计模式：让设计文档跟着你的提示词走
Cursor 的 Plan New Idea 很适合在动手写代码前做一轮规划。
你可以用它梳理需求、拆解任务、分析现有代码，再决定具体怎么改。对于复杂功能，这一步能省掉不少返工时间。
但有个细节挺烦人：
你用中文提问，Cursor 生成的设计文档却是英文。
看代码问题时还好。遇到产品需求、接口说明、改造计划，整篇英文读起来就有点费劲了。
更合理的行为应该是：
- 中文提示词，输出中文设计文档
- 英文提示词，输出英文设计文档
- 中英混合时，按照主要语言输出
- 用户明确指定语言时，优先听用户的
下面给你几种能直接落地的做法。
方法一：在当前对话里直接说明
这是最省事的方案。
在使用 Plan New Idea 前，补一句语言要求就行：
请用中文分析这个需求，并输出中文设计文档。
技术名词、函数名、类名和代码保持英文。
也可以写得更具体一点：
请使用中文完成本次 Plan New Idea。
设计文档需要包含：
1. 需求目标
2. 当前代码分析
3. 实现方案
4. 文件修改列表
5. 风险与测试计划
除代码、API 名称和技术专有名词外，其他内容都使用中文。
这种方式适合临时任务。比如你只是偶尔想规划一个登录页、支付流程，没必要专门改全局配置。
方法二：加入 Cursor Rules，让它长期记住
如果你经常用中文和 Cursor 协作，建议把语言偏好写进项目规则。
在项目里创建规则文件，例如：
.cursor/rules/response-language.mdc
写入下面内容：
---
description: Language preferences for planning and coding
alwaysApply: true
---
# Language Rules
- 默认使用与用户提示词相同的语言回复。
- 用户使用中文时，Plan New Idea、设计文档、任务拆解和解释内容使用中文。
- 用户使用英文时，使用英文回复。
- 用户明确指定输出语言时，遵循用户指定。
- 中英混合输入时，根据用户使用最多的语言判断输出语言。
- 代码、函数名、类名、变量名、文件名、API 名称和技术专有名词保持原样。
- 不要把代码中的标识符强行翻译成中文。
这条规则解决的不是某一次输出，而是整个项目的默认行为。
你以后在中文项目里输入：
Plan New Idea：给后台系统增加批量导出订单功能。
Cursor 就应该生成类似下面这样的内容：
# 批量导出订单功能设计
## 需求目标
允许管理员按照筛选条件批量导出订单数据。
## 实现方案
新增导出接口，并使用异步任务处理大批量数据。
## 文件修改列表
- src/api/order.ts
- src/services/exportOrder.ts
- src/pages/orders/index.tsx
而不是突然甩给你一份英文项目报告。
方法三：把输出格式也固定下来
只指定“用中文”还不够。
如果你希望设计文档稳定、好读、方便交给别人继续开发，最好顺手规定结构。
可以使用这段提示词：
请用中文输出设计文档，并严格按照以下结构：
# 功能名称
## 背景
说明为什么要做这个功能。
## 目标
列出本次改动要解决的问题。
## 非目标
说明本次不处理哪些内容，避免范围失控。
## 当前代码分析
指出相关模块、入口文件和已有逻辑。
## 实现方案
说明整体思路、数据流和关键技术选择。
## 文件修改列表
列出需要新增、修改或删除的文件，并说明原因。
## 任务拆解
将开发工作拆成可以逐项执行的任务。
## 风险与边界情况
列出异常输入、权限、性能和兼容性问题。
## 测试计划
说明需要补充哪些单元测试、集成测试和手动验证。
除代码和技术专有名词外，全部使用中文。
这类提示词的好处是，设计文档不再是一段散文。
你能直接拿它做开发清单，也能发给同事评审。
推荐的项目规则模板
如果你想一步配置好，可以直接使用这份版本：
---
description: Rules for Cursor planning documents
alwaysApply: true
---
# Planning Document Rules
## Language
- 回复语言默认跟随用户提示词语言。
- 用户使用中文时，所有规划说明、设计文档、任务拆解和风险分析都使用中文。
- 用户使用英文时，使用英文输出。
- 用户明确指定语言时，以用户指定为准。
- 中英混合时，使用占比更高的语言。
- 代码、命令、路径、类名、函数名、变量名、接口名和库名保持原样。
## Planning Structure
生成设计文档时，优先包含以下章节：
1. 背景
2. 目标
3. 非目标
4. 当前代码分析
5. 实现方案
6. 文件修改列表
7. 任务拆解
8. 风险与边界情况
9. 测试计划
## Writing Style
- 结论清晰，避免空泛描述。
- 每项建议都尽量对应具体文件、模块或操作。
- 不要在没有分析代码的情况下编造文件名和实现细节。
- 不确定的信息需要明确标注，并说明需要进一步检查的位置。
一个更实用的中文规划示例
假设你要给博客后台增加“草稿自动保存”。
可以这样输入：
请使用中文执行 Plan New Idea。
需求：为博客后台增加草稿自动保存功能。
要求：
- 用户编辑文章时，每 30 秒自动保存一次
- 页面关闭前尝试保存当前内容
- 保存失败时给出提示，但不能阻塞用户继续编辑
- 需要考虑网络断开和重复提交
- 请先分析现有编辑器、文章接口和状态管理方式
- 输出完整的中文设计文档
理想的输出应该包括：
- 当前编辑器状态放在哪里
- 自动保存定时器放在哪个组件或服务中
- 后端接口是否支持幂等
- 草稿和正式发布状态如何区分
- 用户离开页面时如何处理未完成请求
- 需要增加哪些测试
这就比一句“帮我加自动保存”靠谱得多。
常见问题与处理方式
1. 规则文件写了，Cursor 还是输出英文
检查这几个地方：
- 规则文件是否放在当前项目目录
- 文件扩展名是否正确
alwaysApply是否设为true- 当前对话是否已经生成了旧的英文上下文
- 是否在提示词里明确要求了英文输出
可以新开一个对话，再输入：
请用中文继续，并把刚才的设计文档完整改写成中文。
2. 技术名词被翻译得很奇怪
在规则中明确写上：
函数名、类名、变量名、文件名、API 名称、命令和代码片段保持英文原样。
否则你可能会看到这种内容：
用户服务.ts
获取订单列表()
看着就很别扭，也容易影响后续搜索代码。
3. 中英文混合时语言判断不稳定
别把判断交给模型猜，直接指定：
本次请使用中文输出，代码和技术名词保留英文。
需要写英文文档时，再明确说：
请将这份设计文档输出为英文，代码标识符保持不变。
4. 设计文档太长，重点被冲淡
给它加上长度和重点限制：
请控制在 1000 字以内。
只保留会影响实现的内容。
重点说明文件改动、数据流、接口变化和风险。
不要重复描述需求背景。
规划不是写论文。能指导开发就够了。
避坑清单
- 不要只写“请用中文”，却没有说明代码标识符是否保留英文。
- 不要把语言规则只放在一次对话里，长期使用建议写进
.cursor/rules。 - 不要让 Cursor 在没读取代码前直接编造文件修改列表。
- 不要只看设计文档语言，记得检查接口、状态流和异常场景。
- 不要把“自动保存”这种需求写得过于简单，网络失败、重复提交、页面关闭都要提前考虑。
- 不要期待规则能修复所有上下文问题。对话已经跑偏时，开新会话通常更快。
一套可以直接复制的万能提示词
请使用与我提示词相同的语言输出设计文档。
如果我使用中文，请用中文；如果我使用英文，请用英文。
代码、命令、文件名、函数名、类名、变量名、接口名和技术专有名词保持原样。
请先分析当前代码，再给出实现方案。
设计文档包含以下内容：
- 背景
- 目标
- 非目标
- 当前代码分析
- 实现方案
- 文件修改列表
- 任务拆解
- 风险与边界情况
- 测试计划
不要编造没有确认过的文件、接口或业务规则。
不确定的地方请明确标注，并说明需要检查什么。
Cursor 的 Plan New Idea 本身已经很好用。
把输出语言和文档结构补上，使用起来会顺手很多。你用中文提需求，它就该用中文把方案讲清楚。没必要每次都对着英文设计文档做人工翻译，这种重复劳动，交给规则就行。
