狸想岛 · AI 实战学习社区

🎯 学 gstack 的跨项目回顾系统：不是每周开会说"上周做了什么"，而是从 gstack-review-log、deploy reports、learnings 中自动聚合数据——审查趋势、部署频率、bug 模式、代码健康变化——让回顾从"凭印象"变成"看数据"。 ⏱️ 预计时间：25 分钟

💡 新手提示：retro（项目复盘）和日常站会的区别在于——站会说"做了什么"，retro 说"我们变好了还是变差了，数据说话"。没有数据的回顾只是"凭印象"，而这种印象往往不准。

[!quote]- 📖 原Skill精要 技能名称：retro 核心功能：每周工程回顾。分析提交历史、工作模式和代码质量指标，具有持久化历史和趋势追踪。团队感知：分解每个人的贡献，给予赞扬和成长建议。从 gstack-review-log、deploy reports、learnings 中自动聚合数据。 所属体系：gstack 虚拟工程团队 协作关系：在周末或 sprint 结束时建议运行，读取 [[L6-18-审查仪表盘|review dashboard]] 的历史数据生成趋势分析

§1 课程概览

retro 是 gstack 的跨项目回顾系统。它将分散在多个 skill 中的工程数据（/review 的审查记录、/land-and-deploy 的部署报告、/investigate 的 bug 调查、/health 的代码健康评分、learnings.jsonl 的知识积累）聚合成五维趋势报告。核心价值：从"凭印象"变成"看数据"——不是"这周代码质量还行吧"，而是"quality_score 从 7.5 降到 6.8，过去 4 周持续下降，主要因为 Race Condition 类 bug 反复出现"。两种模式（/retro 单项目 + /retro global 跨项目）覆盖从个人开发者到 Tech Lead 的不同层级需求。

[!tip] 白话小课堂 "上周代码质量还行吧"——这是印象，不是数据。retro 就是把所有 gstack skill 产生的历史数据聚合成趋势图。审查记录、部署报告、bug 调查、健康评分——这些数据分散在不同的 skill 里，retro 把它们串成一条时间线：代码在变好还是变差？哪个模块问题最多（inventory 连续 4 周 Race Condition？）？到底是应该重构还是加测试？数据驱动的回顾让决策从"我感觉"变成"数据显示"。给老板汇报时，你能拿出"部署频率增长 38% 同时质量评分从 68 升到 73"这种组合数据，直接反击"更快发布必然牺牲质量"的谬误。

§2 Retro 的工程哲学——从数据中学习

传统回顾 vs 数据驱动的回顾

传统周回顾（印象驱动）：

"这周代码质量还行吧"（凭印象——上周五的严重 bug 会不成比例地影响判断）
"好像 bug 比上周多了"（没有数据——可能只是这周修了更多 bug 所以感觉更多）
"某模块需要重构"（一直这么说但不知道恶化速度——是三周后还是三个月后会爆炸？）

gstack retro（数据驱动）：

"这周 quality_score 从 7.5 降到 6.8，下降了 0.7——具体的恶化量"
"这周新增 3 个 CRITICAL bug，其中 2 个是竞态条件——具体的根因分类"
"payment 模块的圈复杂度从 8.2 升到 12.4，过去 4 周持续恶化——趋势而非快照"
"部署频率：这周 4 次，平均部署耗时 8 分钟——发布节奏的健康度"

数据驱动回顾的四个价值

发现问题趋势：在恶化到严重之前捕捉——"连续 4 周下降"比"本周降了"更有说服力
衡量改进效果：重构后质量有没有真的变好？还是只是感觉变好了？
识别模式：哪类 bug 反复出现？哪个模块问题最多？——用数据定位系统性问题的根源
指导工程投资：应该在哪个领域优先投入改进时间？——数据驱动资源分配，而非"谁喊得最大声"

§3 回顾的多维数据聚合——五个数据源

