Vibe Coding 的 70% 之后

Addy Osmani 的《Beyond Vibe Coding》共有 11 章、254 页。全书从 Vibe Coding 和提示词起步，经过原型、Web 开发与代码审查，最后进入安全、伦理、后台 Agent 和职业变化。

它讨论的核心问题很朴素：模型已经可以在几分钟里搭出一套像样的软件，接下来谁来理解它、验证它、维护它，并在出事时承担责任？

这篇文章最初用一个虚构的会话复盘工具贯穿全书。用户上传 Agent 执行日志，系统在后台分析，最后生成一条可以分享的报告链接。登录、上传、分析、分享四个步骤很适合解释提示词、异步任务、权限和隐私，却也有一个缺点：虚构项目总会在作者需要的时候，恰好出现作者准备讲的问题。

真实工程没有这么配合。问题最初经常被归因到错误方向；一次修复可能只把故障稀释；每个模块单独看都合理，串起来却表达了互相冲突的事实。负责其中任何一个局部的人，也未必能提前看见完整系统。

所以这次我保留书里的框架，把贯穿案例换成自己在 Corevo 参与实现、排障和验收时遇到的三个现场：

1. Workspace 已经有了 owner/admin/member，权限为什么仍然没有完成；
2. API 都能正常工作，为什么一个同步边界仍能让无关请求一起停顿；
3. Agent 已经能在沙箱读写文件，为什么 5GB 共享空间和真实 E2E 会推翻“文件链路已经打通”的结论。

文中只保留理解工程问题所需的结构和脱敏指标，不包含人员、客户、凭证、内部地址或公司源码。它们也不是 Corevo 当前容量与产品能力的承诺，而是我用来解释“70% 之后”的一手证据。

70% 是一种完成感

先回到会话复盘工具的第一个晚上。把下面的需求交给编码模型：

做一个 Agent 会话复盘工具。
用户可以上传 JSON 日志，查看分析进度，完成后得到一份报告。
使用 React、Go 和 SQLite，界面简洁，支持登录和分享。

模型很快就能创建路由、表单、数据库表和几个 API。启动服务，页面有 loading、成功提示和空状态。上传一份样例日志，几秒后报告出现在屏幕上。过去要先搭脚手架、查组件文档、写重复 CRUD，现在第一天就能用真实页面检验产品想法。

这里的速度是真的，完成感也是真的。问题在于，团队此刻计算进度的分母通常只有“用户能看见的主流程”：

登录 → 上传 → 等待 → 查看 → 分享

第一个真实用户进来以后，分母会突然变大：

身份属于谁
大文件怎样进入
重复请求怎样合并
任务由谁领取
进程重启后怎样恢复
结果怎样授权
日志怎样脱敏
依赖超时留下什么状态
失败以后能否重试和回滚

代码没有突然从 70% 倒退到 30%。团队只是第一次看见了完整问题。书中所谓的“70% 问题”，更接近这种分母变化，而不是一条可以统计的代码比例。

探索阶段和工程阶段都需要 AI，只是完成条件不同：

下面三个 Corevo 现场，都发生在“主流程已经能跑”之后。

第一个现场：三个角色只完成了权限的外壳

Workspace 需要 owner/admin/member 三个角色。这个需求看起来很适合快速实现：成员关系增加 role 字段，后端补几个枚举，管理页放一个角色选择器，member 进入只读状态。

这些工作可以很快完成，也容易演示。owner 邀请成员，把某个人从 admin 改成 member，页面重新加载后显示正确角色。若把验收范围停在这里，功能确实已经完成大半。

角色功能落地后的同一轮联调里，系统又连续补了几类行为：

• member 的前端写操作入口需要隐藏；
• Workspace 资产入口和资产装备按钮需要按能力收窄；
• 团队模型 Key 要区分创建、共享、使用、隐藏和成员自助接入；
• 切换、退出或解散 Workspace 时，access token、refresh token 和前端 Workspace 状态要一起更新；
• Agent 真正执行时，运行环境只能得到本次身份允许的资产与凭证。

这几件事并不是互不相干的 UI 补丁。它们共同揭示了最初的问题定义太窄：团队以为自己在“增加三个角色”，实际要完成的是“重新定义一个人在 Workspace 里对各种资源拥有什么能力”。

