个人知识库

Vibe Coding

52分钟阅读

Vibe Coding

不写代码、用自然语言 + 产品思维驱动 AI 完成从原型到上线的完整产品开发方法论

简介

Vibe Coding 是一种 AI 时代的产品开发范式，核心理念是：产品经理不需要会写代码，但必须会讲清楚要什么。开发者（或产品经理）用自然语言描述需求，AI 工具（如 Claude Code、Cursor、Bolt 等）负责所有代码实现。这不是”AI 帮我打字”，而是一套完整的工作流——从调研、PRD、原型到开发上线，每一步都有对应的方法论和心法。

这个概念最早由 Andrej Karpathy 在 2025 年初提出，但真正让它从”技术圈自嗨”走向产品经理群体的是实践者 Iris 的五产品实战验证：Linger、北极星知识库、GlowNote、Duet、Daily Tarot，一行业务代码没亲手敲过，全程 vibe coding。

核心特征

门槛位移

传统开发的门槛是”会不会写代码”，vibe coding 的门槛是”能不能讲清楚要什么”。AI 替你过了代码那一关，剩下的——竞品判断、需求拆解、MVP 取舍、原型评审、流程规范——全是产品经理的主场。

“模糊的需求，必然产生模糊的产品。更扎心的是：那一刻我才发现，连我自己心里都没真的想清楚。“——Iris

四步工作流

步骤对应 PM 能力核心方法
调研竞品分析三问法：有人做吗？没做好哪块？我切哪？结论你拍板，AI 给素材
PRD需求分析苏格拉底式追问：AI 一次一问，往深处挖，直到逼出隐含需求
原型设计评审三阶段顺序：定设计语言 → 做最难一页 → 基准铺开；顺序比审美重要 100 倍
Kickoff项目管理CLAUDE.md 入职手册 + 四步开工（不写业务代码）：定技术栈→搭脚手架→填规范→git commit

改动分级机制

把产品经理的风险分级意识植入开发规范：

  • A 级（核心资产）：动数据库、改密钥、碰支付、不可逆 git 操作 → 写完整方案，等确认
  • B 级（用户可感知）：UI、文案、新功能 → 说意图，跑测试，单独 commit
  • C 级（纯局部）：注释、改名、加日志 → 直接做

数据飞轮

CLAUDE.md 通过 # 指令持续沉淀个人规则，目标 150 行以内。踩坑→沉淀→下一个项目直接避坑，形成复利效应。这个飞轮是 vibe coding 的长期壁垒，也是”别人看到 Iris 做得很快”的真正原因。

适用范围

最适合

  • 独立开发者 / 一人公司快速验证想法
  • 产品经理自建内部工具或原型验证
  • 企业级 0→1 项目前期探索阶段
  • 非技术背景创业者做 MVP

需要谨慎

  • 对性能、安全性有极高要求的生产系统（A 级改动仍需技术把关）
  • 复杂分布式系统架构（AI 可能产生看起来合理但有隐患的设计）
  • 需要精细控制每个实现细节的场景

不同素材中的观点

Karpathy 的「10 分钟碎念法」输入侧（来源：2026-07-25-bnext-karpathy-voice-prompting-method）

数位时代整理 Karpathy 在 X 上的习惯：懒得打完美 prompt 时，切语音意识流碎念约 10 分钟，把背景、限制、卡点与犹豫全部倒给模型，先让 AI 整理并回述对齐（mind meld），再写文档/写代码/拟企划。这直接补强 Vibe Coding 的输入摩擦问题——自然语言开发的瓶颈常常不是「不会说」，而是「懒得打、打不全」。方法与「先讲清楚要什么」同向，但明确反对把整理思路的全部肌肉长期外包：事实数字要核、读完产出后自己重写精炼要点。工具上点名 Claude Code /voice 与中文替代听写。详见实体 10分钟碎念法。

坨小兔的 GithubStarsManager：零代码 × 零会员 × 3.2K Star（来源：2026-07-25-woshipm-github-stars-manager-ai-pm）

产品经理坨小兔自称「一行代码不会写」「没买 AI 会员」，靠各家免费额度与公益中转站，用 AI 做出开源工具 GithubStarsManager（抓取时约 3.2K Star）。这是 Vibe Coding 在硬结果指标上的强样本：不只是 demo 或内部工具，而是可下载的 Electron 桌面端 + 开源社区。方法论一句话——把「要什么、为什么、给谁用」说到极致，架构/写码/修 Bug 外包给 AI；PM 护城河是「把模糊需求拆成 AI 可执行指令」。路径上：bolt.new 黑客松免费额度冷启动 → 自用验证 → 社区截图引发「能分享吗」→ 开源后 Issue 驱动（自定义分类、Fork/Gist、CLI 诉求产品化为 MCP 模型上下文协议 服务）。产品决策把 Vibe Coding 的成本与隐私约束写进架构：BYOK、默认本地存储、不绑模型厂商，使「白嫖额度轮换」可在自用时延续。与 Iris/Shawn/四月案例相比，增量是 开源 Star 级增长 + 反馈闭环 + Agent 可消费的星标 MCP，而不是只证明「能做出来」。

