Vercel CEO的AI编程工作流：7条关键心法

当AI编码助手能在几分钟内生成一个功能，开发者面临的新问题已经不是"能不能做出来"，而是"做出来的东西是否还在正确的方向上"。Vercel CEO 在一次深度访谈中分享了他与 AI Agent 协作的完整工作流，B站 UP 主对这场访谈进行了系统拆解，提炼出七条可直接落地的实践方法。这些方法覆盖了从想法验证、方向纠偏、安全防护到客户反馈闭环的全链路，本文逐条分析其背后的逻辑与操作细节。

用一个最小版本验证想法，而不是只靠"感觉"

Vercel CEO 提到，很多人判断模型好坏的方式是"靠感觉"——听说某个模型对某类提示词效果更好，就照着用，却从不亲自验证。他的做法是：每有一个新想法，就新建一个项目做测试，然后让一个独立的 Agent 从零检查这个想法是否真的可行，而不是听别人怎么说。

这套逻辑在实际操作中对应的是 MVP 优先策略。UP 主分享了自己的做法：每个项目先建一个 specs 文件夹放入 PRD 文档，列出计划中的核心功能。但拿到 PRD 后直接构建完整应用是危险的——方向性错误会渗透到所有早期决策中，等到发现时，返工成本已经很高。因此第一步永远是让 Claude Code 等 Agent 先做一个 MVP，用最少的代码验证"这个东西到底值不值得做"。如果答案是否定的，就尽早放弃，沉没成本极低。

警惕"方向漂移"：别用产出量衡量进展

访谈中最反直觉的观点之一：大多数人用 token 消耗量或代码变更量来衡量 AI 编程的进展，但这些数字只说明你做了多少，不说明你走到了哪里。在 Agent 时代这个问题被急剧放大——构建本身变得廉价，任何临时起意的想法都能在几分钟内变成"看起来像进展"的功能，而模型不会阻止你，因为它只会执行你要求的，并不理解哪些功能对你的产品真正重要。

解决方案是一个名为 direction 的自定义命令。把计划文件夹的路径告知 Agent，它会为每份需求文档分配一个独立 Agent 进行对照检查，主 Agent 汇总后输出完整报告：应用是否偏离计划、偏离程度评分、以及待办清单。拿到报告后你有两个选择——接受漂移并更新需求文档，或者回退偏离过大的改动。这个机制的本质是把"计划"变成可执行的校验闸门，而不是躺在文件夹里的静态文档。

自定义命令（custom command） 是 Claude Code 等 AI 编程工具提供的一种扩展机制：用户可以在项目的特定目录（通常是 .claude/commands/）下创建 Markdown 文件，文件名即命令名，文件内容则是提示词模板。之后在对话中输入 /命令名，Agent 就会加载该模板并执行。这相当于把一套固定的工作流程"固化"成可复用的指令，避免每次手动重复描述。文中提到的 direction 命令正是基于这一机制实现：它把"读取计划文件夹、为每份需求文档分配子 Agent、汇总对比报告"这一多步骤流程封装为一条命令，使方向校验变成日常操作而非一次性动作。

安全债与质量债：Agent 时代必须主动管理

Vercel CEO 反复强调的挑战是安全债——Agent 编写的代码量远超人工审查的能力上限，而攻击方同样拥有廉价且高效的模型来寻找漏洞。他的第一条规则是：功能完成后立即运行安全扫描。Vercel 为此开发了 DeepSec 工具，初始化后生成配置文件，再由 Claude 执行扫描并输出完整报告。

第二条规则是分级管理"slop debt"（为追求速度而接受的粗糙代码）。小项目可以容忍较高的粗糙度，但核心模块必须设置质量闸门（quality gate）。测试只回答"能不能用"，质量闸门还要回答"够不够好"——通过审查 Agent 对每一次变更执行标准校验，不达标不允许上线。

明确不可妥协项，并给每条规则配上验证方法

任何项目都在做取舍：加功能要花时间，加快交付就要牺牲打磨程度或成本。但有些东西不能交易。Vercel CEO 的建议是在项目的 claude.md 文件中单独开辟"不可妥协"章节，列出应用必须满足的底线要求。

关键细节在于：Agent 的上下文很长，规则容易被遗忘。因此每条规则都必须附带一条"如何验证这条规则被满足"的规则。更进一步，可以把验证测试文件提交到 git，让 Agent 无法跳过。这与前面提到的 direction 命令形成互补——后者保证方向不偏，前者保证底线不破。

