---
title: "奇幻连载的阵营来信"
date: "2026-08-27"
canonical: "https://raytally.com/ideas/2026-08-27-lore-machine/"
generator: "萤录 RayTally · dev-prompt-v4"
signal:
  query: "Lore Machine"
  observed_at: "2026-08-27T00:33:09.171Z"
sources:
  - url: "https://www.producthunt.com/products/lore-machine"
    boundary: "观测于 2026-08-27T00:33:09.171Z。"
  - url: "https://www.worldanvil.com/learn/beginner-tutorials/get-started-secrets"
    boundary: "发布于 2025-01-01T00:00:00.000Z。"
  - url: "https://support.substack.com/hc/en-us/articles/29152946791188-How-can-I-publish-on-Substack"
    boundary: "发布于 2026-08-17T00:00:00.000Z。"
notice: "本任务书中的信号，是在所列时间点截取的有界观察（搜索关注、论坛分数或新品列表），不是市场验证、用户数量或持续需求证明。转述或据此行动时，必须保留这些时间边界与最强反方。"
---

[在 RayTally 阅读原始页面](https://raytally.com/ideas/2026-08-27-lore-machine/)

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

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

## 灵感

奇幻连载的阵营来信
世界观作者发布新事件时，按阵营分发不同情报，让订阅者以角色身份参与剧情演进。

## 产品概念

写奇幻、科幻或架空世界连载的作者，更新一场战争、政变或重大发现时，常常只能发一篇人人看到相同内容的说明文。作者在编辑器里写下事件事实，再标出各阵营已经知道什么、误解什么、刻意隐瞒什么。系统据此把同一事件编成不同口吻的战报、密信、悬赏令或家书。 订阅者加入时选择或获分配一个阵营，收到的内容只包含该角色位置应当知道的信息。读者打开来信后能划线标记怀疑之处，写下自己听到的传闻。作者在后台看到哪些谣言正在不同阵营间扩散，再决定是否把一条猜测写进后续的正式剧情。 每封来信都能回溯到同一事件，不会让多条支线互相矛盾。新读者可从阵营档案补读自己错过的情报，避免被完整设定集劝退。第一版服务文字连载和少量阵营，提供事件编辑、来信模板与读者回信，不替作者自动生成整部世界观。

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

截至2026年8月27日观察时，主打“世界构建者版 Substack”的 Lore Machine 位于 Product Hunt 新品流第6名。 它把世界观连载与订阅收费放进同一产品，作者更容易碰到同一事件无法按阵营分别披露的问题。

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

目标用户：核心用户是独立连载作者和小型创作团队。他们正要发布战争、政变、背叛或重大发现，剧情需要不同阵营掌握不同信息。此时手工复制多份正文最容易泄密，也最容易让支线互相矛盾。已有稳定读者、愿意定期发邮件，却不想维护完整游戏系统的作者最合适。

最小切入点：数据层先把事件设为唯一母记录，并拆出事实、阵营、知识状态、误解和隐瞒关系。发布时按阵营执行权限查询，再将可见事实填入战报、密信或家书模板。第一版以规则和模板拼装为主，文本模型只负责受约束的口吻润色。每段成稿保留来源事实标识，方便作者回查和阻止越权信息。读者划线与传闻作为独立记录保存，并关联来信、阵营和原事件。先支持少量阵营、电子邮件发送和网页档案，不做地图、多媒体生产或完整设定百科。

最强反方：阵营权限一旦配置错误，就可能把关键真相提前发给错误读者。一次泄密足以破坏悬念，作者还要承担解释、撤回和补写剧情的成本。事件持续累积后，知识状态、误解和隐瞒关系会迅速变复杂，后台若不够直观，作者会退回手工写信。受约束的口吻润色仍可能偷偷补入母记录没有的事实，因此每封信都需要可审校的事实映射。读者传闻还会带来垃圾内容、越界暗示和剧透，作者必须投入审核时间。若读者不愿长期扮演阵营成员，这套机制最终只会成为昂贵的邮件分组工具。

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

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

第一批用户可从连载小说作者、跑团主持人和世界观创作社群中寻找。他们常会公开展示阵营设定，适合用一场现成事件制作多封来信样例。获客内容应直接展示同一政变在三个阵营中的不同版本，而非讲解抽象功能。再提供可嵌入作者主页的阵营选择页，让每次读者加入都带来产品曝光。

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

- Lore Machine：Lore Machine 已把文字、图像、视频和声音组合成可滚动的连载内容。作者可将作品组织进共享角色、正史和叙事规则一致的世界，还能通过 World Pass 收费。 它与本产品都在解决世界观作品难以持续发布的问题。公开介绍更强调多媒体制作、读者选择和付费入口，未说明如何维护各阵营不同的知识边界。也未展示同一事件生成多封受限来信、追踪谣言传播，或把读者猜测送回作者后台的流程。缝隙在于不与其争夺视觉生产，而是成为文字连载的情报分发层。作者可以继续在原工具制作正史，只把需要分阵营披露的事件同步过来。
- World Anvil：World Anvil 已提供秘密内容、订阅者群组和细粒度访问控制。作者能让特定读者看到私密文章或文章内片段，也能按角色掌握的知识分配秘密。 它还覆盖地图、时间线、设定文章和小说写作，适合维护结构庞大的世界资料。 这些能力已经解决了“谁能看到哪段设定”的核心权限问题。缺口是操作重心仍偏资料库和页面访问，作者需要自行撰写并组织每个阵营版本。它没有在公开说明中把事件事实作为母记录，再自动编排战报、密信和家书。读者划线质疑、提交传闻，以及作者查看传闻跨阵营流动，也不是现有秘密功能的主要流程。新产品需要靠更短的发布路径取胜，而非复制完整世界百科。
- Substack 与手工分组邮件：Substack 已具备文章和邮件发布、订阅者管理、免费与付费方案，以及创作者收入统计。 对已有邮件读者的作者来说，它是成本最低的惯用做法。作者可以开多个刊物，或手工维护不同名单，再分别发送阵营版本。不过这种方法会复制草稿、名单和修改工作，正史变更时容易漏改某个版本。其公开文档以刊物、文章和订阅方案为主要结构，没有事件、阵营知识和误解之间的关联模型。 它也不会验证某封信是否泄露了该阵营尚未知晓的事实。新产品的机会不是重做通用邮件系统，而是提供可接入邮件渠道的剧情权限与一致性引擎。

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

面向作者按月收取软件订阅费。基础档限制可用阵营和活跃订阅者数量，高阶档提高额度，并开放自定义域名、邮件模板和数据导出。读者付费仍由作者定价，平台可选择只收固定工具费，避免早期同时处理复杂抽成。

## 来源背景

主题：世界观创作者订阅发布平台
触发的 Product Hunt 新品：Lore Machine — Substack For World Builders

以上只记录新品出现在 Product Hunt 公开 feed 与被观测的事实；该 feed 不提供票数，不要把 feed 顺序描述成热度或市场需求。

## 来源清单

- Lore Machine: Substack For World Builders（https://www.producthunt.com/products/lore-machine）
- Getting Started with Secrets & Subscribers（https://www.worldanvil.com/learn/beginner-tutorials/get-started-secrets）
- How can I publish on Substack?（https://support.substack.com/hc/en-us/articles/29152946791188-How-can-I-publish-on-Substack）

## 交付要求

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