企业官网建设流程全解析

项目地址：
https://github.com/TreeX-X/WorkFlowX

为什么做这个项目

作为探索AI领域的一名从业者，Superpowers、OMC 这些开源工作流都上手试过。它们各自有很优秀的设计，但我在实际工作中用的始终有点不顺手。

首先就是一个需求扔进去，不知道底部流转机制经历了什么，每一次消耗的token和需求的大小有时候没有直接关系。

而且我觉得spec的思想是重要的，不仅仅是AI生成更好，而是开发过程有了沉淀，真实项目要维护、要复盘，不能就是地单纯让AI修改生成。

vibe-coding是一种很爽的过程，但正经干活时，我还是希望开发者能够在AI开发的流程中进行介入，而不是让他自己一股脑的跑完。

针对上面的几个问题，我决定开发一个需求能追踪、质量能审计、Token利用率高的工作流，让开发者能够在全自动半自动的流程中随时介入。

WorkFlowX 是什么

作为一个多智能体协作的开发工作流框架，我设计的核心思路来源于Anthropic 研究里提的 Harness Design，通过标准化的流程，用文档机制去约束我们的Agent去按照一个约束去进行工作。

我依赖了主流Agent工具都具备的一个功能"runSubAgent",设计了一个主智能体
orchestratorX 做路由和编排，以及对应调度的子智能体：

• orchestratorX— 主编排者，管路由、文档、任务分发和迭代控制
• promptMasterX— 把用户的输入理清楚，减少歧义和 prompt 里的坑
• coderX— 写代码，遵循最小实现原则
• evaluatorX— 独立审计代码，不听 coderX 自己说"我写完了"
• abstracterX— 做代码结构分析和工程总结

为什么用子智能体？因为每个子智能体有独立上下文，不会被前面的对话污染。这样每个 Agent 都是在理论能力最强的状态下干活，出来的代码质量会稳定很多。
WorkFlowX可以按照需求大小分为三种模式，不会啥需求都走同一套重流程：

核心机制：xwhole 完整工作流

在本次中我主要介绍xwhole，它框架的完整工作流，其他的工作流都是其分解出的一部分

开发者在提出一个模块开发或者需求时，不会马上开始写代码，而是先走规划，这有点像传统的"plan"模式，但是我们进行了特殊设计

首先工作流会进行苏格拉底式的提问，不断将你的需求提问，直到理解明白，并且会在分析需求的时候，合理的提出方案和不合理的地方，反馈你修正，到最后只会留下我们交流中确认的需求

需求确认后，就会开始生成一个工作流中很核心的一部分，我命名为Hybrid Tree，工作流把需求拆分为需求树，Parent文档记全局目标、范围、非功能要求、路由表；Child文档记具体子任务、验收标准、涉及的文件、评估结果

通过这个结构，后续子智能体干活的时候，就不需要整个项目上下文都吞一遍，通过父文档路由到对应的子文档，只读当前任务真正需要的东西

另外规划阶段会提前把项目探索一遍，相关文件、关键实体、依赖关系记到文档和临时记忆里。后面 coderX 和 evaluatorX 不用每次从零开始搜项目，Token 自然就省下来了

从需求到代码，再到评估

Hybrid Tree 建好之后，这里我还是采纳了Anthropic 研究里提到的生成对抗网络(GANs)的思路，让生成过程变成一个不断迭代的过程

首先，orchestratorX 把子任务分给 coderX，coderX 的工作很明确：读文档、读验收标准、写最小必要实现。我给它引入了Karpathy 那套工程观 —— 别过度设计，别为了显得高级而搞复杂，用最短路径解决真问题

代码写完，不会让 coderX 自己评价自己。这是很多 AI 工作流的通病：同一个 Agent 既实现又评估，它天然倾向于觉得自己做得不错

所以评估交给了 evaluatorX，一个完全独立的审核 Agent，只读读需求文档和验收标准，只看git diff 和相关代码，不了解coderX 的自我声明，根据逐条AC 判 pass / partial / fail / unevaluable，然后输出问题清单、严重级别、修复建议

没过的话，orchestratorX 把 evaluatorX 的意见扔回给 coderX 改。每个 Child 有迭代上限，不会无限循环；evaluatorX 判 PASS 就提前收工，不白烧 Token

Token 优化怎么做的

首先就是工作流的分级，根据不同的需求，使用不同的流程，合理分配

然后就是依赖Hybrid tree机制，将需求分散，每次只给 Agent 当前子任务需要的文档，不灌全量，并将关键文件和知识点沉淀下来，后面按需加载

在迭代过程中，我设计了增量评估，evaluatorX 这轮只看 diff、失败的 AC 和相关文件，不每轮都重新吞一遍全量上下文；我还在评估中设计了早退机制，让任务完成了，就不会一直继续迭代，而是直接停止

目标不是把 Token 消耗干到零，而是让它透明、可控、花得明白

和别的工作流有啥不一样

Superpowers 侧重工程习惯和自动化体验，OMC 侧重工具调度、多模型协作和专业 Agent 覆盖。WorkFlowX 选了另一个方向：需求追踪、质量审计、结构化迭代、Token 可控

几个独有的特点：

• Hybrid Tree 做需求追踪，需求从哪来到哪去都能查
• AC 交叉验证，不是 coderX 说了算
• orchestratorX 是唯一写文档的人，避免多 Agent 写出冲突
• coderX / evaluatorX 职责分离，实现的人不评估
• 人可以在任意节点介入、确认、审阅
• 按任务规模选不同工作流，不一刀切

现在还不完美的地方

作为作者，我自己都知道WorkFlowX距离完全成熟的工作流还有一定的距离

没有一个专业的安全审查机制，TDD机制也是没有的，不同语言和框架的审核可以做的更好，并行工作流和调度还有细节要打磨，文档可视化也有优化的控件

但即使如此，作为一个以需求为切入点、强调人为可控和 Token 效率的工作流，我觉得它现在到了可以拿出来让人真实试用、给反馈的阶段

接下来的更新计划

一个是ultra参数模式，参考二级路由能力，可能引入 HTML 结构替代部分 Markdown，做一个更重型但能力更强的模式

另一个是把安全审查做得更系统，吸收 OMC 里 security-review 的好思路，但保持 WorkFlowX 自己的结构化风格

还有一个方向是参考 Karpathy 最近提的 autoresearch，让模型反过来分析和优化工作流本身，从真实使用里挖升级点。跑通了会继续分享

最后
如果你用 AI 开发的时候也碰到过这些：

• 需求聊着聊着就丢了
• AI 写完代码，不知道是不是真的满足了要求
• Token 花了不少，但不知道花在哪
• 想自动化，但不想完全失去控制
• 希望开发过程能留下点什么，以后维护用得上
• 希望你能来试试WorkFlowX

欢迎提 issue、PR，或者直接在帖子里说想法。觉得有帮助的话，顺手点个 star 也行

项目地址：
https://github.com/TreeX-X/WorkFlowX