内容发布系统的产品迭代手记
从标题泄漏到单页控制台，记录一个内容发布系统在与 AI 协作下的快速迭代过程。
Bug 现场：标题里混进了日志
用户发现推送到公众号后台的文章标题变成了：
[3/3] 解析并输出标题完成
这不是标题，这是标题优化脚本的标准输出日志。
说到这个，真有点尴尬——我们当时以为 stdout 只有真正标题，结果它还顺带打印了进度条。
根因分析
V4 一键发布流程里，调用 jianfei-title/scripts/generate_titles.py --auto 后，直接把整个 stdout 当作标题解析来源。
而脚本为了方便调试，在输出真正标题的同时，还会打印阶段进度：
[1/3] 分析文章主题...
[2/3] 生成候选标题...
[3/3] 解析并输出标题完成
策略A: 这是真正的标题
后端用了 stdout.strip()，于是最后一行日志被当成了标题。
这就像你点外卖时，收银员顺口说了一句“好了”，你还真以为那是菜名。
修复：两层防护
第一层——精准提取：不再全取 stdout，只提取匹配 策略:标题 格式的那一行。
这样就能避开那些乱七八糟的中间状态信息。
第二层——兜底清洗：发布前再过滤一次，把 [1/3]、[2/3]、[3/3]、解析并输出标题完成 等已知噪声剔除。
相当于给数据加了个“安检门”，哪怕漏网之鱼也跑不出去。
用测试守护修复
新增了一个回归测试，专门覆盖"stdout 含 [3/3] 解析并输出标题完成"的场景。
测试先失败（确认能抓到问题），再改代码，最后全量测试通过：
Ran 30 tests ... OK
现在每次有人改标题脚本，测试都会第一时间报警，省心多了。
产品体验：用"小白用户"的视角审视控制台
产品迭代不只是修 Bug，还有体验优化。
有一次我们让 AI 扮演“完全不懂技术、没耐心的普通 C 端用户”，来吐槽当前控制台。
用户视角的反馈
第一眼的感觉：
"一打开就感觉信息很多，像进了一个后台控制室。我知道它大概跟'发文章、排期、公众号'有关，但 3 秒内不知道我第一步该点哪里。"
说实话，这话挺扎心的。
我们写功能的时候总想着“功能齐全”，但用户只想知道：“我能干啥？”
最想关掉的 3 个瞬间：
- 顶部一排按钮太多，停住不知道哪个是主按钮
- 中间日历刚变清楚，右边又出现一堆分析卡片，注意力被抢走
- 弹窗和旧 drawer 代码还在，不知道会不会突然弹出东西
这些都不是大问题，但组合起来就是让人想逃。
会在哪里跑掉：
"我会在第一次看到首页时跑掉。因为我还没理解'今天我能干什么'，页面已经让我看到太多管理后台的东西。"
这句话让我们意识到：新手的第一印象，决定了他们是否愿意留下来。
基于吐槽的改进
-
布局压缩：全局 padding、header 下边距、卡片间距全部收紧，减少视觉压迫
不再堆砌空间，而是让每一块都更有存在感。 -
单页不跳转：日期详情、公众号切换、文章预览全部改为局部刷新（HTMX），不离开当前页面
用户不用来回切标签页，效率更高，也不容易迷路。 -
公众号快速切换：在当天内容顶部增加"全部 / 各公众号"切换条，点不同公众号只显示当天该号文章
快速定位目标账号，避免翻半天找不到。 -
打开行为改变："打开"按钮不再弹出新标签页，而是直接在当前页显示手机预览
操作更自然，也减少了误操作的风险。
技术债与产品债
标题泄漏是一个典型的技术债：脚本输出格式变了，但消费端没有同步更新。
控制台体验则是一个产品债：功能越加越多，但没有人从"第一次用的人"角度看过全貌。
两者其实很像——都是“当时觉得没问题，后来才发现麻烦”。
两者的共同解法是：
- 自动化测试守护已知场景，防止回归
- 用户视角的定期审视，避免开发者视角的盲区
- 局部刷新替代整页跳转，降低用户的心智负担
不是所有问题都要靠重构解决，有时候一个小改动就能让体验飞起来。
一点体会
内容发布系统的迭代，不是“功能越多越好”。
当系统同时支持：写文章、排期、多公众号管理、AI 标题推荐、内容缺口分析、文章质量评分、账号对比、微博监控……的时候，
核心问题变成了：
"用户今天来是为了完成一件事，还是为了学习一套系统？"
答案显然是前者。
所以每一次迭代，都应该问自己：
- 这一步能不能更快？
- 这个页面能不能更少？
- 这个操作能不能更直觉？
别让工具变成负担，它应该是帮人做事的伙伴。
关键词：内容发布、公众号运营、产品迭代、用户体验、HTMX、回归测试、标题优化