SuperMuse Blog 中文

AI 帮你做完了，你学会了吗？

Yiming — Tue, 15 Sep 2026 04:00:00 GMT

AI 能写代码、解释论文，也能很快做出一个可以运行的小工具。结果来得越容易，我们越会问：还需要花那么多时间学习吗？我更在意的是接下来的事：这一次做完了，下次遇到类似的问题，自己会不会更懂一点？

2023 年，CNBC 主持人 David Faber 在采访中问马斯克，AI 不断进步，该给即将进入职场的孩子什么建议？马斯克停顿了一会儿，承认这个问题很难回答，建议去做感兴趣、有成就感、对社会有用的事。这份职业上的不确定，也落在了学习上：今天投入的时间，以后还用得上吗？

最近在 SuperMuse 上读到 Simon Willison 的一篇短帖，他提起三篇影响过自己的博客，其中有 Joel Spolsky 在 2002 年写的《抽象泄漏定律》。我一直很喜欢 Joel 的文章，多年前读过这一篇，这次又翻了出来。

重读 Joel

Simon 说，这一篇 blog 让自己养成了一个习惯：主动了解工作所在层次之下的东西，以防某一天抽象发生泄漏。

所谓“抽象”，就是工具把复杂细节包起来，让我们用简单的方式做事。

比如，面向对象用对象和方法封装数据与行为，隐藏内部实现；关系数据库让我们通过表和查询管理数据，隐藏许多文件存储与磁盘读写的细节；对象关系映射（ORM）让我们通过程序里的对象操作数据库，处理对象与表之间的映射和常见 SQL 的生成。但被隐藏的细节仍可能影响结果。这种时候，抽象就“泄漏”了。

被藏起来的细节，会怎样回来？

一个表情，为什么长度不一定是 1？

做昵称输入框时，判断字符串长度似乎足够了。可 JavaScript 中 "😄".length 的结果是 2，因为它数的是 UTF-16 码元，并非人眼看到的字符。复杂的组合表情可能涉及更多码元。MDN 文档说明了这种区别。

遇到计数不对、截取后字符损坏的问题，就要往下理解编码和字符边界。一个“长度”属性，并没有替我们决定用户所说的“一个字”究竟是什么。

几行查询代码，为什么会让页面越来越慢？

许多框架允许我们像操作普通对象一样读取数据库。显示十本书及其作者，先取出书，再逐本读取作者，看起来很自然。但如果没有提前加载关联数据，背后可能是一次查书、十次查作者，总共十一次查询。这就是 N+1 查询问题。Rails 文档有具体的例子。

框架省下了手写 SQL 的工作，却没有取消查询的成本。页面慢下来时，需要看实际执行了什么、发出了多少次查询。只看表面那几行代码，可能找不到原因。

请求超时了，为什么不能直接再试一次？

假设程序发送了创建订单的请求，却迟迟没有收到结果。超时可能意味着服务器没有收到请求，也可能意味着订单已创建，只是响应没传回来。缺少防重复处理时，再发一次就可能多出一笔订单。

这时要理解客户端与服务器各自知道什么，以及怎样让同一次操作的重试只产生一次效果。Stripe 的幂等请求文档解释了其中一种做法。函数调用看起来很简单，通信的不确定性却仍然需要处理。

点一下重试很容易。为什么多了一笔订单，却需要往下多看一层。

这些问题有一个共同点：想把事情真正弄清楚，往往还得往下面多看一层。

Joel 在文章中写道：

“So the abstractions save us time working, but they don’t save us time learning.”

抽象节省了工作的时间，却没有省去学习的时间。工具减少了重复劳动，但熟练调用一个接口，并不等于理解它背后的机制。

更高层的抽象，也会泄漏

从使用者的角度看，AI 编程把抽象又往上推了一层。我们可以用自然语言描述需求，让 AI 把它变成编程语言，再交给框架和系统执行。“做一个订单页面”这句话背后，可能已经包含了数据结构、查询方式和请求处理等一连串决定。

但更高层的抽象，仍然会泄漏。页面能打开，不代表数据增长后查询依然高效，也不代表并发提交时订单不会重复。这些细节一旦影响结果，就需要回到代码、数据库和通信机制中找原因。缺少对底层原理的理解和软件工程经验，往往连问题出在哪里、改动是否可靠，都难以判断。

在这个意义上，Joel 的抽象泄漏定律依然适用于 AI 编程。自然语言让我们更容易开始，系统运行的规则却仍在那里。理解底层，能让我们知道该怀疑什么，也知道怎样验证。

