自动化反馈循环
Archon Protocol 的核心引擎——为什么说它是一套自我强化的反馈工具链。
什么是"反馈循环"
传统开发中的反馈循环：
人写代码 → CI 检查 → 人修复 → CI 再检查 → ...反馈延迟：分钟到小时级。修复质量取决于人的经验和注意力。
Archon Protocol 的反馈循环：
AI 写代码 → AI 实时审计 → AI 自修复 → AI 验证 → 新经验写入规则 → 下次更强反馈延迟：秒级。修复质量由规则体系保证，且越用越好。
Demand 循环详解
Demand 循环是这个反馈循环的具体实现。一次 /demand 调用触发完整的 5 阶段闭环：
┌──────────────────────────────────────────────────────┐
│ │
│ Stage 1: 实现 │
│ ────── │
│ AI 在规则约束下编写代码。 │
│ 约束 Skill 的禁止项在这一步就已经生效。 │
│ 编辑 JSX？async-loading skill 约束生效。 │
│ │
│ ▼ │
│ │
│ Stage 1.5: Linter 验证 │
│ ────── │
│ 运行项目 Linter，读取错误，修复。 │
│ 协议拦截架构问题，Linter 拦截语法问题。双层防线。 │
│ │
│ ▼ │
│ │
│ Stage 2: 性能审计 │
│ ────── │
│ 对照项目性能文档逐项检查： │
│ • 列表渲染的 Link 有 prefetch={false}？ │
│ • 异步区域有骨架屏？ │
│ • 屏幕外内容用了视口懒加载？ │
│ │
│ ▼ │
│ │
│ Stage 3: 六维自审 │
│ ────── │
│ 3.1 约束合规 — 搜索所有 ❌ 禁止项是否被违反 │
│ 3.2 代码结构 — 文件大小、职责单一、无循环依赖 │
│ 3.3 边界条件 — null、空数组、0、负数、超大值 │
│ 3.4 测试同步 — 修改了源码？对应测试必须更新并通过 │
│ 3.5 国际化 — 新字符串用了 t("key")？所有语言有？ │
│ 3.6 知识进化 — 这次任务发现了新的反模式吗？◄── 关键！ │
│ │
│ ▼ │
│ │
│ Stage 4: 修复 │
│ ────── │
│ Stage 3 发现的所有问题，逐一修复， │
│ 重新运行测试直到全部通过。 │
│ │
│ ▼ │
│ │
│ Stage 5: 提交 │
│ ────── │
│ 生成 conventional commit，只提交相关文件。 │
│ │
└──────────────────────────────────────────────────────┘自进化机制（Stage 3.6）
这是整个系统最关键的部分。
Stage 3.6 不只是审计——它是系统的学习机制。
每次 Demand 循环结束时，AI 会问自己一个问题：
"这次任务中，我是否遇到了一个之前约束 Skill 没有覆盖的反模式？"
如果答案是"是"：
| 发现 | 动作 | 效果 |
|---|---|---|
| 新的反模式 | 写入 proposed-rules.md（隔离区） | 等待审查 |
| 新的最佳实践 | 写入 proposed-rules.md（隔离区） | 等待审查 |
| 新的架构决策 | 更新知识文档 | 下次 AI 理解项目时，决策一致 |
进化安全：隔离区机制
发现的规则不会直接写入约束技能。它们进入 proposed-rules.md——一个等待审批的隔离区。这防止了：
- 噪音累积：AI 将个例泛化为通用规则
- 自相矛盾：新规则与现有规则冲突
- 质量退化：模糊或不可测试的禁止项混入系统
规则只有在以下条件满足后才能毕业到约束技能：
- 用户审查并明确批准，或
- 通过自动化质量检查（
prohibition-quality.test.js）和矛盾检测（ecosystem-integrity.test.js）
进化过程：
第 1 次任务：AI 可能犯错 X
↓ Stage 3.6 发现 X 是反模式
↓ 写入 proposed-rules.md（隔离区）
↓ 用户批准 → ❌ 禁止 X 写入约束技能
第 2 次任务：AI 在 Stage 1 就被阻止犯错 X
↓ Stage 3.6 可能发现错误 Y
↓ 同样的流程 → 批准 → ❌ 禁止 Y
第 N 次任务：规则体系越来越完善
AI 在 Stage 1 就已经被全面约束
自审发现的问题越来越少
代码质量单调递增这就是"自动化反馈循环"的含义——不是简单地检查和修复，而是每次循环都让下一次循环更有效。
与传统 CI/CD 的关系
Archon Protocol 反馈循环 传统 CI/CD
──────────── ──────────
编码时实时约束 提交后才检查
AI 自修复 人工修复
发现新反模式自动写入约束 Skill 手动维护 lint 规则
秒级反馈 分钟级反馈
每次循环自我增强 静态规则集Archon Protocol 不是替代 CI/CD。理想的工作方式是：
- Archon Protocol：编码阶段的实时约束和自审（预防）
- CI/CD：提交后的最终验证（兜底）
两者共同构成双重安全网。Archon Protocol 把大部分问题在编码阶段就消灭了，CI/CD 捕获漏网之鱼。
反馈链路图
人类提一句需求
│
▼
┌─── Demand 循环 ────────────────────────────────────────┐
│ │
│ 实现 ──► Linter ──► 性能审计 ──► 六维自审 ──► 修复 ──► 提交 │
│ │ │
│ 发现新反模式？ │
│ │ │ │
│ 是 否 │
│ │ │ │
│ 写入 proposed-rules.md 跳过 │
│ │ │
└───────────────────────┼────────────────────────────────┘
│
▼
用户审批后规则入库
│
▼
下次 Demand 循环更强
│
▼
代码质量单调递增这是一个正反馈循环：做的任务越多 → 规则越完善 → 代码质量越高 → 需要修复的问题越少 → 交付速度越快。
实际案例
以本项目的开发经历为例：
第一次重构 Admin Dashboard
- 发现：多个 API 失败时整页崩溃
- Stage 3.6 产出：
❌ 单个 API 失败导致整页崩溃 — 每个区域独立 isError/refetch - 写入 async-loading skill
第二次重构 Account/Agents 页面
- AI 在 Stage 1 就自动遵循了独立错误处理模式（因为约束 Skill 已存在）
- Stage 3.6 发现新模式：屏幕外区域不需要立即请求
- 产出：
❌ 不考虑滚动位置就触发所有 API — 使用 skip: !inView - 写入同一约束 Skill
后续所有涉及 UI 的任务
- 骨架屏 + 独立错误 + 视口懒加载成为自动行为
- AI 不需要被提醒，规则体系已经约束它
从人类的视角：我只提了两次需求，Archon Protocol 就自动学会了三个最佳实践，并永久性地内化到规则中。