用 Cursor 写了 3W 行后，对 AI 编程的几点心得

用了半年多 Cursor，最近刚用它速成了一个后端项目。虽然项目因为客观原因烂尾了，但7、8 天干了 3 万多行代码，整体过程还算游刃有余。趁着印象还新，想整理下这段时间的经验，分享给也在探索 AI 编程的朋友们。

起手式：没有规则，等于慢性自杀！

最早我也尝试过一些所谓的“开发规范”插件或者 riper-5 那类“魔法提示模版”。说实话，很多 rule 虽然看起来头头是道，但实际效果很有限 —— 花里胡哨，解决不了实际问题。

为什么？因为 AI 是按照你的指令写代码的，你不够清晰，它就会“自由发挥”；你不够专业，它就会劣化代码质量；等你意识到问题，可能已经到处都是烂代码，项目早已失控。(弄不好到三五万行代码项目成型前可能早已对项目失控了)

这不是 AI 的问题，而是你要当那个真正的“架构师” —— 项目是你主导的，AI只是你的执行员。

三把锤子：我用的三份关键文档

我后来是通过写三份 .mdc 文件（也可写在 .cursor-rules 里）来解决“AI乱搞”的问题：

1. coding-standards.mdc：通用编码规范

这一份类似代码守则，规定了基础规则，主要作用是“卡死”AI的一些随性操作，内容包括：

• 语言限制：比如统一用 Java、Go、TypeScript，不准混写。
• 注释规范：注释简洁明了，不要多余解释。
• 日志规范：不要乱打 log；错误日志要带上下文信息。
• 错误处理方式：怎么统一封装、如何返回用户友好提示。
• 代码结构引用：强制每次写代码前参考 project-structure.mdc。

小技巧：大版本迭代时，我会要求 Cursor 必须更新这份文档，同时引用更新后的结构。

2. project-structure.mdc：架构 & 工作流规范

这部分是关键中的关键 —— 用来定义：

• 完整目录结构：哪些代码放在哪个包/模块/目录里，谁负责什么。

• 新增文件规则：不能乱放，新增包必须更新结构。

• 需求实现的工作流：

  • API 怎么定义？
  • DB 实体怎么建？
  • 如何生成 migration？
  • Handler / Service / Repository 各层怎么配合？

如果要我说最值得花时间写的规则，绝对是这部分。没有它，AI 根本搞不懂“做一个需求的流程”。

3. docs/模块.md：模块级文档（PRD + 技术文档 + API文档三合一）

我在一开始就划分好了系统的功能模块，每个模块都有一份独立文档（由 Cursor 帮我生成）。内容包含：

• 模块目标与作用
• 关键数据结构
• 对外 API 接口定义
• 与其他模块的依赖关系

放在 docs/ 目录下，方便调用 agent 写代码时引用。功能变更时也必须同步更新。

实际写项目时，怎么协作？

以我的经验，只要前面三件事做得好，AI基本不会“写歪”：

• 一个功能点变化，通常只改 5~10 个文件；
• 简单需求，一次 agent 调用就写完，剩下就是微调；
• 复杂需求也能分两次跑，逐层指引 AI，逻辑保持在线。

我印象最深的是，项目虽然 3 万多行，但因为结构清晰，Cursor 基本能迅速跳到目标位置，不至于“写哪是哪”，反而有种“老兵带新兵”的感觉，甚至还能加速需求推进。

目前花了七八天时间肝了3W+行代码，感觉还游刃有余，还能靠agent模式往里加需求，完全写完也不是问题(不烂尾的话初版上线也许会冲到8-10W行甚至更多，到时候不知道扛不扛得住)

AI 是不是适合当架构师？

我的看法是——不是，至少目前不是。

AI 的特点是：

• 局部能力超强（写某个函数、结构体），
• 全局能力偏弱（架构、横向约束很差），
• context 有限，容易“记不住”规则。

所以我们该反过来思考：

• 人类主导项目结构、模块设计；
• 人类制定需求实现的流程；
• 把工作流和规则“喂”给 AI，让它专注写具体代码。

也就是说，AI 适合“在架构师的规则下干活”。

写给探索 AI 编程的你

总结下，如果你也想用 Cursor / GPT 这种工具去主导项目开发，我的建议是：

1. 别指望 prompt 写得越详细越好，关键是清楚地告诉它：“该在哪写、怎么写”(prompt不一定要很全，太全会稀释注意力)。
2. 别急着写代码，先想清楚每个需求应该怎么落地（工作流），然后再告诉 AI。
3. 三件事写清楚：coding-standard、project-structure、模块文档。

总之，别害怕项目大，AI 是不会累的，但你需要能掌控它，不然就是“野AI写野码”。

其实，做项目最关键的rule不是规定cursor的编码风格，而是得教它做一个需求的workflow是怎样的(尽早定好，不然从开局可能就在跟Al车轱辘对话拉扯了)，代码去哪写(prompt不一定要很全，太全会稀释注意力，)，最后才是所谓的良好但你的理解必须要具体)。

最后总结：用架构(分层/分模块/工作流)给A1框死了，编码风格有问题是可以局部微调的，这样你开个chat把几十个文件全刷一遍也没事，甚至部分情况可以作全局替换。（反正这项目就你一个人写，不存在多人开发的时候不好去做重构而影响到别人的问题）