---
url: 'https://aisee.wiki/ai-engineering/from-traditional-flow-to-aisee/index.md'
---
# 从传统研发流程到 AISEE 工作流

团队引入 AI 以后，最常见的做法是把 AI 放进原来的 Issue、PR、Review 和 CI 流程里。这样可以快速起步，但如果流程本身没有补充规范、执行边界、验证证据和知识复用，AI 只会让原来的问题更快出现。

AISEE 工作流要解决的不是“换一套项目管理方式”，而是让传统研发流程具备 AI 协作所需的四个能力：目标可审查、执行有边界、结果可验证、经验可复用。

## 为什么不能只把 AI 插进旧流程

传统流程默认执行者是人。人会主动追问、回忆上下文、识别隐含约定，也会在不确定时暂停。AI Agent 不一样，它会根据当前上下文继续推进，并且可能把未说明的假设当成事实。

这会带来三个典型问题：

* Issue 只写了目标，Agent 不知道哪些行为不能改。
* PR 只展示最终 diff，评审者看不到执行过程中的假设和取舍。
* CI 只证明当前测试通过，不能说明 Agent 是否越界、是否漏掉视觉状态、是否把经验沉淀下来。

所以，AISEE 的重点不是在旧流程外再加一层文档，而是把旧流程中原本隐性的判断变成可被 AI 读取、可被团队复核的工程事实。

## 传统流程如何对齐 AISEE

| 传统流程节点 | 常见问题 | AISEE 工作流中的对应能力 |
|---|---|---|
| Issue / 需求卡 | 目标太短，边界和验收条件不完整 | 用 SRS、proposal 或 change 描述目标、范围、非目标和验收场景 |
| 技术方案 / 设计讨论 | 方案只存在于会议、聊天或个人判断中 | 用技术上下文和 design artifact 固化架构判断、依赖、风险和实现边界 |
| TODO / 任务拆分 | 任务粒度适合人，不一定适合 Agent | 用 tasks 明确执行顺序、文件边界、验证命令和完成条件 |
| 本地开发 | 人可以临时判断，Agent 容易越界 | 用 harness 把工作目录、工具权限、项目规则、Hook 和上下文输入组织成执行边界 |
| PR / Review | 评审只看最终 diff | 同时评审目标理解、设计一致性、命令输出、测试证据和未覆盖风险 |
| CI / QA | 只验证已有自动化覆盖 | 把构建、测试、截图、链接检查、人工预览结果一起作为验证证据 |
| 复盘 / Wiki | 经验沉淀滞后，下一次任务难复用 | 用 Compound 把解决路径写入 solution docs、memory、skill 或模板 |

## 四个需要补上的层

### 1. Spec Layer

Spec Layer 负责回答“这次变化到底是什么”。它不是把所有文档写得更长，而是把目标、范围、行为变化、设计判断和验收条件放到一个稳定事实源中。

在 AISEE 主线里，这一层通常由 [OpenSpec](/openspec/) 承担。重要变化先进入 change，再由 proposal、spec、design 和 tasks 分别承载不同判断，避免 Agent 只根据一句 prompt 或一个 Issue 自行扩展范围。

### 2. Harness Layer

Harness Layer 负责回答“AI 可以在哪里、用什么方式执行”。它包括工作目录、权限、工具、Hook、上下文注入、运行命令和失败处理。

这一层对应 [AISEE Plugin](/aisee/aisee-plugin/) 的工作流定位：把 SRS、技术上下文、change 规划、实现和验证串起来，让 Agent 的执行不只是一次自由对话，而是处在明确边界内。

### 3. Verification Gate

Verification Gate 负责回答“我们凭什么认为完成了”。传统测试仍然重要，但 AI 协作下还需要检查更多证据：

* diff 是否符合目标和非目标。
* 命令输出是否支持“已完成”的判断。
* 页面截图、交互状态和响应式是否真的可用。
* 评审意见是否覆盖需求理解、设计一致性、测试缺口和越界风险。
* 未完成事项是否被明确记录。

### 4. Compound Layer

Compound Layer 负责回答“这次经验如何帮助下一次”。如果一次复杂调试、评审或流程修复只留在聊天记录里，它很快就会失效。

[Compound Engineering](/compound/) 的价值在这里体现：把计划、执行、评审、调试和复盘沉淀为 solution docs、review findings、memory、skill 或模板，让团队下一次面对类似问题时可以直接复用。

## 最小迁移路径

不需要一次性把所有流程重做。可以按下面顺序逐步迁移：

1. 先选一个经常出问题的任务类型，例如跨文件改动、UI 调整、复杂调试或文档重构。
2. 把这类任务的 Issue 改成包含目标、范围、非目标和验收条件的 change 描述。
3. 在执行前补一份技术上下文，列出相关文件、已有约定、验证命令和风险。
4. 让 Agent 按 tasks 执行，并要求它记录命令、diff、验证结果和未覆盖风险。
5. Review 时同时看代码、文档、测试证据和执行边界。
6. 完成后把可复用经验沉淀为 solution docs、memory、skill 或模板。

这个路径的关键不是追求流程完整，而是让每一次 AI 协作都留下可审查、可验证、可复用的工程材料。

## 常见误区

| 误区 | 问题 | 更好的做法 |
|---|---|---|
| 让 prompt 替代需求 | prompt 适合启动对话，不适合承载长期事实 | 重要变化进入 spec 或 change |
| 只看 AI 最终 diff | 无法判断它是否误解目标或越界 | 同时检查执行过程和验证证据 |
| 把所有经验塞进聊天记录 | 聊天记录难检索，也不稳定 | 稳定经验进入 solution docs、memory、skill 或模板 |
| 认为 CI 通过就足够 | CI 只能覆盖已有自动化 | UI、文档、权限、上下文和人工判断仍需验证 |
| 一开始就重建全流程 | 成本高，团队接受度低 | 从高风险、高频任务类型开始迁移 |