关于 vendor-evaluation
vendor-evaluation 是供团队选择或续约外部工具与服务的通用框架。它涵盖需求定义、自建或采购分析、候选方案评分、安全审查、谈判和上线规划，并关注供应商锁定与退出条款。
主要功能
- 01明确需求、约束和成功标准
- 02梳理自建或采购的决策
- 03筛选并为候选供应商评分
- 04审查安全、合规与锁定风险
- 05指导合同谈判和上线规划
适用场景
- 01比较新工具或服务的供应商
- 02判断应自建还是采购
- 03续约前评估替代方案
- 04准备 RFP 并协商合同条款
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/vendor-evaluation确认已加载。
附带文件README.mdreferences/evaluation-rubric.md
详细介绍
供应商评估
选择合适的工具或服务，协商公平的条款，并避免陷入供应商锁定。与技术栈无关。适用于 SaaS、基础设施提供商、代理机构和任何外部依赖。
何时使用
- 为新需求选择工具或供应商
- 评估当前供应商的替代方案
- 自建还是购买分析
- 即将续约：应该续用还是更换？
- 开展正式的 RFP 或 RFI
- 对比供应商遴选中的最终候选者
- 协商合同
- 评估供应商风险（财务、安全、依赖性）
何时不使用
- 一般性降本（使用
cost-optimization） - 具体的合同法律条款（应交由法务处理）
- 现有供应商的性能问题（尝试先解决问题，再考虑更换）
- 为一次性项目聘请代理机构（需要更轻量的框架）
必需输入
- 需求（要解决什么问题，怎样才算成功）
- 约束条件（预算、时间线、集成要求）
- 相关人员（用户、IT、安全、财务、法务）
- 现有背景（已在使用什么、尝试过什么）
- 合规要求
框架：5 个阶段
结构化的供应商评估。跳过阶段可能要付出代价。
阶段 1：明确需求
在考察供应商之前，先明确你真正需要什么。
- 要解决什么问题？
- 用户是谁／使用场景是什么？
- 6 个月后、2 年后，怎样才算“成功”？
- 预算是多少（给出范围，而不只是上限）？
- 时间线是什么？
- 是否有必须满足的集成要求或约束条件？
一种常见诱惑是跳过这一步，直接开始看演示。供应商乐于展示自己的产品；结果你可能会选择看起来光鲜的方案，而不是真正合适的方案。
阶段 2：自建还是购买
在评估供应商之前，先决定是否应该自建。
适合自建的情况：
- 这是业务核心（能形成差异化）
- 需求非常特殊，没有供应商能满足
- 按你的规模计算，经济上可行
- 你有团队负责维护
- 供应商锁定不可接受
适合购买的情况：
- 这是基础能力（无法形成差异化）
- 现有产品已能很好地满足需求
- 从经济上看，购买更划算
- 团队应该把精力放在其他方面
- 供应商的专业能力胜过你们的通用能力
大多数团队会过度自建。经验法则是：除非有充分理由，否则就购买。即使理由充分，也要再仔细审视。
阶段 3：列出候选名单
先尽可能广泛地搜寻，再逐步筛选。
信息来源：
- 内部团队已有的经验
- 行业分析师报告（Gartner、Forrester 等）
- 同行推荐（与你们类似的其他公司）
- 评价（G2、Capterra；但要注意评价质量）
- 你已在使用的相关供应商（通常也提供你需要的功能）
- 开源替代方案
先广泛搜寻，目标是列出 5-8 个候选方案。然后筛选出 2-4 个最终候选者，进行深入评估。
第 4 阶段：为入围候选者评分
使用评分表。没有评分表，你就容易被演示中的花哨效果或最热情友好的销售代表左右。
评分维度（根据你的情况分配权重）：
功能契合度（40%）： 它能满足你的需求吗？能否处理边缘情况？用户体验质量如何？是否契合工作流？
技术契合度（15%）： 与你的技术栈集成的情况如何？API 的质量和完整性如何？数据导出和可移植性如何？能否满足你的规模下的性能要求？是可自托管、混合部署，还是仅提供 SaaS？
运营契合度（10%）： 上线所需精力。培训和采用情况。文档质量。支持质量（提交工单进行测试）。SLA。
安全与合规（10%）： 视情况而定，是否符合 SOC 2、ISO 27001、HIPAA 等标准。数据驻留。静态和传输中的加密。访问控制和审计日志。渗透测试结果（请索取）。分包商。
供应商健康状况（10%）： 经营年限。融资和资金储备（如果是私有公司，则看营收）。客户规模及类似客户。公开的客户推荐。路线图透明度。
成本（10%）： 许可或订阅费用。实施和上线成本。培训成本。集成成本。机会成本（内部资源投入的时间）。转换成本（万一失败时）。
锁定风险（5%）： 数据导出的质量。标准格式还是专有格式。迁移到其他方案的路径。是否符合开放标准。合同退出条款。
为每个入围候选者的每个维度打 1–5 分。乘以权重后求和。
评分不是金科玉律，而是用来揭示取舍。
第 5 阶段：谈判
大多数企业合同都可以谈判，但多数人不会谈判。
可谈判的内容：
- 价格（多年期、用量、预付款、季度末时机）
- 条款（付款计划、续约条款）
- 成功承诺（培训、上线、支持）
- SLA（正常运行时间、响应时间、服务抵扣）
- 终止条款（自动续约、通知期限、数据导出）
- 责任上限和赔偿（法务会关注这些内容）
- 分包商和数据处理（安全与法务会关注）
常见谈判策略：
- 多年期折扣（签 3 年合同可享 15%–30% 折扣很常见）
- 用量阶梯（承诺更高的用量，以换取单价折扣）
- 预付全年费用以换取折扣
- 免费或折扣上线服务
- 试点定价（以优惠价格试用一段时间）
- “最惠客户”条款（如果你的规模足以提出此要求）
应避免的情况：
- 多年期锁定，但重大违约时没有退出条款
- 自动续约，且通知期很短（不到 60 天；应争取更长的期限）
- 从一开始就采取“就这样，不再谈判”的立场
- 未经法务审核就签约
工作流
第 1 步：明确需求
写一份一页纸的简报：我们需要什么、为什么需要、成功标准、限制条件、利益相关者。
第 2 步：自建还是采购
诚实地回答自建还是采购的问题，并记录理由。
第 3 步：生成候选名单
先广泛搜集，再通过案头调研缩小范围：
- 阅读摘要
- 浏览评测
- 查看客户徽标
- 浏览文档
- 浏览 API 规范
淘汰明显不合适的方案，最终留下 2–4 个入围候选者。
第 4 步：进行演示和试用
对每个入围候选者：
- 根据实际用例进行演示（不要接受对方默认的演示；带上你自己的用例）
- 尽可能安排试用期
- 与类似客户进行推荐访谈
- 条件允许时，使用真实数据开展试点
不要被精心制作的演示迷住。用你真实的工作流进行测试。
第 5 步：进行安全与合规审查
对于任何处理敏感数据的供应商，这一步都至关重要：
- 索取 SOC 2 / ISO 27001 报告
- 审查其安全问卷（大多数供应商都准备好了）
- 确认数据处理方式符合你的要求
- 确认分包商
对于企业级供应商，这一流程可能需要数周。尽早开始。
第 6 步：评分
使用评分表，与利益相关者协作完成评分。
评分讨论比最终分数更重要，因为它能揭示分歧（例如，一人给用户体验打了 5 分，另一人打了 2 分：为什么？）。
第 7 步：谈判
与明显胜出的供应商：
- 通过询问条款来开启谈判，而不只是谈价格
- 做好放弃交易的准备
- 适当时与排名第 2 的供应商并行谈判（为你争取筹码）
第 8 步：规划推广
签署合同是开始，而非结束。请规划：
- 入职引导负责人
- 培训计划
- 如果要替换现有供应商，制定迁移计划
- 30、90、180 天的成功标准
- 续约日历
第 9 步：记录
记录：
- 决策及其理由
- 考虑过的备选方案
- 评分卡结果
- 谈妥的条款
- 续约日期和通知截止日期
- 关系负责人
这些记录对下一次续约或类似评估非常宝贵。
常见失败模式
跳过需求定义。 先看演示，购买看起来很亮眼的产品。用了 6 个月才发现实际需求并未得到满足。
只评估一家供应商就做决定。 只和一家供应商沟通就做出决定。没有对比。很可能多付了钱，或买到的产品无法满足需求。
受个人魅力左右而做决定。 因为销售代表讨人喜欢而购买。产品是你要用好几年的东西；销售代表却未必会一直在。
只联系供应商筛选过的推荐客户。 他们的推荐客户当然都喜欢他们。请寻找供应商没有推荐的客户。
对安全问题一带而过。 因进度压力跳过安全审查，之后就会发生安全漏洞。要么放慢进度，要么明确接受风险。
演示内容与实际用例不符。 演示的是他们的默认场景，而不是你的场景。务必进行针对实际用例的演示。
试用无法模拟真实使用情况。 用合成数据试用，只能证明产品在合成环境下可用。请使用真实数据（或与真实数据非常接近的数据）。
谈判时只谈价格。 与价格低 5% 相比，条款、SLA 和退出条款对长期满意度的影响更大。
自动续约却不追踪通知期限。 续约生效，费率上涨 15%，却没人留意。追踪续约，并在通知期限前审核。
没有退出计划，却深陷供应商锁定。 与供应商的专有功能紧密集成。等你想离开时，已经无法脱身。从一开始就规划退出方案。
与未经验证的供应商签多年合同。 多年合同留给值得信赖的供应商。新供应商应选择较短期限，之后再评估。
没有内部倡导者。 选好了工具，却没人推动采用，工具就此闲置。签约前先确定倡导者。
口头承诺后才开始谈判。 “是的，我们想购买”意味着对方的谈判动力会减弱。条款谈妥前，始终保留其他选择。
忽视安全审查中的危险信号。 供应商对安全问题的回复含糊其辞或不完整。应视为拒绝信号。
把苹果和橘子放在一起比较。 供应商的定价方式各不相同（按用户、按用量或固定费用）。请按你的规模建立可比的成本模型。
输出格式
供应商评估文档包括：
- 需求摘要： 问题、成功标准、约束条件
- 自建还是采购决策： 及其理由
- 候选名单： 2-4 个入围供应商的简要说明
- 评分卡： 填写每个入围供应商的评分；如果数据不可用，则按数据可用性规则说明缺口
- 演示和试用记录： 了解到的情况
- 安全与合规摘要： 每个入围供应商的调查结果
- 推荐客户沟通记录： 客户的反馈
- 建议： 推荐哪家供应商及其理由
- 谈妥的条款： 已达成的约定
- 推广计划： 入职引导、培训、迁移
- 续约日历： 包含通知截止日期
如果所需数据不可用
此技能的输出依赖于其自身无法生成的数据、测量结果或工具结果。当所需输入、工具或数据源不可用或无法验证时，合规的输出应是交付成果，并注明缺口：需要什么、实际获取或验证了什么，以及交付成果的哪些部分受到影响。严禁捏造、估算或插值所需数值来补全交付成果。说明缺口本身就是完整答案。
参考文件
references/evaluation-rubric.md- 评分模板，包含加权维度、各维度的 1-5 分评分标准，以及一个完整的供应商比较示例。