evaluate-existing-solutions

评估现有方案

先复用，再发明，是一种决策准则，而不是要求每个问题都必须引入依赖。应从整个生命周期的所有权成本出发，比较现有能力与定制方案基线。若成熟方案适用且能降低整体风险和机制复杂度，应优先选择；若证据表明定制方案更精简、更安全、更可控或更具差异化，则应优先选择定制方案。

此技能用于调研和决策。未经单独授权，不会安装软件包、运行不可信代码、创建账户、启动采购、接受许可、向服务发送数据，也不会实施所选方案。

进行外部调研前，请阅读 references/evidence-and-currentness.md。比较入围方案前，请阅读 references/evaluation-dimensions.md。请使用 assets/solution-decision-template.md 作为决策文档的模板。

启动边界与深度

根据情况采用以下三种深度之一：

1. 轻量预检 — 在提议构建重要的定制通用机制之前，检查现有代码库能力以及标准、框架或平台提供的基础能力。仅在存在可信的替代方案或重要的所有权决策时继续。
2. 仅做尽职调查 — 用户已指定尚未采用的重要依赖，但未指定具体名称时，核实其确切版本或层级、兼容性、维护情况、安全性、许可、来源、生命周期或执行风险以及与本地环境的适配情况，不再重新比较市场选项。发现未通过的硬性门槛时应予以指出；否则遵从用户指定的选择。
3. 全面比较 — 对尚未解决且影响重大的选择，将可信的现有方案与真正的定制方案基线进行比较，并提出决策建议。

以下情况应进行全面比较：

• 长期使用的直接依赖或框架；
• 通用的横切能力，例如身份验证、队列、调度、验证、搜索、可观测性、存储、迁移或功能开关；
• 开源应用、开发者工具、构建系统、数据库、运行时、托管服务或平台能力；
• 用成熟的基础能力替换选定的定制机制；
• 具有显著生命周期成本的构建、购买、采用、改造、组合、延期或不采取行动的决策。

以下情况不应强制进行全面比较：领域专属策略、小型且透明的辅助函数、一次性胶合代码、不引入新机制的常规修复或重构，或例行使用项目已有的工具。find-skills 用于发现可安装的 Agent 技能；它不用于评估软件库、工具、应用或服务。

执行约定

• 在寻找方案前，先明确任务和硬性约束。若行为仍有歧义，应回到 specification。如果有已安装的 grill-me 技能，可用它对决策树进行压力测试；否则，每次只问一个重点问题，直到明确硬性约束。
• 在外部搜索前，先检查代码库及其现有能力。
• 当前版本、维护情况、安全性、支持、定价和许可都可能变化。请核实候选方案的最新信息；切勿仅依赖模型记忆。
• 论据应以一手技术证据为依据。人气和营销信息可以帮助发现候选方案，但不能作为选择依据。
• 比较中应保留定制方案基线。采用现有方案并不一定更优。
• 比较总所有权成本，包括集成胶合代码、包装层、升级、迁移、安全响应、测试、运维、支持和退出成本，而不能只看初始实现工作量。
• 根据影响和可逆性调整调研力度。一旦硬性门槛或充分证据表明继续搜索不太可能改变决策，就应停止。
• 记录不确定性、置信度、证据日期，以及哪些因素会改变建议。

工作流

1. 明确决策背景

说明：

• 要完成的工作、用户和运营人员，以及可观察的结果；
• 必须满足的约束、偏好和非目标；
• 预期使用期限、规模、关键程度、可逆性、决策负责人、交付期限和紧迫性；
• 运行时、语言、框架、部署、数据、安全、隐私、无障碍、合规和预算约束；
• 与影响范围相称的调研深度。

将不依赖具体解决方案的需求与有吸引力的产品所使用的术语区分开来。不要让某个候选方案在调研开始后重新定义需求。

2. 优先检查本地和内置选项

