3人团队，如何用AI对抗百人竞品
我上次写代码是2005年。
上个月，我是我们项目里定位并修复代码 bug 最多的人。
说说背景。我在大厂和创业公司都干过，做过会员、电商、女性社交、社交游戏、互联网保险等等产品，前后管过几十到上百人的团队。20多年里，对”如何管理一个产品团队”这件事，我有相当完整的认知：PRD、排期、评审、测试、发布，这套流程我已经记不清走过多少次了。
现在我在做一个 AI 健康硬件创业项目。核心团队三个人，而竞品里，主流团队规模是两位数到三位数起步。
每次有人问我们怎么做到的，我通常回答”因为 Claude”。这篇文章想说清楚这句话到底是什么意思。
为什么是 Claude Code，而不只是 AI 助手
市面上不缺 AI 工具。我用过不少，ChatGPT、Gemini、各种垂直场景的 AI 产品。为什么最终把工作流构建在 Claude Code 上？
差异在于它怎么”理解”你的工作。
用普通 AI 助手做技术相关的工作，你要先把问题描述清楚，AI 才能帮你分析。描述本身就是信息损耗的源头：你描述的是你所理解的现象，不一定是真正发生的事。对一个不会写代码的 PM 来说，这个损耗尤其严重：你说”用户会被踢出登录”，背后可能有十几种代码层面的原因，你不知道，描述里也带不出来。
Claude Code 的做法不一样。它可以直接读代码库，自己看。你不需要把问题翻译成语言描述，它进去，原原本本看清楚发生了什么，然后告诉你。这是”AI 助手”和”AI 同事”之间的本质差别。
另一个关键机制是项目记忆。我在项目根目录下维护着一份 CLAUDE.md 文件和 MEMORY.md 文件，存着这个项目的上下文：架构说明、技术决策、团队规范、已知问题、我的工作偏好。每次新开一个会话，Claude Code 自动读入这些内容，不需要重新建立背景。这让 AI 协作从”每次重新教一遍”变成了”持续进行中的协作”。
效果是什么？我们项目的 docs/analysis 目录下存着十几份不同模块的代码分析文档，docs/plans 下存着三十多份技术方案和 PRD。这些内容叠加在一起，让 Claude Code 对这个项目的理解，比任何一个刚加入的新工程师都要深。
团队的变化，是结果不是原因
我们最早的分工是传统的：一个前端，一个后端，我做 PM。每个人守着自己的职责边界。这种模式我熟悉，以前大厂和创业项目都是这么跑的。
大概从半年前开始，这个分工慢慢失效了。
失效的方式不是某次组织调整，是自然发生的渗透。研发开始在开发前主动写 PRD 草稿，拿来跟我讨论。我开始能直接读他们写的代码，提出具体的修改意见。没有人宣布要”打破边界”，只是当 AI 帮你补上以前不会的那部分，”这不是我的职责范围”这句话就站不住脚了。
结果是现在我们三个人都是全栈。能力各有侧重，但已经没有人会说”这件事我没法碰，必须等另一个人来做”。
这个变化之所以重要，是因为它直接决定了速度。任何职能墙都是等待的温床。你发现一个 bug，研发在忙别的，等一天；你想确认某个实现是否和 PRD 一致，研发查完转述给你，但你不确定理解对了，再沟通半天。这些摩擦加起来，每周吃掉的时间相当可观。
三种工作方式
我用 Claude Code 工作，大概有三种模式，各自解决不同的问题。
第一种：对话分析。 这是最轻量的用法。我把背景、问题、相关材料给它，它帮我分析、比较方案、起草文档。PRD 撰写、竞品分析、技术方案评审，都走这个路径。这和用普通 AI 助手差不多，但因为有项目记忆，它的分析带着对我们具体情况的理解，不是泛泛的通用建议。
第二种：代码实操。 这是改变最大的部分，也是我后面会详细展开的内容。它直接读代码、定位问题、生成修复方案。我提 PR，研发 review。这条路径让我从”技术问题的旁观者”变成了”参与者”。
第三种：全流程自动化。 这里要区分一下 Chat 和 Cowork 两种模式。Chat 是对话式的，你问一步它答一步，你全程在掌控每个环节；Cowork 是任务式的，你描述好目标，它自主拆解步骤、按序执行、调用需要的工具，最后汇报结果，全程不用你参与。区别就像是你自己一步步查资料写报告，和把任务交给一个靠谱的同事去做。
这一块对 PM 来说解放感最强，因为 PM 的工作里有大量天然适合这种模式的任务：市场调研、竞品分析、数据整理、汇报文档，这些工作结构清晰、步骤可拆解，以前要花半天甚至一整天，现在可以描述清楚需求，让 Claude Cowork 自主跑完：联网搜索、整合数据、生成文档，最后你审阅结论，确认方向对不对。我之前写过一篇分析 AI 智能体趋势的文章，那篇文章的初稿本身就是这么生成的：联网搜索最新动态、读取参考资料、撰写正文、顺带输出配套 PPT，共 5 步自主执行，两份文件同时落地，我只需要在最后审阅一遍。类似的逻辑用在代码侧就是：全量代码审计、PRD 合规性检查，启动后我去做其他事，跑完再回来看结果。
PM 拿到了一个以前没有的能力
我想具体说说代码实操这条路径，这是我感触最深的变化。
有次，我们刚把 App 链接发给几个外部测试用户，当天就陆续收到反馈：打开 App 直接跳到了登录页，像是被踢出去了。让珍贵的测试用户在第一天直接遇到这个，时机可以说是最差的。
在以前，这类 bug 的处理流程是：PM 描述现象给研发 → 研发排查 → 结论转述回来 → PM 理解一遍 → 如果理解有偏差，再沟通一轮。每个循环快则半天，慢则一两天。最让人抓狂的不是慢，而是”转述”这个环节本身：信息在传递过程里会被压缩和变形，PM 拿到的结论已经是一个简化版本，不是原始的代码逻辑。你在这个简化版本上做决策，风险很难量化。
那次我没有走那个流程。我让 Claude 直接读服务端代码，从 token 验证逻辑开始追。十分钟后，我有了一份完整的根因分析：问题出在服务器重启后所有用户 token 同时失效，同时还顺带发现了一个独立的客户端 bug——网络异常时也会无差别触发登出，两个问题此前都没有人注意到。
但更关键的是接下来我做的一个判断。修复这个问题有两条路：一是把验证逻辑改成”无状态”模式，token 信息直接存在加密串里，不依赖服务器端存储，以后服务器重启也不影响；另一条是保留现有的有状态方案，修复持久化配置。前者看起来更”彻底”，但我知道我们将来一定需要”主动踢人下线”的能力——用户改密码之后、账号出问题时，服务端要能强制让 token 失效。这个能力无状态方案做不到。
我选了保留有状态方案，让 Claude 生成了 Redis 持久化的修复配置，研发确认后部署。这个决定背后是产品逻辑，不是技术逻辑。这正是 Claude 给不了我、我必须自己来的部分。
“读懂”之后，下一步是”动手改”，这个跨越比我预想的要小。一旦能定位问题，修复步骤就变得清晰：哪个文件、哪几行、改成什么。让 Claude 生成修改方案，在本地验证，没问题就提 PR（代码变更请求），研发 review 后决定是否合并。到目前为止，我提的修改还没有被驳回过。
第二个案例：我独立部署了崩溃监控系统
另一件事，让我意识到”一个人能做到什么”已经不一样了。
App 第一次发给外部用户测试，当天就有 iOS 崩溃反馈，但我们完全不知道原因。用户描述的现象五花八门，”突然闪退””进不去””卡死了”——没有日志，这些描述毫无价值。问题是，当时 App 里根本没有任何远程日志能力，所有调试输出只存在本地控制台，手机一关就没了。
我决定自己来解决这个问题，不等“研发排期”。
和 Claude 讨论了几个主流方案的优劣之后，我选了 Sentry。原因不复杂：这个方案我一个人可以独立完成，全程不需要研发帮忙。另一个更主流的选项配置链路更长，每一步都需要开发环境配合。对我来说，能独立推进的方案，就是更好的方案。当天，在 Claude Code 的配合下，我完成了所有代码集成，Sentry 开始接收数据。从零到第一条崩溃报告落地，没有打扰任何人。
但更有意思的事发生在后来。Sentry 上线之后，蓝牙相关的错误瞬间刷屏，几百条报警，看起来像是整个模块都在崩溃。我让 Claude Code 帮我梳理这些错误的性质：哪些是蓝牙设备断连时本来就会触发的”预期异常”，哪些是真正的程序错误？分析结果出来，绝大多数是前者，蓝牙断连是正常用户行为，不是 bug。真正需要修的只有少数几条。
这个判断不是技术判断，是产品判断：什么是正常的、什么是异常的，取决于你对用户行为的理解，不是对代码的理解。Claude 给了我看清楚的工具，但判断本身还是我来做。
测试流程也变了
这个变化稍微隐性，但影响不小。
在我熟悉的传统互联网项目研发流程中，发布链条是：开发完成 → 研发自测 → 测试专员测试 → PM 体验 → 发布。每个环节都是等待和交接，任何一步发现问题就得往回走。
这条链条现在短了很多。核心原因是 Claude Code 在写代码时会把”可验证性”内置进去，它知道某段代码改了之后该怎么测，会把验证步骤明确写出来，有时候还会在代码里加诊断日志方便确认行为，甚至能自己写各种测试用例。问题被发现的时间点从”测试阶段”前移到了”写代码阶段”，下游兜底的压力因此小了很多。
另一个变化是我们没有专职测试了。测试当然重要，但当研发和 PM 都能在完成后走一遍完整验证，专职测试在一个三人团队里撑不住岗位成本。
这不只是效率提升
我在前面写的这些，容易被理解成”AI 让大家效率更高了”。但我觉得这个理解不够准确。
发生的事情不只是速度变快了，而是职责边界本身在重新划定。
举一个具体的对比。过去我招 PM，会问”你熟悉哪种开发流程””你用过哪些项目管理工具”。现在这些问题我已经不问了，因为工具熟不熟练这件事不再稀缺。我现在关心三件事：工程思维，能不能理解一个系统的逻辑，知道什么能做、什么不能做、为什么；产品思维，能不能从用户角度看问题，而不只是完成需求；设计品味，能不能判断好与坏，而不只是”符合规格”。
但这两年我越来越意识到，还有一件事被低估了：说清楚问题的能力。
以前我面试 PM，会对候选人说：PM 这个岗位没有硬技能门槛，不要求你会写代码或者会 PS，这反而是个问题，因为谁都能投简历。所以你必须在软技能上有竞争力，其中最重要的一条，就是能不能把一件模糊的事情说清楚。
现在这条变得更重要了，而且换了一个语境：你怎么跟 Claude 说话，决定了它能帮你做到什么程度。跟它说”帮我查一下这个 bug”和”帮我从这段 token 验证逻辑开始读，看看用户会在什么情况下被意外踢出登录，列出所有可能的代码路径”，出来的结果差距极大。这不是提示词技巧的问题，是表达清晰度的问题：你对问题的理解有多深，决定了你能问出什么样的问题。
还有一件事：因为很多工作现在是 Claude Code 在执行，我意识到管理能力变得具体了。
不是抽象的”要有管理能力”，而是字面意义上的管理：你给方向，它干活；它跑完一段，你 review 结果；有问题，你指出来让它修正；方向对了，你批准继续。这个流程跟带一个高执行力的下属没有本质区别。有时候我给 Claude Code 启动一个任务，它开始自主跑，我站起来伸个懒腰、去倒杯水，它还在干。这种感觉在以前是不存在的。
Claude 可以读 PRD、写代码、排查 bug、分析竞品，但它不知道这个功能该不该做、用户真正在意什么、这个体验是否达到了想要的标准。这些判断，是我的工作。AI 放大的是你的判断力，不是替代它。
我在上一篇文章里写过 Zack Shapiro 的故事——一个两人律所，靠 Claude 接大型律所才能承接的收购交易，凌晨前交出完整反提案，交易第二天如期完成。他有一句话我直接共鸣到：「有 10 到 20 年积累的专业人士，手里握的恰恰是 AI 让它变得更有价值的资产。」
做产品是这个逻辑。带团队是这个逻辑。我猜大多数需要判断力的工作，都是这个逻辑。
三个人，做的事比以前多了。我们没有比别人更能干，只是这件事的前提条件已经变了。
以前”小团队”意味着不得不放弃一些事情，因为人手不够。现在”小团队”意味着你必须想清楚什么是真正重要的，因为 AI 会帮你执行，但它不会帮你思考优先级。
律所的故事是一个版本。我们做硬件创业的故事是另一个版本。你所在的行业，大概率也有类似的事情正在发生，只是还没有人写出来。