I SEE YOU

为什么我认为 AI 短剧可能是最适合生成式 AI 的内容形态

Fri, 11 Sep 2026 00:00:00 GMT

最近我在尝试不同类型的 AI 创作：AI 写小说、AI 写代码，以及 AI 短剧。

越往后做，我越觉得一个很有意思的结论正在变得清晰：

AI 短剧可能不是“AI 恰好能做的一种内容”，而是目前少数几个天然符合生成式 AI 工作方式的完整生产形态。

原因并不只是今天的视频模型越来越强，而是影视制作本身有几个非常特殊的属性：

可视、可拆、可重置、可筛选。

这四点，恰好把生成式 AI 最麻烦的几个问题——幻觉、不一致、不可控、随机性——从系统性风险，变成了可以被观察、隔离和重新生成的局部问题。

1. 我最初的感受：模型越自由，结果反而越惊艳

以我自己尝试 AI 短剧的过程为例：

视频生成统一使用 Seedance 2.5；
图片和人物资产使用 GPT Image；
分镜头设计也通过 GPT Image 完成。

一个很明显的现象是：

当 Seedance 2.5 不被加入太多限制时，它经常能生成非常出彩的结果。

镜头、光影、动作、微表情，甚至一些没有明确要求的细节，会出现很强的“导演感”。

但当我开始给它加入剧情、人物一致性、动作顺序、道具状态、场景限制之后，生成结果反而容易变平。

它完成了剧情。

但不一定有戏。

于是问题开始变得很明确：

不能让一个视频模型同时负责理解剧情、导演、摄影、演员表演、美术和连续性。

真正适合 AI 短剧的方式，不是把剧本直接交给模型，而是把这些职责拆开。

2. AI 短剧真正适合的是“受控生成”

一个成熟的 AI 短剧流程，应该逐渐从：

剧本
  ↓
Prompt
  ↓
视频

变成：

剧本
  ↓
剧情 Beat
  ↓
导演拆解
  ↓
人物 / 场景 / 道具资产
  ↓
Blocking（人物与镜头调度）
  ↓
Storyboard（分镜）
  ↓
Production Keyframe（关键帧）
  ↓
视频生成
  ↓
Take 筛选
  ↓
粗剪
  ↓
补镜 / 重拍
  ↓
成片

这里真正重要的已经不是“Prompt 写得多漂亮”，而是：

剧情中哪些东西必须被锁死，哪些东西应该留给模型自由发挥。

我更喜欢把这种方法理解成：

Macro Control + Micro Freedom

也就是：

宏观锁死，微观放权。

必须锁死的包括：

人物身份；
服装；
场景；
道具；
人物初始位置；
镜头景别；
关键动作；
镜头结束时必须达到的状态。

而可以交给模型发挥的包括：

呼吸；
眼神；
微表情；
头发和衣料的运动；
非关键的小动作；
轻微的镜头漂移；
环境中的自然动态。

这样，AI 的不可控并不会消失。

但不可控的部分被限制在了一个安全的范围内。

甚至，模型的随机性反而会变成一种表演资源。

3. “抽卡”不是缺陷，它很像真人拍摄中的“再来一条”

过去我们往往把生成模型的随机性看成问题。

同样的输入，每次生成都会有差异。

但如果放到影视生产里，它其实很像一件非常传统的事情：

Take 1、Take 2、Take 3……

真人拍摄时，导演本来就会说：

“再来一条。”

演员每一遍的停顿、眼神、呼吸、动作都会不同。

最终挑出最好的一条。

生成式视频也是一样。

如果一个镜头的宏观状态已经被锁定：

State A
  ↓
人物表演
  ↓
State B

那么模型中间产生的随机性就不再是“错误”，而是：

Sampling Space。

一次生成五个 Take：

Take 01
Take 02
Take 03
Take 04
Take 05

然后选最有表现力的一条。

从这个角度看，AI 的随机性甚至和影视工业天然兼容。

4. 剧情应该由剪辑完成，而不是由单个生成任务完成

这是我现在越来越认同的一条原则：

剧情由剪辑完成，表演由镜头完成。

比如一个剧情是：

女主推开办公室门，看见丈夫正在替另一个女人戴项链。她愣住，没有哭，只是慢慢攥紧手里的检查报告。

如果直接交给视频模型，它需要同时完成：

女主进入；
丈夫和另一个女人的位置；
戴项链动作；
女主的发现；
情绪变化；
检查报告；
镜头设计；
人物一致性。

最后往往会变成一个“把事情演完”的镜头。

但如果拆成：

SHOT 01
女主走向办公室。

CUT

SHOT 02
门缝视角，男人替女人戴项链。

CUT

SHOT 03
项链扣合特写。

CUT

SHOT 04
女主停住。

CUT

SHOT 05
检查报告被慢慢攥皱。

CUT

SHOT 06
眼睛微微泛红，但没有流泪。

模型的任务突然变得非常简单。

每一个镜头只需要负责：

一个信息 + 一个动作 + 一个情绪变化。

而剧情的完整性由剪辑来恢复。

这恰好非常适合生成式 AI。

5. 剪辑甚至可以“合理化”AI 的能力边界

如果模型很难一次生成：

男人走进房间 → 拿起杯子 → 倒酒 → 转身 → 开口说话。

那就不要让它做。

可以变成：

SHOT 01
男人走进房间。

CUT

SHOT 02
酒倒进杯子的特写。

CUT

SHOT 03
男人已经拿着酒杯。

CUT

SHOT 04
男人说话。

从生成模型的角度看，这是四个独立任务。

但从观众的角度看，它们会自然地被理解为一个连续事件。

电影剪辑一百多年来一直在利用人脑自动补全时间和空间的能力。

过去它主要用来压缩时间、组织叙事。

到了 AI 时代，它又多了一个新作用：

把模型无法稳定完成的复杂连续过程，拆成多个模型可以稳定完成的小任务。

所以短剧比长镜头电影更适合 AI，并不是偶然。

短剧本来就依赖快速剪辑、反打、特写、Reaction Shot、Insert Shot。

这些语言结构，本身就像是在不断给生成模型“重置世界”。

6. 和 AI 写小说相比：短剧最大的优势是“错误是可见的”

我之前也尝试过 AI 写小说。

小说真正麻烦的地方，不是模型不会写文字，而是：

长篇小说拥有大量不可见的隐状态。

比如：

人物到底 17 岁还是 19 岁；
A 一直称呼 B 为“哥”，还是叫名字；
第 23 章人物受过什么伤；
第 55 章他说过自己不吃什么；
第 102 章埋了什么伏笔；
某个人知道什么，另一个人不知道什么；
主角口袋里到底还有多少钱；
某个道具现在到底在谁手里；
两个人的关系现在发展到了什么阶段。

最麻烦的并不是这些状态多。

而是：

错误发生的时候，它不一定会立刻表现出来。

比如主角口袋里只剩 20 元，AI 却写了一句：

“老板，再来两斤牛肉。”

句子本身完全通顺。

人物也没有崩。

读者甚至不一定马上发现问题。

但世界状态已经错了。

几十章以后，这个错误可能会继续传播。

所以 AI 小说最终往往需要建立：

Character State；
World State；
Timeline；
Knowledge State；
Inventory；
Relationship Graph；
Foreshadowing / Promise Tracking。

也就是说，为了让小说保持一致，最后不得不建立一个越来越复杂的隐状态管理系统。

7. 和 AI 写代码相比：代码的问题是“错误虽然可验证，但不容易定位”

AI 写代码的体验又不同。

现在 Coding Agent 已经非常强。

它可以在很短的时间里：

修改十几个文件；
写几千行代码；
增加接口；
修改数据结构；
添加测试；
重构模块。

真正的问题开始从：

“AI 能不能写代码？”

变成：

“AI 一次性输出太多代码之后，人类还能不能理解系统发生了什么？”

程序员原本最大的优势之一，是可以在脑中维持项目结构。

但 Coding Agent 的代码生成速度已经远高于人类阅读和理解代码的速度。

于是会出现：

AI 对系统的修改速度 > 人脑重新建立系统模型的速度。

当 Bug 出现时，你看到的可能只是：

页面 A 出错

但实际原因可能是：

A
  → B
      → C
          → D

真正坏掉的是 C。

所以我现在在 AI Coding 上越来越关心的不是“让 AI 少写一点”，而是：

可视化、Observability、定位能力。

我可以不关心 AI 写出来的每个函数内部细节。

但当系统出问题时，我希望尽快看到：

哪个模块发生变化；
哪条调用链出现异常；
哪个状态和预期不一致；
哪次 Agent 修改引入了问题；
哪些问题可能来自同一个根因。

这实际上是在解决：

AI 大量生产代码之后，人类如何重新获得系统控制权。

8. 而 AI 短剧天然就是可视化的

AI 短剧最有意思的地方恰好在这里。

如果模型给人物右脸多生成了一道疤：

一眼就能看见。

如果上一镜人物穿的是黑色外套，下一镜变成白色：

一眼就能看见。

如果杯子上一镜在右手，下一镜在左手：

一眼就能看见。

如果门的位置突然从左边跑到了右边：

一眼就能看见。

甚至最重要的是：

我不一定需要知道模型为什么出错。

代码出了 Bug，往往还需要寻找根因，修复以后还要确认副作用。

AI 视频如果一个 Take 不对：

不用。

重新生成。

如果只有一个镜头不对：

SHOT 134  ✓
SHOT 135  ✕
SHOT 136  ✓

只重做 135。

错误的传播成本非常低。

9. 这让我想到一个衡量 AI 适用性的公式

一个领域到底适不适合生成式 AI，也许可以粗略理解成：

AI 价值 ≈ 生成能力 × 可验证性 × 可拆分性 ÷ 错误传播成本

AI 小说

生成能力：高
可验证性：低
可拆分性：一般
错误传播成本：很高

AI 代码

生成能力：极高
可验证性：理论上很高
可拆分性：中等到高
错误传播成本：中高，而且依赖关系复杂

AI 短剧

生成能力：快速上升
可验证性：极高
可拆分性：极高
错误传播成本：低

这也许才是 AI 短剧真正特殊的地方。

不是模型“更懂影视”。

而是这个问题空间本身，非常适合生成模型。

10. AI 短剧真正的生产单位，也许不是“视频”，而是“状态转换”

如果继续往工程方向抽象，我觉得一个镜头最适合描述成：

输入状态 State A
       ↓
发生一个动作 / 情绪变化 / 信息揭示
       ↓
输出状态 State B

比如：

SHOT 37

Input State:

Character:
LINWAN

Location:
Office Corridor

Right Hand:
Medical Report

Emotion:
Calm

Face:
Normal


Event:

看见丈夫正在替另一个女人戴项链


Output State:

Emotion:
Suppressed Shock

Eyes:
Slightly Red

Medical Report:
Crumpled 20%

Location:
Office Corridor

Seedance 真正需要负责的，只是：

如何把 State A 演到 State B。

中间到底怎么呼吸、怎么眨眼、怎么出现细微表情变化，可以让模型发挥。

这样一来，AI 的幻觉被限制在“表演空间”里。

而剧情本身不会跑掉。

11. 人物一致性最终也会变成一个“版本管理问题”

比如一个人物在剧情中受伤。

完全可以建立：

LINWAN_V1
EP01 - EP08
无伤

LINWAN_V2
EP09
右脸刚刚受伤

LINWAN_V3
EP10 - EP14
伤口结痂

