$Wynn5a 技术博客 - AI编程与软件工程实践
~/blog/cursor-in-practices
研发流程#工具#VIBE-CODING

Cursor 实战指南（2026）

引言#

在团队日常研发中，我们也尝试过多种 AI 编码工具（如 GitHub Copilot、Cursor、Claude Code、Opencode、TRAE 等），目前主要使用的是 Cursor。经过近一年的实践，我发现要让这类工具在实际工程中真正产生持续价值，必须搭配工程化的使用规范，系统性地用好 Cursor 的高级功能：Rules（规则）、Commands（命令）、Agent Skills（技能扩展）、Subagents（子代理）和 MCP（模型上下文协议）。

这些功能本质上是为了让我们更好地跟 Cursor 的灵魂——寄居于 IDE 外壳内的 LLM 模型们——打交道，尝试驯服它们根本上的“概率游戏”，吐出“高可用”的代码。这些机制可以为我们的编程助手 Cursor 注入项目上下文、预设任务模板、扩展领域专长、拆分子任务并对接外部系统，从而让这个助手像团队成员一样自然融入产品的研发流程。本文将围绕上述机制/能力的概念、典型场景和实践方法展开，并结合遗留系统的设计、开发与验证过程，介绍如何组合使用它们，获得稳定、可控的辅助开发效果。

用官方的 “Agent harness” 统一理解#

官方将 Agent 的工作方式总结为一个 agent harness，由三部分组成：

  • Instructions：引导 Agent 行为的 system prompt 与规则
  • Tools：文件编辑、代码库搜索、终端执行等工具
  • User messages：你用来指挥工作的提示与后续交互

你可以把本文的五类能力粗略映射到这三者上：

  • Rules /（部分）Skills 主要用于补齐 Instructions
  • MCP 主要用于扩展 Tools
  • Commands 更多是在标准化 User messages（可复用的任务模板）

💡 因行文时效性，具体的文件位置或者命令格式以官方文档/产品为准

Plan-first：先规划再动手（适合中大型改动）#

在开始写代码前，先让 Agent 产出可审查的计划，通常能显著降低返工。

一个好用的固定套路是：

  1. 让 Agent 先在代码库里定位相关文件和现状
  2. 让 Agent 提出澄清问题（不清楚的就先问清楚）
  3. 让 Agent 输出一份包含文件路径与引用的实现计划
  4. 你确认计划后再开始执行

如果执行结果偏离预期，优先回滚改动并回到“计划”层面重新写，而不是在一个已经变乱的对话里不断打补丁。好消息是现在 Plan 模式已经内置到 Cursor 中，赶紧用起来吧。

Rules – 为 AI 制定规矩#

Rules（规则）是一种为 Agent 提供系统级指令的机制，本质上是持久生效的“行为规范”。通过 Rules，可以明确告知 AI：它在当前项目中扮演什么角色、应遵循哪些编码与协作偏好、以及处理问题的基本原则。每当相关 Rule 被应用时，其内容会自动注入到对话或代码生成上下文的开头，为模型提供稳定且一致的指导，从而在不同会话和团队成员之间维持相对统一的行为与风格。

在大型项目中，Rules 通常用于定义编码标准、架构约定和项目背景等信息。例如，我们可以编写规则描述项目的技术栈、目录结构、编码风格以及约束条件等，使 AI 理解项目的整体风格和要求。也可以在 Rules 中注明团队规范和最佳实践，如“API 代码需要包含完整的错误处理”和“所有React组件文件采用PascalCase命名”等。当 Cursor 应用这些规则后，AI 便会在代码生成和修改时自动遵循这些约定，大幅减少人工反复提示的成本。

