CodeSky 代码之空

第一篇讲讲 AI Coding，也就是上班场景；而第二篇讲的是日用篇，也就是个人生活中的一些场景的展望。

在这方面我是实用主义者，看官的大饼不要马上堵我嘴里，谢谢。

上一篇讲到在 AI Coding 领域的发展迅猛，这一篇讲讲 AI Coding 以外的场景，AI 的现状和想象空间到底是怎么样的。

恭喜大家，周更博主到月更博主终于要升级成为年更博主了！

字节上班确实忙啊……本文更多的是一些最近使用 AI 开发以及接触 AI 项目，和同事朋友们唠嗑的碎碎念，后文会解释为什么现在更新速度和更新内容更水了。

首先我可以保证，在很长一段时间内，我不准备让 AI 介入我的博客更新，由 AI 替我提高产能，所以请放心阅读，本文纯人工，不添加任何防腐剂。（但插图可以）

本来准备一篇文章写完，但是光讲一个点就很长了，所以我决定分成几篇来写，这次肯定不太监！

——当知识属于少数人的时候属于红利，但当所有人都意识到的时候，就是红海了。

我几乎踩到了每一个提效的风口，最早体验到了 AI Coding 给我开发带来的体验提升，从最早的代码补全 / Copilot / 多行补全到现在的 SDD / AI 全托管 / 小龙虾生态，冲击和改变对于我们这种工作快十年的老登来说变化是巨大的。

2025 年新年的时候，我还在呼吁大家使用更先进的生产工具去改变开发习惯，并且觉得 AI 浪潮下程序员本质是不会失业的。

而最近我收到朋友发来的消息说她最近看着 AI 很焦虑，希望我能更新一篇文章，所以我在百忙之中终于准备更新了！

阅读前提示：豆包手机本身的表现属于意料之中，也没有网上吹得那么神，也没有黑稿说的这么差。本身豆包手机的定位比起「手机」，更像是「玩具」。大家实际购买前可供参考。

当然我已经自闭一整天：3000 块钱买啥不好了。

硬件

配置

又拖更了很久！最近要打的游戏有点多……

在一个多月以前开始倒霉的我加入了我们的性能排查专项，主要解决我们平台站点网络反应慢的问题。（再不更新就要忘光了）。

为了以防各位难以理解文章的脑回路，首先先来简单描述一下我们遇到的场景：

1. 内部平台，因此没有办法使用全球 CDN 像 C 端那样加速
2. 全球化 team，使用者遍布全球各地
3. 数据合规，因此在美国数据只能在美国，欧洲数据只能在欧洲

也因此处理内部网络问题更加困难，如果说在 C 端可以用「部分用户网络问题」来搪塞的话，内部系统一个老板 Case 就要一查到底了。

还是流水账更新的快啊。

上一篇文章 博客重建计划中我们提到了整个博客基本上都是 Cursor 负责研发，而我负责需求和验收工作。本质上是一种研发模式的变更，包括 Terminal 从 iTerm2 转而用 Warp 一样，新一代的革命随着 AI 的发展逐步升级。

有意思的是，在我日常唠嗑的过程中，往往一些大厂的员工对于工具升级反而没有创业公司的员工接受度高，这里当然指的不止是互联网头部的几家大厂以及一些对于热点敏感的同学（没有开地图炮的意思保命警告）。

这主要是因为对于大厂来说，合规永远是一个顾虑，用别人的模型，别人的 API，如果数据泄露了怎么办，要自研，又只有头部那几家能有这个财力和人力去做，而且投入时间长，效果也没有那么好，也因此对于普通大厂开发的开发体验升级其实反而是滞后的（因为我已经问了不止一家创业公司直接报销 Cursor 了（抹泪）

还是流水账比较好写，先把流水账写了吧。

今年过年期间也没有什么年度规划，不过自 1 月开始进行了博客整体重写的计划，起因是因为之前从腾讯云迁移到阿里云时可能是因为 PHP 版本控制的不对或者是别的问题，导致博客没办法正常的上传文件到又拍云。

现在都是靠着脚本上传文件然后 copy 发布的，Obsidian + Typecho 的脚本也不是很好用，也遇到了 5xx 的问题，但是我已经不会写 PHP 了，更不要说 debug 了。

拖稿时间太长，只能努力还原……QvQ，因为如你所见的近期主要功夫都在重写博客系统和简历页面上了，当然也包括在 NAS 上部署的 gitea + action 的配置之类的，因此后面可以更新的文章还是挺多的

之前我也写过两篇 AI 相关的文章，不过因为不涉及到开发，只涉及到使用，所以我还是用 Windows 宿主机开发的，这次由于涉及到了开发，所以就得折腾一下 WSL GPU 加速的方案。

安装

Redis 是我们常见的缓存解决方案，但是使用不当的 Redis 同样会造成系统瓶颈。

慢日志分析

要启用慢日志分析，首先先要对慢查询记录进行设置：

1# 命令执行耗时超过 5 毫秒，记录慢日志 
2CONFIG SET slowlog-log-slower-than 5000 
3# 只保留最近 500 条慢日志
4CONFIG SET slowlog-max-len 500
5

实在不知道该编什么名字，总之先复习一下缓存吧。本文讲的重点是服务端缓存，尤其是 Redis 相关的设计。

概述

众所周知的是，我们的业务数据多数都会选择存储在 DB 里，但数据库本身是一个吞吐量有限的单点，在实际的高并发场景下，我们肯定不可能让所有的流量都流向 DB，因此在这种情况下，业务往往会涉及一些缓存来缓解 DB 的压力。

具体的来说，从客户端到服务端，链路的每一个节点都能具有缓存的能力。比如客户端的 HTTP Cache、边缘节点的 CDN 缓存，再到服务端缓存，包括内存缓存、Redis 缓存等等，在开头我们说过，重点是服务端缓存，因此我们会对客户端缓存暂且不表。（反正一言以蔽之也就是强缓存和协商缓存）。

我们经常会被问到这样一个问题：在一个下单流程中，如何保证数据的一致性。

如果我们在单服务单库中运行，那么很简单，使用数据库的事务就可以了。

但是正常来说，现在的所有服务都会采用微服务的架构，也就是说一个下单流程中，「订单服务」到「库存锁定」到「生成账单」到「支付交易」到「回调变更状态」，这几步将会有多个服务来共同完成。

此时我们必然不能让用户的任何一步失败，又或者必须保证失败后回滚一定成功，否则用户钱扣了，交易却没成功；或者造成了超卖，这些都会造成严重客诉。

为此才会引入分布式事务这个概念，也就是保障多个事务之间的一致性，要么全部成功，要么全部失败。