大脑活动量化与数据建模：Edgi 的 Strava 式活动流设计

打开电脑，看一眼自己的浏览器历史、笔记软件、Kindle 高亮和稍后读列表，混乱得像一间没有整理过的书房。但你手机上有一张很漂亮的 Strava 图表，记录着上周跑了多少公里；有一份详尽的 Letterboxd 看片清单，标注着每部电影的评分和短评。大脑每天都在高强度工作，可它产出的数据反而最不体面，最难以回顾，也最容易被忽视。

这就是 Edgi 这个项目有意思的地方。“Show HN: Edgi – Letterboxd or Strava for your brain”，一句话就把产品定位说清楚了：给大脑装一个运动记录仪。本文不打算停留在“好酷”的层面，而是要拆开讲清楚三件事：这类产品到底在解决什么真实问题，它背后的数据结构和技术难点是什么，以及如果你想做一个类似 MVP，应该从哪些模块开始落地。

先说结论：Edgi 这类产品的价值，不在于“多了一个记录工具”，而在于它第一次把读书、思考、写作、深度学习这些原本非结构化的“大脑活动”，用 Strava 式的活动流模型变成可量化、可回溯、可分享的数据。对开发者来说，最值得学习的不是 UI，而是这种“把不可见行为变成结构化数据”的建模思路。

1. 这篇文章真正要解决的问题

先想想一个很常见的场景：周末晚上，你回忆这一周做了什么。能想起来的往往是零散的碎片：周一改了一个 bug，周二开了两小时的会，周三看了几十篇技术文章，但看完就忘了。到了写周报或者做季度复盘的时候，你根本说不清自己这周到底在“什么”上花了多少时间，也没有任何数据可以支撑这个回顾。

我们愿意在 Strava 上记录跑步，因为那是一种“看得见的努力”；愿意在 Letterboxd 上标记电影，因为那是品味的展示。但大脑的劳动——阅读、笔记、思考、创作、专注复习——它们更频繁、更琐碎、也更私密，传统工具一直没有很好地支持。

已有的工具都缺一块：

• 任务管理工具（Todoist、Things）记录的是“未来要做的事”，不关注你实际把时间花在了哪里。
• 笔记工具（Notion、Obsidian）记录的是“思考的产出”，不记录你读了多少、想了多久、状态如何。
• 时间追踪工具（RescueTime、Toggl）记录的是“应用使用时间”，但缺少语义：它知道你打开了 Chrome 两小时，却不知道你是在写文章还是在刷短视频。
• 阅读工具（Kindle、Readwise）只覆盖阅读这一个子集，无法统一呈现“阅读 + 笔记 + 写作 + 思考”的整体图景。

Edgi 类产品的切入点是：把 Strava 的“一次骑行 = 一次活动”模型迁移到大脑活动上。“一次深度阅读 = 一次活动”“一次两小时写作 = 一次活动”“一次专注冥想 = 一次活动”。记录之后，用户能看到自己这周的“脑力活动”分布，而不是单纯地看屏幕时间。

这篇文章适合三类读者：

第一类，对量化自我（Quantified Self）感兴趣的开发者，想知道这类产品的功能边界与技术复杂性。 第二类，正在做阅读追踪、行为记录、学习管理类产品的开发者，需要一套清晰的数据建模参考。 第三类，日常被信息过载困扰，想用数据重新认识自己大脑使用方式的用户。

注意，本文会基于项目标题和产品类比做合理推断，而不是照搬官方文档。Edgi 目前还处于 Show HN 阶段的早期产品，实际功能以官方发布为准，但同类产品在数据模型和工程实现上高度相似，下面的思路可以直接复用。

2. “for your brain”是什么意思：拆解两个类比

理解 Edgi 的捷径，是拆开题目里的两个参照物。

2.1 Letterboxd 在记录什么

Letterboxd 是一个电影社交平台，核心操作是：看完一部电影后，标记“看过”，打分，写一句短评，然后把它加入自己的年度清单。

