寫作風格規範

社群首頁、文件站與新聞導讀由不同的人撰寫，讀者讀到的寫法要前後一致。這一頁是三個網站共用的寫作規範，也是各 repo 說明文件的依據。各站自己的格式與流程另外寫，文件站的見貢獻者百科。

套用範圍

• 社群首頁的頁面與社群動態（anoni-net/www）
• 文件站三個語系的內容（anoni-net/docs 的 docs/）
• 新聞導讀的文章（anoni-net/news），篇幅、結構與第一段的新聞寫法另見該 repo 的 guides/posts.md
• 各 repo 的說明文件：根目錄的 README.md、CONTRIBUTING.md、AGENTS.md、CLAUDE.md、NOTICE，以及各子目錄的 README.md

正體中文與簡體中文照這一頁寫，英文另有一套規則，見英文版。照錄他人說法（引用、受訪內容、外部來源的原始標題）不在此限。

可以機器判斷的規則寫成了 linter，放在 anoni-net/docs 的 tools/docs_style_lint.py，只收 .md 與 .js。檢查其他 repo 的檔案時傳完整路徑，linter 依路徑裡的 zh-TW、zh-CN、en 選擇規則集，傳相對路徑可能套錯語系：

# 在 anoni-net/docs 的根目錄執行
python3 tools/docs_style_lint.py /path/to/www/pages/zh-TW/about.md

規則文件會引用被禁的句型當例子，linter 依檔名豁免這一頁與文件站的貢獻者百科。文件站 CI 的觸發條件與只檢查變更行的旗標，寫在貢獻者百科的「寫作風格規範」一節。

禁用句型與標點

• 不使用 ——（雙破折號）作為句中插入語。需要補充說明時，改用冒號、逗號，或拆成兩句
  • 引用或照錄的內容不在此限：連結文字是外部來源的原始標題時保留原樣（例 [Developer mode — apps...](url)）。英文版（docs/en）的破折號屬正常英文排版，也不適用此規則
• 不使用「不是...而是...」、「不再只是...而是...」句型。改用正向直述。省略「而」、靠逗號銜接的「不是甲，是乙」也算同一個句型
• 避免用「；」斷句，優先用「。」或拆句
• 並列詞語或短語請用「、」，不要用全形「／」當列舉符號（半形 / 用在路徑、URL、技術慣用寫法）
• 中文句子裡的逗號用全形「，」。半形 , 只留給英文、程式碼、URL 與數字，中英混排時最容易誤打
  • 例：在台灣架設 Tor WebTunnel 橋接,把流量偽裝成 HTTPS 改成 在台灣架設 Tor WebTunnel 橋接，把流量偽裝成 HTTPS
• 補充說明或指引看哪裡的短資訊，邏輯上依附前一句時，用括號內嵌，不獨立成句
  • 例：也有 Etherpad 做即時共筆、Matrix 做即時討論。三者分工見社群自架服務。 改成 也有 Etherpad 做即時共筆、Matrix 做即時討論（三者分工見社群自架服務）。
• 不使用「評語 + 冒號 + 具體展開」的鋪墊句型，例如「想做的事情很具體：」、「最重要的是：」、「答案很簡單：」。把評語刪掉，直接寫具體的事。冒號用來帶出列表、引述對話或當簡單標籤（方式：用 Matrix）不在此限
  • 例：社群這半年想做的事情很具體：把架設校園節點的過程整理成文件 改成 社群這半年想把架設校園節點的過程整理成文件
• 指示詞、引號內容、抽象名詞不要疊成一個名詞片語，例如「把那段「A、B、C」的經驗」。先給一個總稱，再用頓號接引號內容
  • 例：把那段「跟學校溝通、走 TANet 行政流程、技術部署、長期維運」的經驗整理成文件 改成 把這段過程、「跟學校溝通、走 TANet 行政流程、技術部署、長期維運」的經驗整理成文件
• 不使用「結論。說明」的句型，也就是先用一句話下判斷、句號收尾，接著才解釋。把判斷併進完整的句子，用逗號接下去。粗體的版本（**一句話。** 內文）由 bold-lead-sentence 規則攔得到，沒有粗體的版本要人工看
  • 例：小工具區的起點是照片的 metadata。線上的清除工具幾乎都需要先上傳檔案 改成 小工具區從照片的 metadata 開始，線上的清除工具幾乎都需要先上傳檔案
