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

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

AI 产品做到一定阶段，团队里最容易出现的争论往往不是“模型还够不够强”，而是“这件事到底该放哪一层”。前端觉得后端不该管这么多，工作流觉得前端偷偷做了编排，模型层又被塞进越来越多业务判断。分层一旦乱，后面几乎每个需求都会打架。

有一次标题生成的新 Prompt 只放了 15% 流量，运营同学半小时后就在群里贴了几条结果：标题没报错，但明显比旧版更宽、更空，像是把具体主题又抹回成了通用话术。按直觉做当然也能处理，直接把 Git 里的旧模板找出来改回去就行。可真到操作那一步，问题立刻冒出来了：到底哪些内容已经吃到了新版本？是模板变了，还是变量结构、模型路由或者上下文拼装一起变了？如果这些都说不清，所谓“回滚”其实只是盲切。

我现在越来越少把一整段 AI 逻辑塞进一个“很聪明的 Agent”里。不是因为 Agent 没价值，而是只要功能开始进入多人协作、线上排查和持续演进阶段，把能力拆成可组合服务，几乎总会比单一大黑盒更容易维护。

这两年我越来越觉得，AI 产品里的 BFF 又变得重要了。但它重要，不是因为我们突然怀念传统前后端分层，而是因为很多团队在 AI 功能早期图快，把会话拼装、模型选择、权限裁剪和供应商切换都散落在不同地方，后面一扩展就开始失控。

以前我对博客发布脚本的要求很低，能把 build -> 上传 -> reload 跑通就算不错。等 blogV2 的文章越来越多、迁移批次越来越频繁以后，这条认知很快就被现实打掉了。因为对内容站来说，最贵的成本不是手工上传慢十秒，而是坏内容已经被发到线上以后，才发现链接错了、description 烂了、文章根本还是半成品。

我现在做技术站点的 SEO，已经很少从“关键词密度”开始想了。对这种长期积累型博客来说，真正决定搜索质量的，经常是另外几件更基础的事：description 写得像不像人话，结构化数据有没有最小字段，归档和最近文章入口稳不稳定，文章之间有没有形成明确的主题路径。

很多团队一讨论内容系统，第一句就会问“博客、文档、知识库、教程到底要不要拆成四套”。这个问题当然重要，但我现在越来越少把它放在最前面。因为真正会决定后面是不是越来越乱的，通常不是页面长什么样，而是同一份内容进入系统时，到底有没有一个稳定身份。

我现在看 blogV2 这类站点，已经不太会先问“这一版什么时候正式上线”，而是更在意它能不能稳定地持续发布。因为对内容系统来说，最容易拖垮人的从来不是第一次把站点搭起来，而是后面一篇篇补写、迁移、修订和回归时，发现所有流程都还靠记忆撑着。