它解决的是“电影记忆管理”问题。很多人看完电影不写任何记录，一个月后就只记得“好看”或“不好看”。Letterboxd 把这种一次性消费变成了一种数据资产：你的观影历史、你的口味分布、你的年度总结。它的价值不在于打分本身，而在于“低摩擦 + 可回溯”。

2.2 Strava 在记录什么

Strava 是一个运动追踪平台，核心操作是：开启一次跑步或骑行记录，结束时保存，得到速度、距离、心率、路线等一系列指标，并和过去的自己、和社区里的朋友比较。

它解决的是“训练过程可视化”问题。跑步这件事如果不记录，你只知道“我跑过”，但不知道“我这周比上周进步了多少”。Strava 把运动变成了时间序列数据，让普通人拥有了专业运动员才有的数据化复盘能力。

2.3 Edgi 把两个模型叠加到“大脑”上

用 Letterboxd 的模型，你可以给一本读过的书打分、写短评、维护一份年度阅读清单，形成品味档案。 用 Strava 的模型，你可以“记录”一次深度工作会话：从几点开始、持续多久、中间有没有打断、结束时产出了什么，形成脑力活动的时间序列。

两套模型合并在一起，“for your brain”的含义就完整了：大脑活动既有“品味的沉淀”（读过的书、看过的资料、写过的笔记），也有“状态的追踪”（专注时间、阅读时长、思考强度）。

整个系统想解决的是同一个问题：如何建立一个人的“精神履历”——不是简历那种技能列表，而是你大脑每天都在如何运转的行为记录。

2.4 和传统效率工具的本质差异

这里要强调一个容易被忽视的点。传统效率工具是“以任务为中心”的，它们关心“你是不是完成了该做的事”；Edgi 这类工具是“以数据为中心”的，它们关心“你实际上把脑力用在了哪里，状态如何变化”。

“任务”是目标导向的，而“活动”是行为导向的。这个区别在数据模型上非常关键：任务管理系统的主实体是 Todo，状态只有未完成和已完成；而行为记录系统的主实体是 Activity，需要描述持续时长、开始时间、关联对象、质量评分、精力状态等多维信息。

这意味着，Edgi 类产品的数据库设计会比普通 To-Do 应用复杂得多，因为它本质上是一个面向“自我认知”的时间序列系统。

3. 从数据角度看，这类产品为什么值得做

抛开产品概念的光环，开发者更关心的是：这背后有什么真实的数据价值？为什么值得投入精力去记录所谓“大脑活动”？

3.1 大脑数据是目前最大的数据盲区

我们已经在手机上积累了大量的行为数据：位置轨迹、社交互动、购物偏好、视频观看历史。但所有平台都没有完整覆盖一件事：你读了多少、思考了什么、产出什么。在数据价值链上，“大脑活动”是被互联网巨头普遍忽视的高价值盲区。

如果你能采集用户每周的阅读时长、写作时长、笔记产出数量、深度专注总时长，你得到的数据比社交平台的“点赞行为”更能反映一个人的认知状态。这类数据的商业想象空间很大，但在早期阶段，它的核心价值首先是“对用户自己有用”。

3.2 数据形态足够复杂，有技术挑战

大脑活动数据有四个明显特征：

第一，非结构化。一篇笔记可以是文字、代码、思维导图、语音备忘，内容几乎无法统一建模。第二，强主观性。同样是“阅读一小时”，有人是在深度精读经典，有人只是在刷资讯流，二者的认知价值完全不一样。第三，多源异构。数据分散在 Kindle、微信读书、浏览器历史、笔记软件、日历、Apple Health 之中，合流非常困难。第四，隐私高度敏感。阅读和思考记录是比运动数据更私密的个人信息，如果同步到云端，就涉及用户对平台的核心信任问题。

这四个特征决定了，Edgi 类产品不是“页面画几个表单”就能做出来的。数据采集、数据清洗、标签体系、隐私保护，每一个环节都考验工程能力。这也是为什么做这类产品，一个清晰的数据建模方案比前端交互更重要。

3.3 产品闭环：从记录到自我认知

