7.7
深览指数
科技Bestblogs·浮之静··AI 生成
Noi 编程实战：Fable 没那么强，GPT 也没那么弱
本文通过 Noi 项目中一个插件兼容 bug 的完整调试过程，对比了 Fable 与 GPT Codex 在实际复杂工程问题上的表现。作者指出，Fable 因安全限制拒绝分析插件源码，暴露出封闭模型在工程调试中的适用边界；而 GPT 在收到通用指令后自主设计了 A/B 实验，成功定位并修复了根因——兼容层错误抢占原生系统能力。文章核心贡献在于提出一种可迁移的复杂调试方法论：设计能改变判断权重的实验而非追着报错修，以及责任链闭合比局部补洞更重要。适合有实际 AI 辅助编程经验、对 Agent 工程可靠性问题感兴趣的读者。原文 ↗
核心观点
- ▍复杂系统调试不能只追报错，需要设计能改变判断权重的实验，A/B 实验比日志追踪更能接近根因。
- ▍兼容层作为适配中间件，应只补缺口，不应抢走原生系统已实现的能力，否则会造成责任链断裂式的 bug。
- 01Noi 项目中，Chrome 插件在一个受硬件加速环境影响的页面上渲染失败，错误日志指向 content_script 加载问题，但局部修补无效。
- 02Fable 因模型安全策略拒绝分析插件源码，直接退出调试过程，暴露了封闭式模型在无法解构黑箱时的局限。
- 03GPT Codex 初期被错误日志误导，进行了一系列无效的局部修补；在收到「你自己去 debug 吧」的指令后，主动设计了一个 A/B 实验：保留原生 runtime messaging 而非用兼容层覆盖。
- 04A/B 实验的结果是页面渲染成功，由此发现根因：兼容层错误地抢占了 Electron 原生的 runtime messaging 能力，且后台生命周期尚未就绪。
- 05文章介绍了 Noi 的 AgentOS 架构中 Harness 的「意图→文档→代码→证据→架构优化」自进化闭环，作为复杂工程调试的组织框架。
反方 / 局限
- — GPT 的成功依赖长时间探索和大量 token 消耗，这种高成本模式在简单调试任务中可能不经济；Fable 的退出虽然失败，但背后是明确的策略约束而非能力不足。
3 分钟 · 4 卡片 · 9 资料
读原文 →