单人并行造5个App的AI技能

• Josh Pigford 是连续创业者，上一家公司 Baremetrics（一款给订阅制公司看营收数据的"商业分析 SaaS"）他做了大概 7 年，最终以 400 万美元卖掉。本期主持人是 Peter Yang，开场就定调："他现在同时在做至少五款 AI 产品。"现在他不再带团队、不再只盯一件事，而是作为 solo founder（一个人单干的创始人）同时并行做至少 5 款 AI 产品——从开发、设计到营销、客服，全部一个人靠 AI 撑起来。这次访谈的卖点正是"完整演示一个独立开发者是怎么用 AI 做产品的"。→ 详细
• 谈到"同时做这么多会不会分心"，他自称是**"教科书级别的 ADHD"（textbook ADHD，注意力天生容易到处跳的那种），大脑"天生就在到处乱蹦，一直都这样"。并行多个产品对他来说就是"往这台野兽（feed the beast）里多喂点料**"——这个比喻里的"野兽"指他那颗闲不住、不停想抓新东西的大脑。他承认有利有弊：有些日子因为频繁切换上下文（context switching，脑子在多个项目间来回倒）会更累，但同时反而更有成就感。对照 Baremetrics 那"连续 7 年只做一件事"的经历，他说自己"就是受够了"，兴趣太多、太渴望不停学新东西，被迫聚焦一件事会让他觉得"被束缚住"。→ 详细
• 他也坦诚这未必是最优商业决策："这是不是最佳的商业决策？我不知道。也有种说法是，不，这是个糟糕透顶的主意——如果你想把一个东西做到尽可能赚钱，你确实应该聚焦。"但从他个人对"成功"的定义看，"手里同时握着很多不同的事情，反而让我更有满足感"。Peter 补了个两人都认同的比喻：理想的一天就像一边在花园里养一堆植物、一边在自己的事务所里养一堆产品——道理相通。→ 详细

• Proxy User（当天刚上线）：用真实浏览器跑的"合成用户（synthetic users，AI 模拟的假用户，像真人一样在浏览器里点你的产品）"自动给 App 做 QA 测试，产出一段屏幕录像记录功能是否正常，方便快速定位并修 bug。→ 详细 Rumored（访谈前那个周五上线）：专抓 LLM 对你品牌产生的"幻觉"（大模型一本正经编造不实信息），持续监控大模型怎么瞎说你的品牌、需修正时提醒你；修正方式他举了三种——更新网站文案、发博客文章、给网站加 schema 代码（藏在网页里讲给机器看的结构化标注，让 AI/搜索引擎更准确读懂品牌信息）。Reply Social（今年早些上线）：把所有产品收到的回复、提及全部汇总到一个地方统一盯。→ 详细
• 健康陪护 App = KeptWell（上个月做的）：起因很私人——他母亲刚被诊断出胰腺癌四期，海量医疗资料"每天都有新东西冒出来"。他最初想把资料全丢进 Claude Code，但卡在"怎么让我爸妈、爷奶外公外婆、我妈的兄弟姐妹也能用上"，于是做成让全家同步进展、可直接跟所有医疗文档对话的工具。Peter 当即共鸣："我爸妈也有同样的问题，我得帮他们追踪所有医嘱记录。"→ 详细 Clearly：一款开源的 Markdown 编辑器，因开源在 GitHub 上收到"一大堆功能请求"；这种不花他钱的纯开源项目"大概永远不会收费"。→ 详细

• 他用 Conductor 作为主力开发环境。Peter 问"Codex 和 Claude 都已经挺好了，为什么还要 Conductor"（Codex = OpenAI 的编程 AI，Claude = Anthropic 的模型），Josh 给两个理由：① 可在不同模型间随意切换（界面上有个小小的 review 按钮，能给审查环节单独设模型，有默认值也可自选）；② 自动化的 work tree 管理。每开一个 work tree（同一项目临时复制出的一份独立工作副本，互不干扰），Conductor 都自动跑 setup：分配一个独立端口（门号不撞，所以他能同时跑十个、分别在不同浏览器打开）、复制环境变量、按 iOS 等情况起不同进程——"就是有一堆 setup 的活儿都自动做好了，非常省事"。→ 详细
• 技术栈固定是 Rails + Inertia + PostgreSQL（Rails 后端框架，Inertia 黏合前后端，PostgreSQL 数据库）——因长期固定，他给 AI 的规则才能写得很专。测试用 agent browser（让 AI 代理直接打开浏览器、像人一样点页面实测）。Peter 补充自己其实不用 Claude Code，所以全程 Josh 边演示边解释。→ 详细

