devgo.cnAI 编码把瓶颈从"写"挪到了"验证"：代码产出变便宜了，但每一行仍然需要被证明是对的。美团基础技术部在分布式存储系统里的结论更硬——在一致性、并发、持久化、故障恢复每一项都会碰到的系统里，AI 的正确用法是当假设生成器和验证助手，而不是当作者。谁把"变绿"当成"解决"，谁就在给自己埋故障。
为什么这个问题在存储系统里被放大
同样的人力，一个版本能交付的功能更多、改动的代码也更多。就算 AI 写的代码千行缺陷率和人持平，单个版本累计引入的缺陷绝对数量照样上涨。这是道算术题，不是态度题。
分布式存储把这个算术放大了一个量级：
- 代码规模大、模块耦合深，一处看起来局部的改动，平时一切正常
- 问题要等节点重启、磁盘异常、网络抖动或高并发才暴露
- 出事影响的不只是某个功能，而是上层业务的数据可用性，严重时是数据正确性
- 存储服务托着大量上层业务，故障影响面大、修复也难
所以这里的门槛不是"AI 能不能写出能跑的代码"，而是"AI 写的代码进不进得了评审流程"。答案是：光生成不够，AI 评审、AI 测试验证、AI Debug、受控自动化必须一起建起来。
AI 评审：它强在跨文件落差，弱在设计背景
原文给了一个很典型的例子，值得记住它的形态：`ENABLE_UNITTEST` 在三处调用点控制测试 mock 变体的编译分支，CMake 迁移把名字换成了 `WITH_UNITTEST`，旧名字再没被赋过值。单看任何一个文件都挑不出毛病——这个 bug 只存在于文件和文件之间的落差里。这正是 AI 的舒适区：跨文件搜索、比对、对齐，人类容易漏，机器不会累。
第二个能力是构造可执行证据。AI 说"这里没做边界检查"之后没有停，而是造了一个声明 1 GiB、实际包体只有 5 字节的畸形包，打到真实解码入口，把崩溃现场抓了出来。这个动作的性质和"提了个 review 意见"完全不同——它交付的是现场。
第三个能力常被忽略：承认自己证明不了。一处疑似并发竞态，AI 走读找到可疑路径，然后明确说明要证实这段交错时序需要 ThreadSanitizer，当前工具链跑不了，于是标成"未验证"，没有直接定性为缺陷。这种"标注边界"的自觉，比多找十个问题更有价值。
但它替代不了人对设计背景的判断。评审意见里最贵的部分从来不是"这行有隐患"，而是"这个改动违反了我们当初为什么这样设计"。
AI Debug：假设生成器，不是根因判断者
分布式存储的故障取决于并发时序、节点角色、持久化状态、恢复过程、外部依赖和运维操作，AI 拿到的通常只是其中一部分。它极容易找到一条"能解释现象"的代码路径，却没有证明线上当时真的走过这条路径，也没有证明别的原因产生不了同样的结果。这两件事缺一件，根因就不成立。
它真正擅长的是四件事：
- 把不同节点的日志、监控指标、调用栈、配置和变更对齐到同一条时间线上
- 同一现象并行给出多个可验证候选，每个候选列出必要条件和缺失证据
- 把代码里的条件、阈值、执行顺序转成明确实验预期，并设计能区分不同解释的对照
- 结合新证据持续缩小问题空间，而不是死守第一个假设
原文那个"空格丢失"的案例最能说明问题：AI 用单点实验确认服务端会删除首尾空格，据此归因服务端；人工要求继续查客户端后，AI 把问题改成对照实验——记录客户端计算签名时的内容、实际发送的内容、服务端收到并重算签名的内容，逐段比较第一次差异出现在哪。结果是客户端先按带空格的内容算签名，发送前又删掉空格，签名与实际内容不一致。单点事实是真的，因果位置是错的。
最容易制造的三类错觉
原文的结语把话说得很直：流畅不是证据，一致不是正确，变绿不是解决。
- **流畅不是证据**：分析写得完整、带着行号，只说明它好复核，不说明结论正确。输入不完整时它照样敢给确定的因果链。
- **一致不是正确**：静态分析发现一条危险路径，只是一个风险候选。要认定它是本次故障原因，得证明触发条件在真实运行中能同时满足，并排除已有保护措施的拦截。原文那个"编号重复"的误报就是这么来的——新对象编号由统一分配器保证唯一，AI 把一处局部查询当成了防重复的关键检查。
- **变绿不是解决**：改断言、引入永远成功的替身、跳过依赖真实 KMS 的用例，都能让 CI 变绿，但验证范围已经变了。原文点得很清楚：CMake 改造里用 `_exit` 跳过全局析构来避免退出崩溃，就是典型的"绕过去了"。
还有一条容易被漏掉：为解决局部问题不必要地扩大修改范围。改任务范围外的源码、调公共构建逻辑、放宽检查——当前失败是绕过了，代价是把后面的错误盖住。
可以直接抄走的做法
- 关键验证要走红绿闭环：修复前能稳定复现并变红，修复后同条件变绿，撤回修复又能变红
- 复现走真实入口，让系统自己产生中间状态，不要直接改内部对象，也不要灌生产里到不了的值
- 怀疑基础库/编译器/操作系统之前，先核对编译宏、头文件与库版本、链接顺序、接口签名、运行目录、测试初始化
- 每个结论都要可证伪：写清触发条件、依据证据、以及怎么才能证明它是错的；没有证据的只能标成假设或待验证
- 根因修复、临时绕过、未验证事项分开记录，别让"这次为什么恢复"冒充"为什么会发生"
- 分层授权：只读分析 → 受控修改 → 受控执行 → 人工决策，逐级放开；改公共配置、删数据、发布上线必须由人确认
- 领域知识要显式化并跟着代码维护：架构说明、关键不变量、Review 清单、故障案例、测试规范，写下来给 AI 用，过时了就更新
最后一条判断标准值得贴在工作台上：团队从 AI 那里能拿到多少收益，看的不是生成了多少代码，而是验证能力跟不跟得上生成的速度。边界划得越清楚，AI 能放手干的范围反而越大。
内容与图片版权归原作者所有 · 原文: https://tech.meituan.com/2026/10/29/AI-Coding-IN-Distributed-Storage-System.html