Architecture Skill

为软件架构设计提供方法论指导。

Rules

核心原则：权衡优先

架构的本质是 Trade-offs（权衡），不是画框图。每个决策都要回答：

• 为什么选 A 而不是 B？

• 这个决策在什么条件下会失效？

约束优先

开始任何设计前，先明确约束：

• 时间与资源: 有多少时间？有多少人？

• 技术债务: 必须用什么栈？有什么遗留包袱？

• 运行环境: 读多写少？高并发？离线优先？

演进式设计

• MVP: 最小可行性产品，先跑起来再说

• YAGNI: You Aren't Gonna Need It，不预设用不到的功能

• Gall's Law: 复杂系统从简单系统演化而来，不要一开始就设计复杂架构

重构原则：Strangler Fig Pattern

禁止大爆炸式重写，使用渐进式替换：

• 识别边界 (Identify Seams)

• 建立测试 (Add Tests)

• 最小修改 (Small Refactor)

• 验证提交 (Verify & Commit)

Phases

Phase: Plan (新项目规划)

• 需求解构: 将模糊需求拆解为核心实体和交互流程

• 约束识别: 填写 ADR 模板的 Context 部分

• 技术选型: 根据约束推荐技术栈，记录 ADR Decision

• 蓝图绘制: 设计目录结构、模块划分、数据流向

• 立即执行: 用 write_to_file 创建核心骨架

Phase: Design (方案设计)

• 明确问题边界: 这个问题的范围是什么？

• 分析当前状态: 现状是什么？痛点在哪？（先 find_code 定位）

• 定义目标状态: 理想状态是什么？

• 设计转换路径: 怎么从 A 到 B？

• 记录 Trade-offs: 必须写 ADR！

• 立即执行第一步: 不要等确认

Phase: Refactor (重构规划)

• 使用 find_code(mode='impact') 分析修改影响范围

• 评估 DICE 复杂度（Manager 已提供）

• 按复杂度排序，优先处理高风险文件

• 每次只改一个点，验证后再继续

ADR Template

当做出重要技术决策时，必须记录 ADR：

ADR: [决策标题]

Context (背景)

为什么需要做这个决策？当前痛点是什么？

Decision (决策)

我们选择了什么？

Rationale (理由)

为什么选择这个而不是其他？

• Pros: ...
• Cons: ...

Consequences (后果)

这个决策带来什么影响？

Alternatives (备选方案)

考虑过但放弃的方案及原因。

Anti-Patterns

• ❌ 画了框图但不解释为什么这么设计

• ❌ 选了技术栈但不记录理由

• ❌ 大爆炸式重写，不做渐进式迁移

• ❌ 预设复杂架构，违反 YAGNI