代码评审里最容易被忽略的风险，常常不在某一行语法上：这个配置影响几个租户？失败后谁能回滚？补丁修好了异常分支，是否改变了正常路径的超时预算？大模型适合帮忙列出这些问题，但评审意见不能直接成为部署权限。

从执行命令改成提出目标状态

2026年10月8日，CNCF 上的 让 Agent 提出下一系统状态提出一种架构取向：把建议写成可审查、可构建的状态变更，交给既有流水线处理。它是设计建议，不是“使用不可变系统就自动安全”的证明。

在 Diff 评审中，我会要求模型输出位置、风险机制、支持证据和待补充材料，而不是给一个没有定义的“风险分88”。证据至少关联提交哈希、测试结果与受影响资源。没有这些字段的结论，只能算讨论起点。

图中的 Alice、流水线编号及2024年时间戳都是示意字段，不代表一次实际部署。箭头表达职责：模型参与建议，审批与执行分别由可信组件落实。

提交、部署、服务和责任人也可以组成证据图：边表示可核实的关联，并附来源与有效时间。图谱用于定位影响范围，不能凭连通关系自动证明风险；本文没有部署图数据库。

用普通程序验证提案完整性

下面的离线检查器不判断补丁正确与否，只阻止缺少回滚说明、未通过测试或范围过宽的提案进入下一环节。approved必须来自可信审批系统，不能接受模型自己填的布尔值。

ALLOWED = {'staging/api', 'staging/worker'} def review(proposal, approval_from_trusted_service): resources = proposal.get('resources', []) failures = [] if not resources or not set(resources) <= ALLOWED: failures.append('resource_scope') if proposal.get('tests_passed') is not True: failures.append('test_evidence') if not proposal.get('commit') or not proposal.get('rollback'): failures.append('missing_provenance_or_rollback') if approval_from_trusted_service is not True: failures.append('approval_required') return failures proposal = {'resources': ['staging/api'], 'tests_passed': True, 'commit': 'demo-commit', 'rollback': 'restore_previous_revision'} assert review(proposal, False) == ['approval_required'] assert review(proposal, True) == [] assert 'resource_scope' in review({**proposal, 'resources': ['prod/all']}, True) print(review(proposal, False))

自包含示例只处理已解析的结构化数据。上线时还需要验证提交哈希确实存在、测试属于该提交、审批人有对应资源权限、证据未被替换。空检查结果表示字段层面的门禁通过，绝不表示代码没有漏洞。

怎样评估评审助手

把过去已确认的问题做成盲测，统计可定位的问题、误报和遗漏，尤其保留跨文件配置问题。提示词调整后，用同一组提交比较，不能用更容易的新样本给旧版本“证明进步”。也应记录工程师为核实每条建议花了多久。

本文没有调用真实模型、代码托管审批或部署服务。实用的第一步是让模型生成一份能被驳回的提案：证据不足就补材料，范围不清就缩范围。它帮助人作出决定，却不替审批系统签字。