前言　AI 时代，人人都应该成为 Builder

AI 让写代码变得没有门槛，模型能力越来越强，到处是一种“全民开发”、“商业”的氛围。我认为做产品对一个人的综合能力要求很高，做产品的人要能把需求、设计、开发、上线、商业化组织成一个完整的系统。

一个趋势

“一人公司”“超级个体”这两个词，现在到处都能听到。这两个词说的都是一个人带着几个 AI，做出过去要一个团队才能做出来的产品，自己找用户，自己收钱。

我认为这是一个大趋势。写代码、画页面、查资料这些活，AI 都能接过去，价钱一个人付得起。公司会用更少的人做同样多的事，个人也有了机会，可以自己把一个想法做成一门生意，用不着先凑齐一个团队。

这个趋势和每个人都有关系。留在公司里的人，会被要求一个人做完过去几个人分着做的事。想自己出来做的人，手里有了够用的工具。两条路都要求一个人能把想法做成产品，并且让它有人用。有这种能力的人，这本书叫 Builder，这本书讲的就是怎样成为 Builder。

趋势是这样，我看到的实际情况却是，很多人已经动手了，然后停在了半路上。

一个现象

这两年我经常遇到这样的朋友：他用 AI 做了一个页面，截图发到群里，大家说很酷，他跟我说“我一天搓一个工具，太爽了”。过了一个月我再问他，那个页面还在他电脑里，没有人用，他自己也不用了。我理解那种兴奋，我自己也是从那个阶段过来的。可是一个月做三十个工具，和把一个工具做到有人每天用，是两件不同的事，练出来的能力也不一样。

另一类朋友更让我在意。他是业务部门的，用 AI 做了一个数据周报页面，他输入一句话，页面就出来了，第一眼看上去确实很漂亮。可是他拿到业务里用了一周，问题一个接一个冒出来：页面怎么发给老板？数据错了怎么修改？下周还能不能接着用？历史版本在哪里？不同部门能不能看到不同的内容？能不能接入真实的数据源？能不能定时发送？这七个问题 AI 都能解决，可是他当时一个也没有想到。AI 替他做出了一个页面，他需要的是一套周报流程。第 1 章会把他的经历讲得更详细。

现在用 AI 写出一段代码、做出一个页面已经很容易。做出一个有人持续使用的产品仍然很难，这本书讲的就是中间差的那一段。

这段路之所以难，有一个原因在工具之外。过去一个产品从想法到用户手里，要经过产品经理、设计师、工程师、测试、运维、运营六七个角色，每个角色只做自己那一段，谁也不需要走完全程。现在一个人加一个 AI 就能把它做出来，可是没有人教过这个人全程的每一段分别该做什么。他要么只会前面几段，要么只会中间几段，剩下的只能靠猜。猜错一段，产品就停在那里。

为什么人人都应该成为 Builder

我认为，现在一个普通人借助 AI，就能独自把想法做成产品。过去你有一个想法，要么自己学几年编程，要么找人合伙，要么花钱外包。现在你可以直接告诉 AI 你要什么，它就把代码写出来。门槛降下来了，剩下的问题是你知不知道自己要什么、看不看得出它做得对不对。

Andrej Karpathy 讲 Software 3.0：人人都会说自然语言，所以一下子人人都成了程序员。Vercel 的 CEO Guillermo Rauch 说，他们要把能做软件的人从几百万开发者扩大到一亿人以上。李彦宏说，只要会说话就能当开发者。LinkedIn 取消了助理产品经理的培养项目，改成培养 Builder，同时教写代码、设计和产品，还设立了正式的 Full Stack Builder 职称。

这几位里，Karpathy、Rauch 都来自 AI 编程产品公司或者和它们关系很近，他们的生意和“人人都能做软件”直接相关，读他们的话时要知道这层利害关系。LinkedIn 那一条分量不一样，因为这家大公司真的改变了招聘和职级，把“一个人从想法做到上线”写进了岗位。它给 full-stack builder 下的定义是：能够跨越设计、产品管理、技术、商业策略这些传统上分开的领域，把各种技能和专长组合起来做出产品的人。这和我说的 Builder 是同一个意思。

Anthropic 也讲过他们内部团队怎样用 Claude Code（Anthropic 做的 AI 编程工具）：不熟悉 TypeScript（一种编程语言）的数据科学家做出了可视化应用，法务团队做出了电话分流的原型。做软件的人，已经开始从工程师扩大到任何能把问题描述清楚的人。

国内外讨论“人人都能做软件”的重心不一样。国外的讨论集中在公司内部的岗位怎么变：LinkedIn 改变了培养项目，Anthropic 的非工程团队自己做工具，《启示录》的作者 Marty Cagan 预测产品团队会从八个人缩到三个人。国内的讨论集中在个人和一人公司怎么创业：李开复说未来会出现一个人的独角兽公司，CEO 成为 AI 的总指挥；周鸿祎说你睡觉的时候智能体在替你干活，你就成了超级个体。对产品经理读者来说，国外的材料回答“我的岗位会怎样”，国内的材料回答“我能不能自己做”。这本书两个问题都想回答，前一个靠入门篇和进阶篇前半部分，后一个靠进阶篇的运营与商业化和实践篇。