物理世界有“身体指标”的概念：体重、体脂、睡眠时长。大脑世界同样需要“认知指标”的概念：深度阅读时长、专注会话次数、输出字数、知识主题分布。

有了这些指标，用户才能在两周之后回答这些问题：我最近是不是读得太散？我的深度工作时间是不是被会议挤掉了？我这个月有没有持续在同一个领域产出？这种“看见”本身就是一种改变的动力。产品如果能把闭环跑通，让用户产生“我要重新分配精力”的冲动，留存是水到渠成的事。

对开发者来说，这个闭环意味着：你构建的不只是一个记录工具，而是一套帮助用户建立自我觉察的反馈系统。这类产品的留存来自“数据积累”，用户数据越多，离开成本越高。这与社交产品的网络效应一样重要，也是产品长期价值的根基。

4. 大脑活动记录系统的数据建模

从工程角度说，“for your brain”不是一个抽象的营销概念，而是一个非常具体的数据建模问题。核心任务是回答：用什么数据结构描述一次“大脑活动”？

4.1 核心实体设计：活动流模型

先看核心表结构。下面是一个可运行的设计，适合作为 MVP 起点。

-- 文件路径：schema.sql -- 核心活动表：一次阅读、写作、思考都算一条记录 CREATE TABLE activities ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT NOT NULL, -- 用户标识 type TEXT NOT NULL, -- reading / writing / thinking / reviewing / learning_side_project started_at TEXT NOT NULL, -- ISO 8601 时间，例如 2025-01-12T19:30:00+08:00 duration_minutes INTEGER NOT NULL, -- 记录时长，单位：分钟 source_type TEXT, -- kindle / browser / manual / notion / apple_health / readwise / api source_id TEXT, -- 外部系统的主键，用于幂等去重 title TEXT, -- 本次活动的标题或主题 quality_score INTEGER, -- 用户自评 1-5，代表这次活动的质量 note TEXT, -- 短评或备注 created_at TEXT NOT NULL DEFAULT (datetime('now')), UNIQUE(user_id, source_type, source_id) -- 防止同一来源记录重复导入 ); -- 标签表：活动与标签多对多 CREATE TABLE tags ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT NOT NULL, name TEXT NOT NULL, UNIQUE(user_id, name) ); CREATE TABLE activity_tags ( activity_id INTEGER NOT NULL REFERENCES activities(id), tag_id INTEGER NOT NULL REFERENCES tags(id), PRIMARY KEY (activity_id, tag_id) ); -- 统计快照表：用户可能要按月看自己的大脑活动 CREATE TABLE monthly_summary ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT NOT NULL, month TEXT NOT NULL, -- 格式 YYYY-MM type TEXT NOT NULL, total_minutes INTEGER NOT NULL, activity_count INTEGER NOT NULL, avg_quality REAL, UNIQUE(user_id, month, type) );

几个关键设计决策说明：

第一，用户维度必须从一开始就加上。虽然 MVP 可能只有你自己在用，但后面做多用户、做社交、做分享，都需要 user_id 隔离。

第二，使用started_at + duration_minutes而不是started_at + ended_at。因为用户记录时往往只记得“我读了一个小时”，不记得精确的结束时间。读取时统一用started_at+duration_minutes计算结束时间。

第三，source_type + source_id的联合唯一约束极其重要。它保证同一条 Kindle 阅读记录不会因为同步逻辑的 bug 被导入两次。真实环境里重复数据很难清理，最好在表结构上就杜绝。

第四，quality_score是这类产品特有的字段。运动数据有配速、心率这些客观指标，大脑活动没有统一的客观度量，只能依赖用户自评。这张表保留这个字段，以后做“什么类型的活动质量更高”这类分析才有素材。

4.2 用事件流而不是状态存储

新手容易犯的错误是去设计一张“用户信息表”，记录用户的累计阅读时长、累计写作时长。这个设计在初期看着方便，但很快会出问题。

原因是“累计值”是状态，状态可以推导，不能当唯一数据源。如果用户导入了 100 条历史记录，你的累计逻辑就要重算一遍；如果用户删除了某条记录，累计值也要同步更新。任何状态不同步，就会出现“记录显示我读了 100 小时，但明细加起来只有 95 小时”的尴尬情况。

