Lishunyang's Blog
— 文章

你的 AI demo，到底应该为谁负责？

#agentic-workflow

Demo 验证交互，scaffold 生产代码——这是两种完全不同的东西，不能互相替代。大部分真实需求都是在已有产品上迭代，代码生成必须在仓库里跑，不知道你的项目架构的 agent 生成的只是用完就扔的原型。

Shunyang LiShunyang Li

最近在搭 agentic workflow 的时候，我反复卡在同一个问题上：一个需求从提出到进入开发，中间那个"demo"到底应该扮演什么角色？

这个问题的起点，其实是一个听起来很合理的愿望。

我们希望产品和设计团队产出的 demo 原型不只是用来看的。最好是能给研发团队接着用——在这个 demo 的基础上完成后续开发，产品出交互验证稿，研发直接在上面写业务逻辑，不用从头搭页面，不用重新翻译设计稿。少了那一步"把设计稿变成代码"的翻译成本，交付速度应该快很多才对。

听上去很美好。但真要做的时候，你会发现事情没这么简单。明明是"同一个功能"，设计师眼中的 demo 和工程师眼中的起点是两种完全不同的东西。你拿着设计师的 demo 给工程师，工程师看了五分钟说："这代码我接不进去。"——不是因为代码写得差，是因为它根本不是为"被接进去"而写的。

这个问题看起来是一个沟通问题，但往深了想，它触及的是一个 workflow 设计里最基础的决策。而且我注意到，大多数团队——包括我自己——在最开始的时候都没有认真想过这件事。

在不断思考和调研的过程中，我才逐渐看清了 demo、prototype、scaffold 这些概念的细微差别——它们不是同一件事的不同叫法，而是不同的事。区分它们，是理解整件事的关键。

让我从一个反复出现的场景说起。

PM 提了一个新需求。你用 v0 或者 Lovable 或者 Bolt 生成了一个 demo，UI 精美，交互流畅，happy path 完美。你拿给 PM 看，PM 很兴奋："这差不多就是 80% 了吧？下周能上线吗？"

你知道这不是 80%。你知道这甚至不是 20%。但你说不清楚为什么——因为代码能跑、交互对、UI 好看，你没法指着任何一个具体的东西说"这是错的"。

问题不在代码质量。问题在于：这个 demo 在生成的时候，不知道你的产品长什么样。 不只是代码层面的"不知道"——它不知道你的产品里已经有哪些页面、哪些流程、哪些业务规则。它不知道你的设计系统里按钮的圆角是 6px 还是 8px。它不知道你的用户角色体系里"管理员"和"运营"看到的是不同的侧边栏。

它只是在真空中回答了一个问题："一个长这样的功能，交互应该是什么样？"

这个回答没有问题。有问题的是，你以为这个回答可以当开发起点用。

demo 的两种职责

我越想越觉得，当一个人说"我们先生成一个 demo 看看"的时候，他实际上可能在说两件完全不同的事。

第一件事：验证交互设计。 这个功能的流程顺不顺？用户能不能在三个步骤内完成核心操作？信息架构是否清晰？按钮位置是否合理？反馈是否及时？这时候，你需要的是一个高保真的、可交互的、看起来像真的一样的东西——但你不需要它的代码是真的。你甚至不需要它有代码。它的职责是回答一个问题："我们做对了吗？"答案是"对"或"不对"——然后它就可以被扔掉了。

第二件事：作为开发的起点。 交互已经验证过了，现在需要把它变成可以进入生产环境的代码。这时候，你需要的不再是"看起来对"，而是"接得进去"。你需要它使用项目已有的状态管理模式、已有的组件库版本、已有的 API 层封装、已有的错误处理约定。它的职责是回答另一个问题："这段代码能在这个项目里生长吗？"

这两个职责需要的 artifact 完全不同。前者是 prototype——为交互正确性负责，架构无关。后者是 scaffold——为架构正确性负责，交互可以逐步完善。