这一层抽象提高了生产力，却不会把理解也一并交付。工作变快，并不意味着学习会自动发生，也不意味着学习就变得容易、简单。 AI 可以解释原理、帮助设计实验，但把知识学扎实，仍需要自己推理、练习，并从反馈中修正判断。

答案正确，也可能没有学会

还有一种更难察觉的情况：AI 的答案完全正确，事情也顺利完成，自己却没有学到多少。

吴恩达在今年 8 月的一次访谈中谈到“认知卸载”：把一部分思考交给工具，也可能错过练习。他举了自己的例子：项目中遇到前后端组件的问题，问 AI、拿答案、做完；六个月后再碰到类似问题，却没有记住，只能再问。

这不能直接说成“AI 损伤了记忆力”。更准确的问题是：那些知识，可能从来没有被自己充分理解和记住。

一项发表于 PNAS 的研究，在土耳其一所高中对近千名学生开展数学学习实验。使用普通 GPT-4 对话工具的学生，有 AI 时练习表现提高；撤去 AI 后，独立考试成绩却比未使用 AI 的对照组低约 17%。另一种加入教师设计的提示、避免直接给答案的工具，大幅缓解了负面影响，但也没有让独立考试成绩显著超过对照组。

这不能代表所有学习场景，却提醒我们：完成任务的表现，和学习的结果，需要分开看。

看懂一个解释、照着答案做成功，很容易让人觉得自己已经会了。换一个条件，或者试着从头解释，才会发现哪里还不清楚。

杠杆的这一头

如今，人们常把 AI 比作一根杠杆。它让一个人有机会完成过去需要更多时间、更多人手才能做的事情。而杠杆这一头，是我们自己的积累。

杠杆越来越长，积累仍在我们这一头。你的积累越大，能够撬动的东西也越大、越重。

我们这一头的重量，是知识、经验，也是对眼前问题的了解。读文章时，能追问证据是否支持结论；做产品时，能分清用户的困难和自己想象的需求。有这些积累，和 AI 讨论时就更容易问到关键处，也更有机会把一个初步答案做成有用的东西。

积累多，不保证每次判断正确；新手也能借助 AI 做成以前做不了的事。自己的重量，可以边做边增加。 每次多弄懂一点，下一次能尝试的事情也就多一点。

避开苦修和全盘外包

强调学习，很容易走向“苦修”：觉得只有自己手写每一行代码，才算真正掌握。为了弄懂一次网络请求，不必先从头实现整套协议；工具省下的重复劳动，可以让我们把时间花在更值得理解的问题上。

另一个极端是全盘外包：把实现交给 AI，也把判断和验证一并交出去。结果能运行，就不再追问为什么；出了问题，只能继续让它重试。这样即使完成了很多任务，遇到抽象泄漏时，仍可能不知道从哪里查起。

我更愿意一边用，一边学。让 AI 帮忙完成工作，也给自己留下提问、验证和独立尝试的机会。需要多懂一些的地方，可以沿着眼前的问题逐步补上。

先看全貌，再深入细节

抽象泄漏提醒我们理解底层，但学习也要避免只见树叶、不见森林。先看清自己在解决什么问题、各个概念怎样联系，才知道哪些细节值得追下去。弄懂一个细节以后，也要回头看它在整体中处于什么位置。

AI 很适合帮助我们搭起这样的知识框架：梳理一个主题的核心概念，比较不同领域的相似问题，把新知识与已有经验联系起来。带着这张初步的地图，再去读原文、做实验，检查和修正其中的关系。留下的笔记，也可以记录自己的理解怎样改变。一次好的学习，应该给下一次思考留下东西。

和 Muse 一起读

在 SuperMuse 里，AI Muse 伴读可以陪你把这样的学习继续下去：带着原文讨论，在关键处用问题、反例，甚至一个容易踩进去的“坑”，请你先判断，再解释理由，看看哪里还没想清楚。

读完后，把新划线和旧笔记交给 Muse一起梳理，再由自己确认哪些联系说得通。我喜欢“温故而知新”：有了新问题，旧笔记也会多一层意思。阅读、记录和讨论接在一起，知识才有机会逐渐成为自己的理解。

AI 可以帮我们把事情做完。我希望它也能帮我们在做完之后，多懂一点。

参考与延伸阅读

