技术实战 on Zampo Blog

ready=true 不是发布：Go 内存模型真正要你保证什么

Fri, 22 May 2026 16:40:00 +0800

线上偶现一个很烦的 bug：配置已经加载了，日志也打印了“ready”，但另一个 goroutine 读到的还是旧值。

代码看起来没什么毛病：先写数据，再把 ready 置成 true。读的一侧先等 ready，再读数据。人脑看这段逻辑，很容易得出一个结论：既然 ready 已经是 true，前面的数据当然也该准备好了。

问题就在这里。

在 Go 里，ready=true 不等于发布。普通变量上的“先写后读”，也不等于 goroutine 之间有可见性保证。

并发安全不是让代码看起来有先后，而是让规范承认它有先后。

这篇是 Go 内存模型系列的第一篇。它不打算把你拖进 CPU 指令、缓存一致性协议和汇编细节里。我们先解决一个更常见、更工程化的问题：goroutine A 写了变量，goroutine B 什么时候保证能看到？

答案只有一个：两边要存在 happens-before 关系。

最危险的代码，通常看起来最顺

先看这段很多人都写过的代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


var data string
var ready bool

go func() {
 data = "payload"
 ready = true
}()

for !ready {
}
fmt.Println(data)

直觉上，写入顺序很清楚：data 先被赋值，ready 后变成 true。读的一侧又是看到 ready 才打印 data，似乎不会出错。

Go 服务被 OOMKilled，别先怪 GC

Fri, 22 May 2026 00:01:00 +0800

服务又被 OOMKilled 了。

Pod 刚重启，群里已经有人开始翻 GC 日志。有人说 GC CPU 到了 20%，有人说把 GOGC 调低一点，还有人建议直接上 GOMEMLIMIT。

这些动作不一定错，但顺序错了。

OOMKilled 是结果，不是根因。它只说明容器被内核杀掉了，不说明是谁把内存吃掉了。可能是 Go heap 真的在涨，可能是 goroutine 泄漏把栈和引用一起拖大，可能是 alloc_space 很高导致 GC 忙，可能是 RSS 里有 cgo、mmap、tmpfs，也可能只是容器 limit 给得太紧。

Go 服务的内存问题，最怕一句话定性。

一旦你把所有问题都叫“GC 问题”，排查就会变成调参赌博：今天调 GOGC，明天加 limit，后天又开始怀疑 pprof 没抓准。真正稳定的做法，是先把几条线拆开：Go 堆、Go runtime 管理的内存、RSS、容器 limit，以及业务生命周期。

第一步不是调参数，是确认谁杀了你

线上看到内存上涨，第一件事不是打开 pprof，也不是改 GOGC。

先确认事故事实。

1
2
3
4
5


kubectl describe pod <pod> -n <ns>
kubectl logs <pod> -n <ns> --previous
kubectl top pod <pod> -n <ns> --containers
kubectl get pod <pod> -n <ns> \
 -o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}'

你要先回答几个问题：

Go GC 占 CPU 5%，到底要不要调 GOGC？

Thu, 21 May 2026 23:30:00 +0800

服务 p99 每隔几十秒抖一下。

监控里 GC CPU 大概 5%，不算夸张，但曲线很准：GC 一来，延迟就往上冒。群里很快有人提议：把 GOGC 从 100 调到 200，先让 GC 少跑几次。

这个动作看起来很合理。

CPU 下来了，GC 日志没那么密了，p99 也安静了几天。然后另一个问题来了：容器内存开始逼近 limit，某个高峰期被 OOMKilled。大家又把 GOGC 调回去，延迟抖动也跟着回来。

这就是很多 Go GC 调优的真实状态：不是不会调参数，而是没想清楚自己到底在买什么。

GOGC 调的是账期，不是魔法。

调高它，相当于允许堆多长一段时间，用内存换 CPU；调低它，相当于让 GC 更勤快，用 CPU 换内存。至于 GOMEMLIMIT，它不是另一个版本的 GOGC，而是在告诉 runtime：这个进程由 Go 管的内存，最好别越过这条线。

所以这篇不打算把 GC 参数逐个解释一遍。线上真正需要的是一条决策路径：要不要调，调什么，调多少，什么时候停手。

先别问 GOGC 设多少，先问谁在付账

Go 官方 GC Guide 给过一个很关键的公式：

1

Target heap memory = Live heap + (Live heap + GC roots) × GOGC / 100

这句话不用背，抓住意思就行。

内存一直涨，不一定是泄漏：Go GC 真正在做什么