OpenAI Codex 应用的负责人 Andrew Ambrosino 说，很多公司取消产品岗位、宣布每个人都当 builder，是一个糟糕的主意；他打的比方是，会用 Excel 的人不等于能进财务团队。a16z 的 Justine Moore 说，目前只有大约 1% 的人口（开发者、创始人、设计师、产品经理）在用 AI 编程工具，对大多数人来说 vibe coding（只对 AI 提要求、不读它写出的代码的做法）还是一项观赏运动。Karpathy 自己后来也把 vibe coding 改称 agentic engineering，特别强调 engineering 这个词意味着这件事有它的方法、科学和专业功夫，专业场景需要更多的监督和审视。

Marty Cagan 接受“product creator”这个说法，同时保留了一条：产品经理管商业约束、设计管用户体验、工程管技术，三种能力仍然各自独立，团队会变小，角色不会消失。LinkedIn 在推出 full-stack builder 的同时，也设立了 Craft Leaders，分别负责设计、增长等领域的专业水准。国内的保留意见来自实践者：一位创业一年的朋友写过一篇复盘，题目就叫“第一次 Build 的成就感，是创业最大的幻觉”，他说做出来之后的每一件事，运营、维护、边界管理，都没有消失，都变成了债务。

这些保留意见我都同意。它们都在说，AI 降低了把想法做出来的门槛，判断做什么、做出来以后怎样维护，仍然需要专业能力。门槛降下来了，我认为人人都应该试着成为 Builder。判断和维护需要的专业能力，这本书一块一块讲清楚。这本书不会把你变成产品经理、设计师和工程师三个人。读完以后，你会知道这三个人各自在做什么判断，知道哪些判断你可以自己做，哪些可以交给 AI，哪些要去找专家。

Builder 是什么

Builder 是借助 AI、一个人把想法做成产品，并让它持续被使用、能养活自己的人。

Builder 要做三个动作。提出意图：知道自己要什么，说得清楚。指挥 AI 做出来：把意图写成 AI 能执行的文件，让它干活。对结果负责：看得懂它交回来的东西，判断对不对，决定能不能给用户。

Builder 负责开头和结尾，以及给 AI 立规矩；中间的执行交给 AI。开头是想清楚要什么、什么叫做好；结尾是验收、决定发不发布；规矩是告诉 AI 哪些事不能做、做完了怎样算数。中间那一大段写代码、画页面、查资料，还有生成方案，AI 比你快得多，也比你便宜得多。

定义里还有一个词要解释：养活自己。我说的养活自己，意思是这个产品能长期经营下去：它的收入能覆盖它的开销，或者至少你知道将来谁会为它付钱。一个人做的产品，没有公司在后面养着，做出来以后每个月的服务器、域名、模型调用都是钱，没有人用、没有人付钱，它就会在某一天被你放弃。这本书从入门篇最后一章起就开始讨论谁来付钱，到进阶篇最后一章正式讲怎样收费。

还要说一句 Builder 和“独立开发者”的区别。独立开发者这个词强调的是一个人、会写代码；Builder 强调的是把想法做成产品，会不会写代码在其次。按这个说法，用 AI 做出一个有人付费的工具的产品经理是 Builder。程序员做了三十个没人用的小工具，也还只是在练手。

Builder 和只写代码的区别

写代码只是开发实现这一段。一个产品从想法到用户手里要走六段路：需求分析、产品设计、开发实现、测试验收、发布上线、运营迭代。AI 把第三段的成本压得很低，前后五段还在。Builder 要走完全程。

产品经理和程序员各自只会其中几段。产品经理会前两段，到了开发实现、发布上线就要找人；程序员会中间三段，到了需求分析和运营迭代就容易凭感觉。这本书站在 Builder 的位置，把六段放在一起讲，产品、运营、设计的读者补上开发和上线，程序员补上产品和运营。

这本书教的是思维，工具只是手段

我写这本书的时候用的是 Claude Code 和 Codex。等你读到的时候，这两个工具可能已经更新了版本，或者被别的工具取代。所以每一章开头都放一条方法论，用一个公式或者一句话写出这一章的主要观点，并注明出处。方法论跟着产品设计和软件工程的道理走，工具换了也不会过时。工具怎么安装、怎么使用，放在第 4 章和模板仓库（PM-Shawn/abu-harness）里，随时更新。

每一章的结构是固定的：开头一条方法论；接着用大白话讲怎么做、为什么这样做；然后是案例，正例是照着做而做对了的，反例是没照着做而出了问题的，全部来自我做过或者亲眼见过的事；再往后是一份可以直接复制给 AI 的模板；最后点出两三个对应的专业概念和出处，不展开。你赶时间的话，每章只读方法论和模板也能用。

