一、一个不写字的模型

9 月 15 日，一条推文在开发者社区里传开。

发帖人是 Diogo Almeida。他说自己参与发明了 ChatGPT，然后一直在问自己一个问题：为什么对话模型已经强到超人，AGI 还是没有出现？过去两年他"隐身"，用一种新的训练方法（RLCD）训出了一个新类型的模型，今天发布，名字叫 Jev。

他给出的数字：快 20–200 倍，便宜 40–400 倍。TypeSafe AI 同期宣布了 4000 万美元种子轮。

接下来几天，用 TechCrunch 的标题概括就是："一个来自 ChatGPT 发明者的新型 AI 模型，正在让开发者兴奋。"Reddit 上 r/ArtificialInteligence 的帖子一天之内冲到 120+ 评论，标题是"Jev / TypesafeAI is revolutionary as LLM's"，正文第一句："Jev is insane."X 上 @0xCodila 说这是 AI 行业的"互联网时刻"，@akshay_pachaar 的总结是："我们一直拿 LLM 当锤子，敲每一个 AI 问题，哪怕是再简单不过的判断。Jev 用毫秒和零头的成本把这些判断接了过去。"中文社区里，@Saccc_c 的推荐很直接："强烈建议大家都亲自试试 Jev，能让你的 Codex 操作速度提高 10 倍并省下大量 token。"

同时，接下来的这几天，我的X时间线全被jev刷屏了。

社区的动作也很快。一周之内，已经长出一圈配套工具：给 Claude Code 和 Codex 用的代码评审插件 jev-review、官方的 TypeSafe Skill、把命令风险检查接进 Claude Code hook 的脚本，还有人做了 jevable.com，把散落在 X 上的演示项目收集成可筛选的目录。有人把 X 上 28 个 Jev 用例归成八个方向，从 Agent 调度、记忆筛选、代码质量检查，到浏览器操作、业务分流、实时交互辅助和游戏控制。这些方向的共同点是：判断高频发生、候选范围有限、需要理解语境，而且错了能发现、能补救。一批资源站也纷纷涌现。

但有个事实绕不开：Jev 不做生成。

它不会写文章，不会写代码，不会跟你聊天，也不能解释自己为什么这么选。你给它一段状态（state）和几个带选项的问题，它返回一组类型化的答案和概率，然后停止。

当所有人都在比谁的模型写得更长、更像人的时候，TypeSafe 走的是另一个方向，把模型做成软件里的一个判断原语。最通俗的类比，是一个聪明的 if 语句。

阅读全文

这里给你一个典型的循环内复用 timer 的例子,这是 NewTimer+Reset 最常见的使用场景:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

func worker(ctx context.Context, workCh <-chan Task) {
    timer := time.NewTimer(5 * time.Second)
    defer timer.Stop()

<!--more-->
    for {
        // 每次循环前重置计时器
        if !timer.Stop() {
            // Stop 返回 false 说明计时器已经触发过、channel 里可能有值
            // Go 1.23+ 之后 channel 是同步的,不会有历史遗留的过期值,
            // 但为了兼容旧版本,drain 一下更保险
            select {
            case <-timer.C:
            default:
            }
        }
        timer.Reset(5 * time.Second)

        select {
        case task := <-workCh:
            handle(task)
        case <-timer.C:
            fmt.Println("5秒内没有新任务,做一次心跳/清理")
        case <-ctx.Done():
            return
        }
    }
}

关键点说明:

1. timer.Stop() 的返回值:如果计时器已经到期或已被停止,返回 false,这时候 channel 里可能还留着一个未被读取的值(旧版本行为),需要手动 drain 掉再 Reset,否则下一次 select 可能立刻读到这个旧值。

2. Go 1.23+ 的简化:由于 timer channel 现在是同步的,Stop/Reset 返回后能保证不会再收到过期值,所以在新版本里,上面这段 drain 逻辑理论上可以省略,直接:

1

timer.Reset(5 * time.Second)

但如果你的代码库要兼容旧版本 Go,保留 drain 逻辑是更安全的写法。

