一起写下神椿
把你知道的，留给下一个喜欢神椿的人。
一个错字、一条来源、一句更准确的翻译，都是值得留下的贡献。从你熟悉的词条开始，先完成一处小修改。
先选一件你想做的小事
挑一个你熟悉的方向，再按六步完成一次真实修改。用时只是参考，随时可以保存草稿、下次继续。
这次从这里开始先确认原句，再只改必要的文字；如果改变了事实，也要补来源。
查看对应步骤 →第一次贡献，跟着这六步走
点开当前步骤，边看边做。完成标准是给自己的检查，不会自动提交内容。
圈定这一处修改
先确定一个小目标和一个可核对的来源。
圈定这一处修改
先确定一个小目标和一个可核对的来源。
载入原文，不用从空白开始
从词条进入，或在编辑器里搜索现有内容。
载入原文，不用从空白开始
从词条进入，或在编辑器里搜索现有内容。
- 在词条页点击 编辑源文件，会先来到这份指南。上方会显示目标路径。
- 点击 打开可视化编辑器。支持的词条会载入原有资料与正文；已有草稿时，先按提示备份再决定是否替换。
- 也可以在编辑器右上角点 编辑旧词条，搜索名称或文件路径，再点 载入原文。
- 核对标题、正文和语言。路径末尾的
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 提供词条链接、具体错误与可核对来源。先搜索是否已有相同反馈。