原型、功能初版和可验收版本

AI 辅助开发中，“初版”“验证通过”“可以交付”经常被混成一件事。实际上至少要区分两个维度：

text

产品成熟度
= 现在这套软件已经做到哪一步？

Verification Level（V0–V4）
= 这一次修改需要验证到多深？

产品版本号 0.3 / 1.0 和 V10 的验证等级 V0 / V1 / V2 / V3 / V4 没有对应关系。

1. 四种常见产品成熟度

界面原型

用于确认：

信息结构；
页面布局；
大致操作入口；
视觉方向。

可能只有静态按钮和占位数据。

不能证明：

通信可用；
数据正确；
设备动作正确；
异常恢复有效。

可交互原型

按钮和状态可以模拟变化，适合验证：

用户操作流程；
页面跳转；
状态表现；
操作员反馈。

但如果使用 Fake/模拟数据，必须明确标注。它仍不代表真实设备行为已经验证。

功能初版

核心业务闭环已经接通，例如：

text

输入/任务
→ 业务流程
→ 通信/数据
→ UI/保存

可以使用 Fake、Replay、模拟器或部分真实设备验证。

此阶段通常仍可能缺：

完整异常恢复；
长时间运行证据；
历史兼容验证；
真机高风险场景；
发布/部署验收。

所以“功能初版能跑”不能直接写成“可交付”。

可验收版本

可验收不是一个视觉或代码状态，而是当前合同/需求范围有足够证据。

至少要知道：

text

Requirements covered
Verification evidence
Hardware evidence（如果需求需要）
Known pending items
Environment blockers
Residual risks

如果要求真实高压、运动或其它设备动作，而这些还没执行，就应保持：

text

HardwarePending

不能因为 Fake/Replay 通过就写“真机验收完成”。

2. 产品版本号只是版本管理，不是验证等级

项目可以自己定义：

text

0.1  UI/交互原型
0.2  最小业务闭环
0.3  通信接入
0.4  数据与异常恢复
0.8  现场联调候选
1.0  正式发布

这只是一个示例，不是强制顺序。

不要把它和：

text

V0 静态
V1 affected build
V2 focused device/data/communication
V3 workflow/interlock/state
V4 release/full checkpoint

混在一起。

为了减少歧义，文档中推荐写：

text

ProductVersion: 0.4
VerificationLevel: V2

而不是只写“当前 V2”。

3. 同一个产品版本里可以有不同 Verification Level

例如产品已经到 1.0：

改一个按钮文案

text

ProductVersion: 1.0.3
Task: UI MicroPatch
VerificationLevel: V0

不需要因为它是正式产品就每次完整回归。

修改过流联锁

text

ProductVersion: 1.0.4
Task: BehaviorPatch
VerificationLevel: V3

即使改动只有几十行，也因为控制后果高风险而需要更强证据。

所以：

产品成熟度不能代替任务风险判断。

4. 模拟数据必须标明来源

推荐明确区分：

数据类型	含义
UI Demo Data	只为了页面展示
Fake/Simulation	为软件行为验证构造的数据/设备
Captured Replay	从真实场景捕获后回放的输入
Real Device Data	真实设备返回的数据
Production/Acceptance Data	正式现场或验收过程产生的数据

不要写一个笼统的“测试数据”，让后来的人无法判断证据强度。

5. 模拟数据的红线

不用随机值冒充真实测量结果；
不用固定 Online 状态冒充设备已连接；
不用演示历史记录冒充正式持久化完成；
客户/评审演示时明确哪些数据来自 Fake；
正式文档中区分 Verified / Unverified / EnvironmentBlocked / HardwarePending / DesignOnly；
Replay 能证明软件面对某组真实输入的行为，但不自动证明设备端当前状态。

6. “编译通过”只是一个证据，不是成熟度

下面这些不是严格的线性状态链：

text

编译证据
模拟证据
真机证据
回归证据

现实里可能是：

text

AffectedBuild: Verified
FocusedTests: Verified
Replay: Verified
RealHardware: HardwarePending

也可能是：

text

AffectedBuild: EnvironmentBlocked
FocusedTests: Verified
RealHardware: NotRequired

所以推荐把验证结果分开记录，而不是把整个功能压成一个“已验证”标签。

7. 可验收版本看 Evidence Map

对正式交付，建议用最小追踪关系：

text

Requirement
→ Design / Implementation
→ Verification Method
→ Actual Evidence
→ Status

状态可以是：

Verified；
Unverified；
EnvironmentBlocked；
HardwarePending；
NotApplicable。

技术文档中也使用同一证据口径，避免软件说“完成”、报告又说“待验证”。

详见技术文档工程。

8. 原型到正式版不必按固定技术顺序

不要机械规定：

text

先 UI
→ 再通信
→ 再数据库
→ 再异常

更好的方式是按最小业务闭环推进。

例如测试设备软件：

text

Fake 设备 + 最小启动流程 + 结果展示
→ 真实通信 Session
→ 参数应用闭环
→ 数据保存
→ 异常恢复
→ 真机验收

每一个阶段都应该能证明一项真实能力，而不是只“完成一层代码”。

9. 真实设备安全仍然独立

“这是 1.0 发布候选”也不意味着 Agent 可以自动执行高压、电机、阀门等动作。

真实设备状态改变仍需要单独授权，高风险动作保持 HITL。

详见真实设备操作与验证安全边界。

10. 推荐项目状态写法

text

ProductVersion: 0.6
Maturity: FunctionalBeta
TaskType: BehaviorPatch
VerificationLevel: V3
AffectedBuild: Verified
FocusedTests: Verified
WorkflowSmoke: Verified
RealHardware: HardwarePending
KnownRisks:
- 真机断线恢复尚未现场验证

这种写法比“V0.6 已完成”更准确。

下一步

一句话原则

产品版本回答“软件成熟到哪一步”，V0–V4 回答“这次修改需要验证多深”；两者独立，最终交付必须看实际证据而不是版本号或一句‘真机测过’。

原型、功能初版和可验收版本 ​

1. 四种常见产品成熟度 ​

界面原型 ​

可交互原型 ​

功能初版 ​

可验收版本 ​

2. 产品版本号只是版本管理，不是验证等级 ​

3. 同一个产品版本里可以有不同 Verification Level ​

改一个按钮文案 ​

修改过流联锁 ​

4. 模拟数据必须标明来源 ​

5. 模拟数据的红线 ​

6. “编译通过”只是一个证据，不是成熟度 ​

7. 可验收版本看 Evidence Map ​

8. 原型到正式版不必按固定技术顺序 ​

9. 真实设备安全仍然独立 ​

10. 推荐项目状态写法 ​

下一步 ​

一句话原则 ​

原型、功能初版和可验收版本

1. 四种常见产品成熟度

界面原型

可交互原型

功能初版

可验收版本

2. 产品版本号只是版本管理，不是验证等级

3. 同一个产品版本里可以有不同 Verification Level

改一个按钮文案

修改过流联锁

4. 模拟数据必须标明来源

5. 模拟数据的红线

6. “编译通过”只是一个证据，不是成熟度

7. 可验收版本看 Evidence Map

8. 原型到正式版不必按固定技术顺序

9. 真实设备安全仍然独立

10. 推荐项目状态写法

下一步

一句话原则