Rules 可以按作用范围分为全局规则和项目规则。全局规则通过 Cursor 设置界面配置，适用于所有项目，一般用于设定普适的编码风格或语言无关的原则（例如统一缩进风格、命名约定等）。项目规则则保存在代码仓库的 .cursor/rules 目录下，针对特定项目或子模块定义团队约定和框架特定指南，并随代码版本管理方便团队共享协作。例如，对于电商微服务项目，我们可以在项目规则中规定：“使用 RESTful 风格设计 API，错误码遵循统一格式；数据库访问层使用统一的ORM；禁止直接调用其他微服务的数据库”等等。通过将这些关键指导写入 Rule 文件并启用“始终应用（alwaysApply）”，Cursor 将在每次交互时都参考这些规则。这确保了无论是生成新代码还是解释修改，AI 都能牢记架构师设定的边界，不会偏离既定的技术方案。

需要注意的是，Rules 应当具体、简洁且可执行。避免模糊的指示，例如简单说“代码要干净”对 AI 毫无帮助，不如明确规定“变量命名使用驼峰式（camelCase）、每个函数不超过20行、所有函数参数必须添加类型注解”等。同时，可以在规则中提供上下文背景和示例，帮助 AI 更好理解规则含义。例如，可以在规则中描述“本项目采用JWT进行用户认证，并附上登录流程的步骤示例”，让AI清楚项目的认证机制。良好的规则配置使AI对项目有“先验认知”，在处理具体任务时更符合预期。正如经验所示，配置完善的 Rules 能将AI从通用助手转变为了解你项目的个性化开发伙伴。

提示： 随着大模型的能力提升，规则应从简单或者空白开始，只有当你发现 agent 反复犯同样的错误时，再新增规则。注意，在真正理解自己的开发模式之前，不要过度编写和优化规则。

Commands – 预设任务快捷指令#

Commands（命令）是Cursor提供的_可复用任务模板_，允许我们将常用的AI提示语预先保存，并通过“/”指令快速触发执行。每当我们在 Cursor 聊天输入框键入“/”，IDE 会列出所有可用的命令，让我们一键选用。这些命令本质上是存储于 .cursor/commands/ 目录下的 Markdown 文件，每个文件定义了一项特定任务的提示和流程。当选择某个命令后，Cursor 会将对应的提示内容插入对话并执行，从而自动完成预定义的重复工作。

Commands 非常适用于一次性、确定性的操作，例如代码格式化、生成模板代码、解释函数含义、修复常见错误等场景。团队可以将日常反复执行的工作抽象为命令并纳入版本管理，这样每位开发者都能共享这些标准化的AI助手脚本。Commands 的优势在于快捷、可重复和团队一致性：所有人使用相同的命令就会得到类似的结果和流程，不会因为个人提示风格不同而产生偏差。

举例来说，在大型遗留项目中，我们可能定义如下命令：

  • /code-review：自动审查当前文件代码风格并给出改进建议。
  • /add-documentation：为选中的函数或模块生成文档注释。
  • /fix-lint：一键修复当前文件的Lint错误并解释所做修改。
  • /generate-api-docs：扫描项目代码生成API接口文档。

这些命令文件中可以写明用途说明和执行步骤，例如 add-documentation.md 里描述“为给定函数生成JSDoc风格注释，包括参数、返回值和示例”并列出执行步骤。这样，当开发者输入/add-documentation时，AI 就能按照模板要求在相应位置添加文档注释。

一个更高级的用例是生成技术设计文档。架构师预先编写 design-doc.md命令，定义了如何根据需求生成设计文档的流程，包括提取需求背景、按公司标准模板撰写章节，以及生成架构图等指令。当开发者需要为某项重构撰写方案时，只需输入类似 /design-doc 用户认证服务重构 @JIRA-12345 的命令，Cursor 就会自动执行以下过程：

  1. 获取需求：通过 MCP 工具调用 Jira API，读取指定需求票据 JIRA-12345 的描述和背景。
  2. 生成内容：按照预定义的文档模板，填充“背景与动机”、“目标非目标”、“高层设计”、“详细设计（含API定义、数据模型、时序图）”、“方案对比”、“风险分析”等章节。
  3. 绘制图表：利用 PlantUML 等工具，自动生成架构图和流程时序图并嵌入文档。
  4. 输出结果：将生成的设计文档保存到项目的 docs/design/ 目录，或通过Confluence MCP发布到内部wiki（如果已配置）。

