用途
Version update log format（OneOS PC 版本更新日志）用于把同事提供的粗糙变更清单，整理成可直接对外发布的更新日志正文。当用户要求写、优化或合并「版本更新日志」，输入含模块名加新功能或修复描述，或发版前需要统一文案口径时使用。
主要能力
- 收集元信息：产品线、版本号、更新开始时间。
- 收集变更清单（可粗糙）；缺用户价值或适用部门时按条目合理补全，存疑则跳过并注明。
- 按分类、同模块合并、润色，只输出成稿正文。
- 成稿后按自检清单核对。
预计维护时长由人工单独通知，不写进版本更新日志。输入表模板见 input-template.md；成稿范例见 examples.md；模块与责任部门对照见 module-role-mapping.md（对齐 OneOS「业务条线说明」责任部门定义）。
固定输出格式
OneOS PC版V{主.次.修订}更新日志： 更新时间：{MM}月{DD}日{HH}:{MM}
【新功能】 1「{模块名}」{做了什么}，{责任部门}可{用户价值 / 解决的问题} 2「{模块名}」{…}
【Bug修复】 3「{模块名}」{修复了什么}，{责任部门}可{恢复的能力 / 避免的影响}
版式硬约束
- 标题：OneOS PC版V + 版本号 + 更新日志：（如 V1.1.5，无空格）。
- 更新时间：仅写开始时刻；格式 MM月DD日HH:MM；禁止写「预计x分钟内完成」。
- 分隔线：固定 ----------------------------------------------------。
- 分区：仅【新功能】/【Bug修复】；空类整段省略（含标题）。
- 序号：全篇连续编号，从 1 起。
- 模块名：用「」；与产品菜单正式名一致。
- 结尾：无签名、无「感谢使用」、无技术附录、无需求号/缺陷号。
分类规则
归入【新功能】的情况：新增能力、新入口、新字段/流程、体验优化且用户可感知；「从无到有」「从不能到能」。
归入【Bug修复】的情况：原有能力异常、报错、数据错、交互失效；「从坏到好」。
不写进对外日志的情况：纯技术债、无感性能微调、未开放灰度、仅内部监控；仅运维/后端且产品决定不对外说明。
边界不清时：优先归 Bug修复。
同模块合并（强制）
- 同分区内同一模块多条，合并为一条；分点用中文分号 ； 连接。
- 跨分区同一模块（既有新功能又有修复），分栏各写一条，不混写。
- 模块名必须严格相同才合并（「还车管理」「交还车管理」「还车应结款」视为不同模块）。
- 合并后句式：N「模块名」能力A，{部门}可{价值A}；能力B，{部门}可{价值B}。
文案句式（强制）
每条必须同时包含：做了什么（能力/修复点）、用户价值（解决什么问题，或满足什么用户故事）、适用对象（责任部门融入句中，不写「供…条线…使用」）。
- 新功能推荐句式：{部门}人员可… / {部门}可… / {部门}审批时可…。
- Bug修复推荐句式：修复…，{部门}可… / 修复…，避免{部门}…。
适用对象写法（自然融入）：
- 必须对照 module-role-mapping.md 中的 roles，部门名保持一致。
- 禁止写「供…业务条线…使用」「供…人员使用」等生硬套话。
- 推荐把部门与价值写进同一句，如：运维部人员可快速辨认…、业务员、法务部审批时可快速定位…。
- 多部门：用顿号枚举后接统一动作，或分号分点各写「部门 + 可做什么」。
- 「加氢站」「司机」等非「部/组」角色：直接写「加氢站可…」「司机上报…更清晰」。
- 业务管理组-能源部 对外可简写为「能源部人员」（与业务条线说明一致）。
写作约束
- 结果导向、业务语言；禁止代码名、接口名、表名、内部黑话。
- 禁止「可能」「尝试」「基本」等含糊词。
- 禁止编造清单外模块、能力或适用部门；存疑条目跳过。
- 单条合并后建议不超过 100 字；过长则拆成同模块两条或删次要点。
- 新功能动词优先：支持 / 新增 / 优化 / 升级 / 调整。
- 修复动词统一：修复…的问题 或 修复…，避免/确保…。
- 全篇风格统一；不写「系统/我们」作主语。
排序
- 先【新功能】，后【Bug修复】。
- 同分区：全员影响 > 多角色 > 单角色；同级按模块名稳定排序。
- 资金/合规/安全相关修复：排在【Bug修复】最前。
输入不足时
- 缺版本号 / 更新时间：先问再生成。
- 缺用户价值但能力清晰：可补合理价值句；拿不准则只写能力并标「待确认价值」不进正式成稿。
- 缺适用部门：按模块归属推断；无法推断则问产品或标「待确认部门」不进正式成稿。
- 「不必写入」的条目禁止出现。
输出纪律
- 默认只输出日志正文（纯文本），不要前言后语、不要 Markdown 标题。
- 用户明确要求「说明分类依据 / 待确认项」时，正文后再附简短说明。
发布前自检
- 标题、时间行、分隔线格式正确。
- 时间行无「预计x分钟内完成」。
- 仅两类分区；空类已省略。
- 同模块已在同分区合并；跨分区未混写。
- 每条含「做什么 + 用户价值 + 责任部门（自然嵌入）」。
- 无「供…使用」「供…条线」套话。
- 无技术黑话、无缺陷号、无编造。
- 序号连续。
给同事的一句话用法
把变更清单（或 input-template.md）发给 AI，并说明：按 $version-update-log-format 生成 OneOS PC 版本更新日志成稿。