Thu, 21 May 2026 20:25:00 +0800

服务内存从 800MB 慢慢涨到 2.6GB。

曲线不陡，不像雪崩。它只是每天往上爬一点，重启以后掉下来，过几天又回到老地方。告警响了，群里第一句话通常是：是不是内存泄漏？

这个判断不算错，但太急。

在 Go 服务里，内存持续上涨可能是真泄漏，也可能是 live heap 变大了，可能是 GOGC 目标让下一轮回收来得更晚，也可能是短命对象太多，把 GC 拖进了频繁工作。还有一种更容易误判：heap 已经回收了，但 RSS 没有马上按你想象的方式降下来。

内存涨，不等于内存泄漏。

要把这件事查清楚，不能只盯 RSS。你得知道 Go GC 什么时候启动、怎么判断对象还活着、为什么需要写屏障、哪里会停顿，以及哪些参数是真的能调。

GC 不是保洁员，是成本调度器

很多人对 GC 的直觉是“内存不用了，运行时帮我扫掉”。这个说法只对了一半。

真正重要的是另一半：GC 每扫一次，都要花 CPU；扫得太勤，CPU 被回收器吃掉，服务吞吐和延迟会受影响。扫得太晚，内存峰值又会涨上去，容器可能先把你杀掉。

所以 Go GC 不是等地上脏了才来的保洁员。它更像一个拿着预算表的人：上一轮还有多少对象活着？再往后拖一点，内存能不能接受？现在开始扫，CPU 能不能接受？

Go 官方 GC Guide 讲得很清楚：GC 主要消耗 CPU 和物理内存。想省 CPU，就得允许堆多长一会儿；想省内存，就得让 GC 更频繁地工作。

这就是 GOGC 的本质。

GOGC=100 不是“内存达到 100MB 触发 GC”。它的意思更接近：在上一轮存活堆的基础上，允许新分配对象按约 100% 的比例增长，再触发下一轮 GC。Go 1.19 之后，目标堆计算还会把 GC roots 的成本纳入进来，可以简化理解为：

1

下一轮目标 ≈ live heap + (live heap + GC roots) × GOGC / 100

GOGC 调的是成本，不是情绪。

加 buffer 不是修 bug：Go channel 阻塞排查实战

Thu, 21 May 2026 18:30:00 +0800

goroutine 数量从 200 慢慢涨到 2 万。

监控图上那条线，不陡，但一直在爬。就像水龙头没拧紧——不喷，但也不会停。

你的第一反应是什么？

加大 buffer。

make(chan int, 100) 改成 make(chan int, 1000)。重启。观察。好像好了。

三天后，又涨回来了。

这不是运气差。这是 Go 服务最常见的线上问题之一：channel 阻塞导致 goroutine 泄漏。而"加 buffer"是社区里最流行、也最没用的解法。

buffer 只是把崩溃推迟了。问题的根因——谁在等谁、谁该退出、谁该 close——一个都没解决。

这篇文章做一件事：从"goroutine 涨了"这个信号出发，走一遍完整的排查路径，把 channel 的六个最常见陷阱逐个拆开。

不是背 API。

是下次线上出问题的时候，你知道先看什么。

发现：怎么知道 channel 卡住了

排查 channel 阻塞的第一步不是看代码，是看数字。

runtime.NumGoroutine()：最简单的基线

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


import "runtime"

func init() {
 go func() {
 ticker := time.NewTicker(30 * time.Second)
 defer ticker.Stop()
 for range ticker.C {
 log.Printf("goroutines: %d", runtime.NumGoroutine())
 }
 }()
}

这段代码放到任何 Go 服务的 init() 里，每 30 秒打一行日志。goroutine 数量只升不降，大概率有泄漏。

Go channel 不是高级锁，它是一种组织并发的语言

Thu, 21 May 2026 16:02:00 +0800

有人为了写得“更 Go”，把一个简单 cache 包成了 channel 协议。

每次 Get，先构造 request，发给 owner goroutine，再等 response channel 返回。还要处理 context、close、退出顺序、goroutine 泄漏。

最后代码确实没有显式 sync.RWMutex 了。

但问题也来了：本来一把锁能讲清楚的事，被写成了一套小型 RPC。

这不是优雅。

这是绕远。

Go 社区有一句被反复引用的话：

Do not communicate by sharing memory; instead, share memory by communicating.

很多人把它理解成：Go 不喜欢锁，channel 更高级，能用 channel 就别用 mutex。

这个理解太粗了。