据实践反馈，这个过程非常高效：一位同事在终端敲下命令去喝咖啡，回来时就发现背景、方案、API设计、风险评估一应俱全的设计文档已经生成完毕，甚至连 Jira 票据中的需求背景都被自动提取进来了！Commands 由此体现出强大的一键多用能力——将复杂任务流水线封装为单条指令执行。对于团队而言，这不仅节省大量重复劳动时间，还确保了输出文档符合统一规范和格式。

值得一提的是，Commands 可以与 Skills 结合，实现链式调用或复杂操作。例如，有用户将清理死代码和生成测试设定为命令：输入/refactor-clean即可让 AI 识别并删除长期未使用的死代码，随后使用/tdd或/test-coverage命令自动补充相应的单元测试或输出测试覆盖率报告。这些命令甚至能在单个对话中按顺序执行，从而实现端到端的代码重构和验证工作。

总之，Commands 为日常开发提供了高效的“快捷键”，让我们用简洁的指令驱动 AI 完成繁琐但规整的任务，在保持代码质量一致性的同时显著提升速度。

Agent Skills – 扩展 AI 的专业技能#

从技术角度来看，如果没有特殊处理，Agents 的任务执行结果往往是非幂等的及具有一定的随机性，Agent Skills（智能技能，简称 Skills）在解决特定领域下的随机性有奇效。你可以把 Skills 理解为对 AI 能力与工作流的模块化扩展：通过定义一组面向特定领域或任务的“技能包”，让 AI 在该场景下拥有更强的专业知识与多步推理能力。

从 Agent Skills 的开放规范看，每个 Skill 本质上是一个包含 SKILL.md 的目录，目录中还可以放置自定义脚本、参考资料与资源文件等。与一次性执行的命令（Commands）不同，Skills 更擅长承载多轮、可迭代的交互过程：AI 会依据技能提示持续思考、做出决策并执行一系列动作；必要时还可以配合外部工具完成任务。

简单来说，如果把 Commands 比作“一次性的宏”，那么 Skills 更像是“持续的子程序”。前者触发后直接返回结果，后者则让 AI 进入一个特定模式，拥有该技能的“思维流程”，从而可以跨多个步骤自治地解决问题。Skills 适用于那些涉及多文件、多步骤的复杂任务，或者需要 AI 自主判断和迭代的场景。典型例子包括：代码重构和迁移（需分析整个代码库并逐步应用修改）、性能优化（定位瓶颈并尝试多种优化手段）、安全审计（静态检查所有模块的漏洞）等。这些任务往往需要 AI 仔细规划、逐步执行、评估结果并可能调整策略——Agent Skills 正是为此设计的。

在 Cursor 中，Skills 的引入使得以前需要人工多轮引导的复杂流程可以一次性完成。比如，我们可以创建一个“数据库迁移”技能，令AI在迁移旧数据库到新架构时自动执行以下步骤：分析当前数据库 schema -> 生成迁移脚本 -> 更新ORM模型代码 -> 运行测试验证。再如，可以有一个“跨服务接口兼容性检查”技能，让AI遍历所有微服务的接口定义，检查契约变化对下游服务的影响，最后汇总报告。这些技能的实现可能会调用文件系统MCP读取代码、调用终端执行测试等，但对用户来说只需发出高层指令：“请检查服务接口改动的影响”，AI便能自主地完成任务。

需要强调的是，Skills 与 MCP 是互补关系，而非竞争关系。