LINWAN_V4
EP15+
留下淡疤

那么 EP12 的镜头自动使用：

LINWAN_V3

这比小说中的状态管理有一个巨大的优势：

人物状态本身就是可视化的。

你甚至不需要把所有信息都语言化。

传统数据库可能需要记录：

scar:
  position: right_cheek
  healing: 0.7
  color: ...

而 AI 短剧完全可以直接拿上一阶段已经确认过的人物图作为视觉事实。

所以 Production State 可以同时拥有两层：

Symbolic State
+
Visual State

Symbolic State

保存：

人物 ID；
服装 ID；
道具；
人物位置；
情绪；
当前剧情知识；
人物关系；
剧情阶段。

Visual State

保存：

人物参考图；
服装图；
场景图；
上一镜；
First Frame；
End Frame；
确认过的角色版本。

文字负责逻辑。

图片负责视觉事实。

两者一起控制视频生成。

12. 所以未来的核心可能不是 Prompt Engineering，而是 Shot Engineering

当模型越来越强以后，Prompt 本身很可能会逐渐贬值。

因为普通人也可以写：

女主发现丈夫出轨，非常悲伤。

但真正有镜头语言的人会知道：

SHOT A
先不给丈夫。

女主进入画面。

她的视线停住。

CUT

SHOT B
项链扣合特写。

CUT

SHOT C
女主眼神。

CUT

SHOT D
检查报告被慢慢攥皱。

CUT

SHOT E
最后才给丈夫。

这个差距并不是 Prompt 技巧。

而是：

什么时候应该给信息，什么时候不应该给。

什么时候用特写。

什么时候切 Reaction。

什么时候让人物不说话。

什么时候让观众比角色先知道。

什么时候让角色比观众先知道。

这才是真正的导演能力。

所以 AI 并没有消灭专业性。

恰恰相反：

执行门槛在极速下降，而审美和决策门槛正在上升。

过去一个人即使非常会讲故事，也需要：

摄影机；
灯光；
演员；
场地；
摄影；
美术；
后期；
大量资金。

未来这些门槛都可能大幅下降。

竞争最后越来越集中到：

你到底知不知道应该拍什么。

13. AI 导演、AI 制片人的门槛反而会越来越高

这也是我现在一个很明确的感觉。

很多人看到 AI 视频以后，会认为：

“以后人人都是导演。”

从“能把一个画面做出来”的意义上，也许是。

但从“能持续产出好作品”的意义上，不一定。

因为 AI 把执行成本降下来之后，过去被团队执行能力掩盖的专业差距会被放大。

一个真正懂镜头的人，会不断做这些决策：

这个信息什么时候出现；
这里应该切还是不切；
用 Wide 还是 Close-up；
这里是不是应该给一个 Reaction；
这一句台词是不是不说更好；
是否应该把一个连续动作拆成三镜；
哪个镜头应该让模型自由发挥；
哪个镜头必须严格控制；
哪个镜头值得抽 20 次；
哪个镜头 60 分就够；
哪些镜头看起来漂亮，但放进 Sequence 里没有意义。

所以真正的核心能力，会越来越从：

“怎么执行？”

转向：

“做什么？”以及“为什么这样做？”

14. 不应该逐镜头追求完美，而应该先保证 Sequence 成立

AI 视频还有一个很容易掉进去的坑：

每个镜头都抽到特别漂亮。

SHOT 01 抽 8 次。

终于很漂亮。

SHOT 02 抽 10 次。

也很漂亮。

SHOT 03 再抽。

最后每个镜头单独拿出来都像广告片。

但剪在一起却不好看。

因为影视真正的单位从来不是单个 Shot。

而是：

Sequence。

所以更合理的工作方式应该是：

第一阶段

整集所有镜头快速做到 60～70 分。

马上粗剪。

第二阶段

看完整 Sequence：

哪个镜头多余；
哪个镜头太长；
哪个地方缺 Reaction；
哪个信息出现太早；
哪个节奏断掉；
哪个镜头应该被替换。

第三阶段

只重做真正重要的 Hero Shot。

这样既能控制成本，也避免陷入“局部最优”。

15. 这让我想到：AI 短剧最终需要的可能不是生成平台，而是 Production IDE

如果从产品角度继续往下推，我越来越不看好纯粹的：

“输入一个剧本，一键生成整部短剧。”

它演示起来很震撼。

但真正生产时，很难给专业团队足够的控制能力。

我更期待的是一种：

Visual Production IDE。

它可能长得更像：

EP01
 ├── Scene 01
 │    ├── Shot 001   ✓
 │    ├── Shot 002   ✓
 │    ├── Shot 003   ⚠
 │    └── Shot 004   ✓
 │
 └── Scene 02

点击 Shot 003：

Continuity Warning

Character:
LINWAN            ✓

Wardrobe:
OFFICE_A          ✓

Scene:
OFFICE_V3         ✓

Prop:
Medical Report    ⚠

Previous Shot:
Right Hand

Current Shot:
Left Hand

再往下：

Take 01   ★★★☆☆
Take 02   ★★★★★   Selected
Take 03   ★★☆☆☆
Take 04   Face Error

旁边还有：

Narrative Coverage

Beat 01   ✓
发现异常

Beat 02   ✓
项链信息

Beat 03   ⚠
女主情绪反应不足

Beat 04   ✓
检查报告

对于导演来说，他甚至不需要看到最终 Prompt。

他真正关心的是：

景别；
镜头运动；
人物站位；
情绪；
注意力方向；
信息暴露；
节奏；
Entry State；
Exit State。

系统再把这些信息转换成具体模型需要的 Prompt。

这样以后即使底层从 Seedance 2.5 换成下一代 Seedance、Veo 或其他模型，上层工作流也不需要推倒重来。

16. AI 短剧和 AI Coding，其实在解决同一个问题

表面上看：

一个是代码。

一个是影视。

但我现在越来越觉得，它们底层其实在面对同一件事：

当 AI 的生成速度远高于人的理解和执行速度之后，人类如何继续保持控制权？

AI Coding 需要：

可观察；
可定位；
可追踪；
可回滚；
可验证。

AI 短剧也一样：

哪个 Shot 有问题；
哪个人物状态错了；
哪个 Take 被选中；
哪个道具出现了连续性错误；
哪个 Beat 没有被视觉覆盖；
哪个镜头成本异常；
哪个角色版本正在生效；
哪一次生成改变了什么。

所以 AI 时代真正稀缺的东西，也许越来越不是“生成”。

而是：

控制、观察、诊断和决策。

17. 一个可能非常重要的结论

过去我们很自然地认为：

AI 首先是语言模型，所以 AI 最适合文字。

但从真正的大规模生产角度，也许并不是。

生成式 AI 更适合的，可能是：

那些生成结果可以被人类快速验证，而且错误能够被局部隔离和重新生成的领域。

而视频恰好拥有这些特征。

AI 不需要一次性生成一个绝对正确的世界。

它只需要：

在一个被定义好的局部状态中，生成足够好的下一段。

错了就丢。

不够好就再抽一条。

状态变了就更新角色版本。

连续性错了就重做一个 Shot。

剧情本身通过 Beat、Shot 和剪辑牢牢控制。

这可能才是 AI 短剧真正的优势。

结语：AI 没有降低“导演”的价值，而是重新定义了导演的价值

AI 短剧最让我感兴趣的地方，不是：

“以后不用真人拍摄了。”

而是影视制作正在发生一次非常彻底的重新分工。

AI 越来越负责：

怎么把东西做出来。

人越来越负责：

到底应该做什么。

模型负责生成。

系统负责保持状态。

剪辑负责组织剧情。

导演负责做选择。

而一个成熟的 AI 短剧生产系统，最终可能不再像一个 Prompt 输入框。

它更像：

影视行业的 IDE。

在这个 IDE 里，每一个 Episode、Scene、Beat、Shot、Take、Character State、Visual State 都是可以被观察、修改、版本化和回滚的。

当这种生产方式真正成熟以后，所谓“AI 短剧”也许就不会再是一个独立概念了。

它只是影视生产进入了一个新的阶段：

从拍摄驱动，变成状态管理 + 生成 + 筛选 + 剪辑驱动。

而这也许才是生成式 AI 最擅长的工作方式。

软件过剩之后：AI 时代真正稀缺的，也许是匹配、判断与信任

Tue, 08 Sep 2026 00:00:00 GMT

最近我一直在想一个问题：

如果 AI 让软件开发越来越容易，未来的软件还会像今天这样赚钱吗？

一开始，我只是从个人收入出发思考：怎样让收入不再完全绑定自己的劳动时间？作为开发者，最自然的答案似乎是做产品、做 SaaS、做一个可以重复出售的软件。

但继续往下想，问题开始变得复杂。

因为软件行业本身正在发生变化。

Vibe Coding 让开发门槛快速下降，一个过去需要几周甚至几个月才能完成的小工具，现在可能几小时、几天就能做出来。大量极其小众、极其个性化的软件会不断出现。

与此同时，经济压力又让人越来越关注性价比。

于是一个很现实的问题出现了：

如果一个软件只是“有某个功能”，用户为什么还要为它付钱？

免费软件、开源软件、个人开发者的小工具，甚至让 AI 临时生成一个程序，都可能成为替代方案。

这让我开始怀疑：

未来真正稀缺的，也许不是“软件功能”，而是别的东西。

一、软件正在从稀缺走向过剩

过去的软件市场有一个很重要的前提：

做软件很贵。

开发需要程序员、产品经理、设计、测试，需要相当长的时间。

因此，哪怕一个需求真实存在，只要用户数量不够大，也往往没人愿意开发。

这天然限制了软件供给。

但 Vibe Coding 正在改变这件事。

未来可能会出现大量这样的软件：

只解决一个很窄的问题；
只服务几十、几百甚至几个用户；
由个人在很短时间内完成；
免费、开源或者价格极低；
生命周期可能很短，但供给数量非常大。

也就是说：

软件制造成本下降，软件供给快速膨胀。

这听起来对用户是一件好事。

但供给从“不够”走向“过剩”以后，会产生一个新的问题：

东西太多了。

二、真正稀缺的开始变成注意力

我自己的消费习惯其实很能说明这个问题。

在中国，很多实体商品已经便宜到难以想象。

如果一个东西不重要，我往往两眼扫过去，差不多能用，就挑便宜的。

如果有一些时间，我可能会仔细比较参数、评价、性能和可靠性，希望找到一个“尽可能便宜，但又足够好”的东西。

而如果这个东西非常重要，或者买错的损失很大，我通常会更愿意买成熟品牌。

这背后的逻辑不是单纯的“消费降级”。

更像是：

失败成本低时，我追求最低成本；失败成本高时，我愿意为确定性付钱。

我开始觉得，未来的软件也会越来越像这样。

不重要的软件需求

例如：

临时拆一个 PDF；
批量改一次文件名；
转换一个格式；
偶尔压缩几张图片；
做一个一次性的小工具。

这种需求很可能越来越难收费。

用户会优先：

找免费的 → 找开源的 → 问 AI → 临时生成一个。

功能本身会越来越廉价。

重要的软件需求

但如果一个软件承载的是：

多年的数据；
客户项目；
财务；
工作流；
专业生产资料；
核心业务；

用户考虑的问题马上就变了。

他关心的会变成：

它会不会突然坏？
数据会不会丢？
明年还维护吗？
新版本系统还能运行吗？
有问题谁负责？
数据以后能不能迁出去？
我能不能长期依赖它？

