summaryrefslogtreecommitdiff
path: root/content
diff options
context:
space:
mode:
authorEltrac <hi@guhub.cn>2025-08-22 23:31:16 +0800
committerEltrac <hi@guhub.cn>2025-08-22 23:31:16 +0800
commit294eedd3d1b4b3114c4a6d229eeffb756de03af3 (patch)
treeb8754909a3bc9e69baf95a06c3f7d49d3cd92dd0 /content
parentec4d17e7b6f7efb1f45c362a912dc55656da3d46 (diff)
docs: update drafts
Former-commit-id: fdfdb05d40da81c24d91cb0e1d7587bc12dbfd7b
Diffstat (limited to 'content')
-rw-r--r--content/posts/weekly/43.md71
-rw-r--r--content/posts/极客死亡计划的设计哲学.md71
-rw-r--r--content/posts/英文罪名小赏.md12
3 files changed, 148 insertions, 6 deletions
diff --git a/content/posts/weekly/43.md b/content/posts/weekly/43.md
index f4b34fb4..a5da6e4f 100644
--- a/content/posts/weekly/43.md
+++ b/content/posts/weekly/43.md
@@ -1,22 +1,33 @@
---
title: 稻草人周刊 Vol.43
-subtitle:
-tags:
+subtitle:
+tags:
date: 2025-08-18T16:20:00
categories: 稻草人周刊
draft: true
toc: true
-banner:
+banner:
endnotes:
---
+<iframe allow="autoplay *; encrypted-media *;" frameborder="0" height="150" style="width:100%;max-width:660px;overflow:hidden;background:transparent;" sandbox="allow-forms allow-popups allow-same-origin allow-scripts allow-storage-access-by-user-activation allow-top-navigation-by-user-activation" src="https://embed.music.apple.com/cn/album/spaceland/1511525457?i=1511525461"></iframe>
+> The ceiling's spinning 
+>
+> And I think god is winning 
+>
+> 'Cause I see my hands shaking 
+>
+> And I cannot make them stop
<!--more-->
+{{< callout "欢迎加入本博客的 Telegram 频道「[大脑充血](https://t.me/geedeapro)」。" "🧠" >}}
+
## ↯ · 当下
--
+- 因为发现自己最近状态还没有完全恢复过来,注意力难以集中,于是试着把 Safari 阅读列表里的几篇文章打印了下来,结果惊奇地发现自己居然只用了半个小时就读完了之前需要一个小时才能读完的内容。这大概是因为纸张自带的沉浸感吧。
+ ![](https://image.guhub.cn/uPic/2025/08/printed-reading-materials.jpeg)
## ⋈︎ · 连接
@@ -45,7 +56,7 @@ endnotes:
我一直不相信「AI 会取代人类」之类的鬼话,原因很简单:**计算机程序没有主体性。**
-至少目前为止,AI 仍然需要人与之交互(提供输入)才能生成内容,它不能给自己写提示词,也没法判断生成出来的代码究竟能不能用。==回顾历史,取代人力的从来不是新技术,而是掌握了新技术的其他人;只要自己成为掌握新技术的人,就能成为取代别人的人。==
+至少目前为止,AI 仍然需要人与之交互(提供输入)才能生成内容,它不能给自己写提示词,也没法判断生成出来的代码究竟能不能用。==取代人力的从来不是新技术,而是掌握了新技术的其他人;只要自己成为掌握新技术的人,就能成为取代别人的人。==
### 如何清晰地发言
@@ -71,6 +82,51 @@ endnotes:
缺点也很明显,比如 like 和 literally 这两个词用得实在是太多了,这虽然能从侧面看出他不是在背稿,而是完全基于自己的理解在阐述,但我作为听众不需要看到他的努力,我只需要看到一出逻辑清晰、观点明确、语流连贯的演讲。
+### “用 AI 取代初级员工是我听过最蠢的事”
+
+{{< callout "文章链接:[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 完成工作?<br/>
+ Garman 认为:如果这么做了,那十年之后有企业里就不会有新人学到任何东西,你应该继续雇佣从大学里出来的孩子,并且教他们如何正确地构建软件、拆解问题并作出思考,就像你曾经做过的一样。
+2. 一些人认为:可以通过项目中 AI 生成的代码的占比衡量 AI 对项目的贡献程度。<br/>
+ Garman 认为:**好的代码往往是简短的**。尽管 AI 能够产生大量的代码,但那些代码也可能很烂。
+
+Garman 还给出了一些职业建议:在如今,学习一门应用面很窄的技能(narrow skills)已经不再能保证自己二三十年内还有饭吃了,现在人们应该**学着如何学习**,而不只是学习技能。
+
+#### 我的观点
+
+关于「学着如何学习」,这篇文章中并没有详细阐述,我想就算有的话,我也不愿意照搬别人的方法论。我的观点是,应该在做的过程中去学,而不是学完了再做。既然「做」就是学习的方式,那么一直做、一直尝试新的东西,就能一直保持学习,如此一来自己对「如何学习」就会有自己的经验和方法了。
+
+### AI 正在高速产出技术债务
+
+{{< callout "文章链接:[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]周刊中提到的这篇文章中的观点与我四个多月前表达过的观点是类似的,只是这位作者的语气更加平和,尽管他直接把那些自以为是者比做「不懂事乱刷卡的小孩子」——我承认,这是个更具侮辱性且更聪明的比喻。
+
+### 小而美就够了
+
+{{< callout "文章链接:[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」的思想并不适合商业软件,我认为他的想法更像是「与其开个家具公司,不如只在自己家里锯木头」,我倒是很喜欢这种态度。
+
## ⁂ · 星群
### Lazy Brush
@@ -100,6 +156,9 @@ Hyperclay 仍在早期开发阶段,你可以在官网通过电子邮件订阅æ
## ∬ · 切片
--
+- 一不小心又让周刊的 AI 话题含量超高了……
+- 暂时还养不了狗,但已经想好狗狗名字了!(有点像青春期少女对着暗恋对象幻想美好生活提前想好孩子的名字)——想养一只名字叫「耶树」的萨摩耶。
[^1]: 他在视频里好多次描述了那种开会的场景,每次听到我都觉得头皮发麻。我要是真的需要经常做这样的回报,我大概迟早会上吊自杀的。
+
+[^2]: 我还能期待什么呢?毕竟那是社交媒体,大部分人只看得到情绪并做出本能反应,并没有能力理性地沟通。
diff --git a/content/posts/极客死亡计划的设计哲学.md b/content/posts/极客死亡计划的设计哲学.md
new file mode 100644
index 00000000..1116e8a5
--- /dev/null
+++ b/content/posts/极客死亡计划的设计哲学.md
@@ -0,0 +1,71 @@
+---
+title: 「极客死亡计划」的设计哲学
+subtitle: 极客死亡计划书 III
+categories: 极客死亡计划书
+tags:
+ - Web
+ - 设计
+date: 2025-08-22T12:04:00
+draft: true
+toc: true
+---
+
+这个博客有过很多名字,相应地也有过很多外观设计,能被我记起来的有「考拉咖啡馆」「Isla」「Taco」等等。它们在我的脑中只有过一些模糊的印象,比如「考拉咖啡馆」有点像一块洁白的瓷砖,「Isla」……,「Taco」是纸张、照片和贴纸拼凑出来的内容。
+
+过去的我常常推翻整个网站的理念、设计、代码然后重头来过,一些文章也在这个过程中丢失了。我现在把那些行为当作是一个小孩子寻找自我的方式,一遍又一遍请求别人「重新认识我」。如今我对自己建立起来的形象终于有些满意了,我便想要回顾、总结一下那究竟是什么样子,至少从最浅显的方面开始。<!--more-->
+
+---
+
+{{< callout "本人并非设计师,仅仅分享一些业余见解<br/>本文内容包括网站的配色、排版、内容设计和交互设计等。" "💡" >}}
+
+
+
+---
+
+## 总则
+
+最近发现,对于个人来说,比起建立阐述完备的精确到每个细节的系统和文档,最重要的可能是明确且严格执行的「原则」。比如,我记笔记的原则是「用完即删」「提炼,永远不复制粘贴」和「保证清晰可理解」,除此之外我就不需要再耗费时间精力建立复杂的系统了。
+
+以下是我在折腾这个网站时有意或无意遵守的一些设计原则,现在整理成文字:
+
+### 1. 文字优先于一切
+
+对于注重用文字表达思想的博客网站来说,文字当然是最重要的。曾经加入过一个名为 [Essay](https://www.essay.ink) 的文字社区,主理人对于图片非常谨慎,因为图片一旦出现,就必然比文字更吸引注意力。一开始 Essay 的用户无法在发表的内容中添加图片,开放图片上传之后,图片默认是隐藏的,需要鼠标点击之后才能看到展开的图片——我很喜欢这种「文字优先」的做法。
+
+这一原则的具体实践有:
+
+1. 页面中不允许出现比文字更吸引注意力的元素,除了网站 Logo 等必要的元素。
+2. 装饰和个性化的设计,先从文字下手。
+ - 标题上的文字扭曲效果(实际上是模仿老旧复印机复印后产生的扭曲)[^1]
+3. 如果一段文字没必要出现,那就不要出现。
+
+### 2. 灰度优先于颜色
+
+我之前很喜欢折腾色彩搭配,但任何配色方案都有一个问题(至少对我来说是一个问题)——容易看腻。腻了之后就想换掉,然后再折腾一番。为了减少审美疲劳,网站使用了黑白的配色方案,如果要元素的主次,那么就通过调整灰度来实现(也可以用字体粗细来辅助)。
+
+比如:
+
+1. 网站的标题、文章标题、主体文字是黑色(当然不是纯黑)
+2. 文章的元信息(发布时间、标签、所属分类等)用统一的灰色
+3. 图标、标签等交互元素,默认显示灰色,鼠标悬浮其上或被点击时加深灰度
+4. [统计页面](/stats/) 的图表通过灰度的不同表现数量差异
+
+### 3. 减少空白
+
+由于元素默认靠左排列,如果元素本身的宽度比较小,右侧就会大面积留白。如果右边还有空间,而下方还有其他宽度较窄的元素需要显示,那就排在一行里。如果没有,那就尝试缩短元素的宽度以便能在一行中排列。
+
+![](https://image.guhub.cn/uPic/2025/08/PixPin_2025-08-22_13-35-46.png "首页导航条")
+
+![](https://image.guhub.cn/uPic/2025/08/PixPin_2025-08-22_13-35-22.png "页脚")
+
+### 4. 永远不随大流
+
+### 5. 在自己与用户之间找到平衡
+
+---
+
+## 想办法让读者更容易发现别的内容
+
+## 对于第三方库的使用
+
+[^1]: 这一效果来自 [endtimes.dev](https://endtimes.dev)
diff --git a/content/posts/英文罪名小赏.md b/content/posts/英文罪名小赏.md
new file mode 100644
index 00000000..fb64ede1
--- /dev/null
+++ b/content/posts/英文罪名小赏.md
@@ -0,0 +1,12 @@
+---
+title: 英文罪名小赏
+tags:
+ - English
+ - 词源学
+categories: 猫头鹰化石
+date: 2025-08-22T22:36:00
+draft: true
+toc: true
+---
+
+最近的闲暇时间大都被用在看《绝望的主妇》这部老剧上了,由于是一部非常狗血的剧,所以收获了不少有关犯罪的新单词,比如 arson(纵火)和 manslaughter(过失杀人)。一天晚上,一位语言学爱好者在洗澡的时候突然想起《猫头鹰化石》这个系列已经好久没有更新了,于是这篇文章就出现了。<!--more--> \ No newline at end of file