• build skill 是他自己攒的、开源放在 GitHub 上的核心技能。"我们倒着来讲吧"——他从这个 skill 切入，屏幕上能看到它分三个阶段：研究（research）、规划（planning）、实现（implementation），"它们各自带着不同的指令集"。说白了，这个 skill 就是把"一个功能从想法到落地"切成三段流水线，每一段都有一份固定的"怎么做"说明书喂给 AI。→ 详细
• 第一步产出一份研究文档（research document）。他用的具体例子是"把已经停掉（now defunct）的 Botblock 功能集成进 Reply Social"：AI 会去翻他之前为 Botblock 写好的旧代码库，把它跟 Reply Social 的代码库合并，然后围绕一堆高层面（high-level，只谈大方向不抠细节）的技术问题做调研——"你可能需要的各种 API 调用、各自的利弊、原来那个 Chrome 扩展里哪些可以忽略、哪些需要迁移过来、这些系统之间会怎么交互"。强调一句："但都是高层面的。所以最先生成的就是这么一份研究文档。"（API 调用 = 程序之间互相要数据的标准接口；Chrome 扩展 = 装在浏览器里的小插件。）→ 详细
• 第二步从研究文档跑 implementation 命令，把功能逐步细化成多个阶段。这次的例子拆成 4 个阶段 = 4 个 pull request = Git 里 4 条独立分支。"pull request（PR）"是请别人把你这条分支的改动合并进主干前的一次提交+审查单位；"分支"则是从主干岔出去单独改、改好再并回来的副本。他的用意很明确："这样它就不会试图在一次大动作里把所有事情全做完，而是分成这些相对独立、我可以逐个验证的小块来做。"→ 详细

• 他特意把 build skill 配置成"拆出来的每个阶段都必须是用户可测试的（user testable，意思是每完成一步，他自己都能立刻上手点一点验证它真的能用）"。代价就是：有时一份实现文档会有 30 多个阶段——"因为我希望在每一步、每个节点，我自己都能亲手测一测"。→ 详细
• 构建过程中 AI 会"自己打开浏览器、做一些测试"，但他反复强调"最后那一关"必须是他本人上手玩——Peter 接话"得你自己上手玩玩"，Josh 说就是要靠手感判断对不对劲，原话是"哦，这个加载真的好慢，这里是不是漏了点什么"，或者"这个跟我设想的不一样"。机器测过≠他认可，最终拍板的还是真人手感。→ 详细
• 他并不通读全部文档，只快速扫一遍（a quick scan）。Peter 提醒"倒也不用整篇都读完吧"，Josh 确认：扫的重点不是它生成的那些具体任务，而是那些目标（objectives）——只要确认大方向对了就行，具体任务交给 AI。→ 详细

• 真正干活的命令叫 build phase。比如他想做第一阶段，就直接输入 build phase one bot block，意思是"从 Botblock 这个项目的实现文档里，构建第一阶段"。他还演示了几个各自独立、自成一体的阶段块："加 Facebook 支持""加 Reddit 支持""加这个营销工具"。→ 详细
• 关键点在于：让 AI 去构建某个阶段时，其实是命令它"把实现文档里的这一阶段块拿出来，现在做更深一层的研究"。这层深研究包含三件事：① 网络搜索查竞品——"还有谁有这个功能、他们是怎么实现的"；② 去搜最新的文档，这时可能会用到 Context7（一个能把第三方库/框架的最新官方文档实时喂给 AI 的工具，避免 AI 拿过时知识瞎写）；③ 调用 UI.sh skill 做一遍设计梳理——"配色、组件之类的东西这里都得考虑进去"。他用"极其深入（incredibly in-depth）"来形容。换句话说，第 4 步那份研究文档只是"大方向草图"，到了 build phase 才会针对当前这一小块再钻一次细节。→ 详细
• Peter 追问"看竞品怎么做，它是去浏览人家网站吧"，Josh 确认它是真的在做网络搜索："然后它会去浏览、阅读，如果它判断有必要，有时候还会截图。"Peter 立刻分享了一个同款经历：因为 Substack 现在没有 API（API 缺失意味着你没法用官方接口直接对接，只能曲线救国），他要在自己网站上接入 Substack 登录时，只能去研究别人怎么做，"然后 Codex 就把它给搞定了"——Josh 评价"确实挺夸张的"。→ 详细

