用途
Iterative Code Exploration 是一种系统化模式，用于通过迭代式的上下文细化，逐步探索和理解不熟悉的代码库。它面向的场景是：当开发者接触一个新代码库时，往往不知道哪些文件包含相关代码、项目存在哪些模式与约定、项目使用什么术语、组件之间如何交互。资料指出，常见做法会失效：通读全部内容耗时且令人不堪重负；凭猜测定位文件常常遗漏关键上下文；提出范围过宽的问题会返回大量无关信息。该模式正是为解决这些问题而提出。
主要能力：四阶段迭代循环
该模式的核心是一个四阶段循环：DISCOVER（发现）→ EVALUATE（评估）→ REFINE（细化）→ LOOP（循环），最多进行 3—4 轮循环后进行综合。
Phase 1：DISCOVER（发现）。从广泛探索开始，包括：查找入口点（如 main、index、app 等命名文件）；发现项目结构（以受控深度列出目录，并排除 node_modules、dist、build 等）；查找配置（如各类 .config 文件、package.json、toml 文件）；识别关键模式（如 TypeScript 中的 export class、Python 中的 def）。此阶段需记录初步发现：项目类型（Web 应用、库、服务等）、技术栈（语言、框架）、架构线索（monorepo、微服务等）。
Phase 2：EVALUATE（评估）。评估所发现文件的相关性，例如阅读 README、ARCHITECTURE 等说明文档，检查包清单中的依赖与脚本。资料给出一套评分标准：关键（★★★）为入口点、核心逻辑、主配置；重要（★★）为工具函数、共享组件、类型定义；支撑（★）为测试、文档、示例；噪声（-）为生成文件、第三方 vendored 代码。
Phase 3：REFINE（细化）。聚焦已识别为相关的具体区域，例如深入查看特定模块目录与索引文件、追踪依赖的导入关系、查找相关模式、查看测试以获得用法示例。此阶段的目标是构建心智模型：组件如何连接、哪些模式被一致使用、相似功能位于何处。
Phase 4：LOOP（循环）。这是决策点：是否需要更多上下文。继续的条件是：关键功能仍不清晰、依赖尚未完全追踪、模式不一致或令人困惑。停止的条件是：核心逻辑已理解、能够解释主要流程、可以自信地进行修改。
使用方式：面向具体任务的工作流
资料针对三类任务给出实践流程：
功能实现：发现——查找已有的相似功能；评估——审阅实现模式；细化——检查测试与边界情况；循环——追踪依赖直至清晰。
缺陷修复：发现——定位错误来源；评估——理解周边上下文；细化——检查调用点与调用方；循环——按需扩展上下文。
重构：发现——梳理当前结构；评估——识别耦合点；细化——查找所有用法；循环——确保找到全部引用。
资料还为每一步提供了具体命令示例，例如用 grep 搜索功能名与错误信息、用 git log -S 追溯变更、用 find 与 wc -l 统计文件规模、用管道与排序统计导入分布等。
输出与记录
模式要求在每次循环迭代后记录：本次查询的目标、发现（X 个文件、Y 个模式、Z 个组件）、相关性（高/中/低及原因）、缺口（仍不清楚之处）、下一步（下轮要探索什么）；并列出关键文件及其评级、更新心智模型（对某部分的新理解、组件之间的连接、发现的模式）。
集成点
资料说明该模式可与以下方面互补：knowledge-architecture（用于记录发现成果）、second-brain-librarian（用于保存探索笔记）、project-orchestration（用于规划探索策略）、testing-patterns（通过测试学习）。
适用场景与提示
该模式适用于理解陌生代码库、实现新功能、修复缺陷和重构等需要建立代码认知的场景。资料给出的技巧包括：先宽后窄地聚焦；记录待验证的假设；把测试当作文档；顺着导入/导出关系追踪；查看 git 历史获取上下文；寻找解释“为什么”的注释。
限制
资料未提供该模式的具体代码实现、安装方式、平台要求、收费情况或可量化的效果数据，这些信息暂未提供。该模式以命令行探索命令和文档化流程的形式呈现，本身不含独立的可执行程序。