而且这两种 artifact 需要的生成工具也完全不同。prototype 可以在 sandbox 里生成——它不需要知道你的项目、你的产品、你的设计系统。scaffold 必须在仓库里生成——因为架构正确性的判断标准，全部在仓库里。

我意识到大部分关于"AI 生成代码质量"的讨论，混乱的根源就在这里：人们在用同一个词（"demo"）指代两个职责完全不同的东西，然后用同一个标准去评价两种完全不同的产出。

为什么大部分真实工作应该走 scaffold 路线

这里有一个很现实的判断。我个人的倾向是，大部分需求开发应该走 scaffold 路线——也就是 repo-aware 的代码生成——而不是 prototype 路线。

不是因为 prototype 没用。是因为大部分需求都不是从零开始的新产品。

你想想你最近做的需求。是在一个新项目里从零搭建，还是在已有产品上增加功能、修改行为、替换模块？我在自己的实践里，超过 90% 的工作是后者。而后者意味着：你生成的代码必须跟已有代码共存。它必须知道已有代码做了什么、怎么做的、用的是什么。

这件事比"代码架构"宽得多。我越来越觉得，当我们说"repo-aware"的时候，其实在说三层东西。

第一层是代码架构。 这是最直观的。依赖版本、状态管理模式、文件夹约定、TypeScript 配置、lint 规则。Alex Rusin 的实验是一个很好的例证——Claude Code 生成的 scaffold 结构完美但 Prisma 版本错了，一个版本错误就让整个模块系统从 CommonJS 变成 ESM 才能工作。这是代码层面的"不知道"。

第二层是产品架构。 这个功能在产品里的位置是什么？它跟哪些已有功能有交互？它需要尊重哪些已有的业务规则？用户的角色和权限体系是什么样的？导航结构是怎样的？这些信息不在代码里显式存在——它们在 PRD、设计文档、团队的共同理解里——但它们同样决定了生成的代码能不能用。一个不知道你的产品有"管理员"和"普通用户"两种角色的 agent，生成的 dashboard 页面不会包含权限判断。一个不知道你的产品已经有过"订单详情"页面的 agent，会生成一个全新的、跟已有页面不一致的路由。

这一层比代码架构更隐蔽，因为它的"错误"不会让代码崩溃。它会以"功能上没问题但产品上不对"的形式出现——而这类问题通常要到测试甚至上线后才被发现。

第三层是 UI 架构。 你的设计系统里定义了间距 scale、颜色 token、字体层级、组件变体。你的产品里每个页面的 header 高度是一致的，每个表单的校验文案用的是同一种语气，每个空状态的插图是同一套风格。一个在 sandbox 里生成的 demo 可以用 Tailwind 的默认 spacing——因为它不知道你的设计系统里 spacing 是 4 的倍数还是 8 的倍数。它可以用 #3B82F6——因为它不知道你的 primary-500 变量是什么。

这不是"UI 好不好看"的问题。这是 UI 一致性——产品感受的基础——被 sandbox 的隔离环境悄悄地侵蚀了。

三层加起来，就是 Charity Majors 说的 "durable code" 的前提条件。sandbox 里生成的代码不知道这三层中的任何一层，所以它生成的不可能是 durable code。它只能是 disposable code——用完就扔。

那 prototype 还有用吗

有用，但它该安分地待在它该待的地方。

prototype 的正确位置是交互设计验证节点，不是代码生成节点。在一个合理的工作流里，prototype 应该在设计阶段被生成、被 review、被用来跟 stakeholder 对齐交互预期——然后被扔掉。它不应该进入开发阶段。开发阶段的输入应该是 spec（设计约束）加上 codebase（架构约束），产出的是 scaffold——能直接在已有项目中生长的代码。

Vercel 的 v0 pivot 是对这件事最诚实的承认。v0 v1 生成 prototype，用户发现复制粘贴的代码需要重写才能进入生产。v0 v2 不再让你复制粘贴了——它直接接入你的 GitHub 仓库，在已有代码的上下文中生成。生成的不再是"一段能跑的 UI 代码"，而是"一段属于你这个项目的代码"。

