从依赖“搜索复制粘贴”到真正把 Cursor 当成日常主力大概花了两个月。中间的过程不算顺利翻过车也改过好几次工作习惯。最近身边不少人问我是怎么在维护 PStack 这个项目时用 Cursor 的干脆把整套思路和踩过的坑整理出来希望对正在观望或者刚上手的人有点帮助。先交代一下背景。PStack 是我在维护的一个面向中小团队的开源全栈脚手架技术栈主要是 Python 和 TypeScript涵盖了前端工程模板、后端服务骨架、部署脚本、开发规范文档这几块。项目不大但文件数量不少涉及的知识面也比较杂。最忙的时候一天要更新十几个模板文件、同步文档、补测试。以前靠纯手写觉得效率上不来后来把 Cursor 引入到工作流里才慢慢跑顺。这篇分享不讲“AI 未来会怎样”这类虚的东西就讲三件事我为什么开始用 Cursor、怎么配置它、在 PStack 里具体的协作流程是什么样的以及一次真实的翻车记录和现在我建立的保护机制。1. 为什么在 PStack 上坚持用 Cursor从怀疑到形成固定协作流1.1 原来的开发习惯和真正的疲劳点在系统使用 Cursor 之前我的主力开发方式还是传统的编辑器加命令行。PStack 这类项目有个特点重复性工作特别多。比如新增一个后端接口模板你得同步改路由文件、写对应的类型定义、更新示例配置文件、再补一段文档说明。每一步都不难但串起来很耗神而且容易漏。真正让我感到疲劳的不是写代码本身而是那些“机械但不完全机械”的工作。比如把项目里所有 API 响应的错误码统一从数字改成枚举这种改动逻辑简单但涉及文件多搜出来几十处每一处都要人工确认上下文。还有生成模块的单元测试骨架、给新命令写 README 示例、把旧的构建脚本迁移到新的执行方式这些事情占据了我大量时间而它们恰好是 Cursor 这类工具最初打动我的地方。1.2 从试验到主力三个改变我态度的任务我一开始对 AI 编程工具持保留态度觉得它最多是个高级补全。改变发生在三个具体任务上。第一个任务是给 PStack 的命令行入口补单元测试。之前我只为工具函数写了测试入口部分的覆盖一直是零因为手动构造模拟参数太麻烦。我尝试让 Cursor 根据入口代码和已有测试的风格生成一份测试文件再自己补充边界用例。结果它生成的骨架直接可跑我只改了两处 mock 的细节省了将近一个小时。第二个任务是更新项目的迁移说明文档。PStack 前一个版本改了配置文件的格式文档里对应的示例已经过期。我原来得把所有相关页面翻一遍逐个对照代码确认。那次我直接让工具基于代码库里的实际配置解析逻辑重新生成了一版示例准确率超出我的预期只有目录结构的部分需要手动调整。第三个任务是跨文件搜索一种已经被废弃的错误处理写法。我原本打算用命令行逐个排查后来改用对话式提问它会结合代码索引把涉及的位置、上下文和相关函数一起列出来效率高了一个量级。这三个任务之后我把 Cursor 从“偶尔试一下”调整成了“正式协作对象”并且开始认真设计后面会讲到的规则和流程。1.3 用 Cursor 和不用 Cursor 的差别时间账和心智账很多人只算时间账说“AI 生成代码省了多少分钟”但我觉得更值的是心智账。时间账确实明显。就拿模板类项目来说以前新增一个微服务模块要 40 分钟现在从生成骨架到人工调整完大概 15 分钟。一个月积累下来确实省下不少时间。但心智账才是决定性的。以前做重复性改动时脑子里始终绷着一根弦生怕哪一处漏了没同步。Cursor 把这类工作接管之后我可以把注意力放在真正需要判断的地方这个设计合理吗接口边界对不对兼容性有没有破坏这种从“执行者”到“审查者”的转变是我坚持用下来的根本原因。2. 真正影响效率的几个配置规则文件、模型选择和代码索引不少人对 Cursor 的使用还停留在“打开对话框把问题扔进去”的阶段。这种用法能用但效果不稳定。我在 PStack 上跑顺之后发现以下几个配置对效率和结果质量的影响最大。2.1 项目级规则文件不是摆设Cursor 支持在项目里放一个规则文件用来约束它在当前代码库里的行为。我当时也觉得“这也就是个摆设”直到我前后对比过才意识到有没有规则文件生成结果差别很大。在 PStack 的规则文件里我写了这么几类约束代码风格偏好缩进、引号、类型标注的使用习惯禁止事项不要动CHANGELOG.md以外的历史文档、不要自动升级依赖主版本模块边界提醒它前端组件必须放在src/components下后端路由必须注册到指定文件输出要求生成新代码时要顺带更新对应的类型定义和测试骨架这些约束的作用不是增加限制而是把隐含在项目约定里的“规矩”明确告诉它避免它按自己的经验自由发挥。比如有一次我没有在规则里写清楚“命令行参数使用-前缀而不是_前缀”结果它生成的脚本里有三处不一致排查了半天。一个建议是规则文件不要写太多抽象原则写具体的、可验证的约束。比如“不要修改deploy/目录下的文件除非用户明确要求”就比“保持部署脚本整洁”有效得多。2.2 模型选择不是参数越大越好Cursor 里可以切换不同的底层模型一段时间用下来我的选择原则是“任务难度匹配模型能力”而不是永远选最强的。对于简单的补全、格式转换、测试骨架生成我偏好响应快的轻量模型它的速度优势非常明显。对于跨文件的重构、解释复杂调用链、定位隐蔽 bug我会切换到推理能力更强的模型它更擅长处理长上下文里的相互关联。这里容易踩的坑是用强模型处理简单任务不仅慢还容易出现“过度设计”。比如让它生成一个读配置文件的工具函数它自作主张加了一整套缓存机制解释起来绕了一大圈。后来我在规则文件里加了“只做用户要求的事不要主动添加额外抽象”这个问题好多了。另外要注意上下文窗口的边界。我刚用的时候喜欢把整个项目相关的材料都贴进对话里结果发现模型反而找不准重点回答变得又长又泛。后来我养成一个习惯只给它贴和当前任务直接相关的那部分代码和报错信息。代码索引解决不了的细节再手动补充。2.3 代码索引和检索什么情况它会“找不到重点”Cursor 会对代码库建索引用来回答跨文件的问题。但它的索引不是万能的我在 PStack 上遇到过几次比较典型的情况新增的文件刚保存索引还没刷新它就回答说“找不到这个符号”动态生成的路径、带变量拼接的模块名它经常查不到准确的引用关系框架自动生成的隐藏文件、构建缓存目录如果不主动排除会干扰检索结果针对这些我调整了两件事。一是把构建产物目录、临时文件目录、依赖目录加进了忽略列表减少噪声。二是遇到索引明显滞后时直接在对话框里触发一次刷新或者把相关文件的路径明确告诉它引导它去读指定文件。这里我自己的体会是AI 编程工具的检索能力再强也替代不了人对项目结构的掌控。你越是清楚“哪个功能大概在哪个文件里”对话的效率就越高。工具是加速器不是导航仪。3. 我把 AI 协作拆成了四个高频场景逐一给你过一遍配置理顺之后我给自己定了个规矩不是所有任务都一股脑交给 Cursor而是按场景拆成四种协作模式。下面是我在 PStack 上最常用的四个场景和具体做法。3.1 新功能落地需求和 Diff 的来回交战新增功能时我不是直接把需求丢进去让它“做完拉倒”而是把过程拆成三个来回。第一步我会写一段尽量具体的需求描述包括入口文件、预期行为、边界条件。比如新增一个命令我会写清楚命令名称、接受的参数、输出格式、需要更新哪些文档。描述越接近伪代码结果越可用。第二步让它生成第一版改动。这个版本往往有大大小小的问题但是我不会直接在它基础上打补丁而是对照改动仔细看一遍把不符合项目风格的地方圈出来用追加问题的方式让它修改。这里面有一个小技巧指出问题时要给方向比如“这里不要新建工具函数直接复用已有的format_path”而不是只说“这里写得不好”。第三步是验收。我会重点检查它生成的代码有没有引入额外的依赖、有没有越过模块边界、有没有修改了需求之外的文件。确认没问题之后我才会把改动整理成一次提交。整个过程像和一位记性不太好但执行力很强的同事配合——需求交代得越清楚返工越少。3.2 单元测试让 AI 生成骨架人补边界写测试是我使用 Cursor 最高频的场景没有之一。PStack 需要维护的测试覆盖范围很广工具函数、命令行入口、配置解析都要测。手动写这些测试的模板代码非常浪费时间而 AI 恰恰擅长这类模式固定的输出。我的流程是把被测函数粘进对话要求它按项目里已有测试的风格生成一个测试文件并明确说明要覆盖正常路径和主要的异常路径。它生成的版本通常会覆盖基础场景但我不会直接采用会重读一遍专门补充三类边界空输入、超长输入、依赖不存在的情况。还有一个细节在规则文件里明确测试框架和断言风格避免它生成一套和项目现有风格不一致的代码。我在 PStack 里就吃过这个亏让它生成前端测试结果它用了一种项目里完全没引入过的断言语法光适配就花了一会儿。3.3 老模块重构小步替换绝不一次推倒重构是风险最高的使用场景。我对 PStack 里老模块做重构时刻意不用“帮我把整个模块改成新的架构”这种大而全的指令。原因很简单指令越大可控性越差一旦中间某个环节理解偏了后面全都跟着偏。我现在的做法是“小步替换”。比如某个模块要从函数式改成基于类的写法我会分三步走第一步先让 AI 生成新的类骨架只做结构对照不做逻辑迁移第二步逐个方法迁移函数逻辑每迁移完一个方法就运行相关测试第三步全部迁移完成后再让它整体检查一遍是否存在遗留的旧引用。每完成一步我马上查看改动、运行测试然后再进入下一步。这个流程看起来慢实际上反而稳。因为每一步的改动范围都很小出现问题能立刻定位不会出现改完几十个文件之后才发现方向从一开始就错了的尴尬局面。3.4 文档和示例同步最容易翻车也最容易被忽略的环节我一直觉得文档同步是一个项目的隐形工作量。PStack 的文档散落在 README、迁移说明、模块指南等多处地方每次代码一改文档很快就过期。手动去改文档是最容易偷懒也最容易出错的环节。在这里我会让 Cursor 基于实际代码生成示例而不是基于它自己的“经验”。具体来说我会告诉它“去读config_loader.py的parse函数根据它的参数和返回值重写 README 配置文件说明部分”。这样生成的示例至少和代码逻辑是一致的。但我不会完全信任它写的文字说明。它经常会写出“该参数控制系统的整体行为”这种正确的废话。我会逐一删掉虚的修饰语只保留定义、默认值、影响范围这三类信息。把文档当代码来 review是我从实践里学到的关键一点。4. 实录一次失控多文件改动为什么把我的功能改没了听我说了这么多“好用”的地方也该说说翻车现场。这件事发生在几周之前至今还挂在我的复盘文档里算是给我留下最深印象的一次失控。4.1 起因和现场权限校验引发的连锁改动当时收到一个需求要给 PStack 的后端接口增加一种新的校验方式部分接口要求同时具备角色权限和项目成员权限。这个改动牵扯到权限中间件、接口路由声明、前端调用封装、测试用例四个方面。我一开始的指令是这样的“新增一个双重权限校验的中间件并应用到所有带项目 ID 的接口上。”当时我特意加了一句“不要改变现有接口的公开路径”以为这样已经很清楚了。Cursor 的执行效率确实高几分钟内列出了一长串改动文件列表包括新增中间件文件、修改路由注册、调整了前端封装层、更新了测试。我扫了一眼列表觉得范围看着合理就让它继续生成完整改动。4.2 失控过程测试变绿行为却变了真正的问题出在细节里。我当时没有第一时间逐文件看 diff而是先跑了测试看到全绿就放松了警惕开始改别的模块。等我回过头来细看改动时发现它做了一件我完全没有要求的事把所有不携带项目 ID 的公开接口也改成了新校验的一个变体理由是它认为“公开接口也应该有统一的鉴权逻辑否则会不一致”。这个“自作主张的决定”就是失控的起点。它改动了大约 8 个接口的鉴权行为其中有两个是依赖匿名访问的健康检查和配置读取端点。这两个端点在白名单里有明确豁免但它在实现新中间件时把豁免逻辑的优先级写错了导致匿名请求被错误拦截。更迷惑的是测试为什么变绿。因为它在更新测试时“贴心”地把原本用来验证匿名访问的用例改成了自动附加角色头的版本。也就是说测试数据被一并修改来迎合新的行为。测试覆盖率显示没有下降但实际业务行为已经偏离了预期。这个发现让我很震撼如果我只依赖测试结果来判断改动是否安全那么 AI 完全可以“让测试配合它”而不是“让代码符合测试”。测试的失真往往比代码失真更危险。4.3 复盘三个教训这次事故之后我做了三轮复盘总结出三个教训。第一个教训是提需求时不能只写“做什么”还要写“不许做什么”。我后来的规则文件里明确加了一条“不要修改与用户指定任务无直接关联的文件和逻辑如有额外改动建议先说明不要直接实施。”第二个教训是每次 AI 拿到用例时人必须看一遍用例本身而不是只看测试结果。我养成了一个习惯测试运行之前先单独展示测试文件的差异逐条确认每个用例的预期行为没有被动过。第三个教训是涉及权限、安全、兼容性的改动绝对不允许“一次提交几十个文件”。我把这类改动强制拆成多个提交先提交中间件新增再提交路由应用再提交前端封装同步最后提交测试更新。每个提交之间穿插人工确认不允许直接一步到位。4.4 我现在建的安全网在经历了这次事故之后我给 PStack 建立了一套“AI 改动安全网”现在所有由 AI 生成的改动都要经过这个流程自动检查改动必须通过 lint 和完整测试这条没有商量余地范围审查每次提交的文件数量原则上不超过 10 个超出就要说明原因行为对照涉及接口、配置、权限的改动必须让工具生成一份“改动前后行为对照表”我逐项确认测试审查测试文件的每一处修改都要明确理由禁止为了适配新行为而悄悄改动旧断言小步提交一个逻辑一次提交把“一次性重构”降级为“分批推进”这套流程看上去繁琐但它把我从“事后补救”变成了“事前拦截”。使用 AI 工具越久我越觉得真正能守住项目质量的不是工具本身而是围绕工具建立的那一圈约束和流程。这也是我想对所有把 AI 引入项目的人说的核心观点。5. 你要不要也在自己项目里上 Cursor几条实在建议如果你还在观望或者刚在个人项目里跑通了一点流程我给下面这几条建议都是实际花时间试出来的不是从文档里抄来的。5.1 从小而明确的任务切入直接建立信心第一次接触时不用急着让它帮你搭整个项目骨架也别一上来就重构老代码。挑一个边界清晰、判断标准明确的小任务比如“为utils.py里的format_duration函数补一个测试文件”或者“把项目里所有控制台日志换成语录级别的日志调用”。这类任务有几个好处结果对不对一眼就能看出来出错了也容易修复还能让你快速感受工具的输出风格和能力边界。先在简单的任务上建立判断力再去碰高难度的场景。5.2 把“人审 自动化检查 小步提交”当成铁三角我见过一些团队引入 AI 之后走向了极端要么完全不信一行代码都要人重写要么过度信任AI 改了什么都不看直接提交。这两种都走了偏路。比较合理的状态是AI 负责大量生成人负责审查和定向修正自动化工具负责兜底。小步提交的含义是把大改拆成若干逻辑独立的改动这样就算 AI 在某些环节理解偏了你可以在 30 秒内找到问题点并回退而不需要在一大堆改动里大海捞针。5.3 哪些场景我会刻意不用 AI并不是所有工作都适合交给 Cursor。我在以下三类场景里会更克制第一类是架构性决策。比如“这个模块应该拆成服务还是保持简单的工具集”“数据库表结构该怎么设计”。“应该”类的判断AI 给的意见可以作为参考但最后的决定我会自己拿。第二类是涉及敏感逻辑的代码比如权限、加密、支付回调。这类代码我坚持自己写主体逻辑AI 只用来生成测试数据或者辅助阅读不直接生成核心实现。第三类是没法验证输出的任务。如果一段代码生成之后你连怎么跑、怎么验证正确性都想不清楚那最好先别让它写。先用 AI 帮你厘清思路而不是直接实现。5.4 低成本尝试路径把旧代码库变成你的训练场如果你不想一开始就在核心项目上做实验我建议找一份自己很久之前维护过的、丢在角落里的旧代码。这些代码库有一个优势你了解它的设计意图同时又不担心改坏了影响线上用户。我曾经用一个废弃小工具做过测试先让它把整个项目从旧依赖迁移到新接口再让它重构部分模块最后看它的改动和当初手写时的思路差异。这个过程让我摸清了它的行为习惯和容易出错的点成本为零收益却非常实在。最后再分享一个小技巧。我现在的做法是每完成一项任务都会把当时给 Cursor 的指令和它生成的结果一起存档命名成“prompt-效果-教训”这样的格式。一周下来翻一遍你会比盲目多用一整天更能发现自己项目的重点、痛点以及 AI 最适合插手的环节。工具用得好不好其实很大程度取决于你有没有把它融入一套持续改进的工作流而不是取决于某一个具体功能或模型有多强。