素材来源

• 近一周对 create-flomo、daily-lesson、new-note 等技能反复打磨。
• 近一周关于技能治理、个人工作台和 832OS 的 flomo 与 notes。
• Codex、Grok、Fable 相互 review 和不断纠正的过程。

重点

• 个人技能要从真实使用里长出来。
  • 先写一个能跑的小版本。
  • 自己去用，感到烦，碰到问题，再删、再改。
• 多 Agent review 负责暴露盲区，不能替我决定规则。
  • 建议进入候选池。
  • 适合当下、适合我、能改善真实使用，才进入 SKILL.md。
• 技能只是个人工作台里的一个阀门。
  • 它负责减少上下文、降低输入摩擦、守住材料边界。
  • 它最终要把我送回代码、作品和行动。

这一周是怎么开始的

这一周围绕三个技能做了很多事情：create-flomo、daily-lesson、new-note。

开始时，我还是习惯把问题想完整。

• 一条个人记录，想同时照顾 Issue、flomo、长期 note 和后续发布。
• 一篇日课，想把当天所有过程都收进去，还想判断历史反复模式。
• 一篇长期 note，想处理材料池、文章类型、完成状态、写作风格和未来扩展。

每多想一种情况，skill 就多一条规则。规则多了以后，又需要兼容、fallback、检查和说明。最后得到的是一份看起来很严密的文档，实际使用却越来越重。

近一周 flomo 里有一句话，把这件事说得很直接：

这是我个人系统，不是完备产品。

后面的治理，基本都在把三个技能从“产品能力”拉回“个人动作”。

create-flomo：只做一件事

create-flomo 最早来自个人记录入口的迁移。

以前会先写 GitHub Issue，再同步到 flomo。这个做法看起来有结构，实际多了一个入口、一次格式转换和一层注意力消耗。

后来它被收成一句话：把当前上下文压成一条未来自己会再读的 flomo。

这句话是反复删除后留下来的。

• 删除 new-note fallback。
  • 我调用 create-flomo，就应该得到一条 flomo。
• 删除旧入口和兼容迁移的说明。
  • 已经废弃的路径不需要继续占据 Agent 的注意力。
• 删除各种“不要写到其它系统”的防御性废话。
  • 只保留真正改变动作的正向约束。
• 保留同一窗口更新同一条 memo。
  • 多个独立判断也可以放在一条里，不为了形式干净继续拆入口。

一次真实写入又发现，正文里的 #done 会被 flomo 识别成额外标签。这个问题靠预先设计很难想到，跑过一次就知道该怎么改。

• create-flomo 给我的第一条教训是：
  • 个人入口越小，越容易真的使用。
  • Agent 在这里负责还原上下文，不负责替我设计新的记录系统。

daily-lesson：把停手写进合同

日课一开始也背了太多东西。

它想读取当天过程、flomo、notes、历史日课和个人原则，还想识别连续模式。轻量复盘慢慢长成了一个小型分析系统。

反复打磨后，日课只留下两件事：今天真正围绕什么展开，今天最该提醒自己什么。

为了让这两件事可靠，材料边界也被钉死：

• memo_search 只负责找 ID。
• memo_batch_get 才负责读取完整正文。
• 当天已经生成的日课只用于查重和更新，不能反过来成为当天素材。
• 输出写入一条 flomo，写入成功就完成；后续修改继续更新同一条。

这些规则已经足够让它运行。我却还在继续补确认状态、历史兼容和边角情况。

最后我自己叫停了：

日课技能优化到此为止，真的优化了很久了，停滞不前了，后面真有问题，边跑边优化吧。

第二天实跑日课，留下来的提醒仍然是同一件事：别把个人系统做成完备产品，现在先跑起来。

是的，只是给自己用而已。又不是做一个大而全完美的产品，受众很多很多人。

daily-lesson 给我的第二条教训是：停手也是技能合同的一部分。能跑以后，只有真实问题值得继续治理。

new-note：AI 快，人要慢

new-note 要解决的问题更难。

长文不能只是一个提纲，也不能把整理材料、建立结构和讲清主线的工作继续留给我。Agent 应该交付一篇接近成稿的草稿。

但接近成稿很容易制造另一个错觉：文件已经存在，我就像已经读过、想过、相信了。

所以 new-note 最重要的设计是 @832@ing。

