.NET 项目里怎么用 Cursor 提效？实战篇
接上篇《我用 Cursor 半年后，写代码的方式彻底变了》。这次只聊一件事：在 .NET 解决方案 里，怎么把 Cursor 用顺手，少踩坑、多省时间。
一、先给 Cursor「立规矩」：.cursorrules
.NET 项目通常有分层（Applications / Domain / Infrastructure）、命名和架构约定。把这些写进 .cursorrules，AI 生成的代码会更贴你的项目风格，少返工。
在解决方案根目录新建 .cursorrules，例如：
# 项目技术栈与规范
- 框架：.NET 6+，ASP.NET Core，C# 10+
- 架构：DDD 分层，Applications 调用 Domain，Domain 不依赖 Infrastructure
- 异步：对外接口统一 async Task / Task<T>，避免 async void
- 依赖注入：构造函数注入，接口与实现分离（IInvoiceService / InvoiceService）
- 命名：接口 I 前缀，DTO 以 Dto 结尾，领域实体与数据库模型区分
- 日志：使用项目现有 Log4NetFunc.LOGGER，不引入新日志库
- 不要使用已废弃的 API（如 .Result、.Wait）
这样在 Chat 或 Composer 里说「加一个根据订单号查询发票的接口」时，AI 会倾向于：在 Domain 加接口、在 Applications 写调用、用 async/await、符合你现有命名。
二、快速「读懂」大解决方案：@ 文件夹 + 一句话提问
刚接手一个 .NET 大 solution（几十个项目、N 个层）时，自己翻一遍很费时间。可以这样用 Cursor：
- 在 Chat 里 @ 整个仓库 或 @ 某个项目文件夹（如
Domain.Invoice）。 - 直接问：
- 「这个项目的分层结构是怎样的？Applications 和 Domain 分别负责什么？」
- 「发票申请单从创建到提交，主要经过哪几个类、哪几个方法？」
- 「IInvoiceService 和 InvoiceAppService 的职责边界是什么？」
AI 会基于当前代码结构总结出调用关系、入口方法，比从零看 sln 和命名空间快很多。适合入职接手老项目、做需求前先扫一遍。
三、加一个新接口：从接口到实现一条龙
典型需求：「加一个根据申请单号查询发票申请单详情的接口，返回 DTO，要异步。」
推荐做法：用 Composer（多文件编辑）
-
打开 Composer（或 Chat 里选择 Agent / 多文件）。
-
输入需求，并尽量写清约束，例如：
在发票模块加一个「根据申请单号查询发票申请单详情」的接口。
Domain 层：在 IInvoiceService 增加 GetByApplyNumberAsync(string applyNumber)，在 InvoiceService 里实现（先查申请单，再组装 DTO）。
Applications 层：在 IInvoiceAppService 和 InvoiceAppService 里增加对应方法，调用 Domain。
返回 DTO 用现有的 OrderInvoiceApplyDto 或类似的，没有的话新建一个，包含申请单号、状态、订单列表等必要字段。 -
一次让 AI 生成：接口定义、Domain 实现、Application 层封装、DTO（若需要）。生成后你重点做三件事：补业务校验、补日志、跑一遍接口。
注意：生成代码里若有仓储或 DbContext 的用法，要对照你们项目的 IRepository / 工作单元 再改一版，避免 AI 自己「发明」一套数据访问方式。
四、改 Bug：把报错和上下文一起喂给 Cursor
遇到运行时/编译错误时，不要只贴报错，把相关代码也带上，效率会高很多。
推荐话术：
- 「这段代码在 xxx 场景下报错：
NullReferenceException: Object reference not set to an instance of an object，堆栈指向 InvoiceAppService.CreateOrderInvoiceApply。相关代码在 @Applications.Invoice/InvoiceOrder/Impl/InvoiceAppService.cs 的 CreateOrderInvoiceApply 方法。请分析可能为 null 的地方并给出修改方案。」 - 或直接选中报错的那几行 + 调用栈，用 Ctrl+K Inline 问：「这里为什么会空引用？请加上 null 判断或改用可空类型。」
AI 会结合方法内逻辑（如 customerEmployee、orderInvoiceApplyDto.OrderInvoiceList 等）给出具体位置和改法，你只需做业务上的取舍（是提前 return 还是抛业务异常）。
五、批量重命名与简单重构
例如：「把方法名 CreateOrderInvoiceApply 改成 CreateInvoiceApply，并同步改掉所有调用处。」
- 在 Cursor 里用 Composer 或 Chat + @ 仓库，说明：
- 要重命名的方法/类/参数；
- 范围（整个解决方案 或 某个项目）。
- 让 AI 一次性改完定义 + 所有引用，然后你本地 全局搜索旧名字 再确认一遍，避免漏掉反射、配置、注释里的字符串。
对于「按规范重命名」类、接口、DTO 后缀等，同样可以写清规则后交给 AI 批量改，你再 Code Review 即可。
六、写单元测试：给定场景，让 AI 搭骨架
你们项目里若有 xUnit / NUnit + Moq，可以这样用 Cursor：
- @ 被测类（如
InvoiceAppService）和 @ 其依赖的接口（如IInvoiceService）。 - 说明：
- 「为 InvoiceAppService.CreateOrderInvoiceApply 写单元测试。正常流程：IInvoiceService 返回成功，校验通过；异常流程：校验失败时返回 errorResult，不调用 IInvoiceService.Create。用 Moq mock 依赖。」
AI 会生成 TestClass、Mock、若干 [Fact]，你补上具体断言和边界 case（如 null、空列表）即可。这样测试骨架和命名风格能快速统一。
七、查 API 和写注释：@Docs 与选中代码
- 官方/第三方 API：在 Chat 里用 @Docs（若已配置）或直接问「.NET 里 HttpClient 如何正确配合 IHttpClientFactory 使用？」「EF Core 6 的 ExecuteUpdate 用法」，让 AI 给出示例和注意点，再贴回项目里按你们规范改一版。
- 给老代码补注释：选中一段复杂逻辑（如状态机、多分支校验），用 Ctrl+K 问：「请为这段代码加 XML 注释，说明入参、返回值、主要分支和业务含义。」生成后你只改业务术语和敏感信息即可。
八、容易踩的坑（.NET 特有）
| 坑 | 建议 |
|---|---|
| AI 用 .Result / .Wait | 在 .cursorrules 里写明禁止，强调 async/await 全链路。 |
| 自己「造」仓储/DbContext | 要求 AI 只使用项目里已有的 IRepository、IUnitOfWork 等抽象。 |
| 泛型、反射、动态调用 | AI 容易写错，生成后重点看泛型参数、类型约束和运行时类型。 |
| 配置和选项类 | 如 IOptions<InvoiceOptions>，说明「按现有 Options 模式」再让 AI 生成。 |
九、小结：一套可复用的 .NET + Cursor 流程
- 项目根目录加 .cursorrules：技术栈、分层、命名、禁止用法写清楚。
- 读大项目：@ 文件夹 + 问「分层/流程/职责」，先建立整体图再细看。
- 加新功能：Composer 里描述「接口 + 实现 + 层」，一次生成多文件，再补业务与数据访问细节。
- 修 Bug：报错 + 堆栈 + @ 相关文件，让 AI 定位并给出改法。
- 重命名/重构：说明范围与规则，批量改完再全局搜一遍。
- 单测与注释：@ 被测类/依赖，给定场景生成骨架；用 Ctrl+K 给复杂逻辑补注释。
按这个流程，.NET 项目里的「读代码、加接口、改 Bug、写测试」都能明显提速；同时关键业务逻辑和架构决策仍在你手里，AI 只做执行和规范落地。
你所在团队用 Cursor 做 .NET 开发时，还有哪些好用技巧或坑？欢迎在评论区补充。
