# 第 33 章 任务生命周期与代码即沟通

## 本章目标

- **O1** 能够按真实转移条件排列“待定界”“实施中”“已验收／阻塞”（产物：任务生命周期状态表）
  - 证据: 任务生命周期状态表按时间或状态顺序排列“待定界”“实施中”和“已验收／阻塞”
- **O2** 能够构造任务生命周期状态表，为每个状态或里程碑定义入口和出口（产物：任务生命周期状态表）
  - 证据: 任务生命周期状态表为三个节点分别写出入口、出口和责任人
- **O3** 能够用入口、状态、出口和阻塞原因管理任务生命周期（产物：任务生命周期状态表）
  - 证据: 产物记录一个任务从待定界到验收或阻塞的完整状态轨迹

## 学习路径

- **初学者**: 本章迁移任务是：能够用入口、状态、出口和阻塞原因管理任务生命周期。先按图中的“状态转移”关系完成任务生命周期状态表的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够用入口、状态、出口和阻塞原因管理任务生命周期。提交任务生命周期状态表后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: 任务生命周期状态表
- **图解类型**: task-state-machine
- **关系语义**: 节点沿时间或状态从左向右推进；只有满足出口条件才能转移，时间经过本身不构成完成。
- **核心概念**: 待定界 · 实施中 · 已验收／阻塞

![第 33 章任务生命周期状态表教学图](/learning/diagrams/zh/chapter-33.svg)

按入口与出口条件阅读任务生命周期状态表，避免把日期到达误当成阶段完成。

图沿水平轴依次放置“待定界”“实施中”“已验收／阻塞”。连线表示时间或状态转移，但只有当前节点的出口证据齐全才能进入下一节点；日历时间经过不自动触发转移。

> **公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。

## 课程讲解

### 33.1 看板驱动：让进度可视化、状态可追踪

看板（Kanban）是高自主团队协作的基础设施。它的核心价值：让进度可视化，让状态可追踪。

在高自主的环境中，没有人在你身后盯着进度。看板取代了"监工"，成为团队共享的"进度仪表盘"——每个人都可以随时看到：团队在做什么、谁在做什么、哪些任务阻塞了、哪些任务完成了。

看板的基本列：待办（Todo）→ 进行中（In Progress）→ 评审/测试（Review/Test）→ 已完成（Done）。在此基础上可根据团队需要增加"阻塞（Blocked）"列（任务遇到阻碍无法前进）。

看板驱动的基本原则：

1. 一切工作进看板：任何一项工作（功能开发、Bug 修复、技术债清理、设计任务）都应该在看板上有对应的卡片。没有卡片的任务，等于不存在；
2. 状态真实反映：卡片的状态必须真实反映工作的实际状态——开始做就拖入"进行中"，完成就拖入"已完成"，受阻就标记"阻塞"并说明原因；
3. WIP 限制（Work In Progress Limit）：限制每个列中同时进行中的任务数量，防止"多任务地狱"——同时做太多事，等于什么都没做好；
4. 看板即沟通：进度同步不必反复"汇报"，看板本身就是最真实的进度汇报。

### 33.2 标签的艺术：快速对齐上下文

当任务卡片越来越多，标签（Label/Tag）成为快速分类、筛选、对齐上下文的利器。

常用的标签维度：

- 优先级：P0（立即处理，紧急故障）、P1（高优先级，近期完成）、P2（正常优先级）、P3（低优先级，可以等待）；
- 类型：feature（功能）、bug（缺陷）、chore（杂务）、refactor（重构）、tech-debt（技术债）；
- 业务领域：auth（认证）、payment（支付）、checkout（结算）、user（用户）；
- 状态语义：blocked（被阻塞）、needs-review（待评审）、urgent（紧急）、money（涉及金钱，高风险）。

标签的价值：一张带 `urgent + money + payment` 标签的卡片，让任何看到它的人都能立刻判断——这是一个紧急的、涉及金钱的支付相关任务，需要优先处理。标签让"上下文对齐"从"逐条阅读卡片描述"变成"一眼扫过标签栏"。

标签的纪律：标签体系需要团队共同约定并保持一致性。不要滥用标签（贴得太多等于没贴），定期清理失效标签。

### 33.3 任务的归属与跟进：谁发起、谁澄清、谁闭环

一个任务从"想法"到"归档"，需要明确地回答三个问题：谁发起、谁澄清、谁闭环。