• AI 可以快速整理材料和判断链。
• 草稿可以先落盘。
• 我必须亲自读、改、删和判断。
• 只有经过这一步，它才可能真正进入我的长期系统。

这条边界后来继续展开成几件具体的事：

• 区分事实、我的明确判断、来源观点和 AI 推导。
• 博客、精读、教程、播客、复盘分别保留自己的写法。
• 共享层只处理材料、来源、安全和写入流程。
• 每篇 note 在开头简要说明它从什么经历和思考里长出来。

这里同样出现过过度治理。

• Grok 给过更完整的类型体系和长文分发方案。它们能启发思考，也会把 new-note 推成一个内容平台。
• Fable 式复审则发现了另一类问题：
  • 如果写入前检查失败后要求 Agent “继续补齐”，模型可能为了完成流程而编造材料。

一边是系统过大，一边是执行漏洞。最后留下来的版本没有追求完整，只保留现在确实会用到的边界。

new-note 给我的第三条教训是：

• AI 可以把东西推到六七十分，后面的判断、取舍和个人味道只能由我完成。
• 并且这个过程也是我自己冲刷自己神经元的一个过程。

其实就当下而言，这个技能打造其实还是不够完整。肯定还有很多边边角角的问题出现，但是就应该停到这了，而是每一次跑的时候发现一些问题，然后修改，一次又一次的，可能跑个半个月、一个月，就应该是近乎 90 分的技能了。 还是那句话，技能应该是慢慢长出来的，并且哪怕是 90 分了，后面还是会演化的。

多个 Agent 互相 review 的价值

这一周没有哪个模型单独给出正确答案。

• Codex 更适合回到当前仓库、Git 历史和真实运行边界。
• Grok 更容易提出完整结构，把可能性推到台面上。
• Fable 式复审更像 code review，会盯住材料缺口、虚构风险和流程矛盾。

这些建议经常互相冲突。

完整结构可能让个人技能变重。严格复审可能不断增加防御规则。实现者也可能只盯当前文件，忽略个人工作台更大的目的。

冲突本身有价值。它逼我回答一个问题：这条建议现在真的能改善我的使用吗？

这轮 new-note 治理时，我给过一句很重要的纠正：

别未来治理而治理，关键是合适的当下的，合适我个人的。

Agent 可以提出、反驳、复审和还原过程。最终规则必须经过我的判断。review 报告和治理建议只是候选，当前 SKILL.md 才是运行真源。

把技能放回个人工作台

近一周对 832OS 的诊断已经说得很清楚：当前的问题是反思和反馈产能很高，真正关闭的事情太少。

skill、note、图、prompt 都很容易获得完成感。832X 的真实验证、长文的真正吸收、一次运动、一次现金流实验，反馈更慢，也更容易暴露自己还没有掌握。

所以，技能在个人工作台里只能承担有限职责。

• create-flomo 降低记录摩擦，保留一条短判断。
• daily-lesson 把一天压成主线和提醒。
• new-note 把长材料整理成等待我吸收的草稿。
• whoami 和 principles 继续由我手动阅读和校正。

它们都要把我送回系统、代码外：作品、身体、家庭和现金流。

如果一个技能继续增加规则，却没有改善真实输入、阻止材料污染或帮助下一步行动，它就该停。

最后判断

这一周真正形成的技能治理方法很简单。

• 从零到一写一个能跑的小版本。
• 放进真实场景里使用。
• 只修真实暴露的问题。
• 用不同 Agent 扩大视角，让它们互相挑错。
• 把建议留在候选池，由我决定是否进入真源。
• 技能暂时够用时，立即停手。

真正让 skill 变好的，是自己读、自己用、自己觉得烦、自己删改。

个人系统的味道也从这里长出来。它不来自一次完整生成，也不来自多找一个模型投票。

比如这篇文章继续保留 @832@ing， 我现在认真读完了，所以我就可以来判断是否去掉 832 或者 ing 了

素材已经整理过，过程也已经讲清楚。

但它是否真的成立，还要等我自己读、想、改。文件落盘只是 Agent 完成了工作，还不代表这篇文章已经进入我。

最后，我是否真正内化了呢？我相信我没有，同样的事情我肯定还会再这么干。但和 832OS，一起，我相信我会逐渐地、渐进式地解决这些重复。