Vibe Work：转型迁徙中的低压力训练场（来源：2026-07-25-woshipm-ai-era-transformation-4-tips）

产品方法论集散地提出 Vibe Work（氛围工作）作为 AI 时代迁徙指南第三条：不纠结网站/内容有没有商业价值，先用自然语言走完官网、备课或小插件的全流程，目标是心流与手感。它把 Vibe Coding 从「要做出可上线产品」暂时降级为无 KPI 练习，专门治疗「知道该学 Claude Code/Cursor 但没动力、不知搓什么」的瘫痪。与 Iris/坨小兔等交付向案例形成阶梯：Vibe Work 启动身体记忆 → Vibe Coding 追求可运行产物与作品集 → 再进入商业 Agent 产品换认知。工具选型上强调 WorkBuddy/Trae 等「够用」入口，而非一上来 Codex 最强栈。

Iris 的五产品实战（来源：2026-05-27-pm-vibe-coding-5-products）

Iris 用 vibe coding 独立完成五个产品（Linger、北极星知识库、GlowNote、Duet、Daily Tarot）加两个企业级 0→1 项目，全程不写业务代码。核心洞察是”vibe coding 不是让产品经理去学编程，而是把产品经理最值钱的肌肉，整建制地迁移过去”。最大教训是 GlowNote 最早版本因需求模糊翻车——“帮我做个生成美妆种草文案的 App”得到的是团队协作+多品牌+云端同步的庞然大物，而真正核心功能被稀释。苏格拉底式 PRD 追问法是解决这个问题的关键：让 AI 一次一问，顺着回答往深处挖，把隐含需求翻译成规格。

Karpathy 的原始定义（2025）

Andrej Karpathy 最早提出 vibe coding 概念，描述为”用自然语言告诉 AI 你想要什么，然后看它做，遇到问题就告诉它修”。这一定义侧重”放手让 AI 干”，而 Iris 的实践把它升级为产品经理方法论——不再是被动看 AI 做，而是主动用 PM 技能引导 AI。

四月的番茄时钟实战（来源：2026-05-27-woshipm-codex-product-dev-lessons）

AI 产品经理四月用 Codex + GPT-5.5 半天开发 macOS 番茄时钟 App”专注时刻”并开源到 GitHub，验证了 Vibe Coding 在非技术背景 PM 中的可行性。四步工作流：手搓原型 → Logo 设计 → Gemini 生成 PRD → Codex 写代码。与 Iris 的五产品实战形成互补——Iris 验证了方法论在五个产品上的系统性复用，四月验证了方法论在单个 macOS 原生 App 上的轻量级落地。两次翻车教训完全一致：一句话让 AI 写代码必然翻车，PRD 是连接”模糊想法”和”AI 可执行代码”的关键桥梁。四月还识别出一个新维度——AI 卡壳时的”指路”能力：不是催 AI 换模型，而是用另一个 AI（Gemini）查资料、整理线索，再引导主 AI 查官方最新文档。

汪仔5999 的连连AI 冷启动实战（来源：2026-05-28-woshipm-vibe-coding-cold-start-offline）

汪仔5999 用 vibe coding 搭建双边平台类小程序”连连AI”（AI 帮用户找人并自动沟通），验证了 vibe coding 不只适用于工具类产品，平台类产品同样可行。与 Iris/四月不同的是，本文核心贡献不是产品开发方法论，而是产品上线后的增长方法论——用线下活动冷启动，零推广首月 1500+ 用户。这揭示了 vibe coding 时代的一个关键转移：当 AI 把技术门槛拉到零，独立开发者真正的竞争壁垒从”能不能做出产品”转移到”能不能找到第一批用户”。作者 AI 背景不强，但主动联系 3 个 AI 活动主办方获得演讲机会，用线下活动的高转化率（线上的十倍）和自传播效应打破双边平台冷启动的死循环。三个实战启示：①规模太小的活动不值得参与；②必须以演讲者而非参与者身份出场；③passion 是线下场景的隐性竞争力。

Shawn 的阿布 6 周大规模实战（来源：2026-05-29-woshipm-shawn-abu-claude-code-6-weeks）

