hindsight：一个将日记待办自动变成决策时间线的命令行工具

我花了三个月时间打磨一个叫 hindsight 的命令行工具老实说最初只是因为“记录太多、复盘太少”这件事让我坐不住了。hindsight 这个词直译是“后见之明”通常带点事后诸葛亮的调侃味但我想把它变成褒义每天产生在日记、待办、聊天记录和工作日志里的信息其实已经在替你回答“当时为什么这么决定”和“这段时间到底发生了什么”缺的只是有人把它们定时翻出来串成一条时间线。这个工具解决的最大问题不是帮你做年度总结而是把“回顾”变成一项日常自动化动作在你还来得及补救的时候就拉响警报。如果你也长期写日记、记待办、手动复盘但总是坚持不下来或者明明存了大量记录却从不用它们指导下一步决策那这篇内容应该对你有参考价值。1. 为什么我需要一个能自动“翻旧账”的工具1.1 复盘这件事难点从来不是不记得很多人以为复盘难在“记性不好”我不这么看。现在的工具链早就把记忆外包了日记存在 Obsidian待办在滴答清单工作记录在飞书文档聊天记录在微信。问题根本不是“没记录”而是记录之间彼此孤立没有人主动去做跨平台检索和二次加工。举个例子我 2 月份连续加班了三周每天都写了简短的 worklog。当时的感觉是“项目交付期辛苦一点很正常”并没有觉得有哪里不对劲。直到 4 月我翻回来看才发现那三周里我连续 18 天在凌晨 1 点后结束工作紧接着整个 3 月的工作效率都明显下滑。这中间的因果关系单看任何一条记录都看不出来但放在时间线上串起来看信号非常明显。这就是“后见之明”的核心价值它不创造新信息而是把旧信息重排给你看。手动复盘之所以难坚持是因为你要每天翻几个平台、做日期对齐、还要靠记忆把散点连成线这实在太累了任何一个环节偷懒整个习惯就断掉。1.2 手动复盘的三个断点恰好是工具能补上的我把手动复盘坚持不下来的原因拆成了三个断点数据收集断点记录分散在多个系统每周日晚上光是把它们汇总到一起就要花掉二十分钟。结构加工断点原始记录是流水账没有统一的“事件”字段看不出哪条是决策、哪条是情绪波动、哪条只是琐事。回看触发断点即使我做了周复盘也只会看本周不会自动把本周和一个月前做对比更不会在某个决策满 90 天时收到“该验证当初决定对不对”的提醒。hindsight 的设计目标就是针对这三个断点各给一个自动化方案。它不会替你思考但能保证你在不需要动用意志力的情况下每周都能看到一份结构化的“过去时报告”。1.3 做这个工具之前我给自己的验收标准为了避免把一个“记录工具”做成“又一个吃灰的电子手账”我在动手前给自己定了三条验收标准每天自动化运行不需要我手动点“生成复盘”。输出里必须有“时间对比”不能只是今日摘要。至少要能捕捉到一个我没意识到、但确实存在的模式。三个月跑下来第三条标准在第四周就达成了。它发现我的深度工作时段正在从上午悄悄滑向深夜而我自己毫无察觉。这条洞察直接让我把晚上的观影时间改成了上午的创作时间。上个月回访时我明显感觉到早晨的产出效率比深夜模式要高得多。2. 整体设计把“日记本”改造成“决策时间线”2.1 数据流转只有三步收入、标准化、回看hindsight 早期我试过引入消息队列、事件总线这类重型方案后来全砍掉了。原因很简单个人复盘的数据量根本不需要分布式用最简单的单向管道反而更稳采集层 - 清洗层 - 存储层 - 复盘层采集层负责从 Obsidian 的 Markdown 目录、待办事项里的 CSV 导出、以及按行追加的 worklog 文本里读取原始内容。清洗层做两件事一是把不同平台的文本统一成 UTF-8 的纯文本二是按时间戳把它们排进一个统一的序列里。存储层用的是 SQLite复盘层更像一个定时任务每天凌晨跑一次把当天新增内容喂给本地模型做结构化提取和复盘生成。这个架构最忌讳的一件事就是把“采集”和“复盘”耦合成一个实时在线服务。个人工具一旦需要常驻进程、异常恢复、容器编排维护成本就会迅速超过收益用起来是负担而不是帮手。2.2 为什么存放层选了 SQLite 而不是 JSON 文件很多人上来会用 JSONL 存流水账“反正模型能读”。但我的经验是一旦数据量超过几千条JSON 文件连按时间过滤都做不利索更别提按月聚合统计了。SQLite 虽然看上去很“上世纪”但它恰好卡在个人数据量和查询能力的最佳平衡点上单文件存储备份就是复制一个文件迁移没有任何负担。自带 FTS5 全文索引中文场景下配合分词词表可以做快速检索。SQL 聚合能力成熟按月、按类型统计的语句写起来非常顺手不需要额外写一堆 Python 循环。所以我的建议很直接个人复盘工具哪怕只给自己用也别省掉这一步用 SQLite 打底后续扩展任何分析功能都不会后悔。2.3 一张库表结构把什么能复盘说清楚hindsight 的核心表没有那么多我从中挑四张最关键的表名用途关键字段sources记录每个数据源的路径和类型id, type, path, enabledraw_items原始流水账保持一字不改id, source_id, occurred_at, raw_texttimeline_events标准化后的复盘事件id, raw_item_id, event_type, occurred_at, detailreview_reports每次生成的复盘报告id, report_at, report_type, content, model_used其中 timeline_events 是核心。所有复盘逻辑都围绕 event_type 展开我目前只保留五个类型加多了反而乱decision包含“决定、选择、打算、放弃”这类意图型表达commitment承诺了某天要完成的交付或者约定了某个节点emotion_peak情绪强度明显偏高的内容包括正面和负面time_invest明显围绕某个项目消费时间的记录milestone某个阶段性的成果或者节点有了这层标准化结构我后面写复盘 prompt 就有干净的数据可以喂给模型而不是把昨天一整天的流水账直接丢过去让模型去“大海捞针”。3. 核心实现事件抽取与复盘引擎3.1 事件抽取在文本里识别“决策点”和“情绪峰”事件抽取最笨也最稳定的办法是关键词词典加轻量规则而不是一上来就上大模型。比如“我决定把博客迁移到新框架”这句话要归类为 decision正常人都能判断但规则系统要怎么写我是这样处理的维护一张“决策触发词”表包括“决定”“确定”“最终选了”“还是用”“不再考虑”“选择”之类的动词再配合语气词“吧”“了”“算了”做置信度加权命中两个以上特征才标记为 decision。情绪峰的识别更麻烦因为情绪表达往往藏在感叹号、形容词叠词、以及“气死我了”“开心到转圈”这类习语里。我的做法是分两层判断第一层用情感词典打分第二层用本地模型判断上下文情绪极性两层分数加权超过阈值才标记成 emotion_peak。这里有个经验教训千万不要试图在抽取阶段做得过于精准。抽取的目的是缩小后续分析的范围不是给历史记录做学术标注有少量误判完全可以用复盘阶段的上下文来纠正。比如“然后我把 bug 彻底删掉了”这句话“彻底”不一定是情绪峰但也不算致命。3.2 复盘运行器定时盘点与决策回访的两套 triggerhindsight 的运行逻辑说到底只有两种触发模式每天定时跑和延迟回访。定时模式我直接用系统的 cron 在每天凌晨 0:30 执行一次。触发后程序会取前一天的全部 raw_items做两件事一是调用本地模型生成一份“昨日摘要”二是把昨天的事件按类型聚合和上周同期做环比把差异超过 30% 的维度单独列出来。比如上周一写了 3 条待办这周一写了 8 条它就会提示“待办数量明显上升可能存在过度承诺”。延迟回访模式专门服务 decision 类事件。当一条记录被标记成 decision 后我会给它设置一个 90 天的回访日。到了那一天hindsight 会把当初的原文段落调出来加上这 90 天内与该主题相关的事件列表放在同一个 prompt 里让模型生成“当初预期 vs 实际结果”的对照报告。SQL 上做回访也非常直观SELECT de.occurred_at, de.detail, d.review_at, COUNT(DISTINCT te.raw_item_id) AS related_events FROM timeline_events de JOIN decision_reminders d ON d.decision_event_id de.id LEFT JOIN timeline_events te ON te.occurred_at BETWEEN de.occurred_at AND d.review_at WHERE d.review_at date(now) GROUP BY de.id这个查询每天晚上跑一遍就能找出所有“该做决策回访但还没回访”的事件。3.3 prompt 调优经验一句话让模型别生成彩虹屁复盘模型最让人抓狂的输出不是没结论而是满篇正确的废话比如“你本周整体状态稳定建议继续保持”。这类内容毫无信息量本质上是模型在用泛化语句糊弄你。我调优后确定的系统提示词里有这么一句话效果非常显著如果当前结论无法从时间线上具体的证据条目中推导出来就直接说“本项没有可验证的结论”不要输出建议。加上这句话之后模型的输出质量提升了一个量级。它不再硬凑建议而是会把证据列出来比如“4 月 3 日的记录显示你在处理数据迁移时连续 6 小时没有中断但 4 月 4 日原定完成的接口联调没有出现对应进度记录建议核对是否存在计划外的空耗。”这样的产出才有复盘的真正价值它是可以被证据检验的而不是感觉上舒服的。4. 本地运行与隐私边界4.1 为什么一句话没说就排除了云端方案记日记这类文本的私密等级比账号密码还高。写日记的人可以接受密码泄露后改密码但绝对无法接受某天的情绪记录留在第三方服务器上。所以我从立项第一天就定了一条铁律hindsight 必须在本地跑连注册账号、上传文本这类概念都不允许有。这意味着数据处理链路必须完全封闭采集、存储、分析都在同一台电脑上完成。有人问那模型怎么办现在本地模型的发展速度已经足够支撑复盘任务了8B 到 14B 参数的模型跑在我这块消费级显卡上单次摘要大概几秒到十几秒完全在可接受范围内。4.2 本地模型 FTS5 语义检索的混搭纯靠 SQL 的 like 查询做事件抽取会漏掉大量口语化表达这时候我会用 FTS5 全文索引做一次相关性召回再交给本地模型做最终分类。FTS5 的中文分词是个老话题我这里直接说结论不要指望默认分词器处理中文效果能好到哪去最好在导入时额外做一份按词拆分的配对表。我目前是给每条 raw_items 额外存一份“关键词摘要”字段写入时用结巴分词把名词和动词拆出来用空格拼接后单独建 FTS 索引。查询时先走关键词再回表拿完整文本速度比直接在全文本里扫快几个数量级。这个“混搭”思路其实是想明白了一个道理复盘不是搜索引擎不需要保证所有结果都召回只需要把最相关的那三五年里最高频的主题捞出来就已经强过大多数人工盘点。4.3 备份与迁移要注意的坑本地运行有一个隐性问题数据越来越宝贝备份反而更要自动化。我的方案很简单每天 cron 里多加一条命令把 SQLite 文件复制到 NAS 的指定目录再定期用加密压缩包做整机备份。这里有个实操细节SQLite 文件正在被写入时不能直接拷贝否则容易拿到不一致的快照。正确做法是用sqlite3 .backup命令生成在线一致性备份或者干脆在凌晨运行复盘任务前先结束写事务再进行拷贝。这两个方案我实测都稳定任选一个都比直接 cp 可靠。另一个坑是模型参数差异带来的不可复现问题。同样是本地模型几天后更新了权重生成出来的复盘风格可能就变了导致你没法做长周期对比。我采取的保守策略是每次生成复盘报告都把当时所用的模型标识和温度参数一起写进 review_reports 表。这样后来再看历史报告至少知道为什么这一周的措辞风格跟上一周不一样。5. 实测三个月的收获与噪音5.1 让我印象最深的几条洞察hindsight 跑满三个月后我回翻了产出的 47 份周报和 12 份决策回访报告其中三条洞察让我觉得这个工具没有白做。第一条我已经在前面提过深度工作时段从上午漂移到了深夜。复盘数据显示这个变化用了将近两周期间没有任何一天让我感觉异常。如果不是按周对比时长分布我是绝对察觉不到的。第二条和任务承诺有关。hindsight 统计出我在一个季度内的承诺类事件中有 23% 出现了“承诺当天有记录、到期日前后一周无任何进展记录”的现象。翻译成大白话就是我答应出去的事有近四分之一会在执行期完全断线。这个比例比我直觉估计的高不少促成了我现在对外承诺时必须先写一句“预计产出时间和风险点”。第三条是情绪峰与项目周期的关联。我的情绪低谷出现的时间段和项目交付冲刺期高度重合这个结论算常规操作但神奇的是它有大约一周的滞后性也就是说情绪真正跌落的时候项目往往已经进入收尾阶段了。这让我学会了提前给自己加缓冲期。5.2 噪音来源分析哪些复盘结果完全没用不是每一条复盘都有价值有一段时间输出的噪音比例高达四成。最常见的噪音有两种。第一种是时间粒度错误。比如我早上写的是“刚才”程序默认把它归为当天凌晨结果时间线把上午十点的会议记录串到了凌晨两点的日志后面模型就把数据搞错了生成了一句“深夜仍记录任务进展脑力负荷偏高”。这种错误一回两回还好常年存在就会让人不再信任复盘结论。我后来通过限制“相差不到 12 小时且来源文件不同”的事件不做关联才把这类噪音压下去。第二种是模型幻觉式的关联。特征是两个毫无关联的主题放在同一个 prompt 里模型自动脑补出因果关系。比如“今天给博客加了搜索功能”和“晚饭吃了麻辣烫”本来没有关系模型却生成出“饮食刺激可能促进了工作产出”这种毫无意义的结论。解决方法是给 prompt 加一条证据链约束要求结论必须引用具体事件 ID没有共同标签的事件默认不建立关联。5.3 我给 hindsight 加的“防瞎说”机制为了让复盘报告更可验证我后来实现了一个最小化的证据校验模块。模型生成每条洞察时必须附带引用事件的 ID 列表。程序会检查这些 ID 是否存在、是否属于对应时间范围如果不满足就直接丢弃这条洞察。这个机制看起来简单实际上把复盘从“模型的独角戏”变成了“数据与模型的交叉验证”。在加入这个机制之前报告读起来像 AI 味很重的周报加入之后报告明显更像一个熟悉自己脾气的朋友在说话。凡事都把结论锚定在证据上信息密度反而更高。6. 后续还能怎么扩展hindsight 现在的形态已经让我的复盘习惯稳定了大半年但我也清楚它还有很大的开发空间。我打算做的第一件事是加入目标追踪模块。在写入时间线时如果检测到某个事件跟已设置的目标关键词相关就把它追加到该目标的进度时间线里。周末复盘时直接看到“目标 A 本周推进 3 次、累计投入 14 小时”这会比零散事件统计更有方向感。第二件事是把“后见之明”往前推一步变成“先见之明”。既然已经积累了大量事件序列理论上可以做简单的模式前置预警。比如发现每次情绪低谷前都有连续三天睡眠不足和任务量陡增的迹象那下次这个组合出现时就提前亮黄灯在真的情绪滑坡前提醒自己减少排期、增加休息。这算时间序列预测的极简应用数据量虽然小但对个人场景这种粗糙粒度已经够用。第三件事是沉淀一套模板化的复盘查询。现在我仍然经常临时写 SQL 去翻历史思考能不能把这些高频查询固化成一个hindsight query子命令比如直接跑“近 90 天决策回访清单”“本月承诺兑现率”。这纯粹是从工具角度提升易用性但做出来之后每天的使用门槛会更低。如果你写了一段自己的“hindsight”我最大的建议是必须先忍受噪音阶段。工具刚跑起来那两周输出质量会参差不齐看到几条垃圾结论就想删掉这时候一定要继续积累数据。复盘这类东西真正发挥作用的时间维度往往是月度而不是单次活得足够久才是它最大的本领。