- 谁发起（Initiator）：任务的创建者。负责把想法转化成清晰的任务卡片（含背景、目标、验收标准）；
- 谁澄清（Clarifier）：通常也是创建者。当执行者对任务有疑问时，负责澄清需求、补充上下文、解决分歧；
- 谁闭环（Closer）：执行者。负责完成任务并更新状态，创建者负责验收确认。只有经过验收确认的任务，才能标记为"已完成"。

归属与跟进的实操准则：

1. 一个任务一个负责人：每个任务卡片必须有一个明确的 Assignee（执行者），不允许出现"没人负责"的任务；
2. 发起者跟进到底：任务创建者有责任跟进任务的进展，直到闭环——不能"建了卡就消失"；
3. 阻塞必上报：任务被阻塞时，执行者必须立即在卡片上说明原因、影响和需要的帮助，而不是默默等待。

### 33.4 分支管理：一个任务，一个分支

"一个任务，一个分支"是代码协作的基本纪律。它让每一次代码变更都与一个明确的任务卡片对应，让合并、审查、回滚都变得清晰可控。

分支命名规范（推荐约定式）：

<!-- code-example:chapter-33-E1 mode:reference -->
> **示例类型：参考。** 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。
```text
feature/[ticket-id]-[short-description]    # 功能开发
fix/[ticket-id]-[short-description]        # Bug 修复
hotfix/[ticket-id]-[short-description]     # 生产环境紧急修复（从 master 创建）
chore/[ticket-id]-[short-description]      # 杂务/构建/工具
refactor/[ticket-id]-[short-description]   # 重构
```

示例：`feature/TICKET-123-user-tagging`、`fix/TICKET-789-null-pointer-on-profile`。

分支纪律：

1. 一个任务一个分支：分支从开发主线（develop/master）创建，与任务一一对应，任务完成并合并后删除分支；
2. 分支从正确的主线创建：普通功能从 develop 创建；生产紧急修复必须从 master（代表线上代码的分支）创建——因为 develop 上可能包含其他未发布的、不稳定的新功能，你不希望在紧急修复中引入无关的有风险变更；
3. 小步提交：分支内的提交保持小而清晰，每个提交讲一个故事（见 33.5）；
4. 合并前通过评审：分支合并到主线前，必须通过 CI 检查 + 代码评审（一个任务一个分支让评审的对象天然聚焦）。

### 33.5 提交管理：让每一次 Commit 讲述一个清晰的故事（约定式提交）

提交（Commit）是团队协作的"文字记录"——它是代码历史的最小单元，也是团队文化在代码库中的投影。一个团队的提交历史，应该像一本结构清晰的日记，而不是一团乱麻。

约定式提交（Conventional Commits）是一套标准化的提交信息规范：

<!-- code-example:chapter-33-E2 mode:reference -->
> **示例类型：参考。** 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。
```text
<type>(<scope>): <subject>

<body>（可选）

<footer>（可选，如 BREAKING CHANGE: ...）
```

Type 类型：

| 类型 | 含义 | 示例 |
|------|------|------|
| feat | 新功能 | `feat(auth): 增加手机号登录` |
| fix | Bug 修复 | `fix(payment): 修复支付掉单问题` |
| refactor | 重构（不改变行为） | `refactor(user): 抽离用户数据获取逻辑` |
| docs | 文档变更 | `docs: 更新 README` |
| test | 测试相关 | `test(discount): 增加周年庆折扣测试用例` |
| chore | 构建/工具/杂务 | `chore: 升级依赖版本` |
| style | 格式调整（不影响逻辑） | `style: 统一代码缩进` |
| perf | 性能优化 | `perf(orders): 用 SQL 聚合代替内存计算` |

约定式提交的价值：

1. 让历史可读：任何人浏览 git log，都能快速理解每一次提交的意图——这个提交是加功能、修 Bug 还是重构？
2. 自动生成 Changelog：基于提交类型，可以自动生成清晰的版本变更日志；
3. 支持自动化：语义化版本号可以根据提交类型自动计算（feat 加 minor，fix 加 patch，BREAKING CHANGE 加 major）。

好的提交 vs 坏的提交：

<!-- code-example:chapter-33-E3 mode:reference -->
> **示例类型：参考。** 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。
```text
❌ 坏的提交：`fix stuff` / `update` / `changes`
✅ 好的提交：`fix(payment): 修复并发下单导致的重复扣款`

❌ 坏的提交（一条提交混入多个改动）：`add auth and fix bugs and refactor user service`
✅ 好的提交（一个提交一个故事）：`feat(auth): 增加 JWT 刷新令牌机制`
```

