114 lines
2.4 KiB
Markdown
114 lines
2.4 KiB
Markdown
# L0 与 L1 轻量流程
|
|
|
|
## L0
|
|
|
|
仅对影响极小且不改变运行行为的变更使用 L0。
|
|
|
|
```text
|
|
理解并定位
|
|
→ 说明具体改动和影响
|
|
→ 用户确认
|
|
→ 修改
|
|
→ 检查差异
|
|
→ 执行最小必要验证
|
|
→ 报告结果
|
|
```
|
|
|
|
确认内容可以很精简：
|
|
|
|
```markdown
|
|
变更等级：L0
|
|
|
|
计划修改：
|
|
- ...
|
|
|
|
影响范围：
|
|
- ...
|
|
|
|
验证方式：
|
|
- ...
|
|
```
|
|
|
|
L0 不创建完整的 L2 PM 文档集，但仍必须保留用户已有改动、遵循项目规则、检查最终差异，并说明实际执行了哪些验证。
|
|
|
|
如果看似简单的修改会改变配置、运行行为、对外含义、契约或业务规则，必须升级。
|
|
|
|
## L1
|
|
|
|
维护一份持续更新的文档：
|
|
|
|
```text
|
|
01.精简变更日志.md
|
|
```
|
|
|
|
落地位置分两种情况：
|
|
|
|
- 独立需求：放在该需求的 `management/PM-<编号>-<名称>/` 大需求根目录下。
|
|
- 大需求下的子任务：放在对应 `tasks/ST-<编号>-<名称>/` 子任务目录内。
|
|
|
|
PM 编号尚未确定时使用 `PM-待确认-<需求名称>`，在本次 L1 编码前确认中由用户决定后再改为正式目录。Agent 不得自行生成永久编号。
|
|
|
|
编码前完成第 1–6 节并取得一次确认；编码后补充第 7–12 节。
|
|
|
|
```markdown
|
|
# 精简变更日志
|
|
|
|
## 1. 基本信息
|
|
- 需求编号：
|
|
- 需求名称：
|
|
- 影响等级：L1
|
|
- 当前状态：
|
|
|
|
## 2. 需求说明
|
|
|
|
## 3. 变更范围
|
|
- 涉及工程：
|
|
- 涉及功能：
|
|
- 涉及接口：
|
|
- 非本次范围：
|
|
|
|
## 4. 影响及回归范围
|
|
|
|
## 5. 技术实现计划
|
|
- 现有逻辑：
|
|
- 复用内容：
|
|
- 计划改动：
|
|
- 数据变化：
|
|
- 风险与待确认项：
|
|
|
|
## 6. 冒烟自测用例
|
|
| 功能点 | 验证场景 | 预期结果 |
|
|
|---|---|---|
|
|
|
|
## 7. 用户确认记录
|
|
|
|
## 8. 实际代码改动
|
|
|
|
## 9. Code Review
|
|
|
|
## 10. 逻辑验证和冒烟结果
|
|
|
|
## 11. 遗留问题
|
|
|
|
## 12. 完成结论
|
|
```
|
|
|
|
执行流程：
|
|
|
|
```text
|
|
只读调查
|
|
→ 编写计划部分
|
|
→ 用户确认一次
|
|
→ 实现
|
|
→ Review
|
|
→ 逻辑验证和冒烟
|
|
→ 补全日志
|
|
→ 标记开发完成
|
|
```
|
|
|
|
编码前可以写 Review 检查范围，但不能伪造 Review 结论。实际 Review 和测试结果只能在执行后填写。
|
|
|
|
如果发现广泛依赖、核心架构变化、破坏性兼容问题、复杂迁移或无法界定的回归范围，升级为 L2。
|
|
|
|
Agent 在 L1 中不得执行 `git add`、`git commit`、`git push`；暂存、提交和推送由用户完成。变更日志中的请求响应、日志和测试证据必须脱敏。
|