Shawn 用 vibe coding 将方法论推到前所未有的规模——零基础 PM、6 周、1 万元、62,376 次 Claude Code 对话、8.5 万行代码、386 个文件、1,362 个测试，产出完整跨平台桌面应用”阿布 Abu”。这是 vibe coding 在真实产品开发中最大规模的一次验证，证明了不写代码交付企业级产品在 2026 年已经可行。与 Iris（5 个产品系统化方法论）和四月（单 App 轻量验证）相比，Shawn 的增量贡献是工程纪律——5 条构建纪律（分支隔离/版本同步/提交三连/commit 规范/发版清单）+ 版本注册表测试 + 23 case eval 框架 + 多窗口并行开发。核心比例反转：Claude 写代码 10 分钟，PM 想清楚需求要一个晚上。“想”的时间远超”写”的时间，这与传统开发完全相反。四步工作流的升级版：想清楚 → User Story 需求描述 → Claude 写 → 2-3 轮 review → 测试验证。另一个关键洞察是”产品方案优先于技术方案”——浏览器功能开发时，第一段对话完全不聊技术，先聊用户场景，核心设计决策（必须接入已有浏览器而非新建实例）自然浮现后才进入技术实现。

玄学产品开发实践（来源：2026-06-02-woshipm-ai-fortune-telling-products）

作者 YUE 用 vibe coding 两小时手搓出”AI 解盘紫微斗数工具”——调用 iztro 排盘组件解决大模型不会安星诀的问题，再将正确排盘结果传入大模型解读。文章指出 vibecode 让玄学 App 开发成本急剧降低：曾经需要”命理师+产品经理+前后端研发+设计”的团队，现在只需一个懂玄学+懂 AI 工具的人。这验证了 vibe coding 在垂直行业工具开发中的降维打击效应——但也同时指出，当模型越来越 AI Native，靠流程编排做应用的 AI 产品将何去何从。

巫师Sorcerer 的 PM Builder 化视角（来源：2026-06-12-pm-as-builder-prototyping）

巫师Sorcerer 从 PM 心态和身份认同角度重新审视 vibe coding 的意义——vibe coding 不只是编码方法论，更是 PM Builder 化的技术基础设施。核心论点是”文档是用来说服别人的，原型是用来说服现实的”，vibe coding 把”做出一个能点击的 demo”的门槛从”会写代码”降到”能讲清楚要什么”，让 PM 的 60 分原型成为可能。与 Iris 的五产品实战（方法论层面）和 Shawn 的 6 周大规模验证（工程纪律层面）不同，本文贡献的是心理门槛分析——Builder 化最大的障碍不是技术，是”我不是搞技术的”这层身份认同。文章也给出明确边界：demo 层成立不等于商业层成立，“能跑”和”能上线”是两回事，Builder 化是拿回验证主动权，不是取消专业分工。这与 7 Agent 软件工厂的升级路径形成互补——前者解决”PM 为什么不做”的心态问题，后者解决”做了之后怎么升级”的工程问题。

7 Agent 软件工厂对 Vibe Coding 的升级（来源：2026-05-31-blocktempo-7-agents-software-factory）

@sairahul1 提出了 Vibe Coding 的结构性天花板和升级方案——当项目复杂度超过单一 AI 对话的承载力时（“第 1 天像魔法，第 30 天你花在监督 AI 的时间比自己写代码还多”），需要引入 7 Agent 软件工厂。核心诊断是：Vibe Coding 把所有角色塌缩到一个 AI 对话里，错误在混乱中累积；升级之道是把工作拆给 7 个专责 Agent（研究员→故事撰写者→规格撰写者→后端建造者→前端建造者→测试验证者→验证员），每个只拥有单一职责和干净的上下文窗口。3 个人类审核点（核准故事、核准简报、核准 PR）取代了 Vibe Coding 中”全程监督”的低效模式——人类被从”不需要判断力”的部分踢出去，专注于”对的问题、对的设计、能不能安全上线”。这不是对 Vibe Coding 的否定，而是当项目规模增长时的自然演进路径。

零代码基础AI开发失败案例（来源：2026-06-17-woshipm-ai-dev-failure-engineering）

次级插件用 AI 从零开发微信小程序”随手当市长”的失败复盘，是 Vibe Coding 方法论的重要反面案例。作者的核心诊断是：很多AI编程宣传视频给人的感觉是”想法→AI→成品”，但真实流程更像”需求→AI写代码→编译器→构建工具→平台规则→权限系统→云服务→用户设备→产品上线”。AI的大量时间浪费在用修代码的方法去解决根本不是代码导致的问题。

与 Iris/Shawn 的成功案例形成鲜明对比：Iris 验证了方法论在五个产品上的系统性复用，Shawn 验证了方法论在 6 周大规模开发中的工程纪律，但本文揭示了 Vibe Coding 的前提条件——核心前提必须先验证。作者问 AI”我能用你无代码开发微信小程序吗？“，AI 承诺”你只需要告诉我做什么，我来负责所有代码”，但微信个人主体只能做普通图片编辑，AI 图生图要求企业主体——这个致命前提直到开发完才发现。