从官方的表述来看，可以把它们放回 agent harness 的三要素里理解：

  • Skills 更偏向 Instructions + 工作流：它封装“做什么”和“怎么做”，包括任务流程、判断标准与领域知识，并且通常会在 Agent 认为相关时动态加载，从而避免把所有细节都常驻在上下文里。
  • MCP 更偏向 Tools：它回答“可以用什么工具”，提供文件读写、终端执行、API 访问等底层能力。

因此，很多过去需要在 MCP 里堆砌大量细粒度调用才能完成的需求，更适合用 Skills 抽象成高层工作流：由 Skill 负责编排步骤与做决策，再通过 MCP 调用通用工具落地执行。

另外，官方还提到一种常见且强大的模式：通过 Skills 配合 hooks，把“目标可验证”的循环固化下来，让 Agent 持续迭代直到满足条件（例如“直到所有测试通过为止”）。这种设计既能保持上下文简洁，又能让复杂任务的执行路径更稳定、更可复用。

从开发者的角度使用 Skills 并不复杂。在 Cursor 中，可以把社区提供的或自定义的技能放入 ~/.cursor/skills/ 或当前项目的 .cursor/skills/ 目录中。Cursor 会在启动时发现技能的名称和描述，必要时在对话中智能激活匹配的技能（按需加载技能的完整内容）。例如，当你请求AI“生成设计文档”时，Cursor 会发现有个名为“design-doc-generator”的 Skill 符合该需求描述，于是载入这个技能的详细指令集，使 Agent 按照既定流程执行文档生成。这种按需激活机制确保AI不会被无关技能干扰，又能在需要时发挥技能威力。

总而言之，Agent Skills 为 Cursor 带来了高度模块化的AI扩展能力。我们可以不断沉淀和复用针对各种场景的技能，让AI具备特定领域的“专长”。对于遗留项目而言，这意味着我们可以培育出一系列“老练的AI助手”，如“遗留代码重构专家”、“性能优化顾问”、“安全审计助手”等技能模块，在需要时随时调用它们为项目服务。

现在 Skills 已经是各大 Agents 编程工具的必备模块，所以网络上有很多相关的资源可以供我们使用，如果我们安装了 find-skills 和 skill-creator 这两个 Skill，就能在 Cursor 中快速且便捷的寻找和创建 Skill 了。

在下文的实战部分，我们将看到Skills与其他工具配合如何助力复杂任务的完成。

Subagents – 子代理与任务委派#

大型工程往往将任务拆解给不同角色的人去并行处理，类似地，Cursor 引入了Subagents（子代理）的概念，实现AI 助手的多代理协作。Subagent 是由主 Agent（主代理）派生出的专门 AI 助手，每个子代理在自己的隔离上下文中运行，专注处理特定类型的工作，然后将结果反馈给主代理。由于上下文隔离，子代理的详细对话内容不会污染主代理的对话，使主代理能够保持高层次的视野。这种架构让复杂任务可以像人类团队那样并行、分工完成：主代理负责任务编排和决策，不同子代理各司其职，最后汇总成果。

在 Cursor 近期版本中，Subagents 特别适合用于拆解多步骤任务和执行耗时操作。使用子代理有几个主要好处：

  • 上下文独立：每个子代理有自己的上下文窗口，可以加载专门的信息和工具，而不会挤占主对话的上下文容量。例如，一个子代理可以读取大量代码文件进行分析，而主代理的上下文仍保持简洁，避免因加载大量细节而触发AI遗忘关键指令。
  • 并行处理：主代理可以同时启动多个子代理，让它们并行工作，从而加快整体任务完成时间。比如在重构大型代码库时，一个子代理扫描代码寻找重复模式，另一个子代理同时在生成重构方案，两者完成后主代理汇总。
  • 能力专精：每个子代理可以配置成专精某类任务，拥有特定的技能集和工具权限。这类似于团队中有架构师、测试工程师、安全专家等角色，各自使用适合自己的工具。通过这种专精化，AI 的表现会更准确。例如，测试子代理可以只使用测试相关命令和MCP（如运行测试套件的工具），安全子代理则加载漏洞扫描技能和安全数据库访问等工具。

