洗心岛1. 一次事故现场：说好的碳硅协同，变成了AI挖坑、人填坑
2024年下半年，我给自己定了一个很高调的开发关键词：碳硅协同。当时的想法很简单——我是碳基工程师，大模型是硅基队友，两边各干各自擅长的事，软件的产出效率就能翻倍。这种论调在圈子里已经流行过一阵，不过我自己真正动手跑过几个小项目之后，发现事情远没有那么美好。其中一个叫“会员积分模块重构”的小项目，几乎让我把“协同”两个字从词典里划掉。
事故发生在周日晚上的线上环境。运营那边启动了一个秒杀活动，活动结束后大量用户反馈积分不对：有的人秒杀订单该到账的积分没到，有的人却被加了两份。我们紧急翻查代码，最后定位到的问题让人哭笑不得——积分明细和账户余额之间的一致性被新逻辑打破了。
旧系统的设计其实非常朴素：积分账户表永远只有一个来源，就是积分变动流水表。新增积分的操作必须同时做两件事，先插入一条流水，再更新账户余额，这两步在同一个数据库事务里完成。可那天晚上同事为了赶需求，让AI助手直接改了代码生成逻辑。AI生成的实现看起来每一步都合理：检查订单状态、生成积分变动记录、更新账户余额。但它在生成过程中漏掉了系统一个极其重要的隐藏契约：下游有个定时对账任务，每天会扫描账户余额表，如果发现累计流水和余额不一致，就会触发自动修正，修正逻辑是按照最近N天的流水重新计算余额。
结果就是，流水先写入、余额还没更新，对账任务跑过来发现账不平，主动重算并加了一次分；随后业务回调里原来的逻辑又正常执行了一次，又加了一次分。用户拿到的积分就这么翻倍了。只看AI生成的那段代码，逻辑是自洽的、局部正确、甚至测试都写得挺规范，但它根本不知道这个老系统里还存在一个“自动修正”的队友。
那次事故之后我专门在项目笔记里写了一句话：如果我们不能让AI在动手写逻辑前先理解系统的契约，那它产出的代码就像实习生在一家老店后厨乱炒菜——每道菜看起来都会做，但不知道灶台的脾气、老板的规矩、高峰期谁先谁后。
这句话最终演化成了“碳硅协同开发篇”整个系列的基础。我在复盘那次积分事故时正式决定：不能让AI在完全自由的状态下直接产出可上线的业务代码。于是有了这篇文章的主角——ELR。ELR一开始并不是产品名，也不是什么开源框架，它只是一个内部代号，代表一套我反复迭代出来的人机协作闭环。项目名字取的是三个英文单词的首字母：Explain、Learn、Review。这套东西诞生的过程很平淡，没有华丽的顶层设计，全是靠一次一次填坑填出来的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. ELR不是框架，是一套被真实项目逼出来的协作闭环
很多团队都把AI辅助开发理解成“给AI一个需求，让它自己写完代码，人等着验收”。但我自己的实践和经验是，这种理解在简单页面或一次性脚本上确实成立，一旦碰到有历史包袱的核心业务模块，几乎必然翻车。原因非常简单：**企业级业务系统的真实约束，绝大部分不在代码里，而在流程、历史数据、上下游约定、补偿机制和对账规则里。**这些东西不会出现在需求文档中，AI光凭阅读代码库很难完整推断出来。
ELR之所以被我反复打磨，就是因为它试图解决这个核心矛盾