这时候，“免费”不再是唯一优势。

用户真正买的是：

我敢不敢把重要的事情交给它。

三、软件和实体商品还有一个不可调和的区别

这也是我后来觉得最重要的一点：

软件比实体商品难理解得多。

一把椅子、一件衣服、一台显示器，用户通常很容易理解它是干什么的。

看尺寸、价格、材质、图片、评价，大致就能形成判断。

软件不是。

一个软件到底适不适合我，可能要看：

功能说明；
截图；
教程；
视频；
版本记录；
操作系统兼容性；
支持的文件格式；
免费版和付费版区别；
用户评价；
实际下载安装；
拿自己的数据测试。

最后才能知道：

它到底能不能完成“我的这个具体任务”。

软件的价值更像一个函数：

软件价值 =
用户
× 具体任务
× 数据
× 使用习惯
× 系统环境
× 软件版本
× 技能水平
× 其他工具

这就是为什么同一个软件可以出现完全相反的评价。

一个视频工具，对某个人来说，最重要的是自动加字幕。

对另一个人来说，最重要的是批量处理。

对我来说，也许关心的是硬件解码、编解码格式、metadata 和 GPU 支持。

大家讨论的虽然是同一个软件，实际上评价的是完全不同的东西。

所以简单的：

⭐ 4.8 / 5

对软件而言，信息量远没有实体商品那么高。

真正有价值的信息往往是：

“在某个 Windows 版本、某种 GPU、某种文件格式下，这个具体功能是否正常。”

但这样的信息，又只对很少一部分人有用。

这导致软件天然存在严重的匹配问题。

四、这也许能解释为什么很多优秀开源软件依然非常小众

很多开源项目并不是能力不够。

恰恰相反，它们可能：

性能很好；
功能很强；
完全免费；
没广告；
代码质量也不错。

但用户打开 GitHub 后看到的是：

Installation

pip install xxx

Requires:
Python >= 3.x
libxxx
...

普通用户很可能直接关掉。

旁边有一个商业软件，首页只有一句：

“把照片拖进来，自动整理完成。”

再配一个 15 秒演示视频。

用户马上知道：

“对，这就是我要的。”

第二个软件未必技术更强。

但它完成了一件非常重要的事情：

把能力变成了用户可以识别的价值。

所以很多软件的问题并不是：

“没有需求。”

而是：

能力存在，但能力和需求没有完成匹配。

开发者描述的是：

“我拥有什么 capability。”

用户想表达的是：

“我想得到什么 outcome。”

中间存在巨大的语义鸿沟。

五、AI 会解决搜索问题，但不一定解决判断问题

AI 看起来天然适合解决这件事。

以前我可能需要 Google 两小时：

“有没有一个软件可以完成 XXX？”

现在问 AI，10 秒钟就能得到几个名字。

搜索成本确实下降了。

但马上又出现下一批问题：

它真的支持吗？
这个功能是免费版的吗？
Windows 版本支持吗？
两年没更新了还能用吗？
会不会改坏我的原文件？
AI 推荐的软件名字是不是它编出来的？
文档写支持，但我的场景到底能不能用？

于是：

Search Cost 下降了，Evaluation Cost 并没有同步消失。

甚至可能出现一个反直觉的现象：

软件制造成本 ↓
软件数量 ↑
搜索成本 ↓
候选数量 ↑
判断成本 ↑

过去只有 10 个软件，一个个试还能接受。

未来有 1000 个。

这时候“更多选择”本身反而变成负担。

六、从 Search Economy 到 Matching Economy

后来我想到一个很有意思的例子：婚恋。

传统婚恋平台的逻辑是：

给你更多人 → 你自己筛 → 你自己聊 → 你自己判断。

但人与人之间的适配是典型的高维问题。

年龄、学历、收入、城市，都只能描述极少的一部分。

真正重要的可能是：

消费观；
生活节奏；
是否想要孩子；
对家庭关系的理解；
风险偏好；
沟通习惯；
对事业和生活的排序。

这些东西过去很难结构化。

AI 的出现第一次让平台有机会通过长对话去理解一个人，然后：

减少推荐，而不是增加推荐。

这让我意识到，也许未来会出现一类非常重要的 AI 产品：

它们不是帮用户获得更多选择，而是帮用户拒绝绝大多数错误选择。

这和过去互联网的方向几乎相反。

过去：

更多商品
更多内容
更多候选人
更多软件
更多信息

未来一部分 AI 产品的价值也许是：

理解你
↓
筛选
↓
减少候选
↓
解释差异
↓
帮助决策

我愿意把这种变化称为：

从 Search Economy 走向 Matching Economy。

七、招聘可能也是典型场景

招聘和婚恋在结构上其实非常像。

传统招聘平台匹配的是：

学历
工作年限
技能
薪资
城市

但真正决定一个员工半年以后会不会离开的，可能是：

老板管理得有多细；
工作节奏是否稳定；
是否经常临时加班；
员工希望自主还是被明确管理；
是更重视成长还是稳定；
对风险、晋升和收入的排序；
对冲突和反馈的接受方式。

这些信息，JD 和简历几乎都写不出来。

如果 AI 分别和老板、候选人深入交流，它也许能做的并不是：

“给你一个 92% 的匹配分。”

而是：

你们技能匹配，但工作节奏明显冲突。

薪资没有问题，但管理方式很可能产生矛盾。

如果要继续面试，最应该确认的是这两个问题。

真正值钱的可能不是“帮 HR 更快看简历”。

而是：

减少本来就不应该发生的面试和错误入职。

因为错误匹配本身有非常明确的经济成本。

八、高维匹配市场可能具有一组共同特征

继续往下推，我觉得值得关注的不是“AI 婚恋”“AI 招聘”这些具体标签。

而是一类市场。

它们通常具有下面这些特征：

1. 供给已经很多

人、软件、服务商、课程、商品、岗位……

用户并不缺候选。

2. 很难用少量参数描述

几个字段无法真正表达供需双方。

3. 用户自己也很难准确描述需求

往往需要被追问以后，才知道自己真正重视什么。

4. 筛选非常耗时间

候选越多，负担越大。

5. 选错具有明显成本

钱、时间、机会、数据或者长期关系。

6. 用户真正想要的是少数好结果

不是 100 个候选。

而是：

“给我 3 个真正值得看的。”

7. 匹配以后能够获得结果反馈

例如：

招聘推荐
→ 面试
→ Offer
→ 入职
→ 6 个月
→ 是否还满意

一旦存在这个反馈闭环，就可能形成真正的数据资产。

九、这对软件意味着什么？

软件可能也属于这种高维匹配市场。

未来用户也许越来越不会搜索：

“给我推荐一个视频软件。”

而是直接表达任务：

“我有几百个某种格式的视频，希望在某个 GPU 上批量转换，同时保留某些 metadata，不能修改源文件。”

此时真正需要匹配的已经不是：

App Category → App

而是：

Task → Capability → Solution

软件本身可能逐渐从用户侧的“商品”，变成后台的一种供给能力。

用户最终关心的是：

谁能可靠地帮我完成这件事？

至于背后使用的是：

商业软件；
开源项目；
FFmpeg；
一个插件；
多个工具组合；
AI 临时生成的一段程序；

也许会越来越不重要。

这意味着软件世界未来可能出现一种新的品牌：

不是 Software Brand，而是 Trust / Execution Brand。

用户信任的不是某个具体工具。

而是：

“我把任务交给你，你会给我一个合适、可靠、可解释的方案。”

十、功能越来越便宜以后，什么会变贵？

把前面的思考放在一起，我得到一个越来越明确的判断：

当制造变便宜，价值会向“制造之前”和“制造之后”移动。

制造之前：

理解需求；
搜索；
筛选；
评估；
判断；
匹配；
建立信任。

制造之后：

集成；
迁移；
验证；
部署；
维护；
兼容；
责任；
持续可靠。

而中间那一块：

“把功能写出来”

可能恰恰越来越便宜。

这也是为什么，我开始觉得未来真正危险的一类软件是：

功能并不独特；有大量免费替代；失败成本又不高；用户也不会形成长期依赖；但它还想仅靠“我做得稍微好一点”收费。

它很容易被夹在：

免费 / AI 生成

和：

大品牌 / 高信任

之间。

未来的软件市场可能越来越像一个杠铃：

免费 / 极便宜                         高信任 / 高价值
████████████████                   ████████████
        \                           /
         \                         /
          \______ 中间地带 _______/

左边卖“能做”。

右边卖“可以放心依赖”。

中间会越来越难。

十一、AI 最重要的价值，也许不是帮世界生产更多东西

这是我目前最感兴趣的结论。

我们长期把 AI 理解成一种生产力工具：

写更多代码。

生成更多内容。

做更多图片。

做更多视频。

但如果 AI 真的让供给爆炸，那么社会接下来的问题可能会变成：

东西已经太多了。

这时候 AI 更有价值的能力反而可能是：

理解我真正需要什么。

告诉我什么不适合。

帮我减少选择。

帮我找到最值得尝试的那个。

也就是说：

AI 既可能制造过剩，也可能成为解决过剩的工具。

过去互联网最大的资产往往是：

“我有多少供给。”

例如多少商品、多少用户、多少岗位、多少软件。

未来一个新的竞争维度也许是：

“我到底有多懂这个用户真正需要什么？”

这是一种从供给数据库向需求模型的变化。

十二、这对个人意味着什么？

想到这里，很容易产生一种挫败感：

这是一个大趋势，但和一个普通开发者有什么关系？

如果答案只是：

“未来 AI 匹配很重要。”

确实没有意义。

真正有意义的地方在于，它会改变我接下来应该积累什么。

如果“写出功能”越来越便宜，那么仅仅让自己成为一个写代码更快的人，长期可能并不够。

更值得积累的可能是：

技术
+
产品判断
+
行业理解
+
AI
+
真实用户
+
商业理解
+
数据

代码仍然重要。

但代码应该逐渐成为武器，而不是唯一商品。

更重要的是：

靠近真实交易。

去理解：

客户为什么来？
为什么付钱？
为什么选择某个方案？
为什么流失？
什么样的匹配最后成功？
哪些条件在真正影响结果？
哪些需求嘴上说得很多，但实际上没人付钱？

这种理解不是靠坐在电脑前想出来的。

它需要进入真实市场以后慢慢获得。

十三、我现在更愿意用这几个问题寻找未来机会

以后再看到一个行业，我不太想先问：

“AI 能不能用在这里？”

这个问题太宽泛了。

我更愿意问：

这里的供给是不是正在过剩？

供需双方是不是很难用几个字段描述？

用户是不是花大量时间筛选？

选错是不是很贵？

用户真正需要的是不是“更少、更好的候选”？

匹配以后能不能获得长期结果反馈？

如果明年的 AI 比今年强十倍，这个业务会变强，还是会直接被基础模型吃掉？

如果一个方向在这些问题上都给出了比较好的答案，我会觉得它值得认真研究。

结语：未来也许不是“更多”，而是“更少”

互联网过去几十年的故事，很大程度上是：

更多。

不再持续掌握架构：Vibe Coding 下的人类重新进入与 AI 守望

Tue, 01 Sep 2026 00:00:00 GMT

最近，我又完成了一次接近“全 Vibe Coding”的尝试。

在这个项目里，我只负责需求和最终结果：

不看代码；
不看目录结构；
不持续理解内部架构；
让 AI 自己实现、修复 Bug 和调整设计。

