主观觉得更快，可能测到更慢
METR 在 16 名熟悉开源项目的开发者、246 项任务中随机允许或禁止 AI。该条件下，允许 AI 的任务耗时增加 19%。这是早期 2025 工具与特定成熟项目的结果，不能外推到所有开发工作或今天的模型。[S3]
Garry Tan × Paul Copplestone
小团队，
放大的是什么？
AI 可能缩短部分制作任务。一个小团队能否因此交付更多价值，仍取决于用户需求、质量、持续使用和总成本。
01 / 先读结论
把制作优势，逐步验证为交付优势
本页分析：可以尝试更小团队与更多自动化。每次尝试都要保留可观察的验收结果，才能判断这种组织方式是否适合当前任务。
本页结论 · 分析判断
制作更快之后，
还要测量什么？
原型完成、代码生成、任务自动化、客户付款、持续使用和复购是不同指标。制作成本下降可能扩大可尝试的项目数量，也可能增加同质化、获客竞争和维护负担。
- 总工时：把审查、返工与维护计入同一统计范围。
- 质量：同一验收标准下比较结果，记录缺陷。
- 用户行为：分别记录付款、接受交付、后续使用和复购。
01 → 任务能力
某项工作更快
比较同类任务，先记录基线。
02 → 系统总量
总工时更少
加上集成、复核和返工。
03 → 用户结果
交付达到要求
让真实使用者按标准验收。
04 → 经营结果
重复产生净价值
继续观察使用、复购与全部成本。
箭头表示下一项需要验证的关系。通过前一步，不能自动证明后一步。
02 / 原文图谱
七个主题，各自提出什么问题
左侧是主题；中间按公众号整理转述嘉宾观点；右侧是本页提出的检验问题。已核对的原访谈数字段见 [S8]；自动字幕可能存在识别误差，精确措辞以原音频为准。[S1]
嘉宾观点 · 二手转述
硬科技
AI 辅助研发，让少数技术人才更可能尝试过去难以进入的领域。
本页检验：仿真改进是否经过真实实验、制造和客户验证？研发能力与资本需求应分别测量。
嘉宾观点 · 二手转述
单人产出
嘉宾用多种高倍数描述个别人的产出，也承认先前的表达过强。
本页检验：倍数指哪项任务？是否在同等质量下计入了人工复核？单项任务能否代表公司全部工作？
嘉宾观点 · 二手转述
创业基本功
与用户交谈、做出首版、观察真实使用，仍被视为创业的基础。
本页检验：是否记录用户原来的做法、接受标准与实际行为？Paul Graham 早期文章支持这一方法方向，但不能验证本次转述的逐字准确性。[S2]
嘉宾观点 · 二手转述
Agent 与记忆
Garry 的经验从细致编排转向目标、上下文与检索辅助，并提到 G Stack、G Brain。
本页检验：能否追溯来源、处理过期信息、定位错误和恢复操作？检索测试与外部动作权限要分开管理。
嘉宾观点 · 二手转述
早期招聘
优先考虑熟悉、可信、愿意运用 Agent 的合作者。
本页检验：是否能独立定义问题、审查结果、处理异常并负责交付？熟悉程度与岗位能力应各自验证。
嘉宾观点 · 二手转述
融资与即时软件
硬科技受到更多关注；按需生成的小工具成为新的工作方式。
本页检验：融资金额不能证明需求。临时工具是否留下权限、依赖和维护成本？是否存在反复发生的用户任务？
嘉宾观点 · 二手转述
SaaS 与小团队
嘉宾反对 SaaS 消亡的判断，并用匿名高收入案例支持小团队的可能性。
本页检验：收入指累计、年度、ARR 还是其他口径？是否含外包？是否盈利？无公司身份和数据口径，无法比较典型表现。
03 / 数字核查
数字先对口径，再谈意义
未核实数字保留为线索，不制作趋势图、不计算投资回报，也不把匿名个案拼成人均收入排行。
已追到发言 · 统计未验证
25% / 3–5%
官方访谈 00:21–00:36，Garry 给出约 75% 软件、25% 硬科技，并用近似、回忆性的措辞描述五年前约 3–5%。已验证他这样说过；尚无批次清单、样本量与分类标准，不能当作整个创业市场份额。[S8]
发言人估计
8× 至 100×
官方访谈 01:38 起，Garry 先撤回先前的 400 人表达，再提及 8、10、50 至 100 倍。字幕与公众号转述方向一致；没有统一任务、时间、质量口径和对照样本，不能作默认实测参数或招聘与裁员依据。[S8]
匿名案例
收入与人数
官方访谈 25:24 起，嘉宾列出 2000 万、5000 万、1 亿美元收入及 50、30、15 人的团队；原文另提年轻创始人的案例。公司、时期、收入口径、外包与利润均未验证。不要把两组数字自行一一配对，也不要将收入当作利润。[S1][S8]
已纠错 · 官方公告
WhatsApp 收购金额
公众号和官方视频 26:17 附近均出现“以 10 亿美元出售”的说法。Meta 于 2014-02-19 公告的交易对价约为 160 亿美元（40 亿现金、120 亿股票），另有约 30 亿美元员工受限股。这里采用公告时口径，并非最终交割估值；“55 人”仅核实为嘉宾说法，未找到独立一手人数记录。[S5][S8]
成果公告与机构状态分开
Navier–Stokes
不可作能力保证
95% / GPU 故障 / 24–36 月
长上下文检索准确率、GPU 通信故障比例与未来问题解决时间，均缺本轮可核对的测试、样本或原始报告。七加减二是历史认知表述，不能与 token 数直接换算组织能力；本页不采用这些数字作能力或时间承诺。[S1]
怎样削弱本页的判断？
如果相同验收标准下，计入复核、返工和维护后仍没有减少总工时，就应下调对该任务的效率判断。如果用户持续使用并重复付款，且总成本可控，才有更强证据支持商业价值。任何一项反证都应保留。
04 / 可调整情景
代码快十倍，总工时会怎样？
这是本页建立的简化模型。先把一项任务的原始总工时标准化为 100 小时，再拆分可加速工作与其他工作。所有预设都是演示假设。
总工时推演情景演示 · 不是实测
占原始总工时的比例；其余工作保持原耗时。
只作用于 p 对应的工作；要求质量标准相同。
新增复核、集成、返工与维护；分母是原始总工时，避免与 p 内的耗时重复计算。
61.0 h情景总工时 / 原始 100 h
1.64×总体加速倍数
未加速工作加速后工作新增工时
未加速 40.0 h + 加速后 6.0 h + 新增 15.0 h = 61.0 h。情景节省 39.0% 总工时。
工时比例 = (1 − p) + p ÷ s + o
总体加速倍数 = 1 ÷ 工时比例
总体加速倍数 = 1 ÷ 工时比例
本计算器不是效率实测，也不是收入预测。它仅演示：当一部分工作可以被加速时，新增复核、返工与维护成本会如何影响总体工时。请使用自己的任务记录填写参数，并将结果视为待验证假设，而不是生产率承诺。
查看假设、边界与公式例子
公式假设工作可以按原始工时拆分，其余工作耗时不变。它没有表示任务之间的依赖、排队、客户等待和并行资源冲突，因此不能直接预测日历交付周期。若新流程改变质量、范围或任务种类，需要重新建立可比基线。
初始值：p = 0.60、s = 10、o = 0.15。结果 = 0.40 + 0.06 + 0.15 = 0.61，100 ÷ 61 ≈ 1.64 倍。模型不计算收入、利润、就业人数或成功率。
后续工具改进，也需要新的测量
METR 的后续数据出现加速信号，但研究者指出，参与者与任务选择、以及并行 Agent 的计时问题，使新数据不足以可靠估算当前效果。旧研究不能当成“AI 永远降效”的证明，新研究也不能支持统一高倍数。[S4]
05 / 商业验证
每一步，留一份独立证据
这是一套建议的记录顺序，实际业务可以分支或反复。下列状态目前都是“待读者验证”；本页不推断读者是否已有客户或收入。
- 01 / 具体问题
谁在什么情境受阻
记录原有做法、发生频率和现有代价。
访谈表达说明存在问题；仍需观察行为。
- 02 / 报价
对交付范围达成理解
写清付款方、使用者、期限与接受标准。
收到报价或口头赞同，尚不能证明付款。
- 03 / 付款
有人真实支付
记录金额、退款条件与对应承诺。
付款证明这笔交易；交付仍需验证。
- 04 / 验收
用户接受交付
对照预定标准，保留问题与修改记录。
一次验收尚不能说明后续价值。
- 05 / 后续使用
结果进入真实工作
约定合适观察期，查实际使用与效果。
使用不自动等于愿意继续支付。
- 06 / 复购或续费
同类需求再次发生
观察再次付款、续费或明确流失原因。
一次复购尚不能估计稳定留存。
- 07 / 全部成本
扣除投入后仍值得做
同时计入人力、模型、获客、交付、维护和退款。
成本从第一天记录，最后统一核算。
- 08 / 重复验证
检查结果能否复现
换任务、换用户，保留失败样本与结果分布。
小样本提示路径，不估计普遍成功率。
收入、人效与利润，各自回答不同问题。
收入高不能单独证明净利润高。团队人数少也可能包含大量外包、平台能力与创始人隐性工时。比较小团队时，需要统一时期、收入定义、人员边界、质量与服务成本。
06 / 组织与工具
给 Agent 明确任务，也保留验收能力
以下是本页建议，不是嘉宾已经证明的通用方法。用一个范围清楚、能恢复的任务开始，避免把整套工具采购当作经营验证。
从文章迁移到自己的流程
- 目标与上下文：写清输入、输出、质量标准、资料来源和不可做的动作。
- 并行有条件：只有相互独立的任务才并行。对同一文件或系统的写入指定唯一负责人。
- 记忆可追溯：保留原文、日期与来源。为检索设已知答案的小样本，记录漏检与错误引用。
- 外部动作单独授权：能生成草稿不代表能发消息、付款、改权限或发布。让负责人明确确认目标。
先识别招聘要解除的限制
- 如果需求判断不清：先安排真实用户观察与交付访谈，记录仍无法回答的问题。
- 如果审查积压：测量审查耗时、缺陷类型和返工；再判断需要领域经验还是流程调整。
- 如果维护占用增长：核查重复故障、依赖与服务承诺，再确定岗位责任。
- 如果拟聘合作者：给同一范围的小任务，观察其问题定义、异常处理与交付证据，工具熟练度只是其中一项。
本页推断 · 需要客户验证
即时软件之后，SaaS 可以验证哪种价值？
客户也许愿意为已经接通的数据与权限、稳定运行、多人协作、问题处理和明确的服务责任付费。这些只是候选价值，仍需逐项问清付款方、替代方案、接受标准和持续使用情况。能临时生成一个工具，不代表愿意自行承担长期运行；有人选择购买，也不能证明某种收费方式普遍成立。
一项任务的最小闭环
负责人定义标准 → Agent 生成或执行 → 负责人核对来源与测试 → 真实使用者验收 → 记录工时、缺陷和下一步。失败时回到对应步骤，保留错误结果。
即时软件也需要有人维护。若每次使用都要重复修复、解释或人工兜底，应将这些工时纳入总成本；若任务涉及敏感资料，应先确定可用的数据范围。
07 / 七日实验
用一周换一个可复核的判断
本计划用于发现流程问题，不是市场需求已经成立的证明。原有客户、已有收入或正在运行的业务，均应使用自己的真实记录。
第 1 天 / 划边界
选一项有明确输出和验收标准的任务，写下原始流程。先确定工时、缺陷和费用的记录方式。
第 2 天 / 记基线
按原有流程完成一次记录。任务若无法重做，就选择难度相近的任务，并写明这种比较的偏差。
第 3 天 / 用 Agent
记录生成、等待、人工介入和模型费用。试验期间固定输入范围与质量标准，避免同时改变太多因素。
第 4 天 / 算返工
独立核查输出并修复。把审查、集成和返工加入总工时；记录仍未发现的风险与后续维护窗口。
第 5 天 / 看验收
请真实使用者按预定标准验收，记录接受、修改或拒绝及原因。没有真实使用者时，标记“用户价值尚未验证”。
第 6 天 / 查行为
若确有交易场景，核对报价与实际付款；若是内部任务，观察后续使用。复购与长期使用超出一周时，另设回访日期。
第 7 天 / 作决定
按事先确定的阈值选择继续、修改或停止。一次对比容易受任务难度与熟悉程度影响，下一轮交换任务顺序并重复记录。
开始前填写自己的阈值
任务：______ 质量标准：______ 工时上限：______ 费用上限：______
真实使用者及接受标准：______ 后续观察日期：______ 停止条件：______
没有实际付款、使用或复购记录时，相应一栏保持“尚未验证”。不以模拟反馈、模型评分或他人成功案例填补。
08 / 来源与限制
知道什么，尚不知道什么
外部事实按已打开的原始页面核查。证据只能支持对应陈述；官方方法论文章不能证明这次访谈的逐字准确性。
- S1 · 主材料深思圈：YC CEO 谈小团队的时代：一个人干一百个人的活，创业的根本却一点没变
发布：2026-10-23 08:35。wechat-reader 成功读取文字正文，未截断。包含 5 个图片引用，未做图片 OCR；未把图片内容作为本页事实。文章是中文整理与评论，属于二手材料。
- S2 · 方法原文Paul Graham · Do Things that Don't Scale
2013-07。原文论述手动招募早期用户、直接观察使用和提供服务。它支持用户工作的重要性，不验证 AI 倍数与当前 YC 批次数据。
- S3 · 对照研究METR · Early-2025 AI and Experienced Open-Source Developers
2025-07-10。16 名开发者、246 项任务；特定工具与成熟项目条件下耗时增加 19%。不代表其他行业、全部开发者或当前工具。
- S4 · 研究更新METR · Changing our Developer Productivity Experiment Design
2026-02-24。后续研究存在参与者选择、任务选择与计时限制，研究者认为新数据难以可靠估算当前效果。与 S3 来自同一研究机构，不算两条独立研究。
- S5 · 金额纠错Meta · Facebook to Acquire WhatsApp
2014-02-19 公告。约 160 亿美元交易对价，另有约 30 亿美元受限股；不是 10 亿美元收购。只核查当时公告金额，未将其作为 AI 时代案例。
- S6 · 成果提出方OpenAI · On the Navier–Stokes Millennium Prize Problem
2026-09-08。发布内部系统的解答与形式化材料；本页只核查官方声明，未独立验证证明。不能由此推断所有研发问题将在相同时间与成本内解决。
- S7 · 机构页面状态Clay Mathematics Institute · Navier-Stokes Equation
2026-10-23 查阅：Active。表示当前页面状态，不能据此判断提出方证明正确或错误，也不能替代数学共同体审查。
- S8 · 原始访谈Supabase Library · Tiny Teams Doing the Work of 100 People | Garry Tan
2026-10-02 录制，官方频道 2026-10-12 上传，时长 27:09；讲者 Garry Tan 与 Paul Copplestone。官方活动页也列出此场次：Supabase Select 26。本次对关键段自动字幕作定向核对，未逐秒听校全片。
本次制作与核验范围
- 原访谈：已定位官方视频与活动页，并核对四个关键数字段的自动字幕。主材料仍为公众号文字；未逐秒人工听校全片，未独立验证嘉宾的样本数据。
- 本页整理原文七个主题；其余框架、公式与行动计划均明确标为本页分析或建议。没有读取读者的经营后台，未核实匿名公司的收入。