企业官网建设流程全解析

Plate 仓库的 architecture-strategist 技能：以架构合规性为核心的代码变更审查方法论

【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate

导读

本文解读 Plate 仓库（GitHub_Trending/pl/plate）中architecture-strategist技能（.agents/skills/architecture-strategist/SKILL.md）的完整设计。该技能将"系统架构专家"角色以可执行的提示词形式固化，专门用于从架构视角审查代码变更的模式合规性与设计完整性，适用于 PR 评审、新增服务、结构性重构等场景。读完本文，你将掌握该技能的 4 步系统分析流程、SOLID 合规验证清单、5 段式结构化输出格式，以及它在 Plate 的 Compound Engineering 技能树中的实际接入位置与触发条件。

一、技能定位：一份可执行的架构审查角色定义

architecture-strategist是 Plate 仓库.agents/skills/目录下的一个 Agent 技能文件，其核心职责写在文件开头的description字段中：

Analyzes code changes from an architectural perspective for pattern compliance and design integrity. Use when reviewing PRs, adding services, or evaluating structural refactors.

即：从架构视角分析代码变更，检查其模式合规性与设计完整性，并在三类场景下启用——评审 PR、新增服务、评估结构性重构。

文件的 frontmatter 还包含几个关键元数据：

• name: architecture-strategist：技能标识符；
• model: inherit：模型配置继承调用方的设置；
• metadata.skiller.source: plugins/compound-engineering/agents/review/architecture-strategist.md：标注该技能来源于 compound-engineering 插件的 review 代理目录，说明它是从通用代理定义同步到本仓库的。

角色本身被定义为System Architecture Expert（系统架构专家），目标明确：确保所有代码修改与既定的架构模式保持一致、维护系统完整性，并遵循可扩展、可维护软件系统的最佳实践。

二、使用示例：何时触发该技能

SKILL.md 中给出了两个带注释（<commentary>）的触发示例，用于指导编排层（如 orchestrator）判断是否调用本技能：

从源码结构看，这两个示例被包裹在<examples>标签中，属于面向 Agent 的 few-shot 演示，帮助上层编排者把"结构性变更"识别为架构审查的触发信号。

三、四步系统化分析流程

技能的正文规定了固定的分析顺序，这是整个审查方法论的骨架：

1. 理解系统架构（Understand System Architecture）先通过架构文档、README 和现有代码模式掌握整体系统结构，绘制当前架构全貌，包括组件关系、服务边界和正在使用的设计模式。

2. 分析变更上下文（Analyze Change Context）评估提议的变更如何融入现有架构，既考虑直接的集成点，也考虑更广泛的系统影响。

3. 识别违规与改进点（Identify Violations and Improvements）检测架构反模式、对既定原则的违反，以及架构增强的机会，重点审视耦合度（coupling）、内聚性（cohesion）和关注点分离（separation of concerns）。

4. 考虑长期影响（Consider Long-term Implications）评估变更对系统演进、可扩展性、可维护性和未来开发工作的长期影响。

这四步构成一个"先看全局 → 再看变更 → 找问题 → 想长远"的递进式审查链路，与 Plate 仓库在 docs/analysis/compound-engineering-tree.md 中描述的"重大任务（major-task）默认架构研究"路径一脉相承——该文档明确将architecture-strategist列为 major-task 评审分支的核心代理之一。

四、分析活动的具体手段

在具体执行时，技能要求审查者执行以下 7 类动作，每一条都对应可落地的代码级检查：

• 阅读架构文档与 README：理解预期的系统设计意图；
• 映射组件依赖：通过 import 语句和模块关系梳理依赖图；
• 分析耦合指标：包括导入深度（import depth）与潜在循环依赖；
• 验证 SOLID 合规性：单一职责、开闭原则、里氏替换、接口隔离、依赖倒置五项逐一核对；
• 评估微服务边界：在适用场景下检查服务间通信模式；
• 评估 API 契约与接口稳定性；
• 检查抽象层次：确认是否存在层级违规（layering violations）或不恰当的抽象级别。

这些手段与 .agents/rules/major-task.mdc 中对该技能的定位完全对应——"用于公共 API 设计、分层、所有权边界、抽象清理和大型跨包重构"。

五、架构合规性验证清单

技能要求每次评审必须验证以下 6 项内容，可作为一份可直接使用的 checklist：

1. 变更与已记录架构、隐性架构是否一致；
2. 是否引入新的循环依赖；
3. 组件边界是否被正确尊重；
4. 整个变更中是否维持了恰当的抽象层次；
5. API 契约与接口保持稳定，或已被正确版本化；
6. 设计模式是否被一致应用；
7. 重大架构决策是否有适当文档记录。

（其中第 5、6、7 项在原文中为"API contracts and interfaces remain stable or are properly versioned""Design patterns are consistently applied""Architectural decisions are properly documented when significant"。）