正确做法是：activities 表是唯一事实来源，累计值永远通过SELECT SUM(duration_minutes) FROM activities WHERE user_id = ?动态计算。如果需要高性能查询，再用定时任务把聚合结果刷到 monthly_summary 表，而不是在写入时维护累计字段。

4.3 为什么不需要“睡眠”和“心率”

做一个大脑活动记录产品时，很容易被“要不要接入 Apple Health，记录心率、睡眠”带偏。

这里要区分两类数据：一类是本产品自己就能产生的业务数据，比如阅读记录、写作时长、笔记数量；另一类是第三方设备数据，比如心率变异性、睡眠分期。设备数据听起来很硬核，但它对“用户是否更了解自己的大脑”这个核心闭环帮助有限。更关键的是，接入设备数据会迅速消耗你的开发资源，从传感器权限、数据同步到图表展示，每一条链路都不简单。

MVP 阶段的建议是：不做设备数据。把精力集中在用户主动记录、外部阅读数据自动导入和统计反馈这个主线上。等到用户已经养成了记录习惯，再考虑引入身体指标做关联分析，比如“睡好了之后深度阅读时长是不是更长”。

5. 最小可行产品：快速实现一个 Edgi 类 MVP

下面给一个完整的 MVP 实现路径。技术栈选用 FastAPI + SQLite + 原生 HTML，目的是让过程尽可能短，一个人在一个晚上可以跑完。

这个实现的完整代码路径如下：

edgi-mvp/ ├── main.py # FastAPI 应用，包含接口和页面 ├── schema.sql # 上面的建表语句 ├── requirements.txt # 依赖 └── data.db # 运行时自动生成

5.1 环境准备

建议使用 Python 3.10 及以上版本。需要安装的依赖较少，核心是 FastAPI 和 Uvicorn。

mkdir edgi-mvp && cd edgi-mvp python3 -m venv venv source venv/bin/activate pip install fastapi "uvicorn[standard]"

如果你偏好使用 Conda，也可以直接创建虚拟环境后安装依赖。版本要求并不苛刻，以实际安装到的最新稳定版为准即可。

5.2 核心接口实现

先创建main.py，实现三个核心能力：记录活动、查询活动列表、查看每日统计。

# 文件路径：edgi-mvp/main.py import sqlite3 from datetime import date, datetime from typing import Optional from fastapi import FastAPI, HTTPException, Query, Request from fastapi.responses import HTMLResponse from pydantic import BaseModel DB_PATH = "data.db" app = FastAPI(title="Edgi MVP") def get_db(): conn = sqlite3.connect(DB_PATH) conn.row_factory = sqlite3.Row return conn def init_db(): with open("schema.sql", "r", encoding="utf-8") as f: schema = f.read() conn = get_db() conn.executescript(schema) conn.commit() conn.close() class ActivityIn(BaseModel): type: str started_at: str duration_minutes: int source_type: str = "manual" source_id: Optional[str] = None title: Optional[str] = None quality_score: Optional[int] = None note: Optional[str] = None class ActivityOut(ActivityIn): id: int created_at: str @app.on_event("startup") def startup(): init_db() @app.post("/api/activities", response_model=ActivityOut) def create_activity(activity: ActivityIn): if activity.duration_minutes <= 0: raise HTTPException(status_code=400, detail="duration_minutes 必须大于 0") if activity.quality_score is not None and not (1 <= activity.quality_score <= 5): raise HTTPException(status_code=400, detail="quality_score 必须在 1-5 之间") conn = get_db() try: cur = conn.execute( """ INSERT INTO activities (user_id, type, started_at, duration_minutes, source_type, source_id, title, quality_score, note) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?) """, ( "default-user", activity.type, activity.started_at, activity.duration_minutes, activity.source_type, activity.source_id, activity.title, activity.quality_score, activity.note, ), ) conn.commit() row = conn.execute( "SELECT * FROM activities WHERE id = ?", (cur.lastrowid,) ).fetchone() conn.close() return dict(row) except sqlite3.IntegrityError: conn.close() raise HTTPException(status_code=409, detail="记录重复，请检查 source_id") @app.get("/api/activities", response_model=list[ActivityOut]) def list_activities( activity_type: Optional[str] = Query(default=None, alias="type"), date_from: Optional[str] = Query(default=None), date_to: Optional[str] = Query(default=None), ): sql = "SELECT * FROM activities WHERE user_id = 'default-user'" params: list = [] if activity_type: sql += " AND type = ?" params.append(activity_type) if date_from: sql += " AND substr(started_at, 1, 10) >= ?" params.append(date_from) if date_to: sql += " AND substr(started_at, 1, 10) <= ?" params.append(date_to) sql += " ORDER BY started_at DESC LIMIT 100" conn = get_db() rows = conn.execute(sql, params).fetchall() conn.close() return [dict(row) for row in rows] @app.get("/api/stats/daily") def daily_stats(day: str = date.today().isoformat()): conn = get_db() rows = conn.execute( """ SELECT type, COUNT(*) AS activity_count, SUM(duration_minutes) AS total_minutes, AVG(quality_score) AS avg_quality FROM activities WHERE user_id = 'default-user' AND substr(started_at, 1, 10) = ? GROUP BY type ORDER BY total_minutes DESC """, (day,), ).fetchall() conn.close() return {"date": day, "items": [dict(row) for row in rows]}

