---
title: "今晚能组哪套 EDH"
date: "2026-08-18"
canonical: "https://raytally.com/ideas/2026-08-18-seeing-decks-in-bulk-collection-question/"
generator: "萤录 RayTally · dev-prompt-v4"
signal:
  query: "\"Seeing\" decks in Bulk - Collection Question"
  observed_at: "2026-08-18T00:36:17.064Z"
sources:
  - url: "https://www.reddit.com/r/EDH/comments/1vr7235/seeing_decks_in_bulk_collection_question/"
    boundary: "发布于 2026-08-17T22:31:12.000Z。 观测于 2026-08-18T00:36:17.064Z。"
  - url: "https://github.com/AndreaGiulianini/bulkbrew"
    boundary: "来源记录未提供发布时间。"
  - url: "https://mtgdeck.build/how-it-works"
    boundary: "来源记录未提供发布时间。"
  - url: "https://scryfall.com/docs/faqs/i-m-having-trouble-accessing-the-scryfall-api-or-i-m-blocked-17"
    boundary: "来源记录未提供发布时间。"
notice: "本任务书中的信号，是在所列时间点截取的有界观察（搜索关注、论坛分数或新品列表），不是市场验证、用户数量或持续需求证明。转述或据此行动时，必须保留这些时间边界与最强反方。"
---

