从 Engineer 到 Builder：AI 时代的一人公司与产品思维

在上一篇关于生成式 AI 的文章里，我写过一个判断：AI 不会简单终结工作，它更可能先改变任务分工，再催生更多需求。对程序员来说，代码、文案、资料研究、设计草稿和 demo 都变得更便宜。结果未必是工作减少，而是个人可以更快试做过去没时间或没能力完成的想法。

这篇文章中的问题也可以和Model Is Good Enough：2026 年，AI 真正稀缺的是应用而不是更大的模型、从设计师到 Agent Builder：看、做、想放在一起阅读，以比较相近的概念如何在不同语境中展开。

一个例子：随着 Coding Agent 或者说 LLM 变得越来越强，我更经常的感觉某个项目或者工具不让我满意，总想自己去进行一些自己喜欢的修改。我个人所关注的项目，在解决的问题数量也愈发膨胀。而 2024 与 2025 年的前半年，这些想法恐怕不会出现在我的脑海里。It is too hard for me to solve it.

传统意义上的 Software Engineer 正在向 Builder 靠近。过去的软件工程被组织分工定义：产品定需求，设计定交互，工程师负责实现，测试负责质量，运营和销售负责触达用户。工程师多数时候是在解决别人已经定义好的问题。

AI 扩大了个人能够独立完成的工作范围。一个工程师现在可以借助工具处理部分研究、设计、开发和运营任务，先跑通一条规模较小的产品链路。这里所说的 Builder，是能够选择问题、做出产品、找到用户并根据反馈继续调整的人，而不只是写出更多代码的人。

代码变便宜后，工程师的价值前移

Anthropic Economic Index 观察到，AI 的使用主要集中在软件开发、技术写作等认知任务上。现阶段，它更多是在改变具体任务，而不是一次替代整个职业。Google DORA 2025 也指出，AI 工具的收益与团队原有的协作方式、反馈机制和质量标准有关。工具可以加快执行，也可能让已有的流程问题更快累积。

Microsoft 2026 Work Trend Index 描述了一种新的组织分工：AI 和 agent 承担更多执行，人类负责意图、判断、质量标准和工作设计。放到个人开发者身上，这意味着许多判断需要更早发生。写代码之前就要考虑什么值得实现、谁会使用、怎样验证，以及第一批用户从哪里来。

一个能跑的 demo 不是产品。AI 让 demo 更便宜，也让人在错误方向上快速堆出更多产出。过去做错方向至少很累，现在一个周末就能做出漂亮但没人要的东西，这反而要求工程师更早接触用户和市场。

OPC：一个人的最小公司系统

这里的 OPC 不是法律概念，而是本文使用的一种工作定义：由一个人负责选择问题、定义产品、维护用户关系和管理收入，把部分执行工作交给 AI 与外部服务。自由职业通常按时间或项目交付，OPC 则试图经营可以重复销售或交付的产品，例如软件、插件、模板、内容产品、自动化服务或垂直工作流。

“一人独角兽”的说法很吸引人，它假设一个人可以借助 AI 完成开发、设计、内容、客服和数据分析。但工具链还不能无成本复制完整组织。对大多数人来说，更现实的起点是做出一个能够持续维护和收费的小产品，而不是先追求独角兽规模。

更明显的变化发生在公司职能上。开发、设计、客服、部署、支付、分发和数据分析中的一部分工作，可以交给 AI、自动化、SaaS、云服务、外包或平台市场。创业者不必在第一天搭出完整组织，可以先找到用户和问题，再按需要接入这些能力。

一个 OPC 要逐步建立四项能力。首先是明确服务对象和具体问题；其次是用软件、模板、自动化或内容产品重复交付；然后要有价格、付款方式和续费或复购理由；最后还要持续查看使用、留存、退款、客服和转化数据。早期产品不一定同时具备所有能力，但长期缺少收入或反馈机制，就很难成为可持续经营的业务。

普通工程师更容易从范围较窄的产品开始，例如微型 SaaS、浏览器插件、开发者工具、行业模板、自动化脚本，或把内部反复使用的工作流做成外部工具。选题时先看一个具体人群是否反复遇到同类麻烦，以及产品能否持续替他们节省时间或成本。

支持成本较低、容易自动化、交付方式稳定，并且有明确获客入口的业务更适合小团队起步。AI 可以推迟扩张组织的时间，却不会消除现金流、维护、信任、获客和合规问题。工具减少了执行成本，需求是否存在仍要单独验证。

反过来说，并非所有业务都适合一开始按 OPC 来做。高客制化交付、重销售、强合规、重客服、长实施周期，或者依赖大规模网络效应的业务，都不该被简单想象成“一个人加 AI”就能跑起来。OPC 更适合从窄问题、轻交付、明确入口和可计量收益开始。

产品思维：先找真实痛点，再写更多代码

对传统程序员来说，困难往往出在问题选择。工程师很容易从新框架、强模型或漂亮架构出发，再寻找一个可以套上去的产品。用户通常不为技术的新颖程度付费，他们在意的是产品能否节省时间、降低成本、增加收入或减少麻烦。

Marc Andreessen 在 “The only thing that matters” 中讨论 product-market fit，提醒创业者优先确认市场需求。需求明确时，不完美的产品仍有机会继续改进；需求不存在时，技术实现得再优雅也很难创造用户。AI 让 demo 更容易制作，也让团队更容易在错误方向上快速增加投入。