3. defer timer.Stop():即使 Go 1.23 之后未 Stop 的 timer 能被 GC,显式 Stop 依然是好习惯——能让底层的 timer 立刻从运行时的堆里摘除,而不是等 GC 扫描到。

如果只是简单的"一次性超时",不涉及循环复用,直接用 time.After 或者一次性的 NewTimer 就足够了,不需要这套 Reset 逻辑。

Go 1.27 已经在 2026 年 8 月 19 日正式发布,而且这个版本里有个关键变化:asynctimerchan 这个 GODEBUG 开关被彻底移除了——也就是说 Go 1.23 引入的"新计时器实现"(可被 GC 回收 + 同步 channel)在 1.27 里变成了唯一行为,不再有任何回退旧实现的选项。

回到最初的问题:Stop() 还需要调用吗?——需要,而且仍然是最佳实践。 原因和"会不会内存泄漏"是两件事:

1. GC 回收 ≠ 立即释放
即使不 Stop,不再被引用的 timer 最终会被 GC 清理掉,但这依赖于 GC 扫描周期。如果你的程序创建 timer 很频繁,不 Stop 意味着这些对象要一直等到下一轮 GC 才能真正释放,期间仍然占用内存和运行时的计时器堆(timer heap)空间,增加不必要的 GC 压力。显式 Stop 能让资源立刻释放。

2. Ticker 是完全不同的情况,必须 Stop
这是最容易踩坑的地方。Ticker 会持续触发,只要它还被某个存活的 goroutine 引用(比如一个 for { select { case <-ticker.C: ... } } 循环),它就是可达的,GC 根本不会回收它,会一直触发下去,浪费 CPU 唤醒和调度开销。Go 1.23+ 的自动回收解决的是"对象不可达时被 GC 捡走",但只要 ticker 还在被使用中的 goroutine 持有,它就不会被自动回收——这种情况下不 Stop 就是真正的资源泄漏,和 Go 版本无关。

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

func poll() {
    ticker := time.NewTicker(time.Second)
    defer ticker.Stop() // 必须显式调用,否则 ticker 会一直运行下去

    for {
        select {
        case <-ticker.C:
            doSomething()
        case <-done:
            return
        }
    }
}

3. AfterFunc 场景下 Stop 直接影响程序逻辑
time.AfterFunc 到期后会在新 goroutine 里执行回调,如果你想在某个条件下取消这个回调执行,必须调用 Stop(),这和内存回收完全无关,是功能正确性问题。

总结一句话:Go 1.27 把"未 Stop 的 timer/ticker 不会造成内存泄漏"这件事变成了语言运行时的永久保证,你不再需要担心 time.After 在 select 里被跳过导致的经典泄漏。但 Stop() 依然是推荐的显式资源管理习惯——尤其是 Ticker,不 Stop 会导致它无限期继续触发,这跟 GC 能不能回收内存没有关系。简单说:一次性的 Timer/time.After 现在"忘记 Stop 问题不大",但 Ticker 永远要 Stop。

关系型数据库存 JSON 早就不稀奇了，但把它用对没那么简单。你得先分清 PostgreSQL 里 json 和 jsonb 到底差在哪、什么时候该建什么索引，再决定 Go 代码里怎么读写才不别扭。这篇就把这几件事讲清楚，代码都能直接抄进项目。

一、三种类型的本质区别

• PostgreSQL 绝大多数场景直接用 jsonb。只有当你需要"原样存回、包括空格和键顺序"这种审计类需求时才用 json。
• MySQL 只有 json 一种（内部实现类似 jsonb，二进制存储、支持部分更新）。

阅读全文

同样叫 timestamp，MySQL 和 PostgreSQL 的含义完全不同：一个是绝对时刻，一个是墙钟时间，正好相反。踩坑重灾区，也是面试高频题。这篇文章把两者放在一起对齐比较，并且提供了 Go 语言和 Java 语言应用访问数据库时间类型字段的坑。

前四节讲数据库侧（类型语义与对照），后四节讲应用侧（时间从应用流到列的链路、Go 与 Java 驱动的行为、可直接抄的配置清单）。

