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

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

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

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

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

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

从零搭内部 AI 平台时，最重要的不是一次性把能力做全，而是先收出一个最小可治理的底座。

如果让我给还打算继续做 AI 的团队只留三项投资建议，我不会先选更复杂的 Agent 框架，也不会先选更花哨的工作台。我会先问三个很现实的问题：线上某次异常到底发生了什么，最近一次改动到底是变好了还是变差了，三周前那次事故今天还能不能重放出来。如果这三个问题答不上来，后面所有“持续迭代”都很容易变成盲飞。

内容审核最难看的时刻，通常不是漏了一条规则，而是补丁已经打上去了，现场却没人说得清它到底会影响谁、优先级会不会把旧规则压掉、误杀一旦冒出来要怎么撤。这个阶段如果还把规则更新理解成“改几行配置”，系统就很容易开始靠运气运行。

把单点 AI 功能做成系统能力，关键变化不在模型更强，而在团队开始补模型路由、评测回放和成本视图这些控制面。