个人实践之Prototype、Patch 与 Spec vNext：按需求稳定性组织 AI Coding

Prototype、Patch 与 Spec vNext：按需求稳定性组织 AI Coding

前言

在使用 AI Agent 做前端和中后台业务开发时，很多人会自然套用一条固定流程：先写 Spec，再写 Plan，最后 Implement。这个流程在需求明确时很有效，但一旦进入 UI、交互、Dashboard、活动页这类探索场景，固定流程就会变成负担。

问题不在于 Spec 或 Plan 没价值，而在于它们被放在了错误的时机。需求还没稳定时，强行维护稳定文档，会让 Agent 和人都陷入“改一次代码、补一次文档”的循环。真正需要调整的不是是否写文档，而是根据需求稳定程度选择不同工作流。

本文的核心观点是：AI Coding 工作流应该建立在“需求稳定性”上，而不是建立在“项目类型”上。Prototype 负责解决需求未确定的问题，Patch 负责解决已确定需求的持续演进问题，Spec vNext 则负责把一轮变更重新收敛成稳定知识。

一、问题

前端开发使用 AI Agent 时，是否可以固定走 Spec-Plan-Implement 流程？

答案是否定的。问题不在于 Spec 和 Plan 本身，而在于它们在错误的时间、以错误的粒度被要求维护。当需求还在探索（UI 调整、交互试验、产品反复），工作流却要求产出一份“稳定的 Spec”，文档就会频繁失效，Agent 被迫反复回改。最终结果是花在维护文档上的时间比写代码还多。

常见痛点：

痛点	说明
前期文档成本过高	还没写代码就开始花大量时间维护文档
探索阶段不断回改	UI/交互频繁变化，Spec 一直失效
Agent 被文档一致性约束	每次改动都提示“请更新 spec/plan”
Plan 粒度过细	写到组件、文件甚至函数级，稍有变化即失效
Spec 混入实现细节	把 UI 布局、组件选择写进 Spec，实现一变就要改
文档驱动开发	先完善文档再编码，降低前端快速迭代的效率

更深层的问题：很多工作流是：

需求 → Spec → Plan → Implement

但真实的前端开发通常是这样：

需求 → 不知道怎么做 → 试一下 → 改一下 → 再试一下 → 产品确认 → 正式开发

也就是说，需求尚未收敛时，工作流却要求产出一份稳定的 Spec。文档要求稳定，需求却还在变化，这就是根本矛盾。

因此，工作流不应该按“前端/后端”“CRUD/活动页”这类项目类型固定套模板，而应该按需求稳定性选择模式。

二、模型：需求稳定性三分法

核心结论：决定流程的不是项目类型，而是需求稳定性。

按需求稳定性将工作分为三类：

模式	需求状态	适用场景	流程	文档策略
模式一：需求已确定	目标、边界、接口、验收标准已经明确	CRUD、后台管理、权限、登录、SDK、公共组件	Spec → Plan → Implement	Spec 先写，Plan 存在，进入正式开发
模式二：需求探索	目标方向存在，但 UI、交互、体验方案尚未收敛	UI、交互、动画、Dashboard、活动页	Prototype → Review → Prototype → Review → Prototype → Implement → Spec	Prototype 优先，Spec 最后沉淀，Plan 可以不存在，不使用 Patch
模式三：已有 Spec，小范围修改	需求主体稳定，只发生局部演进	字段调整、样式修改、新增一个小功能、文案修改	Spec → Plan → Implement → Patch → Implement → Patch → Release → Merge Patch → Spec vNext	Patch 追加变更，版本结束后合并进 Spec vNext

这三个模式不是按项目类型硬切分。同一个后台页面里，列表查询可能属于“需求已确定”，一个复杂筛选器的交互可能进入“需求探索”，上线前新增字段则属于“已有 Spec，小范围修改”。

2.1 模式一：需求已确定

当字段、接口、权限、业务规则和验收标准都已有明确设计时，完整走：

Spec
↓
Plan
↓
Implement

适用场景包括：

CRUD
后台管理
权限
登录
SDK
公共组件

这个模式的特点是：Spec 先写，Plan 存在，进入正式开发。Spec 定义目标和边界，Plan 拆分模块和依赖，Agent 按计划实施。这个流程稳定、可追踪，后期复盘也有据可查。

2.2 模式二：需求探索

当交互方案没定、UI 布局需要试几个版本、产品还需要看效果再判断时，强制写 Spec 就是在预判一个还没确定的结果。更合适的做法是直接进入 Prototype 阶段，快速实现一个版本，验证方案，然后推翻或调整，直到需求收敛。

流程是：

Prototype
↓
Review
↓
Prototype
↓
Review
↓
Prototype
↓
Implement
↓
Spec（最终沉淀）

适用场景包括：

