一介布衣

我后来不太爱用“清理过期文档”这个说法了，因为它太容易让人误会成一次性的删库动作。真正麻烦的，从来不是把几篇旧文删掉，而是判断它们到底该保留、补写、软归档、重定向，还是彻底退出系统。内容写得越久，这个问题越明显，因为旧文不只是旧文件，它们还是外链入口、搜索结果、系列上下文和历史证据。

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

最开始我也以为，把旧博客迁到 Docusaurus 主要是文件格式问题：把文章导进 blog/，补齐 frontmatter，再让站点 build 起来就差不多了。真开始做才发现，Markdown 导入只是最浅的一层。更难的是后面那几件不太显眼、却直接影响站点可信度的事：旧链接能不能继续访问，归档会不会乱，补写过的文章会不会被迁移脚本覆盖，历史内容和新内容能不能进同一套索引。

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

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

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

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

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

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

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