最初，我只是想知道：能不能算出一句话里的信息量，进而判断一次会话的质量？

背景是一个客服系统。用户提出问题，客服给出回答，有的回答很长，却让人不知道下一步该怎么办；有的只有几句话，就把事情说清楚了。如果能用一个量把这种区别表示出来，似乎就能更客观地评价客服。

顺着这个问题，我接触到了信息熵、条件熵、交叉熵、互信息，以及 KL 散度、JS 散度。它们看起来都与“信息多少”有关，但仔细看，...

一个 Coding Agent 修复了一处错误。它读代码、调用工具、看到报错、调整方案，最后交出了能工作的修改。这已经是一种很有价值的能力，但下一次遇到相似问题时，它可能还会经历同样的弯路。

如果它进一步发现，弯路来自自己读取文件的方式、组织上下文的策略或选择工具的流程，并把改进保存成下一版 Agent；如果下一版还能够继续改进后续版本，问题就开始触及 RSI：**Recursive Self-...

用户昨天在 App 里反馈商品破损，上传了照片，客服承诺今天给出处理结果。今天他换到网页，只问了一句：

昨天那件事怎么样了？

一个能搜索历史聊天的 Agent，也许能找到“商品破损”。但要把服务接下去，它还需要知道：是哪笔订单、照片是否已收到、昨天承诺了什么、谁负责处理、现在是否已退款，以及今天适用的处理规则。

这些信息分散在对话、工单、订单、支付和知识库里，更新速度也不同。**记忆管理...

有一种代码，刚写完的时候怎么看都很清楚，过两个月再打开，却要一边翻调用方，一边查数据来源，最后还得问一句：这里为什么要这样处理？

代码没有变，消失的是写它时脑子里的上下文。

当时知道这个字段一定存在，知道两个方法必须按顺序调用，知道某个看起来多余的判断是为了兼容旧数据。这些前提没有留下来，于是下一次修改的人，只能重新推理一遍。

读《代码整洁之道》时，我越来越在意这种落差。命名、小函数、注释、...

之前写实习经历时，我写过一句话：

我以前不理解为啥有人会因为工作感到压力大？做不完就加班呗，反正总能做完。

现在再看，还是能理解那时候的自己。刚进入一个陌生的环境，技术不够熟，业务不够懂，经验也谈不上，能拿出来证明自己的东西似乎只有努力。不会可以学，做不完可以晚点走，只要自己再多付出一点，事情总有办法解决。

这个想法让人安心。它把复杂的问题变成了一件我能够控制的事：继续努力就好了。

读 Robert C. Martin 的《程序员的职业素养》时，我反复想起这句话。书里有一段经历：他在凌晨三点，为了解决一个定时问题，写出了通过事件分派系统给自身发送消息的代码。当时他觉得这个方案很好，也为自己的投入感到自豪。后来，这个设计让团队不断遇到奇怪的时序问题，大家一边绕着它打补丁，一边继续声称没有时间重写，包袱就这样留了好几年。

让我在意的是，他记得自己当时那种很专业、很敬业的感觉。

我们确实可能在最确信自己负责的时候，做出让别人长期承担代价的决定。努力的感受如此真切，结果却未必配合。

这也是这本书值得读的地方。它把职业素养放进了很多不太体面的时刻：答应了做不到的事，怕别人失望而隐瞒进度，为了按时交付省掉检查，想当救星，最后搞砸。作者没有把自己摆在这些事情之外，我也很难心安理得地把它们当成别人的问题。

AI 把代码写好了，功能跑通了，你再让它解释一遍，好像也都看懂了。

但过几天遇到类似的问题，换一个条件，你还能判断这段代码会不会出错吗？

我是 26 届，2025 年 3 月开始实习，现在做 Agent 开发和后端。经历了从自己写为主的古法编程时代，到把 95% 的需求实现交给 AI，这半年我最关心的一个问题就是：能完成的任务越来越多，自己能解释、判断和维护的部分，有没有跟着增长？

...