From f0d8a2bc5000653e28d2d96122a315ce4cf86b83 Mon Sep 17 00:00:00 2001 From: eltrac Date: Mon, 10 Aug 2026 00:16:54 +0800 Subject: [draft] update --- content/weekly/93.md | 32 ++++++++++++++++++++++++++++---- 1 file changed, 28 insertions(+), 4 deletions(-) diff --git a/content/weekly/93.md b/content/weekly/93.md index ed0ac6ce..c67e23bb 100644 --- a/content/weekly/93.md +++ b/content/weekly/93.md @@ -1,7 +1,7 @@ +++ title = "大脑充血 Vol.93" -subtitle = "" -tags = [] +subtitle = "《奥德赛》特辑" +tags = ["哲学","文学","互联网文化","创作","AI","编程"] date = 2026-08-03T19:51:15+08:00 draft = true toc = true @@ -9,7 +9,9 @@ endnotes = [] fedi = '' +++ -I say random stuff here. +本期周刊我将讨论《奥德赛》的三个版本：荷马史诗原著，Jorge Rivera-Herrans 改编的名为《EPIC》的音乐剧，以及由诺兰改编和导演《奥德赛》电影。荷马的《奥德赛》我其实只读了第一章，诺兰的电影我也只是有所耳闻，只有《EPIC》从头到尾看过、听过好几遍，所以可能有失偏颇。 + +总之，可以把这期周刊当作《奥德赛》特辑，不过还辅以一些 LLM、旧新闻和牢骚。希望读者周一愉快吧。 @@ -137,16 +139,38 @@ Last.fm 表示用户数据、功能、API 以及背后的开发团队都没有 1. 开发者的大部分时间都用来写代码。实际上有研究表明开发者只有 14% 的时间在写代码，其他时候基本都在开会、讨论方案和设计。 2. 写代码是瓶颈。如上所述，写代码只占开发者 14% 的时间，加速写代码不会让开发速度显著提升。 +3. “AI” 生成的代码行数足以证明其影响。比尔·盖茨说：用代码行数衡量生产力，就像是用重量衡量一架飞机。 +4. “AI” 平等地帮助所有人物、所有工程师。研究发现用 “AI” 做已经被理解、很熟悉的事情，提升的效率才会更高；此外从业经验与编写高效提示词的自信心呈负相关，研究发现 “AI” 延长了那些有经验的开源开发者实现代码的时间——我猜这是因为缺乏经验的人更容易忽略 LLM 生成代码中的模糊点，也不那么吹毛求疵。 +5. “AI” 能让一个开发者干十个的活儿。如前文所述，真实的软件开发还涉及协作，这才是最大的瓶颈。效率提升与人物的种类也有关。 +6. 让 “AI” 变得好用是开发者自己的事。“AI” 工具不是天然地好用，而且缺乏必要的指导。“AI” 可能是为数不多被企业花大价钱引进，却不知道如何最大化其价值的工具——这个我也有同感，LLM Agent 的使用方式模糊多变，企业不得不引入额度限制或额外教导使用方式，才能保证员工不因为「不会上下文管理」而烧掉太多的钱。事实不是开发者不会用，而是它本身就不好用。 +7. 表现很好的 “AI” 工具会自动被采用。“AI” 不总是很容易融入现有的工作流，需要结构化的调整。 +8. 用了生成式 “AI”，大企业就可以像初创企业一样快速地发行软件。人们对初创公司的期待不同，能够容忍更多的缺陷，而人们对大企业的可靠性有更严苛的要求。 + +作者的论述很完整了，所以请允许我插一句与原文无关的话：我发现几乎所有谈论 LLM 的人，无论持什么态度，几乎都避开了版权议题，除了 [Codeberg](https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html)。事实就是，LLM 生成的代码是从开源软件的源代码扒下来、拼凑起来的，而开源软件有授权协议，使用这些代码需要遵循协议。有的协议要求使用者自己也开放源代码，有的协议非常宽松，但也要求署名。无论原本的代码是什么协议，从 LLM 输出之后便不可知了，开源协议被洗掉了，==从此任何人都可以没有代价地使用他们本应该付出代价才能使用的代码==。这难道不可怕吗？为什么其他人都避开这个话题？为什么我数次在博客提出这个问题都没有人回应？是因为它太难解决了吗？ + +> 大型组织会花费大量时间在讨论无关紧要的琐事，但是真正重大的决议反而可以轻松过关这种现象。这是由于人对大议题较难有全面性的理解，故怕贸然提出异议，可能会失言；相反地，对于一些简单琐碎的小事，有相当的认识，因此意见特别多，造成组织在各事项上讨论所花费之时间，通常与事项本身的重要程度呈现反比。 + +{{< right "——[帕金森琐碎定理 - 维基百科](https://zh.wikipedia.org/zh-cn/%E5%B8%95%E9%87%91%E6%A3%AE%E7%91%A3%E7%A2%8E%E5%AE%9A%E7%90%86)" >}} + +以前还有画师会公开反对自己的作品被用于训练模型，如今他们的声音似乎也消失了。是成为科技进步的牺牲品了吗？真是令人唏嘘。我对企业不抱任何「突然良心发现」的期待，但开源社区至少应该开始讨论它。 ### 烤牛排不需要技巧 > [!note] 📜 > [Almost No Skill Required to Cook a Steak (Though You Probably Can't Make a Decent One)](https://blog.sydorets.com/en/posts/almost-no-skill-required-to-cook-a-steak/) +烤牛排不需要技巧，开火，淋上油，把牛排放上锅煎，一段时间后翻面就好。谁都能烤牛排，但不是所有人都能烤出好吃的牛排，甚至仅仅是烤出还行的牛排都很难。开发软件也逐渐变成烤牛排一样的活动，所有人都能写软件，但不是所有人都能把软件做好。 + +很有意思的比喻，我大概也会用这个比喻去说服持有不同观点的其他人。不过，我并不完全赞同。和上一节所述的观点一致，烤牛排仅仅是制作菜肴、宴请宾客的一小部分活动而已。烤牛排并不涉及到「所有人都想要一块好牛排，于是一起讨论怎么烤牛排」的活动。 + +LLM *或许*解决了怎么开火、用什么工具给牛排翻面更容易、怎么防止牛排粘锅的问题，但正如 Frederick Brooks 在《[No Silver Bullet](/article/engineering-perspective/)》里写的，这些仅仅是偶然性问题。对烤牛排而言，最难解决的是自发性问题（或者说内源性问题），怎么判断一块牛排到几分熟了、怎么知道多久翻面一次、怎么根据牛排的种类和大小调整烹饪方式等等。 + --- ## 漫步遐思 -## Footnotes +呃，我好像已经连续两周没有写这一节内容了，牢骚都在联邦宇宙上发完了，这之后的想法要么写成文章了，要么就根本没有出现。下班之后我就在读书，瘫在书桌前看剧，或者一边听《EPIC》一边乱逛。最近在看音乐剧《Little Shop of Horror》，或许你也会感兴趣？ + +不过说起来，我的精力的确变低了。读书变慢了，用来读书的时间也变少了。这其实不是因为上班太累太烦导致的，工作其实还算轻松，同事人也都很好。只是，我可能不适合在公司的环境下和人产生那么多的接触吧。尽管没有那么多接触，但我还是会感到社交压力，回到家就没什么力气了。每天只有早晨最有活力，可惜我这周有好几天睡太久了。或许会习惯这种生活的，会吧？ [^1]: Cast（演职人员）的意思，一般戏剧、音乐剧的演员都被称作卡司。 -- cgit v1.2.3