前言：最让我不安的，不是 AI 写错，而是它写得太像完成了

Vestigra 做到后半段，我经常遇到一种很麻烦的状态：

  • config 有了；
  • model 有了；
  • status 有了；
  • CLI 有输出；
  • test 也是绿的。

从代码 diff 看，这个功能已经相当完整。换成以前，我大概会觉得可以收工了。

但放到真实机器上长期运行，再顺着数据往下查，结果可能完全不是那么回事：状态显示 active，Endpoint 的真实订阅却已经退化；字段出现在 plan 里，却从来没有驱动 Runtime；Dashboard 把 unknown 画成了健康；Story 能从 live cache 临时算出来，却没有 durable query 面。

AI 并不一定是把代码写错了。

更准确地说，它完成了“看起来应该存在的代码”，但没有证明产品承诺真的成立。

这比编译错误难处理得多。编译器至少会指着一行代码骂我，假完成只会安安静静地躺在一片绿色里。

于是我开始重新想一个问题：当 AI 已经可以快速实现大量功能以后，人到底还应该管理什么？

Vestigra 第三阶段，折腾的已经不只是产品架构，而是整套开发系统。

一、AI 很会补齐形状，但不会自动追问语义是不是真的

在开发过程中，我开始把一类“人工在真实现场发现”的问题标记成 human。

这个标签不是拿来吐槽 AI，也不是为了证明人比 AI 高明。它只是描述一类很具体的问题：

  • 代码能编译；
  • 单元测试不是完全没覆盖；
  • 表面状态也没有明显报错；
  • 但真实运行语义已经不对了。

例如：

  • 状态显示 active，实际 Endpoint 订阅已经退化；
  • 配置字段存在于 plan / status，却没有真正驱动 Runtime；
  • Dashboard 把未知权限状态显示成健康；
  • Story 来自 bounded live cache，却被展示得像 durable query；
  • projection 已经截断，CLI 仍然像正常一样返回结果；
  • warning 藏在机器可读输出里，用户根本看不见。

AI 很擅长根据上下文补出 config、model、status、CLI 和 test 这些“一个完整功能应该有的东西”。

但它不一定会主动追问：

  • 这个字段真的驱动行为了吗？
  • 这个状态来自事实，还是来自 projection？
  • fallback 会不会把失败伪装成 success？
  • warning 对用户真的可见吗？
  • 测试跑的是构造环境，还是真实 macOS 语义？
  • 这个查询来自 durable store，还是 bounded live cache？

这些问题很多时候只能靠真实机器、长期运行、现场状态，以及人那种“总感觉哪里不对劲”的直觉暴露出来。

以前我会把它们统称为 bug，修完就关。

后来我发现，这样太浪费了。

二、human 问题不应该只被修掉，还应该反过来修改流程

如果同一类问题出现两三次，说明它已经不只是某段代码的问题，而是开发流程没有防住它。

例如：

  • 多次出现“状态绿色但真实不可用”，就应该统一建模 health、gap 和 degraded；
  • 多次出现“字段存在但不驱动行为”，验收标准就必须加入 config → runtime effect；
  • 多次出现“live cache 有结果但 durable store 没结果”，就必须把 live projection 和 materialized query 分开；
  • 多次出现“CLI text 能看但 Skill 无法稳定读取”，就应该建立稳定的 CLIResultEnvelope；
  • 多次出现“当前机器能讲故事，导出后却不能复核”，就要补上 case export / verify / replay。

所以 human 标签真正的价值，不是给问题分类，而是给流程喂反馈。

人不应该永远跟在 AI 后面修 bug。更好的做法是把每一次现场翻车变成下一轮的系统约束、测试要求和 Release Gate。

AI 犯一次错，我修一次，只能得到一个修复。

AI 犯一次错，我把它变成验收契约，才可能让后面的十次开发都少踩这个坑。

三、CLI + Skill dogfood：我不允许 AI 变成隐藏的 truth source

Vestigra 后来开始大量使用 CLI + Skill dogfood。这里最先要解决的，不是 AI 会不会分析，而是 AI 到底从哪里拿事实。

我给这条链路定了几个限制：

  • AI 不能直接读取产品数据目录；
  • 不能直接解析 ledger segment；
  • 不能绕过 product data self-protection；
  • 不能把自己的判断写成 observed evidence；
  • 不能直接执行高风险响应。

如果 AI 可以为了“方便”绕开这些边界，那么 Vestigra 前面辛苦建立的 Ledger、Evidence、Gap 和 Audit 全都白做了。

所以正确的方向应该是：

1
2
3
4
5
产品生成事实和状态
→ service / CLI 暴露稳定结果
→ CLI 输出稳定 JSON contract
→ Skill 消费 contract 并进行解释或编排
→ 高风险动作仍然经过产品策略、确认和审计

CLIResultEnvelope 对我来说不只是一个 JSON 格式，它其实是 AI 参与产品工作流的合同。

Skill 可以解释 Vestigra state、evidence、gaps、self-protect status、case results 和 performance alerts，但它不能悄悄成为新的事实源。

以前我容易把 AI 想成一个 magic backend：把数据交给它，它自然会给我一个聪明答案。

现在我更愿意把它当成一个能力很强、但必须被 contract 约束的协作者。

四、Case Export / Verify / Replay：好听的 Story 不算验收

如果一个 Story 只能在当前机器、当前 UI、当前 live cache 里看见，那它还不够可信。