这正是我之前一直在尝试的方向：如果代码和内部架构可以由 AI 快速重写，人是否可以只掌握需求、契约、风险与最终验收？

但这次实践再次暴露了一个问题。

它不是某个功能没有实现，也不是某条测试没有通过，而是整个系统在几天内沿着一个逐渐错误的结构继续生长，而我直到问题已经变得明显以后才介入。

一个最初合理、后来逐渐错误的文件

项目早期需要多个 EXE 交换状态。

AI 选择了一个简单方案：使用同一个文本文件作为交互媒介。各个 EXE 从文件中读取状态，也把自己的状态写回文件。

在最初阶段，这个设计可能是合理的：

EXE 数量少；
状态简单；
并发要求不高；
不需要复杂的一致性；
实现速度快；
能够尽快验证产品方向。

但之后需求不断细化，新的功能和 Bug 持续出现。越来越多的 EXE 开始依赖这个文件，越来越多的状态需要被读写，冲突也开始频繁发生。

AI 对每一次问题都进行了修复：

增加等待；
增加重试；
调整读写顺序；
增加特殊判断；
增加兼容逻辑；
在已有机制上继续缝补。

每一次修复可能都能让当前问题暂时消失，但系统的底层方向没有被重新审视。

直到四五天后我主动介入，才发现这些 Bug 的共同根因并不在某一段代码，而在于：

这个文本文件已经从一个简单的状态载体，逐渐变成了所有 EXE 的通信、同步和协调中心。

最初适合快速验证的设计，已经不适合后来增长出来的需求。

问题不只是 AI 选错了架构。

更重要的是：在架构成立的前提已经逐渐失效之后，AI 仍然把每一次新冲突理解为一个孤立 Bug，并继续在原有路径上修复。

系统在局部上不断恢复可用，在整体上却越来越难以维护。

前三次思考还缺少了什么

在之前的实践中，我的认识经历了几次变化。

最开始，我尝试不再掌握全部架构，只掌握：

产品应该表现成什么样；
哪些行为必须成立；
哪些数据不能丢失；
哪些风险不能接受；
AI 是否有权修改某项契约。

内部实现则交给 AI。

之后，在自动化测试框架的设计中，我进一步区分了 AI 与确定性流程：

AI 负责理解、泛化、分析和提出建议；
传统自动化负责执行、断言、记录和复现；
Harness 负责持续产生可观察、可定位的证据。

再后来，我发现契约本身也会膨胀，于是继续拆分：

人维护产品承诺与不可接受的风险；
AI 和工具维护当前机器现实；
Harness 维护证据；
Git、Issue、日志和生产数据维护历史。

这些方向仍然成立。

但共享文本文件的经历说明，其中还缺少一个问题：

即使人掌握正确性与风险，如果人完全无法看见系统正在形成什么结构，也可能无法及时意识到自己应该介入。

测试可以告诉我当前行为失败了。

Observer 可以告诉我某个 EXE 没有得到正确状态。

日志可以告诉我文件读写发生冲突。

但这些证据并不会自然告诉我：多个看似独立的 Bug，其实都围绕同一个逐渐膨胀的协调机制发生。

这不是单纯的测试覆盖问题，而是架构认知出现了延迟。

AI 自己 Review 架构是否足够

一种自然的改进方式是：让 AI 更频繁地 Review 自己的架构。

例如每次需求变化后，让另一个 Agent 检查：

当前设计是否仍然适用；
是否出现新的共享状态；
是否有模块承担了过多职责；
是否应该停止修补并进行重构。

这可能有帮助。

但我目前仍然不认为它足以成为唯一方案。

AI 对架构的判断仍然受限于：

它是否理解某项兼容性真正有多重要；
它是否知道未来需求可能怎样变化；
它是否正确理解了产品约束；
它是否在根据现有实现合理化已有设计；
它是否与实现 Agent 共享了同样的盲区。

即使增加多个 Reviewer，也不能保证 AI 一定能够提前判断某个设计已经不再合理。

很多时候，真正触发人类警觉的可能仍然是经验：

修复了 A Bug，为什么突然又出现了 B Bug？

或者：

为什么这个区域最近总是在修改？

又或者：

为什么一个看起来很小的需求，现在会影响这么多功能？

这些直觉暂时很难完全交给 AI。

所以我开始考虑另一个方向：不是要求 AI 自动判断所有架构问题，而是让人在需要介入时，能够非常快速地重新理解当前架构。

从持续掌握，转向随时恢复掌握

传统软件开发里，开发者通常通过亲手编写代码，持续维护一个关于系统的心智模型。

因为经历了每一次修改，所以能够大致知道：

模块之间如何连接；
数据如何流动；
某个设计为什么存在；
一个改动可能影响哪里。

但在 Vibe Coding 下，AI 的实现速度可能远远超过人的认知吞吐量。

要求开发者实时跟上全部结构变化，最终可能意味着：AI 虽然加快了编码，却没有真正降低人的工作量。人只是从亲自写代码，变成了不断追赶 AI 产生的代码。

因此，我现在更倾向于另一个目标：

人不再持续掌握完整架构，但系统必须保证人能够在需要时快速恢复局部掌握。

这两者差别很大。

我平时可以不知道某个模块内部经过了多少次重构，也不需要了解每一个类为什么存在。

但是当 A Bug 修复后出现 B Bug，我应该能够快速回答：

两个 Bug 分别经过了哪些区域；
它们是否共享某个节点或状态；
相关区域最近发生过哪些结构变化；
新增了哪些依赖、读写者或兼容层；
当前的数据流和控制流究竟是什么；
如果继续深入，应该从哪里开始看。

这需要的不是一份静态架构文档，而是一张持续跟随代码变化的大型结构图。

这张图不是架构裁判，而是系统坐标系

我并不期待这张图自动告诉我：

哪个模块最重要；
哪个设计一定错误；
哪个区域必须立即重构；
当前架构还能支撑多少未来需求。

这些判断仍然可能需要人的经验、产品理解和风险意识。

结构图首先需要回答的是：

系统现在是什么形状，某个问题发生在哪里，它与周围什么东西连接？

因此，它更像一套坐标系统。

当开发者的警觉性被异常触发后，可以沿着这套坐标快速进入相关区域，而不需要重新阅读整个项目。

一张真正适合 Vibe Coding 的结构图，可能需要具备几个特点。

1. 从系统级结构开始

最顶层优先展示：

EXE、进程和服务；
主要功能模块；
文件、数据库、配置与共享状态；
HTTP、Pipe、Socket、消息和文件等通信通道；
外部设备与外部系统。

而不是一开始就展示所有类和函数。

2. 支持逐层放大

它应该像地图一样工作：

系统级：有哪些程序、服务和存储；
进程级：某个 EXE 内有哪些主要模块；
功能级：某条业务流程经过哪些组件；
文件级：最终由哪些类和函数实现。

开发者只展开当前怀疑的区域。

3. 保持空间位置稳定

如果每次 AI 修改代码以后，整张图都重新排列，开发者就无法形成任何视觉记忆。

所以同一个模块应该尽量保持原来的位置，新模块在相关区域附近出现，模块移动、拆分和消失也应该留下可追踪的变化。

长期使用后，开发者应该逐渐形成一种“系统地理感”。

4. 能够比较时间和版本

只看当前架构是不够的。

真正重要的问题经常是：

从 A Bug 被修复，到 B Bug 出现之间，这个区域发生了什么？

因此需要能够比较：

某个需求开始前；
AI 完成实现后；
A Bug 修复前后；
B Bug 出现时；
两个 Git 版本之间的结构差异。

新增、删除或变化的节点和连接应该被清楚标出。

5. Bug、测试和 Commit 能够落到图上

点击一个 Bug、失败测试或 AI 任务时，图上应该能够高亮：

修改过的区域；
相关调用链和数据流；
测试实际经过的路径；
异常发生的位置；
多个问题共同经过的节点。

这样，人可以直接看见 A Bug 和 B Bug 是否可能存在共同的结构原因。

6. AI 只解释当前选中的局部区域

AI 在这里仍然有价值。

但它不需要先替人判断整张图哪里最危险，而是在开发者选中一个区域后帮助：

总结该区域的职责；
解释连接为什么存在；
整理最近的相关修改；
还原某条状态流；
找出可能遗漏的调用方；
建议下一步应该查看什么证据。

也就是说，先由人决定关注哪里，再由 AI 帮助快速恢复理解。

Human Re-entry：让人重新进入架构

我暂时把这种能力称为 Human Re-entry。

它的目标不是让人持续 Review 所有 AI 代码，而是缩短下面这段时间：

从“我感觉这里可能不对”，到“我已经理解这个局部结构，可以作出判断”。

传统项目里，这个过程可能依赖开发者长期积累的记忆。

在全 Vibe Coding 项目里，这种记忆可能已经不存在，所以必须由工具帮助重新构建。

因此，结构图真正需要优化的指标可能不是“自动发现了多少架构问题”，而是：

人需要多久才能定位相关区域；
需要打开多少文件才能理解一条链路；
能否看见多个 Bug 的共同节点；
能否还原某个结构是怎样逐步形成的；
能否在几分钟内决定继续修补还是重新设计。

AI Sentry：同一套系统也可以提高 AI 的警觉性

当结构图、Bug、测试、Commit 和运行记录已经连接起来以后，它也可以成为 AI Review 的基础。

但这时 AI Review 不再是一个完全独立的尝试，而是这套架构观测系统上的派生能力。

系统可以先用相对确定的信号发现值得关注的区域，例如：

同一条路径在一段时间内关联了多个缺陷；
同一个节点被连续高频修改；
修复一个问题后，相邻路径快速出现新的回归；
某个共享资源的读写者持续增加；
一个很小的需求开始影响越来越大的范围；
同一模块不断增加 retry、fallback、lock 和兼容分支。

这些信号并不能证明架构已经错误。

它们只需要表达：

这里可能值得重新看一眼。

达到默认阈值后，系统可以把一个有限的局部子图交给 AI，包括：

最近相关的需求；
几次 Bug 与修复；
结构变化时间线；
相关测试和运行证据；
当前节点与周边节点的关系。

然后让 AI 回答更有限的问题：

这些问题是否可能共享结构性原因；
当前机制是否承担了越来越多职责；
最近的修复是在消除根因，还是继续增加补丁；
还缺少什么证据；
是否值得由人介入检查。

我暂时把这种能力称为 AI Sentry。

它不是架构裁判，而是一个基于结构和历史进行守望的观察者。

同一套系统，两种介入方式

走到这里以后，我最初的两个方向实际上开始合并。

第一种方式是人主动介入：

人发现 Bug、回归或异常模式；
打开结构图；
定位相关区域；
恢复局部理解；
判断继续修补还是要求 AI 重构。

第二种方式是系统主动提醒：

系统持续记录结构变化与缺陷关联；
某些信号达到阈值；
AI 对局部子图进行重点分析；
在图上标记值得关注的区域；
人决定是否真正介入。

两种方式共用同一个基础：

当前系统结构；
结构随时间的变化；
Bug、测试和 Commit；
运行时证据；
局部查询与解释能力。

所以最终可能只需要一个方向：

建立一套同时供人和 AI 使用的架构观测系统。

人使用它来快速恢复理解。

AI 使用它来提高警觉性。

不需要一个抽象的架构健康分数

我目前并不希望系统简单地给出：

架构健康度 72 分；
当前模块高风险；
建议立即重构。

这种结论太容易掩盖真实信息，也容易让开发者产生虚假的确定感。