• 每完成一步，build phase 会更新一份进度文件（progress file），把那一阶段"做过的所有事情都记进去，也包括做过的这些决策（decisions made）"。他特别强调这不是一次成型："我会来来回回地折腾——这些可不是一次成型的，我得边做边迭代"，而 AI"在过程中学到的东西"也会被追加进这份进度文件。→ 详细
• 进度文件有两个作用：① 让 AI 不重复犯同样的错；② 更重要的是解决"失忆"问题——他做完第一阶段去做第二阶段时，会新开一棵 work tree，里面"手里没有任何别的上下文，根本不知道之前做过什么"。进度文件就成了一根"接力棒"，让"后面的阶段去参考前面的阶段，从而搞清楚自己在整个实现计划里走到哪一步了"。Peter 复盘了一遍整套流程：research 就是调研，implementation"基本上就是写一份 spec，类似产品技术规格说明书"，然后每次分三到四个阶段。→ 详细

• Peter 问"每阶段新开 work tree 是为了省 token 吗"。Josh 否定了这个理解：他把一个 work tree 当成一个"可交付（shippable）的东西"——"比如我要推到生产环境的某个功能"，它必须自成一体（self-contained）。（"推到生产环境" = 真正上线给用户用；token 是大模型按字数计费的计量单位。）→ 详细
• 开新 work tree 一部分确实是为了上下文，但他说"更大一部分是为了能回滚（rolling back）"：万一"把一堆东西搞砸了，它能给我一些 checkpoint（检查点 / 存档点），让我能回退到之前的状态"。他直接把它类比成打游戏的"save points（存档点）"——出事了就读档重来。→ 详细
• 还有一个收益：每次都是全新的 context，"这样就不会有 context rot（上下文腐化——对话越拖越长，AI 越容易记混、跑偏、瞎编），它幻觉也会少很多"。Peter 总结确认："所以每个阶段差不多就是一个 PR，然后你再去试用、跑一遍。"Josh："完全正确，每一个百分之百都是一个 PR。"→ 详细

• 他的固定流程是："大部分工作我都用 Opus，所有的规划它来做，每件事的第一版也是它先出。"（Opus 是 Anthropic 旗下能力最强的那档模型，适合啃复杂的规划和首版实现。）等它在那个 work tree 里把代码写完，他会再用 GPT-5.5 做一轮 review。（注：开场 t000 字幕作"GPT 3.5"，应为口误或转写笔误，正文 t035 明确为 GPT-5.5；用另一家的模型来挑刺，本身就构成"换个脑子看"的对抗效果。）→ 详细
• GPT-5.5 会对 work tree 里的所有东西做一种对抗式（adversarial）的审查，他给的硬数据是"每次都能找出三到五个 Opus 漏掉的 bug"，过完这一轮才 merge（合并）进去。这一步就是靠 **Conductor 里那个"review 按钮 + 可选 review 模型"**实现的：有默认模型，也可自选。他把整条流程浓缩成一句："先让 Opus 出一个大的第一版，再让 GPT 把所有漏掉的缺口找出来，然后才把它推成一个 pull request。"并强调"这个组合是我试下来对我最好用的"。→ 详细

• learnings skill（学习技能，开源）：在他把当前 work tree 全部跑完、把这一阶段 ship（交付/上线）之后运行。它会去看这棵 work tree 里"做过的所有事情"、以及"我们实际的那些 session（指他和 AI 的真实对话记录）"——尤其盯住那些他不得不"坐在那儿一遍又一遍跟 AI 讲'不行，这样不行''不行，这也不行''试试这个''还是不行'"的地方。换句话说，凡是他被迫人工纠正的痛点，都被当成"教训素材"挖出来。→ 详细
• 然后它把这些复盘"提炼成任何可以加进 Claude 文件里的东西，这样你以后就不会再犯同样的错"。结果就是 CLAUDE 文件在不断被更新——AI 的"行为说明书"会随着每次踩坑自动变厚变准。Peter 当场评价："哦，这个很聪明啊。"（CLAUDE 文件 / CLAUDE.md 见第 12 段。）→ 详细

