回顾与反思：Aristotle 项目中的七种人机协作模式

五篇文章之后，我想退一步，看看脚下的路。

Aristotle：让 AI 学会从错误中反思 讲了设计理念和初版实现。claude-code-reflect：同样的元认知，落在不同的土壤 讲了跨平台移植的坎坷。信任边界：同一个想法在开放系统和受限系统上的实现实验 提出了信任分层模型。从四道伤疤到一套铠甲：Aristotle 改造中的驾驭工程实践 用改造过程验证了理论。一份 Markdown 的三次生命：从静态规则到 Git 版本管理的 MCP Server 把反思规则从 append-only 推进到了 GEAR 协议。

五篇文章讲的是设计和技术。这篇讲人——具体地说，讲我和 AI 在这个项目中的协作方式。回顾从 4 月初到 4 月中旬的完整开发过程，我提炼出了七种协作模式。它们不是平行排列的清单，而是一条随时间演化的线——从高信任启动到元认知闭环，每一种模式都是对前一种的修正和深化。

模式一：用户给哲学，AI 填细节

初版 Aristotle 的设计与实现。

我给 AI 三条设计原则——即时触发、会话隔离、人在回路——以及 5-Why 根因分析的框架。AI 用 3 个 commit 实现了完整的 SKILL.md（394 行）、测试脚本和 README，一气呵成。

这种模式的特点是高信任启动。用户定义"为什么"和"做什么"，AI 负责"怎么做"。当问题空间足够清晰、平台基础设施足够完善时，AI 的执行能力很强。OpenCode 的 skill 体系和 omo 后台任务把最难的部分解决了，AI 只需要把能力组合起来。

但"一气呵成"本身隐藏了风险。37 个静态断言验证了协议步骤能按顺序执行，但没有验证副作用是否可接受。测试不会告诉你主 session 被占了 371 行上下文空间，也不会告诉你用户需要另开终端才能审核。自动化测试通过给了"跑通了"的假象，让我跳过了人工验证。

当工具足够流畅，人类会自然地把 review 当成可选项。流畅感本身成了陷阱。

模式二：平台现实不断修正 AI 的假设

同样的设计哲学，搬到 Claude Code，事情完全不一样。

AI 反复安装失败——marketplace.json 格式不对，skill 调用路径错误，配置改了半天不生效。好不容易装上了，又撞上权限模型的暗坑：bypassPermissions 有 bug，静默拒绝项目根目录外的写入。再后来，主会话和子会话共用 API endpoint，并发请求触发了 ECONNRESET 错误。

每一次都是 AI 带着上一轮的经验信心满满地提出方案，然后被平台现实打脸。V1 引入 bypassPermissions 解决弹窗问题 → 发现写入被拒。V2 把写入移到 resumed session → 忘记了准备阶段原子性。V3 合并成单条 Bash 命令 → 测试发现 bypassPermissions 其实不能去掉。

AI 的理论知识丰富，但对特定平台的隐含规则一无所知。模型对 OpenCode 积累的经验不能直接迁移到 Claude Code——每个生态的"常识"细节都需要重新学习。就像一个资深 Java 开发者第一次写 Rust：架构能力可以迁移，但平台的隐含约定必须从头积累。

回头看，三个方案的差异一目了然。但搞清楚着实费了一番功夫。

模式三：用户在关键时刻做架构决策

初版 Aristotle 用了两周，四个问题浮出水面：上下文污染（371 行全量注入）、报告泄漏（RCA 全量拉回主 session）、审核断裂（task session 非交互式）、注意力浪费（模型选择弹窗）。AI 的分析结论是四个问题各自独立，需要分别修复。

我做了一个关键判断：四个问题指向同一个结构性缺陷——没有区分"协调者"和"执行者"的角色边界。基于这个判断，改造方向不是四个独立修复，而是一次架构重构：把 371 行的单文件拆成 4 个按需加载的文件（Progressive Disclosure），每个文件对应一个清晰的职责。

