如果你已经使用 Cursor 一段时间，并开始用它处理一些更 复杂 的项目，那你几乎肯定会遇到一个挑战：如何让一切保持在正轨上。

当然，这并不是 Cursor 独有的问题，而是 AI 辅助编码的通病。小范围的上下文容易处理，大范围的上下文就难了。模型已经进步很大，但总体来说，人类在判断“哪些东西该出现在大局里”这方面仍然做得更好。

这篇文章是干什么的？我为什么要读？

我已经使用 Cursor（以及其他 LLM 工具）一年多了，所以想分享一些在处理大项目时帮到我的技巧。你的情况可能有所不同（YMMV），但希望这些建议能让你从 AI 辅助这颗“橙子”中再多挤出一点汁来。🍊

1. 使用 Composer

Chat 功能适合回答一些小问题或快速插话，但（至少在写这篇文章时）它不像 Composer 那样可以设置检查点。你可能还没发现，Composer 会为你的对话设置检查点。如果你的项目开始走偏，或者你在修 bug 上浪费了太多时间，你可以轻松回到之前一个“已知正常”的状态 —— 在模型开始把代码弄乱之前。😁

2. Git，Git，还是 Git

Git。不是所有人都喜欢 Git，它有些部分确实很“吓人”。但好在 VS Code 把很多复杂的部分都封装了起来，所以你大概率不会接触到那些恐怖的命令。但如果你不常用 Git，你总有一天会经历这样一个时刻：某个 diff 应用错了，导致一个文件被彻底覆盖，而你已经没法“回到过去”。🕥

存储空间很便宜，所以应该“少量多次”地提交。不要等项目“完美”再 commit，因为它几乎永远不会完美。Git commit 不是什么值得吹奏的里程碑，它只是一个方便的小检查点。学会“回到过去”的技能，真的能帮你省下好几个小时的痛苦时间。💔

3. 引导型 prompt

如果你希望模型热爱“解耦”和“封装”，那就告诉它“你很擅长解耦和封装”。如果你希望它成为你所用技术栈的专家，那就告诉它“你就是专家”（为什么这么做有效我会在最后解释）。我每次开始新的 Composer 会话时，都会先贴一段鼓励良好编码习惯的 boilerplate —— 你在网上也能找到类似的模板 —— 如果上下文变得混乱，我就重新开一个新会话。

3b. Notepad 记事本

如果你没有一个 Notepad 来记录你的目标（至少写个功能说明文档），并且始终绑定在 Composer 上下文里，那你就真的错过了。这其实是任何稍微大一点项目的基本操作，是让模型保持正确方向和“有动力”的最佳方式之一。

4. Composer 会话别太长

就像你可能会拖着不提交 Git 一样，有些人会等“完美时机”才换主题或开启新会话。但如果过程中遇到 bug 或思路混乱，你的 Composer 会话就可能变得越来越长。

根据我的经验，这不仅会让 UI 非常卡，还会导致输出质量下降。我最开心的编码体验通常发生在会话刚开始的时候，而那些“抓狂时刻”通常发生在会话已经太长 —— 那时会开始出现幻觉、反复修改的问题（“A 不行，得用 B；B 不行，得回到 A”，无限循环）。当你发现模型开始回答你之前的问题而不是你刚问的那个问题时，这就来了……🤦

学会经常开启新会话（点击 Composer 视图右上角的 “+” 按钮），重新贴上你的 boilerplate，说明当前项目进行到哪一步了，哪里坏掉了，然后继续推进 —— 会获得更清晰、更高质量的结果。✅

5. 让 AI 给出计划（而不是直接编码）

我最成功的会话大多遵循这样的格式：

• 贴上 boilerplate，告诉模型它在某个语言和库上是专家
• 解释系统的整体结构
• 告诉它你接下来要实现什么
• 告诉 AI 暂时不要写代码，而是总结你说的内容，并输出一个实现计划。然后把这个计划复制保存，一旦上下文模糊就可以贴回来。

接下来每一条 prompt（或每几条），你可以要求 AI：

