--- title: 稻草人周刊 Vol.43 subtitle: 为什么大语言模型无法创造软件 tags: - AI - 编程 - 软件 - 设计 - 职业 - 沟通表达 date: 2025-08-25T11:28:00 categories: 稻草人周刊 draft: false toc: true banner: https://image.guhub.cn/uPic/2025/08/IMG_20230331_185418大.jpeg endnotes: - 封面图自摄，一两年前用 HUAWEI P40 拍的 --- > The ceiling's spinning  > > And I think god is winning  > > 'Cause I see my hands shaking  > > And I cannot make them stop > [!note] 🧠 > 欢迎加入本博客的 Telegram 频道「[大脑充血](https://t.me/geedeapro)」。 > [!note] 🤖 > 由于本周我不小心任由 Hacker News 上的推送进入我的大脑，所以周刊的 AI 话题量稍显累赘，还请读者见谅。 ## ↯ · 当下 - 什么时候意识到自己状态恢复的呢？就在一分钟前发现自己吃完饭听完播客站起来莫名其妙地跟着播客最后的背景音乐跳舞的时候。 - 熟悉的高中同学暑假几乎都没有留在家乡，回家之后一直找不到人一起出游，本来想找点一个人可以做的事情，结果不仅重庆本身是个文化荒漠（剧院和展览几乎没有能看的），想看的电影在这个小地方的影院也没有上线…… 就关在家里读书得了。 - 因为发现自己近期的注意力难以集中，于是试着把 Safari 阅读列表里的几篇文章打印了下来，结果惊奇地发现自己居然只用了半个小时就读完了之前需要一个小时才能读完的内容。这大概是因为纸张自带的沉浸感吧。 ![](https://image.guhub.cn/uPic/2025/08/printed-reading-materials.jpeg) ## ⋈︎ · 连接 ### 为什么大语言模型无法创造软件 > [!note] 📜 > 文章链接：[Why LLMs Can't Really Build Software](https://zed.dev/blog/why-llms-cant-build-software) 作者认为，真正的软件工程师构建软件的过程是这样的： 1. 在脑中构建一个需求的模型； 2. 编写代码实现它； 3. 在脑中构建这段代码实际行为的模型； 4. 发现两个模型的区别，然后更新代码。 大语言模型很擅长写代码，但无法创造软件的根本原因在于：它无法维护清晰的思维模型。原因如下： 1. **上下文遗漏**（context omission）：大语言模型会遗漏已经出现过的上下文。比如，明明先前要求大语言模型用 YAML 格式编写配置，可接下来却擅自使用 TOML 格式。 2. **近因偏差**（recency bias）：大语言模型更容易被最近的指令影响。 3. **幻觉**（hallucination）：大语言模型会幻想出根本不存在的细节。 这些或许是能够解决的问题，增加「记忆」功能就可以解决一些遗漏，但根本上，大语言模型创造的是[思考的幻觉](https://machinelearning.apple.com/research/illusion-of-thinking)，他们不能维护两套「思维模型」、识别差异，然后判断应该修改代码还是修改需求。大部分复杂的思考还是要交给软件工程师来做。 作者相信（至少目前为止）程序员仍然在驾驶座，而大语言模型只是可以取用的工具而已。 #### 我的观点 我一直不相信「AI 会取代人类」之类的鬼话，原因很简单：**计算机程序没有主体性。** 至少目前为止，AI 仍然需要人与之交互（提供输入）才能生成内容，它不能给自己写提示词，也没法判断生成出来的代码究竟能不能用。换句话说，它是客体。==取代人力的从来不是新技术，而是掌握了新技术的其他人；只要自己成为掌握新技术的人，就能成为取代别人的人。== [#AI](/tags/ai/) [#编程](/tags/编程/) ### 如何清晰地发言 > [!note] 📺 > 视频链接：[How to articulate your thoughts more clearly than 99% of people](https://www.youtube.com/watch?v=JHmAS4q-GqY) 这位 YouTuber 拆解了「表述清晰」（articulate）的意思，即需要同时做到流畅（fluency）和连贯（coherency）。要做到这点，演讲者需要有好的内容和结构（content / structure），还要很好地将内容传达出去（delivery）。 其中我觉得最有启发的建议是：减少听众的心理负担。如果讲了太多话，听众就需要耗费很多的心理资源和认知资源来理解这些话，用尽可能直接的语言描述自己的想法和需求能够提高表达的效率。不过，按照这位 YouTuber 自己的表述来看，他更多地是在传授「职场技巧」，即怎么和那些没什么时间精力听你讲话的高层人员做汇报、开会[^1]；我认为，减少听众的心理负担，对与自己了解甚少的陌生人沟通时也有必要。 #### 我的观点 在背景里的逻辑框架的伪装下，这位 YouTuber 的演讲看起来具有逻辑连贯性，实则不然。如果看完了整个视频，就能观察到明显的前后矛盾。 首先，在「Content / Structure」部分，作者讲到的一条原则是「解释的最快路径」，即用最少的文字讲清楚自己的内容和目标，去掉不必要的细节。然而，在「Delivery」部分，作者却提到了「讲故事」的技巧，即通过描述场景、增加细节，让表达更引人入胜。这两条建议完全是相反的，而作者并没有解释这两条建议分别适用于什么场合。回过头看，这整个视频都充斥着**让人不知道什么时候用但听起来又很实用**的方法指导。 当然，尽管我觉得内容不怎么样，但这位 YouTuber 讲话的方式非常清晰，我也完全理解了他的意思，这也是为什么我能很快找出视频中的逻辑错误。我认为他的表达清晰并非源自于他在视频中解释的方法，而是： 1. 他的发音很清晰（enunciate 而非 articulate），观众能听清楚每个单词是什么。 2. 他的重音很明显，需要强调的地方有自然地加重语气、拖长语调，一些不重要的虚词和句子语速则较快。 3. 他有解释原因，不仅让观众理解了「怎么做」，还能在理性上认同「为什么要这样做」。 4. 他有适当的例证，观众容易产生画面感，在感性上认可其价值。 5. 他没有明显的卡顿、废话，整体而言，演讲较为连贯。 缺点也很明显，比如 like 和 literally 这两个词用得实在是太多了，这虽然能从侧面看出他不是在背稿，而是完全基于自己的理解在阐述，但我作为听众不需要看到他的努力，我只需要看到一出逻辑清晰、观点明确、语流连贯的演讲。 [#沟通表达](/tags/沟通表达/) ### “用 AI 取代初级员工是我听过最蠢的事” > [!note] 📜 > 文章链接：[AWS CEO says using AI to replace junior staff is 'Dumbest thing I've ever heard'](https://www.theregister.com/2025/08/21/aws_ceo_entry_level_jobs_opinion/) 小标题上的这句话是亚马逊 Web 服务的 CEO，Matt Garman，说的，他对一些常见的管理人员对 AI 的迷思做出了反驳。 1. 一些人认为：既然 AI 能完成初级员工能做到的事情，甚至能做得更好，那么为什么不把人员开除掉，用 AI 完成工作？
Garman 认为：如果这么做了，那十年之后有企业里就不会有新人学到任何东西，你应该继续雇佣从大学里出来的孩子，并且教他们如何正确地构建软件、拆解问题并作出思考，就像你曾经做过的一样。 2. 一些人认为：可以通过项目中 AI 生成的代码的占比衡量 AI 对项目的贡献程度。
Garman 认为：**好的代码往往是简短的**。尽管 AI 能够产生大量的代码，但那些代码也可能很烂。 Garman 还给出了一些职业建议：在如今，学习一门应用面很窄的技能（narrow skills）已经不再能保证自己二三十年内还有饭吃了，现在人们应该**学着如何学习**，而不只是学习技能。 #### 我的观点 关于「学着如何学习」，这篇文章中并没有详细阐述，我想就算有的话，我也不愿意照搬别人的方法论。我的观点是，应该在做的过程中去学，而不是学完了再做。既然「做」就是学习的方式，那么一直做、一直尝试新的东西，就能一直保持学习，如此一来自己对「如何学习」就会有自己的经验和方法了。 [#AI](/tags/ai/) [#编程](/tags/编程/) [#职业](/tags/职业/) ### 读着顺口与写得正确 > [!note] 📜 > 文章链接：[Good Writing](https://www.paulgraham.com/goodwriting.html) Paul Graham 在这篇文章中讨论了好的写作是怎样的。他认为，通常来讲，好的写作有两个层面的意思——读着顺口（sounding good）和写得正确（ideas being right）。他认为这两种好的写作往往同时出现，有可能是同一个东西的两端。 他发现自己在修改文章时，为了减少字数或改掉不顺口的地方，会重写一些句子，而这些无论出于何种原因重写的句子似乎总是更准确地表达了观点。当他在尝试让句子读得更顺口的时候，自己也写得更正确了。他认为这是因为修改时，自己有意识或无意识地修正了一些错误表达，**读着更顺口的句子更有可能是内部逻辑连贯的句子**。好的作家在写作时能够无意识地做到读着顺口和写得正确，因为他们不仅是诚实的，对所写话题也有真正的思考，并且相信自己写的东西是正确的。 不过，他认为这一发现只适用于那些为了发展想法而写的文章（writing that's used to develop ideas）。 #### 我的观点 我想本文表达的只是 Paul Graham 的经验法则，适用范围较窄，但仍然具有参考价值。同时，你也可以从他的言外之意读出，写作最重要的是连贯的内部逻辑和忠于自我。 [#写作](/tags/写作/) ### AI 正在高速产出技术债务 > [!note] 📜 > 文章链接：[Vibe code is legacy code](https://blog.val.town/vibe-code) Vibe coding 不仅仅是指「用 AI 直接生成代码而不去过多地审查」，作者指出，Andrej Karpathy 造出 Vibe code 这个词的时候，指代的实际上是「用 AI 生成后，直接忘记这段代码存在」的编码方式。这样被忘记的代码，在一开始被 AI 生成后也没有被认真地阅读和审查过，也就没有被理解过。在生成式 AI 编程崛起前，人们早就造了一个词用来称呼那些老旧的、没人看得懂的代码——Legacy code（遗产代码）。 这样的代码由于没有人能看懂（或者说需要耗费很多不必要的时间精力才能读懂），维护起来十分困难，也就形成了所谓的「技术债务」（Technical debt）——而那些**过度依赖 AI 编程的人，正在以极高的速度产生这样的技术债**。这一现象在那些没有任何编程基础的人身上尤为明显：一开始，他们惊叹于 AI 的能力，觉得现在不需要学编程也能做软件了；过不了多久，他们会发现自己完全读不懂代码库里的代码，不明白那些文件和目录是什么意思（不仅他们，其他人来了也看不懂）；他们需要依靠 AI 继续产出更多的看不懂的代码来修复那些看不懂的代码产生的问题，并在这个过程中反复产生技术债——==让不懂编程的人用 AI 编程，就像把信用卡交给那些不明白「债务」是什么的小孩子一样，一开始，他们为能到任何想要的东西而高兴，一个月后，他们看着账单惊恐不已，发现自己根本不知道应该怎么办，只好继续借贷，用新的债务偿还已有的债务。== 作者认为，AI 编程工具应该交给那些清楚其利弊得失，能够用人眼读懂代码的人来使用，因为「构建理论」依然是构建软件的重点，程序员就算没有自己在写代码，也应该理解自己每时每刻在干些什么。此外，作者并没有否认 Vibe coding 的价值，他认为 Vibe coding 很适合用来做软件原型和那些用完就扔的代码。 #### 我的观点 我曾经写过一篇题为《[AI 正在让人变得前所未有地自以为是](/posts/ai-正在让人变得前所未有地自以为是/)》的言辞激烈的批评，这也是博客上浏览量最高的文章，在当时引发了不少争议。被转发到社交媒体上之后，有一部分人并没有来我的博客评论，而是在社交媒体上将我评价为「感觉这个作者破防了」「读完了，一个程序员在无能狂怒」，用夸张的网络热词指出我的情绪，但**回避直接回应我的观点**。[^2]周刊中提到的这篇文章中的观点与我四个多月前表达过的观点是类似的，但这位作者的语气更加平和，尽管他直接把那些自以为是者比做「不懂事乱刷卡的小孩子」——我承认，这是个更具侮辱性且更聪明的比喻。 [#AI](/tags/ai/) [#编程](/tags/编程/) ### 小而美就够了 > [!note] 📜 > 文章链接：[Do things that don't scale, and then don't scale.](https://derwiki.medium.com/do-things-that-dont-scale-and-then-don-t-scale-9fd2cd7e2156) Scalability 是软件过程中的一个概念，中文里叫做「可规模性」「可拓展性」或「可缩放性」，用于衡量软件系统能够处理大规模数据的能力。 作者认为，如今的编码成本变低了，人们不需要制作可规模性很好的软件来供所有人使用，人们可以用更简单的编码工具（当然是指 AI 辅助编程）构建只满足自己或身边人需求的软件。作者还认为，规模越大不代表越好，他用 Slack 群组举了个例子——在一个小于 100 人的群聊里，大家都彼此熟悉，而且很聊得来；如果规模增加，大家彼此都会变得陌生，不知道发出来的消息会有谁回复——增长不总是会让事情变得更好。作者还说，他以前还做过一个把自己的 Instagram 更新自动做成明信片发送给他母亲的软件，当他把这个软件开放给其他人注册使用后，他发现了很多滥用情况，自己还可能面临法律责任，于是关闭了新的注册，他觉得只满足一小部分人的需求就够了。 #### 我的观点 在以前，花时间写那种只能给一部分人用、自己用，甚至用完就丢的代码可能很可笑，但与上一个条目的观点不谋而合的是，AI 编程非常适合写那些「用完就丢」的代码，以及那些规模较小、需求明确的软件。作者也承认这种「Don't scale」的思想并不适合商业软件，我认为他的想法更像是「与其开个家具公司，不如只在自己家里锯木头」，我倒是很喜欢这种态度。 [#软件](/tags/软件/) [#设计](/tags/设计/) ## ⁂ · 星群 ### Lazy Brush 一个 JavaScript 库，提供了可以用于绘制平滑曲线和直线的工具。算法的原理很有意思，就像用链子拖着一个摩擦力很强的球画画一样。 ![](https://image.guhub.cn/uPic/2025/08/PixPin_2025-08-21_13-13-40.png) 访问：[Lazy Brush](https://lazybrush.dulnan.net) ### Hyperclay Hyperclay 允许 Web 开发者创建可以自修改的 HTML 文件，当开发者直接在网页中修改内容（比如勾选复选框、编辑表单……）时，Hyperclay 会直接把更改写入这个文件本身，保证页面刷新之后变更的内容依然保留。 作者说现代的 Web 应用往往需要维护复杂的基础设施才能实现数据持久层，比如数据库、API 和一个服务器，但静态网站又无法保留数据，所以他开发了 Hyperclay，允许开发者像玩粘土、使用实物一样保留 Web 应用中的数据。他认为个人博客、个人财务统计、开发日志等简单的 Web 开发需求都可以用「可塑的 HTML 文件」实现——你只需要直接在网页中修改内容，然后分发这个自动更新后的版本，而不需要读写数据库并支付高昂的服务费用。 Hyperclay 仍在早期开发阶段，你可以在官网通过电子邮件订阅更新，作者声称会在接下来的几天内开放 Early Access。订阅之后你会收到一封欢迎邮件，作者说如果回复邮件介绍自己，他会让那些真正感兴趣的人先试用 Hyperclay。不过我不打算去凑热闹了。 ![](https://image.guhub.cn/uPic/2025/08/SwgtYp.jpg) 访问：[Hyperclay](https://hyperclay.com) ## ∬ · 切片 - 暂时还养不了狗，但已经想好狗狗名字了！（有点像青春期少女对着暗恋对象幻想美好生活提前想好孩子的名字）——想养一只名字叫「耶树」的萨摩耶。 - 当我看完一期视频，发现里面出现的梗我一个都看不懂的时候，我的微笑难以抑制。 [^1]: 他在视频里好多次描述了那种开会的场景，每次听到我都觉得头皮发麻。我要是真的需要经常做这样的回报，我大概迟早会上吊自杀的。 [^2]: 我还能期待什么呢？毕竟那是社交媒体，大部分人只看得到情绪并做出本能反应，并没有能力理性地沟通。