太长不看

OMP 是一个 AI 编程助手。你跟它聊得越久，对话越长。AI 一次能处理的文字有上限，所以到了一定长度，OMP 会自动把旧对话压缩成一段摘要，继续聊。

压缩的过程是让 AI 重新读一遍旧对话，写个总结。问题出在 OMP 怎么排版旧对话：它用了一种叫 Harmony 的格式来序列化，其中 AI 之前的思考内容被包上了 <|channel|>analysis 这样的标记。这个标记是 OMP 自己加的格式，不是 AI 写的，也不是对话里本来就有的。

GitHub Copilot 的 gpt-5.6 系列模型拒绝处理包含这个标记的请求。为什么只有 gpt-5.6 系列拦、其他模型不拦，没有从官方得到确认。从行为看，它可能把这个标记识别为不该出现在用户输入里的内部协议符号。哪怕请求里只有这一个字符串、什么都没有，也会被拒。

结果就是压缩失败，会话卡住，用户得手动换模型或清空历史才能继续。

十几个字符的字符串，直接让 OMP compaction 400 了。

字符串是这个：

1

<|channel|>analysis

场景是 OMP 的自动压缩。会话太长以后，OMP 会把历史对话压成一份摘要，继续塞回上下文里。正常情况下，这件事不该惊动用户。结果这次直接炸了：

1
2

Compaction failed: Summarization failed: 400
{"error":{"message":"Request blocked.","code":"invalid_request_body"}}

一开始看起来像凭证问题。再看 raw request，味道不对。

为什么 AI coding 让人一边兴奋，一边心里发毛？

不是因为它写不出代码。恰恰相反，是因为它太能写了。你说一句，它回你一屏；你开个 agent，它能自己读文件、改代码、跑命令、再解释一遍自己做了什么。

问题是：生成变快了，判断有没有变严？

如果没有，那就不是工程效率提升，而是把风险生成得更快。

前几天盯 Copilot 的一次响应，看到里面多了两行之前没留意的 header：

1
2

x-usage-ratelimit-session: ...rem=5.7&rst=...
x-usage-ratelimit-weekly: ...rem=74.9&rst=...

rem=5.7。这个数在掉。我不知道它按什么规律掉，也不知道掉到几要出事。

晚上花了点时间去追，想搞清楚四件事：这俩 header 啥时候冒出来的，rem 到底是什么，它怎么往下走，单次调用扣多少。

你每天开的 IDE，到底在为谁设计？

为代码吗？为你吗？还是为”你的手”？

这个问题以前不用问。答案太明显：执行器就是你自己。你盯着光标，一行行写，一个参数一个参数改，一个文件一个文件过。

IDE 所有能力，从语法高亮到 refactor，从跳转定义到 diff，都在服务这个动作链。

可今天不一样了。Copilot coding agent 在后台接活，Codex 在云上并行跑任务，Claude Code 拿到一个 issue 就能自己开 worktree 干活。

你发出的是目标，回来的是 PR。中间那层微操作，开始不在你手里了。

过去一年我写了四篇跟 AI Agent 有关的文章。

洗脑 Copilot 讲怎么用指令让 agent 按你的方式工作。

Agent 陷阱 讲构建 agent 时那些看起来对实际上坑的模式。

AI 育儿博主 讲怎么把大量领域知识喂给 AI。

MCP 启动优化 讲逆向工程 Claude Code 的 MCP 初始化流程。

四个完全不同的话题，写的时候也没想过它们之间有什么关系。

但写完 MCP 那篇之后，我发现它们在讲同一件事。

最近在用 Claude Code 时，用得越顺手，启动时的那阵漫长等待就越显得碍眼。

我装了 9 个 MCP 服务器：sequential-thinking 用来思考，memory 用来记东西，firecrawl 用来抓网页……每一个都是得力助手，但加在一起，每次启动都要对着终端干等十几秒，才能看到输入框。

