验证是高级工程师的 AI 护城河
AI 让生成代码更便宜，但可信的生产变更仍然需要验证、判断和责任。
AI 让生产代码草稿更容易。它不会自动让软件更可信。对高级工程师来说，这个区别正在变成重要信号，因为错误生产变更的成本不会随着草稿成本下降。
Stack Overflow 2025 Developer Survey 显示了这种张力。对 AI 工具准确性表示不信任的开发者多于表示信任的开发者：46% 不信任，33% 信任，只有很小比例高度信任。经验丰富的开发者更谨慎，因为他们仍然要对发布负责。
工作转向证明
模型可以生成迁移、Kubernetes manifest、Solidity helper、监控脚本、GitHub Action 或 API endpoint。高级工程师要判断变更是否尊重真实系统：认证边界、竞态、gas 假设、链行为、依赖版本、rollback 和可观测性。
验证不能只是最后的礼貌 review。在 AI-native 工程中，验证是 workflow 设计的一部分。Agent 可以起草和比较。系统必须检查。涉及责任或不可逆操作时，人必须批准。
建立证据阶梯
强 AI workflow 给 reviewer 的不只是生成答案。它会经过多个证据层级：来源上下文、模型假设、生成的变更、自动检查、人工 review 和变更后的监控。每一层都应该增强信心，或者停止 workflow。
这很重要，因为 AI 错误常常看起来很连贯。迁移脚本可以语法正确却破坏保留规则。runbook 更新可以听起来有用，却删掉唯一有效的升级路径。交易说明可以很流畅，却隐藏错误的目标地址。
- 来源上下文：Agent 使用的文件、日志、ticket 和文档。
- 假设：模型推断但无法证明的约束。
- 检查：测试、模拟、静态分析或 policy gate。
- 审批：指定 reviewer 和其接受的证据。
- 监控：发布后确认或反驳结果的信号。
强验证包含什么
- 静态分析、type check 和 lint，覆盖基本正确性。
- 绑定真实用户或运营流程的单元、集成和 E2E 测试。
- 针对工具、secret 和生产访问的安全扫描与权限 review。
- 在部署、Safe 交易、合约交互或高影响配置变更前模拟。
- 对不可逆、高成本或安全敏感动作要求人工审批。
- 部署后监控、rollback 路径和可解释的审计日志。
为什么区块链团队要更严格
链上系统会惩罚弱验证。生成的 helper 可能通过表面测试，但破坏 accounting 假设。看似合理的 Safe 交易可能指向错误模块。监控脚本可能错过流动性事件或 oracle 事故中的关键信号。
因此，AI 应该先准备证据，再准备动作。它可以收集 diff、模拟、事件 trace、runbook 状态和签名者上下文。执行等待确定性检查和负责人的 review。
实用验证清单
- AI 改了什么，做了哪些假设?
- 哪些生产系统、权限或用户流程会受影响?
- 哪些测试或模拟能在上下文中证明变更?
- 哪个 reviewer 负责批准，需要什么证据?
- 事后哪个日志能说明动作路径?
- 如果输出错误，有什么 rollback 或人工 override?
更快的草稿只有在验证路径能抓住错误草稿时才有价值。
延伸阅读
Nexuain 实践含义
没有验证的 AI 速度不是护城河，而是运营风险。系统应阻止私钥访问、chainId 不匹配、模拟失败、未经批准的 Safe 模块或守卫变更，以及没有人工审批的资金移动。
