在过去一年的 AI Coding 实践中，天玑前端团队经历了一个明显的瓶颈期。

早期我们沉浸在 Vibe Coding（氛围编码）的快感中——通过简单的对话、截图，AI 确实能飞快地生成页面。但随着需求进入深水区，这种模式的弊端开始显现：由于缺乏标准化约束，AI 生成的逻辑往往是“碎片化”的。面对中后台复杂的表单联动、嵌套的数据转换，AI 经常在多轮对话后开始“左右互搏”，导致开发者不得不陷入反复纠错的泥潭。

我们意识到，AI 效率的波动，本质上是上下文断层和需求共识缺失导致的。

随着业界向 Spec-Driven Development (SDD) 演进，大家开始达成共识：AI 不缺代码实现能力，缺的是精准的“指令规格”。我们需要一套流程，能把模糊的需求拆解成机器可理解的“契约”，并让 AI 在每个阶段扮演特定的专家角色（如架构师、测试员），以此来对冲个体经验带来的不确定性。

在构建我们自己的标准流之前，我们深入拆解了目前业界主流的三种规格驱动方案。它们代表了对“复杂任务拆解”的三种不同理解：

OpenSpec：“轻量级、面向变更的敏捷利器”

核心点：它非常推崇“原子化变更”。通过 Proposal（提案）和 Apply（实施）的闭环，把大的功能拆解成小的变更包。

GitHub Spec Kit：“工业级、标准化的协作协议”

核心点：极其强调“先写规格，再写任务”。它通过 Constitution（宪章）定义技术底线，确保 AI 生成的代码风格不走样。

启发：它给我们的启示是“门控”。如果需求阶段（Specify）没对齐，后续的编码（Implement）就是南辕北辙。

BMAD-METHOD：“全能型、多代理协作的工程框架”

核心点：它不再把 AI 当成一个简单的助手，而是模拟一个完整的专家团（PM、架构师、QA）。

启发：在复杂场景下，必须引入“角色思维隔离”。让 Plan 阶段像架构师一样思考，而不是一边写设计文档一边就想写代码。

为什么我们决定“集百家之长”？

调研完这些工具后，我们发现它们在 Cursor 等现代 IDE 中依然存在一些“摩擦力”：

• 心智负担重：有些流程需要开发者频繁切换文件、手动同步状态。

• 状态易丢失：在多轮对话中，AI 容易忘记最初在 spec.md 里定下的技术方案。

因此，我们决定吸收 OpenSpec 的轻量、Spec Kit 的严谨和 BMAD 的多角色思维，自研一套深度适配 Cursor 的AI研发流（Agentic Workflow）——Specflow。

方案设计：重塑 AI 研发的“流水线”

三种工具各有所长，为了满足自身业务需要，决定不采用任何社区方案，集各家所长建设适用于当前团队的 规格驱动开发（Spec-Driven Development, SDD）方案——Specflow。

整体架构

全链路流程闭环：从“模糊”到“可交付”

不同于只关注编码的工具，Specflow 强制要求在进入代码阶段前完成深度的“需求对齐”。

• 问题澄清（Specify）：在产品文档确认后，AI 会优先识别逻辑漏洞和边界盲区，通过“问题澄清”环节强制补全细节，产出完善的业务规格书。

• 技术建模（Plan）：将业务规格映射为技术路径，包含接口定义与任务拆解，确保每一行代码都有据可查。

• 原子化实现（Implement）：基于任务组进行分步开发，并引入“人机协同”的断点 Review 机制。

严格的物理门控：拒绝“带病”进入开发

这是 Specflow 区别于社区方案的核心纪律。

• 逻辑阻断：我们引入了硬性门控（Blocker Gate）机制。如果 Specify 阶段的细节未澄清，或者 Plan 文档中的技术风险（Block 项）未被回答，流程将强制停顿。

• 确定性保障：这种设计迫使开发者“先想清楚，再写清楚”，严禁跳过设计直接编码，从而在根源上消灭了因理解偏差导致的无效重工。

单指令状态机：0 心智负担的“自动寻迹”

为了不让复杂的流程变成开发者的负担，我们实现了单指令入口（One Main Command）。