channel 的价值不是把锁藏起来，而是把通信显式写出来。mutex 也不是“不 Go”，它就是保护共享状态的直接工具。

真正要问的不是：channel 和 mutex 谁更高级？

真正要问的是：你现在到底是在传东西，还是在护东西？

channel 首先讲的是结构，不是性能

Rob Pike 在那场很有名的演讲《Concurrency is not Parallelism》里，一直在压一个区分：concurrency 是 structure，parallelism 是 execution。

并发不是“同时跑得更快”的同义词。

并发先是一种组织程序的方式：把一件事拆成多个可以独立执行的单元，再让它们通过通信协调。

Go channel 源码不是在讲队列，而是在讲 goroutine 怎么排队

Thu, 21 May 2026 15:17:00 +0800

goroutine dump 里满屏 chan send，你知道它卡住了。

但它到底卡在哪里？

是缓冲区满了？没有 receiver？被 select 挂进了等待队列？还是 channel 被 close 之后才醒过来，然后 panic？

如果只停留在“channel 是 goroutine 之间通信的管道”，这些问题永远说不清。

ch <- v 这一行代码，在 Go runtime 里不是一句“把数据塞进队列”。它会走过 hchan、环形缓冲区、sendq / recvq、sudog、gopark、goready，最后决定一个 goroutine 是继续跑，还是挂起来等别人。

Go 的 channel 设计长期受 CSP 思想影响。Rob Pike 在 Go 早期设计和并发模型传播里反复强调：不要通过共享内存来通信，而要通过通信来共享内存。

这句话听起来像哲学，但到了 runtime 里，它会变成很具体的结构：谁在等谁，数据放在哪里，哪个 goroutine 应该被唤醒。

这篇只做一件事：沿着 Go 1.25.4 的 runtime/chan.go 和 runtime/select.go，把 channel 的几条关键路径走一遍。

不是为了背源码。

是为了让你下次看到 chan send、chan receive、close、select 的时候，脑子里有一张清楚的运行时地图。

channel 不是无锁队列，它是带调度语义的协作原语。

hchan：channel 在运行时到底长什么样

Go 代码里你写的是：

Go 服务 goroutine 涨了，别先猜：按这条流程查 context 泄漏

Thu, 21 May 2026 13:45:00 +0800

线上 goroutine 数开始往上爬，最怕的不是它涨。

最怕的是你盯着监控看了十分钟，然后开始猜：是不是 context 泄漏了？是不是超时没生效？是不是某个 channel 卡住了？

这些猜法都有可能对，也都有可能错。

runtime.NumGoroutine() 只能告诉你“现在有多少 goroutine”。它不会告诉你这些 goroutine 停在哪里，也不会告诉你是谁创建的，更不会告诉你为什么没有退出。

排查这类问题，第一步不是解释 context 原理。

第一步是采样。

这篇是 Go context 系列第三篇。前两篇讲过 context 的生命周期、cancel 的边界，以及 Go 为什么坚持显式传 ctx。

这一篇换一个角度：不从源码开始，从排查现场开始。

一套最小流程就够了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


goroutine 涨了
 ↓
先采样，确认趋势
 ↓
用 pprof 找等待点
 ↓
用 go vet 查静态路径
 ↓
按创建路径、取消路径、响应路径回到代码
 ↓
修复，再验证

Go 为什么宁可让你多传一个 ctx 参数

Wed, 20 May 2026 22:20:00 +0800

很多 Go 开发者第一次系统用 context，都会嫌它啰嗦。

一个请求从 handler 进来，service 要传 ctx，repo 要传 ctx，RPC client 要传 ctx，连中间那些根本不关心超时和取消的函数，也要机械地把 ctx 往下递。

看多了以后，很自然会冒出一个问题：为什么不能像 Java、Node.js、Python 那样，把上下文放进运行时里？

Java 有 ThreadLocal。Node.js 有 AsyncLocalStorage。Python 有 contextvars。它们都能让深层函数不改签名，也拿到当前请求的 trace id、用户信息、日志上下文。

Go 偏不。

它宁可让你在函数签名里多写一个参数：

1
2
3


func DoSomething(ctx context.Context, arg Arg) error {
 // ...
}

这不是因为 Go 不知道隐式上下文更省事。恰好相反，这正是 Go 的取舍：它愿意把“不优雅”摆在台面上，换调用链里的生命周期可见。

显式传参，最先付出的就是签名噪音

先承认代价。

ctx context.Context 作为首参，会污染函数签名。尤其在分层很深的服务里，中间层经常只是 pass-through：自己不用 ctx，但必须接住它，再传给下一层。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