讲 AI 编程的书大多只教工具怎么用，或者只覆盖从想法到产品的其中一段：有的讲变现但缺产品设计和工程，有的有真实产品和模板但缺界面和运营，有的这几块都讲但都很浅。免费的开源教程已经把入门的内容覆盖得很好，它们是这本书入门篇最直接的替代品，我也推荐你去看。这本书想把产品设计、界面交互、开发、运营四块放在一起讲，面向没有技术背景的读者，每一步都有一个真实产品半年的原始记录作证，每一章都有一条有出处的方法论。

Builder 要具备的能力

五项能力里，产品思维和判断对错最难交给 AI，技术常识最容易被误以为必须自己学会。写代码你可以不会，只要知道软件由哪几块组成，就能看懂 AI 做了什么。

这五项不需要你一开始就全部具备。入门篇里每一项只要求做到“够用”：产品思维够用到能写出一条用户故事，和 AI 协作够用到能在一个窗口里把一件事做完，判断对错够用到能按清单亲手验收，技术常识够用到知道前端、后端、数据库各是什么，持续运营够用到能收集第一批反馈改出第二版。进阶篇再把每一项做深。我自己也是这样过来的：先把阿布（我做的桌面 AI 助手）的第一版做出来，再在后面半年里把每一块补齐。

这本书的路线图

全书按软件从想法到用户手里的六个阶段组织。运营迭代收到的反馈又回到需求分析，这是一个循环。

flowchart LR
  A[需求分析] --> B[产品设计]
  B --> C[开发实现]
  C --> D[测试验收]
  D --> E[发布上线]
  E --> F[运营迭代]
  F -->|用户反馈| A

入门篇用 Bentoly（一个让别人也能生成自己主页的网站）把六个阶段走一遍；进阶篇用阿布把每个阶段做深；实践篇在另外四个方向上各走一遍：浏览器插件、微信小程序、电脑客户端（下面叫桌面软件）、手机 App。下面的表在六个阶段前后各多一行：开工准备和复盘改进。

读完能做到什么

读完入门篇，你能把一个想法写成用户故事、画出原型，交给 AI 做出来；能看懂 AI 做了什么，并检查它做得对不对；能把产品上线，让身边的人用起来，并根据反馈改出第二版；知道这个产品将来可能由谁来付钱。入门篇读完是一个完整的终点，很多人到这里就够了。

读完进阶篇，你能搭好一套研发 harness（套在 AI 身上的一整套规矩和检查），让一队 Agent 按规矩干活；能在睡前把任务交代清楚，第二天早上按清单验收；能让产品有真实用户、长期迭代、不出大事，并找到让它养活自己的方式。

我是谁

我是产品经理出身。B 端、C 端都做过，国内外的百万级项目交付过不少，做过商业化广告产品和数据产品，现在主要做 Data AI 这个方向。运营这一块，我从零做过出海产品，用 AI 编程做的工具在 Product Hunt 上拿过日榜第一。

AI Coding 我投入了 1200 小时以上，做过 30 多个小工具。阿布是我近期最重要的一个产品：7 天做出第一版，3 个月迭代到别人能用，之后半年持续发版，有企业付费用户。我为这套方法花了几万元、用了半年。

做阿布的这半年，我和 AI 的协作方式也变了好几次。开头我只开一个窗口，一件事一件事地和 AI 聊；后来我同时开几个窗口，每个窗口做一条线；再后来我睡前写一份任务书，让两个 AI 会话通宵干活，我早上按清单验收。每一次变化都是被问题逼出来的：它忘了昨天的决定，它说做完了，实际上没做完，它一条命令把文件恢复成了旧版本，它换了一个地方，把同一种错犯了第三次。每遇到一个问题，我就定下一条规矩。那些规矩现在有三百多条，一半写在项目手册里，一半做成了机器检查，会随书全部公开。

这本书来自我把 AI 放进真实产品开发流程里的经历。每一章的方法论都有出处，每一个案例都是我做过或者亲眼见过的事，踩过的坑我也原样写了出来。

这本书怎么读

入门篇从头读到尾，读完可以停下，等产品需要时再读进阶篇。进阶篇和实践篇可以按需要跳着读，进阶篇每一章开头都有一句“什么时候读这一章”。

程序员读入门篇时可以快速翻过开发实现的部分（第 12 到 16 章），重点读需求分析（第 5 到 8 章）、产品设计（第 9 到 11 章）和运营迭代（第 19 章）。产品、运营和设计的读者正好相反，需求和设计的部分你可以读快一些，第 12 到 18 章请慢慢读，那是你过去最依赖别人的一段。

不管你是哪一类读者，第 1 到 4 章请完整读。这四章讲的是为什么很多人做不出产品，AI 是一个什么样的同事，人和 AI 怎么分工，以及把工具安装好。

然后，Just Build It。