一、先分清两种语义

一切混乱的根源是"时间"这个词同时指两样东西：

• 绝对时刻（instant）：世界上唯一的一个瞬间，比如 2026-09-05 00:00:00 UTC。下单、日志、消息发送用它。任何时区看到的都是同一个点，只是显示不同。
• 墙钟时间（wall time）：挂钟上的读数，比如"早上 9 点开会"。不带时区就没有唯一时刻，但业务要的就是这个字面值：每天 9:00 的闹钟、营业时间、生日、定时任务。

四种数据库类型各占一边：

名字陷阱就在这张表里：MySQL 的 TIMESTAMP 对应 PG 的 timestamptz，不是 PG 的 timestamp。跨库迁移或写 ORM 时极易搞反。后面所有内容都是这张表的展开。

阅读全文

告诉coding agent一句话： 『实现一个网页版五子棋游戏』，对比目前各最新的大模型的能力。测试不一定很科学的测试个大模型的能力，只能说从一个用例方向上做对比。

综合分析

同一句提示词「实现一个网页版五子棋游戏」，通过 pigo 命令行、medium 思考档位，分别丢给 8 个最新模型，得到的结果差异相当明显。总体上每个模型都完成了「能玩的五子棋」这个基本盘，但在是否带 AI 对弈、运行方式、设计审美、工程严谨度四个维度上分化清晰。其中 deepseek-v4-flash 和 kimi-k3 是综合表现最好的两个——功能全、AI 实测能用，而且都自带了测试。

阅读全文

pigo 是一个类似pi coding agent的ai coding agent，使用Go语言开发。

你可以通过下面的命令安装它:

1

curl -fsSL https://raw.githubusercontent.com/smallnest/pigo/master/install.sh | sh

在配置文件配置（推荐），或者命令行中输入参数也可以：

尝试了它的功能，你一定好奇，这样一个功能完备的ai coding agent是怎么快速开发出来的？

开发这个项目主要有两个目的，而且这两个目的都达到了：

• 为Go生态圈提供一个小巧灵活，功能强大、易于扩展的Agent, 就像 Pi agent、Claude code那样。既可以作为coding agent日常使用，也可以作为SDK方便集成到Go程序中使用
• 通过真实的项目证明，goal-workflow这套从需求到上线这套AI时代的软件开发工程方法非常有效，可以舒舒服服的开发中小型应用，而且也适合AI主导的项目后期的维护

所以本文想从这两个方面分享从零开发这个项目的经验，同学可以各取所取，从不同的关注点了解这个过程。

阅读全文

TypeScript 名师 Matt Pocock 开源了一套 Claude Code Skills（https://github.com/mattpocock/skills）。据他在 X（Twitter）上的说明，这套 skills 的核心是 5 个命令串起来的一条主线：

/grill-with-docs → /to-spec → /to-tickets → /implement → /code-review

即：先把想法拷问清楚 → 写成规范 → 拆成卡片 → 动手实现 → 双轴评审。

这套 skills 的问题在于文档跟不上功能，很多人拿到手不知道怎么用。我此前也搭过一套类似流程，并用这套 skills 开发了一个 Go 版本的 pi agent（https://github.com/smallnest/pigo ，仓库里的 issues 都是这套 skill 生成的），因此对它的运作有一定了解。本文介绍这套流程。

安装命令：

1

npx skills add mattpocock/skills

阅读全文

"Clear is better than clever."
清晰胜于聪明。
—— Rob Pike, Go Proverbs

第 23 章把重构讲完了。嗅坏味道、套 Fowler 手法、小步施工、每步测试，这套东西对 Java、Python、Go 一视同仁。但真到 Go 上手你会发现，Fowler 的目录够不着 Go 的好几层脾气。一段能跑的 Go 代码，可能还停在 Go 1.10 的写法，不地道；可能并发原语用错了，race detector 一开就红，不安全；也可能分配没控住，cache line 在 false sharing，不快。这些坏味道扫不出来，是 Go 二十年攒下来、只有老手才摸得到的门道。

