by smallnest

jev 兼容

https://github.com/mizorewww/laya-mlx
https://github.com/mizorewww/laya-coreml

要运行 aac6fef/laya-coreml 并提供 Type-Safe（类型安全） 兼容的 API，最有效的方法是结合 Python 的 laya_coreml 库，并利用 Pydantic 或 Python 3.10+ 的 TypedDict / Literal 对输入结构与返回概率进行严格的类型约束。

由于该模型不是生成文本的大模型，而是直接返回“选择题、评分或布尔判断”的概率，我们可以完美地用类型系统将模型输入输出锁死，从而在编译器或 IDE（如 VS Code / PyCharm）中获得完整的类型提示。 [1]

下面是为您编写的完整运行及 Type-Safe API 封装方案：

阅读全文

Go
by smallnest

新AI模型 Jev 实战：概念、场景和两个实战

一、一个不写字的模型

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 语句。

阅读全文

by smallnest

网站被投毒

2026-09-17，我发现 colobu.com 的页面上被加载了一个可疑 iframe：https://soduncdn.com/m.html。域名注册于十天前、没有任何 A 记录、被 6/89 个安全引擎标记。查了一圈之后，结论有点出乎意料。

结论

页面本身没被改。被投毒的是页面引用的那个第三方 CDN 脚本。

出问题的是一行看起来再普通不过的写法：

1
<script src="//cdn.staticfile.org/jquery/1.11.1/jquery.min.js"></script>

cdn.staticfile.org 会在极低概率下返回一个被追加了 383 字节的篡改版 jQuery（96169 字节，官方版本是 95786 字节）。这 383 字节干的事，就是往页面里塞一个隐藏 iframe。

阅读全文

by smallnest

grep 工具大盘点：rg、tgrep、rawgrep、zg

如果你问一个程序员"平时在代码库里怎么找东西"，大概率会得到一个答案：rg。ripgrep 从 2016 年发布到现在，快十年了，又快又稳，68k stars，早就成了事实标准。

但你要是追问一句"仓库已经大到 rg 也要扫好几秒，怎么办"，答案就变得有看头了。过去一两年，grep 世界冒出来好几路新势力，同一个老问题，各自给了一份不同的答卷：

  • tgrep（微软）：预建三元组索引，一次启动、永久秒搜，已经被 Copilot CLI 集成；
  • rawgrep：绕过文件系统，直接读裸盘；
  • zg（阿里 zvec）：把 ripgrep、BM25、向量检索捏进一个入口，专门伺候人和 AI Agent。

加上守擂的 rg，这四把刀恰好是四条完全不同的技术路线。挨个拆开看。

先交代一个背景。AI Coding 时代，"搜索"从开发者的日常工具变成了 Agent 的核心基础设施，Agent 找证据靠它、省 token 也靠它。所以这四把刀里有两把（tgrep、zg）几乎就是冲着 AI 编程助手做的。而且更有意思的是，今天主流的几个 Coding Agent，Claude Code、OpenAI Codex、Pi，默认的代码搜索引擎不约而同都选了 ripgrep。这个细节放到第五节说。

阅读全文

Go
by smallnest

go time.After 优化

这里给你一个典型的循环内复用 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 逻辑是更安全的写法。

  1. 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。

Go
by smallnest

PostgreSQL与MySQL的JSON类型及Go语言处理

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

一、三种类型的本质区别

维度 PostgreSQL json PostgreSQL jsonb MySQL json
存储形式 原始文本（逐字节保存） 分解后的二进制 分解后的二进制
保留空格/键序 保留 不保留 不保留
保留重复键 保留 只留最后一个 只留最后一个
写入速度 快（不解析） 稍慢（要解析） 稍慢（要解析）
查询速度 慢（每次重解析） 快 快
支持索引 否（需表达式索引） GIN 索引 函数索引 / 多值索引
去重/规范化 否 是 是
一句话选型：
  • PostgreSQL 绝大多数场景直接用 jsonb。只有当你需要"原样存回、包括空格和键顺序"这种审计类需求时才用 json。
  • MySQL 只有 json 一种（内部实现类似 jsonb，二进制存储、支持部分更新）。

阅读全文

Go
by smallnest

MySQL 和 PostgreSQL 中的时间戳：Go 和 Java 访问时的坑

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

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

一、先分清两种语义

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

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

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

绝对时刻 墙钟时间
MySQL TIMESTAMP DATETIME
PostgreSQL timestamptz timestamp

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

阅读全文

AI
by smallnest

如果你不能外包你的理解，你咋掌控AI写的那一大坨代码

上一篇文章的结尾，我留了一个话题。

我引用了那句话："你可以外包你的思考，但是你不能外包你的理解。"

有读者在后台问我：道理都懂，可 AI 一天给我生成的代码，比我自己一年写的都多。思考我可以外包给 AI，理解我肯定要自己消化——但是消化也得有时间和精力啊。生成是光速，理解是步行，AI拉的是一大坨，理解缺是要细嚼慢咽，这道题怎么解？

阅读全文

Go
by smallnest

测试最新的几个大模型创建五子棋游戏

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

综合分析

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

阅读全文