开源项目 zcf 的解读，特别是它的六阶段工作流

一句话判断：ZCF 不是新的 AI 编程引擎，而是一个面向 Claude Code 与 Codex 的“配置管理器 + 工作流模板分发器”。它的六阶段工作流本质上是一份纪律性很强的提示词 SOP，不是具备持久状态、自动门禁和失败恢复能力的工作流引擎。

项目在做什么

运行 npx zcf 后，它主要帮助用户统一配置：

• Claude Code / Codex 的全局配置。

• 官方登录、API Key、第三方 API 和 Claude Code Router。

• MCP 服务，如 Context7、网页搜索、DeepWiki、Playwright、Serena。

• 六阶段、Feat、Git、BMAD 等工作流 Skills。

• 输出风格、全局提示词、用量统计和配置备份。

所以它的核心价值是“降低 AI 编程工具的配置门槛”，而不是增强模型本身的推理或编码能力。项目文档、CLI 实现

代码结构也比较直接：TypeScript CLI、配置读写模块、交互式菜单和大量模板文件；六阶段工作流最终通过 Skills CLI 安装到 Claude Code/Codex。工作流安装器、Skills 安装器

六阶段实际怎么工作

实际模板比文档描述更严格：中文 Workflow Skill

它还有两个很强的规则：

1. 计划未经用户批准不得执行。

2. 几乎每个阶段、每次收到反馈后都要再次请求确认，直到用户明确说“结束”。

优点

1. 有效抑制 AI 过早写代码

“先理解、再选方案、再计划”能减少需求还没弄清楚就大改代码的问题，尤其适合跨模块功能、架构改造和复杂重构。

2. 人在回路中的控制比较强

研究、构思、计划、优化、最终完成都有确认点。对于高风险修改，用户有较多机会纠偏，而不是等 AI 一口气改完才发现方向错误。

3. 计划可以落盘和追踪

.zcf/plan/current 和 .zcf/plan/history 比只依赖聊天上下文可靠，方便长任务恢复、团队评审和事后复盘。六阶段文档

4. 强迫模型考虑备选方案

“至少两个方案”可以降低模型过早锁定第一个想法的概率，对技术选型、数据迁移和兼容性改造尤其有价值。

5. 易于理解和定制

它只是一个 Markdown Skill，团队可以直接修改阶段、输出格式和确认规则，不会被专有编排平台锁定。

主要缺点

1. 它不是严格意义上的工作流引擎

阶段状态主要靠模型遵守提示词维持，没有程序化状态机、结构化阶段输出、自动校验或事务机制。模型可能跳步、忘记归档，或者在长上下文中发生漂移。

2. 确认机制过度

“任何回复后都再次请求确认”很容易形成确认疲劳：

• 简单任务也要经过多轮对话。

• Token、时间和交互成本明显增加。

• 用户最后可能习惯性点击同意，反而失去真正的质量门禁。

保留“计划批准”和“高风险写操作批准”即可，没必要每个阶段都确认。

3. 缺少硬性的验证门禁

实际 Skill 没有强制要求执行具体的：

• 单元测试、集成测试；

• lint、类型检查、构建；

• 安全扫描；

• 性能基准；

• 验收标准逐项验证。

因此“完成了评审”不等于代码真的通过 CI。它更像模型的自我评价，而不是可重复验证。

4. 评审缺少独立性

配置中六阶段工作流的 agents 是空数组，没有单独的规划者、测试者或审查者；通常是同一个模型在同一上下文中实现后再审查自己，容易产生确认偏差。工作流配置

5. 流程过于线性

真实开发经常是：

执行发现前提错误 → 回到研究/方案 → 修改计划 → 再执行

而模板强调“严格按计划执行”，却没有明确的偏差阈值、变更记录和重新审批机制。计划一旦过时，模型只能选择机械执行或临时偏离。

6. “每次都优化”可能制造无效改动

优化阶段只检查“本次对话产生的代码”，可能忽略系统级影响；同时，无论是否存在性能问题都要求进入优化，容易出现为了优化而重构、扩大 diff、引入回归。更合理的顺序应当是：

执行 → 验证 → 有证据时优化 → 再验证 → 评审

7. 对简单任务性价比低

修拼写、改单个配置、明确的一行 Bug，都要求研究、两个方案、详细计划和优化，流程成本可能大于任务本身。

8. 有一些跨平台和供应链细节需要注意

工作流要求用 Bash 的 date +... 获取时间，在原生 PowerShell/Codex 环境中未必直接可用。另外，多项 MCP 配置使用 npx -y package@latest，方便但不利于版本锁定和可重复安装。MCP 配置

ZCF 的完整 Codex 备份还会复制除 backup/tmp 外的整个 .codex 目录，因此可能同时复制 auth.json；备份虽然有利于恢复，但也增加了凭据副本，需要注意本机权限和清理策略。备份实现

适用判断

比较适合：

• 需求尚不清楚的中大型功能。

• 跨模块重构、架构调整、技术选型。

• 希望深度参与方案决策的个人开发者。

• 缺乏成熟研发流程、希望先建立基本纪律的小团队。

不太适合：

• 小 Bug、机械修改、紧急故障处理。

• 已有严格 RFC、Issue、CI、Code Review 流程的成熟团队。

• 需要并行多 Agent、自动恢复和无人值守执行的场景。

• 对构建可重复性和依赖版本锁定要求严格的企业环境。

我的综合评价

• 作为 Claude Code/Codex 的一键配置工具：8/10。

• 作为复杂任务的可选提示词模板：7.5/10。

• 作为所有开发任务的默认强制流程：5.5/10。

• 作为真正的自动化工作流引擎：不够，它还停留在 Prompt/SOP 层。

最值得借鉴的是“需求评分、方案比较、计划落盘、执行前批准”；最需要修改的是“无限确认、缺少硬验证、同模型自审、所有任务固定六阶段”。如果把它改成按任务复杂度选择三阶段/四阶段/六阶段，并把测试和 CI 设成真正的硬门禁，实用性会明显提高。