architect

架构设计

先设计，再实现。用 not implemented 函数体和伪代码勾勒类型、函数签名、类结构和模块边界。综合多个模型的视角，然后根据选定的草图编写代码。如果实现证明草图有误，就弃用它并重新设计。

开始

开始前，创建一个待办清单，每个阶段对应一项。在没有检查点的自主模式下，清单需要显示当前所处阶段，并避免阶段悄然消失。

1. 梳理
2. 草拟
3. 确认
4. 实现
5. 弃用

阶段 A：梳理问题

为新代码涉及的每个系统建立真实的心智模型。对相关子系统运行 how 技能。如果现有结构构成限制，或设计必须对此提出异议，则使用批判模式。

仅仅说出文件名不算梳理。请按照 how 的要求，产出经过追踪的模型。如果设计重新定义了所有权或分层，还要对现有结构运行 why 技能，让设计依据成为约束，而非猜测。

只有在工作确实属于全新领域、无需与周边系统集成时，才跳过阶段 A。

阶段 B：草拟

使用设计草图任务和阶段 A 的梳理产物运行 arena 技能。将 references/runner-prompt.md 作为每个运行器的提示词。每个候选方案都要按 references/rationale-template.md 的结构生成设计包：先写调用方的用法，再写类型草图、函数签名、模块映射，以及据此推导出的文字说明。

使用配置的架构设计运行器（默认为 claude-opus-4-8-thinking-xhigh、gpt-5.5-high-fast、composer-2.5-fast）。

这是 exhaust-the-design-space 原则技能的具体实践。比较整体形态不同的方案，而不是在同一形态内做局部修补。

Arena 会返回一个综合设计包。综合决策会填入设计依据中的「综合决策」部分。

阶段 C：确认（可选）

默认：直接根据综合后的设计开始实现，不设人工检查点。

仅当调用方明确提出要求时才启用检查点，例如：「/architect with checkpoint」（/architect 并设置检查点）、「停止并在实现前给我看」，或类似表述。然后展示综合设计并暂停，等待确认。

无论如何，综合设计都可以单独作为一次提交发布。这就是 foundational-thinking 原则技能中的「先搭脚手架」模式；后续提交会表现为基于稳定契约补全函数体。根据 outcome-oriented-execution 原则技能，填充过程中按计划、有范围的破坏性改动是可以接受的。若要在实现前对设计施加对抗性压力，请对综合草图运行 interrogate 技能。

如果人工对方案形态提出异议（无论是在检查点还是事后），都应将其视为阶段 A 的证据。重新梳理并重新运行阶段 B，然后再编写更多代码。

阶段 D：根据草图实现

将 not implemented 函数体替换为代码，将伪代码替换为逻辑。综合后的草图就是契约。

偏离草图是值得指出的信号，而非可以默默消化的摩擦。如果某个函数需要草图未考虑的参数，应判断是草图有误、遗漏了需求，还是实现超出了范围。请明确指出，不要直接补上。

阶段 E：架构错误时推倒重来

如果实现过程不断产生草图无法消化的阻力，就把草图推倒重来。不要在错误的设计上不断打补丁，请遵循 从第一性原理重新设计 和 修复根本原因 原则技能。

判断信号看的是一种模式，而非个别情况。迹象包括：

• 在互不相关的代码中反复出现形态相同的变通方案。
• 多个互不相关的边缘情况都需要特殊分支处理。
• 为了通过编译，类型需要逃生口（any、类型转换、实际上总会赋值的可选字段）。
• 草图明明指出状态没有共享，却条件反射般地说“我们需要加锁”。
• 调用方必须了解抽象内部规则才能使用它。
• 实现中出现两个或更多形态相同、彼此独立的阶段 D 偏离。暴露偏离是阶段 D 的职责；反复出现的偏离模式则是阶段 E 的触发信号。

请自行判断。少数边缘情况并不足以否定一种架构。有些问题确实很复杂；数据复杂，不代表设计也复杂。触发重写的信号是同一形态的阻力反复出现，而非个别棘手问题。

推倒重来时：

1. 针对已完成的工作重新执行 how 技能。实现经验应作为输入纳入新设计，而不是凭感觉行事。
2. 按照“从第一性原理重新设计”的原则，假设这些新约束从第一天起就已存在，然后重新设计。
3. 遵循 先做减法，再做加法 原则技能。新草图在扩展前应比旧草图更精简。
4. 返回阶段 B，重新运行 arena。

产出

先写出调用方的用法，再据此推导类型草图。小改动时，用一个文件列出新类型和签名；较大的改动则提供模块映射和类型定义。随附的设计依据应遵循 references/rationale-template.md 的格式，并包含用法草图和综合决策。