状态比文章数量更难处理#
6 月 2 日我主要在整理 AI Reader 的阅读流。
一开始它只是一个更聪明的 RSS 列表：左边选模块，中间看文章，右边看详情和问答。但用了一段时间后，我发现真正的问题不是文章太少，而是状态太乱。
未读、已读、星标、稍后读、已立项、评分维度、低质量源，这些东西如果只是堆在一起，用户还是会迷路。
新到、候选、已立项#
后来我把它拆成一个更自然的线索流：新到、候选、已立项。
新到就是 Miniflux 里的未读文章，它代表信息刚进入系统；候选复用 Miniflux 的星标，表示我觉得它值得后续关注；已立项则落在本地 entry_project_queue 里，表示它已经从阅读材料变成要跟进的线索。
这个设计没有引入 Miniflux 不支持的自定义标签，也没有去改 Miniflux 源码。
这个取舍很重要。Miniflux 是稳定的 RSS 后端，负责订阅源、抓取、未读/已读、星标；AI Reader 只补它没有的工作台状态，比如稍后读、项目队列、评分设置和源质量偏好。
这样做的好处是边界干净：以后 Miniflux 可以升级，AI Reader 也可以继续迭代自己的界面和状态表。
工作台按阅读流重排#
界面上也围绕这个思路改了。左侧不再只是普通分类，而是分成信息流、线索流、评分维度、订阅源管理。
默认列表是“最新/全部”，避免用户点开文章后因为未读状态变化，列表突然消失。候选和已立项保留可追溯性，即使某个订阅源被隐藏，已经被我标记过的文章仍然能打开。
专注阅读页也开始承担更明确的角色。工作台适合筛选，专注页适合阅读和追问。
文章可以刷新全文，如果抓不到完整正文，就明确提示当前只有 RSS 片段；Agent 回答会渲染成 Markdown，而不是把 ## 结论 这种文本原样丢出来。
这个变化不大，但让“AI 辅助阅读”从一个右侧小工具，变成了阅读流程的一部分。
订阅源质量不能只靠感觉#
这轮还有一个让我印象比较深的点：订阅源质量不能只靠感觉。
于是我加了 feed quality 统计，用最近 300 篇文章看完整正文率、blocked/fragment 比例、平均分、高分占比，以及星标、稍后读、已立项、已读这些用户行为。
系统可以把低质量源排后，用户也可以手动隐藏，但不会删除 Miniflux 订阅。
我没有让系统自动封杀低质量源，因为信息源的价值不是绝对的。有的源正文很差，但标题能提供线索；有的源平时一般，偶尔会有重要内容。
AI Reader 应该帮我降低噪音，而不是替我做不可逆决定。
数据流要分清楚#
从技术上看，这一轮主要是在理清数据流：
- Miniflux 提供原始文章和基础状态；
scorer-worker提供评分和摘要；reader-web把这些信号组织成模块、排序和操作；- PostgreSQL 存本地状态和偏好。
每一层都不复杂，但职责不能混在一起。
现在回头看，这个项目最有价值的地方不是“RSS + AI”四个字，而是它开始把阅读变成一个可执行流程：新文章进来，系统初筛；我挑出候选；重要内容进入项目队列；阅读时有摘要、评分理由和问答辅助；低质量源逐步降权。
它离成熟产品还远，但已经不是单纯的信息列表了。