Sanbei的博客

Go MCP:用编译器内省取代文本检索

Mon, 01 Jan 0001 00:00:00 +0000

在工程实践中,当给 Agent 分配一个代码重构任务时:

“找出项目中所有实现 DataSink 接口的结构体,为其追加批量刷盘机制;同时重构认证上下文中的 Session.Token 字段。”

标准库优先:先穷尽内置,再引入外部

Mon, 01 Jan 0001 00:00:00 +0000

在 Go 语言服务端工程中,标准库覆盖了网络 I/O、数据序列化、并发同步、加密哈希等绝大多数核心基础设施。

外部依赖不仅带来代码体积膨胀,还会破坏代码基座的平整性。大语言模型在接手多层封装的框架时,需要检索深层调用栈、插件生命周期与隐式上下文,导致有限的会话上下文被框架样板迅速耗尽。反之,现代 Go 持续吸纳了泛型抽象、编译器固有指令、硬件向量化汇编与并发运行时演进,许多曾经作为性能标杆的第三方库,在现代标准库面前已丧失技术优势。

显式、平铺、可推导:Go 为何契合模型推理

Mon, 01 Jan 0001 00:00:00 +0000

在服务端开发中,Go 语言一直以语法简单、编译为单二进制文件以及并发模型直接见长。在日常结合模型进行代码生成的过程中,我发现 Go 的很多语言设计,恰好避开了模型推理时最容易犯错的陷阱。

一份契约,两端编译:OpenAPI + Orval

Mon, 01 Jan 0001 00:00:00 +0000

在前后端协同开发中,接口定义的高频变动通常是效率瓶颈:

业务管理后台中,每个数据实体均涉及标准 CRUD 接口的定义与前端调用层封装;
表单模型调整字段名称或增删属性,前端需同步更新对应的数据模型与请求方法。

在缺乏确定性契约的场景下,依赖人工同步或通过自然语言让模型阅读 Git Diff 修改代码,容易消耗额外上下文,且极易出现类型遗漏或字段漂移。

rtk: 过滤终端噪音,守护推理视界

Mon, 01 Jan 0001 00:00:00 +0000

在工程实践中,当给 Agent 分配一个典型的后端重构任务时:

“检查 internal/payment 模块中所有的退款与流水状态机单测,修复由于通道竞争导致的超时报错,确保所有测试通过并准备提交。”

不猜瓶颈:基于 PProf 的定向性能迭代

Mon, 01 Jan 0001 00:00:00 +0000

在人机协同开发中,许多人习惯把成百上千行的业务代码直接抛给模型,提出类似"帮我看看这段代码性能有没有问题"、“优化系统性能"的请求。

寻找适合工程环境的 Agent 工具链

Mon, 01 Jan 0001 00:00:00 +0000

目前用于辅助编程的智能体工具非常多样,主流的选择包括:

Claude Code
Codex
Opencode
以及 Pi、deepseek harness 这类定制程度极高的本地或开源框架

在实际开发中,不同工具底层接入的大模型能力虽然接近,但在工程交互设计上的取舍,会直接影响日常编码的流畅度与自动化效率。

依赖甄选:单一职责、零传递、接口透明

Mon, 01 Jan 0001 00:00:00 +0000

在人机协同开发中,如果对外部依赖不加克制地引入,项目极易迅速退化为不可控的泥潭。随意引入质量参差不齐、带有复杂隐式黑魔法或深层传递依赖的库,不仅会破坏代码基座的平整性,还会让模型在理解调用栈时陷入上下文混乱。

SQL 即源码:用 sqlc 构建零反射数据访问层

Mon, 01 Jan 0001 00:00:00 +0000

在 Go 语言开发中,ORM 常因运行时反射带来不必要的内存开销与 GC 压力;而手写原生 SQL 若缺乏工具约束,又容易面临参数注入、字段变更缺乏静态感知、手写 Scan 繁琐等问题。

真实测试:别让错误越走越远

Mon, 01 Jan 0001 00:00:00 +0000

在人机协同开发中,最需要警惕的汇报之一是:

“代码已完成,测试已通过。”

审查测试代码时,常会发现明显的工程隐患:

当 Service 依赖数据库时,模型生成了一个返回 nil 的 FakeRepository,使每个调用都直接跳过底层读写;
测试仅断言无错误返回,未验证数据是否真实持久化或事务是否正确回滚;
并发逻辑中硬编码 time.Sleep(100 * time.Millisecond),在本地容易通过,而在持续集成流水线中因调度延迟产生随机 Flaky 报错。

这类测试的风险在于提供虚假的通过信号:模型基于自创的 Mock 验证了自身生成的逻辑,而真实的 SQL 语法、约束与并发竞争从未被运行时检验。

Linter: 规范从软约束变成硬门禁

Mon, 01 Jan 0001 00:00:00 +0000

在日常工程中,当给 Agent 分配一个后端业务任务时:

“在结算模块新增一个同步第三方支付凭证的 HTTP 接口,解析回调参数并更新订单流水。”

日志:构建排错的证据链

Mon, 01 Jan 0001 00:00:00 +0000

在工程演进中,系统上线后通常面临如下场景:

“生产环境接口在夜间偶发 500 错误,随后自动恢复,需要定位根本原因。”

若服务在标准输出中仅打印非结构化文本:

APT 镜像源

Tue, 01 Sep 2026 00:00:00 +0800

为 Ubuntu 配置 APT 镜像源

ubuntu配置文件从旧版的/etc/apt/sources.list

变更为/etc/apt/sources.list.d/ubuntu.sources

Homebrew 安装指南

Tue, 01 Sep 2026 00:00:00 +0800

Homebrew 国内网络环境下安装指南

创建`brew`用户

这是因为brew不支持使用root用户安装,如果没有非 root 用户需要创建一个

Postgres 安装指南

Tue, 01 Sep 2026 00:00:00 +0800

国内网络环境下安装 Postgres 数据库

APT 安装

添加清华源仓库签名

sudo wget -q -O /etc/apt/keyrings/postgresql.asc \
 https://mirrors.tuna.tsinghua.edu.cn/postgresql/repos/apt/ACCC4CF8.asc

添加清华源仓库

sudo bash -c 'echo "Types: deb
URIs: https://mirrors.tuna.tsinghua.edu.cn/postgresql/repos/apt
Suites: $(lsb_release -cs)-pgdg
Components: main
Signed-By: /etc/apt/keyrings/postgresql.asc" > /etc/apt/sources.list.d/postgresql.sources'

更新源并安装

sudo apt update
sudo apt install postgresql-18 # 替换为版本号

启动

sudo systemctl start postgresql

验证

sudo systemctl status postgresql@18-main.service # 替换为版本号

连接

sudo -u postgres psql

动态规划背包问题总结

Tue, 01 Sep 2026 00:00:00 +0800

背包问题总结

一共有2种背包:
- 01背包
- 完全背包
一共有4种求解目标:
- 求最大价值
- 求组合数
- 求排列数
- 给target,求最少/最多的物品数量

其中01背包不考虑排列数,完全背包不考给出target的最多物品数量

制裁流氓软件云枢

Tue, 01 Sep 2026 00:00:00 +0800

制裁流氓软件云枢

禁止云枢安装浏览器监控插件

云枢这个流氓软件会在启动的时候往浏览器里塞一条强制安装浏览器拓展的策略ExtensionInstallForcelist,从而让你删都删不掉他的浏览器拓展

Sanbei的博客

Go MCP:用编译器内省取代文本检索

标准库优先:先穷尽内置,再引入外部

显式、平铺、可推导:Go 为何契合模型推理

一份契约,两端编译:OpenAPI + Orval

rtk: 过滤终端噪音,守护推理视界

不猜瓶颈:基于 PProf 的定向性能迭代

寻找适合工程环境的 Agent 工具链

依赖甄选:单一职责、零传递、接口透明

SQL 即源码:用 sqlc 构建零反射数据访问层

真实测试:别让错误越走越远

Linter: 规范从软约束变成硬门禁

日志:构建排错的证据链

APT 镜像源

为 Ubuntu 配置 APT 镜像源

Homebrew 安装指南

Homebrew 国内网络环境下安装指南

创建brew用户

Postgres 安装指南

国内网络环境下安装 Postgres 数据库

APT 安装

添加清华源仓库签名

添加清华源仓库

更新源并安装

启动

验证

连接

动态规划背包问题总结

背包问题总结

制裁流氓软件云枢

制裁流氓软件云枢

禁止云枢安装浏览器监控插件

创建`brew`用户