举个具体例子，一个大型微服务遗留项目可以配置以下子代理角色：

  • Planner（规划者）：负责分析高层需求，将复杂功能拆解为可执行的开发任务列表（相当于项目经理/业务分析的角色）。
  • Architect（架构师）：擅长系统设计，基于项目的架构规则，为新功能或重构方案生成设计方案（例如设计微服务的交互、新增模块的架构等）。
  • Coder/Refactorer（开发者）：专注于代码实现或重构工作，根据任务编写或修改代码。
  • TDD-Guide（测试指导）：专门用于测试驱动开发，帮助编写单元测试、集成测试，确保代码满足验证标准。
  • Security-Reviewer（安全审核）：负责静态扫描代码中的安全隐患，检查依赖项漏洞、敏感信息泄露等问题。

主代理可以根据任务需要动态委派给一个或多个子代理。例如，当我们让 Cursor “升级用户认证服务的架构”，主代理会先调用 Architect 子代理生成新的设计方案，然后调用 Coder 子代理按方案修改代码，接着召唤 TDD-Guide 子代理为关键组件生成测试用例，最后让 Security-Reviewer 子代理审计修改后的代码安全性。每个子代理都在自己的上下文中各尽其职，而主代理统筹全局、整合结果。整个过程就如同多个AI专家在协作，各自贡献专长，最终合力完成一项复杂任务。

配置 Subagents 需要我们为每个子代理设计专属的规则、技能和工具权限。例如，可以为 Architect 子代理制定规则，让其风格更偏向架构决策和文档输出，并允许它使用PlantUML绘图工具和项目Wiki的MCP接口；而 Security-Reviewer 子代理则配置只能访问代码文件和安全漏洞数据库，不具备修改代码的权限。通过明确子代理边界，既保证了安全性，又提高了子代理工作的聚焦度和可靠性。

需要注意的是，目前 Subagents 功能相对新颖，自定义子代理时要避免过度复杂化。如果任务本身不需要并行或隔离处理，引入子代理可能徒增沟通成本。最佳实践是针对那些上下文非常庞大或任务流程清晰可拆分的场景使用子代理，让每个子代理发挥长处。

总的来说，Subagents 将我们与 AI 的协作提升到了团队层面，我们可以合理利用它们来模拟真人团队的并行协作模式，使 AI 在复杂项目中也能井井有条、各个击破。

MCP – 模型上下文协议，连接外部世界#

工程开发中经常需要获取代码以外的信息或执行环境操作，例如读取文档、调用外部API、运行构建脚本等。MCP（Model Context Protocol） 正是为此而生的机制。MCP 是 Anthropic 提出的一个开放协议，作用是连接 Cursor AI 与外部系统和数据，为 AI 提供“触手”去感知和操作外部世界。打个比方，如果把 AI 比作大脑，MCP 提供的各种工具接口就是 AI 的手脚，赋予它操作系统资源的能力。

在 Cursor 中，MCP 通过 MCP Server 的形式实现。这些服务器可以是本地运行的进程（通过标准IO）或远程的服务（通过 SSE 流），Cursor 客户端与它们通信，发送指令并获取结果。每一种 MCP 工具都封装了一类外部交互能力，我们可以根据需要安装和配置。例如：

  • 文件系统工具：允许 AI 读写项目文件，浏览项目目录结构等。这使AI能够直接查阅代码库的内容或写入生成的代码文件。
  • 终端命令工具：让 AI 执行 shell 命令（受控范围内），比如运行测试套件、构建项目、执行数据库迁移脚本等。
  • Web/API 工具：调用外部HTTP API或者集成第三方服务。例如 Jira MCP 可让 AI 读取/更新任务工单，GitLab/GitHub MCP 可用于检索代码仓库信息、创建合并请求，Confluence MCP 则能读写内部Wiki内容。
  • 数据库工具：连接外部数据库执行查询或修改。比如 DevDB MCP 支持对 MySQL、PostgreSQL 等数据库进行查询并以表格形式返回结果。
  • 浏览器/测试工具：通过 Browser MCP，让 AI 驱动无头浏览器进行端到端测试、页面截图等操作。
  • 设计工具：如 Figma MCP，可以让 AI 获取设计稿信息并生成对应的前端代码，实现设计到代码的自动转换。

