PStack 是我自己维护了大半年的一套全栈技术栈模板从后端 API 定义、数据库表结构到前端页面骨架和部署脚本全部拢在一个仓库里。这半年里对我开发方式改变最大的事情就是把 Cursor 从一个偶尔问问题的外挂工具变成了真正的主力编辑器。标题里写我怎么用 Cursor其实不是介绍功能而是想聊聊在 PStack 这种跨端项目里我踩过的坑、试出来的组合拳以及哪些做法纯属自己骗自己。这篇内容适合两类人一是已经在用 AI 编辑器、但总觉得生成的代码能跑但不是我的风格的开发者二是正准备把 AI 工具真正接入日常工作流、又不想把项目搞成一团乱麻的人。我会拆着讲我自己在 PStack 上的使用习惯不是通用教程但大部分经验换个项目也能直接用。1. PStack 是个什么项目为什么非得用 AI 编辑器不可1.1 PStack 的定位与核心痛点PStack 最初只是个我私用的脚手架目标很朴素让我从零开始做一个小产品时不用每次重新纠结目录结构、请求封装、错误处理、部署配置这些东西。后来越用越顺手索性把它整理成了一套公开可复用的技术栈模板。它的典型形态是前端用组件化框架搭管理后台后端提供 REST 接口数据库层用 ORM 管理表结构配上统一的类型定义和构建脚本。听起来不复杂但这类项目有一个隐蔽的痛点代码量不大一致性要求却极高。比如前端请求函数、后端路由参数、数据库字段命名三处的命名和类型必须对齐再比如新增一个业务模块常常要同时改路由注册、接口文档、前端 API 封装、表单校验规则循环往复。人写这种代码最大的问题是烦一烦就容易复制粘贴。而复制粘贴恰好是技术债的来源。PStack 这套项目尤其怕这个因为它的价值就在于规范两个字。如果内部都开始不一致模板本身就废了。所以我很早就意识到效率瓶颈不在敲键盘的速度而在怎么又快又不出错地完成这种跨文件的一致性改动。Cursor 这种工具的价值恰好落在这里它能同时感知多个文件的上下文然后做跨文件的协同修改。别的编辑器加 AI 插件也能做到但后文会细说为什么最后留下的是它。1.2 我对比过的工具为什么最终选了 Cursor在把 Cursor 转正之前我确实认真试过几条路线。先说结论不是其他工具不行而是 Cursor 在当前阶段最贴合 PStack 的痛点。路线一是传统编辑器加 AI 补全插件。这类插件在单文件内补全很强写函数、写样式、写重复性模板都跟得上。但一旦任务变成把后端某个接口改名然后同步所有调用点它基本帮不上忙因为你还是要自己靠全局搜索跳来跳去。PStack 恰恰有一堆这种改动所以补全型工具的边际效益对我并不高。路线二是通用聊天式 AI把代码贴进去问问题。这个适合这段代码哪里错了帮我解释一下这个逻辑的场景是个好老师但不是一个合格的同事。它不能主动打开你的项目结构不能把改动直接落到不同的文件里得靠你手动搬运结果中间只要漏掉一个文件就会翻车。Cursor 和这两类的核心差异有两个。第一它给编辑器内置了完整代码库的索引能力。你说一句话它能自己去找到相关文件而不是只盯着你当前打开的这个。第二它的 Agent 模式能自己规划多步操作——先改 A 文件再改 B 文件再跑测试最后把结果汇总给你中途你只需要审批关键动作。这个体验非常接近雇了个初级工程师在旁边干活。当然我也要说明它不适合谁。如果你只想要更好的自动补全完全没必要换编辑器你现有工具加个插件就挺好。Cursor 的真正优势是一次性处理跨文件的整块任务所以项目越像 PStack 这种多端、多文件、多约束的结构它越划算。1.3 PStack 里哪些工作量被 Cursor 真正消化掉了具体说一下分配到日常迭代里的体感。有几个场景我个人统计过之前平均半天的工作现在基本压到一两个小时。第一是新增模块。比如前后端各加一个定时任务功能原来我要手动建后端路由文件、注册路由、写数据库迁移、建前端页面目录、补菜单配置、加接口封装可能在六个文件里来回切。现在让 Cursor 基于已有模块当作参考一次性生成一套结构相同的模块我再逐个检查改差异。大多数情况它生成出来的骨架是能直接跑起来的。第二是重构命名。有一次我想把 PStack 里的task统一改成scheduledJob。表面上是字符串替换实际牵涉变量名、接口路径、数据库字段映射和注释。用全局替换不现实少了人肉检查就是事故。用 Cursor 做重构它能跟着语义走顺带把相关测试断言也改了最后我只需要跑测试确认。第三是补测试。老实说我以前写单测的动力很差。但 Cursor 对 PStack 里已有的测试文件理解得不错让它照着一个已有测试文件写一个新的结构基本一致我要做的是把断言改对。这一点彻底改变了我的测试意愿后续章节会细讲。2. 我目前在 PStack 上的 Cursor 工作流2.1 最关键的起步动作先把规则说清楚很多人拿 Cursor 写代码、说不好用最大的原因其实是没告诉它你的项目规则。Cursor 虽然能读代码但它不知道你的偏好注释要中文还是英文、缩进几个空格、接口返回格式固定是什么、测试文件该放哪、哪些目录不许改。这些信息你不说它就只能靠猜猜出来的代码当然不合你意。我的做法是在项目根目录维护一套规则文件新版 Cursor 支持把规则放进项目统一管理内容分成两层。第一层是硬性约束比如禁止修改公共导出接口的签名所有新增业务方法必须写对应的单元测试前端代码不得直接使用后端返回的原始字段必须经过 DTO 映射。这些是 PStack 的核心契约违反了项目就失去意义。第二层是风格偏好比如注释简洁不为简单代码注释新目录优先建在 modules 下而不是顶层文件名用 camelCase 还是 kebab-case 必须一致。这套规则文件有几点要注意。一是别写得像散文要像检查清单一条一条能判断对错。Cursor 对禁止必须这种词理解最好模糊的形容词像尽量合理作用很小。二是规则要随项目演进每次 Cursor 反复犯同一个错我就把对应规则补进去相当于把这个初级工程师的入职培训越做越完善。三是规则文件本身也要做版本管理因为它和代码一样是有价值的项目资产。2.2 Agent 模式的正确用法从替我写到替我办Cursor 补全和对话用的模型都能写代码但真正拉开效率差距的是 Agent 模式。它的特点是可以自己列计划、连续操作多个文件、运行命令然后把变更呈现在 Diff 里让你审查。我在 PStack 里对 Agent 任务有个固定流程。第一步先给它一个明确且范围可控的指令比如参照 modules/user 的实现新增一个 modules/task包含后端路由注册和前端管理页面并补充路由配置。这里的关键是参照给它一个明确模板比描述要符合项目规范高效得多。第二步允许它先做但不允许直接合入所有变更必须以 Diff 形式出来我点开看关键文件。第三步让它自己跑测试。现在的新版本支持自动执行命令、收集输出并自我修正这一步确定性高我不自己跑就等于放弃了最后一道质检。用 Agent 的时候我踩过最大的坑是给它的任务太宏大。有一次我让它把 PStack 的部署流程从 Docker Compose 迁移至 Kubernetes结果它列了一个非常长的计划改了十几个文件最后测试失败整个变更直接推翻重来。后来我学会拆任务一次只让 Agent 完成一个逻辑闭环比如先只做配置文件的迁移再单独做启动脚本的适配最后做文档更新。每一个闭环都能独立验证出了问题定位起来也是清晰的。2.3 上下文管理别把底牌一次打光Cursor 对项目的理解依赖索引但具体到某次对话任务它能看到的信息并没有一些人想象得那么多。如果文件太多、上下文过长它就可能漏掉某个关键文件然后给出看起来合理但实际不接线的方案。我的经验是每次任务前刻意收敛范围。与其说帮我看看整个 PStack 的前端代码有什么问题不如说打开 src/api 目录下的请求封装文件检查其中的错误处理是否与后端 errors 中间件的返回格式一致。前一种说法的上下文太散结果往往是泛泛而谈后一种给了它明确的目标文件它给出的判断才真正有用。同时我尽量不让一个对话无限加长。每次完成一个完整的改动就开启新对话把任务背景用一两句话重新交代。有过一次经历我在一个长会话里让它连续改了三四个模块到后面明显感觉判断在退化问它前面的改动它的回答口径都不一致。这种状态下的输出需要大量返工反而不如开新对话、带足摘要来得快。3. 让 Cursor 产出可维护代码的实操细节3.1 给示例比给形容词管用一百倍这个是我想重点强调的经验。很多人描述需求时特别爱用形容词写一个优雅的错误处理做一下合理的模块划分。这类描述对人是友好的因为人会脑补但对模型形容词其实是很弱的约束。我在 PStack 里总结出了一个最有效的模板四个部分。一是目标用一句话描述要做什么。二是参考明确指定一个已有文件作为风格模板比如参照 xxx.ts 的写法。三是边界说清楚哪些不能动比如不要改动公共类型定义不要引入新的依赖库。四是验证方式比如跑 apps/server 目录下的测试并保证通过。举个例子。要新增一个列表查询接口我不会说帮我写一个列表接口注意分页和筛选而是给它一个完整任务描述参照 user 模块的 list 接口实现在 task 模块新增一个获取任务列表的接口入参包含 page/pageSize 和 status 筛选返回结构保持统一格式最后补充该接口对应的单测。这个描述里没有难懂的专业词汇没有抽象要求模型给出的结果与预期几乎一一对应。3.2 拆任务的标准每个任务必须能独立验证这可以说是 Cursor 使用中最重要的一条原则。我在 PStack 上总结就是任务要小到出错了能一眼看出来。之前我写过一段体验很差的经历就是让它一口气把整个权限系统改掉。它改了接口、前端路由、菜单和数据库种子数据结果登录直接进不去我光定位问题就花了一个晚上最后只能回滚。所以现在我的做法是先用人的脑子把项目拆成可验证的功能切片再逐个丢给 Cursor。比如改权限系统我会拆成数据库表结构调整与迁移脚本、后端鉴权中间件更新、前端路由守卫更新、菜单渲染逻辑调整四个切片依次完成。每个切片结束后都跑一次相关测试或者手动验证确认没破坏其他部分再开启下一个切片。这个习惯还有一个好处Diff 审查的压力小很多。一次只看一两个文件的变动注意力不会被十几个文件的大 Diff 拉扯。从长期看代码质量其实不完全依赖模型的能力而是依赖使用者的拆解能力。AI 只是执行者架构设计还是自己的事。3.3 先让它写方案再让它动手这招是我从一次失败里学出来的。早先我拿到一个功能需求就直接让 Cursor 改它改得很快但经常出现一种情况它在动手时选了一个我不认可的实现路线。比如我要的是前端拦截请求后做统一错误提示它实现成了每个页面单独处理逻辑没错但架构上违背了 PStack 的约定。返工成本比从头写还高。之后我要求自己任何超过半小时的改动就先让 Cursor 出一份简短的实现方案包含它会改哪些文件、每个文件的改动点、潜在风险。这份方案其实相当于一个执行大纲我审过之后才允许它动手。这个过程有两个附加收益。第一方案阶段能暴露理解偏差。模型对需求存在误解时方案里会体现出来这比等代码写完了再发现要省事得多。第二方案可以作为测试依据。在它动手之前我就已经知道验收标准等它改完我可以对照方案逐个检查不用凭感觉看。3.4 测试先行把 AI 的兴奋剂关进笼子里AI 写代码有个特点它能很快地给你看起来能跑的代码。问题就出在看起来这三个字。尤其当一段代码只在小范围数据上验证过很多边界情况根本没覆盖到等上到真实场景就会暴露。我的应对方法非常简单粗暴先写测试再写实现然后让 Cursor 看着测试把代码改到通过为止。这其实就是 TDD 的思路但在 Cursor 场景下会顺畅很多因为它不介意反复修改。具体流程是这样给一个功能点我先让 Cursor 按我描述的接口契约生成测试用例。这里只需要描述输入输出和异常场景不用写实现。然后运行测试自然是红的。接着让它根据测试补全实现目标只有一个让测试变绿。最后再人工审查一遍实现代码因为测试全过不代表设计合理还是要确保实现确实遵循了项目规范。这套流程说实话让每个功能的耗时变长了一些但质量稳定性提升非常明显。PStack 的定位是模板项目它的代码会被别人拿去做基座如果基座里的逻辑都不稳后面所有借它起步的项目都会继承问题。所以这一步我认为值得。4. 实测踩坑记录与排查思路4.1 自作聪明的全量重构陷阱先说我翻过最严重的一次车让 Cursor 批量修正某一类 API 调用方式的错误。它完全没有只修改目标函数而是把多个模块里看似相关、实则不同语义的调用也一并改了。测试突然冒出来十几个失败回滚之后我逐个 diff 才发现问题出在我给的指令范围就没界定清楚。原因其实在我我用了一句统一修改所有调用点但所有这两个字对 AI 来说太开放了。它自己判断哪些算调用点判断标准和我并不完全一致。它的目标是把任务完成得看起来漂亮而不是保守地不碰不该碰的代码。之后我加了一条铁律凡是批量改动必须先让它列出将修改的文件清单我人工勾选确认后再执行。这个动作看起来多了一步但省下的返工时间是以小时计的。而且 Cursor 的 Diff 与文件树是联动的确认清单其实很快。4.2 索引过期与实际代码不一致Cursor 是依赖代码索引的但索引不是总是实时的尤其是你通过外部工具改文件、或者切换分支很频繁的时候。我有一次经历刚切了个分支让 Cursor 看一个文件里的函数定义它描述的还是另一个分支的旧签名。我当时还以为是模型推理能力的问题后来发现是指数没有更新。排查方法也很简单在对话里引用文件时观察它回答的细节是否与当前编辑器里打开的文件一致。一旦发现它说出的代码和你看到的不同就别继续对话了先刷新索引。Cursor 也提供了索引管理入口可以手动触发全量重建。频繁切分支的开发者建议定期重建尤其是当你发现它明明代码在那里却说找不到的时候。这类问题不算模型的智商问题是工具链使用上的盲区知道了就很好规避。我现在养成的习惯是切分支后、开新任务前先花几秒钟确认索引状态这个成本几乎可以忽略。4.3 幻觉代码的三种识别信号AI 偶尔会凭空回忆出不存在的接口或依赖。在 PStack 这种真实项目里幻觉代码的直接后果就是编译失败或运行时报错。我总结了三个比较高频的信号。第一种引用了不存在的依赖。比如它给你写了一个 import但 package.json 里根本没有这个库。第二种调用了一个项目中不存在的函数或方法。常见于它仿照某种常见库的 API 写但实际项目里的封装是另一套。第三种参数顺序和真实签名不一致很多时候是它记忆的框架 API 版本和项目里装的版本不同。应对思路就一句话凡是编译器和测试说有错的地方不要还赖着跟它理论。直接看真实代码、查真实依赖以项目里的实际定义为准。我见过有人花很长时间跟 AI 反复论证一个它记错的 API这在我看来是纯纯的浪费。代码库就是真相AI 写错了改就是了。4.4 多文件改动误伤后的恢复策略Cursor 做多文件改动时除了性能开销需要等待之外最要命的还是误伤。它可能为了一个小改动顺带优化了某个不相关的函数或者把格式调整得和原风格不一致。如果这些改动混在一个大 Diff 里你很可能注意不到。我现在用的是三层防护。第一层改动前在规则里声明不可触碰的文件范围比如生成的迁移文件、公共类型文件等敏感区域明确写出除非特别要求不要修改这些文件。第二层每次审批前逐文件过 Diff凡是和任务无关的改动一律撤销。Cursor 的 Diff 视图支持单文件丢弃没必要整体回滚。第三层提交前跑全量测试。PStack 的测试覆盖率虽然不是百分百但核心链路都有覆盖能兜底大部分误伤。这套防护做完之后我基本没再遇到过改完功能发现某个老功能悄悄挂了的事。偶尔有漏网之鱼凭借测试也能快速定位。5. 一些只有长期用才会注意到的体会5.1 Cursor 的风格学习能力是被低估的大多数人在意的是 Cursor 能不能准确执行指令但我觉得它真正值钱的是在长期工作中形成的风格一致性。这一点在小项目上体现不明显PStack 这种有固定规范的模板项目里就非常有体感。规则文件和项目代码其实是在共同给它做示范什么样的函数应该放在哪、错误处理走什么流程、测试文件怎么写。本质上代码库本身就是最好的提示词。当项目规范足够清晰、示例足够丰富时Cursor 生成的代码会越来越接近我亲手写出来的样子。以前有新模块要加时我还要逐行调整风格现在大部分时候检查一下逻辑和边界条件就行。所以我的建议是如果你觉得 Cursor 生成的代码总是不合心意先别急着换工具可以看看自己的项目里是不是缺乏清晰的范式。模板和范例本身就是你投入给 AI 的训练数据这个投入的回报是复利式的。5.2 AI 并没有取代设计工作只是加速了执行坦率讲用了这么久 Cursor我反而更确定一件事项目里的架构决策、模块边界、数据流设计这些工作没有任何被替代的迹象。Cursor 帮我省掉的是大量的转录、对齐、搬运工作但它没法告诉我 PStack 的权限模型应该怎么设计、任务模块和用户模块之间应该保持什么样的耦合度。从这个角度看与其说 Cursor 是个自动写代码的工具不如说它是个放大执行力的工具。你给它一个清晰的边界和任务它能快速给出高质量结果你自己的想法是模糊的那它的输出也必然是模糊的有时候看起来很好改但实际要改的东西比重新写还多。我现在的日常是一小部分时间做规划和拆解大部分代码执行交给 Cursor最后再花时间做认真的代码审查。这个手感有点像带实习生写代码你敢放权是因为你清楚验收标准而不是因为 AI 不会犯错误。5.3 建议从一个小模块开始切到 Cursor如果你还没把 Cursor 作为主力编辑器我的建议不是全面替换或者只用它做辅助而是选一个小模块完整地走一遍需求、方案、编码、测试、审查。只有当一个小功能整个流程走通你才会理解它的工作方式和那些细节规则为什么重要。我自己就是这么过来的。PStack 里第一个完全由 Cursor 主导的模块是一个简单的配置管理页从后端 CRUD 到前端表单再到测试全流程它都参与了。那个模块现在回头看没什么特别的但它让我摸清楚了该怎么提问、怎么给约束、怎么验收。这个能力阈值跨过之后后续的功能开发体验就完全不一样了。归根结底工具好不好用真的取决于用的人。Cursor 给了你一个能干活的助手但你能不能让它干得符合你的标准取决于你怎么描述任务、怎么设边界、怎么验收成果。这些能力是练出来的不是装个编辑器就自动有的。