Simon Willison：What blog posts influenced your thinking the most?（2026-09-14）
Joel Spolsky：The Law of Leaky Abstractions（2002-11-11）
Will Larson：Migrations: the sole scalable fix to tech debt
Charity Majors：The Engineer/Manager Pendulum
CNBC：马斯克谈孩子的职业选择（2023-05-16）；问答转录
Silicon Valley Girl：Andrew Ng: The Biggest Opportunities in AI Aren’t Where You Think（2026-08-28，学习话题从 11:59 开始）；访谈转录
Bastani 等：Generative AI without guardrails can harm learning: Evidence from high school mathematics（PNAS，2025）
Oracle：对象、封装与实现细节
PostgreSQL：关系数据库的基本概念
Rails：对象关系映射（ORM）
Rails：N+1 查询问题
Stripe：幂等请求
MDN：字符串长度与 UTF-16 码元

为什么叫 SuperMuse

Yiming — Sun, 26 Jul 2026 01:30:00 GMT

SuperMuse 最早并不叫这个名字。最初我把它叫做 VoxMind。那时候我的想法相对简单：我想做一个以语音为入口的 AI-native 笔记和创作工具。很多想法出现的时候其实并不完整，可能只是在走路、开车或者喝咖啡的时候突然想到一句话，与其等到坐到电脑前再整理，不如直接说出来，让 AI 帮忙记录、理解和扩展，最后再把这些零散的东西变成文章或者其他内容。

但随着产品一点点往前做，我开始发现，自己真正感兴趣的似乎并不是“怎样让 AI 帮人写得更快”。

今天的 AI 已经很擅长生成内容。给它一个 Prompt，它可以很快写出一篇文章，也可以生成图片、音乐甚至视频。生成的速度越来越快，质量也越来越高。可当生成本身变得越来越容易以后，我反而开始觉得，创作过程中真正困难的部分可能一直都不是“把东西写出来”，而是更前面的那一步：我们究竟为什么想写这件事情？一个真正属于自己的想法，又是从哪里来的？

Muse

今天，一个作家可能把某个人称作 my muse，一个摄影师也可能把一座城市视为自己的 Muse。这个词常被用来指“灵感来源”。

在古希腊神话中，Muses 是与艺术和知识有关的女神，按最广为流传的说法，一共有九位。诗人常在故事开篇呼唤 Muse，请她帮助自己讲述，荷马的《奥德赛》便是如此。

九位缪斯与一位倾听的诗人。

我喜欢这种创作观：诗人从听到的故事和已有的记忆里汲取素材，再用自己的方式讲述。

记忆生出了 Muse

对我来说，Muse 不只意味着“创造”，也让我想到记忆、发现与连接。

真正让我喜欢上这个名字的，是九位 Muse 的母亲：Mnemosyne，古希腊神话中的记忆女神。

Mnemosyne：记忆中的片段，逐渐成为灵感。

赫西俄德《神谱》记载，宙斯与 Mnemosyne 相伴九夜，后来她生下了九位 Muse。我喜欢这个故事里的隐喻：

Memory gave birth to the Muses.

记忆，孕育了灵感。

一本几年前读过的书，可能突然帮我们理解今天的问题；一个搁置的想法，也可能因为新技术而变得可行。所谓灵光一现，有时就是过去的经历，在新的处境里产生了联系。

Memory → Connection → Inspiration

原本分散的经历，在一个新的问题里相遇。

灵感只是创造的开始

至少对我来说，很多想法刚出现时都很模糊。做一个产品可能最初只有一句话，写一篇文章可能只是觉得某件事值得再想想。我会去读一些东西，和 AI 讨论，做出第一版，才发现有些地方说不通，需要回头修改。有时，动手以后我才知道自己到底想做什么。

想法不是被执行出来的，它是在创造过程中被打磨出来的。

上下文不只是记忆

刚读到的文章、手边的草稿、上一次尝试带来的反馈，连同过去的记忆，构成了此刻的上下文。随着创作推进，上下文也在改变。

这也是上下文工程（Context Engineering）吸引我的地方：此刻的想法需要什么？ 卡住时，一个例子可能就有帮助；过于确信时，也许需要一个反例。把什么带进讨论，会影响我们接下来怎样想。

我们不仅是在为 AI 构造上下文，也是在借助 AI，为自己的思考重新构造上下文。

在尝试中学习，再带着新的理解回到作品。

AI 可以成为 Muse

我希望 AI 像 Muse 一样，带来启发，也提出质疑。但要不要采纳、认不认同、最后怎么表达，仍由我决定。一次好的讨论，应该让我更清楚自己在想什么。

创作者始终是人。

Muse 陪伴创作，动手创造的始终是人。

SuperMuse

VoxMind 这个名字来自最初的语音入口。随着产品往前做，我想留下的已经不只是说出口的念头，还有让它逐渐成形的过程。于是，我把它叫作 SuperMuse。

最初加上 Super，主要是因为这个名字容易记，单独的 Muse 又不好注册。

