目录

工欲善其事必先利其器。

AI 和 Cursor 更新迭代太快，文章内容容易落后或变更，暂无时间，也不去整理汇总各方的内容，只记录文章地址、亮点及个人解读。

版本更新

Changelog | Cursor - The AI Code Editor

使用技巧

  • Cursor 设计负责人 Ryo Lu 的 AI 编码最佳实践指南

    • 1、指定明确的项目规则，让 cursor 了解项目的结构与约束。如果项目自身具备现代规范，可以使用 cursor 的生成 rule 命令生成规则（/Generate Cursor Rules）。

    • 2、准备具体的 mini 规范说明书，让 cursor 知道项目独有的技术栈组合、期望行为与约束规范。

    • 3、以分而治之与原子正确性思想为指导。从上到下，逐步分解，架构、分层、文件、函数、测试组织，从下往上生成代码、测试与审查，不同阶段采用不同的模型

    • 4、测试驱动开发。先写测试，再写代码。短期内有难度。

    • 5、一定要审查 Ai 的输出，再去接受。

      避免无脑接受，再无脑让 AI 调整，尽量做到 AI 和人都知道在干什么，否则以后项目上的业务知识就完全依赖 AI，方案讨论时就不要人的参与了。

      当然可能以后真不需要真人了，真就是 AI 团队了，人给 AI 团队制定规章制度，制定 PDCA 规则，由 AI 团队自行运转 PDCA，根据人给定的主题自行讨论，确定方案，执行方案，评判结果，进一步完善方案。

    • 6、限制关注范围。尽量使用@相关符号，限制 AI 关注正确的上下文范围。

    • 7、手动修正一些错误代码。cursor 从编辑中学习比从解释中学习更快。

    • 8、利用聊天历史。需要参考一个很长的对话的重要上下文含推理与决定时，新的对话希望保持连续性。

    • 9、选择性使用模型。Claude 适合广度，比如更上层的处理；Gemini 适合精确深度，比如局部范围的处理。

    更多原英文详见文章内容。

  • Cursor 官方下场谈 Cursor 正确用法，以及我的实践解读 - 知乎

    这篇文章还是对 Cursor 首席设计师 Ryo Lu 上周发布的关于如何正确使用 Cursor 的 12 个方法建议的解读。

    比上一篇会更丰富些，还有些范例。

  • Cursor 首席设计师 Ryo Lu 关于如何正确使用 Cursor 的 12 个方法建议原文

    Using Cursor well = fast, clean code.

    Using it wrong = AI spaghetti you’ll be cleaning up all week.

    Here’s how to actually use it right:

    1. Set 5-10 clear project rules upfront so Cursor knows your structure and constraints. Try /generate rules for existing codebases.
    2. Be specific in prompts. Spell out tech stack, behavior, and constraints like a mini spec.
    3. Work file by file; generate, test, and review in small, focused chunks.
    4. Write tests first, lock them, and generate code until all tests pass.
    5. Always review AI output and hard‑fix anything that breaks, then tell Cursor to use them as examples.
    6. Use @ file, @ folders, @ git to scope Cursor’s attention to the right parts of your codebase.
    7. Keep design docs and checklists in .cursor/ so the agent has full context on what to do next.
    8. If code is wrong, just write it yourself. Cursor learns faster from edits than explanations.
    9. Use chat history to iterate on old prompts without starting over.
    10. Choose models intentionally. Gemini for precision, Claude for breadth.
    11. In new or unfamiliar stacks, paste in link to documentation. Make Cursor explain all errors and fixes line by line.
    12. Let big projects index overnight and limit context scope to keep performance snappy. Structure and control wins (for now)

    Treat Cursor agent like a powerful junior — it can go far, fast, if you show it the way.

  • Cursor v0.49.x 更新：自动生成 Rules、MCP 上下文可添加图像、新增 5 种强大编程模型

    文章提到这次更新的几个亮点：

    • 1、Cursor Rules：

      • 使用/Generate Cursor Rules 直接生成规则；
      • Auto Attached 的规则会智能应用于匹配路径；
      • Always 的规则现在持久性更好。

    • 2、聊天记录移至命令面板

    • 3、对话结束时可使用内置的 diff 功能审查代码，可以在对话窗口左上角 edit files 查看文件改动情况

    • 4、MCP 上下文可添加/传递图像

    • 5、在 Agent 运行终端命令前，选择编辑或跳过

    • 6、新增全局忽略文件

    • 7、添加了 Gemini 2.5 Pro、Grok 3、GPT-4.1、o3、o4-mini 模型

    • 8、在上下文中引入项目结构

    关于生成 cursor rules，文章中也提到暂时没法生成比较细致全面的规则，我们自己试，没有很好的完成，况且对于存量代码项目来说，有些规则是为了规范未来，而不是从存量代码生成，需要人为的制定规则。

    这里我们再补充早就有的@Docs 使用说明，可以事先在设置的 Features 选项找到 Docs，并 Add new doc（允许团队内共享），之后在对话框中输入@Docs，即可基于指定文档的读取（可能还会读取文章中关联相同前缀的文档），进行问题回答。这里@Docs 和@web 的区别在于：

    • @web 是进行实时网络搜索，获取最新信息
    • @docs 是查询预先索引的文档内容，更适合查 API 和标准用法
    • @web 的结果可能更新更快但不一定准确，@docs 的内容相对稳定可靠
    • @docs 支持自定义添加文档源，而@web 是搜索整个互联网

    使用建议：

    • 当需要查最新信息或解决方案时，使用@web
    • 当需要查询 API 文档、使用说明等标准内容时，使用@docs

    注：@Docs 文档地址仍然是走 cursor 的云端访问，私域地址暂时不能正常访问。

  • Cursor 使用分享 | Ningto’s Blog

    这篇文章包含了 0.49.x 的大部分使用分享，可以一次性概览，心中有数，知道在哪里以及大概使用方向，一回事两回熟。

    通过这篇文章第一次知道可以多开 chat，惭愧。其实对话窗右上角的 + 号上有提示使用 Alt+点击+号，可以新开并行的对话窗，上下文不独立维护互不影响。

  • Cursor Agent 模式的黄金使用指南

    • 文中提到对于架构、方案比较大型的任务，可以考虑使用 agent 模式。在局部精细调整时，建议采用 Ask 模式。因为 Agent 一次只能读取最多 250 行代码，需要多次读取，且调用工具较多，总体上下文长度低于普通的 Ask 模式。
    • 可以开启在 feature 设置中开启 auto-run，避免每次点击确认工具调用。但出于目前工具和 mcp 的不完善，比如 mcp 存在提示词投毒、撤地毯、影子工具等安全问题，我们建议谨慎开启。
    • 作者建议使用 Agent 的时候，一个对话中不要连续超过 20 次对话。仅为经验判断建议。

  • 让代码听你的话：Cursor 助你打造极致心流体验 - 知乎

    文章中提到的技巧：

    • 反向费曼学习法：提出问题后，让 AI 反述问题，质疑需求，反向逼迫思考"真需求”，将 AI 作为思维的延展。
    • 分而治之思想：将复杂问题拆分为简单小问题，用 AI 给出解决方案并拆分任务，以 Markdown 格式记录到 Notepad，逐步执行验证。

    10 大家可能已知道的技巧：

    1. 终端对话：在命令行用自然语言描述命令行操作。不用再担心 windows 和 linux 的不熟悉的指令。
    2. 历史代码生成注释：快速为历史代码生成注释。为旧代码添加注释，方便后续维护。
    3. 一键生成 commit message：自动生成代码提交信息。
    4. 快速可视化项目架构：用 Ask 模式生成项目架构图。
    5. 巧用 Notepad 记录思路：记录重要上下文，方便后续使用。
    6. @Git 找出代码漏洞：对比代码差异，检查问题。
    7. 使用 checkpoint 一键回滚：快速回滚代码状态。
    8. 设置专属提示词：在 Cursor Rules 中自定义提示词。
    9. 拖拽式添加上下文：直接拖拽文件到对话框添加上下文。
    10. @web 联网获取信息：快速获取最新信息。

  • 让你的 Cursor 变得和 JetBrains IDEs 一样好用

    如果你之前比较喜欢使用 JetBrains IDE, 这篇文章介绍了一些可重现 JB IDE 功能的扩展插件、键盘、主题、字体以及特定 IDE 迁移扩展的简单说明，比如 goland、phpstorm、webstorm、pycharm、Rider、idea 等。

  • Cursor 与 Git 协同工作指南

    除了 ask 模式下让 cursor 生成项目当前状态的相关 git 指令及生成 commit message 外，还可以让 cursor 智能审查指定提交 commit id、git diff、pr 内容。

    如果你仍然想在 ide 里敲 git 命令，或者比如像我已经不喜欢去记也记不住那么多命令的情况下，可以考虑在终端 Terminal 里使用 Ctrl/Command+K，通过自然语言描述 git 命令，cursor 会自动识别并生成对应的 git 命令。

  • CLI + CursorRules，为你的 Cursor 插上翅膀 - 知乎

    这篇文章是 25 年 2 月发布的，当时 mcp 应该还米有这么火，看起来都可以通过 mcp 来实现？

    其中涉及的工具：eastlondoner/cursor-tools: Give Cursor Agent an AI Team and Advanced Skills

  • 如何让 AI 开发真正可控、可靠？Cursor AI 工程化

    文章的亮点在于：自定义模式，您可以通过 Settings → Features → Chat → Custom modes 启用自定义模式，你可以定制你的工作模式。

    AI 开发并不能帮我们完全减少某个研发流程阶段，只能是加速某个阶段。

    作为开发人员在不同阶段可能有不同的角色，可以在 cursor 上指定不同模式，，用于不同阶段。每个模式可以裁剪指定合适的 LLM、Tools、Auto-run 配置、预置角色提示词等，让 Ask 或 Agent 在细分领域更精准。

    我们可以直接看官方文档，其中也简单罗列了自定义模式示例，如学习、重构、计划、研究、Yolo、调试：Cursor – Custom Modes - example-modes

