version-update-log-format

Version update log format (OneOS PC version update log)

Organize the rough change list provided by colleagues into update log body text that can be published externally directly.

When to use

The user requests writing / optimizing / merging a "version update log"
The input contains module names + new feature / fix descriptions
Before a release, the wording needs to be unified

Workflow

Collect meta information: product line, version number, update start time
Collect the change list (may be rough); when user value or applicable department is missing, complete it reasonably per item; if in doubt, skip it and note it
Categorize → merge same modules → polish → output only the final body text
After finalizing, do a self-check (see the checklist at the end)

Estimated maintenance durationnotified separately by personnel,not written intothe version update log.

See the input table template at input-template.md; for a final draft example, see examples.md；Module and responsible department mappingsee module-role-mapping.md(aligned with the responsible department definitions in OneOS "Business Line Description").

Fixed output format

OneOS PC版V{主.次.修订}更新日志：
更新时间：{MM}月{DD}日{HH}:{MM}
----------------------------------------------------
【新功能】
1「{模块名}」{做了什么}，{责任部门}可{用户价值 / 解决的问题}
2「{模块名}」{…}

【Bug修复】
3「{模块名}」{修复了什么}，{责任部门}可{恢复的能力 / 避免的影响}

Hard layout constraints

Item	Rule
Title	`OneOS PC版V` + version number + `更新日志：`(e.g. `V1.1.5`, no spaces)
Update time	Write only the start time; format `MM月DD日HH:MM`；Prohibitedto write "expected to be completed within x minutes"
Separator line	Fixed `----------------------------------------------------`
Sections	Only `【新功能】` / `【Bug修复】`; omit an entire empty category (including its heading)
Numbering	Continuous numbering throughout, starting from 1
Module name	Use `「」`; consistent with the official name in the product menu
Ending	No signature, no "thank you for using", no technical appendix, no requirement number/defect number

Categorization rules

Classify as [New Features]	Classify as [Bug Fixes]	Do not write into the external log
New capabilities, new entry points, new fields/flows, experience optimization that is perceptible to users	Abnormalities in existing capabilities, errors, data errors, interaction failures	Pure technical debt, imperceptible performance fine-tuning, unreleased gray-scale, internal monitoring only
"From nothing to something" "from impossible to possible"	"From broken to good"	Operations/backend only and the product decides not to explain it externally

When the boundary is unclear:Prefer to classify as Bug fixes。

Same-module merge (mandatory)

Within the same sectionMultiple entries for the same module → merge into one; use Chinese semicolon ； to connect the points
Across sectionsSame module (with both new features and fixes) → write one entry in each column, do not mix them
Module names must be strictly identical to be merged ("还车管理", "交还车管理", and "还车应结款" are considered different modules)

Merged sentence pattern:

N「模块名」能力A，{部门}可{价值A}；能力B，{部门}可{价值B}

Copy sentence pattern (mandatory)

Each entry must contain all of the following:

What was done(capability / fix point)
User value(what problem it solves, or what user story it satisfies)
Applicable audience(the responsible department is woven into the sentence; do not write "for ... business line ... to use")

Type	Recommended sentence pattern
New feature	`{部门}人员可…` / `{部门}可…` / `{部门}审批时可…`
Bug fix	`修复…，{部门}可…` / `修复…，避免{部门}…`

How to write the applicable audience (naturally integrated)

MustRefer to module-role-mapping.md in roles; department names must stay consistent
ProhibitedWriting stiff stock phrases such as "for ... business line ... to use" or "for ... personnel to use"
RecommendedWrite the department and the value in the same sentence, e.g.:运维部人员可快速辨认…、业务员、法务部审批时可快速定位…
Multiple departments: enumerate with enumeration commas followed by a unified action, or separate with semicolons and write "department + what it can do" for each
For roles other than "department/group" such as "hydrogen station" or "driver": directly write "Hydrogen stations can..." or "Driver reporting... is clearer"
业务管理组-能源部 Externally it may be abbreviated as "Energy Department personnel" (consistent with the business line description)

Writing constraints

Result-oriented, business language; code names, interface names, table names, and internal jargon are prohibited
Vague words such as "may", "attempt", and "basically" are prohibited
It is prohibited to fabricate modules, capabilities, or applicable departments outside the list; skip doubtful entries
After merging, a single entry is recommended to not exceed 100 characters; if too long, split it into two entries for the same module or delete secondary points
For new features, prefer verbs:支持 / 新增 / 优化 / 升级 / 调整
For fixes, use unified verbs:修复…的问题 or 修复…，避免/确保…
Keep the style consistent throughout; do not use "system/we" as the subject

Ordering

First [New features], then [Bug fixes]
Within the same section: all-staff impact > multiple roles > single role; at the same level, sort stably by module name
Fixes related to funds/compliance/security: place at the very front of [Bug fixes]

When input is insufficient

Missing version number / update time → ask first, then generate
Missing user value but the capability is clear → a reasonable value sentence may be added; if uncertain, write only the capability and mark "value to be confirmed" and do not include it in the formal draft
Missing applicable department → infer based on module ownership; if it cannot be inferred, ask the product team or mark "department to be confirmed" and do not include it in the formal draft
Entries marked "do not write" are prohibited from appearing

Output discipline

By default, output only the log body(plain text), with no preface or closing remarks and no Markdown headings
When the user explicitly requests "explain the classification basis / items to be confirmed", append a brief explanation after the body

Self-check before release

Title, time line, and separator line are correctly formatted
The time line does not contain "estimated to be completed within x minutes"
Only two sections; empty categories have been omitted
The same module has been merged within the same section; cross-section mixing has not occurred
Each entry contains "what was done + user value + responsible department (naturally embedded)"
No stock phrases such as "for ... to use" or "for ... business line"
No technical jargon, no defect numbers, no fabrication
Numbers are sequential

One-sentence usage for colleagues

Send the change list (or input-template.md) to the AI, and explain:

According to $version-update-log-format generate the final draft of the OneOS PC version update log.