用 Cursor 一个月才懂的三件事

用 AI 写代码的人分两种：一种以为提示词是关键，一种以为换个更强的模型是关键。Cursor 官方出了套免费课程（Cursor Learn），不讲机器学习不讲训练，就讲怎么把模型用明白——三课看下来，我确认自己踩过的三个误区，大概率你也在踩。

误区一：以为它会给你相同的答案

模型是概率机器，不是确定性 API。课程给的定义很准：把 AI 模型当作"超智能的通用 API 端点"——你集成 Stripe 处理支付，同样可以调用模型干活，唯一的本质区别是：你无法保证每次得到相同的结果。

同样的输入，它可能走很多条不同的路。由此推出两条铁律：相同的模型和提示，可能给出不同回答；模型不总是遵循你的指令——包括"只改这一个函数"这种简单约束。

你让它只改一个函数，它顺手重构了半个文件。不是它调皮，是概率机器天然如此。与 AI 协作的第一课：验证它的输出，永远别默认它对。依赖 AI 输出的流程，测试和评审环节省不得。

选模型的三维框架也朴素得残忍：智能、速度、成本——又快又便宜又聪明的不存在。改错别字用旗舰模型是烧钱，让便宜模型设计架构是自虐。

误区二：以为关键在提示词

第二课的核心结论，认知错位重灾区：与模型协作的本质不是写更好的提示词，而是管理你提供的上下文。

做菜比喻：食材（输入）决定汤的下限，食谱（计划）只是路径。上下文管得好，平庸的提示词也能出好活；上下文喂错了，文采再好也救不回来。

上下文里有两块容易被忽略的暗区：系统提示排在最前面，是工具注入的规则，你看不见但它每轮都在生效——理解这点就明白为什么同一个模型在不同工具里表现不同；自动注入是编辑器的价值所在——打开的文件、终端输出、Linter 报错都已经在场，不用手动贴。

还有物理极限：上下文随轮次增长，触顶后早期约定被压缩挤出，模型开始"违反前面说好的事"。这不是 bug，是工作记忆的容量。该新开对话时新开，别恋战——切换任务时、Agent 开始反复犯错时，都是明确的信号。

工具调用和 MCP 是这课的延伸：模型能自己取上下文（读文件、跑命令、搜代码），MCP 让工具构建一次处处运行——模型的能力边界，由你接了什么工具定义。

误区三：以为 Agent 靠谱

第三课有句定性，比任何技术定义都好用：把 Agent 看作行动迅速的初级开发者——需要明确指导，容易忘事，需要监督，还可能陷入循环反复用同一种失败方法。

委派的艺术核心是一条：Agent 会遵循你的现有模式，而不是自行创造新模式——前提是你把模式指给它看。对比一下就懂：

模糊版："添加用户设置页面。"——它得猜布局、猜组件、猜样式，有时能蒙对，通常不能。

明确版："添加用户设置页面。查看 src/app/profile/page.tsx 里现有的配置页，参考我们的布局模式；用 src/components/ui/Form.tsx 的表单组件；设置项：显示名称（文本）、邮件通知（开关）、主题（下拉）；用现有的 useUserPreferences hook。"——引用现有文件、现有组件、清晰范围。

最常见的失败模式排第一的是范围失控：没做好规划就要大范围更改——Agent 做了无关改动、动了你不想动的文件。处方是把任务拆小、把边界写进提示词，而不是事后收拾。

最后一句课程原话值得裱起来：委派的是实现，不是责任。验证代码能否运行、是否符合你的标准，永远是你的事。

聊两句：三个误区你踩过哪个最狠？我投"恋战不换对话"一票——曾经在一个 40 万 token 的会话里反复纠偏，新开对话五分钟就解决了。评论区说说你的案例，我置顶我的完整踩坑清单。

往期：LVS、双模型流水线、扫描 PDF 转 EPUB 都在主页；下一篇把整个 GitHub 搬进终端。关注不迷路。