統一內容格式指南

本指南說明本站內容應當怎樣組織和表述。貢獻流程見貢獻指南；Markdown、frontmatter 和媒體短語法見語法屬性指南。

規則的目標不是讓每篇詞條看起來完全相同，而是讓讀者能迅速理解內容、核對來源，也讓後來者能夠安全地繼續編輯。條目型別確有需要時，可以調整章節，但不要為了套模板而建立空章節。

適用範圍與規則強度

本指南適用於詞條導言、正文、章節、frontmatter、資訊卡、參考資料、連結和媒體說明。歌詞原文、直接引語、作品內臺詞、官方名稱、程式碼和資料欄位值應忠實保留，不為迎合正文文風而改寫；其外圍說明仍須遵守本指南。

• “必須”“不得”表示涉及事實準確性、隱私、安全、來源或站點結構的強制要求。
• “應”“優先”表示通常適用的推薦做法；偏離時應有明確的內容或可讀性理由。
• “可”表示按條目需要選擇，不要求所有詞條使用。
• 當本指南與版權、隱私、內容來源、站點 schema 或語法屬性指南衝突時，後者優先；不能確定時，先保留原文並在 Pull Request 中說明。

核心原則

內容必須可核實

日期、作品資訊、成員關係、人物經歷、引語、排名和評價等事實，應能由公開來源直接支援。來源必須確實包含相鄰文字所表達的資訊；不要用一個只談到作品名稱的頁面去支援對作品影響力的判斷。

• 優先採用官方網站、官方公告、作品頁、正式訪談、出版物和具備編輯稽核的新聞報道。
• 單純的發行日期、曲目、演出陣容等基礎事實，可以引用第一方資料。
• 影響、評價、爭議或行業地位等判斷，應優先引用可靠且獨立的二手來源，並清楚標明是誰作出的評價。
• 找不到可靠來源時，先不寫。AI 生成內容、搜尋結果摘要、其他 Wiki 和轉載聚合頁不能替代原始來源。

這與 Wikipedia 的可驗證性和可靠來源原則一致：讀者應能沿著引文回到真正支援該陳述的材料。

保持中立並明確歸屬

正文負責說明事實和重要觀點，不負責替藝人、企劃、粉絲群體或批評者站隊。避免“神曲”“史上最強”“慘遭背叛”“毫無疑問”等宣傳性或裁判式措辭。

當來源中確實存在評價時，把觀點歸屬於作出評價的人或機構：

不推荐：这是一首划时代的神曲。

