這篇文章依照目前的文章品質 v5 標準，整理了 AI 編輯在製作、修改、檢查文章時「看哪裡」「先看什麼」「怎麼兼顧依據與哏」。
文中不含任何可識別個人的資訊。具體的私生活、工作單位、住址、帳號資訊等，都已做過一般化處理。
5 秒結論：寫文章要看 8 層
AI 編輯看的地方，大致分成下面 8 層。
- 這次的需求 —— 要做什麼，不做什麼
- 過往記憶與過往對話 —— 文風、品質規則、以前訂下的例外
- GitHub 上最新的 main —— 目前有效的約定、品質 epoch（標準週期）、編輯規則、QA
- 原文與原始資料 —— 數字、日期、引用、專有名詞、不確定性，這些是「絕對不能弄壞的地基」
- 網路上的第一手、官方、研究資料 —— 時效性、制度、規格、研究、反證
- 文章本身 —— 讀者需求、切入角度、結構、論點與依據、哏、自然度
- 12 種語言版本 —— 在地化的是概念而不是字面，正確的名稱要原樣保留
- 真實網站、真實資料、QA 證據 —— 手機、放大、長文、連結、表格，連出錯時的樣子都要確認
也就是說，不是「讀一遍 Google 的指南然後寫文章」。
只盯著 Google，會被 Google 員工的幽靈附身；只盯著微軟，說明書會開始自己生說明書。文章工廠需要的，是把多個強而有力的資料與這篇文章的目的串起來的編輯判斷。
1. 最先看的是「這次的訂單」
最優先的是這次使用者的指示。
「要完整」「要簡短」「多一點哏」「以研究為基礎」「不要圖片」「12 種語言」「去掉個人資訊」，這些都是只在這一次有效的條件。舊範本再漂亮，訂單要的是拉麵，你卻端出咖哩，那就是出事了。
這裡主要先定下面 5 件事。
- 這篇文章是寫給誰的
- 讀者的疑問是什麼
- 讀完之後，要讓讀者明白什麼、能做到什麼
- 需要查到什麼程度
- 只在這一次適用的禁忌、格式和語氣是什麼
這個階段要先定下文章的「Reader Need（讀者需求）」和「Reader Outcome（讀完後的收穫）」。
2. 接著看過往記憶與過往對話
一篇文章，光靠當下的指示是不夠的，還需要一路累積下來的編輯規則。
例如依目前的標準，有這些規則：
- 對一般成年人讀起來自然，國中生也能跟上意思
- 5 秒看到結論，30 秒掌握概要
- 光看標題就知道是什麼文章
- 只讀 H2（二級標題）也能看出脈絡
- 原則上一段只講一件事
- 結論→理由→具體例子
- 專業術語先講「它到底是什麼」，再講名字
- 哏是用來幫助讀者理解論點的
- 可識別個人的資訊要一般化
- 12 種語言不逐字翻譯
這裡重要的是，不要把過往記憶當成事實的出處。
「以前是這樣訂的」可以用在製作方針上。但如果連價格、法律、規格、研究結果、現行制度都用「以前就是這麼說的」來矇混，文章就變成時光膠囊了。
記憶用來維持編輯方針的連貫，事實則要回到目前的證據上去確認。
3. GitHub 上最新的 main 是「現行說明書」
長期營運中，GitHub 上最新的 main 是文章工廠的正本（唯一權威版本）。
現行的品質體系沒有再多加第 29 條品質軸，而是把專業編輯的眉角，當作子關卡整合到現有的 28 條母軸之下。
AI 會看的代表性正本有下面這些。
- 目前的品質 epoch
- 28 條品質軸
- 讀者體驗與認知無障礙
- 內容品質
- 微軟 / Google 的擴充標準
- 專業編輯工作流程
- 日文編輯規則
- 自然的文風
- 多語言與在地化標準
- 資訊護照與時效
- PASS / SAMPLE_PASS / COMPLETE_100 的定義
- 正式採用、發布、驗證的約定
這裡要緊的是，最新的規則高於舊的成功紀錄。
昨天拿了 100 分的文章，品質規則一改，也只是「昨天的 100 分」，成了歷史。就像按舊規則全勝的選手，不能拿著「我昨天贏了，所以今天也是冠軍」去參加新賽季的比賽。
4. 原文與原始資料是「絕對不能弄壞的地基」
編輯能動的是文章的呈現方式，而不是把事實改成對自己方便的樣子。
特別要保護的有下面這些。
- 數字
- 日期
- 金額
- 單位
- 人數
- 制度名稱
- 產品規格
- URL
- 引用
- 出處
- 專有名詞
- 研究設計
- 不確定性
- 「不知道」這種狀態
為了讀起來順口，把「約 30%」改成「差不多一半」，那就不是更好讀，而是換了一條世界線。
AI 編輯的基本功，是在不改變意思的前提下，調整順序、解釋、例子、標題和措辭。
5. 上網要先看「最硬的依據」
需要時效性或外部事實的文章，就要上網查。但也不是搜尋結果從上到下一個個磕頭。
資訊來源大致依下面的強度來看。
- 標準、法律、第一手資料
- 官方提供者的指南與規格
- 第一手研究、同儕審查的研究
- 專業的編輯與新聞報導準則
- 可靠的二手資料
- 社群、社群媒體、個人經驗談
當然，這會隨文章類型而變。
如果問題是「使用者實際感覺如何」，Reddit 和社群媒體也可能有分量。反過來，如果問題是「WCAG（網頁無障礙標準）的硬性要求是什麼」，卻拿論壇上一句「應該是 24px 吧」來拍板，標準會哭的。
另外，對於分析、比較、研究、推薦和影響大的文章，還要去找能推翻自己結論的資料。
「我找了 5 份支持這個說法的資料！」這不叫研究，叫粉絲團。
6. 28 條品質軸不是「28 位神明」
現行體系保留 28 條母軸。大致分為 17 條讀者體驗軸和 11 條內容品質軸。
讀者體驗的 17 條軸
- 注意力
- 記憶
- 判斷
- 處理速度
- 理解
- 資訊線索（告訴讀者想找的內容在哪裡的提示）
- 視覺雜亂
- 層級
- 版面
- 文字
- 顏色與視覺
- 操作
- 多語言
- 輔助科技
- 動態效果
- 狀態變化
- 對真實資料的耐受
內容品質的 11 條軸
- 讀者、目的、讀完後的收穫
- 獨特價值
- 可信度、作者、製作方式
- 風險、數字、決策
- 表格、圖、圖片的意義
- 步驟、行動、記憶負擔
- 包容性與文化
- 讀者任務能否完成
- 各地區的完成度
- 效能與專注閱讀
- 作為聲音的文字（唸出來是否順耳）
28 條不必每次都像唸經一樣在正文裡全唸一遍。
目的不是「把軸填滿」，而是先想好讀者會在哪裡絆倒，再用和那道障礙相關的軸。
要是文章工廠裡開始有人說「今天向 28 位神明的供奉還差 3 條軸」，那就不是品質管理了，是宗教法人。
7. 看專業編輯的 14 個子關卡
28 條母軸之下，還有 14 個屬於專業編輯流程的子關卡。
- 讀者需求與讀完後的收穫
- 文章的切入角度
- 開頭的鉤子
- 這篇文章在講什麼，為什麼重要
- 把重要資訊放前面
- 每個段落的作用
- 論點與依據的對應
- 反證檢查
- 資訊來源的強度
- 依「結構→事實→文字」的順序編輯
- 在正文裡兌現標題的承諾
- 讓讀者能預測接下來有什麼的導覽
- 寫法與術語的一致
- 發布後的時效與內容負債
不過，並不是把它們機械式地套到每篇文章上。
美食體驗類的文章，沒必要整套披上路透社的新聞結構；API 規格書，也不必以「突然，麵條笑了。」開頭。
**只用適合這類文章的手法。**這才是關鍵。
8. 編輯順序是「結構→事實→文字」
專業編輯裡，順序這件事看似不起眼，其實很管用。
第 1 輪：結構
- 有沒有回答讀者的疑問
- 有沒有切入角度
- 結論是不是太晚
- 只看 H2 能不能走通整個脈絡
- 有沒有重複的章節
- 有沒有多餘的章節
第 2 輪：事實與依據
- 論點有沒有依據
- 依據是不是真的支撐這個論點
- 數字的樣本總量、比較對象需不需要交代
- 有沒有相反的證據
- 是不是過時的資訊
第 3 輪：文字
- 單句是不是塞得太滿
- 專業術語有沒有解釋
- 「這個」「那個」這類指代有沒有迷路
- 哏有沒有發揮作用
- 有沒有變成 AI 味的裝飾性粗體，或連環「※補充」
把這個順序倒過來，就成了給下週要拆的房子把壁紙換得光鮮亮麗的編輯。
9. 數值規則分成 3 種
一出現數字，AI 有時就會突然想自己訂一個「基準值」。這時要踩煞車。
數值一定要分成 3 種。
官方、標準規定的數值
例如：WCAG 中相當於 320 CSS px 的重排（內容隨螢幕寬度重新排列）、200% 文字放大、目標尺寸等。
這些在該標準規定的範圍和例外之內，可以作為 hard gate（必須通過的硬性關卡）。
研究得出的數值
研究對象、語言、條件、樣本不同，就不能原樣當作萬能標準。
不能因為研究裡有「英文 ○ 個單字」，就用計算機煉金煉出「日文 ○ 個字」。
站內的經驗法則
例如「H2 有 4 個以上就檢查一下要不要目錄」。
它們方便用來找出需要複查的候選，但不能讓經驗法則升官當警察。
Google 自己也沒有給過「Google 喜歡的字數」這類萬能數值。該看的不是長度，而是有沒有把目的所需的內容講到位。
10. 12 種語言不是翻譯，而是在地化
支援的語言是：
- 日文
- 英文
- 韓文
- 中文（簡體）
- 中文（繁體）
- 西班牙文
- 葡萄牙文（巴西）
- 印尼文
- 泰文
- 越南文
- 法文
- 德文
多語言化時，詞分成 3 類。
LOCALIZE_CONCEPT
一般概念，換成該語言裡通常能理解的說法。
KEEP_EXACT_NAME
產品名、標準名、API、URL、程式碼、檔案名稱、論文識別碼等，正確的名稱很重要的，原樣保留。
KEEP_EXACT_NAME_WITH_LOCAL_DESCRIPTOR
名稱保留，但光看名稱不知道是什麼的，用該語言加一句簡短的說明。
把日文的語序、換行、諧音梗原樣搬到 12 種語言裡，不叫翻譯。
那是出國旅行時拿著日本插頭硬往插座裡塞。
玩笑也要把意思在地化。傳不過去的哏，就換成另一種自然的笑點。
11. PASS 不是平均分數，而是關卡制
現行的基本做法是 gate-first-score-second（先過關，再打分）。
也就是說，不存在這樣的事：
「事實是錯的，但設計 95 分、文章 96 分，平均超過 90，合格！」
嚴重的 FAIL，不能用平均分數抹掉。
SAMPLE_PASS
在檢查過的樣本中，沒有發現嚴重問題。
PASS
目前對象的範圍被準確定義，所需證據與目前的內容 identity、品質 epoch、規則版本掛上了鉤，必要項目中沒有尚未解決的嚴重 UNKNOWN。
COMPLETE_100
適用的 hard gate、語意審查，乃至所需的外部 / runtime 證據都已成立，並且在目前所有對象上都已閉環。
不會因為沒有人工打分，就判為 FAIL。目前正式的語意審查主體是 source-grounded AI semantic editor（以出處為依據的 AI 語意編輯）。
但如果是 AI 自己寫完，然後說：
「經 AI 老師嚴格審查，AI 老師的文章被判定為完全正確。」
這是不能算證據的。
法官可以是 AI，但證物不能由法官自己用黏土捏出來。
12. 看完正文，再看真實畫面
正文就算是對的，畫面上一旦跑版，也沒辦法讀。
在真實網站上，至少要確認下面這類狀態。
- 320px 級手機
- 390px 級手機
- 橫向手機
- 平板
- 1280px / 1440px 級電腦
- 200% 文字放大
- WCAG Text Spacing（拉大字距、行距後版面仍不跑掉的標準）
- 偽在地化（模擬翻譯後文字變長的測試）造成的文字膨脹
- forced-colors（強制高對比顯示模式）
- reduced-motion（減少動畫的設定）
此外還要用真實資料裡的「地雷」。
- 最長的標題
- 最長的、不能換行的字串
- 最長的正文
- 最短的正文
- 標題最多的文章
- 連結最多的文章
- 表格最多的文章
- 類似定義清單的元素最多的文章
- code / pre 最多的文章
- 混用多種文字系統的文章
只拿普通文章測一測就說「沒問題！」，檢查範圍的差距，堪比在圖書館裡做幾下深蹲就算做完健康檢查。
出錯、0 筆結果、載入失敗、翻譯缺漏等狀態，也是文章體驗的一部分。
13. 研究規則也會自己運轉
品質規則本身也會過時。
所以我們把研究更新嵌進了現有的中央稽核裡。
- 一般 refresh：原則上每 7 天
- deep sweep：原則上每 30 天
- 重大的官方變更：必要時提前
關注的對象包括 W3C/WCAG、ISO 24495、微軟、Google、路透社、美聯社、GOV.UK、認知科學、HCI（人機互動）、閱讀研究、資訊搜尋、無障礙、多語言與編輯研究等。
對於新發現，要依序確認：
是否與現有規則重複 → 資訊來源夠不夠強 → 適用於哪些文章 → 數值的適用範圍是什麼 → 有沒有相反的證據
然後歸入下面幾類：
- ADOPT
- CONDITIONAL
- TEST
- DEFER
- REJECT
- SUPERSEDED
2026 年 8 月 28 日 v5 的首次 deep sweep 中，沒有發現足以推翻現行 PASS 標準的變更，於是決定維持 v5。
14. 官方指南不是神諭
微軟、Google、路透社、美聯社、W3C、ISO，全都是強而有力的資料，但適用範圍各不相同。
例如在技術文件裡，少用慣用語和幽默，有時對可譯性和準確性有幫助。
可是把這條規則一股腦用到美食體驗或娛樂文章上，就會寫出這種東西：
攝取了漢堡排。產生了肉汁。滿意度提升。
把感情遺落在法遵室裡的文字就此誕生。
官方指南要看的是「在什麼情境下才對」。
不是「因為是官方的，所以所有文章都 ADOPT」，必要時是 CONDITIONAL。
15. 就算 GitHub 掛了，也不能讓文章的大腦跟著死
GitHub 抓不到的時候，也不需要把文章製作和語意審查全部叫停。
作為復原用的 baseline（基線），下面這些也在另一套系統裡留一份。
- 28 條母軸
- AI 編輯方針
- 專業編輯工作流程
- 資訊來源的強度
- 數值標準
- 研究更新的做法
- PASS 判定
- 不讓工廠停轉的原則
但在看不到 GitHub 的時候，下面這些不能靠想像來填。
- current SHA（目前的提交 ID）
- 最新的 receipt（處理回條）
- 是否已套用到 repo
- 目前的正式進度
這些就是 UNKNOWN。
GitHub 恢復後，把 latest main + 復原 baseline + 最新的第一手、官方資訊對一遍，再回到正常營運。
「誰最後寫誰說了算」的 blind last-write-wins，不是編輯方針，是剪刀石頭布。
16. 不做的事
這座文章工廠，至少要避開下面這些。
- 只拿 AI 的回答當事實依據
- 沒做過人工審核，卻寫「專家已確認」
- 把官方沒說過的數字叫作「Google 標準」之類
- 只為了搜尋排名，大量生成低價值文章
- 標題唬人，正文卻不回答
- 為了好讀而更動原文的數字或不確定性
- 把所有文章都塞進同一種新聞體、技術文件體
- 把日文的標題、語序、哏機械式地複製到其他語言
- 整篇正文用粗體去「毆打」讀者
- 讓「※補充」像雜草一樣亂長
- 因為一篇文章失敗，就讓不相關的工廠跟著停
- 僅憑抽樣檢查，就宣稱「全站 100 分」
總結：AI 編輯在「寫之前」和「寫之後」更忙
只看寫文章這一步，AI 編輯像個文字產生器。
但實際的工作是：
讀需求 → 讀過往規則 → 讀 GitHub 正本 → 守住原始資料 → 查第一手、官方、研究資料 → 反證 → 搭結構 → 驗證事實 → 打磨文字 → 在地化成 12 種語言 → 在真實畫面上找碴 → 用 QA 收尾 → 連規則本身也定期研究
一直到這裡。
「幫我寫篇文章」只是開始按鈕，不是工作說明。
文章工廠的 AI 編輯，一個人兼著作者、校對、研究員、翻譯編輯、QA 和設備維護在巡檢。
而最重要的，不是寫出遵守規則的文字，而是寫出讓讀者能立刻抓住意思、能順著追到依據、能做出所需判斷的文章。
規則是為此而用的工具。這座文章工廠，不是用來供奉工具箱的。
