#人工智能
最近我似乎患上了一种“AI模型用量FOMO症”：总觉得没把每周的额度耗尽，心里就不踏实。这周，我终于把 Kimi 的周额度彻底“榨干”了，与之相呼应的，是我在 GitHub 上肉眼可见暴增的提交记录（目前在做的开源项目）。

在日常开发中，我使用AI的方式更像是一名架构师：先梳理业务需求、设计系统架构、划分功能模块，并严谨地定义好每一个接口与测试用例。只有在完成这些全局规划后，我才会把具体的编码细节交由AI按部就班地去执行。总的来说，现阶段 AI 对我而言依然是“副驾驶（Copilot）”的角色——我必须完全掌控它的每一步逻辑，亲自去做Code Review为其兜底，而不是依赖它去生成一个我自己都毫无头绪的黑盒。

正因如此，我认为在这波AI对程序员群体的冲击浪潮中，首当其冲的将是刚入行的初级开发者。由于经验尚浅，他们往往还没有建立起这种高维度的架构设计与项目组织能力，依然停留在“单纯写代码”的阶段，因而在这场技术变革中最容易遭到替代。

最后，聊聊近期的工具体验。去年12月底我开始使用 GLM，初体验确实令人惊艳，但随着深度使用，各种莫名其妙的状况开始频发：卡顿、突然中断、输出乱码，甚至陷入无限读取代码并狂刷终端的死循环，整体的可用性和稳定性大打折扣。因此，三月份 GLM 的季度套餐到期后，我打算正式弃用不再续费了。取而代之的，是我会把 Kimi 的订阅从99元档直接升级到199元档，让它继续做我可靠的开发助手。

#健康
我在2017年的时候，就以一次跑步后晕倒昏迷十几秒的代价，明白了如果没有休息好就不要强行运动的道理。

张雪峰的身体，应该在这之前也给过类似的告警，可惜他没有听，也许是听到了但是也没有在意。

张雪峰真是可惜了，在一个这么卷的行业，给公司的人很多福利，自己却累到死。

#开源项目
手动关闭选项，不允许Github使用私人项目来训练copilot，关闭按钮在 https://github.com/settings/copilot/features 中的 Privacy。

#分布式
《图解分布式系统原理》的博客目录，今天更新到《第六章：分区》。前面章节已经讲解完毕复制和复制时面对的一致性问题、共识算法等，本章讲解分区相关知识，即将数据划分到不同的节点上存储。本章也是教程中相对最不满意的一章，因为感觉对比DDIA的相同章节，并没有写出太多新的东西来，读者看后可以给我一点反馈和建议。

第一章：分布式系统概述
第二章：分布式系统模型
第三章：分布式系统中的时间和顺序
第四章：复制
第五章：共识算法
第六章：分区

另外需要说明，由于我的初稿是Latex，放到博客时用工具转成的Markdown格式，所以可能有些格式问题，请见谅。

#人工智能
我这几天也用了一下GLM新的5.1模型。还是跟之前一样，上下文一长，就有概率死循环一直往外输出。

一句话总结：GLM模型的可用性仍然很不稳定。

我用武侠小说的例子做个对比，GLM模型就像段誉用的六脉神剑，可能这个武功确实是顶级武功绝学（上限高），但是时灵时不灵，实战中就很慌。同理，我现在都不会把GLM用于过于复杂（例如上下文会超过100K）的任务了。

截止2026年3月31日，继续维持Kimi2.5是目前国内最好编码模型的判断。（补充一下我的使用场景：kimi 用的是官方的 kimi-cli，glm用的是不带插件的opencode，另外两个模型用的都是官方的模型，而不是云厂商的模型）

#博客
这几天claude code代码泄露，网上出了很多分析其源代码的文章，借这个机会，再推荐一下之前写的文章《如何阅读一份源代码？（2020年版） 》，这是在前AI时代古法阅读代码的一些经验和方法总结。

有了AI加持之后，这些方法依然起效，但是可以在AI辅助下加速代码的阅读和理解：比如可以就其中某个具体的问题、场景，提问AI具体的问题等等，比如可以让AI生成调用的流程图。简而言之，AI只是加速工具，阅读代码的方法并未改变，如何指导AI、从哪里入手、如何问具体的问题，都是可以从文章中有借鉴的。

另外如果读的是Github上的开源项目，可以去 https://deepwiki.com/ 里面找是不是已经有相关文档，比95%以上的人写的代码分析文档都要好。

#人工智能
#投资

因为是小鹏的全仓股东，昨天3月份的销量数据出来之后，突发奇想让Kimi深度研究了一下2026年Q1的业绩和展望，Kimi花费了快一个小时出了这份报告，由于我对小鹏相当了解了，看这份报告感觉挺不错的：数据详实、引用都有准确的出处，未来做基本面研究可以借用AI工具做辅助。

我也同样让Kimi生成了一份茅台的Q1分析，由于不是茅台股东对这家公司不够了解，所以我也说不好质量如何，单从内容上来说比小鹏的报告少了一半内容，这也可能是因为这个生意不够“性感”，没有什么新的产品吧。

对这两家公司感兴趣，或者对Kimi的深度研究分析公司的能力好奇的，都可以看看这两份报告，百度网盘地址。

#开源项目
#人工智能

