团队引入 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 承担。重要变化先进入 change，再由 proposal、spec、design 和 tasks 分别承载不同判断，避免 Agent 只根据一句 prompt 或一个 Issue 自行扩展范围。

2. Harness Layer

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

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

3. Verification Gate

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

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

4. Compound Layer

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

Compound Engineering 的价值在这里体现：把计划、执行、评审、调试和复盘沉淀为 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、文档、权限、上下文和人工判断仍需验证
一开始就重建全流程	成本高，团队接受度低	从高风险、高频任务类型开始迁移

贡献者: sincerly90

上一页传统与 AI 增强

下一页AI 没有改变什么