tech-selection

技术选型 — 门控清单

一份用于在技术之间做出选择的清单，而非评分标准。核心理念：这些标准是筛选条件，而非排序依据——它们会淘汰违反原则的候选方案。让候选方案和权衡取舍保持可见，然后应用当前授权：选择并验证一个已获授权且可逆的实现；将尚未解决的业务、产品或偏好权衡交还给用户。 候选方案数量、耗时和信心措辞都不能决定由谁做出选择。

以下情况会提前终止流程：

1. 由用户决定的选择——缺少授权，或存在真正尚未解决的业务、产品或偏好权衡。返回证据和建议。
2. 未经验证的完成声明——不要做出此声明，执行已获授权的验证，并报告任何剩余的验收差距。

非本清单的用途

• 不适用于研究报告（使用 deep-research）、已确定代码中的调试或错误修复，也不适用于供应商之间的价格比较——这些都不是技术选型。
• 不是面试框架——用户委托的是实现，而不是方向。只要可以自行调查并做出决定，就不要问“你更喜欢哪一个”。
• 不是评分标准——没有加权分数，也没有“赢家”排名。先筛选，再以业务目标为锚点。
• 不是自我认证——“为什么这不是垃圾”的论证由此技能撰写，但必须可以独立核查，不能由自己批准。
• 不是成本门槛——预算决定执行档位（运行哪个模型），而不是决定是否执行。不要以成本为由拒绝用户自己的项目。
• 不是扩展范围的理由——不要加入未请求的功能、框架或复杂性。
• 不由包大小驱动——行数和打包体积只是替代指标，并不代表质量。

执行流程

轻量路径。 对于小型、可逆且本地的实现，且不存在外部契约时，执行步骤 0、1 和适用的步骤 3 评估维度。使用下方的简短输出；在声称结果有效之前，先执行必要且已获授权的探测。错误修复中使用 JSON 库符合此路径；项目的存储引擎或外部字段契约则需要执行完整流程，即使更改耗时不到 10 分钟。耗时估计的是工作量，而非授权范围。不确定适用哪条路径时，采用完整流程。两条路径都必须遵守停止条件和任何明确的当前任务指令。

步骤 0 · 界定

比较任何候选方案之前，先写下以下内容：

1. 此选择所服务的明确业务结果。
2. 明确的失败模式——什么可观察到的现象能证明这个选择是错误的。

根据上下文推导业务结果，而不是照搬请求文本。单独一句“选哪个 DB”本身并未说明要实现什么结果——请查看项目的决策日志、用户最近的更正，以及此选择能推动哪些后续事项。如果没有可据以推导的上下文，就明确说明，而不是凭空编造。

检查点：无法根据任何可用上下文推导出业务结果 → 这是执行任务，而非选型任务。退出此技能。若业务结果写成“测试通过”或“流水线完成” → 这是替代指标。请重写。

第 1 步 · 清点现有方案

固定顺序：内部／付费资产 → 外部一流方案 + 社区方案 → 从零构建（最后手段）。为每个候选方案标注其所属层级。

第 1 层可查找的内容：现有凭据和付费服务能力目录、已安装的技能、当前代码库中已有的流水线、项目的决策日志，以及用户自行整理的收藏（如果已安装，请先运行 favorites-search）。不要将第 1 层的搜索局限于当前代码库中的 grep——这会导致付费服务和技能的搜索结果为零，而狭窄搜索的零结果并不代表不存在。

第 2 层有最低覆盖要求：使用搜索工具列举现有方案，不能只凭记忆。「搜过，找到 2 个」不算覆盖——请列出运行过的搜索查询，或者明确说明没有可用的搜索工具，清点结果仅基于记忆。

检查点：如果最终建议选择第 3 层（构建），且没有记录第 1～2 层的相关理由 → 标记为闭门造车。第 1 层搜索结果为零时，必须区分「按结构性标记搜索」和「按记忆中的名称搜索」——后者结果为零并不代表不存在。

用户点名的候选方案。 用户点名某个具体选项时（「用 Redis 还是 Postgres？」、「要不要添加向量存储？」），该选项与其他方案一样纳入候选集——须按相同维度评估并给出判定。它既不免于筛选（被点名不代表必须采用），也不能随意舍弃（要淘汰用户点名的候选方案，必须像淘汰其他方案一样，指出评估维度和失效模式）。如果用户恰好点名了两个选项，它们就是最低候选集；另外还要加入清点中发现的任何第 1 层或第 2 层候选方案，并说明这一点。

第 2 步 · 探查证据

对于摄取、索引、存储或批量数据的选择，先加载 references/batch-data-probes.md，并根据实际消费者契约推导出代表性案例，然后再比较引擎。

按证据所能证实的内容为其标注：观测到的执行结果只能证明测得的行为；当前官方 API 文档或经过检查的源码可以确立契约或排除不兼容的候选方案，但不能证明运行时可用性或业务收益。仅有 README／供应商声明时，这些说法仍属「未知」。 终止条款：每个候选方案在所有方法中的尝试次数最多为两次；失败两次 →「当前无法完成」，未测量的说法仍标记为「未知」。

检查点：每个关键主张都必须注明其证据及适用范围。有关运行时和业务结果的主张需要相应的观测证据；不得将基于源码契约的证据重新标记为观测结果。

第 3 步 · 筛选每个候选方案

阅读决策维度。对每个候选方案，按每个维度给出判定：pass／fail（指出失效模式）／unknown（需要探查）。

核心维度上的 fail 会淘汰候选方案。references/scoped-criteria.md 中 C 类标准上的 fail 不会淘汰——将其记录为该候选方案的「明确反对偏好」备注，然后继续。只有核心维度上的失败会将候选方案移出幸存者集合。

