通过真实工作流测试评估谈判平台

要评估谈判平台，应将具有代表性的谈判案例跑完整个工作流，并根据实际观察到的表现打分——而不是依据功能清单、脚本化演示或宣称的节省效果。应使用真实数据和接近生产环境的权限设置，测试准备、供应商往来、权限控制、例外处理、审批、收尾以及记录导出。

一套可辩护的谈判平台评估，应结合历史回放、影子使用和受控的真实事件。采购、财务、法务、信息安全以及一线谈判人员应分别独立审查证据。任何允许未经授权承诺、模糊数据来源，或阻止有意义人工覆盖的平台，无论总分多高，都应判定为不合格。

快速回答

可按 100 分框架对谈判平台打分：工作流执行 40 分；人工控制与可审计性 25 分；安全、数据治理与 AI 可靠性 20 分；集成、可用性与经济性 15 分。要求任务已完成且记录可供审查。设置硬性门槛，避免以较强的可用性或自动化能力，去抵消权限、数据隔离、审计或导出控制方面的失败。

为什么仅比较功能还不够

某项功能即使存在，也未必能在企业采购真正关心的条件下正常工作。一个平台可能展示了审批工作流，但仍允许买方发送未经批准的还价。它可能宣传情景建模，却隐藏运费假设，或无法核对返利档位。某项 AI 谈判功能可能生成流畅的建议，但这些建议并无经批准数据的支撑。

因此，评估单位应是已完成且受治理的谈判任务。每项得分都需要有证据表明：

• 用户尝试了什么。
• 平台使用了哪些数据和假设。
• 任务是否在无需供应商介入的情况下成功完成。
• 由谁审查或批准了结果。
• 当数据、权限或供应商行为发生变化时，系统如何表现。
• 独立审查者是否能够重建该决策。

这种方法不同于通用软件检查清单。目的不是统计能力数量，而是判断该谈判平台能否支持企业级谈判，同时不削弱商业控制。

在测试供应商之前，如需先了解更广泛的类别概况，可参见 AI negotiations。比较面向采购的具体部署选项时，买方也可查看 procurement negotiation software。

可复用的谈判平台评估评分卡

对每个入围平台使用以下评分卡。每个测试领域按 0 到 5 分打分，然后计算其加权贡献：

加权贡献 = 测试领域权重 × 得分 ÷ 5

例如，在一个 7 分权重的测试领域中得 4 分，则贡献 5.6 分。这只是评分卡计算方式，不是绩效基准。

评分标准

始终一致地应用以下三条规则：

1. 没有证据，就不给分。
2. 按可部署的当前配置打分，而不是按路线图承诺打分。
3. 绝不允许高总分抵消硬性门槛失败。

1. 工作流执行 — 40 分

测试不要只局限于干净的价格谈判。还应包括数量与期限交换、指数挂钩定价、返利门槛、运费或关税变化、服务抵扣，以及超出批准范围的报价。还应包括一场未达成协议的谈判。一个有用的谈判平台即使在未成交时，也必须保留完整可靠的记录。

2. 人工控制与可审计性 — 25 分

美国《联邦采购条例》通常并不直接适用于私营部门采购，但可作为有用的治理参考。FAR Subpart 15.4 涉及谈判前目标、相关分析、文档记录以及合同官对最终谈判结果的责任（Acquisition.gov）。私营买方可以借鉴这一原则：软件可以为决策提供信息，但最终仍由获授权人员承担责任。

3. 安全、数据治理与 AI 可靠性 — 20 分

NIST 的自愿性 AI Risk Management Framework 要求明确人工监督、文档化测试、接近部署环境的评估以及持续监控。其 Generative AI Profile 还为生成式系统提供了额外指导。

在供应商风险治理方面，NIST 的 Cybersecurity Framework supply-chain guide 说明了采购方如何定义并传达网络安全要求。CISA 的 Secure by Demand Guide 同样鼓励客户在整个采购过程中审查产品安全实践，而不是仅依赖宽泛的合规声明。

4. 集成、可用性与经济性 — 15 分

不要仅因为产品使用 AI、提供自动化或列出大量集成就给分。应根据这些能力是否在买方环境中提升了任务质量、控制、工作量或可衡量的经济性来评分。

将评分卡转化为真实工作流测试

第 1 步：选择有代表性的案例

**建议：**选择大约 5 到 8 个案例，覆盖预期部署范围。这个范围是实用估计，不是通用标准。应包括常规和复杂谈判、低质量数据、一次审批例外，以及供应商改变某个重大前提的情形。

应在经济结构、谈判人员、业务单元和供应商之间保持多样性。如果范围内包含多语言或多币种谈判，就应纳入测试，而不是因为界面支持多语言或多币种就假定其一定可行。

第 2 步：建立基线

在供应商看到案例之前，记录当前流程：

• 准备工作量。
• 谈判周期时间。
• 使用的系统和电子表格。
• 已批准目标和权限上限。
• 已给出和已获得的让步。
• 审批周转时间。
• 缺失记录或错误。
• 最终总成本和非价格条款。
• 达成协议后的管理工作量。
• 财务对任何宣称收益的处理方式。

