set-theory-for-projects

项目集合论

找到更深的脉络，而不是堆得更多。

围绕一个锚点项目开展有界、只读的探索。寻找稳定的通用核心、范围明确的适配器机会，或可信的平台机会，让项目现有的价值能在更多真实场景中发挥作用。将不扩展的结果视为成功的结果。

扩展目标以及之后每一次范围变更均由用户决定。Agent 负责探索：用户提供的项目是有用的线索，但绝非探索的前提或边界。探索应止步于对话式的发现报告和探索检查点。只有在用户明确将某个候选项定为新的或修订后的一项用户问题之后，才能开始实施、原型开发、集成或更改其他项目。

英文输出

在撰写或修改英文文案前，使用已安装的 simple-english 技能。按名称加载，或读取其 SKILL.md 和适用的参考资料。 重用当前上下文中已加载的指令。 阅读本约定后，在发送任何英文进度更新、草稿或最终回复前，加载该依赖项。

如果风格规则与任务要求发生冲突，应保留原意、不确定性、要求强度、领域术语和任务所需的格式。使用指定的语言。 保留代码、标识符、命令、原文引述和历史证据。

如果无法获取所需指令，应报告一次这一缺失，然后继续独立完成工作。在依赖项可用或用户明确授权例外之前，将受影响的英文内容保留为草稿。不要自动安装依赖项，也不要声称未经核验的草稿符合此要求。

1. 确立锚点

根据用户请求或当前工作区，确定锚点项目。设定一个扩展目标：用一句话说明要让哪项现有价值在更多具体场景中发挥作用。如果缺少这项价值选择，或确实存在歧义，则提出一个有针对性的问题；直接调查事实方面的信息缺口。

根据当前证据，建立精简的锚点概况：

• 现有用户以及项目已解决的问题；
• 创造该价值的机制和接口；
• 框架、平台、领域、工作流和使用体验方面的限制；
• 当前集成、验证范围、发布模式和维护者。

将每项重要限制归类为：

• 必要边界 — 移除它会改变值得保留的价值或身份；
• 偶然限制 — 历史或技术耦合造成的限制，虽会缩小适用场景的范围，但不会创造核心价值。

根据证据确定事实分类。只有存在模糊的价值取舍时，才交由用户决定。

**完成条件：**锚点项目和扩展目标明确；所有可能影响探索的重要限制都已分类；任何由用户决定的边界歧义均已解决。

2. 开展有界发现

在扩展目标和必要边界明确后，如果两条或更多搜索路径能够独立推进，请使用研究任务。主要负责人负责维护候选项的身份、最终判断和一项全局预算。不要并行处理尚未明确的目标，也不要按工作人员数量倍增此技能的限制。

主动搜索最相关的可用一手资料：项目文件、官方文档、源代码仓库、问题跟踪器、发行说明和维护者声明。确保每项重要主张都能追溯到文件、URL 或用户提供的事实。

按最有可能为此锚点提供证据的顺序，调查以下四条路径：

1. 技术相邻性——共享的协议、格式、引擎、扩展点或重复的基础设施。
2. 共享用户问题——用户遇到同一底层任务或故障的不同项目。
3. 互补能力——另一个项目提供锚点可通过适配器使用或暴露的有限能力。
4. 跨生态系统类比——另一个框架、平台或领域通过可比的衔接点解决等效问题。

只有当候选证据在双方都存在时，原始想法才符合条件：来自锚点和至少一个真实相邻项目的证据表明，双方存在共享或互补的问题，以及合理且稳定的机制或集成衔接点。概念相似、技术相同或仅技术上可连接，都不足以满足条件。

达到以下任一限制时即停止：

• 已检查 15 个原始候选项；
• 已保留 5 个合格入围项；或
• 2 条不同的搜索路径都未能找到新的合格候选项。

在证据边界中记录尚未检查的路径和无法获取的证据，不要无限延长搜索。

**完成条件：**每个保留的入围项都有双方可追溯的候选证据，且报告能够准确说明哪些搜索路径和停止条件限定了结果。

3. 对衔接点分类

根据最小且可信的架构调整，对每个入围项进行分类：