func (h *Handler) Create(ctx context.Context, req CreateReq) error {
 return h.service.Create(ctx, req)
}

func (s *Service) Create(ctx context.Context, req CreateReq) error {
 return s.repo.Insert(ctx, req.UserID, req.Payload)
}

func (r *Repo) Insert(ctx context.Context, userID string, payload []byte) error {
 _, err := r.db.ExecContext(ctx, `insert into ...`, userID, payload)
 return err
}

这段代码里，Handler 和 Service 可能都没有真正“使用” ctx。它们只是把一段调用生命周期交给更底层的数据库调用。

Go context 最容易被误用的地方：以为 cancel 会替你收拾现场

Wed, 20 May 2026 17:50:00 +0800

线上接口开始超时，goroutine 数一路往上涨。

你第一反应可能是：不是已经传了 context.WithTimeout 吗？超时到了，goroutine 不就该停了吗？

这就是 Go context 最容易被误用的地方。

context 不负责替你停掉 goroutine。它只负责把“该停了”这句话传到门口。门里的人听不听、什么时候退场，要看你自己的代码。

这篇是 Go context 系列的第一篇。先不急着讲 HTTP、gRPC、database/sql 这些框架怎么接入，也不急着把所有 API 列一遍。

我们先把最底下这层讲清楚：context 到底是什么，cancel 到底做了什么，为什么 WithTimeout 后面那句 defer cancel() 不是仪式感，而是资源释放动作。

事故通常不是从源码开始的

真实排查里，很少有人一上来就打开 context.go。

更常见的是这样的场景：

一个接口偶发超时。压测一上来，P99 开始抖，错误日志里出现 context deadline exceeded。你看监控，CPU 没打满，内存也没爆，但 goroutine 数不太对，一路往上爬。

然后你打开 pprof：

1

curl -s 'http://127.0.0.1:6060/debug/pprof/goroutine?debug=1'

采样里有一批 goroutine 卡在业务 worker 上，等某个 channel，或者等 <-ctx.Done()。

这时候最危险的判断是：

“是不是 Go 的 context 泄漏了？”

大多数时候，不是。

更可能是你的调用链里少了三件事之一：创建了 timeout context 但没及时 cancel；启动了 goroutine 但没监听 ctx.Done()；或者监听了 Done，却没有确保取消路径真的跑到。

给 Cursor 一个小需求，怎样让它先计划、再修改、再验收

Wed, 20 May 2026 10:39:00 +0800

这篇不讲安装，也不讲一堆按钮。

我们只做一件小事：给 Cursor 一个登录页，让它把页面视觉调得更像一个正式产品，但不允许它改业务逻辑。

任务很小，正好适合练手。小到你能看完所有 diff；也真实到足够暴露问题。很多人用 Agent 翻车，不是让它做了多复杂的架构，而是从一句“帮我优化一下页面”开始，最后发现字段、校验、接口路径都被顺手动了。

这一次不追求“让 Cursor 改得多快”。

我们只看一件事：它能不能按你的节奏走，分析、计划、执行、验收。

准备一个小到能验收的项目

我用的是一个最小登录页 demo，只有四个核心文件：

1
2
3
4
5


cursor-agent-demo/
├── index.html
├── style.css
├── login.js
└── tests/login.test.js

页面里有两个字段：邮箱和密码。

表单的业务契约也很明确：

1
2
3
4


<form id="loginForm" action="/api/login" method="post">
 <input id="email" name="email" type="email" required />
 <input id="password" name="password" type="password" required minlength="8" />
</form>

这次需求只允许改视觉层：背景、卡片、阴影、圆角、按钮质感。

不能改这些东西：

表单字段名
form action
请求路径
required
minlength
提交流程

如果你第一次练 Cursor Agent，我建议也从这种项目开始。不要一上来就让它改业务模块、重构页面、接新接口。项目越大，你越容易被一堆看起来很努力的 diff 淹没。

Agent 不是不能做大任务。

但你得先练会怎么管住小任务。

第一步：只分析，不许改

很多人给 Cursor 的第一句话是：

1

帮我优化登录页。

这句话太危险。

“优化”是什么？只改样式，还是改交互？能不能抽组件？能不能动校验？能不能顺手把 HTML 结构也重排？你没说清楚，Agent 就只能猜。

Cursor 真正难的不是安装，是别把 Agent 用成自动补全

Fri, 15 May 2026 18:45:00 +0800

你只是想让 Cursor 改一个登录页。

