夜雨聆风一个老朋友、一杯凉了的咖啡、一份被反悔的股权协议——和我后来想清楚的事。
开场: 老朋友的那顿饭
前阵子和一位老朋友吃饭——技术出身, 在阿里待了七八年, 出来后在一家创业公司当工程合伙人。三杯啤酒下去, 他把手机翻过来给我看一段对话, 是几天前他和自己合伙人在咖啡馆见面后留下的。
对方原话:
"老哥, 现在 Claude Code 都能直接写完 SaaS demo 了, 我们之前说的那个股权比例, 是不是有点高了? 你看现在普通人都能上手, 这个东西的技术门槛, 没有那么稀缺了对吧?"
朋友当时没接话, 端着咖啡, 看着对面这个比他年长几岁、当过几年大厂产品负责人的"创业合伙人", 突然意识到——对方完全搞反了。
桌上摊着他们几个月前打印出来、各自签了字的合作意向书。两位数的工程合伙人股权, 是对方主动开的, 当时还用了一个词——"工程师是项目的命门"。
几个月过去, "命门"变成了"普通人都能上手"。中间发生的唯一一件事是, Anthropic 又发了一版 Claude Code, 推特上多了一批人晒"我用一晚上做了个 SaaS"的截图。
朋友讲完, 我端着自己那杯凉了的茶, 沉默了很久。
那顿饭回家的路上, 我把这件事一层层想清楚——坦白说, 我不只是在帮朋友想, 我是在替自己想。朋友的处境, 也是我未来某天可能要面对的处境——做了十年技术管理, 一直在判断"和谁合伙、给什么价"。朋友讲的那段话, 是发生在他身上的, 但激起我思考的, 是它对我自己的意义。
接下来这一整篇, 第一人称的体悟、判断、下注, 都是从这个代入开始的——朋友是引信, 但弹药、推理、责任, 全在我自己身上。
而且我意识到, 这种"用 AI 工具进步给工程合伙人压价"的话术, 我最近三个月已经从其他几位工程师朋友那里, 听到了不止一次:
AI 编程, 让工程师变贵了, 不是变便宜了。而 80% 的非技术合伙人, 正在用旧公式给新世界定价。
下面这篇, 是我对着朋友的亲历、过去三个月听到的几个类似版本、九个 OPC (One Person Company) 案例, 把这件事彻底想清楚之后, 第一次写出来。
可能我错了。但你比我更可能错。
第一幕: 非技术合伙人的 AI 焦虑
一、 同一个错觉, 我在三个月里听到了四遍
朋友那段对话拆开看, 让我背脊发凉的不是对方要砍他股权, 而是对方说话时的"自然"——他真的觉得自己在帮朋友"对齐市场"。
更诡异的是, 这不是孤例。
过去三个月, 我从几位工程师朋友那里, 至少听到了四个版本类似的对话——四位非技术背景的合伙人, 在某个时间点对自己的工程合伙人说过几乎可以互换的话:
• 一位是 SaaS 方向的资深产品 (就是开场朋友的合伙人)。 • 一位是消费类硬件出身、想做 AI 硬件的连续创业者。 • 一位是金融背景、转做 To B Agent 的早期发起人。 • 一位是大厂出身、攒局做行业大模型应用的合伙人。
他们的开场白几乎可以互换:
"现在 AI 都能写代码了, 工程师的成本应该降下来了吧。""你看 AI 编程 / Claude Code / Codex 这些工具, 一个人能顶以前一个团队。""我朋友圈那个独立开发者, 一个月做了三个产品都上线了, 这个技术门槛是不是已经不存在了?"
每一句单独看, 都"挺有道理"。合在一起看, 就是同一种焦虑的不同变体——他们看着 AI 编程工具一周一个版本地往前跑, 心里反复打同一个算盘:
"如果工程师做事情变得更快了, 那我给工程师的股权 / 工资, 是不是该往下压一压?"
我能理解这种焦虑。AI 工具的进步速度确实让人眩晕, 任何一个非技术背景的人, 看到推特上每天都有人发"用 AI 一晚上做出一个产品"的截图, 都会本能地重新评估"工程"这件事的稀缺度。
但他们的算盘, 算错了一个最关键的变量。
二、 他们的逻辑链, 哪一步错了
把这四位非技术合伙人的推理拆解出来, 大概是这条链:
AI 写代码越来越强 ↓"代码"作为产出, 边际成本趋近于零 ↓工程师的劳动被工具替代 ↓工程师作为"生产要素", 议价能力下降 ↓所以: 工程合伙人的股权 / 工资 / 估值, 应该向下重估这条链上, 第一句是事实, 第二句也大致是事实, 第三句开始, 已经偷换了概念。
偷换在哪?
他们把"写代码的成本"当成了"做出可商业化产品的成本"。
写代码, 是这条价值链上最显性、也是最容易被 AI 替代的一环。但一个能稳定收钱、不被骂、不出事故、能扩展、能合规的产品, 它的总成本里, "写代码"这一项, 大概只占 5-15%。
剩下那 85%, 是什么?
• 是知道该写哪段代码——需求识别、问题拆解。 • 是知道该不该写——架构判断、技术选型、债务管理。 • 是写完之后让它撑住真实流量——性能、稳定性、可观测性。 • 是出事故时有人能在凌晨三点上线扛住——SRE、应急、根因定位。 • 是产品长大之后不被监管打死——合规、安全、数据治理。 • 是让所有这些事情, 在一个组织里持续运转——工程文化、招聘、传承。
AI 编程工具今天最强的能力, 是把第一项 (写代码) 的成本, 往下压了 50-80%。剩下那 85% 的工作里, AI 能帮上忙的地方, 大多是让懂行的人更快, 而不是让不懂行的人也能做。
这就是那句话的核心:
AI 编程的进步, 抹平的是"写代码"的能力差距; 放大的是"懂工程"的能力差距。
三、 一组让人清醒的数字
为了让这件事不停留在直觉, 我用自己过去几年带过的项目、加上 OPC 案例库里的真实数据, 算了一组对照:
注意右边那一栏: 越往商业化的深处走, AI 能帮你压缩的成本比例, 反而越低。
因为越深的工程, 越是"判断、协作、责任"的工作, 这些恰恰是大语言模型今天还啃不动的部分。
那位想砍朋友股权的合伙人, 他眼里看到的, 是第一行——demo 一周, 几乎零成本。他没看到, 也不愿意看到, 是后面三行。
他不愿意看到的原因也很简单——如果他承认后面三行存在, 他就得承认, 自己作为非技术合伙人, 在这个项目里的真实贡献度, 远没有他自己估算得那么高。
这是这场认知错配的第一层根因: 不是 AI 工具骗了他, 是他需要 AI 工具的进步, 来给自己的认知打一个台阶, 把工程合伙人的估值往下压一压。
小注: 这一段我可能错了。也许那位合伙人真的只是在做"理性的市场再定价"。6 个月后回来看, 如果非技术背景的合伙人仍然能用"低于一年前的股权水位 + AI 编程工具进步"的话术, 招到合格的工程 CTO, 那我承认, 是我把这件事看重了。我赌的是反面。
第二幕: 工程师视角的真相
一、 需求挖掘的真相——它从来不是"想"出来的
主流叙事是这样的:
好产品来自深度用户洞察。产品经理通过用户访谈、市场调研、竞品分析, 把用户没说出口的需求挖出来, 再让工程师去精准实现。
这套叙事, 是过去十五年互联网产品方法论的"圣经", 也是无数 PM 岗位的存在基础。
我从不否认它在用户群清晰、市场成熟、迭代周期长的场景里 (比如成熟互联网产品的优化), 这套打法确实有效。
但今天我们讨论的, 是早期产品、新方向、新人群——也就是绝大多数创业项目真正面对的局面。在这种局面下, 真相是冷酷的:
真需求是试错试出来的, 不是想出来的。
这不是一句鸡汤, 是一道数学题。
工程师 + AI 的速度
我自己最近做过几个小测试。利用每周末和晚上时间, 用 Claude Code + 我熟悉的技术栈, 尝试快速做"小产品", 验证一个市场假设。
数据:
• 平均一个完整可用的 demo (前端 + 后端 + 部署 + 基本数据): 3-5 天 • 一个月做出来 5 个不同方向的 demo • 单个 demo 在我个人朋友圈/小红书/X 试投流, 跑出"被人愿意付钱"信号的概率: 10-15%
按这个节奏, 一个工程师一个月可以做 5 个 demo, 半年试错频次能到 20-30 个。
产品经理 + 外包团队的速度
对照组: 一个典型的"非技术合伙人主导 + 外包工程师执行"的早期团队。
我观察过的 3 个真实案例 (匿名化):
• 平均一个 PRD 从"想法"到"可上线产品": 2-3 个月 • 同样 6 个月, 这种团队最多迭代 2-3 个方向 • 单个产品的"跑通"概率: 30-40% (因为前期调研更深)
乍一看, 这种团队的"单次命中率"似乎更高——前期想得更清楚, 命中率自然不低。
但你要把这两个数字放回经济账里看:
| 20-30 次 | 2-3 次 | |
试错频次差了一个数量级。我不打算给你一个精确的累计命中率, 因为试错并非完全独立 (同一个圈层投放会疲劳, 同一类需求会越试越偏), 但数量级的差距, 任何理性的人都看得到——而且经济账更扎心: 单次命中的成本只有对照组的 1/20 到 1/40。
这就是为什么我说主流叙事在 AI 编程时代失效了——它假设的前提 ("做一个产品很贵, 所以要提前想清楚") , 在 AI 编程把"做出来"的成本压低之后, 根本不成立了。
在试错成本足够低的时代, "想清楚再做"是一种昂贵的奢侈品; "做出来再说"才是新的最优策略。
而"做出来再说"这条路, 天然偏向工程师, 而不是依赖翻译的合伙人组合。因为它要求执行链条上没有"翻译"环节。
诚实声明: 上面这组对照, 我故意挑的是"工程师 + AI 的高产能" vs "非技术主导 + 外包工程师的低效组合"。我不是不知道还有第三种——"非技术合伙人 + 工程合伙人 + AI"。这种组合在 demo 阶段是有竞争力的。我攻击的不是这种组合, 是其中 "用 AI 工具进步给工程合伙人压价" 的那一类。后面会再讨论。
二、 demo 到商业化的死亡谷, 才是真正的鸿沟
如果你觉得上一节我在贬低产品经理的价值, 那这一节会让事情变得更复杂——也更接近真相。
因为我接下来要说的是: 就算"非技术主导 + 外包"团队真的命中了一个方向, 他们大概率也走不到下一关。
那一关, 我叫它"demo 到商业化的死亡谷"。
死亡谷里有什么
一个 demo 跑通, 拿到了第一批种子用户的付费意愿。你以为后面的事情是"复制粘贴, 把用户做大"——错。
后面要解决的, 全是工程问题:
• 性能: 100 用户和 10000 用户, 系统设计完全是两件事。你以为 AI 能帮你重构? AI 能给你的, 是建议, 不是判断。 • 稳定性: 第一次半夜出事故, 谁上线扛? 工程合伙人。第二次, 第十次。SRE 不是工种, 是责任。 • 合规: 数据怎么存、用户协议怎么写、跨境怎么走、未成年人怎么过滤——每一个都是雷, 每一个都需要懂工程的人判断"该不该写、写在哪一层"。 • 计费: 你以为接个 Stripe 就完事了? 退款、对账、税务、欺诈、订阅生命周期——这一套东西, 一个有经验的工程师能两周搞定, 一个 PRD + 外包工程师的组合, 大概率两个月还在打补丁。 • 客服与可观测性: 用户投诉一个"我的数据丢了", 你能不能在 5 分钟内定位到是哪一行代码、哪一条日志、哪一个时间点的问题? 这不是产品力, 是工程力。 • 灾备: AWS 一个区域挂了, 你的服务是回滚 5 分钟, 还是回滚 5 天?
每一项, AI 都能"辅助"。但每一项, 都需要一个能拍板、能负责、能凌晨三点上线的人。
这个人, 不是 PRD 写得最漂亮的那个人。
我亲眼见过的三次失控
过去两年, 我至少观察过 3 个"非技术合伙人 + 外包工程师"组合的项目, 从 demo 跑通走到死亡谷, 然后死在那里。
模式惊人一致:
1. 前 3 个月: 非技术合伙人主导, 想法清晰, 外包工程师按 PRD 干活, demo 上线, 拿到第一批用户。 2. 第 4-6 个月: 用户增长, 系统开始抽风, 合伙人找外包工程师要"修一下", 外包工程师以"不在合同范围"或"需要追加预算"为由拖延。 3. 第 6-9 个月: 合伙人决定换团队 / 自建团队。换团队意味着代码交接, 但外包工程师交接质量差; 自建团队意味着重新招聘, 而能扛住这个阶段的工程师, 不会接受小股权进场。 4. 第 9-12 个月: 项目要么停摆, 要么被资方接管重做, 原合伙人出局。
这 3 个案例总投入加起来超过 500 万人民币, 时间累计超过 30 个月, 最终活下来 0 个。
小注: 这是"外包工程师"模式的特定结构性问题, 不是"非技术合伙人"这个身份的原罪。一个非技术合伙人如果一开始就配了真正的工程合伙人 (而不是甩单给外包), 这套失控点是可以避免的。我攻击的是结构, 不是身份。
而这个失控点, 工程师独立项目根本不存在。因为工程师自己就是那一关——没有翻译、没有合同、没有外包工程师的"不在合同范围"。
这就是为什么 OPC 案例库里, 9 个年入百万-千万的小公司, 全是工程师独立运营——后面第三幕会展开讲, 也会承认这个数据本身的样本偏差。
三、 AI 加持的边际收益, 两边差出一个数量级
我们再回到最关键的那个问题: AI 编程工具的进步, 给两类组合带来的边际收益, 到底是多少?
我的估算 (基于自己使用 + 观察其他人的使用):
| +10% ~ +20% | ||
| +200% ~ +500% |
为什么差这么多?
因为 AI 编程工具的本质, 是给"懂工程的人"的杠杆, 不是给"不懂工程的人"的拐杖。
杠杆和拐杖的区别在于: 杠杆是放大已有的力量, 拐杖是补足缺失的能力。
AI 编程能放大工程师的力量 (因为工程师本来就有判断、有架构、有调试、有责任意识, AI 帮他把"打字"这件事压缩); 但 AI 给非技术团队的"补足", 只能补到 demo 这一层, 死亡谷之后的能力, AI 补不了——那一层需要的不是代码生成, 是工程判断。
这就是为什么 OPC 时代的成功案例里, 工程师比例显著偏高 (后面给数据)。
也是为什么, 那位想砍朋友股权的合伙人, 算盘打反了。
第三幕: OPC 案例对比——不是我说的, 是数据说的
如果你觉得上一节我对非技术合伙人太刻薄了——别急, 让数据说话。但在数据之前, 先把数据本身的局限性说清楚。
零、 先承认这个样本怎么来的 (重要)
过去六个月, 我有意识地追踪了一个我命名为 "OPC (One Person Company)" 的小样本。筛选标准:
1. 独立创始人, 没有合伙人。 2. 主营业务以 AI 编程工具为生产力核心。 3. 年化收入 100 万人民币以上, 或月活付费用户 500 以上。 4. 创立时间不超过 24 个月。
最后我攒到了 9 个相对完整的案例 (来源: 朋友圈、推特、独立开发者社区、私下交流)。
这个样本有两个明显的偏差, 我必须先承认:
1. 筛选条件 #2 自带偏向——"以 AI 编程工具为生产力核心"这一条, 天然更容易筛出工程师。这不是我作弊, 但我承认: 我没有去找"以 BD / 设计 / 商务为核心"的成功 OPC 来对照——如果你能给我推荐, 我会乐意补进下一版。 2. 没有分母——我数过的是"已经跑通的工程师 OPC", 没数"试图做 OPC 但失败的工程师"。失败率我自己估算大概在 70-80%, 也就是说 9 个成功的背后, 可能有 30-40 个失败的工程师 OPC, 但失败者不发推特, 我看不到。
所以下面这张表, 能说明"成功的 OPC 长什么样", 不能直接证明"工程师必然比非技术更适合 OPC"。我会在解读时尽量克制。
一、 9 个 OPC 的共同画像
| 9/9 都是工程师 | |
| 9/9 无合伙人 | |
| 0/9 配置专职 PM | |
| 8/9 未融资 | |
| 9/9 都做了 3-10 个小产品 |
这张表里, 最值得看的不是收入数字, 是那一列 "9/9 都是工程师"。考虑到样本偏差, 我不会用"90% 的成功 OPC 都是工程师"这种话——但 "在符合上述筛选条件的成功样本里, 工程师占比是 100%" , 这是事实, 你可以自己解读。
更进一步, 我去问了其中 4 位 (有交集), 同一个问题:
"如果你当初拉了一个产品经理或商务合伙人, 给对方 30-40% 股权, 你觉得现在你的项目会更好还是更差?"
4 个回答, 4 个"更差"。理由出奇一致:
• "试错速度会被开会拖慢。" • "我现在一个月迭代 4 次, 加合伙人之后估计 2 次都不到。" • "我自己懒得跟人沟通, AI 不会跟我吵架。" • "产品方向我自己摸出来的, 当时如果听 PM 的, 早死了。"
注意最后一条——"产品方向我自己摸出来的, 当时如果听 PM 的, 早死了"。这印证了第二幕里那个论点: 真需求是试错试出来的, 不是想出来的。
二、 对照组: 非技术合伙人 + 外包工程师的死亡名单
为了不偏听一面, 我把第二幕里提到的 3 个失败案例, 也补充了一些细节 (匿名化处理, 不指名):
总投入超过 530 万, 时间累计 44 个月, 活下来 0 个。
我不是说所有"非技术主导 + 外包"的项目都会死。我只是说: 在 AI 编程让"做 demo"的成本急剧下降之后, 这种组合的相对竞争力, 已经从"可行选项"掉到了"低概率赌博"。
而对面的工程师 OPC, 用 1/20 - 1/40 的成本, 跑出了 1-50 倍的现金流。
这两组数字摆在一起, 还有什么好说的?
三、 这意味着什么——给两类人的不同信号
给工程师:
如果你有工程判断力 (注意: 不是"会写代码"那种工程师, 是能扛系统、能扛事故、能拍架构板的那种), 这是过去十年最好的时间窗口。
不要再用 2018 年的旧公式给自己定价——"小股权 + 跟着非技术合伙人冲"。那个时代结束了。
你现在的真实选项是:
1. 自己做 OPC, 用 AI 编程加杠杆, 一个月试 3-5 个产品, 6 个月找到一个跑通的。 2. 接合伙人 offer 时, 把工程合伙人股权底线显著抬高——具体多少, 看项目处在哪一阶段 (文末附了一张分档参考表, 我把推导过程算给你看)。 3. 拒绝所有把"AI 让工程师变便宜"当作降股权理由的合伙人——这是认知错配的信号, 不是市场再定价。
给非技术合伙人:
你的窗口期正在关闭。
不是说你没机会了, 是说你过去那套"我出想法 + 找工程师执行"的打法, 已经在 AI 编程时代失效。要在新时代活下来, 你只有两条路:
1. 自己学工程, 至少到能判断的程度 (不需要会写, 但要能看懂、能选型、能拍板)。 2. 接受工程合伙人是真合伙人, 给出反映新市场水位的股权——上面那张分档表, 反过来对你也成立。
第三条路——"用 AI 工具威胁工程师降股权"——这条路已经走不通了, 只是大多数人还没意识到。
第四幕: 那顿饭之后, 我想清楚了三件事
写到这里, 我意识到这篇文章如果只停留在分析, 它就只是另一篇"AI 时代如何如何"的观察文。我自己最讨厌这种——道理一堆, 不下注。
所以这一节, 我把那顿饭之后我自己想清楚、并且开始付诸行动的三件事写出来。全是要付代价的判断。
一、 我给朋友的建议
朋友吃完那顿饭, 让我帮他看看怎么处理。
我当时给他的建议, 大意是:
你们几个月前签的工程合伙人比例, 是基于"工程是项目命门"的共识。AI 编程工具的进步, 让"工程"这件事的真实价值变得更高, 不是更低。如果对方坚持要按"AI 让普通人都能上手"的逻辑重估, 那你们的认知差距已经拉得太大, 我建议你直接终止合作, 各自安好。沉没成本忍住, 比未来一年继续被压价划算。
朋友听完, 沉默了一晚。第二天告诉我, 他发了一条类似的信息出去。对方第三天回了一句"我们再聊聊"。他没回。
这个项目, 就这样停在了那里。沉没成本是个不小的数字, 时间成本一年。
我可能错了。也许 6 个月后, 对方换了一个工程合伙人, 用 AI 编程做出了一个不错的产品, 给那个新合伙人 5% 的股权——如果那一天真的来了, 我承认是我对市场的判断错了。我赌它来不了。
附录: 工程合伙人股权分档参考表
上一节给出了"拒绝"的信号，但工程师朋友们更常问的问题是："那我该要多少？"
我不打算给一个"35-50%"的数字然后甩给你。这个区间在不同阶段差距很大，我按自己见过的项目分四档，算给你看。
先把前提条件说清楚——这张表针对的是这种情况：
非技术合伙人只出想法、不出资、不带客户、不全职投入，由工程合伙人全职扛产品落地。
如果非技术合伙人出资（按出资额折算）、自带种子客户（按 LTV 折算）、全职投入（按市场薪资折算），那么"想法贡献"之外他还有别的筹码——分档表的工程方占比应相应下调。说白了，工程合伙人不应该被压价，但也不该把别人的真实贡献当成空气。
| 0 → demo | 30-45% | ||
| demo → 第一批付费 | 25-35% | ||
| 已收入 → 找 PMF | 15-25% | ||
| 已融资 → 规模化 | 5-15%（期权 + 加速归属） |
这张表不是教条，是我用过去 5 年里观察到的项目"反着算"出来的水位——用项目存活率倒推，而不是用合伙人和气倒推。
关键不在那个具体百分比，在于：如果你处在前两档、前提条件成立，而对方给的数字停留在"旧公式"那一列，这是一个底层操作系统不兼容的信号，不是谈判技巧能解决的问题。
二、 我给自己设的过滤器
朋友的事情让我意识到, 这种话术不只是个例。所以我给自己设了一条原则, 挂在任何未来合作意向的入口:
凡是把"AI 让工程师变便宜"当作压低工程合伙人股权 / 工资的逻辑, 我个人坚决反对——不管是朋友咨询, 还是未来某天自己面对类似选择。
不是傲慢, 是过滤器。
我对一个朋友这样解释: "如果对方在这一点上的认知和市场严重脱节, 那么后面所有的产品判断、招聘判断、节奏判断, 大概率也是脱节的。这不是一次谈判的问题, 是一个底层操作系统的问题。"
朋友问我: "那不怕错失机会吗?"
我说: "在这个时代, 错失一个糟糕合伙人, 不叫错失机会, 叫节省时间。"
三、 我给自己的下注
接下来 6 个月, 在主业 (一个我深度参与的硬件项目, 这里不展开) 之外, 我也想亲自验证一下"工程师 + AI 杠杆"到底有多大。
不当任何非技术合伙人的杠杆。不用我的工程能力, 去补别人认知的洞。
这第三件事, 是写给我自己的。但我把它放在公开版本里, 是因为——我希望 6 个月后, 你们能回来打我的脸或者拉我去吃饭。
可证伪, 是这篇文章对自己的最后一道闸。
结尾: 给可能反驳我的人
写到这里, 我已经能想到至少四种反驳的声音。先替你们说出来, 再一个一个接住。
第一种: "你只是被朋友的故事激起了情绪, 在这里替别人出头, 凑数据撑结论。"
对。一半对。这篇文章的情绪起点, 确实是那杯凉了的咖啡——只不过端着它的是朋友, 不是我。但情绪只是引信, 数据和案例才是弹药——9 个 OPC 案例 (我已经承认了样本偏差)、3 个死亡案例、一组从 demo 到百万用户的成本对照表、一张股权分档表 (我也写清了前提条件)。你如果觉得这些不足以支撑判断, 请拿出反向数据, 我马上改稿。
第二种: "AI 编程还在进步, 再过两年, 工程师真的会被替代。"
也许。但被替代的, 是只会"打字"的工程师, 不是有工程判断力的工程师。架构判断、事故定位、合规拍板、组织搭建——这些事情上, 大语言模型今天的进步速度, 比代码生成慢了一个数量级。除非哪一天 AI 能在凌晨三点上线扛事故并对结果负责, 否则这条护城河只会越来越深, 不是越来越浅。
我承认这个分类有"无回路"的嫌疑——什么算"有判断力的工程师"? 边界确实是滑的。但市场上的工程师朋友们大概都知道, 自己属于哪一类。
第三种: "产品经理这个职业, 比你说的复杂得多, 你在贬低一群人。"
这一条我特别想接住, 因为我打的不是产品经理。
我打的是"用 AI 工具进步给工程合伙人压价"这个具体行为, 而做这个行为的人, 大多数恰好不是真正合格的产品经理, 而是 "想法发起人 / 资源整合者 / 攒局者" 自称合伙人。一个真正懂工程、会判断、能拍板的产品负责人, 在 AI 时代比以前更稀缺、更值钱——他们和我反对的那群人, 是两个物种。
如果你是一位真正的好 PM, 这篇文章不是骂你。如果你被骂到了, 你大概要想一下, 我说的是不是恰好戳到了你不愿意承认的地方。
第四种: "你在没有真正下场赚钱的时候, 写一篇文章把责任推给市场。"
这一条最狠, 也最值得我接住。所以第四幕那三件事, 不是分析, 是下注: 提供过滤器给朋友、对自己设原则、亲自下场试错。
我愿意为这篇文章的判断负责。
可能我错了。但你比我更可能错。
我们 6 个月后见。
如果你也在判断"这个合伙人值不值得跟"，或者你是工程师、正在重估自己的定价——
留言告诉我你在哪个阶段，我在下一篇里会专门回这个问题。
也可以直接转发这篇给你觉得"认知还停留在旧公式里"的朋友。有时候一篇文章，比你说一百遍管用。
📌 下一篇预告：「OPC 案例库」里那 9 个工程师独立创业者——他们具体用什么 AI 工具栈、怎么找到第一批付费用户、最大的认知拐点发生在哪一刻。没有方法论，只有真实玩法。
关注「Leo 的 AI 机器人进化论」，10 年机器人 CTO，硬核实战分享。
