agentleFS
Sign inStart free
peterwangzepeterwangze/software-project-governance/skills/stage-maintenance/SKILL.md

stage-maintenance

Skill2 starsChanged 5 months agoMITView on GitHub

维护与演进——Bug修复、规则更新、复盘。阶段子工作流，可独立使用。

The file

Create a free account to mount
Files
SKILL.md

维护与演进 — 子工作流

本文件定义"维护与演进"阶段的独立子工作流。用户可单独加载本文件执行维护阶段。

阶段目标

通过复盘和经验回灌持续改进工作流和项目。维护阶段的核心产出是"复盘结论和改进计划"——回答"学到了什么、哪里做得不好、下次怎么做得更好"。

AI 编程场景特有风险

在 AI 辅助编程项目中，维护与演进阶段存在以下特有风险：

风险说明缓解方向
AI 复盘流于形式AI 生成的复盘文档倾向于罗列"做了什么"而非"学到了什么"，缺少真正的根因分析和可执行的改进项，"看起来完整但实质上空洞"复盘必须包含 5-Why 根因分析（至少 1 个问题的深度追溯）；"做得好/做得不好"各有 ≥3 条且每条有具体例子
经验回灌表面化AI 声称"已更新规则/模板"但实际只是加了一句话或改了个名字，没有真正改变行为约束（文档更新 ≠ 经验回灌）经验回灌必须验证：新规则能否被自动化检查？模板字段是否有新增或调整？现有流程是否会因此产生不同行为？
改进计划过于乐观AI 倾向于规划远超下一轮执行能力的改进项——7 条 P0 任务塞进 2 个 session，结果每条都只做一半改进计划单轮不超过 5 条；每条有预估工作量（session 数）；总预估不超过下一轮可用资源的 80%
技术债务累积被忽略AI 倾向于关注"下一步做什么"而忽略"现有代码中哪些地方在拖慢我们"——技术债在维护阶段最应该被正视但最容易被跳过维护阶段必须执行技术债盘点——列出 ≥3 条已知技术债，标注严重度和偿还代价
复盘变成自我表扬AI 倾向于在复盘中软化批评、弱化失败、放大成绩——"基本完成""大致达到预期""总体良好"复盘必须有"下次要改什么"的具体项（≥3 条）；"做得不好"的条目不得使用模糊词（基本/大致/总体）

独立使用时的目标锚定

当本子工作流被独立加载（非通过 main-workflow.md 总入口加载）时，MUST 在执行阶段活动前完成：

  1. 目标确认：读取 .governance/plan-tracker.md，确认项目立项时定义的量化成功标准
  2. 偏离检查：对照成功标准，确认复盘和改进方向与项目总目标一致。如发现偏离，MUST 先记录到 .governance/decision-log.md 再继续
  3. 质量底线：复盘必须包含根因分析和可执行的改进项（参考 profile 质量要求）

进入条件

  • 运营阶段已完成（G10 通过）
  • 有运营报告和反馈数据

活动清单

1. 复盘执行

活动描述交互边界企业实践
目标回顾逐项评估立项时定义的量化成功标准的达成度——不是"感觉完成了"，是"数据说完成了多少"自动执行：数据 vs 目标值对比[ByteDance 数据驱动] 目标达成度必须有数字——"基本完成"不是完成
结果评估做得好的 ≥3 条 + 做得不好的 ≥3 条，每条有具体例子和影响描述自动执行 → 需用户确认[华为自我批判] "做得不好"必须有具体事例，不得使用"基本/大致/总体"等模糊词
根因分析对关键问题（做得不好的 Top 3）做 5-Why 深度追溯，直到找到流程/机制层面的根因自动执行[华为 RCA] 5-Why 必须追到流程或机制层面，不能停在"人没做好"
团队反馈收集汇总项目参与者的反馈——不是一个人的复盘，是所有参与者的声音需用户输入[Google Blameless Postmortem] 复盘聚焦"流程怎么改进"而非"谁犯了错"

2. 经验回灌

活动描述交互边界企业实践
提炼可复用经验按维度分类：流程/技术/协作/管理；区分"本项目特有的"和"可跨项目复用的"自动执行[Amazon] 不只提炼经验，要区分适用边界——不是所有经验都能跨项目复用
映射到规则和模板经验能否转化为检查项、模板字段、Gate 规则或自动化脚本？自动执行[华为 IPD] 经验必须转化为可执行的规则——停留在文档里的经验不是经验，是记忆
更新工作流资产按映射结果更新子工作流、Gate、skill 或模板自动执行[ByteDance Context not Control] 更新时记录"为什么改"——让后来者理解上下文
验证回灌效果新规则能否被自动化检查？模板更新是否改变行为？自动执行：运行验证脚本[Google] 回灌不是"文档改了就行"——要验证新规则真的改变了系统行为

3. 下轮规划

活动描述交互边界企业实践
确定下轮方向基于复盘结论和运营数据，确定下一轮迭代的目标和优先级需用户确认[Amazon Working Backwards] 下一轮方向必须回应运营阶段发现的用户需求
制定改进计划不超过 5 条改进项，每条有责任人、预估工作量（session 数）和截止日期自动执行 → 需用户确认[Google OKR] 改进项 = 下一轮的 KR；每个 KR 有量化目标
资源评估总预估工作量不超过下一轮可用资源的 80%，留 20% 缓冲应对意外自动执行[Amazon] 规划必须诚实——塞不下的就不要塞，延期比做一半强
更新计划跟踪表改进项按任务格式进入下一轮跟踪（含 task ID、优先级、依赖）自动执行通用实践