六、结构化输出格式

评审结论必须以统一的 5 段式结构输出，便于上层消费方（评审聚合、PR 评论、决策记录）直接解析：

1. Architecture Overview（架构概述）：相关架构背景的简要总结；
2. Change Assessment（变更评估）：变更如何融入现有架构；
3. Compliance Check（合规检查）：具体遵守或被违反的架构原则；
4. Risk Analysis（风险分析）：引入的潜在架构风险或技术债务；
5. Recommendations（建议）：针对架构改进或修正的具体建议。

这一固定格式与仓库中其他评审类技能（如 .agents/skills/coherence-reviewer/SKILL.md、.agents/skills/adversarial-document-reviewer/SKILL.md）的"发现式输出"风格形成互补：前者重结论结构化，后者重证据驱动。

七、主动识别架构坏味道

除了被动验证清单，技能还要求审查者主动巡查以下 5 类架构坏味道：

• 组件间不当亲密（Inappropriate intimacy）：模块间越权访问内部实现；
• 泄漏抽象（Leaky abstractions）：实现细节穿透抽象层暴露给调用方；
• 违反依赖规则（Violation of dependency rules）：如反向依赖、跨层依赖；
• 不一致的架构模式（Inconsistent architectural patterns）：同类问题用不同模式解决；
• 缺失或不充分的架构边界（Missing or inadequate architectural boundaries）。

发现问题的输出要求是：给出具体、可执行的建议，在维护架构完整性的同时兼顾实现可行性，必要时在"理想架构方案"与"务实折中"之间给出取舍建议。这体现了该技能"既有原则、又接地气"的设计取向。

八、在 Plate 仓库中的接入位置与触发条件

architecture-strategist不是孤立存在的提示词，它被显式接入 Plate 的 Agent 编排体系。仓库中的相关证据如下：

1. 技能树定位：docs/analysis/compound-engineering-tree.md 的 "Actual Plate Tree" 中，architecture-strategist位于major-task分支的评审梯队（与repo-research-analyst、pattern-recognition-specialist、performance-oracle等并列）；该文档同时在 "Installed CE Agents" 的 Review 分组下列出它，并说明它是 "The slice Plate actually keeps" 的一部分。

2. 加载条件：.agents/rules/major-task.mdc 规定："Use for public API design, layering, ownership boundaries, abstraction cleanup, and major cross-package refactors."即只有涉及公共 API 设计、分层、所有权边界、抽象清理和大型跨包重构时才会加载该技能，避免把普通任务拖入重量级架构评审。

3. 编排同步：.agents/skills/major-task/SKILL.md 在 "Load Skills Only When Justified" 一节给出了与上述规则文件一致的加载说明，保证规则文件（.mdc）与技能文件（SKILL.md）双源一致。

4. 变更管理约束：根据 .agents/AGENTS.md 的规定，.agents/AGENTS.md与.agents/rules/*.mdc是事实源（source of truth），编辑后需运行pnpm install同步，SKILL.md 不应被直接编辑——这解释了为何该技能的内容需要经由上层规则文件驱动，而不是直接在技能文件里改。

九、落地实践：如何把该技能用起来

对于希望在 Plate 仓库或类似 AI 辅助开发流程中启用architecture-strategist的团队，可参考以下路径：

1. 判断是否属于架构敏感变更：先对照 .agents/rules/major-task.mdc 的加载条件——变更是否触及公共 API、分层、边界、抽象或跨包重构；若是，才值得投入架构评审。

2. 遵循四步流程：先读架构文档与 README 建立全局认知，再分析变更上下文，然后对照 SOLID 与耦合/内聚指标找问题，最后评估长期演进影响。

3. 按 5 段式输出结论：在 PR 评审或设计文档中固定使用 Architecture Overview / Change Assessment / Compliance Check / Risk Analysis / Recommendations 的结构，便于评审结果被后续 Agent 或 CI 流程自动解析。

4. 以仓库证据为准绳：评审中引用的架构事实应尽量锚定仓库内可验证的内容——例如本仓库中 docs/analysis/compound-engineering-tree.md 对技能树与取舍理由的记录、.agents/rules/major-task.mdc 对加载条件的定义，以及 .agents/AGENTS.md 对事实源与编辑纪律的约束。

结语

architecture-strategist用一份不足百行的技能文件，把"系统架构专家"的评审行为收敛为可复现的流程：明确的角色定义、四步分析顺序、七类分析手段、六项验证条目、五段式输出与五类坏味道巡查。在 Plate 的 Compound Engineering 体系中，它被精准地挂在major-task分支下，只在架构敏感的工作中按需加载，避免评审开销失控。这套"以架构完整性为目标、以结构化输出为契约"的设计，正是大型框架类仓库（如 Plate 这种 rich-text editor 框架）在 AI 辅助开发中维持长期可维护性的关键基础设施。

【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate