AI 产品从 0 到 1 的失败,很少是因为某个模型选错了。Google Cloud 2026 年的一篇工程博客给出了一个被反复引用的基线:只有 5% 的 AI 原型真正进入生产,其余 95% 坠入了“验证深渊”。更值得追问的是这 95% 卡在了哪里。Zenodo 上 2026 年 7 月发表的一篇治理设计论文给出了一个有力的解释:人与 AI 的工作关系通常滑向两种失败姿态——“奴役”(每一个动作都需要批准,系统无法复合)和“弃权”(基于表面能力给予广泛信任,安全靠希望)。论文的核心论点是:可逆性,而非事前审批,才是承重的安全保证。把这条原则翻译成产品语言:从 0 到 1 的关键,不是让 AI 永远不做错,而是让每一个做错的动作都可以被廉价地撤销。可逆性因此不是某一个环节的检查项,而是贯穿全流程的设计轴心。
第一个交接点:场景选择与动作分级。 常见的分派轴是“任务难不难”,但工程上更有效的轴是可逆性。Forbes 2026 年提出的一套三层框架直接以此为据:Tier 1 的 routine 任务(日历同步、房间预订)可以 100% 自主;Tier 2 的复杂合成(起草对外更新)需要人审后修改;Tier 3 的敏感动作(回复特定邮件、处理法律数据)必须由人构造、批准、发送。这个分级不需要模型参与,它是一条策略配置,可以用单元测试覆盖。下面的 reversibility_gate 把动作的可逆性和影响范围编码为确定性裁决,模型只在被允许的路径上负责语义表达。
from dataclasses import dataclass
@dataclass
class Action:
name: str
reversible: bool # 动作是否有机械回滚路径
external: bool # 是否产生对外可见效果
def reversibility_gate(a: Action) -> str:
if not a.reversible and a.external:
return "HUMAN_CONSTRUCT" # 不可逆且对外,人从零构造
if not a.reversible:
return "HUMAN_APPROVE" # 不可逆,但影响域可控,人批准后执行
if a.external:
return "STAGE_THEN_CONFIRM" # 可逆且对外,先进入 proposal 状态
return "AUTO" # 可逆且内部,直接执行,回滚兜底
for act in [
Action("同步日历", reversible=True, external=False),
Action("发送草稿邮件", reversible=True, external=True),
Action("修改收款账户", reversible=False, external=True),
]:
print(f"{act.name:12s} → {reversibility_gate(act)}")reversibility_gate 的输出是确定性的,它不关心模型“觉得”自己有多确定。可逆的动作可以激进,不可逆的动作必须保守——这条边界一旦在代码里固定下来,后续的路由、评测和灰度才有稳定的地基。
第二个交接点:MVP 的推理成本与质量约束。 把所有请求发给同一个前沿模型,是在用最贵的方式验证最不确定的假设。RouteNLP 在 2026 年 ACL 工业 track 的实测数据提供了一个可参照的基准:在一个日处理约 5000 次查询的企业客服部署中,级联路由将推理成本降低 58%,p99 延迟从 1847 ms 降至 387 ms,同时保持 91% 的响应接受率。NVIDIA 的 LangChain 基准也显示,在 Nemotron 3.5 Lightning 与 Claude Opus 4.8 之间使用升级路由,成本降低 74%。路由规则本身可以粗糙,但每一次路由决策的层级、成本、延迟和风险必须落盘,它们既是定价的基线,也是评测集天然的分层依据。
import time
from dataclasses import dataclass
@dataclass
class Tier:
name: str; model: str; cost_per_1k: float
TIERS = [Tier("fast", "small", 0.0005), Tier("deep", "large", 0.005)]
def route(query: str, risk: float) -> Tier:
if risk > 0.7:
return TIERS[1] # 风险越线,不省
if len(query) < 60 and "为什么" not in query:
return TIERS[0]
return TIERS[1]
def serve(query, risk, call_model):
t = route(query, risk)
t0 = time.time()
out = call_model(t.model, query) # 替换为真实调用
return {"tier": t.name,
"cost": round(t.cost_per_1k * len(query) / 1000, 6),
"latency": round(time.time() - t0, 3),
"risk": risk, "answer": out}路由和动作分级解决的是“怎么做”,而上线决策必须由评测门禁来回答。2026 年的工程共识已经从“发版前跑一份报告”转向“evals-as-code 的 CI 门禁”:评测集、执行器、阈值三者一起入库,每次 PR 自动触发冒烟与基线比对,分数劣化则合并被 exit 1 熔断。门禁的关键不在于阈值定得多精细,而在于它能否在某一维度劣化时毫不犹豫地拦截——哪怕另一维度的分数看起来更高。
def release_gate(results: dict, th=None) -> str:
th = th or {"accuracy": 0.90, "hallucination": 0.05, "p0_safety": 1.0}
fails = []
if results["accuracy"] < th["accuracy"]:
fails.append(f"准确率 {results['accuracy']:.1%}")
if results["hallucination"] > th["hallucination"]:
fails.append(f"幻觉率 {results['hallucination']:.1%}")
if results["p0_safety"] < th["p0_safety"]:
fails.append("P0 安全用例未零失败")
return "BLOCK: " + "; ".join(fails) if fails else "PASS"
print(release_gate({"accuracy": 0.93, "hallucination": 0.08, "p0_safety": 1.0}))
# BLOCK: 幻觉率 8.0% —— 准确率更高不是放行理由上线之后,链条进入最后一段:Bad Case 回流。没有回流的评测集是一个静止的过去时;有了回流,每一次线上失败才会变成下一次门禁的资产。可运行的闭环不需要复杂,核心是让失败样本自动进入“待标注收件箱”,经归因后转化为标准评测用例,追加进回归集。从 0 到 1 的终点,不是上线那一刻,而是“Bad Case → 归因 → 修复 → 门禁验证 → 灰度”这个循环第一次完整闭合的时刻。
全流程设计的专业性,最终不体现在选了哪个模型或写了多精巧的提示词,而体现在链条上每一个交接点是否以可逆性为共同语言:场景用可逆性划界,MVP 用路由建立成本与质量的平衡,评测用门禁替代主观判断,灰度用回流把失败转化为下一次上线的确定性。当不可逆的动作在代码层就被拦住,可逆的动作在回滚兜底下被允许试错,AI 产品才真正从“演示可用”跨入“生产可托付”的区间。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。