企业评估 AI 测试平台时，最容易出现一种错觉：两小时演示里，需求一粘贴，用例自动生成，接口脚本也能运行，缺陷报告写得像模像样，于是 POC 被判定“成功”。
三个月后却发现：真实需求文档无法稳定解析；平台拿不到测试环境权限；生成的 300 条用例只有 20 条值得保留；模型费用没人算；最关键的支付链路又不敢让它执行。
问题不是 AI 没能力，而是 POC 回答错了问题。
POC 不是验功能，而是验证组织能不能承担它
一个平台在理想数据、管理员账号和厂商工程师陪同下跑通，只能证明“存在成功路径”。采购决策需要确认的是：在本企业数据边界、权限体系、研发流程和预算下，它能否长期运行。
因此，第一步不是列 50 个功能打勾，而是设一票否决项：测试数据能否按规则脱敏与删除；不同租户是否隔离；写操作是否最小权限并支持人工确认；模型、提示词、知识与工具版本能否追溯；平台退出时资产能否导出。
用真实工作量建立人工基线
平台说“效率提高 70%”没有意义，除非你先知道当前流程耗时多少。选择两条业务链路：一条高频但风险中等，例如会员营销；一条低频但损失高，例如退款或资金审批。让同一组变更分别走现有流程与平台辅助流程，记录：
从需求到首版测试策略的净工时；
生成用例的采纳、重写和删除比例；
有效缺陷数、重复缺陷和误报；
回归反馈时长以及失败定位时间；
模型调用、环境、接入与人工复核成本。
不要让“生成数量”进入核心 KPI。生成 1000 条、最终删掉 900 条，是负收益。
把评分规则写成机器也能检查的门禁
下面这份简化代码体现两个原则：硬门禁不能被平均分冲掉；质量收益要同时考虑有效缺陷和误报成本。
HARD_GATES = {"tenant_isolation", "audit", "human_confirm_write", "asset_export"}
WEIGHTS = {"quality": 0.30, "integration": 0.25,
"reproducibility": 0.20, "tco": 0.25}
def poc_decision(evidence: dict) -> dict:
failed = [name for name in HARD_GATES if not evidence["gates"].get(name)]
if failed:
return {"decision": "STOP", "failed_gates": sorted(failed)}
score = sum(evidence["scores"][name] * weight
for name, weight in WEIGHTS.items())
return {
"decision": "BUY_WITH_CONDITIONS" if score >= 80 else "NO_BUY",
"score": round(score, 1),
"conditions": evidence.get("open_risks", []),
}
评分的输入必须是证据，不是现场印象。比如“可复现”要用一次历史失败回放证明；“可接入”要在企业自己的 CI、缺陷库和身份系统里跑；“可退出”要真的导出一次用例、报告和轨迹。