### 33.6 版本发布与 Changelog：语义化版本

语义化版本（Semantic Versioning, SemVer）是版本号的标准规范，格式为：`MAJOR.MINOR.PATCH`：

- MAJOR（主版本号）：不兼容的 API 变更时递增（如 1.0.0 → 2.0.0）；
- MINOR（次版本号）：向后兼容的功能新增时递增（如 1.0.0 → 1.1.0）；
- PATCH（修订号）：向后兼容的 Bug 修复时递增（如 1.0.0 → 1.0.1）。

语义化版本的价值：它向所有人（包括其他依赖你的系统的团队）传达了变更的"风险等级"——看到 MAJOR 版本变化，就知道可能有不兼容变更；看到 PATCH 版本变化，就知道是安全的修复。

Changelog（变更日志）是版本发布的"对内同步、对外宣告"：

- 对内：团队成员通过 Changelog 了解每次发布的内容，快速定位"这个 Bug 是哪个版本修好的"；
- 对外：依赖方通过 Changelog 评估升级风险，判断是否需要调整代码。

Changelog 的规范：

<!-- code-example:chapter-33-E4 mode:reference -->
> **示例类型：参考。** 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。
```text
## [2.1.0] - 2026-08-15
### Added（新增）
- 支持手机号登录
### Fixed（修复）
- 修复支付掉单问题
### Changed（变更）
- 升级依赖库版本
```

Changelog 与 AI 协作的交汇点：还记得第 13-14 章吗？CHANGELOG.md 是 AI 的"航行日志"——每次 /clear 后通过它恢复上下文。它既是给人看的版本记录，也是给 AI 看的"项目状态快照"。一份规范的 Changelog，同时服务了"人类协作"和"人机协作"两个目标。

版本发布流程（结合第 24 章的灰度 SOP）：

1. 合并所有变更到 develop，跑完整测试套件；
2. 更新 Changelog，明确本次发布的变更内容；
3. 创建 release 分支，部署到灰度环境验证；
4. 灰度通过（双人确认），全量发布；
5. 打版本 Tag（如 `v2.1.0`），作为可回滚的基线。

---

> 第十部分完成。你已经掌握了团队协作与交付文化的完整体系：异步优先默认公开（告别"在吗？"、信息饱和式传递、公开频道的价值）、高信任无须监控的默契（可预测性比能力更重要、"事事有回响"、坏消息第一时间法则、SBI-I 困难对话模型）、高自主与高质量交付（产出导向而非在线导向、清晰边界与共同蓝图 OKR、从执行者到负责人、敬畏生产与数据红线、15 分钟法则）、任务生命周期与代码即沟通（看板驱动、标签的艺术、任务归属、一个任务一个分支、约定式提交、语义化版本与 Changelog）。

> 现在，让我们进入第十一部分：团队导入与持续进化。在那里，方法论将从一个团队的文化，变成一套可复制的导入路线图与培训体系。

## 独立练习

使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 `chapter-33.md`，写上版本、决定、证据和缺项。

为unknown修复建任务卡，写状态退出条件、分支名、提交说明、评审摘要和变更记录。解释哪些操作需要单独授权。

<!-- chapter-artifact-requirement -->
### 本章必交产物：任务生命周期状态表

以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。

- O1: 任务生命周期状态表按时间或状态顺序排列“待定界”“实施中”和“已验收／阻塞”
- O2: 任务生命周期状态表为三个节点分别写出入口、出口和责任人
- O3: 产物记录一个任务从待定界到验收或阻塞的完整状态轨迹

<details>
<summary>查看参考反馈（先独立作答）</summary>

## 参考反馈

任务说明症状、范围和固定检查；提交说明为什么改及用户行为变化；评审附实际运行结果和风险。状态完成需产物与检查，不只代码写完。推送、合并、外部通知和部署须遵守已有授权，不能由任务状态自动触发。

### 自评与下一步

对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。

</details>

## 来源与边界

登记来源只支持本章涉及的外部事实；任务生命周期状态表、示例数字和练习情境属于课程内部教学设计，必须在实际项目中重新验证。

- [Git 官方参考](https://git-scm.com/docs) — Git project, 2026-09-17. 版本、分支、提交与恢复操作须按实际仓库状态验证。
- [GitHub Actions 官方文档](https://docs.github.com/en/actions) — GitHub, 2026-09-17. 仓库工作流可以自动执行构建、测试和持续集成任务。