关于使用 LLM 进行思考的思考

# Thinking About Thinking With LLMs
# 关于使用 LLM 进行思考的思考

**Oct 25 2025 | 3 minutes**
<br>
*2025年10月25日 | 3分钟阅读*

---

After reading [Developing our position on AI](https://www.recurse.com/blog/191-developing-our-position-on-ai) from the [Recurse Center](https://www.recurse.com/), the corresponding entry in [my newsletter](/weekly) grew long enough I’ve decided to break it out into a full blog post. Above and beyond its specific findings, I think the post charts a path for a more civil and considered mode of discussion that we should all strive for on the Internet and in our own lives.

在阅读了 [Recurse Center](https://www.recurse.com/) 发布的《[阐明我们对人工智能的立场](https://www.recurse.com/blog/191-developing-our-position-on-ai)》一文后，我在[我的时事通讯](/weekly)中对应的条目变得足够长，所以我决定将其扩展成一篇完整的博客文章。我认为，除了其具体发现之外，这篇文章还为一种更文明、更深思熟虑的讨论模式指明了方向，我们所有人都应该在互联网上和自己的生活中努力追求这种模式。

I’ve long been fascinated by the Recurse Center. Throughout my career I’ve been consistently impressed with alums I’ve crossed paths with, so I’m not particularly surprised that probably the most balanced and thoughtful take on AI and software engineering that I’ve read so far has come out of Recurse.

我一直对 Recurse Center 很着迷。在我的职业生涯中，我遇到的校友都给我留下了深刻的印象，所以我并不特别惊讶，迄今为止我读到的关于人工智能和软件工程最平衡、最深思熟虑的观点可能就出自 Recurse。

## Discourse on the Internet
## 互联网上的讨论

I think the article presents a great way to deal with contentious issues within organizations and how to write about those issues publicly. First, listen to everyone. Then, acknowledge disagreements and emphasize nuance to make an effort to find common ground.

我认为这篇文章提出了一种很好的方式来处理组织内部有争议的问题，以及如何公开发表关于这些问题的文章。首先，倾听每个人的意见。然后，承认分歧并强调细微差别，努力寻找共同点。

The goal doesn’t need to be having The Correct Take at every moment. People have different life experiences which often leads them to different top-line beliefs. But beyond those headlines, where reasonable people state anything from “we’ll all be living in ASI-powered utopia by 2028” to “LLMs are slurping up all our fresh water”, there is a surprising amount of common ground.

目标不必是每时每刻都持有“正确”的观点。人们有不同的人生经历，这常常导致他们持有不同的顶层信念。但在这些标题之外，尽管理性的人们会发表从“到2028年我们都将生活在ASI驱动的乌托邦”到“LLM正在耗尽我们所有的淡水”等各种言论，但令人惊讶的是，仍存在大量的共同点。

In the case of this article, most people agreed that *using LLMs to learn new things* needs to be done with some caution.

就这篇文章而言，大多数人同意*使用LLM学习新事物*需要谨慎行事。

## Step-Functions in Abstractions
## 抽象中的阶跃函数

This paragraph from the post really resonated with me:

这篇文章中的这段话真的让我产生了共鸣：

> [T]utorials and teachers can only get you so far. Ultimately, you must build your own mental structures. Stack Overflow can be a helpful resource, but blindly following or copy-pasting from it does little to help you learn. While you can get a lot farther mindlessly using LLMs than Stack Overflow, the same principle holds true.
> 
> 教程和老师只能带你走这么远。最终，你必须建立自己的心智结构。Stack Overflow 可以是一个有用的资源，但盲目跟从或复制粘贴对你的学习帮助不大。虽然不假思索地使用 LLM 比使用 Stack Overflow 能让你走得更远，但同样的原则依然适用。

The comparison to StackOverflow is one that I’ve seen pop up again and again in discussions around LLMs. While LLMs can feel revolutionary, it’s not the first time we’ve seen a step change in software development resources.

将 LLM 与 StackOverflow 进行比较，是我在关于 LLM 的讨论中反复看到的观点。虽然 LLM 感觉是革命性的，但这并不是我们第一次看到软件开发资源出现阶跃式变化。

Google made the skill of searching and skimming manuals for reference materials almost obsolete. O’Reilly still exists, but reference books are a much smaller part of an engineer’s education than shorter-form blog posts focused on specific tasks[^1].

谷歌几乎淘汰了搜索和浏览手册以查找参考资料的技能。O'Reilly 仍然存在，但与专注于特定任务的短篇博客文章相比，参考书在工程师教育中所占的比重已大大减小[^1]。

StackOverflow made it possible to accomplish many common coding tasks without much upfront thinking. Most consider copy/pasting StackOverflow answers to be an unfortunate shortcut. StackOverflow filled a niche, but it didn’t obviate the need for a deep understanding.

StackOverflow 使得在没有太多前期思考的情况下完成许多常见的编码任务成为可能。大多数人认为复制/粘贴 StackOverflow 的答案是一种不幸的捷径。StackOverflow 填补了一个空白，但它并没有消除对深入理解的需求。

Software engineering has always had a component focused on automating “white collar” human work like airline logistics, processing payroll, or organizing and maintaining libraries[^2]. Programming as a profession has never been immune to this — assemblers automated away calculating memory offsets for jumping to procedures; garbage collectors automated memory management; Google Search changed what it meant to RTFM.

软件工程一直以来都有一个专注于自动化“白领”人类工作的组成部分，比如航空物流、薪资处理或组织和维护图书馆[^2]。编程作为一个职业从未能幸免于此——汇编器自动化了计算跳转到过程的内存偏移量；垃圾收集器自动化了内存管理；谷歌搜索改变了“RTFM”（读那该死的手册）的含义。

New tools always make it easier to code with a shallower understanding of the system. Claude Code, Cursor and their ilk are bringing programming closer to natural language just like C and Java and Python once did.

新工具总是让人们可以用对系统较浅的理解来编码。Claude Code、Cursor 及其同类产品正在使编程更接近自然语言，就像 C、Java 和 Python 曾经做过的那样。

This is a good thing! It’ll lead to the continued democratization of programming and ever more people in conversation with computers. But I don’t think this changes the fundamental reality that the *best* programmers aren’t the ones that make the widest use of the highest abstractions. That’ll continue to be those who dig down and understand what’s happening at a deeper level — that understanding will always lead to more deft use of any tools that programmers have at their disposal.

这是件好事！它将导致编程的持续民主化，以及越来越多的人与计算机进行对话。但我认为这并不会改变一个基本事实，即*最优秀*的程序员并不是那些最广泛使用最高层抽象的人。最优秀的程序员将继续是那些深入挖掘并理解更深层次发生的事情的人——这种理解将永远导致他们更熟练地使用程序员所拥有的任何工具。

***

[^1]: All [four of types of documentation](https://nick.groenen.me/posts/the-4-types-of-technical-documentation/) certainly existed before the advent of search engines, but shorter-form content thrives in ranked searches and recommendation algorithms.
<br>*所有[四种类型的文档](https://nick.groenen.me/posts/the-4-types-of-technical-documentation/)在搜索引擎出现之前当然都存在，但短篇内容在排名搜索和推荐算法中更为繁荣。*

[^2]: The ones filled with stacks and stacks of books, not the ones with pre-written functions you can call from your programs.
<br>*是指那些堆满书的图书馆，而不是那些包含你可以从程序中调用的预写函数的库。*