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

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

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

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

我现在已经不太把“AI 生成标题”理解成一个文案灵感问题了。对技术博客来说，标题更像一个半结构化字段，它既要服务读者，也要服务站内列表、搜索结果和后续 slug 管理。只要规则没先定好，模型再能写，也很容易稳定地产出一堆“能看但不能发”的标题。

如果技术博客今天还只是一个随手放 Markdown 的目录，它当然很容易被放弃。真正让我还愿意认真维护它的原因，不是“写博客”突然又流行了，而是站点早就不只是写作工具了。一篇文章只要要进首页、归档、标签页、RSS、结构化数据和发布流水线，它就已经不再是孤立文本，而是一个被系统消费的内容对象。

内部 AI 平台一旦开始做大，最容易发生的一件事不是能力不够，而是“什么都想统一”。最开始大家统一的是鉴权、日志、模型路由，听起来都没问题；再往后，连业务模板、流程步骤、审批习惯和租户差异也一起往平台里收，灵活性就会开始明显下降。

组织真正开始提效，通常不是因为又接了一个新模型，而是 Prompt、工具、知识和评测终于共享了一套版本和发布语言。

聊天机器人刚起步时，很多事情都很顺。用户发一句话，模型回一段结果，页面把消息 append 上去，看起来就已经像个产品了。真正开始露出边界，通常是在需求变成这样的时候：帮我整理这批资料，明天继续；如果权限不足就先挂起等审批；调用外部系统失败就自动重试；执行到一半也要能从详情页接着看。到这一步，你会突然发现，消息列表已经不够当系统主结构了。

AI 成本和体验看板里最该删掉的，往往是那些看起来平滑、却掩盖尾部问题的平均指标。