AI工作流的元迭代：如何审查和改进你自己的AI协作工作流

“工具越强，工具本身的管理越重要——你用AI写得越快，如果你的工作流有缺陷，你只是在更快地制造问题。“

核心观点 / 起源

一段让我后背发凉的对话

几个月前，我和朋友聊到用AI编程的体验。他用了某款AI编码助手半年，突然说了一句：

“我发现很多配置还是半年前刚装的，有些Skill我甚至不知道什么时候装的，也不知道该不该删。”

我说，这不就跟你从来不重构的代码一样——能跑，但没人敢动？

他愣了一下，然后苦笑。

我也笑不出来，因为我意识到：我自己也在犯同样的错误。

我引以为傲的Claude Code工作流——Hook系统、CLAUDE.md、Memory、各种Skill——看起来井井有条，但它真的在持续进化吗？还是说，它只是比别人的整洁，但自身已经几个月没被审视过了？

这就像你的代码需要重构，你的依赖需要升级——你的AI协作工作流，也需要被审查。

为什么要审查工作流本身

我们很容易陷入一个陷阱：用AI越顺手，越不会回头怀疑流程本身。

我们用AI写代码、做审查、管项目、写文档——然后用AI的效率证明这套流程”行之有效”。但这个推理链条有一个盲区：

流程有效 ≠ 流程最优

更危险的是，AI工具本身在快速进化。你三个月前建立的工作流，可能已经存在更好的替代方案——但因为你没去检查，你一直用着旧方案，还以为这是”最佳实践”。

所以我决定做一个实验：像审查代码一样，审查我自己的AI协作工作流。

过程 / 推演

审查框架：7维成熟度模型

没有框架的审查是漫无目的的。我设计了一个7维度的成熟度模型，覆盖AI协作工作流的完整生命周期：

这7个维度不是拍脑袋想的。它们对应着AI协作中最常翻车的地方：

• 质量护栏管的是”AI生成了有问题的代码”
• 规范固化管的是”同一个坑反复踩”
• 测试闭环管的是”改了A坏了B”
• 权限体验管的是”人机交互的摩擦成本”
• Memory鲜活度管的是”AI记住的是过时的信息”
• CI/CD管的是”协作的工程化程度”
• 跨语言覆盖管的是”多语言项目的质量死角”

实操五步法

有了框架，怎么用？我总结了一个五步迭代流程：

发现缺口 → 排优先级 → 实施改进 → 写入记忆 → 输出文章

发现缺口：逐维度检查，记录每个维度的现状

排优先级：按P0→P1→P2分类

• P0：必须修复（安全、数据丢失、测试断裂）
• P1：效率损失（权限弹窗多、流程卡顿）
• P2：锦上添花（体验优化、格式美化）

实施改进：动手改，一个维度一个维度来

写入记忆：把改进后的方法论沉淀到Memory，下次不再从头思考

输出文章：把审查过程本身变成知识资产

关键：这五步是循环的。完成一轮后，下个月再来一轮。

实战记录：一次完整的工作流审计

说干就干。我对自己当前的工作流做了逐项分析。

审查结果

代码质量护栏 — A+ 这是我的强项。PreToolUse + PostToolUse 双层Hook，写入前AST验证，写入后black→autopep8→ruff→py_compile自动格式化链，任意阶段失败有备份回滚。这几乎达到了”纠错不改错”的级别。

规范固化 — A CLAUDE.md记录了YAGNI决策梯子、Ponytail原则，结构清晰。Memory系统也在用。但——超过一整月没有更新了。

测试闭环 — C 这是最大的缺口。修改完代码后，我有质量验证，但没有测试验证。改完代码AI不会自动跑测试确认没问题，完全依赖我手动执行。在”改了A坏了B”的场景里，这个缺口是致命的。

权限体验 — B- 所有操作走统一的权限弹窗。read-only的读文件、搜索也要确认。这虽然是安全考虑，但的确增加了摩擦。

Memory鲜活度 — C MEMORY.md的最后一条记录已超过一个月以上。这意味着AI记住了我的旧习惯，记不住我的新变化。

CI/CD — D 没有配置。这是一个需要填的大坑。

跨语言覆盖 — C 只有Python有完整的质量护栏（determystic validate + Hook）。如果涉及TypeScript/JavaScript项目，没有对应的检查链。

改进实施

我立刻动手改了最能改的部分。

追加测试验证闭环到CLAUDE.md：

## 测试验证闭环

修改代码后，必须自动运行相关测试来验证正确性：

1. **新建测试文件** → `pytest <test_file> -x -q`
2. **修改业务代码** → `pytest tests/ -x -q --tb=short`
3. **重构/大规模修改** → `pytest --cov=<module> --cov-fail-under=80`

追加TS/JS质量要求：

npx tsc --noEmit           # 类型检查
npx eslint src/            # lint
npx vitest run             # 单元测试

追加Memory维护规则：

明确什么该写（有效的工作模式、值得记录的项目决策）、什么不该写（代码结构本身、临时讨论），以及维护节奏——每月至少检查一次。

运行 fewer-permission-prompts：

这个Skill可以扫描历史transcript，把read-only的常见操作自动加入白名单，减少权限弹窗。虽然因为服务波动暂未完成，但这是P1待办。

沉淀到Memory

我把工作流审查的方法论本身写成了Memory条目——这样AI以后也会记得这套审查体系，遇到类似问题时会主动调用。

---
name: workflow-review-process
description: 定期用 project-compass 审查工作流成熟度
metadata:
  type: feedback
---
**Why:** 工作流需要持续进化
**How to apply:** 每月对照7维度做自检

一点补充

这一套框架的核心约束是：它是元迭代，不是一次性审计。

你做完第一次审查，发现了漏洞、修复了漏洞——但这只是起点。下个月再查，可能发现之前的”改进”已经过时了，或者出现了新的缺口。这个模型真正的力量，来自重复循环的过程，而不是单次的满分。

结语 / 反思

最后说一个反常识的观察。

你可能觉得花时间审查工作流是在”降低效率”——本来可以直接用AI写代码，你非要去审查流程。但我想说的是：工具越强，工具本身的管理越重要。

你用AI写得越快，如果你的工作流有缺陷，你只是在更快地制造问题。

代码要重构，依赖要升级，你的AI协作工作流也需要。

附：7维度检查清单（可复制使用）

## 工作流自检清单

【代码质量护栏】
[ ] Hook系统是否正常运作？
[ ] 覆盖了项目使用的所有语言吗？
[ ] 失败时有回滚机制吗？

【规范固化】
[ ] CLAUDE.md是否反映了当前的约定？
[ ] Memory中是否有过时条目？
[ ] 最近一次更新是什么时候？

【测试闭环】
[ ] 修改代码后会自动跑测试吗？
[ ] 测试失败会阻止提交吗？
[ ] 覆盖率有阈值要求吗？

【权限体验】
[ ] read-only操作是否需要每个都确认？
[ ] 是否有白名单/分层管理？

【Memory鲜活度】
[ ] 最近一个月有写入新Memory吗？
[ ] 过时的Memory有被清理吗？

【CI/CD】
[ ] 有持续集成管道吗？
[ ] PR会触发质量检查吗？

【跨语言覆盖】
[ ] 所有项目语言都有对应的质量护栏吗？