角色告诉系统“他是谁”，没有告诉系统“他能做什么”

假设 Bob 是 Workspace A 的 member。只知道 role=member，还不足以回答下面这些问题：

“member 是只读角色”也不能一次回答这些动作。Bob 可能可以读取 Workspace 资料、运行已经配置好的 Agent、使用创建者共享的模型能力，同时不能查看共享 Key 的明文、不能修改公共资产；系统又可能允许他接入一把只属于自己的模型 Key。

这里至少有五个维度：

主体 Subject
  × 当前上下文 Context
  × 目标资源 Resource
  × 请求动作 Action
  × 附加条件 Condition

一条真实能力可以表达成：

Bob
在 Workspace A
通过 Agent 使用模型凭证 K
条件：K 由创建者共享，只允许运行时使用

同一套规则会允许 Bob → 使用 K 执行 Agent，同时拒绝 Bob → 查看 K 明文、Bob → 修改 K 和 Bob → 把 K 转发到另一个 Workspace。权限因此更像一张能力图，角色只是这张图的一组输入。

隐藏按钮解决不了越权，后端拦截也解决不了错误体验

member 不能写时，前端应该隐藏或禁用写入口。否则用户会不断点击一个必然返回 403 的按钮。但安全边界不能依赖按钮是否可见：浏览器请求可以被手工构造，旧客户端可能仍然保留入口，后台 Agent 也不会经过同一套页面。

同一个能力需要在不同位置得到一致答案：

前端：展示可用动作，避免诱导错误操作
API：以服务端身份为准，拒绝越权请求
WebSocket：长连接期间继续携带正确上下文
资产服务：区分可见、可装备、可修改和可执行
凭证服务：允许受控使用，不泄露明文
运行环境：只注入这次执行实际获准的能力
审计：记录谁在什么上下文使用了什么能力

只补其中一层，系统都会留下旁路。

Workspace 切换让一个普通角色问题进入认证状态机

假设 Bob 从 Workspace A 切换到 Workspace B。页面把当前 Workspace 改成 B，新的 access token 也包含 B；但旧 refresh token 仍绑定 A。等 access token 过期，刷新接口可能再次签发 A 的上下文。

此时浏览器以为自己在 B，后端却按 A 解析身份。轻则列表跳回旧空间，重则一个请求带着错误的 Workspace 边界继续执行。正确切换需要原子更新 access token、refresh token、前端状态和后续连接使用的上下文，缺一项都会形成“当前空间”分叉。

一个角色下拉框，最后触及 UI、认证、资产、凭证和 Agent Runtime。这里的后 30% 没有多少炫目的新页面，它在决定系统里的“当前用户”究竟是谁。

人同样很难第一次想全

这些遗漏不能简单归因于 AI。产品、前端、认证、资产和沙箱分别掌握一部分事实，任何一个人都未必能自然拥有整张能力图。有些规则甚至没有唯一答案：member 能不能接入自己的模型，属于产品决策；共享 Key 能不能被使用但不显示，属于安全和运行时共同定义的能力。

AI 加快了字段、接口和页面的落地，也让“已经完成”的外观更早出现。真正有效的改进不是要求模型一次猜中全部规则，而是先把能力矩阵写出来，再让所有执行入口服从同一份契约，并用无 membership、跨 Workspace、直接调用 API、凭证不可见等反向测试固定边界。

第二个现场：API 都能用，一个同步边界仍能冻结所有请求

Corevo 的另一个现场发生在生产调度器里。单看功能，每条 API 都能响应，Agent 可以执行，数据库也没有损坏。系统真正暴露的是延迟：一次问题发生前，event-loop lag 的 P95 已到 472ms，HTTP P99 接近 10 秒。

有一段时间，增加 Uvicorn worker 数量缓解了现象。更多进程把阻塞稀释开，单个 worker 停顿时，其余 worker 还能接请求。这个动作有现实价值，却也容易制造第二次完成感：指标下降了，问题似乎已经解决。

后来重新审计调用链，根因仍然存在。部分 async def 路由内部执行同步 HTTP、同步 ORM、文件读写、对象存储或 CPU 密集操作。某个协程等待这些操作时，负责同一批连接的 event loop 也一起等待。于是一个用户触发重操作，登录、心跳和其他会话都可能同时变慢。