它很积极。顺手改了组件结构、路由命名、校验逻辑，还帮你重排了几个文件。

diff 很长，像是干了很多活。问题是你不敢合并。

这就是很多人用 Cursor 的真实卡点。不是不会安装，不是不知道 Chat 在哪，也不是模型不够强。

难的是：你得学会管住一个会主动行动的 Agent。

Cursor 的价值不在“让 AI 多写几行代码”。它真正改变的是开发者和代码库之间的关系。过去你是在编辑器里写代码，现在你是在编辑器里指挥一个会读文件、改文件、跑命令、解释 diff 的执行者。

如果还把它当成更聪明的自动补全用，结果通常只有两种：要么大材小用，要么放它乱跑。

低门槛，反而容易误判

Cursor 对 VS Code 用户很友好。

打开项目，侧边栏聊天，选中文件提问，让它解释一段代码，或者直接让它改一个小功能。这些动作都很自然。Cursor 官方文档里也把 Agent 定义得很直接：它可以完成复杂编码任务，可以运行终端命令，也可以编辑代码。

这很方便，但方便会制造一个错觉：装上就会用了。

实际上，装上 Cursor 只是打开了入口。真正决定结果的，是你怎么给它上下文、怎么限制改动范围、怎么验收输出。

很多人第一次用 Cursor，都会写这种 prompt：

1

帮我优化登录页。

这句话看起来没问题，实际问题很大。

“优化”是什么意思？改视觉，还是改交互？能不能动接口请求？能不能改路由？能不能顺手抽组件？改完怎么判断对不对？

你没说，Agent 就只能猜。

Agent 的可怕之处不是它不会做事，而是它太愿意做事。你给一个含糊任务，它会补齐你的空白。补得对，是惊喜；补得错，就是事故。

不要直接让它改，先让它只分析

我做了一个最小实测项目：一个纯 HTML/CSS/JS 登录页。

项目很小，只有这几个文件：

1
2
3
4
5


cursor-agent-demo/
├── index.html
├── style.css
├── login.js
└── tests/login.test.js

任务也很小：只调整登录页的视觉层，不改变字段、表单 action、请求路径和校验逻辑。

Hermes Kanban 实战：别再用聊天记录管理多 Agent 团队

Wed, 13 May 2026 15:36:00 +0800

你把任务卡创建好了，researcher、writer、coder 也都分配了。

然后什么都没发生。

这不是 bug。恰恰相反，这是 Hermes Kanban 最容易被误解、也最值得讲清楚的地方：创建 card，不等于启动 worker。

很多人把多 Agent 系统想得太像“开几个聊天窗口”。一个负责调研，一个负责写稿，一个负责代码，大家各干各的。听起来很美，真跑起来就会发现：谁先干？谁等谁？谁审核？交付物放哪？失败了谁接？

靠聊天记录和几个 Markdown 文件也能凑合跑。但只要任务链稍微长一点，协作就开始变脆。

Hermes Kanban 解决的不是“让 Agent 更聪明”。它解决的是另一个更工程的问题：

把 Agent 的工作，放进一条可追踪、可审核、可恢复的流水线里。

这篇不讲概念安利，只讲怎么用。

先记住一句话：Kanban 是任务系统，不是魔法按钮

Hermes Kanban 是一块持久化的任务板。你可以用它创建任务、分配 assignee、声明 parent/child 依赖、绑定 workspace、记录 comment、阻塞等待审核、完成后给下游传 handoff。

它适合管这种任务：

一个任务需要多个 profile 接力，比如 researcher → writer → default；
下游必须等上游交付后才能开始；
交付物必须有路径、有验证、有审核记录；
任务失败后不能靠人翻聊天记录猜状态；
你希望 worker 不只是“答一句”，而是按岗位技能执行。

它不适合管这种任务：

你只是问一句命令怎么写；
任务几分钟就能完成，没有上下游；
没有明确交付物，也不需要审核；
你还没把需求想清楚，只是随手丢一个念头。

这也是为什么 Hermes Kanban 的六列看板很重要。它不是装饰，它是任务生命周期。

六列可以这样理解：

列	含义	你该做什么
Triage	原始想法，还不是可执行任务	点 Specify，或用 `hermes kanban specify` 补成任务简报
Todo	任务已创建，但依赖未满足或还没分配	等 parent 完成，或补 assignee
Ready	已经可执行，等 dispatcher 或人工 claim	检查 gateway/dispatcher 是否在跑
In Progress	worker 已 claim，正在执行	看 heartbeat、runs、log
Blocked	等审核、等补料、或断路器触发	看 block reason，决定 unblock 还是打回
Done	任务完成	看 summary 和 metadata，给下游消费