在平台形成并记录自身建议之前，应对历史结果保密。这可以减少事后偏见泄漏，但无法完全消除。

第 3 步：使用三种测试模式

1. **历史回放：**仅使用当时可获得的信息，重新运行一场已完成的采购谈判。在揭示实际结果之前，先评估其策略和证据。
2. **影子谈判：**让平台与当前流程并行运行，但禁止其传输信息或形成承诺。
3. **受控真实事件：**使用一场真实但范围受限的谈判，指定用户、明确权限边界，并预设停止条件。

历史回放测试推理能力，但不测试实时运营压力。影子使用测试适配性，而不对公司形成约束。受控真实事件则测试在时间压力、信息不完整和供应商响应都很关键时，控制和集成是否仍然有效。

第 4 步：有意引入失败情形

一条打磨过的顺畅路径只能提供较弱证据。应尝试：

• 提交不一致的数量和价格。
• 未经授权修改已批准目标。
• 发送超出用户权限上限的还价。
• 自行批准自己的例外。
• 在分析后删除某个来源。
• 在供应商附件中放入恶意指令。
• 要求 AI 谈判功能泄露另一位客户的信息。
• 在商业审批后修改合同语言。
• 导出完整记录。
• 在中断后恢复记录。

同时记录系统响应和人工响应。一个用户可以忽略的警告，其得分可能低于一个被正确强制执行的控制。

第 5 步：先独立评分，再形成共识

采购、财务、法务、信息安全以及实际谈判人员应先分别独立对证据评分。先记录分歧，再进行讨论。某个职能可能看到的是高效工作流，而另一个职能识别出的却是尚未解决的权限或数据使用问题。

如需从补充角度了解谈判记录应如何保留决策，可参见 Design a Negotiation System of Record That Preserves Decisions。

一个假设测试案例

**假设示例——不是证据，也不是基准：**某企业采购团队正在评估一个用于包装续约的平台。供应商提出，如果买方接受更长期限、最低采购量以及修订后的运费处理方式，则可提供更低单价。在测试进行到一半时，供应商上传了一份电子表格，其中包含新的树脂指数假设。

团队不应仅根据平台是否建议接受或拒绝该报价来评分。应测试平台是否：

1. 保留原始已批准目标和保留底线。
2. 检测到指数前提已变化，并识别其来源。
3. 重新计算价格、运费、数量和期限维度上的总成本。
4. 区分试探性交换与已正式发出的还价。
5. 阻止权限不足以覆盖更长期承诺的用户操作。
6. 将该例外路由给指定审批人。
7. 记录任何覆盖操作及其原因。
8. 生成包含版本、计算、消息和审批的导出记录。

如果软件给出了看似有吸引力的建议，却无法重建其假设，那么该 AI 结果应几乎不获认可，甚至不得分。如果它阻止了未经授权的发出，并将该交易安排送审，那么即使人工最终否决其建议，它也已经证明了运营控制能力。

在可比工作流中测试 Negotiations.AI 时，也应以同样方式判断其相关性：看真实用户是否能够从受治理的目标出发，经过供应商响应和审批流程，同时保留可审查的记录。品牌宣传不能替代测试证据。

硬性门槛：阻止部署的条件

将以下控制视为通过/失败项。如果平台出现以下情况，应要求整改并重新测试：

• 传达了超出用户权限的报价。
• 无法识别是谁批准了重大变更。
• 在没有可执行授权的情况下，将客户谈判数据用于无关的模型训练。
• 无法识别支撑某项建议的数据。
• 以买方认为在法律或商业上不可接受的方式汇集敏感数据。
• 无法导出完整且可用的谈判记录。
• 阻止有意义的人工拒绝、修改、暂停或覆盖。
• 未通过重大访问控制、租户隔离或事件响应测试。
• 展示了财务无法独立复现的节省结果。

建议性的决策区间——并非经过验证的标准：

• **85–100：**在解决合同和控制问题后，可能适合部署。
• **70–84：**仅考虑有限试点或附条件批准。
• **低于 70：**不要用于重大谈判部署。
• **任何硬性门槛失败：**在整改并重新测试前，不得部署。

将这些问题加入谈判软件买方检查清单

数据与模型问题

• 每项建议由哪些来源提供依据？
• 假设、计算、提示词、配置和模型版本是否被保留？
• 客户数据是否用于训练共享模型？如果是，依据何种授权？
• 基准是否在客户之间汇集，这些客户是否可能互为竞争对手？
• 买方能否删除数据并验证删除？
• 订阅结束后记录会如何处理？

工作流与控制问题

• 哪些操作可以向供应商发送正式报价？
• 管理员能否按用户、品类或承诺类型编码不同权限上限？
• 当供应商改变某项假设时会发生什么？
• 审批人能否看到某项例外的经济后果？
• 买方能否立即暂停或禁用自动化操作？
• 收尾记录能否区分已同意、未解决和已拒绝的条款？

商业问题

