距离上篇 文章 又过了三个月。这期间又发生了很多事，再写一篇博客同步下新的进展和最近自己的一些想法吧。
新的进展
首先同步下项目进展。总体来说目前 clice 已经达到了一个初步可用的状态。也就是所有核心的特性都已经实现，并且服务器架构稳定，可以在 LLVM 这样的项目上运行，不崩溃，并且具有合理的性能。clice 相比于 clangd 有非常多重要的架构创新，这些创新解决了 C++ 工具链长期以来的很多问题：
- 多进程架构：用来隔离 Clang 本身的 BUG 导致的内存泄漏问题和崩溃问题，编译进程（子进程）和查询进程（主进程）隔离，即使子进程崩溃了，主进程可以在优雅地拉起它的同时继续提供各种符号查询服务，不受任何影响。同时子进程也给编译任务优先级调度提供了更灵活的空间
- 编译上下文：用于处理项目中一个文件对应多个编译命令，或文件非自包含 (non self contained) 的情况。这是 clangd 从诞生之初就存在的问题，并且始终没有一个良好的解决方案。clice 终于彻底地解决了它，围绕着这个概念做了大量的工作（比如为了解决这个问题需要项目的依赖图，但是现有的依赖扫描不够快，用户体验不好，于是我们根据需求定制了一个快 10~100 倍的依赖扫描器）
- 模块编译图和共享编译缓存：实现了一个动态的模块编译图，模块依赖可以动态改变，不同模块之间可以共享编译依赖，支持并发编译模块，基于引用计数的取消机制，当一个模块不再被需要的时候可以优雅地取消编译，不额外占用任何 CPU。并且把 PCH 和 PCM 等编译缓存缓存在磁盘上，下次启动的时候可以快速恢复，大大加快了启动速度
- 基于 DFS 剪枝的伪模板实例化器，用于在模板语境下添加更智能的推断处理
这里还有很多其他的架构设计创新，就不一一介绍了，我创建了详细的文档 https://docs.clice.io/clice/design/overview 感兴趣的读者可以自行深入阅读。这也算是对两年前的自己有了一个交代，当初模糊的想法终于都完全落地了，中间也经历了漫长的探索和推翻的过程，很多之前的看法并不完全正确。在实现过程中，也顺便解决了 clangd 中长期存在的一些小 issue，也就是顺手的事情。我也会根据需要顺手解决上游 Clang 的一些 issue，比如解决了 Clang 长达十年来缺乏模板显式实例化位置信息的 问题。
既然架构问题已经解决了，接下来就是各个具体的 feature 实现。在这个阶段收集用户反馈很重要，而我也认为时机较为成熟了。于是我在 2026-07-19 发布了一个新的 pre-release 版本。可以直接在 VSCode 里面搜 clice VSCode 下载体验。开箱即用,无需额外的配置或者下载，与 clangd 的打包策略不同，我已经把 clice 二进制产物和 VSCode 插件捆绑在一起。并且支持 Windows/Linux/macOS x arm64/x64 一共 6 个平台，欢迎下载体验！
发版策略是，每个 main 分支的新提交会在 CI 产物里面上传构建产物。然后每日定时发布一个奇数版本号的 nightly 版本。等时机合适的话再由我主动选择偶数版本发布稳定版。
不过要强调的是，前段时间我一直在处理这些核心的架构问题，对于具体 feature 的支持没有花费太多精力，所以有很多 bug 是预期的（比如高亮不正确，代码补全结果不对，等等等）。实际上已经有一些群友尝试并提了很多相关的 issue。接下来的几个月，主要任务就是根据早期用户的反馈来修复常见的 issue。还有就是持续地优化性能，目前的性能只能说还算合理，但是相较于 clangd 还是有一些明显的延迟，这可能是因为我们多进程架构带来了额外的开销，但理论上这些开销应该是很小的，需要进一步深入的调查和优化。等时机成熟，我就会发布第一个正式版。到那时，我想 clice 就可以真正地取代 clangd，成为绝大多数用户的首选项。
目前这个阶段也是参与贡献的好时候，对于具体某个 feature 的修复和实现相对比较独立和简单，不需要对整个代码库有太深入的理解。而且经过我持续的优化，现在编译开发环境应该是可以一键配置的，上手成本很低。相关的文档也相对齐全。
新的愿景
最初产生编写一个新的 C++ 语言服务器的想法，大概也就是两年前的这个时候。现在还可以查到我当时尝试为 clangd 编写伪模板实例化器的 评论。也正是因为这件事，我才发现了 clangd 无人维护的现状。事实上这挺颠覆我当时的认知的，一个这么多开发者都在使用的开源软件居然无人维护？也就是从这里，我开始深入地了解开源软件的工作模式，背后复杂的社区构成。半年后，我发布了 一个新 C++ language server 的设计与实现，收获了很多关注和鼓励，看起来大家都想要一个新的语言服务器。当时预计大概 25 年应该就可以写得差不多并且实际用上，但项目的推进比我想象中慢得多。最主要的原因还是时间投入问题，从大三下到大四毕业，实际上我都处于一边实习、一边处理学校事务的状态，只能用剩下的空闲时间写 clice。而最开始的预期则是基于我一周七天完全投入的假设，但实际上只有一些周末的时间可以投入，粗略估计下慢了大概 3 倍时间也算是合理的了。
不过最近这个问题现在已经得到了极大的缓解。在今年 2 月份的时候我就开始尝试使用 opus4.6 这样的模型来辅助我编写 clice。最开始仍然是 human in the loop，我会去不断地调整 agent 编写的代码直到达到我的预期。随着使用的不断深入和模型的不断变强，尤其是 fable5 这样的顶级模型的出现，我发现很多时候我不再需要去干预 agent 编写代码。只需要详细地描述我的需求，然后等待它静静地完成就好。实际上目前 clice 最近的所有代码均为 fable5 编写的。到这里读者难免产生疑问：
- 即使是 fable5 这样的模型，真的能胜任 clice 这样的复杂项目吗？如何确保 agent 编写的代码是正确的？
答：我们不需要保证 agent 编写的代码是「正确」的，绝对的正确本身就是不可能的。我们只需要保证准确率在可接受的范围内即可。什么叫可接受的范围内呢？比如说，有些人编写的项目是要上线的，如果出问题会造成巨大的损失，那么显然他对代码的准确率要求是非常高的。别说 agent 写的代码了，就算是其他人类写的代码可能对他造成影响，他都会非常谨慎。那么我们可以观察到这部分程序员目前很大程度上是保留「古法」的，最信任的人可能只有自己。对于 clice 而言，作为一个离线工具，有一些 bug 其实完全可以接受，后面再修复就好了。事实上，即使是 Clang 这样的项目（在过去几乎完全由人类编写），也是经常会收到大量的 bug 报告的，对于一个复杂的项目来说完全没有 bug 本身就是不可能的。所以，clice 完全可以接受由 agent 编写的代码所产生的 bug，并且可以根据用户反馈不断地改进和修复。再者，我们可以尽可能地通过各种方式来提高 agent 编写出的代码的正确率（整体正确率），比如用 opus4.6 编写出的代码正确率可能只有 50%，换成 fable 就有 70%。然后通过一些自动化的工作流，比如说目前我的 agent 工作流就是 fable 编写完代码后，本地起三个 opus subagent review，然后开 PR。PR 上又有 GPT5.6 和 Coderabbit 来进行多轮 review，fable5 会定时拉取 review comment 解决，继续推送然后触发 review 流程，交互 review 个几轮。这么一套流程下来，再配合我精心设计的完善的 CI 流程，正确性可以来到 80%~90%。可以想象一下，如果是我自己来编写，上了一天班下班回来疲惫地写代码，能有这么高的准确率吗？大概是不能的。这样的准确率对于 clice 来说已经是绰绰有余了。
- 如果所有的代码都是 fable 写的了，那么还需要你做什么呢？
答：我尝试过让 fable 完全独立在这个代码库上工作，具体来说有一个 planner fable 来调度其他不同的 fable 长时间自主地进行编码、完成需求。代码很快就变得很乱了，即使是 fable 这样的顶尖模型，受限于模型上下文限制，对于项目整体的理解仍然是落后于对这个项目有两年的思考和 context 的人类的。这里有大量的隐性知识无法完全地通过代码的注释/项目的文档等其他方式表达出来，实际上如何防止文档过期本身就是件非常困难的事情了，因此我只维护了少量的架构核心文档给 AI 补充上下文，保证这部分文档是正确并且及时更新的。所以我的工作就是确保这个项目可以长期维护下去。如何做到这一点呢？有非常多的策略，比如精心设计合理的，多层次的，可验收的测试流程。目前我们有单元测试，集成测试，快照测试，冒烟测试，端到端测试总共五种测试流程，每种测试都是服务于不同的目的，并且为 AI 提供清晰的 feedback。根据我对 fable 工作的观察，这套测试流程发现了大量的错误，为它提供反馈并进行校准。而且像 fable 这样的模型 hack tests 的次数远远少于其他的模型，整体的效果非常好。我还负责把关项目的整体架构，如果你去观察 clice 的 commit 历史就会发现，这里有大量的 refactor commit，我会定期对项目做重构和清理，保持代码质量，剔除冗余代码（实际上我发现我非常喜欢干这样的事情）。典型的工作流程是周一到周五，我上班前给 fable 提一些需求，它自己干，一般要干很久因为要走前面提到的那套 CI 流程，典型的时间是 6 个小时，等下班后我简单看看关键部分没问题就合并。虽然相比于其他的模型，fable 的代码风格已经是非常好的了，但是仍然有一些更大的更本质的 refactor 可以清理和复用大量的代码，如果你不主动提示它的话，它是不会去做的。我会在周末进行这样的清理工作，确保项目可以持续运行下去，最后的代码甚至比人类写的更优雅，更不容易积累技术债务。
通过这样自动化的 agent 工作流，彻底地解决了时间不足的问题，甚至还有冗余，周末我只需要花很少的时间来清理下代码就好了。但是它在解放了生产力的同时带来了新的挑战，如果人类都不写代码了，那还要语言服务器做什么呢？尽管前面我们提到，在一些对准确性要求非常高的场景，依然会有人去「古法」编程，自己去写代码看代码。但随着模型能力的不断进步，这样的场景会越来越少，语言服务器的长期价值在不断降低。或者说任何在过去主要是为了方便人类操作而设计的产物，其价值都在不断地降低，各种 Web 交互，IDE …。这是时代的趋势，不可避免。在项目初期我可以凭借着好奇心和学习新知识的乐趣推动项目继续下去，但是现在已经到了后期。我是个特别需要「意义感」的人，如果长期来看这样的项目没有太大意义，那也没必要继续下去了。
实际上过去几个月中我一直在思考这个问题，在 agent 时代的 clice 中有一些简单的讨论，并没有详细展开。最近的话，有了一些更为深入的想法。首先，我们可以有一些基本的假定，比如像编译器这样的软件在中短期还是有价值的。我们不讨论任何「长期」的结论，AI 的发展完全是非线性的，人类的想象力还是太匮乏了，我们无法想象未来的生产形态是什么样的。事实上连一年内都无法想象，在去年的这个时候，我是完全无法预料到自己几乎不需要参与到 clice 的编码过程中去。仅仅基于目前的形势来看，像编译器这样的软件仍然存在价值，更进一步来说，围绕着编译器的一些基础设施，比如各种静态检查工具，文档提取生成工具，代码索引重构工具等，同样存在一定价值。
除此之外，还有如下的观察：
C++ 社区特别喜欢的一件事是「重复造轮子」，这件事情会发生在多种不同层面。编译器，标准库，构建系统，各种编译缓存工具，各种第三方库，用户代码。一个直接的结果就是经常一份代码需要在不同的层面都写一遍，典型的案例是 Windows 上 MSVC 编译环境的寻找，这套逻辑 Clang 写了一份（用于 clang-cl），构建系统写了一份（比如 xmake），用户的构建脚本又写了一份（因为有时候找不到），甚至连 Rust 的 cc-rs 为了编译 C++ 依赖也自己写了一份 ……。事实上这样造轮子完全没必要，只会让用户体验变得很差，并且浪费社区的精力，但是对于 C++ 来说由于这样那样的原因（主要是历史遗留），想要彻底统一已经非常困难了
这件事情的另外一个体现是 C++20 模块的支持，这是一个需要上下游紧密合作的例子。编译器，构建系统，各种编译缓存工具。目前来看，相关的设施仍然不太成熟 …… 推进起来十分缓慢。「模块在编译器前端是已解决的问题，在其他所有方面都是未解决的问题」
- LLVM/Clang 作为一个编译器项目最成功的地方在于其模块化的设计，以今天的视角来看或许没什么，但是如果把视角拨回到 20 年前，这可是相当先进的设计。这样模块化的设计可以将编译器作为 API 暴露使用，从而催生出各种各样的下游生态工具，比如 clang-tidy, clangd 和 clang-doc
- 但有一个问题，Clang 只提供了编译器这样的抽象，却没有提供「编译」这一过程本身的抽象。什么意思呢？编译器本身只是一个 driver，想要真正完成一个项目的编译往往需要构建系统的参与。可是目前的构建系统只服务于编译器/链接器这样的工具，正如前面提到的实际上还有一些基于 Clang 的工具，比如 index, tidy, doc 等等，它们的表现类似于编译器，但是现有的工具却无法调度它们。Clang 中同样缺乏这样的工具抽象，这就导致了类似的逻辑在多个不同代码里面重复，clangd 有自己的一套多线程调度索引机制，clang-tidy 没有官方的调度机制（实际上依赖 Python 来编写多进程相关的逻辑），clang-doc 又重复造了相关的轮子。由于 LLVM 是一个编译器社区，缺乏异步调度相关的投入，产生这样的结果并不令人奇怪。事实上一些更现代的编程语言，编译器和构建系统本身就不再区分，这使得上述的情况完全不会发生
- clice 表面上是一个新的 C++ 语言服务器，但是其核心是一个实时的，高效的编译调度器，根据输入的 CDB 文件进行调度，语言服务器只是这一个系统的一个消费者。这实际上就是 Clang 社区长期缺乏的抽象！在认识到其本质后，我们可以很轻松地基于这个核心延伸一些新的功能：
clice flags: 获取文件的编译命令等信息clice lint: 基于 Clang/clang-tidy 对整个项目进行 lint 检查，给出并应用可能的 fixclice format: 对整个项目进行 format，可以基于 clang-format (token stream based)，也可以结合我们获取到的语义信息进行更精准的 formatclice index: 将整个项目的代码索引成可分发的二进制文件，供特定的查询目的clice query: 基于前面的索引信息进一步提供各种查询结果，比如调用图/引用关系/包含关系/继承图等等等，可以返回结构化的信息 txt/markdown/json 供不同的消费者使用。比如给 agent 读取或者各种 render 渲染成图片clice doc: 提取整个项目的文档信息成结构化的格式，供外部使用，比如说渲染文档网站clice refactor: 提供一些方便的功能用于大规模重构，比如函数顺序重排，重命名clice modulize: 尝试对源码进行适当的 rewrite 来自动化迁移到 C++20 named module...
前面提到 C++ 的工具生态十分琐碎，需要自己组装大量工具才能有一个还算可以的体验。clice 处在一个巧妙的交叉位置上，一方面它通过源码集成 Clang 提供了语义分析的能力，另一方面实现了一个编译调度器又具备了部分构建系统（后端）的能力，从而能提供开箱即用的丰富的功能。不仅是功能丰富，连性能也可以更上一层楼。比如根据我的统计 clang-tidy 大概 10% 的时间在 parse，90% 的时间在 checks，而头文件这种复制粘贴的复用方式，导致里面的代码被不同的源文件重复检查了非常多次。但无论是 clang-tidy 还是构建系统对此都无能无力，因为它本质上需要一种跨 TU 的实时分析，要求不同分析进程之间可以互相通信，在过去完全分离的模型下想要实现这个很困难。但是对于 clice 来说就很简单，本身就是 master-worker 的架构，只需要子进程将 check 后的声明信息发送给主进程缓存，其他进程就能跳过这些缓存，从而大大加速 clang-tidy，快 3-5 倍不是幻想。clice 也将成为统一 C++ 工具链生态上前进的一小步。
这就是 clice 这个项目的新的愿景，这样一来，即使写代码的不再是人类，那么作为 agent 使用的工具，它也可以发挥其价值。更遥远的价值就无法确定了，我无法想象 AGI 如果真的实现会怎么样……
新的领域
我想起来去年的这个时候我还在纠结未来应该从事什么方向工作。如上图所示，我本科专业是化学，所以所有的编程知识都是我自学的。因为一些原因，主要是高中的时候同样是自学参加化学竞赛，没有取得我预期的结果，所以我对化学其实没太大兴趣了。但是转专业的话，课内成绩太差也是有一些困难，所以的话我就按照自己的兴趣来自学编程。自学的路径大概是这样的：
- 大一：我是从 C 语言开始学习的，最开始跟着教程下载了 visual studio 然后编写一些命令行程序。但是这太无聊了，大部分人在学习编程之前对编程的想象肯定是编写一些图形界面，因此我后面了解到可以通过 easyx 这一图形库实现绘图，于是我就尝试基于此编写一些小游戏。最后失败了，因为 C 语言缺乏数据结构抽象，于是我又得跟着教程写数据结构，vector/list 这种，当时我应该写出来了，但是很多 BUG。后面我又开始学习 QT，因为 QT 本身提供更丰富的绘图功能，而且还有标准库我可以不用自己从头搓轮子。然后我就基于 QT 写了一些小游戏，比如一个象棋游戏，但是一个人怎么下象棋？我就想给它添加网络联机功能，于是开始学习研究 socket 编程，UDP/TCP，多线程编程。还花很大功夫租了个云服务器，最后的话让朋友帮忙测试，成功远程联机了，不过游戏没继续做完。
- 大二上：我继续沿着兴趣深入学习，这段时间知乎上比较火的是图形学（大概 23 年）和游戏引擎，听说学这个以后很容易找工作，然后我也开始学。跟着经典的 Learn OpenGL 开始学习，调用 API 画一些简单的图像。不过这个教程我也没有做完，我只学习了前面如何绘图的部分，后面更深入的图形算法就没研究了。然后我开始考虑如何基于这部分 API 编写游戏引擎。我想要在 C++ 中实现 QT 的 signal-slot 不借助于 MOC，这样有了事件机制和绘图就可以写一些简单的游戏了。然后我就开始研究 C++ 模板元编程，花了很多时间终于使用 C++ 复现了 QT 的信号槽机制。然后我就基于前面学到的内容尝试编写一个「游戏引擎」，写一些小游戏，最后印象里是写了个简单的平台跳跃游戏，主要就是绘制人物动作和一些交互逻辑。后面我继续研究，了解到实现游戏引擎需要实现反射，那究竟什么是反射？这个对于当时的我也是非常难以理解，静态类型/动态类型等相关的概念我完全陌生，又开始补课学习了解其他各种不同的编程语言的实现机制。后面又发现反射和 AST 有一些关联，然后开始学习了解编译原理前端的相关知识。我也接触了一些编程语言理论 (PL) 和操作系统相关的知识。当时还想自己搓一个编译器/操作系统，编译器最后只写了点前端，操作系统也只是用 MinGW 为 x86 编写引导程序 (Bootloader)，然后在 VMWare 上成功启动。都是从零开始搓的，也没继续坚持下去 ovo。绕了这么一圈，什么都没写成，反倒是学了很多新知识，以及进一步精进 C++ 知识，实现这些「框架」需要对 C++ 的语言机制有深厚的了解
- 大二下：前面学习了很多 C++ 模板相关的知识，我也在知乎上发表了一些博客。很巧的是，有一位网友 blueloveTH 他有一个开源项目 pocketpy，是一个 Python 解释器。然后他想要为这个项目实现类似 pybind11 那样的便捷的 binding 接口。考虑到我有很多相关的经验，就问我有没有兴趣实现？我就说感觉挺有趣的，可以的，直接开始写吧，很激动。他当时就叮嘱说，这不是几天就可以写完的项目，为了能鼓励并督促项目最终能完成下去，他打算为这个项目申请 GSoC，这样的话最后完成了就有 1800$ 的奖金。我当时其实都不知道 GSoC 是什么，但是有钱拿还是很开心的，就按照他的指示最后也是成功申请了。事实证明他说的是对的，这个项目大概花了我三个月时间。虽然模板相关的知识我已经非常熟悉了，但这只是实现手段，还需要学习「领域知识」，跨语言交互的领域知识就是两种语言各自不同的机制。比如 Python 虚拟机的各种机制，GC 时间，变量生命周期。C++ 的各种机制，RAII，异常等等等。于是我又在成为 C++ 语言律师的道路上前进了一步 Σ(ﾟДﾟ)。拿到奖金后十分开心，毕竟是第一次靠编程赚到钱，而且还不是一笔小数目。以前一直用笔记本电脑编程，我直接买了两个 4K 显示器，宿舍放一个家里放一个，这样编程体验好多了。我的开发环境也从 visual studio 切换到了 VSCode + clangd，这样的环境配置对 C++ 开源项目更加友好
- 大三：大三的故事主要就是 Clang 和 clice 了，关于这部分的故事可以阅读 一个新 C++ language server 的设计与实现，中途还有一段实习学习了一些 LLVM 中端的知识
大三结束就要开始考虑找工作了，当时其实还是挺担心的。因为一方面我的专业是化学，另一方面其实「只会 C++」，以及对一些 Clang 相关的代码比较熟悉吧。这其实挺难求职的，主要是缺乏领域知识，可能会想找编译器相关的岗位？但是大多数其实要求的是编译器中后端，其实我没什么经验，而且很多卡学历简历都过不了。考虑到直接投简历对我来说比较困难，最后的话就在知乎上写了篇文章，看看网友能不能帮忙内推一下 ovo。也是运气比较好，得以去实习做 LLM Infra 推理，最后也是成功转正留在这里了。
LLM Infra 推理对我其实是完全陌生的领域。要学习哪些知识呢？深度学习，LLM, HPC，CUDA，体系结构。从前面我的自学经历可以发现，几乎没有和这些领域相关的内容。一方面还是压力挺大的，相当于要从头学，过去的知识几乎没什么可迁移的。另一方面其实我也挺感兴趣的，学习新的领域新的知识总是让我很激动。现在大概实习了一年吧，对这些领域有了一些了解，处理工作上的一些任务没太大问题。但总的来说还是挺菜的 (；ﾟДﾟ)。还是要继续学习，说实话可以学的太多了，除了推理相关的知识，横向可以继续学习训练，RL Infra 等相关的内容，纵向可以学习硬件知识，体系结构（计算，通信，储存）等等等。
目前我主要是对 Attention 算子比较熟悉。在过去写 CUDA 算子一直被认为是门槛比较高的工作，解决的办法就是通过 DSL 来进行抽象降低门槛。但现在 Agent 降维打击了这一问题，门槛再低还能有自然语言低吗？虽然目前 Agent 仍然无法完全独立地完成复杂的 Kernel 设计，受限于模型能力，但未来未必。实际上 DSL 我认为还有另外一个问题，就是选择合适的前端抽象很困难，尤其是在编程范式快速变化的情况下？抽象太高的话，很难控制底层细节，暴露给编译器的信息太少，编译器只能保守处理，很多优化没法做。抽象太低的话，DSL 意义何在呢？不过个人认为，如果把编译器看成一个搜索优化的过程，显然由于它是一个封闭集合优化能力总是有限的。如果能以合适的抽象，将优化决策暴露给 Agent，利用 Agent 强大的探索能力，可能相比于现在 Agent 直接写 kernel 效果会更好。此时编译器的角色变成了引导和验证。
新的开始
之前实习的时候由于公司离学校很近，坐十分钟地铁就到了，所以一直住在学校。现在毕业了，需要自己租房住了，花了一周时间找到了一个很满意的，现在住进来已经快一个月了。一切好像那么的自然而然，大学生活就这样结束了。其实没有太多感触，我的大学生活还是挺单调的。在出去实习之前，我的活动范围都仅限于学校内部，连学校大门都不怎么出去，出去的话也就是去吃校门口的麦当劳。大多数时候都在宿舍里面一个人写代码，在网上和群友聊天交流。后面开始实习了，活动范围稍微扩大到了学校附近的一些商圈吧，也线下认识了一些好朋友。
一个人在学校里无聊的时候就看看动画。我是上大学才开始看动画的，入坑作是《孤独摇滚》。大概是大一下吧，当时还是挺迷茫的。一方面本专业的课程不想学，心态上出了一些问题，另一方面编程也才刚入门，完全不知道以后要怎么样。机缘巧合之下看了孤独摇滚，深受感动，看了很多遍还是内心感觉有点惆怅。就开始寻找相似的作品，后面也看了很多其他优秀的作品。不过，每当我有点迷茫的时候我都会去看《孤独摇滚》，目前为止已经看了七八遍了。
原本我对未来的想法是，像很多现在开源社区工作的大神那样，靠自己的热爱，过着较为自由的生活。但未来连代码本身的意义是否存在，尚存疑问，这种开源生活当然也可能不再存在。我对 AI 的感受比较复杂：
- 一方面它极大地提高了我的效率，把我从各种繁琐的事情当中解放出来。比如学校里面的琐事，或者写代码时候的各种无聊过程。同样，新的变化也就意味着新的问题新的机遇新的可能性，作为一个技术爱好者，身处这样的时代，很难不想参与到其中去
- 另一方面，它也在不断拷问你所做事情的意义。引发了普遍的意义危机。当一切具体的 skill 都能交给 agent 去执行，那作为人类我们应该做些什么？现在该怎么样？随着 agent 能力的不断增强又该怎么样？未来又该怎么样？
或许很多问题只有时间能给出答案。未来会走向何方无人知晓，我们能做的就是保持好奇，持续学习，不断思考。
这就是这篇文章的全部内容了，这篇文章也算是对我学生时代的一个总结，在不同的层面上它有不同的意义。感谢阅读！