这十几秒的延迟虽然不算长，但在频繁使用（比如反复重启会话）的场景下，确实有点消磨耐心。

家里那本《崔玉涛育儿百科》，700 多页，厚得像块砖。

不是不想看——是真的没时间。但眼看宝宝马上满周岁了，第 14 章「12-14 个月幼儿」的内容马上就要用上了。什么疫苗要打、吃什么辅食、怎么引导走路……这些知识点散落在几十页密密麻麻的文字里，每次翻书都要重新定位。

我想：能不能把这些精华提取出来，做成那种「一图读懂」的海报？这样需要的时候直接翻手机相册就行。

问题是——我不会设计。不过，我有 Claude。

当泛型遇上现实：从表象到本质的技术思考

最近在优化一个序列化框架时，遇到了一些类型安全方面的意外行为。这让我重新审视了JVM泛型系统的底层机制。虽然类型擦除是个老话题，但当我深入分析Kotlin的reified实现时，发现了一些值得思考的细节。

一个简单现象引发的思考

我们都知道Java的类型擦除，但最近在排查问题时，我又重新观察了这个现象：

1
2
3
4
5

List<String> stringList = new ArrayList<>();
List<Integer> intList = new ArrayList<>();

// 在运行时，它们的Class信息完全相同
System.out.println(stringList.getClass() == intList.getClass()); // true

这是类型擦除的基本表现：编译器将泛型参数替换为边界类型。不过这让我想到一个问题：既然编译器会进行严格的泛型类型检查，那反射是如何绕过这些检查机制的？

在构建 Cline AI agent 的过程中，我们发现最危险的不是那些一眼就能看出来的坏想法，而是那些理论上听起来完美、实践中却一败涂地的诱人陷阱。

引言

在 Cline 构建 AI agent 的征程中，我们发现最危险的其实不是那些一眼就能识破的馊主意，而是那些理论上完美无缺、实践中却惨败收场的”陷阱”。这些思维病毒早已蔓延整个行业，吞噬了数百万工程师小时，把一个又一个团队拖进了架构死胡同。

以下是我们见过的三大最常见陷阱：

1. Multi-Agent Orchestration（多智能体编排）
2. RAG (Retrieval Augmented Generation) 索引代码库
3. 指令越多 = 效果越好

业务复杂 ≠ 代码必然复杂。好代码常常看着普通，关键在于设计和可测试性平衡得好。

引言：为什么质量改进总是做不好？

我们都见过这种情况：团队加了各种检查清单、覆盖率红线、扫描工具。

几个月后，流程更复杂了，质量却没怎么变好。

问题不在执行力度，而在于把质量活动放错了时间：设计定好了才让测试介入，只能事后补漏洞。

核心思路：把质量从”事后检查”变成”设计时就考虑进去”，让测试帮助改进设计。

This message is used to verify that this feed (feedId:97818615095497728) belongs to me (userId:97817750660390912). Join me in enjoying the next generation information browser https://folo.is.

控制权旁落

RSS 并未消亡。

变化的不是协议，而是信息分发领域的权力结构。

用户在事实上让渡了选择看什么、何时看的权利。

微信公众号重塑了这种结构，通过两层约束：

1. 技术约束：内容被封装于 App 内，无标准 API，无 RSS 输出通道。
2. 算法约束：信息流按商业目标而非时间或信息价值排序。

本文是极客时间 8x 课程的读书笔记。我本想取名 G8 (Geekbang 8x)，但听起来不太对劲，所以就有了现在这个标题。

“软件的价值，最终由其承载的知识决定。代码，只是这些知识的可执行形态。”

引言：从“构建者”到“知识工程师”的身份转变

我们习惯于将软件开发看作一种“建造”活动，谈论“构建”软件、“编写”代码。

但随着 AI 大语言模型（LLM）的普及，我们或许需要换个角度审视自己的工作。

引子：把 AI 新兵改造成精锐士兵