Rules、Notepads、文档模板

  • Cursor Rules 最佳实践总结

    • rule 文件也需要分门别类，方便管理与识别。人识别的了，AI 也能识别的了。
    • 如果使用了 Agent Requested 类型的 rule，要求写上描述，方便 agent 自动识别是否需要调用该 rule 文件。

  • Cursor Notepads 最佳实践总结

    文章说 Notepads 适合的内容类型如下：

    • 项目架构决策和背后的思考逻辑
    • 团队约定的编码规范和标准
    • 经过验证的代码模板和实用示例
    • API 文档和关键技术规范
    • 新成员入职指南和环境配置说明

    且适合于复杂只是管理、团队协作文档，深入指南与知识库，但目前没有发现团队之间如何共享 Notepads 的方案。

    而且，如果是作为团队不敏感的规范说明，也可以考虑使用 project rules 或者是 docs 目录文件来实现，仍然能满足手动@的场景？

    是不是可以认为手动的话，完全不一定要使用 rule 或是 notepad？只有 always、agent Requested 才有必要使用 rule？

  • 喂好你的 Cursor “小抄”，让它秒懂你的项目"黑话”！(告别 AI 瞎指挥)

    作者也表达了 AI 总是会先用公开课本上的知识来解决我们的专属私域问题。原因是 AI 只对公开的资料了如指掌，但对公司私域内的黑话（内部工具、架构设计、团队特有规范等）却一概不知，平常也不知道我们内部讨论后形成的一些潜规则等。

    所以，大家也都想到了，将私域信息同步给 AI，为 cursor 打造一份开卷考小抄，将团队项目只是浓缩成小抄喂给 AI，整个小抄可能会因为项目不同而不同，仍然根据实际情况基于分而治之的思想，将这份小抄分门别类拆分多个小小抄。

    文章中提到工具类和配置模板也需要设计结构化的统一格式的小抄，但我们觉得是不是代码本身注释好点，cursor 就能识别这些比较单纯的内容。

    要设计成模板的，应该是那些需要从大量代码文件中，抽取出来的典型的穿透多层的代码与协调方式，作为模板或脚手架（最佳实践）。

    使得 cursor 不需要自己去翻阅 codebase，再尽力找规律，并使用其认为的业务实现方式编码，只需要参考最佳实践，就能很好地完成贴近项目实际情况的需求编码。

    接下来我们需要让熟悉项目、熟悉架构、熟悉更多技术栈、熟悉更多使用技巧的人，结合规范与规定制定者来设计这个项目的各种 cook book。

    如果项目比较规整，显然上面的 cook book，我们可以让 AI Agent 来协助我们生成。可以参考作者文章的 3 中方法。

  • Cursor 也需要"入职培训”：结构化引导法提升编程效率

    作者将 AI 编程助手比作"天才实习生”，指出其技术基础扎实但缺乏实际经验，需要通过结构化的"培训模板"来提供项目背景、技术规范、业务上下文和具体任务要求。

    文章详细介绍了如何创建这些模板，以及如何在现有企业代码库中实践"实习生培训"方法，包括面对遗留系统的现实挑战和渐进式集成新功能到现有系统的策略。此外，还提供了专业场景的"实习生培训模板"示例，以及与 Cursor 结合的高效工作流和团队协作最佳实践。通过这种结构化的交互方式，开发者可以更高效地与 AI 协作，避免常见的沟通陷阱，提升代码质量和一致性。

    培训资料模板如：

    • 项目架构概览（项目背景、技术栈、架构设计）
    • 代码规范摘要（团队编码风格和最佳实践）
    • 业务领域知识（核心业务概念与规则）

  • Cursor 0.49 更新：规则自动生成，详解&演示

    文章有个亮点：结合 Plan/Act 模式：打造智能工作流，参考 Cline 工具的 Plan/Act 模式，通过 cursor 自动生成 Plan/Act 模式的 rules，模拟类似的工作流。

    文章还提供了一个优秀的 cursor rules 配置项目分析，详见：elie222/inbox-zero: AI personal assistant for email. Open source app to help you reach inbox zero fast.

  • elie222/inbox-zero: AI personal assistant for email. Open source app to help you reach inbox zero fast.

    这是一个优秀的规则配置项目，建议大家去观摩学习一下这个前端项目的规则配置，可以为我们的项目提供一些灵感。

    • 全面的规则覆盖：
      • 项目概述与技术栈：清晰定义项目目标和使用的技术。
      • 目录结构：让 AI 了解项目文件组织。
      • API & 路由：后端接口规范。
      • 数据处理 & Prisma: ORM 使用和数据操作规则。
      • UI 组件 (Shadcn/ui): 前端组件库的使用规范、安装命令示例。
      • 开发流程 & 工具：测试、日志、工具类等规则。
      • 特定功能模块：如 Gmail API 调用、LLM 测试等。
    • 清晰的结构与描述：每个规则文件都有明确的用途说明，易于理解和维护。
    • 实用性强：包含了很多实际开发中会遇到的场景，如新组件安装命令、测试最佳实践等。

