整理技术选型的证据与缺口

这个场景能帮你做什么

技术选型不能只看功能表和厂商宣传。WorkBuddy 可以围绕真实约束整理候选方案的证据、未知项和验证任务，使评审能区分“资料宣称支持”与“已经验证可用”。

开始前需要准备什么

提供目标任务、性能与成本约束、现有系统条件、候选产品或技术资料、许可证与部署要求，以及已完成的测试结果。说明哪些是必须项，哪些可协商。

具体怎么做

第一步：先确定评价问题

按任务列必须能力、接入、环境、维护和退出成本。评价项要能影响选择，避免把一堆与目标无关的功能堆成分数。

第二步：为候选逐项取证

每格记录支持结论、资料来源、版本和证据类型。官方说明、第三方介绍和企业实测分开；未知写未知，不能用产品名的印象补表。

第三步：设计最小验证

对会改变选型的未知项，列输入样本、环境、操作、预期结果和失败条件。先验证关键集成或难例，不只重复演示厂商最擅长的样例。

第四步：形成取舍说明

列满足项、不满足项、条件满足项及剩余风险。评分仅用已批准规则，结论附适用条件和重新评估触发点，不写永远最优。

可以直接交给 WorkBuddy 的完整要求

根据附件业务目标与约束，建立候选技术选型证据表。
每项注明是否必须、各候选支持情况、来源/版本、是否实测及缺口。不得补造产品能力。
对关键未知设计小范围验证：样本、环境、步骤、预期、失败条件和所需资源。
输出候选取舍、未决问题及验证优先顺序，费用和许可条件只使用资料已确认口径。

完成后会得到什么

一份能支持评审的证据矩阵和验证计划。团队可以看清选择依赖哪些假设，而不只看到总分最高的名字。

结果应该怎么检查

重点回查必须项、版本限制、部署条件和许可范围。检查实测是否覆盖目标环境，接口可用是否被误写成已经接入。

遇到这些情况怎么处理

候选资料缺失时先补证据。宣传与实测不一致时保留测试条件并安排复核。没有候选满足硬约束时，回到需求或方案，不靠降低评分掩盖缺口。

哪些必须人工决定

技术负责人确认可行性，相关人员确认预算、许可和运维责任。AI 整理证据，不替团队承担技术路线决定。