• but for real skill（直译"玩真的"，开源）是另一个对抗式玩法，独立于上面的 GPT review。流程是："它先做计划，再去实现这个计划，然后我就跑 but for real。"这个 skill"基本上就是去欺负（bully）AI、欺负 LLM"——预设的语气是"嘿哥们儿，你几乎肯定搞砸了一些地方，给我重新从头检查一遍"。靠这种"先认定你错了"的施压，它能"再找出三到五个 bug"。→ 详细
• 他明确这"跟那个 GPT review 的流程是分开的"——也就是说同一份代码会被"挑刺"两轮（GPT 一轮、but for real 一轮）。"很多时候就是逼着它把东西再过一遍。"这个 skill 让 Peter 当场叫绝："哇，这是到目前为止我从你这儿看到的最喜欢的一个 skill。"Josh 形容它"好用到让人吃惊（shocking how good it is）"，还自嘲挺解气——"当你真的被它老是搞坏东西气得不行的时候……反正它就是个机器嘛"。→ 详细
• 为什么要让 AI 来扮"审查者"？他给了完整的团队类比："在一个典型的团队场景里，你整个团队可能三五个、十个开发者一起做，甚至上百人。你提一个 pull request，那里的逻辑就是让另一个开发者来 review，多一双眼睛盯着。他们几乎总能发现点什么，会说'啊，这个我不会这么写'，或者'这里还有另一种做法'。现在就是把这件事照搬过来，只不过让 AI 来扮演这个角色，而不是另一个人。"Peter 点出了为什么这招对单干者尤其香："让一个人去 review 大量代码是很花时间的，但对 AI 来说很多时候就是一瞬间的事。"Josh 还补了个生动细节：被逼到临界点时他甚至会"全大写打字，搞得好像它在乎似的"（全大写在网络语境里等于"吼"）。→ 详细

• Peter 问他有没有一个"列着一堆最佳实践（比如'永远要写测试'）的 CLAUDE.md 或 AGENTS.md"。这类文件本质是放在项目里、AI 每次干活前都会先读一遍的"行为总纲"。Josh 的做法是：作为项目初始化流程的一部分，让 AI 基于同一个通用模板、为每个项目生成一份独有的 CLAUDE 文件。Peter 追问"这不是你手动一条条敲的吧"，Josh 明确："不不，这是它自己生成的。我只是告诉它：这是文档的大框架、大致的形状，你帮我把它填满。"→ 详细
• CLAUDE 文件具体写了什么，他逐项点过：① 产品背景——"先给一些关于这个产品的背景，让它清楚自己在讲的是什么、实际产品到底是什么"，包括用户画像、以及"该怎么用营销的口吻去表达"；② 这个例子是一个 mono repo（单一仓库，把多个相关项目放在同一个代码库里管理），里面同时有一个 Web 应用和一个 iOS 应用，所以文件"一上来就交代清楚各个东西放在哪儿，这点很重要"；③ 它需要调用的各种命令——因为 AI"会倾向于去用一些它觉得对某个 app/框架来说比较典型的命令"，所以这部分要"讲清楚该用什么、什么时候用、怎么跑各种测试"，避免它自作主张乱用。→ 详细
• 这份文件"非常偏 Rails，涵盖了大量 Rails 上的最佳实践"，也写明了他喜欢的测试方式（用 agent browser 把页面打开）和 Conductor 的独有变量——比如"每个 work tree 独有的 Conductor 端口，所以得把这类东西写进去"。他说这些"都是我这些年攒下来的经验"，文件"挺长的"。→ 详细