• 不用序數接力的修辭，例如「下一所學校」、「第二、第三所學校」、「下一棒」。改用中性的集體說法（之後加入的學校、更多學校一起響應）
• 不使用「讓 X 不再因為 Y 而 Z」、「讓 X 終於可以 Y」、「讓 X 真正成為 Y」這類願景式句型，寫出實際發生的事，標題尤其要避免
  • 例：讓加密協作工具不再因為語言而擋在門外 改成 CryptPad 2026.5.0 內建正體中文語系

標題句構

• 標題用名詞片語，不寫成句子。以動詞為主幹的標題改寫成名詞結構，需要交代第二層資訊時用逗號接續，或把補述留給前言與 summary
  • 這三週文件站多了什麼，以及照著舊版做過準備的人要補的五件事
  • 2026/09 文件站更新回顧
• 標題不使用「主題：說明」的冒號句構
  • Brave 抹平 GPU 指紋：一致化與隨機化在同一次更新裡分工
  • Brave 抹平 GPU 指紋的兩種相反手法
• 標題裡不讓非人的主體做動作，判準與內文的擬人化同一條
  • 設定抽屜把散落的開關收在一起
  • 設定抽屜
• 不用比喻性或散文化的小標題，例如「這條路」、「談談…」、「我們的故事」，改用具體名詞（工作的進展、翻譯歷程）
• 段落內容有讓步與權衡時，標題不用「堅持」這類帶教條暗示的詞，改用中性的名詞片語（X 與 Y 的用字）
• 文章標題與各層小標題同樣適用
• 翻譯文章照錄外部來源的原始標題時保留原樣，例：介紹 oniux：針對任何 Linux 應用程式的核心層級 Tor 隔離技術
• 既有文章不必回頭改寫，新文章與大幅改版時套用

並列引號的標點

連續的「」引號之間要加「、」。錯誤與正確對照：

• 「決策者」「被諮詢者」「需被告知者」
• 「決策者」、「被諮詢者」、「需被告知者」

段落語氣

• 像一位了解主題的社群成員在解釋，而非教科書或百科條目
• 不在每段末尾加總結句，讓段落自然收尾
• 避免「值得注意的是」、「總的來說」、「綜上所述」、「談的是」、「指的是」、「涵蓋的是」這類開頭
• 避免過度對稱的三段結構（常見 AI 寫作模式）。兩段對仗的空句也算，例如「對外面的人來說…。對裡面的人來說…」只有形式、沒有資訊，改成寫出規模、數字、誰受影響
• 能用完整句子說清楚的內容，不拆成條列
• 號召語不用「找人做一做」這類太鬆的說法，改用「邀請…一起參與」、「歡迎…一起加入」

敘事結構

• 前言不堆日期、版本號、PR 編號與 URL。第一段交代這件事為什麼重要，事實放到對應的段落
• 整篇要有一條主張，每個段落都連回它，避免寫成依時間排列的事件報告
• 時間線可以條列日期，前後要有敘述銜接：開頭交代為什麼值得做，結尾交代做完對誰有意義
• 號召型文章在開頭就寫出邀請誰、做什麼、做不到時的替代方案，必要時用 admonition（!!! tip）讓它跳出來

品牌名稱與受眾

• 品牌名稱寫 anoni.net 或 匿名網路社群 anoni.net，一律小寫，英文段落也一樣（anoni.net Docs Project），不寫 Anoni.net。網址與 email 照原樣
• 內容涉及正體中文使用者時，受眾寫「正體中文使用者」，不要只寫「台灣使用者」，後者把香港、澳門等地的讀者排除在外。前言點明一次範圍（例：無論在台灣、香港、澳門或其他華語環境），之後用簡潔的說法帶過
• 寫「華文社群」、「華語使用者」前，先確認是否同時包含正體與簡體中文使用者。只想指特定字系或地區時直接寫出來（正體中文使用者、中港澳的中文使用者）
• 描述在地脈絡時寫「台灣的法規環境」是準確的。寫到「希望讓 X 用得上」這類訴求段時，先確認真正的受眾範圍