门道都散在各处。Dave Cheney 的高性能工作坊讲一套，dgryski 的 go-perfbook 讲一套，《Go 并发编程实战》讲一套，Go 团队的 modernize 分析又讲一套，再加上无数生产事故换来的风格约定。以前你得一本书一本书读、一个 pprof 一个 pprof 啃。现在有人把这些蒸成一个 Skill，Agent 调一下就能用。

本章介绍五个 Go 专属的 Skill，正好覆盖 Go 工程的四个面：现代化（/modern-go）、性能（chao-go-perf）、并发（chao-go-sync）、风格（go-style-guide），外加一个把这几样打包、还顺带做了效果评估的全家桶（cc-skills-golang）。前三个是本书作者 smallnest 写的，对，写这本书的人和写这些 Skill 的人是同一个；后两个分别来自 madflojo（Benjamin Cane）和 samber。

阅读全文

事情的起点，是 Go 仓库里一个很普通的 issue（golang/go#77273）。

在 Go 这种量级的开源项目里，每天都有人提出各种各样的提案：增加一个语法糖、调整一处行为、复活一个曾经被否决的设计……其中有相当一部分，是在重新提起一个早已被讨论过、并且已经下过结论的话题。

对维护者来说，这是一件很消耗精力的事。如果每个人都可以无限次地把一个已经决定的问题重新拉出来辩论一遍，那么决策永远不会真正「落地」，团队会被无穷无尽的回锅讨论拖垮。

于是，在这条 issue 的讨论里，有人贴出了 Go 官方提案流程（go.dev/s/proposal）中的一段话：

一般来说，对于「重新审议此前已经决定的提案」这件事，我们的做法遵循 John Ousterhout 在他那篇 Open Decision-Making 中给出的建议，尤其是其中「Reconsideration（重新审议）」那一节。

换句话说，连 Go 团队这样的顶级工程组织，在「怎么做决策、决策之后还要不要重新讨论」这件事上，引用的也不是某套高深的管理学理论，而是 John Ousterhout —— 也就是写《软件设计的哲学》那位斯坦福教授 —— 的一篇博客。

那一节的核心其实只有一句话：当有人想推翻一个已经做出的决定时，先问一句 「你掌握了什么新的信息？」（What new information do you have?）。如果没有新信息，那就不必重新讨论；如果有，那随时欢迎修正。

这套关于「决策」的方法论，远不止「要不要重新讨论」这一个点。Ousterhout 在这篇文章里，系统地讲了他在两家创业公司里摸索出来的一整套**开放式决策（Open Decision-Making）**框架。

下面是这篇文章的完整翻译。

开放式决策

作者：John Ousterhout，斯坦福大学计算机科学系教授
原文：Open Decision-Making
最后更新：2021 年 6 月 8 日

引子

在创办并领导两家创业公司的过程中，我亲历过形形色色的决策：有些成功，有些惨败。回过头看，那些好与坏的结果背后，其实有一套可以总结的规律。我逐渐形成了一套自己偏爱的决策方法，它处在「集权 — 开放」这条光谱中相当靠近「开放」的那一端：与其依赖少数几个人拍板，不如尽可能去汇聚许多人的集体智慧。

很多管理者对这种做法心存疑虑，担心它低效、担心自己失去掌控。但我的经验恰恰相反：

• 达成共识，往往比你想象的要容易。
• 领导者其实不需要把决策攥得那么紧。
• 尽早把争议摆到台面上，反而能减少后期的冲突。

阅读全文

seq 库的一行代码，从左读到右。写过 lo.Map(lo.Filter(...)) 的人，大概会愣一下。

这个库的开发我昨天晚上在微信上了做了直播，展示我如何使用Loop Engineering 从 0 构建出来。使用的是火山引擎的coding plan, GLM-5.2模型，花了 2 小时，耗费Token 7.23M。你可以查看直播回放：

你也可以访问这个库的项目地址： https://github.com/smallnest/seq， tasks目录中有需求文档和设计文档。

阅读全文