提示词

  • x1xhlol/system-prompts-and-models-of-ai-tools: FULL v0, Cursor, Manus, Same.dev, Lovable, Devin, Replit Agent, Windsurf Agent & VSCode Agent (And other Open Sourced) System Prompts, Tools & AI Models.

    这个 git 仓库放置的是 FULL v0，Cursor，Manus，Same.dev，Lovable，Devin，Replit Agent，Windsurf Agent & VSCode Agent（以及其他开源的）的系统提示、工具和 AI 模型。

    我们可以也可以自己搭建代理抓取 cursor 等工具的交互，捞到相关提示词的上报。具体可以看一些对于这 AI 工具系统提示词的解读，比如这篇文章：Cursor、Devin 等爆款系统提示词曝光，Github 上斩获近 2.5 万颗星！官方给 AI 工具"洗脑”：你是编程奇才，有助于我们进一步了解我们正在使用的 AI 工具，来匹配提升我们的问题提示词、rules 等。

    看人家的系统提示词，我们有两点要说：不要低估 AI，给他戴高帽；也不要高估 AI，给他戴紧箍咒。

  • 补一个 豆包系统提示词

    我的名字是豆包，有很强的专业性。用户在电脑上和你进行互动。

### 在回答知识类问题时，请遵照以下要求
1. 在细节程度上：
    - 围绕问题主体和用户需求，全面、深入地回答问题。
    - 提供详尽的背景信息和细节解释，对于复杂概念可使用案例、类比或示例来充分说明，目标是让用户深入理解和掌握相关概念。
    - 如果问题回答内容涉及范围较广、或者用户需求较为宽泛和不明确，可先提供一个概览性的回答，再将问题拆解为多个方面回答。 
    -  适当提供与问题主题相关的延伸内容，帮助用户获取更多有用信息。
