7.2
深览指数
产品人人都是产品经理·怂怂的AI脑内小剧场··AI 生成
别再只会 Vibe Coding：AI 做大项目，产品经理要先搭 Harness
本文指出当AI Coding从小需求转向大型项目时，纯Vibe Coding模式会因上下文过长、依赖复杂、验收滞后而失效。核心观点是，产品经理应转向设计“Harness”——一个包含执行环境、对话上下文、工程门禁、治理节奏和自进化能力的五层AI生产系统框架。文章提供了需求拆解、质量门禁、汇报节奏等实操建议，适合已接触AI Coding、正面临项目扩展问题的产品经理和研发负责人阅读。原文 ↗
核心观点
- ▍AI Coding 做大项目坍塌的根本原因是AI产能超过团队治理能力，项目以更高速度积累混乱。产品经理应从需求投喂者转型为AI工作系统(即Harness)的设计者。
- 01小项目（如落地页、内部工具）中AI优势被放大，因为上下文小、验收简单、错误成本低。
- 02大项目面临五个具体风险：上下文太长AI记不住业务边界；依赖太多导致小改动牵动多模块；验收太慢致问题堆叠暴露；并行任务致人类成瓶颈；技术债产生更快、发现更慢。
- 03文章提出了五层Harness能力框架：执行环境（沙盒/Dev Container隔离风险）、对话上下文（一Agent一任务线程）、工程门禁（自动lint/测试/双重Code Review）、治理节奏（按天分主题处理）、自进化（记录摩擦并沉淀为工具/规则）。
- 04需求任务卡应包含六要素：业务目标、范围边界、上下文材料、输出要求、验收标准、回滚方式。
- 05质量门禁不只是代码层面，应包含产品验收清单：新手用户3步完成任务、异常状态文案、关键路径埋点、改动影响范围截图/录屏、帮助文档更新等。
- 06治理节奏建议：周一查代码质量，周二做体验验收，周三看用户反馈，周五专门优化流程。
- 07稳定、可重复的治理应沉淀为工具/流程（如重复率检测、文案规范检查、自动录屏），而非每次都靠长长的Prompt来约束。
反方 / 局限
- — 文章隐含假设是团队具备搭建Harness工程基础设施的能力，对于仅有产品经理而无研发支持的小团队，五层Harness的落地门槛可能很高。
- — 案例中偏向UI/前端项目场景，对于后端服务、API网关等高并发/强一致性系统的适用性未充分讨论。
8 分钟 · 3 卡片 · 6 资料
读原文 →