局部代码经常长得很正常：

async def handler():
    data = sync_client.fetch()
    return data

fetch() 自己可能完全正确，异常处理也很完整。错误发生在调度关系上：它被放进了一个需要持续服务其他协程的共享线程。

“加 worker”为什么只是稀释故障

增加 worker 改变了故障半径，没有消除阻塞边界。原本一个同步调用会停住全部请求；增加进程后，它只停住落到同一 worker 的请求。流量继续增加，或者多个 worker 同时命中重操作，问题还会回来。

这类问题很容易让人和模型都误判：

• 单元测试调用一次接口，会通过；
• 本机只有一个用户，感觉不到无关请求停顿；
• 函数自身没有明显错误；
• 增加 worker 后监控短期好转；
• 代码里的 async def 又给人一种“已经异步”的熟悉感。

真正有区分度的证据，是重操作发生时，无关心跳和轻量接口是否同时停顿。

从修几个调用点，走到全仓可执行规则

后续治理没有停在搜索几处 requests.get()。一次全仓审计覆盖了 8,113 个非忽略文件、3,208 个 Python 文件和 9,868 个 async def。初始静态规则在运行时代码里找到 127 个同步阻塞命中，另有 150 个“没有真实 await、内部只做同步 ORM”的异步路由，分布在 27 个文件中。

真实索引也进入了验证。一份约 333MB 的向量 JSON 加载耗时 3.254 秒，第一次检索 0.497 秒，缓存后的检索降到 0.003 秒。这个结果没有说明“缓存就够了”；它说明加载、解析和首轮矩阵构造必须离开主事件循环，并且需要明确的内存与准入边界。

最后形成的产物包括：

• 同步 SDK 在 adapter 边界统一卸载，能用原生 async client 的地方直接使用 async；
• 重文件与 CPU 阶段进入有界 worker，避免把 event-loop 阻塞改造成无限线程和磁盘风暴；
• Ruff 的 async 规则进入默认 lint；
• AST 契约测试扫描同步 ORM、目录遍历、大文件 I/O 和锁内 await；
• 真实大索引与分层回归结果作为验收材料保留下来；
• 已知的旧测试失败明确归因，没有为了“全绿”重新恢复已经退役的旧事实源。

完整的 event loop、持久 Job 和跨 worker 租约演进，我另外写在《单体里的分布式系统》。放到这篇里，它最重要的意义是：一次故障真正完成的标志，不是某个调用点多了一行 to_thread，而是下一位开发者和下一轮 Agent 再写出同类代码时，lint 和测试会立刻阻止它。

事故在这一刻才变成了项目记忆。

第三个现场：沙箱已经能读写文件，5GB 以后整个模型变了

Agent 沙箱的文件链路看起来也有一个清晰主流程：

创建 microVM
→ 把当前会话和共享文件投影进去
→ Agent 调用 bash / Python / file tool
→ 扫描变化
→ 把允许的结果写回持久事实源
→ 回收沙箱

普通文件、少量 Skill 和 Tool 能够创建、修改、读取和删除时，“沙箱文件能力已经打通”是一个合理判断。ensure 和 kill 都稳定，单个用例也能形成正确文件与 revision。

后来我在隔离的类生产环境里构造了一个 4.92GiB 的共享空间：30,007 个文件，其中 30,000 个是 16KiB 小文件，另有 7 个大文件。测试仍走真实的 ensure、投影 prepare、沙箱内命令、扫描、写回和 kill 链路。

结果很有区分度：创建 microVM 只要约 600ms，kill 约 100ms，控制面没有明显问题；系统真正崩在“把授权文件准备给 Agent”这一步。

一个正确的小文件循环，怎样放大成系统故障

当时的投影逻辑先把所有授权文件内容读进内存，再统一写入沙箱。它对十个小文件完全合理，对 4.92GiB 视图则会让 5GiB 内存限制的整个后端进程直接 OOM。死掉的不只是发起工具调用的会话，同进程里的其他请求也会一起失去服务。

海量小文件暴露了另一个维度：30,000 个文件的同步拷贝耗时 22.7 到 25.7 秒，event-loop lag 峰值达到 27.3 秒。这段 prepare 又没有进入已有的创建、连接或工具执行超时预算，时间上没有明确上限。