Review Trends（审查趋势）

来源：gstack-review-log（每次 /review 的持久化记录）。指标：

quality_score 的时间序列——本周平均分 vs 上周 vs 上月
每类发现（CRITICAL/INFORMATIONAL）的数量趋势——严重问题在减少还是增加？
AUTO-FIX vs ASK 比率——自动修复比例上升 = 代码中的机械性问题在减少（好信号）
专家利用率——哪些专家子 Agent 被门控跳过？审查清单是否需要调整？
Greptile 抑制率——误报多说明 Greptile 模型需要调整或规则过时

Deploy Trends（部署趋势）

来源：/land-and-deploy 的 deploy reports。指标：

部署频率——多久合入一次？频率是否健康？
部署成功率——REVERTED vs HEALTHY 比率——回退率高说明什么？
平均部署时长——CI wait + deploy + canary 各段耗时分析
Staging vs Production 差异——staging 验证通过率 vs production 成功率——如果差距大说明 staging 环境不够真实

Bug Patterns（Bug 模式）

来源：/investigate 的 Debug Reports。指标：

6 种 bug 模式的分布（Race Condition / State Corruption / Boundary Error / Assumption Violation / Environmental / Logic Error）
根因的重复模式——同一类 bug 反复出现 → 审查清单需要更新，或代码结构需要重构
3-Strike Rule 触发频率——调不好的 bug 多 → 代码库可能过于复杂或文档不足

Health Trends（代码健康趋势）

来源：/health 的持久化评分。指标：

6 个类别的评分趋势（Typecheck/Lint/Tests/Dead Code/Shell/GBrain）
GBrain 评分 vs 其他指标——背离是最危险的信号（其他指标上升但 GBrain 下降 = 在修症状不管病因）
Shell 脚本健康——shellcheck 问题数趋势（Shell 中的错误可以是灾难性的）

Learning Trends（学习趋势）

来源：learnings.jsonl（跨会话的知识积累）。指标：

新 learning 的类型分布——团队在学什么？
重复 learnings——同一件事被反复学习 → 应该写入 CLAUDE.md 固化知识

§4 Retro 报告结构——五段式输出

报告格式

═══════════════════════════════════════════════════════════
                    RETROSPECTIVE — mega-shop
                    Period: 2026-04-26 to 2026-05-03
═══════════════════════════════════════════════════════════

REVIEW TRENDS
─────────────────────────────────────────────────────────
Reviews completed: 12
Average quality_score: 7.8/10 (↑ 0.3 from last week)

Finding severity trend:
  CRITICAL:  3 → 2 → 1 → 1  ↓ improving
  INFO:      8 → 7 → 5 → 4  ↓ improving

Top finding categories:
  1. Race Conditions: 5 (repeated — update checklist?)
  2. Null Checks: 3
  3. N+1 Queries: 2

AUTO-FIX rate: 62% (↑ 8% — more mechanical issues found and fixed automatically)

DEPLOY TRENDS
─────────────────────────────────────────────────────────
Deploys: 4 (⬇ 1 from last week)
Success rate: 100% (4/4 HEALTHY)
Average deploy time: 6m 15s
  CI wait: 2m 30s | Deploy: 3m 20s | Canary: 25s

BUG PATTERNS
─────────────────────────────────────────────────────────
Bugs investigated: 5 | Root cause found: 4 (80%)
3-Strike escalation: 1

Bug pattern distribution:
  Race Condition: 2 (inventory module — 4 weeks in a row!)
  Boundary Error: 1 | Environmental: 1 | State Corruption: 1

⚠ ALERT: inventory 模块连续 4 周出现 Race Condition bug
  → 建议：对 inventory 模块进行全面并发安全性重构
  → 预计工作量：~3 天 (human) / ~2h (CC+gstack)