推荐：音乐媒体 X 在 2025 年的评论中将该曲称为组合风格转变的代表作。[来源](https://example.com/review)

本頁所有 example.com 連結均為格式演示地址，不能作為真實詞條的參考資料。

對於存在分歧的話題，說明有哪些主要觀點、各自來自哪裡，並按可靠來源中的關注程度分配篇幅。不要製造“雙方各佔一半”的假平衡，也不要在正文中與某一觀點辯論。詳見 Wikipedia 的中立觀點指引。

不做原創推斷

來源 A 說某人參加了活動，來源 B 說一首歌曲在同日釋出，並不自動證明兩件事存在因果關係。不要根據服裝、聲線、賬號活動、時間巧合或零散採訪自行推斷身份、關係、動機和未公佈企劃。

可以概括來源已經明確表達的內容，但不得把多個來源拼接成來源本身沒有提出的新結論。參見 Wikipedia 的禁止原創研究。

準確、簡潔、保持一致

優先使用容易理解的短句，一個段落集中討論一個主題。已有詞條內部採用了合理且一致的名稱、日期或標點風格時，應當沿用；只有能明顯改善準確性或可讀性時才統一調整，並在一次範圍清楚的修改中完成。

詞條名稱與專有名詞

詞條標題應當可識別、準確、簡潔，並與同類條目保持一致。以官方當前使用的名稱為首選；官方名稱有特殊大小寫、空格、標點或全半形形式時，不要自行“糾正”。這與 Wikipedia 的條目標題原則一致。

• 人名、藝名、團體名、歌曲名和企劃名在首次出現時，可同時給出官方原文與當前語言的常用寫法。
• 後文選擇一種清晰的簡稱並保持一致，不要在同一段落反覆切換羅馬字、日文和譯名。需要同時標註振假名和羅馬字時，優先使用 ruby 標註振假名，並在括號中附上羅馬字；具體語法見語法屬性指南。
• 只有發生同名衝突時才增加消歧資訊，而且只寫足以區分的部分。
• 不自創縮寫或譯名。非官方譯名確有助於理解時，應標明為暫譯，並優先保留官方原名。
• URL 目錄名、translationKey 和 frontmatter 欄位遵守語法屬性指南，不要因為顯示名稱變化而隨意改動穩定標識。

導言與章節結構

導言先回答三個問題

頁面標題由 frontmatter 生成，因此正文直接以一段簡短導言開始，不再重複一級標題。導言通常應說明：

1. 條目物件是什麼；
2. 它與神椿、相關藝人或企劃的關係；
3. 最重要且有來源支援的辨識資訊是什麼。

導言是正文的摘要，不應放入正文完全沒有說明的新觀點。短條目一段即可；成熟條目通常兩到三段，不要在開頭堆滿詳細年表、完整曲目或所有合作物件。

標題從二級開始

正文主章節使用 ##，子章節使用 ###，不要跳級。標題採用簡短名詞短語，避免“關於她的一些事情”“其他”這類資訊不足的名稱，也不要在標題裡堆連結、加粗和裝飾符號。

## 概述
## 活动历程
### 2024 年
## 代表作品
## 参考资料
## 外部链接

章節按讀者理解順序組織：先說明物件，再展開歷史、作品或關係，最後集中列出來源和外部連結。時間線預設由早到晚；若某個日誌列表明確以最新動態為用途，可以由新到舊，但必須在同一列表中保持一致。

各類詞條的推薦骨架

以下是推薦起點，不是強制填空表。沒有內容的章節應刪除；資料豐富時可以增加有明確名稱的子章節。

藝人與角色

导言

## 概述
## 角色与创作定位
## 基本资料与人物设定
## 活动历程
## 代表作品
## 相关企划
## 参考资料
## 外部链接

真實人物資訊與角色設定必須分開。角色世界觀、官方設定和現實活動不可混寫成同一層面的事實；涉及中之人、私人身份或未公開關係時，遵守本指南的隱私規則。

歌曲

导言

## 作品简介
## 发行与版本
## 创作与演出
## 视听
## 参考资料

歌詞正文、歌詞翻譯、注音與逐字時間軸應使用語法屬性指南規定的結構。創作名單以正式署名為準，不從聽感猜測樂器、取樣或演唱者。

專輯與發行物

导言

## 作品简介
## 发行与版本
## 曲目说明
## 参考资料
## 外部链接

frontmatter 已經儲存的曲目、日期、編號等結構化資料，不必在正文中機械重複。正文應補充版本差異、發行背景或需要解釋的事實。

企劃與事件

导言

## 简介
## 发展历程
## 成员与关联对象
## 作品或活动
## 参考资料
## 外部链接

按公開資訊區分“宣佈”“開始”“舉辦”“發行”“結束”等事件，不要把預告日期寫成實際發生日期。尚未發生的活動或發行應明確標為“預計”“計劃”或“預定”，並在官方資訊改變後更新。涉及劇情或 ARG 時，明確區分作品內敘事、官方宣傳設定和現實事件。

觀測日誌

日誌應以明確日期和單一事件為核心，先寫發生了什麼，再寫其與本站記錄物件的關係。避免把即時猜測、粉絲反應或未經確認的後續計劃寫成事實。後續資訊改變時，更新原有描述並保留必要的時間背景。

Frontmatter 與資訊卡

• frontmatter 是頁面、列表和搜尋索引使用的結構化資料；資訊卡是面向讀者的視覺化摘要。兩者表達的核心事實必須一致，但不要求逐字重複。
• 欄位名稱、型別、日期格式和允許值必須遵守語法屬性指南及內容 schema；不能識別的欄位不要自行新增。
• 資訊卡只放適合快速核對的穩定事實，不放個人評價、宣傳語、粉絲討論或未經確認的推測。
• 名稱、圖片和歸屬優先採用官方資料。確有收錄價值的非官方整理資訊，應先在正文中說明來源與性質；不得把未核實內容僅以“非官方”標籤移入資訊卡。
• 藝人 frontmatter 的 code 欄位沿用本站已經建立的廠牌編號體系：Phenomenon Record 使用 P 加數字，SINSEKAI RECORD 使用 S 加數字，Girls Revolution Project 使用 G 加數字。只記錄能夠從現有條目或維護資料確認的編號，不根據排序自行推算。

文風與段落

• 使用說明性、剋制的陳述句，避免口號、安利文、吐槽、對讀者喊話和過度感嘆。（“請大家一定要去聽”“這首歌真的太棒了”屬於個人評價，不是可核實的事實。）
• 一個段落集中一個主題；主題切換時另起段落。
• 優先寫明確的主語。連續出現多個藝人、作品或組織時，不要只用“其”“他們”造成指代不明。
• 交代事件時使用絕對日期，不用“昨天”“最近”“今年”等會隨時間失效的詞。
• 不用加粗代替章節結構。加粗只用於確有必要的區域性強調，且不要整段加粗。
• 引語只保留理解事實所需的短段，並註明說話者和來源；其餘內容用自己的話準確概括。
• 不為了顯得“完整”而重複 frontmatter、資訊卡或前文已經清楚說明的內容。

日期、時間與數字

frontmatter 日期按語法要求使用 YYYY-MM-DD、YYYY-MM 或 YYYY。正文根據語言自然書寫：

• 中文：2025年3月14日
• 日文：2025年3月14日
• 英文：14 March 2025

只知道月份時不要補寫具體日，只知道年份時不要猜月份。跨時區直播、發售或公告需要精確到時刻時，應寫明時區，例如 20:00（UTC+8） 或 21:00（JST）；必要時再補充目標讀者時區。不要單獨使用可能有多種含義的 CST。數字、單位和百分比在同一詞條中保持同一種格式。

年齡、排名、播放量、成員數量等會變化的資料應附日期或統計範圍：

截至 2026 年 7 月，官方页面列出 12 首收录曲。[来源](https://example.com/official)

列表、表格與時間線

連續段落適合解釋背景和因果，列表適合並列專案，表格適合欄位相同且需要橫向比較的資料。不要為了視覺效果把一兩句話做成表格。

• 同一列表中的專案使用平行語法，例如全部以日期開頭或全部以作品名開頭。
• 表格每列只承載一種含義，表頭應獨立可懂；長篇說明移到表格外。
• 時間線保持統一的日期精度與排序方向。
• 空值使用“未公佈”或當前語言的等價表達；不要用 0 代替未知。
• 移動端難以閱讀的寬表，應拆分為小表或改寫成列表。
• 複雜的時間線或事件表格可以先在正文中概述主要事件，再在附錄或子頁面中提供完整資料。
• 表格過長且會打斷正文時，可以使用語法屬性指南支援的摺疊結構；摺疊標題必須說明內容，關鍵結論不能只存在於摺疊區域。
• 說明文字通常左對齊，短狀態值可以居中，需要按位比較的數字可以右對齊。同一列保持一種對齊方式。

來源與參考資料

來源選擇順序

社交平臺帖子可以支援賬號本人釋出的公告，但通常不能證明關於第三方的爭議性事實。匿名爆料、截去上下文的截圖、未經授權轉載和生成式 AI 輸出不應作為來源。

Wikipedia 可以幫助發現關鍵詞和線索，但它本身不是本站事實的最終來源。引用其中的資訊前，應開啟它列出的原始資料並確認確實支援你的表述。

引文應貼近所支援的內容

每個來源應放在它支援的句子或段落附近。不要在文末堆一組連結，卻不說明每個連結支援哪一項事實。來源標題或連結文字應能識別頁面內容：

推荐：该单曲于 2025 年 3 月 14 日发行。[官方发行页面](https://example.com/release)

不推荐：该单曲于 2025 年 3 月 14 日发行。

## 参考资料

- [点这里](https://example.com/release)

同一來源支援連續數句時，可以在段落末引用一次；若段落中混有多個來源或不同性質的判斷，應分別標註。

在世人物、隱私與爭議

涉及在世人物時，準確性與隱私優先於“資料完整”。沒有可靠公開來源的本名、住址、學校、家屬、健康、財務、私人賬號、身份推測和人際衝突不得寫入，也不要通過多條零散資訊幫助讀者反向識別。

負面或可能損害名譽的內容必須有高質量來源並與條目主題直接相關；僅有傳聞、匿名帖或粉絲討論時應刪除或不寫。即使某項個人資訊真實存在於網路，也不表示它適合收錄。可參考 Wikipedia 的在世人物傳記原則。

多語言內容

本站維護中文 zh.md、日文和英文三種源內容，並由可混寫簡繁的中文源自動派生規範化的簡中、臺灣繁體與香港繁體頁面，共提供五個頁面 locale。中文源不要求預先統一字形；正文和可轉換的 Frontmatter 文案可混用簡體、臺繁或港繁。不同語言應表達相同的核心事實，但可以按語言習慣調整語序、標點和解釋密度，不要求逐句直譯。

• 官方名稱、日期、數字、作品編號和 URL 在各語言間應一致。
• 翻譯時重新檢查來源，不要因為原語言文本存在就預設其事實正確。
• 當前語言沒有公認譯名時，保留官方原名，並在首次出現處作簡短說明。
• 不把機器翻譯當作最終稿；人名、敬稱、主語省略和作品語境尤其需要人工核對。生成式 AI 可以作為翻譯輔助工具，但不是事實或譯文來源；採用其輸出時必須逐句核對、修改，並按專案要求標明 AI 輔助情況。
• 新增或刪除重要事即時，儘量同步三種維護源；簡中、臺灣繁體與香港繁體頁面會隨中文 zh.md 源規範化或重新生成。
• 不直接修改 zh-tw / zh-hk 生成檔案。普通簡繁混寫無需修正；正文中自動轉換無法判斷的少量語境詞使用 {{zh-variant::简中::台繁::港繁}}；跨詞條複用的官方專名誤轉應維護 public/TraditionalChineseConvert.json。
• 臺灣與香港頁面可以採用各自常用詞，但不為了製造地區口語差異而改寫事實或語氣。
• 審閱中文修改時，同時抽查簡中和兩種繁體結果，特別注意後／後、發／發／發、幹／幹／幹、裡／裡、臺／臺、制／制、面／面與復／復／復等高風險字。

連結、圖片與媒體

內部連結使用清楚的條目名稱作為連結文字；不要寫“點選這裡”。外部連結主要放在相關事實後的來源，或詞條末尾獨立的“外部連結”章節。外部連結章節只收錄官方主頁、官方賬號和對讀者有持續價值的頁面，不等同於參考資料。

圖片和媒體必須有合法、明確的使用依據。替代文本說明影像對理解內容有用的資訊，不寫“圖片”或檔名；圖注保持事實性，並標明必要的作者、時間和來源。不要用圖片代替可以搜尋和翻譯的文字，也不要僅為裝飾連續堆放宣傳圖。

嵌入播放器、歌片語件、注音和圖片路徑的具體寫法，以語法屬性指南為準。

修改範圍與協作

一次提交儘量圍繞一個清晰目的，例如“補充發行來源”“統一該詞條中的藝名寫法”或“重組過長的活動歷程”。不要在補一條日期時順便重寫整篇文章。提交說明應清楚描述修改結果和理由，避免只寫“更新”或“修復已知問題”等無法幫助審閱者判斷範圍的概括。

如果現有寫法雖然與你偏好不同，但準確、清楚且內部一致，通常應保留。大範圍改名、改變章節體系或刪除有來源內容前，先在 Pull Request 中解釋原因，便於其他貢獻者核對。

提交說明應描述結果和理由，而不是隻寫“更新”：

content(kaf): 补充 2025 年演出记录及官方来源
docs(format): 统一歌曲条目日期与版本章节

常見問題改寫

宣傳語改為事實陳述

修改前：她凭借无与伦比的歌声迅速爆红。

修改后：她于 2024 年发布首支单曲；截至同年 12 月，该曲进入 X 榜单前十。[发行来源](https://example.com/release) [榜单来源](https://example.com/chart)

如必須使用宣傳語，請在正文中明確標註它的來源和歸屬。

模糊時間改為絕對日期

修改前：最近官方宣布她将参加新的演出。

修改后：官方于 2026 年 7 月 18 日宣布她将参加 9 月 2 日举行的 X 演出。[官方公告](https://example.com/news)

推斷改為來源能夠支援的範圍

修改前：同日发布预告，证明两项企划属于同一世界观。

修改后：两项企划均于 2025 年 6 月 1 日发布预告；截至该日，官方尚未说明二者的关系。[企划 A 公告](https://example.com/a) [企划 B 公告](https://example.com/b)

提交前檢查

• 標題、導言和章節順序是否讓第一次訪問的讀者也能理解？
• 新增事實是否都有能夠直接支援它的公開來源？
• 是否把個人評價、來源觀點和已確認事實明確區分？
• 是否刪除了原創推斷、宣傳語、傳聞和不必要的私人資訊？
• 名稱、大小寫、日期、時區、數字和標點是否在全文一致？
• 列表和表格是否真的比連續文字更清楚，並能在移動端閱讀？
• 內部連結、外部連結、圖片替代文本和媒體來源是否準確？
• 三種維護源與兩種繁體派生中的關鍵名稱、數字和連結是否一致？
• 是否只修改了本次目標相關內容，並在預覽中檢查了差異？
• Markdown 與 frontmatter 是否通過語法屬性指南的檢查？

參考資料

本指南結合本站內容結構，參考並改寫了 Wikipedia 的以下編輯原則；這些連結用於說明本指南的編輯方法，不替代詞條事實所需的原始資料：

• Manual of Style：清晰、簡潔、一致的文章組織與文風。
• Neutral point of view：公平呈現重要觀點並明確歸屬。
• Verifiability：確保讀者能夠核查重要陳述。
• Reliable sources：根據內容性質選擇恰當來源。
• No original research：不把材料組合成來源沒有提出的新結論。
• Article titles：名稱應可識別、準確、簡潔且一致。
• Biographies of living persons：謹慎處理隱私、爭議和可能造成傷害的資訊。