为了学习如何实现一个Agent，我用Rust照着Python实现的kimi-cli在写一个coding agent，名字叫ironcode，目前还比较粗糙，后面如果能做到：用ironcode的agent来编码ironcode自身就有意思了。项目地址：https://github.com/lichuang/ironcode

#开源项目
使用微信读书和Obsidian的朋友，可以用这个Obsidian插件来同步微信读书上的笔记到Obsidian上。

#开源项目
#人工智能

有人将John Ousterhout的《A Philosophy of Software Design》里的设计理念总结为skill了。

《A Philosophy of Software Design》是一本教你如何将复杂的软件系统分解为可以相对独立实现的模块的经典书，所以这个skill可以用于：代码重构、review等环节里。

之前曾经介绍过：作者也是TCL语言的作者，Raft论文作者的导师，也在论文作者名单中。

#人工智能

我采用《A Philosophy of Software Design》里的设计理念总结的skill来分析了一下rockraft现有的代码，马上给出了一个很详细的重构错误类型的意见，参见附件里的Markdown文件，根据这个意见的修改见pr ，AI编程工具是在kimi-cli上用的kimi-2.5模型。

#分布式
《图解分布式系统原理》的博客目录，今天更新到《第七章 事务》。这是这个教程的最后一章，本来这并不是一个讲数据库内核的教程，但是到了事务这部分，需要先讲解数据库中ACID的概念，有了对事务的基本理解才能继续后面的讲解。前面已经讲解了复制和分区技术，复制技术（包括将重点介绍的共识算法）提升了系统的容错性，而分区技术提升了系统的扩展性，这两项技术解决的是数据的*“物理问题”。除此以外，分布式系统中的数据访问还经常面临着“逻辑问题”，这就需要事务技术来解决。


第一章：分布式系统概述
第二章：分布式系统模型
第三章：分布式系统中的时间和顺序
第四章：复制
第五章：共识算法
第六章：分区
第七章：事务

另外需要说明，由于我的初稿是Latex，放到博客时用工具转成的Markdown格式，所以可能有些格式问题，请见谅。

#分布式

从2024年末开始动笔撰写《图解分布式系统原理》，到2026年初完成初稿，前后历时14个月。期间不仅完成了近20万字的文稿，还亲手绘制了数百幅插图，本就不算茂密的头发也因此又稀疏了几分。

自2026年春节后，开始陆续在博客上公开发布这些内容，直至清明过后全部更新完毕，终于为这个阶段画上了一个小小的句号。

#分布式

找Kimi深度阅读了目前已经公开的《图解分布式系统原理》所有章节之后，给评论打分：https://www.kimi.com/share/19d66c1f-4362-8e4f-8000-0000d4277d09 ，还有改进的空间，可能还会改一改。

图一乐: gemini 评分 https://gemini.google.com/share/414ba8884625

#编码
#人工智能
我继续用《A Philosophy of Software Design》里的设计理念总结的skill来重构Rockraft的代码，它这一次没有改代码的实现，只是修改了代码的注释（pr），理由是：improve documentation to explain "why" not "what"。


以其中一段代码注释的前后修改为例：

修改前：

/// Write a log entry to the raft cluster
///
/// This function writes a LogEntry to the raft log and waits for it to be applied.
/// It can only be called on the leader node.
///
/// The `time_ms` field of the entry will be set to the current timestamp before writing.
///
/// # Arguments
/// * `entry` - The LogEntry to write
///
/// # Returns
/// * `Ok(AppliedState)` - The result of applying the log entry
/// * `Err(Error)` - If the operation failed or this node is not the leader

修改后：

/// Write a log entry to the raft log (leader-only)
///
/// Appends the entry to the local log and replicates it to followers.
/// Returns after the entry is committed (majority acknowledgment).
///
/// # Leader Requirement
/// This method **must** only be called when this node is the leader.
/// Callers should use `RaftNode::assume_leader()` to verify leadership first.
///
/// # Timestamp
/// The `time_ms` field is automatically set to the current time before writing.

可以看到，修改前的注释，只是简单列举函数的参数和返回值（重复了函数签名（signature）），而修改后增加了行为的解释和函数的前置要求（需要是leader）。

回到最开始做这个注释重构的动机上，注释、文档应该“explain "why" not "what"”这属于更偏代码审美品位的事情了，没有之前大量的代码训练实践，可能不会具备这样的品味。

而现在，如果AI一开始替代了大量手搓代码的实践，还能通过什么方式积累这样的品味？

#分布式

随着《图解分布式系统原理》初稿的完成，现在找有意向出版成纸书的出版社合作，大家可以帮忙转发给认识的出版社朋友，初稿完成的目录在这里。

如果最终无法出版成纸书，我将自己找专业Latex排版人员重新排版，在网上售卖电子版pdf。

#分布式
#开源项目

写了一篇博客介绍一下最近做的开源项目 Rockraft 和衍生的 coredb：《Rockraft：基于 OpenRaft 与 RocksDB 的强一致 KV 存储框架》

#分布式
#人工智能
《多 Agent 协作本质是分布式系统问题，模型多强也没用》，这篇文章很好诠释了AI智能体时代，为什么还需要学习分布式系统理论。里面涉及的分布式相关概念：共识、safety、liveness、拜占庭故障等内容，在《图解分布式系统原理》中均有涉及。