從一條資料到公開頁面：完整投稿演練

這篇教程怎麼用

第一次投稿，可以按本章從頭做一遍；已經會操作，只需用目錄跳到卡住的步驟。這裏以“給現有詞條補充一條有來源的活動信息”為演練。示例不提供虛構的活動日期或公告網址：請在自己的投稿中填入真實資料。舊版指南提出的“選擇路線 → 找到源文件 → 按需查語法 → 預覽差異 → 提交 PR → 跟進檢查與審閲”仍是這篇教程的骨架。網站現在又提供站內投稿，因此每一步都列出兩條路線的對應操作。

先備齊四樣材料

1. 目標頁面。 在百科資料庫搜尋名稱和別名，打開當前語言的詞條；從頁面地址確認這就是要修的實體。不要看到篩選結果為空就直接新建。
2. 原始資料。 保存官方公告或其他可核對頁面的標題、發佈者、網址、發佈日期和與你要寫的事實直接對應的段落。截圖可以輔助辨認，但儘量附原始可訪問鏈接。
3. 要改的一句話。 先寫清“哪一句原文、要改成什麼、為什麼”。若資料只給月份，就寫月份，不補具體日期。把事實與推測分開。
4. 素材權利。 若沒有圖片來源和使用依據，先只改文字。文字許可不自動覆蓋封面、照片、歌詞和視頻；請看來源與授權説明。

第一步：從目標詞條進入

打開目標詞條的閲讀頁，先讀正文和“參考資料”，確認沒有人已經補過同一信息。點擊“完善此詞條”或“編輯源文件”進入編輯器，確認頁面頂部顯示的實體、語言和源文件是你打算修改的對象。若要創建新詞條，先到投稿選擇頁選“百科詞條”，在編輯器中選擇實體類型和原文語言；同一實體的中文、日文、英文源稿使用同一穩定 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 合併和網站發佈是不同節點。最終打開公開詞條，核對修訂已經出現；時間軸修訂還要確認公開事件版本。

另一類投稿怎樣套用

時間軸中的單日事件是一個時間點，持續事件的長度由真實日期跨度決定。只知年或月時保留不確定區間。新增與修訂都可以從站內編輯器起稿；在 GitHub 路線，新事件使用獨立 YAML 文件，修訂只改目標事件。

把 AI 當成校對助手

把你已經收集的資料交給 AI，請它整理結構、檢查缺口；它不能代替來源，不能憑空補日期、人物、授權或翻譯。可複製下面的提示詞，把方括號內容替換為你自己的資料：

我正在給 KAMITSUBAKI Wiki 的 [詞條名稱與語言] 補充 [要改的事實]。請只根據我粘貼的原始資料，列出：①可直接確認的事實及其對應原文；②日期精度（年／月／日，資料沒有的不要猜）；③還需核對的信息；④建議放入詞條哪個段落。請保留原資料標題和網址，不要編造來源，不要替我判斷圖片授權。資料如下：[粘貼來源標題、網址和相關摘錄]

下面是我修改前後的兩段文字及來源。請逐句指出：哪些主張在來源中找不到、哪些引用離事實太遠、是否誤刪原文有效信息、是否把推測寫成事實。不要直接新增事實。修改前：[粘貼] 修改後：[粘貼] 來源：[粘貼]

得到建議後，請逐項回到原始頁面人工核對。歌詞、譯文、圖片署名和時間戳尤其需要自己複查。舊版歌詞 AI 排版提示詞與站內擴展語法示例保留在完整語法指南。

提交前最後檢查

• 搜尋過名稱與別名，確認沒有重複詞條或同一事件。
• 每條新事實有對應的原始來源；日期精度與資料一致。
• 原有正確正文、引用和不熟悉的擴展語法沒有被誤刪。
• 圖片、歌詞及第三方文字的授權邊界已經核對。
• 預覽中的標題、圖片、鏈接和目錄能正常使用。
• 站內收到了投稿回執，或 GitHub 上確實創建了 PR；保存草稿不算投稿。
• 合併之後還會核對公開頁面，未發佈前不寫“已公開”。