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。
真正要工程化的是專業編輯的判斷：「讀者看不懂你在講什麼」「標題承諾了正文沒回答的東西」「這個梗別刪，換位置」「這個事實要來源」。
把它們變成機械檢查、語意評審、局部修改與複檢，同一個模型也能產出更好的成品。
因為進步的不只是模型，而是模型周圍的編輯系統。
