83 篇博文 含有标签「AI工程」

最近看 Ornith 1.5 时，一个说法很容易让人兴奋：它能自己生成训练任务，所以 Agent 是不是会在日常使用中“越用越聪明”？

我的答案是：**可以形成越用越贴近真实工作的改进闭环，但它不是聊天时自动学习，更不是不需要数据。**真正发生的事情是，系统把已授权的使用信号转成可验证任务，在隔离环境里训练候选版本，再由独立评测决定是否发布。

这两年桌面应用开发一直在两条路之间摇摆。

一条路是 Electron，生态成熟、前端团队上手快，但大家对它的抱怨也很稳定：包体偏大、内存占用高、冷启动不够利落。另一条路是 Tauri，它把 Chromium 换成系统 WebView，再加上 Rust 后端，明显把体积和资源占用压下来了，但 WebView 本身依然会带来平台差异和能力边界。

现在 Vercel Labs 推出的 Native SDK，想走的是第三条路：不带浏览器，不依赖 WebView，也不靠 JavaScript 运行时，而是直接用自己的原生渲染引擎来画界面。

如果只看第一眼数据，这条路线确实很猛。

• 示例应用体积大约在 3.4 MB 到 5.7 MB
• 常见启动时间在 100 ms 左右，官方展示里温启动约 71 ms 到 131 ms
• 目标覆盖 macOS、Windows、Linux，同时也在尝试 iOS 和 Android

这组数据足够吸引人，但真正值得关心的不是“它是不是更快更小”，而是：它到底解决了什么问题，又会把新的成本转移到哪里。

我现在已经不太相信“多做实验，自然会长出方法论”这件事了。AI 项目里最常见的情况，反而是实验做得很勤，群聊消息也很多，表格也不是没有，可半年后回头看，大家只记得一句很模糊的话：我们当时好像试过这个。

有次上线一个看起来很轻的生成接口，前端只是多加了一个“重新生成”按钮，工作流层为了稳妥又补了自动重试，结果当天晚上数据库里就出现了三份互相打架的结果。产品同学以为模型突然变飘，工程同学第一反应去翻 Prompt，最后真正把问题钉住的，却是一串再普通不过的事实：入口没有幂等键，调用链没有统一 traceId，谁也说不清那三次请求到底是不是同一件事。

如果今天让我重新给这个站排下一年的写作方向，我最先想砍掉的，不是某一个具体技术，而是那种“这个也值得写一下，那个也可以补一篇”的冲动。这个站过去最浪费精力的时候，往往不是没写，而是写得太散。

我现在判断一个 AI 功能值不值得继续投，已经不会先看它演示时有多惊艳了。因为真正烧掉团队时间和预算的，往往不是“它第一次看上去效果不错”，而是上线以后才发现评测起伏大、人工兜底很重、转化不稳，最后整条链都在为一个看起来聪明但不太划算的能力让路。

最尴尬的一次排查，不是没日志，而是四拨人都拿着“自己的那条 id”在说话。前端同学贴了一个 sessionId，BFF 说自己只有 requestId，工作流平台那边只认 runId，到了工具服务层又冒出一个没人见过的 trace。会议开了十几分钟，大家连“我们查的是不是同一次请求”都还没对齐。

如果只看工具清单，2025 到 2026 这段时间变化确实很大。模型在换，供应商在换，RAG 方案在换，Agent 说法也几乎一季一变。可我回头看一圈，真正留下来的并不是那些当时最热的名词，而是几件特别“土”的事情：版本、评测、日志、回放、人工接管。

AI Demo 最迷人的地方，是它总能让人很快看到“这事可行”。屏幕上字在流、结果也能出，十分钟就能把人打动。可真正把一个功能从 Demo 做到长期可用，体验上往往反而会变得没那么惊艳。不是产品退步了，而是你开始被真实用户教育。

很多 Agent 任务拆分失败，表面上看像“模型没理解需求”，但我越来越觉得，真正的原因往往更工程化：你把一整条长任务拆成了几个子任务，却没有告诉每个子任务它到底拿到什么、应该产出什么、失败以后怎么恢复。