文章还识别出 Vibe Coding 的另一个隐性风险：玩乐模式 vs 开发模式。玩乐模式是接受 AI 的乐观判断、不验证、不查资料、不去想后果；开发模式是做之前先确认最关键的前提能不能成立。作者直到项目挂掉才意识到自己从来没切进开发模式。这与 Iris 的”苏格拉底式 PRD 追问”和 Shawn 的”产品方案优先于技术方案”形成互补——前两者主动切进了开发模式，而本文作者始终停留在玩乐模式。

七步工程化解法（观测→描述→猜想→验证→修改→沉淀→重置）提供了 Vibe Coding 失败后的补救框架，核心原则是”用 AI 必疑，疑 AI 方用”。

B端PM的 Skill 培育路径（来源：2026-06-18-bpm-vibe-coding-skill-guide）

Serencry 从 B端PM 视角揭示了 vibe coding 从”单次协作”升级为”持续能力”的关键环节——Skill 培育。核心论点：vibe coding 的真正难点不是让AI吐出一个demo，而是让它持续、稳定地产出贴合业务的设计；解决方案是把产品直觉外化为一套可复用的协作规则（即 Skill）。

Skill 培育四阶段：

  1. 混乱期（踩坑→记录协作日志→积累种子）
  2. 收敛期（归纳规律→抽象成三五条规则的 v0.1→从”被动踩坑”进入”主动驯化”）
  3. 验证期（压力测试→暴露规则矛盾→精细化+场景分支→从个人武器升级为团队资产）
  4. 稳定期（演化成六部分结构：角色定义+核心工作流+输出质量铁律+场景分支+禁止清单+迭代记录）

核心心法：(1) 从最疼的点开始，Skill是长出来的不是设计出来的；(2) 用”参考系”和”禁止清单”代替形容词——“参考Ant Design Pro”比”要专业”有效100倍。

三层递进价值：效率价值（协作起点抬高）→思维价值（反向逼迫产品感觉显性化，本质是训练产品判断力）→组织价值（个人隐性知识变团队共享资产）。

与 Iris 的五产品实战（方法论层面）和 Shawn 的6周大规模验证（工程纪律层面）不同，本文贡献的是Skill成长曲线——vibe coding 不只是”做产品”的方法论，更是”培育可复用规则系统”的方法论。这把 vibe coding 从”单次能做”升级为”持续能做好”。

从Vibe Coding到Vibe Using的反思（来源：2026-06-26-vibe-coding-to-vibe-using）

Ranger 对 vibe coding 提出了一个根本性的质疑：vibe coding 的”coding”一词仍然暗示着”写代码、做产品”，带有上一个时代的思维惯性。Karpathy 的心率 App 案例虽然展示了个人做 App 的可能性，但最终产出物仍然是一个 App——只不过是从应用商店下载变成自己用 AI 做的。

核心论点是：App 本身是 if-else 技术范式的妥协产物。传统软件需要开发者穷举所有可能的用户意图并预设响应路径，这种技术框架天然把数字世界切割成孤岛。AI 真正在做的事情不是”帮你更快地做 App”，而是瓦解 if-else 这个底层范式——大语言模型可以理解模糊的、未被预设过的意图，并动态生成响应。

因此，vibe coding 的意义可能根本不在于”做 App”，而在于”接入世界”。Ranger 提出 Vibe Using 这个更本质的概念：用户并没有在”构建”什么，用户只是在”使用”，而系统在背后自动完成了构建。这也暗示代码本身可能只是一种妥协——AI 作为新解释器后，未来可能出现介于自然语言和形式化规约之间的新中间表达形式。

这一视角与 Iris/Shawn 的实践视角形成互补：他们关注”怎么做”，Ranger 关注”为什么要做”和”做完之后是什么”。

Claude Code + Xcode 的个人 iOS App 案例（来源：2026-07-08-bnext-claude-code-xcode-ios-app）

数位时代《一天一AI》记录了查尔斯把饮控网页工具升级为 iOS App 的案例，补充了 Vibe Coding 在原生 App 场景中的一条务实路径：先用 HTML 版本厘清需求，再用 Claude Code + Xcode 进入 App 化。这个案例并不是证明“vibe 一个 App 很容易”，而是证明 Vibe Coding 的成功前提仍然是具体场景和可观察反馈。

查尔斯的需求足够具体：他要用手机记录每天摄入的营养素，方便和健身教练回报；常吃的波奇碗不是固定商品，而是小黄瓜 100g、毛豆 50g、鲑鱼 80g 等食材组合，所以通用饮食 App 的商品记录逻辑并不贴合。他做“菜单库”，把常吃食材和份量预先建好，每天像点自助餐一样勾选，三大营养素自动加总。这个案例说明，自制工具的优势不在功能多，而在对个人场景贴合。

协作流程也很典型：Claude Code 写 Swift / SwiftUI 代码，Xcode 打开同一个项目资料夹并显示预览，用户不用懂 Swift，但要懂“这个画面哪里不对”。真正的门槛从代码语法转移到需求判断、预览反馈和功能取舍。文章尤其强调 Claude Code Plan 模式：先让 AI 列出开发计划，再逐条问“这个我真的会用吗？”删掉不用功能后再执行。这与 Vibe Coding 的核心纪律一致：AI 写得越快，越要先确认方向。