更有价值的可能是一组可以直接检查的事实：

Camera Discovery 链路最近 8 天修改了 6 次；其中 4 次经过 status.txt；该文件写入者从 1 个增加到 4 个；修复 A 后出现的 B、C 两个回归也经过这里。

人看到这些信息以后，可以自行判断是否需要进入结构图继续调查。

AI 也可以基于这些事实提出假设，但它的结论不应该覆盖事实本身。

一个尽可能克制的第一版

如果真的开始实现，我认为第一版不需要成为一个通用的软件架构平台。

它甚至可以只服务当前最熟悉的场景：一个包含多个 C# EXE、Windows Service、设备和本地状态的项目。

第一版只需要识别：

Project、EXE、Service；
主要模块；
文件、配置和数据库；
HTTP、Pipe、Socket 等通信关系；
每个共享资源的读取者和写入者；
Git 版本之间的结构变化；
Bug、测试和 Commit 关联的区域。

然后提供：

一张稳定、可下钻的大型结构图；
两个版本之间的结构 Diff；
从 Bug 或测试跳转到相关子图；
选中局部区域后让 AI 进行解释；
根据简单阈值产生关注提醒。

它暂时不需要：

自动决定架构好坏；
支持所有语言和框架；
生成完整架构文档；
自动修改所有契约；
用多个 Agent 对整个项目进行持续争论。

最重要的验证标准只有一个：

如果重新回放共享文本文件项目的历史，这套系统能否在 A Bug 修复后出现 B Bug 时，让我在几分钟内看见它们共同经过 status.txt，并理解这个文件已经从简单状态载体演变成通信枢纽？

如果能做到，它就已经开始解决真正的问题。

下一阶段需要继续验证的问题

这仍然只是一个新的方向，而不是最终答案。

接下来真正需要验证的可能包括：

自动生成的结构图是否足够准确，还是会产生新的错误认知；
图在持续变化时能否保持稳定的空间位置和节点身份；
如何把 Bug、测试、Commit 与具体结构区域可靠关联；
静态分析无法发现的动态调用和跨进程关系如何补充；
一张足够大的图如何避免最终变成无法阅读的“毛线团”；
默认阈值是否会产生过多误报和告警疲劳；
AI 对局部子图的解释是否真的比直接阅读代码更快；
这套系统是否能够显著降低人重新取得架构理解所需的时间；
当人介入并要求重构后，图是否能够帮助验证结构是否真的得到改善；
最终哪些信息需要长期保存，哪些解释应该只在查询时即时生成。

目前的结论

经过这次实践，我不再认为选择只有两个：

要么持续理解 AI 生成的全部架构；
要么完全放弃架构，只看最终测试结果。

中间可能存在第三种状态：

人平时不需要跟上全部架构变化，但系统持续维护一张可以被查询、比较和下钻的机器现实地图；当异常触发人的警觉，或者结构信号达到阈值时，人和 AI 都能够基于这张地图重新进入相关区域。

这并没有让人重新接管所有实现。

它只是保留了一条重新取得理解的通道。

所以，Vibe Coding 下一阶段需要解决的，也许不是怎样让人永远跟得上 AI，而是：

当 AI 的开发速度已经超过人的认知速度以后，怎样让系统仍然保持可重新理解。

人不再持续拥有全部架构。

但人必须能够在真正需要的时候，随时恢复掌握。

当契约也开始失控：AI 原生工程中的承诺、现实与证据分离

Mon, 10 Aug 2026 00:00:00 GMT

最近，我又开始重新审视自己在 Vibe Coding 下的工作方式。

前一阶段，我逐渐接受了一件过去很难接受的事情：

在不需要多人协作的项目里，我未必需要持续掌握 AI 生成的全部架构和实现细节。

如果 AI 可以快速重构代码、替换模块、改变内部数据流，而我仍然能够通过测试、契约和可观察结果判断系统是否正确，那么“理解每一个内部实现”本身可能不再是必要条件。

于是我的工作方式开始发生变化。

我不再试图持续维护完整的软件架构，而是把注意力转向：

验收；
边界；
不变量；
风险；
可观察结果。

AI 负责内部架构和绝大部分实现。

人负责定义什么叫正确。

这个方向一开始工作得很好。

但随着项目继续变复杂，我又遇到了一个新的问题：

如果架构可以交给 AI，而人只负责契约，那么契约本身会不会也变成新的认知债？

答案逐渐变成了：会。

而且它可能比传统架构文档膨胀得更快。

第一阶段：我试图只维护验收和边界

最开始，我的想法其实很直接。

既然 AI 可以负责：

代码；
模块拆分；
内部架构；
数据流；
重构；
实现细节；

那么我只需要掌握：

产品应该表现成什么样；
哪些场景必须通过；
哪些情况绝对不能发生；
哪些行为属于正式支持范围。

也就是说，把系统变成：

人
↓
验收 / 边界 / 契约
↓
AI
↓
架构 / 实现 / 重构

这样看起来非常合理。

尤其是在单人负责项目时，我不需要为了多人协作去维护大量模块说明，也不需要理解每一次 AI 的内部重构。

只要最终行为正确，内部实现就可以是可抛弃的。

但很快，现实开始污染这套模型。

边界文档开始变成“问题垃圾场”

一个理想的边界可能是：

Camera Discovery 必须能够正确返回当前可用设备。

这句话非常简单。

但是进入真实开发后，很快就会出现：

某型号设备初始化前不会出现；
某 Driver 版本会重复返回；
某台研发电脑存在 USB Hub 问题；
Debug 阶段暂时屏蔽虚拟设备；
Remote Desktop 下暂时不可用；
某个功能只有 Release Build 才开启；
测试环境里为了绕过一个已知问题，需要增加特殊等待；
某个 Bug 当前不处理，因为只影响内部研发环境；
某版本兼容层存在临时 workaround。

于是原来只有一句话的边界，慢慢变成：

Camera Discovery 必须能够正确返回设备。

但是：

- DEV-PC-07 忽略重复设备问题；
- Driver 3.8 存在已知兼容问题；
- Debug 环境不验证 Virtual Camera；
- Remote Desktop 当前不保证；
- 某些机器启动后需要额外等待；
- 研发阶段允许屏蔽某一类异常；
……

继续维护下去之后，我发现这里已经出现了一个根本问题：

这些内容根本不是同一种东西。

它们至少包含：

产品正式承诺；
当前实现能力；
已知缺陷；
环境特例；
临时研发措施；
兼容性结果；
workaround；
尚未验证的未知情况。

但是因为它们都与“边界”有关，我把它们塞进了同一个文档。

结果就是：

边界文档越来越完整，同时也越来越不可维护。

第二阶段：我尝试 Harness Engineering

为了降低这种失控，我开始进一步分层。

不再只是写文档，而是建立 Harness。

每一层负责一种稳定的能力，例如：

Core
↓
Windows Capability
↓
Observer
↓
Backend Adapter
↓
UI Adapter
↓
Case

AI 可以在这些能力之上组合新的测试流程。

系统的每一层也尽可能能够独立观察：

Backend
↓
Service
↓
Client
↓
UI

当最终行为失败时，我不希望只得到一个 FAIL，而是希望看到：

Backend: PASS
Service: PASS
Client: FAIL
UI: FAIL

这让我逐渐把测试理解为一种：

measurement system

也就是测量系统。

Harness 不负责解释整个项目，而是负责提供可重复、可观察、可定位的证据。

这个方向解决了一部分问题。

但又带来了一个新的诱惑：

既然已经分层，是不是每一层都应该拥有自己的定义、边界、特殊情况、兼容说明和文档？

如果继续这样做，Harness 很快又会变成第二个产品。

最终我还是需要维护：

Core 文档
Windows 文档
Observer 文档
Backend 文档
UI 文档
Case 文档
特殊情况
兼容情况
已知问题
临时措施

于是问题又回来了。

只是这一次，从“架构复杂度”变成了“知识结构复杂度”。

我开始意识到：契约本身也会腐化

之前我认为：

AI 可以拥有架构，但不能拥有“什么叫正确”。

所以人应该长期维护契约。

这个原则仍然成立。

但现在我认为，它还缺少一个更细的拆分。

因为“契约”这个词太大了。

如果把所有下面这些东西都叫契约：

正式支持什么；
当前能做到什么；
哪些环境测过；
哪些环境失败；
哪些问题暂时忽略；
哪些 bug 已知但不修；
哪些功能研发阶段关闭；
哪些场景尚未验证；
哪些兼容性只是偶然跑通过；

那么契约最终一样会变成机器才能理解的大型知识库。

真正需要长期由人维护的东西，也许比“完整契约”还要更少。

从“边界”转向“承诺”

我现在认为，最重要的一次变化是：

不要维护系统全部边界，而是维护我们愿意承担责任的边界。

这两者不是一回事。

例如：

某个功能在 Windows 10 + 特定 Driver + Remote Desktop 下，当前实际上可能能够运行。

但这不代表产品必须正式承诺支持。

反过来，如果产品已经正式承诺支持 Windows 11，那么即使当前版本存在 Bug，也不能因为实现失败，就把文档改成：

Windows 11 暂不支持。

否则就会发生一种非常危险的逆向过程：

实现存在问题
↓
测试失败
↓
AI 修改边界
↓
把失败重新定义成“不支持”
↓
测试重新通过

这实际上不是修复系统，而是在修改“什么叫正确”。

所以我开始把“边界”进一步收缩成：

Support Envelope

也就是：

产品明确愿意承担责任的支持范围。

例如：

Camera Discovery

正式支持：

- Windows 11
- 当前正式版本与前一个正式版本
- 官方 Driver
- 本地用户 Session

明确不保证：

- Remote Desktop
- 虚拟 Camera
- 非官方 Driver

到这里就应该结束。

不要继续把所有现实世界里的临时问题都追加进去。

软件其实存在两种不同的 Truth

过去我一直在寻找一个稳定的 Source of Truth。

后来我发现，很多混乱恰恰来自于：

我试图让同一个东西同时表达两种完全不同的真相。

第一种是：

Normative Truth

也就是：

系统应该是什么。

例如：

我们承诺支持 Windows 11；
用户数据不能被静默删除；
一个 Tenant 不能访问另一个 Tenant 的数据；
已确认的历史记录不能被修改；
某个 API 必须保持兼容；
某项操作失败后必须可恢复。

这些是：

产品承诺；
业务规则；
不变量；
安全边界；
数据保证；
兼容保证。

它们不应该随着某一次实现问题而自动变化。

第二种是：

Descriptive Truth

也就是：

系统现在实际上是什么。

例如：

Build 143 在 Windows 11 上是否真的通过；
当前 Driver 4.31 是否兼容；
某个 Feature Flag 当前是否开启；
某条内部调用链现在经过哪些模块；
当前版本是否存在已知 Crash；
某环境是否需要 workaround。

这些不是产品承诺。

它们描述的是当前现实。

而当前现实应该主要由这些东西决定：

代码
运行状态
测试
Trace
配置
生产观测

AI 可以负责读取和整理这些事实。

当 SHOULD 和 IS 不一致时，不要强行同步

假设：

Normative Truth:
Windows 11 必须支持。

Descriptive Truth:
当前 Build 在 Windows 11 上失败。

正确的结果应该是：

BUG

而不是：

修改边界文档：
Windows 11 暂不支持。

这让我开始接受一个过去不太习惯的状态：

系统应该是什么，与系统现在是什么，可以暂时不一致。