• 他有一个开源的 Mac app 叫 Chops，"基本上就是专门用来管理 skill 文件的"——所有 skill 都集中在里面，"估计有十来个（a dozen）吧"。这些 skill 由 AI 写，但他"反复迭代了好多版"：Chops 内置一个 AI 迭代器（AI iterator），他给 AI 一句指引就让它把整个 skill 重写一遍，举的原话指令是"再凶一点（be meaner）"（正是这种微调把 but for real 这种"会欺负 AI"的 skill 一版版磨出来）。→ 详细
• 对零散的小需求他不走完整 build 流程，而是用一个从 build skill 抽出来的 research skill。例子：Clearly 开源、GitHub 上接了集成，他看到用户请求"给这些 mermaid 图加一个缩放（zoom）功能"（mermaid 图 = 用文字描述自动画出的流程图），就把请求附上去让 research skill"把 GitHub 信息拉进来、做网络搜索、看 UI、查文档"，然后"它自己决定怎么集成、给我一个方案，我批准后"再开干。→ 详细

• 他的设计流程顺序很固定：先有名字——"不管我在做什么，我得先有个名字"。然后做 logo，而且**"99% 的情况下 logo 都是在 Adobe Illustrator 里亲手做的"**——"我就是亲自钻在里面，用钢笔工具，把上千种字体翻一遍"。这一块他坦言"一直没找到什么好办法能走捷径"，是少数他不交给 AI、坚持手工的环节。→ 详细
• 他用 Rumored 完整还原了这个过程的来龙去脉：起点是一个概念联想——"因为 LLM 经常会断章取义地说东西，或者错误地引用你的话，所以'引用（quoting）'这个点就一直卡在我脑子里"。顺着这个概念，他去找"哪些字体的引号长得比较有意思"，结果翻了一大堆发现"它们最后都有点糊成一团、长得都差不多"，最后才挑中一款喜欢的字体。配色也是在这个阶段顺带敲定——他先黑白浅深随便搭，"接着我又看上了这种偏深的橙色"，再把它套进各种场景试质感，比如"做成**头像、favicon（浏览器标签页上那个小图标）**这种小图标会长什么样"。→ 详细
• 整套品牌工作都在**"动任何代码之前"**完成，他反复强调"到这一步我其实什么都还没设计、什么都还没动手写，纯粹是在搞品牌的东西"。定好之后，他把成品交给 AI："这就是我要的配色，这是 logo 的 SVG 文件"（SVG 是一种放大不糊的矢量图格式），交完这些"我就跳进代码里开干了"。→ 详细

• 营销页他故意等 App 做完之后才弄，理由是"得先搞清楚这 App 到底能干嘛"——高层想法他心里有，但具体落地成一个个功能"这中间得折腾好几天反复迭代"，功能没定型文案就无从写起。等"对功能这块觉得真的稳了"，才让 AI 生成营销网站，且先喂品牌那套：他想要的"调调（vibe）"是"带点棱角、紧迫感、科技感、不那么柔和、不那么大众脸"，还现场纠正"我想要紧迫感、科技感，不是'军事风'，这个词不太对"，然后让 AI"把整个 App 的功能集都过一遍，再据此生成营销文案"——让文案精准对齐真实功能而非凭空吹。→ 详细
• Peter 由此点破一个反直觉之处：他本想问"你做什么样的 MVP（最小可行产品，传统打法是先做最小版本试水）、怎么验证需求"，结果发现 Josh 是直接先把整个产品做出来。原因 Peter 自己说了"现在用 AI 把整个东西做出来成本很低"，Josh 补了句关键背景："对，但这在以前可不是常态。"——"先造完再说"这条路是 AI 时代才打通的。→ 详细

• 这是全片最有共鸣的一段。他的原话："发布一个东西真的挺吓人的——我这行干了 25 年，发布过几百个不同的产品。可每一次都还是那种感觉——啊，万一根本没人在乎怎么办？那也太惨了。"经验值再高，发布前的恐惧一次不少。他点名批判了一种拖延式打法："我们就老想拖着这事不办，搞个落地页收一收邮箱地址，然后试图把这个折算成'需求'之类的，但其实根本不是。那就是个干扰项（a distraction）。"（落地页收邮箱 = 先做个介绍页让感兴趣的人留邮箱，用人数当"有没有需求"的证据。）替代方案干脆："所以我干脆一咬牙，把东西做出来，直接扔出去，看会发生什么。"→ 详细
• 上线后靠什么获取关注？主要靠社交媒体："我在 Twitter 上有差不多六万粉丝，这至少能帮我把事情启动起来。"——粉丝盘子是他敢"造完直接扔"的底气来源。→ 详细

