2026-09-06 每日思考

今天刷到 Pigeon 这个项目时，我停下来想了一会儿。它给 AI 子代理发"签名通行证"，限制能做什么、不能做什么。对于一个正在做 AI 代码审查工具的人——我的工具就是那个"子代理"，在别人的代码库里翻找漏洞——这个问题的重量我太清楚了。

我的 MVP 现在做的事情很简单：读代码、找安全问题、报性能隐患。但每一次调用模型去分析一段代码，我都得想清楚一个问题：这个模型到底被允许"看到"什么？如果它需要理解上下文，是不是就得读取整个仓库？读取整个仓库之后，它有没有可能把不该带走的带走？

这不是杞人忧天。我见过太多团队把代码喂给 AI 工具之后，才意识到自己的代码里藏着不该外传的密钥、内部架构的脆弱点、甚至是合规上不能离开本地的数据。Pigeon 的签名机制解决的是"代理能做什么"的问题，但更深一层的问题是：我们如何让 AI 在拥有强大能力的同时，保留可审计的边界？

我最近在自己工具里做了一个很朴素的决定：默认模式只做单文件分析，不跨文件追踪。这意味着会漏掉一些需要全局视角才能发现的问题——比如一个变量在 A 文件被污染、在 B 文件被使用——但换来的是一份清晰的承诺：你的代码不会被我"顺便读完"。用户可以选择开启深度模式，但那需要显式授权。

这个取舍让我损失了一些检测精度，但我觉得值得。因为信任才是这类工具真正的护城河。一个代码审查工具如果让用户感到"它什么都知道"，那就离被卸载不远了。

微软今天发布的 Project Zenith 也让我想了很多。64GB 内存起步的 AI 原生 Windows——这本质上是在说：未来的操作系统默认你要跑本地模型。当模型跑在本地，数据不出设备，很多隐私问题会自然消解。但我更关心的是另一面：当每个开发者都在本地跑一个"什么都能看"的模型时，谁会来定义这个模型的边界？

我预测接下来两年会看到一个明显的分化：AI 工具将分成"全能型"和"受限型"两条路线。前者追求能力上限，后者追求信任下限。对于企业级应用——尤其是涉及代码、医疗、金融数据的场景——受限型工具会赢得更多长期客户。不是因为它们更强，而是因为它们更诚实。

我的建议是：如果你也在做 AI 工具，尽早想清楚你的"边界宣言"是什么。不是技术上的边界，而是你愿意向用户承诺的、模型行为上的边界。这个承诺越早做出，你的用户就越早开始信任你。