HEALTH TRENDS
─────────────────────────────────────────────────────────
Overall Health: 73/100 (≈ flat vs last week)
  Typecheck: 20/22 (≈) | Lint: 14/18 (≈) | Tests: 19/28 (⬆ +2)
  Dead Code: 11/13 (≈) | Shell: 9/9 (≈) | GBrain: 6/10 (⬇ -1)

⚠ GBrain 下降 + Tests 上升 = 在加测试覆盖旧代码但复杂度在增长

ACTIONS RECOMMENDED
─────────────────────────────────────────────────────────
1. 🔴 重构 inventory 模块的并发安全性（连续 4 周竞态 bug）
2. 🟡 更新审查清单：Race Condition 检查项需要强化
3. 🟡 监控 GBrain 评分——如果继续下降，需要分配重构时间
4. 🟢 将 3 个重复 learning 写入 CLAUDE.md

报告各部分的设计意图

REVIEW TRENDS：代码质量在变好还是变差？（最直接的质量信号）
DEPLOY TRENDS：团队发布节奏是否健康？（速度和稳定性的平衡）
BUG PATTERNS：哪些问题值得系统性地解决？（而不是每次都"修完这个 bug 就完了"）
HEALTH TRENDS：架构质量的技术债务趋势（最深层的健康指标）
ACTIONS：具体可执行的改进建议——不是"质量需要提高"这种空洞建议，而是"重构 inventory 的并发安全性，预计 3 天"

§5 Retro 的两种模式

/retro — 单项目回顾

回顾当前项目的近期数据。默认回顾最近 7 天。支持 --weeks 2（回顾 2 周）和 --since 2026-04-01（回顾指定起始日期）。

/retro global — 跨项目全局回顾

扫描 ~/.gstack/projects/ 下所有项目，汇总全局趋势。回答"哪个项目质量最高？哪个最需要关注？""跨项目的 bug 模式是什么？"。适用：Tech Lead 负责多个项目，需要在项目间分配资源。

回顾频率建议

每周快速回顾（5 分钟）→ 发现趋势——"这周有什么变化？"
每月深度回顾（15 分钟）→ 决策 + 行动——"我们下个月应该重点做什么？"
发布前回顾 → 确保没有遗漏的技术债务——"这个版本可以放心发布吗？"

§6 结构拆解

retro 项目复盘 Skill 结构模板

核心特征

管理对象: 工程团队的长期代码质量和发布趋势
核心原则: 数据驱动回顾——从"凭印象"变成"看数据"，发现趋势而非孤立事件
关键设计:
- 五维数据聚合：Review + Deploy + Bug + Health + Learning
- 趋势追踪：周环比、月环比、季度趋势——不是快照，是时间序列
- 可执行建议：具体到模块的改进方案 + 预估工作量（🔴🟡🟢 优先级）

通用结构

Review Trends 聚合层: 来源: gstack-review-log 指标: quality_score 时间序列、发现严重度分布、AUTO-FIX 比率、专家利用率
Deploy Trends 聚合层: 来源: land-and-deploy 的 deploy reports 指标: 部署频率、成功率（REVERTED vs HEALTHY）、平均部署时长（CI/deploy/canary 分段）
Bug Patterns 聚合层: 来源: /investigate 的 Debug Reports 指标: 6 种 bug 模式分布、重复根因检测、3-Strike 频率关键信号: 同一模块同一类 bug 连续出现 → 不是修 bug 的问题，是重构的问题
Health Trends 聚合层: 来源: /health 的持久化评分指标: 6 个类别的评分趋势关键信号: GBrain vs 其他指标的背离（最危险——在修症状不管病因）
Learning Trends 聚合层: 来源: learnings.jsonl 指标: 新 learning 类型分布、重复 learning 检测行动: 重复 learning → 写入 CLAUDE.md 固化
Actions 建议层: 🔴 紧急: 连续出现的安全/竞态 bug、持续恶化的架构指标 🟡 重要: 审查清单更新、monitor 趋势 🟢 优化: 知识固化、流程改进