这个决策不是 AI 能做的。AI 能分析每个问题的症状和修复方案，但把分散的问题归因到一个共同的根因，并据此做架构级决策——这是人类的认知优势。AI 的 5-Why 分析可以找到表面原因，但把四个独立的 5-Why 链条串成一个系统性的架构洞察，需要跨领域的问题抽象能力。

另一个例子。在 GEAR 协议设计中，AI 建议"L 直连 S 就行，O 是不必要的中间人"——用了 CQRS 做类比：命令走协调者，查询直接取，天经地义。

我纠正了这个判断。L 是正在帮用户写代码的那个 agent，O 是 Aristotle 这个独立的反思 skill。它们运行在不同的上下文中。L 的上下文应该尽可能留给用户的主线任务——反思基础设施的任何细节都不应进入 L 的上下文。AI 后来被 Aristotle 自己的反思机制做了一次 5-Why 分析，根因结论是"对间接层有默认的负面判断"。

在一般软件设计中，去掉中间人通常是合理的。但在 Agent 场景下，隔离层本身就是产品价值。

模式四：实际使用比设计文档更能暴露问题

设计阶段，我信誓旦旦地写了"主会话上下文零污染"、“整个过程对用户透明”、“不会打断工作流”。37 个测试全部通过。代码层面的逻辑完全正确——Coordinator 确实启动了 Reflector，Reflector 确实生成了 DRAFT。

但一用就出问题：

这不是 AI 的错——AI 忠实地实现了 SKILL.md 里的协议。问题在于，协议本身没有考虑副作用。测试验证了"协议有没有正确执行"，没有验证"协议的副作用是否可接受"。

后来在 claude-code-reflect 的开发中，我把这个教训付诸实践：让 AI 来测试系统。测试中发现了三个方案文档的盲区——bypassPermissions 的平台特性、API 并发的环境限制、heredoc 变量不展开的 Bash 实现细节。这些都是设计阶段不可能预见的。让 AI 来测试系统，AI 不只是执行者，还是设计验证的参与者。

自动化测试验证正确性，人工测试验证体验。两者不可替代。

模式五：AI 做调研，人类做判断

前几种模式讲的是设计和实现。但整个项目里还有一种不太显眼却贯穿始终的协作——AI 帮我做调研，帮我提高决策的合理性，降低犯错的概率。

改造 Aristotle 时，我需要确认一个关键事实：OpenCode 的 task() 创建的 session 到底是不是非交互式的？这不是靠猜的。AI 查阅了 OpenCode 的源码和数据库，实证了 47 个 task session 全部只有 1 条 user message，还是 system prompt，没有一个有后续交互。同时查到 GitHub 上的 Issues #4422、#16303、#11012，都指向同一个结论。这不是 AI 的"意见"，是实证数据。基于这些证据，我做出了"审核不能在子 agent session 中进行，必须在主 session 中实现"的架构决策。如果没有这些调研，我可能会继续沿着"让用户切入子 session 审核"的错误方向走下去。

设计 MCP Server 时，AI 帮我做了 Git 方案和 SQLite 方案的对比分析。Git 的优势（透明、轻量、无运行时依赖）和 SQLite 的优势（查询能力强、适合复杂索引）都被客观列出来，我基于"调试频繁的早期系统需要透明性"这个判断选了 Git。AI 还帮我调研了 Claude Code 泄漏的源码中 Dream 子系统的沙箱设计、Cursor Bugbot 的多轮并行分析策略、以及驾驭工程领域的最新实践。这些调研成果直接进入了第三篇和第五篇博客，成为信任分层模型和 GEAR 协议设计的论据支撑。

甚至在不同模型的使用上，AI 也参与了调研决策。开发 claude-code-reflect 时遇到一系列技术问题，我特地和 Sonnet 4.6 做了深度对话来分析原因。但具体到项目实现，我认为当前模型完全能胜任，就用它来推进。这也是调研的一种——对模型能力的判断本身就是基于日常使用中积累的"调研数据"。

这个模式的特点是：AI 提供信息和选项，人类基于判断做选择。AI 的调研能力——快速检索文档、查阅源码、对比方案、汇总证据——大幅降低了我的决策成本。以前需要自己花几个小时翻文档、读源码、搜 Issue 的事，现在 AI 几分钟就能给出结构化的调研结果。我做决策的质量没有下降（因为最终判断还是我做的），但做决策的速度和信心显著提升了。

