当AI Coding遇上大型项目，从Vibe Coding的爽快体验到Harness系统的构建，产品经理的角色正在被重新定义。本文深入剖析AI在大项目中为何容易失控，并提出从执行环境到自进化的五层Harness能力框架，揭示产品经理如何从需求投喂者转型为AI工作系统设计师。

过去一段时间，很多产品经理对 AI Coding 的体验大概是这样的：

小需求很爽。让 AI 写一个落地页、做一个内部工具、改一段交互，很快就能看到结果。你甚至会产生一种错觉：是不是以后只要“把想法说清楚”，产品和研发之间的大量摩擦就会自动消失？

但项目一旦变大，另一种体验很快出现：AI 产出越来越多，错误也越来越分散；代码能跑，但你不知道它改了哪里；需求被实现了一半，却埋下新的技术债；几个 agent 同时工作，看似并行，最后却变成你一个人排队验收、救火和兜底。

这就是 Vibe Coding 的上限：它擅长把灵感变成原型，却不天然擅长把复杂系统变成可持续交付。

一、为什么小项目很爽，大项目会塌？

小项目里，AI 的优势会被放大，因为上下文小、验收简单、错误成本低。你看一眼页面，点几下功能，基本就能判断它有没有做对。

大项目完全不同。它的风险通常不是“AI 不会写”，而是：

• 上下文太长，AI 记不住真实业务边界；
• 依赖太多，一个小改动牵动多个模块；
• 验收太慢，问题堆到最后才暴露；
• 并行任务太多，人类反而成了瓶颈；
• 技术债被更快地产生，也被更慢地发现。

所以，“纯 Vibe Coding 做大项目会塌”并不是一句唱衰 AI 的话。它真正指向的是：当 AI 的产能超过团队的治理能力，项目会以更高速度积累混乱。

产品经理尤其要警惕这一点。过去我们担心研发资源不够，现在更常见的问题可能变成：AI 给了你更多产出，但你没有足够清晰的边界、验收和优先级来管理这些产出。

二、Harness：不是多写 Prompt，而是给 AI 搭生产系统

在这期节目里，徐文浩反复提到一个词：Harness。

如果把 AI Agent 看成生产系统里的新角色，Harness 不是角色本身，而是它的运行环境、协作协议、权限边界和检查站。它的目标不是限制 AI，而是让 AI 能稳定地处理更长链路的任务。

对产品经理来说，可以把 Harness 理解成五层能力：

第一层是执行环境。让 AI 在远程机器、沙盒、dev container、worktree 里工作。核心不是炫技，而是隔离风险：AI 可以大胆执行，但不能轻易炸掉主工程。

第二层是对话上下文。一个 agent、一个频道、一个任务线程，把上下文拆开，避免不同任务互相污染。产品经理可以把它理解成“一个目标一个工作台”。

第三层是工程门禁。代码提交后，不是靠人肉看一遍就结束，而是自动跑格式检查、重复率检查、lint、命名规范、自动化测试、测试录屏、双重 code review。

第四层是治理节奏。不是每天让 AI 报八类问题，而是按天处理不同主题。周一看代码质量，周二看体验验收，周三看用户反馈，周五专门优化流程。人类的注意力也要被产品化。

第五层是自进化。记录 AI 执行中的摩擦：哪里缺权限、哪里缺工具、哪里总是绕路、哪里总要人手工补救。然后把这些摩擦沉淀成工具、规则和自动化流程。

这套东西的本质，是把“我会用 AI”升级成“团队有一套 AI 生产系统”。

三、产品经理的新职责：从需求投喂者，变成 AI 工作系统的设计者

很多人把 AI Coding 理解成研发提效工具，所以产品经理容易把自己放在旁边：我提需求，AI 或研发去实现。

但一旦 AI 进入真实项目，产品经理就不能只做需求投喂者。因为 AI 不只是写代码，它会改变任务拆解、验收方式、协作节奏和问题反馈方式。

这意味着产品经理至少要参与设计四件事。

1. 把需求写成“可验收任务”，而不是愿望描述

过去的需求文档可以留一些空间给研发理解。AI 参与后，模糊空间会变成随机产出。

更好的任务卡应该包含：

• 业务目标：这个任务要改善哪个指标或用户体验；
• 范围边界：哪些页面、接口、角色、状态包含在内，哪些不做；
• 上下文材料：设计稿、接口文档、历史决策、竞品参考放在哪里；
• 输出要求：需要代码、文档、测试用例、截图还是录屏；
• 验收标准：通过什么测试、看到什么状态、哪些异常必须覆盖；
• 回滚方式：做错了如何撤回，不影响主流程。