claude.md 是 Claude Code 在项目根目录读取的配置文件，作用类似于给 Agent 的"项目说明书"：每次会话开始时它会被自动加载进上下文，用于声明项目结构、技术栈约定、编码规范和禁止事项。由于它随仓库一起提交，团队成员共享同一份约束，Agent 的行为因此在团队范围内保持一致。实践中通常把它写得精炼——规则越多，单条规则在长上下文中的"注意力权重"越低，越容易被忽略。这也是文中强调"每条规则必须附带验证方法"的原因：仅靠声明无法保证执行，必须给出可检查的判据。

让 Agent 主动攻击你的应用

产品上线时，Vercel CEO 没有只验证功能正常，而是把产品交给一个 Agent，要求它模拟高并发压力去"搞破坏"：并发冲突、性能衰减、跨产品对比。原因很直接：模型写代码时，写出"一切顺利时能跑通"的代码很容易，穷举所有出错路径却很难。Agent 测试自己的作品时，会按照它设计的使用方式去用，自然全部通过；但真实用户不会那样用。

具体做法是创建一个 breaker agent，其唯一职责是故意攻破应用并报告所有成功突破的路径。UP 主特别指出一个工程细节：这个 Agent 在攻击时会复制应用数据的副本，真实数据不受影响。攻击完成后可以让 Agent 修复问题并重新运行测试，甚至进入"发现—修复"的循环审查模式。

MCP（Model Context Protocol） 是 Anthropic 提出的一种开放协议，用于让模型以标准化方式连接外部工具和数据源。每个 MCP 服务器暴露一组工具（如读取邮件、查询错误日志、访问数据库），模型通过协议发现并调用这些工具，而无需为每个数据源单独编写集成代码。文中提到的 Gmail MCP 与 Sentry MCP 即属此类：前者让 Agent 能读取支持邮箱中的客户来信，后者让它能拉取应用的异常监控数据。MCP 的价值在于把"反馈来源"变成 Agent 可直接操作的工具集，从而使从报障到修复的链路可以端到端自动化。

用"首次用户"视角审视产品

Vercel CEO 最看重的指标之一是 error-free sessions 的数量——完整走完流程且没有遇到任何错误的用户数。这个指标之所以重要，是因为开发者永远无法成为自己产品的首次用户：你知道每个按钮在哪、每个页面做什么，但新用户一无所知。注册页上一个令人困惑的字段，你永远不会卡在那里，新用户卡住后直接离开，而你无从得知原因。

对应的方法论是创建一个"首访用户" Agent。关键约束是：这个 Agent 被禁止读取源代码——通过 hook 限制其 bash 工具只能用于运行应用，不能编辑或删除代码。一旦它能读代码，它就不再是首次用户了。此外还需要一个独立的浏览器测试 Agent，跑通所有客户必经路径，逐步记录结果并保存为 JSON，每次发布前运行，用于发现卡顿步骤、失效环节和中断的流程。

hook 在 AI 编程工具中指在 Agent 执行特定动作前后自动触发的拦截脚本。配置后，每当 Agent 尝试调用某个工具（如 bash、文件编辑），hook 会先运行一段自定义逻辑，根据返回结果决定放行还是阻断。这让开发者可以对 Agent 的能力施加硬性边界，而不依赖提示词中的"请不要……"这类软约束——后者在长上下文中并不可靠。文中"禁止首访用户 Agent 读取源码"正是通过 hook 限制其 bash 工具用途实现的：它只能运行应用，无法编辑或删除代码，从而保证该 Agent 的视角始终接近真实新用户。

客户反馈的响应速度，是衡量 AI 使用水平的最佳标尺

访谈的收尾观点颇具洞察力：判断一家公司是否真正用好了 Agent，看客户报障后的处理过程就够了——有没有人认真回复、有没有排查原因、明确的问题有没有被修掉、从报告到修复花了多久。

反馈分两类。截图级别的明确故障不需要思考，越快修越好；而"我用不明白"这类模糊反馈无法直接转成提示词，必须先与人沟通理解。通过 MCP 服务器可以把 Claude 接入反馈来源：Gmail MCP 读取支持邮件，Sentry MCP 捕获应用出错（即使客户没有报告）。Claude 逐条读取新报告，明确故障直接修复，需要判断的转交人工决策。这条链路把"响应速度"从一个管理口号变成了可自动化的工程流程。

七条心法的共同底层逻辑

把七条建议放在一起看，会发现它们指向同一个核心：Agent 时代，构建成本趋近于零，真正稀缺的是方向判断和质量约束。MVP 验证、direction 纠偏、不可妥协清单、breaker agent、首访用户视角、反馈闭环——这些机制本质上都是在给"廉价的构建能力"套上方向盘和刹车。Vercel CEO 在访谈中反复回到同一个判断标准：不要看你跑了多远，要看跑的方向对不对。对于正在把 AI 编程引入生产环境的团队来说，这可能是比任何具体工具都更重要的一条原则。