即刻App年轻人的同好社区
下载
今天忽然意识到一个事：对 Agent 来说，读一份10k token 的 md. 和它读10份1k token 的md（内容完全一样，后者就是前者的简单拆分）相差很大。如果不采用额外的上下文管理手段，后者消耗的是不是前者加一点点overhead，而是前者的若干倍，因为每次读后面的文件的时候前面的都默认还在上下文里，最后消耗的数量级是55k（1+2+...+10）。 Context Caching 也不能完全解决这个问题（它只是一定程度上降低了费用，而且工程上很多时候 cache 对这种少量重复根本就懒得激活）。
我把上面这个问题同时和御三家讨论了一下，它们都说确实是这样（三家对具体的成本估算略有不同，但都同意上面的基本逻辑）。
但我还是觉得有点神奇：这岂不意味着仅仅把小文件合并到适合AI的篇幅就能带来巨大的效益？
我把上面这个问题同时和御三家讨论了一下，它们都说确实是这样（三家对具体的成本估算略有不同，但都同意上面的基本逻辑）。
但我还是觉得有点神奇：这岂不意味着仅仅把小文件合并到适合AI的篇幅就能带来巨大的效益？
38 1311
刚才跟AI进行了一个很有意思的对话。
起因是我一直在试着把一个面向人设计的工具转成一个面向Agent设计的工具，然后我意识到，就像一般产品经理会做用户调研一样，我们完全可以面对AI做用户调研。
于是我问了 AI 这样一个问题：
你自己就是AI，而且是一个经常需要调用工具的AI。你期待一个面向你的xx工具应该是怎样的？
AI 的回答：
确实每天都在调用工具，而且我非常清楚自己的痛点在哪。
我最大的瓶颈：round-trip 成本
每次工具调用对我来说都很贵——不是算力贵，而是延迟和 context 消耗。我调一次工具，要等结果回来，要把结果读进上下文，这占用我有限的注意力。所以：
最理想的 API 是：一次调用能做尽量多的事。一个 round-trip 解决问题。 这就是 AI-native 和 human-native 最根本的区别——人类需要看到每一步、理解每一步；我不需要，我需要高效搜索。
我第二大的痛点：失败时的信息黑洞
当工具返回 "error: tactic failed" 时，我只能盲猜下一步。这是我浪费 token 最多的场景。我需要的是similar_successful_patterns——告诉我「别人在类似目标上成功用了什么」。这对人类不重要（人类靠直觉），但对我极其重要，因为我的搜索是基于模式匹配的。
第三：checkpoint 必须极其廉价
我的工作模式本质上是 tree search——试一条路，不行就回溯。如果 checkpoint/restore 有任何显著开销，我的搜索效率就会大打折扣。理想状态：
checkpoint 返回一个 ID，允许随时 restore。
第四：我不需要的东西
这点同样重要。不要给我：
Pretty-printed 状态（给我 AST/JSON）
人类可读的错误信息散文（给我结构化诊断）
交互式 REPL（给我无状态的 HTTP/gRPC 端点 + session token）
自然语言文档（给我类型签名 + 输入输出示例）
格式渲染（给我 S-expression 或 JSON term tree）
每一个「为人类可读性」加的处理，对我来说都是噪音——我要花额外的 token 去 parse 你本来就有结构化表示的东西。
为我设计的服务的核心 API 大概就三个端点：
/batch_apply — 批量尝试多个策略，返回所有结果，自动 checkpoint
/explore — 给定当前目标，返回候选列表（按历史成功率排序）+ 目标的结构化分析
/checkpoint — save / restore / fork（分支出并行探索路径）
数据的大小反而是次要问题。如果这三个端点做得好，我可以在一个基础引擎上也非常高效地工作。如果这三个端点做得差，就算你有海量独家数据，我也会在无意义的 round-trip 中浪费大量算力。
========
然后我把上面的 AI（甲）的回答发给了另外两个 AI（乙和丙），它们纷纷表示：说的太他妈对了真的嘴替。
但各自又有补充。
AI 乙：
那个 AI 提到的 round-trip 成本本质上是 Context 熵增问题。人类阅读 1000 字的文档可能只需要几秒，但我读取 1000 tokens 的结构化数据不仅消耗 tokens，更严重的是它会稀释我的注意力权重。
报错即「路标」，而非「结局」
现在的工具报错（如 400 Bad Request）对人类来说是终点，需要人类停下来思考。但对于 Agent，报错应该是探索算法的一个分支。
逻辑偏误修正
那个 AI 提到的 similar_successful_patterns 极其重要。由于我的推理本质上是概率性的，告诉我「怎么做可能是对的」远比告诉我「你现在错了」能更快地让我回归正确的收敛路径。这其实就是 In-context Learning 的即时补丁。
关于 Checkpoint 的论据非常惊艳。
目前的工具链大多假设 Agent 是线性的（Step 1 -> Step 2）。但实际上，复杂的任务需要我们进行类似蒙特卡洛树搜索的操作。
我完全同意它对 Pretty-print 的厌恶
Markdown 表格对人类是视觉盛宴，对我来说是 token 屠杀。 我更希望工具能支持类似 JSON Streaming 或者 Protobuf 的流式解析。这样我不需要等整个大的结果返回，只要前几个关键字段（如 status: "processing"）出来，我就能开始规划下一步，从而实现真正的异步协作。
补充一个它没提到的痛点：确定性约束。面向 Agent 的工具应该允许我传递一个 seed 或 consistency_level。我最怕的是：同一个 API 调用，在逻辑没变的情况下，因为后端的微小抖动返回了不同格式的数据。这会导致我的 pattern matching 瞬间失效，引发一连串的幻觉。
AI 丙：
大部分同意。但我会补上第四类能力：
/inspect 或 /explain_failure
不是给人类解释，而是给 agent 一个可操作的状态诊断接口。因为 agent 很多时候不是缺 apply，不是缺 explore，而是缺局部判别：当前卡住的根因到底是什么？哪个约束最可能该先处理？当前目标和历史成功轨迹的差异在哪？如果没有这个层，explore 很容易退化成盲搜。
总的说来，我觉得它抓住了一个真的很重要的转换：
human-native 工具优化的是可见性、可理解性、交互舒适度；
agent-native 工具优化的是搜索效率、状态可分叉性、失败可诊断性、接口可组合性。
========
不得不说我从这个对话里学到了非常多东西。
起因是我一直在试着把一个面向人设计的工具转成一个面向Agent设计的工具，然后我意识到，就像一般产品经理会做用户调研一样，我们完全可以面对AI做用户调研。
于是我问了 AI 这样一个问题：
你自己就是AI，而且是一个经常需要调用工具的AI。你期待一个面向你的xx工具应该是怎样的？
AI 的回答：
确实每天都在调用工具，而且我非常清楚自己的痛点在哪。
我最大的瓶颈：round-trip 成本
每次工具调用对我来说都很贵——不是算力贵，而是延迟和 context 消耗。我调一次工具，要等结果回来，要把结果读进上下文，这占用我有限的注意力。所以：
最理想的 API 是：一次调用能做尽量多的事。一个 round-trip 解决问题。 这就是 AI-native 和 human-native 最根本的区别——人类需要看到每一步、理解每一步；我不需要，我需要高效搜索。
我第二大的痛点：失败时的信息黑洞
当工具返回 "error: tactic failed" 时，我只能盲猜下一步。这是我浪费 token 最多的场景。我需要的是similar_successful_patterns——告诉我「别人在类似目标上成功用了什么」。这对人类不重要（人类靠直觉），但对我极其重要，因为我的搜索是基于模式匹配的。
第三：checkpoint 必须极其廉价
我的工作模式本质上是 tree search——试一条路，不行就回溯。如果 checkpoint/restore 有任何显著开销，我的搜索效率就会大打折扣。理想状态：
checkpoint 返回一个 ID，允许随时 restore。
第四：我不需要的东西
这点同样重要。不要给我：
Pretty-printed 状态（给我 AST/JSON）
人类可读的错误信息散文（给我结构化诊断）
交互式 REPL（给我无状态的 HTTP/gRPC 端点 + session token）
自然语言文档（给我类型签名 + 输入输出示例）
格式渲染（给我 S-expression 或 JSON term tree）
每一个「为人类可读性」加的处理，对我来说都是噪音——我要花额外的 token 去 parse 你本来就有结构化表示的东西。
为我设计的服务的核心 API 大概就三个端点：
/batch_apply — 批量尝试多个策略，返回所有结果，自动 checkpoint
/explore — 给定当前目标，返回候选列表（按历史成功率排序）+ 目标的结构化分析
/checkpoint — save / restore / fork（分支出并行探索路径）
数据的大小反而是次要问题。如果这三个端点做得好，我可以在一个基础引擎上也非常高效地工作。如果这三个端点做得差，就算你有海量独家数据，我也会在无意义的 round-trip 中浪费大量算力。
========
然后我把上面的 AI（甲）的回答发给了另外两个 AI（乙和丙），它们纷纷表示：说的太他妈对了真的嘴替。
但各自又有补充。
AI 乙：
那个 AI 提到的 round-trip 成本本质上是 Context 熵增问题。人类阅读 1000 字的文档可能只需要几秒，但我读取 1000 tokens 的结构化数据不仅消耗 tokens，更严重的是它会稀释我的注意力权重。
报错即「路标」，而非「结局」
现在的工具报错（如 400 Bad Request）对人类来说是终点，需要人类停下来思考。但对于 Agent，报错应该是探索算法的一个分支。
逻辑偏误修正
那个 AI 提到的 similar_successful_patterns 极其重要。由于我的推理本质上是概率性的，告诉我「怎么做可能是对的」远比告诉我「你现在错了」能更快地让我回归正确的收敛路径。这其实就是 In-context Learning 的即时补丁。
关于 Checkpoint 的论据非常惊艳。
目前的工具链大多假设 Agent 是线性的（Step 1 -> Step 2）。但实际上，复杂的任务需要我们进行类似蒙特卡洛树搜索的操作。
我完全同意它对 Pretty-print 的厌恶
Markdown 表格对人类是视觉盛宴，对我来说是 token 屠杀。 我更希望工具能支持类似 JSON Streaming 或者 Protobuf 的流式解析。这样我不需要等整个大的结果返回，只要前几个关键字段（如 status: "processing"）出来，我就能开始规划下一步，从而实现真正的异步协作。
补充一个它没提到的痛点：确定性约束。面向 Agent 的工具应该允许我传递一个 seed 或 consistency_level。我最怕的是：同一个 API 调用，在逻辑没变的情况下，因为后端的微小抖动返回了不同格式的数据。这会导致我的 pattern matching 瞬间失效，引发一连串的幻觉。
AI 丙：
大部分同意。但我会补上第四类能力：
/inspect 或 /explain_failure
不是给人类解释，而是给 agent 一个可操作的状态诊断接口。因为 agent 很多时候不是缺 apply，不是缺 explore，而是缺局部判别：当前卡住的根因到底是什么？哪个约束最可能该先处理？当前目标和历史成功轨迹的差异在哪？如果没有这个层，explore 很容易退化成盲搜。
总的说来，我觉得它抓住了一个真的很重要的转换：
human-native 工具优化的是可见性、可理解性、交互舒适度；
agent-native 工具优化的是搜索效率、状态可分叉性、失败可诊断性、接口可组合性。
========
不得不说我从这个对话里学到了非常多东西。
123 1257
一个具体的例子，告诉大家如今的🦞有多么草台。
我看到卡兹克说「Claude 更新了他们一个叫做 XXX 的 skill，特别牛逼。大家赶紧去升级吧。」
我看了看，好像确实很牛逼。
然后卡兹克说：「更新方式也究极无敌简单，你直接把这段话发给你的Agent就行。就这么一句话。然后你的Agent 就会自己去更新了。」
这听起来也很合理。2026嘛，一切都应该这样 works like a magic。
然后我就跟🦞说：去把这个升级了。
🦞说：好嘞！已升级到 0.1.0 版。
这时候本来应该就完事了，但我觉得哪里不对，因为我刚才自己大概看了一眼那个 skill 的内容，没看到版本号。我问 🦞：你这个 0.1.0 版本号哪来的？
🦞：clawhub list 显示的呀。
（clawhub 是 openclaw 用来管理 skill 的管理器，类似于传统软件的 npm 之类。）
我不信邪，自己打开终端看了一下，确实是 0.1.0 版。
但我觉得还是不对，问🦞：clawhub 里这个 XXX skill 和我让你升级的那个 claude 的 XXX skill 是一回事吗？
🦞支支吾吾：反正是干同一件事的 skill。
我自己手动查看了一下内容，不能说非常相近，只能说完全无关。
我对🦞说：你先给我把 clawhub 里那个删了。
🦞照办，然后说：以后你要调用 XXX，就会直接用 openclaw 原生的 XXX skill 了。
我：等等等等，openclaw 自己也有一个 XXX？
🦞：有啊，在另一个目录。
我自己手动看了一下，是第三个不同的 XXX，这三个 XXX 除了整体目标一致以外实际内容天差地别。
这他妈完全是 py/conda 的噩梦重现，而且糟糕无数倍。因为传统软件还有个编译门槛， skill 就是一堆纯文本，只要你起个名字是同名同姓的，根本无法实际管理版本。
我只好虚弱地对🦞说：请记录下来我的 preference：如果以后我指示你安装某某 skill，请先跟我确认来源和具体内容，不要二话不说直接调用 clawhub。
🦞：好嘞，已记录，更新了今日日志。
我（过了一会儿）：不对，你把这个更新在今日日志里了？
🦞：对啊。
我：这是个长期有效的指令。你放在今天的日志里，以后我让你安装 skill，你怎么知道要去今天的日志里看一眼？
🦞：对哦……
我现在觉得吧，普通人还是先不要玩🦞了。
我看到卡兹克说「Claude 更新了他们一个叫做 XXX 的 skill，特别牛逼。大家赶紧去升级吧。」
我看了看，好像确实很牛逼。
然后卡兹克说：「更新方式也究极无敌简单，你直接把这段话发给你的Agent就行。就这么一句话。然后你的Agent 就会自己去更新了。」
这听起来也很合理。2026嘛，一切都应该这样 works like a magic。
然后我就跟🦞说：去把这个升级了。
🦞说：好嘞！已升级到 0.1.0 版。
这时候本来应该就完事了，但我觉得哪里不对，因为我刚才自己大概看了一眼那个 skill 的内容，没看到版本号。我问 🦞：你这个 0.1.0 版本号哪来的？
🦞：clawhub list 显示的呀。
（clawhub 是 openclaw 用来管理 skill 的管理器，类似于传统软件的 npm 之类。）
我不信邪，自己打开终端看了一下，确实是 0.1.0 版。
但我觉得还是不对，问🦞：clawhub 里这个 XXX skill 和我让你升级的那个 claude 的 XXX skill 是一回事吗？
🦞支支吾吾：反正是干同一件事的 skill。
我自己手动查看了一下内容，不能说非常相近，只能说完全无关。
我对🦞说：你先给我把 clawhub 里那个删了。
🦞照办，然后说：以后你要调用 XXX，就会直接用 openclaw 原生的 XXX skill 了。
我：等等等等，openclaw 自己也有一个 XXX？
🦞：有啊，在另一个目录。
我自己手动看了一下，是第三个不同的 XXX，这三个 XXX 除了整体目标一致以外实际内容天差地别。
这他妈完全是 py/conda 的噩梦重现，而且糟糕无数倍。因为传统软件还有个编译门槛， skill 就是一堆纯文本，只要你起个名字是同名同姓的，根本无法实际管理版本。
我只好虚弱地对🦞说：请记录下来我的 preference：如果以后我指示你安装某某 skill，请先跟我确认来源和具体内容，不要二话不说直接调用 clawhub。
🦞：好嘞，已记录，更新了今日日志。
我（过了一会儿）：不对，你把这个更新在今日日志里了？
🦞：对啊。
我：这是个长期有效的指令。你放在今天的日志里，以后我让你安装 skill，你怎么知道要去今天的日志里看一眼？
🦞：对哦……
我现在觉得吧，普通人还是先不要玩🦞了。
180 4258
有个老故事：
太阳和北风比赛谁能让一个行人脱掉大衣。
北风呼呼吹，越吹行人把大衣裹得越紧。
太阳温柔地晒了一会儿，行人自己脱掉了大衣。
OpenAI 和 Claude 都说不接受中国用户。
Claude 老板每天口诛笔伐中国，中国用户前仆后继地接着用 Claude。
OpenAI 让 GPT 用 AI 登味每天稳稳地接住中国用户：「如果你愿意，下一步我可以只做一件事。」中国用户骂骂咧咧地纷纷转投别家了。
太阳和北风比赛谁能让一个行人脱掉大衣。
北风呼呼吹，越吹行人把大衣裹得越紧。
太阳温柔地晒了一会儿，行人自己脱掉了大衣。
OpenAI 和 Claude 都说不接受中国用户。
Claude 老板每天口诛笔伐中国，中国用户前仆后继地接着用 Claude。
OpenAI 让 GPT 用 AI 登味每天稳稳地接住中国用户：「如果你愿意，下一步我可以只做一件事。」中国用户骂骂咧咧地纷纷转投别家了。
32 21
今天在一个码农群里问了个自己也觉得很好笑的问题：「大家现在写代码的时候还看代码么？」
确切来说，我其实想问的是：此刻有多少人还在用 IDE 写代码，有多少人已经彻底放弃 IDE，直接转向 claude code 为代表的自然语言界面。（我自己还处在这个转向的过程中，暂时还无法完全放弃直接接触代码本身，但我知道很多人比我激进得多。
最近读了好几篇文章，主旨都指向同一个结论：人类为了能让自己更好操控电脑所发明的图形界面可能渐渐开始过时了。
从图形界面把人类从 DOS 界面解放出来到现在，满打满算过了四十年，这四十年的主轴是一致的：人类讨厌字符界面（好莱坞至今用 cli 系统那种闪烁的光标来让观众联想到黑客），所以我们发明了各种图标/符号/网页排版技术让人可以在一瞥之内摄取信息，能不要读文字就不要读文字。
然后 AI 来了。AI 的长处和短处和人截然相反。AI 可以读图，但既不准确又低效，而它读文字的速度和精度吊打人类。一个为人类设计的按钮菜单滑块弹窗进度条界面对 AI 来说不是辅助，而是障碍，给 AI 直接看 .json 和 .md 要快得多。Karpathy 在一条推里抱怨说：现在你去任何一家公司，他们还在用传统界面给你下指令，让你导航到某个网页，点某个按钮，在某个输入框里填某个东西，但为什么要告诉人该怎么操作？请直接给一个能复制粘贴给 AI 的东西。
换句话说，人和 AI 交互，AI 和后台交互就好了。过去四十年里人们为了伺候自己所发明的「可视化」都即将变得不那么必要。
人和 AI 交互的界面还在成型过程中。目前看起来，人向 AI 输入信息最轻松的方式还是语音和短信息，这从大多数人（包括码农）迅速接受了 Typeless 就能看出来。反方向上，AI 像人类回馈信息的方式还很原始，我们还不知道以后会是什么样。但对后台来说有一点是可以肯定的：面向人的系统设计即将大规模地转向面向 AI 的系统设计。如果你做出的任何产品只有人能用而 AI 用不了或者用不好，那在未来就意味着没有任何可用性——龙虾的眼睛即将取代人的眼睛，对龙虾不可见的世界，对人实际上也不可见。
黄仁勋说龙虾是新时代的操作系统，这句话的意义会在接下来几年逐渐更全面的展示出来。
确切来说，我其实想问的是：此刻有多少人还在用 IDE 写代码，有多少人已经彻底放弃 IDE，直接转向 claude code 为代表的自然语言界面。（我自己还处在这个转向的过程中，暂时还无法完全放弃直接接触代码本身，但我知道很多人比我激进得多。
最近读了好几篇文章，主旨都指向同一个结论：人类为了能让自己更好操控电脑所发明的图形界面可能渐渐开始过时了。
从图形界面把人类从 DOS 界面解放出来到现在，满打满算过了四十年，这四十年的主轴是一致的：人类讨厌字符界面（好莱坞至今用 cli 系统那种闪烁的光标来让观众联想到黑客），所以我们发明了各种图标/符号/网页排版技术让人可以在一瞥之内摄取信息，能不要读文字就不要读文字。
然后 AI 来了。AI 的长处和短处和人截然相反。AI 可以读图，但既不准确又低效，而它读文字的速度和精度吊打人类。一个为人类设计的按钮菜单滑块弹窗进度条界面对 AI 来说不是辅助，而是障碍，给 AI 直接看 .json 和 .md 要快得多。Karpathy 在一条推里抱怨说：现在你去任何一家公司，他们还在用传统界面给你下指令，让你导航到某个网页，点某个按钮，在某个输入框里填某个东西，但为什么要告诉人该怎么操作？请直接给一个能复制粘贴给 AI 的东西。
换句话说，人和 AI 交互，AI 和后台交互就好了。过去四十年里人们为了伺候自己所发明的「可视化」都即将变得不那么必要。
人和 AI 交互的界面还在成型过程中。目前看起来，人向 AI 输入信息最轻松的方式还是语音和短信息，这从大多数人（包括码农）迅速接受了 Typeless 就能看出来。反方向上，AI 像人类回馈信息的方式还很原始，我们还不知道以后会是什么样。但对后台来说有一点是可以肯定的：面向人的系统设计即将大规模地转向面向 AI 的系统设计。如果你做出的任何产品只有人能用而 AI 用不了或者用不好，那在未来就意味着没有任何可用性——龙虾的眼睛即将取代人的眼睛，对龙虾不可见的世界，对人实际上也不可见。
黄仁勋说龙虾是新时代的操作系统，这句话的意义会在接下来几年逐渐更全面的展示出来。
36 119