我之前一直有个惯性想法：既然要做自己的个人 IP 工作台，阅读器也应该自己做。
这个想法听起来很顺。输入、收藏、筛选、生成内容机会，全部在一个系统里，数据也更干净。但真正试了一轮之后，我发现这里面有个误区：我真正缺的不是一个“自己写的阅读器”，而是一个能稳定承接真实阅读行为的入口。
个人内容系统最怕的不是少一个功能，而是输入链路太脆。每天读到的文章、收藏的内容、临时产生的判断，如果不能自然沉淀下来，后面的选题、草稿、发布候选都会变成补作业。
所以这次我把判断改了：阅读器不自研，改用 Miniflux。
Miniflux 已经把我需要的入口做到了足够好。
我实际体验了一轮 Miniflux 的阅读和 RSS 订阅流程，结果比预期好很多。阅读体验顺，RSS 订阅更稳定，而且它的可定制性够用。我加了内容 AI 总结，用来快速判断一篇文章值不值得继续读；又把 PC 页面调整成两列布局，减少来回跳转。
这些改动不大，但它们说明一件事：如果一个成熟工具已经能承接阅读、订阅、收藏和基础定制，我没必要再从头造一个阅读器。
真正应该自研的是后半段：把收藏内容变成可用的内容机会。
我的新路线是：以后内容尽量切到 Miniflux 里阅读，IP 工作台通过 Miniflux API 增量读取我收藏的内容，再把这些收藏转成外部内容机会。这样阅读仍然发生在一个成熟阅读器里，创作判断则沉淀到自己的工作台里。
这个取舍对独立开发者很重要。
很多自用工具最后卡住，不是因为技术做不出来，而是把边界画错了。明明只是需要一个稳定输入源，却开始做完整阅读器；明明真正的差异在后续判断和创作链路，却把时间花在通用功能上。
这次 Miniflux 给我的提醒是：成熟工具能解决的部分，尽量让它解决。自己的系统只接管真正有差异的部分。
当然，这条路线还没有完全跑通。
最大缺口是社交媒体平台。很多平台本身不支持 RSS，尤其是公众号、小红书、X 这类内容源，不能简单假设都能像普通博客一样订阅。
微信公众号这块，我目前的判断是先用自托管 WeRSS 做小规模试验：先接入 5–10 个重点公众号，连续观察 7 天，看漏文、延迟和授权状态，再决定是否导入 Miniflux。RSSHub 的公众号路由更多依赖间接来源，而且有反爬限制，只适合作为少量补充。
这也让我更确认一个原则：内容工作台不应该一开始追求“全平台自动采集”。更现实的做法是先把稳定输入源跑顺，再给不稳定平台设计降级方案。能 RSS 的走订阅，不能 RSS 的保留人工收藏或按需核验，不要为了全自动把证据质量做虚。
后面我会继续验证 WeRSS 的部署和稳定性。
这件事最后沉淀成一个很简单的判断：
个人 IP 系统的核心，不是拥有一个“全自研工具”。核心是让真实阅读、真实收藏、真实判断，能低摩擦地进入后续创作流程。
阅读器可以用现成的。
但什么值得收藏、什么值得写、什么能变成长期表达，这部分必须长在自己的系统里。