# Ch8: 迁移到你的项目 — 如何用这套方法设计你自己的 workflow

> 不要先写 skill。先把产品边界想清楚。

## 8.1 一条更稳的落地顺序

如果你准备为自己的项目设计 workflow，建议按这个顺序：

1. 定义目标交付物
2. 定义机器可读真源
3. 定义控制面
4. 定义受控写入边界
5. 定义验证结论来源
6. 定义经验回流方式

这比“先写几个 `SKILL.md` 试试”稳定得多。

## 8.2 可以直接复用的设计清单

你至少应该先写清楚下面这些问题：

### 交付层

- 最终要写进目标项目哪些文件
- 哪些文件是工具托管的
- 哪些文件永远不能被静默覆盖

### 控制面

- 机器可读真源是什么
- 是否需要阶段模型
- 哪些步骤必须沉到确定性脚本

### 验证层

- 什么算 PASS
- 什么算 FAIL
- 哪些失败是设计问题，哪些是实现问题，哪些是环境问题
- 最终结论由谁给

### 闭环层

- lessons 写到哪
- 长期规则写到哪
- 哪些经验允许自动提炼，哪些必须审批

## 8.3 用 WorkflowProgram 反推自己的 workflow

如果不知道怎么开始，可以直接仿照 WorkflowProgram 的四层结构：

1. `spec`
2. `entry + runner`
3. `validate`
4. `lessons + constraints`

不需要一开始就完全照搬 `S0..S6`，但这四层思路最好保留。

## 8.4 最小可行版本

如果你想先做一个轻量版本，可以先实现：

1. 一个机器可读 spec
2. 一个最小 entry wrapper
3. 一个边界明确的写入流程
4. 一个独立 verdict 产物
5. 一个最小 lessons 文件

这已经比大多数“纯 prompt workflow”稳很多了。

## 8.5 最后的判断标准

当你审视自己的 workflow 时，可以用这 5 句问自己：

1. 我能说清楚真源是什么吗
2. 我能说清楚谁在控制状态转移吗
3. 我能说清楚谁在给最终 verdict 吗
4. 我能说清楚证据落在哪里吗
5. 我能说清楚失败经验如何回到下一轮吗

这 5 句都能答清楚，workflow 才算真正开始走向产品化。

## 回到首页

- [教程首页](./index.md)
- [单页版教程](../workflowprogram-101.md)