adding-reference-mindsets

# 添加参考思维模式 参考思维模式是简化的哲学基础。它们解释了*为什么*少即是多，为智能体提供了超越机械检查点的更深层次的校准。 ## 它们存在于何处 思维模式存放在 @reference/ 中。每个都是以概念命名的独立文件。 ## 文件结构 yaml --- description: 核心洞察及其重要性的一句话总结。 --- # 概念名称 ## 核心洞察 用 1-2 句话概括中心思想。可引用，易记忆。 ## 为什么这很重要 这与避免复杂性有何关联。为什么大语言模型（LLM）应该关注这一点。 忽略此原则会产生什么后果。 ## 实际应用 需要提出的具体问题或应用的检查点。 在评估设计方案时如何使用这种思维模式。 ## 外部参考 指向原始来源的链接——演讲、论文、书籍，这些是该概念的起源或最佳解释。 ## 质量检查清单 在添加思维模式之前： - [ ] **是否抵制过度工程？** 它是否有助于抵制添加功能的冲动？ - [ ] **是否与现有内容不同？** 与当前思维模式不冗余 - [ ] **是否简洁？** 能在 50 行内解释清楚 - [ ] **核心洞察是否易记？** 具有可引用的中心原则 - [ ] **是否按概念命名？** 而不是按人名或来源命名 ## 好的候选主题 可以构成强大思维模式的想法： | 概念 | 核心洞察 | |---------|--------------| | `worse-is-better` | 发布简单的东西胜过完善复杂的东西 | | `essential-vs-accidental` | 大多数复杂性是偶然的，可以被消除 | | `locality-of-behavior` | 代码应该无需跳转即可理解 | | `boring-technology` | 创新令牌是有限的；默认使用无聊的技术 | | `separation-of-concerns` | 每个部分应该只有一个变更理由 | | `rule-of-three` | 在看到三次模式之前不要进行抽象 | ## 不要添加的内容 **特定技术建议** → 属于项目文档或特定技术技能 - "React 组件应该..." - "在 Rust 中，优先使用..." **流程/工作流规则** → 属于技能，而非思维模式 - "在...之前总是运行测试" - "在...时使用 TDD" **模糊的陈词滥调** → 如果没有可操作的洞察，请跳过 - "编写整洁的代码" - "编码前先思考" **任何需要上下文的内容** → 思维模式应该是通用的 - "在微服务架构中..." - "当处理遗留代码时..." ## 测试 一个好的思维模式应该能帮助智能体回答：“我应该添加这个抽象吗？” 如果该思维模式不能直接告知