• Peter 直接问"发布了没人在乎的事现在还会发生在你身上吗"，Josh 答得毫不含糊："哦，绝对会。哦，老兄，太会了。"→ 详细
• 但他坦白自己真正要对抗的不是"怕没人在乎"，而是一个更隐蔽的自身毛病——"我太容易转头就扑到别的事情上去了：我会不再提某个东西，然后大家自然就把它给忘了。"产品没死，是被他自己的注意力转移"讲没了"。所以他给自己开的药方是"多去聊聊那些我已经做出来的东西，而不是光顾着做新玩意儿"。这与第 1 段他的 ADHD 自述前后呼应——同一种"闲不住"既是他的产能引擎，也是他的增长软肋。→ 详细

• 他**"尽量让每个东西都有个付费版本"**。例外是纯开源、不花他钱的（如 Markdown 编辑器 Clearly）"我估计永远不会对它收费，反正它也不花我什么钱"；但凡"那种需要托管、有服务器、会产生成本的东西，对，我就会收费，然后但愿有人愿意付钱"。→ 详细
• 判断 PMF（product-market fit，产品与市场是否对得上）、决定一个产品去留的硬标准，被他压成一句话："它能不能把服务器的钱赚回来？" 他用 Reply Social 举例："它接了一堆要花钱的 API 数据源，如果赚不回这些成本——这又不是做慈善，我不可能一直贴钱，它得自己养活自己。"他画出的那条线很具体："如果我已经掏了好几千美元先垫着这东西的成本，却还是搞不到一个人愿意付钱，那我大概就得重新琢磨琢磨一些事了。"→ 详细
• 心态上他因为做东西太久，已经不担心别人觉得蠢（详见下面的闪电问答）："我可能就是有这么个痒处想挠，但说不定全世界就我一个人有这个痒。那也没关系，这并不能说明这个痒是假的，只是也许它带来的盘子不够大、cover 不了成本。"——也就是说，"没人买"对他不等于"这想法很蠢"，只等于"这门生意养不活自己"，两件事他分得很清。→ 详细

• 关停一个还有付费用户的产品时，他会"试着对这点敏感一些"：具体做法是"关掉它的时候，把最近这几个月的钱退给他们"。他不假装这能弥补一切——"这并不能改变一个事实：他们现在用不上一个他们本来需要的工具了"——但当作"做生意的现实：我也不能一直自己掏钱让别人白用"。→ 详细
• Peter 补充了自己 Substack newsletter 的教训：以前按月订阅，发现"如果你定价太低，比如就 20 来块钱，大家动不动就'我要退款我要退款'，然后涌进来一大堆客服需求，烦死了"，所以后来"干脆决定收个几百块"。Josh 完全认同并上升成一条普遍规律："这些定价超低的套餐，往往客服负担最重（the highest support overhead）。"——便宜不等于省心，反而最磨人。→ 详细

• 五个产品的客服底层结构是：每个服务有一个独立邮箱，但全汇到他一个收件箱里。更关键的是他又掏出一个 skill（自嘲"我这听着简直像在给我自己的一堆 skill 打广告了"）：它能"在你的 App 里直接生成一整套应用内聊天客服系统"，相当于"Intercom 的替代品，但嵌在 App 里面"（Intercom = 市面上流行的付费在线客服工具），用户直接在 App 内聊天、消息发到后台。→ 详细
• 他强调"说到底里面还是只有我一个人"，但效率被两点拉高：① 聊天里"我能直接看到用户账户的上下文"，不用反复问"你是谁、用哪个版本"；② 能分门别类隔开处理——"处理完这个产品的客服，再去搞另一个"。Peter 由此提炼出一句 Josh 也认同的总结："作为一个单干的开发者，凡是你不想花时间去做的事，你都可以搭一套自动化的东西，尽可能地把它自动化掉。"→ 详细

