"在这个代码库中查找以下漏洞：
1. 可能的 SQL Injection 点
2. 容易引发 XSS 的渲染
3. Authentication bypass 路径
4. 正在记录的敏感数据
5. Path Traversal 对每个发现项提供：file:line、severity (H/M/L)、建议修复方案"

- **Prompt caching**：使用 Anthropic 的缓存。重新摄入相同的 1M token 可以获得 90% 的折扣
- **Selective ingestion**：只包含与分析相关的文件（排除测试、vendor 代码、minified bundles）
- **Sonnet first**：Sonnet 4.6 足以完成简单聚合和摘要，将 Opus 留给复杂推理 ## 注意事项 1. **Lost in the middle**：即使有 1M 上下文，位于中间位置的内容准确率也可能下降。把关键信息放在开头或结尾附近
2. **Code token efficiency**：删除注释并裁剪空白可以让你多放入约 30% 的代码
3. **Single-prompt limits**：对于较长的分析，采用 Suspense-style 的方式请求分段响应 ## 💡 真实世界经验 大多数文章止步于“1M 上下文 = 自动更好”这种泛泛说法，但韩国开发者真正遇到的阻碍是 **成本结构和缓存命中率**。我在一个约 500,000 行的内部 monorepo（Spring + React）上使用了六个月后发现，如果不积极使用 Prompt Caching，月账单会达到 $300–$500。只有在我开始按代码库边界划分 `cache_control` 块，并在 5 分钟 TTL 内重复提问之后，成本才稳定在每月约 $40–$60。另一个在韩国开发者社区（OKKY、Disquiet）经常被忽略的点是，**复用你的 `.gitignore` 模式来排除 vendor/dist/lockfile** 平均可以减少约 35% 的 token（根据 2025 GitHub Octoverse，平均 repo 大约三分之一的体积来自 lockfiles 和构建产物）。最后，最大的实际省时并不来自“完整分析”，而是来自 **按 PR 的 diff 分析**（只加载 base branch + diff，约 50K–150K token）。这是在不构建 RAG 基础设施的情况下自动化代码审查最现实的方式。 ## 总结 1M 上下文打开了许多“你不需要 RAG”的场景。你可以不搭建分块或 embedding 基础设施就立即开始，从而提升 MVP 速度。如果谨慎管理成本，它可以成为个人和小团队处理大型代码库时的关键工具。 ## 实用提示词模板合集 **遗留代码架构分析提示词**

|---------|---------|---------|----------------|
| 50K 行代码的完整分析 | 800K | 5K | ~$12.4 |
| 使用 Prompt Cache | 800K（90% cached） | 5K | ~$1.6 |
| 10 个后续问题 | 800K × 10（cached） | 50K | ~$13.5 | 通过 Prompt Caching，重复工作可以将成本降低 80–90%。 ## 1M 上下文的限制及应对方法 **限制 1：Lost-in-the-middle 效应**
放在上下文中间的信息更不容易被准确处理。将重要代码或说明放在提示词的开头或结尾。 **限制 2：长文本生成较慢**
在 1M token 输入之后，生成可能需要 30–60 秒。streaming API 能更快输出第一个 token，并改善 UX。 **限制 3：规模扩大后代码准确率下降**
一旦超过 50K 行代码，当模型必须精确指出某个具体函数时，错误率会上升。请在提示词中明确重新引用关键函数。 **应对方法：Tree-sitter 预处理**
使用代码解析器（tree-sitter）先提取 AST，只传递压缩后的结构信息，可以将 token 效率提升 40–60%。 ## 常见问题 **Q. 我可以直接通过 Claude Code CLI 使用 1M 上下文吗？**
A. 可以。指定 Opus 并使用 `claude --model claude-opus-4-7` 会自动激活 1M 上下文。它适合分析大规模代码库。 **Q. 我可以在 1M token 中包含图片吗？**
A. 可以。单张图片大约消耗 1,000–2,000 token。附加图表或截图可以补充你的代码上下文。