418 lines
14 KiB
Markdown
418 lines
14 KiB
Markdown
# 云效日常口语化操作口令
|
||
|
||
## 1. 先说一次项目
|
||
|
||
每次新会话先输入：
|
||
|
||
```text
|
||
项目：统一运营管理平台PC端
|
||
```
|
||
|
||
之后直接说口令即可。项目没有明确、同一编号可能属于多个项目或用户切换项目时，Codex必须先问清项目，不能猜。
|
||
|
||
口令可以自然表达，不要求标点完全一致。例如：
|
||
|
||
- `记录需求：增加车辆批量导出`
|
||
- `帮我记录一个需求，增加车辆批量导出`
|
||
|
||
两句话含义相同。
|
||
|
||
## 2. 产品和需求
|
||
|
||
### 记录需求
|
||
|
||
产品输入：
|
||
|
||
```text
|
||
记录需求：增加车辆批量导出
|
||
```
|
||
|
||
Codex执行：查重后在当前项目创建产品类需求，初始状态为`待处理`，返回需求编号。只有标题也可以先记录；云效必填字段缺失时只追问缺少的字段。
|
||
|
||
**带模块/原型的记录（OneOS）：** 若口令含模块名或原型（如「记录需求：保险采购」），创建前**先调用 `$oneos-autoprd`**，把「需求说明」写入描述；若用户同时定稿，一并写入「更新内容」。
|
||
|
||
**统一运营管理平台 · 快路径（强制）：** 项目为「统一运营管理平台 / PC 端」时，先读 [oneos-pc-fast-path.md](oneos-pc-fast-path.md) 与 [oneos-pc-runtime-ids.json](../assets/oneos-pc-runtime-ids.json)。用已验证 `POST /workitem/workitem` 建单（创建时带 `document`），不要探测 `/workitem/create`。推进至「开发中」时状态连跳：`待处理 → 设计完成 → 待开发 → 开发中`。
|
||
|
||
**优先级 / 推进至 Plan 单选门禁（强制）：** 用户要求 Plan 模式单选，或口令含「优先级」「推进至」需点选时：
|
||
|
||
1. 先用 `AskQuestion`（可用时）或 Plan 确认拿到 A（紧急/高/中/低）与 B（分析中/设计中/设计完成/开发中）。
|
||
2. **禁止**未选时默认「中 + 分析中」并继续建单。
|
||
3. 「批准 / Implement 计划」本身不等于已选 A+B；计划里仍是空选项时必须先问清。
|
||
4. 标签须用户从云效标签 catalog（`oneos-pc-tag-catalog.md`）点选；禁止按业务条线说明/`lines.ts` 自动推断。点选后 API 打标，失败则停并请用户回复标签名，禁止假装成功。
|
||
|
||
**完整可复制提示词（推荐）：** 统一运营管理平台建单优先用 [oneos-pc-record-requirement-prompt.md](oneos-pc-record-requirement-prompt.md)——含 `$yunxiao-requirement-lifecycle` + `$oneos-autoprd`、A/B/C 三门禁与 30 项标签枚举。复制该文件「用户口令」整段发给 Agent；确认后再执行快路径。
|
||
|
||
简短版（填需求名与模块后复制）：
|
||
|
||
```text
|
||
使用 $yunxiao-requirement-lifecycle + $oneos-autoprd
|
||
记录需求到云效 · 统一运营管理平台
|
||
|
||
【需求名】（填写）
|
||
【描述来源】$oneos-autoprd，原型/模块：（填写）
|
||
|
||
请先 Plan 让我点选 A 优先级、B 推进至、C 标签（30 项 catalog，见 oneos-pc-record-requirement-prompt.md；禁止 lines.ts 推断）。
|
||
我确认后再执行快路径建单。
|
||
```
|
||
|
||
确认回复示例：`优先级：高；推进至：设计完成；标签：运维管理条线`
|
||
|
||
### 确认需求
|
||
|
||
产品输入：
|
||
|
||
```text
|
||
确认需求：ONEOSP-123
|
||
```
|
||
|
||
Codex执行：检查范围、负责人、优先级和验收标准，齐全后把需求改为`已确认`。
|
||
|
||
`确认需求`默认不创建分析任务。确认和真实开始分析是两个事件，防止开始时间失真。由分析人员下一步输入`开始分析`。
|
||
|
||
### 需求定稿（原型 + AutoPRD）
|
||
|
||
产品输入：
|
||
|
||
```text
|
||
保险采购需求定稿
|
||
```
|
||
|
||
或：
|
||
|
||
```text
|
||
需求定稿：ONEOSP-123；模块=保险采购
|
||
```
|
||
|
||
Codex执行：
|
||
|
||
1. 调用 `$oneos-autoprd` 定稿流程：更新原型 `.spec/requirements-prd.md` 第 10 章「功能变更记录」与 `autoprd-baseline.json`（只记功能/逻辑，不记样式/UI/表结构）。
|
||
2. 若已有云效需求编号：刷新描述中的「需求说明」与「更新内容」；旧更新内容 →「更新内容·历史」。
|
||
3. 若口令要求进待开发/发对象存储：继续走下方「快速进入开发」或 OneOS 快轨口令，不得跳过 AutoPRD。
|
||
|
||
### 快速进入开发
|
||
|
||
产品输入：
|
||
|
||
```text
|
||
快速开发：ONEOSP-123；原因=小改动；负责人=张三；范围=只改后端
|
||
```
|
||
|
||
Codex执行：检查项目是否允许快轨、验收标准是否明确，再跳过不需要的分析/设计阶段并建立必要开发任务。条件不齐时不跳状态，只提示缺少什么。
|
||
|
||
**OneOS 模块已定型进待开发（推荐）：**
|
||
|
||
```text
|
||
「保险采购」需求已经确定：先 AutoPRD 写需求说明与更新内容；发布对象存储并写入描述；
|
||
推进到待开发；自动建与需求同名的【交付】任务并正式关联；负责人何斐。
|
||
```
|
||
|
||
执行前必须先跑 `$oneos-autoprd`（含定稿变更记录若用户刚定稿）。进入待开发时**必须**执行 [auto-stage-task.md](auto-stage-task.md)（同名任务、标签交付、负责人何斐、时间沿用需求）；已有唯一交付任务则复用并改负责人为何斐，禁止建第二条。
|
||
|
||
### 需求变更
|
||
|
||
产品输入：
|
||
|
||
```text
|
||
变更需求：ONEOSP-123；增加导出时间筛选
|
||
```
|
||
|
||
Codex执行：先分析受影响的任务、MR、用例、缺陷和发布范围，给出应回到哪个阶段；产品确认后再修改，不直接覆盖历史说明。涉及原型功能变更时，同步 `$oneos-autoprd` 更新 PRD；用户再说「定稿」时写入第 10 章。
|
||
|
||
## 3. 分析和设计
|
||
|
||
### 开始分析
|
||
|
||
分析人员输入：
|
||
|
||
```text
|
||
开始分析：ONEOSP-123；负责人=李四
|
||
```
|
||
|
||
Codex执行：
|
||
|
||
1. 将需求推进到`分析中`（或确认已在分析中）。
|
||
2. **按 [auto-stage-task.md](auto-stage-task.md)**：查重后创建/复用与需求**同名**任务；标签=`分析`；正式关联需求；负责人默认=需求**创建人**（口令写了负责人则用口令）；计划开始/创建时间沿用需求。
|
||
3. 任务进入`处理中`（或项目约定的开工态）。
|
||
4. `stage_tasks`：需求标签含`分析`。`oneos_delivery`：不因此再建第二条【交付】主任务。
|
||
|
||
### 分析完成
|
||
|
||
分析人员输入：
|
||
|
||
```text
|
||
分析完成：ONEOSP-123；说明=https://...
|
||
```
|
||
|
||
Codex执行：检查分析产物和未决项；完成对应任务或主任务阶段，核查需求进入`分析完成`。
|
||
|
||
### 开始设计
|
||
|
||
设计人员输入：
|
||
|
||
```text
|
||
开始设计：ONEOSP-123；负责人=王五
|
||
```
|
||
|
||
Codex执行：
|
||
|
||
1. 将需求推进到`设计中`。
|
||
2. **按 auto-stage-task**：同名任务；标签=`设计`；正式关联；负责人默认=需求**创建人**（口令可覆盖）；时间沿用需求。
|
||
3. 任务开工态同上。
|
||
4. `oneos_delivery`：不同时新建交付主任务（交付主任务在待开发时建/复用）。
|
||
|
||
### 设计完成
|
||
|
||
设计人员输入：
|
||
|
||
```text
|
||
设计完成：ONEOSP-123；原型=https://...
|
||
```
|
||
|
||
Codex执行：检查原型或设计说明，完成设计任务/主任务阶段，核查需求进入`设计完成`。
|
||
|
||
如果项目已经部署并验证自动建开发任务的桥接，而且负责人、仓库和范围明确，Codex继续查重并创建开发任务；否则停在`设计完成`，提示技术负责人输入`安排开发`。不得创建无负责人或重复任务。
|
||
|
||
**进入待开发时（含快轨）：** 必须再跑 auto-stage-task：同名任务、标签`交付`（或`开发`）、负责人**何斐**、正式关联、时间沿用需求。
|
||
|
||
## 4. 开发
|
||
|
||
### 安排开发
|
||
|
||
技术负责人输入：
|
||
|
||
```text
|
||
安排开发：ONEOSP-123；前端=张三/ln-one-os-web；后端=李四/ln-cloud
|
||
```
|
||
|
||
只改一端时可以说：
|
||
|
||
```text
|
||
安排开发：ONEOSP-123；只改后端=李四/ln-cloud
|
||
```
|
||
|
||
Codex执行：按实际范围创建一条或多条`【开发】`任务，正式关联需求；`oneos_delivery`还要关联交付主任务。任务初始为`待处理`，需求进入`待开发`。明确“不涉及”的仓库不会成为完成门禁。
|
||
|
||
### 开始开发
|
||
|
||
开发人员输入：
|
||
|
||
```text
|
||
开始开发：ONEOSP-123；任务=TASK-456；仓库=ln-cloud
|
||
```
|
||
|
||
Codex执行：记录真实开始时间，确认真实基线`dev`或`develop`，创建`feature/ONEOSP-123`并同时正式关联需求和开发任务。任务进入`处理中`，需求进入`开发中`。
|
||
|
||
首次提交只作兜底，不覆盖这次真实开始时间。
|
||
|
||
### 提交代码
|
||
|
||
开发人员输入：
|
||
|
||
```text
|
||
提交代码：ONEOSP-123；任务=TASK-456；仓库=ln-cloud
|
||
```
|
||
|
||
Codex执行：检查改动和测试，先拉取并处理冲突，再提交、推送并创建合并到真实`dev/develop`的MR；MR同时关联需求和开发任务。提交成功不等于开发完成。
|
||
|
||
### 开发完成
|
||
|
||
开发人员或技术负责人输入：
|
||
|
||
```text
|
||
开发完成：ONEOSP-123
|
||
```
|
||
|
||
Codex执行：汇总该需求所有非取消开发任务、前后端仓库和正式关联MR。只有全部任务完成、全部相关MR已合并，才确认需求进入`开发完成`；少一个仓库也不提前完成。
|
||
|
||
条件满足后，如果项目已配置并验证唯一测试任务桥接，则查重创建测试任务；否则提示测试负责人输入`提交测试`。
|
||
|
||
## 5. 测试和缺陷
|
||
|
||
### 提交测试
|
||
|
||
测试负责人或开发负责人输入：
|
||
|
||
```text
|
||
提交测试：ONEOSP-123；test流水线=oneos-web-test
|
||
```
|
||
|
||
Codex执行：确认开发完成，触发或核查明确的test流水线。部署成功后，查重创建并正式关联唯一测试任务和需求用例包，进入`待测试/测试中`的项目真实状态。
|
||
|
||
test成功只允许开始测试，不能变成发布完成。
|
||
|
||
### 开始测试
|
||
|
||
测试人员输入：
|
||
|
||
```text
|
||
开始测试：ONEOSP-123；负责人=赵六
|
||
```
|
||
|
||
Codex执行：核查test部署和测试任务，把测试任务改为`测试中/处理中`，需求进入`测试中`。
|
||
|
||
### 发现Bug
|
||
|
||
测试人员输入：
|
||
|
||
```text
|
||
发现Bug：ONEOSP-123；用例=CASE-12；现象=车辆来源显示0；期望=显示中文来源
|
||
```
|
||
|
||
Codex执行：查重后创建缺陷，正式关联需求、原失败用例和必要开发任务；用例保持未通过，需求保持`测试中`。
|
||
|
||
### Bug修复完成
|
||
|
||
开发人员输入：
|
||
|
||
```text
|
||
Bug修复完成：BUG-123；MR=456；已部署test
|
||
```
|
||
|
||
Codex执行：核查代码、MR和test部署后，把缺陷改为`已修复`并交给测试复测。不会关闭缺陷，也不会把原用例直接改成通过。
|
||
|
||
### 复测通过
|
||
|
||
测试人员输入：
|
||
|
||
```text
|
||
复测通过：BUG-123；用例=CASE-12
|
||
```
|
||
|
||
Codex执行：重新记录原用例为通过，把缺陷改为项目真实关闭态，再检查该需求是否还有失败、阻塞、未执行用例或未关闭缺陷。
|
||
|
||
### 复测失败
|
||
|
||
测试人员输入：
|
||
|
||
```text
|
||
复测失败：BUG-123；用例=CASE-12；现象=仍显示0
|
||
```
|
||
|
||
Codex执行：原用例保持未通过，缺陷重开或回到处理中，并通知修复负责人；需求保持`测试中`。
|
||
|
||
### 测试完成
|
||
|
||
测试负责人输入：
|
||
|
||
```text
|
||
测试完成：ONEOSP-123
|
||
```
|
||
|
||
Codex执行：检查本需求用例包，不按整个迭代一刀切。只有没有未执行、阻塞、失败用例，且所有缺陷都经过测试复测关闭，才完成测试任务并推进需求到`测试完成`。
|
||
|
||
## 6. 发布和验收
|
||
|
||
### 准备发布
|
||
|
||
运维或项目负责人输入：
|
||
|
||
```text
|
||
准备发布：迭代V1.3；需求=ONEOSP-123,ONEOSP-124；窗口=今晚22:00
|
||
```
|
||
|
||
Codex执行：检查本批需求均测试完成，查重创建或复用唯一`【发版】`任务，正式关联迭代和需求，生成发布范围及回滚清单。
|
||
|
||
### 开始发布
|
||
|
||
运维输入：
|
||
|
||
```text
|
||
开始发布：发版任务=TASK-900；prod流水线=oneos-prod；审批人=王经理
|
||
```
|
||
|
||
Codex执行：核查审批、本批范围、生产流水线和回滚方案后进入`发布中`。这句话授权执行明确的本次生产发布，但不授权修改生产流水线定义。
|
||
|
||
### 发布成功
|
||
|
||
运维输入：
|
||
|
||
```text
|
||
发布成功：执行ID=PIPE-789；发版任务=TASK-900
|
||
```
|
||
|
||
Codex执行：到生产流水线核查环境、执行ID、范围和成功证据，确认后推进本批需求到`发布完成`并停留，等待验收。只说“成功”但没有生产证据时不改状态。
|
||
|
||
### 发布失败
|
||
|
||
运维输入：
|
||
|
||
```text
|
||
发布失败：执行ID=PIPE-789；原因=镜像拉取失败
|
||
```
|
||
|
||
Codex执行：核查失败证据，记录原因并进入项目真实`发布失败`状态；项目尚无该状态时记录阻塞并给出人工处置，不创建近义重复状态。
|
||
|
||
### 验收通过
|
||
|
||
产品或业务输入：
|
||
|
||
```text
|
||
验收通过：ONEOSP-123；验收人=王经理；证据=https://...
|
||
```
|
||
|
||
Codex执行：核查生产发布完成和验收证据后，把需求改为`已关闭`。发布成功不能代替本句验收。
|
||
|
||
### 验收不通过
|
||
|
||
产品或业务输入：
|
||
|
||
```text
|
||
验收不通过：ONEOSP-123；问题=导出字段缺失
|
||
```
|
||
|
||
Codex执行：创建或关联可追踪问题，判断应回到开发、测试还是重新发布，先给出处理建议；不关闭需求，不覆盖原发布记录。
|
||
|
||
## 7. 随时可用的查询口令
|
||
|
||
```text
|
||
查状态：ONEOSP-123
|
||
下一步：ONEOSP-123
|
||
为什么没流转：ONEOSP-123
|
||
查重复任务：ONEOSP-123
|
||
查关联代码：ONEOSP-123
|
||
查测试闭环：ONEOSP-123
|
||
给我回滚方案：刚才那条规则
|
||
```
|
||
|
||
这些口令默认只查询或出方案，不修改云效。
|
||
|
||
## 8. Codex的简短回报格式
|
||
|
||
处理成功：
|
||
|
||
```text
|
||
已处理：ONEOSP-123
|
||
状态：已确认 → 分析中
|
||
任务：已创建并关联分析任务 TASK-456
|
||
下一步：分析人员输入“分析完成：ONEOSP-123；说明=链接”
|
||
```
|
||
|
||
条件不足：
|
||
|
||
```text
|
||
暂未处理：ONEOSP-123
|
||
缺少：开发负责人
|
||
请补充：安排开发：ONEOSP-123；只改后端=负责人/仓库
|
||
```
|
||
|
||
自动化未触发：
|
||
|
||
```text
|
||
未触发：ONEOSP-123 仍为待开发
|
||
原因：分支只写了需求编号，没有在云效正式关联开发任务
|
||
下一步：我可以补正式关联，然后再核查一次
|
||
```
|
||
|
||
## 9. Codex执行口令的规则
|
||
|
||
1. `记录、确认、开始、完成、提交、修复、复测、准备发布、发布、验收`属于当前项目和明确工作项的执行授权。
|
||
2. `查、看看、为什么、下一步、给方案`只允许读取或规划。
|
||
3. 写操作前必须确认当前项目；项目不清楚只问项目名。
|
||
4. 其他必要字段缺失时只追问最少信息，不发送长表单。
|
||
5. 先查重、再创建；任务幂等键使用项目ID、需求ID和阶段类型。
|
||
6. 项目使用`stage_tasks`还是`oneos_delivery`由Codex识别，同事不需要记规则编号。
|
||
7. 当前平台或桥接不支持的动作要明确说“需要人工一步”，不能伪装成已自动化。
|
||
8. 自动规则执行后等待5–30秒，再回看状态、正式关联和执行日志。
|
||
9. 不用手工改最终状态冒充自动化通过。
|
||
10. 不修改生产流水线定义，不删除规则、分支、MR、任务或测试资产，除非用户单独明确授权。
|