4. 版本化更新

活动描述交互边界企业实践
更新版本记录版本号、日期、变更说明自动执行[Google] 语义化版本——维护更新也遵循 semver
更新 CHANGELOG汇总本轮所有变更自动执行[Google] CHANGELOG 是写给用户看的，不是写给机器看的
更新样例总览统计数据重新计算（总任务数/已完成/阻塞中/风险数）自动执行通用实践
归档本轮资产复盘文档、改进计划、经验提炼纳入版本管理自动执行[Google] 复盘和历史版本一样可追溯、可审计

5. 技术债务盘点

活动描述交互边界企业实践
识别技术债代码中哪些地方在拖慢开发速度：硬编码、重复代码、过时依赖、缺少测试的模块、架构妥协自动执行：静态扫描 + 代码审查[Google] 技术债必须显式记录——不可见的债不会被还
评估偿还优先级按"影响开发频率 × 修复代价"排序自动执行 → 需用户确认[Amazon] 不是所有技术债都值得现在还——只还"继续拖下去代价更高的"
纳入改进计划高优先级技术债纳入下一轮改进计划自动执行 → 需用户确认[华为] 技术债是改进计划的一等公民——不是"有时间再说"

6. Bug 修复与回归测试积累

活动描述交互边界企业实践
回归测试积累每次 Bug 修复 MUST 执行以下至少一项：(a) verify_workflow.py 新增检查项（如可行）；(b) infra/tests/ 中新增测试用例；(c) infra/tests/e2e/ 中新增端到端场景。目标：每个已修复的 bug 都有自动化回归覆盖自动执行[Google] 每个 bug fix 必须有对应的回归测试——不靠人记着"下次别犯"，靠机器拦住

产出物标准

产出物格式要求质量标准企业实践来源
复盘文档目标回顾（量化达成度）+ 结果评估（好/不好各 ≥3 条+具体例子）+ 根因分析（≥1 个 5-Why）+ 经验沉淀 + 改进计划每部分有实质内容；"做得不好"无模糊词[华为 RCA] + [Google Blameless]
改进计划≤5 条，每条有责任人、预估工作量（session 数）、截止日期总预估 ≤ 下一轮资源的 80%；每条可独立验证[Google OKR] + [Amazon]
资产更新记录哪些文件被更新、更新了什么、为什么更新与 git 提交记录对应；每个更新有"为什么"[ByteDance Context]
技术债清单≥3 条已知技术债，标注严重度、影响频率和偿还代价优先级排序清晰；高优先级已进入改进计划[Google] + [Amazon]

退出条件

  • 复盘已完成（目标回顾量化 + 好/不好各 ≥3 条具体例子 + 根因分析 ≥1 个 5-Why）
  • 经验已回灌到规则和模板（有对应的 git 提交记录，验证脚本通过）
  • 下轮方向已明确（计划跟踪表中有 ≥1 条 P0 任务）
  • 版本化记录已更新（版本号、CHANGELOG、样例总览）
  • 技术债务已盘点（≥3 条，有严重度和优先级排序）

Gate 映射

本阶段对应 G11 — 维护闭环。

Gate 检查项对应活动判定标准自动化判定
是否完成复盘？复盘执行复盘文档存在，包含：目标回顾（量化达成度）+ 好/不好各 ≥3 条具体例子 + 根因分析（≥1 个 5-Why）可自动：检查文档结构完整性 + 条目计数 + 模糊词扫描（基本/大致/总体）
经验是否回灌到规则和模板？经验回灌规则/模板有对应的更新提交记录；验证脚本通过可自动：git log 检查 + 验证脚本执行
下轮方向是否已明确？下轮规划下一轮方向在计划跟踪表中有 ≥1 条 P0 任务可自动：检查 plan-tracker 中 P0 条目
版本化记录是否已更新？版本化更新manifest 或样例总览中的版本/日期字段已更新可自动：检查版本字段 + CHANGELOG 更新
改进计划是否可执行？下轮规划≤5 条改进项，每条有责任人和截止日期；总预估 ≤ 资源的 80%可自动：计数 + 字段完整性检查
技术债务是否已盘点？技术债务盘点≥3 条已知技术债，有严重度和优先级排序可自动：计数 + 字段完整性检查

企业实践溯源

本子工作流的设计参考了以下企业实践，每条实践已映射到具体活动步骤：

企业核心实践映射到本工作流
华为RCA 5-Why 根因分析复盘执行→关键问题深度追溯，追到流程/机制层面
华为自我批判（"做得不好"必须具体）复盘执行→"做得不好"不得使用模糊词，必须有具体事例
华为IPD 经验回灌（转化为可执行规则）经验回灌→经验必须转化为检查项/模板字段/Gate 规则
GoogleBlameless Postmortem（聚焦流程改进）复盘执行→复盘聚焦"流程怎么改进"而非"谁犯了错"
GoogleOKR（量化 KR + 可追溯）下轮规划→改进项 = 下一轮的 KR
Google技术债显式管理技术债务盘点→不可见的债不会被还
AmazonWorking Backwards（下轮方向回应运营发现）下轮规划→方向必须回应运营阶段发现的用户需求
Amazon诚实规划——塞不下就不塞下轮规划→总预估 ≤ 资源的 80%
Amazon区分适用边界经验回灌→区分"本项目特有"和"可跨项目复用"
ByteDance数据驱动——复盘也必须用数据说话复盘执行→目标达成度必须有数字
ByteDanceContext not Control（记录"为什么改"）经验回灌→更新资产时记录上下文

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free