这种不一致本身就是有价值的信息。

不应该为了让文档看起来“永远一致”，把差异抹掉。

不再要求工程师知道所有边界

这里还有另一个让我犹豫很久的问题。

如果内部架构和大量细节都交给 AI，那么客户突然问：

XX 场景可不可行？

工程师很可能根本不知道。

在传统软件开发里，一个长期负责系统的工程师往往可以凭经验回答很多问题。

但在 AI 高速修改系统之后，这种能力会快速下降。

我最开始认为：

这是不是说明 AI 开发已经造成严重失控？

后来我逐渐认为，不一定。

真正的问题不是：

工程师有没有把所有 edge case 记在脑子里。

而是：

当工程师不知道的时候，系统能不能提供可信证据。

例如 AI 不应该回答：

看代码应该可以。

而应该回答：

状态：VERIFIED

Build:
2.8.143

Environment:
Windows 11 24H2
Driver 4.31

Evidence:
CASE-CAMERA-041
CASE-CAMERA-087

Last verified:
2026-08-08

Formal Support:
NO

这时候 AI 的角色不再是：

知识权威。

而是：

证据检索器。

这两者差别很大。

“能不能运行”不应该只有 Yes / No

现实中的支持状态其实不是 Boolean。

它至少应该存在几个不同级别：

GUARANTEED

产品正式承诺支持。
失败属于产品缺陷。

VERIFIED

当前版本在某个明确环境中验证通过，
但不一定属于正式支持承诺。

KNOWN LIMITATION

已经知道当前版本在该场景存在问题。

UNSUPPORTED

明确不属于产品支持范围。

UNKNOWN

没有足够证据判断。

这样一来，客户问：

Windows 11 + 4K Camera + Remote Desktop 能不能用？

答案就不再需要伪装成绝对确定：

Formal Support:
UNSUPPORTED

Current Evidence:
Build 2.8.143 曾在类似环境运行通过 3 次。

Conclusion:
当前存在成功运行证据，
但产品不对该组合提供正式保证。

这比工程师凭记忆说：

应该可以吧。

可靠得多。

特殊情况不应该进入承诺层

很多文档失控，就是因为“特殊情况”全部进入了长期边界。

现在我认为，这些特殊情况应该被独立建模。

例如：

DEV-PC-07 上暂时忽略 Camera Discovery 的某个 Bug。

它不是产品边界。

它应该是：

type: environment_exception

scope:
  machine: DEV-PC-07

issue: CAMERA-142

effect:
  ignore_failure: CameraDiscovery

reason:
  defective_usb_hub

expires:
  2026-09-01

再例如：

研发阶段暂时屏蔽 Virtual Camera。

它应该是：

type: temporary_guard

scope:
  stage: development

feature:
  VirtualCamera

reason:
  implementation_incomplete

expires:
  before_release: true

issue:
  FEATURE-183

这些东西可以很多。

甚至可以由 AI 自动维护。

但是它们不应该污染产品正式承诺。

临时例外必须允许被遗忘

这又让我意识到一个很容易被忽略的问题：

AI 工程中的遗忘机制，可能和记录机制一样重要。

人类看到一条两年前的临时 workaround，往往会本能地觉得：

这个东西是不是已经过时了？

AI 不一定。

如果没有明确状态，它可能非常忠实地继续把旧内容当成现实的一部分。

所以任何：

临时屏蔽；
开发环境特例；
测试豁免；
workaround；
临时兼容层；
某设备特殊规则；

都应该尽量包含：

scope
reason
issue
introduced_at
expiry

没有 expiry 的 temporary exception，最终很容易变成永久知识污染。

那人还需要掌握架构吗？

走到这里以后，另一个问题又回来了：

如果工程师既不掌握所有 edge case，也不掌握全部内部架构，那是不是退让太多了？

我目前的答案仍然是：

不需要重新掌握全部 Implementation Architecture。

但人必须掌握另一种架构：

Risk Architecture

也可以叫：

Irreversibility Map

人未必需要知道：

CameraService
↓
DeviceResolver
↓
Win32Provider
↓
CacheProvider

这些东西 AI 可以随时重构。

但人应该知道：

设备发现
↓
生成稳定 Device Identity
↓
写入持久化配置
↓
客户配置引用 Device ID

因为这里开始出现不可随意修改的现实：

Device ID 能不能改变？
历史配置还能不能读取？
旧客户端是否仍然兼容？
数据迁移失败以后怎么办？
已经写出去的状态能不能恢复？
外部系统是否已经引用了这个值？

这些才是人真正值得长期掌握的结构。

可重写的结构，与不可逆的现实

我现在倾向把系统分成两部分：

┌──────────────────────────────┐
│ 可自由重写                    │
│                              │
│ internal algorithm           │
│ class hierarchy              │
│ service layout               │
│ cache strategy               │
│ internal framework           │
└──────────────────────────────┘

               ↓

┌──────────────────────────────┐
│ 人必须关注                    │
│                              │
│ Persistent Data              │
│ Identity                     │
│ External API                 │
│ Security Boundary            │
│ Side Effects                 │
│ Compatibility                │
│ Migration                    │
│ Recovery                     │
└──────────────────────────────┘

上面那部分可以让 AI 高频调整。

下面那部分一旦变化，人就应该知道。

因为 AI 可以在一天内重写十万行代码，但无法撤回已经发生的现实。

Harness 的职责也需要重新限定

Harness Engineering 仍然是我目前非常认可的方向。

但现在我会给它一个更严格的定义：

Harness 是 measurement system，不是 knowledge system。

它的目标不是：

完整描述系统。

而是让系统能够回答问题。

例如：

Can Camera A be discovered?

Can old configuration survive migration?

Does UI state equal backend state?

Can this workflow recover after restart?

Does retry create duplicate side effects?

Harness 只需要持续产生高质量证据。

不需要承担所有历史知识、产品承诺和特殊情况。

否则 Harness 本身会重新变成另一个需要维护的大型系统说明书。

我现在倾向于只长期维护四类资产

经过这几轮变化，我越来越不希望项目里存在十几份“需要长期正确”的文档。

更合理的状态可能只有四类。

1. Human Guarantee Surface

这是人真正拥有的部分。

它应该非常小。

只记录：

我们承诺什么；
我们明确不支持什么；
什么绝对不能发生；
什么数据不能丢；
哪些兼容性必须保证；
哪些产品行为未经人工批准不得改变。

一个非常重要的约束是：

项目负责人必须能够在较短时间内重新读懂这部分内容。

如果这一层已经出现几千条特殊规则，说明它已经失去意义。

2. Risk / Irreversibility Map

这也是人拥有的。

它描述：

持久化数据；
Identity；
外部 API；
权限边界；
不可逆副作用；
数据迁移；
兼容关系；
故障恢复；
已经发生的外部承诺。

它不需要描述每一个内部模块。

它只需要告诉人：

哪些地方一旦改错，AI 不能靠“重新生成代码”解决。

3. Machine Reality

这一层允许非常大。

由 AI、代码分析、运行状态和工具共同维护。

例如：

当前架构；
当前 Capability；
Feature Flag；
Known Issue；
Environment Exception；
Temporary Guard；
Compatibility Result；
当前内部数据路径；
运行时 Observation；
Trace 索引。

这部分未来很可能完全不适合人直接阅读。

我认为这不是失败。

它本来就可以成为：

AI-interpretable project memory

也就是机器可消费的项目现实模型。

4. Evidence

Evidence 主要由 Harness 产生。

例如：

CASE-041 PASS
Build 143
Windows 11 24H2
Driver 4.31
2026-08-08

或者：

Migration V12 → V13
Dataset: production-snapshot-20260801
Result: PASS
Rollback: PASS

AI 在回答现实问题时，应该尽量回到 Evidence。

而不是根据一段长期维护的自然语言文档做推测。

最终结构

整个体系开始变成：

                    Human

          ┌──────────────────────┐
          │ Guarantee Surface    │
          │ Risk / Irreversibility│
          └──────────┬───────────┘
                     │
              defines SHOULD
                     │
                     ▼
          ┌──────────────────────┐
          │        System        │
          │   AI Implementation  │
          └──────────┬───────────┘
                     │
                  Harness
                     │
                     ▼
          ┌──────────────────────┐
          │ Evidence / Trace     │
          └──────────┬───────────┘
                     │
                     ▼
          ┌──────────────────────┐
          │   Machine Reality    │
          └──────────┬───────────┘
                     │
                     ▼
                    AI
                     │
                     ▼
              Human asks questions

这里有一个很大的变化：

人不再维护“系统全部知识”。

人维护的是：

承诺
风险
裁决权

AI 维护的是：

当前现实
内部结构
大量细节

Harness 维护的是：

证据

历史系统维护的是：

过去发生过什么

AI 即时生成文档，不一定是退化

以前我会认为：

如果工程师每次都要问 AI 才知道系统怎么运行，说明项目已经失控。

现在我不再完全这样看。

如果 AI 只是根据旧文档做语言推测，当然危险。

但如果 AI 是：

读取当前系统
+
查询 Evidence
+
读取正式 Support Envelope
+
结合 Risk Map

然后生成一次即时解释，那么这更像：

Query / Projection

而不是：

临时编一份文档。

这种文档本身甚至不需要长期保存。

例如：

“当前版本对 Windows 11 + Driver 4.31 的 Camera Discovery 支持情况如何？”

AI 可以即时生成一份报告。

下一次版本变化后，再重新查询。

长期保存的应该是：

正式承诺；
证据；
运行事实；
风险；
历史。

而不是每一次给人看的自然语言解释。

工程师的职责也可能因此改变

传统软件工程里，一个长期负责项目的好工程师，往往意味着：

他脑子里拥有大量系统知识。

但 AI Native 工程里，这个定义可能需要改变。

未来更重要的能力也许是：

知道什么可以承诺，什么不能承诺，以及如何取得可信证据。

工程师不需要记住 500 个 edge case。

但必须清楚：

什么是产品承诺？
什么只是当前实现？
什么只是一次测试结果？
什么属于已知缺陷？
什么还没有验证？
什么允许 AI 自动修改？
什么必须人工批准？

这更像一种：

Authority Model

而不是完整系统记忆。

从 Contract-Driven 再往前一步

我之前逐渐接受：

不再拥有架构，只拥有契约。

现在我认为，这句话还可以继续收缩：

甚至不要试图长期拥有全部契约。

更准确的表达可能是：

人拥有承诺、风险和最终裁决权。

AI 拥有：

内部现实和实现细节。

Harness 拥有：

可重复的证据。

Version Control、Issue、日志和生产数据拥有：

历史。

这四种东西不应该再被强行压进同一份文档。

Promise / Reality Separation

我现在越来越觉得，这个模式真正的核心不是“怎样把 AI 文档维护得更好”。

而是：

永远不要再试图用同一份文档同时表达：

我们承诺什么；
系统现在是什么；
历史上发生过什么；
当前有哪些临时问题。

这四种信息的生命周期完全不同。

强行同步它们，只会制造认知债。

如果把它们分开：

Promise
↓
人负责

Reality
↓
AI / Runtime 负责

Evidence
↓
Harness 负责

History
↓
Version Control / Issue / Log 负责

那么很多原本需要“维护文档”解决的问题，会自然变成不同系统之间的职责划分。

这也许可以叫 Evidence-Backed AI Engineering

如果继续沿着这个方向发展，我目前更愿意把它理解为一种：

Evidence-Backed AI Engineering

