mcpField
A
architect

architect

github.com/xgent-ai开发1107 次安装1 天前更新
代码仓库

关于 architect

Architect 是面向开发者和 Agent 的编码技能,通过明确的设计草图组织实现。它先梳理现有系统、比较不同方案,并将反复出现的实现阻力视为重新设计的信号。

主要功能

  1. 01梳理现有系统
  2. 02提出多个不同设计方案
  3. 03综合设计并记录理由
  4. 04依据草图实现代码
  5. 05反复受阻时重新设计

适用场景

  1. 01规划跨模块改动
  2. 02比较不同架构方案
  3. 03按确定的接口实现代码
  4. 04重做实施中失效的草图

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/xgent-ai/skills --skill architect

安装后在 Claude Code 中输入/architect确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

references/
design-red-flags.md
rationale-template.md
runner-prompt.md

详细介绍

Architect

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

开始

开始前,创建一个待办清单,为每个阶段添加一项。

  1. 探查
  2. 草拟
  3. 确认
  4. 实现
  5. 推翻

阶段 A:探查问题

为新代码涉及的每个系统建立真实的心智模型。针对相关子系统运行 how 技能。

仅仅指出文件名不算探查。产出 how 规定的追踪模型。如果设计重新定义了所有权或分层,也要对现有结构运行 why 技能,让设计依据成为约束,而非猜测。

只有在工作确实是全新开发、且无需集成到周边系统时,才跳过阶段 A。

阶段 B:草拟

使用设计草图任务和阶段 A 的探查成果运行 arena 技能。将 references/runner-prompt.md 作为每个运行器的提示词。每个候选方案都应生成符合 references/rationale-template.md 格式的设计方案包。

使用 pstack-models.mdc 规则中 architect runners 一行指定的运行器,代替 arena runners 一行。如果该规则或该行不存在,则使用 claude-opus-5-5-max、gpt-5.6-sol-max、grok-4.7-xhigh-fast。别名和被拒绝的条目遵循 agi-mode 的 Arena 手册中运行器选择部分,可通过 arena 兼容性入口访问。

设计两轮。即使第一个候选方案看起来已经足够,也至少要有两个结构上不同的候选方案,再进行综合。这是将 exhaust-the-design-space 原则技能付诸实践。应比较整体结构不同的方案,而不是同一结构中的局部修补。

综合前,依据 references/design-red-flags.md 审查每个候选方案。拒绝或修订浅层模块、信息泄漏、按时间拆分和透传方法等问题。

对可行候选方案的接口深度进行比较。优先选择能通过更小、更简单的公共接口隐藏更多复杂性的设计。丰富的接口能集中能力,而非将其分散到各层,从而缩短调用链。

Arena 会返回一个综合后的设计方案包。综合决策应填写在理由说明的「综合决策」部分。

阶段 C:确认(可选)

默认情况下,直接根据综合后的设计进入实现,不设人工检查点。

只有调用者明确要求时,才启用检查点,例如「/architect with checkpoint」「先停下来给我看看,再开始实现」或类似表述。此时展示综合后的设计,并暂停等待确认。

无论如何,都可以将综合成果单独提交为一次提交,这是 foundational-thinking 原则技能中的「先搭框架」模式。根据 outcome-oriented-execution 原则技能,填充过程中计划内、范围明确的破坏性变更是可以接受的。若要在实现前对设计进行对抗性检验,可对综合后的草图运行 interrogate 技能。

如果人工审核者(无论是在检查点还是事后)对结构提出异议,应将其视为阶段 A 的证据。重新探查并重跑阶段 B,然后再编写更多代码。

阶段 D:根据草图实现

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

偏离草图是值得提出的信号,而不是可以默默消化的摩擦。如果某个函数需要草图中未考虑的参数,应判断是草图有误、遗漏了需求,还是实现超出了范围。

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

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

信号在于模式,而非个别情况。迹象包括:

  • 在互不相关的代码中反复出现相同形式的变通方案。
  • 多个互不相关的边缘情况都需要特殊分支。
  • 类型必须借助逃生通道(any、类型转换、实际上总是设置的可选字段)才能通过编译。
  • 草图明明说状态并非共享,却下意识觉得“我们需要一把锁”。
  • 调用方必须了解抽象的内部规则才能使用它。
  • 实现中出现两个或更多形态相同的独立阶段 D 偏差。

酌情判断。少数边缘情况并不能说明架构有问题。有些问题确实很复杂。数据复杂,不等于设计复杂。

推倒重来时:

  1. 针对已构建的内容,重新运行how技能。
  2. 按照从第一性原理重新设计的原则,假设新约束从第一天起就已确定,然后重新设计。
  3. 遵循先删减,再添加原则技能,先删减,再添加。新草图在扩展之前应比旧草图更精简。
  4. 返回阶段 B,重新运行 arena。

产出

先写出调用方的用法,再据此推导类型草图。小改动只需一个包含新类型和签名的文件。较大的改动则需要模块映射和类型定义。随附的设计依据应按照 references/rationale-template.md 编写,其中包括用法草图和综合决策。

评论

支持 Markdown