我用自己的记忆数据，复盘最近一个月注意力去哪儿了
注意力复盘
我一直有个习惯，遇到新东西就想试一试。
很普通的折腾：看到一个工具，想试试；碰到一个小问题，就请 AI 助手一起查；某个流程不顺手，让它帮忙写个脚本；哪天写材料、整理表格、改文章时踩了坑，再让它把值得复用的经验记下来。
以前这些东西大多散了。
有些留在聊天记录里，有些留在命令行历史里，有些只在脑子里转过一圈。过几天再遇到类似问题，只觉得“这个坑我好像踩过”，但具体怎么解决的，已经忘了。
后来我借助 AI 助手搭起一套很土的自动化机制：日常折腾、材料整理、工具排障、文章写作，只要有一点值得复用的东西，就让助手沉淀进 Nowledge Mem。每天晚上，定时任务再汇总当天记录、提炼候选题材，写进知识库。第二天我打开日记和候选池，看哪些值得继续处理，哪些暂时放下。
这个机制的源头不是自动化。
真正的源头还是好奇心。先是好奇，才会上手试；试了才会遇到真实摩擦；遇到摩擦才会有翻车记录；有了记录，机器才有东西可整理。自动化只是一个兜底网，防止已经发生过的思考和踩坑白白丢掉。
最近我想到一个问题：既然一个月的记录都沉淀下来了，能不能反过来看看，我的注意力到底花到哪里去了？
先把一个月的记录拉出来
我把这个问题交给了 Codex：根据 Nowledge Mem 里的数据，回顾最近一个月，看看我的注意力主要落在哪些事情上。
Codex 检索到的记忆记录大概有 1000 多条。
这里要说明一下，这不是“我一个月做了 1000 多件事”。很多记录只是一个结论、一个坑、一次排查、一个偏好，甚至只是某个流程的补充说明。它更像是注意力留下的脚印，不是严格的工时表。
一个月的记录像注意力的脚印，不是工时表
因为 Codex 的额度消耗得太快了，我还给 Codex 提了一个要求：调用其他工具协助完成，由它负责核对和汇总。我没有逐条手工读，安排几个工具分头做事：
Codex 调用 cmd，把记录按关键词粗分并统计；
Codex 把必要的统计和背景交给 qodercn，让它提供分析草案；
Codex 调用 opencode，取得另一份分析意见，作交叉比对；
Codex 核对统计口径、处理不同意见，再把整理后的结果交给我。
我主要看 Codex 给出的结果报告，再根据结果继续提要求。看到“其他”占了不小一块，我就追问：这部分还能不能细分？看完分类，我又要求它给出把注意力放在有价值事情上的建议。
这次复盘就是这样一轮轮推进的：我提出问题、审阅结果和追问；Codex 拆解任务、调用工具、核对证据。报告能帮助我看见自己的习惯，至于以后把精力放在哪里，还要由我来决定。
Codex 的分析里，记录落在这些方向
Codex 做了主题分类，也按价值类型重新梳理了一遍。写成文章时，我要求把具体工作场景泛化，保留下面这些读者也能理解的类别。
第一类是正式交付。
比如工作方面的材料、问题清单、文档整理、表格核对、对外说明。这类事情不一定有趣，但有明确用途，也有外部节点。做完以后，要么能交出去，要么能被别人复用。
第二类是数据资产。
比如某个表格的口径、字段含义、统计方式、后续怎么更新。它们看起来像琐碎的数据清理，但只要整理清楚，后面就能反复使用。下一次再遇到类似问题，不用从头猜。
第三类是工具建设。
比如本地工作台、模型工具、自动化脚本、不同助手之间的分工。它们本来是为了省时间，但如果不小心，也会变成最耗时间的东西。
第四类是维护消耗。
比如环境坏了、权限不对、端口冲突、同步异常、某个服务没起来。这类事有个特点：不修不行，修完也不会产生新成果。它们只是在把系统恢复到能用。
第五类是内容输出。
比如文章草稿、配图、发布流程、选题池。它们不一定立刻有回报，但会变成长期资产。至少我以后可以回头看，知道自己是怎么从一个坑里爬出来的。
最后还有健康和生活。
这类记录不多，但权重其实很高。人本身才是所有系统的底座。工具坏了可以重装，人被长期透支，恢复起来就没那么简单。
记录按用途分成五摞，健康和生活单独放
最扎心的是：工具也会偷走注意力
统计结果出来以后，最扎心的不是正式材料多，也不是内容产出少。
让我留意的是，工具和维护在记录里占了很大一块。
这件事很容易被忽略。因为每次修工具时，都有一个很合理的理由：这次修好，以后就省事了。
这个理由没错。
问题是，“以后省事”不能无限透支“今天的注意力”。
Codex 整理出的例子里，有很多类似的片段：某个工具需要改配置，某个本地服务要设置自启，某个模型名称写法不对导致回退，某个脚本在特定环境里失效，某个权限开关关着导致调用失败。
单独看，每件事都值得修。
放在一个月里看，让个人工作系统跑得更稳，已经是一条反复出现的主线。记录能说明我经常围绕这些问题安排任务、跟进结果，但还不能据此算出实际花了多少小时。
这当然有价值。
但它也有风险。工具是为了服务产出，不该自己变成主角。如果一个月结束时，留下最多痕迹的是“我又修好了什么工具”，而不是“我交付了什么东西、写出了什么内容、沉淀了什么资产”，就说明注意力有点跑偏。
修好一堆工具，产出那只箱子还是空的
看过分析后，可以怎样安排注意力
我要求 Codex 继续给出取舍建议。把它的建议放回日常安排里，可以用三条线来看事情。
第一条叫产出线。
能直接变成成果的事，都放这里。比如一份材料、一篇文章、一个可以复用的清单、一份整理好的说明。
第二条叫建设线。
为了让以后更快、更稳、更省力而做的事，都放这里。比如工具、脚本、工作台、候选池、自动化流程。
第三条叫维护线。
不修会影响使用，但修完本身不产生新价值的事，都放这里。比如环境、权限、同步、端口、服务异常。
这三个词一分开，很多事就清楚了。
产出线要保护。建设线要有上限。维护线要集中处理，不能一天到晚被它打断。
三条线：产出线要保护、建设线有上限、维护线集中处理
比如，本来安排 Codex 协助写文章，途中发现图片流程有问题，便让它先处理；处理过程中，又给它加上修改脚本、调整工作台的任务。每一步都能说出理由，最初想完成的文章却可能一直往后排。
这就是注意力最容易漏掉的地方。
不是不努力，而是努力没有回到产出线上。
新事情进来，先问三句话
Codex 给出的建议中，有一个适合放在新任务前面的过滤器。
以后任何新事情进来，先问三句话。
第一，这件事会变成一个交付物吗？
可以是一篇文章、一份文档、一个表格、一段可复用流程。只要能留下明确成果，就算。
第二，不做会真的影响什么吗？
如果不做只是心里痒，或者只是觉得“以后可能有用”，那就先放进候选池，不要马上动手。
第三，做完以后，下次同类事情会不会明显更快？
如果答案是会，它可能是建设线里值得做的事。如果不会，它大概率只是一次性折腾。
三句话里至少两个是“是”，才值得马上做。
这个规则值得在接下来的安排里试一试。尤其是在我准备给 Codex 追加任务时，先想清楚做完要留下什么。
三道问话当过滤器，把有意思的事挡在门外
Codex 负责派工和验收
这次分析还有一个收获：我更明确了人与工具的分工。
这次过程中，因为 Codex tokens 额度有限，而我有 opencode go, command goat, agy, qodercn 等的套餐，我明确要求默认采用协作模式：我把目标交给 Codex，由它判断哪些环节适合交给其他工具。
命令行适合检索、统计和批处理；qodercn、opencode 可以承担草案、分析或其他执行任务。Codex 需要给它们清楚的要求和必要的材料，再核对返回结果。我也要求它每次汇报自己和其他工具分别完成了多少工作。这个比例按贡献估算，用来了解分工。
工具返回一段看起来通顺的话，还不算完成。验收本身也是我交给 Codex 的任务。
Codex 要核对有没有偷换概念：标签出现次数不能当成实际工时，记录数量多不能简单等于价值高，维护类记录多也不能直接证明一天被维护占满。同一件事在多个来源里留下记录，还要避免重复计算。
我审阅的是 Codex 汇总后的结果，继续追问遗漏、纠正理解偏差，并决定采纳哪些建议。这篇文章也是这样：我让 Codex 起草，再看它有没有把我的经历和它的执行过程混在一起。
分工说清楚以后，才知道哪里需要继续追问：工具输出的可靠性由 Codex 核对，我自己的目标和取舍由我负责。
我提出目标 → Codex 拆解并派工 → cmd、qodercn、opencode 等执行 → Codex 核对与汇总 → 我审阅、追问和决定下一步。
工具负责干活，Codex 负责派工和核对，我负责验收
把这次复盘接到每天的日记里
看完这次分析，我又让 Codex 做了一件具体的事：在每天的复盘里，增加对当天注意力分配的评价，以及明日建议。
Codex 已把要求加进 Hermes 每晚 23:40 的日记任务。从 9 月 26 日晚开始，任务会依据当天可见的记录，归纳主要投入方向，评价投入与产出的关系，并提示判断依据和不确定性。没有可靠时长，就不编一个看似精确的百分比。
明日建议最多三条，要有具体行动和依据，优先对应尚未完成的事、近期安排或值得继续推进的成果。我希望第二天打开日记时，能据此决定先把注意力放在哪里。这项改动刚加上，实际效果还要看后续日记。
最后
这次复盘以后，我对“时间都去哪儿了”这个问题有了一个更具体的答案。
时间不是一下子丢掉的。
从 Codex 整理出的记录看，工具调试、环境修补、临时好奇、顺手优化，是我反复关注的事情。每一件都有理由，放在一起却提醒我：安排这些任务的时候，也要看看最初想完成的成果走到了哪一步。
对我来说，接下来要做的不是再找一个更强的工具，而是把工具收住。
真正值得放注意力的事，大概就三类：
能交付的正式成果；
能复用的数据和流程；
能长期留下来的内容。
其他事情不是不能做，而是要排队。
记录的意义，也不只是为了保存过去。更重要的是，它能在某一天反过来提醒你：你一直说最重要的事，和你真正花时间做的事，是不是同一件事。
如果不是，那就该把注意力慢慢收回来了。
附：我的日常工作流与技术栈
这套技术栈服务的是每天的信息积累、复盘和写作。我把它分成记忆、整理、自动化和输出几层，工具各自负责一段，最后仍由我自己筛选和判断。
跨工具记忆：Nowledge Mem。我使用 Claude Code、Codex、Cursor 等 AI 助手处理任务，让值得以后复用的决定、处理过程、踩坑结论和个人偏好沉淀到 Nowledge Mem。助手可以通过 MCP 检索记忆和相关对话线程，减少换一个工具就要重新交代背景的麻烦。晚间自动任务则通过脚本访问 Nowledge Mem 本地 API，补充当天的跨助手记录。
长期存储与整理：Obsidian、Markdown、Git。日记、文章草稿、模板和候选选题以 Markdown 文件保存在 Obsidian 知识库中。目录按用途分区：模板和脚本放在管理区，日常主题笔记和文章草稿放在各自的内容区；Git 用于追踪知识库文件的变化。纯文本文件可以直接搜索、批量处理，也不依赖某个笔记软件才能读取。
每日复盘：Hermes 定时任务加 Python 脚本。每天约 23:40，复盘任务调用 daily-digest-collect.py 汇总邮件、Git、文件和浏览器等来源，再由 nmcp-daily-digest.py 通过 Nowledge Mem 本地 API 补充跨助手记录；运动记录和聊天摘要由各自的同步流程提供，最后写入 Obsidian 日记。我让 Codex 加入的“今日注意力评价”和“明日建议”，也会在这个任务里生成。前者根据去重后的记录归纳投入方向、评价产出，并说明依据与不确定性；后者最多三条，给出有事实依据的下一步行动。
选题整理：Hermes 定时任务加 Markdown 候选池。每天约 23:55，任务从近期记忆和思考记录中提炼公众号选题，追加到知识库的 gzh-topic-candidates.md。我在 Obsidian 中逐条处理，用“选中、稍后处理、忽略”等状态标记；选中的题目再扩展成文章。候选池和日记分开，避免选题混进每天的流水记录里。
写作与发布：Markdown、md2wechat 和人工终审。文章先以 Markdown 保存在知识库的固定草稿目录，文件名带日期和文章类型；需要转换时用 md2wechat 把 Markdown 转成公众号排版，再配图、预览并人工检查事实、表达和隐私。工具负责格式转换，定稿与发布决定由我把关。
用一条线概括就是：我安排 AI 助手处理日常任务 → Nowledge Mem 沉淀记忆，Python 脚本采集其他记录 → Hermes 定时复盘与选题提炼 → Obsidian 日记及 Markdown 候选页 → 我审阅、选题并安排写作 → Markdown 草稿、md2wechat 排版、人工终审；Git 负责知识库版本留痕。它们把“记下来、找得到、理得清、写得出”连成了日常流程。
整套东西并不神秘。它的核心不是某个高级模型，而是几条很朴素的原则：
平时留下记录；
定期把记录端出来；
用工具做粗活；
自己做判断；
最后把有价值的东西变成文章、文档或流程。
工具可以换，原则不要换。