企业官网建设流程全解析

用 AgentFlow 把 Kanban 看板变成自治 AI 开发流水线：从 SPEC 拆分到多 Worker 编排的完整实践

【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,600+ agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址: https://gitcode.com/GitHub_Trending/an/agentic-awesome-skills

AgentFlow 是 AAS（agentic-awesome-skills）技能库中一个面向 Claude Code 的自治开发流水线技能：它不做任何自定义编排基础设施，而是把 Asana、GitHub Projects、Linear 这类项目管理工具的看板当作一个分布式状态机，让多个 AI Worker 通过评论读写状态、跨阶段流转任务，人则用拖拽卡片的方式随时接管。读完本文，你将掌握从编写 SPEC.md、用/spec-to-board拆解任务、并行启动 3–4 个 Worker，到配置 crontab 驱动的无状态编排器、借助确定性质量门禁与对抗性评审保障代码质量，以及通过成本追踪、心跳检测与自动回滚实现崩溃可恢复的完整实战方案。

何时应该使用 AgentFlow

在动手编排之前，先判断场景是否匹配。AgentFlow 的适用边界非常清晰（技能元数据 中source: community、risk: safe，已加入 AAS 目录索引 skills_index.json 且仅标注claude: supported、codex: blocked），满足以下任一条件即可考虑引入：

• 需要在一个完整开发生命周期（构建、评审、测试、集成）内编排多个 Claude Code Worker；
• 希望在 AI 生成代码进入 AI 评审之前，先由tsc、eslint、测试等确定性门禁兜底，用近乎零成本拦下约 60% 的问题；
• 希望从看板或手机上获得全流水线可视性，而不是依赖某个进程内面板；
• 个人或团队项目需要自主任务派发，且对每次任务的花费有追踪要求；
• 需要能在会话重启后继续运行的“防崩溃”编排——状态不落在内存里，而是落在项目管理工具中。

需要特别说明：AgentFlow 当前在 AAS 中属于uncategorized类别，plugin.targets记录其 Codex 目标为blocked（原因target_specific_home_path），因此本文的安装与运行均以 Claude Code 环境为前提。

核心设计：五个关键概念

AgentFlow 的整套设计可以浓缩为五个彼此咬合的概念，理解它们之后再读后面的操作步骤会顺畅得多。

七阶段看板流水线（7-Stage Kanban Pipeline）

任务在看板列之间流转：Backlog → Research → Build → Review → Test → Integrate → Done，每个阶段都有对应的门禁。关键约束是看板本身就是编排层——没有独立数据库、没有消息队列、没有自定义基础设施。任务通过评论携带上下文（retry context），评论就是它的持久化存储。

无状态编排器（Stateless Orchestrator）

编排不是常驻守护进程，而是一个由 crontab 驱动的一次性扫描（one-shot sweep），默认每 15 分钟跑一次。由于全部状态都存放在项目管理工具里，进程崩溃后下一次扫描会从上次断点继续，天然获得免费崩溃恢复。

确定性先于概率性（Deterministic Before Probabilistic）

硬门禁（tsc+eslint+ 测试）先于任何 AI 评审执行，在近零成本下捕获约 60% 的问题；AI 评审作为第二层防线随后介入。这一顺序决定了成本与质量的基本盘。

对抗性评审（Adversarial Review）

由另一个 AI 智能体评审代码，并且必须先列出 3 个问题才能决定放行。这从机制上杜绝了“橡皮图章式”的走过场审批。

传递式优先级派发（Transitive Priority Dispatch）

任务按“解除下游阻塞最多者优先”的顺序被构建，从而自动计算关键路径（critical path）。也就是说，被最多后续任务依赖的任务最先被执行，整体交付时间最短。

命令一览：五个斜杠命令

AgentFlow 的全部控制面只有五个斜杠命令，职责划分清晰：

分步实战：从 SPEC 到落地的完整流程

第一步：编写 SPEC.md

任何项目开始前，先写一份清晰的SPEC.md，描述你想构建什么。它是后续拆解与派发的唯一事实来源，也是避免范围蔓延和规格漂移的基准。

第二步：拆解为任务

在项目目录下执行：

claude -p "/spec-to-board"

该命令读取你的SPEC.md，将其分解为原子任务，映射依赖关系，并在看板上创建对应的任务卡片。

第三步：并行启动 Worker

打开 3–4 个终端窗口，每个作为一个 Worker 槽位：

# 终端 2 — 构建者 claude -p "/sdlc-worker --slot T2" # 终端 3 — 构建者 claude -p "/sdlc-worker --slot T3" # 终端 4 — 评审者 claude -p "/sdlc-worker --slot T4" # 终端 5 — 测试者 claude -p "/sdlc-worker --slot T5"

注意：Worker 的角色（构建/评审/测试）取决于它领取到的是哪个阶段的任务，槽位编号（--slot T2等）用于区分不同 Worker 的心跳与归属。

第四步：启动编排器

# 编辑 crontab crontab -e # 添加一行（每 15 分钟运行一次） */15 * * * * ~/.claude/sdlc/agentflow-cron.sh >> /tmp/agentflow-orchestrate.log 2>&1

编排器以一次性扫描的方式运行，日志写入/tmp/agentflow-orchestrate.log便于排障。

第五步：监控与人工介入