• 物理寻迹：开发者只需输入万能指令 /specflow。

• 自动识阶：系统会智能检索本地磁盘文件的状态（如 plan.md 的完成度），自动判定当前处于 PM、架构师还是开发者模式，实现研发进度的数字化自动追踪，无需手动切换工具。

SSOT 与角色思维隔离

SSOT 单文档策略：坚持 Single Source of Truth，将功能拆解、方案与任务状态集中在 plan.md 中。这让 AI 在编码时无需跨文件检索，向上滚动即可回溯初衷，大幅提升了上下文一致性并降低了 Token 损耗。

多 Agent 协作：通过特定 Prompt 为每个阶段分配专家角色（PM、TL、Dev、Admin），实现内生的“审计与校准”，确保产出质量不受个体经验偏差的影响。

概述

Specflow是一套由 AI 驱动的结构化开发流程，通过 自动探测 机制，根据ai-docs/ 目录下的文件状态，精准切换工作模式。通过Specify - Plan - Implement - Achieve四个阶段确保了需求不失真、设计不跑偏、编码可追踪、经验可沉淀。

[specflow] AI 辅助编码标准流程工作流

核心工作流 (Standard Workflow)

[Specify] 需求分析阶段

• 指令: /specflow-specify

• 职责: 严谨的资深产品经理，定义“做什么”和“为什么”。

• 核心动作: 扫描代码库提取业务规则，识别逻辑真空。

• 产物: ai-docs/{ID}/specify.md。

[Plan] 架构规划阶段

• 指令: /specflow-plan

• 职责: 架构师兼技术负责人，将业务规格映射为技术路径。

• 核心动作: 制定 [F-xx] 功能契约与 Phase 3 执行路径。

• 产物: ai-docs/{ID}/plan.md。

[Implement] 编码实现阶段

• 指令: /specflow-implement

• 职责: 严谨的软件工程师，原子化编码与实时同步进度。

• 核心动作: 按照 Group 顺序执行任务，回写标准化 Log 存证。

• 断点机制: 每个 Group 完成后强制停顿，展示 Diff 并等待授权。

[Archive] 知识归档阶段

• 指令: /specflow-archive

• 职责: 知识管理员，执行“知识脱水”与资产精细化归档。

• 核心动作: 自动映射年/季路径，更新全局索引 ARCHIVE_SUMMARY.md。

• 产物: ai-docs/{ID}/summary.md。

Specflow 是一款专为 Cursor IDE 定制的研发效能工具，通过集成常用的 Commands 与 Templates，助力开发者实现标准化开发流程。

前置要求

• IDE: 仅支持 Cursor。

• Node.js: >=18.0.0，需要 node 环境支持。

• Cursor rules：保证生成代码符合项目规范。

核心指南

• 流程标准化 (Standardization)：Specflow 的核心职责是规范 AI 的实施路径。通过统一的命令与模板，它消除了开发者与 AI 协同中的随机性，确保每一项产物的规格、路径和结构高度一致，实现研发流程的“拉齐”。

• 质量约束力(Quality Control)：Specflow 定义“如何做”，而 Cursor Rules 定义“做得好不好”。代码质量是否符合项目特定的规范、架构模式及最佳实践，完全取决于规则的完善程度。它是 AI 编码时的“交通规则”。

• 业务感知进化 (Evolution)：AI 对业务背景的理解是一个动态增长的过程。

• 初期：依赖 Cursor 对代码库的静态索引。

• 长期：随着需求归档 (Requirements Archiving) 的增加，这些结构化的归档文件将成为 AI 的“经验值”。归档越多，AI 对复杂业务逻辑的上下文理解就越深，从而实现从“辅助写码”到“理解意图”的质变。

安装与配置

第一步：安装命令行工具

通过爱奇艺私有镜像源安装全局 CLI 工具：

第二步：项目初始化

进入你的项目根目录执行初始化。该操作会将必要的配置（commands 和 templates）注入到项目的 .cursor 文件夹中。

第三步：版本更新

当 Specflow 有新功能发布或模板更新时，运行以下命令同步最新内容：

核心功能概览

初始化完成后，你可以在 Cursor 中直接使用以下资源：

