说实话用 AI 写代码这件事我自己从最初的新鲜期一路走到现在差不多经历了三个阶段真香、鸡肋、真香。前两次“真香”中间夹着的那个“鸡肋期”恰恰是我对 Cursor 这类 AI 编程工具从“看热闹”转向“看门道”的节点。如果你现在也觉得 AI 生成的代码多数只能当参考真正落地还得靠自己重写那这篇内容就是讲我怎么给 Cursor 装上各种“外挂”把那些半吊子的 AI 输出逐步变成能直接进生产环境的产出。这篇文章适合谁适合已经用过 Cursor、但总觉得 AI 写的东西不够顺手的人也适合刚接触 AI 编程、想少走弯路的人。我会从问题根源讲起再到规则文件、工具链接入、完整工作流最后附上我踩坑后的排查记录。没有太多高深理论全是能直接抄过去用的配置和思路。1. 为什么 AI 干的活经常“鸡肋”1.1 问题不在模型在边界很多人觉得 Cursor 生成代码“鸡肋”是因为模型能力不够。但实际用下来我更倾向于另一个结论大部分问题出在使用边界没划清楚。模型有一个已知的强项就是基于给定上下文做延续式生成给的信息越具体输出越接近预期给的信息越宽泛它就越容易发挥出“废话文学”的天赋。比如你直接在对话框里写“帮我优化一下这段代码”模型只能猜。猜你指的是性能优化、可读性优化还是安全优化猜你现在的技术栈是什么猜你有没有测试兜底。一旦猜偏结果自然就是那种“说不上错、但根本没法直接用”的鸡肋代码。1.2 缺上下文是鸡肋的第一来源我发现最常见的失败模式是这样的AI 只看到了当前打开的一两个文件就敢给出一版改动方案。它不知道这个项目有没有统一的路由封装不知道接口请求走的什么层更不知道状态管理用的什么方案。结果生成出来的代码风格跟项目里其他文件完全对不上复制进去之后编译倒是能过但代码审查时一眼就被打回。人类程序员接手一个陌生项目时第一件事是看 README、看目录结构、看整体架构。AI 不会主动做这些事除非你告诉它。这就是为什么直接让它干活往往只能得到“局部正确、整体无语”的结果。1.3 没有反馈闭环AI 在盲目飞行再往深一层说AI 干的活鸡肋还有一个关键原因它没有自己验证的能力。你写代码的时候写完会编译、会跑测试、会看一眼报错但 Cursor 里的 AI 默认没有这个环节它生成完代码就开始等你的反馈就像一个人在黑屋子里拍了一张照片然后问你“拍得怎么样”。有时候它生成的是残缺函数有时候是过时 API但因为没有反馈它自己并不知道。所以后来我的思路整个转变了与其指望 AI 一步到位不如把环境给它配好让它能查资料、能跑命令、能看报错、能自己改自己。这一步就是从“对话式编程”迈向“代理式编程”的核心差异。2. 先立规矩规则文件是性价比最高的外挂2.1 一分钟看懂规则文件机制如果你还没认真用过 Cursor 里面的规则文件那我建议从它开始。简单说规则文件就是一段持续性注入给 AI 的上下文它会随你的每次提问一起发送相当于给 AI 立了一套“对话前必读”的行为准则。这个机制的价值在于你不用每一次对话都重复解释“我们是 Java 项目、用 Maven 构建、代码风格是 Google Style、不要随便动公共模块”。只要规则文件里写清楚了AI 每次回答都会默认遵守。这就像给新同事发了一份入职手册而不是等对方反复来问。规则文件分为项目级和全局级。项目级放在项目根目录文件名通常是 .cursorrules生效范围局限在当前项目全局级放在全局配置目录对所有项目生效。我的做法是全局文件只写通用的行为准则比如“不要编造不存在的 API”项目文件才写具体的架构约束和编码规范。2.2 一份生产可用的规则文件模板下面这份模板我在多个项目里反复调整过基本可以直接套用。关键不是模板本身而是每一条背后要对应真实的项目约束别写空话。# 项目背景 这是一个面向内部运营人员使用的数据可视化平台前端采用 React 18 TypeScript Vite 后端采用 Spring Boot 3数据库为 MySQL 8。项目内已存在统一的请求封装src/utils/request.ts 所有接口请求必须通过该封装发起禁止在业务代码中直接使用 fetch 或 axios。 # 代码规范 - 组件文件使用 PascalCase 命名工具函数使用 camelCase 命名。 - 样式优先使用 CSS Modules禁止使用全局 class 污染。 - 所有异步操作必须考虑 loading 和 error 状态不得静默失败。 - 禁止在组件内部直接写复杂的业务逻辑请抽取到 src/hooks 或 src/services。 # 架构约束 - 业务状态管理使用 zustand已有 store 位于 src/stores。 - 公共组件放在 src/components/common业务组件放在 src/features/{业务名}/components。 - 新增页面必须配置路由与菜单权限相关配置位于 src/router。 # 开发流程 - 修改前先阅读相关文件理解现状后再动手。 - 涉及多个文件的大改动请先输出改动清单等待确认后再开始编码。 - 生成代码必须符合 TypeScript 严格模式禁止使用 any。 # 不要做什么 - 不要改动 package.json 中已有依赖的版本。 - 不要修改后端接口定义如有需要请提出建议由人工确认。 - 不要生成没有实际调用的死代码。注意规则文件不是越长越好。我自己吃过亏一开始恨不得把所有约定都塞进去结果 AI 经常被长规则干扰反而把重要约束给忽略了。后来我控制在十到二十条每条一句话讲清楚效果明显改善。把最重要的约束放前面因为模型对靠前内容的注意力通常更强。2.3 规则文件里的三个常见误区第一个误区是把规则写成散文。比如“希望 AI 能生成高质量且可维护的代码注意遵循业界最佳实践”这种内容没有任何信息量。规则要具体到能被执行和校验最好是有“是或否”的判断标准。第二个误区是规则之间互相冲突。比如前一条说“所有接口走统一封装”后一条又说“某些场景可直接使用 axios”。一旦出现这种情况AI 的表现会非常不稳定这次听这条下次听那条。所以规则文件里要尽量避免“例外条款”如果真有必要例外就明确写清楚触发条件。第三个误区是写了规则就再也不更新。规则文件应该跟项目同步演进公共模块一旦调整规则里的描述也要跟着改。我习惯每次代码审查时顺手过一遍规则发现过时描述就更新这个习惯帮我避掉过不少 AI 乱带节奏的坑。3. 打通工具链让 AI 真正“动手干活”3.1 从“会聊天”到“会办事”的关键一步规则文件解决了“AI 说人话”的问题但距离“AI 干实事”还差一步它仍然不能主动查资料、执行命令、跑测试。默认情况下Cursor 里的人工只能靠对话框输入AI 输出文字和代码块剩下的动作全部由人来完成。这就像你请了一个只肯写方案、不肯动手打印的助理。后来我接入了一套东西业内管它叫 MCP全称是 Model Context Protocol。你可以把它理解成给 AI 装上的“手脚”——让模型能够通过标准协议去调用外部工具。这样 AI 就可以自己检查项目文件、执行构建命令、搜索文档、操作浏览器甚至查数据库。它彻底改变了协作方式从“人想一步、AI 写一步”变成“人提目标、AI 自己想办法完成并自我验证”。3.2 用一个最小配置跑通 MCP接入 MCP 的第一步是配置文件。在项目根目录创建 .mcp.json内容类似下面这样{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, .] }, command-runner: { command: npx, args: [-y, mcp-server-command-runner], env: { ALLOWED_COMMANDS: npm,git,node,python } } } }配置里给 AI 开了两个“外挂”一个是文件系统访问让它能读取项目目录里的任何文件另一个是命令执行器限定只能运行 npm、git、node 等命令。从我实际使用的安全角度来说给 AI 开放命令行权限要克制越具体的命令白名单越是好习惯。配好之后重启 Cursor 的会话AI 那边会自动识别可用工具。你在对话里提出需求它会在回复的过程中调起这些工具。比如让它“看看这个目录下有哪些文件”它不再只是猜测而是真的去列出文件列表。这一步一旦走通后面很多工作流都会轻松不少。3.3 自定义斜杠命令把高频操作变成一键触发除了 MCPCursor 还支持自定义斜杠命令。我把它理解成“给 AI 预设的常用话术模板”。举个例子我写了一个 /review 命令作用是把当前改动的代码交给 AI 做一轮代码审查。每次写完功能我不需要再打字说明“请你看一下我改的东西重点关注边界条件和错误处理”只需要敲 /review 回车。斜杠命令需要放在项目目录的 .cursor/commands 下每个命令一个 md 文件。下面是一个典型的提交助手命令# 文件.cursor/commands/commit.md 请根据当前的 Git 改动内容生成一条符合 Conventional Commits 规范的提交信息。 要求 1. 先运行 git status 和 git diff --stat 查看改动范围。 2. 再查看 git diff 中的关键内容理解改动意图。 3. 提交信息格式为 type(scope): description。 4. 如果改动涉及破坏性变更在提交信息末尾注明 BREAKING CHANGE。这样做的好处不只是省几个字而是让每次触发的“行为模板”保持稳定。我实际用下来斜杠命令最重要的价值在于把人的经验固化下来。你平时是怎么指挥 AI 的把最顺手的几套指挥方式沉淀成命令文件下次在新项目里也直接同步过去整个团队都能受益。3.4 补充一个给 AI 配“技能包”的进阶方向如果你有编程基础还有另一个思路很值得尝试为 AI 额外挂一个私有工具箱。原理不复杂就是把你自己写的 Python 脚本、Node 脚本暴露成 MCP 服务让 AI 在需要的时候调用。举个例子我维护一套数据库元信息读取脚本AI 在写数据查询相关代码时可以通过这个脚本直接读取表结构而不是靠我的口述。这比让 AI 去翻建表语句文件要可靠得多因为脚本的输出是清洗过的、聚焦的。这个能力做起来并不难你需要在一个本地服务里实现几个 JSON-RPC 接口注册到 MCP 配置里去。第一次配置会花一点时间但一套完整的项目专属工具链收益会持续很久。4. 工作流实战从需求到验收告别一次性对话4.1 一个真实的协作场景前面把规则、工具链都讲了一遍现在落到一个具体场景里串起来看。假设我要在一个老项目上加一个新功能给订单列表增加一个“导出 CSV”按钮后端接口已经有人写好了但前端需要接入。如果按老办法直接问 AI大概率得到的结果是一个写死的接口地址、一段没有 loading 状态的下载逻辑、还有一堆跟项目风格不一致的代码。但按我配好规则和工具的工作流操作过程完全不一样。4.2 四步推进法第一步让 AI 先“读”再“说”。我会要求它先查看路由配置、请求封装、列表页现有逻辑然后输出一份改动影响清单。注意这一步的关键不在清单本身而是强迫 AI 在动手之前建立项目上下文。它输出的清单通常长这样要改哪几个文件、每个文件改什么、是否新增接口封装、是否涉及权限菜单配置。我会检查一遍确认无误后再让它开工。第二步拆分任务小步推进。我不会让 AI 一次性把所有文件改完而是拆成三个任务新增 CSV 导出工具函数、接入列表页按钮、补充导出完成后的提示逻辑。每个任务都让 AI 遵循“先解释思路、再生成代码”的方式完成后停下来等我的反馈。这样做的好处是一旦某一步跑偏修正成本很低不用推倒重来。第三步强制自我验证。任务完成后我会要求 AI 自己跑一遍相关检查通常是指定它执行 linter 或 TypeScript 类型检查。如果环境中配好了 MCP命令由 AI 自己触发没有配好的话我把检查结果贴回去让它修正。这一步是很多“鸡肋”输出的终结者因为大量低级问题在类型检查阶段就暴露了AI 自己就能改掉。第四步人工走查重点看边界。AI 把功能做完之后我不会直接合并。我会把注意力放在它最容易忽略的细节上比如导出的文件名是否有时间戳、空列表时按钮是否可用、接口返回异常时用户看到什么提示。这些边界问题规则文件里很难写全必须靠人来补位。但有了前面几步人工走查的负担已经降到很低了。4.3 一个高价值的提示词模板上面这套流程我沉淀成了一套提示词模板每次在 Cursor 新对话里开始时先发一遍我接下来会给你布置一个开发任务。请你按以下流程执行 1. 先阅读相关文件和目录结构理解现状输出改动影响清单。 2. 等我确认清单后再开始写代码。 3. 每次只完成一个子任务完成后停下来等待反馈。 4. 每个子任务完成后请主动说明你做了什么、改了哪些文件、验证了什么。 5. 如果你发现方案存在坑或有更优解请直接指出而不是蒙头执行。这个模板的价值在于它把一次性的大对话变成了多轮的小协作。AI 不再是一个“话痨生成器”更像一个“有任务边界、会汇报进度的协作者”。我强烈建议你把这个模板存成全局斜杠命令任何项目都能用。4.4 关于人工审阅的聚焦建议很多朋友问过我一个问题既然 AI 都能跑了人工还要看什么我的经验是人工看得不是代码本身而是确认三件事需求理解对不对、边界覆盖全不全、改动面是否最小。这三件事恰好是 AI 在现有技术条件下的短板。需求理解方面AI 容易把“导出 CSV”理解成“把当前表格内容导出”但产品真正要的可能是“根据筛选条件导出全部匹配数据”。边界覆盖方面AI 倾向于处理正常路径对异常路径要么草草带过要么写一堆防御代码。改动面控制方面AI 有时为了达成目标会顺手重构它觉得不顺眼的旧代码这其实是工程上的大忌。每回人工走查时把这三件事放在最前面效率会高很多。5. 常见问题与排查实录5.1 规则“不生效”怎么办最常遇到的问题就是明明写了规则文件AI 还是我行我素。我自己排查下来原因通常是三种一是规则文件放错了位置项目级规则必须放在项目根目录而且文件名要完全正确二是规则内容跟对话里的即时指令冲突而即时指令的优先级更高如果你在对话里又说“别管规则直接给我答案”那 AI 自然会顺从后续指令三是规则写得太长或太抽象模型没能有效提取约束。解决办法也很直接。先确认文件路径和名称再检查规则里的每一条是否具体可执行。如果都没问题但依然不生效就把最关键的一条规则直接复制到当前对话里强制它先确认收到。一个小技巧是新改完规则文件后最好新开一个对话旧对话里的上下文不会自动加载最新的规则。5.2 AI 改完的代码无法通过编译这类问题的根源通常是 AI 没见过完整项目上下文尤其是依赖关系比较复杂时。报错信息里经常出现“找不到模块”或“类型不存在”之类的提示。以前我的做法是自己去修后来改成把报错信息原样贴回给 AI让它自己追踪问题、给修复方案。这里有个关键细节不要只贴最后一两行报错要贴完整日志最好带上相关文件片段。AI 从完整日志里判断原因的准确率比只看摘要高出一大截。顺着这个思路我后来干脆把“编译检查”写进任务必做清单每次任务收尾时让 AI 先跑一遍检查再交付这类问题就少了很多。5.3 不同会话之间“失忆”如果不做额外处理每次新开对话AI 都不记得上一个对话发生了什么。这在多文件、多轮次的大功能开发中会很折磨人上一轮刚确认的决策下一轮它可能又跑偏。我的经验是把关键决策固化到文件里。比如规则文件、设计说明文档、改动清单这些都应该以文件形式存在于项目中。新对话开始后先让 AI 去读这些文件再开始工作。这相当于给 AI 建了一个“外部记忆库”效果很好。另外遇到跨大量文件的改动时我会考虑把所有相关任务放在同一个对话里完成减少中断传导的损失。5.4 快速排查速查表下面这张表是我自己贴在笔记里的小抄遇到问题先对着找一遍多数情况能快速定位症状常见原因处理办法AI 无视我在规则里强调的约束规则与即时指令冲突或规则太长太抽象精简规则强调关键约束新开对话测试生成代码风格和项目不一致上下文里缺失风格示例在规则文件里附一段本项目的典型代码片段修改涉及多个文件时前后矛盾任务粒度过大AI 上下文负担过重拆成多个子任务逐个确认经常生成不存在的接口或依赖模型记忆的 API 版本过时明确要求它先查项目里的真实定义不许凭印象生成MCP 工具无法使用配置路径、环境变量或命令名称问题重新读取服务日志检查 .mcp.json 与工具名拼写5.5 一点关于预期管理的体会最后说点个人体会。把 Cursor “外挂”配齐之后并不是说你就可以躺平了而是你的工作重心从“逐行写代码”变成了“定义标准、控制流程、审查边界”。我自己的时间里写代码的比例反而下降了思考设计和把关质量的比例明显上升。这个转变对个人心态也有影响以前看到 AI 产出垃圾代码会烦躁现在我会习惯性地想是不是我的输入还不够具体哪条规则没覆盖到。这种把问题归因于“系统设计”而不是“工具垃圾”的思路是我觉得用好 AI 编程工具最重要的心态转变。工具只是工具规则、上下文、工具链、反馈机制这些才决定它在你手里到底是一个“打字辅助”还是一个真正能分担生产任务的协作者。如果你也想给自己的 Cursor 装一套趁手的配置我的建议是从规则文件开始再到斜杠命令最后尝试 MCP 工具链循序渐进。不要一上来就追求一步到位否则只会给自己徒增配置负担。先把一小块流程跑顺再慢慢扩展你会发现 AI 干的活慢慢就不再鸡肋了。