更麻烦的是，每次工具调用都会先清空投影目录，再把全部共享文件重新复制。即使 Agent 只执行一个空转的 true，warm 执行仍可能花 29.5 秒。一个会话调用 20 次工具，意味着同一批数据被重复搬运 20 次；多个会话并发时，磁盘与内存成本继续相乘。

压测还发现了几种主流程截图里看不到的语义错误：

这几个问题没有否定“文件 API 能工作”。它们改变的是交付结论：系统必须在执行前计算容量，超限时明确拒绝；投影要流式、增量并离开 event loop；扫描截断必须成为用户可见错误；失败后的状态、实例和目录要能对账回收。

四十一条看起来正确，仍然不能把 56 条验收写成通过

完成一轮修复后，文件与资产链路又进行了一次真实 dev 网页端 E2E。验收不是只看 Agent 的最终回复，而是交叉读取执行、工具调用、FileEvent、文件 placement、审计、资产 revision、binding 和持久卷事实。

56 个用例的第一次结果是：36 条通过、5 条通过但有告警、2 条部分通过、7 条失败、6 条未验证。普通会话文件的 9 个用例全部通过，真正阻断发布的是跨层一致性：

• ignored 内容没有进入持久 revision，却仍残留在下一次 execution 的沙箱视图；
• 非法 Subagent 在页面上显示失败，底层却已经产生 revision、FileEvent 和物理文件；
• Tool Pack 的物理目录删除了，部分 child revision 和 binding 仍然保持 enabled；
• 一个无关 MCP 写回会被已有 Tool Pack 的 baseline 冲突牵连；
• “新会话读取共享文件”的步骤实际上没有创建新会话；
• “点击停止”和“双标签并发写入”没有真正发生，因此不能算作取消和并发已验证。

这里最重要的动作，是把结论写成“不通过”。41 条最终结果正确，不能覆盖 7 条明确失败；测试人员写下了 prompt 没有真正执行关键前置，也没有把“未验证”包装成“可能没问题”。

AI 很擅长生成测试，也能帮助检查数据库和日志。可交付判断仍需要一个责任主体回答：这些证据是否覆盖了我们准备宣称的能力？失败返回以后已经产生副作用，算失败还是部分成功？持久事实正确但下一轮 RuntimeView 错误，用户到底处于哪个现实？

最后 30% 的难点，在这些问题里已经不是代码数量。它要求系统为“成功、失败、取消、重试、并发和恢复”分别定义可观察事实。

提示词要从需求描述升级成任务合同

第一轮 Vibe Coding 常用一句目标启动工作，这在探索阶段很高效。进入权限和运行时链路后，提示词需要减少模型替团队做决定的空间。

以 Workspace member 为例，一轮更可靠的任务合同可以写成：

目标：为 Workspace member 落地只读协作能力。

现状：身份来自服务端 access/refresh token；WorkspaceMembership 保存角色；
资产、模型凭证和 Agent 运行时分别有独立服务与授权入口。

不变量：
1. 前端隐藏写入口，但安全不能依赖前端；
2. member 可以使用明确共享的模型能力，不得读取共享 Key 明文；
3. member 可以接入自己的模型，不能修改创建者的配置；
4. 切换 Workspace 时 access token、refresh token 和前端状态必须原子一致；
5. API、WebSocket、资产服务与运行时注入必须得到同一授权结论。

验收：
- 直接调用写 API 返回拒绝且不产生副作用；
- 跨 Workspace 读取、装备资产和查看 Key 明文均失败；
- token 刷新后仍停留在目标 Workspace；
- 运行 Agent 只注入允许使用的资产和凭证；
- 覆盖 owner/admin/member 正向与反向测试。

交付：先列能力矩阵和全部执行入口，再修改代码；
给出测试结果、未覆盖场景、兼容影响和回滚办法。

这里没有特殊咒语。目标、现状、不变量、验收和交付把一次聊天变成了可以核对的任务。模型少猜一步，评审者就少追一次事故。

复杂任务还要分轮推进：第一轮只读仓库和调用链；第二轮冻结角色与能力矩阵；第三轮实现一个垂直切片；第四轮补直接 API、跨空间和凭证泄露等反向证据；最后才扩大到所有入口。一次生成几十个文件看起来省时，评审时却很难判断错误假设从哪里扩散。

