1. 总结

你不应该搭生产线，而应该生产！

2. AI 洞察

• 默认洞察
  • 核心矛盾不是不会搭系统，而是太会搭系统。
    • 一边搭工作流、命令、MCP、发布链，
    • 一边又不断提醒自己别折腾，回到真正的构建。
  • 深层驱动力是对失控和无意义的焦虑，所以会用系统、Issue、周报、诊断来换掌控感。
  • 最大风险是把 “管理工作的工程”当成工作本身。
  • 工具红线：
    • 既是在保护注意力，也是在缓解“怕错过新工具”的焦虑。
  • 你真正想做的，不只是某个工具项目，而是一套能保住创作主权、让 AI 读懂并增强自己的个人工作体系。
• 行动指南：接下来只做构建者。
  • 每天先定一个微构建物，一个文件、一段代码、一篇文章的核心段落、一个可演示结果。
  • 每天一个可行性最小原型
• 心底之问：
  • AI 能代劳越来越多事情后，我自己的价值和行动到底是什么
  • 很多具体疑问：还要不要自己读源码，为什么要亲自 build，工具流程会不会架空“我” ？
• 反直觉洞察
  • 什么是好工具？
    • 不抢注意力，不要求额外管理，直接托住思考和交付。
  • 输入带宽很重要：
    • 语音输入可以绕过打字和拼音摩擦，让想法更快进入 AI 协作链。
• 主要矛盾
  • 主矛盾是工具探索冲动和专注产出。
    • 工具探索带来虚假的推进感
    • 专注产出要求面对真正难的问题。
  • “每天一个可行性最小原型 ”
• 控制二分法
  • 完全可控的是
    • 判断、选择和行动：
      • 今天做什么、写什么、关哪个 Issue、推进哪个构建物。
  • 不可控的是
    • 工具更新、模型强弱、外部平台、市场机会、别人怎么看。
  • 可部分影响的是：
    • 输入方式、工作流、AI 协作、终端状态、浏览器能力、个人环境。
  • 痛苦来自把“可部分影响”误当成“必须完全掌控”。
  • 当又想研究新工具、对比模型、榨干账号额度时，先问：此刻我能控制的是什么。
    • 答案：通常不是再看一个工具，而是写下一行代码、完成一个 Issue、推进一个最小交付。

3. 事实

• 反复做减法：
  • 不折腾 Claude Desktop
  • 不让 Claude Code、OpenCode、OpenClaw、Trae、VS Code、Things
  • 各种 Markdown 工具继续占注意力
• 个人工作台和根级命令基本跑通
• 写作要求越来越清楚：
  • 写给自己看
  • 说人话
  • 极致压缩，不怕漏观点
  • 不把播客、资料、AI 输出原样搬成又长又完整的整理稿。
• 中旬之后
  • 主线不断收敛到 general-agent-lab
  • 先读 Codex CLI，先做 code agent，
    • 别一开始拉 opencode、DeepSeek、GLM、Cursor 自动化一起横评。
• 月底开始把“每天一个可行性最小原型”写成硬约束：
  • 不是计划，不是复盘，不是工具研究，还是当天就能运行的东西
• 语音输入被重新看见，输入侧带宽升级
  • 不是拼音问题的小修补，而是输入侧带宽升级。
  • flomo、Issue、草稿、工作沟通都可以吃到这个红利。
• 身体也冒出来提醒了：
  • 喝水少、饮食、睡眠、居住环境、累的时候怎么安排，这些不是旁枝，是能不能持续 build 的底层条件。

4. 产物

• ~/832 的边界更清楚了：
  • 根 workspace、os、flomo、liguwe.github.io、skills、tools、config、飞书、语雀、flomo MCP 各自该放什么，不该放什么。
• Issue 到 flomo 的副本链路变成月报素材来源，weekly 也改成默认用 flomo MCP，不再依赖本地导出备份。
• 写作和 note 的默认风格被压实：
  • 大白话、短句、少套话、保留自己的判断，删除“为了完整而完整”的材料。
