編輯準則

Free2Box 如何做工具，也如何寫內容

Free2Box 不想做成一堆只有介面、沒有內容價值的工具頁。我們做的是能解決明確工作的工具，並且只在內容真的能幫助使用者理解流程、避開錯誤、作出更好判斷時才會發佈。

最後更新：2026 年 3 月 7 日

我們對自己訂下的標準

一頁內容首先要幫人完成工作。如果一段文字或一個功能看起來精緻，但對完成任務沒有幫助，那就不應該留下。

能在瀏覽器本地處理的，就盡量本地處理。若功能必須經過伺服器，我們應該清楚說明，而不是用含糊字眼帶過。

我們優先寫例子、錯誤情境、操作判斷和實際限制。空泛定義、重複模板和為了湊字數而寫的段落，長遠只會變成負債。

工具上線、文章發佈之後，仍然要跟著產品行為、標準更新和使用者回饋持續修正。

我們通常從一個狹窄但重複出現的工作開始，例如合併幾個 PDF、整理 JSON、快速產生強密碼、檢查 schema 片段，或者在上傳前把檔案壓小。如果問題本身說不清，或者唯一理由只是想搶搜尋流量，那通常還不值得上線。

工具發佈前，我們至少會問三件事：它是否解決一個具體工作？在正常瀏覽器環境下是否夠快？我們能否清楚說明何時該用、何時不該用，以及最常見的錯誤是甚麼？

工具頁不應該只有操作介面。頁面本身要能解釋任務、提供真實例子、指出常見錯誤，並幫助使用者選對流程。正因如此，核心工具頁需要有專屬內容，而不只是共用模板。

當工具牽涉格式規格、技術標準或明確做法時，我們盡量把說明建立在原始文件或一手資料上。與其寫一篇很廣但站不住腳的內容，我們更願意寫一篇範圍較窄但可信的頁面。

我們把文章當成產品文件的一部分，而不是圍繞工具堆砌的填充物。好的文章應該反映真實使用情境、合理取捨，以及一個做過這項工作的人會給出的建議。

起草工具可以協助整理結構、處理翻譯或重寫語序，但正式發佈的內容仍然必須經過人工審核和編修。如果文字聽起來空泛、過度自信，或明顯脫離真實使用，我們不會把它當成可發佈內容。

只要一頁內容變得誤導、過時或不完整，就應該修。這包括工具說明、教學文章、metadata，以及私隱或條款頁面。我們寧願回頭修正，也不想讓低質內容慢慢累積。

讀者的意見在這裡很重要。無論是 bug、描述不清、流程卡住，還是內容事實需要更正，對我們來說都是改進產品的重要訊號。

如果你覺得某個工具頁講得不夠清楚、某篇指南已經過時，或者某個流程值得寫得更好，歡迎聯絡我們。這些訊息會直接影響我們下一輪優先修的內容。