它不要求人长期理解系统的每一个内部细节。

也不要求 AI 永远维护一份完美、无冲突、完整可读的知识文档。

它要求的是：

人明确产品愿意承诺什么；
人知道哪些现实状态不可逆；
AI 可以自由修改内部实现；
Harness 持续生产确定性证据；
当前现实允许由 AI 重新提取；
未知必须保持 UNKNOWN；
临时例外必须能够过期；
实现失败不能自动变成产品边界；
最终所有外部结论都能够追溯到承诺或证据。

目前的结论

这仍然不是一个最终答案。

我现在只是越来越确定：

AI 时代真正的问题已经不是代码生成速度，而是认知所有权如何重新分配。

传统软件工程默认：

工程师
=
需求理解
+
架构理解
+
实现理解
+
边界理解
+
历史理解
+
故障理解

但当 AI 的实现速度远远超过人的认知吞吐量以后，这个模型可能无法继续成立。

新的模型也许会变成：

Human
=
Promise
+
Risk
+
Judgement

AI
=
Implementation
+
Current Reality
+
Explanation

Harness
=
Evidence

History System
=
Past

这样，人并没有放弃系统控制权。

人放弃的是：

对所有内部细节的持续占有。

而真正保留下来的，是：

定义什么值得保证、什么损失不可接受，以及什么证据足以让我相信系统仍然正确。

我目前正在沿着这个方向继续实践。

它很可能还会暴露新的问题。

但至少现在，我开始觉得：

下一阶段真正需要被设计的，不再只是软件架构，而是人、AI、运行系统和证据之间的权力边界。

从 AI 全自动测试，到 AI + 确定性流程：重新设计一套自动化测试框架

Wed, 05 Aug 2026 00:00:00 GMT

前言

最近准备重新设计公司的自动化测试框架。

一开始，我的目标其实很简单：

能不能让 AI 完全替代测试人员？

后来越研究越发现，这条路并没有想象中那么简单。

这篇文章主要记录整个思考过程，而不是介绍某个具体项目。

最初的设想

最开始，我想的是：

AI

↓

自己规划测试流程

↓

点击所有按钮

↓

分析结果

↓

生成报告

理论上，大模型已经能够：

理解界面
点击按钮
阅读文本
判断结果

似乎已经可以完成整个自动化测试。

但是深入调研以后，我发现真正的问题并不是：

AI 能不能做到。

而是：

AI 能不能稳定做到。

为什么放弃 AI 全流程驱动？

最大的几个问题：

1. Prompt 太脆弱

不同的软件版本

不同的界面

不同的弹窗

都会影响最终效果。

为了提升稳定性，需要不断调整 Prompt。

最终维护成本非常高。

2. AI 不适合确定性验证

例如：

金额计算

属性计算

优惠券叠加

编码参数

…

这些结果必须：

100%

正确。

99% 的准确率其实等于不能使用。

这些场景应该交给：

单元测试
集成测试
Assert

而不是 AI。

3. AI 自己规划流程容易失控

例如：

今天：

打开软件

↓

录像

↓

关闭软件

明天：

AI 可能决定：

打开软件

↓

修改属性

↓

录像

↓

打开菜单

↓

关闭软件

流程越来越不可预测。

Bug 很难复现。

日志也很难分析。

一个重要的转折

后来看到了一些 AI 自动化测试方案（例如 KUITest）。

让我意识到：

AI 真正擅长的是：

泛化。

不是：

控制流程。

于是整个思路开始改变。

AI 应该负责什么？

后来我把职责重新划分。

AI：

负责：

理解界面
提供扰动
判断视觉异常
分析测试报告
推荐新的测试 Case

传统自动化：

负责：

流程执行
点击
Assert
数据验证
属性验证

整个职责开始变成：

flowchart LR
    goal["可靠的自动化测试"]

    subgraph ai["AI · 负责泛化"]
        direction TB
        a1["理解界面"]
        a2["提供扰动"]
        a3["判断视觉异常"]
        a4["分析报告与推荐 Case"]
    end

    subgraph deterministic["传统自动化 · 负责确定性"]
        direction TB
        d1["执行固定流程"]
        d2["点击与读取属性"]
        d3["数据验证与 Assert"]
        d4["输出可复现结果"]
    end

    ai --> goal
    deterministic --> goal

自动化测试真正的目标

以前我一直认为：

自动化测试：

就是：

模拟人的操作。

后来发现不是。

真正的目标其实是：

构建一条可以不断重复执行的验证链路。

所以我重新定义了一条测试链：

flowchart LR
    backend["Backend<br/>PASS"] --> service["Service / Feeder<br/>PASS"]
    service --> client["Client<br/>FAIL"]
    client --> ui["UI<br/>FAIL"]

    classDef passed fill:#dff4dd,stroke:#171c24,color:#171c24,stroke-width:2px
    classDef failed fill:#ffd9d4,stroke:#171c24,color:#171c24,stroke-width:2px
    class backend,service passed
    class client,ui failed

每一层都应该能够独立观察。

失败的时候，不再只告诉你一个 FAIL，而是同时标出每一层的状态。

这样开发人员几乎可以立即定位问题。

自动化测试应该如何分层？

最终我把整个系统拆成了六层。

flowchart TB
    testCase["06 · Case<br/>组合业务测试流程"]
    ui["05 · UI Adapter<br/>读取界面状态"]
    backend["04 · Backend Adapter<br/>调用 Backend DLL 与记录 Trace"]
    observer["03 · Observer<br/>只观察系统状态"]
    windows["02 · Windows 能力<br/>Process / Service / Shortcut / File"]
    core["01 · Core<br/>Runner / Step / Context / Timeline"]

    testCase --> ui
    testCase --> backend
    testCase --> observer
    ui --> windows
    backend --> windows
    observer --> windows
    windows --> core

第一层：Core

负责：

TestRunner
Step
Context
Timeline

这里不关心任何业务。

第二层：Windows 能力

封装：

Process
Service
Shortcut
File

所有和 Windows 相关的能力。

第三层：Observer

负责观察系统状态。

例如：

service_status.json
camera_snapshot.json

Observer 永远不主动控制系统。

只负责观察。

第四层：Backend Adapter

封装 Backend DLL。

提供：

Discover
Open
Close
Property
Capture

所有调用都会记录 Trace。

第五层：UI Adapter

封装：

UI Automation。

这里只负责：

读取。

而不是业务。

第六层：Case

真正的测试流程。

例如：

CheckService

↓

Launch AdminConsole

↓

Observer 获取 Camera

↓

UI 获取 Camera

↓

Compare

↓

Generate Report

Case 不直接调用底层。

而是组合已有能力。

为什么要这样分层？

因为真正需要复用的不是：

代码。

而是：

能力。

例如：

今天完成：

LaunchProcess()

以后：

任何 Case 都可以使用。

今天完成：

ReadCameraList()

以后：

所有测试流程都能直接调用。

整个系统会越来越像积木。

而不是越来越复杂。

多 Agent 开发

整个项目后面采用了多 Agent 并行开发。

每个 Agent：

只负责一个模块。

例如：

Agent A

↓

Core

----------------

Agent B

↓

Windows

----------------

Agent C

↓

Observer

----------------

Agent D

↓

Backend Adapter

----------------

Agent E

↓

UIA

----------------

Agent F

↓

Case

第二天回来以后。

我不会先 Review 代码。

而是：

Review：

能力。

例如：

今天：

新增了：

启动程序
检查 Service
Observer
Camera Discovery

只有这些能力全部能够独立验证。

才开始进入下一阶段。

我的收获

这次最大的改变其实不是：

设计了一套自动化测试。

而是重新理解了 AI。

AI 不应该替代整个流程。

而应该负责：

那些传统自动化最不擅长的部分。

而：

确定性、

稳定性、

可复现、

可定位，

依然应该交给传统自动化。

最终形成：

AI

负责：

泛化。

传统自动化

负责：

确定性。

我认为，这种职责划分，才是真正适合工程项目的 AI 自动化测试方向。

后续计划

目前 V1 的目标非常明确：

完成基础框架
建立 Observer
打通 Backend → Client → UI 链路
实现第一条可重复执行的自动化 Case

等这一版稳定以后，再逐步引入：

AI 扰动生成
AI 日志分析
AI 测试建议
AI 回归策略优化

而不是一开始就把 AI 放到整个测试流程的中心。

AI 时代，还需要掌控软件架构吗？

Wed, 05 Aug 2026 00:00:00 GMT

最近，我开始重新审视自己在 Vibe Coding 下的工作方式。

在没有 AI 的时候，我通常会先根据需求，大致设计系统需要分成多少层、有哪些模块，然后开始开发。在开发过程中，随着对需求和问题理解的加深，再不断调整架构。产品上线后，也可能继续以新的架构方向逐步重构。

这种工作方式不一定能在一开始就设计出正确架构，但它有一个很大的好处：我亲手写过绝大部分代码，也经历了每一次结构变化，因此能够清楚地理解模块之间的关系、数据如何流转，以及系统为什么会变成现在这样。

那时可能会有技术债，却很少有严重的认知债。

但在 AI 参与开发之后，情况发生了变化。

我可以完全不写代码，先快速堆出需求，等产品方向基本确定后，再和 AI 讨论架构。第一版架构确定以后，由 AI 负责实施；实施过程中遇到问题，AI 又会继续修改架构、增加模块、调整数据流，甚至推翻之前的设计。

整个过程非常快，但到了最后，我可能只知道系统的大致方向，却不再清楚实际运行的架构。代码里可能已经出现了我不知道的模块、抽象、兼容层和数据路径。

更矛盾的是，如果我想重新掌控架构，就必须理解 AI 做出的每一个重要决定。AI 经常能够提出看上去更好的设计，但要判断它是否真的更好，我又必须深入理解实现细节。AI 开发得越快，我需要补充的上下文越多，认知债反而膨胀得越快。

于是，一个以前听起来很危险的问题开始变得合理：

如果项目只有我一个人负责，而且 AI 可以在一两天内完成过去需要数周甚至数月的重构，我是否可以完全不管架构，只负责判断测试是否通过？

我的答案逐渐变成了：可以，但这里的“测试”必须被重新定义。

传统架构解决了什么问题

在传统软件开发中，架构主要承担三类任务。

第一，帮助开发者压缩复杂度。

系统规模变大后，没有人能够同时记住所有代码。稳定的模块边界、分层和依赖关系，可以让开发者只理解当前需要处理的部分。

第二，帮助团队进行协作。

多人开发需要明确模块归属、接口边界、数据所有权和依赖方向。架构不仅是技术设计，也是团队之间的协作协议。

第三，降低未来修改的成本。

传统开发中，大规模重构非常昂贵。它需要大量人工修改、测试和协调，还可能造成长时间的功能停滞。因此，提前保留扩展空间、控制耦合和稳定边界，具有很高的经济价值。

但在“单人开发者加 AI”的场景中，这三个条件都发生了变化。

复杂度可以部分交给 AI、代码检索和运行时工具管理；
没有多人分工，也就不需要通过架构持续维持团队共识；
AI 显著降低了代码重写和结构迁移的成本。

这意味着，架构的传统价值确实在下降。

过去，我们需要尽量保护代码，因为代码很贵；现在，代码甚至整个内部架构，都可能逐渐成为可以重新生成的中间产物。

架构可以被抛弃，但现实状态不能

不过，AI 能快速重构代码，并不代表它能快速重构已经发生的现实。

