目录

1 前言：为什么选择Cursor？

2 用 rules 建立协作共识：让 AI 懂你的 “做事规矩”

3 MCP

4 一次实践

5 后语

本文分享了作者使用AI编程工具Cursor的实战经验，重点探讨了如何通过制定协作规则（rules）和集成MCP工具提升开发效率。文章系统性地介绍了规则约束的必要性、常用MCP工具的功能价值，并通过分析OpenAI Agent SDK的案例，展示了规则与工具配合的高效协作模式。

01

前言：为什么选择Cursor？

最近几个月，我深度参与到大模型应用相关的开发工作。刚开始接触OpenAI的AgentSDK、OpenManus时，面对一大堆新名词，比如Functioncall、ReAct、Agent 等概念像一堆零散的拼图等，真的是一头雾水。好在平时我也会关注大模型领域的最新资讯，了解到Cursor可以帮助快速理解项目代码。实际体验后，发现它确实名不虚传，于是我就果断“付费上班”了。而这段经历的价值远不止于效率提升 —— 在与 Cursor 磨合的过程中，我逐渐沉淀出一套与 AI 结对编程的方法论。

转眼四个月过去了，Cursor确实帮了我很多忙。无论是熟悉新项目，还是日常查代码、自动生成文档，它都为我节省了大量时间，也让我在工作中积累了不少新知识。使用过程中，我有两个深切体会：

  • 如何把需求说清楚：模糊的描述会让 Cursor 无所适从，只有将需求讲得具体、明确，它才能更精准地提供帮助。好的描述能事半功倍，比如用 “帮我拆分这个函数，不改变核心逻辑，提升复用性”，而非笼统的 “帮我优化这段代码”。

  • 开发前要做好规划：直接让 Cursor “帮我写个 XX”，效果往往不尽如人意。提前拆解需求、规划好步骤，再让它协助实现，效率和质量都会大幅提升。这个规划过程可以自己完成，也能和 Cursor 用文档协作完成 —— 让它帮忙梳理任务、拆解步骤，实现分而自治。

总的来说，Cursor就像一个“聪明但需要明确指令的实习生”，需要你给出明确的指令和框架引导。借此机会，我也想分享一下这四个月的使用心得。我会先讲讲 Cursor 的核心功能与协作逻辑，再用具体案例串联起这套方法论的实践过程。

02

用 rules 建立协作共识：让 AI 懂你的 “做事规矩”

什么是 rules？就像 “国有国法，家有家规”，在和 Cursor 结对编程的过程中，也需要一套 “家规” 来约束它，防止它随意发挥、天马行空。简单来说，rules 就是我给 Cursor 定下的行为准则和沟通规范。

之所以需要这样的 “家规”，核心原因在于和 AI 协作时，其 “聪明” 与 “不可控” 的矛盾始终存在 —— 就像实习生需要明确职责边界才能让工作有序推进，与 Cursor 协作同样需要通过规则来框定行为范围。这正是 rules 的核心价值：用具体可执行的约束替代模糊的预期，让 AI 的输出能够精准贴合实际开发需求。

未经约束的 Cursor 可能过度设计代码（比如为简单功能加多层抽象），或在修改时误触核心逻辑。而 rules 通过提前明确 “能做什么”“不能做什么”，解决三个关键问题：

  • 减少无效沟通：比如规定 “解释代码必须用通俗语言”、“修改代码或解释代码前，需要多画图”，省去反复纠正表达风格的时间；

  • 降低操作风险：用 “最小化修改原则” 限制 AI 仅改动必要部分，防止核心代码被破坏；

  • 统一协作标准：团队共用一套规则时，AI 输出的代码风格、文档格式能保持一致，减少整合成本。

有了这些规则，Cursor 就像多了 “说明书”，能更贴合工作习惯和合规要求，沟通更高效。且规则需动态完善 —— 遇到新需求或新问题时，可补充rules让其更适配团队需求。