这段代码里有几个容易出错的细节：

• source_id不加会导致UNIQUE约束失效，所以如果你做外部导入，务必给每条记录生成一个稳定的来源 ID。手动记录时，可以让source_id留空，靠应用的业务逻辑控制不重复提交。
• 日期过滤使用substr(started_at, 1, 10)是为了兼容带时区的 ISO 字符串。如果你在业务上统一用 UTC 存储，这没任何问题；如果客户端传的是本地时间，务必在写入前统一转换，否则统计会从“某一天跑偏”变成“整体错乱”。
• 查询接口是阶段性的核心接口，因为用户最频繁的操作是“我今天读过书”，而不是“看报表”。

5.3 最小可视化页面

纯接口不方便日常使用，再加一个最简单的前端页面。这一步是为了验证“记录后能看”的闭环。

# 继续在 main.py 末尾添加 @app.get("/", response_class=HTMLResponse) def index(): return """ <!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>Edgi MVP</title> <style> body { font-family: sans-serif; max-width: 640px; margin: 40px auto; padding: 0 16px; } input, select, button { font-size: 16px; padding: 8px; margin: 4px 0; } .box { border: 1px solid #ddd; border-radius: 8px; padding: 16px; margin: 12px 0; } </style> </head> <body> <h1>Edgi MVP</h1> <div class="box"> <h3>记录一次大脑活动</h3> <select id="type"> <option value="reading">阅读</option> <option value="writing">写作</option> <option value="thinking">思考/规划</option> <option value="reviewing">回顾/复习</option> </select> <input id="duration" type="number" placeholder="时长（分钟）" min="1" /> <input id="title" type="text" placeholder="主题（可选）" /> <button onclick="submitActivity()">保存</button> </div> <div class="box"> <h3>今日统计</h3> <button onclick="loadStats()">刷新</button> <pre id="stats"></pre> </div> <script> async function submitActivity() { const payload = { type: document.getElementById('type').value, started_at: new Date().toISOString(), duration_minutes: parseInt(document.getElementById('duration').value, 10), source_type: 'manual', title: document.getElementById('title').value || null, quality_score: null, note: null }; const res = await fetch('/api/activities', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(payload) }); alert(res.ok ? '已记录' : '保存失败，请查看控制台'); } async function loadStats() { const res = await fetch('/api/stats/daily'); const data = await res.json(); document.getElementById('stats').textContent = JSON.stringify(data, null, 2); } window.onload = loadStats; </script> </body> </html> """

