用途：当一个任务需要代码库约定、局部模式、可复用实现指导、关于“这里代码怎么写”的上手说明，或在实现同类工作前做模式盘点时使用。不要用它为代码库中并不存在的偏好设计背书；除非能解释为何可推广，否则不要把单个示例升格为约定。
挖掘流程：先界定范围，说明子系统、语言、框架与产物类型，范围要窄到示例可比较。再用仓库搜索与代码导航，收集反复出现的实现动作，如模块边界、构造函数、适配器、校验、错误处理、持久化、测试、配置、CLI 标志、API 形状与命名方案。为每个候选模式尽量收集至少三个独立示例；只有两个示例时，除非其核心、近期且刻意平行，否则标为弱信号。接着区分约定与巧合：看哪些跨示例保持稳定、哪些会变化，只把稳定的实现动作保留为约定，名称、顺序、辅助选择与文件布局除有证据表明有意义外视为附带细节。再搜索用不同方式解决同一问题的代码，反例不必然否定模式，而是界定其适用边界、揭示迁移漂移或暴露竞争性的本地约定。然后为每个被接受的模式提炼简短使用规则：何时应用、如何实现、最清晰范例、应避免什么、什么算过度拟合。最后用可能的新实现检验指导，若照做会迫使照搬无关细节，就收窄规则。
质量与护栏：强模式要有重复的独立示例、清晰的存在理由、一致行为与有用边界；弱模式常基于单个文件、某个作者的习惯、新代码不再遵循的旧代码、生成产物、故意使用怪异形状的测试，或仅有表面相似的示例。优先关注行为与意图而非语法琐事；标注置信度为强、中、弱；纳入反例并说明是例外、漂移还是另一模式；除非仓库有广泛证据，避免“总是”“从不”等绝对词；保留安全变化；不要仅因示例形状相同就要求新增抽象。
输出为紧凑报告，含范围、模式清单（每个模式含置信度、证据、约定、指导、边界、过度拟合风险），以及未提升的候选模式及原因。交接给实现者时，保持指导可执行：引用具体示例、说明置信度、指出哪些是可选项；若输出将成为长期文档，删除弱模式或明确标为观察而非约定。