这个案例也补充了边界：通过 Apple 帐号用开发者测试方式装到 iPhone，不需要正式上架费用，但凭证每 7 天过期，必须回电脑打开 Xcode 重新签署。也就是说，Vibe Coding 能显著压缩“做出自己能用的工具”的时间，但不能自动完成正式上架、销售、审核和长期分发。

AI Coding 大项目中的 Harness 上限（来源：2026-07-08-woshipm-ai-coding-harness）

人人都是产品经理这篇素材把 Vibe Coding 的边界说得更清楚：小需求很爽，是因为上下文小、验收简单、错误成本低；一旦项目变大，AI 产出越来越多，错误也越来越分散，多个 agent 并行后，人类反而可能变成排队验收、救火和兜底的瓶颈。文章的关键判断是：纯 Vibe Coding 做大项目会塌，并不是因为 AI 不会写，而是因为 AI 的产能超过了团队的治理能力。

这补充了 Vibe Coding 方法论的重要分层：Vibe Coding 适合点燃灵感、快速出原型、把模糊想法变成可观察 Demo；但要进入复杂系统和可持续交付，就必须升级到 Agent Harness。Harness 包括执行环境隔离、对话上下文拆分、工程门禁、治理节奏和自进化机制。它不是“多写几句 Prompt”，而是把 AI 放进一套生产系统里，让 AI 能在清晰边界内大胆执行、让人类按主题验收、让重复治理被工具和流程接管。

对产品经理来说，这篇素材也把 Vibe Coding 的 PM 能力要求从“会讲清楚要什么”推进到“会设计 AI 工作系统”：需求要写成业务目标、范围边界、上下文材料、输出要求、验收标准和回滚方式齐全的可验收任务；质量要固化为门禁，例如 3 步完成关键任务、异常文案、埋点、截图/录屏、帮助文档更新；AI 汇报要按主题组织，而不是每天把所有问题同时推给人。简言之，Vibe Coding 解决“能不能做出来”，Harness 解决“能不能持续做对”。

Vibe Coding 产品被”一眼看穿”的三大 UI/UX 破绽（来源：2026-07-09-techorange-ai-app-vibe-coding-uiux）

TechOrange 引述《Business Insider》归纳出 AI 做的 App 在市场上高度同质化、最容易露馅的三个特征，补齐了 Vibe Coding 在”上线之后”的设计短板视角。这条视角与 Harness（解决工程治理）不同，它指向的是设计判断力这一 AI 目前替代不了的部分：

  1. 界面陷入”平均美学”：AI 生成设计会收敛成”单一且符合统计平均值的美学”——米色/淡色背景、标准无衬线字体、圆角与投影堆叠。Impeccable CEO Paul Bakaus 称之为”演算法版的 Uniqlo 或 Ikea”，卡内基美隆副教授 Sauvik Das 称之为设计上的”回归平均值”。参见新实体 AI设计平均美学。
  2. 只优化 happy path，互动经不起操作：AI 只对”一切顺利无误”的路径优化，静态画面看似完整，实际互动露馅——例如 hover 出现阴影/放大暗示可点击，点下去却无反应。华丽页面背后可能只是 alpha 阶段产品。
  3. 忽略边界状态（edge-state design）：空状态、错误信息、骨架屏、离线状态被视为事后补充甚至直接省略，错误文案套用”发生了一些错误，请再试一次”这类冰冷模板，在用户最需要引导时剥夺了产品的人味。

破解之道——从”美学提示”转向”决策提示”：与其对 AI 说”让界面看起来乾净现代”，不如给策略性情境提示，例如”这个画面是用户对自己的数据感到焦虑、正在决定是否继续的地方，我应该移除什么？文案要达到什么安抚效果？“。这与本页 Iris 的”苏格拉底式 PRD 追问”、Shawn 的”产品方案优先于技术方案”一脉相承——都是把用户情境和判断力显性化，而不是把设计外包给 AI 的默认审美。文章结论也定了 Vibe Coding 的天花板：完全靠 vibe coding 的产品仍可能成功，但要从”不错”提升到”伟大”，专业 UI/UX 设计师的眼光与细节处理仍无可取代。

王三思的”顺序错了”反思（来源：2026-07-14-woshipm-let-ai-reject-your-idea）

王三思引述 Anthropic《创始人手册》，给 Vibe Coding 补上了最前置的一层反思——问题不在工具，问题在顺序。他自己用 Codex 半天做出一个 Figma 翻译变量导入器插件，把同事两三天的活压缩到几秒，那一刻”觉得自己很厉害”，但事后发现自己跳过了整个验证环节：Vibe 出来的产品自己能用，但除了自己以外没问过任何人愿不愿意用、愿不愿意付费。