尤其 AI 参与解释以后，文字可以变得很流畅，因果链也可以讲得很像那么回事。但只要离开当前环境就无法复核，它仍然只是一段漂亮叙述。

所以 Vestigra 后来补上了 case export / verify / replay 这条闭环。

一个 case 至少应该能够携带：

  • evidence-backed stories；
  • rule evaluations；
  • coverage；
  • privacy / redaction 信息；
  • integrity report；
  • gap；
  • claim；
  • 必要的 replay material。

导出以后，另一个环境仍然应该能 verify / replay。AI 生成的每个关键判断，也应该能回指 evidence、claim 和 gap。

这条要求看起来给开发添了很多麻烦，但它逼着我区分“当前界面能展示”和“结论真的可复核”。

对于安全产品，这两个完成度根本不是一回事。

五、我后来发现，Release Gate 比 Feature List 更重要

早期做项目，我很容易盯着功能列表：这个功能有没有，那个功能什么时候做完。

Vestigra 做到后面，我越来越关注另一张表：什么条件不满足，就绝对不能发。

安全产品不能因为一个按钮能点、一个 CLI 能跑就进入 release。发布前，至少要重新证明这些承诺还成立：

  • 证据仍然可以追溯；
  • Story 仍然是 evidence-backed；
  • case 仍然可以 export / verify / replay；
  • privacy / redaction 仍然生效；
  • self-protect 退化时仍然会明确暴露；
  • CLI JSON contract 没有漂移；
  • 高风险 Response 仍然受控；
  • AI / Skill 仍然不能绕过边界。

这也改变了我对“项目管理”的理解。

项目管理不只是开多少 issue、关多少任务，而是在管理：

  • 什么才算完成；
  • 什么必须可复现；
  • 什么必须 fail-closed；
  • 什么只是 warning；
  • 什么必须 block release；
  • 哪些结论必须回指 evidence；
  • 哪些能力不能过度承诺；
  • 哪些 AI 行为必须被 contract 约束。

这部分工作比让 AI 再补一个功能难多了，因为它要求我自己先想清楚产品到底承诺什么。

六、PerformanceWatch 之后，我还想让系统检查“自己有没有说真话”

PerformanceWatch 解决的问题是：程序是不是太慢。

但只盯 CPU、Memory、Queue 和 Latency 还不够。系统也可能性能完全正常，只是语义已经悄悄错了。

所以我后来开始想 Functional Watchdog。

它不问“系统快不快”，而是问“系统还诚实吗”：

  • Story 是否真的 durable？
  • live projection 是否已经截断？
  • 查询来源是 live 还是 materialized？
  • 有没有出现 out-of-order apply？
  • coverage gap 是否影响当前 Story？
  • Dashboard 是否把 unknown 显示成 healthy？
  • 配置字段是否真的改变了 Runtime 行为？
  • Endpoint Extension 授权状态是否被真实建模？

理想状态下，这套 Functional Watchdog 应该复用 PerformanceWatch 已经走过的 Self Feedback 路径：

1
2
3
4
5
6
7
发现语义退化
→ 收集上下文
→ 生成稳定报告
→ 通过 CLI JSON 暴露
→ 通知 Skill / AI
→ 进入修复工作流
→ 由同一套 Watchdog 回归验收

性能 Watchdog 解决“系统是不是太慢”。

Functional Watchdog 解决“系统是不是还在说真话”。

后者现在还不是一个可以随便夸口的完成态，它是我下一阶段想继续验证的方向。这个边界必须写清楚，否则我又会犯“有了设计名词，就当成功能已经存在”的老毛病。

七、当代码变便宜，真正昂贵的是设计开发系统

整个项目一路做下来，我的关注点一直在变。

最开始，我觉得代码实现能力最重要。

后来，我觉得架构设计最重要。

现在，我越来越觉得项目管理能力才是 AI 开发里的核心能力。

因为 AI 可以写代码、补实现、生成测试、解释状态，也可以整理一套看起来很完整的方案。但它不会自动替我决定：

  • 验收标准是什么；
  • 哪条工作流拥有事实；
  • 出问题以后通知谁；
  • 什么需要自动测试，什么必须真实机器验收；
  • 上下文怎么收集；
  • 问题怎么分类并回灌流程；
  • 哪些 Gate 不允许绕过；
  • Watchdog 最终要证明什么。

没有这些约束时，AI 的速度只是让混乱更快发生。

约束足够强以后，它才可能成为真正的工程加速器。

目前的结论：Vestigra 也成了我的开发黑匣子

Vestigra 最开始想记录的是 macOS 端点上发生了什么，把底层事件串成 Story，让用户看见证据链。

做到后来，它也开始记录我自己的开发过程：

  • 我怎么做决策；
  • AI 怎么犯错；
  • Runtime 怎么退化；
  • 自动化测试怎么漏掉真实问题；
  • 人的现场直觉怎么被变成流程输入；
  • 项目怎么从“功能完成”走向“语义可验证”。

所以 Vestigra 表面上是一个本地优先、证据中心、规则驱动、AI 辅助、受控响应的 macOS EDR-like runtime。

再往里一层，它也是我对 AI 开发方式的一次长期实验。

未来真正重要的，也许不是谁能让 AI 写代码最快，而是谁能设计出一套会持续反馈、持续修正、持续提高质量的开发系统。

至少这是我现在的阶段性结论。

等 Functional Watchdog 真正在真实机器上跑起来以后，我大概还会回来再推翻一次自己。