在构建 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 工具实际上可以被深度”引导”，甚至达到一种”洗脑”的效果，让它们按照我们的意愿来行动。

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

引子

工业化、现代化、城市化、民主化、自由化、市场化、全球化，不一定要姓“西、资、基”。

第一章

五常的否决权是对大国毁灭性力量的承认。核武器，氢弹，洲际导弹，核潜艇，多弹头分导。

退缩不会让狼群放弃供给，逃跑不会让狼群放弃追捕，倒下不会让狼群放弃杀戮。

大国没资格投降。

泡水膨胀球

这是一种小玩具，干燥时拿在手里，小巧紧致。

泡在水里，一段时间之后，浑圆饱满，一只手都未必能捧的住。

放在干燥通风的地方晾晒，一段时间过后，又可以恢复原本的大小。

软件需求

前言

分布式键值存储（Distributed Key-Value Store）并不是一个新鲜的玩意。
常见的Redis，Memcache等等都有很多人在用。

不过如果要是说其中的细节，如replicate，读写，一致性，retry等等的话，又是经常会遇到把自己绕的混淆不清的情况。。
恰巧我最近在看的一门网课《Programming Reactive Systems》中有一道作业题就是要自己实现一个Distributed Key-Value Store，那就正好借此机会详细写下其中的关键点。

组成系统的参与者

既然是分布式键值存储，那么肯定会有主从节点，每个结点又会有自己的持久化，而主从之间也需要协调，于是就得出了如下关键参与者：

• Primary： 主节点。接受来自client的更新（增/删/改）操作，并把更新后的数据扩散到其它节点。当然，也可以接受来自于client的读操作。
• Secondary： 从节点。接受来自主节点的更新操作。接受来自client的只读操作。
• Arbiter： 仲裁者。任何节点，无论主从，都要把自己注册到Arbiter上去。当有从节点加入或者离开集群的时候，Arbiter负责告知主节点。
• Persistence： 每个节点都拥有自己的独享的Persistence。用于把节点上的数据持久化。
• Clients： 客户端，可能与主或者从节点通信，进行各种读写操作。

原文作者：Robert C. Martin (Uncle Bob)
原文链接：https://blog.cleancoder.com/uncle-bob/2019/06/16/ObjectsAndDataStructures.html

类是什么？

类是一组相似对象的范本。

对象又是什么呢？

对象是对封装的数据进行操作的一组函数。

不如这么说:对象是对隐含数据进行操作的一组函数。

Scala里有一个很有趣的语言特性叫做Self Type，可以用来限定一个trait可以被mixin到哪里去。

看个例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

trait User {
  def username: String
}

trait Tweeter {
  self: User =>
  def tweet(tweetText: String) = println(s"$username: $tweetText")
}

class VerifiedTweeter(val username_ : String) {
  def username = s"real $username_"
}

object SelfTypeBlog {
  def main(args: Array[String]): Unit = {
    val realBeyoncé = new VerifiedTweeter("Beyoncé") with User with Tweeter
    realBeyoncé.tweet("Just spilled my glass of lemonade")
  }
}

User就仅仅相当于一个Interface，定义一个username。

Tweeter内的第一行是重点 self: User => 就限定了Tweeter只能被mixin到实现了User的类里面去。
由于可以确定Tweeter只能被mixin到实现了User的类里面去，这样Tweeter的tweet方法内就可以放心大胆地用 username 了。

VerifiedTweeter是一个很普通的class，别人new它的时候给什么字符串，它的username就是啥。

先看这么一段Scala代码：

1
2
3
4
5
6
7
8
9
10
11

object PFBlog {

  def usePF(pf: PartialFunction[Option[Int], Int]) = {
    pf(Some(11))
  }

  usePF {
    case Some(x) => x + 1
    case None => 0
  }
}

声明一个usePF方法，接受一个PartialFunction作为参数，它的实现就是传一个 Some(11) 给pf。
pf的具体类型是 PartialFunction[Option[Int], Int] 所以传递给它一个Some(11)可以期待它会返回一个Int。

然后调用usePF，传递给usePF的是一个pattern match表达式。给Some加一，给None返回0。

这时问题就来了，这个pattern match表达式是怎么能够符合usePF需要的参数类型的呢？
这么单纯的一个pattern match表达式怎么变成PartialFunction[Option[Int], Int]的呢？

为了探寻答案，先把这几行Scala代码编译成class文件，然后把byte code反编译成Java来一探究竟吧。

我们来一起看一下两个程序员之间的故事。

以下示例代码是用Scala写的，不过本文所讲的话题并不仅限于Scala，任何有Future/Promise支持的语言都是适用的。
下面这个wiki页面罗列了各个有Future/Promise支持的语言，已经涵盖了大多数的常用语言。
Future与promise实现列表

我是异步函数的编写者

我写了两个异步函数,来提供给其他程序员同事使用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

type CallBack = Try[String] => Unit

def pretendCallAPI(callBack: CallBack, okMsg: String, failedMsg: String) = {
  val task = new TimerTask {
    override def run() = {
      val percentage = Random.between(1, 100)

      if (percentage >= 50)
        callBack(Success(okMsg))
      else if (percentage <= 30)
        callBack(Failure(new Exception(failedMsg)))
      else
        callBack(Failure(new Exception("network problem")))
    }
  }

  new Timer().schedule(task, Random.between(200, 500))
}

val searchTB = pretendCallAPI(_, "product price found", "product not listed")
val buyFromTB = pretendCallAPI(_, "product bought", "can not buy, no money left")

这两个异步函数: searchTB用来从淘宝搜索物品,另一个buyFromTB用来购买搜到的物品。

原文地址： https://blog.cleancoder.com/uncle-bob/2018/04/02/InTheLarge.html

原作者：Robert C. Martin (Uncle Bob)

自敏捷之开端始，我们就思考大规模敏捷的问题。我们是否能够把轻量级，迭代，增量，快速反馈等软件开发的原理应用于规模巨大的项目呢？

最初我们想到的答案是Scrum of Scrums之类的东西。这个想法是在更高的层次上递归地应用敏捷开发的原理。如果一个项目需要超过5-12个开发人员，那么可以组织两个这样的团队，以及一个更高级别的团队来“监督？”他们。

请注意上面的问号。当我们开始考虑大型项目时，我们不可避免地要谈及层级化的组织。但是敏捷似乎是厌恶组织层级的。毕竟，敏捷就是关于平等主义的。敏捷是拒绝命令和控制的。敏捷是拒绝计划和时间表的，还有…

无稽之谈！并不是这样的！

原文地址：https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html

原作者：Robert C. Martin (Uncle Bob)

在过去的几年中，我通过与人结对来学习函数式编程，他们中的很多人表达了反对OO的偏见。他们经常会说：“啊，这太像对象了。”

他们会这样说是因为他们认为FP和OO在某种程度上是互斥的。许多人似乎认为程序FP的程度等同于其非OO的程度。我认为这种观点是学习新事物的自然结果。

当我们采用一种新技术时，我们通常倾向于避开以前使用的旧技术。这很自然，因为我们认为新技术“更好”，因此旧技术就一定是“更糟”的。

在此博客中，我将说明OO和FP是正交的，但它们并不互斥。一个好的函数式程序可以（并且应该）是面向对象的。而且一个好的面向对象程序可以（并且应该）是函数式的。在此之前，我们必须非常谨慎地给FP和OO这两个词语下个定义。