• 他先承认时代红利："我觉得 AI 在很多方面把竞争的起跑线拉平了（leveled the playing field）。"——以前需要一整支团队才能做的事，现在一个人也能上手。但"被拉平"不等于"大家一样强"，他的护城河是25 年实战经验："我能把事情做得特别高效，是因为我有 25 年实打实摸爬滚打的经验——在没有 AI 的年代亲手把这些东西一件件做出来。"这份经验的实际价值是一种"预判力"：他"大概知道一个东西最终该长成什么样，能很快做到那一步，然后判断：这个行得通、这个不行、或者这个过几个月会变成大麻烦"。结论："我能比较快地把东西做到可以发布的程度、或者快速把问题修掉，就是因为这些问题我在 AI 之前都踩过了"——AI 帮你写得快，但什么写法将来会出事，得靠老经验提前看穿。→ 详细

本视频没有标准的"闪电问答"环节，但收尾处 Peter 抛出"对没有 15 年经验、靠 vibe coding 入门的新手开发者有什么建议"（vibe coding 指不太懂底层、主要靠跟 AI 对话"凭感觉"把东西堆出来的编程方式），Josh 的回答很集中，逐条列出：

• 多失败、快失败。 他先给 vibe coding 正名："很多人把 vibe coding 当成一个贬义词来用，但现实是——任何人能动手做出点东西，这本身就特别棒。"而搞清"什么不该做"的唯一办法，就是先把事情做错一遍——"他们唯一能搞清楚什么不该做的办法，就是先把事情做错一遍"。→ 详细

• AI 减少犯错次数，但别幻想"AI 之前就不犯错"——那是天方夜谭。 原话："任何形式的 AI 辅助编程都会减少你犯错的次数，但要说 AI 之前就不犯错，那简直是天方夜谭（insane）。"所以关键是"尽可能快地把错犯了，然后认清错在哪，下次别再犯"；而且"没什么能替代直接跳进去动手、把东西丢出来这件事"。→ 详细

• 尽早上线、别打磨几个月。 "那种花几个月打磨一个东西、再拿给别人用的想法，我觉得是个很糟糕的主意，完全没理由不现在就把它丢出来。"配套数据见第 16 段与下面：有些产品他 24 小时内甚至当天就上线（"当然不是每次都能做到，但只要能快我就一定快，绝对的"）。Peter 也现场承认这正是自己的软肋："我总想把东西做得特别特别好、特别完美，可结果可能根本没人在乎。"→ 详细

• 尽快拿到"别人的视角"。 这是他对"为什么要早上线"的深层解释："很多时候你会基于自己对问题的假设去做东西，也许它确实完美解决了你自己的问题，但别人面对的问题虽然类似，看起来却有点不一样。"差异你自己想不出来，"在别人真正用上之前，你根本没法知道差在哪"——直到有人来问"那这个用法呢？"你才"哦，我没想到这个"。所以"你要做的就是尽快拿到这些不同的视角"。→ 详细

• 关于"砸声誉"的心理包袱。 Peter 坦白自己作为"挺新手的创造者"，最怕"发布了个烂东西、又没人在乎，感觉声誉就砸进去了"。Josh 的解法是把"声誉"和"成败"解耦：他做东西太久，已经不担心别人觉得蠢，"每个人都不一样，也许全世界就我一个人有这个痒，但这并不能说明这个痒是假的"；真正该看的判断线，回到那句"能不能 cover 成本"。→ 详细

• Twitter / X：@shpigford —— 他说"最好的地方就是 Twitter"，自称"一天在那儿发一百条，所有产品什么的都在那儿聊"，简介里放了他"那五十来个项目的全部链接"。→ 详细

• 博客：everydayisayear.ai —— Peter 评价"写得非常好，也非常实用"。→ 详细

• 主持人：Peter Yang（YouTube 频道，本期由 WhisperFlow 赞助——一款语音转文字的 AI 应用，Peter 说它每周帮他省下至少 3 小时，会自动删口头语、排版句子；优惠码 Peter WhisperFlow 可免费用 6 个月）。→ 详细

• 提及但未展开的彩蛋：Peter 还点名喜欢 Josh 的 "rats ball"、"open claw"，说"咱们下次可以接着聊那个"，留作悬念。→ 详细