這篇教程怎麼用
第一次投稿，可以按本章從頭做一遍；已經會操作，只需用目錄跳到卡住的步驟。這裡以“給現有詞條補充一條有來源的活動資訊”為演練。示例不提供虛構的活動日期或公告網址：請在自己的投稿中填入真實資料。舊版指南提出的“選擇路線 → 找到原始檔 → 按需查語法 → 預覽差異 → 提交 PR → 跟進檢查與審閱”仍是這篇教程的骨架。網站現在又提供站內投稿，因此每一步都列出兩條路線的對應操作。
先備齊四樣材料
- 目標頁面。 在百科資料庫搜尋名稱和別名，開啟當前語言的詞條；從頁面地址確認這就是要修的實體。不要看到篩選結果為空就直接新建。
- 原始資料。 儲存官方公告或其他可核對頁面的標題、釋出者、網址、釋出日期和與你要寫的事實直接對應的段落。截圖可以輔助辨認，但儘量附原始可訪問連結。
- 要改的一句話。 先寫清“哪一句原文、要改成什麼、為什麼”。若資料只給月份，就寫月份，不補具體日期。把事實與推測分開。
- 素材權利。 若沒有圖片來源和使用依據，先只改文字。文字許可不自動覆蓋封面、照片、歌詞和影片；請看來源與授權說明。
第一步：從目標詞條進入
開啟目標詞條的閱讀頁，先讀正文和“參考資料”，確認沒有人已經補過同一資訊。點選“完善此詞條”或“編輯原始檔”進入編輯器，確認頁面頂部顯示的實體、語言和原始檔是你打算修改的物件。若要建立新詞條，先到投稿選擇頁選“百科詞條”，在編輯器中選擇實體型別和原文語言；同一實體的中文、日文、英文源稿使用同一穩定 ID。臺灣和香港繁體由中文源稿生成。
通過 GitHub 投稿時，從詞條頁的原始檔入口進入倉庫，核對路徑通常位於 src/content/ 下。不要編輯 dist/、.astro/ 或 node_modules/。舊版人物詞條的分節思路仍適用：概述、角色與創作定位、活動歷程、代表作品、相關企劃、參考資料、外部連結。實際欄目要跟隨實體型別與現有正文，修訂時保留已有可靠資訊。
第二步：只改資料支援的內容
站內編輯器會帶入現有內容。先選語言，再在合適段落增補事實；日期、關聯物件、製作署名等結構化屬性應填在對應欄位，不要只藏在正文。原文已有引用或擴充套件語法時，先理解再改。內容結構、分類、文風和來源規則見完整內容格式指南；Markdown、屬性、注音、摺疊內容、媒體短語法與歌詞排版示例見完整語法指南。
例如，資料只證實“某企劃在 2026 年 9 月公佈一項活動”，寫作時可以保留“2026 年 9 月”；不能改寫成 9 月 1 日。活動名稱、成員、地點也只能寫來源實際提到的內容。引用要放在事實附近，參考資料中保留資料標題和原始網址。要表示“尚待查證”，明確寫出待核對點，不用空白或猜測填滿條目。
詞條附件與圖片檔案是不同流程。 詞條正文或封面的附件隨詞條提案進入 GitHub PR；圖片檔案可以直接投稿獨立照片，也可以建立設定組，不必先給每張照片分類。每張圖仍須填寫可核對的作者、出處和使用依據。不要把一套設定圖當作詞條附件上傳。給資料頁選擇區域性主題色時，先從官方主視覺或角色穩定識別色取依據；缺少依據就保留預設樣式，介面主題色不會改變圖片原色。
第三步：用預覽和差異自查
在站內編輯器開啟預覽，對照閱讀頁檢查標題層級、目錄錨點、圖片、連結和引用。再檢視變更差異，確認只改了這次有意修改的段落。儲存本機草稿不等於提交稽核；在草稿仍在時可以繼續查證。若網路斷開，先匯出或複製草稿，再重新整理頁面。
GitHub 路線請在自己的分支或 Fork 中修改目標檔案，檢查 YAML frontmatter 的引號與縮排，確認 id、locale、entityType 等身份欄位沒有意外變化。新增同一實體的多語檔案時要保持 ID 一致。執行倉庫的 pnpm test、pnpm check、pnpm build；在 PR 的 Files changed 中再次看差異。構建失敗應讀實際錯誤行，不要盲改不相關檔案。
第四步：提交與審閱
站內路線點選“提交稽核”後，等到頁面給出記錄編號或 PR 連結，再到創作者中心確認狀態。若只看到“儲存成功”或“檔案已暫存”，投稿尚未進入稽核。提交超時先查是否已有記錄，再決定是否重試，避免重複提案。管理員要求修改時，開啟同一條投稿，對照意見修訂並再次提交。
GitHub 路線則建立 Pull Request，寫清目標詞條、事實來源、修改理由及本地檢查結果。在同一 PR 中回覆審閱意見並推送修訂。GitHub 投稿不一定自動出現在站內創作者中心，進度以該 PR 為準。CI 通過、管理員審閱通過、PR 合併和網站釋出是不同節點。最終開啟公開詞條，核對修訂已經出現；時間軸修訂還要確認公開事件版本。
另一類投稿怎樣套用
| 投稿型別 | 先準備什麼 | 在哪裡檢查結果 |
|---|---|---|
| 文章 | 明確論點、作者、來源和關聯詞條 | 文章預覽、稽核記錄、公開文章頁 |
| 圖片檔案 | 每張圖的作者、出處和使用依據；人物、型別、標籤和設定組可後補 | 私有暫存、逐圖稽核、分類建議、公開圖片 |
| 時間軸 | 日期精度、軌道、關聯詞條、至少一項原始來源 | 事件預覽、PR 稽核、公開事件版本 |
時間軸中的單日事件是一個時間點，持續事件的長度由真實日期跨度決定。只知年或月時保留不確定區間。新增與修訂都可以從站內編輯器起稿；在 GitHub 路線，新事件使用獨立 YAML 檔案，修訂只改目標事件。
把 AI 當成校對助手
把你已經收集的資料交給 AI，請它整理結構、檢查缺口；它不能代替來源，不能憑空補日期、人物、授權或翻譯。可複製下面的提示詞，把方括號內容替換為你自己的資料：
我正在給 KAMITSUBAKI Wiki 的 [詞條名稱與語言] 補充 [要改的事實]。請只根據我貼上的原始資料，列出：①可直接確認的事實及其對應原文；②日期精度（年／月／日，資料沒有的不要猜）；③還需核對的資訊；④建議放入詞條哪個段落。請保留原資料標題和網址，不要編造來源，不要替我判斷圖片授權。資料如下：[貼上來源標題、網址和相關摘錄]
下面是我修改前後的兩段文字及來源。請逐句指出：哪些主張在來源中找不到、哪些引用離事實太遠、是否誤刪原文有效資訊、是否把推測寫成事實。不要直接新增事實。修改前：[貼上] 修改後：[貼上] 來源：[貼上]
得到建議後，請逐項回到原始頁面人工核對。歌詞、譯文、圖片署名和時間戳尤其需要自己複查。舊版歌詞 AI 排版提示詞與站內擴充套件語法示例保留在完整語法指南。
提交前最後檢查
- 搜尋過名稱與別名，確認沒有重複詞條或同一事件。
- 每條新事實有對應的原始來源；日期精度與資料一致。
- 原有正確正文、引用和不熟悉的擴充套件語法沒有被誤刪。
- 圖片、歌詞及第三方文字的授權邊界已經核對。
- 預覽中的標題、圖片、連結和目錄能正常使用。
- 站內收到了投稿回執，或 GitHub 上確實建立了 PR；儲存草稿不算投稿。
- 合併之後還會核對公開頁面，未釋出前不寫“已公開”。