不要小看这六列。多 Agent 协作最大的问题，不是 Agent 不会做事，而是状态没人管。

Claude Code vs Cursor：不是选工具，是选入口

Fri, 08 May 2026 11:30:00 +0800

花 $200 买了 Cursor Ultra，发现请求数不够用。

又花 $100 买了 Claude Code Max，结果两个工具各跑各的。Claude 改完代码，Cursor 不知道；Cursor 里聊了半天，Claude 从头开始。

最后两边都浪费，你还得花精力在两个界面之间切换。

这不是工具的问题。

是你没想清楚一件事：你习惯在哪干活，就该在哪接 AI。

很多人选 Claude Code 还是 Cursor，看的是功能对比表：谁上下文更大、谁模型更强、谁更便宜。

这个思路从一开始就错了。

工具选型不是比功能，是比入口。

先说结论：两个都能用，但入口不同

Claude Code 和 Cursor 的核心差异，不是"谁更强"。

是交互入口不同。

	Claude Code	Cursor
入口	终端	编辑器/对话环境
工作流	命令驱动，批量操作	对话驱动，可视化交互
上下文管理	需要手动 `/compact`	最高 1M tokens
自动化	天然适合 CI/CD、脚本	更适合人工交互
适合谁	终端重度用户、批量编码	习惯对话式开发、大上下文项目

Cursor 2.0 之后，已经明显偏向对话式开发环境。不要再把它简单理解成"看代码和调试"的辅助 IDE。

Claude Code 把工作流压进终端，Cursor 把工作流放进对话环境。

你选的不是工具。

别让 Claude Code 一路狂奔：高手都在盯这 5 个地方

Fri, 08 May 2026 11:30:00 +0800

Claude 修一个 bug，顺手改了 12 个文件。

它删了旧组件，换了依赖，重写了一段状态管理。终端里日志飞快滚动，看起来很努力，也很专业。

你隐约觉得不对，但没按 Esc。

十分钟后，测试挂了，页面也挂了。最麻烦的是，你已经看不清它到底从哪一步开始跑偏。

很多人用 Claude Code 的进阶方式，恰好是错的：把权限开大，把确认关掉，把任务丢进去，然后等它“一路跑完”。这不是高手，这是把方向盘交出去。

Claude Code 真正好用的地方，不是它能连续工作，而是你能在它工作时不断校准。

真正的进阶，不是放手，而是会接管。

先理解它为什么会跑偏

Anthropic 的 Cal 在官方最佳实践分享里提到一个很关键的心智模型：Claude Code 很像一个“只用终端的同事”。

它不是靠提前索引整座代码库，然后从向量数据库里召回文件。按照官方分享里的说法，它更像一个新同事进入项目：用搜索、glob、grep、find 之类的方式，一点点探索代码库，看到结果后再决定下一步搜哪里。

这套方式很灵活，但也有代价。

它会不断读文件、跑命令、改代码，上下文越来越长，判断会受当前看到的信息影响。如果你一开始没给规则，中途不看计划，最后也不跑测试，它当然可能越走越偏。

所以 Claude Code 的进阶，不是让它更自由。

而是给它一条轨道。

第一个地方：CLAUDE.md，不是备忘录，是项目规则

很多人知道 /init 可以生成 CLAUDE.md，但写完就放在那里了。

这很浪费。

官方分享里说得很清楚：当你启动 Claude Code 时，如果当前工作目录里有 CLAUDE.md，它会被放进上下文里，作为开发者留给 Claude 的重要指令。

这不是“给 Claude 留一句备注”。

这是你给它的项目规则。

CLAUDE.md 里至少应该有三类信息：

类型	应该写什么	例子
项目结构	模块在哪里，测试在哪里，入口在哪里	`src/app` 是路由，`src/lib` 放业务逻辑
运行方式	怎么启动、测试、构建	`npm test`、`npm run typecheck`、`npm run lint`
工程约束	不能做什么，修改前要注意什么	不要引入新状态库；改 API 前先看兼容层

一个实用模板：

装了 Claude Code，别上来就写 prompt

Fri, 08 May 2026 10:00:00 +0800

装好 Claude Code，打开终端，输入第一句话：

帮我做一个办公室排班应用。

五分钟后，Claude 生了一堆文件。npm install 跑不起来，页面打不开，你盯着终端不知道该从哪开始修。

问题不在 Claude Code，在你给 prompt 的方式。