文章的核心判断是”AI 让构建变得太容易了，简单到我都没意识到自己跳过了什么”。他引用 CB Insights 数据——42% 的创业公司失败于做了没人想要的东西，并指出这还是 Vibe Coding 时代之前的数据；过去开发的高成本本身是一道天然筛选门槛，逼你在投入真金白银前想清楚有没有人用，而现在这道门槛消失了，验证反而更容易被跳过。

他给出的正确顺序是：有想法 → 先让 AI 用芒格逆向思维找出所有失败路径（让AI否定你）→ 带着质疑去找真实用户问过去的行为 → 假设站得住再做 MVP 拿证据 → 有证据支持再大规模 Vibe Coding。“顺序变了，但做的事没有变。你还是会用 AI 去构建，只不过在按下回车键之前多做了一件事：去确认你想要构建的东西真的有人需要。“这与本页 Iris 的”苏格拉底式 PRD 追问”、2026-06-17-woshipm-ai-dev-failure-engineering 的”玩乐模式 vs 开发模式”、Shawn 的”产品方案优先于技术方案”完全同源——都在说 AI 写得越快，越要先把”做什么”想清楚，只不过王三思把这一步进一步前移到”要不要做”的需求验证阶段。手册里那句”瓶颈不再是你能构建什么，而是你选择构建什么”是这一视角最凝练的表达。

木水的非技术 PM 1 天做个人官网实战（来源：2026-07-12-woshipm-codex-personal-website-1-day）

AI 产品木水（不写代码的 PM）用 Codex 花约 8 小时做出响应式、SEO/GEO 齐全、中英双语的定制 个人官网，0 元部署到 Vercel，全程没写一行代码。这个案例把 Vibe Coding 的方法论进一步验证到 Web 端个人品牌资产场景，与四月的 macOS 番茄时钟（原生 App）、查尔斯的 iOS 饮控 App（Claude Code + Xcode）形成”三种终端形态”的互补样本。它的增量贡献有三点：①把”先聊透需求”细化为 7 轮结构化对话（定位→个人信息→内容模块→设计风格→功能需求→技术约束→素材确认），1 小时输出设计简报再动手，是苏格拉底式 PRD 追问的具体落地；②数据驱动组件模式（数据与 UI 分离、改内容只改数据文件）是让非技术 PM 能长期自维护的关键工程决策；③踩坑即检查规则——5 个坑（Google Fonts 国内慢、中文文件名部署 404、设计稿≠代码、国际化半成品、大文件拖慢首屏）与本页”AI 写得越快越要先想清楚”的核心纪律一致，也印证了 2026-07-01-woshipm-vibe-motion-10-pitfalls 的”每次踩坑沉淀为强制检查项”。作者的商业化思考（PM + Codex 卖官网）仍停留在”参考着去 X 鱼、某书验证”，尚未做真实需求验证——这恰好落在 2026-07-14-woshipm-let-ai-reject-your-idea 提醒的”构建太容易导致跳过验证”盲区里。

ChatGPT Sites：部署最后一公里与个资纪律（来源：2026-07-18-bnext-chatgpt-sites-deploy）

数位时代指出 vibe coding 的常见断层：本地 HTML/仪表板做完后，家人一句「能传给我看吗？」就暴露「做出来 ≠ 可分享上线」。ChatGPT Sites 用对话把部署收进 ChatGPT——拖入 HTML 或描述点子，@Sites 建站，默认私人，主动提醒出生月份等个资，再选公开或指定分享。这与木水的 Codex→Vercel 路径形成轻重两条交付链：Sites 换零运维与速度，适合展示型/轻量互动 prototype；自建部署换工程深度（SEO/GEO、组件资产、自有域名策略）。两者都说明：Vibe Coding 方法论必须把部署、分享权限与合规写进工作流，而不是停在「生成能跑的页面」。

北海道农夫：Vibe Coding 进入田间物理世界（来源：2026-07-18-bnext-ai-farmer-chatgpt-japan）

冨安弘樹 的案例把 Vibe Coding 从「做出 App / 官网 / 可分享网页」推到软硬一体的现场系统：不会写程式的农人用自然语言驱动 Codex 与 ChatGPT，两到三周内用不到 2 万日圆材料做出 LINE 远控温室（对比买断设备 30 万日圆量级），并叠加病虫害拍照诊断、LINE 数据助理与 NDVI 巡田图。方法论与本页一贯主张同构——先有真实痛点与可测原型，再谈模型与技巧；他明确说「仅仅懂 AI 不够，要在一线建原型、反复测改」。差异在于验收标准从「页面能打开」变成「卷帘会动、通知会来、巡田更省脚力」，且必须保留物理安全与农艺合规边界。这为 普通人学AI 提供了非互联网职业的极端正例，也提醒 Vibe Coding 的下一战场是工厂、看护、物流等现场产业（见 农业AI）。

