即刻App年轻人的同好社区
下载
置顶Yibie 的自我策展
我整理之前发过的帖子，这些是值得推荐一看的。也顺道向你暴露我的世界观、性格、兴趣和观点，有机会的话交个朋友😊
✨ AI 与新世界
得到 Prompt 系列（共 18 个） ⭐️已被“提示词图书馆收录”
m.okjike.com
Promopt: 文章精炼大师
web.okjike.com
Promopt: 概念卡片制作专家
web.okjike.com
Promopt: PPT 大纲制作助手 ⭐获得即刻精选推荐
web.okjike.com
Promopt: Kiweb. 文章精华浓缩专家
web.okjike.com
开发 12 Weeks LifeRPG 背后的过程与思考
web.okjike.com
用 AI 帮忙总结笔记（测试了 ChatGPT、Gemini、Kiweb.、豆包）
web.okjike.com
微软 CTO Kevin Scott 接受 every 访谈
web.okjike.com
吴恩达总结 AI 工程师制作 Promopt 的经验
web.okjike.com
OpenAI 2024 年春季发布会源文件， 包括演讲稿和演示用代码
web.okjike.com
视频内容识别是 Gemini Pro 1.5 的杀手锏
web.okjike.com
Perplexity 的官方 Promopt
web.okjike.com
大模型公司对 Token 的计算方法都不一样
web.okjike.com
AI 与创作者经济
web.okjike.com
------------------------------------
🤔我对这个世界有点看法
every 长文: AI 将冲击广告业, 后果很严重
web.okjike.com
Vision Pro 之我见
web.okjike.com
社会生活的趋同让人恐惧
web.okjike.com
「探索式」笔记法 ⭐获得即刻精选推荐
web.okjike.com
子弹日记法
web.okjike.com
商业价值的 3 个重要特征
web.okjike.com
Arc 这家公司的特点
web.okjike.com
新产品形态: Jina AI 将 URL 变为 API
web.okjike.com
------------------------------------
📒囤了一些清单
值得推荐的豆瓣小组
web.okjike.com
包豪斯设计的精华链接
web.okjike.com
Design Engineer 的 Twitter List
web.okjike.com
------------------------------------
📖️那些值得推荐的好书
读完斯多葛主义代表人物塞涅卡的书信集 <短暂的生命>
web.okjike.com
程序员超强大脑笔记
web.okjike.com
读完<巨人的工具>
web.okjike.com
读完<为什么伟大不能被计划>
web.okjike.com
精要主义读书笔记
web.okjike.com
读《了不起的盖茨比》
web.okjike.com
------------------------------------
💭️脑海里闪过的一句话
天才税
web.okjike.com
高度抽象的现代生活损害人类天生的类比能力
web.okjike.com
你能列出充分反映时代精神的 3 家公司吗？
web.okjike.com
解决拖延症的办法是找出之前最想完成但一直没做的事
web.okjike.com
美 = 深刻的简洁
web.okjike.com
尊重常识 = 不犯基本错误
web.okjike.com
与其花 1 小时如昙花一现, 不如花 10 倍时间震惊四座
web.okjike.com
这个世界有种人，以好人为食。
web.okjike.com
最难沟通的，是被灌输了标准答案的人
web.okjike.com
拖延 = 甩锅给未来的自己
web.okjike.com
折腾的定义
web.okjike.com
------------------------------------
🛠喜欢折腾工具
开启 Mac 系统自带白噪音音乐的方法
web.okjike.com
20-20-20 护眼原则
web.okjike.com
用哔哩哔哩替代网易云音乐
web.okjike.com
中国著名羽毛球运动员郑思维学习英语的工具和方法
web.okjike.com
------------------------------------
📁未归类的答案
「参考答案」的策展原则
web.okjike.com
我整理之前发过的帖子，这些是值得推荐一看的。也顺道向你暴露我的世界观、性格、兴趣和观点，有机会的话交个朋友😊
✨ AI 与新世界
得到 Prompt 系列（共 18 个） ⭐️已被“提示词图书馆收录”
m.okjike.com
Promopt: 文章精炼大师
web.okjike.com
Promopt: 概念卡片制作专家
web.okjike.com
Promopt: PPT 大纲制作助手 ⭐获得即刻精选推荐
web.okjike.com
Promopt: Kiweb. 文章精华浓缩专家
web.okjike.com
开发 12 Weeks LifeRPG 背后的过程与思考
web.okjike.com
用 AI 帮忙总结笔记（测试了 ChatGPT、Gemini、Kiweb.、豆包）
web.okjike.com
微软 CTO Kevin Scott 接受 every 访谈
web.okjike.com
吴恩达总结 AI 工程师制作 Promopt 的经验
web.okjike.com
OpenAI 2024 年春季发布会源文件， 包括演讲稿和演示用代码
web.okjike.com
视频内容识别是 Gemini Pro 1.5 的杀手锏
web.okjike.com
Perplexity 的官方 Promopt
web.okjike.com
大模型公司对 Token 的计算方法都不一样
web.okjike.com
AI 与创作者经济
web.okjike.com
------------------------------------
🤔我对这个世界有点看法
every 长文: AI 将冲击广告业, 后果很严重
web.okjike.com
Vision Pro 之我见
web.okjike.com
社会生活的趋同让人恐惧
web.okjike.com
「探索式」笔记法 ⭐获得即刻精选推荐
web.okjike.com
子弹日记法
web.okjike.com
商业价值的 3 个重要特征
web.okjike.com
Arc 这家公司的特点
web.okjike.com
新产品形态: Jina AI 将 URL 变为 API
web.okjike.com
------------------------------------
📒囤了一些清单
值得推荐的豆瓣小组
web.okjike.com
包豪斯设计的精华链接
web.okjike.com
Design Engineer 的 Twitter List
web.okjike.com
------------------------------------
📖️那些值得推荐的好书
读完斯多葛主义代表人物塞涅卡的书信集 <短暂的生命>
web.okjike.com
程序员超强大脑笔记
web.okjike.com
读完<巨人的工具>
web.okjike.com
读完<为什么伟大不能被计划>
web.okjike.com
精要主义读书笔记
web.okjike.com
读《了不起的盖茨比》
web.okjike.com
------------------------------------
💭️脑海里闪过的一句话
天才税
web.okjike.com
高度抽象的现代生活损害人类天生的类比能力
web.okjike.com
你能列出充分反映时代精神的 3 家公司吗？
web.okjike.com
解决拖延症的办法是找出之前最想完成但一直没做的事
web.okjike.com
美 = 深刻的简洁
web.okjike.com
尊重常识 = 不犯基本错误
web.okjike.com
与其花 1 小时如昙花一现, 不如花 10 倍时间震惊四座
web.okjike.com
这个世界有种人，以好人为食。
web.okjike.com
最难沟通的，是被灌输了标准答案的人
web.okjike.com
拖延 = 甩锅给未来的自己
web.okjike.com
折腾的定义
web.okjike.com
------------------------------------
🛠喜欢折腾工具
开启 Mac 系统自带白噪音音乐的方法
web.okjike.com
20-20-20 护眼原则
web.okjike.com
用哔哩哔哩替代网易云音乐
web.okjike.com
中国著名羽毛球运动员郑思维学习英语的工具和方法
web.okjike.com
------------------------------------
📁未归类的答案
「参考答案」的策展原则
web.okjike.com
56 1621
最近 Codex 爆出会狂刷日志，加速 SSD 硬盘的疲劳。然后我发现 Codex 还有一个坑，就是即便关闭了界面，后台进程还在，不关。
这两个连环拳下来，就相当于，如果不完全退出 Codex 进程，它就会不断刷爆你的 SSD 硬盘。
所以，提醒大家一句，除了关闭 Codex 写入日志的功能外，在 CLI 退出 Codex 时，还要执行 /exit，这样才能真正退出 Codex 进程，确保万无一失。
这两个连环拳下来，就相当于，如果不完全退出 Codex 进程，它就会不断刷爆你的 SSD 硬盘。
所以，提醒大家一句，除了关闭 Codex 写入日志的功能外，在 CLI 退出 Codex 时，还要执行 /exit，这样才能真正退出 Codex 进程，确保万无一失。
4 40
推荐这篇文章，作者完整展示了怎么用 LLM 做一个真正好用的个人工具，重要的是，他展示了如何让 LLM 取代那些你之前觉得不好用的产品，服务，非常值得参考。
作者分享了自己的真实经验，用了个月、迭代了多个版本的产品。作者遇到的每一个坑（模型选错、prompt 架构设计、延迟优化）都是实战教训。如果你也想用 LLM 改造自己的工作流，这篇是最佳案例。
---
我取消了 $200/月的法语家教，自己写了个 LLM 替代品，效果更好
几个月前，我还在用传统方式学法语——每周一次 45 分钟私教课，每月 $200。导师学术背景扎实，教学有方。但几个月下来，我发现讲了很多话题，记住的却不多。
每节课前 20 分钟在对话，然后花大量时间回顾已经讲过的内容。新语法点进展很慢，我越来越不耐烦。
我读过足够多关于遗忘曲线的文章，也知道 LLM 工具摆弄了挺久。所以开始想：能不能自己做一个——更好，更便宜？
问题不是教学质量。是两个结构性问题。
第一，复习节奏。人类导师按日历来排课。我需要的算法应该按遗忘曲线来排——在刚要遗忘之前正好复习，而不是在随机时间迟来的回顾。这叫间隔重复，背后有 40 年的记忆研究。Anki 这类 APP 已经证明了它有效。问题是怎么把它应用到比闪卡更细腻的东西上。
第二，错误追踪。我的导师大概记得我哪里弱，会在合适的时候测试我。但一个类型为"Alex 在虚拟语气上挣扎"的数据点不够用。我需要的是："Alex 在否定句中持续用 avoir 做 aller 的 passé composé 助动词。"这才够精确，解决起来才快。
我还琢磨：真的要花钱就为了对话前 20 分钟，而且一周只能聊一次？我能不能随时练口语，免费或者几乎免费？
所有这些，感觉都是可以解决的软件问题。
架构：两个关键组件
一个知识库导师，一个语音练习应用，互相配合。
知识库导师是一个基于 Claude 的文本工作流。它维护一个 JSON 文件，追踪我学过的每一个语法点——上一次什么时候复习、当时信心如何、具体哪里错了、什么时候又该复习了。每次 session 前，它读这个文件，找出该复习的内容，生成难度递增的练习题：先选择，再填空，再翻译，最后自由输出。session 结束后，所有数据写回文件。
底层算法是 SM-2——Anki 用的同一个。每次练完一个 topic，我给自己打分 1 到 4。分数调整两个参数：这个 topic 对我来说的自然掌握程度，和下次复习的时间间隔。连续四次满分，三周后见。彻底忘了，明天见。久而久之，它构建出一个按 topic 划分的、针对我个人的遗忘曲线模型。
弱点追踪是真正有用的地方。不记录"Alex 在 passé composé 上挣扎"，而是记录"否定句中运动动词用错助动词——自 2026-04-12 起"。下次这个 topic 被复习时，练习就围绕这个具体结构来出——不是泛泛的 passé composé 练习，而是精确炸那个曾经过不去的点。
语音导师叫 Causons，是一个浏览器应用。点一下麦克风，说，听到同一个语言的回复。启动时它读取同一个知识库文件，把对话引导向该复习的 topic 和已知的薄弱点。它还会在对话流中纠正语法错误——但只纠正那些客观上就是错的、母语者绝对不会说的东西。转录错误、标点、语域选择、口语缩略——默认忽略。
两个组件分工明确。知识库导师建立知识。Causons 在对话场景中激活它。你可以理论上掌握反身代词的规则，然后在真要说出口的时候完全卡住。语音应用的作用就是打破这个壁垒。
语音管线是三次 API 调用串联：
语音转文字走 Groq，跑 Whisper-large-v3。Azure 认知服务有免费层，看起来是低成本首选。没用多久就推送到付费层——不是因为用量超标，就是开始用免费层了。体验很差。换到 Groq，同一个模型，硬件更快（200-500ms vs OpenAI 的 800-1500ms），价格约 $0.002/分钟。
对话走 gpt-4o-mini。这块费了挺长时间。最初用 Groq 的 Llama 3.3 70B，因为更便宜、能力不差。日常规范法语还行，但碰到完全正常的口语表达会自信地解释为什么它错了——实际没错。花了很长时间 prompt engineering，最后结论是问题不在 prompt，在前端模型对口语化法语语法的底层知识不行。切到 gpt-4o-mini 解决了。每 session 成本差异可以忽略。
文本转语音走 OpenAI tts-1，和 gpt-4o-mini 共用一把 key。Nova 和 Onyx 音色自动适配语言，无需配置。ElevenLabs 音质更好，但第三家 provider 和 $5/月起步价不值得。
总结：一次 15 分钟的 session，三道 API 总共约 4 美分。
Prompt 架构的设计思路也很有启发。
语言导师的 prompt 里有两种性质完全不同的内容。教学策略——什么时候该纠正、怎么措辞、什么语域——对每个用户基本稳定，应该跨 session 保持不变。上下文数据——今天练哪个语言、哪些 topic 该复习了、最近错了哪些东西——每次都在变，应该每次都从源重建。
第一版把两者混在一起，一个星期后 prompt 里塞着过期的 topic 列表。修复方法是把它们当两类数据来对待：稳定的教学策略存在 IndexedDB 里直接用，数据驱动的部分从真实的源（语言下拉框、知识库文件、今天日期）每次重建。还有一个组装顺序：稳定的放前面（LLM provider 可以缓存 prefix），会变的部分放后面。
还有一个明确的原则：假纠正比漏纠正更糟。 如果导师把正确的东西标错，你知道的情况下会惹恼你，你不知道的情况下是学习损害。
延迟优化方面：从 2-6 秒砍到 0.8-2.5 秒。靠的是 MediaSource Extensions——不等整个 MP3 下载完，边接收边播。再加上不等完整句子，看到 25 个字符以上就发第一段 TTS 请求。
最后：安保可以不用管。在个人设备上本地存储 key 是 fine 的，有 PIN-based 加密的草图但优先级不高。
回头看两个教训。在错误的模型上待太久了。 一旦 Llama 开始幻觉语法纠正，我应该马上切。Prompt 里不要把稳定策略和变化数据混在一起——分开处理。
两个组件都在 GitHub 上。知识库导师用 Claude 项目管理起来就行。Causons 一行 npm install，一行 deploy 到 Cloudflare Pages。
原文：Alex She, "I Canceled My French Tutor and Built an LLM Tool That Does It Better", 2026-06-21
alshe.substack.com
作者分享了自己的真实经验，用了个月、迭代了多个版本的产品。作者遇到的每一个坑（模型选错、prompt 架构设计、延迟优化）都是实战教训。如果你也想用 LLM 改造自己的工作流，这篇是最佳案例。
---
我取消了 $200/月的法语家教，自己写了个 LLM 替代品，效果更好
几个月前，我还在用传统方式学法语——每周一次 45 分钟私教课，每月 $200。导师学术背景扎实，教学有方。但几个月下来，我发现讲了很多话题，记住的却不多。
每节课前 20 分钟在对话，然后花大量时间回顾已经讲过的内容。新语法点进展很慢，我越来越不耐烦。
我读过足够多关于遗忘曲线的文章，也知道 LLM 工具摆弄了挺久。所以开始想：能不能自己做一个——更好，更便宜？
问题不是教学质量。是两个结构性问题。
第一，复习节奏。人类导师按日历来排课。我需要的算法应该按遗忘曲线来排——在刚要遗忘之前正好复习，而不是在随机时间迟来的回顾。这叫间隔重复，背后有 40 年的记忆研究。Anki 这类 APP 已经证明了它有效。问题是怎么把它应用到比闪卡更细腻的东西上。
第二，错误追踪。我的导师大概记得我哪里弱，会在合适的时候测试我。但一个类型为"Alex 在虚拟语气上挣扎"的数据点不够用。我需要的是："Alex 在否定句中持续用 avoir 做 aller 的 passé composé 助动词。"这才够精确，解决起来才快。
我还琢磨：真的要花钱就为了对话前 20 分钟，而且一周只能聊一次？我能不能随时练口语，免费或者几乎免费？
所有这些，感觉都是可以解决的软件问题。
架构：两个关键组件
一个知识库导师，一个语音练习应用，互相配合。
知识库导师是一个基于 Claude 的文本工作流。它维护一个 JSON 文件，追踪我学过的每一个语法点——上一次什么时候复习、当时信心如何、具体哪里错了、什么时候又该复习了。每次 session 前，它读这个文件，找出该复习的内容，生成难度递增的练习题：先选择，再填空，再翻译，最后自由输出。session 结束后，所有数据写回文件。
底层算法是 SM-2——Anki 用的同一个。每次练完一个 topic，我给自己打分 1 到 4。分数调整两个参数：这个 topic 对我来说的自然掌握程度，和下次复习的时间间隔。连续四次满分，三周后见。彻底忘了，明天见。久而久之，它构建出一个按 topic 划分的、针对我个人的遗忘曲线模型。
弱点追踪是真正有用的地方。不记录"Alex 在 passé composé 上挣扎"，而是记录"否定句中运动动词用错助动词——自 2026-04-12 起"。下次这个 topic 被复习时，练习就围绕这个具体结构来出——不是泛泛的 passé composé 练习，而是精确炸那个曾经过不去的点。
语音导师叫 Causons，是一个浏览器应用。点一下麦克风，说，听到同一个语言的回复。启动时它读取同一个知识库文件，把对话引导向该复习的 topic 和已知的薄弱点。它还会在对话流中纠正语法错误——但只纠正那些客观上就是错的、母语者绝对不会说的东西。转录错误、标点、语域选择、口语缩略——默认忽略。
两个组件分工明确。知识库导师建立知识。Causons 在对话场景中激活它。你可以理论上掌握反身代词的规则，然后在真要说出口的时候完全卡住。语音应用的作用就是打破这个壁垒。
语音管线是三次 API 调用串联：
语音转文字走 Groq，跑 Whisper-large-v3。Azure 认知服务有免费层，看起来是低成本首选。没用多久就推送到付费层——不是因为用量超标，就是开始用免费层了。体验很差。换到 Groq，同一个模型，硬件更快（200-500ms vs OpenAI 的 800-1500ms），价格约 $0.002/分钟。
对话走 gpt-4o-mini。这块费了挺长时间。最初用 Groq 的 Llama 3.3 70B，因为更便宜、能力不差。日常规范法语还行，但碰到完全正常的口语表达会自信地解释为什么它错了——实际没错。花了很长时间 prompt engineering，最后结论是问题不在 prompt，在前端模型对口语化法语语法的底层知识不行。切到 gpt-4o-mini 解决了。每 session 成本差异可以忽略。
文本转语音走 OpenAI tts-1，和 gpt-4o-mini 共用一把 key。Nova 和 Onyx 音色自动适配语言，无需配置。ElevenLabs 音质更好，但第三家 provider 和 $5/月起步价不值得。
总结：一次 15 分钟的 session，三道 API 总共约 4 美分。
Prompt 架构的设计思路也很有启发。
语言导师的 prompt 里有两种性质完全不同的内容。教学策略——什么时候该纠正、怎么措辞、什么语域——对每个用户基本稳定，应该跨 session 保持不变。上下文数据——今天练哪个语言、哪些 topic 该复习了、最近错了哪些东西——每次都在变，应该每次都从源重建。
第一版把两者混在一起，一个星期后 prompt 里塞着过期的 topic 列表。修复方法是把它们当两类数据来对待：稳定的教学策略存在 IndexedDB 里直接用，数据驱动的部分从真实的源（语言下拉框、知识库文件、今天日期）每次重建。还有一个组装顺序：稳定的放前面（LLM provider 可以缓存 prefix），会变的部分放后面。
还有一个明确的原则：假纠正比漏纠正更糟。 如果导师把正确的东西标错，你知道的情况下会惹恼你，你不知道的情况下是学习损害。
延迟优化方面：从 2-6 秒砍到 0.8-2.5 秒。靠的是 MediaSource Extensions——不等整个 MP3 下载完，边接收边播。再加上不等完整句子，看到 25 个字符以上就发第一段 TTS 请求。
最后：安保可以不用管。在个人设备上本地存储 key 是 fine 的，有 PIN-based 加密的草图但优先级不高。
回头看两个教训。在错误的模型上待太久了。 一旦 Llama 开始幻觉语法纠正，我应该马上切。Prompt 里不要把稳定策略和变化数据混在一起——分开处理。
两个组件都在 GitHub 上。知识库导师用 Claude 项目管理起来就行。Causons 一行 npm install，一行 deploy 到 Cloudflare Pages。
原文：Alex She, "I Canceled My French Tutor and Built an LLM Tool That Does It Better", 2026-06-21
alshe.substack.com
21 014
oh-my-openagent 编程 Skills 深度分析
oh-my-openagent 的编程 skills 不是提示词模板，是可执行的工程纪律契约。每条 skill 是一个状态机：定义触发条件、强制前置阅读、分阶段执行、自检环。
核心 skills 共有六条：
1. programming 负责跨语言编码纪律（覆盖 Go、Python、Rust、TypeScript）
2. refactor 实现 6 阶段安全重构协议
3. debugging 提供假设驱动的调试循环
4. git-master 管工作流
5. review-work 管代码审查
6. start-work 做计划编排。
一、programming — 跨语言编码纪律
设计哲学：6 条公理
所有语言规则都从这 6 条公理推导出来。
第一条：类型系统是你的证明系统。 让非法状态不可表示。编译器是你跑过的最便宜的测试。
第二条：解析，不验证。 不可信输入在边界恰好被解析为类型化值一次；边界之内接收类型化值，永不重复验证。
第三条：一个名字就是一个概念。 UserId 不是 string，Seconds 不是 Milliseconds。每个语义原语用 newtype 包装。
第四条：穷举变体匹配，始终。 禁止用 if/elif/else 区分 tagged variant，只用 match 加 assert_never。
第五条：信任框架保证，只在边界验证。 不对类型系统已经证明的值做空检查、不对不会抛异常的代码做 try/except。
第六条：测试驱动，用正确形状的测试。 Red → Green → Refactor，Given/When/Then 结构。
跨语言铁律
这 6 条公理落到四个语言上，各有不同的实现方式。
默认不可变。 Python 用 frozen=True, slots=True 的数据类。Rust 默认 let 而非 let mut。TypeScript 用 readonly。Go 不导出字段。四个语言，同一个原则。
尊重原语。 Python 用 NewType("UserId", int)，Rust 用 struct UserId(u64)，TypeScript 用 branded type，Go 用 type UserID string。核心思想一样：不让原始类型裸奔。
穷举匹配。 Python 用 match 加 assert_never，Rust 的 match 编译器强制穷举，TypeScript 用 switch 加 assertNever，Go 用 sealed interface 加 exhaustive linter。每个语言都有自己的穷举检查手段，不用 if/else 凑合。
错误处理。 Python 用带类型的 exception dataclass，Rust 用 thiserror enum，TypeScript 用 Error 子类，Go 用 errors.New 加带类型 struct 再加 %w 包装。没有裸字符串错误。
边界捕获。 Python 只捕获预期的异常，Rust 的 ? 无处不在但只传播声明过的错误类型，TypeScript 的 catch 必须窄化再重抛，Go 每个 (T, error) 返回值都要检查。
资源管理（RAII）。 Python 用 with 和 async with，Rust 用 Drop trait，TypeScript 用 using 和 await using，Go 用经典的 defer x.Close()。
2026 年技术栈（逐语言）
Python： uv 管包，basedpyright 做全量类型检查，ruff 同时做 lint 和格式化，pytest 跑测试，FastAPI 做 web，SQLAlchemy 2.x async 管数据库，typer 加 rich 做 CLI，structlog 记日志，pydantic-ai 对接 LLM 和 Agent。
Rust： cargo 管包，rustc 加 clippy pedantic 做类型和 lint，rustfmt 格式化，cargo-nextest 跑测试，axum 做 web，sqlx 管数据库，clap 做 CLI，tracing 记日志。LLM 调用通过 subprocess 桥接到 Python。
TypeScript： Bun 做包管理兼运行时，tsc --noEmit 在 strict 模式做类型检查，Biome 替代 ESLint 和 Prettier，bun test 或 vitest 跑测试，Hono 做 web，Drizzle 做 ORM，@clack/prompts 做 CLI 交互，pino 记日志，Vercel AI SDK 对接 LLM。
Go： go modules 管包，golangci-lint v2 加 nilaway 做类型和 lint，gofumpt 格式化，go test -race -shuffle=on 跑测试，gin 或 chi 做 web，sqlc 加 pgx 做数据库（不是 GORM），cobra 做 CLI，log/slog 记日志，net/http 直接调用 LLM API。
代码坏味道（自动触发审查）
文件超过 250 行纯逻辑代码就是缺陷，必须拆分。
函数超过 3 个参数就是坏味，应该分组为类型化值对象。
破坏操作后的冗余验证（写完之后马上读回来检查）是 AI 生成代码的典型防御性膨胀，直接删掉。
否定形式命名（isNotValid、noErrors）重命名为肯定形式。
强制写后审查环
每次写完代码后，Agent 必须自问 10 个问题：
文件有单一职责吗，能用一句话命名吗；边界纯净吗，不可信输入在边界被解析了吗；变体区分用了穷举匹配而非 if/else 吗；有没有 Any、unwrap、@ts-ignore 这样的逃脱舱口；有没有对类型已证明值做多余的防御性空检查；有没有只被调用一次的一次性 helper 函数；新行为被测试锁定吗；参数超过 3 个吗；破坏操作后有多余的重新查询验证吗；有没有否定命名的东西。
二、refactor — 6 阶段安全重构协议
重构不是"打开文件，开始改"。oh-my-openagent 把它做成了一个 6 阶段的状态机。
Phase 0 是意图门：先解析请求类型，验证自己是否真正理解了要做什么。很多 AI 重构失败在这一步——它没确认就动手了。
Phase 1 是代码库分析：并行启动 5 个 explore agent，加上 LSP 做精确定义查找和引用分析，加上 ast-grep 做结构化模式匹配。三路并进。
Phase 2 构建代码地图：生成依赖图、标记影响区域、评估每步的风险等级。
Phase 3 评估测试覆盖：如果覆盖率不够，拒绝激进重构。
Phase 4 生成计划：Plan agent 把重构分解为多个原子步骤，每一步都可以独立验证。
Phase 5 执行重构：每一步的模式是 LSP 安全重命名 → 运行 lsp_diagnostics 验证 → 提交 git checkpoint。一步一个 checkpoint，出问题立即回滚。
Phase 6 最终验证：跑全量测试套件、类型检查、lint、构建。四项全绿才算通过。
核心原则就五个：理解再修改（先 LSP 再动手）、预览再执行（ast-grep 先 dry-run 再 apply）、每步验证、失败即停、覆盖不足就阻塞。
五个工具各司其职：LSP 负责精确定义查找和引用分析，ast-grep 做结构化模式匹配和批量替换，explore agent 做并行的代码库模式发现，Plan agent 生成详细的重构步骤，Oracle agent 应付复杂的架构决策。
当重构步骤中独立文件操作超过 3 个时，自动启用 team mode。一个 Lead（叫 Sisyphus）纯编排不写代码。两个 quick worker 做机械编辑（LSP 重命名、提取变量）。两个 unspecified-low worker 做逻辑重构（提取函数、模式转换）。外面还有一个独立的 verifier 负责验证，不参与重构本身。
三、debugging — 假设驱动的调试循环
调试 skill 有两条核心纪律。第一，运行时真相胜过代码阅读——每个关于 bug 原因的声明，必须来自观察到的状态，不能是从看代码编出来的可信故事。第二，不留痕迹——所有调试产物都记录到 .debug-journal.md 日志，完成后全部清除。
具体执行分 10 个阶段。
Phase 0 做环境评估——搞清楚运行时类型、端口、符号表、环境变量。
Phase 1 建日志文件追踪所有产物。
Phase 2 是关键：形成至少 3 个假设，必须跨正交轴（不是同一维度的 3 个变体），每个假设要有区分性证据。
Phase 3 并行调查，可以用 team mode 的 debug-squad 或者异步子代理。
Phase 4 是 Oracle Triple：连续两轮调查失败后，从正交角度生成 3 个 Oracle 提示。
Phase 5 只在证据耗尽且有政策影响时才升级给用户决策。
Phase 6 根因确认规则很严格：只有当切换疑似原因能切换 bug 时才算确认。
Phase 7 开始 TDD 修复——先写失败的 red test，最小 green 修复，不扩展范围。
Phase 8 手动 QA，实际使用系统——tmux、Playwright、curl，不是只跑测试。
Phase 9 清理，按日志回滚所有产物，验证 git diff 只有修复和测试。
Phase 10 过 4 个证据门做最终验证。
调试 skill 还有一个独特的设计：
每个运行时都有必读的参考文件，不读就不能动手，因为这个运行时的调试工具和行为和其他运行时不同。
Python 的 pdb、ipdb、debugpy、pytest --pdb 语义各自不同。Node.js 的 tsx 加 node inspect 有静默 source-map 失败。
Rust 的 Release 构建剥离了调试符号，tokio 任务需要 tokio-console 才能看到。Go 的 goroutine 泄漏和 recover panic 默认静默。macOS 原生二进制的 SIP、Mach-O、lldb 行为与 Linux 完全不同。甚至打包应用二进制（看起来像 Mach-O 或 ELF 但实际是 JS）需要完全不同的调试策略。
四、skill 设计的通用模式
从这三条 skill 里能提炼出 oh-my-openagent 设计 philosophy 的六个通用模式。
第一，强制前置阅读。 每条 skill 开头都是"读这个参考文件。不读就别动手。"这不是建议，是硬性门控。Phase 0 的 LANGUAGE GATE 用全大写写死了："DO NOT WRITE OR EDIT A SINGLE LINE OF CODE BEFORE COMPLETING THIS GATE."这不是给人类的，是给 AI Agent 的约束。
第二，引用外部化。 SKILL.md 本身是精简的索引，90% 的知识存在 references/ 子目录里。触发 skill 时只加载 SKILL.md（体积小），按需加载 references（按语言、按场景）。这是渐进式披露在 skill 层的应用。
第三，状态机阶段。 每条 skill 都是明确编号的阶段序列，每个阶段有四个要素：进入条件、工具或代理调用指令、完成标记、失败处理路径。不是段落散文，是状态机。
第四，自我审查环。 执行完不算完——必须通过自检环。programming 有 10 个问题，debugging 有 4 个证据门，refactor 每一步都要验证。这是 AI 写代码最容易跳过的步骤，oh-my-openagent 把它写死了。
第五，代理组合。 skill 不是让单个 agent 执行，而是编排多个 agent 协作。explore agent 做人肉搜索，plan agent 生成详细计划，oracle agent 应付困难决策，后台 agent 做并行探索，team mode 协调多 agent 协作重构。skill 是 conductor，不是 executor。
第六，技术栈锁定。 不泛泛说"用好的实践"——每个语言在 2026 年的正确工具链是写死的：uv 而非 pip，Biome 而非 ESLint 加 Prettier，sqlc 而非 GORM。这是可执行的判断，不是可讨论的风格。当工具链被锁定，AI 就没有选择余地，也就不会在选工具上浪费时间或选错。
来源：oh-my-openagent packages/shared-skills/skills/, 2026-06-18
oh-my-openagent 的编程 skills 不是提示词模板，是可执行的工程纪律契约。每条 skill 是一个状态机：定义触发条件、强制前置阅读、分阶段执行、自检环。
核心 skills 共有六条：
1. programming 负责跨语言编码纪律（覆盖 Go、Python、Rust、TypeScript）
2. refactor 实现 6 阶段安全重构协议
3. debugging 提供假设驱动的调试循环
4. git-master 管工作流
5. review-work 管代码审查
6. start-work 做计划编排。
一、programming — 跨语言编码纪律
设计哲学：6 条公理
所有语言规则都从这 6 条公理推导出来。
第一条：类型系统是你的证明系统。 让非法状态不可表示。编译器是你跑过的最便宜的测试。
第二条：解析，不验证。 不可信输入在边界恰好被解析为类型化值一次；边界之内接收类型化值，永不重复验证。
第三条：一个名字就是一个概念。 UserId 不是 string，Seconds 不是 Milliseconds。每个语义原语用 newtype 包装。
第四条：穷举变体匹配，始终。 禁止用 if/elif/else 区分 tagged variant，只用 match 加 assert_never。
第五条：信任框架保证，只在边界验证。 不对类型系统已经证明的值做空检查、不对不会抛异常的代码做 try/except。
第六条：测试驱动，用正确形状的测试。 Red → Green → Refactor，Given/When/Then 结构。
跨语言铁律
这 6 条公理落到四个语言上，各有不同的实现方式。
默认不可变。 Python 用 frozen=True, slots=True 的数据类。Rust 默认 let 而非 let mut。TypeScript 用 readonly。Go 不导出字段。四个语言，同一个原则。
尊重原语。 Python 用 NewType("UserId", int)，Rust 用 struct UserId(u64)，TypeScript 用 branded type，Go 用 type UserID string。核心思想一样：不让原始类型裸奔。
穷举匹配。 Python 用 match 加 assert_never，Rust 的 match 编译器强制穷举，TypeScript 用 switch 加 assertNever，Go 用 sealed interface 加 exhaustive linter。每个语言都有自己的穷举检查手段，不用 if/else 凑合。
错误处理。 Python 用带类型的 exception dataclass，Rust 用 thiserror enum，TypeScript 用 Error 子类，Go 用 errors.New 加带类型 struct 再加 %w 包装。没有裸字符串错误。
边界捕获。 Python 只捕获预期的异常，Rust 的 ? 无处不在但只传播声明过的错误类型，TypeScript 的 catch 必须窄化再重抛，Go 每个 (T, error) 返回值都要检查。
资源管理（RAII）。 Python 用 with 和 async with，Rust 用 Drop trait，TypeScript 用 using 和 await using，Go 用经典的 defer x.Close()。
2026 年技术栈（逐语言）
Python： uv 管包，basedpyright 做全量类型检查，ruff 同时做 lint 和格式化，pytest 跑测试，FastAPI 做 web，SQLAlchemy 2.x async 管数据库，typer 加 rich 做 CLI，structlog 记日志，pydantic-ai 对接 LLM 和 Agent。
Rust： cargo 管包，rustc 加 clippy pedantic 做类型和 lint，rustfmt 格式化，cargo-nextest 跑测试，axum 做 web，sqlx 管数据库，clap 做 CLI，tracing 记日志。LLM 调用通过 subprocess 桥接到 Python。
TypeScript： Bun 做包管理兼运行时，tsc --noEmit 在 strict 模式做类型检查，Biome 替代 ESLint 和 Prettier，bun test 或 vitest 跑测试，Hono 做 web，Drizzle 做 ORM，@clack/prompts 做 CLI 交互，pino 记日志，Vercel AI SDK 对接 LLM。
Go： go modules 管包，golangci-lint v2 加 nilaway 做类型和 lint，gofumpt 格式化，go test -race -shuffle=on 跑测试，gin 或 chi 做 web，sqlc 加 pgx 做数据库（不是 GORM），cobra 做 CLI，log/slog 记日志，net/http 直接调用 LLM API。
代码坏味道（自动触发审查）
文件超过 250 行纯逻辑代码就是缺陷，必须拆分。
函数超过 3 个参数就是坏味，应该分组为类型化值对象。
破坏操作后的冗余验证（写完之后马上读回来检查）是 AI 生成代码的典型防御性膨胀，直接删掉。
否定形式命名（isNotValid、noErrors）重命名为肯定形式。
强制写后审查环
每次写完代码后，Agent 必须自问 10 个问题：
文件有单一职责吗，能用一句话命名吗；边界纯净吗，不可信输入在边界被解析了吗；变体区分用了穷举匹配而非 if/else 吗；有没有 Any、unwrap、@ts-ignore 这样的逃脱舱口；有没有对类型已证明值做多余的防御性空检查；有没有只被调用一次的一次性 helper 函数；新行为被测试锁定吗；参数超过 3 个吗；破坏操作后有多余的重新查询验证吗；有没有否定命名的东西。
二、refactor — 6 阶段安全重构协议
重构不是"打开文件，开始改"。oh-my-openagent 把它做成了一个 6 阶段的状态机。
Phase 0 是意图门：先解析请求类型，验证自己是否真正理解了要做什么。很多 AI 重构失败在这一步——它没确认就动手了。
Phase 1 是代码库分析：并行启动 5 个 explore agent，加上 LSP 做精确定义查找和引用分析，加上 ast-grep 做结构化模式匹配。三路并进。
Phase 2 构建代码地图：生成依赖图、标记影响区域、评估每步的风险等级。
Phase 3 评估测试覆盖：如果覆盖率不够，拒绝激进重构。
Phase 4 生成计划：Plan agent 把重构分解为多个原子步骤，每一步都可以独立验证。
Phase 5 执行重构：每一步的模式是 LSP 安全重命名 → 运行 lsp_diagnostics 验证 → 提交 git checkpoint。一步一个 checkpoint，出问题立即回滚。
Phase 6 最终验证：跑全量测试套件、类型检查、lint、构建。四项全绿才算通过。
核心原则就五个：理解再修改（先 LSP 再动手）、预览再执行（ast-grep 先 dry-run 再 apply）、每步验证、失败即停、覆盖不足就阻塞。
五个工具各司其职：LSP 负责精确定义查找和引用分析，ast-grep 做结构化模式匹配和批量替换，explore agent 做并行的代码库模式发现，Plan agent 生成详细的重构步骤，Oracle agent 应付复杂的架构决策。
当重构步骤中独立文件操作超过 3 个时，自动启用 team mode。一个 Lead（叫 Sisyphus）纯编排不写代码。两个 quick worker 做机械编辑（LSP 重命名、提取变量）。两个 unspecified-low worker 做逻辑重构（提取函数、模式转换）。外面还有一个独立的 verifier 负责验证，不参与重构本身。
三、debugging — 假设驱动的调试循环
调试 skill 有两条核心纪律。第一，运行时真相胜过代码阅读——每个关于 bug 原因的声明，必须来自观察到的状态，不能是从看代码编出来的可信故事。第二，不留痕迹——所有调试产物都记录到 .debug-journal.md 日志，完成后全部清除。
具体执行分 10 个阶段。
Phase 0 做环境评估——搞清楚运行时类型、端口、符号表、环境变量。
Phase 1 建日志文件追踪所有产物。
Phase 2 是关键：形成至少 3 个假设，必须跨正交轴（不是同一维度的 3 个变体），每个假设要有区分性证据。
Phase 3 并行调查，可以用 team mode 的 debug-squad 或者异步子代理。
Phase 4 是 Oracle Triple：连续两轮调查失败后，从正交角度生成 3 个 Oracle 提示。
Phase 5 只在证据耗尽且有政策影响时才升级给用户决策。
Phase 6 根因确认规则很严格：只有当切换疑似原因能切换 bug 时才算确认。
Phase 7 开始 TDD 修复——先写失败的 red test，最小 green 修复，不扩展范围。
Phase 8 手动 QA，实际使用系统——tmux、Playwright、curl，不是只跑测试。
Phase 9 清理，按日志回滚所有产物，验证 git diff 只有修复和测试。
Phase 10 过 4 个证据门做最终验证。
调试 skill 还有一个独特的设计：
每个运行时都有必读的参考文件，不读就不能动手，因为这个运行时的调试工具和行为和其他运行时不同。
Python 的 pdb、ipdb、debugpy、pytest --pdb 语义各自不同。Node.js 的 tsx 加 node inspect 有静默 source-map 失败。
Rust 的 Release 构建剥离了调试符号，tokio 任务需要 tokio-console 才能看到。Go 的 goroutine 泄漏和 recover panic 默认静默。macOS 原生二进制的 SIP、Mach-O、lldb 行为与 Linux 完全不同。甚至打包应用二进制（看起来像 Mach-O 或 ELF 但实际是 JS）需要完全不同的调试策略。
四、skill 设计的通用模式
从这三条 skill 里能提炼出 oh-my-openagent 设计 philosophy 的六个通用模式。
第一，强制前置阅读。 每条 skill 开头都是"读这个参考文件。不读就别动手。"这不是建议，是硬性门控。Phase 0 的 LANGUAGE GATE 用全大写写死了："DO NOT WRITE OR EDIT A SINGLE LINE OF CODE BEFORE COMPLETING THIS GATE."这不是给人类的，是给 AI Agent 的约束。
第二，引用外部化。 SKILL.md 本身是精简的索引，90% 的知识存在 references/ 子目录里。触发 skill 时只加载 SKILL.md（体积小），按需加载 references（按语言、按场景）。这是渐进式披露在 skill 层的应用。
第三，状态机阶段。 每条 skill 都是明确编号的阶段序列，每个阶段有四个要素：进入条件、工具或代理调用指令、完成标记、失败处理路径。不是段落散文，是状态机。
第四，自我审查环。 执行完不算完——必须通过自检环。programming 有 10 个问题，debugging 有 4 个证据门，refactor 每一步都要验证。这是 AI 写代码最容易跳过的步骤，oh-my-openagent 把它写死了。
第五，代理组合。 skill 不是让单个 agent 执行，而是编排多个 agent 协作。explore agent 做人肉搜索，plan agent 生成详细计划，oracle agent 应付困难决策，后台 agent 做并行探索，team mode 协调多 agent 协作重构。skill 是 conductor，不是 executor。
第六，技术栈锁定。 不泛泛说"用好的实践"——每个语言在 2026 年的正确工具链是写死的：uv 而非 pip，Biome 而非 ESLint 加 Prettier，sqlc 而非 GORM。这是可执行的判断，不是可讨论的风格。当工具链被锁定，AI 就没有选择余地，也就不会在选工具上浪费时间或选错。
来源：oh-my-openagent packages/shared-skills/skills/, 2026-06-18
8 12
# Johnny.Decimal：一个让你永远不会找不到文件的组织系统
我上周花了两个小时，把我整个内容工作室的项目目录全部重构了一遍。
不是我闲。是我发现一个问题：当你的项目里有 17 个信息源、75 个 X 账号、几百篇素材和草稿，你会花越来越多的时间在"找东西"上。你在 20 个目录之间来回切，你记不清"信息源清单"放在 `sources/` 还是 `data/` 还是 `links/`，你每次新建一个素材文件都要想应该塞哪个文件夹。
然后我遇到了 Johnny.Decimal。
---
## 这是什么
Johnny.Decimal 是一个文件组织系统。它的核心思想极其简单：**给每个文件夹一个编号，用编号代替脑子记位置。**
编号格式是 `AC.ID`——两个数字的区域，两个数字的类别，两个数字的 ID。
比如 `21-articles/`。你不需要记"外部文章和推文原文在 sources 目录下的 articles 子目录"。你只需要记"文章在 21"。你的脑子处理 `21` 比处理一长串中文路径快得多。
更妙的是，**编号本身不携带语义。它只是一个指针。** 你今天叫它"外部文章"，明天想改成"原文收录"，后天想拆成"英文"和"中文"——编号 21 始终在那里。目录名可以随便改，编号不动，所有引用都不会断。
---
## 我的实践：一个内容工作室的 Johnny.Decimal 化
我的项目是一个 X (Twitter) 内容工作室。日常要做的事：选题、找素材、写草稿、发布、追踪数据、定期复盘。
原来的目录结构是这样的：
```
inbox/ # 选题
sources/ # 素材
articles/ # 文章
deep-analysis/
links/
templates/
...
drafts/ # 草稿
published/ # 已发布
data/ # 数据
tools/ # 工具
```
看起来没问题。但当你真的在里面干了一两个月活，你会开始碰到一些"说不清哪不对"的痛点：
- "信息源清单"是放在 `sources/` 还是 `data/`？它既是素材也是配置
- `sources/` 下挂了 8 个子目录，眼睛扫过去是 8 个中文词，没有结构感
- 每次新建文件，你都要犹豫"这个算 article 还是 deep-analysis"
- Agent（AI 编码助手）在处理路径时，中文目录名经常出错
我决定用 Johnny.Decimal 全部重排。按"工作流"的维度分区：
```
10-19 内容流水线
11-inbox/ 选题
12-drafts/ 草稿
13-published/ 已发布
14-slides/ 配图
20-29 素材库
21-articles/ 外部文章
22-deep-analysis/ 深度分析
23-info-sources/ 信息源清单
24-links/ 链接索引
25-templates/ 模板
...
30-39 数据与追踪
31-engagement/ 互动数据
32-scout-reports/ 侦察报告
33-archive/ 归档
40-49 工具
50-59 系统配置
```
**为什么这样分区？**
10-19 是我的"生产线"——选题进来，草稿出去，发布，存档。这是日常打开最多的区域。
20-29 是"原料库"——所有外部输入都在这里。按信息深度从外部文章（21）到深度分析（22）到信息源清单（23）递增。
30-39 是"仪表盘"——不看的时候不需要，需要的时候必须迅速找到。
40-49 是"引擎舱"——工具脚本，偶尔打开。
50-59 是"说明书"——系统本身的文档。
**每个区域只放 10 个以内的类别，所以脑子里只有 5 个大区。** 找东西的逻辑变成："这是素材 → 去 20-29。这是数据 → 去 30-39。"不用再在十几个同级中文目录里扫。
---
## 实际用了几天后的感受
### 好处
**1. Agent 友好。** 这是我之前没想到的收益。AI 编码助手在处理项目文件时，`21-articles/` 比 `sources/articles/` 更容易被正确引用。数字编号没有编码问题、没有拼写歧义、字节更短。我让 Agent 帮我找一篇素材，说"在 21-articles 里"，它一次找对。以前说"在 sources/articles 里"偶尔会跑到别的文件夹。
**2. 新建东西时不再犹豫。** 以前写一篇深度分析，我要想"这是存 `sources/articles/` 还是 `sources/deep-analysis/`？"——因为它是基于外部文章写的，两边都有道理。现在 22 就是深度分析，不管来源是什么。编号强制你做分类决策，并且让决策变得简单。
**3. JDex 索引给了全局视野。** Johnny.Decimal 体系里有一个叫 JDex 的东西——一张表，列出所有编号和对应的内容。我的 JDex 只有一页，一眼看完整个项目的骨架。新加分类的时候，看一眼表就知道下一个可用的编号是什么。
**4. 删目录不心疼。** 以前 `sources/` 下有 8 个子目录，有一天我发现 `products/` 和 `cases/` 里面只各存了一个文件。在原来的结构里，你不会去删它们——好歹也是 sources 下面的一员。在编号体系里，29 如果只有两个文件，要么合并到 28，要么直接清空。编号冷冰冰地告诉你：这个槽位使用率 10%，砍了吧。
### 不适合的场景
- 项目很小（5 个文件以内）：编号是过度设计
- 高频变动的协作项目：编号适合相对稳定的分类体系，每周都变的不合适
- 如果你就是喜欢用搜索（Spotlight/Everything）找文件：编号体系的价值会打折
---
## 一段话总结
**Johnny.Decimal 解决的不是"文件夹太多"的问题，而是"脑子里的文件夹地图太模糊"的问题。**
你从来不是找不到文件。你是不确定它在哪个文件夹里。编号系统把你脑子里的模糊地图换成了精确坐标。`21-articles/` 的意思不是"文章应该在 20-29 大区下面的第一个类别"——而是你不需要想它在哪。你的手指自己会敲出 `cd 21`。
---
来源：johnnydecimal.com
实践项目：本文的目录结构来自我自己用 Johnny.Decimal 重构的 X 内容工作室。
我上周花了两个小时，把我整个内容工作室的项目目录全部重构了一遍。
不是我闲。是我发现一个问题：当你的项目里有 17 个信息源、75 个 X 账号、几百篇素材和草稿，你会花越来越多的时间在"找东西"上。你在 20 个目录之间来回切，你记不清"信息源清单"放在 `sources/` 还是 `data/` 还是 `links/`，你每次新建一个素材文件都要想应该塞哪个文件夹。
然后我遇到了 Johnny.Decimal。
---
## 这是什么
Johnny.Decimal 是一个文件组织系统。它的核心思想极其简单：**给每个文件夹一个编号，用编号代替脑子记位置。**
编号格式是 `AC.ID`——两个数字的区域，两个数字的类别，两个数字的 ID。
比如 `21-articles/`。你不需要记"外部文章和推文原文在 sources 目录下的 articles 子目录"。你只需要记"文章在 21"。你的脑子处理 `21` 比处理一长串中文路径快得多。
更妙的是，**编号本身不携带语义。它只是一个指针。** 你今天叫它"外部文章"，明天想改成"原文收录"，后天想拆成"英文"和"中文"——编号 21 始终在那里。目录名可以随便改，编号不动，所有引用都不会断。
---
## 我的实践：一个内容工作室的 Johnny.Decimal 化
我的项目是一个 X (Twitter) 内容工作室。日常要做的事：选题、找素材、写草稿、发布、追踪数据、定期复盘。
原来的目录结构是这样的：
```
inbox/ # 选题
sources/ # 素材
articles/ # 文章
deep-analysis/
links/
templates/
...
drafts/ # 草稿
published/ # 已发布
data/ # 数据
tools/ # 工具
```
看起来没问题。但当你真的在里面干了一两个月活，你会开始碰到一些"说不清哪不对"的痛点：
- "信息源清单"是放在 `sources/` 还是 `data/`？它既是素材也是配置
- `sources/` 下挂了 8 个子目录，眼睛扫过去是 8 个中文词，没有结构感
- 每次新建文件，你都要犹豫"这个算 article 还是 deep-analysis"
- Agent（AI 编码助手）在处理路径时，中文目录名经常出错
我决定用 Johnny.Decimal 全部重排。按"工作流"的维度分区：
```
10-19 内容流水线
11-inbox/ 选题
12-drafts/ 草稿
13-published/ 已发布
14-slides/ 配图
20-29 素材库
21-articles/ 外部文章
22-deep-analysis/ 深度分析
23-info-sources/ 信息源清单
24-links/ 链接索引
25-templates/ 模板
...
30-39 数据与追踪
31-engagement/ 互动数据
32-scout-reports/ 侦察报告
33-archive/ 归档
40-49 工具
50-59 系统配置
```
**为什么这样分区？**
10-19 是我的"生产线"——选题进来，草稿出去，发布，存档。这是日常打开最多的区域。
20-29 是"原料库"——所有外部输入都在这里。按信息深度从外部文章（21）到深度分析（22）到信息源清单（23）递增。
30-39 是"仪表盘"——不看的时候不需要，需要的时候必须迅速找到。
40-49 是"引擎舱"——工具脚本，偶尔打开。
50-59 是"说明书"——系统本身的文档。
**每个区域只放 10 个以内的类别，所以脑子里只有 5 个大区。** 找东西的逻辑变成："这是素材 → 去 20-29。这是数据 → 去 30-39。"不用再在十几个同级中文目录里扫。
---
## 实际用了几天后的感受
### 好处
**1. Agent 友好。** 这是我之前没想到的收益。AI 编码助手在处理项目文件时，`21-articles/` 比 `sources/articles/` 更容易被正确引用。数字编号没有编码问题、没有拼写歧义、字节更短。我让 Agent 帮我找一篇素材，说"在 21-articles 里"，它一次找对。以前说"在 sources/articles 里"偶尔会跑到别的文件夹。
**2. 新建东西时不再犹豫。** 以前写一篇深度分析，我要想"这是存 `sources/articles/` 还是 `sources/deep-analysis/`？"——因为它是基于外部文章写的，两边都有道理。现在 22 就是深度分析，不管来源是什么。编号强制你做分类决策，并且让决策变得简单。
**3. JDex 索引给了全局视野。** Johnny.Decimal 体系里有一个叫 JDex 的东西——一张表，列出所有编号和对应的内容。我的 JDex 只有一页，一眼看完整个项目的骨架。新加分类的时候，看一眼表就知道下一个可用的编号是什么。
**4. 删目录不心疼。** 以前 `sources/` 下有 8 个子目录，有一天我发现 `products/` 和 `cases/` 里面只各存了一个文件。在原来的结构里，你不会去删它们——好歹也是 sources 下面的一员。在编号体系里，29 如果只有两个文件，要么合并到 28，要么直接清空。编号冷冰冰地告诉你：这个槽位使用率 10%，砍了吧。
### 不适合的场景
- 项目很小（5 个文件以内）：编号是过度设计
- 高频变动的协作项目：编号适合相对稳定的分类体系，每周都变的不合适
- 如果你就是喜欢用搜索（Spotlight/Everything）找文件：编号体系的价值会打折
---
## 一段话总结
**Johnny.Decimal 解决的不是"文件夹太多"的问题，而是"脑子里的文件夹地图太模糊"的问题。**
你从来不是找不到文件。你是不确定它在哪个文件夹里。编号系统把你脑子里的模糊地图换成了精确坐标。`21-articles/` 的意思不是"文章应该在 20-29 大区下面的第一个类别"——而是你不需要想它在哪。你的手指自己会敲出 `cd 21`。
---
来源：johnnydecimal.com
实践项目：本文的目录结构来自我自己用 Johnny.Decimal 重构的 X 内容工作室。
4 00
# AI Agent 在真实工作中到底改变了什么？Perplexity + 哈佛商学院的 10 万条数据给出了答案
AI Agent 到底有没有用？这个问题被问了两年，答案一直停留在"感觉上"和"我觉得"之间。
上周，Perplexity 和哈佛商学院联合发了一篇研究。他们拿自己家的 Computer（一个通用 Agent 编排器）和 Search（对话式 AI 助手），在真实用户的 10 万条数据上做了系统性对比。这篇研究最难得的地方是：**它不是实验室里的受控实验，而是真实产品、真实用户、真实工作场景的使用数据。**
结论可以用一句话概括：**Agent 不只是让人做同样的事更快——它让人开始做以前做不到的事。** 但数字比这句话精彩得多。
---
## 三个数字：48×、-87%、-55%
### 48×：机器工时
同样的任务，用 Search（对话助手）和 Computer（Agent）分别跑，差别有多大？
Search 平均 33 秒返回结果。Computer 平均自主运行 **26 分钟**。中位数是 9 分钟 vs 14 秒。**48 倍的机器工时差距。** 在所有 18 个领域里，Computer 的自主运行时长都是 Search 的 26–75 倍。
**但你可能会想：跑这么久，会不会乱搞？用户会不会不耐烦按停？**
不会。用户主动停止的比例几乎一样：Computer 3.7%，Search 3.4%。自主性暴增 48 倍，放弃率没变。更有意思的是：Computer 确实更经常暂停问用户——13% 的查询会请求用户输入（Search 只有 0.3%），通常是确认权限或澄清需求。**这不是 bug，是 Agent 的正常行为模式：大部分时间自主推进，碰到关键决策点就问。**
### -87%：任务时间
研究者用了三种独立方法来估算效率提升（工具分类法、LLM 估算法、用户访谈法），结果一致：
- **工具法**：Search + 人工 = 269 分钟 → Computer + 人工 = 36 分钟（**-87%**）
- **LLM 法**：**-84%** 时间，**-93%** 成本
- **用户访谈**（中位数）：**-96%** 时间，约 **25 倍**加速
换算成钱：按美国劳工统计局各行业平均时薪计算，总成本缩减 **94%**。
**最极端的是编程领域**：Search + 人工 = 596 分钟（近 10 小时），Computer + 人工 = 48 分钟。92% 的时间压缩，96% 的成本压缩。而且这是在匹配相同任务的前提下——实际使用中 Computer 用户往往做更大的任务，真实差距可能更大。
**但你可能又会想：省了时间，质量呢？会不会做出来一坨？**
### -55%：不满意率
这是整篇研究最反直觉的数字。在匹配的多轮对话里：
- Search 的"有意义不满意"率：**2.9%**
- Computer：**1.3%**
**自主性越高，用户越满意。** 包含轻度不满在内的任何不满信号：Search 16.6%，Computer 10.8%。
为什么会这样？研究没有直接解释，但数据给了线索：Computer 用户把更多追问用于"扩展"（14.2% vs 12.5%）和"审查修改"（24.6% vs 23.6%），而 Search 用户更多是短指令式的确认和重试（11.6% vs 9.9%）。换句话说，**Search 创建的是"消化-再执行"的短循环；Computer 创建的是"审查-扩展"的长循环。** 短循环里你一直在纠正 AI 的输出，长循环里你在 AI 产出的基础上往上加。前者让人烦，后者让人爽。
---
## 更重要的事：任务本身的维度在变
效率数字当然震撼。但研究里更重要的部分，可能是任务范围的测量。
### 横向：用户不断跨界
Computer 用户 **59%** 的问题涉及自己主业以外的领域，Search 用户是 50%。跨界流向也有结构性变化：Search 的跨界全部涌向 Digital Technology（程序员的活儿），而 Computer 的跨界分散在 Marketing、Management、Financial Services 等多个领域。
**Agent 让你的能力边界变模糊了。** 你不是"问了 AI 然后自己去做"，你是"让 Agent 替你做"。一个市场营销人员可以让 Agent 写一个数据分析脚本；一个金融分析师可以让 Agent 做一套可视化图表。不需要学编程，不需要请人。Agent 填平了专业之间的沟。
### 纵向：任务认知层级急剧上升
用 Bloom 认知分类法（教育学界用了 70 年的框架）标注 5000 条 Computer 查询和 5000 条 Search 查询：
- **高阶认知任务**（分析、评估、创造）：Computer **76%**，Search 55%
- **创造级任务**（最高层）：Computer **50%**，Search 26%
- **记忆级任务**（最底层，纯查事实）：Search 大量集中，Computer 几乎不做
换句话说，**你把"查东西"扔给了 Search，把"做东西"扔给了 Computer。** Agent 并没有取代搜索——Computer 用户比非 Computer 用户每天多用 1.05 次 Search——而是把人的注意力从"查找"和"执行"解放出来，投入到"定义目标"和"判断产出"上。
这引出了整篇研究最重要的一句话：
> *"用户从操作者变成了监督者。他们花更少的时间操作工作流，更多的时间设定目标、提供上下文、检查输出、请求扩展。"*
### 还有更吓人的：23% 的任务是"全新的"
研究者做了一件事：把同一个用户用 Computer 和 Search 的任务列出来，找那些**只出现在 Computer 里、从来没在 Search 中出现过的任务类型**。
结果：在最严格的定义下，**23% 的 Computer 查询涉及 Search 从未覆盖的任务**。这些"Computer 专属任务"集中在软件/web 开发、文档生产、数据可视化。
**Agent 不只是自动化已有工作。它让人开始做以前根本不会去做的工作。** 不是因为人懒，而是因为以前做这些事的成本高到不值得做。Agent 把成本打到几乎为零，于是边际上的新任务全冒出来了。这就是经济学说的"需求弹性"：价格跌到零，需求不是翻倍，是爆炸。
---
## 什么在变，什么没变
### 确认了的事情（和之前的研究一致）
- Agent 大幅提升效率——这和此前 OpenAI、Anthropic、GitHub 的编码 Agent 研究一致
- 白领知识工作是 Agent 影响最大的领域
- 效率提升在高薪领域更显著（因为省的人工更贵）
### 新发现（之前的研究没覆盖的）
- **自主性和满意度正相关**——这是反直觉的。直觉上你会觉得 Agent 做越多、人越不放心。数据说正好相反
- **Agent 补充而非替代搜索**——Computer 用户更多用 Search，不是更少。两种工具满足不同层级的认知需求
- **Agent 生成新任务，不只是替代旧任务**——23% 的"Computer 专属任务"是这篇研究最原创的发现
- **任务认知层级的结构性上移**——50% 是创造级任务，这个比例远超任何之前的估计
---
## 启发
1. **"效率提升"是 Agent 最无聊的卖点。** 这篇研究把省时间和省钱算得很清楚，但真正重要的发现是任务结构在变。用户从"操作者"变成了"监督者"。这不是量变，是质变。监督者和操作者需要的技能、思维方式、工作习惯，完全不一样。
2. **"不满意率下降"这个发现值得单独拿出来讲。** 它暗示了一个可能：用户对 AI 的不满，很大一部分不是因为 AI 不够聪明，而是因为 AI 只是"助手"——它告诉你答案，让你自己去执行。执行过程中出问题，你怪自己还是怪 AI 都别扭。Agent 直接把执行也做了，你只需要判断结果好坏。认知负担从"理解 + 执行 + 判断"压缩成了"判断"。负担轻了，满意度自然高了。
3. **"23% 的新任务"是最容易被忽视的炸弹。** 如果说 Agent 让现有工作变快变便宜是"效率革命"，那它让从未被做过的工作变成可能，就是"范围革命"。范围革命的影响远大于效率革命——蒸汽机不只是让马车跑得更快，它让铁路和工厂成为可能。
4. **今天这篇文章读起来可能有点抽象，但如果把你自己代入"Computer 用户"的角色，你会发现你已经在做这些事情了：** 你让 Agent 帮你写代码、做表、搜素材、翻译文章。你不是在"用工具"，你是在"下达任务、检查产出"。你早就是监督者了。只是之前没人拿 10 万条数据告诉你：大家都这样。
---
原文：research.perplexity.ai
技术报告：arxiv.org
AI Agent 到底有没有用？这个问题被问了两年，答案一直停留在"感觉上"和"我觉得"之间。
上周，Perplexity 和哈佛商学院联合发了一篇研究。他们拿自己家的 Computer（一个通用 Agent 编排器）和 Search（对话式 AI 助手），在真实用户的 10 万条数据上做了系统性对比。这篇研究最难得的地方是：**它不是实验室里的受控实验，而是真实产品、真实用户、真实工作场景的使用数据。**
结论可以用一句话概括：**Agent 不只是让人做同样的事更快——它让人开始做以前做不到的事。** 但数字比这句话精彩得多。
---
## 三个数字：48×、-87%、-55%
### 48×：机器工时
同样的任务，用 Search（对话助手）和 Computer（Agent）分别跑，差别有多大？
Search 平均 33 秒返回结果。Computer 平均自主运行 **26 分钟**。中位数是 9 分钟 vs 14 秒。**48 倍的机器工时差距。** 在所有 18 个领域里，Computer 的自主运行时长都是 Search 的 26–75 倍。
**但你可能会想：跑这么久，会不会乱搞？用户会不会不耐烦按停？**
不会。用户主动停止的比例几乎一样：Computer 3.7%，Search 3.4%。自主性暴增 48 倍，放弃率没变。更有意思的是：Computer 确实更经常暂停问用户——13% 的查询会请求用户输入（Search 只有 0.3%），通常是确认权限或澄清需求。**这不是 bug，是 Agent 的正常行为模式：大部分时间自主推进，碰到关键决策点就问。**
### -87%：任务时间
研究者用了三种独立方法来估算效率提升（工具分类法、LLM 估算法、用户访谈法），结果一致：
- **工具法**：Search + 人工 = 269 分钟 → Computer + 人工 = 36 分钟（**-87%**）
- **LLM 法**：**-84%** 时间，**-93%** 成本
- **用户访谈**（中位数）：**-96%** 时间，约 **25 倍**加速
换算成钱：按美国劳工统计局各行业平均时薪计算，总成本缩减 **94%**。
**最极端的是编程领域**：Search + 人工 = 596 分钟（近 10 小时），Computer + 人工 = 48 分钟。92% 的时间压缩，96% 的成本压缩。而且这是在匹配相同任务的前提下——实际使用中 Computer 用户往往做更大的任务，真实差距可能更大。
**但你可能又会想：省了时间，质量呢？会不会做出来一坨？**
### -55%：不满意率
这是整篇研究最反直觉的数字。在匹配的多轮对话里：
- Search 的"有意义不满意"率：**2.9%**
- Computer：**1.3%**
**自主性越高，用户越满意。** 包含轻度不满在内的任何不满信号：Search 16.6%，Computer 10.8%。
为什么会这样？研究没有直接解释，但数据给了线索：Computer 用户把更多追问用于"扩展"（14.2% vs 12.5%）和"审查修改"（24.6% vs 23.6%），而 Search 用户更多是短指令式的确认和重试（11.6% vs 9.9%）。换句话说，**Search 创建的是"消化-再执行"的短循环；Computer 创建的是"审查-扩展"的长循环。** 短循环里你一直在纠正 AI 的输出，长循环里你在 AI 产出的基础上往上加。前者让人烦，后者让人爽。
---
## 更重要的事：任务本身的维度在变
效率数字当然震撼。但研究里更重要的部分，可能是任务范围的测量。
### 横向：用户不断跨界
Computer 用户 **59%** 的问题涉及自己主业以外的领域，Search 用户是 50%。跨界流向也有结构性变化：Search 的跨界全部涌向 Digital Technology（程序员的活儿），而 Computer 的跨界分散在 Marketing、Management、Financial Services 等多个领域。
**Agent 让你的能力边界变模糊了。** 你不是"问了 AI 然后自己去做"，你是"让 Agent 替你做"。一个市场营销人员可以让 Agent 写一个数据分析脚本；一个金融分析师可以让 Agent 做一套可视化图表。不需要学编程，不需要请人。Agent 填平了专业之间的沟。
### 纵向：任务认知层级急剧上升
用 Bloom 认知分类法（教育学界用了 70 年的框架）标注 5000 条 Computer 查询和 5000 条 Search 查询：
- **高阶认知任务**（分析、评估、创造）：Computer **76%**，Search 55%
- **创造级任务**（最高层）：Computer **50%**，Search 26%
- **记忆级任务**（最底层，纯查事实）：Search 大量集中，Computer 几乎不做
换句话说，**你把"查东西"扔给了 Search，把"做东西"扔给了 Computer。** Agent 并没有取代搜索——Computer 用户比非 Computer 用户每天多用 1.05 次 Search——而是把人的注意力从"查找"和"执行"解放出来，投入到"定义目标"和"判断产出"上。
这引出了整篇研究最重要的一句话：
> *"用户从操作者变成了监督者。他们花更少的时间操作工作流，更多的时间设定目标、提供上下文、检查输出、请求扩展。"*
### 还有更吓人的：23% 的任务是"全新的"
研究者做了一件事：把同一个用户用 Computer 和 Search 的任务列出来，找那些**只出现在 Computer 里、从来没在 Search 中出现过的任务类型**。
结果：在最严格的定义下，**23% 的 Computer 查询涉及 Search 从未覆盖的任务**。这些"Computer 专属任务"集中在软件/web 开发、文档生产、数据可视化。
**Agent 不只是自动化已有工作。它让人开始做以前根本不会去做的工作。** 不是因为人懒，而是因为以前做这些事的成本高到不值得做。Agent 把成本打到几乎为零，于是边际上的新任务全冒出来了。这就是经济学说的"需求弹性"：价格跌到零，需求不是翻倍，是爆炸。
---
## 什么在变，什么没变
### 确认了的事情（和之前的研究一致）
- Agent 大幅提升效率——这和此前 OpenAI、Anthropic、GitHub 的编码 Agent 研究一致
- 白领知识工作是 Agent 影响最大的领域
- 效率提升在高薪领域更显著（因为省的人工更贵）
### 新发现（之前的研究没覆盖的）
- **自主性和满意度正相关**——这是反直觉的。直觉上你会觉得 Agent 做越多、人越不放心。数据说正好相反
- **Agent 补充而非替代搜索**——Computer 用户更多用 Search，不是更少。两种工具满足不同层级的认知需求
- **Agent 生成新任务，不只是替代旧任务**——23% 的"Computer 专属任务"是这篇研究最原创的发现
- **任务认知层级的结构性上移**——50% 是创造级任务，这个比例远超任何之前的估计
---
## 启发
1. **"效率提升"是 Agent 最无聊的卖点。** 这篇研究把省时间和省钱算得很清楚，但真正重要的发现是任务结构在变。用户从"操作者"变成了"监督者"。这不是量变，是质变。监督者和操作者需要的技能、思维方式、工作习惯，完全不一样。
2. **"不满意率下降"这个发现值得单独拿出来讲。** 它暗示了一个可能：用户对 AI 的不满，很大一部分不是因为 AI 不够聪明，而是因为 AI 只是"助手"——它告诉你答案，让你自己去执行。执行过程中出问题，你怪自己还是怪 AI 都别扭。Agent 直接把执行也做了，你只需要判断结果好坏。认知负担从"理解 + 执行 + 判断"压缩成了"判断"。负担轻了，满意度自然高了。
3. **"23% 的新任务"是最容易被忽视的炸弹。** 如果说 Agent 让现有工作变快变便宜是"效率革命"，那它让从未被做过的工作变成可能，就是"范围革命"。范围革命的影响远大于效率革命——蒸汽机不只是让马车跑得更快，它让铁路和工厂成为可能。
4. **今天这篇文章读起来可能有点抽象，但如果把你自己代入"Computer 用户"的角色，你会发现你已经在做这些事情了：** 你让 Agent 帮你写代码、做表、搜素材、翻译文章。你不是在"用工具"，你是在"下达任务、检查产出"。你早就是监督者了。只是之前没人拿 10 万条数据告诉你：大家都这样。
---
原文：research.perplexity.ai
技术报告：arxiv.org
4 00