很多人装完 Claude Code 的第一反应是把它当聊天机器人用——扔一句话，等它干活。结果就是：代码能生成，但跑不起来；功能有，但结构乱；改一处，崩三处。

这篇文章不罗列功能，不背参数。只讲一件事：怎么从装好 Claude Code 到做出第一个能跑的项目，中间不翻车。

Claude Code 是什么

一句话：Anthropic 出的终端 AI 编程工具。

它不是 IDE，不是编辑器，是一个跑在终端里的 AI 代理。你能跟它对话，它能读你的代码、改你的文件、跑你的命令、提交你的 Git。

Anthropic 团队里有个说法很准确：

Claude Code 就像那个只用终端的同事——从不碰 GUI，但什么都能搞定。

它和 Cursor 的区别也很简单：Claude Code 是终端里的 AI，Cursor 2.0 之后更偏向对话式开发环境。两者不冲突，但分工不能再按老版本 Cursor 来理解——不要再把 Cursor 简单当成“看代码和调试”的辅助位。

安装：三分钟搞定

前置条件

装了 Node.js（node -v 能出版本就行）
有 Claude 付费订阅（Pro / Max / Teams / Enterprise），或者有 API Key

2026 年 4 月 21 日 Anthropic 曾短暂从 Pro 计划中移除 Claude Code 访问权限，后恢复。定价政策可能波动，写这篇文章时的价格是：Pro $20/月、Max 5x $100/月、Max 20x $200/月。

别为了 Agent 而 Agent：2026 年多 Agent 工作流实战指南

Sat, 25 Apr 2026 10:00:00 +0800

一个团队花了两周，搭了三 Agent 流水线——研究员搜集数据、写作者整理报告、审核者把关质量。

跑起来之后发现：每次执行花 40 秒，API 账单涨了 3 倍，调试时根本不知道哪个 Agent 说了什么。

最后他们回到单 Agent，5 行代码解决了同样的问题。

这不是个例。2026 年，多 Agent 工作流成了 AI 圈最热的方向。但很多团队的问题不是不会搭多 Agent，而是根本不需要。

能单 Agent 解决的，别拆成三个。

如果你看完这篇，判断自己的场景确实需要多 Agent——这篇能帮你选对框架、跑通示例、避开坑。如果判断不需要——恭喜你，省了两周围绕三个 Agent 转的日子。

先判断：你到底需不需要？

Agent 越多，调试越难，成本越高。

该用的场景：

复杂多步骤工作流，有分支、循环、暂停恢复——单 Agent 写出来像意大利面
需要不同"角色"各司其职——研究员、写作者、审核者，每个角色的 system prompt 差异很大
需要人类在环审批——跑到一半暂停，等人确认后再继续
编码任务需要沙箱隔离——Agent 生成的代码不能直接在宿主机跑

不该用的场景：

简单问答/单步任务——引入多 Agent 是过度工程，直接用单 Agent 或 OpenAI API
高确定性流水线——对话式控制流不可预测，用传统状态机/工作流引擎
实时性要求高——LLM 调用延迟 + 多轮累积延迟，用缓存 + 异步处理
无 LLM 的纯规则引擎——不需要 LLM 能力，用 transitions、state_machine 等库
严格合规/审计——对话路径难以完全预测和审计，用确定性工作流引擎

一句话判断： 如果你的任务可以写成"输入 → 处理 → 输出"三步，别用多 Agent。如果需要分支、循环、多角色协作、人类审批，再考虑。

你以为自己会用 PostgreSQL，其实你只是会写 SQL

Mon, 13 Apr 2026 17:18:00 +0800

很多开发者天天在用 PostgreSQL，但只要你追问三个问题，场面就会立刻安静下来：它为什么并发强？为什么崩了还能恢复？为什么 JSONB、大文本这些大字段没把系统拖死？

如果这些问题你平时很少认真想过，那你多半还停留在“会用 PostgreSQL”的表层。说得再狠一点：很多人其实不是理解 PostgreSQL，只是会写 SQL。

我把 Claude Code 改造成了自动化工程系统，不再陪它聊天了

Tue, 07 Apr 2026 15:00:00 +0800

你有没有这种感觉：

用 Claude Code 的时候，每次都要重新交代背景。

让它写个脚本，要说明项目结构；让它查个 bug，要解释代码逻辑；让它写篇文章，要重复一遍要求。

同样的任务，说一遍又一遍。

输出质量还时好时坏——心情好时写得不错，心情不好时直接跑偏。

问题不在模型。

