Dify 构建 FE 工作流：前端团队可复用 AI 工作流实战

1. 为什么是"工作流"，不是"聊天"

直接聊天写代码的问题很典型：

1. 同一需求不同人问法不同，结果波动大
2. 输出格式不统一，难接工程流程
3. 无日志闭环，难复盘
4. 难形成团队资产

Dify 的价值在于：把 Prompt、规范、知识、输出格式、调用链路沉淀为"流程"。

2. 环境准备（macOS 本地）

2.1 基础要求

1. CPU >= 2 Core
2. RAM >= 4GB（建议 8GB+）
3. 已安装 Docker（Docker Desktop）

2.2 验证 Docker

docker --version
docker compose version

如果命令不存在，先装 Docker Desktop。

3. Dify 本地部署（docker compose）

以下基于仓库根目录：dify-main

3.1 启动

cd docker
cp .env.example .env
docker compose up -d

首次启动会拉大量镜像，时间可能较长。

3.2 初始化入口

1. 首次访问：http://localhost/install
2. 完成初始化后：http://localhost
3. 建好之后可以尝试用模版建app

3.3 查看状态

cd docker
docker compose ps

看到 api/web/nginx/db/redis/worker 等服务 Up 即正常。

3.4 查看日志

cd docker
docker compose logs -f api
docker compose logs -f web

3.5 停止服务

cd docker
docker compose down

4. 常见坑（实战里最常见）

4.1 docker-credential-desktop not found

报错示例：拉镜像时提示 credential helper 不存在。

修复：

ln -sf /Applications/Docker.app/Contents/Resources/bin/docker-credential-desktop /usr/local/bin/docker-credential-desktop
ln -sf /Applications/Docker.app/Contents/Resources/bin/docker-credential-osxkeychain /usr/local/bin/docker-credential-osxkeychain

4.2 端口冲突

Dify 默认占用 80/443。如果冲突，改 docker/.env 和 docker-compose.yaml 端口映射。

5. FE 团队"AI 辅助编码标准化"方案

当前目标：先标准化辅助编码。

暂不做：AI 自动代码审核裁决。

5.1 输入标准（统一请求模板）

每次调用 AI 前，必须给统一结构：

task_type: feature|bugfix|refactor
module: web/app/xxx
goal: 一句话目标
constraints:
  - 不改接口语义
  - 不改共享字段语义
  - 必须通过 lint/typecheck
acceptance:
  - 场景A
  - 场景B
context_refs:
  - PRD链接
  - API文档链接

5.2 输出标准（统一结果结构）

统一输出 JSON，便于落地执行和审计：

{
  "change_plan": ["修改文件A做什么", "修改文件B做什么"],
  "risk_points": ["风险1", "风险2"],
  "implementation_notes": ["关键实现点"],
  "self_check": ["lint", "typecheck", "关键场景手测"]
}

6. 在 Dify 里搭建最小 FE 工作流

推荐先做 Chatflow，节点保持最小闭环：

1. Start
2. LLM（基于统一系统提示词）
3. JSON 校验（格式不合法则重试）
4. Answer

如果后续增强，再加：

1. Knowledge Retrieval（规范/PRD/接口文档）
2. 条件路由（feature/bugfix 分流）
3. 工具调用（例如文档检索）

7. 系统提示词（可直接用作第一版）

你是前端架构与工程规范助手。目标是给出可执行、可审计的辅助编码方案。

硬约束：
1. 不修改未授权模块
2. 不改变已有字段/接口语义
3. 不绕过 lint/typecheck/test
4. 信息不足时先列"缺失信息"，禁止臆造

输出必须是 JSON，字段固定：
- change_plan: string[]
- risk_points: string[]
- implementation_notes: string[]
- self_check: string[]

要求：
- 优先最小改动原则
- 明确影响面
- 给出可验证的检查步骤

8. 模型与费用怎么理解

1. Dify 自托管本身不按调用收费
2. 真正计费来自你接入的模型提供商（OpenAI/Anthropic 等）
3. 用本地模型可降 API 成本，但会增加本机资源消耗

9. 团队治理（必须做，不然会失控）

1. Prompt 版本化（像代码一样管理）
2. 输出 Schema 固定（禁止自由文本漂移）
3. 结果必须过 CI 门禁（lint/typecheck/test）
4. 保留调用日志，便于复盘与优化

10. 落地节奏（建议 3 周）

1. 第 1 周：定义输入/输出标准与红线
2. 第 2 周：上线 Dify 最小工作流，单模块试点
3. 第 3 周：扩展到 2-3 个 FE 模块，评估提效与返工率

结语

把 大模型 当聊天工具，收益是个人级的。

把 Dify 当 FE 标准化工作流平台，收益才是团队级的。