而且 AI 的调研不只服务于我的决策，还服务于博客写作。第三篇信任边界那篇文章里的 OpenClaw 安全事件分析、CVE 清单、行业讨论——这些素材的整理都有 AI 的参与。AI 不是替我写结论，而是帮我把论据找齐、组织好，让我的结论站得住脚。

模式六：AI 做执行和验证，人类做取舍和定调

规则管理系统经历了五个阶段的迭代，每一步都被实际使用中遇到的具体问题逼出来：

• 规则无法回滚 → 引入 Git
• 读写互相干扰 → 引入读写分离和状态机
• AI 直接执行 git 命令不可靠 → 引入 MCP Server
• 规则之间没有结构 → 引入 YAML frontmatter 和检索维度
• 生产和审核目标冲突 → 引入角色分离
• 设计可以复用 → 抽象为 GEAR 协议

在这个迭代过程中，AI 做了大量具体的执行工作：写 MCP Server 的 8 个工具（75 个 pytest 全部通过）、设计两阶段流式过滤、实现原子写入和冷启动迁移。这些工作量大、细节多、确定性强——正好是 AI 的优势区域。

但每一步的方向决策都是人类做的。为什么用 Git 而不是 SQLite？因为"看得见、摸得着"的透明性对调试频繁的早期系统至关重要。为什么不让 AI 直接执行 git 命令？因为规则仓库是用户的长期知识积累，一个错误命令可以毁掉全部历史。为什么要把 O/R/C/L/S 分成五个角色？因为 R 追求覆盖面、C 追求准确率，把它们混在一起两个目标会互相干扰。

AI 可以在"怎么实现"上给出高质量输出，但"为什么这样选择"需要人类的判断。尤其在取舍涉及价值观时——透明 vs 性能、安全 vs 灵活、隔离 vs 效率——这些判断本质上不是技术问题。

模式七：反思系统反思了设计者自己的错误

在 GEAR 协议设计中，AI 建议 L 绕过 O 直连 S 的那个错误判断，后来被 Aristotle 自己的反思机制做了一次 5-Why 根因分析，生成了一条规则：

对"间接层"有默认的负面判断——认为每多一层协调就是不必要复杂度。这个判断在一般软件设计中通常是合理的，但在 Aristotle 的场景下是错误的。Aristotle 的间接层不是开销，它是产品本身。整个 skill 的存在意义就是让反思基础设施对主线 agent 不可见。去掉间接层等于去掉产品价值。

AI 在设计反思系统时犯了错误，反思系统反思了这个错误，生成了一条预防规则。有点套娃，但确实是这个系统设计的初衷——从错误中学习，哪怕是设计者自己的错误。

这揭示了一个更深的协作模式：AI 系统的元认知能力可以反哺系统本身的设计。当 AI 能审视自己的决策过程、发现认知偏差、生成防范规则时，它已经从"执行工具"变成了"认知伙伴"。这种伙伴关系不是建立在 AI 永远正确的假设上，而是建立在对错误的共同反思上。

七种模式的演化脉络

把七种模式按时间排列，能看到一条清晰的演化线：

演化方向：人类从"全程参与"逐渐转向"关键决策点介入"，AI 从"被动执行"逐渐获得"有限自主 + 自省"能力。这个方向和 GEAR 协议中的信任分层模型（Level 0 → Level 3）是同一件事的两个侧面——随着信任积累，checkpoint 后移，但判断"现在可以后移了"这件事本身，始终是人的责任。

这不是一幅"AI 越来越强、人类越来越不重要"的图景。恰恰相反——随着 AI 能力增强，人类的判断力变得更加关键，因为每一个决策的影响范围都变大了。一条错误的反思规则被自动加载后，会影响后续几十个 session 的决策。越强的 AI，越需要更精确的人类驾驭。

驾驭 AI 的关键不是提示词，也不是让 AI 自主。而是在合适的时机做合适的介入——知道什么时候放手，什么时候插手，什么时候反思。Aristotle 项目本身就是这个判断力的训练场。