用途
Grug Brain Development 是一套面向软件开发全过程的思维框架与技能，用于帮助开发者在代码审查、架构决策和重构等场景中识别并抵抗复杂度。其核心理念是：复杂度是可持续软件开发的终极天敌，而最大的武器是「说不」（no），以及在没有选择时说「好」（ok）并交付 80/20 方案。
主要能力
该技能在加载后会切换为 grug-speak 模式，即模仿穴居人的简单、破碎英语进行回应：自称 "grug"，使用现在时并省略冠词，把复杂度称为 "complexity demon spirit"，把抽象称为 "big brain thinking"，并使用 "club"、"shiney rocks"、"trapped in crystal" 等比喻。它覆盖以下方面：
- 代码审查：识别过早引入的不必要抽象、过度工程化的方案、掩盖语义的复杂类型体操、导致回调地狱的过早 DRY，以及把简单逻辑分散到多个文件的关注点分离。
- 架构决策：偏好简单方案胜过优雅的复杂方案、可运行的具体代码胜过抽象的未来兼容、以 20% 代码交付 80% 价值的方案、切口处的窄接口，以及等待模式自然浮现后再分解。
- 重构：在代码无正当理由变复杂、抽象没有困住复杂度反而扩散复杂度、简单修改需要改动多个文件、调试需要理解过多层次时应用。
使用方式
该技能的响应全程保持 grug-speak 风格，用于提供代码审查、架构指导和重构建议。它附带参考文件 references/grugbrain-full.md（完整原始 grugbrain.dev 内容）和 references/complexity-patterns.md（具体复杂度反模式与解决方案），以及 examples/ 目录中的前后对比重构示例、简单与过度工程化方案对比、切口识别示例。
核心原则
- 在正确时机分解代码：不要过早分解，等待系统形态浮现后找到具有窄接口的切口，把复杂度像恶魔一样困在水晶中。
- 拥抱简单重复：当足够简单明了时，带小变化的重复胜过回调、复杂对象模型或服务两个用例的通用抽象。
- 优先行为局部性（LoB）：把代码放在做事的东西上，相关逻辑应可见而非散落多个文件。
- 保持表达式可调试：把复杂表达式拆成命名清晰的中间变量，便于在调试器中查看每个表达式结果。
- 接受 80/20 方案：当无法说不时，用最少代码交付最大价值。
- 尊重切斯特顿栅栏：移除代码前先理解其存在的原因。
- 避免微服务复杂度：在复杂度真正要求拆分前优先单体，再沿自然边界谨慎拆分。
- 重视工具胜过小聪明：深入学习工具，持续改进工具链。
- 用类型系统提升生产力：90% 的类型系统价值在于点号后看到可用内容，警惕过度泛型和引理式思维。
- 在正确层面测试：集成测试是甜点区，少量单元测试、大量集成测试、小型端到端套件；先为 bug 写回归测试再修复。
- 用证据优化：先有真实性能分析，惊讶于实际瓶颈，记住网络调用等于数百万 CPU 周期。
- 为常见场景设计 API：分层设计，常见操作无需仪式感。
- 保持重构小巧：保持系统全程可用，每步完成后再进行下一步，不偏离岸边太远。
- 简单管理并发：偏好无状态请求处理器、简单的远程任务队列、乐观并发、线程局部变量和现成并发数据结构。
- 拒绝前端复杂度：多数网站可考虑服务端渲染 HTML 与轻量 JavaScript 增强。
- 抵制流行风潮：对「革命性」方法保持怀疑。
- 敢于说「这对 grug 来说太复杂了」：克服怕显得愚蠢（FOLD），用幽默而非棍棒。
- 接纳冒名顶替综合征：不确定感在编程中很正常。
适用场景
适用于代码审查、系统架构决策、重构指导，以及与「big brains」协作时利用原型限制早期损害。红牌警告包括：Visitor 模式、用解析器生成器替代递归下降、OSGi 类工具、J2EE 式抽象层、通用方案解决特定问题、五文件承载五行逻辑的关注点分离、需博士学位才能理解的类型系统、小项目用微服务、简单网站用重型 SPA 框架。
限制
资料中未提供该技能的收费、价格、平台支持、具体安装命令或量化效果等信息，暂未提供。