代码可以被重写，但下面这些东西不会自动消失：

已经写入数据库的数据；
已经产生的支付和退款；
已经发送的消息、邮件和通知；
正在运行或等待重试的异步任务；
已经安装旧版本的客户端；
第三方系统保存的状态；
已经对外公开的 API；
用户形成的行为预期；
必须长期保留的审计记录。

单人项目消除了人与人之间的协调成本，却没有消除系统与自身历史之间的协调成本。

AI 可以在一天内重写十万行代码，却不能撤回一笔已经完成的转账，也不能自动修复已经丢失的数据。

因此，真正可以被完全放权的不是整个项目，而是项目的内部实现。只要系统存在持久化状态、不可逆操作或对外承诺，我们就仍然需要掌控这些风险。

从架构驱动转向契约驱动

一个更适合 AI 原生开发的思路是：

人负责可观察契约和风险边界，AI 负责全部内部架构。

在这种模式里，长期资产不再是某套目录结构、某个框架或者某种分层设计，而是：

产品应该表现出什么行为；
哪些业务规则永远不能被违反；
数据必须满足什么约束；
性能、成本和可靠性必须达到什么指标；
系统失败后如何恢复；
哪些对外行为必须保持兼容。

AI 可以在这些约束内部自由选择架构，也可以随时推翻自己的实现。只要所有契约仍然成立，内部到底使用了几层、多少模块、什么设计模式，就不再需要成为人的主要关注对象。

这可以称为“可抛弃实现”：

需求、契约、数据和验证体系是源代码；具体代码与架构只是当前的一次编译结果。

flowchart LR
    requirement["需求与风险"] --> contract["可观察契约"]
    contract --> implementation["AI 自由实现"]
    implementation --> validation["独立验证"]
    validation --> release["渐进式发布"]
    release --> feedback["生产反馈"]
    feedback --> requirement

    contract -. "约束" .-> implementation
    validation -. "不通过则重写" .-> implementation

“只管测试”不等于只测正常功能

如果测试仅仅覆盖“按钮能点击”“接口返回成功”“正常流程可以完成”，它还不足以替代架构治理。

要让内部架构真正可以被自由替换，测试必须成为系统的可执行宪法。

1. 用户行为测试

这一层描述用户能够直接观察到的结果，例如：

创建订单后能够正确查询；
修改设置后行为发生预期变化；
重复提交不会产生重复记录；
不同入口执行同一业务操作时结果一致。

行为测试不应该关心内部调用了哪个类、经过了多少层，只关心系统最终做了什么。

2. 业务不变量测试

行为测试描述“系统应该做什么”，不变量测试描述“系统绝不能发生什么”。

例如：

用户余额不能无缘无故增加或减少；
同一个支付回调不能导致重复发货；
一个租户不能访问另一个租户的数据；
已经确认的历史记录不能被静默修改；
任何合法操作都不能让系统进入无法恢复的中间状态。

不变量比具体流程更适合长期保存，因为它们不绑定某一种架构。

3. 数据迁移与兼容性测试

如果允许 AI 随时推翻架构，就必须把数据演化能力当成一等公民。

需要验证：

旧数据可以升级到新版本；
新版本仍然能够读取历史数据；
迁移失败后可以安全恢复；
同一迁移重复执行不会破坏数据；
迁移执行到一半被中断后可以继续；
新旧版本短暂共存时不会相互污染。

代码重构可以很快，错误的数据迁移却可能永久破坏项目。

4. 故障与恢复测试

真实系统并不总是在理想条件下运行。还需要验证：

外部接口超时会怎样；
消息被重复投递会怎样；
执行到一半时进程退出会怎样；
数据库暂时不可用会怎样；
某一步成功、下一步失败时会怎样；
服务重启后未完成任务是否能够继续；
重试是否会产生重复副作用。

如果系统可以在任意步骤失败，却仍然能够保持数据正确并最终恢复，那么内部架构的可替换性会大幅提高。

5. 非功能指标

过去很多架构讨论，本质上是在预测未来的性能、扩展性和维护性。AI 时代可以把其中一部分转化为直接指标：

请求延迟；
吞吐量；
错误率；
单次操作成本；
内存和计算资源消耗；
部署时间；
故障恢复时间；
完成同等规模需求所需的时间；
每次修改造成的回归数量。

甚至“可维护性”也可以被部分结果化。

如果 AI 实现同类需求所需时间越来越长、回归越来越多，或者每次都要求进行全局修改，那么就说明内部结构已经开始妨碍结果。此时再触发重构，而不是提前为想象中的未来设计复杂架构。

测试的修改权必须与实现权分离

完全放权模式中最重要的一条边界是：

AI 可以修改实现，但不能自行修改“什么叫做正确”。

如果同一个 AI 同时拥有代码和验收标准的最终修改权，它很容易在遇到困难时修改测试，而不是修改系统。例如：

删除难以通过的边界用例；
修改预期结果以适应当前实现；
使用 Mock 绕开真实的数据流；
将缺陷重新解释成产品行为；
降低性能或可靠性指标。

因此，测试最好分为两类。

第一类是人拥有的契约测试。它们可以由 AI 帮助编写，但测试所表达的业务含义必须由人确认。AI 未经明确允许，不得删除、弱化或改变预期。

第二类是 AI 拥有的内部测试，包括单元测试、私有模块测试和实现细节测试。AI 可以随着架构变化自由增删。

flowchart LR
    subgraph human["人拥有 · 什么叫正确"]
        direction TB
        h1["产品行为契约"]
        h2["业务不变量"]
        h3["数据与风险边界"]
        h4["性能 / 成本 / 恢复指标"]
    end

    gate["不可静默修改的验收边界"]

    subgraph ai["AI 拥有 · 如何实现"]
        direction TB
        a1["内部架构"]
        a2["单元与模块测试"]
        a3["重构与框架替换"]
        a4["实现细节"]
    end

    human --> gate --> ai
    ai -->|"提交结果"| gate

这样，人不需要审查每一行实现，却始终保留最终的产品裁决权。

避免 AI 对测试集过拟合

固定测试集还有另一个风险：AI 可能学会“通过这些测试”，却没有真正满足需求。

这和模型对题库过拟合很相似。测试全部通过，并不代表真实环境不存在测试之外的问题。

一种可行的方式是建立三个相对独立的验证来源：

根据产品需求形成的固定契约测试；
不读取具体实现、只根据契约生成的对抗性测试；
根据生产日志、真实用户行为和历史故障生成的回归测试。

可以让另一个独立上下文中的 AI 扮演攻击者，只阅读需求和外部契约，不阅读当前架构方案，专门寻找：

边界条件；
异常状态组合；
并发与重试问题；
权限绕过方式；
数据迁移风险；
实现可能钻测试空子的地方。

虽然项目仍然只有一个人，但通过上下文和角色隔离，可以减少“同一个 AI 同时出题和答题”带来的共同盲区。

一套可执行的 AI 原生工作流

基于以上思路，一个单人 AI 项目可以采用下面的循环。

flowchart TB
    s1["01 · 定义结果"] --> s2["02 · 转换成契约"]
    s2 --> s3["03 · 锁定核心契约"]
    s3 --> s4["04 · AI 自由实现"]
    s4 --> s5["05 · 独立对抗验证"]
    s5 --> s6["06 · 验证历史状态"]
    s6 --> s7["07 · 渐进式部署"]
    s7 --> s8["08 · 根据真实信号干预架构"]
    s8 -->|"新的需求与反馈"| s1

第一步：定义结果，而不是定义架构

说明用户需要完成什么、系统应该表现出什么行为，以及哪些损失不可接受。

暂时不规定目录结构、分层方式和设计模式。

第二步：将需求转换成契约

让 AI 根据需求生成：

验收用例；
业务不变量；
权限边界；
性能与成本指标；
故障与恢复要求；
数据迁移要求。

人负责检查这些内容是否准确表达了真正意图。

第三步：锁定核心契约

核心契约由人拥有。AI 可以建议修改，但不能静默调整。

修改预期行为属于产品决策，而不是普通代码修改。

第四步：允许 AI 自由实现

AI 可以选择任何适合的架构，也可以重构、替换框架、拆分或合并模块。

只要没有改变外部契约，就不要求人理解每一次内部变化。

第五步：进行独立的对抗验证

让另一个独立上下文根据需求寻找遗漏的边界条件，并补充随机测试、属性测试、故障注入和安全测试。

第六步：验证历史状态

使用真实或脱敏后的历史数据执行升级、降级、迁移中断和恢复测试。

这一步用于证明新架构不仅能处理新数据，也能接管项目过去积累的状态。

第七步：渐进式部署

通过灰度、影子流量、功能开关或小范围发布验证真实运行效果。

测试环境只能证明已知条件，生产监控负责发现未知条件。

第八步：根据结果触发架构干预

平时不主动审查架构。只有出现以下信号时，才要求 AI 解释或重组内部实现：

同类功能越来越难增加；
回归问题持续上升；
AI 频繁声称现有结构无法实现需求；
测试环境本身变得极其复杂和脆弱；
数据迁移越来越危险；
性能或成本持续无法达标；
故障难以定位和恢复；
每个小需求都需要修改大量无关模块。

这里的架构调整由真实问题驱动，而不是由抽象的“最佳实践”驱动。

哪些项目最适合这种模式

“契约稳定、实现可抛弃”尤其适合：

个人工具；
原型和实验项目；
内容型产品；
无状态服务；
数据可以重新生成的应用；
内部自动化系统；
外部依赖较少的独立项目；
失败容易发现、容易回滚的业务。

对于有用户数据、长期运行、存在异步任务或依赖多个外部系统的项目，这种模式仍然可以成立，但必须加强数据迁移、故障恢复、生产观测和兼容性验证。

对于支付、权限、隐私、医疗、安全、合规以及不可恢复数据，则不能只依赖普通的功能测试。内部架构仍然可以交给 AI，但业务风险模型、不可违反的约束和最终验收权必须由人掌握。

人最终需要掌握什么

在这种模式中，人不再需要掌握：

每一个模块；
每一条内部调用链；
每一个类为什么存在；
当前使用了什么设计模式；
AI 在某次重构中移动了哪些代码。

但人仍然需要掌握：

什么结果才算正确；
哪些业务规则绝不能被违反；
哪些数据不能丢失；
哪些操作不可逆；
性能、成本和安全的容忍边界；
出现故障后如何发现、回滚和恢复；
AI 是否有权修改某项契约。

这意味着，人的角色正在从“系统实现的理解者”转变为“系统正确性的裁判”。

结语

在传统软件开发中，架构是一项需要长期保护的资产，因为代码昂贵、重构困难、多人协作需要稳定共识。

但在单人负责、AI 实施、重构成本大幅降低的项目中，我们可以进一步放权：

不再拥有架构，只拥有契约、测试裁决权、数据安全和恢复能力。

架构可以持续变化，代码可以随时被推翻，模块也可以在不被人理解的情况下增加或消失。只要系统的外部契约始终成立，重要数据受到保护，错误能够被发现，失败能够被恢复，那么实现层面的失控并不等于项目失控。

真正危险的不是“我不知道 AI 新增了哪个模块”，而是：

我不知道什么叫做正确，也不知道系统做错以后会损失什么。

AI 时代的软件工程，或许不再要求开发者持续拥有全部代码和架构知识。更重要的能力，将是定义可验证的结果、识别不可接受的风险，并建立一套即使内部实现被完全替换，也仍然能够判断系统是否正确的契约体系。