GitHub Copilot 就像一个天赋异禀但野路子出身的“新兵”。它枪法精准（编码能力强），但缺乏战场纪律（工程规范）。

你让它冲锋，它能迅速拿下山头，但阵地上一片狼藉：没有构筑工事（错误处理），不关心侧翼安全（边界情况），弹药随意堆放（命名混乱）。

我们需要的不是一个只会冲锋的“莽夫”，而是一个懂得协同作战、遵守战场纪律的“精锐士兵”。因此，我决定为它编写一套严格的“作战条令”（Prompts），对它进行一次彻底的“军事化改造”，让它乖乖听话。

不是魔法，是系统指令

经过一段时间的研究和实践，我发现 Copilot 这类 AI 工具实际上可以被深度”引导”，甚至达到一种”洗脑”的效果，让它们按照我们的意愿来行动。

🚀 Reveal.js 高级特效演示

极致的视觉体验

• 背景视频 · 动态效果 · 交互体验
• 使用纯 Markdown 语法编写
• 所有特效通过 Reveal.js 注释实现

🎨 背景特效展示

渐变背景效果

flowchart TD
  subgraph 被动信息接收
    style 被动信息接收 fill:#f9d6c1,stroke:#000,stroke-width:2px;
    A[被动接受信息] --> B[算法过度控制]
    B --> C[信息茧房]
    C --> D[注意力消耗]
  end

  subgraph 信息主动消费
    style 信息主动消费 fill:#c1e1f9,stroke:#000,stroke-width:2px;
    E[回归RSS] --> F[掌握信息主动权]
    F --> G[自主订阅]
    G --> H[控制信息摄入质量]
    H --> I[主动选择信息来源]
    I --> J[避免无用信息轰炸]
    J --> K[减少干扰]
    K --> L[专注高质量内容]
    L --> M[享受纯粹阅读乐趣]
    M --> N[高质量阅读体验]
    N --> O[注意力回归有价值内容]
    O --> F
  end

  D --> E

问题描述

在使用LibreOffice的Calc组件将电子表格导出为PDF文件时，如果启用了“Whole sheet export”（整页导出）选项，导出的PDF文件中的超链接将不会保留原始的URL，而是显示为本地文件路径。

这个问题在

1. LibreOffice 官方论坛上的提问
2. Stack Overflow 上的提问

上都有讨论。

解决思路

将Microsoft Office文件转换为其他格式的场景

在一些情况下，可能需要将Microsoft Office文件转换为其他格式：

• 兼容性问题：与不同的办公软件或操作系统进行交互，可能需要将MS Office文件转换为更通用的格式。例如，如果要与没有安装Microsoft Office的人分享文档，将其转换为PDF格式可能更合适。
• 归档和存档：将Office文件转换为更稳定、可持久保存的格式可以确保文件的长期保存和归档。某些文件格式（如PDF/A）专门用于长期存档目的，以确保文件内容的完整性和可访问性。
• 数据提取：你可能只对文档中的特定数据或内容感兴趣。通过将Office文件转换为其他格式（如纯文本或CSV），可以更容易地提取所需的数据，并在其他应用程序中进行分析或处理。
• 网页发布：如果要将MS Office文件发布到网页上，可能需要将其转换为HTML或其他网页友好的格式，以确保文件在网页上正确显示。

LibreOffice - 微软Office的开源替代

LibreOffice是一个免费、开源的办公套件，在某种程度上可以被视为微软Office的开源替代品。

• LibreOffice Writer：对应于Microsoft Word。
• LibreOffice Calc：对应于Microsoft Excel。
• LibreOffice Impress：对应于Microsoft PowerPoint。

第一个问题：在多个线程中同时运行隔离级别为serializable的事务而导致的无法重试获取锁的问题

Spring Integration JDBC分布式锁的实现会需要使用一个serializable级别的事务来获取锁。

如果多个线程同时尝试获取锁，这些事务之间可能会出现顺序问题。