擬人化

非人的主體不做人的動作，四種常見情況與改法：

情況
組織說話	Brave 說之後會補上	Brave 的公告寫了之後會補上
文件說話	原文說、報告指出、文章點出風險	原文裡寫、報告的結論是、風險寫在同一篇文章
軟體有感知	網站看到不認識的字串、網站以為取得了真實資訊	網站取得的字串不在既有清單裡、網站收到的值與真實硬體無異
抽象物有意志	開關的存在說明取捨仍在、規則要做對	保留這些開關代表取捨仍在、要讓規則生效

兩種情況不在此限。組織作為行為者，動詞是實際做得出來的動作時保留原樣（Brave 推出防護、Tor Project 發布新版、OONI 蒐集量測）。直接引述照錄時，引號內保留原始說法。

標點集合

正文主要使用：「、」、「，」、「。」、「：」、「！」、「「」」、「（）」。技術術語（Tor、OONI、IP、USB 等）保持英文原文，不加引號，也不加粗體。

版面元件裡的項目分隔可以用半形間隔點（·），例如首頁主按鈕下方那一列次要連結。限定在元件上，句子裡的並列詞語仍然用「、」。

精簡與去 AI 味

校稿時最常做的修法，多數是把 AI 生成痕跡與贅語拿掉：

• 刪掉開場的鋪陳句。例：把 CryptPad 的基本資料先擺出來。它由… 改成 CryptPad 由…，直接進入內容，不先宣告「接下來要講什麼」。對讀者喊話的預告也算，例如「這封信想跟你說」、「以下要告訴你」、「讀完會知道…」。
• 避免「這…」、「這個…」開頭，與「其實」、「換句話說」、「把它換成白話」這類填充轉折，能刪則刪。
• 「這」與「那」不要在同一句裡堆疊。同一個字在同句出現 3 次以上，或兩次中間隔不到 9 個字，就把其中一個換成它實際指的名詞，或整句重寫。例：這件事說明有人在賣這個概念，不等於這套技術已經在運作 改成 有人在賣這個概念，不等於技術已經在運作。兩個字分別計數，這份文件提到那個結論 各出現一次，不算堆疊。全文密度可以拿來抓大方向，站上每千漢字約 5 個是常態，超過 10 個的文章通常整段都要重寫。zhe-repeat 與 na-repeat 規則只掃同句堆疊，全文密度要人工判斷。
• 抽象說法改成具體內容。例：下一段會說明這個結論為什麼不準 改成 下一段的使用量資料會推翻它。
• 「橋樑」、「拼圖」、「最後一哩」這類意象，沒有具體可指的對應物就不用。比喻偶一為之可以，不要整篇靠比喻撐，也不要在同一句裡疊用同一個比喻。例：台灣多一個節點，就是把一個入口放到那張地圖上 改成 台灣每多架一個節點，當地人就多一個還沒被封鎖、能連上 Tor 的入口。

• 不用行銷腔與 AI 常見的套話，改用具體的動詞或描述：

  避免	改用
  賦能、強化能力	寫出實際能做到的事
  打造、構建（用在抽象意義時）	建立、製作、開發
  對接	銜接、對應到、參與、溝通
  痛點、剛需	寫出實際遇到的問題
  大幅提升	寫出提升了多少
  一站式、無縫、零門檻、全方位	刪除，或寫出具體的範圍
  加碼、加持、生態（行銷意義）	刪除，或寫出實際內容
  共創、共榮、共贏、攜手、引領	寫出誰做了什麼

  「生態系」指技術上的一群專案（Tor 生態系）時不在此限。新寫的內容適用，既有文章不必回頭改寫。 - 句子偏短中等。一句話接了四個以上的逗號分句時拆成兩句。 - 去掉誇飾與情緒詞。例：經過真實使用壓力 改成 有實際使用紀錄。一般詞語不必加引號強調，例：是「可被驗證的隱私」 改成 是可被驗證的隱私。 - 段落開頭不要放一句粗體的完整句子。並列的項目升成小標題，單獨一段就寫成正常句子。例：**位置。** OONI 記錄國家與 ASN… 改成 ### 位置，空一行再接內文。升成小標題後語意也更準確，那些多半本來就是子章節，順帶會進側邊目錄。粗體詞作為句子成分或清單標籤不在此限，例：**對照日**用同樣的參數、**資料來源**：…。判準是粗體內容有沒有自成一個以句號結尾的完整句子，bold-lead-sentence 規則掃的就是這個形式。

