AI 写得不够好时，最直觉的办法是换更强的模型。
但还有另一条路：在模型旁边放一个永远不睡觉、而且极其挑剔的编辑部。
它检查标题、标题与正文是否兑现同一个承诺、专业词有没有解释、同一段保留意见是不是说了三遍、12 种语言是否齐全；哪里失败，就只让 AI 重写哪里。
TypeScript 本身不会写文章，但它可以搭出一个**“不过质量门就不准发布”的编辑流水线**。
1. 5 秒结论：不是把文采写进代码，而是把编辑流程写进代码
共享规则当然能改善 AI 写作，但更重要的是把规则变成流程：生成 → 检查 → 语义评审 → 局部修改 → 再检查。
OpenAI 对 eval（结构化质量评估）的说明强调“定义什么叫好 → 测量 → 改进”，并把真实输出里发现的新失败继续加入评估体系。[1]
换成文章生产，就是发现缺陷、找原因、增加检查项，让下一百篇也受益。
2. TypeScript 不是作者，而是生产线
代码擅长确定性的事情：
- H1 是否出现多个
title与og:title是否冲突- 12 个语言版本是否缺失
- 标题是否重复
- 日期、URL 格式是否异常
- 评分不达标时是否退回重做
但“开头有没有吸引力”“这个比喻该不该留”“标题是否真的表达读者的问题”“研究资料是不是把原本有趣的观察淹没了”，需要理解意义。
因此更稳的分工是：TypeScript 做机械检查，AI 编辑做语义判断。
3. 把“专业编辑”拆成角色，才容易落地
结构编辑
看读者的问题、答案出现得够不够早、章节顺序是否自然。
文案编辑
处理标题、导语、重复、用词和节奏。
事实编辑
检查数字、日期、引语、断言强度和来源是否一致。
搜索入口编辑
检查标题前半段是否已经告诉读者“这篇文章讲什么”。
Google Search Central 说明，搜索结果标题是用户快速理解页面内容及其与查询相关性的核心信息之一，并建议标题具体、简洁、可区分，同时避免关键词堆砌。[2]
NN/g 的可用性研究也显示，网页用户经常扫描而不是逐字阅读，链接和标题开头的信息密度非常重要。[4][5]
这不是“把 SEO 咒语塞到最左边”，而是让读者更快判断“这是不是我要的”。
4. Before / After：不要杀掉梗，把梗从入口挪开
修改前
姓氏没错，是词典出事故了——从 Manko、Wang、Chin 看“换一种语言就变危险的名字”
梗很强，但主题来得太晚。
修改后
换一种语言会变尴尬的名字——从 Manko、Wang、Chin 看姓名的跨语言碰撞
正文第一句再写：
姓氏没错。是词典出事故了。
梗没死，反而因为读者已经知道主题，更容易奏效。
Google 的 people-first 内容指南也建议检查标题是否对内容作出有帮助、准确的概括，而不是只为搜索流量制造夸张入口。[3]
5. 好的共享规则不是让文章长得一样，而是防止同一种事故重复发生
如果每篇都强制“三句话”“所有小标题都用问句”“固定两个例子”，文章很快就会变成模板泥浆。
更好的规则定义“不能发生什么”：
- 不让口号压过核心问题
- 不在标题承诺正文没有回答的内容
- 不重复同一个保留意见
- 不把术语直接扔给读者
- 小标题脱离上下文也能理解
- 研究资料负责支撑原始洞察，不抢主角
- 12 种语言不按日语语序硬翻
6. 用 P0 / P1 / P2 分级，避免掉进规则监狱
P0：绝不能失败
事实、数字、日期、引语、标题与正文一致、隐私、语言版本完整、禁止无依据断言。
P1：非常重要
尽早给答案、一段一个核心、先用普通话解释再上术语、标题可独立理解、减少重复。
P2：文章的味道
笑点、比喻、口语感、节奏、强钩子。
为了 P0 没必要把 P2 全杀掉，否则质量控制最后只会生产“政府公告体”。
7. 真正强的是从失败中生长的评估循环
- 生成初稿
- 做机械检查
- AI 编辑阅读含义
- 输出结构化失败原因
- 只修改失败部分
- 再次检查
- 如果是新型且可泛化的失败，就加入长期规则候选
OpenAI 的 eval 思路同样强调把真实失败持续反馈到下一轮评估和改进中。[1]
标题坏了，就别把两千字正文全部重写。全量重生常常会把已经正确的地方也改坏。
8. TypeScript 实现不需要很花哨
const draft = await writeArticle(input);
const hardCheck = runDeterministicChecks(draft);
const editorial = await semanticEditor.review(draft, rubric);
if (!hardCheck.ok || editorial.hasCriticalIssue) {
const revised = await reviseOnlyFailures(draft, { hardCheck, editorial });
return verifyAgain(revised);
}
return draft;
能确定判断的放到代码里，需要读懂意思的交给 AI 编辑，失败原因再转成精准修改指令。
9. 自动化仍然会错：AI 编辑也不是神
它可能把好笑点判成“冗余”，把少数风格判成“不自然”，把文化梗在本地化时磨平，也可能对自己生成的文字过度宽容。
所以语义评分只是检查信号，不是真理。事实要回到一手或官方来源，高风险内容应升级给人类审核，各语言也要按各自语言的自然程度判断。
10. 做到 100 篇、1000 篇后，最值钱的是“改进的复利”
一次发现“口号把核心问题挤到后面”，以后所有文章都能检查。
一次发现“不过、但是”重复到把结论冲淡，也能变成新标准。
一次发现德语虽然语法正确但翻译味很重，就能增加德语专用检查。
失败不再只是一次修稿，而会变成编辑资产。
11. 结论：别堆规则山，搭一个不睡觉的编辑部
目标不是把文采移植进 TypeScript。
真正要工程化的是专业编辑那些判断：“读者看不懂你在讲什么”“标题承诺了正文没回答的东西”“这个梗别删，换个位置”“这个事实需要来源”。
把这些判断变成机械检查、语义评审、局部修改和复检，同一个模型也能产出明显更好的成品。
因为进步的，不只是模型，而是模型周围的编辑系统。
