第四章：上下文管理：文件选择、代码库索引、减少跑偏

4.1 上下文决定上限：同一个模型，结果差一倍

Cursor 输出质量的关键变量往往不是“模型强不强”，而是：

• 你有没有把相关文件给到它
• 它有没有正确理解项目入口与调用链
• 你有没有写清楚项目规则与验收命令

上下文充分时，改动通常更小、更可控；上下文缺失时，改动容易扩散、跑偏、难回滚。

4.2 先给“入口文件”，再给“证据链”

当你要修一个 bug 或实现一个功能，建议按顺序提供上下文：

1. 入口：路由/Controller/handler/CLI 入口
2. 调用链：关键函数到下游依赖
3. 数据结构：DTO/Schema/核心模型
4. 测试：现有用例与断言

你可以用一句话约束：

只基于我提供的文件与代码库实际搜索结果做结论；不要凭经验假设项目结构。

4.3 把“项目规则”当作必需上下文

规则越明确，AI 越不容易做出高风险动作。

常用规则清单：

• 只允许修改哪些目录
• 禁止修改哪些目录
• 是否允许新增依赖
• 测试/lint/build 的正确命令是什么

建议你把这些写到固定模板里（第 11 章会给团队固化方式）。

4.4 减少跑偏的两条硬约束

• 先定位根因证据，再动手改代码
  让 Cursor 先指出文件/函数/调用链证据，避免“直接改错地方”。

• 先给最小方案，再扩展
  先做最小修复通过测试，再做重构与优化，避免混合主题导致审阅困难。

4.5 本章小结

上下文管理的目标只有一个：让改动更小、更可控、更可验证。

• 先入口，再证据链
• 规则与验收命令是必需上下文
• 调查优先、小步交付，减少跑偏与返工

下一章进入提示词工程化：把你的意图写成 Cursor 可执行的“工单”，让输出稳定且可复用。