从 inbox-first 改成 output-first↗
Daigest 的第一屏不是 unread queue，而是一个持续更新的 briefing。用户为每个主题选择可信 sources、写明关注标准和输出方式，系统定期生成可以直接阅读和分享的 document。
产品因此避开了“先堆 500 篇，再帮你清理”的 Reader 逻辑。
123每个主题拥有独立 sources、memory 与 schedule↗
竞品监控、技术学习和内部项目可以分别拥有 RSS、YouTube、Reddit、Slack、GitHub、Notion 或 URL sources，以及不同的 AI instruction。主题之间 context 隔离，减少一个全局 persona 把不同任务混在一起。
质量先由 source selection 决定↗
用户先选 5–7 个真正信任的来源，再写一句如“只保留 pricing change、launch 与 enterprise adoption”。AI 读取更新，过滤噪声、分类并写成 briefing；结果通过 email、Slack 或 share link 交付。
相同 sources 如果只给一句宽泛指令，很容易每次重复背景；如果为每个 feed 指定关注问题、受众、语气和排除项，briefing 才会稳定。Daigest 把 context 隔离在 feed 内，适合同时维护竞品、客户与内部项目。更进一步应让系统显示本次哪些 source 被使用、哪些没有变化、哪些因为权限或抓取失败被跳过。
Briefing 也可以成为 agent 的 grounded context↗
Daigest 公开 API、OpenAPI spec 与 agent skill。Agent 可以创建 feed、同步来源、查询变化、读取摘要，也能把自己的研究结果写回 feed 并发布 snapshot。RSS/URL 可直接通过 API 加入；Slack、Notion、GitHub 等 OAuth source 需先在网页连接。
since 与 has_changes 让外部 agent 在消耗一次 AI request 前先做便宜的状态检查。这是一种值得复用的接口语义：把昂贵生成从轮询中拆开。但它仍需要幂等 sync、游标、版本号和失败重试；否则多个 agent 同时拉取时，可能重复生成或把较旧结果覆盖到较新版本。
免费验证 briefing，付费扩大 source 与共享↗
Free 当前提供每月 20 次 AI requests、每个 briefing 两个 sources、两次 audio generation 与三天 version history。价值计量更接近“生成了多少持续 brief”而非“收藏了多少文章”。
套餐同时受 feed 数量、更新频率与 AI requests 约束。高频连接大量 sources 不一定更有价值，反而会产生重复 brief 和配额焦虑。更合理的使用方式是按业务节奏设置 schedule，让变更检测先阻止空跑；产品若能按 material change 而不是固定生成次数收费，会更贴近用户购买的结果。
公司、团队与资本：先确认是谁在经营↗
条款显示由 Darak 依据韩国法律运营；未找到可核实的法人登记号。创始人为 Sangkwun Kang，LinkedIn 标注 2025 年成立、2–10 人，并只显示两位成员。这是平台信号，不是审计后的 headcount。
FIRST-PARTY / REGISTRY · Daigest terms / operator ↗
极早期小团队：公开人员包括 Sangkwun Kang 与 Lee Seoyoung。产品同时覆盖连接器、生成、audio、share、billing 和 agent API，意味着每增加一种 source 都会显著放大维护面。
FIRST-PARTY / PLATFORM SIGNAL · Daigest company profile ↗ · Founder profile ↗
未找到 VC、accelerator、grant 或 crowdfunding 披露；也不能因此把它写成‘已验证 bootstrapped’。资本来源与 runway 均未知。
DISCLOSURE / UNKNOWN BOUNDARY · Daigest terms / operator ↗
能证明什么，不能证明什么↗
收入结论：未披露收入、MRR、付费客户、增长率或盈利。最诚实的结论是：已经建立收费机制，但没有公开证据证明 product–market fit。
DISCLOSED / UNKNOWN / SCENARIO · Daigest pricing ↗
可验证 traction：没有公开用户数、app-store 分发或可验证客户 logo。少量创始人访谈只能说明问题存在，不能证明 retention。定价页出现过 Free 5 与 20 AI requests 的 schema/UI 不一致，也是早期商业化尚在调整的信号。
PLATFORM / FIRST-PARTY SIGNAL · Daigest company profile ↗
没有找到独立产品评测、客户案例或 app marketplace cohort。LinkedIn 只能验证公司自述与可见成员，不能证明使用或 retention；因此 PMF 判断保持低置信度。
INDEPENDENT / PLATFORM SIGNAL · LinkedIn company signal ↗
收费模型：Free 验证单个 briefing；Starter $5/月提供 320 AI requests、30 audio、最多 5 sources；Pro $19/月提供 1,220 requests、150 audio、premium sources、小时级更新与 30 天历史，年付 8 折。价值单位是持续生成的 brief，而不是 unread item。
CURRENT PUBLIC PRICING · Daigest pricing ↗
REVENUE ENGINE
$5 Starter$19 ProAI request / audio limitsCOST ENGINE
Scheduled inferenceConnectors + OAuthAudio · email · support价格背后的成本与可持续性↗
Vertex/Gemini 推理、音频生成、Supabase/AWS Seoul、邮件发送、OAuth/connector 维护、定时任务、全文抓取、分享页面、支持与支付。Pro 的小时级更新和 150 次 audio 可能让重度用户的边际成本显著偏离平均值。
三个假设，以及怎样证明我们错了↗
以下不是一句‘值得做/不要做’的结论，而是三个可以被证伪的方向。任何一个 kill test 命中，都应停止为原叙事寻找借口。
把最重要的产品承诺放到失败路径里↗
4 个公开 sources + 1 个需要 OAuth 的 private source；第二次 sync 只改一条 release note，第三次加入相互矛盾的说明。
检查 connect surface、briefing example、OpenAPI/agent contract、pricing 与 version history；按 create → sync → has_changes → read → publish snapshot 还原调用顺序。
公开 evidence 支持 per-feed sources/context、scheduled briefing、share/audio 与 has_changes 节流；private OAuth 必须先在网页连接。has_changes 只证明 source/document 变化，未公开返回 canonical entity 的 old/new value。
第三次矛盾输入若只触发‘有变化’，agent 仍需重读全部 context；若 publish 与 sync 并发，公开资料没有说明 conflict resolution。
它已是 output object 与 agent context 的好原型，但不是结构化 delta store。应学习 contract，不应把版本历史误写成 event memory。
同一任务：Daigest 与 Inoreader 的证据边界↗
把 OpenAI、Anthropic、Vercel、GitHub releases 与一个内部项目源合成工作日早报，并让 agent 只在内容变化时读取。
| Same job / public evidence | Daigest | Inoreader | Decision boundary |
|---|---|---|---|
| 相同 5 sources setup | sources + instruction + schedule | feeds/folder + rules + report | Daigest 步骤少；Inoreader 控制面深 |
| private source | OAuth connector | newsletter/web/team integrations | 都需要权限边界；Daigest 的范围更年轻 |
| 增量接口 | has_changes + sync | feed update + rule execution | Daigest 对 agent 更直接，但 delta 语义更薄 |
| 产物 | editable/shareable briefing | article/report/digest | Daigest output-first；Inoreader library-first |
| 公开成本 | $5/$19 月付，按 request/audio | $89.99/年 + report/Team | Daigest 简单；重度 inference 的单位经济仍未知 |
Output 简单，不等于 source graph 已经解决↗
Daigest 明显降低日常消费成本，但结果仍依赖用户先找到高质量 sources。与 Feedly 相比，它没有同等公开成熟的 entity resolution、ontology、historical corpus 与 enterprise controls；与 Reader 相比，它也不是逐篇深读工具。
unknown unknown discovery 和长期 recall 是需要单独评估的能力。
外部网络与内部协作可以进入同一个 briefing↗
RSS、URL、YouTube、Reddit 提供公开信息；Slack、Notion、GitHub 等 OAuth connectors 提供团队上下文。每个 briefing 可以混合多种 source，却保持独立 instruction 和 memory，避免竞品监控与内部项目总结互相污染。
输出不是 email 附件，而是会继续更新的版本化 document↗
Briefing 有目录、share link、Markdown copy、audio 和 version history。它可作为人类阅读的文档，也可通过 API 被 agent 读取。这个设计让相同的 grounded corpus 同时服务会议、Slack 分享、研究和后续生成。
五个可信 sources 生成一份竞争情报晨报↗
产品经理为每个 competitor 加入官方博客、release notes、GitHub 和相关 subreddit，instruction 只保留 pricing、launch、partnership 与 enterprise adoption。系统每天同步并生成 briefing，经 Slack 推送给团队。
它把日常写作成本降到接近零，但 source selection 的质量仍决定上限。
先检查变化，再消耗 AI quota↗
官方 agent guide 建议先用 since 查询检查是否有变化，只有需要时才 sync；每次同步会消耗 AI request。这个小细节揭示了 agent-ready 产品必须暴露 delta，而不是让 agent 反复重读完整 corpus。
先有 connected document automation，后来才把 source briefing 说清楚↗
2025 年 onboarding 仍以 New Document、template、Sources tab、AI agent、review/edit 与 auto update 描述产品。到 2026 年，首页把它压缩成更容易理解的动作：选 sources，得到 briefing。Copy、share、audio、version history 和 folder 则保留了早期 document system 的基因。
这个历史解释了为什么 Daigest 既不像 Reader，也不只是 email digest：它的核心 artifact 是一份能被人编辑、被链接分享、被 agent 查询并按 schedule 更新的 document。
同一份 briefing 可以连接开放网络和组织内部变化↗
RSS、URL、YouTube、Reddit、Substack 与 X 提供外部 signal；Slack、Notion、GitHub、Discord 则提供团队上下文。Notion connector 能跟踪 page/database 修改，Slack connector 能总结 selected channels、决策和 action items。把两类 sources 放在一个 briefing 中，可以回答“外部市场发生了什么，以及内部团队做了什么”。
代价是权限模型更复杂。OAuth source 必须先在 web app 连接；agent 只能读取已授权的 feed。不同 source 的 retention、删除和访问政策也不一致，不能把统一输出误认为统一数据所有权。
has_changes 是很好的机器接口，但还不是完整 event memory↗
Agent guide 建议先用 since 检查 has_changes，只有变化存在时再 sync，因为同步会消耗 AI request。这使 delta 成为 API workflow 的显式控制信号，也避免 agent 每次重写全部背景。
不过它目前证明的是“source/document 有新内容”，不是“某个 entity 的 pricing 从 X 变成 Y”。要形成更高价值 intelligence，还需要 canonical entity、event type、old value、new value、evidence 与 confidence 等结构化记忆。
Snapshot、overwrite、Markdown 与 audio 让 briefing 离开产品也能工作↗
Share link 可以固定某一版本，也可以覆盖成 latest；Markdown copy 能进入 Notion、Obsidian 或另一个 LLM；audio 让通勤消费成为另一种 surface。对小团队来说，这些低摩擦 output 常比复杂 dashboard 更容易建立共同上下文。
版本能力也暴露一个关键问题：如果同一个 URL 被覆盖，读者需要知道哪段发生了变化；如果每次创建新 link，则需要 index 和 diff。单纯保存多个完整文本不会自动形成可读的 change history。
它占据 Reader 与 enterprise intelligence 之间的 output-first 空间↗
相对 Inoreader，Daigest 少了精细 inbox/rule workbench，却把设置压缩为 sources + memory + schedule。相对 Readless，它支持更广 source、private workspace 与 agent API；Readless 的 newsletter dedup/synthesis 更专注。相对 Feedly，它缺少同等公开成熟的 ontology、entity resolution 与历史 corpus，却用低设置成本服务个人和小团队。
Daigest 已经把“连接 sources、按时写 briefing、分享给人或 agent”做成低摩擦闭环，直接复制只会比拼模板和模型价格。仍有价值的上层是持续事实状态：系统不只说有新内容，而是记录某个客户、竞品或项目的旧状态、新状态、证据和影响。Briefing 变成 event memory 的一种视图，而不是每次从零重写的最终产品。
让用户购买 briefing，而不是购买另一个 inbox↗
Daigest 的核心学习是 output-first：先决定谁在什么时候需要读什么，再反推 sources 和 instruction。Share link、Slack 与 API 让 output 直接进入协作和 agent workflow，而不是停留在产品内部。
判断一个新方向是否只是 Daigest 的功能，可以问三个问题：如果删除漂亮的 briefing 页面，剩下的数据是否仍有独立价值；如果两周没有新文章，系统能否明确回答“没有重要变化”而不是生成重复背景；如果用户更换模型，历史实体、版本与判断是否仍然保留。只有答案都为是，产品才拥有超越定时摘要的资产。
补上 source discovery、event identity 与长期 delta↗
下一步不是更多 connector，而是让一句 objective 自动产生 source graph，并把跨 source 的同一事件合并成可引用对象；系统还应记住上周的 pricing、版本和合作关系，报告真正变化，而不是每天重写一份“最新摘要”。