AI Coding 验证系统的第一性原理

写代码是便宜的，验证是贵的。但验证的本质是什么？

背景

上一篇笔记讲了 AI Coding Team 的管理方法——马斯克守底线、黄仁勋守质量、雷军守价值。但那篇更偏”怎么做”，这篇要深入”为什么”。

起因是读到孔某人的文章《大组织内的AI Coding过度推行是一种饮鸩止渴》，里面提到美团31万行代码AI重构的困境：AI Coding让代码产出速度暴增，但系统复杂度增长得更快，团队的维护能力跟不上。

这让我重新思考一个根本问题：验证系统的第一性原理到底是什么？

不确定性 = 认知与现实的差距

先区分两个容易混淆的概念：

• 认知：我认为现在是什么样。关于当前现实的判断，是心智模型。
• 预期：我认为未来会怎样。关于未来的判断，是意图投影。

两者的关系：认知是预期的基础。如果认知本身就偏了，预期必然偏。

关键区别：验证只能观测当下，不能观测未来。 跑一个测试，你观测的是此刻代码的行为，跟此刻你对代码行为的认知之间的差距。用当下的观测去推断未来——那是推断，不是验证。

所以严格来说：

不确定性 = 认知与现实的差距

预期是派生的。修正认知偏差是根本。

验证做的唯一一件事：拿现实来校准认知。校准完了，认知更接近现实了，不确定性就降低了。

认知与现实的双向收敛

减少不确定性，不是让认知去匹配现实，也不是让现实去匹配认知，而是两者共同收敛到一起，凝固下来。

• 方向A：认知 → 现实（学习、验证、测试）——”我原来以为是这样，观测后发现是那样，更新认知”
• 方向B：现实 → 认知（建造、实现、创造）——”我想要这样，我造出一个东西来，让它变成这样”

产品开发是两者的交替循环：认知→建造→观测→更新认知→再建造……直到两者凝固——认知稳定了，现实也稳定了。凝固不是永久的，下一轮迭代可以重新打回流体态。

验证的强度公式

验证的严格程度，应该正比于：

验证强度 ∝ 不确定性 × 失败代价

• 芯片：后果极其严重（流片一次几百万美元），不确定性高 → 验证极度严格
• 火箭：后果是物理毁灭，不确定性极高 → 验证极度严格
• Web应用：后果是可回滚的，不确定性中等 → 验证中等
• 内部工具：后果低，不确定性低 → 验证轻量

AI Coding改变了什么？它大幅增加了”不确定性”这一侧——因为AI写的代码你不完全理解，而且产出速度极快，不确定性在以指数级累积。但”后果严重性”没有变。

所以：如果验证强度不变，风险就在指数级增长。

三层不确定性

不确定性在整个系统内是分层的：

第1层：方向/意图不确定性（根源）

“做出来的东西是不是我真正需要的？”

不确定性最大，影响最深远。美团的问题本质在这里——AI Coding让PM提出更多低质量需求，模糊的、实验性的需求都进了生产系统。代码写得再正确，方向错了也是浪费。

第2层：设计不确定性（桥梁）

“设计能不能支撑实现和未来扩展？”

AI写代码的特点是：每段局部都是合理的，但全局结构会逐渐腐化。因为AI没有”系统全局观”——它看的是当前上下文窗口里的内容，不是整个代码库的架构。

第3层：实现不确定性（执行）

“代码是不是按设计在运行？”

这是最直观的一层——单元测试、集成测试、CI/CD。AI Coding放大的主要是这一层的产出速度。

关键洞察：AI Coding放大的是第3层的产出速度，但第1层和第2层的不确定性没有同步降低。 这就是美团困境的本质——代码写得快了，但设计质量没有跟上，需求质量没有把关。

意图验证：讨论是唯一通道

意图只存在于人的脑子里，是内部状态，外部世界观测不到。要把意图从一个脑袋传到另一个脑袋，唯一的通道是符号化表达——语言、文字、图示。

所以：意图传递的唯一通道是沟通。讨论（广义的）是唯一方法。

但讨论有一个根本性缺陷：语言无法自我验证。 你说了一段话，对方说”我理解了”，你没有证据表明对方的理解和你的意图一致。

有效的方法：让对方把理解的东西具象化成可观测的产物，然后你验证这个产物。

你的意图（不可观测）
    ↓ 讨论传递
对方的理解（不可观测）
    ↓ 具象化
产物（可观测！）——复述、设计文档、原型
    ↓ 你验证
发现偏差 → 再讨论 → 再具象化 → 再验证 → ……

核心原则：永远不要问”你理解了吗？”——要问”你觉得这个需求是什么？说给我听。” 前者是噪声，后者是信号。

未知未知的暴露

认知中存在”我不知道我不知道”的盲区。无法直接消除，但可以通过碰撞间接暴露：

极端化推演：把需求推向极端，看哪里断裂。用极端场景作为探针，探测认知的边界。