2. 在格式上，使用 markdown 格式排版回复内容，包括但不限于：
    - 加粗：标题及关键信息加粗。
    - 列表：
        - 表达顺序关系时使用有序列表（1. 2. 3. ）。
        - 表达并列关系时使用无序列表（- xxx）。
        - 如果存在明确的上下层级关系，可以搭配使用标题（###）与列表甚至嵌套列表。
- 表格：当对比多个维度时，使用表格进行排版，以便更清晰地呈现信息。
- 灵活使用其他格式，以提高文本的可读性：
    - 引用：用于突出重要引用或参考内容。
    - 下划线：用于强调特定术语或短语。
    - 斜体：用于强调次要信息或表达语气。
    - 链接：用于提供外部参考资料或相关内容。
      
### 在写文案或进行内容创作时，请遵照以下要求：
1. 在篇幅长度上：
    - 围绕用户需求进行高质量的创作，提供丰富的描述，适度延展。
2. 在格式上
    - 默认情况下，使用自然段进行回复，除非用户有特殊要求。
    - 在需要排版的创作体裁中，使用 markdown 格式，合理使用分级标题、分级列表等排版。
    - 对标题、关键信息及关键句子适当使用加粗，以突出重点。

请注意，以上要求仅限于回答知识问答类和创作类的问题，对于数理逻辑、阅读理解等需求，或当提问涉及安全敏感时，请按照你习惯的方式回答。如果用户提问中明确指定了回复风格，也请优先满足用户需求。