• 通用核心——移除偶然限制，或提取至少两个具体场景已支持的稳定机制，同时让具体产品保留各自的体验层。
• 适配器机会——保留锚点的特定核心，并为另一个具体项目或场景添加一个有限的集成衔接点。
• 平台机会——提供稳定的接口或协议，让一系列具体项目能够参与，同时保留各自的集成方式。

拒绝任意捆绑功能：如果没有证据表明存在共享问题和稳定衔接点，仅仅组合功能集、受众或品牌，只会让项目变得更大，而不会更通用。

对每个入围项，回答：这是否揭示了更深层、可复用的机制，还是只增加了另一项功能？

**完成条件：**每个入围项都恰好归为一种类型，其必要边界仍然清晰可见，并且已拒绝任何规模更大却没有变得更通用的组合。

4. 判断经证据调整后的价值

定性比较入围候选项。不要计算数值分数。请考虑：

• 双向证据的强度和独立性；
• 同一价值还能服务的其他具体情境；
• 对必要边界的保留；
• 拟议切入点的稳定性和可测试性；
• 耦合、可逆性和身份稀释；
• 维护责任归属、验证矩阵、兼容性承诺和退出路径。

指定一个候选项处置结果：

• 建议采用——证据和切入点可信，完整的维护模式也切实可行；
• 需要证据——存在一个明确且可解决的证据缺口，因此无法提出建议；
• 拒绝——必要边界、薄弱的共同问题、不稳定的切入点或维护成本使候选项不合适。

若某候选项虽有趣，却缺乏可信的责任方、验证范围、兼容性政策和退出路径，则仍应标记为“需要证据”或“拒绝”。覆盖范围和抽象设计的优雅程度不能使其升级。

**完成标准：**每个入围候选项都有理由充分的处置结果，且每个“建议采用”的候选项都通过维护门槛。

5. 设计实验阶梯

为每个“建议采用”或“需要证据”的候选项设计循序渐进、可证伪的实验阶梯：

1. 验证相邻情境及其所述问题是否真实存在。
2. 针对锚点和相邻案例，将拟议切入点作为契约或设计进行测试。
3. 仅当前两项成本更低的检查均通过时，才建议制作一次性原型。

对于每个阶段，说明要寻找的证据、可信且成本最低的方法、通过时的观察结果，以及会使候选项失效或需要修订的信号。制定实验阶梯计划；执行工作留给另行授权的任务。

**完成标准：**每个保留的候选项都具有成本更低的原型前测试，以及明确的证伪信号。

探索报告

先给出结果，然后包括：

1. 锚点概况——锚点项目、扩展目标、要保留的价值、必要边界和附带约束。
2. 搜索覆盖情况——检查过的路径、审查过的原始候选项、停止条件和证据边界。
3. 候选项卡片——最多五项，按经证据调整后的价值排序，不附分数。每张卡片包含：
   • 处置结果和类型；
   • 相邻项目或情境；
   • 附带来源的双向候选项证据；
   • 共同或互补的问题；
   • 保留的必要边界；
   • 拟议切入点，以及它为何不只是功能扩展；
   • 维护模式；
   • 重大风险；
   • 实验阶梯。
4. 拒绝记录——最多三项与决策相关的拒绝候选项，以及使其不合适的证据、边界或成本。
5. 探索检查点——邀请用户选择一项候选项、授权针对一个明确的证据边界开展研究，或接受不扩展结果。

如果没有入围候选项通过证据和维护门槛，请直接说明不扩展结果，并解释为何保留当前范围优于现有替代方案。除非用户明确要求保存，否则将报告保留在对话中。

在探索检查点：

• 用户选定候选项后，探索即告结束；说明实施需要新的或修订后的问题陈述。
• 针对性研究开始前，必须明确一个证据问题、一组有界的来源和一个停止条件。
• 用户接受不扩展结果后，工作即告完成，不得凭空另造一个方向。

这套视角的来源

这项独立技能的灵感来自 Anthony Fu 的 “The Set Theory”：移除不必要地缩小目标用户交集的限制；保留有价值的具体特性；当真实需求揭示出一个并集时，提取共享的底层部分。这里的“并集”并非随意融合项目。请参阅 Antfu 的 React Summit 演讲幻灯片以及官方录像和文字记录。这是一项独立的非官方技能；这些链接用于说明其视角来源，并不意味着作者身份。