借助 MCP，这些外部能力都可以被 AI 在对话中像调用函数一样使用。例如，之前提到的设计文档命令使用了 Jira MCP 来获取需求背景，又用文件系统MCP将文档保存到项目目录。再如，当我们要求 AI “请运行所有单元测试并修复失败”，Cursor 可以借助终端MCP执行测试命令，然后读取测试结果文件，分析失败原因并尝试修改代码。MCP 的引入大大扩展了 AI 的工作范围——从只能凭训练知识“闭门造车”，进化到可以实时查询项目现状和与环境交互，真正融入开发流程。

然而，强大的MCP也带来了新的挑战，其中最主要的是上下文和资源管理。每添加一种MCP工具，AI在对话中就多了一份可用信息和接口说明。如果启用了太多MCP工具，这些工具描述会占据大量上下文窗口，从而挤占AI思考实际问题的空间。实践经验表明，即使Claude模型支持高达20万Token的上下文，但如果同时加载几十个工具，其有效上下文可能大幅缩水（例如只剩下70k tokens 可用），导致性能下降。因此我们在配置 MCP 时应遵循“按需加载，精简高效”的原则。一些最佳实践包括：

  • 挑选关键工具：优先配置那些通用且价值高的 MCP，例如文件系统、终端、GitHub、浏览器等。尽量避免加入过于细碎和冷门的工具。理想情况下，启用的MCP数量控制在十个以内，每个 MCP Server 提供若干高层次功能即可。
  • 分阶段启用：Cursor 允许根据需要手动启用/禁用 MCP。可以在需要时动态加载某些工具，而非让所有工具始终占用上下文。例如，仅在运行测试时启用测试相关MCP，平时关闭。
  • 监控上下文占用：定期留意对话中的系统提示长度。如果发现MCP说明占比过高，可以考虑精简MCP工具集或者修改MCP Server配置让描述更简洁。
  • 安全控制：MCP开放了AI对外部世界的通道，也要注意安全。确保对具有破坏性的终端命令或数据修改操作设置确认步骤或权限限制，防止AI误用工具造成破坏。

总之，MCP 为 AI 打开了一扇与现实交互的窗户，让 Cursor 真正融入开发者生态。例如，在遗留项目的改造中，我们常常需要查阅历史文档、读取旧版数据库、调用外部API验证行为，有了MCP这些都能交给AI自动完成。只要我们精心挑选和配置工具，AI 助手就能如虎添翼地完成许多过去需要人工才能完成的环境交互任务。

最佳实践与注意事项#

