2022年末到2023年初，ChatGPT爆火，我开始用LLM来辅助写脚本。虽然相当好用，但是价格较贵，且个人付款始终是问题，应用也就仅限于简单的代码问题了。2024年末到2025年初，DeepSeek爆火。虽然它的回答很多时候不那么令人满意，且增加了思考模式后，得到结果的时间总是会慢一拍，但是，它便宜呀！在一年之后，DeepSeek依然是输出结果还不错的前提下，Token最便宜的模型之一。年初充了50块，到现在刚好差不多一年，还剩27… 因此，我就更大胆地将LLM用在了各种其他方面。
从“奢侈品”到“日用品”
如果前两年使用 AI 还像是偶尔尝鲜的奢侈品，那么今年它已经彻底变成了我工作流中的日用品。DeepSeek 低廉的价格让我可以毫无心理负担地用它处理各种任务：从简单命令的查询，到整个脚本的重构，再到完全陌生领域的探索。虽然不一定达到了效率的飞跃，但是它确实扩展了我的能力边界，让我能做之前只有概念但从未实践的工作（然后成为了更牛马的牛马）。
本年的成功应用案例
批量翻译博客
利用命令行 AI 工具 Aider，我编写了一个简单的 Shell 脚本，让它自动读取中文博客目录下的每一篇文章，将其翻译成英文，并保存到对应的英文目录中。
脚本完成翻译只花了一个半小时的时间，但是我人工校对足足花了一个星期的夜晚时间… 这也是我过去虽有将博客英文化的想法，但是最终做不下去的原因——没有脚本化的工具，一篇篇复制粘贴也能弄到吐血。另外，校对英文翻译的那一周，也让我回想起了当时准备英文临床试验材料的那段时间… 即使现在看过的英文专业论文及材料已经数以千计了… 还是会觉得这个过程相当折磨… 这大概就是没有语言天赋吧…
给 FydeTab Duo Wiki 贡献中文翻译
除了我的博客，我还向 FydeTab Duo Wiki 贡献了好几次中文翻译。也是借由 Aider 初翻，然后我再进行一遍校对，同时我也借它了解了一下 FydeTab Duo Wiki，毕竟它采用的 Wiki 框架我之前并没有用过。
撰写博客初稿
今年下半年开始，我上传的博客数目开始指数增加，这也是拜 Aider + DeepSeek 的组合所赐。因为我写博客主要是记录给自己看，没有什么风格化的要求，记录目的远大于展示目的。所以列个提纲出来，把相关代码或者 Notebook 甩给它们，生成草稿我再改就可以了。这真的很省时间。原来我一个博文就能写一整个晚上… 现在只要有题材，一晚上写5篇都不是问题… 配合之前的翻译，中英文同步发布也不是问题。
批量生成 API 测试
面对多个服务组的 Swagger 描述文件，手动编写 pytest 测试用例过去是一件不难但相当耗时的事情。同样借助 Aider，我只需提供 Swagger 描述文件，它就能在几分钟内生成一套可运行的基础测试代码框架。我只需要在此基础上微调，就能快速提高测试覆盖率。
今年上半年在给接手的系统构建 CI 体系时，Aider + DeepSeek 的组合让我比预期早很多完成了工作。
修复 Hexo 主题的国际化问题
在为博客搭建英文站时，我发现主题 Volantis 的小部分文字实际上是硬编码在配置文件或者项目代码中的，且部分交互功能在子目录路由下失效。通过 DeepSeek 分析浏览器控制台报错和主题源码，我快速定位到问题根源：
- CDN 路径配置错误导致
app.js加载失败，修复后交互功能恢复正常。 - 将主题配置文件中固定的中文标题、描述等字段逐一替换为英文。
最终，我通过生成并应用补丁的方式，在不直接修改主题源码仓库的前提下，解决了双语支持问题。这在过去是非常难想象的，毕竟我并没有真的做过完整的 JS 项目开发，看代码找问题本身会很费劲，但是 AI 帮我缩小了检查范围，让短时间内解决问题成为了可能。
配置 GitHub Actions 进行 CI 和 CD
这也是一个比较好的例子。我今年有两个平台的自动化流程使用经验，一个是 Azure Pipeline，另外则是 GitHub Actions。前者我是对着说明文档手动写的，花了大概一整天，因为是全英文的文档，翻译又比较一言难尽（微软很多文档的中文感觉就像是根本没有中文用户，所以全是机翻也不优化）。
GitHub Actions 则很大程度上是在 AI 指导下完成的，生成大致样例后我再改，基本上 1~2 小时就能搞定。
为 conda‑forge 贡献 ARM64 包
当发现 tree_sitter_languages 缺少 ARM64 架构的 conda 包，导致 aider‑chat 无法在 Fydetab Duo（ARM 设备）上安装时，我决定自己动手补充。在 AI 的指引下，我：
- 了解了 conda‑forge 的 feedstock 工作机制。
- 在对应的
conda‑forge.yml中添加了linux_aarch64构建支持。 - 按照社区流程提交 PR，并成功通过 CI 测试。
本年的失败或部分失败案例
AI 显然也不是万能的，其给出的方案往往需要专业判断，否则就会原地打转，甚至很多时候我也不知道我是在打转还是还没摸到尽头。
尝试修改 Theia 的远程模块
我希望在浏览器版的 Theia IDE 中增加远程开发支持，因为我在 FydeTab Duo 上用 Linux 子系统的 VSCode 实在太卡了… Aider 和 OpenHands 都能给出代码修改建议，但由于我对 Electron/Node.js 的大型项目一无所知，无法判断这些修改是否正确，也不知如何调试。最终，这个尝试无果而终。
尝试更新 FydeOS 内核以支持 Vulkan
为了提升图形性能，我考虑将 FydeTab Duo 的内核升级到新版，以期支持 Vulkan 驱动。AI 帮我找到了适用于 RK3588 的新内核源码，但我无法理解编译时的 overlay 替换机制。最终我采取了简单粗暴的替换方式，结果导致设备变砖。
尝试基于 DevPod 的源码直接写一个符合我要求的应用
DevPod 的功能非常符合我脱离 FydeOS 的 Linux 子系统创建开发环境的要求，只是它必须基于 Docker 或者 Podman，但是我目前无法在子系统外运行 Docker/Podman。所以我曾经尝试让 AI 直接参照以及复用 DevPod 的源代码，写一个通过 SSH 连接，在远程机器上安装 VSCode 并进行端口转发的应用。然而 AI 并没有参考或复用 DevPod 已有的内容，而是根据我的描述一顿重写，然后代码却无法运行。
尝试在 FydeOS 上编译运行 Podman
我成功使用 Pixi 管理依赖，编译出了 ARM64 版本的 Podman 及其依赖库。然而在运行时，却因 FydeOS/ChromeOS 内核的 SafeSetID 安全限制，无法完成用户命名空间映射，导致 rootless Podman 最终无法运行。AI 给我解释了这一问题的来源，但是我至今也不确定它说的对或不对，以及我该怎么解决问题。
小结
回顾这一年，AI 已经彻底融入我的工作学习日常。它帮我完成了大量重复劳动，解决了无数具体问题，甚至让我敢于涉足以前不敢随便涉及的领域。但与此同时，我也更加清醒地认识到，AI 的能力发挥极大程度依赖于使用者的知识储备和判断力。
- 在已有知识框架内，AI 能带来一定的效率提升，虽然绝对到不了各家宣传的可以当甩手掌柜的程度，但一定是有真实的效率提升的。
- 在一知半解的方面，AI 能大大缩短从0到1突破的时间，这在过去是很难想象的，但是今年很多新内容的上手，实际上就只花了半天时间。
- 在完全陌生的领域，没有足够的背景知识去验证和筛选 AI 的输出，只能被动地按照 AI 给出的建议一条条尝试，非常容易花大量时间在无用功上。
简单来说，就是我的上限决定 AI 的上限，最终，还是使用的人需要好好学习，提升自己。
