第十二章：常见问题与排障清单（上下文/索引/命令/跑偏）

12.1 回答离谱：像是没看代码

优先排查：

• 你有没有把相关文件给到它（入口与调用链）
• 你有没有写清楚项目规则与验收命令
• 它是否只基于“猜测”给方案，而不是基于证据

修复方式（可直接复制）：

先不要改代码。
请基于代码库实际搜索结果，定位入口与证据（文件/函数/调用链）。
只在你能指出明确证据后再给最小改动方案。

12.2 改动扩散：动了不该动的目录

根因通常是：边界没写清楚。

修复方式（可直接复制）：

边界：
- 只允许修改 src/ 与 tests/
- 禁止修改 .github/、infra/、deployment/、terraform/、docs/
每轮修改先输出 diff，我确认后再继续

并把这段固化成团队规则（第 11 章）。

12.3 跑命令失败：测试/构建/lint 不通过

先检查两件事：

• 命令是否正确（项目不一定是 npm test）
• 是否缺少环境变量/配置（但不要粘贴密钥）

建议处理（可直接复制）：

请先从项目配置文件中找出正确的 tests/lint/build 命令（如 package.json、pom.xml、pyproject.toml）。
然后按顺序执行，并把失败日志（脱敏后）贴出，定位根因并给出最小修复方案。

12.4 命令卡住：像是进入交互模式

常见原因：

• 命令需要交互输入
• 测试运行时间过长

建议处理：

• 明确禁止交互式命令，让它给出非交互替代
• 先跑子集测试，再扩到全量

12.5 本章小结

排障的关键是“按层定位”：

• 上下文（文件/规则/验收）→ 索引与搜索 → 命令与环境 → diff 审阅与小步回滚

至此，《Cursor从入门到精通》系列完结。建议你从第 3 章的首次会话模板开始，把目标/约束/验收写清楚，然后用“审阅 diff + 跑验证命令”把交付变成稳定流程。