打开手机上的看板，观察任务在流水线中流转。需要人工干预时，直接把任意卡片拖到 “Needs Human” 列即可；也可以在终端运行/sdlc-health查看实时仪表盘。

第六步：停止流水线

claude -p "/sdlc-stop"

Worker 会先把手头任务收尾（drain），未开始的任务自动退回 Backlog，实现优雅关闭。

质量门禁：每个阶段的晋升条件

任务只有通过对应阶段的门禁才能晋级：

• Build → Review：tsc+eslint+npm test全部通过（确定性门禁）；
• Review → Test：对抗性评审者必须列出 3 个问题才能放行；
• Test → Integrate：新文件测试覆盖率 ≥ 80%；
• Integrate → Done：合并后在 main 上跑全量测试套件，失败自动回滚。

这一设计与 AAS 库中其他质量导向技能一脉相承，例如 tdd-orchestrator、spec-driven-development 都强调“先确定性、后智能体”的校验顺序，AgentFlow 把同样的哲学搬到了多 Worker 流水线层面。

成本追踪与护栏

AgentFlow 为每个任务提供分阶段成本追踪，默认采用 Sonnet 的阶段性上限：

在此基础上还有自动护栏：累计成本达到 $3/$8（Sonnet/Opus）时告警，达到 $10/$20（Sonnet/Opus）时硬性停止并升级到人工处理。任务卡片上的COST:CRITICAL标签即由该机制触发。

安全与恢复机制

AgentFlow 的“防崩溃”并非单一手段，而是一组互相补充的机制：

• 自动回滚：集成失败触发git revert（产生新提交，绝不 force-push 到 main）；
• 阻塞升级：任务失败 2 次后自动升级到人工评审；
• 死智能体检测：每 5 分钟一次心跳，超过 10 分钟超时即重新指派；
• 优雅关闭：/sdlc-stop排空 Worker，未开始任务退回 Backlog；
• 范围蔓延检测：PR 的 diff 文件列表与预测文件列表比对；
• 规格漂移检测：对 SPEC 做 SHA-256 哈希比对，捕捉 sprint 中途的需求变更。

其中“状态与重试上下文都写在看板评论里”这一点，是上述全部机制成立的前提：新接手的 Worker 通过评论读到“之前试过什么、为什么失败”，而不是从零开始。

安装方式

# 克隆仓库 git clone https://github.com/UrRhb/agentflow.git # 把 skills 和 prompts 复制到 Claude Code 配置目录 cp -r agentflow/skills/* ~/.claude/skills/ cp -r agentflow/prompts/* ~/.claude/sdlc/prompts/ cp agentflow/conventions.md ~/.claude/sdlc/conventions.md

或者以 Claude Code 插件方式安装：

/plugin marketplace add UrRhb/agentflow /plugin install agentflow

在本仓库中，该技能同时收录于 skills/agentflow/SKILL.md 与 Claude 专用插件目录 plugins/agentic-awesome-skills-claude/skills/agentflow/SKILL.md，两份内容一致，可按你的 AAS 使用方式（单技能或插件）直接启用。

最佳实践

应当做的：

• 运行/spec-to-board之前务必写好清晰的 SPEC.md；
• 典型项目从 3–4 个 Worker 起步；
• 从看板持续监控，需要介入时把卡片拖到 “Needs Human”；
• 定期复盘LEARNINGS.md——它沉淀了常见的失败模式。

应当避免的：

• 跳过确定性质量门禁——它们以最低成本拦截了大多数问题；
• 对 main 使用 force-push——AgentFlow 的安全模型建立在git revert之上；
• 启动超出项目并行能力的 Worker 数量，过多并行只会带来冲突与浪费。

故障排查：三个高频问题

问题一：Worker 疑似卡死

症状：任务卡片 15 分钟以上未移动，且没有新评论。解法：编排器通过心跳检测死智能体，超过 10 分钟会重新指派。若仍未恢复，运行/sdlc-health查看状态，并手动把卡片拖回 Backlog。

问题二：成本护栏被触发

症状：任务被移到 “Needs Human”，并带有COST:CRITICAL标签。解法：阅读任务评论线程中累积的上下文，决定是提高预算、简化任务，还是把任务拆成更小的碎片。

问题三：合并后集成测试失败

症状：任务被自动从 main 回滚。解法：自动回滚保证了 main 的稳定性。查看任务评论中的重试上下文（此前尝试了什么、为何失败），下一位被指派的 Worker 会直接使用这份上下文继续。

相关联的技能

• @brainstorming（见 skills/brainstorming/SKILL.md）：在运行 AgentFlow 之前用它设计你的 SPEC.md；
• @writing-plans（见 skills/writing-plans/SKILL.md）：与规格编写互补，辅助任务分解；
• @test-driven-development（见 skills/test-driven-development/SKILL.md）：与 AgentFlow 的质量门禁配合良好；
• @subagent-driven-development（见 skills/subagent-driven-development/SKILL.md）：多智能体协作的另一种编排思路，可作为对比方案。

局限与边界

• 仅当任务与上述场景明确匹配时才使用本技能；
• 输出不能替代针对具体环境的验证、测试或专家评审；
• 当缺少必要输入、权限、安全边界或成功标准时，应停下并请求澄清，而不是强行推进。

【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,600+ agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址: https://gitcode.com/GitHub_Trending/an/agentic-awesome-skills