我们如何让 AI 越用越强：1lux 自进化模型实践

一、AI 的真正瓶颈不是智商

Claude、GPT、Gemini——今天的大模型已经足够聪明。它们能写代码、能做分析、能理解复杂的业务逻辑。但在实际协作中，我们反复遇到一个问题：

同样的错误，AI 会犯两次。

上周它在 CSS 布局改动中忘了推演收起状态导致页面错乱，这周遇到类似场景，它还是会忘。上次它误诊了一个 UI 闪烁问题，把数据缺失当成代码时序问题，下次遇到类似症状，它还是会走同样的弯路。

这不是智商问题，是记忆问题。

大模型的上下文窗口是有限的，对话结束就清零。它不会从昨天的失败中学习，不会把上周的成功模式带到这周。每次对话都是一张白纸。

团队积累的经验是无限增长的，但 AI 能携带的经验是有限的。 这个矛盾，才是 AI 协作的真正瓶颈。

二、我们的解法：外循环自进化

业界解决这个问题有两条路：

我们选了外循环。

不修改模型的一个权重，而是在模型之上建一层「自进化中台」——通过结构化案例积累、执行前检索、执行后沉淀，让同一个 Claude 在 1lux 的语境下越来越准确。

打个比方：内循环是给大脑做手术（贵、危险、不可逆），外循环是给同一个大脑配更好的装备（便宜、安全、随时可换）。我们选择后者。

三、飞轮：三层架构

整个系统由三层构成，形成一个自增强的飞轮：

┌─────────────────────────────────────────────────┐
│                                                 │
│   LLM 引擎（Claude）         不变，冻结权重      │
│       │                                         │
│       ▼                                         │
│   自进化中台                  持续增长            │
│   ┌─────────────────────────────────────┐       │
│   │ 案例库 ← /case-record（执行后记录）  │       │
│   │ 案例库 → /case-check（执行前检索）   │       │
│   │ MEMORY 规则 + Skill 技能库           │       │
│   └─────────────────────────────────────┘       │
│       │                                         │
│       ▼                                         │
│   1lux 业务系统               持续产生信号       │
│   JobMorse / TechMorse / Fermi / SuperStar      │
│       │                                         │
│       └──── good/bad 信号回流 ──→ 自进化中台     │
│                                                 │
└─────────────────────────────────────────────────┘

LLM 的推理能力从不改变，但 Agent 的有效智能持续增长。

飞轮的动力来自真实业务——每一次开发、每一次部署、每一次 bug 修复都产生信号。自进化中台把信号转化为可复用的经验，下次遇到同类问题时自动调取。转得越快，AI 在 1lux 语境下越强。

四、四组件架构

自进化中台由四个组件构成，参考业界 Self-Evolving Agent 的标准架构：

生成器是 Claude 本身，我们不碰它。其余三个组件是我们构建的：

• 评价器 = /case-check 技能——每次制定方案前，自动检索案例库，找到同类历史教训（要规避的坑）和成功模式（可复用的解法）
• 记忆库 = evolution-cases.json 案例库 + MEMORY.md 核心规则 + skills/ 技能库
• 策略器 = /case-record 技能——每次执行后，判断是否值得记录，结构化沉淀到案例库

五、案例库：从失败和成功中学习

案例库是整个系统的核心资产。每条案例包含两个维度的标签：

• 技术维度（category）：css-layout / architecture / diagnosis / deploy / performance 等
• 业务维度（module）：jobmorse / techmorse / fermi / superstar / king 等

两类案例各有价值：

Bad 案例——从失败中提取防御规则：

案例：tab-group-misdiagnosis
失败：把 UI 闪烁误诊为代码时序问题，实际是配置文件缺少注册项
教训：诊断 UI 异常的顺序——数据是否存在 → 代码逻辑 → 时序
      不要跳过数据直接改代码

Good 案例——从成功中提取可复用模式：

案例：ssr-prop-passing
模式：服务端可读的数据在 server component 中读取，
      通过 prop 传给客户端组件，首帧即为最终态
适用：所有「服务端有数据但客户端才加载」导致的闪烁问题