UI
交互
动画
Dashboard
活动页

Prototype 是一个探索活动，不是文档类型。核心活动是快速编码验证，可选产出 Prototype Notes（轻量现场记录），但不是强制输出。

探索阶段的最大原则是：不要为了维护 Spec 而放慢探索速度。

在这个阶段，Spec 最后补，Plan 可以不存在，也不使用 Patch。因为 Patch 的前提是已有稳定 Spec，而探索阶段恰恰还没有稳定需求。如果每试一次 UI 都补一次 Patch，本质上还是把探索阶段错误地拉回文档维护。

探索阶段的出口有两种：

正向确认：产品或开发者看了之后确认“就这样”，进入交付阶段。
负向终止：发现方案有明显缺陷，决定终止，不浪费后续开发。

方案确认后，再补一份事后 Spec：一句话功能目标 + 验收标准 + 接口契约（可精简）+ 技术栈约束。它只沉淀已确认的内容，不回填探索过程中被推翻的临时方案。

2.3 模式三：已有 Spec，小范围修改

当已有 Spec 描述的需求主体仍然稳定，只发生字段增减、文案调整、样式微调、新增一个小功能这类局部变化时，不需要重新写 Spec 和 Plan，而是采用 Patch 工作模式。

流程是：

Spec
↓
Plan
↓
Implement
↓
Patch
↓
Implement
↓
Patch
↓
Release
↓
Merge Patch
↓
Spec vNext

这个模式的重点是：Patch 是演进机制，不是重新写 Spec。开发过程中，Agent 使用：

Spec
+
Patch

而不是不停修改 Spec。

三、Spec 的职责

Spec 不是“要么完整要么不写”的二元选择，而是记录已经确认的事实。它描述的是 Behavior，不是 Implementation。

Spec 应记录：

功能目标
验收标准
接口契约
技术约束

Spec 不应记录还没确认或容易变化的实现细节：

UI 放左还是右
Button 用 Antd 还是自定义组件
Header 放几列
某个组件具体拆成几个文件

Spec 的详细程度

Spec 可以按稳定程度调节详细级别：

级别	内容	适用场景
最简	一句话目标 + 验收标准	探索后的总结 Spec、小改动
中等	加上接口契约/数据流 + 技术栈约束	需求骨架已定但细节不确定
完整	加上必要的业务流程、权限、状态、异常分支	完全确定的需求

Spec 的底线

不论哪个级别，以下四项不可省略：

一句话功能目标
验收标准（可测试的条件）
接口契约 / 数据流（可精简但不能缺失）
技术栈约束

如果一个信息只是实现选择，而不影响功能目标、接口契约或验收标准，通常不应该写进 Spec。

四、Plan 的职责

Plan 不是实施步骤。以下不是 Plan：

创建 Header.vue → 创建 Login.vue → 修改 xx.ts

这是 Implementation Checklist，不是 Plan。

真正的 Plan 应该回答：

需要完成哪些模块？
模块之间有什么依赖？
哪些可以并行？

Plan 的粒度保持在模块级，例如：

认证模块：负责登录、刷新 token、退出和鉴权状态恢复。
权限模块：负责菜单权限、按钮权限和路由守卫。
页面模块：负责列表查询、详情查看、编辑弹窗和提交反馈。
接口模块：负责请求封装、错误处理、下载或上传约定。

Plan 不应该规定每个文件怎么改，也不应该替代编码清单。在需求探索场景下，Plan 可以不存在，直接从 Prototype 进入 Implement；在需求已确定场景下，Plan 才有稳定价值。

五、Patch 的职责

Patch 是追加变更，不是覆盖 Spec。

当已有 Spec 仍然有效，但开发中出现小范围变更时，应该新增 Patch 来描述增量，而不是反复改写原 Spec。这样做的好处是：每次变更都有来源、有原因、有影响范围，Agent 能读到完整上下文，人也能追踪需求为什么演进。

Patch 推荐固定四部分：

部分	回答的问题
Why	为什么改
Change	改什么
Impact	影响哪些文档、模块、接口或验收标准
Implementation	如何实施

示例结构：

## Patch 2026-07-20：新增状态筛选字段

### Why
运营需要按启用状态快速筛选账号，减少人工排查成本。

### Change
查询区新增 `status` 字段，支持全部、启用、停用。

### Impact
影响用户列表查询接口参数、列表页查询表单和验收标准。

### Implementation
复用现有字典枚举；提交查询时仅在非空状态下传 `status`。

Patch 会越来越多，这是正常现象。它类似 Git Commit：记录每一次演进，不要求每次都把历史整理成最终形态。

版本结束时再做：

Merge Patch
↓
Spec vNext
↓
清空 Patch

也就是说，Patch 类似 Git Commit，Spec vNext 类似 Squash。开发期保留增量历史，发布后再把有效 Patch 合并进新版 Spec，让长期文档重新变干净。