提示词装不下长期事实，仓库必须会记忆

Corevo 的租户与 Workspace 改造期间，团队专门给产品侧 Vibe Coding 写过一份文件系统原则。它没有禁止快速做页面、交互、状态、预览和临时适配，约束的是哪些东西不能因为实现方便就变成长期事实：

• 物理路径不能成为文件归属和权限判断的依据；
• 不能复制整个历史目录来冒充 Workspace Fork 或数据迁移；
• 不能继续把旧 team_id 当成租户、Workspace、文件和权限的万能字段；
• 不能解析 Agent 最终回复里的 Markdown 路径来创建正式 Artifact；
• Agent、Skill、Tool、MCP 和 Credential 不能被当作普通 Workspace 文件；
• 后端尚未实现的能力可以先做 UI 占位，但不能顺手发明一套相反的稳定接口。

这份规则划出的边界很实用：可逆的体验可以快速试，不可逆的数据模型和权限语义要等待契约。Vibe Coding 不需要退出项目，只需要在风险上升时切换工作方式。

长期有效的上下文也不能只存在于一次提示词里：

类型和 schema       保存数据边界
领域文档             保存已经作出的决定
正向/反向测试        保存历史行为
lint 和静态扫描      保存禁止再次出现的模式
验收材料             保存这次结论依据什么证据
发布门禁             保存什么条件下可以交付

会话会结束，模型会更换，成员会流动。只有进入这些载体的经验，才能继续约束下一轮实现。

代码接管要沿着系统走，而不是只沿着文件读

生成代码经常有一种迷惑性：命名完整，注释流畅，结构也很像团队里的既有实现。熟悉感只能说明它接近训练数据里的常见答案，无法证明它符合当前系统。

接管一段生成实现时，我更愿意沿一次真实请求走几遍：

1. 意图遍：它解决的是原始需求，还是模型自己补出的相邻需求；
2. 身份遍：用户、Tenant、Workspace、Session 和 Execution 身份从哪里来，中途会不会变化；
3. 数据遍：数据在哪里创建、复制、缓存、持久化和删除，哪个才是事实源；
4. 失败遍：超时、重试、进程退出和部分成功分别留下什么；
5. 并发遍：两个请求同时做这件事，谁拥有状态，迟到结果还能不能写；
6. 权限遍：查看、使用、修改、分享和运行时注入是否被错误地合成一个动作；
7. 证据遍：现有测试真正执行了关键前置，还是只验证了一个更容易的替代场景。

函数长度、抽象和命名仍然重要，但它们应该排在系统不变量之后。一个漂亮的 helper 也可能从请求体读取 user_id，把身份决定权交给客户端；一个测试名可以写着“跨会话”，实际执行仍然停留在同一个会话里。

后台 Agent 会同时放大吞吐和分歧

书中后段讨论后台编码 Agent。人把目标交出去，Agent 在隔离环境里读仓库、修改代码、运行测试，几十分钟后带回 diff 或 Pull Request。多个任务可以并行，工作节奏从持续结对变成派发、等待和集中审查。

Corevo 这类跨认证、资产、文件和 Runtime 的系统，很容易出现三个 Agent 各自正确、合起来错误的情况：

• 一个 Agent 修改 Workspace token；
• 一个 Agent修改 member 的资产入口；
• 一个 Agent 修改模型 Key 的共享规则；
• 三者都通过自己的局部测试，却对“member 可以使用什么”给出不同答案。

并行能力会放大任务合同的质量。边界清楚时吞吐上升，边界含糊时，团队会更快得到一组互相冲突的解释。

一条更可靠的执行链通常是：

冻结领域契约
→ 拆出互不重叠的任务边界
→ 独立工作区与最小权限
→ Agent 计划、实现和自测
→ 契约测试、lint、安全扫描和真实 E2E
→ 提交 diff、证据、已知失败和剩余风险
→ 人工判断是否合并与发布

适合并行委派的任务往往有稳定复现、明确边界和确定性验收，例如补反向测试、机械迁移、清理静态违规和修复局部缺陷。跨系统权限语义、生产事故和模糊产品决策，需要先由人把冲突显式化，再交给 Agent 扩大实现和验证吞吐。