产品经理要少说“帮我优化一下”，多说“把这个路径的首屏加载时间降到 X 秒以内，并提供前后对比数据”。

2. 把“好不好”固化成门禁，而不是靠最后的感觉

AI 做得越快，越不能把质量检查放在最后。

对产品经理来说，门禁不一定都是代码层面的。它也可以是：

• 新手用户能否在 3 步内完成关键任务；
• 异常状态是否都有明确文案；
• 关键路径是否有埋点；
• 改动是否影响既有用户；
• 是否有截图或录屏证明功能可用；
• 是否更新了对应帮助文档。

重要的是，不要让每一次验收都从零开始。能清单化的清单化，能自动化的自动化，能录屏证明的就不要只让 AI 说“已完成”。

3. 把 AI 汇报节奏设计成“按主题处理”

节目里有一个特别值得产品经理借鉴的点：不要每天让 AI 给你八个方向的汇报。

这不是 AI 能力问题，而是人的带宽问题。一个产品经理同时收到代码质量、测试失败、用户反馈、文档缺失、素材问题、数据异常，很容易全部都不处理。

更好的方式是设计节奏：

这种节奏看起来慢，实际上更快。因为它减少了上下文切换，让人可以在同一类问题上连续做判断、定规则、补工具。

AI 擅长并行，人不擅长。Harness 的一个关键价值，就是让 AI 在后台并行跑，让人按主题验收。

4. 不要把所有治理都写进 Prompt

很多团队一遇到 AI 产出不稳定，就想加 Prompt：多写规范，多写注意事项，多写角色设定。

Prompt 当然有用，但它不是万能容器。稳定、重复、可检查的事情，应该尽量沉淀成工具和流程，而不是每次都靠一段长提示词提醒 AI。

比如：

• 不想要重复代码，就引入重复率检测；
• 不想要接口乱用，就加依赖规则；
• 不想让文案风格漂移，就维护文案规范和检查清单；
• 不想让体验状态遗漏，就把空状态、加载态、错误态变成验收模板；
• 不想每次都手工截图，就让测试流程自动录屏。

Prompt 适合表达意图，工具适合保证秩序。大项目里，真正可持续的部分往往不是“写得更长的 Prompt”，而是“被固化下来的机制”。

四、一个产品经理可直接复用的 AI Agent Harness Canvas

如果你想在团队里开始试，可以先不用搭很复杂的技术系统。先把下面这张 Canvas 用起来，就已经能减少大量混乱。

这张表的重点不是形式，而是逼迫团队承认一件事：AI 不是一个“聪明外包”，而是一个需要被设计工作条件的生产角色。

五、常见误区：买了工具，不等于拥有生产力

听完这期播客，我觉得很多团队会踩的坑有四个。

第一个误区，是以为买了 Claude、Codex 或其他 AI Coding 工具，就自动拥有了生产力。实际上，工具订阅只是算力入口，能不能用足，取决于并行环境、上下文管理和验收体系。

第二个误区，是只追求并行数量。开十个 agent 同时干活很酷，但如果没有任务边界和验收门禁，它们只是同时制造十份不确定性。

第三个误区，是让 AI 随时汇报所有问题。AI 不累，人会累。汇报机制如果不设计，最终会把人压垮。

第四个误区，是把所有机制都写成 Markdown。文档很重要，但工程治理、质量检查、自动录屏、线上监控，很多时候应该变成代码、工具和流程。

六、结语：未来的产品经理，要会设计“AI 的工作环境”

AI Coding 的价值不在于让产品经理绕过研发，也不在于让团队不再需要工程纪律。

恰恰相反，AI 把工程纪律的重要性放大了。

当代码产出速度提升，混乱也会更快到来；当 agent 可以并行执行，人类验收就会成为瓶颈；当 Prompt 可以生成结果，真正稀缺的就是清晰目标、边界、门禁和反馈机制。

所以，对产品经理来说，下一阶段真正重要的能力不是“会不会让 AI 写代码”，而是：

你能不能把一个模糊目标，拆成 AI 可执行、人可验收、系统可迭代的工作流？

Vibe Coding 适合点燃灵感，Harness 才能支撑生产。

这可能就是 AI 产品团队从玩具走向系统的分水岭。