如果要赋予它一点期待，我希望这位 Muse 能陪着一个还没有成形的念头，多走一段路。

我为什么做 SuperMuse

Yiming — Sat, 27 Jun 2026 01:30:00 GMT

盐田边的一天

泳池边

红杉林里

面朝大海

八月，Google 园区

骑行途中

街头缆车

We are ebay

休息一会儿

这九张卡片用 SuperMuse 制作，把旅途和生活里的照片，配上日期、地点或几句想留下的话。左右滑动浏览，点击图片放大。

我的备忘录里，躺着几百条只写了一半的想法。

读书时摘下的一段话，散步时冒出的产品点子，一个想写的故事开头，写代码时没想通的问题，还有旅行中的照片和感受，都可能被随手记在这里。记下来的时候，都觉得以后可能用得上。

但真正想写点什么，或者想清楚一个问题时，又常常找不到它们。

有时候，明明记得自己读过一个相关的观点，却忘了是哪本书。换了几个关键词搜索，还是没找到。有时候翻到一条旧笔记，才发现它和最近一直在想的事情有关，只是当时没有意识到。

把这些点连起来

乔布斯在 2005 年的斯坦福毕业演讲里说过：

“You can only connect them looking backwards.”

只有回头看时，你才能把这些点连起来。

在这段 “connecting the dots” 的故事里，他回忆，大学时旁听的书法课，多年后影响了 Macintosh 的字体设计。他讲的是自己的人生经历，也让我想到那些随手留下的记录：当时不知道有什么用，后来可能正好帮上忙。

分类和标签能帮忙整理，却很难预先知道一条笔记以后会和什么有关。我想做 SuperMuse，就是希望读书笔记、照片和零散的想法能够放在一起，遇到问题时，更容易找到相关的材料，接着讨论下去。

有些讨论会变成一篇文章，有些只会让一条笔记多出几句话。能把以前没想完的事情接着想下去，就已经很有用了。

先记下来，不急着分类

一个念头突然冒出来时，往往来不及想标题，更顾不上放进哪个文件夹。如果还要先整理好，我可能就不想记了。说几句话、写一段笔记，或者留下照片和链接，都应该可以直接开始。

我尤其想保留的，是记录时的那一点背景。一段摘抄旁边写下“这里没想明白”，一张照片旁边留一句“这个地方让我想到什么”。以后再看，才有机会接着当时的思路往下想。

至于这些内容最终有什么用，可以晚一点再决定。

带着一个问题，把材料放在一起

读书时，作者的一句话可能让我赞同，也可能让我想起一个相反的例子。我希望，在阅读器里，原文和自己的问题能留在一起。遇到不懂的概念，可以请 AI Muse举个例子；有了自己的理解，也可以让它帮忙找找漏洞，再带着新的问题读下去。

比如，读到一段关于“留白”的讨论，也许会想起旅行中拍过的一张海报，以及做产品时的一次犹豫：功能越多，真的越好用吗？可以把阅读笔记、海报照片和自己的想法选进对话，和 Muse 一起比较：海报上的留白，和产品里少做几个功能，是一回事吗？

比较后，也可能发现，自己把两件不同的事混在了一起。一个解释说不通，就回去看原文、换个例子，再修改笔记。写代码时也可以这样：带着技术文章和自己卡住的问题，讨论几种做法的取舍。事实和引用仍然需要核对，判断也需要通过实际尝试来检验。

这也是我理解的 AI Native：AI 就在阅读、记录和创作的过程中，和我一起学习、讨论、修改。读到一半有疑问，或者写到一半卡住，可以带着手边的材料接着聊，不用换个窗口，再把背景从头讲一遍。哪些材料带进对话，也应该由自己选择。

想清楚一点，再写出来

等到对一个问题有了自己的看法，可以和 Muse 一起把笔记和例子整理成初稿：最初困惑的是什么，现在怎么看，还有哪里没想明白。我可以请它指出说不清楚的地方，再补材料、改写，直到这篇文章能表达自己的意思。产品构想也一样，先一起讨论出一个可以尝试的方案，做过之后，再带着结果回来修改。

也有些内容不需要写成长文。顶部的九张卡片，就是把旅途和生活里的照片，配上日期、地点，或者几句想留下的话。它们和读书笔记一样，都是我愿意以后再翻看的东西。

不必每条笔记都走到最后。 有些留给自己就好，有些过了很久，才会用在一篇文章里。

我做 SuperMuse，就是希望下次遇到一个问题时，能更容易用上这些积累。找到以前读过的那段话，重新看一眼旧照片，接着写完那条只开了个头的笔记。

了解 SuperMuse →