你给 Composer 写了”清理一下这段”或”统一下风格”，回头一看 git status 显示 14 个文件变更、500+ 行改动、连命名约定都改了。能跑的测试现在挂三个。问题不在模型”贪心”，而在 Composer 默认把任何模糊指令当成”我可以做我认为对的事”，agent 模式更激进。
止血只要 git checkout，但要让 Composer 下次不再这么放肆，得改你交给它的边界。
常见原因
1. Prompt 用了动词模糊词
“clean up”、“refactor”、“improve”、“polish”、“modernize” 这类词没有上限。模型把它们当成”做你认为应该做的全部”，于是改命名、抽函数、重排参数、加注释一起来。
如何判断：把你的 prompt 第一句拎出来，看动词是否”unbounded”。“clean up” 是，“rename foo to bar” 不是。
2. Agent 模式默认有写多文件 / 跑命令权限
Composer 在 agent 模式下可以 read_file → grep → edit_file 跨整个仓库迭代。你只问了一件事，它”顺便”修了它认为相关的另外 8 件。
如何判断：Composer 输入框模式下拉是不是 “Agent” 而不是 “Edit” / “Ask”；Agent 模式下一次回复会列十几个 tool call。
3. 没列”不要碰”的清单
模型不知道哪些文件神圣。migrations/、generated/、vendor/、schema.prisma、第三方 SDK 包装层这些都是高危区，但你不说它就改。
如何判断：看 git diff --stat，是否有改动落在”我从来没让你碰过这”的目录。
4. 没 commit 就连发多 prompt
你给一句 prompt → 它改了 → 不满意 → 再来一句 → 又改。3 轮后 diff 已经混在一起了，最后 revert 起来分不清哪改哪没改。
如何判断：git log --oneline 看上一次 commit 是不是今早或几天前。
5. 模型选错（agent 用了重写型模型）
opus / gpt-5 在 agent mode 下倾向”大刀阔斧”重构；sonnet / haiku 倾向保守 patch。任务是 surgical edit 时用大模型反而误伤。
如何判断：看 Composer 右下角模型；如果是 opus 又是 surgical 任务，模型选错了。
6. .cursorrules 没说”小改动优先”
没 rules 时模型按训练时学到的”好工程师风格”行动——其中包括”看到坏代码就重构”。你不显式说”don’t refactor unless asked”它就会。
如何判断：仓库根 cat .cursorrules；如果没有 “minimal edits” / “don’t refactor” 类条款就要补。
动手前先确认
- 确认问题是在 Composer / Cmd+K / chat 哪个入口；Cmd+K 局部、Composer 全局、行为差很大。
- 出问题立刻别再发 prompt，先
git diff > /tmp/diff.patch留证据再决定 revert。 - 记下 Cursor 版本和当前模型；切换模型重跑同 prompt 行为可能完全不同。
需要收集的信息
- 触发 misedit 的 prompt 全文。
git diff --stat输出，列出哪些文件改了多少行。- 当前模型 + 模式（Ask / Edit / Agent）+ 是否开 Max mode。
- 仓库
.cursorrules内容、是否有.cursorignore。
最短修复路径
按”先止血再修方法论”顺序。
Step 1：止血 + 留证据
git diff > /tmp/composer-misedit.patch # 留个 patch 备查
git stash # 临时收起，不丢
# 或直接 revert：
git checkout HEAD -- . # 丢掉所有未 commit 改动Step 2：分类筛留——只保留你要的
如果只是 5/14 文件想留：
git stash pop # 取回 patch
# Cursor 内 source control 面板逐文件 discard
# 或命令行：
git checkout HEAD -- path/to/unwanted-file也可以 git add -p 交互式只 stage 想要的 hunk。
Step 3：重写 prompt，加 explicit scope
把 unbounded 词换成 surgical 词：
原：refactor the auth module
改：In src/auth/login.ts only:
1. Replace the magic string "DEFAULT_TIMEOUT" with the constant from config.
2. Do NOT change function signatures.
3. Do NOT touch any other file.
4. Do NOT add or remove comments.
Output a unified diff, ≤ 30 lines.Step 4：切到 Edit 模式或 Cmd+K，限制行动空间
Composer 输入框模式下拉 → “Edit” 而不是 “Agent”。Edit 模式只改你 @ 的文件、不会跨文件迭代。
外科级修改用 Cmd+K（选中要改的代码块再触发），权限缩到选中范围内。
Step 5：在 .cursorrules 里写死”保守原则”
# .cursorrules
- Make the minimum change required to satisfy the prompt.
- Do NOT refactor, rename, or reformat code that is not explicitly mentioned.
- Do NOT touch files in: migrations/, generated/, vendor/, schema.prisma.
- If the task seems to require changes outside the listed files, STOP and ask first.
- Preserve existing comments and existing import order unless asked to change them.Step 6：危险任务前 commit
养成 Composer 大任务前 git commit -m "wip: before composer" 的习惯。失败 revert 成本秒级。
怎么确认已经修好
- 用同一 prompt 重跑一次，检查改动是否限定在你 @ 的文件里。
- 让队友打开同一 workspace 用同样 prompt 重跑，确认是规则层的修复。
- 跑测试 + lint，确认 diff 没引入风格 / 行为漂移。
如果还是没修好
- 把 prompt 缩到极小：单一动词 + 单一文件 + 单一目标行。
- 回滚最近一次
.cursorrules改动，逐项确认是哪条没起作用。 - 在 forum.cursor.com 搜 “composer over-edits”；附 Cursor 版本 + 模型 + prompt + diff。
- 抓 View → Output → Cursor 日志贴 Bug Reports。
预防建议
- 每次开 Composer 前 commit，给自己一个干净基线。
- prompt 模板里加 “Constraints” 段：allowed files / forbidden files / max diff lines。
- 默认用 Edit 模式或 Cmd+K，agent 模式只在你确定要 multi-step 时手动开。
.cursorrules写死 “minimum diff” 原则 + 神圣目录清单。- 给重要文件加显眼注释：
// DO NOT MODIFY without ticket #1234—— 模型看了通常会跳过。