第 33 章 任务生命周期与代码即沟通
2026.08.2933.1 看板驱动：让进度可视化、状态可追踪
看板（Kanban）是高自主团队协作的基础设施。它的核心价值：让进度可视化，让状态可追踪。
在高自主的环境中，没有人在你身后盯着进度。看板取代了"监工"，成为团队共享的"进度仪表盘"——每个人都可以随时看到：团队在做什么、谁在做什么、哪些任务阻塞了、哪些任务完成了。
看板的基本列：待办（Todo）→ 进行中（In Progress）→ 评审/测试（Review/Test）→ 已完成（Done）。在此基础上可根据团队需要增加"阻塞（Blocked）"列（任务遇到阻碍无法前进）。
看板驱动的基本原则：
- 一切工作进看板：任何一项工作（功能开发、Bug 修复、技术债清理、设计任务）都应该在看板上有对应的卡片。没有卡片的任务，等于不存在；
- 状态真实反映：卡片的状态必须真实反映工作的实际状态——开始做就拖入"进行中"，完成就拖入"已完成"，受阻就标记"阻塞"并说明原因；
- WIP 限制（Work In Progress Limit）：限制每个列中同时进行中的任务数量，防止"多任务地狱"——同时做太多事，等于什么都没做好；
- 看板即沟通：进度同步不必反复"汇报"，看板本身就是最真实的进度汇报。
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）：执行者。负责完成任务并更新状态，创建者负责验收确认。只有经过验收确认的任务，才能标记为"已完成"。
归属与跟进的实操准则：
- 一个任务一个负责人：每个任务卡片必须有一个明确的 Assignee（执行者），不允许出现"没人负责"的任务；
- 发起者跟进到底：任务创建者有责任跟进任务的进展，直到闭环——不能"建了卡就消失"；
- 阻塞必上报：任务被阻塞时，执行者必须立即在卡片上说明原因、影响和需要的帮助，而不是默默等待。
33.4 分支管理：一个任务，一个分支
"一个任务，一个分支"是代码协作的基本纪律。它让每一次代码变更都与一个明确的任务卡片对应，让合并、审查、回滚都变得清晰可控。
分支命名规范（推荐约定式）：
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。
分支纪律：
- 一个任务一个分支：分支从开发主线（develop/master）创建，与任务一一对应，任务完成并合并后删除分支；
- 分支从正确的主线创建：普通功能从 develop 创建；生产紧急修复必须从 master（代表线上代码的分支）创建——因为 develop 上可能包含其他未发布的、不稳定的新功能，你不希望在紧急修复中引入无关的有风险变更；
- 小步提交：分支内的提交保持小而清晰，每个提交讲一个故事（见 33.5）；
- 合并前通过评审：分支合并到主线前，必须通过 CI 检查 + 代码评审（一个任务一个分支让评审的对象天然聚焦）。
33.5 提交管理：让每一次 Commit 讲述一个清晰的故事（约定式提交）
提交（Commit）是团队协作的"文字记录"——它是代码历史的最小单元，也是团队文化在代码库中的投影。一个团队的提交历史，应该像一本结构清晰的日记，而不是一团乱麻。
约定式提交（Conventional Commits）是一套标准化的提交信息规范：
<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 聚合代替内存计算 |
约定式提交的价值：
- 让历史可读：任何人浏览 git log，都能快速理解每一次提交的意图——这个提交是加功能、修 Bug 还是重构？
- 自动生成 Changelog：基于提交类型，可以自动生成清晰的版本变更日志；
- 支持自动化：语义化版本号可以根据提交类型自动计算（feat 加 minor，fix 加 patch，BREAKING CHANGE 加 major）。
好的提交 vs 坏的提交：
❌ 坏的提交：`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 的规范：
## [2.1.0] - 2026-08-15
### Added（新增）
- 支持手机号登录
### Fixed（修复）
- 修复支付掉单问题
### Changed（变更）
- 升级依赖库版本
Changelog 与 AI 协作的交汇点：还记得第 13-14 章吗？CHANGELOG.md 是 AI 的"航行日志"——每次 /clear 后通过它恢复上下文。它既是给人看的版本记录，也是给 AI 看的"项目状态快照"。一份规范的 Changelog，同时服务了"人类协作"和"人机协作"两个目标。
版本发布流程（结合第 24 章的灰度 SOP）：
- 合并所有变更到 develop，跑完整测试套件；
- 更新 Changelog，明确本次发布的变更内容；
- 创建 release 分支，部署到灰度环境验证；
- 灰度通过（双人确认），全量发布；
- 打版本 Tag（如
v2.1.0），作为可回滚的基线。
第十部分完成。你已经掌握了团队协作与交付文化的完整体系：异步优先默认公开（告别"在吗？"、信息饱和式传递、公开频道的价值）、高信任无须监控的默契（可预测性比能力更重要、"事事有回响"、坏消息第一时间法则、SBI-I 困难对话模型）、高自主与高质量交付（产出导向而非在线导向、清晰边界与共同蓝图 OKR、从执行者到负责人、敬畏生产与数据红线、15 分钟法则）、任务生命周期与代码即沟通（看板驱动、标签的艺术、任务归属、一个任务一个分支、约定式提交、语义化版本与 Changelog）。
现在，让我们进入第十一部分：团队导入与持续进化。在那里，方法论将从一个团队的文化，变成一套可复制的导入路线图与培训体系。