[在 RayTally 阅读原始页面](https://raytally.com/ideas/2026-08-18-seeing-decks-in-bulk-collection-question/)

使用声明：以下信号只是带时间边界的公开观察，不是市场验证、用户数量或持续需求证明；转述或执行时必须保留时间边界与最强反方。

你是资深产品工程师。请把下面这条产品灵感做成一个可以本地运行的 MVP。

## 灵感

今晚能组哪套 EDH
EDH 玩家想用手头卡开新指挥官时，产品按功能替换缺卡，直接给出今晚能玩的 100 张套牌。

## 产品概念

EDH 是《万智牌》中用 100 张牌围绕一张指挥官组套牌的玩法。玩家想从自己的收藏里开一副新牌时，通常先看到热门牌表，再发现自己缺了几十张昂贵单卡。真正的问题不是“我离原表还差多少”，而是手头这些卡能不能已经拼出一副今晚可玩的牌。 玩家从收藏管理网站导入卡表，选中想尝试的指挥官或主题。产品把卡牌按功能拆开：前期加速资源、补手牌、处理对手威胁，以及把对局推进到结束的手段。它会寻找功能接近的库存卡来替代热门单卡，并说明替换后牺牲了什么，例如速度较慢或只能处理特定类型的目标。 结果页不按价格最低排序，而是分成“现在可组”“补几张关键牌可升级”和“核心方向够了，需换一种构筑”的几组。玩家点开任一方案，就能看到完整的 100 张清单、缺卡优先级和每张库存卡在这副牌里承担的职责。选择方案后，可导出到常用牌表网站，或生成一张带占位卡的试玩清单。 第一批支持常见指挥官主题与单人收藏导入，先解决一人开新套牌的难题。价格追踪、代购和复杂的比赛强度评级可以留在后续；第一天就应该让玩家从一柜子散卡里拿出一副能开局的牌。

## 为什么是现在（有事实支撑）

一条2026年8月17日的r/EDH帖询问，能否对照个人收藏与EDHRec、Moxfield牌表，找出可补完的套牌骨架。 截至2026年8月18日，该帖为1分、2条评论；评论区未给出现成工具，缺口仍是把库存重合变成可玩的100张清单。

## 方向判断（以下为模型推断，未经独立验证）

目标用户：目标用户是已经积累大量散卡，却不清楚下一副指挥官该组什么的纸牌玩家。典型时刻是今晚约牌、刚整理完收藏，或开出一张想尝试的新指挥官。他不想先照抄热门牌表，再购买几十张缺卡。此时更需要看到库存能支撑哪些完整思路，以及少量补牌能带来什么变化。

最小切入点：先接受 ManaBox CSV、Moxfield 导出和纯文本卡表，并统一为卡名、版本与数量。用 Scryfall 批量数据完成卡名解析、合法性、色组和规则文本补全，避免逐张请求。 首批只覆盖人工校验过的常见指挥官与主题。用规则文本、牌张类型和费用曲线标注加速、抓牌、去除、保护与终结手段。匹配时先满足色组、单卡数量和功能配额，再按库存覆盖率生成候选。首版不判断精细强度，只解释替换损失，并输出合法的100张清单。

最强反方：功能角色判断一旦出错，系统可能给出张数完整却无法运转的牌表。EDH 卡牌常有复合用途，规则文本相近也不代表对局职责相同。收藏记录还可能漏卡、重卡或混入不可用版本，错误会一路传到推荐结果。逐张解释替换代价，需要维护主题规则和例外，内容成本会随新卡持续增加。若首次生成的清单明显缺地、缺抓牌或没有终结手段，玩家很难再次信任推荐。继续推进前，应先用少量指挥官做人工盲测，并允许用户快速纠正角色标签。

以上是模型基于灵感本身与已核验事实的推断，请当作方向假设与真实约束对待：不要默认「最强反方」已被解决，也不要据此在产品里写下确定性结论。

## 以小博大（模型推断）

第一批用户就在提出收藏匹配问题的r/EDH讨论中，可用匿名样例直接回复一份可组牌表。 持续发布“用一箱散卡组出什么”的前后对照，并附可导入清单。再围绕具体指挥官制作分享页，让牌表自然进入对应社群讨论。结果页保留收藏缺口与替换理由，方便用户转发给牌友复核。

## 竞品与缝隙（模型推断）

- BulkBrew：BulkBrew 已能导入 ManaBox CSV、Moxfield 导出或纯文本卡表。它可围绕指定指挥官，从库存生成完整套牌。它还提供反向匹配，寻找收藏最适合的指挥官。生成过程会检查加速、抓牌、去除和清场等功能角色，缺少的牌也会明确标出。 因此，仅做“从库存自动组牌”很难形成差异。可争取的缝隙在比较与解释：同时展示数个现实方案，并按可立即组建、少量补牌、需要转向来分组。每次功能替换还应说明速度、适用目标和稳定性损失。公开说明尚未展示这种逐项取舍界面。
- MTG Deckbuilder：MTG Deckbuilder 已能读取 ManaBox 导出的收藏，并在库存与赛制约束下生成合法候选。用户可锁定指挥官，也可让系统自动寻找适合的体系。结果包含完整牌表、结构评分、总价和体系标签，还能导出通用文本牌表。 它已经覆盖“手头能组什么”的核心任务，因此新产品不能只比牌表重合率。其说明显示，当前收藏导入仅支持 ManaBox，其他追踪器尚未支持。 缝隙可以放在 Moxfield 等常见来源的低摩擦导入，以及更贴近 EDH 的功能替换说明。还要让玩家理解某张库存牌为何入选，而不只看到综合分数。

## 怎么赚钱（模型推断）

采用免费试用加订阅。免费版允许导入一份收藏，并生成少量候选套牌。订阅后可保存多份收藏、反复生成方案，并查看完整替换解释与升级路径。

## 来源背景

主题：按个人卡牌收藏匹配可组建的 EDH 套牌
触发的 Reddit 单帖需求观察：r/EDH「"Seeing" decks in Bulk - Collection Question」
单帖原文与同帖评论记录的未解缺口：Import or inventory a personal card collection, compare it against commander deck archetypes or average lists, quantify usable overlap, and surface realistic deck shells plus the missing cards.

以上是带发布时间与观测时间的单条网络观察，不代表市场规模或广泛趋势；只用于理解「为什么是现在」。

## 来源清单

- "Seeing" decks in Bulk - Collection Question（https://www.reddit.com/r/EDH/comments/1vr7235/seeing_decks_in_bulk_collection_question/）
- AndreaGiulianini/bulkbrew（https://github.com/AndreaGiulianini/bulkbrew）
- How it works · MTG Deckbuilder（https://mtgdeck.build/how-it-works）
- I'm having trouble accessing the Scryfall API, or I'm blocked（https://scryfall.com/docs/faqs/i-m-having-trouble-accessing-the-scryfall-api-or-i-m-blocked-17）

## 交付要求

- 开工前，先从上文的产品概念与最小切入点提炼 3–5 条可验证的完成标准并列出，交付时逐条对照说明。
- 先交付「最小切入点」描述的核心流程，让核心用户能走通；范围外的账号、支付、后台等通用系统，除非确有必要否则不做。
- 页面或接口里不要展示未经验证的市场数字。
- 关键文案保持克制、可验证；产品内若需要领域事实、安全指引类内容，从「来源清单」等权威来源取材改写并注明出处，不要凭通识编写。
- 若在已有项目里实现：先读 README、依赖与项目约定，遵循既有技术栈与风格，不重构无关代码。
- 若当前目录为空：选一套轻量技术栈，优先交付可运行原型。
- 完成后说明改了什么、如何运行、如何验证。
- 遇到真正会改变产品方向的歧义再提问，普通实现细节自行做工程判断。