阅读适用的说明、架构决策、当前计划、清单文件、锁文件、工作区配置和相关代码。找出：

1. 可复用或扩展的现有仓库功能；
2. 语言标准库或开放标准；
3. 现有运行时、框架、云平台、浏览器、数据库或操作系统原语；
4. 团队已拥有并支持的依赖项和工具。

检查版本兼容性、当前用法、传递依赖、运维惯例、许可证和安全策略，以及复用是否会造成不协调的第二条路径。本地复用仍需有适用性证据；不能仅仅因为旧代码已存在就选用它。

3. 确定候选类别

仅纳入对当前决策而言可信的类别：

• 暂不采取行动或复用现有本地功能；
• 标准、框架或平台原语；
• 有维护的库；
• 开源工具或应用；
• 托管服务或商业服务；
• 调整、封装或组合少量现有选项；
• 定制实现。

避免为了显得选择广泛而罗列候选方案。通常，选出两三个有代表性的最终候选方案，再加上定制实现作为基准，就足够了。不要列出冗长的热门度清单。

4. 收集最新的外部证据

对每个仍在考虑的外部候选方案进行在线调研。酌情优先查阅：

• 官方文档、标准、源代码仓库和权威软件包注册表；
• 精确的版本发布、更新日志、支持期限、兼容性、生命周期终止（EOL）和迁移页面；
• 仓库中确切的 LICENSE、SECURITY、治理、所有权和贡献文件；
• 供应商的 SLA、定价、DPA、数据驻留、可移植性、备份和删除条款；
• OSV、GHSA、供应商公告以及相关国家/地区指南等官方或生态安全公告；
• 当性能对决策至关重要时，优先采用可复现的基准测试，而非供应商说法。

记录观察到的版本或服务层级、证据日期、URL 和结论。搜索摘要、星标数、下载/安装次数、博客排名、自动生成的对比网站以及单一综合安全评分，都只能作为发现线索。

如果无法进行实时调研，只使用本地缓存、锁文件、随附文档和源代码。将外部状态标记为未经核实，并注明决策为暂定；实现前必须重新核实。

5. 先应用硬性门槛，再比较权衡

使用 references/evaluation-dimensions.md。

若候选方案不符合硬性约束，则淘汰该方案或提出可信的缓解措施。然后对剩余方案进行定性比较——不要用加权数值评分来掩饰判断。

评估整个采用的系统，包括传递依赖、集成代码、托管控制平面、运维人员工作流、迁移桥接、回退行为，以及仍需编写的定制胶水代码。小型软件包也可能带来沉重的维护责任；与集成大型框架相比，聚焦的定制模块可能成本更低。

除了生命周期维护责任，还要比较价值实现时间和机会成本。定制方案即使稳态维护成本颇具吸引力，如果交付延迟、学习风险或精力分流带来的代价超过其收益，仍可能落败；现有方案也可能因为集成和迁移耗时过长，不如聚焦开发。只有当这项工作确实值得自行负责时，才应将定制能力视为战略差异化。

将最终决策归类为：

• 采用 — 基本按照现有方案的设计使用。
• 调整 — 配置、扩展、分叉或封装一个方案，并明确负责维护所做的更改。
• 组合 — 组合少量互补能力，并明确指定集成负责人。
• 构建 — 由于总体权衡更优，自行实现定制基线方案。
• 推迟 — 证据或时机尚不充分；保留选择空间并指出下一步触发条件。
• 不做任何更改 — 当前状态已满足需求，而更改带来的维护责任大于其价值。

6. 安全地消除不确定性

对于重要的未知因素，提出能够改变决策的最小适配性验证：临时试验、契约测试、兼容性构建、代表性基准测试、运维演练、许可证／安全审查或迁移演练。