六、Prototype 的定位

Prototype 不是文档，而是一种探索活动。

它的目的不是沉淀设计，而是快速验证需求：

这个交互是否成立？
这个布局是否能承载信息密度？
这个动画是否干扰操作？
Dashboard 的指标组织是否符合阅读顺序？
活动页的视觉方向是否可接受？

Prototype 的输出可以没有任何文档。最多只产生 Prototype Notes，用来记录现场判断、被否掉的方向、临时约束或下一轮要试的点。

Prototype Notes 不应该升级成正式 Spec。只有当需求稳定后，才把已经确认的事实沉淀进 Spec。

七、Ticket 与 Task 的区别

在 AI Coding 工作流里，推荐用 Ticket 替代传统 Task 来组织开发。

Task 更像 Implementation Checklist，回答的是：

下一步写什么代码？

例如：

创建查询表单
接入列表接口
增加导出按钮
修改详情弹窗字段

Ticket 更像 Project Slice，回答的是：

整个项目如何组织开发？

一个 Ticket 应该具备项目切片能力：

可以独立交付
可以独立 Merge
可以独立 Review
可以分配给不同 Agent
可以存在 Blocked By

Task 适合单个 Agent 在实现过程中自我推进；Ticket 适合多人、多 Agent 或多阶段协作。对于 AI Coding，Ticket 比传统 Task 更适合作为交付单位，因为它能表达边界、依赖、验收和阻塞关系，而不仅是 TODO。

八、AI Agent 的判断边界

这个模型也为 Agent Prompt 的设计提供了规则参考。

Agent 可以自主推进：

UI 微调
命名修改
组件替换
文件拆分
局部样式优化
不改变行为的实现重排

这些属于实现层面的振幅，通常无需更新 Spec。

只有影响以下内容时，Agent 才需要停下来，由人重新判断：

功能目标
接口契约
验收标准

停下来后，要判断当前变化属于哪一类：

需求还没确定：进入 Prototype。
已有 Spec 仍然有效，只是局部演进：新增 Patch。
原 Spec 的目标、边界或验收已经失效：重新写 Spec。

分类可中途变更：同一个任务的不同子模块可以处于不同的稳定性分类。假如一个需求按“已确定”写了 Spec 和 Plan，实施中产品决定某部分 UI 换方案，已有文档的稳定部分保留，变化部分切到 Prototype 探索模式。

九、完整生命周期

最终工作流不是单一线性流程，而是一个从探索到沉淀再到演进的生命周期：

探索阶段
↓
Prototype
↓
需求稳定
↓
Spec
↓
Plan
↓
Ticket
↓
Implement
↓
Patch
↓
Release
↓
Merge Patch
↓
Spec vNext

这里有两个容易混淆的点：

阶段	解决的问题	是否要求稳定 Spec
Prototype	需求还没确定	不要求
Patch	需求已经确定，但持续演进	要求已有 Spec

Prototype 与 Patch 是两个不同阶段，不要混为一种流程。

Prototype 解决的是“需求还没确定”，所以探索速度优先，文档最多轻量记录。Patch 解决的是“需求已经确定，但持续演进”，所以要保留变更原因、影响范围和实施方式。

十、最终模型

几种活动/文档的职责划分：

活动/文档	真正职责	什么时候产生
Prototype	探索方案、快速编码验证	需求不明确时，可选附 Prototype Notes
Spec	记录已确认的功能目标、接口契约、验收标准和技术约束	需求稳定后，或探索完成后沉淀
Plan	拆分模块、依赖和并行关系	开始正式开发前，需求探索场景可取消
Ticket	定义可独立交付、Review、Merge 的项目切片	正式开发组织阶段
Task	记录下一步具体编码动作	Agent 实施过程中
Patch	记录已有 Spec 上的增量变化	需求主体稳定但发生局部变更时
Review	验证是否达到 Spec / Patch 的验收要求	开发完成后或每轮 Prototype 后

这些职责边界清晰，不会互相覆盖：Spec 定义稳定事实，Plan 定义模块组织，Ticket 定义交付切片，Task 指向具体编码动作，Patch 记录增量演进，Prototype 承担探索。

核心原则一句话：原有工作流的问题，不是文档太多，而是把探索阶段和交付阶段混在了一起。

在探索阶段，允许快速试错，以 Prototype 活动为主，不要求维护稳定文档。在交付阶段，才沉淀 Spec、Plan 和 Ticket，使它们成为长期有效的项目资产。进入持续演进阶段后，用 Patch 记录增量变化，并在版本结束时合并为 Spec vNext。

posted @ 2026-07-20 15:44 bleemyoung 阅读(18) 评论(1) 收藏举报

刷新页面返回顶部

bleemyoung