这一步验证的是核心闭环：用户在页面选择活动类型，填入时长，保存，然后看到今天的汇总。这个页面虽然简陋，但它已经有“记录 → 存储 → 聚合 → 反馈”的完整链路了。

5.4 启动运行

pip install -r requirements.txt uvicorn main:app --reload --port 8000

如果这一步成功，终端会显示 Uvicorn 启动日志，访问http://127.0.0.1:8000可以看到页面，访问http://127.0.0.1:8000/docs可以打开 Swagger 文档调试接口。

6. 运行结果与效果验证

接口是否正常，可以通过一条简单的 curl 命令验证。先手动插入一条阅读记录：

curl -X POST "http://127.0.0.1:8000/api/activities" \ -H "Content-Type: application/json" \ -d '{ "type": "reading", "started_at": "2025-06-10T20:30:00+08:00", "duration_minutes": 45, "source_type": "manual", "title": "读完《黑客与画家》第三章" }'

预期返回：

{ "id": 1, "type": "reading", "started_at": "2025-06-10T20:30:00+08:00", "duration_minutes": 45, "source_type": "manual", "source_id": null, "title": "读完《黑客与画家》第三章", "quality_score": null, "note": null, "created_at": "2025-06-10 20:35:12", "user_id": "default-user" }

验证成功标准很简单：返回的 JSON 里有自增的 id，并且没有报错。如果 category 或 type 填成了不存在的值，接口不会拦你，因为当前表结构没有枚举约束。这一点在 MVP 阶段可以接受，但生产环境建议改成枚举类型，避免统计里出现拼音、大小写混用、空格结尾等脏数据。

再验证当日统计：

curl "http://127.0.0.1:8000/api/stats/daily?day=2025-06-10"

预期返回：

{ "date": "2025-06-10", "items": [ { "type": "reading", "activity_count": 1, "total_minutes": 45, "avg_quality": null } ] }

这里要特别注意时间与字符串的问题。curl 携带的started_at带时区 +08:00，而统计接口用substr(started_at, 1, 10)做字符串截取，截取结果是2025-06-10，这依赖于数据写入时的时间格式保持一致。一旦某条数据写入的格式是2025-06-10T12:30:00Z（UTC 格式），同一天在北京时间 08:00 之前的数据就会变成前一天，统计看似“偶发”错误，实际是时区规则不统一导致的必然问题。这个 bug 在新手项目中非常高频，排查时先检查所有时间字段的格式。

如果运行失败，排查顺序如下：

第一，ModuleNotFoundError: No module named 'fastapi'，说明虚拟环境没有激活，或者没有安装依赖，运行pip install fastapi "uvicorn[standard]"。 第二，访问页面无样式，多半是浏览器缓存，强制刷新或换无痕窗口。 第三，端口被占用，换端口启动，例如uvicorn main:app --port 8001。 第四，数据库出现no such table，检查schema.sql是否放在项目根目录，以及启动时是否成功执行。

7. 从 MVP 到产品的常见问题与坑

MVP 跑通只是第一步，真正做产品时，有很多问题会浮出水面。

这里专门强调两个问题。

第一个是幂等。做外部数据导入时，最开始容易出现“跑一次脚本，数据翻倍”的情况。原因是外部 API 经常因为网络超时，让你不确定“上次是否已经写入成功”。解决方案一定是在表结构上做唯一约束，而不是在代码里“尽量判断”。数据库的唯一索引是最后一道防线，任何导入代码都不能绕过它。

第二个是隐私。大脑活动数据比位置数据更敏感。一旦产品支持多用户和云同步，就必须认真考虑数据加密、访问控制和导出能力。用户看到自己的阅读记录泄露，比看到运动记录泄露更惊恐。作为开发者，在第一版设计里就要思考：哪些字段需要加密，哪些统计可以公开，用户是否允许导出完整数据。MVP 阶段可以本地优先，但产品化阶段不建议把用户数据默认上传到无保护的对象存储中。

8. 最佳实践与工程建议

如果你要在这个方向继续深入，下面几条建议来自同类产品反复踩过的坑。

8.1 数据采集：手动 + 半自动 + 自动三层

