背景AI发展迅速曾经 AI 只能帮我们补全下一行代码到现在 AI 几乎已经可以在我们工作的各个阶段都提供帮助。创建需求、分析需求、分析技术方案、编写代码、调试bug、测试、性能优化 等等几乎都有了AI的介入。但这些零散的节点都需要开发者去自行选择使用有的开发者可能还停留在传统编码不同开发者用的不同 AI 方案。没有一个统一的工具将从TAPD到提测整个链路串起来没有标准化的流程能够推动所有人都高效的利用 AI。对于一些简单工作如果没有开发者的介入AI 是否可以自己从头到尾完成。对于一些复杂的工作如果有标准化的流程开发者可以在固定的节点使用 AI充分利用 AI 加速需求完成。因此我们从 prompt 工程演进 Harness Engineering做了一系列智能开发工作流让AI能够帮助我们执行跨越整个研发生命周期的长任务。工作流总览整体架构详细设计智能知识库为什么需要项目知识库AI 虽然能够理解代码但它缺少对项目整体的结构化认知缺乏项目全貌AI 每次对话都是全新开始不知道项目的技术栈、目录结构、编码规范无法复用经验之前的分析结果无法持久化每次都需要重新分析上下文受限无法一次读取所有项目文件来建立完整认知规范不一致生成的代码可能与项目现有风格不一致.workflow 知识库正是为了解决这些问题。它是一套结构化的项目元信息文档让 AI 能够快速了解项目的技术栈和架构遵循项目现有的编码规范和命名约定复用已有的组件和工具函数按照项目惯例进行 API 调用.workflow 知识库架构目录结构知识库与开发流程的协作.workflow 知识库是整个 AI 辅助开发流程的基础设施与其他命令形成完整的协作链路协作流程详解具体协作方式1. prd-preprocess 如何使用知识库prd-preprocess 命令: │ ├─→ 读取 knowledge/business.md │ └─→ 理解业务模块划分识别涉及模块 │ ├─→ 读取 knowledge/components.md │ └─→ 了解现有组件避免重复开发 │ ├─→ 读取 rules/tech-stack.md │ └─→ 确认技术栈约束 │ └─→ 输出: 结构化 PRD 技术可行性分析2. dev-workflow-plan 如何使用知识库dev-workflow-plan 命令: │ ├─→ 读取 knowledge/api.md │ └─→ 遵循 API 调用规范生成代码 │ ├─→ 读取 knowledge/components.md │ └─→ 复用现有组件遵循 CSS 变量 │ ├─→ 读取 rules/code-style.md │ └─→ 生成符合项目规范的代码 │ ├─→ 读取 rules/naming.md │ └─→ 遵循命名约定 │ ├─→ 读取 template/ (如有匹配模板) │ └─→ 基于模板生成代码 │ └─→ 输出: 符合项目规范的代码3. archive 如何使用知识库archive 命令: │ ├─→ 读取 tech/ 目录 │ └─→ 收集该需求的所有技术方案 │ └─→ 输出: 整合到 archive/ 目录 │ └─→ 归档文档成为知识库的一部分 可被 RAG 搜索用于后续开发命令介绍1. workflow-init知识库初始化作用深度分析项目生成完整的 .workflow/ 知识库使用方式# 基本用法 mcp__bgent__bili-fe-workflow-init # 强制覆盖已有知识库 mcp__bgent__bili-fe-workflow-init forceOverwritetrue执行流程支持的项目类型单项目标准的单页应用多项目Monorepo、Vue 多页应用2. knowledge-update知识库更新作用当项目代码变化后增量更新指定的知识库文件使用方式# 更新 API 文档 mcp__bgent__bfw-knowledge-update knowledgeFile.workflow/knowledge/api.md # 更新组件文档 mcp__bgent__bfw-knowledge-update knowledgeFile.workflow/knowledge/components.md # 更新全部知识库 mcp__bgent__bfw-knowledge-update knowledgeFile.workflow/knowledge/index.md执行流程更新策略内置知识库使用特定的分析指令确保分析质量一致自定义知识库使用通用更新流程根据文档内容确定分析范围差异对比示例## 差异对比报告 ### 新增内容 (New) - [API] 新增接口: GET /api/v2/user/profile - [组件] 新增业务组件: UserAvatarUploader.vue ### 修改内容 (Modified) - [API] 修改响应结构: getUserList 返回数据路径从 response.data 改为 response.result ### 删除内容 (Removed) - [API] 废弃接口: GET /api/v1/user/old-list ### 保持不变 (Unchanged) - [API] 基础架构: Service Layer 模式保持不变需求文档澄清为什么需要预处理我们知道光有一个 PRD 是不足以直接开始需求的。原因有下PRD 是以产品角度对需求的描述无法直接映射到代码模块PRD 需要经过需求评审来进一步澄清补充PRD 如果涉及到多个项目前端PC、H5、后端我们需要提取出当前项目的改动前端开发还需要交互稿和视觉稿前端开发需要后端的技术方案其他问题因此只拿到一份 PRD 是完全不够的我们还需要进行二次处理。当然人工整理是完全ok的但这需要花费我们较多的时间。相比人工AI 可能更具以下优势AI 分析文档、分析代码的速度更快据粗略统计AI 编写的文档长度是人写的 7 倍更加适合拿来作为 promptAI 能检测到一些人会忽略的模块模仿我们自己开发需求的流程产品出TAPD - 需求评审对齐 - 技术方案对齐 - 写代码。其中需求评审是非常重要的通过评审去明确一些不确定的需求点、对齐产品和技术上的理解差异。但问题是往往需求评审讨论的内容我们并不会落实到文档里而是口头上的信息传递。为了让这一部分信息能让AI获取到需要 prd-preprocess 命令。命令介绍命令的大致流程是需求文档、设计稿、接口文档收集 - 代码涉及模块匹配 - 代码现状和需求对比 - 澄清 - 落实文档。这其实是对 产品出TAPD - 需求评审对齐 这一个步骤的AI化模仿即通过拆分更加详细的步骤让AI模仿真实开发的流程。核心作用/prd-preprocess 是一个需求文档预处理工具帮助开发者将原始的产品需求文档PRD、设计稿、技术方案转换为结构化、可执行的开发 PRD 文档。减少需求理解偏差自动分析涉及的代码模块提前发现需求中的问题和歧义生成标准化的开发文档使用示例# 基本用法 /prd-preprocess # 指定需求目录 /prd-preprocess prd/20251217-new-feature/ # 通过 选择文件自动识别父目录 /prd-preprocess prd/20251217-new-feature/original-prd.md执行后生成的文件结构prd/20251217-new-feature/ ├── README.md # 需求概览 ├── clarification.md # 澄清记录 ├── 20251217-new-feature-module-a-prd.md # 子需求1 ├── 20251217-new-feature-module-b-prd.md # 子需求2 ├── images/ # 设计稿截图 │ ├── design-1.png │ └── design-2.png ├── backend-api.md # 后端接口文档 └── original-prd/ # 原始文档 └── document.mdprd-preprocess 命令使用介绍前置条件: 先安装 mcp tool bilibili-business/mcp-server-sdk, 或者安装 Claude Code 插件 Fugue在 Claude Code 中输入 /prd-preprocess 会出现命令选项下图中第一个是我自己在当前项目下创建的命令.claude/commands/prd-preprocess.md第二个是我发布在 Claude Code 插件 Fugue 上的 command第三个是我发布在 mcp 工具的 prompt哪一个更好这三个目前来说效果是一样的我们也在对比探索 mcp vs plugin 的效果那个更好。目前建议大家使用 mcp 的版本。如果大家看到前缀跟我的 mcp-router:workflow 不一样不用担心因为我本地安装了 mcp-router 来托管。有关 mcp-router 的使用见todo阶段一prd、技术方案、设计稿的资源获取我们可以不带任何参数直接执行工作流没有接收到任何的需求文档会询问用户需要使用的需求应该存放在哪个目录。这个目录会作为工作流执行过程中prd、技术方案、预处理生成最终文档的存放地址。默认情况下会在项目/prd/20251217-xxx/ 目录下进行工作流会询问你是否有 设计稿链接 、技术方案文档我们再把准备好的 技术方案 贴过来这里的演示没有 figma 设计稿。然后工作流就可以进入到下一步了阶段二分析需求和代码提取需求工作流会先提取需求中与前端相关的功能点并整理出来。提取需求时会按照以下四个方向进行界面改动新增页面、修改现有页面、删除页面功能改动新增功能、修改功能、删除功能交互改动用户操作流程、状态变化、动画效果数据改动新增接口、修改接口参数、数据格式变化这四个方向也是我们平时自己开发需求的时候会从前端考虑的点。这符合工作流的两个原则模仿和拆解。分析涉及代码分析会从两个方向下手一个是会使用mcp tool rag-knowledge-search进行知识库的查询如果此前有相同模块的需求改动并且通过工作流生成过相关的 prd\tech\archive 文档那么 rag search 能够快速定位到涉及模块。工作流和知识库可以互补完善。使用Explore Glob Grep等工具直接进行代码筛查同样的生成最终模块时也会拆分成不同的方向。这些方向基本上会涵盖到一个前端需求所需要的所有代码了。主页面相关组件路由配置API 接口工具和类型定义阶段三需求澄清在这一步中工作流会对比 prd 和项目的代码现状分别从完整性一致性明确性三个角度来进行需求的澄清这是非常重要的一步。我们需求将在需求评审时口头讨论的内容明确的告知给 AI只有这样才能消除模糊减少AI的幻觉产生。并且AI 也能发现一些此前需求评审时没有讨论到的问题通过澄清来补全。其实站在前端的角度有非常多的交互细节产品都不会再prd里描述的往往是我们自己哼哧哼哧开发完了然后产品一看发现不好然后再返工改。通过AI澄清明确性能更早的把问题暴露出来比如下图中提到的基本上全都是prd未明确的细节。选择自定义后输入 X 天X 的取值范围是多少是否有最小值/最大值限制当用户从等于切换到匹配或为空时已选择的枚举值如何处理保留还是清空阶段四需求拆解整理澄清内容生成 https://clarification.md 文档并且拆分子需求。就像我们自己开发的时候也不会一次性就把整个需求写完而是会先写一块再写另一块。对于AI来说也是一样由于上下文的限制AI也不能一次性就将整个需求写完通过将一整个大需求拆分成几个小型需求能够让 AI 生成的更加准确。这也属于 模仿和拆解 的思路。当然我们可以自行修改拆解的范围比如说我认为 维度条件配置和指标条件配置 可以一起实现那么可以手动调整。生成多份 prd 文档并整理各个模块的依赖关系给出后续开发建议。智能开发工作流在上一步 需求文档澄清中中我们将原始的 prd 整理拆分一共拆分出了多个子需求 prd。接下来需要开始开发。我们常规的一个开发流程一般是prd - 技术方案选型 - 技术方案设计 - 代码编写。一般来说我们都是自己项目的负责人对项目的很多细节比较熟悉因此我们经常不会将 技术方案选型 - 技术方案设计落实成文档而是在头脑风暴直接开始写代码。按照模仿拆解的思路我们将这个流程拆解成 AI 可以执行的流程编排了智能开发工作流。智能开发工作流主要是一个顶层工作流调度器负责分析需求文档中的 Figma 解析策略分三条路径执行如下图所示两大Skill的定位非常清晰并且通过 d2c-logic-hints-generator进行衔接D2C 视觉驱动设计稿 → UI 代码→ 逻辑补全提示Dev 逻辑驱动需求 → 完整可运行代码整体调用的Skill列表如下D2C核心理念“设计驱动代码” — 从 Figma 设计稿自动生成高还原度的 UI 代码将视觉还原工作自动化。传统工作流分析技能组成6 个 Skill对于传统工作流进行拆解实现设计稿分析和UI还原七步流水线这个阶段的产出是两样东西可运行的 UI 代码和一份logic-hints.md。UI 已经还原但按钮点击事件是空的、接口调用是 mock 的、表单校验还没写——这些都被精确地标记在 logic-hints.md 中。关键设计点1) 并行 MCP 调用所有 Figma API 调用在单条消息中并行发起大幅缩短总耗时2) 单 Task 批处理组件识别和图标匹配各用一个 Task子代理完成全部项目避免逐个启动子代理的开销3) 预计算样式映射figma-design-analyzer 在提取阶段生成 tw-to-css.jsoncode-generator 直接查表不重复解析 Tailwind4) 渐进式数据持久化.workflow/temp/d2c/[需求名]/ ├── manifest.md # 步骤5 确认后生成防止上下文压缩导致丢失 ├── raw/ # 原始 Figma JSON完整备份用于追溯 ├── extracted/ # 提取后的结构化数据代码生成时按需读取 │ ├── code.html, styles.json, components.json │ ├── assets.json, tw-to-css.json └── screenshots/5) 子代理上下文隔离D2C 在独立子代理中运行完成后上下文自动释放不污染主代理的上下文窗口Dev核心理念“需求驱动动态编排” — 分析 PRD 复杂度和特征自动规划最优的 Skill 执行序列。技能组成7 个 Skill动态规划Dev 的核心设计是 Step 0 的动态计划生成对需求特征和其他输入进行分析- Skill 选择 - 用户确认具体 SKill 动态选择规则如下技术要点提取→学习→方案 的三级流水线这是 Dev 最核心的设计 — 三个 Skill 形成递进式知识构建设计精髓需求驱动过滤只提取与当前需求相关的技术点不过度学习三级优先级⚪从提取阶段贯穿到学习阶段控制学习深度覆盖度校验tech-architect 验证方案中使用的所有技术是否都已被学习发现缺口则补学3大执行策略在full模式的执行策略下两大子系统的协作关系如下D2C Phase 1 生成logic-hints.md内容如下logic-hints.md 内容: ├── 已生成文件列表 ├── 已完成项UI骨架/组件配置/样式 ├── 待补全清单API调用/事件处理/数据源/路由 ├── 已使用组件列表 └── 补全建议Dev 根据logic-hints.md 内容进入逻辑补全模式各个Skill的行为调整如下layout-only / none 策略下直接进入 Dev 标准模式动态规划 Skill 执行序列。自动化测试使用流程概览实现方案完整工作流设计Step1调用测试工作流调用测试工作流有多种方式(输入/找到/bili-fe-test-workflow)自然语言输入可按需调整: 根据用户输入生成规范且详细的测试计划包括frontmatter基本信息、执行要求、每个测试用例的基本信息ones caseid(如果有的话) 初始URL, 前置条件(包含3A造数信息)测试步骤(越详细越好小学生也能按照步骤一步步点下去)预期结果等常见使用举例商业部门需求正常可直接贴ones链接或者onesid, 如或者说onesid:16751可额外 xxx-prd.md, tech.md 等随意添加自定义要求简单的需求也可以直接tapd/企微复制过来贴给工作流第一遍生成后可按需调整修改人工Review一遍避免开始测试时ai走偏或找不到实际内容以免浪费大量时间和TokenStep2运行测试计划当你觉得测试计划修改的比较详细且完善后就可以让ai继续开始测试了:Step3生成测试报告AI测试完可以让AI生成详细的测试报告以供校验追溯Step4生成Playwright测试脚本然后可以基于之前的测试上下文生成playwright测试脚本, 项目playwright初始化可使用我们MCP里的/bili-fe-test-workflow-setup来快速初始化Step5测试脚本修复生成脚本后需要先本地运行测试脚本AI调试/人工调试跑通后就可以提交git了Step6UI自动化平台重复跑测试代码提交后可以在UI自动化平台上跑跑看能不能通过后续的需求、回归用例就可以定时重复的跑了Step7CI流水线配置UI自动化平台接入成功后就可以开始配置CI流水线以便于在release前发MR时进行回归测试提升上线稳定性 完整AI交互流程可选工作流程以上为走完一个完整的测试工作流的过程当然我们也可以根据实际情况按需跳过某些步骤不同情况的适合场景Ai在生成测试计划后下一步之前会提示使用哪种模式:完整流程(传统)适合用例在15个以内的场景基本可以在可接受的范围内执行完渐进式AI测试完一个用例立即生成测试脚本并验证可运行性以此循环进入下一个用例(一定程度上减少第一种方式的上下文丢失)代码优先(适合vibe coding者)基于plan直接生成完整的测试脚本代码然后一个个运行并修复对于50用例的场景建议跑一部分测试生成脚本调通后让AI依葫芦画瓢复杂用例场景处理1. 登录态解决a. 本地b. 平台2. 用例前置数据准备a. 已支付订单相关行为测试(3A造数)后续迭代方向基于上面的Plugin Skill 探索分发测试工作流的各部分减少AI测试的等待时间提升生成测试脚本的准确性以及减少过程中的token消耗AI Mock工作流实现方案核心优势AI帮你完成配置调用/bili-fe-mock-workflow-setup即可无需额外代理软件配置集成在你的前端项目里且不影响业务代码与你本地的AI Agent无缝集成任意Mock逻辑(mock本身即代码)3种模式任选AI通过MCP动态添加(不改本地文件)AI修改本地custom-handlers(gitignored), 基于Swagger使用场景适合在开发过过程中无实际接口时Mock已有接口但需要调整不同的数据返回来测试不同的UI场景本地UI测试时临时Mock一下减少AI操作浏览器消耗的token发挥你的想象力...使用方式调用/bili-fe-mock-workflow-setup初始化mcp_server_sdk 配置--enable-mockarg以及额外可选选项(刷新页面保留添加arg: --mock-persist-handlers)首次可以调用/bili-fe-mock-workflow 你的mock需求, 不明确时AI会引导你使用哪种mock方式前2个直接开始mock, 当选择swagger时会引导你使用定制的/bili-fe-swagger-mock-workflow 来完成swagger mock后续的mock或者你已经很了解要怎么mock, 可以直接告诉AI要求无需每次都调工作流总结思考过去一年的实践验证了方法论的有效性但这只是开始。AI 时代的前端正在经历根本性的范式变革。过去我们依赖个人经验推动需求落地未来则会更多依赖规范化的工作流、可复用的上下文资产以及人与 AI 的协同生产机制。Harness Engineering 的意义不只是提供一套更高效的开发流程更是在团队内部建立一种新的工程共识: 先定义清楚问题再约束生成过程最后通过标准化验证确保结果可交付、可维护、可复用。这意味着前端工程师的价值正在从“单点编码产出”转向“问题抽象、方案设计、规则沉淀与质量把控”。谁能更好地组织需求、编排上下文、制定约束、验证结果谁就能更有效地放大 AI 的能力。工作流的价值也不只体现在一次提效上而在于它是否能够沉淀为团队能力帮助更多同学以更低门槛、更稳定质量完成复杂交付。因此这份文档的目标不是给出一套固定答案而是提供一个可实践、可迭代的起点。希望大家在使用的过程中持续补充案例、沉淀模板、优化规则把零散的个人经验逐步升级为团队共享的智能开发体系。这套体系一旦建立提效就不再是偶发结果而会成为组织层面的稳定能力。-End-作者丨梦园、远书
bili-fe-workflow —商业化智能开发工作流实践
发布时间：2026/5/16 11:15:21
背景AI发展迅速曾经 AI 只能帮我们补全下一行代码到现在 AI 几乎已经可以在我们工作的各个阶段都提供帮助。创建需求、分析需求、分析技术方案、编写代码、调试bug、测试、性能优化 等等几乎都有了AI的介入。但这些零散的节点都需要开发者去自行选择使用有的开发者可能还停留在传统编码不同开发者用的不同 AI 方案。没有一个统一的工具将从TAPD到提测整个链路串起来没有标准化的流程能够推动所有人都高效的利用 AI。对于一些简单工作如果没有开发者的介入AI 是否可以自己从头到尾完成。对于一些复杂的工作如果有标准化的流程开发者可以在固定的节点使用 AI充分利用 AI 加速需求完成。因此我们从 prompt 工程演进 Harness Engineering做了一系列智能开发工作流让AI能够帮助我们执行跨越整个研发生命周期的长任务。工作流总览整体架构详细设计智能知识库为什么需要项目知识库AI 虽然能够理解代码但它缺少对项目整体的结构化认知缺乏项目全貌AI 每次对话都是全新开始不知道项目的技术栈、目录结构、编码规范无法复用经验之前的分析结果无法持久化每次都需要重新分析上下文受限无法一次读取所有项目文件来建立完整认知规范不一致生成的代码可能与项目现有风格不一致.workflow 知识库正是为了解决这些问题。它是一套结构化的项目元信息文档让 AI 能够快速了解项目的技术栈和架构遵循项目现有的编码规范和命名约定复用已有的组件和工具函数按照项目惯例进行 API 调用.workflow 知识库架构目录结构知识库与开发流程的协作.workflow 知识库是整个 AI 辅助开发流程的基础设施与其他命令形成完整的协作链路协作流程详解具体协作方式1. prd-preprocess 如何使用知识库prd-preprocess 命令: │ ├─→ 读取 knowledge/business.md │ └─→ 理解业务模块划分识别涉及模块 │ ├─→ 读取 knowledge/components.md │ └─→ 了解现有组件避免重复开发 │ ├─→ 读取 rules/tech-stack.md │ └─→ 确认技术栈约束 │ └─→ 输出: 结构化 PRD 技术可行性分析2. dev-workflow-plan 如何使用知识库dev-workflow-plan 命令: │ ├─→ 读取 knowledge/api.md │ └─→ 遵循 API 调用规范生成代码 │ ├─→ 读取 knowledge/components.md │ └─→ 复用现有组件遵循 CSS 变量 │ ├─→ 读取 rules/code-style.md │ └─→ 生成符合项目规范的代码 │ ├─→ 读取 rules/naming.md │ └─→ 遵循命名约定 │ ├─→ 读取 template/ (如有匹配模板) │ └─→ 基于模板生成代码 │ └─→ 输出: 符合项目规范的代码3. archive 如何使用知识库archive 命令: │ ├─→ 读取 tech/ 目录 │ └─→ 收集该需求的所有技术方案 │ └─→ 输出: 整合到 archive/ 目录 │ └─→ 归档文档成为知识库的一部分 可被 RAG 搜索用于后续开发命令介绍1. workflow-init知识库初始化作用深度分析项目生成完整的 .workflow/ 知识库使用方式# 基本用法 mcp__bgent__bili-fe-workflow-init # 强制覆盖已有知识库 mcp__bgent__bili-fe-workflow-init forceOverwritetrue执行流程支持的项目类型单项目标准的单页应用多项目Monorepo、Vue 多页应用2. knowledge-update知识库更新作用当项目代码变化后增量更新指定的知识库文件使用方式# 更新 API 文档 mcp__bgent__bfw-knowledge-update knowledgeFile.workflow/knowledge/api.md # 更新组件文档 mcp__bgent__bfw-knowledge-update knowledgeFile.workflow/knowledge/components.md # 更新全部知识库 mcp__bgent__bfw-knowledge-update knowledgeFile.workflow/knowledge/index.md执行流程更新策略内置知识库使用特定的分析指令确保分析质量一致自定义知识库使用通用更新流程根据文档内容确定分析范围差异对比示例## 差异对比报告 ### 新增内容 (New) - [API] 新增接口: GET /api/v2/user/profile - [组件] 新增业务组件: UserAvatarUploader.vue ### 修改内容 (Modified) - [API] 修改响应结构: getUserList 返回数据路径从 response.data 改为 response.result ### 删除内容 (Removed) - [API] 废弃接口: GET /api/v1/user/old-list ### 保持不变 (Unchanged) - [API] 基础架构: Service Layer 模式保持不变需求文档澄清为什么需要预处理我们知道光有一个 PRD 是不足以直接开始需求的。原因有下PRD 是以产品角度对需求的描述无法直接映射到代码模块PRD 需要经过需求评审来进一步澄清补充PRD 如果涉及到多个项目前端PC、H5、后端我们需要提取出当前项目的改动前端开发还需要交互稿和视觉稿前端开发需要后端的技术方案其他问题因此只拿到一份 PRD 是完全不够的我们还需要进行二次处理。当然人工整理是完全ok的但这需要花费我们较多的时间。相比人工AI 可能更具以下优势AI 分析文档、分析代码的速度更快据粗略统计AI 编写的文档长度是人写的 7 倍更加适合拿来作为 promptAI 能检测到一些人会忽略的模块模仿我们自己开发需求的流程产品出TAPD - 需求评审对齐 - 技术方案对齐 - 写代码。其中需求评审是非常重要的通过评审去明确一些不确定的需求点、对齐产品和技术上的理解差异。但问题是往往需求评审讨论的内容我们并不会落实到文档里而是口头上的信息传递。为了让这一部分信息能让AI获取到需要 prd-preprocess 命令。命令介绍命令的大致流程是需求文档、设计稿、接口文档收集 - 代码涉及模块匹配 - 代码现状和需求对比 - 澄清 - 落实文档。这其实是对 产品出TAPD - 需求评审对齐 这一个步骤的AI化模仿即通过拆分更加详细的步骤让AI模仿真实开发的流程。核心作用/prd-preprocess 是一个需求文档预处理工具帮助开发者将原始的产品需求文档PRD、设计稿、技术方案转换为结构化、可执行的开发 PRD 文档。减少需求理解偏差自动分析涉及的代码模块提前发现需求中的问题和歧义生成标准化的开发文档使用示例# 基本用法 /prd-preprocess # 指定需求目录 /prd-preprocess prd/20251217-new-feature/ # 通过 选择文件自动识别父目录 /prd-preprocess prd/20251217-new-feature/original-prd.md执行后生成的文件结构prd/20251217-new-feature/ ├── README.md # 需求概览 ├── clarification.md # 澄清记录 ├── 20251217-new-feature-module-a-prd.md # 子需求1 ├── 20251217-new-feature-module-b-prd.md # 子需求2 ├── images/ # 设计稿截图 │ ├── design-1.png │ └── design-2.png ├── backend-api.md # 后端接口文档 └── original-prd/ # 原始文档 └── document.mdprd-preprocess 命令使用介绍前置条件: 先安装 mcp tool bilibili-business/mcp-server-sdk, 或者安装 Claude Code 插件 Fugue在 Claude Code 中输入 /prd-preprocess 会出现命令选项下图中第一个是我自己在当前项目下创建的命令.claude/commands/prd-preprocess.md第二个是我发布在 Claude Code 插件 Fugue 上的 command第三个是我发布在 mcp 工具的 prompt哪一个更好这三个目前来说效果是一样的我们也在对比探索 mcp vs plugin 的效果那个更好。目前建议大家使用 mcp 的版本。如果大家看到前缀跟我的 mcp-router:workflow 不一样不用担心因为我本地安装了 mcp-router 来托管。有关 mcp-router 的使用见todo阶段一prd、技术方案、设计稿的资源获取我们可以不带任何参数直接执行工作流没有接收到任何的需求文档会询问用户需要使用的需求应该存放在哪个目录。这个目录会作为工作流执行过程中prd、技术方案、预处理生成最终文档的存放地址。默认情况下会在项目/prd/20251217-xxx/ 目录下进行工作流会询问你是否有 设计稿链接 、技术方案文档我们再把准备好的 技术方案 贴过来这里的演示没有 figma 设计稿。然后工作流就可以进入到下一步了阶段二分析需求和代码提取需求工作流会先提取需求中与前端相关的功能点并整理出来。提取需求时会按照以下四个方向进行界面改动新增页面、修改现有页面、删除页面功能改动新增功能、修改功能、删除功能交互改动用户操作流程、状态变化、动画效果数据改动新增接口、修改接口参数、数据格式变化这四个方向也是我们平时自己开发需求的时候会从前端考虑的点。这符合工作流的两个原则模仿和拆解。分析涉及代码分析会从两个方向下手一个是会使用mcp tool rag-knowledge-search进行知识库的查询如果此前有相同模块的需求改动并且通过工作流生成过相关的 prd\tech\archive 文档那么 rag search 能够快速定位到涉及模块。工作流和知识库可以互补完善。使用Explore Glob Grep等工具直接进行代码筛查同样的生成最终模块时也会拆分成不同的方向。这些方向基本上会涵盖到一个前端需求所需要的所有代码了。主页面相关组件路由配置API 接口工具和类型定义阶段三需求澄清在这一步中工作流会对比 prd 和项目的代码现状分别从完整性一致性明确性三个角度来进行需求的澄清这是非常重要的一步。我们需求将在需求评审时口头讨论的内容明确的告知给 AI只有这样才能消除模糊减少AI的幻觉产生。并且AI 也能发现一些此前需求评审时没有讨论到的问题通过澄清来补全。其实站在前端的角度有非常多的交互细节产品都不会再prd里描述的往往是我们自己哼哧哼哧开发完了然后产品一看发现不好然后再返工改。通过AI澄清明确性能更早的把问题暴露出来比如下图中提到的基本上全都是prd未明确的细节。选择自定义后输入 X 天X 的取值范围是多少是否有最小值/最大值限制当用户从等于切换到匹配或为空时已选择的枚举值如何处理保留还是清空阶段四需求拆解整理澄清内容生成 https://clarification.md 文档并且拆分子需求。就像我们自己开发的时候也不会一次性就把整个需求写完而是会先写一块再写另一块。对于AI来说也是一样由于上下文的限制AI也不能一次性就将整个需求写完通过将一整个大需求拆分成几个小型需求能够让 AI 生成的更加准确。这也属于 模仿和拆解 的思路。当然我们可以自行修改拆解的范围比如说我认为 维度条件配置和指标条件配置 可以一起实现那么可以手动调整。生成多份 prd 文档并整理各个模块的依赖关系给出后续开发建议。智能开发工作流在上一步 需求文档澄清中中我们将原始的 prd 整理拆分一共拆分出了多个子需求 prd。接下来需要开始开发。我们常规的一个开发流程一般是prd - 技术方案选型 - 技术方案设计 - 代码编写。一般来说我们都是自己项目的负责人对项目的很多细节比较熟悉因此我们经常不会将 技术方案选型 - 技术方案设计落实成文档而是在头脑风暴直接开始写代码。按照模仿拆解的思路我们将这个流程拆解成 AI 可以执行的流程编排了智能开发工作流。智能开发工作流主要是一个顶层工作流调度器负责分析需求文档中的 Figma 解析策略分三条路径执行如下图所示两大Skill的定位非常清晰并且通过 d2c-logic-hints-generator进行衔接D2C 视觉驱动设计稿 → UI 代码→ 逻辑补全提示Dev 逻辑驱动需求 → 完整可运行代码整体调用的Skill列表如下D2C核心理念“设计驱动代码” — 从 Figma 设计稿自动生成高还原度的 UI 代码将视觉还原工作自动化。传统工作流分析技能组成6 个 Skill对于传统工作流进行拆解实现设计稿分析和UI还原七步流水线这个阶段的产出是两样东西可运行的 UI 代码和一份logic-hints.md。UI 已经还原但按钮点击事件是空的、接口调用是 mock 的、表单校验还没写——这些都被精确地标记在 logic-hints.md 中。关键设计点1) 并行 MCP 调用所有 Figma API 调用在单条消息中并行发起大幅缩短总耗时2) 单 Task 批处理组件识别和图标匹配各用一个 Task子代理完成全部项目避免逐个启动子代理的开销3) 预计算样式映射figma-design-analyzer 在提取阶段生成 tw-to-css.jsoncode-generator 直接查表不重复解析 Tailwind4) 渐进式数据持久化.workflow/temp/d2c/[需求名]/ ├── manifest.md # 步骤5 确认后生成防止上下文压缩导致丢失 ├── raw/ # 原始 Figma JSON完整备份用于追溯 ├── extracted/ # 提取后的结构化数据代码生成时按需读取 │ ├── code.html, styles.json, components.json │ ├── assets.json, tw-to-css.json └── screenshots/5) 子代理上下文隔离D2C 在独立子代理中运行完成后上下文自动释放不污染主代理的上下文窗口Dev核心理念“需求驱动动态编排” — 分析 PRD 复杂度和特征自动规划最优的 Skill 执行序列。技能组成7 个 Skill动态规划Dev 的核心设计是 Step 0 的动态计划生成对需求特征和其他输入进行分析- Skill 选择 - 用户确认具体 SKill 动态选择规则如下技术要点提取→学习→方案 的三级流水线这是 Dev 最核心的设计 — 三个 Skill 形成递进式知识构建设计精髓需求驱动过滤只提取与当前需求相关的技术点不过度学习三级优先级⚪从提取阶段贯穿到学习阶段控制学习深度覆盖度校验tech-architect 验证方案中使用的所有技术是否都已被学习发现缺口则补学3大执行策略在full模式的执行策略下两大子系统的协作关系如下D2C Phase 1 生成logic-hints.md内容如下logic-hints.md 内容: ├── 已生成文件列表 ├── 已完成项UI骨架/组件配置/样式 ├── 待补全清单API调用/事件处理/数据源/路由 ├── 已使用组件列表 └── 补全建议Dev 根据logic-hints.md 内容进入逻辑补全模式各个Skill的行为调整如下layout-only / none 策略下直接进入 Dev 标准模式动态规划 Skill 执行序列。自动化测试使用流程概览实现方案完整工作流设计Step1调用测试工作流调用测试工作流有多种方式(输入/找到/bili-fe-test-workflow)自然语言输入可按需调整: 根据用户输入生成规范且详细的测试计划包括frontmatter基本信息、执行要求、每个测试用例的基本信息ones caseid(如果有的话) 初始URL, 前置条件(包含3A造数信息)测试步骤(越详细越好小学生也能按照步骤一步步点下去)预期结果等常见使用举例商业部门需求正常可直接贴ones链接或者onesid, 如或者说onesid:16751可额外 xxx-prd.md, tech.md 等随意添加自定义要求简单的需求也可以直接tapd/企微复制过来贴给工作流第一遍生成后可按需调整修改人工Review一遍避免开始测试时ai走偏或找不到实际内容以免浪费大量时间和TokenStep2运行测试计划当你觉得测试计划修改的比较详细且完善后就可以让ai继续开始测试了:Step3生成测试报告AI测试完可以让AI生成详细的测试报告以供校验追溯Step4生成Playwright测试脚本然后可以基于之前的测试上下文生成playwright测试脚本, 项目playwright初始化可使用我们MCP里的/bili-fe-test-workflow-setup来快速初始化Step5测试脚本修复生成脚本后需要先本地运行测试脚本AI调试/人工调试跑通后就可以提交git了Step6UI自动化平台重复跑测试代码提交后可以在UI自动化平台上跑跑看能不能通过后续的需求、回归用例就可以定时重复的跑了Step7CI流水线配置UI自动化平台接入成功后就可以开始配置CI流水线以便于在release前发MR时进行回归测试提升上线稳定性 完整AI交互流程可选工作流程以上为走完一个完整的测试工作流的过程当然我们也可以根据实际情况按需跳过某些步骤不同情况的适合场景Ai在生成测试计划后下一步之前会提示使用哪种模式:完整流程(传统)适合用例在15个以内的场景基本可以在可接受的范围内执行完渐进式AI测试完一个用例立即生成测试脚本并验证可运行性以此循环进入下一个用例(一定程度上减少第一种方式的上下文丢失)代码优先(适合vibe coding者)基于plan直接生成完整的测试脚本代码然后一个个运行并修复对于50用例的场景建议跑一部分测试生成脚本调通后让AI依葫芦画瓢复杂用例场景处理1. 登录态解决a. 本地b. 平台2. 用例前置数据准备a. 已支付订单相关行为测试(3A造数)后续迭代方向基于上面的Plugin Skill 探索分发测试工作流的各部分减少AI测试的等待时间提升生成测试脚本的准确性以及减少过程中的token消耗AI Mock工作流实现方案核心优势AI帮你完成配置调用/bili-fe-mock-workflow-setup即可无需额外代理软件配置集成在你的前端项目里且不影响业务代码与你本地的AI Agent无缝集成任意Mock逻辑(mock本身即代码)3种模式任选AI通过MCP动态添加(不改本地文件)AI修改本地custom-handlers(gitignored), 基于Swagger使用场景适合在开发过过程中无实际接口时Mock已有接口但需要调整不同的数据返回来测试不同的UI场景本地UI测试时临时Mock一下减少AI操作浏览器消耗的token发挥你的想象力...使用方式调用/bili-fe-mock-workflow-setup初始化mcp_server_sdk 配置--enable-mockarg以及额外可选选项(刷新页面保留添加arg: --mock-persist-handlers)首次可以调用/bili-fe-mock-workflow 你的mock需求, 不明确时AI会引导你使用哪种mock方式前2个直接开始mock, 当选择swagger时会引导你使用定制的/bili-fe-swagger-mock-workflow 来完成swagger mock后续的mock或者你已经很了解要怎么mock, 可以直接告诉AI要求无需每次都调工作流总结思考过去一年的实践验证了方法论的有效性但这只是开始。AI 时代的前端正在经历根本性的范式变革。过去我们依赖个人经验推动需求落地未来则会更多依赖规范化的工作流、可复用的上下文资产以及人与 AI 的协同生产机制。Harness Engineering 的意义不只是提供一套更高效的开发流程更是在团队内部建立一种新的工程共识: 先定义清楚问题再约束生成过程最后通过标准化验证确保结果可交付、可维护、可复用。这意味着前端工程师的价值正在从“单点编码产出”转向“问题抽象、方案设计、规则沉淀与质量把控”。谁能更好地组织需求、编排上下文、制定约束、验证结果谁就能更有效地放大 AI 的能力。工作流的价值也不只体现在一次提效上而在于它是否能够沉淀为团队能力帮助更多同学以更低门槛、更稳定质量完成复杂交付。因此这份文档的目标不是给出一套固定答案而是提供一个可实践、可迭代的起点。希望大家在使用的过程中持续补充案例、沉淀模板、优化规则把零散的个人经验逐步升级为团队共享的智能开发体系。这套体系一旦建立提效就不再是偶发结果而会成为组织层面的稳定能力。-End-作者丨梦园、远书