§7 电商 Skill 案例：双11大促后项目复盘报告自动生成

🛒 实战案例：双11大促结束后，某电商平台CTO需要准备Q4工程回顾报告向CEO汇报。平台有4个微服务+5个开发Squad，使用gstack全家桶（/review、/qa、/health、/ship、/land-and-deploy）已积累6个月数据。使用/retro自动聚合所有数据源生成季度回顾报告。

部署速度与频率：Q3(7-9月) 42次部署(3.5次/周) → Q4(10-12月) 58次部署(4.8次/周)，部署频率提升38%。平均部署耗时从7.5分钟降到5.2分钟（减少31%）。封网期(10/25-11/11)hotfix部署8次全部通过canary验证。关键洞察——部署更快的同时质量也在提升，反驳"更快部署必然牺牲质量"的常见谬误。

代码质量趋势（Health Score + QA Score + Review Quality）：health score从Q3平均68→10月71→11月73→12月76（持续改善+8）。QA Score从78→81→82→84（+6）。Review Quality Score从7.2→7.5→7.8→8.0（+0.8）。多维质量指标全部向上——不是单一指标的虚高。

Bug严重度趋势与根因分析：CRITICAL bug从Q3月均4个→10月4个→11月1个→12月1个（下降75%）。根因分布——Race Condition 5个(42%，inventory×3+payment×2)、Assumption Violation 2个(17%，API契约变更后消费者未知)、Boundary Error 1个(8%)、Null Reference 2个(17%)、配置错误 2个(17%，CDN缓存预热不足)。Race condition集中在库存模块——连续2个季度排名第一的bug根因。

模块级健康对比：payment模块——Health Score 72→78(+6，最佳改善)，GBrain复杂度7→6（重构成功降低复杂度），Race Condition bug 2→0（重构解决了并发问题）。inventory模块——Health Score 65→66(+1，几乎无改善)，GBrain复杂度4→4（未改善），Race Condition bug 3→3（问题没有减少）。两个模块的对比形成鲜明反衬——投资重构的模块vs未投资的模块，效果差距5倍。

TOP 3 工程投资建议：(1)库存模块深度重构（连续2季度Race Condition #1来源，投资2周预期CRITICAL bug -75%/Health+5）；(2)引入OpenAPI spec-based contract testing（消除"接口改了但消费者不知道"类assumption violation bug）；(3)巩固部署自动化ROI——Q4部署频率+38%同时质量+8，证明自动化投资的决策正确。

给CEO的3页PPT：第1页团队速度——"Q4发布了58次(比Q3+38%)，平均部署5.2分钟"；第2页代码质量——"健康评分+8，CRITICAL bug-75%，我们在同时变快和变好"；第3页下一步——"库存模块重构（当前最大技术债务）+ API契约测试消除假设违反bug"。

🔑 启示：/retro的真正价值不是"生成漂亮的图表"——是让工程决策从政治变为数据驱动。inventory模块是否需要重构这个决策，如果没有retro数据，CTO凭感觉说"库存模块问题多"，team lead反驳"还好吧，最近没啥大问题"→讨论陷入主观。但retro数据摆出来："连续2季度Race Condition #1来源、Health几乎无改善、与payment模块对比差距5倍"→不需要争论，数据自己说话。

[!info] 参考来源工程回顾的数据驱动方法论参考了 DORA Metrics (DevOps Research and Assessment) 的四大指标和 Accelerate State of DevOps Report 的研究方法。

§8 掌握检验

Q1：retro 从五个数据源聚合信息，其中 Bug 模式（Bug Patterns）的数据来源是什么？

A) git log 和 git diff
B) /investigate 的 Debug Reports —— 6 种 bug 模式的分布和根因的重复模式
C) GitHub Issues 和 Slack 讨论
D) 开发者手动填写的 bug 报表

