文章总结： 本文分享了作者使用CursorAI编程工具进行结对编程四个月的经验，重点介绍了如何通过建立rules规则和MCP模型上下文协议工具提升AI协作效率。作者强调清晰指令和结构化思维的重要性，认为AI编程工具是提高效率的助手而非替代品，能够放大开发者的优点并暴露不足，成为成长的催化剂。文章提供了具体的rules示例和MCP配置，以及实际应用案例，展示了AI辅助编程的最佳实践。
综合评分： 87
文章分类： AI安全,安全工具,应用安全,安全建设,其他
与Cursor结对编程的四个月，我大彻大悟了！
腾讯程序员
腾讯技术工程
2025年8月11日 17:36
广东
作者：hassonlin
前言：为什么选择Cursor？
最近几个月，我被安排负责与大模型应用相关的开发工作。刚开始接触OpenAI的AgentSDK、OpenManus时，面对一大堆新名词，比如Functioncall、ReAct、Agent 等概念像一堆零散的拼图等，真的是一头雾水。好在平时我也会关注大模型领域的最新资讯，了解到Cursor可以帮助快速理解项目代码。实际体验后，发现它确实比当时的工蜂好用不少，于是我就果断“付费上班”了。而这段经历的价值远不止于效率提升 —— 在与 Cursor 磨合的过程中，我逐渐沉淀出一套与 AI 结对编程的方法论。
转眼四个月过去了，Cursor确实帮了我很多忙。无论是熟悉新项目，还是日常查代码、自动生成文档，它都为我节省了大量时间，也让我在工作中积累了不少新知识。使用过程中，我有两个深切体会：
● 如何把需求说清楚：模糊的描述会让 Cursor 无所适从，只有将需求讲得具体、明确，它才能更精准地提供帮助。好的描述能事半功倍，比如用 “帮我拆分这个函数，不改变核心逻辑，提升复用性”，而非笼统的 “帮我优化这段代码”。
● 开发前要做好规划：直接让 Cursor “帮我写个 XX”，效果往往不尽如人意。提前拆解需求、规划好步骤，再让它协助实现，效率和质量都会大幅提升。这个规划过程可以自己完成，也能和 Cursor 用文档协作完成 —— 让它帮忙梳理任务、拆解步骤，实现分而自治。 总的来说，Cursor就像一个“聪明但需要明确指令的实习生”，需要你给出明确的指令和框架引导。借此机会，我也想分享一下这四个月的使用心得。我会先讲讲 Cursor 的核心功能与协作逻辑，再用具体案例串联起这套方法论的实践过程。
用 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 中文
MCP
MCP 是什么？相信大家都有一定了解。如果说 rules 是协作的 “规则”，那 MCP（模型上下文协议）就是 “工具箱”—— 它让 Cursor 能连接外部工具，从单纯的代码解析器升级为覆盖开发全流程的伙伴。
关于具体原理这里就不展开细说了，下面直接分享我常用的几个 MCP，它们能有效提升工作效率。
mcp-feedback-enhanced
git链接：https://github.com/Minidoracat/mcp-feedback-enhanced
用过Cursor的都知道，其订阅方案是根据request的次数来计算的，每月仅提供 200 次高级模型使用额度（目前计算方案已调整，但该 MCP 仍能发挥作用）。但实际使用中，因为各种原因，如我们自己描述不清晰、大模型本身“偷懒”、或者一些本身大模型就需要与你反复确认的、多步操作，会让本就稀有的额度白白浪费。
有了这个MCP，配合一些rules，就可以让大模型在本应结束会话时，调用这个MCP征求你的反馈，而且输入体验与原生几乎一模一样，可以输入图片、文字， 可以设置超时后的默认回复，能够有效避免额度浪费。
对比一下有和没有使用该MCP，在遇到一个error信息时，对额度的消耗。
sequential-thinking
一个可以让大模型类似人类思考的工具，结合rules中的实验性规则，为解决复杂问题提供了一种结构化思维管理工具。相比COT（思维链）、ReAct（思考->执行） 可以做到：
- 动态问题拆解：将复杂任务分解为 多步骤思考链 （如理解->分析->计划->确认 ）。如遇到逻辑错误时，会先拆解为 “定位报错行→分析依赖关系→设计修复路径→验证影响范围”，而非一次性给出笼统的方案。
- 反思与修正: 有了这个工具，Cursor会实时修正错误 ：允许自主回溯并修改历史步骤（如“我认为第2步需要修正，因为忽略了xxx这种情况”，让我重新执行）。避免因 “一步错步步错” 的无效推理，减少冗余的额度消耗。
mcp_better_tapd_server
作为推荐架构的同学，我的工作以算法需求和自驱型任务为主，日常产品类需求较少，因此基本不会专门创建 TAPD 。过去要么不记录，要么简单写个标题应付，导致后续部门统计需求或回溯工作时，出现 “找不到具体做了什么” 的情况。
随着mcp的出现，我在内网寻找自动生成tapd 的mcp工具，发现了同事写的 tapd mcp工具。
但我个人有一些定制化述求（主要还是太懒），不想每次建立tapd 的时候，都指明我是xxx、工作区ID是xxxx。所以就自己稍微魔改了一下（Cursor更新后，其实也可以用Memory的功能来实现）。
在与 Cursor 完成交互（包括需求讨论、代码修改等过程）后，只需说一句：“根据我们的交互记录及代码修改记录，帮我写个 TAPD”，Cursor 就能直接生成包含需求背景、具体执行步骤的 TAPD 单，还能自动关联指定迭代。整个过程无需重复输入固定信息，大幅提升了记录Tapd的效率。
其它常用的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工具太多，大模型执行的成功率也会下降）。
一次实践
以学习 OpenAI Agent SDK 为例，我想通过一个具体场景，展示 rules 与 MCP 工具是如何配合工作的。对我而言，熟悉一个项目的核心，在于理清两个逻辑：进程启动的底层机制，以及用户请求的处理链路。于是我向 Cursor 提出需求：“分析这个项目中，用户的一次请求从发起至响应的完整执行流程”。
第一步：Cursor的 “自主拆解” 过程
Cursor 接收到指令后，首先对代码建立索引，自动读取了几个核心文件 —— 这一步遵循了 rules 中 “改动前必须看完所有相关代码” 的约束。
紧接着，它调用了 sequential-thinking 工具，像人类拆解问题那样分步推进：
● 先通过项目结构和文档建立基础认知，明确 “用户请求处理” 是核心流程；
● 再按 “发起→预处理→主循环→响应→结果” 拆解成 8 个步骤；
● 每一步都标注关联的代码模块（比如用户通过Runner.run()发起请求）。
这种结构化思维，完美规避了 AI 直接给结论导致的逻辑断层。
第二步：可视化与反馈闭环
完成初步拆解后，Cursor 按照 rules 要求，用 Mermaid 语法生成了流程图（值得一提的是，聊天框内直接渲染 Mermaid 图表的功能，是 Cursor 最近才更新的新特性，极大提升了逻辑展示的直观性）。随后，它自动调用 mcp-feedback-enhanced 工具弹出反馈框：“是否需要补充细节？”
我在反馈框中输入：“能否从代码层面细化，比如每个步骤涉及的具体类和函数？”—— 这一步将单次请求的额度充分利用，避免了重复发起对话的浪费。
第三步：基于反馈的深度迭代
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 就能从 “被动响应” 变成 “主动推进” 的协作伙伴。
后语
回头看这段 “付费结对编程” 的经历，最珍贵的收获并非节省的时间本身，而是在与 Cursor 磨合中沉淀的思维方式。Cursor也是一种工具，正如 JetBrains 系列 IDE 用快捷键与插件体系重塑编码效率，Git 用版本控制逻辑规范协作流程——好的工具不仅仅会提高效率，还会倒逼使用者优化思维模式：从模糊描述到精准指令，从随性开发到结构化规划。
有的人担心Cursor会取代我们，我认为它就像一面镜子，
● 它会放大你的优点：清晰的需求拆解能力、结构化的思维方式都会被它无限放大；
● 也会暴露你的不足：模糊的指令、混乱的规划必然得到低效的结果。这种 “反馈即时性” 反而成了最好的成长催化剂。
近期我也使用了司内最新推出的CodeBuddy（Tencent Cloud Code Assistant CodeBuddy – AI Code Editor），现在也支持最强模型Claude4.0，弥补了模型上的差距后，体验确实好了不少，直逼Cursor。感兴趣的同学也可以体验下。
真心希望CodeBuddy越做越好，争取早日结束“付费上班”。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：腾讯技术工程 腾讯程序员《与Cursor结对编程的四个月，我大彻大悟了！》