update-changelog

name	update-changelog
description	把一次改动按 erArk 的既定体例写进仓库根目录的 update.log（新增/调整/修正三类、括号标签规则、追加位置、文案风格）。当需要"更新更新日志"、"把本次改动写进 update.log"、"补一条 changelog"，或完成一个 plan/功能后要登记版本日志时使用。

Skill Instructions

你是 erArk 的更新日志维护助手。update.log 在仓库根目录，是给玩家看的版本变更记录（不是给开发者看的 commit 历史）。本 skill 归纳了它的体例，照做即可，不要自创格式。

文件属性：UTF-8 无 BOM，换行符全文统一为 CRLF（\r\n）。用 Python 改写时必须 io.open(..., newline='') 读、按 \r\n 拼接、newline='' 写，否则会污染整份文件的行尾。

一、文件结构

更新日志
----------
2026.8.25          ← 发布日期 YYYY.M.D（不补零）
v0.66              ← 版本号
新增：（标签）……    ← 新增段，若干行
新增：（标签）……
                   ← 空行
调整：……           ← 调整段，若干行
调整：……
                   ← 空行
修正：……           ← 修正段，若干行
修正：……
                   ← 空行
2026.7.31          ← 上一个版本块
v0.65
...

• 版本块倒序：最新版本在文件最上方，往下越来越旧。
• 每个块固定三段，顺序恒为 新增 → 调整 → 修正，段与段之间空一行，块与块之间空一行。
• 某一类没有内容时该段整段省略（连同空行）。

二、三种类型的判据

类型	含义	判据
新增	玩家能用到的新东西	新的指令/行为/系统/面板/角色卡/口上/图片/地图/素质。从无到有才算
调整	已有功能的行为、数值、界面被改成了另一种样子，改前也不算错	数值平衡、界面优化、交互流程变化、放宽或收紧限制、文案措辞
修正	改之前是坏的：报错、死循环、数值算错、显示错、逻辑与设计意图不符	只要能说清"原来会出什么问题"，就归修正而不是调整

判不准时的分界线：问自己"改之前那样算不算 BUG"。算 → 修正；不算，只是换了一种做法 → 调整。

历史遗留：v0.64 及更早的块用的是「实装：」，v0.65 起统一改为「新增：」。写新条目一律用「新增」，也不要去改旧块。

三、单条格式

新增：（标签）正文
调整：正文
修正：正文

• 只有「新增」带 （标签），而且必带（近两个版本 81/81 条 100% 带）。
• 「调整」和「修正」一律不带标签（近两个版本 161 条无一例外）。写了就是错的。
• 冒号是中文全角 ：，括号是中文全角 （）。
• 一条一行，行内不换行、不加句号结尾。

标签怎么选

标签是这条改动所属的功能域，2~5 个字。优先复用文件里已出现过的标签，不要造近义的新词（已有「睡觉」就别写「睡眠」）。查已有标签：

./.conda/python.exe -c "
import io,re,sys,collections
sys.stdout.reconfigure(encoding='utf-8',errors='replace')
txt=io.open('update.log',encoding='utf-8').read()
for k,v in collections.Counter(re.findall(r'^新增：（([^）]+)）',txt,re.M)).most_common(): print(k,v)
"

常用标签举例：口上、纸娃娃地文、角色、图片、地图、UI、设置、AI、debug、烹饪、道具、避孕套、怀孕、隐奸、睡奸、睡觉、衣柜、身体管理、性履历、助理、委托、医疗、多语言、Web绘制。

外部 PR 的条目

由 PR 合入的改动，正文沿用 PR 标题，行尾加 (#PR号) - 作者名（半角括号、空格、短横线、空格）：

新增：（衣柜）增加了衣柜中衣物的一键偷取 (#270) - CKecy1209
修正：修复Tk模式下输入失效的问题 (#266) - meower-z

自己做的改动不加署名。

四、文案风格

面向玩家写，讲玩家能观察到的变化，不写函数名、文件名、效果 id、前提名这类实现细节。

类型	常用句式
新增	「新增了……」「增加了……」「在……中新增了……」「将……独立为……」
调整	「……了」结句表示"现在变成这样了"，如「厨师干员不会在食堂中制作酒类食物了」；或「优化了……」「增加了……的……」
修正	「修正了……的BUG」是主句式（约 6 成条目）。原因说得清就带上因果：「修正了A导致B的BUG」；必要时可在 BUG 后追加逗号补一句现在的行为

修正里那些不是程序缺陷的小订正（错字、错误数值、多余配置），可以直接写「修正了……」「去掉了……」而不带 BUG 结尾。

五、粒度与追加位置

• 粒度＝玩家视角的一件事，不是一个 commit。commit message 用的是同一套 类型：（标签）正文 格式，但写日志时要合并同类（四个「XX高潮的AI纸娃娃地文」commit 合成一行）、拆开一 commit 多修（一条 commit 里并列两个「修正：」要拆成两行）。
• 追加到当前版本块内对应类型段的末尾（同段内按时间从上到下累积），不要插在段首，也不要新开版本块——除非确实在发布新版本。
• 顶部的日期行就是本次发布日；若当天已经是该日期就不用动。

六、写完自检

./.conda/python.exe -c "
import io,re,sys
sys.stdout.reconfigure(encoding='utf-8',errors='replace')
raw=open('update.log','rb').read()
assert raw[:3]!=b'\xef\xbb\xbf', 'BOM 混入'
assert raw.count(b'\n')==raw.count(b'\r\n'), '混入了裸 LF'
txt=raw.decode('utf-8')
blk=txt.split('2026.7.31')[0]   # 换成上一个版本块的日期
bad=[]
for l in blk.split('\r\n'):
    if l.startswith('新增：') and not l.startswith('新增：（'): bad.append(('新增缺标签',l))
    if re.match(r'^(调整|修正)：（',l): bad.append(('调整/修正多了标签',l))
    if re.match(r'^实装：',l): bad.append(('应改用新增',l))
    if re.match(r'^(新增|调整|修正):',l): bad.append(('用了半角冒号',l))
print('问题条目:', bad if bad else '无')
"

再肉眼确认：三段顺序对、段间恰好一个空行、新条目在段末、CRLF 未被破坏（git diff update.log 应该只显示你新增的那几行，不应整文件重写）。