• Commands: 预定义的 AI 指令集，提升代码生成质量。

• Templates: 标准化代码模板，确保团队代码风格一致。

运行环境：请确保在 Cursor Chat (Agent Mode) 中执行以下操作。

流程总览

Specflow 将研发流程分为四个核心阶段，通过 /specflow 指令驱动。

Step 1：需求规格化 (Specify)

目标：消除需求模糊性，将自然语言转换为 AI 可理解的开发规范。

• 执行指令：

• 关键动作：

  
  

• 上下文补充：如有 UI 设计图，建议作为附件上传，使用 AI将图转换为 HTML/CSS 结构效果会更好。

  
  

• 问题澄清：查看ai-docs/{{需求号}}/specify.md。

▪ 在[User]区域直接勾选选项或输入回答。

▪ 审查业务状态机、流转逻辑及验收标准。

• 流转：再次输入/specflow，校验澄清项。若全部完成，将自动触发Plan锚点。

Step 2：技术方案与任务拆分 (Plan)

目标：明确实现路径，拆解原子化开发任务。

• 前置输入：流程会停在交互锚点，请提供接口文档(API Docs)。

  
  

• 若无文档，回复“继续”跳过。

• 核心审查项 (plan.md)：

  
  

a.[Block] 问题：必须回答，否则无法进入开发。

b.[?] 问题：可选回答，不阻塞流程。

c.方案审查：确认实现思路与验收标准是否符合预期。

d.任务组 (Groups)：检查任务拆分是否有遗漏。

Step 3：原子化代码实现 (Implement)

目标：AI 自动编码、自检，并由人工进行阶段性 Review。

• 执行逻辑：

  
  

• AI 将按照 plan.md 中的 Group 顺序进行开发。每完成一个分组，流程会暂停。

• 开发者介入：

• Review：检查当前分组的代码质量与逻辑。

• 确认/继续：回复 继续 或再次输入 /specflow 启动下一个分组。

• 状态记录：AI 会实时更新任务标记并记录开发日志。

Step 4：需求归档 (Archive)

目标：沉淀技术债背景，建立逻辑对撞索引。

• 触发时机：提测完成、合并至 develop 分支前。

• 执行动作：

a.生成摘要：创建 summary.md，记录核心技术决策。

b.迁移文档：将 ai-docs/ 移动至 history/{{年份}}/{{季度}}/。

c.更新索引：更新全量的ARCHIVE_SUMMARY.md标签与索引。

• 安全机制：AI 会先进行 Dry-run（预览模式），确认无误后回复“确认”即可正式归档。

文档资产说明

Specflow 2.0：从“模拟流程”进化为“自治架构”

Subagents：深度角色隔离与上下文裁剪

• 角色原子化：将原有的资深产品经理、架构师等角色彻底解耦为独立的 Subagents，每个子代理仅加载其职能相关的指令集，避免角色重叠导致的逻辑干扰。

• 上下文精准注入：主代理根据当前阶段，仅向 Subagents 投喂必要的文档，通过裁剪非必要的历史推理，极大提升响应速度并降低长文本导致的“逻辑漂移”。

• 自主验证闭环：Subagents 拥有独立的“思考-验证”空间，在提交结果给主代理前，必须先在内部完成单测或静态检查。

Agent Skills：从“命令执行”到“意图自触发”

• 意图驱动流转：摒弃手动输入 /specflow。系统通过监控文件状态或对话意图自动触发对应的 Skills。

• 原子能力封装：将命令中的脚本片段（如 ID 锁定、季度归档、物理搬运）封装为标准化的 Agent Skills。

AI 辅助编码不该是单纯的“快”，而应该是“准”。

Specflow 的意义，就是把解决问题的战场从“编码调试期”强行推到了“需求设计期”。当设计稿和逻辑契约足够清晰时，写代码本身就成了一种极其廉价的体力活，可以放心地交给 AI。

我们正在告别那个“边写边修”的野蛮时代。未来的核心竞争力，不再是你写代码的速度，而是你定义需求、拆解任务和驾驭规范的能力。流程的确定性，才是我们对抗业务复杂性的唯一手段。