为 AI Agent 沉淀简约思维Meshery 仓库 Reference Mindsets 创作规范与实战指南【免费下载链接】mesheryMeshery, the cloud native manager项目地址: https://gitcode.com/GitHub_Trending/me/meshery导读本指南围绕 Meshery 仓库中.agents/skills/reducing-entropy/adding-reference-mindsets.md这一规范文档展开系统讲解参考思维模式Reference Mindsets的概念、存放位置、文件结构与 YAML 模板、质量检查清单、候选主题与禁区并结合作业仓库中reducing-entropy技能及其 4 个已落地的思维模式文件进行源码级印证。读完本文你将掌握为 AI Agent 设计可加载、可引用、可检验的简约哲学基础文件的完整方法论并能直接套用模板为当前仓库沉淀新的思维模式。Reference Mindsets为 Agent 校准为何少即是多参考思维模式Reference Mindsets是简约simplicity的哲学地基。与机械化的检查点不同它们解释为什么少即是多为 Agent 在遇到具体取舍时提供更深层的校准依据。在 reducing-entropy 技能说明 中可以看到这一机制的运转方式技能执行前必须从references/目录加载至少一个思维模式——先列出目录文件、读取 frontmatter 描述挑选适用的模式、加载至少一个并声明所加载的模式及其核心原则然后才能继续。该技能的核心问题被定义为代码库在之后变成什么样这正是思维模式存在的目的——用哲学原则武装 Agent使其在面对要不要加这个抽象时做出偏向删除而非增补的决策。Meshery 仓库的 Agent 工具布局在 .agents/README.md 中有完整说明.agents/skills/是每个打包工作流的唯一事实来源single source of truth每个技能一个目录并包含SKILL.md.claude/skills仅作为指向.agents/skills的相对符号链接存在。因此思维模式文件是这个技能体系中的一等公民。思维模式存放在哪里规范明确指出Mindsets live inreference/——思维模式存放在参考目录中每个模式是一个独立文件按概念命名而非按人或来源命名。在 Meshery 仓库中reducing-entropy技能的实际参考目录为.agents/skills/reducing-entropy/references/当前已存在 4 个思维模式文件文件核心思想来自 frontmatter descriptionsimplicity-vs-easy.mdSimple 是客观的不交织easy 是主观的熟悉。长期可维护性应选 simple 而非 easydata-over-abstractions.md100 个函数操作一个数据结构胜过 10 个函数操作 10 个数据结构泛型数据与操作才能组合design-is-taking-apart.md设计是拆解而非添加功能分离关注点、移除依赖、用简单部件组合expensive-to-add-later.mdPAGNIProbably Are Gonna Need It当事后回填的成本远超从一开始就构建时YAGNI 应当让位这些文件恰好是adding-reference-mindsets.md规范所定义产物形态的现成范例——每个文件都以 YAML frontmatter 开头提供一句话描述正文按核心洞见→为何重要→实战应用→外部参考组织。文件结构与 YAML 模板规范给出了思维模式文件的标准结构模板新增模式时须严格遵循--- description: One-sentence summary of the core insight and why it matters. --- # Concept Name ## The Core Insight The central idea in 1-2 sentences. Quotable. Memorable. ## Why This Matters How this connects to avoiding complexity. Why an LLM should care. What goes wrong when you ignore this principle. ## Practical Application Concrete questions to ask or checks to apply. How to use this mindset when evaluating design options. ## External References Links to primary sources - talks, papers, books that originated or best explain this concept.对各部分的作用进一步拆解YAML frontmatterdescription用一句话概括核心洞见及其重要性。reducing-entropy的 SKILL.md 明确要求读取 frontmatter 描述来挑选适用的模式因此这段描述是 Agent 决定加载哪个思维模式的关键索引信息必须精准凝练。The Core Insight12 句话的中心思想要求可引用、可记忆。已有的 4 个文件都践行了这一点例如>Counters over-engineering?它是否有助于抵抗想添加的冲动Distinct from existing?与现有思维模式不冗余。Concise?能在 50 行以内解释清楚。Memorable core insight?拥有可引用的中心原则。Named by concept?按概念命名而非按人或来源命名。对照清单检查现有 4 个文件simplicity-vs-easy按概念命名、data-over-abstractions、design-is-taking-apart、expensive-to-add-later全部满足按概念命名且各自聚焦独立原则——simplicity-vs-easy讲主观/客观之别data-over-abstractions讲数据优于定制抽象design-is-taking-apart讲拆解优于构建expensive-to-add-later讲 YAGNI 的边界。这也印证了Distinct from existing原则每个思维模式应占据互不重叠的思想空间。优质候选主题规范给出了 6 个会成为强思维模式的候选概念可直接作为灵感来源ConceptCore Insightworse-is-betterShipping a simple thing beats perfecting a complex one交付一个简单的东西胜过打磨一个复杂的东西essential-vs-accidentalMost complexity is accidental and can be eliminated大多数复杂性是偶然的、可以被消除locality-of-behaviorCode should be understandable without jumping around代码应无需跳转即可被理解boring-technologyInnovation tokens are limited; use boring tech by default创新令牌有限默认使用无聊的技术separation-of-concernsEach piece should have one reason to change每个部件应只有一个变更理由rule-of-threeDont abstract until youve seen the pattern three times在三次见到同一模式之前不要抽象值得注意的是仓库中现有的data-over-abstractions.md与design-is-taking-apart.md在思想谱系上分别与essential-vs-accidental、separation-of-concerns有亲缘关系新增候选时应通过Distinct from existing检查避免与这些已落地概念产生思想重叠。什么不该加四类禁区规范明确划定了思维模式的边界以下内容不应进入思维模式目录技术栈特定的建议Technology-specific advice——应归属项目文档或技术专项技能。例如React 组件应该……在 Rust 中优先……。这类内容缺乏普适性会让思维模式退化为某语言的编码风格备忘。流程/工作流规则Process/workflow rules——应归属技能skills而非思维模式。例如运行测试之前先……写代码时应使用 TDD。reducing-entropy的 SKILL.md 本身就承担了这类流程规则的角色如加载至少一个思维模式后才能继续与思维模式文件职责分离。空洞的陈词滥调Vague platitudes——如果没有可操作的洞见就跳过。例如写干净的代码思考后再写码。这类内容无法给 Agent 提供任何可执行的判断依据。任何依赖上下文的内容Anything requiring context——思维模式应当是普适的。例如在微服务架构中……在处理遗留代码时……。一旦依赖特定场景它就不再是哲学基础而退化为条件规则。判定的根本逻辑在于思维模式服务的是所有代码决策而技能、项目文档服务的是特定场景。放错层级的建议会污染两个体系。终极检验它能否回答那个问题规范给出了一个简单而犀利的验收标准A good mindset should help an agent answer: Should I add this abstraction? 一个好的思维模式应能帮助 Agent 回答我该加这个抽象吗如果某个思维模式不能直接为该问题提供判断依据它很可能属于其他归属地技能、项目文档或干脆不该存在。结合reducing-entropy技能的三问框架可以更清晰地理解这一检验的实际运作——该技能要求每次变更回答① 解决这个问题的最小代码库是什么② 该变更是否导致总代码量更少变更前后逐行计数若 after before 则拒绝③ 我们还能删掉什么思维模式正是为这三问提供为什么应该这么做的哲学支撑例如加载simplicity-vs-easy后Agent 会主动追问我选择这个方案是因为它简单还是因为它熟悉加载expensive-to-add-later后Agent 会区分哪些是事后回填代价 10 倍以上且从经验可证的 PAGNI从而在 YAGNI 与必要的基础设施投资之间找到平衡点。灵感来源简约思想的经典脉络规范为创作新思维模式提供了推荐的一手资料谱系这些来源构成了简约思考的经典脉络以下仅列出资料名称供创作时溯源参考Rich HickeySimple Made Easy简单与容易之辨simplicity-vs-easy的直接思想来源、Hammock Driven Development吊床驱动开发、The Value of Values值的价值data-over-abstractions的外部参考。Moseley MarksOut of the Tar Pit逃离焦油坑essential vs accidental complexity 的出处。Fred BrooksNo Silver Bullet没有银弹。Richard GabrielWorse Is Better更差即更好。John OusterhoutA Philosophy of Software Design软件设计哲学deep vs shallow modules。Tim PetersThe Zen of PythonPython 之禅。grugbrain.devThe Grug Brained Developer。现有 4 个思维模式文件均在External References一节中引用了这些资料中的若干篇如 simplicity-vs-easy.md 引用 Simple Made Easy 与 The Value of Valuesexpensive-to-add-later.md 引用 Simon Willison 的 PAGNIs 一文创作新思维模式时可以从这份谱系中寻找尚未被本目录覆盖的思想源头。结语让 Agent 的每次取舍都有哲学依据adding-reference-mindsets.md规范的价值在于它把减少熵增从一句口号变成了一个可扩展的知识工程体系。通过固定的存放位置、标准化的 YAML 文件模板、严格的质量检查清单、清晰的禁区边界以及可执行的验收测试仓库中的 Agent 得以在每次该不该加这个抽象的决策前加载恰当的哲学依据——而不是靠提示词中的泛泛号召。对于希望为 Meshery 仓库或其他项目扩展这一体系的开发者完整路径是阅读 adding-reference-mindsets.md 规范 → 对照 references/ 目录中 4 个现有范例 → 套用 YAML 模板新建按概念命名的文件 → 逐项通过质量检查清单与Should I add this abstraction?测试。记住该技能的总原则Bias toward deletion. Measure the end state.偏向删除。度量最终状态。【免费下载链接】mesheryMeshery, the cloud native manager项目地址: https://gitcode.com/GitHub_Trending/me/meshery创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