具体而言，可能会遇到以下错误：

1

org.postgresql.util.PSQLException: ERROR: could not serialize access due to read/write dependencies among transactions

发生这样的问题其实也不可怕，因为JDBC锁会进行重试。

在一个Kubernetes（K8s）集群中，部署了Prometheus和Grafana用于监控集群本身和应用的状态。

在其中一个Java应用对应的Pod级别观察到了内存上升的现象。具体而言，当该应用刚启动时，内存占用并不高。如果不发送请求给应用，内存将保持在启动时的水平上。

如果大量发送请求给应用并在短时间内持续发送，内存会迅速增加。这在一定程度上是正常的。

一旦内存增加之后，即使停止发送请求和压力，内存使用也不会下降，一直保持在高峰水平。

上面的状况是由Grafana中观察到的。

观察到的现象看起来像是内存泄漏，但实际上并不一定是内存泄漏。

最近在项目中需要使用Spring Integration提供的基于JDBC实现的分布式锁。

在实践的过程中，我们遇到了一些有趣的问题，现在在此记录和总结一下。

一共遇到了两个问题，第一个和time to live有关，第二个还是和time to live有关。

第一个问题：由于time to live默认值不够长而导致被动失去锁的问题

sequenceDiagram

actor event_initiator
participant instance_1
participant instance_2

event_initiator->>instance_1: do something

note over instance_1: instance 1 获得了 lock

instance_1->>instance_1: start doing its thing

event_initiator->>instance_2: do another thing

note over instance_2: instance 2 等待 lock
note over instance_2: 等 ......
note over instance_2: 等 ......

note over instance_1: lock的超时时间TTL到，instance 1还没干完活，但是它失去了 lock<br>失去不同于主动release<br>失去lock后，instance 1还会继续干活<br>而这些活里面可能会有SQL写操作

note over instance_2: instance 2 获得了 lock

instance_2->>instance_2: start doing its thing

note over instance_1,instance_2: 此时二者同时干活，有撞车的风险，因为二者干活的先后顺序没有保证<br> instance 1尚未把它干完活后才能确定的状态写入DB，而instance 2已经开始干活了

note over event_initiator,instance_2: 为了降低风险，可以： <br> ① 想办法尽量让instance 1能在超时前干完活 <br> ② 以防万一可以考虑在合适的时间节点延长锁的过期时间

根据上图所示，我们有两个实例。

一份有意思的代码

最近看到了一份使用随机生成的数据作为测试输入的有趣代码，把其大致思路用伪代码描述如下

需要被测的实现代码

1
2
3
4
5

function calculateSomething(inputData) {
    // 使用inputData来计算结果
    // 假装这里有一些很复杂的逻辑
    return result;
}

这是被测的函数，在此不管它算的是什么，总之它接受input，返回result。

测试代码的helpers

此书讲什么

马克思《资本论》讲的三件事：

• 原始积累靠暴力
• 贫富差距会扩大
• 最终自毁

经济与政治

经济学是有阶级属性的。

金本位时期金融机构的层级结构

19th century nation state financial institution hierarchy

央行的负债≈银行的资产≈货币

银行的负债≈私营部门的资产≈存款

亏钱先亏哪儿？

2007年，我在读大二。

当时经常会去学校食堂对面的报刊亭买杂志，一本，是《大众软件》，另一本，是《程序员》。

印象中当时《程序员》上的多数文章充满了我没听过的各种缩写与稀奇古怪的名词，文风是老成持重，我看不懂，但很是佩服。

而这当中偶尔会夹杂着几篇文风犀利，睥睨天下的文章，加上作者头像很是非主流，我虽也看不懂，但印象深刻。
这些犀利文章的作者，便经常冠有TW的头衔。

2012年，我在一家小软件公司上了两年的班。
当时我们每半年发布一个版本，每到要发布前夕，程序员便都停止写代码，去做回归测试。