用詞與譯名

• 口語字改書面語。例：「講」改成「提到」、「說明」，「照實講」改成「不迴避」。常見的還有：

  口語	書面語
  跑（執行軟體）	依語境用執行、架設、運作、營運
  拿到	取得
  得先、得靠	需先、需仰賴
  動手	實際操作、著手、實作
  踩到	遇到
  找上門	依語境用接洽、找上、追究
  省事、省力	簡便、容易
  怎樣	副詞用「如何」，修飾語（怎樣的 X）用「什麼樣的」。「長怎樣」整句改寫，不要寫成「長如何」
  照舊	維持原狀
  差不多	相近
  掛了	無法連線
  搞錯、弄壞	出錯、損壞
  說不過去	前後不一致、於理不合
  灌爆	失真、超出範圍
  玩（在瀏覽器裡）	執行、操作
  做出來、做得出來	完成、開發
  卡住、卡在	受阻
  拿去用、拿來用	取用
  自己（副詞，例：自己挑）	自行
  是不是	是否
  反過來看	相對地
  能用的	可用的

  照錄他人說法不在此限。例：把讀者的感受寫成「連不上」、「跑很慢」時保留原樣，因為那正是要呈現的口吻。

  兩個判斷準則。表示能不能做到的「V 得 + 結果」要改，用「可以」、「能」加動詞（找得到 改成 可以找到、下載得到 改成 可以直接下載）。表示程度的「V 得 + 補語」不必改（解釋得清楚、回答得最準）。另外，書面語不等於官腔，改到像機關公告一樣也是問題。低門檻與概數這類自然的說法保留（當天走進教室就能參與、只聽一兩場），「跟」與「與」都可以用。 - 定義、併排列舉與正式說明裡的疑問詞用「如何」，不用「怎麼」。動詞寫完整詞組，不要為了對仗縮成單字。例：發行端（誰能發、怎麼發） 改成 發行端（誰能發行、如何發行）。FAQ 問句與模擬讀者口吻的段落可以保留「怎麼」。 - 用詞跟著臺灣走。同一個東西兩岸的說法不同時，正體版用臺灣的說法，簡體版用簡體讀者慣用的那個。

  中國慣用	臺灣慣用
  站台	網站。指這個站自己時也可以寫文件站
  網關	閘道。照錄合約或產品名稱裡的「安全網關」不在此限

• 譯名分三種處理：

  • 工具、協定、產品名保持英文原文（Tor、OONI、Tails、CryptPad）。
  • 學術或概念性名詞用中文譯名，首次出現在括號附原文，之後用中文。例：Lorenz 曲線 首次寫成 羅倫茲曲線（Lorenz curve）。
  • 機器欄位或程式內部名稱改用人類可讀說法再附原文，不要把欄位名直接丟給讀者。例：web_connectivity 寫成 網路連線測試（Web Connectivity）。
• 縮寫首次出現附中文說明，之後直接用縮寫，例：ASN（自治系統編號）。面向一般讀者時，專有名詞第一次出現用括號補一句白話，說明它做什麼，例：深度封包檢測（DPI，逐筆分析連線、判斷要不要放行的技術）。

數字與編號

• 清單編號、ID、流水號用 inline code 標記，例：10006、10298，讓讀者一眼分辨那是識別碼而非一般數字。

安全與隱私寫作

匿名與隱私是這個網站的主題，寫作本身也要守住同一條線：

• 不提供可被濫用的操作配方。即使資料與 API 都公開，文章也不手把手教「全量枚舉」、「逐一抓取」這類步驟。改用結果導向的陳述，例：我們以某日為快照盤點全部清單，而非貼出枚舉所有編號的指令。
• 不揭露個別操作者的個人帳號或 handle。引用他人的觀測時用地區或角色代稱，例如把某個真實帳號代稱為 泰國觀測者，只在當事人公開且必要時才具名。
• 涉及受害者、未公開研究、個資的內容，走上傳機敏資訊流程。