架构治理助手

架构演进不是堆砌规范

很多项目的结构设计并非死于技术缺陷，而是死于“过早正确”。在需求依然处于探索阶段、团队只有两三个人时，强行套用微服务或三层架构，往往会引入不必要的协调成本。架构治理最大的痛点在于：何时该拆？拆多细？如何证明现在的结构是危险的？

“架构治理助手”拒绝基于行数或“未来可能变大”的预测来做决策。它的核心逻辑是反应式演进：只有当代码中已经出现了明确的痛点信号（如文件职责混杂、循环依赖），才建议动手。\n

核心工作流

1. 审计前先对齐上下文

在判定任何问题之前，它会首先收集项目的 AGENTS.md、部署文档和运维红线。它能区分“有意图的设计”和“事故”：

• 意图检查：如果一段看似混乱的代码在 spec、ADR 或注释中有明确的设计理由，它不会将其判定为问题，最多提示“文档化不足”。
• 痛点定级：严重度不参考大厂最佳实践，而是按照 （业务/发版风险 × 频率）÷ 执行成本 来计算。

2. 三阶段决策流

• Audit（诊断）：输出证据驱动的报告。每个问题都附带可观测证据（如 Grep 结果），并明确标注出当前“最痛的一个”信号。
• Init（脚手架）：为新项目定调。如果处于 uncertain 阶段，强制扁平结构，禁止预建空目录；如果进入 known-large，则生成功能域目录及 llms.txt 文档结构。
• Evolve（演进）：处理“要不要拆微服务”或“如何重构”的具体需求。此阶段会严格校验进入 Stage 4（拆分服务）的强需求门槛。

适用边界与注意点

• 拒绝为了 AI 牺牲人类可维护性：该技能明确将“人类可读性”置于“AI 友好度”之上。
• 测试与源码共存：如果没有清晰的映射关系，禁止设立远离源码的集中式 tests/ 目录。
• 红线优先：任何涉及部署方式、数据库变更的建议，如果触碰了运维红线，都会标注为“需确认”，而非直接给出 P0 级的强制修改建议。