• 先定义问题、成功／失败判定标准、代表性工作负载、时间限制和可丢弃的产物。
• 使用一次性、最小权限的执行沙箱，而不只是临时目录。默认禁止挂载主目录和代码仓库、访问网络、使用凭据和主机服务；仅挂载一次性输入，并明确批准每项例外。
• 未经授权和检查，不要安装或执行不可信的软件包、安装后脚本、容器、二进制文件或远程安装程序。
• 若生态系统支持，应禁用生命周期／安装脚本；执行前验证确切的制品及可用的校验和／签名／来源证明，并记录所有经授权的网络、挂载、凭据或权限例外。
• 未经明确授权且未通过获批的数据路径，不得向候选服务发送机密、个人数据、专有代码或生产负载。
• 测试实际版本和受支持的用法，而不只是玩具 API。

适配性验证证据可以减少不确定性，但无法免除持续的维护、安全或运维义务。

7. 决策并分配负责人

使用 assets/solution-decision-template.md 编写决策。每项由 Agent 产出的结果最初都应标记为提议；只有指定的决策负责人可以接受，并记录接受人和日期。遵循现有的故事、设计或活跃计划约定。如果没有此类约定，请编写带时间戳的临时文件，而不是另行创建永久文档路径。对于明确接受的长期决策，通过 expectations 将其纳入项目现有的 ADR 约定。对于影响重大的提案，使用 technical-writing。

如果采用或调整：

• 写明确切的受支持版本／范围或服务层级，以及更新政策；
• 说明谁负责升级、公告、事件、续订和移除；
• 定义最精简且实用的依赖边界，不要为了封装而封装；
• 使用本地语言表达领域政策，避免让供应商模型渗入整个代码库；
• 记录退出路径、数据导出路径和重新评估触发条件。

如果自行构建：

• 说明现有方案为何无法满足明确的约束条件，或为何在总体责任归属上不合适；
• 区分领域优势与通用基础设施；
• 明确界定当前承担的机制、维护承诺、安全工作和运维范围；
• 指出定制设计中仍复用的任何标准或小型基础构件。

将选定的实现分配给相应负责人：

• 模块职责和隐藏依赖的约定：codebase-design；
• 公共协议或跨团队兼容性：api-design；
• 源码／包的放置和约束执行：structure-codebase；
• 通过净减法替换选定的自定义机制：reduce-system-complexity；
• 交付顺序：planning；
• 新增或变更行为：实现期间使用 tdd、testing 和 refactoring；随后在 PR 就绪时，对累计变更进行一次 mutation-testing；
• 最终的高风险决策审查：double-check。

重新评估触发条件

每项长期决策都应说明何时重新审视，例如：

• 主要版本发布、弃用、生命周期结束（EOL）、维护放缓或兼容性中断；
• 安全公告、所有权／治理变更或许可证变更；
• 定价、SLA、数据驻留、采购或平台政策变更；
• 集成问题反复出现、缺少可观测性、可靠性事件或升级负担；
• 新的规模、延迟、可移植性、无障碍或合规要求；
• 现在有平台基础构件能以明显更少的责任完成该工作。

完成检查

• 是否在研究候选方案之前就明确了工作目标和硬性约束？
• 是否优先检查了代码库、标准库、框架和平台的能力？
• 每个入围的外部方案是否都有当前的一手证据，并注明版本／层级和日期？
• 定制方案基线是否真实，而不是稻草候选方案？
• 是否先应用硬性门槛，再进行定性权衡？
• 比较是否涵盖传递依赖、运维、安全、迁移和退出成本？
• 是否仅将受欢迎程度和综合评分视为参考信号？
• 建议是否与证据相称、尽可能可逆，并明确说明哪些情况会使其改变？
• 实现是否仍需单独授权，并分配给合适的专业技能？
• 除非指定负责人明确接受，否则成果是否仍标记为提议？每个被否决的替代方案是否都有理由？

方法来源

此工作流将本地的「优先复用，再考虑自建」原则与依赖管理、生命周期、安全和技术选型指南结合起来。请参阅 references/evidence-and-currentness.md，了解来源映射和保留的局限性。