一起寫下神椿
把你知道的，留給下一個喜歡神椿的人。
一個錯字、一條來源、一句更準確的翻譯，都是值得留下的貢獻。從你熟悉的詞條開始，先完成一處小修改。
先選一件你想做的小事
挑一個你熟悉的方向，再按六步完成一次真實修改。用時只是參考，隨時可以儲存草稿、下次繼續。
這次從這裡開始先確認原句，再只改必要的文字；如果改變了事實，也要補來源。
檢視對應步驟 →第一次貢獻，跟著這六步走
點開當前步驟，邊看邊做。完成標準是給自己的檢查，不會自動提交內容。
圈定這一處修改
先確定一個小目標和一個可核對的來源。
圈定這一處修改
先確定一個小目標和一個可核對的來源。
載入原文，不用從空白開始
從詞條進入，或在編輯器裡搜尋現有內容。
載入原文，不用從空白開始
從詞條進入，或在編輯器裡搜尋現有內容。
- 在詞條頁點選 編輯原始檔，會先來到這份指南。上方會顯示目標路徑。
- 點選 開啟視覺化編輯器。支援的詞條會載入原有資料與正文；已有草稿時，先按提示備份再決定是否替換。
- 也可以在編輯器右上角點 編輯舊詞條，搜尋名稱或檔案路徑，再點 載入原文。
- 核對標題、正文和語言。路徑末尾的
zh.md、ja.md、en.md分別是簡體中文、日文和英文。
讀原文失敗時： 重試；或到 GitHub 開啟對應檔案的 Raw 原文，使用“匯入原文”貼上完整檔案，也可選擇不超過 1 MB 的 .md 檔案。兩條 --- 之間的資料也要保留。
網站指南、公告和首頁文案不在視覺化編輯器的五類詞條範圍內。編輯這些檔案時，使用上方提供的 GitHub 連結。
編輯器裡的標題、語言和正文都對應目標詞條；沒有用空白稿覆蓋舊檔案。
像寫文章一樣完成修改
常用格式在工具欄，複雜內容按需插入。
像寫文章一樣完成修改
常用格式在工具欄，複雜內容按需插入。
先點選中間的段落，直接改文字。正文從二級標題開始，頁面標題已有獨立位置。
| 想做什麼 | 在哪裡操作 |
|---|---|
| 加粗、斜體、加連結 | 選中文字，使用頂部或浮動工具欄 |
| 高亮、注音、劇透黑幕 | 使用工具欄對應專案；需要解釋或讀音時填寫彈窗 |
| 插入標題、列表、圖片、表格 | 在空段落按 /，或點“插入內容”，搜尋內容型別 |
| 修改圖片說明、表格、歌詞 | 點選對應內容塊，檢視右側“屬性” |
| 調整內容順序 | 使用內容塊的上移、下移；也可拖動塊柄 |
| 找到一段文字 | 使用左側“查詢正文”；大綱可跳到章節 |
| 改標題、日期等資料 | 左側“屬性”中的“詞條資料” |
練習一次加來源： 選中“官方公告”四個字 → 點“新增連結” → 填真實公告地址 → 應用 → 在右側預覽核對文字和連結。
遇到“原樣保留的內容”，說明這一段含複雜語法。先保留它；需要修改時切到“原始碼”，對照語法參考小範圍修改。解析錯誤時先修正 YAML，再切回視覺化；不要為消除提示刪除整段資料。
預覽中只出現預期改動，標題層級和原有複雜內容仍完整。
把事實和來源一起留下
讓下一個讀者能沿著連結查到依據。
把事實和來源一起留下
讓下一個讀者能沿著連結查到依據。
新增發行日期、製作人員、活動經歷等事即時，優先核對官方作品頁、公告、正式採訪或出版資料。連結應直接支援附近那句話，不能只放一個網站首頁。
寫法可以是：“官方作品頁列出了該曲的作詞與作曲資訊。”隨後新增對應作品頁連結。不要把“我很喜歡”改寫成“廣受好評”；來源有評價時，說明是誰作出的評價。
- 名稱和日期以來源為準；不把搜尋摘要、AI 回答或粉絲猜測當成依據。
- 圖片需說明來源並確認可使用；已有授權欄位不要刪。編輯器填寫圖片地址，不會替你上傳圖片檔案。
- 引用、翻譯和歌詞要核對原文，保留已有署名、翻譯者及授權資訊。
- 不確定的內容先不寫，在 PR 中說明缺什麼資料。
AI 可以幫你檢查表達、整理你提供的來源或解釋錯誤，但最終逐項核對的是你。不要讓它猜日期、製作人員、譯文含義或歌詞時間。
每個新增事實都有直接支援它的來源，署名和授權資訊沒有丟失。
預覽、檢查，再匯出
瀏覽器裡的草稿，還沒有提交到網站。
預覽、檢查，再匯出
瀏覽器裡的草稿，還沒有提交到網站。
- 開啟 閱讀預覽，從頭讀一遍；檢查標題、連結、圖片說明、表格和摺疊內容。窄屏可用底部“閱讀預覽”切換檢視。
- 點選底部 匯出前檢查，補齊提示中的必填資料。這能發現欄位問題，不能替你判斷事實是否正確。
- 檢視底部草稿狀態。“草稿已儲存在此瀏覽器”只代表本地儲存，不會同步到其他裝置；重要修改請下載備份。
- 右上 匯出 Markdown → 複製完整 Markdown，或 下載 .md。複製的是完整檔案，包括頂部資料。
- 有有效檔案路徑時，同一選單提供 開啟 GitHub 檔案位置。把完整 Markdown 貼上到該檔案的編輯區，不要只粘正文後誤刪資料。
在 GitHub 的 Preview / Changes 或差異檢視再核對一次。GitHub 不一定能渲染本站的注音、媒體和歌詞短語法，這些效果以站內預覽為參考，最終還需網站構建檢查。
暫停也沒關係： 資訊未齊時可先下載草稿，不必為了消除提示填猜測或佔位資料。
備份已儲存；全文包含原有資料；差異中只有打算提交的修改。
把修改交給維護者
儲存 Commit 後，還要建立 Pull Request。
把修改交給維護者
儲存 Commit 後，還要建立 Pull Request。
第一次用 GitHub？ 到 GitHub 註冊建立個人賬號並驗證郵箱。免費賬號即可完成公開倉庫貢獻；練習編輯不需要提前註冊。登入後回到目標檔案的編輯頁面。
- 沒有倉庫寫入許可權時，GitHub 會引導你建立 Fork（你賬號下的副本）。按頁面提示繼續。
- 貼上修改並核對差異，點 Commit changes… / Propose changes 儲存。說明寫清實際變化，例如“修正詞條中的重複文字”。Commit 只是儲存記錄。
- 繼續進入 Compare & pull request / Create pull request。確認目標倉庫為
LinkTh1rsty/kamitsubaki-wiki-site、目標分支為main，來源是你的修改分支。 - 寫一句清晰標題，用下方模板說明改動、來源和檢查結果，然後建立 PR。出現帶編號的 Pull Request 頁面，才算已交給維護者。
接下來會發生什麼？ Checks 是自動檢查：執行中就稍等，失敗就看具體錯誤；通過後仍需維護者審閱。收到補來源或改格式的意見很正常。回到同一個 Fork 的同一分支修改並再次 Commit，新提交會加入原 PR，不必重複開一個。
合併表示修改已進入主分支，正式網站還要等待部署成功。PR 和提交記錄會留下貢獻歷史，頁面上的貢獻者資訊可能稍後才更新。
介面措辭可能變化，可查 GitHub 網頁編輯說明與 從 Fork 建立 PR。
已開啟帶編號的 PR 頁面，說明裡寫清改動和來源；知道如何檢視後續意見。
先認路，再動手
對應現在的詞條編輯器。桌面可並排寫作與預覽，窄屏按需切換側欄和預覽。
- 左側 · 找到位置
- “詞條”搜尋名稱或路徑；“大綱”跳到章節；“屬性”填寫詞條型別、語言與資料。
- 中間 · 寫正文
- 直接編輯文字。選中文字會出現格式工具；空段落按 /，或點“插入內容”新增內容塊。
- 右側 · 看效果、調內容
- “閱讀預覽”檢查排版；選中內容塊後，在“屬性”裡調整圖片、表格、歌詞等設定。
- 底部與右上 · 檢查、帶走
- 底部檢視草稿儲存狀態與“匯出前檢查”；右上“匯出 Markdown”複製全文或下載 .md。
做完第一處修改，再學你需要的
新建詞條、翻譯和歌詞各有自己的檢查重點，不必一次學完。
新建歌曲、專輯或其他詞條
先檢查是否已有，再準備資料和目錄。
新建歌曲、專輯或其他詞條
先檢查是否已有，再準備資料和目錄。
先在網站與編輯器中搜索名稱和別名。已有詞條就補寫它；確實缺少時，在編輯器“大綱”頂部使用“新建詞條”，再到“屬性”選擇型別和語言。新建會替換當前草稿，先下載需要保留的內容。
藝人、歌曲、專輯、企劃、活動記錄的必填欄位不同，以“匯出前檢查”為準。標題、條目標識和來源先確定，再新增有內容的章節；不要造空章節來湊完整度。
- 歌曲目錄
songs/：src/content/songs/<artistId>/<category>/<songId>/<locale>.md，例如src/content/songs/kaf/originals/new-song/zh.md。 - 專輯目錄
albums/：src/content/albums/<artistId>/<albumId>/<locale>.md，例如src/content/albums/kaf/new-album/zh.md。 - 其他型別沿用同類現有詞條的目錄。不要自行更改已有條目的資料夾名或標識。
以上 new-song、new-album 只是目錄示意。提交前用實際標識替換；先核對歌曲的藝人、曲種、製作資訊，專輯的發行資訊、曲序和曲目關聯。圖片另行上傳到倉庫，頁面填對應地址。
在左側“屬性”展開“GitHub 檔案路徑（可選）”，填寫包含語言檔名的完整路徑。匯出選單會據此開啟 GitHub 的新建檔案位置；填寫路徑本身不會建立檔案。
同一詞條的語言檔案共用 translationKey。新條目應準備 zh.md、ja.md、en.md，暫時無法完成某種語言時，在 PR 明確說明，請維護者協助；不要把未翻譯內容偽裝成完成的版本。更多欄位與歌曲、專輯補寫標準見語法參考。
翻譯與繁體中文
保持同一個詞條，不丟原文、標識和署名。
翻譯與繁體中文
保持同一個詞條，不丟原文、標識和署名。
修改已有翻譯時，載入目標語言原文，再對照來源逐句核對。語言選擇器只設置內容語言，不會自動翻譯正文；不要在舊檔案中只改語言就覆蓋另一個版本。
各版本保留相同的 translationKey，日期、作品編號、人員關係保持一致。姓名和作品名優先採用官方寫法；未確定的譯名在 PR 中說明依據。
繁體中文由簡體中文自動生成，修改原稿 zh.md，不要編輯生成的 zh-tw.md、zh-hk.md。區域性需要臺灣或香港用詞時，可查語法參考的“混合簡繁轉換與生成檔案”，編輯器工具欄“···”也有“繁體用詞覆寫”。
歌詞翻譯應保留對應原文、譯者與授權資訊。先改進確定的一句，不用一次完成整首。
歌詞、注音與學習模式
先把一行對齊，再考慮逐字時間軸。
歌詞、注音與學習模式
先把一行對齊，再考慮逐字時間軸。
在歌曲中插入“雙語歌詞”，在屬性裡填寫原文、假名、羅馬音和譯文。先預覽一行，確認分組對應，再繼續下一行；“文字注音”適合給普通正文中的詞語注音。
要做同步歌詞，先試聽同一版本的音源，填寫該行開始時間（例如 00:03.50）；需要逐字同步時再拆分逐字單元，並逐個核對時間。開始時間應遞增，原文與譯文應對應。沒有準確時間就留空，使用普通歌詞展示，不要按字數平均分配或讓 AI 猜時間。
閱讀器的歌詞學習可切換假名、羅馬音與譯文顯示，逐句練習；這些顯示依賴原文結構正確。合併後還要在正式閱讀器檢查對應關係和播放同步，編輯器預覽不等於完整音源聯調。
複雜歌詞 HTML 會原樣保留。修改前下載原文，按語法參考的“逐字歌詞時間軸”核對結構，保留原譯者和版權說明。
原始碼、媒體和本地開發
需要時再走到這裡。
原始碼、媒體和本地開發
需要時再走到這裡。
“原始碼”顯示完整 Markdown：兩條 --- 之間是 YAML 資料，後面是正文。視覺化無法處理的內容保留為原文塊；不要為了換模式刪除未知欄位或複雜排版。
媒體使用編輯器的“媒體播放”或“多平臺媒體切換”，填寫受支援平臺的真實連結。圖片地址不等於上傳成功；倉庫圖片需另行新增。表格、摺疊內容、程式碼塊和數學公式可從“插入內容”選擇，完整語法按需查參考。
熟悉 Git 的貢獻者可以 Fork、建立分支後本地編輯。按倉庫 README 配置環境，提交前執行 pnpm check、pnpm test、pnpm build，並在實際頁面檢查內容。只用網頁編輯時，不必安裝這些工具；在 PR 中如實說明做過哪些檢查。
修改指南本身請使用 GitHub 原文入口，保留 YAML 結構，並同步適用的語言版本。
隨用隨查
交給維護者前，再看一遍
- 目標詞條、語言和修改範圍正確
- 事實有來源，連結能開啟，署名與授權保留
- 預覽完整，原有欄位和複雜內容沒有誤刪
- 草稿已有備份，GitHub 差異已經看過
- PR 說明寫清實際檢查與尚未解決的問題
一份可以直接填寫的 PR 說明
把方括號中的提示換成這次的實際修改；沒有做的檢查不要寫“已通過”。
卡住了，也可以繼續
沒有 GitHub 賬號，現在能做什麼？
可以先瀏覽指南、用視覺化編輯器修改並下載草稿。準備提交時再註冊和驗證郵箱。也可以先整理詞條連結與錯誤說明，稍後一起反饋。
草稿儲存了，為什麼網站還沒變？
草稿只儲存在這個瀏覽器。還需要匯出、到 GitHub 儲存修改、建立 PR，經審閱合併併成功部署後，正式頁面才會更新。
找不到要改的檔案，或載入失敗？
先檢查語言與路徑，在“編輯舊詞條”搜尋名稱；也可從 GitHub 獲取完整 Raw 原文後匯入。指南、公告、首頁文案請直接在 GitHub 編輯。載入失敗時先備份當前草稿。
檢查變紅了，或維護者讓我修改？
開啟失敗檢查的具體錯誤或評論，處理最先出現的問題。在原 PR 對應的分支修改並再次 Commit。看不懂就回復公開錯誤文字、目標檔案和你做過的操作，請維護者協助。
我只會一點點，會不會添麻煩？
一處範圍清楚、來源明確的小修正很有價值。不確定就說明，不需要裝作全都知道。先完成自己能核實的部分，其餘可以在 PR 裡討論。
下一次，不必從頭再學。
收藏這份指南。下次從詞條進入編輯器，做一個你能核實的改進；遇到問題，在 PR 中說清楚卡在哪一步。你留下的來源和說明，也會幫助後來的人。
還不想編輯？也可以到倉庫 Issues 提供詞條連結、具體錯誤與可核對來源。先搜尋是否已有相同反饋。