問題定位

文章模板的責任是穩定作者流程，正文的責任是承載技術文章本身。讀者進入文章時，需要看到概念、判讀、取捨與路由；作者在寫作時，需要一組欄位檢查文章是否具備可維護的最低結構。

本 blog 同時由人類作者、Claude Code 與 Codex 協作產生內容。模板若只放在單一 agent 的設定裡，就會形成工具分岔；模板若直接放進 backend 正文，又會把作者工作流暴露成讀者負擔。因此模板的單一真實來源放在 content/posts/，作為本 blog 專屬的寫作設定記錄。

放置決策

模板放置位置的核心判斷標準是讀者與維護者是否一致。backend 文章面向技術讀者，report 面向可重用事後檢討，posts 面向 blog 自身的規範、設計與工具鏈紀錄。

位置適合內容本議題判斷
content/backend/技術文章正文、概念推導、案例分析保持讀者主線，作者模板留在上游
content/report/從具體 case 抽出的工程原則可寫抽象原則，操作模板留在 posts
content/posts/blog 規範、設計決策、工具鏈契約作為模板設計的 SSoT
.claude/Claude Code 執行規則可引用本文，本文維持語意來源
.codex/Codex 執行規則可引用本文，本文維持語意來源

這個分工讓模板同時支援 Claude Code 與 Codex，也保留文章對讀者的自然技術敘事。

模板責任

模板是品質閘門，責任是讓文章保留關鍵判斷標準。它要檢查文章是否具備責任、判讀、風險、邊界與下一步路由，正文仍用技術文章的推導順序排列。

模板欄位作者要回答的問題正文呈現方式
責任這篇文章解決哪一類工程問題概念定位或開頭原則段
判讀讀者如何知道自己遇到這個問題判斷標準的條件與後果、表格
風險判讀錯誤或缺漏會造成什麼代價風險段、反模式、情境段
邊界這篇文章處理到哪裡，交給誰接續往相鄰文章的交接、與其他章節分工
回寫案例或事故教訓應回寫到哪個章節下一步路由、復盤段

模板欄位可以出現在文章大綱、作者檢查清單或 agent brief 裡。正文要以技術文章方式展開，讓讀者看到推導，作者填表痕跡留在工作流內部。

Backend 技術文章要交付的內容

Backend 技術文章（04 / 06 / 08 這類語言無關的後端能力文章）常見的內容組成有三項：概念在系統層的定位、判斷標準，以及往相鄰文章的交接。這三項是作者檢查一篇文章有沒有交付完整的清單，不是段標組；每一篇的段標各自用那一篇的對象命名，段落的數量與順序也由那一篇的推導決定。

概念在系統層的定位寫的是這個概念是什麼能力、流程或控制面，在系統裡承擔什麼責任，以及它處在哪個抽象層級。這一項排在案例與設定值之前，因為讀者要先知道這個概念為什麼存在、處理什麼需求，後面的案例才有比較的基準。以 rate limiting 為例，段標寫「Rate limiting 在 API 閘道與服務之間的位置」，比「概念定位」多交代了這一節講的對象；同一個模組裡的每一篇都寫「概念定位」時，讀者從段標分不出任何一篇在講什麼。

判斷標準寫成條件與後果：讀者帶著自己的系統進來，判斷得出自己落在哪一個條件，以及每個條件之下的後果與理由。例如「請求量的尖峰集中在少數租戶時，全域限流會讓其他租戶一起被拒絕，因為所有租戶共用同一個額度」寫出了條件（尖峰集中在少數租戶）、後果（其他租戶被拒絕）與理由（共用額度）。判斷標準有好幾個時，各自寫出它在什麼情境下成立，不寫成先檢查哪一項、再檢查哪一項的順序；讀者需要的是判斷的依據，檢查的順序由他自己的系統決定。真實服務中會看到的徵兆、團隊實際遇到的操作問題、事故或演練暴露的缺口，是判斷標準的材料，寫在它們所佐證的那個條件旁邊。

往相鄰文章的交接寫出這一篇處理到哪裡、哪一部分交給哪一篇，以及那一篇會交付什麼。只列出上游與下游的篇名不夠，讀者要知道點進去會拿到什麼，才判斷得出自己要不要去讀。

三項之外，文章需要完整案例、方案比較或實作步驟時，依那一篇的內容增加段落；每個情境各自用它自己的業務壓力、資料形狀與失敗條件來寫，不為了各篇整齊而套用同一組欄位。

案例前置欄位

案例前置欄位的責任是讓服務案例能回寫到文章系統。它屬於作者拆案例時的內部欄位，正文只吸收欄位背後的判讀與取捨。

欄位用途例子
來源案例來自事故、演練或公開實踐post-incident review、SRE case
觸發事件如何被發現alert、customer ticket、vendor status
Evidence判讀使用哪些證據log、metric、trace、audit log
Decision當時做了什麼取捨rollback、degradation、containment
Impact影響到誰與什麼功能tenant、region、feature、financial impact
回寫教訓回到哪個章節04.17、6.20、8.19

04 / 06 / 08 的案例拆解可共用這組欄位，但正文仍要用技術文章敘事。欄位幫作者維持可比性，文章幫讀者理解機制。

Agent 共用方式

寫作規則以專案的規則檔（repo 根目錄的 AGENTS.md 與它路由到的 docs/rules/ 分冊）為準，本文說明 Backend 文章常見的內容組成。Claude Code 與 Codex 都讀同一組規則檔，.claude/ 與 .codex/ 引用本文時，引用的是這些內容組成背後的理由。

使用者使用方式
人類作者寫作前確認文章是否需要這組欄位
Claude Code依本文判斷正文與作者模板的分工
Codex依本文建立、補寫與檢查 content 文章
mdtools檢查 Markdown 結構與連結，語意模板交給作者流程

這個安排避免 .claude/ 與 .codex/ 各自演化成不同模板，也避免把 agent 操作細節寫進 backend 讀者正文。

使用邊界

模板適合用在多篇系列文章、跨模組路由與案例回寫。單篇短文、事故紀錄或工具使用筆記可以採較輕的結構，只要仍能說清楚核心責任與下一步。

情境使用方式
Backend 能力章節交付系統層定位、判斷標準與交接三項內容
服務案例拆解使用案例前置欄位，正文呈現案例判讀與取捨
Blog 工具鏈規範依主題調整，保留 posts 的規範與工具鏈定位
Report 原則卡依 report 固有結構，維持 case-driven 原則抽象
Skill reference使用 skill 自身 portable 結構，維持跨專案可移植

模板開始主導正文時，需要降級成作者檢查清單。文章完成後的檢查重點是讀者能否理解技術推導，並確認欄位已在文章背後支撐判讀。

完稿檢查

完稿檢查的責任是確認技術文章維持主線。檢查時先看正文是否能獨立閱讀，再看欄位是否完整支撐交接。

  • 首段是否先說概念責任
  • 判讀訊號是否來自真實服務情境
  • 表格項目是否有延伸說明
  • 交接路由是否指向具體章節
  • 案例欄位是否能回寫到 04 / 06 / 08
  • 正文是否保留技術推導，並把欄位轉成讀者可理解的判讀