要充分发挥 Cursor 这些功能的价值，并在团队协作中安全顺畅地使用，值得遵循以下几个最佳实践：

  • 把任务写成“可验证目标”：目标描述里明确给出验证信号（signals），例如 typecheck、lint、关键测试用例、以及必要的手工验证点。Agent 无法修复它“看不见”的问题，越可验证，迭代越快。
  • 对话要短而聚焦：如果要切换到另一个功能、Agent 看起来困惑、或已经完成了一个逻辑完整的工作单元，就开始新对话。继续同一功能的迭代和调试时再延续当前对话。
  • 让 Agent 自己获取上下文：不知道文件在哪时，不必在提示里手动标记一堆文件，交给 Agent 通过搜索去定位。把不相关文件塞进上下文反而会稀释重点。
  • 需要历史成果时引用而不是粘贴：在新对话里尽量引用过去的工作成果，而不是把整段对话复制过来。
  • 逐步引入，聚焦需求：面对众多新概念，不要一次性全部打开。根据项目需求优先启用最有价值的部分。例如，先编写关键的 Rules 和常用 Commands，等团队熟悉后再尝试 Skills 和 Subagents。每增加一种技能或子代理，都应有明确的目的和用法，避免配置泛滥导致混乱。
  • Rules 精炼有效：编写规则时抓大放小，重点约束AI容易出错或必须统一的地方。规则文件不求面面俱到，而在于提供关键指引。定期根据AI表现调整规则内容和措辞——有经验的用户甚至会让不同模型各自“翻译”一遍规则，以优化其理解效果。同时将 .cursor/rules 纳入版本控制，以便团队共享更新。
  • Commands/Skills 模板化团队经验：当某个操作被反复执行或某类问题反复出现时，就把它总结为命令或技能。例如代码合并流程、发布流程、常见故障修复步骤等，都可以写成命令供大家使用。这不仅节省时间，也在无形中沉淀了团队的隐性知识为显性脚本，提升新人上手速度。
  • 合理运用 Skills vs MCP：尽量使用 Skills 来封装复杂流程逻辑，减少对细粒度 MCP 工具的滥用。MCP 工具应聚焦提供底层能力（如文件访问、执行命令）和少数高价值外部集成功能，而不是把业务逻辑硬编码进 MCP。一些情况下，用简单脚本配合技能即可完成任务，无需开发繁杂的 MCP Server。总之，以技能的灵活编排结合 MCP 的硬件接口来设计解决方案，能获得更佳的性能和可靠性。
  • 监控上下文占用：始终记得，AI 模型有上下文长度限制。随着对话推进和各种规则/工具加载，可能触发模型对先前内容的“遗忘”或输出变慢。遇到这种情况，可考虑使用 Cursor 提供的内存管理功能（如记忆窗、上下文折叠等）来压缩不必要的历史对话，或者手动暂时停用某些Rules/MCP，以保证当前任务的有效上下文充足。
  • Subagents 边界清晰：如果启用子代理，务必为其设定清晰的角色边界和权限。例如限制子代理只能访问指定目录文件或特定API，防止“越权”操作。同时关注子代理的运行状况，防止因为上下文不共享而导致的信息不一致问题。如果子代理效果不佳，不妨简化任务改由主代理完成——切忌为用而用，增加不必要复杂度。随着产品更新，子代理功能也在持续改进，保持关注官方文档以获取最新用法。
  • 人机协同把关：再强大的AI也不应完全脱离人的监督。在让 AI 执行危险操作（如删除文件、数据库变更）前，建议加入人工确认环节。最终的代码和文档也要经过团队review，尤其是安全和架构方面由相关负责人把关。将 Cursor 视为能显著加速和增强人类工作的工具，但责任主体仍是人这一点非常重要。
  • 证据驱动的 Debug（适合棘手 bug）：当“直接让 Agent 修 bug”效果不佳时，可以切换到更偏证据的调试方式：先让 Agent 给出多个可能原因假设，然后通过日志/埋点指导复现与采样，最后基于真实运行数据做定向修复。关键是把复现步骤写得足够具体。

按照以上指南使用 Cursor，您的开发流程将逐渐体现出“Agent 编程助手深度融入”的特征：很多重复繁琐的工作由 AI 承担，复杂决策由 AI 给出草案供人拍板，团队成员能够把更多精力投入创造性和关键性的事务上。这种转变对于维护庞大的遗留系统特别有益 - AI可以帮助我们梳理旧代码、规避已有陷阱，同时以统一标准推进新功能开发，使得整个系统的演进更加从容有序。

下一篇博文将会详细讲述一个使用 Cursor 进行遗留系统改造的实例供你参阅 😄