先查已有方案，再决定是否自建

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

文档仓库需要死链检查，已有维护脚本支持 href/fragment，但没有语言目标判断。教学环境当前只能检查本地仓库，外部注册源不可用。你要选择采用、扩展、组合或自建，不把渠道缺失写成所有方案都不存在。

具体做法

先查任务相关本地实现与测试，再检查实际可用的外部渠道。对候选比较接口、覆盖、维护、许可和依赖成本：满足则采用，缺一小块则扩展，互补能力才组合，确无适配才自建。报告搜索边界与选择理由，安装或执行外部依赖前核对内容和任务范围。

反例

不读已有链接脚本就重新造检查器。注册源不可用便宣布没有任何现成方案，并加入未审查依赖。

改进写法

阅读教学已有 href/fragment 检查器及测试，确认只缺语言目标。优先扩展这一小块并验证，解释为何无需另造完整解析器。外部渠道不可用只说明未查，不声称全局无方案。记录候选与适配判断；其他任务若真需要组合/自建，也应有明确缺口和依赖审查依据。

为什么这样改

复用决策不是总要安装一个包，而是从可见证据判断已有能力与真实缺口。搜索边界透明，选择的理由才不会依赖“我没看见所以没有”的推断。

如何验证

示意决定为扩展现有检查器，列已覆盖 href/fragment、新增语言检查与对应结果；外部渠道标未检查。

检查没有复制第二份重复管线，采用理由含适配而非仅热门或许可证名称，也没有把未检索范围写成不存在。

适用边界

已有代码和热门依赖也可能错误，必须核对当前契约；没有合适可见方案仍可按明确范围自建。不需要为了搜索清单调用全部渠道，来源的固定包数量与工具路径不是通用要求。