统一内容格式指南

本指南说明本站内容应当怎样组织和表述。贡献流程见贡献指南；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：谨慎处理隐私、争议和可能造成伤害的信息。