• 一批高频判断被沉淀成 Issue：
  • 停止工具探索、先 build、Codex/Cursor 主线、Obsidian 够快就别换、Markdown 本身就是大纲笔记
  • 任何别人说的、写的，最终都要转成自己的话术
• general-agent-lab 被推到主战场位置，但真正硬产物还不够硬。
  • 更多是边界、方向、规则、Issue 和文章，还没有足够多可运行的小原型。
• 这篇月报本身也是一个产物：
  • 把 5 月的 flomo 和 AI 洞察压成一个可继续追问自己的诊断稿。

5. 诊断

• 看清“工具空转”不是偶发毛病，而是默认惯性。
• 你很擅长搭系统，所以也最容易用“再把系统搭好一点”逃避真正交付。
• 你一直在找更好的入口：
  • CLI、Zed、Cursor、Codex、Claude Code、Antigravity、Google One AI、语雀、飞书、flomo MCP。
  • 但真正的问题不是入口不够，而是每次入口变多，主线就变虚。
• Flomo AI 洞察 里说得很准：
  • 你不是缺方法论，是用工程化方法治疗过度工程化。
• 5 月后半段反复出现一句话：
  • 现在到底在 build 什么？
  • 这句话比任何工具选择都重要。答不上，就说明又在绕。
• 你把 GitHub Issue、flomo、Obsidian、AI 洞察接起来了，这是好事；
  • 但如果最后只生产更多“关于生产的记录”，那还是系统管理员，不是构建者。
• 真正的验收不是这个月写了多少判断，而是有多少判断变成了可运行、可关闭、可复用的东西。

6. 重复模式

• 先被一个工具或能力刺激，然后开始想：
  • 要不要换入口、配环境、买会员、接 MCP、做自动化。
• 发现自己又跑偏，于是写一条 Issue，把它收束成原则。
• 原则越写越清楚，但行动容易停在“原则已经说清楚了”。
  • 这句话好讽刺。
• 对外反馈、阅读量、热力图、commit 数、账号额度，会反复勾起虚荣和焦虑。
• 担心遗漏，所以想保留更多材料；后来又提醒自己大胆压缩。
• 想要高带宽输入，于是看见语音输入；
  • 但是一定要一定要警惕。
    • 如果输入之后没有 build，带宽越高，只是堆得越快。
• 想把一切都纳入 832 上下文，
  • 但真正需要的是上下文服务判断和行动
  • 而不是把 workspace 变成材料仓库

7. 启示

• 5 月不是“工具搭好了”的一个月，而是“再不 build 就说不过去”的一个月。
• 记住，主角是我，不是工具。
• 832 工作台已经够了，剩下的问题是把这套系统用到发烫。
• 写作也一样。
  • 不是多写，而是重读、删减、重组，直到只剩自己的判断。
• Issue 不是情绪垃圾桶
  • 能 build 的就 build，能关闭的就关闭，发现问题再 reopen。
• 用好豆包输入法语音输入。语音输入是重要能力，但它的目标不是多说，而是更快把想法推到可验收的产物。
• 健康、喝水、饮食、睡眠不是另一个管理项目，它们是持续工作最便宜的前置条件。
• 这个月留下的核心判断：别再证明系统合理了，开始证明系统有产出。

8. 问自己

• 每天是否有一个最小可运行原型。
• 写清楚了，不代表完成。
• 哪些 Issue 今天就可以关掉，哪些只是继续制造存在感？
• 如果 6 月只允许保留一个主线动作，它是什么？

9. 下一步

• 6 月只认一条主线：
  • general-agent-lab 里跑通一个最小 code agent CLI 闭环
• 工具探索只记录，不展开；
  • 除非它直接服务当天构建物。
• 每周关一批 Issue：
  • 能关就关，不能关就写清下一步。
• 写作继续极致压缩：
  • 每篇只留自己的判断、必要证据和下一步。
• 用语音输入提高记录速度，但记录后必须落到 Issue、note、代码或关闭动作。
• 喝水和吃饭定最低线：
  • 每天喝够水，在家吃饭别放纵；
  • 身体管不住，主线也会散。