Q2：retro 报告中发现 "GBrain 下降 + Tests 上升"——这意味着什么？

A) 代码在全面改善——测试增加且架构优化
B) 在加测试覆盖旧代码，但代码复杂度在持续增长——"在修症状（加测试）但不管病因（重构复杂代码）"
C) GBrain 和 Tests 没有关联，这只是巧合
D) 测试增加导致 GBrain 评分下降——应该减少测试

Q3：inventory 模块连续 4 周出现 Race Condition bug。retro 建议"重构并发安全性"而非"再多加些测试"——为什么额外的测试不是正确的应对策略？请从"测试捕获 bug vs 重构消除 bug 来源"的角度分析两种策略的长期效果差异。

Q4：retro 报告显示"Q2 部署频率增长 38% 同时质量评分从 68 升到 73"。为什么这个数据组合有说服力——它反驳了什么常见的工程谬误？如果只汇报"部署频率增长 38%"而忽略质量数据，对 CEO 来说这个信号会变成什么？

Q5：/retro 和 /retro global 的核心区别是什么？假设你是一个 Tech Lead 负责 3 个项目，其中项目 A 的 Health 评分 85、项目 B 评分 72、项目 C 评分 58——global retro 应该建议怎样的资源分配优先级？每个项目的具体行动应该是什么？

Q6："上周代码质量还行吧"是印象驱动的回顾，而 retro 是数据驱动的回顾。请分析为什么印象驱动的回顾往往不准——给出至少两个认知偏误（Cognitive Bias），解释它们如何导致团队高估或低估自己的代码质量。数据驱动的 retro 如何通过具体的指标来纠正这些偏误？

§9 答案

点击查看答案

Q1：B —— Bug 模式数据来自 /investigate 的 Debug Reports。不是 GitHub Issues（那些是用户报告的 bug，不是工程团队调查的 bug），也不是主观报表。

Q2：B —— GBrain 下降 + Tests 上升 = 团队在持续增加测试覆盖（Tests 从 19 → 21），但代码的内在复杂度在增加（GBrain 从 7 → 6）。"在修症状（加测试覆盖旧代码）但不管病因（重构降低复杂度）"。

Q3：额外测试的局限性：测试能捕获"已经发生的 Race Condition"然后你修复它——但测试不能防止"下一个 Race Condition"的出现。如果 inventory 模块的根本问题是"代码结构容易产生竞态条件"，每个新 feature 都可能在现有测试覆盖不到的路径中引入新 Race Condition。重构并发安全性是从根源上让"竞态条件难以被引入"。长期效果：重构 → bug 减少趋势持续；加测试 → bug 反复出现，每次用测试补一个洞。

Q4：反驳的谬误："更快发布必然牺牲质量"。这个团队用数据证明：部署频率 +38% 同时质量 +5——更快和更好可以同时发生。原因是部署自动化（非人更快）。如果只汇报频率而忽略质量，CEO 可能担心"团队为了速度牺牲稳定性"——频率 + 质量的联合数据 = 工程能力的可信证明。

Q5：/retro 是单项目回顾；/retro global 扫描所有项目汇总全局趋势。资源分配：A（85 GOOD）→ 维持，最低投入；B（72 FAIR）→ 中等投入，分析拖分维度；C（58 POOR）→ 最高投入，停止新功能，系统性偿还债务。global retro 避免"投诉最多的项目得到最多资源"的政治化分配。

Q6：①近因效应（Recency Bias）——最近发生的 bug 权重更高。上周五的生产事故会让团队高估"整周都很差"。数据纠正：retro 显示全周期聚合数据。②确认偏误（Confirmation Bias）——感觉质量变好时会注意证明变好的信号，忽略变差的信号。数据纠正：retro 从多维度独立收集数据，交叉验证揭示"感觉"忽略的矛盾。

（5/6 通过）

L6-36：项目复盘大师 —— 从历史数据中挖出团队成长密码