Vercel 的选择是：prototype 工具的终局是 scaffold 工具。他们选择跨过 sandbox 和 repo 之间的那条线。

但这不是唯一的答案。Google Stitch 走的是另一条路——它不试图生成 scaffold，而是让设计交付物本身（DESIGN.md）变成机器可读的约束，然后交给 repo-aware 的 agent 去实现。prototype 和 scaffold 之间的 gap，它们没有试图用 AI 来跨，而是用结构化 spec 来桥接。

哪种路线更对，我不知道。但两种路线都承认了同一件事：prototype 和 scaffold 是两种不同的东西，你不能把一个当另一个用。

对 workflow 设计意味着什么

如果你在搭 agentic workflow，这件事会影响一个很具体的决策：代码生成节点应该在哪里运行。

如果这个节点的职责是验证交互——在 sandbox 里跑，用 prototype 工具，产出 disposable artifact，不进入开发管道。

如果这个节点的职责是产出可进入开发的代码——在 repo 里跑，用 repo-aware agent，产出 scaffold，直接走 review 和 merge。

这两个节点不应该混在一起。你不能在 sandbox 里生成一段代码然后假装它可以当 scaffold 用——因为它出生的时候没有见过你的三层架构，它从基因上就是 prototype。

而且对于大部分真实工作——在已有产品上迭代——你应该默认走第二条路。

demo 的正确职责是验证交互，不是生成代码。把它当开发起点用，是 workflow 设计里最贵的错误。

我现在还没搞明白的一些事

写到这里，有几个问题我还在转。

一个是产品架构和 UI 架构的约束，应该以什么形式编码到仓库里，让 agent 能读到？代码架构的约束天然在代码里——package.json、tsconfig、已有组件的写法。但产品架构——特征开关、用户角色、业务流程——通常不在代码里，在人脑子里。UI 架构——设计 token、组件变体、交互模式——可能在 Figma 里，可能在 Storybook 里，可能在一个 PDF 设计规范文档里。AGENTS.md 和 CLAUDE.md 可以承载一部分，但它们能承载多少？会不会变成另一个需要手动维护、跟现实脱节的文档？

另一个问题是，prototype 真的应该被完全扔掉吗？Vercel 的选择是"prototype 工具的终局是 scaffold 工具"，放弃了 prototype 和 scaffold 之间的中间地带。但有没有可能做一个 hybrid 节点——用 prototype 验证交互，然后 agent 读取 prototype 的交互逻辑，在 repo 里重新生成 scaffold？这相当于让 agent 来做"从交互验证到架构实现"的翻译，而不是让人类来做。我不知道这个方向技术上有多可行。Rusin 的实验已经显示了 re-scaffolding 的脆弱性——在没有 repo 上下文的情况下，连依赖版本都搞不对。也许 hybrid 模式的前提跟 scaffold 模式一样：agent 必须有 repo 访问权。

还有一个维度我最近才开始想。这三层架构之间可能有优先级差异。代码架构错了，编译不过或者运行时炸，容易发现。产品架构错了，功能行为不符合预期，测试阶段能发现一部分。UI 架构错了，交互一致性被破坏，可能要到用户感觉到"这个产品越来越乱了"的时候才会被发现——而那时候已经积重难返。如果三层架构的"错误可检测性"不一样，那 workflow 的设计是不是应该对它们区别对待？比如代码架构用自动化检查（lint、type check、test），产品架构用 review gate，UI 架构用 visual regression test？

最后一个问题可能是一个反驳我自己的方向。如果 repo-aware 工具的终极形态是你给了它仓库访问权之后，它能自动从代码、commit history、PR discussion 中推理出产品架构和 UI 架构——那是不是就不需要显式编码这些约束了？Claude Code 在 2026 年已经能通过阅读代码推断出很多项目约定，但这个能力在多大程度上能延伸到产品逻辑和设计系统？"读代码推断产品规则"这件事有天花板吗？还是它只是一个模型能力的问题，随时间会解决？

参考文献

— 分享
分享到 X分享到微博