Daniel Lemire's blog
A Fast Immutable Map in Go
source
A Fast Immutable Map in Go
source
Daniel Lemire's blog
A Fast Immutable Map in Go
Consider the following problem. You have a large set of strings, maybe millions. You need to map these strings to 8-byte integers (uint64). These integers are given to you. If you are working in Go, the standard solution is to create a map. The construction…
Chips and Cheese
Embracing AI with Claude's C Compiler
#ChipAndCheese
Telegraph | source
(author: Chester Lam)
Embracing AI with Claude's C Compiler
#ChipAndCheese
Telegraph | source
(author: Chester Lam)
属于CYY自己的世界
Opus 4.6 级别的 AI 真的可以取代程序员吗？
背景
因为自 Opus 4.6 以来的 AI 能力快速提升，使得自己效率得到了充分提高，便开启好几个 AI Agent 同时进行各种各样的 Project（曾经梦想着毕业后带一个团队来干很多心里认为有趣的idea，结果在 AI 时代提前低成本实现了），有自己论文的完善，也有新论文的实现以及探索，还有一些大工程性质的玩具。然而，我很快发现，如果当前 AI 的上下文能力或者记忆能力不能在现在的 Baseline 上指数级提升，对复杂的任务依然只有加速能力而非完全的取代能力。
曾经在电视上看到过脑部受伤，海马体受损无法产生新记忆的人（如“笔记本男孩” 10分钟记忆人生），而现在的 AI 就有点类似于这样的可怜人。
AI 还记得多少曾经告诉过它的内容
每个体验过 Vibe Coding 的人应该都会感叹，在给出一个大 Markdown 的设计之后，AI 写代码和 Debug 的速度非常地快，甚至会用很多复杂的工具去 debug 最终完成目标。
但是，我却发现了一些问题，上下文本身就是一个巨大瓶颈。
例如我自己有几台机器在局域网里 share 同一个 NFS，但仅有特定机器有特定硬件（例如 AVX512 的支持，CUDA 的支持，ROCm 的支持等等），亦或是某个 benchmark 必须在某一台机器跑来获得一致的结果，我会告诉 AI 一个 Markdown 说执行某个任务的时候需要 ssh 到某个机器，但随着 Context Window 压缩几轮，往往这些会忘记，直到 AI 发现错误后自己通过种种方式阅读脚本与先前的 Prompt 才会想起来，最后我的解决方法就是把这些步骤都打包成脚本，这样 AI 只要执行脚本即可。
执行任务时这个问题更严重，我通常观测到 AI 去做了一个错误的解决问题的方向后会及时纠正，或让 AI 先去解决另一个更严重的问题，而过一段时间重新回来解决该问题时，AI 往往又会重新走一次这个错误的方向，直到自己发现问题 / 我纠正才会回到正确的路上。
针对这些问题其实有一些解法，例如开多个独立 Context 的 AI，有的负责编写，有的负责 Review，有的观测进度，让 AI 进行互相的沟通。但我觉得最靠谱的方法其实是：让未来 AI 更加能模拟人类大脑权重的不断更新，而非仅仅存储一个很小的 Context Window。
代码的维护能力
在一个大型项目中，代码的维护能力是十分重要的。经验丰富的人在写代码时往往每一行都有自己的 Consideration ，这些 Consideration 往往对 Maintainability 、 Performance 、 Function 进行了 Trade-off。比如，我们可能会考虑软件某一个位置是否需要一个 mutex_lock（我们未来会不会有PL层面的解决方案呢，类似现在的safe rust解决内存安全一样？），会考虑 CPU 的 LSU 设计与 Cache 配合会不会出现 Memory-Order Violation ，会考虑编译器某一个优化 Pass 会不会导致其他优化 Pass 失效或引入 Bug 等等。而在过去人类为主的现实开发中，往往的流程是：
1. 读透别人的代码 （git blame 找到对应的 commit，把整个 commit 读完）
2. 自己在试错中习得经验
3. 发送 PR / patch 的时候提醒与当前修改有相关的人进行 Review （git blame 找到相关人士）
而大量 Vibe Coding 改变的是：
1. 试错中习得的经验会随着 Context Window 填满而消失，维护时重复犯错。
2. 如果与当前修改有相关的人是让 AI 代劳完成的代码，自己并不清楚当时写代码的 Consideration ，那么会遇到一个非常恐怖的问题：Review 并不来自一个过去经验丰富的人，并没有指出其问题的能力。
未来的就业市场的工业界 / 学术界会如何变化
我认为，AI 固然能在很多事情上提升效率（例如自动进行设计空间探索，优化性能，Debug等等）。但人理解 AI 在做的事情，并提供巨大的 Context 能力依然必不可少。否则很容易发生不停的重构，就像许多企业小团队换一拨人就会对代码进行一次重构一样。同时，这些基础软硬件提供了现代计算机的基座，可靠性与确定性仍然是必不可少的一部分，在 Context Window 无法指数级增加前，我们不应该完全信赖 AI 提供的能力，否则我们往往无法从过去探索的经验中习得教训，而这一部分工作，只要 Context Window 无法大幅增加，依然需要能跟上 AI 节奏的人的脑力来辅助完成。在这种情况下，我也认为 企业对人力贡献评估需要的也许不是 OKR，而是评估一个人在 long-term 下提高效率与降低风险的贡献，同时能否提出新的思路来让企业生出更好的产品。
而且，如果我是企业管理，其实相比裁员，我会更愿意用 AI 提效后发展更多的业务，或者在已有业务上尽快追上甚至超越竞争对手，做更加先进的产品，否则这就是员工已有 Context 的巨大损失。至少目前 Context Window 的限制，让 AI 提效的前提依然是了解代码的人来驾驭。
但是对于新的 Junior ，我确实持有一些悲观态度。因为我看到了一些朋友会为了完成上级任务去使用 AI 完成自己完全不熟悉的东西，似乎自己成了一个 完全 不理解 AI 在做什么的转发器。又容易因为其自身的完全不了解，对 AI 的输出没有任何的判断能力。而过去，这样的人往往拿不到行业的入场券，而现在，也许他们在 AI 的加持下获得了一定的捡漏空间。
说完了工业界，那学术界呢？因为大多数情况下，学术界编写的代码通常只使用一次，对 long-term maintainability 没有要求，甚至往往代码还不一定做到了 General ，只要方法理论上是 General 的即可，AI 确实能起到大幅的加速效果。但我担心这个世界将出现劣币驱逐良币，认真 review AI 生成的代码，保证代码与论文中的描述一致的人，在数篇数的学术市场中被淘汰。
而对于学术圈，我一个很大的建议是：去优先做那些只有自己接触到的 Context 才会想到的 idea，如果只是看到一个很多人都能看到的问题，并提出一个 AI 都能分析出来的解法，非常容易 idea 撞车，也非常容易在激烈竞争中被随机淘汰。在我看来，科研的意义是 push the human race forward，而不是去抢占谁最先做出来某一个大家很容易发现的解决方法。如果自己不是全世界为数不多发现这个问题，并且能想到解决方法，并找到一个好场景的人，那么请慎重去做。
未来的 AI 能力
我认为上下文压缩、RAG 等等技术不应该是面对这些问题的终极解决方案。
暴论：现有 LLM Benchmark 缺失的部分正是人类还能高效进行的智力劳动部分。因为现有的 Benchmark 往往只评估 AI 能不能完成某一件事情，而难以评估 Long-term 下 AI 执行多个任务的速度、能力以及 potential 带来的 Bug 、 Security 等等这些短时间难以量化的能力。
而人脑大概是什么样呢？我们接触到一个信息，脑子很容易直接联想起这个信息有关联的一切，直接完成推理，而不是一个 explicit 的插入数据库与搜索的过程。这就有点像，我们接触到的信息直接改变了模型的权重。也许未来是否可能，每个人都有一个客制化的 AI，是在已有的模型权重上叠加了一层客制化的 diff，在实践中不断修改自身的权重，最终变得更像人类。
我想随着大家在 Opus 4.6 这样的模型中不断踩坑，发现同样问题的人越多，我们应该更快能迎来全新的 AI 能力与新的 Context 管理方式。
同样，我们如果在现有 AI 能力的基础上研究更多的类似 AGENTS.md 、RAG 作为 work-around ，是否也可以同样应用于海马体受损的可怜人，让他们有更好的生活质量。
source
(author: Yangyu Chen)
Opus 4.6 级别的 AI 真的可以取代程序员吗？
背景
因为自 Opus 4.6 以来的 AI 能力快速提升，使得自己效率得到了充分提高，便开启好几个 AI Agent 同时进行各种各样的 Project（曾经梦想着毕业后带一个团队来干很多心里认为有趣的idea，结果在 AI 时代提前低成本实现了），有自己论文的完善，也有新论文的实现以及探索，还有一些大工程性质的玩具。然而，我很快发现，如果当前 AI 的上下文能力或者记忆能力不能在现在的 Baseline 上指数级提升，对复杂的任务依然只有加速能力而非完全的取代能力。
曾经在电视上看到过脑部受伤，海马体受损无法产生新记忆的人（如“笔记本男孩” 10分钟记忆人生），而现在的 AI 就有点类似于这样的可怜人。
AI 还记得多少曾经告诉过它的内容
每个体验过 Vibe Coding 的人应该都会感叹，在给出一个大 Markdown 的设计之后，AI 写代码和 Debug 的速度非常地快，甚至会用很多复杂的工具去 debug 最终完成目标。
但是，我却发现了一些问题，上下文本身就是一个巨大瓶颈。
例如我自己有几台机器在局域网里 share 同一个 NFS，但仅有特定机器有特定硬件（例如 AVX512 的支持，CUDA 的支持，ROCm 的支持等等），亦或是某个 benchmark 必须在某一台机器跑来获得一致的结果，我会告诉 AI 一个 Markdown 说执行某个任务的时候需要 ssh 到某个机器，但随着 Context Window 压缩几轮，往往这些会忘记，直到 AI 发现错误后自己通过种种方式阅读脚本与先前的 Prompt 才会想起来，最后我的解决方法就是把这些步骤都打包成脚本，这样 AI 只要执行脚本即可。
执行任务时这个问题更严重，我通常观测到 AI 去做了一个错误的解决问题的方向后会及时纠正，或让 AI 先去解决另一个更严重的问题，而过一段时间重新回来解决该问题时，AI 往往又会重新走一次这个错误的方向，直到自己发现问题 / 我纠正才会回到正确的路上。
针对这些问题其实有一些解法，例如开多个独立 Context 的 AI，有的负责编写，有的负责 Review，有的观测进度，让 AI 进行互相的沟通。但我觉得最靠谱的方法其实是：让未来 AI 更加能模拟人类大脑权重的不断更新，而非仅仅存储一个很小的 Context Window。
代码的维护能力
在一个大型项目中，代码的维护能力是十分重要的。经验丰富的人在写代码时往往每一行都有自己的 Consideration ，这些 Consideration 往往对 Maintainability 、 Performance 、 Function 进行了 Trade-off。比如，我们可能会考虑软件某一个位置是否需要一个 mutex_lock（我们未来会不会有PL层面的解决方案呢，类似现在的safe rust解决内存安全一样？），会考虑 CPU 的 LSU 设计与 Cache 配合会不会出现 Memory-Order Violation ，会考虑编译器某一个优化 Pass 会不会导致其他优化 Pass 失效或引入 Bug 等等。而在过去人类为主的现实开发中，往往的流程是：
1. 读透别人的代码 （git blame 找到对应的 commit，把整个 commit 读完）
2. 自己在试错中习得经验
3. 发送 PR / patch 的时候提醒与当前修改有相关的人进行 Review （git blame 找到相关人士）
而大量 Vibe Coding 改变的是：
1. 试错中习得的经验会随着 Context Window 填满而消失，维护时重复犯错。
2. 如果与当前修改有相关的人是让 AI 代劳完成的代码，自己并不清楚当时写代码的 Consideration ，那么会遇到一个非常恐怖的问题：Review 并不来自一个过去经验丰富的人，并没有指出其问题的能力。
未来的就业市场的工业界 / 学术界会如何变化
我认为，AI 固然能在很多事情上提升效率（例如自动进行设计空间探索，优化性能，Debug等等）。但人理解 AI 在做的事情，并提供巨大的 Context 能力依然必不可少。否则很容易发生不停的重构，就像许多企业小团队换一拨人就会对代码进行一次重构一样。同时，这些基础软硬件提供了现代计算机的基座，可靠性与确定性仍然是必不可少的一部分，在 Context Window 无法指数级增加前，我们不应该完全信赖 AI 提供的能力，否则我们往往无法从过去探索的经验中习得教训，而这一部分工作，只要 Context Window 无法大幅增加，依然需要能跟上 AI 节奏的人的脑力来辅助完成。在这种情况下，我也认为 企业对人力贡献评估需要的也许不是 OKR，而是评估一个人在 long-term 下提高效率与降低风险的贡献，同时能否提出新的思路来让企业生出更好的产品。
而且，如果我是企业管理，其实相比裁员，我会更愿意用 AI 提效后发展更多的业务，或者在已有业务上尽快追上甚至超越竞争对手，做更加先进的产品，否则这就是员工已有 Context 的巨大损失。至少目前 Context Window 的限制，让 AI 提效的前提依然是了解代码的人来驾驭。
但是对于新的 Junior ，我确实持有一些悲观态度。因为我看到了一些朋友会为了完成上级任务去使用 AI 完成自己完全不熟悉的东西，似乎自己成了一个 完全 不理解 AI 在做什么的转发器。又容易因为其自身的完全不了解，对 AI 的输出没有任何的判断能力。而过去，这样的人往往拿不到行业的入场券，而现在，也许他们在 AI 的加持下获得了一定的捡漏空间。
说完了工业界，那学术界呢？因为大多数情况下，学术界编写的代码通常只使用一次，对 long-term maintainability 没有要求，甚至往往代码还不一定做到了 General ，只要方法理论上是 General 的即可，AI 确实能起到大幅的加速效果。但我担心这个世界将出现劣币驱逐良币，认真 review AI 生成的代码，保证代码与论文中的描述一致的人，在数篇数的学术市场中被淘汰。
而对于学术圈，我一个很大的建议是：去优先做那些只有自己接触到的 Context 才会想到的 idea，如果只是看到一个很多人都能看到的问题，并提出一个 AI 都能分析出来的解法，非常容易 idea 撞车，也非常容易在激烈竞争中被随机淘汰。在我看来，科研的意义是 push the human race forward，而不是去抢占谁最先做出来某一个大家很容易发现的解决方法。如果自己不是全世界为数不多发现这个问题，并且能想到解决方法，并找到一个好场景的人，那么请慎重去做。
未来的 AI 能力
我认为上下文压缩、RAG 等等技术不应该是面对这些问题的终极解决方案。
暴论：现有 LLM Benchmark 缺失的部分正是人类还能高效进行的智力劳动部分。因为现有的 Benchmark 往往只评估 AI 能不能完成某一件事情，而难以评估 Long-term 下 AI 执行多个任务的速度、能力以及 potential 带来的 Bug 、 Security 等等这些短时间难以量化的能力。
而人脑大概是什么样呢？我们接触到一个信息，脑子很容易直接联想起这个信息有关联的一切，直接完成推理，而不是一个 explicit 的插入数据库与搜索的过程。这就有点像，我们接触到的信息直接改变了模型的权重。也许未来是否可能，每个人都有一个客制化的 AI，是在已有的模型权重上叠加了一层客制化的 diff，在实践中不断修改自身的权重，最终变得更像人类。
我想随着大家在 Opus 4.6 这样的模型中不断踩坑，发现同样问题的人越多，我们应该更快能迎来全新的 AI 能力与新的 Context 管理方式。
同样，我们如果在现有 AI 能力的基础上研究更多的类似 AGENTS.md 、RAG 作为 work-around ，是否也可以同样应用于海马体受损的可怜人，让他们有更好的生活质量。
source
(author: Yangyu Chen)
JSON and C++26 compile-time reflection: a talk
The next C++ standard (C++26) is getting exciting new features. One of these features is compile-time reflection. It is ideally suited to serialize and deserialize data at high speed. To test it out, we extended our fast JSON library (simdjson) and we gave a talk at CppCon 2025. The video is out on YouTube.
iframe (www.youtube.com)
Our slides are also available.
source
Chips and Cheese
Microbenchmarking Chipsets for Giggles
#ChipAndCheese
Telegraph | source
(author: Chester Lam)
Microbenchmarking Chipsets for Giggles
#ChipAndCheese
Telegraph | source
(author: Chester Lam)
又到了植树节！想和大家一起再种一颗 tgcn 频道树🌳！（这次有更多功能可以玩哦~）
这里是 Easton Man's Channel，是 @ziyao233channel 的树枝 🌿 在频道树的第 4 层~
（如果你也有公开频道，想成为这个频道的树叶的话，就点击下面的「成为树叶」吧！ > <）
这里是 Easton Man's Channel，是 @ziyao233channel 的树枝 🌿 在频道树的第 4 层~
（如果你也有公开频道，想成为这个频道的树叶的话，就点击下面的「成为树叶」吧！ > <）
Daniel Lemire's blog
Prefix sums at tens of gigabytes per second with ARM NEON
source
Prefix sums at tens of gigabytes per second with ARM NEON
source
Daniel Lemire's blog
Prefix sums at tens of gigabytes per second with ARM NEON
Suppose that you have a record of your sales per day. You might want to get a running record where, for each day, you are told how many sales you have made since the start of the year. day sales per day running sales 1 10$ 10 $ 2 15$ 25 $ 3 5$ 30 … Continue…
属于CYY自己的世界
AI 提高了效率，喜欢打开黑盒的 hobbyist 怎么办
背景
我很幸运我是一个在很小的时候就找到了自己喜好的人——探索世界，打开一个个我曾经认为的黑盒子。
我也很幸运，从小学就会自己折腾计算机，翻看 Windows 的系统文件，自己学编程，组装电脑，硬件 Mod，折腾 Linux 桌面，甚至到最后学机器人参加比赛，以及玩 Arduino 单片机，这些事情给了我计算机以及程序逻辑的最早启蒙。
我同样很幸运，在高中的时候开始学 OI，最后拿到省一等奖参加自主招生，选了省一等奖可以满足前两个专业志愿的学校，再到后来继续参加 ICPC 比赛拿到 EC-Final 银牌，NSCSCC 比赛做出能跑 Linux 的五级流水双发射 CPU，再到后来当一生一芯助教，在学校给本科的 CPU 和 OS 课程实验做教学改革，在 PLCT 成为 GCC、Linux Kernel 等众多开源项目的贡献者，再到后来去到香山以及 Intel 实习。这些经历让我一直走在探索计算机底层的算法与基础软硬件的道路上，让我不停打开计算机的黑盒子，并成为一个自己能发现问题并改进现有软硬件架构的人。这些经历也许本来已经奠定了一生的方向。
可是最近看到的 Claude Opus 4.6 以及 GPT-5.4 的能力，却让我开始思考，不仅仅是 AI 的能力对从业者的影响，更是我们这样的 hobbyist 在未来应该怎么办。
AI 能力的发展
ChatGPT 出现的2022年底，恰好是我在学校当操作系统课程助教的期末改作业时间。由于是自己教改的实验自然对问题回答情况一清二楚，在那个时候，AI 针对这样很简单的问题还有相当严重的幻觉，大量的上下文错误（比如说非 x86 架构如何切换页表冒出来一个 CR3 寄存器的答案）。在那个时候我还尚且觉得， AI 距离走向实用还有一定的距离，但是对于 common sense 问题，它给出的回答结合自己去网上搜索的 validation 已经能够解答很多问题。
可是到了后来，事情越来越无法控制。我一直是一个 GitHub Copilot 使用者，4年来亲眼见证了：
● 2023年，它帮我写个 Verilog 连线都能写错，最后还是得自己写个小脚本，但是显而易见小函数的代码补全省了我很多的工作量。
● 2024年，Verilog 连线不是困难，大型开源软件还能帮我 Hint 出我不熟悉的 API，让我事半功倍。帮我改改论文更是不在话下。
● 2025年，它能帮我独立实现一个小的功能 Feature。
● 2026年，Claude Opus 4.6 开始，它可以对着我给的一个 Markdown 写出几千行代码，然后转一晚上完成测试。还可以自己打 CPU 性能计数器，打 CPU RTL 波形图，甚至反馈流程比我还快，还不用休息。
而我们自己去思考如何在一个大型项目插入想要的 feature，调试时打 stack dump，打印中间结果，抓 RTL 波形这些事情，最终对于我们这些 hobbyist 来说，每一次的经历不仅仅是工作本身，更是打开了我们所想要探索的黑盒子的过程，让我们了解更多，收获更多，自己的能力也随之提升。
而现在， AI 的出现让这些事情已经开始出现转机。甚至分析性能的 Agent 这样非常依赖经验和大量知识的事情都已经能够被 AI 取代。如果这个时候，出于目标导向来说，我把这样的活全部 Offload 给 AI，它干的不仅比我快还比我好，只是我在这个事情中什么都没有学到。
思考
我不禁思考，我们这样的系统工科猪在未来何去何从呢？本科毕业的时候我常听到许多人熟练了某种技能，比如说 CPU uArch、NoC 甚至 PCI-E 协议本身，就可以因为这样人才的稀缺性拿到很高的薪水。但是现在，我们所掌握的知识已经完全失去了小众性，失去了未来因为这种特殊经历与 HR 议价的权利。同时，在任务压力下，从业者很有可能因为自己已经无法超过 AI 的速度，而不再是以前那样的自己工作越多经验越多，而是直接把这些事情 Offload 给 AI 然后研究自己更喜欢研究的事情，AI 跑了几个小时帮我们找到了功能 Bug 甚至性能 Bug 然后自己修复，我们就完成了目标。
自己的许多创新想法正是因为自己有了这种经验，脑子里才能把零散的知识联系起来，做出创新。而在 AI 时代，如果我们给 AI 的 Prompt 仅仅知识完成任务，AI 也仅仅不废话地给我们一个最终结果以及思考思路。而若没有对中间结果发散地思考、细看，进而迸发出新的科研 idea，我们的创新会不会在这个过程中消亡呢？
自救
也许，到了思考自救的时候。我个人觉得这样的大势本身已经不可避免，自然最好的办法是 live with it。也许正是人有了更多的时间，因此可以更高效地探索一个自己甚至所属组织先前不熟悉的方向，结合自己已有的专业知识的摩擦，更容易迸发出创造性 idea，而不是对着几个 percent 的现存量化指标在那不停内卷。
同时，我觉得这也许将迎来经济模式的重大变革。也许未来的社会对螺丝钉的需求将逐步降低，因为那些事情本质已经可以 Offload 给 AI，进而中高端的知识密集型就业市场大概率会受到很大的冲击。
但是，我们生而为人，我们能够理解自己的需求，我们能够以自己主观的判断评价事物。而 AI 带来的是所有事情的门槛降低，包括产品化的软件、影视、音乐、动漫、游戏，结合每个人都可以在 AI 的加持下获得专业知识，对自然科学领域的所有问题进行低成本咨询，并将可计算的问题在自己的计算机上生成一个数学模型进行研究，那么自己能够在生活中以人的主观感受发现问题，解决问题的创新很大概率会大开花，且更容易落在每个人头上。正如同自己现在看到开源项目自己使用中存在的不足就想去提一个 PR 一样。因此，我给自己定的初级目标是：更加关注自己主观感受中不足的细节，当遇到可改进的问题或者想做成科技/艺术创作时，尽快行动。
希望5-10年后再来看这篇博客，我会感谢当时那个周末没烧多少 Token，慢下来的思考。
source
(author: Yangyu Chen)
AI 提高了效率，喜欢打开黑盒的 hobbyist 怎么办
背景
我很幸运我是一个在很小的时候就找到了自己喜好的人——探索世界，打开一个个我曾经认为的黑盒子。
我也很幸运，从小学就会自己折腾计算机，翻看 Windows 的系统文件，自己学编程，组装电脑，硬件 Mod，折腾 Linux 桌面，甚至到最后学机器人参加比赛，以及玩 Arduino 单片机，这些事情给了我计算机以及程序逻辑的最早启蒙。
我同样很幸运，在高中的时候开始学 OI，最后拿到省一等奖参加自主招生，选了省一等奖可以满足前两个专业志愿的学校，再到后来继续参加 ICPC 比赛拿到 EC-Final 银牌，NSCSCC 比赛做出能跑 Linux 的五级流水双发射 CPU，再到后来当一生一芯助教，在学校给本科的 CPU 和 OS 课程实验做教学改革，在 PLCT 成为 GCC、Linux Kernel 等众多开源项目的贡献者，再到后来去到香山以及 Intel 实习。这些经历让我一直走在探索计算机底层的算法与基础软硬件的道路上，让我不停打开计算机的黑盒子，并成为一个自己能发现问题并改进现有软硬件架构的人。这些经历也许本来已经奠定了一生的方向。
可是最近看到的 Claude Opus 4.6 以及 GPT-5.4 的能力，却让我开始思考，不仅仅是 AI 的能力对从业者的影响，更是我们这样的 hobbyist 在未来应该怎么办。
AI 能力的发展
ChatGPT 出现的2022年底，恰好是我在学校当操作系统课程助教的期末改作业时间。由于是自己教改的实验自然对问题回答情况一清二楚，在那个时候，AI 针对这样很简单的问题还有相当严重的幻觉，大量的上下文错误（比如说非 x86 架构如何切换页表冒出来一个 CR3 寄存器的答案）。在那个时候我还尚且觉得， AI 距离走向实用还有一定的距离，但是对于 common sense 问题，它给出的回答结合自己去网上搜索的 validation 已经能够解答很多问题。
可是到了后来，事情越来越无法控制。我一直是一个 GitHub Copilot 使用者，4年来亲眼见证了：
● 2023年，它帮我写个 Verilog 连线都能写错，最后还是得自己写个小脚本，但是显而易见小函数的代码补全省了我很多的工作量。
● 2024年，Verilog 连线不是困难，大型开源软件还能帮我 Hint 出我不熟悉的 API，让我事半功倍。帮我改改论文更是不在话下。
● 2025年，它能帮我独立实现一个小的功能 Feature。
● 2026年，Claude Opus 4.6 开始，它可以对着我给的一个 Markdown 写出几千行代码，然后转一晚上完成测试。还可以自己打 CPU 性能计数器，打 CPU RTL 波形图，甚至反馈流程比我还快，还不用休息。
而我们自己去思考如何在一个大型项目插入想要的 feature，调试时打 stack dump，打印中间结果，抓 RTL 波形这些事情，最终对于我们这些 hobbyist 来说，每一次的经历不仅仅是工作本身，更是打开了我们所想要探索的黑盒子的过程，让我们了解更多，收获更多，自己的能力也随之提升。
而现在， AI 的出现让这些事情已经开始出现转机。甚至分析性能的 Agent 这样非常依赖经验和大量知识的事情都已经能够被 AI 取代。如果这个时候，出于目标导向来说，我把这样的活全部 Offload 给 AI，它干的不仅比我快还比我好，只是我在这个事情中什么都没有学到。
思考
我不禁思考，我们这样的系统工科猪在未来何去何从呢？本科毕业的时候我常听到许多人熟练了某种技能，比如说 CPU uArch、NoC 甚至 PCI-E 协议本身，就可以因为这样人才的稀缺性拿到很高的薪水。但是现在，我们所掌握的知识已经完全失去了小众性，失去了未来因为这种特殊经历与 HR 议价的权利。同时，在任务压力下，从业者很有可能因为自己已经无法超过 AI 的速度，而不再是以前那样的自己工作越多经验越多，而是直接把这些事情 Offload 给 AI 然后研究自己更喜欢研究的事情，AI 跑了几个小时帮我们找到了功能 Bug 甚至性能 Bug 然后自己修复，我们就完成了目标。
自己的许多创新想法正是因为自己有了这种经验，脑子里才能把零散的知识联系起来，做出创新。而在 AI 时代，如果我们给 AI 的 Prompt 仅仅知识完成任务，AI 也仅仅不废话地给我们一个最终结果以及思考思路。而若没有对中间结果发散地思考、细看，进而迸发出新的科研 idea，我们的创新会不会在这个过程中消亡呢？
自救
也许，到了思考自救的时候。我个人觉得这样的大势本身已经不可避免，自然最好的办法是 live with it。也许正是人有了更多的时间，因此可以更高效地探索一个自己甚至所属组织先前不熟悉的方向，结合自己已有的专业知识的摩擦，更容易迸发出创造性 idea，而不是对着几个 percent 的现存量化指标在那不停内卷。
同时，我觉得这也许将迎来经济模式的重大变革。也许未来的社会对螺丝钉的需求将逐步降低，因为那些事情本质已经可以 Offload 给 AI，进而中高端的知识密集型就业市场大概率会受到很大的冲击。
但是，我们生而为人，我们能够理解自己的需求，我们能够以自己主观的判断评价事物。而 AI 带来的是所有事情的门槛降低，包括产品化的软件、影视、音乐、动漫、游戏，结合每个人都可以在 AI 的加持下获得专业知识，对自然科学领域的所有问题进行低成本咨询，并将可计算的问题在自己的计算机上生成一个数学模型进行研究，那么自己能够在生活中以人的主观感受发现问题，解决问题的创新很大概率会大开花，且更容易落在每个人头上。正如同自己现在看到开源项目自己使用中存在的不足就想去提一个 PR 一样。因此，我给自己定的初级目标是：更加关注自己主观感受中不足的细节，当遇到可改进的问题或者想做成科技/艺术创作时，尽快行动。
希望5-10年后再来看这篇博客，我会感谢当时那个周末没烧多少 Token，慢下来的思考。
source
(author: Yangyu Chen)