问题在于，你一直在陪它聊天，而不是让它工作。

2025 年的 Claude Code，早已不是单纯的聊天工具。

通过五层扩展机制，你可以把它改造成一个可靠的自动化工程系统：

CLAUDE.md 是记忆，Skills 是知识，Commands 是流程，Subagents 是团队，Hooks 是纪律。

今天这篇文章，不聊概念，只给能落地的框架。

看完之后，你可以直接照着搭建自己的工作流。

PostgreSQL 入门：为什么说它能装下世间万物？

Tue, 07 Apr 2026 12:16:00 +0800

这是世界上最先进的开源关系型数据库。

PostgreSQL 的能力早已超越了传统关系型数据库的范围。现代开发中，为了解决各种问题，各类花哨的工具层出不穷——缓存用 Redis、全文检索用 Elasticsearch、文档存储用 MongoDB、向量数据库用专门的方案、定时任务跑在 K8s 上。

但有时候，仅仅一个 PostgreSQL，就能覆盖大部分后端开发需求。

Redis 最容易踩的 7 个坑，问题往往不在 Redis

Sat, 04 Apr 2026 12:10:00 +0800

很多人觉得 Redis 没什么门槛。

命令不难，接入也快，压测时还总能打出很漂亮的数字。于是项目上线后，大家默认它“应该不会出事”。

但我看过不少 Redis 问题，最后都不是 Redis 自己不行，而是前面的设计太随便：Key 怎么拆，TTL 怎么设，热点怎么扛，内存打满以后怎么办，这些事一开始没想清楚，后面都会用线上故障补课。

我最近刷到一条讲 Redis 避坑的短视频，里面提到的点很典型。我没有照着转写，而是按“线上最容易出事故的顺序”重新整理成这篇文章。

如果你只记一句话，那就是：

Redis 真正危险的坑，大多不是命令层面的，而是设计层面的。

Gemma 4 刚发布，我连夜把它装进了 OpenClaw

Fri, 03 Apr 2026 10:20:00 +0800

昨天 Gemma 4 刚发，今天它已经跑在我本地了，而且接进了 OpenClaw。

很多人一看到新模型发布，第一反应是去搜教程。

然后就会看到两类内容：

一堆参数表，读完还是不知道怎么装
直接甩一句 ollama pull xxx，结果你一跑就报错，因为库里根本还没有，或者版本不对

所以这篇文章我不聊空话，只讲一条真的能跑通的链路：

1
2
3


hf download
→ ollama create
→ OpenClaw 接入

这条路的好处很现实：

你知道模型文件是从哪里来的
你知道自己下的是哪个量化版本
你不需要赌 Ollama 官方库有没有同步
你装完就能在 OpenClaw 里用，不是“理论上可行”

如果你只想要一句结论，那就是：

先别冲 31B，也别一上来折腾一堆转换脚本。先从 Gemma 4 E4B 开始，用 GGUF 跑通本地链路，这是最稳的。

Qwen 3.5 小模型本地部署实战：在 OpenClaw 中跑出自己的 AI 助手

Thu, 05 Mar 2026 10:37:00 +0800

阿里最新发布 0.8B-9B 端侧模型，10 分钟完成部署，显存最低 500MB。本文实测 4 种型号在 OpenClaw 中的表现，含完整配置、性能数据、踩坑记录。

写在前面

2026 年 3 月初，阿里通义千问发布了 Qwen 3.5 小模型家族（0.8B/2B/4B/9B）。没有发布会，但技术文档里的几个数字让我停下了手头的工作：

0.8B 模型显存占用 ~500MB
4B 模型支持 原生多模态（非适配器方案）
9B 模型用了 Scaled RL 强化学习

我花了一下午把这四个型号全部署到 OpenClaw 里跑了一遍。结论先行：端侧 AI 的拐点，可能真的到了。

下面是完整实测报告，包含部署步骤、配置方法、性能数据和踩坑记录。你可以直接照着做。

一、Qwen 3.5 小模型家族规格

1.1 型号对比

型号	定位	适用场景	VRAM 占用	推理速度
0.8B	边缘设备/IoT	传感器数据处理、简单指令	~500MB	120 tokens/s
2B	移动端/轻量任务	聊天机器人、文本分类	~1.5GB	85 tokens/s
4B	轻量级 Agent	多模态任务、自动化流程	~3GB	65 tokens/s
9B	推理与逻辑	代码生成、复杂推理	~6GB	42 tokens/s

测试环境：MacBook Pro M3，16GB 统一内存，量化版本 Q4_K_M