即刻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 1620
什么时候一段口语指令就够了，什么时候值得把它固化为一个 Skill？
Matt Pocock 问了一句话："Would you guys dig a /resolve-merge-conflicts skill?"
274 个赞，30 条回复。但回复的内容不是「要！」——而是分裂成了两个阵营，吵了起来。
一边说「合并冲突 agent 自己就能解决，不需要 skill」。另一边说「我有自己的 skill，你的应该更好」。还有几个人在评论区贴了自己的 skill 链接。
这场微型争吵暴露了一个比「Skill 是什么」更根本的问题：什么时候一段口语指令就够了，什么时候值得把它固化为一个 Skill？
---
一、/resolve-merge-conflicts 到底是什么？
先回到这个 skill 本身。Matt 说得很清楚：「我有一个 prompt 已经在用了，只是还没做成 skill。」那这个 prompt 和直接说「fix the merge conflicts」有什么区别？
看了他的其他 skill 设计原则后，差别很可能是这些：
如果直接说「fix conflicts」，agent 会做它能做的——读冲突标记，判断哪个版本更新，合并，完成。这在 90% 的情况下够用。30 条回复里，至少 10 个人说「直接问就行，没失败过」。
如果一个 `/resolve-merge-conflicts` skill 做得更好，它会做什么？
1. 不只解决冲突，还理解意图。 "taking into account the recent commits and intention of each side of the conflict"（
@dabernathy89
的手写 prompt 里加了这一句——这条回复拿了 4 赞，是最高赞的回复）
2. 强制一致性。 团队里 5 个开发者各自对 agent 说「fix conflicts」，结果可能是 5 种不同的合并策略。一个标准化的 skill 强制所有人走相同的决策树。
3. 和其他 skill 组合。 resolve-conflicts → review-changes → verify-tests → commit——它不是独立的，是流水线的一环。Matt 在别处提出了「model-invocable skills vs user-invocable commands」的区分：merge-conflict 是 model 在 PR 流程中自动调用的，不是人手动输入 `/resolve-merge-conflicts`。
这就是「一段 prompt」和「一个 skill」的关键差异。不是功能差别，是可组合性和可复制性的差别。
---
二、回复中暴露的三个痛点
痛点一：Skill 是有代价的——上下文成本
@dhruvilshah009
（2 赞）：
「"this does not need a skill. Not everything needs a skill. Models today already possess a lot of knowledge internally, and adding more context simply worsens outcomes."」
这不是反 skill。这是一个工程判断：Skill 不是免费的。 每一个加载的 skill 都消耗 context window token。如果你的 `SKILL.md` 用 500 个 token 教会了 agent 一个它本来就知道的事，你实际上在降低 agent 的整体表现——context window 里的噪声变多了。Skill 的价值必须超过它的 token 成本。
痛点二：我们不知道什么该做成 Skill
@adelbucetta
：
「"we still don't know what skills to build before llms get too good at everything."」
这是 Skill 时代的灵魂拷问。我们花两周打磨一个 `/deploy` skill，GPT-6 发布后 agent 自己就能比你更懂部署。我们精心写的 `/code-review` skill，下个版本的 Claude Opus 可能已经内化了所有最佳实践。
Skill 是一种时间套利——你用今天的知识填补模型今天的缺口。但缺口在以月为单位消失。什么时候投资 skill 值得？什么时候等一等更好？没有人知道答案。
痛点三：Skill 太重了
@khepin
（1 赞）："is there a skill needed there? i've always had all the success i need with 'fix conflicts'"
这个问题换一个问法：一段 prompt 在什么阈值下值得变成一个文件？
10 个字的 prompt 显然不需要 skill。1000 个字的系统指令显然需要一个 skill 来管理。但中间的灰色地带——像 merge conflict 这种"当前 prompt 已经够用，但标准化后可能更好"的场景——正确答案是什么？
目前社区没有共识。有人直接问 agent。有人写了自己的 skill。有人用了 Cursor 团队的现成方案。有人说应该消灭合并冲突本身（trunk-based development）。
---
三、回复中揭示的四种方法
30 条回复不只是观点——每一类回复背后是一种实际的 skill 使用策略。
策略一：口语 prompt（多数派）
@dabernathy89
的 prompt 模板是代表：
「"Intelligently resolve the current merge conflicts, taking into account the recent commits and intention of each side of the conflict."」
这不是「fix conflicts」，这是一段经过打磨的口语指令。它有结构、有上下文提示、有判断标准。但它不是一个 skill。它没有文件，不跨项目复用，没有版本控制。
适用场景：当前模型已经足够好的任务。成本：每次需要手动输入，不同人输出不一致。
策略二：个人 skill（少数派）
@schrockn
：💯 I have my own but I think yours would be more thoughtful and tested.
@suny_nick
：Why don't you just /babysit-pr? I have one, and it monitors the pr until it's merged.
这些人已经自己做了 skill。但他们想要 Matt 的版本——不是因为他们做不出来，而是因为 Matt 的版本经过了更多人的测试、更多场景的打磨。Skill 的价值不只是「能用」，是「被足够多人验证过」。
策略三：复用第三方 skill
@cihadsmind
贴了 Cursor 团队的现有 merge conflict skill 链接。
@eddy_builds
分享了自己的 meta-skill 链：`/groundwork → /grill-me → /implement`——三个 skill 组成一条完整的「理解需求→审查询问→执行实现」流水线。
skill 正在从「个人工具」变成「社区资产」——和开源代码一样的 Fork → Star → 贡献循环。
策略四：消灭问题本身
@volleybau
的回复是 30 条里最激进的：
「"no. what's a conflict? why are we still not pushing things and doing trunk based?"」
在 AI 驱动的开发流程里，也许合并冲突不应该发生。如果你用 agent 做所有 feature，feature 之间不重叠，你不需要 merge——你只需要按顺序 apply。但这个思路要求整个团队的开发流程围绕 agent 重新设计。
@EightBitElon
进一步："other skills should inherently integrate this. Fully autonomous. Any human input at runtime is error." 终极愿景不是更好的 merge conflict skill——是 merge conflict 根本不应该出现在 agent 的工作流里。
---
四、Matt 自己在想什么
回看 Matt 的时间线，他其实已经在探索答案了。那条 543 赞的推文说了他最近的想法：
「"I've been feeling the itch to divide my skills repo into two kinds: Model-invocable skills (skills) and User-invocable skills (commands)"」
`/resolve-merge-conflicts` 在 Matt 的设计里不是给你手动输入的。它是 model-invocable skill——agent 在处理 PR 时自动调用。你不需要知道冲突发生了。agent 检测到冲突 → 加载 merge-conflict skill → 解决 → 继续。
这就是为什么回复里有人说「不需要，agent 自己会做」而同时有人想要它——前者说的是今天（人手动触发 agent），后者说的是明天（agent 自动编排 skill）。
---
五、结论：Skill 的边界在「可组合性」
回到那个核心问题：什么时候一段 prompt 值得变成一个 skill？
从这篇讨论里提炼出的答案不是「功能复杂度」或「token 长度」。而是可组合性。
如果一个 prompt 只是你一次性扔给 agent 的指令——不需要 skill。如果它是 agent 需要在不同上下文里反复调用、和其他 skill 串联、被团队复用的能力——那就值得固化。
`/resolve-merge-conflicts` 之所以让社区分裂，是因为它在边界上。今天 merge conflict 用一个口语 prompt 解决得很好。但明天——当 agent 自动跑 PR 流水线，当你需要它和 review、test、deploy skill 串联——一个独立的 prompt 就不够了。
Skill 的真正价值不在「教 agent 怎么做」。在「让 agent 能在看不见你的时候，自己做。」
---
*参考来源：Matt Pocock X 推文及 30 条回复 (2026.06)；mattpocock/skills GitHub (48K+ stars)；Anthropic Engineering Blog "Equipping agents with Agent Skills"；Barry Zhang & Mahesh Murag AI Engineer Code Summit talk*
Matt Pocock 问了一句话："Would you guys dig a /resolve-merge-conflicts skill?"
274 个赞，30 条回复。但回复的内容不是「要！」——而是分裂成了两个阵营，吵了起来。
一边说「合并冲突 agent 自己就能解决，不需要 skill」。另一边说「我有自己的 skill，你的应该更好」。还有几个人在评论区贴了自己的 skill 链接。
这场微型争吵暴露了一个比「Skill 是什么」更根本的问题：什么时候一段口语指令就够了，什么时候值得把它固化为一个 Skill？
---
一、/resolve-merge-conflicts 到底是什么？
先回到这个 skill 本身。Matt 说得很清楚：「我有一个 prompt 已经在用了，只是还没做成 skill。」那这个 prompt 和直接说「fix the merge conflicts」有什么区别？
看了他的其他 skill 设计原则后，差别很可能是这些：
如果直接说「fix conflicts」，agent 会做它能做的——读冲突标记，判断哪个版本更新，合并，完成。这在 90% 的情况下够用。30 条回复里，至少 10 个人说「直接问就行，没失败过」。
如果一个 `/resolve-merge-conflicts` skill 做得更好，它会做什么？
1. 不只解决冲突，还理解意图。 "taking into account the recent commits and intention of each side of the conflict"（
@dabernathy89
的手写 prompt 里加了这一句——这条回复拿了 4 赞，是最高赞的回复）
2. 强制一致性。 团队里 5 个开发者各自对 agent 说「fix conflicts」，结果可能是 5 种不同的合并策略。一个标准化的 skill 强制所有人走相同的决策树。
3. 和其他 skill 组合。 resolve-conflicts → review-changes → verify-tests → commit——它不是独立的，是流水线的一环。Matt 在别处提出了「model-invocable skills vs user-invocable commands」的区分：merge-conflict 是 model 在 PR 流程中自动调用的，不是人手动输入 `/resolve-merge-conflicts`。
这就是「一段 prompt」和「一个 skill」的关键差异。不是功能差别，是可组合性和可复制性的差别。
---
二、回复中暴露的三个痛点
痛点一：Skill 是有代价的——上下文成本
@dhruvilshah009
（2 赞）：
「"this does not need a skill. Not everything needs a skill. Models today already possess a lot of knowledge internally, and adding more context simply worsens outcomes."」
这不是反 skill。这是一个工程判断：Skill 不是免费的。 每一个加载的 skill 都消耗 context window token。如果你的 `SKILL.md` 用 500 个 token 教会了 agent 一个它本来就知道的事，你实际上在降低 agent 的整体表现——context window 里的噪声变多了。Skill 的价值必须超过它的 token 成本。
痛点二：我们不知道什么该做成 Skill
@adelbucetta
：
「"we still don't know what skills to build before llms get too good at everything."」
这是 Skill 时代的灵魂拷问。我们花两周打磨一个 `/deploy` skill，GPT-6 发布后 agent 自己就能比你更懂部署。我们精心写的 `/code-review` skill，下个版本的 Claude Opus 可能已经内化了所有最佳实践。
Skill 是一种时间套利——你用今天的知识填补模型今天的缺口。但缺口在以月为单位消失。什么时候投资 skill 值得？什么时候等一等更好？没有人知道答案。
痛点三：Skill 太重了
@khepin
（1 赞）："is there a skill needed there? i've always had all the success i need with 'fix conflicts'"
这个问题换一个问法：一段 prompt 在什么阈值下值得变成一个文件？
10 个字的 prompt 显然不需要 skill。1000 个字的系统指令显然需要一个 skill 来管理。但中间的灰色地带——像 merge conflict 这种"当前 prompt 已经够用，但标准化后可能更好"的场景——正确答案是什么？
目前社区没有共识。有人直接问 agent。有人写了自己的 skill。有人用了 Cursor 团队的现成方案。有人说应该消灭合并冲突本身（trunk-based development）。
---
三、回复中揭示的四种方法
30 条回复不只是观点——每一类回复背后是一种实际的 skill 使用策略。
策略一：口语 prompt（多数派）
@dabernathy89
的 prompt 模板是代表：
「"Intelligently resolve the current merge conflicts, taking into account the recent commits and intention of each side of the conflict."」
这不是「fix conflicts」，这是一段经过打磨的口语指令。它有结构、有上下文提示、有判断标准。但它不是一个 skill。它没有文件，不跨项目复用，没有版本控制。
适用场景：当前模型已经足够好的任务。成本：每次需要手动输入，不同人输出不一致。
策略二：个人 skill（少数派）
@schrockn
：💯 I have my own but I think yours would be more thoughtful and tested.
@suny_nick
：Why don't you just /babysit-pr? I have one, and it monitors the pr until it's merged.
这些人已经自己做了 skill。但他们想要 Matt 的版本——不是因为他们做不出来，而是因为 Matt 的版本经过了更多人的测试、更多场景的打磨。Skill 的价值不只是「能用」，是「被足够多人验证过」。
策略三：复用第三方 skill
@cihadsmind
贴了 Cursor 团队的现有 merge conflict skill 链接。
@eddy_builds
分享了自己的 meta-skill 链：`/groundwork → /grill-me → /implement`——三个 skill 组成一条完整的「理解需求→审查询问→执行实现」流水线。
skill 正在从「个人工具」变成「社区资产」——和开源代码一样的 Fork → Star → 贡献循环。
策略四：消灭问题本身
@volleybau
的回复是 30 条里最激进的：
「"no. what's a conflict? why are we still not pushing things and doing trunk based?"」
在 AI 驱动的开发流程里，也许合并冲突不应该发生。如果你用 agent 做所有 feature，feature 之间不重叠，你不需要 merge——你只需要按顺序 apply。但这个思路要求整个团队的开发流程围绕 agent 重新设计。
@EightBitElon
进一步："other skills should inherently integrate this. Fully autonomous. Any human input at runtime is error." 终极愿景不是更好的 merge conflict skill——是 merge conflict 根本不应该出现在 agent 的工作流里。
---
四、Matt 自己在想什么
回看 Matt 的时间线，他其实已经在探索答案了。那条 543 赞的推文说了他最近的想法：
「"I've been feeling the itch to divide my skills repo into two kinds: Model-invocable skills (skills) and User-invocable skills (commands)"」
`/resolve-merge-conflicts` 在 Matt 的设计里不是给你手动输入的。它是 model-invocable skill——agent 在处理 PR 时自动调用。你不需要知道冲突发生了。agent 检测到冲突 → 加载 merge-conflict skill → 解决 → 继续。
这就是为什么回复里有人说「不需要，agent 自己会做」而同时有人想要它——前者说的是今天（人手动触发 agent），后者说的是明天（agent 自动编排 skill）。
---
五、结论：Skill 的边界在「可组合性」
回到那个核心问题：什么时候一段 prompt 值得变成一个 skill？
从这篇讨论里提炼出的答案不是「功能复杂度」或「token 长度」。而是可组合性。
如果一个 prompt 只是你一次性扔给 agent 的指令——不需要 skill。如果它是 agent 需要在不同上下文里反复调用、和其他 skill 串联、被团队复用的能力——那就值得固化。
`/resolve-merge-conflicts` 之所以让社区分裂，是因为它在边界上。今天 merge conflict 用一个口语 prompt 解决得很好。但明天——当 agent 自动跑 PR 流水线，当你需要它和 review、test、deploy skill 串联——一个独立的 prompt 就不够了。
Skill 的真正价值不在「教 agent 怎么做」。在「让 agent 能在看不见你的时候，自己做。」
---
*参考来源：Matt Pocock X 推文及 30 条回复 (2026.06)；mattpocock/skills GitHub (48K+ stars)；Anthropic Engineering Blog "Equipping agents with Agent Skills"；Barry Zhang & Mahesh Murag AI Engineer Code Summit talk*
2 00
Search as Code 背后的设计哲学：Agent 交互范式的哥白尼革命
---
Perplexity 的 Search as Code（SaC）表面上是一个产品发布——搜索架构从 function calling 切换到代码生成。但我越读越觉得，它的理论意义比产品意义更大。
SaC 不是一个更好的 function calling。它在定义另一套 agent 设计范式。这套范式还没有正式的名字，但它的四个核心原则已经清晰得令人兴奋。
---
一、接口不是给人设计的，是给 AI 设计的
这是最根本的转向。
搜索引擎的第一批用户是人类。人类要什么？输入一个查询，看到一页链接，点第一个蓝的。这个模式有效了二十年，以至于所有「AI 搜索」产品——包括 Perplexity 自己早期的版本——都在这个框架上叠加 LLM 层。你搜，它读，它回答。
但 SaC 做了件反直觉的事：它不把 AI 当成另一种「用户」。AI 不是一个更快的人类读者。AI 是一个可以通过代码表达精确搜索策略、并行执行数百次检索、然后只消费其中最相关的几条信息的实体。
这要求完全不同的设计原则：
| 人类用户 | AI Agent |
|---------|----------|
| 想要简洁的 UI | 想要可组合的原语 |
| 点一两个链接就够了 | 可能需要上千次检索 |
| 无法表达「怎么搜」 | 可以通过代码精确表达 |
| 需要预设的 pipeline | 需要运行时组装的 pipeline |
| 人适应工具 | 工具适应 agent |
理论意义：我们正在进入一个「AI-native 基础设施」的时代。不是把给人类用的工具加一个 LLM wrapper，而是从零为 AI agent 设计计算原语。这相当于从「把汽车装个马鞍」进化到「为引擎设计轮胎」。
---
二、从「工具调用」到「编程」：交互范式的哥白尼革命
过去两年，整个行业在说同一句话：「给 AI 工具。」OpenAI 做了 function calling，Anthropic 做了 MCP，Google 做了 Tool Use。核心假设是同一个：AI 是工具的使用者，我们给它定义好的工具，它按需调用。
SaC 说：不要给工具，给编程语言。
这不是修辞。两者有本质差异：
工具（function calling）的边界是预设的。 search(query, filters) 能做什么取决于谁写了这个函数、在什么抽象层级上写的。如果函数不支持「只搜厂商公告，排除 NVD 和 MITRE」，模型只能在自己的 token 空间里做过滤——昂贵、不精确、污染上下文。
编程语言的边界是无限的。 模型拿到的是 SDK（一组原子原语：检索、排序、过滤、去重、fan-out），然后用 Python 自由组合。同一个 SDK，不同任务可以组装出完全不同的搜索流水线。不存在「这个不支持」的问题——写代码就行了。
这其实是一次「哥白尼革命」式的视角转换。不是 AI 围绕工具的接口适应自己，而是工具把自己的原子原语暴露给 AI，让 AI 通过编程来定义交互方式。
理论意义：最好的 agent 接口不是一个精心设计的 function schema。最好的 agent 接口是一组原子原语 + 一个代码运行时。接口本身变成了一门「语言」。
---
三、「代码即接口」：最好的 API 是没有 API
这是上一个原则的必然推论。
传统 API 是「我有一个能力，你调这个 endpoint」。API 的设计者决定了调用方式、参数结构、返回格式。API 使用者只能在这个边界内工作。
SaC 的 SDK 不是传统意义上的 API。它是一堆积木。模型通过代码任意组合积木。接口不再是 function signature，接口就是 Python 代码本身。
为什么这很重要？因为传统 API 抽象层级由人决定，但 AI agent 需要的抽象层级因任务而异。同一个 Agentic Search SDK，对于简单的信息检索任务，模型可能只调几个高层 endpoint。对于复杂的 CVE 分析任务，模型会深入到原子原语层级，自己实现查询计划、去重逻辑和结果验证。
理论意义：未来 agent 基础设施的竞争不是「谁提供了更好用的 function schema」。而是「谁的原语拆得更原子、更可组合、更利于代码编排」。接口设计的重心从「定义 function」转移到「定义原语」。
---
四、确定性计算回归：AI 不需要什么都「推理」
这是 SaC 最被低估的一条设计决策。
Agent 系统有一个普遍倾向：把所有操作都扔进 token 空间让 LLM「推理」。过滤结果？LLM 推理。去重？LLM 推理。验证一致性？LLM 推理。
但 LLM 在这些任务上天然劣势：昂贵、不精确、上下文膨胀。一个简单的字符串匹配在 Python 里是一行代码、零 token 成本的事。在 GPT 5.5 的 token 空间里，它需要消耗上下文窗口、推理时间和金钱。
SaC 的设计把这种「本不该 LLM 做的事」坚决地从 token 空间移到了沙箱里：
- 过滤 → Python if 语句
- 去重 → Python set
- 验证 → Python 函数
- 聚合 → Python groupby
- 排序 → Python sorted
而 LLM 只做它最擅长的事：理解模糊需求、设计检索策略、判断结果的相关性和质量。
理论意义：好的 agent 架构不要求 LLM 做所有事。它让 LLM 做「推理」，让代码做「计算」。两者的边界应该由设计者主动划定，而不是让 LLM 在 token 空间里自己摸索。
---
五、SDK 通过 autoresearch 自进化：元工具也必须是 AI 原生
这是 meta 层面最让我兴奋的一条。
Perplexity 没有手工设计 Agentic Search SDK。他们建了一个 autoresearch 循环，连续运行数周，自动提出和验证 SDK 的改进。衡量的不是某种审美偏好，而是硬指标：延迟、代码生成质量、任务完成率。
这意味着什么？构建 AI agent 基础原语的工具本身，也必须是 AI 原生的。
手工设计的 SDK 会带有人的认知偏见：你觉得这个函数名好懂、这个参数结构合理、这个抽象层级合适。但 AI 是另一个物种。它在 .py 文件里的「可消费性」和在 .md 文件里的人类可读性不是同一个东西。
autoresearch 循环持续把「AI 实际上怎么用这个 SDK」的信号反馈回设计本身。这形成了一个自我优化的闭环：SDK 进化 → agent 更好用 → 更多使用数据 → SDK 再进化。
理论意义：这为「AI-native 基础设施」下了最终定义——不只是给 AI 设计的，还是由 AI 参与设计的。
---
六、总结：一套新范式的轮廓
把这些原则串起来，就是一套完整的 agent 设计范式：
1. 原语层 — 把系统能力拆成可组合的原子积木（不是 function schema，是 SDK）
2. 编排层 — 模型通过代码自由组合原语（不是 tool calling，是 programming）
3. 执行层 — 确定性计算在沙箱里完成，LLM 只做推理
4. 进化层 — SDK 本身通过 AI 自优化（不是人手工迭代，是 autoresearch 闭环）
这套范式和 Claude Code 动态工作流在精神上一脉相承——都是放弃「预设接口」，拥抱「运行时代码编排」。但它们解决的是不同层面的问题：动态工作流解决的是 agent 内部的子任务调度，SaC 解决的是 agent 和外部基础设施（搜索）的交互。
两者合在一起，指向同一个未来：
「Agent 不是工具的使用者。Agent 是基础设施的编程者。」
这不是一个产品改进，这是一个理论框架。我们正在从「给 AI 定义工具」的时代，进入「给 AI 定义原语，让它自己编程」的时代。
---
参考：Perplexity Research, "Rethinking Search for Agents: Search as Code" (2026.06)
---
Perplexity 的 Search as Code（SaC）表面上是一个产品发布——搜索架构从 function calling 切换到代码生成。但我越读越觉得，它的理论意义比产品意义更大。
SaC 不是一个更好的 function calling。它在定义另一套 agent 设计范式。这套范式还没有正式的名字，但它的四个核心原则已经清晰得令人兴奋。
---
一、接口不是给人设计的，是给 AI 设计的
这是最根本的转向。
搜索引擎的第一批用户是人类。人类要什么？输入一个查询，看到一页链接，点第一个蓝的。这个模式有效了二十年，以至于所有「AI 搜索」产品——包括 Perplexity 自己早期的版本——都在这个框架上叠加 LLM 层。你搜，它读，它回答。
但 SaC 做了件反直觉的事：它不把 AI 当成另一种「用户」。AI 不是一个更快的人类读者。AI 是一个可以通过代码表达精确搜索策略、并行执行数百次检索、然后只消费其中最相关的几条信息的实体。
这要求完全不同的设计原则：
| 人类用户 | AI Agent |
|---------|----------|
| 想要简洁的 UI | 想要可组合的原语 |
| 点一两个链接就够了 | 可能需要上千次检索 |
| 无法表达「怎么搜」 | 可以通过代码精确表达 |
| 需要预设的 pipeline | 需要运行时组装的 pipeline |
| 人适应工具 | 工具适应 agent |
理论意义：我们正在进入一个「AI-native 基础设施」的时代。不是把给人类用的工具加一个 LLM wrapper，而是从零为 AI agent 设计计算原语。这相当于从「把汽车装个马鞍」进化到「为引擎设计轮胎」。
---
二、从「工具调用」到「编程」：交互范式的哥白尼革命
过去两年，整个行业在说同一句话：「给 AI 工具。」OpenAI 做了 function calling，Anthropic 做了 MCP，Google 做了 Tool Use。核心假设是同一个：AI 是工具的使用者，我们给它定义好的工具，它按需调用。
SaC 说：不要给工具，给编程语言。
这不是修辞。两者有本质差异：
工具（function calling）的边界是预设的。 search(query, filters) 能做什么取决于谁写了这个函数、在什么抽象层级上写的。如果函数不支持「只搜厂商公告，排除 NVD 和 MITRE」，模型只能在自己的 token 空间里做过滤——昂贵、不精确、污染上下文。
编程语言的边界是无限的。 模型拿到的是 SDK（一组原子原语：检索、排序、过滤、去重、fan-out），然后用 Python 自由组合。同一个 SDK，不同任务可以组装出完全不同的搜索流水线。不存在「这个不支持」的问题——写代码就行了。
这其实是一次「哥白尼革命」式的视角转换。不是 AI 围绕工具的接口适应自己，而是工具把自己的原子原语暴露给 AI，让 AI 通过编程来定义交互方式。
理论意义：最好的 agent 接口不是一个精心设计的 function schema。最好的 agent 接口是一组原子原语 + 一个代码运行时。接口本身变成了一门「语言」。
---
三、「代码即接口」：最好的 API 是没有 API
这是上一个原则的必然推论。
传统 API 是「我有一个能力，你调这个 endpoint」。API 的设计者决定了调用方式、参数结构、返回格式。API 使用者只能在这个边界内工作。
SaC 的 SDK 不是传统意义上的 API。它是一堆积木。模型通过代码任意组合积木。接口不再是 function signature，接口就是 Python 代码本身。
为什么这很重要？因为传统 API 抽象层级由人决定，但 AI agent 需要的抽象层级因任务而异。同一个 Agentic Search SDK，对于简单的信息检索任务，模型可能只调几个高层 endpoint。对于复杂的 CVE 分析任务，模型会深入到原子原语层级，自己实现查询计划、去重逻辑和结果验证。
理论意义：未来 agent 基础设施的竞争不是「谁提供了更好用的 function schema」。而是「谁的原语拆得更原子、更可组合、更利于代码编排」。接口设计的重心从「定义 function」转移到「定义原语」。
---
四、确定性计算回归：AI 不需要什么都「推理」
这是 SaC 最被低估的一条设计决策。
Agent 系统有一个普遍倾向：把所有操作都扔进 token 空间让 LLM「推理」。过滤结果？LLM 推理。去重？LLM 推理。验证一致性？LLM 推理。
但 LLM 在这些任务上天然劣势：昂贵、不精确、上下文膨胀。一个简单的字符串匹配在 Python 里是一行代码、零 token 成本的事。在 GPT 5.5 的 token 空间里，它需要消耗上下文窗口、推理时间和金钱。
SaC 的设计把这种「本不该 LLM 做的事」坚决地从 token 空间移到了沙箱里：
- 过滤 → Python if 语句
- 去重 → Python set
- 验证 → Python 函数
- 聚合 → Python groupby
- 排序 → Python sorted
而 LLM 只做它最擅长的事：理解模糊需求、设计检索策略、判断结果的相关性和质量。
理论意义：好的 agent 架构不要求 LLM 做所有事。它让 LLM 做「推理」，让代码做「计算」。两者的边界应该由设计者主动划定，而不是让 LLM 在 token 空间里自己摸索。
---
五、SDK 通过 autoresearch 自进化：元工具也必须是 AI 原生
这是 meta 层面最让我兴奋的一条。
Perplexity 没有手工设计 Agentic Search SDK。他们建了一个 autoresearch 循环，连续运行数周，自动提出和验证 SDK 的改进。衡量的不是某种审美偏好，而是硬指标：延迟、代码生成质量、任务完成率。
这意味着什么？构建 AI agent 基础原语的工具本身，也必须是 AI 原生的。
手工设计的 SDK 会带有人的认知偏见：你觉得这个函数名好懂、这个参数结构合理、这个抽象层级合适。但 AI 是另一个物种。它在 .py 文件里的「可消费性」和在 .md 文件里的人类可读性不是同一个东西。
autoresearch 循环持续把「AI 实际上怎么用这个 SDK」的信号反馈回设计本身。这形成了一个自我优化的闭环：SDK 进化 → agent 更好用 → 更多使用数据 → SDK 再进化。
理论意义：这为「AI-native 基础设施」下了最终定义——不只是给 AI 设计的，还是由 AI 参与设计的。
---
六、总结：一套新范式的轮廓
把这些原则串起来，就是一套完整的 agent 设计范式：
1. 原语层 — 把系统能力拆成可组合的原子积木（不是 function schema，是 SDK）
2. 编排层 — 模型通过代码自由组合原语（不是 tool calling，是 programming）
3. 执行层 — 确定性计算在沙箱里完成，LLM 只做推理
4. 进化层 — SDK 本身通过 AI 自优化（不是人手工迭代，是 autoresearch 闭环）
这套范式和 Claude Code 动态工作流在精神上一脉相承——都是放弃「预设接口」，拥抱「运行时代码编排」。但它们解决的是不同层面的问题：动态工作流解决的是 agent 内部的子任务调度，SaC 解决的是 agent 和外部基础设施（搜索）的交互。
两者合在一起，指向同一个未来：
「Agent 不是工具的使用者。Agent 是基础设施的编程者。」
这不是一个产品改进，这是一个理论框架。我们正在从「给 AI 定义工具」的时代，进入「给 AI 定义原语，让它自己编程」的时代。
---
参考：Perplexity Research, "Rethinking Search for Agents: Search as Code" (2026.06)
4 00
用 Codex + GPT-5.5 处理 UI 和 交互上的细节，忙活一天，仅仅改了几处，其它时间都在等它「thinking...」，妈的，怒从心起，忍无可忍。
马上换到 Pi + DeepSeek-V4-Pro，说啥改啥，一点都不过度思考。
真好用，真快，真清爽！
马上换到 Pi + DeepSeek-V4-Pro，说啥改啥，一点都不过度思考。
真好用，真快，真清爽！
16 101
感谢 @瑜伽姐的斜杠人生 在播客中对我的采访，在本期播客中，瑜伽姐通过反复提问，让我畅快淋漓地分享了：
- 我与 AI 共同协作的经历
- 企业、组织与 AI 协作中的一些需要注意的地方
希望这期访谈的内容有提供到价值给大家！
播客地址： www.xiaoyuzhoufm.com
- 我与 AI 共同协作的经历
- 企业、组织与 AI 协作中的一些需要注意的地方
希望这期访谈的内容有提供到价值给大家！
播客地址： www.xiaoyuzhoufm.com
3 20
AI 正在批量生产不会思考的人
上周，Brilliant 创始人 Sue Khim 发了一个产品，首日 410 万观看。产品叫 Koji，全球首个图形化 AI 私教——MIT 和哈佛训练，十一年的学生交互数据喂养，能"看见"你屏幕上的每个互动组件，直接在上面画线、高亮、拖拽图形来讲解。
设计哲学是：不给答案。
在这个所有 AI 产品都在比"谁的答案更准、更快、更全"的时代，一个由顶级学术团队打造的产品，选择了限制自己的能力。
听起来反常识。但过去两年的随机对照实验正在给出同一个结论：给答案的 AI，在帮学生完成作业的同时，正在摧毁他们的学习能力。
2025 年 PNAS 发表的 Bastani 实验是其中最硬的一个。近千名土耳其高中生随机分三组复习数学：一组用通用 ChatGPT（随便问，给完整解答），一组用辅导型 AI（只给提示不给答案），一组用传统教科书。练习阶段，ChatGPT 组成绩最好——这不意外，AI 在替他们做题。但到闭卷考试，ChatGPT 组的成绩比教科书组还差一截。辅导型 AI 组与教科书组持平。论文原话："Generative AI can harm learning when it provides direct answers."
MIT Media Lab 同年做了更底层的研究：脑电图显示，用 ChatGPT 辅助写作的学生，大脑中负责深度加工的神经连接显著减少。更少的神经激活等于更少的学习。哥本哈根大学 Makransky 团队的 ChatTutor 实验（175 名大学生 + 234 名高中生，2025 年发表于 Educational Psychology Review）进一步证实：基于学习理论设计的苏格拉底式反问 AI，在学习效果、使用愉悦感和复用意愿三个维度上都显著优于 ChatGPT。
以上实验证明：给答案的 AI 是一种认知拐杖——撤掉就摔。不给答案的 AI 是一种认知训练——慢，但有效。
但问题不止于此。更深层的问题是：过去三十年，ed-tech 的核心叙事一直是"用技术实现学生端的个性化"。1990 年代的电脑辅助教学给学生不同练习题，2010 年代的自适应平台给学生不同学习路径，2020 年代的 AI 导师给学生不同讲解。假设都是同一个——"如果我能更精确地照顾每个学生，教育就变好"。
这个假设被大规模实证击穿了。
Hattie 分析 1200 多项教育研究、195 个影响因素后发现：一对一辅导的效应量是 0.58-0.60，而精心设计的大班教学（Direct Instruction）效应量是 0.59——几乎一样。班级人数从 40 人缩到 20 人，效应量只有 0.21，连"有意义"的门槛（0.4）都没到。真正巨大的杠杆是反馈质量（0.7+）和课的设计质量。
美国教育史上最大的教学对比实验 Project Follow Through（1967-1977，覆盖七万多名低收入家庭学生，对比九种教学法）的结果更震撼：高度结构化的集体教学法在基础技能、认知能力、情感发展三个维度上全部排名第一。开放式教育法被认为更能激发自主性，但在情感发展上也没超过它。
上海 48 人的班级在 PISA 中数学、阅读、科学三项全球第一。他们有的不是个体化关注，而是教研组花几周打磨一节课，轮流上课、互相观察、反复迭代——日本管这叫 Lesson Study，有一个多世纪的传统。
Wisconsin-La Crosse 大学 2025 年的 Macro Buddy 实验给出了一个更细腻的发现。他们在经济学课程中部署了"不给答案"的 AI 导师，搭配同伴讨论。第二场考试时各组没有显著差异，到第三场考试——引入 AI 几周以后——差异才拉出来。"不给答案"的学习效果是积累性的，不会立刻在成绩上体现，但会随时间加深。这和东京大学 2025 年的警告形成呼应："通用聊天机器人提供了现成的答案，可能导致学生的认知卸载。"认知卸载——你不再思考，因为你不需要。
现实世界也在投票。Dallas ISD 取消了 Khanmigo 的合同。Iowa 大学试点后正式建议不推广。Michigan Virtual 在 1102 名学生中试点，使用频率不到每周一次。这些不是缺乏预算或技术问题——是学生直觉地知道：一个只会给答案的东西，用几次就腻了。真正能留住学生的是那种"让我自己想出来"的满足感。
结论是反直觉的：与其让 AI 尝试同时照顾 40 个不同的学生，不如让 AI 帮老师把一节课设计到足够好，好到它同时对 40 个不同学生起作用。前者的瓶颈是老师的认知带宽（线性），后者的杠杆是课的设计质量（指数级）。Koji 的"不给答案"设计因此有了更深层含义：它不是"给学生端的个性化"，而是一套经过精心设计的、可复用的教学交互模式——一种"课的设计"，而非"学生的回答机器"。
当然，必须承认反方证据。
德国 IZA 研究所 2025 年发布的随机实验（334 名大学生，有激励的考试）得出了不同结论：AI 导师将考试成绩提高了 0.23 个标准差，而且无限制访问组（可以随时用 AI）显著优于限制访问组（必须先独立阅读才能用 AI）。一种解释是大学生和高中生的元认知水平不同——高年级学生被 AI 给出答案后能意识到自己没掌握，主动回溯学习。这提醒我们："不给答案"的设计需要匹配学生的元认知水平，一刀切的"永远不给"可能在某些场景适得其反。
另一组反方证据更根本：Bastani 实验中，辅导型 AI 在闭卷考试中的成绩仅仅是"与教科书组持平"，没有更好。如果做得最好的方案也只是"不伤害学习"，那投入 AI 辅导的巨额成本是否值得？Hattie 的元分析告诉我们，提高反馈质量（效应量 0.7+）和改善课的设计（效应量 0.59）可能是更高效的资源投向。
但这不是非此即彼的选择。Koji 真正的启示在于：当我们不再让 AI 和学生的大脑赛跑，而是让 AI 成为一个苏格拉底——追问、引导、画线、高亮、让你自己走到答案面前——AI 就从"认知拐杖"变成了"认知健身房"。一个让你暂时省力的工具，和一个让你长期变强的工具，是两种完全不同的东西。
教育 AI 的方向盘正在打向一个分岔口。左边是"更准、更快、更全的答案"——所有主流产品都在冲的同一堵墙。右边是"更深的追问、更久的困惑、更强的思维"——需要克制、需要设计、短期内看不到留存数据。左边是让学生依赖，右边是让学生离开你之后依然能思考。
这可能是 AI 教育十年内最重要的产品决策。不是技术能力的决策，而是设计哲学的决策：你究竟是想让学生离不开你，还是想让他们不需要你？
AI 应该让你的孩子变聪明，还是变懒？答案取决于它给不给答案。
参考来源：
• Bastani et al., "Generative AI Can Harm Learning," PNAS, 2025
• MIT Media Lab, EEG study on ChatGPT-assisted writing, 2025
• Makransky et al., ChatTutor vs ChatGPT, Educational Psychology Review, 2025
• Hattie, Visible Learning meta-analysis (1200+ studies, 195 factors)
• Project Follow Through (1967-1977), 70,000+ students, 9 teaching methods
• Shanghai PISA results / Lesson Study tradition
• Macro Buddy experiment, Wisconsin-La Crosse, 2025
• Dallas ISD cancels Khanmigo / Iowa University pilot / Michigan Virtual (1102 students)
• IZA Institute, randomized experiment with 334 university students, 2025
• Tokyo University, cognitive offloading warning, 2025
• Koji by Brilliant / Sue Khim, product launch data
上周，Brilliant 创始人 Sue Khim 发了一个产品，首日 410 万观看。产品叫 Koji，全球首个图形化 AI 私教——MIT 和哈佛训练，十一年的学生交互数据喂养，能"看见"你屏幕上的每个互动组件，直接在上面画线、高亮、拖拽图形来讲解。
设计哲学是：不给答案。
在这个所有 AI 产品都在比"谁的答案更准、更快、更全"的时代，一个由顶级学术团队打造的产品，选择了限制自己的能力。
听起来反常识。但过去两年的随机对照实验正在给出同一个结论：给答案的 AI，在帮学生完成作业的同时，正在摧毁他们的学习能力。
2025 年 PNAS 发表的 Bastani 实验是其中最硬的一个。近千名土耳其高中生随机分三组复习数学：一组用通用 ChatGPT（随便问，给完整解答），一组用辅导型 AI（只给提示不给答案），一组用传统教科书。练习阶段，ChatGPT 组成绩最好——这不意外，AI 在替他们做题。但到闭卷考试，ChatGPT 组的成绩比教科书组还差一截。辅导型 AI 组与教科书组持平。论文原话："Generative AI can harm learning when it provides direct answers."
MIT Media Lab 同年做了更底层的研究：脑电图显示，用 ChatGPT 辅助写作的学生，大脑中负责深度加工的神经连接显著减少。更少的神经激活等于更少的学习。哥本哈根大学 Makransky 团队的 ChatTutor 实验（175 名大学生 + 234 名高中生，2025 年发表于 Educational Psychology Review）进一步证实：基于学习理论设计的苏格拉底式反问 AI，在学习效果、使用愉悦感和复用意愿三个维度上都显著优于 ChatGPT。
以上实验证明：给答案的 AI 是一种认知拐杖——撤掉就摔。不给答案的 AI 是一种认知训练——慢，但有效。
但问题不止于此。更深层的问题是：过去三十年，ed-tech 的核心叙事一直是"用技术实现学生端的个性化"。1990 年代的电脑辅助教学给学生不同练习题，2010 年代的自适应平台给学生不同学习路径，2020 年代的 AI 导师给学生不同讲解。假设都是同一个——"如果我能更精确地照顾每个学生，教育就变好"。
这个假设被大规模实证击穿了。
Hattie 分析 1200 多项教育研究、195 个影响因素后发现：一对一辅导的效应量是 0.58-0.60，而精心设计的大班教学（Direct Instruction）效应量是 0.59——几乎一样。班级人数从 40 人缩到 20 人，效应量只有 0.21，连"有意义"的门槛（0.4）都没到。真正巨大的杠杆是反馈质量（0.7+）和课的设计质量。
美国教育史上最大的教学对比实验 Project Follow Through（1967-1977，覆盖七万多名低收入家庭学生，对比九种教学法）的结果更震撼：高度结构化的集体教学法在基础技能、认知能力、情感发展三个维度上全部排名第一。开放式教育法被认为更能激发自主性，但在情感发展上也没超过它。
上海 48 人的班级在 PISA 中数学、阅读、科学三项全球第一。他们有的不是个体化关注，而是教研组花几周打磨一节课，轮流上课、互相观察、反复迭代——日本管这叫 Lesson Study，有一个多世纪的传统。
Wisconsin-La Crosse 大学 2025 年的 Macro Buddy 实验给出了一个更细腻的发现。他们在经济学课程中部署了"不给答案"的 AI 导师，搭配同伴讨论。第二场考试时各组没有显著差异，到第三场考试——引入 AI 几周以后——差异才拉出来。"不给答案"的学习效果是积累性的，不会立刻在成绩上体现，但会随时间加深。这和东京大学 2025 年的警告形成呼应："通用聊天机器人提供了现成的答案，可能导致学生的认知卸载。"认知卸载——你不再思考，因为你不需要。
现实世界也在投票。Dallas ISD 取消了 Khanmigo 的合同。Iowa 大学试点后正式建议不推广。Michigan Virtual 在 1102 名学生中试点，使用频率不到每周一次。这些不是缺乏预算或技术问题——是学生直觉地知道：一个只会给答案的东西，用几次就腻了。真正能留住学生的是那种"让我自己想出来"的满足感。
结论是反直觉的：与其让 AI 尝试同时照顾 40 个不同的学生，不如让 AI 帮老师把一节课设计到足够好，好到它同时对 40 个不同学生起作用。前者的瓶颈是老师的认知带宽（线性），后者的杠杆是课的设计质量（指数级）。Koji 的"不给答案"设计因此有了更深层含义：它不是"给学生端的个性化"，而是一套经过精心设计的、可复用的教学交互模式——一种"课的设计"，而非"学生的回答机器"。
当然，必须承认反方证据。
德国 IZA 研究所 2025 年发布的随机实验（334 名大学生，有激励的考试）得出了不同结论：AI 导师将考试成绩提高了 0.23 个标准差，而且无限制访问组（可以随时用 AI）显著优于限制访问组（必须先独立阅读才能用 AI）。一种解释是大学生和高中生的元认知水平不同——高年级学生被 AI 给出答案后能意识到自己没掌握，主动回溯学习。这提醒我们："不给答案"的设计需要匹配学生的元认知水平，一刀切的"永远不给"可能在某些场景适得其反。
另一组反方证据更根本：Bastani 实验中，辅导型 AI 在闭卷考试中的成绩仅仅是"与教科书组持平"，没有更好。如果做得最好的方案也只是"不伤害学习"，那投入 AI 辅导的巨额成本是否值得？Hattie 的元分析告诉我们，提高反馈质量（效应量 0.7+）和改善课的设计（效应量 0.59）可能是更高效的资源投向。
但这不是非此即彼的选择。Koji 真正的启示在于：当我们不再让 AI 和学生的大脑赛跑，而是让 AI 成为一个苏格拉底——追问、引导、画线、高亮、让你自己走到答案面前——AI 就从"认知拐杖"变成了"认知健身房"。一个让你暂时省力的工具，和一个让你长期变强的工具，是两种完全不同的东西。
教育 AI 的方向盘正在打向一个分岔口。左边是"更准、更快、更全的答案"——所有主流产品都在冲的同一堵墙。右边是"更深的追问、更久的困惑、更强的思维"——需要克制、需要设计、短期内看不到留存数据。左边是让学生依赖，右边是让学生离开你之后依然能思考。
这可能是 AI 教育十年内最重要的产品决策。不是技术能力的决策，而是设计哲学的决策：你究竟是想让学生离不开你，还是想让他们不需要你？
AI 应该让你的孩子变聪明，还是变懒？答案取决于它给不给答案。
参考来源：
• Bastani et al., "Generative AI Can Harm Learning," PNAS, 2025
• MIT Media Lab, EEG study on ChatGPT-assisted writing, 2025
• Makransky et al., ChatTutor vs ChatGPT, Educational Psychology Review, 2025
• Hattie, Visible Learning meta-analysis (1200+ studies, 195 factors)
• Project Follow Through (1967-1977), 70,000+ students, 9 teaching methods
• Shanghai PISA results / Lesson Study tradition
• Macro Buddy experiment, Wisconsin-La Crosse, 2025
• Dallas ISD cancels Khanmigo / Iowa University pilot / Michigan Virtual (1102 students)
• IZA Institute, randomized experiment with 334 university students, 2025
• Tokyo University, cognitive offloading warning, 2025
• Koji by Brilliant / Sue Khim, product launch data
6 03
自打两周前，我换了一个好睡的枕头之后，睡觉也变香甜，以前每天起床后大脑昏沉，靠着毅力顶过一天，现在不用，心情也好了很多。
我的下一个目标是换床垫，还在挑选中。
有感于此，我觉得，如果一个人要对自己好，不要买什么电子设备，买好这几样：
桌子，椅子，枕头，床垫。
换到合适自己的，幸福感会马上提升一大截。
我的下一个目标是换床垫，还在挑选中。
有感于此，我觉得，如果一个人要对自己好，不要买什么电子设备，买好这几样：
桌子，椅子，枕头，床垫。
换到合适自己的，幸福感会马上提升一大截。
12 40
HN 吵了 300 楼才达成共识：你还需要一个领域，只是不再是写代码
最近 Brent Horsting 的一篇文章在 HN 引发了激烈讨论。他的核心论点简单但锋利：
「Agentic AI 切断了一个维系整个软件行业几十年的链接——写代码和建立领域心智模型之间的链接。你现在可以在不构建领域理解的情况下产出软件。」
这篇文章在 HN 上拿了 400+ 分、300+ 条评论，正反双方都拿出了硬核的论据。我把原文和讨论一并消化，提炼出几个值得认真思考的结论。
原文的核心框架
Pre-agentic 时代，写软件从来不是难在"写"本身。难的是先在脑子里建立一个领域的工作模型——你不可能在理解什么是税前扣除、什么是工资期跨税率变更之前，就写出一套工资系统。
Agentic AI 改变了这个等式。Brent 用两个人的对比来说明：
领域专家 + AI：惊人的有效。 一个物流调度员不懂什么是哈希表，但他看一眼 AI 生成的排班表，立刻知道哪个司机的工作时长不合法。他知道"正确答案长什么样"，因为他在这个领域里泡了十年。AI 提供的是他缺的东西（产出代码的能力），他提供的是 AI 缺的东西（ground truth）。
通才工程师 + AI：危险的盲区。 一个架构能力极强的工程师被扔进临床编码领域。AI 可以生成通过所有测试的账单规则——但这个规则可能"微妙地、昂贵地错误"。工程师可以验证软件"构建得好不好"，但无法验证它"对不对"。因为这里的"对错"完全由他不掌握的领域知识定义。
Brent 的判断：
「Agentic 工具摧毁了两条路径中的一条，而不是两条。工程师的优势——把领域模型翻译成工作代码——现在变得便宜了。领域专家的优势——知道正确长什么样——没有变便宜。你无法通过 prompt 获得一个处理了上千次工资核算的人的隐性知识。」
HN 最精彩的几个反驳
任何简洁的论点都会在 HN 上被从各个角度撕裂。这次也不例外。但撕裂的过程本身很有价值。
反驳一：软件工程本身就是一种领域知识
这是讨论中最有力的一个方向。
@patrickthebold
用一个具体的例子拆解了问题。他看过一个领域专家用 AI vibe-code 出来的应用——一个菜单管理系统。领域专家的实现方式是为每个菜品的每种可能配料设置独立的布尔标记：
技术上正确，测试也能过。但任何一个有经验的工程师都会用一个数组来建模。当新菜品需要新配料时，布尔标记方案需要改 schema、改 UI、改所有相关逻辑——这是一个设计故障，不是质量故障。领域专家不知道"对"长什么样，因为他不知道"软件设计"这个领域里什么是对的。
几个资深工程师在讨论中达成的一致结论：
「成功的软件来自两个领域专长的交集——应用领域，和软件工程本身。」
反驳二：AI 已经在编码领域知识
@a_bonobo
的反驳很直接：LLM 本身就在编码领域知识。你可以通过反复追问一个 LLM 来"学会"很多领域。相当多领域的壁垒只是"你不理解这个领域"，而 LLM 正在瓦解这个壁垒。
但
@PheonixPharts
的一个长篇回复提供了更有力的反例——产权保险和托管服务。他在这个领域干了多年，带过大型团队，深度使用过前沿模型。结论是：
「我们从 LLM 那里没有得到真正的 ROI。它产生了大量可疑的输出，无法在深度领域问题上给出准确答案而不产生幻觉，也无法理解在一个司法管辖区有效的东西在另一个司法管辖区可能完全错误。」
最有意思的是他的结论：我们发现构建最好产品的方式仍然是去现场，坐在产权和托管人员旁边，看他们工作，问他们问题，为真实世界设计。
反驳三：真正的护城河是销售
@jagged
-chisel 提供了另一个维度的思考：
「到目前为止，证据指向的是一个不同的格言：Sutton 的"惨痛教训"。它告诉我们，不要把人类专业知识带到可以被海量数据解决的问题上。因为后者在历史上反复屠杀了前者。」
他认为，如果一定要找一个真正的、持久的护城河，它不是领域知识，而是销售——说服其他人类掏钱。
延伸：平台工程师的新角色
@saghm 提出了一个正在浮现的新角色：
「我现在在做的基本上是平台工程师。工作内容是为领域专家使用编程 agent 创建护栏、验证流程、prompt 库，以及人工和自动审查机制。类似于内部 T2/T3 支持工程师——你在那里是为了抓住危险点和边缘案例，确保一切配置正确，而不是解决 100% 的常规问题。」
真正的结论：不是二选一，是交集
Brent 的文章标题叫"领域知识一直是真正的护城河"，但 HN 讨论把它修正成了更准确的表述：
领域知识是必要条件，但不是充分条件。
最安全的位置不在光谱的任何一端。它在两个人格的重叠处：
- 你能在 AI 生成的代码中识别出 has_milk = true 是个设计灾难
- 你能在工资单上识别出税前扣除的计算错误
- 你知道什么时候 agent 给的答案"听起来对但错得离谱"
@r
-m 在评论里举了一个他自己的真实案例。他的公司做私募股权和风险投资的软件。他们的内部笑话是："我们宁愿招一个资深基金会计来教他编程，也不愿意招一个工程师来教他基金会计。"——问题是前者几乎不存在。
这就是 Brent 给工程师的建议最后落点的地方：
「如果你是一个有经验的工程师，在考虑接下来几年应该把时间投入到哪里，这就是你的赌注。你辛苦练习的机械技能——把清晰想法翻译成干净代码——已经大幅贬值。仍然稀缺的，是一个对真实世界的某个领域有深度、可验证的心智模型。去找一个领域。就像你曾经学习一门编程语言或框架那样，去学一个行业、一个工具、一个监管体系、一个物理过程。」
一句话
「写代码的能力正在变成水。知道"对"长什么样的能力才是油。拥有两者的人，是 AI 时代最稀缺的资源。」
原文链接：brethorsting.com
HN 讨论：news.ycombinator.com
最近 Brent Horsting 的一篇文章在 HN 引发了激烈讨论。他的核心论点简单但锋利：
「Agentic AI 切断了一个维系整个软件行业几十年的链接——写代码和建立领域心智模型之间的链接。你现在可以在不构建领域理解的情况下产出软件。」
这篇文章在 HN 上拿了 400+ 分、300+ 条评论，正反双方都拿出了硬核的论据。我把原文和讨论一并消化，提炼出几个值得认真思考的结论。
原文的核心框架
Pre-agentic 时代，写软件从来不是难在"写"本身。难的是先在脑子里建立一个领域的工作模型——你不可能在理解什么是税前扣除、什么是工资期跨税率变更之前，就写出一套工资系统。
Agentic AI 改变了这个等式。Brent 用两个人的对比来说明：
领域专家 + AI：惊人的有效。 一个物流调度员不懂什么是哈希表，但他看一眼 AI 生成的排班表，立刻知道哪个司机的工作时长不合法。他知道"正确答案长什么样"，因为他在这个领域里泡了十年。AI 提供的是他缺的东西（产出代码的能力），他提供的是 AI 缺的东西（ground truth）。
通才工程师 + AI：危险的盲区。 一个架构能力极强的工程师被扔进临床编码领域。AI 可以生成通过所有测试的账单规则——但这个规则可能"微妙地、昂贵地错误"。工程师可以验证软件"构建得好不好"，但无法验证它"对不对"。因为这里的"对错"完全由他不掌握的领域知识定义。
Brent 的判断：
「Agentic 工具摧毁了两条路径中的一条，而不是两条。工程师的优势——把领域模型翻译成工作代码——现在变得便宜了。领域专家的优势——知道正确长什么样——没有变便宜。你无法通过 prompt 获得一个处理了上千次工资核算的人的隐性知识。」
HN 最精彩的几个反驳
任何简洁的论点都会在 HN 上被从各个角度撕裂。这次也不例外。但撕裂的过程本身很有价值。
反驳一：软件工程本身就是一种领域知识
这是讨论中最有力的一个方向。
@patrickthebold
用一个具体的例子拆解了问题。他看过一个领域专家用 AI vibe-code 出来的应用——一个菜单管理系统。领域专家的实现方式是为每个菜品的每种可能配料设置独立的布尔标记：
技术上正确，测试也能过。但任何一个有经验的工程师都会用一个数组来建模。当新菜品需要新配料时，布尔标记方案需要改 schema、改 UI、改所有相关逻辑——这是一个设计故障，不是质量故障。领域专家不知道"对"长什么样，因为他不知道"软件设计"这个领域里什么是对的。
几个资深工程师在讨论中达成的一致结论：
「成功的软件来自两个领域专长的交集——应用领域，和软件工程本身。」
反驳二：AI 已经在编码领域知识
@a_bonobo
的反驳很直接：LLM 本身就在编码领域知识。你可以通过反复追问一个 LLM 来"学会"很多领域。相当多领域的壁垒只是"你不理解这个领域"，而 LLM 正在瓦解这个壁垒。
但
@PheonixPharts
的一个长篇回复提供了更有力的反例——产权保险和托管服务。他在这个领域干了多年，带过大型团队，深度使用过前沿模型。结论是：
「我们从 LLM 那里没有得到真正的 ROI。它产生了大量可疑的输出，无法在深度领域问题上给出准确答案而不产生幻觉，也无法理解在一个司法管辖区有效的东西在另一个司法管辖区可能完全错误。」
最有意思的是他的结论：我们发现构建最好产品的方式仍然是去现场，坐在产权和托管人员旁边，看他们工作，问他们问题，为真实世界设计。
反驳三：真正的护城河是销售
@jagged
-chisel 提供了另一个维度的思考：
「到目前为止，证据指向的是一个不同的格言：Sutton 的"惨痛教训"。它告诉我们，不要把人类专业知识带到可以被海量数据解决的问题上。因为后者在历史上反复屠杀了前者。」
他认为，如果一定要找一个真正的、持久的护城河，它不是领域知识，而是销售——说服其他人类掏钱。
延伸：平台工程师的新角色
@saghm 提出了一个正在浮现的新角色：
「我现在在做的基本上是平台工程师。工作内容是为领域专家使用编程 agent 创建护栏、验证流程、prompt 库，以及人工和自动审查机制。类似于内部 T2/T3 支持工程师——你在那里是为了抓住危险点和边缘案例，确保一切配置正确，而不是解决 100% 的常规问题。」
真正的结论：不是二选一，是交集
Brent 的文章标题叫"领域知识一直是真正的护城河"，但 HN 讨论把它修正成了更准确的表述：
领域知识是必要条件，但不是充分条件。
最安全的位置不在光谱的任何一端。它在两个人格的重叠处：
- 你能在 AI 生成的代码中识别出 has_milk = true 是个设计灾难
- 你能在工资单上识别出税前扣除的计算错误
- 你知道什么时候 agent 给的答案"听起来对但错得离谱"
@r
-m 在评论里举了一个他自己的真实案例。他的公司做私募股权和风险投资的软件。他们的内部笑话是："我们宁愿招一个资深基金会计来教他编程，也不愿意招一个工程师来教他基金会计。"——问题是前者几乎不存在。
这就是 Brent 给工程师的建议最后落点的地方：
「如果你是一个有经验的工程师，在考虑接下来几年应该把时间投入到哪里，这就是你的赌注。你辛苦练习的机械技能——把清晰想法翻译成干净代码——已经大幅贬值。仍然稀缺的，是一个对真实世界的某个领域有深度、可验证的心智模型。去找一个领域。就像你曾经学习一门编程语言或框架那样，去学一个行业、一个工具、一个监管体系、一个物理过程。」
一句话
「写代码的能力正在变成水。知道"对"长什么样的能力才是油。拥有两者的人，是 AI 时代最稀缺的资源。」
原文链接：brethorsting.com
HN 讨论：news.ycombinator.com
38 29