人也做不到一次想全，人的职责是组织不确定性

说到这里，很容易把文章误读成“AI 做前 70%，人类工程师负责最后 30%”。Corevo 的经历恰好反对这个简单分工。

人一样会漏权限、把同步调用写进异步路由、相信一组没有真正执行前置的测试，也会用增加 worker 暂时掩盖根因。权限和运行时知识分散在不同模块，很多规则只有经过真实用户、生产负载和失败现场才会显形。

AI 造成的主要变化，是系统更早拥有完整外观：字段、API、页面、测试名和文档可以在很短时间内同时出现。讨论和建模还没有跟上，产品已经看起来像是完成了。错误假设也会被更快复制到多个入口。

人的价值不来自全知，而来自三种责任：

1. 决定语义：member 能不能接入自己的模型，失败后是否允许部分结果，都没有唯一技术答案；
2. 判断证据：41/56 的最终结果正确，能不能宣称功能完成，需要有人对声明范围负责；
3. 承担取舍：哪些风险可以暂时保留，哪些必须 fail-closed，什么时候可以发布，需要明确责任主体。

AI 可以帮助列能力矩阵、扫描入口、生成反向测试、分析日志和复核证据。真正成熟的协作方式，是让 AI 参与后 30% 的绝大部分工作，同时让系统和负责人共同决定完成条件。

这个学习循环比“最后由人手写”更重要：

用户与生产暴露事实
→ 团队修正问题模型
→ 把结论写成不变量
→ 让 Agent 实现并扩大验证
→ 测试、lint 和 E2E 固定证据
→ 发布后继续观察

系统不会因为有资深工程师就自动可靠，也不会因为大量代码由 AI 生成就必然失控。关键在于，它能不能把每次新认识沉淀成下一轮不可轻易越过的工程记忆。

安全、数据和责任不会因为生成更快而消失

书中还专门讨论知识产权、透明度、公平和责任。Corevo 的模型 Key 场景提供了一个很具体的提醒：用户“能够使用一项能力”，不等于他应该看到支撑能力的原始秘密。凭证可以在运行时受控注入，前端和普通日志不需要获得明文。

输入端也一样。客户代码、生产日志、密钥和个人信息能否交给外部模型，要看工具的数据政策与组织授权。把敏感日志粘进聊天窗口是一次已经发生的数据传输，之后删除本地会话无法收回它。

自动生成的依赖与实现还需要来源和许可证检查。异常完整的注释、特定项目名或大段风格突变，都是停下来核查的信号。关键模块由 AI 深度参与时，团队应保留人工审查和自动验证的证据。

这些工作很少出现在漂亮的首屏截图里，却决定了一个系统能不能接触真实用户与真实数据。

70% 之后，工作对象已经变了

回看三个 Corevo 现场：

• Workspace 出现三个角色，只完成了权限的名称；后续工作是在所有执行层建立一致的能力图；
• API 全部能响应，只完成了功能路径；生产延迟迫使团队重新定义同步边界和共享调度责任；
• 沙箱可以读写文件，只完成了小规模成功路径；5GB 压测与真实 E2E 才暴露容量、部分成功、残留和事实源分叉。

它们都有同一种节奏：可见功能先完成，系统语义随后显形，最后再把教训压进契约、测试、lint、验收和发布门禁。

因此，70% 之后并不是 AI 退出、工程师回来手写剩余代码。工作对象已经从“生成更多实现”转向“定义系统相信什么，并拿出足够证据证明它在成功和失败时都守得住”。

这本书留下的规则，可以结合这些现场改写成一句话：

模型负责扩大探索、实现与验证的吞吐；人负责决定语义和证据门槛；系统负责把每次踩坑变成下一轮不会轻易倒退的约束。

资料

• Addy Osmani：Beyond Vibe Coding，O’Reilly，2025。
• 公开章节预览：70% 问题、理解并接管生成代码、安全、维护与可靠性、后台编码 Agent。
• O’Reilly 正式中文版：《超越Vibe编程》。
• Corevo 案例来自脱敏后的工程文档、压测结果、E2E 验收与提交轨迹；内部地址、身份、凭证和源码未进入本文。