Cursor 的 rules 分为全局 rules 和项目 rules：不同项目可在.cursor/rules/*.mdc 目录下添加专属规则，用 git 管理实现团队共享；用模块化语言编写规则，更利于大模型理解。

以下是我目前的rules。

    ## 通用礼节 (General Etiquette)- 优先保证代码简洁易懂。- 别搞过度设计，简单实用就好。- 写代码时，要注意圈复杂度，函数尽量小，尽量可以复用，尽量不写重复代码。- 写代码时，注意模块设计，尽量使用设计模式。- 给我解释代码的时候，说人话，别拽专业术语。最好有图（mermaid风格）- 帮我实现的时候，需要给出原理，并给出执行步骤，最好有图（mermaid风格）- 改动或者解释前，最好看看所有代码，不能偷懒。- 改动前，要做最小化修改，尽量不修改到其他模块的代码- 改动后，假定10条case 输入，并给出预期结果- 给出的mermaid图，必须自检语法，可以被渲染，在暗黑主题上清晰可见- 给出的mermaid图，必须要可以被暗黑主题渲染清晰 # 实验性规则 (Experimental Rule)当你被要求修复一个 Bug 时，请遵循以下步骤：1.  **理解问题 (Understand):** 仔细阅读 Bug 描述和相关代码，复述你对问题的理解。2.  **分析原因 (Analyze):** 提出至少两种可能的根本原因。3.  **制定计划 (Plan):** 描述你打算如何验证这些原因，并给出修复方案。4.  **请求确认 (Confirm):** 在动手修改前，向我确认你的计划。5.  **执行修复 (Execute):** 实施修复。6.  **审查 (Review):** 查看自己的修改有没有问题。7.  **解释说明 (Explain):** 解释你做了哪些修改以及为什么。 # MCP Interactive Feedback 规则1. 在任何流程、任务、对话进行时，无论是询问、回复、或完成阶段性任务，皆必须调用 MCP mcp-feedback-enhanced。2. 每当收到用户反馈，若反馈内容非空，必须再次调用 MCP mcp-feedback-enhanced，并根据反馈内容调整行为。3. 仅当用户明确表示「结束」或「不再需要交互」时，才可停止调用 MCP mcp-feedback-enhanced，流程才算结束。4. 除非收到结束指令，否则所有步骤都必须重复调用 MCP mcp-feedback-enhanced。5. 完成任务前，必须使用 MCP mcp-feedback-enhanced 工具向用户询问反馈。 Always respond in 中文

    03

    MCP

    MCP 是什么？相信大家都有一定了解。如果说 rules 是协作的 “规则”，那 MCP（模型上下文协议）就是 “工具箱”—— 它让 Cursor 能连接外部工具，从单纯的代码解析器升级为覆盖开发全流程的伙伴。

    关于具体原理这里就不展开细说了，下面直接分享我常用的几个 MCP，它们能有效提升工作效率。

       3.1 mcp-feedback-enhanced

    git链接：https://github.com/Minidoracat/mcp-feedback-enhanced

    用过Cursor的都知道，其订阅方案是根据request的次数来计算的，每月仅提供 200 次高级模型使用额度（目前计算方案已调整，但该 MCP 仍能发挥作用）。但实际使用中，因为各种原因，如我们自己描述不清晰、大模型本身“偷懒”、或者一些本身大模型就需要与你反复确认的、多步操作，会让本就稀有的额度白白浪费。 

    有了这个MCP，配合一些rules，就可以让大模型在本应结束会话时，调用这个MCP征求你的反馈，而且输入体验与原生几乎一模一样，可以输入图片、文字， 可以设置超时后的默认回复，能够有效避免额度浪费。

    图片

    对比一下有和没有使用该MCP，在遇到一个error信息时，对额度的消耗。

    不使用mcp-feedback-enhanced

    		  使用mcp-feedback-enhanced 

    1. 描述报错 → AI返回方案1（消耗1次）

    1. 提交报错截图或日志（初始请求）

    2. 方案1无效 → 用户重新描述（消耗2次）

    		 2. Cursor分析，返回修复方案 →   弹窗调用工具待确认 

    3. AI返回方案2 → 仍报错（消耗3次）

    		 3. 提供修正方案细节 →   AI调整后执行 

    4. 循环至解决（总计5-8次）

    		 4.  循环至解决，1次调用完成全流程 

       3.2 sequential-thinking 

    一个可以让大模型类似人类思考的工具，结合rules中的实验性规则，为解决复杂问题提供了一种结构化思维管理工具。相比COT（思维链）、ReAct（思考->执行） 可以做到：

    1. 动态问题拆解：将复杂任务分解为 多步骤思考链  （如理解->分析->计划->确认 ）。如遇到逻辑错误时，会先拆解为 “定位报错行→分析依赖关系→设计修复路径→验证影响范围”，而非一次性给出笼统的方案。

    2. 反思与修正：有了这个工具，Cursor会实时修正错误  ：允许自主回溯并修改历史步骤（如“我认为第2步需要修正，因为忽略了xxx这种情况”，让我重新执行）。避免因 “一步错步步错” 的无效推理，减少冗余的额度消耗。

    图片

       3.3 mcp_better_tapd_server

    作为推荐架构的同学，我的工作以算法需求和自驱型任务为主，日常产品类需求较少，因此基本不会专门创建 TAPD 。过去要么不记录，要么简单写个标题应付，导致后续部门统计需求或回溯工作时，出现 “找不到具体做了什么” 的情况。

    随着MCP的出现，我在内网寻找自动生成TAPD的MCP工具，发现了同事写的 TAPD MCP工具。  

    但我个人有一些定制化述求（主要还是太懒），不想每次建立TAPD的时候，都指明我是xxx、工作区ID是xxxx。所以就自己稍微魔改了一下（Cursor更新后，其实也可以用Memory的功能来实现）。

    在与 Cursor 完成交互（包括需求讨论、代码修改等过程）后，只需说一句：“根据我们的交互记录及代码修改记录，帮我写个 TAPD”，Cursor 就能直接生成包含需求背景、具体执行步骤的 TAPD 单，还能自动关联指定迭代。整个过程无需重复输入固定信息，大幅提升了记录TAPD的效率。

    图片

    图片

       3.4 其它常用的MCP

    除了上述提到的工具外，以下这些 MCP 也帮了我很多

    • context7：最近也是化身为全栈工程师，有些前端的接口术语不是很懂，context7这个mcp会保存各个组件的实时文档，防止Cursor乱编；

    • mcp-git-ingest：让Cursor直接通过网络访问github仓库并理解，无需下载到本地；

    • tRPCMCPServer：TRPC官方出的MCP工具，对脚手架的生成、文档查询都有一定帮助。在写trpc相关服务的时候非常有用。

    以下是我完整的MCP配置。

      {  "mcpServers": {    "context7": {      "command": "npx",      "args": ["-y", "@upstash/context7-mcp@latest"]    },    "mcp-git-ingest": {      "command": "uvx",      "args": ["--from", "git+https://github.com/adhikasp/mcp-git-ingest", "mcp-git-ingest"]    },    "mcp_better_tapd_server": {      "command": "uvx",      "args": [        "--index-url", "https://mirrors.tencent.com/repository/pypi/tencent_pypi/simple",        "--extra-index-url", "https://pypi.org/simple",        "mcp_better_tapd_server"      ],      "env": {        "TAPD_API_USER": "feed_mcp",        "TAPD_API_PASSWORD": "",        "TAPD_API_BASE_URL": "xxxx",        "TAPD_BASE_URL": "xxx",        "TAPD_DEFAULT_OWNER": "xxxx",        "TAPD_WORKSPACE_ID": "xxx"      }    },    "mcp-feedback-enhanced": {      "command": "uvx",      "args": ["mcp-feedback-enhanced@latest"],      "timeout": 600,      "env": {        "MCP_DESKTOP_MODE": "true",        "MCP_WEB_PORT": "8765",        "MCP_DEBUG": "false"      },      "autoApprove": ["interactive_feedback"]    },    "tRPCMCPServer": {            "type": "sse",            "url": "http://trpc-mcp-server.woa.com/sse"     },    "sequential-thinking": {        "command": "npx",        "args": [          "-y",          "@modelcontextprotocol/server-sequential-thinking"        ]      }  }}

      mcp-feedback-enhanced 让我明白，闭环沟通是减少浪费的关键 —— 把多轮交互压缩在单次请求里，本质是用工具固化 “提出需求→获取反馈→迭代优化” 的循环；sequential-thinking 则示范了结构化思维的力量，将复杂任务拆解成 “理解→分析→计划→验证→结果” 的步骤，其实是在复刻人类解决问题的自然逻辑；而 mcp_better_tapd_server 则印证了无缝衔接的智慧，让协作过程自动转化为任务记录，消除了 “开发” 与 “记录” 之间的割裂感。

      也尝试过更多的MCP工具，但使用得越多，越明白一个道理：它们的价值远不止于 “解决某个具体问题”，更在于串联起一套高效协作的工作流（当然，MCP工具太多，大模型执行的成功率也会下降）。

      04

      一次实践

      以学习 OpenAI Agent SDK 为例，我想通过一个具体场景，展示 rules 与 MCP 工具是如何配合工作的。对我而言，熟悉一个项目的核心，在于理清两个逻辑：进程启动的底层机制，以及用户请求的处理链路。于是我向 Cursor 提出需求：“分析这个项目中，用户的一次请求从发起至响应的完整执行流程”。

         4.1 第一步：Cursor 的 “自主拆解” 过程

      Cursor 接收到指令后，首先对代码建立索引，自动读取了几个核心文件 —— 这一步遵循了 rules 中 “改动前必须看完所有相关代码” 的约束。

      紧接着，它调用了 sequential-thinking 工具，像人类拆解问题那样分步推进：

      • 先通过项目结构和文档建立基础认知，明确 “用户请求处理” 是核心流程；

      • 再按 “发起→预处理→主循环→响应→结果” 拆解成 8 个步骤；

      • 每一步都标注关联的代码模块（比如用户通过Runner.run()发起请求）。

      这种结构化思维，完美规避了 AI 直接给结论导致的逻辑断层。

      图片

         4.2 第二步：可视化与反馈闭环

      完成初步拆解后，Cursor 按照 rules 要求，用 Mermaid 语法生成了流程图（值得一提的是，聊天框内直接渲染 Mermaid 图表的功能，是 Cursor 最近才更新的新特性，极大提升了逻辑展示的直观性）。随后，它自动调用 mcp-feedback-enhanced 工具弹出反馈框：“是否需要补充细节？”

      图片

      我在反馈框中输入：“能否从代码层面细化，比如每个步骤涉及的具体类和函数？”—— 这一步将单次请求的额度充分利用，避免了重复发起对话的浪费。

      图片

         4.3 第三步：基于反馈的深度迭代

      Cursor 根据我的需求，进一步定位到核心代码片段：

      • 指出用户请求的入口是Runner.run()（位于 src/agents/run.py:166），这是一个静态方法，实际委托给DEFAULT_AGENT_RUNNER执行；

      • 详细解释AgentRunner.run()（src/agents/run.py:328）如何处理上下文、设置循环次数，以及钩子函数的调用时机；

      • 补充RunImpl.process_model_response解析 LLM 输出的具体逻辑。

      图片

      这样不断循环，直到达到一次Request的MCP调用次数上限（25次）。  

      整个过程中，它始终遵循我的rules—— 只聚焦用户请求的流程分析，不触碰无关代码，并用各式各样的图展示出来。当规则明确了协作框架，工具填补了能力缺口，AI 就能从 “被动响应” 变成 “主动推进” 的协作伙伴。

      05

      后语

      回头看这段“付费结对编程”的经历，最珍贵的收获并非节省的时间本身，而是在与 Cursor 磨合中沉淀的思维方式。Cursor也是一种工具，正如 JetBrains 系列 IDE 用快捷键与插件体系重塑编码效率，Git 用版本控制逻辑规范协作流程——好的工具不仅仅会提高效率，还会倒逼使用者优化思维模式：从模糊描述到精准指令，从随性开发到结构化规划。

      有的人担心Cursor会取代我们，我认为它就像一面镜子，

      • 它会放大你的优点：清晰的需求拆解能力、结构化的思维方式都会被它无限放大；

      • 也会暴露你的不足：模糊的指令、混乱的规划必然得到低效的结果。这种 "反馈即时性" 反而成了最好的成长催化剂。

      近期我也使用了司内最新推出的CodeBuddy（https://www.codebuddy.ai/ ），现在也支持最强模型Claude4.0，弥补了模型上的差距后，体验确实好了不少，直逼Cursor。感兴趣的同学也可以体验下。

      随着 CodeBuddy 的持续迭代、越做越好，我早日结束“付费上班”的日子已经不远了！

      # 结对编程
      Logo
      AI编程社区

      汇聚全球AI编程工具，助力开发者即刻编程。

      更多推荐

      cover

      AI编程的革命性变革

      avatar AI编程社区
      cover

      AI编程正在颠覆传统软件开发范式。根据Gartner预测，到2025年，70%的新应用将通过低代码/无代码技术开发。本文通过技术解析、代码实例和可视化图表，深入探讨三大核心领域

      avatar AI编程社区
      cover

      用 TRAE 从零开始跑通仓颉编程语言开发的MCP服务器——全流程实战笔记

      avatar AI编程社区