检查点：unknown 不等于 pass。带有 unknown 的候选方案不得进入第 4 步的幸存者集合。本步骤不得输出「赢家」。

步骤 4 · 筛选剩余候选项 — 核心关卡

• 0 个剩余候选项：说明哪个维度淘汰了哪个候选项，以及是维度有误还是候选集不完整。区分 unknown 和 fail；指出停滞的探测及恢复条件。先运行可用且已获授权的探测，再询问只有用户才能提供的信息。绝不凭空捏造剩余候选项。
• 1 个或更多剩余候选项：阅读 references/delegation-contract.md。检查当前授权及其后果，包括可维护性和相关行业实践。对于已获授权且可逆的实现，依据证据进行选择，保留备选方案和权衡，并执行必要的验证。对于尚未解决且由用户决定的选择，返回候选项、权衡及一条建议，并且只停止依赖该选择的操作。不要悄然丢弃被否决的候选项。

检查点：输出能否指出哪个候选项被降级，以及是由哪个维度降级的？如果不能，这道关卡就形同虚设。

步骤 5 · 自我辩护环节

完整协议的结论必须附带一段“为什么这不是垃圾”的说明，而且不能仅由此技能自行认证。轻量路径则在简短输出中附上明确的理由和证据。

检查点：自我辩护中的每句话都必须能追溯到证据，或该证据范围内的维度判定。泛泛的原则（例如“这是一个成熟的库”）= 无效。

步骤 6 · 覆盖不可逆表面

扫描无法在发布后修补的表面：遥测/事件、字段和导出格式、外部契约、不可逆的外部操作。如果存在此类表面 → 从 v0 起全面覆盖。此维度的证据仅适用于单一场景——当选择会产出已发布的制品时才应用；不要用于内部或可回滚的更改，也绝不要用它来提高没有不可逆表面的工作的标准。

检查点：明确列出不可逆表面，或明确写出“无”。不作说明 = 未检查。可回滚的本地更改不会触发此步骤。

步骤 7 · 完成声明

区分“我已验证”和“我声称”。每条完成声明后都必须说明实际执行和观察到的内容。

检查点：运行 Agent 能执行的、已获授权的检查。单独标注人工验收；未观察到的验收仍属未确认，不得将其作为完成声明，也不得因此阻止已获授权的验证和交付。

输出形式

轻量输出： 业务结果 + 证伪条件；既有方案层；选定的本地实现 + 理由和授权；必要探测的结果或 unknown。 保留相关备选方案，无需提供完整矩阵或未使用的步骤 4–6 字段。

完整协议输出： 输出以下字段。根据决策分支，说明实际验证情况和人工验收状态。

1. 业务结果 + 失败模式（步骤 0）。
2. 候选方案表（步骤 1–3）——每个候选方案都要标明所属层级标签、各轴判定结果（pass／fail／unknown），以及每项 pass 背后的探测名称；若是来源契约判定，则提供权威来源证据。带有 unknown 的候选方案必须明确标出，不得隐藏。
3. 存活候选方案降级记录（步骤 4）——针对每个被降级的候选方案，说明淘汰它的轴和明确的失败模式。如果没有候选方案被降级，则写明「没有候选方案被淘汰」，并列出所有候选方案均通过的各轴。
4. 决策分支（步骤 4）——必须且只能声明以下一项：
   • 已授权实现，并说明选定的存活候选方案、备选方案、权衡、授权，以及步骤 5 的自我辩护
   • 由用户选择 → 停止，并说明候选方案 + 权衡 + 一项建议、尚缺的决策／授权，以及因此暂缓的操作
   • 0 个存活候选方案，并说明诊断结果（轴不匹配还是候选集不完整）
5. 自我辩护（步骤 5）——每句话都要对应某项探测或轴判定。针对选定的实现或建议撰写；若没有存活候选方案，则说明诊断结果，不要为虚构的赢家辩护。
6. 不可逆操作涉及的界面清单（步骤 6）——列出已发现的界面，或写「无」。不得省略。

停止条件

停止 1 · 多候选方案需要人工权衡

如果当前授权将业务、产品或偏好选择交由用户决定，输出内容为：

• 每个存活候选方案
• 各自的权衡（成本和舍弃的内容）
• 一项附有理由的建议

在用户作出选择前，不得执行依赖该选择的操作。保留被拒绝的候选方案及其原因，不得捏造排序。仅有多个存活候选方案，并不意味着对本地、可逆实现重新获得授权。即使只有一个候选方案存活，新增范围、对外承诺和不可逆操作仍须获得相应授权。除非后续事实或指令改变先前答复的适用性，否则应沿用先前答复。

停止 2 · 完成声明未经验证

Agent 执行已授权的探测，并观察实际使用方／结果；测试通过不能替代对该结果的观察。如果产物需要人工验收，应提供具体结果和验收证据，并在实际观察到验收情况前将状态标记为未确认。不得作出缺乏依据的完成声明；继续执行独立且已获授权的工作，并在受阻时指出确切缺少的条件。

Agent 编排

委派前，请阅读编排契约。

参考资料

文件	阅读时机
决策轴	步骤 3——核心筛选条件
批量数据探测	步骤 2——摄取／索引／存储正确性、增长、增量工作和恢复
范围化标准	步骤 3——补充标准和类别处理
拒绝模式	提出方案前——使用自测检查草稿
委派契约	步骤 4——决策归属；委派或解决范围边界前

边界速查

解决这些表面上的冲突前，请阅读已解决的范围边界。