### 你具备以下能力
- 你可以接收和读取各类文档（如 PDF、excel、ppt、word 等）的内容，并执行总结、分析、翻译、润色等任务；你也可以读取图片/照片、网址、抖音链接的内容。
- 你可以根据用户提供的文本描述生成或绘制图片。
- 你可以搜索各类信息来满足用户的需求，也可以搜索图片和视频。
- 你在遇到计算类问题时可以使用如下工具：
Godel：这是一个数值和符号计算工具，可以在计算过程中调用。
今天的日期：2025 年 03 月 01 日 星期六

    豆包的系统提示词里，最后指出了今天的日期，这个日期很多人在写提示词的时候，会忘记，导致 AI 回答会有些出入。

思考

  • 2025 - AI 编程的能力边界 - 知乎

    • 文档为锚、API 为舵、代码为帆 结构化 PRD 防认知偏移，API 文档掌控决策，代码只是顺风之帆。

      AI 时代，可能是先有更规范的 PRD 和 API 文档，然后才有的代码。

    • 任务拆分、模块拆分、Agent 拆分

    • 不懂编程也得会 Git 用 Git 追踪 AI 改动，避免幻视导致项目面目全非。

    • 别做甩手掌柜 避免"Accept All"懒人模式，失去需求掌控，需适时暂停。

    • 工具链与时俱进 从 MCP 到 Cursor Rule，优化 AI 工作流不可少。

  • 关于"自然语言编程"的愚蠢。Dijkstra 锐评 AI 编程 - 知乎

    这是一篇 1978 年发表的文章，作者是计算机科学领域的先驱，图灵奖获得者，著名计算机科学家艾兹赫尔·戴克斯特拉（Edsger Dijkstra）。

    自计算机诞生以来，就有人觉得编程需要精确严谨是个缺陷，期望机器能更"智能”。但 Dijkstra 认为，编程语言的形式化符号是必要的，它能有效避免自然语言中难以避免的荒谬错误。他质疑用自然语言编程能简化人类生活的假设，认为这会让机器和人类都承担更多工作量。他还提到，历史上数学的发展也证明了形式化符号体系的重要性。最后，他指出，现代教育中人们对母语掌握能力的退化，也从侧面说明了自然语言编程的不可行性。

    现在回头看，你觉得自然语言编程可行吗？

工具与资源