写代码是便宜的，验证是贵的。但验证的本质是什么？
背景
上一篇笔记讲了 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的事，验证是你的事。
]]>