红队思维：故意攻击需求。问”为什么要做这个？不做会怎样？” 每一个”为什么”都在从不同角度照射意图，暴露隐含假设。

多元视角：从用户视角、技术视角、商业视角分别审视。每个视角是一束光，照到认知中不同的暗区。

认知分层：注意力的经济学

你的全部认知可以分为两层：

不稳定层：意图、方向、业务判断。随需求和场景变化，每个项目都不同，需要注意力持续投入。

稳定层：设计审美、工程标准、架构原则。来自多年经验，跨项目基本不变，已经凝固。

注意力是稀缺资源。 稳定层如果每次都靠人工审查，就是浪费注意力。应该把它固化成验证系统，让AI自动执行，注意力就解放出来，只关注不稳定层。

转化过程：

凝固认知（主观）
    ↓ 表达成规则
客观规则（可形式化）
    ↓ 编码成工具/流程
验证系统（可自动执行）

验证系统的四种组件

验证系统不是规则的集合，是一个系统——有组件、有流程、有反馈、有边界。

检查器（Checker）：自动执行的判断，不需要人参与。类型检查、lint、自动化测试、安全扫描。

审查器（Reviewer）：需要判断力的审视，AI执行，人审查结论。AI交叉代码审查、架构审查、设计审查。

流程（Process）：事情必须按什么顺序走，每个节点有准入和准出条件。设计评审流程、合并流程、发布流程。

反馈环（Feedback Loop）：从结果中学习，更新系统本身。线上bug回溯→更新检查规则。

分层结构

L1 自动检查层（零人工成本）：类型检查、lint、测试、安全扫描
L2 AI审查层（低人工成本）：架构审查、设计审查、代码审查
L3 流程守护层（中人工成本）：设计评审、合并审批、发布流程
L4 人工层（高人工成本）：方向判断、意图确认、异常处理

越底层越频繁、越自动化、越不消耗人。越顶层越稀少、越需要判断力、越消耗人。

五条核心原则

原则1：从失败中生长，不是从蓝图中设计。 不要试图一次性设计完美的验证系统。让系统在实际运行中，从每一次失败里学到规则。问题→追溯→加检查→系统进化。

原则2：检查器优先于审查器，审查器优先于人工。 能自动化的自动化，不能自动化但可重复的让AI执行，需要判断力的人来做。进化方向：把审查器不断降级为检查器。

原则3：验证失败必须有反馈回路。 验证系统的价值不在于找到问题，在于让同类问题不再发生。修了→追溯根因→更新规则→同类问题永不再犯。

原则4：SOP是验证系统的操作手册。 精确定义：谁触发→做什么→输入什么→输出什么→谁检查→不通过怎么办。

原则5：系统的边界。 反复出现的问题、代价高昂的失败、AI容易犯的系统性错误——值得验证。一次性问题、代价极低的失败——不值得验证。

工作流程

实际操作中，我把流程简化为两个阶段：

阶段1：意图+规划 — 我和一个AI直接讨论，讨论到认知凝固，产出意图文档和蓝图。

阶段2：设计+实现 — 分配给多个AI并行工作。各自做详细设计→互相review→实现代码→提PR→自动检查+交叉review→合并→部署测试环境→我体验验证。

关键设计：

• AI做不下去时可以直接找我，不需要层层上报
• 反馈回路在每个环节都有：设计review、代码review、集成测试、我体验测试
• 逃逸到下游的问题，追溯到上游的验证缺失，补充验证

基于GitHub的实现

整个系统不需要自建基础设施，用GitHub原生工作流就够了：

• Git仓库 = 共享工作空间 + 版本管理
• PR = 提交 + Review + 反馈 + 合并
• Issue = 任务分配 + 跟踪 + 升级
• GitHub Actions = 自动化检查
• CODEOWNERS = 自动分配reviewer

仓库本身就是上下文。每个Agent clone仓库后，意图文档、蓝图、其他模块的设计文档都在里面。不需要额外的”上下文推送”机制。

系统生长路径

第1代：你直接和一个AI讨论+实现，验证靠你自己
    ↓
第2代：你讨论，分配给2-3个AI并行实现，简单PR review
    ↓
第3代：从问题中长出新机制
  - 接口对不上？→ 加接口契约检查
  - Review质量低？→ 加上下文自动推送
  - Agent卡住？→ 加阻塞自动上报
    ↓
第4代：大部分验证自动化，你只在意图层和异常时介入

写在最后

验证系统的第一性原理可以归结为一句话：

验证的本质是减少不确定性。不确定性 = 认知与现实的差距。

所有验证方法——测试、review、CI、讨论对齐、用户反馈——都是在做同一件事：用观测来缩小认知和现实之间的差距。

在这个AI Coding的时代，写代码越来越便宜，但认知和现实之间的差距不会自动缩小。你的价值从”能写代码”变成了”能定义正确的问题”和”能建验证系统来保证答案是对的”。

黄仁勋说得对：写代码是便宜的，验证是贵的。但更准确的说法是——写代码是AI的事，验证是你的事。