Builder 在开始开发前，需要先确认谁遇到了什么问题，以及对方是否愿意付钱、花时间或承担迁移成本。先别开 repo。用一页纸写清用户是谁，使用者、付费者和决策者是否是同一个人，现有方案是什么，问题多久出现一次，以及你能在哪里找到第一批访谈对象。写不清这些，再快的开发也只是在扩大猜测。

a16z 曾提出 product-user fit 应该先于 product-market fit。对个人 Builder 来说，先找到几个具体用户比估算一个巨大市场更有用。能够约到访谈、反复听到同一个问题，并获得试用或预付意向，说明产品至少有了继续验证的起点。

从稳定赛道切出自己的小标签

独立开发不一定要从一个 DAU 很大的赛道开始。这里说的“小 DAU”不是用户越少越好，而是先找到一群人数有限、需求稳定、可以被直接触达的用户。他们反复遇到同一种麻烦，已经在为它投入时间、预算，或承担出错成本；只要问题足够高频，或者单次价值足够高，小用户群也能支撑一个长期维护的小产品。

另一个更稳的起点，是从一个已经稳定的大赛道里切出新的 tag。不要凭空创造一个“AI 可以做点什么”的需求，也不必一开始就和通用产品争夺全部用户；先找到已有工作流、已有付费与已有分发入口的领域，再按用户角色、触发时刻和最后的交付物把它切小。大赛道提供需求、预算与共同语言，小标签提供明确的定位，以及能找到第一批用户的入口。

这一步需要市场调研，而不是打开几个竞品网站就算完成。至少要弄清谁实际使用、谁付钱、谁决定采购、谁承担出错成本；他们现在用什么办法完成任务，问题多久发生一次，交付结果是否可验收；以及第一批用户聚集在哪里，为什么愿意给你一次试用或访谈。这里的市场调研本质上也是一次更早的验证：它验证的不是产品能不能跑，而是这个问题是否值得花时间去解决。

模型的下一次升级也要放进这层判断里。它会把你的价值压成一个通用功能，还是让你已有的流程、数据、服务与分发更有价值？AI 让做 demo 的成本越来越低，也让选错问题的代价越来越容易被忽视。

MVP 用来以较低成本验证关键假设，不是简单删减功能。验证时要观察用户现有的解决方法、付费或迁移意愿、第一批用户来源，以及 AI 实际降低了哪部分交付成本。项目还需要提前设置继续和停止的信号。低触达产品可以先用两周观察试用、反馈或付费情况；B2B 或垂直行业的验证周期通常更长，可以用四到六周检查访谈、试点意向和决策链条。这些周期只是起始安排，需要按销售和使用周期调整。

分发应该从选题阶段开始

技术人常把推广留到产品完成之后。这样做的问题是，产品即使能够运行，也可能一直找不到第一批用户。分发方式需要在选题阶段就进入讨论。

对个人 Builder 来说，分发不只指投广告。内容、开源、插件市场、SEO、社群、应用商店、B2B outbound，以及垂直工作场景里的直接触达，都可能带来用户。选择哪种方式，取决于第一批用户在哪里以及他们为什么会信任产品。

一个想法刚出现时，就要检查潜在用户聚集在哪里、通过什么渠道发现产品、为什么愿意试用，以及渠道能否重复使用。如果这些问题完全没有答案，商业模型中就缺少了连接产品和用户的路径。

不同产品需要不同的渠道。SEO 型产品要对应可搜索的问题；开源或开发者工具需要可展示的 repo 和集成场景；插件产品要适配 marketplace；B2B outbound 则需要明确的 ICP 和触发事件。这些条件会反过来影响功能、定价和产品形态。

没有稳定入口，小产品很容易停在本地项目阶段。AI 降低了制作成本，但获得注意力和信任仍然需要时间。

从能力栈到验证系统

Builder 仍然需要工程基本功。系统理解、测试、部署、安全、数据、可观测性、成本控制和长期维护，决定 demo 能否变成稳定服务。AI 可以加快编码，但不能自动保证正确性，也不会替开发者承担用户数据、支付失败、权限泄露和服务中断的责任。

变化在于，工程能力需要进入更早的反馈过程。先接触用户和判断需求，再用最小实现验证，并根据反馈决定继续、收缩或停止。除了 coding workflow，工程师还要练习用户访谈、需求判断和渠道选择。

除了单纯的 Coding, AI 还可以参与访谈摘要、竞品表、落地页草稿、发布文案、客服问题整理和每周指标复盘。把这些任务放进固定流程，比临时向模型索要灵感更容易复用，也能持续降低整理信息和准备实验的成本。

工程师转向 Builder，首先要调整工作顺序：从具体用户开始，用最小实现验证付费场景，并把上线后的使用数据和反馈继续带回开发过程。商业知识可以逐步补，但验证不能等到产品全部完成之后。

OPC 和 Builder 最终都要求个人设计一套最小工作系统。AI 负责部分执行，工程能力保证质量，分发渠道连接用户，MVP 用来验证假设。代码仍然重要，但写出代码只是验证过程中的一个环节。

代码变便宜后，工程师可以把更多时间放在问题是否值得解决、谁愿意使用，以及怎样尽快验证上。从 Engineer 到 Builder，并不是放弃技术，而是让工程能力更早接触用户和市场反馈。

参考资料

• Anthropic, The Anthropic Economic Index
• Google, How are developers using AI? Inside our 2025 DORA report
• Microsoft, 2026 Work Trend Index Annual Report
• Fortune, Could AI create a one-person unicorn?
• Marc Andreessen, The only thing that matters
• a16z, Product-User Fit Comes Before Product-Market Fit
• Blake Masters / Peter Thiel, CS183 notes: If You Build It, Will They Come?
• Lean Enterprise Institute, Lean Startup