东哥系列第1篇：结果导向的大众定义（来源：2026-07-23-woshipm-vibe-coding-intro）

东哥说AI「Vibe Coding AI编程实战」开篇把概念压成大白话：换的是沟通方式，不是新语言——自然语言规划/写/测，AI 从补全半行升为可搭架构的主程序员，真实产品靠多轮对话迭代。最要紧的一条是视角从代码导向换成结果导向：盯界面、功能、结果是否达标，而不是默认逐行抠生成代码。同时给出产业映射：规划（ChatGPT 深度调研）→ 设计（自然语言 Figma）→ 开发（Cursor / Claude Code）→ 测试运维（AI 单测等），支撑「一人 + AI 跑通传统全流程」与 OPC 一人公司 叙事。冷水同样写清：复杂系统会改 A 丢 B、UI 描述不够精、自然语言有歧义；一上来堆 MCP 模型上下文协议 / Agent 指望长跑做完不现实。口诀大道至简——先想清 demo 还是长期产品、先搭骨架再让 AI 上；Skill / MCP 是辅助，不是生产力本身。这与 Iris「讲清楚要什么」、王三思「顺序错了」、失败工程「玩乐 vs 开发模式」同源，并作为第5–7篇（任务外置→后端真源→联调防假通过）的心智前置。

东哥联调收尾：文档真源 + 防假通过（来源：2026-07-23-woshipm-vibe-coding-system-pitfalls）

东哥说AI「Vibe Coding AI编程实战」第7篇把智能数据分析代理做到前后端联调收官，补上 Vibe Coding 方法论里常被跳过的交付后半段。核心不是新模型技巧，而是几条避坑铁律：联调前用 Claude Code Plan 模式 对齐接口，以后端真实字段为基准、前端适配，避免双边同时改导致 AI 自我怀疑；人当「看仪表盘的人」盯端口/进程/虚拟环境，防止 AI 再建一套 venv 把服务搞挂；用真实 API Key 跑 提问→SQL→查库→出图→回答，堵住 假测试通过；MCP 按需、Rules 先 MVP 再对反复错误点加规则；全程维护的是需求文档、Plan、字段规范，不是生成代码本身。这与 Iris 的「讲清楚」、Shawn 的工程纪律、Harness 的治理叙事同轴——把「能 vibe 出来」升级为「能联调验收并复用到下一项目」。

东哥任务闭环：MCP + Rules 让清单自己会动（来源：2026-07-23-woshipm-mcp-rules-40-tasks）

同系列第5篇把 Vibe Coding 从「能写代码」推进到任务清单自治。Plan 拆出约 40 个阶段后，痛点不是拆不拆得动，而是跨天/跨人后状态丢失。解法：在 Trae IDE 接 Linear 官方 MCP（约 42 tools）批量把阶段同步为 Todo，再用 IDE Rules 语义触发——说「开始做阶段 1」即 In Progress（可建 Git 分支），提交后 Done 并推进下一阶段。关键经验：别手写 Rules、别抄通用模板，把 MCP 文档 + IDE Rules 规范喂给 AI 生成再迭代。终态叙事：人不是在管代码切换，而是在管一份会自己动的任务清单，只把握方向。与第7篇联调铁律成对：第5篇是 Happy Path 任务外置，第7篇是交付验收纪律。

东哥后端测试先行：字段样板写回文档（来源：2026-07-23-woshipm-ai-backend-test-first-debug）

系列第6篇补上「任务板就绪之后如何啃后端」的中间段。智能数据分析代理后端最易连环翻车，口诀是测试先行：先挂 docs-langchain MCP 用 ask 模式查 LangChain/通义千问/NL2SQL 规范，再写独立 .py 用 DashScope 跑通对话→流式→工具调用并记录真实字段；NL2SQL 测现成 SQLDatabase/create_sql_agent 后因编排不合拍改为自研（意图→SQL→sqlglot 禁删表/禁 SELECT */强制 LIMIT→查库→图表→总结，SSE 输出）；字段规范追加进开发文档后再集成，作者称基本一次过。Pydantic v2 拆包、空表无种子数据、Trae 多起后端实例等坑靠人盯。范式再次钉死：没敲业务代码，但反复改文档——维护的是越来越准的合约，不是生成代码本身。时间线宜读 5（任务外置）→6（后端真源）→7（联调防假通过阅读）。

媒体人的 Vibe Coding 转折：纯对话 AI 不够，Antigravity 的介面化工作流赢了（来源：2026-07-27-techbang-vibe-coding-antigravity-codex）