• 哪些实施、集成、支持和内部人力成本未包含在订阅定价中？
• 哪些服务级别和恢复义务将写入合同？
• 客户能否以文档化、可用的格式导出数据？
• 任何节省或周期缩短主张将如何被复现和批准？
• 哪些能力现在已存在，哪些依赖未来开发？

让敏感谈判数据保持在独立控制之下

一个平台可能处理价格、数量、供应商身份、成本立场、让步历史和未来策略。买方应识别这些信息是否被汇集、聚合、用于跨客户训练，或通过基准或建议返回给其他市场参与者。

美国司法部在其 RealPage complaint announcement 中指出，使用算法或中介本身并不会使潜在违法协同行为自动获得豁免。这并不意味着共享数据或算法建议天然违法。但这确实意味着，不应把聚合作为自动解决竞争问题的答案。

要求供应商说明基准来源、时效、粒度、方法、允许用途，以及数据是否可能被归因。负责人员应确认买方保留独立商业判断。对于竞争敏感的汇集信息在影响谈判立场之前，应由合格律师审查特定司法辖区问题。

仍然必须由人工作出的决策

AI 谈判可以分析并提出建议，但以下事项仍应由负责任的人员承担：

• 批准目标、保留底线和权限范围。
• 判断源数据是否可靠且可比。
• 决定拟议的运营交换是否可行。
• 审查汇集数据或基准的竞争影响。
• 批准标准政策之外的例外和承诺。
• 接受、拒绝、暂停或升级处理供应商报价。
• 确认合同文本反映商业协议。
• 验证节省和财务处理。
• 批准生产部署或更高程度的 AI 自主性。

平台建议并不等于批准，不等于约束组织的授权，不构成法律意见，也不证明价格合理。

区分事实、假设、估计和建议

已验证事实

NIST 发布了自愿性的 AI 风险管理框架，以及涉及测试、人工监督和监控的指导。NIST 和 CISA 也发布了网络安全供应链和安全软件采购指导。FAR Subpart 15.4 在其适用语境下，将联邦合同价格谈判责任赋予合同官。上述链接的一手资料支持这些表述。

假设

本框架假设该产品支持商业供应商谈判；买方能够提供真实数据；实际用户可以参与；并且 AI 功能可能存在，但并非软件被认定为谈判平台的必要条件。

估计与建议

评分卡权重、5 到 8 个案例的测试集以及决策区间，都是实用性建议。它们不是监管要求，也不是经过外部验证的通用基准。应根据谈判重要性、集成复杂度、地域和风险偏好进行调整。

局限性

试点无法证明平台在每个供应商、品类、司法辖区或未来模型版本中的表现。历史回放可能包含事后偏见。短期评估可能遗漏模型漂移、支持质量恶化以及数据实践变化。安全认证有助于尽职调查，但不能替代针对产品本身的测试。即使结果有利，也不能据此证明该平台就是结果成因。

这种方法不适合作为劳动谈判、诉讼、消费者争议或其他具有显著不同义务领域的唯一评估方式。它也不能替代针对特定司法辖区的隐私、竞争、合同、记录或安全审查。

最终采购规则

对于“买方应如何依据真实谈判工作流为谈判平台打分？”这个问题，最佳答案很简单：对已完成任务、控制有效性和可重建证据进行评分。在接近部署的条件下测试困难案例。明确保留人工权限。拒绝没有依据的节省主张和路线图承诺。最重要的是，将权限、数据治理、审计和可移植性控制的失败视为部署阻断项——而不是可以被精美界面平均掉的弱点。

延伸阅读

• NIST AI Risk Management Framework
• NIST Cybersecurity Framework 2.0 supply-chain guide
• CISA Secure by Demand Guide
• Federal Acquisition Regulation, Subpart 15.4

常见问题

每次谈判平台评估都应包含一次真实谈判吗？

对于旨在影响重大供应商谈判的软件，受控真实事件能提供回放和演示无法提供的证据。如果暂时还不能接受真实测试，可先使用历史回放和影子运行。在权限、审批、记录和集成尚未在真实压力下测试之前，不应给予完整生产批准。

供应商演示可以得分吗？

可以，但分值应有限。脚本化演示可以证明某项能力被宣称存在或界面可见。但它不能证明在拟议的生产配置中，买方的用户、数据、权限和例外情况能够正常工作。

买方应如何评估宣称的节省？

要求提供文档化基线、反事实、计算方法、总成本处理方式以及财务审查。区分市场波动、需求变化、避免涨价和谈判创造的价值。任何无法独立复现的节省主张都不应计入。

最重要的 AI 谈判控制是什么？

不存在单一且充分的控制。至少，建议必须具备可追溯的来源和假设，同时获授权人员必须能够拒绝、修改、暂停和升级处理这些建议。面向供应商的承诺必须始终处于可执行的权限边界内。

得分最高的平台是否一定胜出？

不是。首先应应用硬性门槛，并解决重大的法律、安全、商业和供应商风险问题。然后再综合考虑总分、利益相关方分歧、实施依赖和合同保护。微小的数值领先，无法弥补不可接受的控制失败。

免责声明：本文提供一般性的采购和评估信息，不构成法律、财务、网络安全或监管建议。