• 详细解释它接下来要做什么、背后的逻辑、好解决方案的标准、为什么这么设计（这样做的结果通常是代码质量更高）
• 实现代码更改
• 回顾当前计划，并明确下一步行动

不断让 AI 解释自己、回顾整体规划，似乎（真的只是“似乎”，因人而异）有助于保持“全局视角”的清晰，从而避免一团乱。🪢

PS：也可以把这些贴进 Notepad 中，并一直绑定上下文 —— 人生苦短，效率为先。

6. TDD（测试驱动开发）

你应该听过 TDD（Test-Driven Development）吧？如果你学过计算机科学，可能会记得它是那种你 应该 喜欢的东西 —— 因为它能证明你的代码不出错，并满足功能规范。你列出假设、写测试、然后写代码让测试通过。

但在小项目中，很多开发者会说：“呃……我只想写代码，写测试太费时间了”。确实很无聊，也很枯燥。于是很多人慢慢就养成了跳过写测试的习惯 —— 人生苦短，没时间写测试嘛。

但是：AI 来了！

当我尝试这个方法时，感觉像是发现了新大陆。对于中型项目，先写一些描述性的测试，但不要让 AI 写代码，而是让它 写测试。测试这部分传统上很枯燥、耗时、人类讨厌，但 AI 却很擅长。

让初期对话尽量不要出现代码，和 AI 一起探讨主题与系统设计，让它帮你描绘一个理想系统，然后让它生成结构代码，留出 TODO 或 mock。接着让它写单元测试（后面还可以写集成测试）。📋

当你真正开始写代码时，如果模型写错了东西，你可以直接 贴出失败的测试 —— 比你自己用语言描述问题容易多了。而且 AI 可以始终读取这些测试，它们非常清晰、结构化，是很好的“上下文锚点”。🗳️

对我而言，这种方式使很多原本对 AI 来说过于复杂的项目也变得可行了。

最后的思考

呼……写得比我预期长多了。如果你读到这里，恭喜你，请收下一个符合 GDPR 的 cookie 🍪

最后说一句关于 AI 的事，然后我就收工。

那就是：不要忘了，LLM 本质上是非常精致的自动化 “骗术大师” —— 它们的唯一技能就是告诉你它“觉得”你想听什么内容，它会不惜一切代价维持住“它很聪明”的错觉。🤓

这就是为什么它们会“幻觉” —— 举个例子，试试问 ChatGPT：你最喜欢的某部剧集中哪一集某个角色穿了蓝夹克？它会一本正经地胡说八道。

这也是为什么你告诉它“你是专家”居然有效 —— 它会用符合专家语气和句式的方式回应你，以维持错觉。有时你甚至可以告诉它“慢慢来、仔细想”，虽然它不会真的延迟回应，但你可能会得到更高质量的答案 —— 因为这更像一个小心谨慎的专家说话的方式。🧙‍♀️

好啦，真的说完了。希望这篇文章能帮到正在使用 Cursor 进行 AI 编码的朋友们，或者至少带来一点关于 AI 使用方式的灵感。如果它对你有帮助，欢迎点个赞，或者回帖分享你自己的经验，让它在这个活跃的社区里“冒个泡”。😇

PS：标题中“白痴”不是说你，是说我自己。

附录：补充与修正

• 不要只说 “yes”。根据惨痛经验，如果模型问你“要不要我来实现这个功能？”而你只回一句 “yes”，它有可能会跳回上下文中一个完全不相关的地方去“重温旧梦”。正确的说法是：“是的，请你按照刚才提到的建议来实现修改”，这样可以避免困惑和浪费 token。

• 要求 debug 日志。如果事情开始不对劲 —— 尤其是当你陷入“别做 A，做 B；别做 B，做 A”这样的循环时 —— 告诉 AI 写大量 debug 日志，然后把这些日志一股脑贴给它。模型在阅读冗长日志并找出一个小错误的能力是“超人级别”的。这通常能让模型发现它的错误假设，有时甚至光是加上日志，模型就能修复那些难以复现的 bug，就像你让一个实习生“复述一下你的操作过程”时他自己就发现问题了🙂