每条案例还带有跨域标签（applicable_categories）——一条在 TechMorse 学到的教训，如果也适用于 JobMorse 和 Fermi，会被自动标记，下次在这些模块遇到同类问题时也能命中。

经验不被模块隔离，而是跨系统流动。

六、实战：同一个 bug 的三次诊断深化

以下是真实发生的案例链，展示自进化模型的核心价值：

问题：多个子系统的 tab 栏在页面刷新时先全部平铺，再收入分组，产生明显闪烁。

第一次诊断（CSS 布局）： 改导航居中方式时，只验证了展开状态，忽略了收起状态，导致收起动画丢失 + 层级遮挡。 → 教训：布局改动必须穷举所有交互状态组合

第二次诊断（数据源）： 判断为异步加载时序问题，提议加载占位符。但实际根因是配置文件里根本没有注册该模块的分组数据。 → 教训：先检查数据源是否存在，再改代码逻辑

第三次诊断（加载架构）： 数据补全后闪烁仍在。原因是数据虽然在服务端可读，却放在客户端异步获取，服务端渲染首帧永远是空状态。 → 教训：SSR 可读的数据不应客户端 fetch；单系统 bug 必须全系统审计

三次诊断形成递进链：状态覆盖 → 数据源优先 → 加载架构合理性。每次失败都让诊断能力更完整。

如果没有自进化系统，第二次、第三次遇到类似问题时，AI 大概率还会走同样的弯路。有了案例库，这些教训被永久保存，下次遇到 UI 闪烁类问题时，/case-check 会自动命中这三条案例，AI 在制定方案时就会先查数据源、再查加载架构，而不是直接改代码。

七、六大核心机制

其中最关键的是全系统审计：当在 TechMorse 发现 tab 闪烁时，我们不只修 TechMorse，而是搜索全代码库的同类模式，发现 Fermi、SuperStar、CvTab 有完全相同的问题，加上 3 个子系统的配置缺失——一次部署解决了 5 个组件的问题。

八、五级进化阶梯

业界共识的进化投入梯度，我们在 L1 到 L2 之间：

我们有意识地不做 L5（模型微调）。原因很简单：

• 成本极高（需要 GPU 集群和标注数据）
• 风险大（模型可能越训越偏）
• 被绑死在单一模型上（换模型就要重新训）

外循环的优势是模型无关——今天用 Claude，明天换 GPT，案例库和技能库一样生效。经验积累在中台层，不在模型层。

九、收敛：怎么知道系统在变强

我们定义了三个度量指标：

部署浪费率（DWR）：因方案失误导致的无效部署次数占比。下降 = 方案质量在提升。

案例命中率（CHR）：执行前检索命中案例的比例。上升 = 案例库覆盖面在扩大。

新 Category 频率（NCR）：每月首次出现新问题类型的次数。下降 = 遇到的问题趋于收敛。

当 DWR 趋近于 0、CHR 稳定在高位、NCR 持续走低时，系统就接近成熟——不是因为不再遇到问题，而是因为大部分问题都有历史经验可参考。

目前案例库只有 4 条（刚启动），这些指标还不具备统计意义。但结构已经就位，随着案例积累，飞轮会越转越快。

十、为什么这件事值得做

回到最初的问题：AI 的瓶颈不是智商，是记忆。

大多数团队用 AI 的方式是一次性的——问一句答一句，做完就忘。这等于雇了一个每天失忆的天才：能力很强，但永远在从零开始。

自进化模型解决的就是这个问题。它让 AI 协作从「一次性消耗」变成「持续积累」：

• 每次失败都沉淀为防御规则，同样的坑不会踩第二次
• 每次成功都提炼为可复用模式，好的解法自动扩散到所有子系统
• 经验跨模块流动，TechMorse 学到的教训自动保护 JobMorse
• 知识分层治理，核心规则全局生效，领域经验按需加载

我们不是在训练一个更强的模型，而是在为同一个模型持续积累更好的装备。 模型可以换，装备永远在。

这是我们理解的 AI Native 组织的核心竞争力——不是谁用了更贵的模型，而是谁积累了更深的业务经验并让 AI 能检索和复用这些经验。

飞轮已经转起来了。