很多 Cursor 新手会把“问模型”理解成“把需求一次性说完”。
结果通常不是更高效，而是更混乱：
- 改动范围变大
- 上下文被污染
- 输出看起来很完整，落地却很难 review
真正的问题，不是 Cursor 不够聪明，而是提示词没有把任务压缩成可执行范围。你可以先配合阅读 Cursor 项目级提示词规范、Cursor Rules 模板、结构化输出与 Schema 控制 与 Cursor 最小回归集。
先给结论：越大的问题，不会自动得到越完整的答案
很多翻车提示词都符合一个共同模式：
$$ 模糊目标 + 过大范围 + 缺少验收 = 结果不可控 $$
当你说“帮我把这个项目优化一下”，模型只能按统计概率猜什么叫“优化”。而工程任务里，最危险的就是猜。
所以这篇文章不教“更会聊天”，而是教你识别 10 种高频反例，并把它们改写成团队可复用的提示词模板。
10 种最常见的反例问法
| 反例类型 | 典型问法 | 为什么会翻车 | 改写方向 |
|---|---|---|---|
| 1. 范围失踪 | 帮我把这个页面改好看 | 没有边界，容易越改越多 | 先限定文件、模块和目标 |
| 2. 目标叠加 | 顺便把性能、SEO、样式都优化了 | 多目标互相竞争，输出发散 | 拆成单一主目标 |
| 3. 非目标缺失 | 你看着改就行 | AI 会顺手重构无关区域 | 写清楚不能改什么 |
| 4. 验收缺失 | 按最佳实践处理 | “最佳实践”没有统一标准 | 给出可验证结果 |
| 5. 输入过量 | 整个仓库你都看看 | 上下文成本高，重点被稀释 | 只喂必要文件 |
| 6. 输入不足 | 直接写，不用看现有代码 | 输出不贴合项目约定 | 至少提供参考文件 |
| 7. 把过程省掉 | 直接给最终代码 | 无计划、无检查、无回滚 | 先计划再执行 |
| 8. 把 AI 当判断器 | 你决定什么方案最好 | 决策标准未声明，容易偏题 | 先给评估维度 |
| 9. 忽略失败路径 | 出错你再修一下 | 没有兜底策略 | 明确失败处理方式 |
| 10. 没有版本意识 | 改到满意为止 | 很难复盘是哪次改坏的 | 要求输出 diff 与验证 |
反例 1 到 4：最容易在第一句就把任务问坏
1. “帮我优化一下”
这是最常见的坏开头，因为“优化”至少可能指向：
- 视觉优化
- 性能优化
- 交互优化
- SEO 优化
- 代码优化
如果你不先选一个主目标，模型会把所有维度混在一起，最后哪一项都不够深。
更好的写法：
仅修改首页 Hero 和 FAQ 区块，不改依赖和路由；目标是压缩首屏文案并提升移动端可读性；验收为首屏高度不超过两屏、无新增 console error。
2. “顺便把别的也一起处理”
这类问法的风险不在“多做一点”，而在于它会让模型主动扩展边界。边界一旦扩展，就很难 review 改动是否还属于当前任务。
更好的做法是把“顺便”改成“后续任务”。
3. “按最佳实践处理”
最佳实践不是一个动作，而是一组取舍。不同项目里，性能、SEO、可维护性和交付速度的优先级并不一样。
更可靠的写法是：
优先保证改动最小；如果存在性能与开发速度冲突，先保证可回滚与交付稳定。
4. “不用给我计划，直接改”
这句话只适合局部函数补全，不适合任何跨文件任务。多文件任务没有计划，就意味着你在提交结果之前看不到影响面。
先计划的价值，不是拖慢速度，而是减少返工。
反例 5 到 7：上下文给错，比不给更危险
5. 把整个仓库都塞进去
上下文不是越多越好。大量无关文件会带来三种副作用：
- 关键信号被稀释
- 历史旧代码被误当成现行规范
- 模型开始引用与你任务无关的实现细节
推荐做法：只提供三类输入。
- 当前要改的文件
- 1 到 2 个风格参考文件
- 1 份验收标准
6. 完全不提供参考
另一种极端是“你自己写”。
如果没有现有组件、命名风格、目录结构和禁改项，模型只能输出通用答案。通用答案通常能跑，但很难融入你的项目。
7. 把草稿、猜想、备选方案一起喂进去
这会制造严重的上下文污染。模型无法知道哪些是最终要求，哪些只是讨论残留。
更稳的做法是先自己收口，按“目标 / 范围 / 非目标 / 验收”四段式再投喂。
反例 8 到 10：没有评估标准，任何结果都看起来像“差不多”
8. “你决定哪种方案最好”
如果你没有说明判断标准，模型会按通用偏好做选择，而不是按你的项目条件做选择。
先声明维度，例如：
- 优先交付速度
- 优先少改文件
- 优先 SEO
- 优先后续维护成本
9. “出错再修”
这类心态等于把错误处理外包给事后。正确姿势应该在提示词里先写：
- 若修改超过 3 个文件，先停在计划阶段
- 若存在未知依赖，先列风险不执行
- 若测试失败，输出最小回退建议
10. “改到我满意”
这句话的问题是没有停止条件。没有停止条件，模型只能不断追求“更完整”，而不是“已经满足验收”。
可靠的停止条件至少包含：
- 功能完成的客观标准
- 不允许越界的边界
- 最小验证动作
一个可复用的修复模板
把上面的 10 个反例压缩后，修复模板可以很简单：
任务目标：只解决一个主要问题
允许改动：限定到目录或文件
禁止改动：依赖、配置、无关模块
参考输入：现有实现 + 风格参考
验收标准：功能 / 质量 / 性能
执行方式：先计划，再改动，再验证
它和 Prompt 版本控制 的关系也很紧：当你开始记录每次提示词如何变化、结果如何变化，你就能真正定位“哪类问法更稳”，而不是反复重问。
一个失败案例：为什么“把登录页优化一下”最后会改到表单逻辑
某个常见场景是：
- 开发者原本只想改登录页布局
- 提示词里写了“顺便提升体验”
- 模型开始修改校验提示、提交流程、按钮状态
- 最后 UI 看起来更好了，但业务逻辑和埋点被一起碰了
根因不是模型乱来，而是提示词授权过宽。
这类任务正确的提法应该是：
仅调整布局与文案层级，不修改表单字段、校验逻辑、提交流程和埋点。
一句“仅”加一句“禁止”，通常比额外写 200 字背景更有效。
发布前检查清单
- 目标是否只保留一个主目标
- 范围是否精确到目录或文件
- 是否写清楚禁止改动项
- 是否给出至少一个参考实现
- 验收标准是否能被手测或回归验证
- 是否要求先输出计划再执行
- 是否给出失败时的停止条件或回退方式