手动输入是产品冷启动的必要条件，用户只有先手动记录几次，才能体会到数据的价值。半自动是通过分享或剪贴板，把用户在微信读书、Kindle、浏览器里看到的内容一键导入。自动是后台定时拉取外部服务的数据，比如 Readwise、Apple Health。

不要第一版就做全自动同步。因为外部平台的 API 不稳定，处理字段映射和增量同步会消耗大量时间。先把手动体验做到 5 秒内完成，再逐步加自动导入。

8.2 质量字段要单独设计

大脑活动不能像运动心率那样用设备测量，只能靠用户主观评分。主观评分有严重的膨胀问题，大多数用户会习惯性打高分。建议使用相对评分而不是绝对评分，例如问用户“这次专注程度比平时高还是低”，而不是“这次专注程度打几分”。相对值比绝对值更适合做趋势对比。

另外，质量字段应该是可选的。每次记录都要打分，用户会觉得是负担。可以让用户偶尔打分，系统只对打过分的数据做质量分析，没打分的记录仍然保留时长和类型信息。

8.3 周报和回顾是真正的价值时刻

记录本身不是目的，用户留下来的原因是回顾时有惊喜感。Edgi 类产品最核心的留存点是周报、月度总结和年度回顾。

就像 Strava 每周一给用户推送“你上周跑量超过 80% 的跑友”，大脑活动记录工具也应该定期生成一份“认知周报”：本周深度阅读时长、与上周的对比、最常出现的主题标签、输出字数变化。这类内容的生成不复杂，在 monthly_summary 表做好聚合基础上，用模板渲染即可。

建议把这部分功能放在所有图表之前。用户可能看不懂复杂的仪表盘，但一定看得懂“你这周专注时间上升了 23%”。

8.4 社交功能要克制

Strava 的社交是建立在一个公开可见的社区上的，但大脑活动比运动数据私密得多。如果 Edgi 做社交，应该默认所有数据私有，用户在自主选择后，才能公开某类活动的统计信息，比如“公开我 7 月读过的书”，但阅读时长、笔记内容保持私有。

建议按“内容私有，统计公开”的方式设计：读书列表可以分享，每种活动每周花了多少小时也可以分享，但具体的地点、笔记、备注永远不对外。这样既能满足用户展示自我的需求，又不会触碰隐私底线。

8.5 服务端和数据库选型

从 MVP 升级到正式产品时，SQLite 不建议继续用于多用户在线服务。推荐使用 PostgreSQL，原因是它的时间函数、JSONB 类型和全文检索在后续做语义分析时非常顺手。

引入外部阅读数据时，数据库表可以增加一个meta JSONB字段，用于存放不同来源的扩展数据，比如 Kindle 的书名、作者、章节进度。这样就不用为每个外部来源都建一张新表，扩展起来成本低。

9. 总结与后续学习方向

Edgi 这类产品最值得关注的点，不是“给大脑做记录”这个创意本身，而是它背后的思考方式：用运动类应用的数据模型，去重新审视大脑活动，把它从难以捕捉的抽象过程变成一组可以被存储、聚合、比较和分享的结构化事件。

对普通用户来说，它提供了一个重新认识自己时间分配的机会；对开发者来说，它是一座数据建模的迷宫，牵涉到时间处理、幂等导入、标签体系、统计聚合、隐私设计，每一步都有真实的复杂性。

如果你对这个方向感兴趣，下一步建议这样做：

在自己的机器上把上面的 MVP 跑通，记上三天的真实阅读和写作记录，然后看统计结果能不能回答你“我主要把时间花在哪了”。如果答案是“不能”，考虑是不是类型设计不够细，标签分类没有贴近真实使用方式。如果答案是“能”，再想想怎么接入你最常用的阅读工具，把导入流程自动化。

从“记录”到“看见”再到“改变”，是一个很长的链路。Edgi 还在这条路线的起点，但方向已经足够清晰。对开发者来说，这类产品的价值恰恰在于：它是少数几个能把自我认知、行为数据和产品设计结合在一起的实验场，值得持续关注。