背景
AI发展迅速。曾经 AI 只能帮我们补全下一行代码，到现在 AI 几乎已经可以在我们工作的各个阶段都提供帮助。话说回来，创建需求、分析需求、分析技术方法、编写代码、调试bug、测试、性能调整 等等。几乎都有了AI的介入，
但这些零散的节点，都需要开发者去自行选择使用。有的开发者可能还停留在传统编码，不同开发者用的不同 AI 方案。没有一个统一的工具将从TAPD到提测整个链路串起来没有标准化的流程能够推动所有人都高效的利用 AI。
-
痛点1： 对于一些简单工作。如果没有开发者的介入，AI 是否可以自己从头到尾完成？
-
痛点2： 对于一些复杂的工作。如果有标准化的流程，开发者可以在固定的节点使用 AI，利用 AI 加速需求完成？
工作流总览
整体架构
详细设计
智能知识库
为什么需要项目知识库？
主要痛点：AI 缺乏对项目整体结构化认知！
虽然AI能理解代码片段，但它缺少项目级别全貌认知：
-
"短期记忆"问题：每次对话都是新开始 - 不知道项目技术栈/目录结构/编码规范等关键信息！按理说，这导致重复解释项目背景浪费时间！按理说，
-
"知识沉淀"问题：之前分析结果无法持久化 - 每次需要重新解析相同文件！这增加了启动成本，
-
"局部视野"问题：无法一次读取所有项目文件建立完整认知 - 对大型项目无法形成程序理解！话说回来，这限制了AI生成代码时的一致性！
-
"风格碎片"问题：生成代码可能与现有风格不一致 - 增加后续修改负担！这降低了团队协作效率，其实，
.workflow知识库正是为了解决这些问题而设计的一套结构化项目元信息文档程序。
.workflow 知识库架构设计原则:
| 设计原则 | 对应痛点方法 | 具体实现方式 |
持久化存储 | 解决短期记忆与知识沉淀问题
-
- 全局唯一方法:.workflow/knowledge/*.md
- 自动版本控制: 每次更新创建.gitignore排除备份
- 持久化内容示例:
# .workflow/knowledge/index.md
---
project_name: bili-fe
tech_stack:
- Vue3 + Composition API
- TailwindCSS v3.5
coding_conventions:
api_style: RESTful with snake_case parameters
...
markdown
-
- 支持增量更新: knowledge-update命令仅修改变更部分
-
- 全局可访问: 所有子命令均可读取此数据夹中信息
模块化组织 | 解决局部视野与风格碎片问题
- 按功能拆分多个MD文件:
-
.workflow/knowledge/api.md
'-
.workflow/knowledge/components.md
'-
.workflow/knowledge/styleguide.md
'-
.workflow/knowledge/routes.md
'
'- 分层索引程序:
└── .workflow/
├── knowledge/
│ ├── api/
│ │ ├── user.service.md
│ │ └── video.service.md
│ ├── components/
│ │ └── ui/
│ └── styles/
'- 自动关联检查:
-
/dev-workflow-plan会校验当前操作是否符合styleguide规定
- 项目目录树自动提取:
.project-structure.md:
├── src/
├─ components/
├─ pages/
└─ utils/
...
markdown
实时同步 | 动态维护数据完整性
#!/bin/bash
# pre-commit hook example
if;n
git add .workflow/*
mcp__bfw-knowledge-update # 自动更新变更部分
fi
{
"files":,"exclude":
}
bash
### 上下文注入机制
jsonl{"context":"export WORKFLOW_KB_PATH=$/.worklow"}
### 操作示例：
bash
mcp__bfw workflow dev \
--kb-dir=.workflow \
--prd-doc=./prd/new-feature.md \
--task-list auto-generate.jsonl \
--output-dir=./generated-code/
---
## 需求文档澄清模块
**主要挑战**：如何将产品角度PRD转换为可直接执行的工程任务？### 源头痛点分析：
1️⃣ **理解偏差**：PRD以业务场景描述为主 → 开发需识别技术边界与交付单元
2️⃣ **信息碎片**：需求涉及多个子程序 → 开发需手动梳理依赖关系
3️⃣ **隐含假设**：PRD未明确交互细节 → 开发需额外沟通或猜测逻辑
**工作流价值主张**：通过标准化处理流程 + 上下文感知能力实现：
🔍 **自动提取** - 抽象出可落地实施项
🧩 **智能拼装** - 建立各模块间依赖关系图谱
💡 **主动澄清** - 检查未明确场景并追问产品补充细节
---
## 自动化测试模块
### 流程梳理：
1. **输入阶段**
mermaid-graphql-diagram.png
-table
| 输入类型 | 典型示例 | 处理方式 | 输出物料
|
| Ones任务链接 | https://ones.bilibili... |
-
执行阶段
sequence-diagram.png
javascript-pseudocode
// 测试脚本生成逻辑伪代码示例:
async function generateTestSuite {
const playwright = new PlaywrightBuilder;按理说，const steps = parseStepsFromPlan;不过，
for {
// 预置条件处理器选择器模式匹配资源URLs并自动造数...
await playwright.addStep;if ) {
const mock = await findMockHandler;
playwright.attachMock;
}
}
return playwright.toCode;}
Mock服务模块
从架构图来看，
mermaid-component-diagram.png
特色功能这方面，
🌠 三级Mock策略
1. ⚡ 快速临时调试模式 -> 基于OpenAPI直接生成响应体Schema
2. 🛠️ 项目级持久存储 -> .mock/目录Gitignored隔离管理handlers.ts定义静态数据集合按场景分组保存如user.login.success.json等便于团队共享修改
3. 🤖 全生命周期管理 -> MCP调用mock-scenario-worker实现运行时行为注入支持多种请求匹配策略包括URL正则路由参数匹配请求头Content-Type过滤还有响应延迟仿真等特殊场景覆盖率达95%以上
说到整体价值。
根据数据调整收益验证：
| 指标维度 |
基线值 |
调整后 |
调整幅度 |
| 需求理解效率 |
人均5天 |
人均1天 |
↑80% |
| 测试覆盖率 |
~65% |
~90% |
↑25% |
| Mock搭建时间 |
小时级 |
分分钟 |
↓70% |
📊 以上数据来自内部三个月实际使用情况
说到前瞻性思考，
未来六个月主要突破方向：
☑︎ 模板库
至微服务架构场景支持跨语言协同如Go后端Python算法组Java基础网站等全域覆盖；☑︎ 在CI/CD管道中嵌入质量闸门将MCP作为预检环节强制执行规约验证；☑︎ 探索基于LLMOps网站进行本地私有权限管控满足内网安全审查要求。
*以上设计严格遵循「以人为本」原则——所有智能辅助均应被显著意识且随时可中断修正。
|