9to5Google 编辑提供了一个非 PM、非独立开发者的 Vibe Coding 采用路径——前工程师在 2010 年代初毕业后逾十年未深耕写代码技能，对编程逐渐排斥，视实作为「苦差」。转变的触发点是琐碎的重複性日常工作（图片浮水印、AE 动画微调、档案转档、Photoshop 调色），这类任务共同特征：规则清楚、重复性高、无人愿做、但「太小太临时不值得排期」。关键转折在工具选择——先用纯对话 AI（Gemini）写脚本失败 → 改用 Antigravity 具专有介面规划工作流 + Codex 执行 → 成功。

增量贡献有三：（1）提供了纯对话 AI vs 结构规划介面的鲜明对照数据——Antigravity 的「先规划后执行」工作流把使用者模糊需求转化成明确可执行步骤，大幅提升 AI 一次成功率，佐证了 Vibe Coding 方法论中「讲清楚要什么」的前设；（2）点明 Vibe Coding 一个被低估的高频场景——工作中的规律重复「苦差事」，前工程师以这类切入比本页其他案例（Iris 产品级、Shawn 6 周企业级、木水个人官网）都更轻量更日常，更可能成为非技术岗位的第一块 Vibe Coding 踏脚石；（3）量化了成本效益——半年内节省大量时间 + 省去昂贵通用外挂费用，投入产出为正。但同样敲响警钟：AI 产出原型只需几分钟，修缮余下 10% 瑕疵却要花数天乃至数周，且不理解代码结构容易制造安全隐患——坚守「个人用途优于商业产品」这条纪律，与本页次级插件「玩乐模式 vs 开发模式」、王三思「顺序错了」完全同轴。

与其他案例的最大不同：它代表了「第三代 Vibe Coding 采纳群」不再局限于 PM / 独立开发者 / 创业者 → 媒体从业者 + 前工程师也开始入场；触发点不是「想做出一个产品」，而是「不想再做这些跑腿小事了」——一个比任何商业故事都更人性化、更贴近日常的入门动机。

它同时补上了工具选型矩的新维度：Gemini（纯对话式）→ Codex（任务执行式）→ Antigravity（介面规划式）→ Claude Code（CLI 多模式），Antigravity 填充了「结构介面 + 需求规划」的空白。Googlebook 以 Gemini 智能为中心的笔记型电脑预计 2026 下半年问世，为这个路线加上了硬体端的想象空间。

实用信息

入门建议

  1. 从一个极小的想法开始，不要上来就做复杂产品
  2. 先把苏格拉底式 PRD Prompt 跑一遍，再动原型
  3. 原型严格按三阶段顺序，不要跳步
  4. 每完成一个小步骤就 git commit，这是你的保险绳
  5. 用 # 把踩过的坑沉淀进 CLAUDE.md，目标 150 行

核心 Prompt（苏格拉底式 PRD）

见 2026-05-27-pm-vibe-coding-5-products 的”实操内容保留”节，可直接复制使用。

远程操控让 Vibe Coding 脱离办公桌（来源：2026-07-17-woshipm-agent-remote-control-codex-uu）

数字生命卡兹克指出：Vibe Coding 以及知识处理、数据分析等 Agent 任务，都可以用「常驻主力机 + 手机遥控」完成，而不必人坐在工位前。关键不是再发明一种写代码姿势，而是把已配置好的 Vibe Coding 环境（规则、记忆、Skill、项目）固定在一台 24h 机器上，用 Codex Remote Control 派任务、用 UU远程 处理扫码与 GUI。这把 Vibe Coding 的瓶颈从「会不会用 Agent」推进到「能不能在碎片时间持续喂任务、收结果」。

小普的 Agent 选型四步法与多 Agent 协作（来源：2026-07-29-woshipm-vibe-coding-agent-selection）

作者小普将 Vibe Coding 实践从「能用」推进到「选什么、怎么协作」的系统化操作层面。首次提出 Agent 选型四步法（定场景→定维度→跑测试→算成本，顺序不能乱），并用 SWE-bench Verified 和 Terminal Bench 2.0 两套公开评测数据对比三大 Agent：代码能力几乎持平（Claude Code 88.6% vs Codex 88.7%），但终端自主操作 Codex 明显占优（82% vs 69.4%）。由此得出分工策略：从 0→1 冷启动用 Claude Code（主动拆架构）、1→N 精修切 Codex（指哪打哪）、个性化工作流走 Pi Agent（400 Token 极简）。

另一个重要贡献是提出 VS Code 作为多 Agent 容器的概念和「最高指令软链接法」——在项目根目录存一份 COLLABORATION.md，再在 CLAUDE.md、AGENTS.md 等各 Agent 功能配置文本（如 CLUDE.md / AGENTS.md）首句用 @文件路径 引用，实现三个 Agent 共享同一份最高指令（技能栈、命名规范、禁区、管理方式）。这篇文章首次从「生产资料所有权」角度反思 Vibe Coding ——数月积累的 Skill、聊天记录、工作流一旦因账号被封号而消失则崩溃，主张「不管工具怎么迭代，项目主动权一定要掌握在自己手里」。

相关页面

关系图谱

快速导航

反向链接