扩展氢能站点、加氢记录与台账原型链路,新增工作台、车辆资产 H5、自营物流等原型,并同步导航注册、PRD 资源与交付技能。

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
王冕
2026-07-21 17:15:39 +08:00
parent e39df1c7c8
commit a01d2ab708
242 changed files with 102296 additions and 4866 deletions

View File

@@ -0,0 +1,139 @@
---
name: AutoVUL
description: >-
Generates OneOS PC version update logs from a Yunxiao (云效) iteration name by
loading all linked requirements, or from a pasted changelog list. Use when testers
or PMs say AutoVUL, 版本更新日志, 按迭代生成更新日志, 发版公告, or give a 迭代名称.
---
# AutoVULOneOS PC 版本更新日志)
面向**测试人员发版**:输入云效**迭代名称** → 拉取该迭代关联需求 → 自动生成对外版本更新日志。
也可手动粘贴变更清单(兜底)。**预计维护时长**由人工单独通知,不写进日志。
## 何时使用
- 测试说:`按 $AutoVUL` / `生成版本更新日志` / `按迭代 xxx 出更新日志`
- 输入含云效「迭代名称」
- 发版前需要统一文案口径
## 主流程(测试 · 按迭代,默认)
完整取数步骤见 [references/yunxiao-sprint.md](references/yunxiao-sprint.md)。
```text
1. 确认云效项目缺省统一运营管理平台PC端可改
2. 向用户索取「迭代名称」(若口令里已带则直接用)
3. 在云效查找该迭代 → 立即反馈成功或失败(见下)
4. 成功:列出迭代内关联「需求」清单(编号 + 标题 + 状态)供用户快速核对
5. 从每条需求提取变更素材(优先级见「素材优先级」)
6. 按本文格式分类、合并、润色 → 输出成稿正文
```
### 迭代读取 · 成功 / 失败反馈(强制)
查找迭代后**必须先反馈**,再继续或停止:
| 结果 | 反馈文案(可微调,语义不变) | 下一步 |
|------|------------------------------|--------|
| 精确命中 1 个迭代 | `✅ 已找到迭代「{名称}」(状态:{状态}),关联需求 {N} 条。` | 继续拉需求并生成 |
| 0 个匹配 | `❌ 未找到迭代「{输入}」。请核对后重新输入迭代名称(可复制云效迭代标题)。` | **停止生成**;等待用户重输 |
| 多个模糊匹配 | `⚠️ 找到多个相似迭代1)… 2)… 请回复序号或完整精确名称。` | 等用户选定后再继续 |
| 登录/权限失败 | `❌ 无法访问云效(未登录或无权限)。请在浏览器登录云效后重试,或改用手动清单。` | 停止;提示登录或兜底 |
| 迭代存在但 0 条需求 | `⚠️ 迭代「{名称}」已找到,但暂无关联需求。请确认规划后再试,或改用手动清单。` | 停止生成对外正文 |
**失败后**:用户只需再发一次迭代名称(或纠正项目名),从步骤 2 重跑;不要要求用户重装 Skill。
### 素材优先级(每条需求)
| 顺序 | 来源 | 用法 |
|------|------|------|
| 1 | 需求描述中的「更新内容」段(非「更新内容·历史」) | 首选,直接改写成日志条目 |
| 2 | AutoPRD「功能变更记录」中可对外部分 | 次选 |
| 3 | 需求标题 + 简短描述摘要 | 仅当前两者皆空时;价值句可合理补全 |
| — | 纯技术债、内部监控、未对用户开放 | **不写入**对外日志 |
Bug 类需求(类型/标签含缺陷修复、或更新内容写「修复」归入【Bug修复】其余归【新功能】。边界不清优先 Bug修复。
### 版本号与更新时间
| 字段 | 规则 |
|------|------|
| 版本号 | 优先从迭代名解析(如含 `V1.1.5` / `1.1.5`);解析不到再问用户 |
| 更新时间 | 用户提供则用;未提供可写迭代计划开始日的 `MM月DD日HH:MM`,或先问 |
| 产品线 | 默认 `OneOS PC版` |
## 兜底流程(手动清单)
无云效权限、或迭代为空时:用 [input-template.md](input-template.md) 粘贴清单,跳过迭代步骤,直接分类润色。
## 固定输出格式
```text
OneOS PC版V{主.次.修订}更新日志:
更新时间:{MM}月{DD}日{HH}:{MM}
----------------------------------------------------
【新功能】
1「{模块名}」{做了什么}{责任部门}可{用户价值 / 解决的问题}
2「{模块名}」{…}
【Bug修复】
3「{模块名}」{修复了什么}{责任部门}可{恢复的能力 / 避免的影响}
```
### 版式硬约束
| 项 | 规则 |
|----|------|
| 标题 | `OneOS PC版V` + 版本号 + `更新日志:`(如 `V1.1.5`,无空格) |
| 更新时间 | 仅开始时刻;`MM月DD日HH:MM`**禁止**「预计x分钟内完成」 |
| 分隔线 | `----------------------------------------------------` |
| 分区 | 仅 `【新功能】` / `【Bug修复】`;空类整段省略 |
| 序号 | 全篇连续,从 1 起 |
| 模块名 | `「」`;与产品菜单正式名一致 |
| 对外正文 | **不写**需求号、缺陷号、迭代 ID核对清单可另附 |
| 结尾 | 无签名、无「感谢使用」、无技术附录 |
## 分类 / 合并 / 文案(成稿规则)
| 归入【新功能】 | 归入【Bug修复】 | 不写进对外日志 |
|----------------|-----------------|----------------|
| 新增能力、新入口、新字段/流程、可感知体验优化 | 原有能力异常、报错、数据错、交互失效 | 技术债、无感性能、未开放灰度、仅内部监控 |
- **同分区同模块**合并为一条,分点用 ``
- **跨分区**同模块分栏各写一条
- 每条含:做什么 + 用户价值 + 责任部门自然嵌入(`{部门}人员可…`
- **禁止**「供…条线…使用」;部门对照 [module-role-mapping.md](module-role-mapping.md)
- 禁止编造迭代内不存在的能力;存疑跳过或标待确认(不进正式成稿)
- 单条建议 ≤100 字
排序:先新功能后修复;同分区全员影响优先;资金/合规修复置修复区最前。
## 输出纪律
1. **先**输出迭代读取反馈(✅/❌/⚠️)
2. 成功时:可先给「本迭代需求清单」短表(含编号,便于测试核对)
3. 再输出**纯文本成稿正文**(默认不要 Markdown 大标题包裹成稿)
4. 用户明确要求时,可在正文后附「分类依据 / 跳过项」
## 发布前自检
- [ ] 已反馈迭代查找结果;失败时未强行编造成稿
- [ ] 成稿条目均可追溯到本迭代关联需求素材
- [ ] 标题、时间行、分隔线正确;无预计时长
- [ ] 同模块合并正确;每条含价值 + 部门自然嵌入
- [ ] 对外正文无需求号/缺陷号/技术黑话;序号连续
## 给测试同事的口令
```text
按 $AutoVUL 生成版本更新日志。
项目统一运营管理平台PC端
迭代名称V1.1.5发版迭代
更新时间07月16日16:00
```
迭代名写错时,按提示改完再发一次即可。
手动兜底见 [input-template.md](input-template.md);成稿范例见 [examples.md](examples.md)。