老友baojie如是说，字字千钧，全文引用如下：
2026-01-18 vibe it until you make it by西瓜 1、以前创业的哲学是 fake it until you make it, 现在是 vibe it until you make it。 2、code is cheap, show me the talk. 3、以前的软件是祖传屎山，现在是 vibe出来的一夜屎山。 4、你的编程 agent 也是需要你熟悉的你需要和 AI一起待 2000 个小时才能和它成为好朋友，摸清楚它的脾气。这大概需要一年的时间。 5、软件工程的本质是结构化思维。在agent时代，结构化思维的重要性更放大了，优秀的软件工程师真的可以100x，一个打一百个。 6、拆解能力是核心生产力。结构化思维的核心就是拆解能力。 7、品味 Taste 决定产品的天花板，结构化思维决定产品的地板。 8、工程师要培养的核心能力是品味，而不是最某个 SDK 或者框架的 coding 熟悉度。 9、以前的工程师是一个琴师，现在的工程师是一个乐队指挥。 10、工程师有产品思维 vs 产品经理有工程思维那个更难?无论如何，以前产品需求瀑布式开发的流程过时了。 11、持续学习能力将是所有系统的标配。以前的软件数是死的系统，未来所有的软件都是活的。以前是软件，以后是软件体。 12、软件吞噬世界，AI 吞噬软件，大模型吞噬 Al，Agent 吞噬大模型。 13、以后所有岗位的工作都是软件工作大量的“一次性软件”(JIT 软件)和“脚本软件”是文秘岗位创造的。未来 agent办公软件的地位就和现在的 office 系统样，不会使用的人根本找不到工作。 14、人类过去大部分的需求得不到满足是因为生产产品的成本太高。但是现在生产力十倍以上提高了，以前不成立的商业模式现在可以成立了，会涌现大量的新产品。 15、agent 能产生商业价值的转折点生产有效代码的 TCO 成本降低到每小时 1美元，这样低于地球上任何国家程序员的时薪。具有社会破局力量的平衡点是每天成本 2 美元，这是国际贫困线。目前 agent 的成本还是1小时 10~40 美元。两年之内应该可以达到转折点。 16、工作结算的颗粒度会单人化，Paul Graham《如何创造财富》里描述的主要矛盾可以解决了。 17、未来优秀的工程团队不应该超过 10个人。以前公司上市需要 200 个以上工程师，需要配备更多的“管理”和销售人员。现在，同样的工作，工程师只需要<10 个，需要配备的管理人员就可以降低到几个人。 18、超过 10 个人的公司没有 VC 投资价值，因为它们技术过于落后，居然还需要那么多人。 19、传统的公司制度要死了。创造者为什么要需要那些混蛋的不写代码的人。以后所有的管理人员本质上都是软件工程师，公司本身就是一个软件 (不是个比喻)，软件工程这个岗位将吞噬一切岗位。 20、过去公司里大部分的管理任务都是落后的生产力的结果。这些岗位将被消灭。要管理 Al+人的新岗位要出现。 21、人均 100 万美元收入应该是 OPC（One-Person Company）的起步目标。 22、以后的优质企业都应该是 OPC 的集合体。 24、现在的 AI 如同互联网在 1997 年。 25、制约某些地方生产力发展的是落后的生产关系。Agent 就和互联网一样，需要自由，也会创造出新的自由。自由本身是一种生产关系，也是一种生活方式。 26、巨大的生产力进步会把很多糟粕扫进历史的垃圾堆，尽管我们还不能完全预言这个巨大进步的社会学后果，但它一定会发生。
Agent 时代工程师与公司的最小形态
——读〈vibe it until you make it〉的一些结构性观察
一、这篇文章讨论的，是生产组织的最小单位
文章并没有在讨论模型参数、算法路线或工具栈，而是在反复指向一个更底层的问题：
当生产力被 agent 极度放大之后，组织还需要维持原来的形态吗？
作者给出的答案非常明确：不需要。
-
- 团队规模应该持续缩小（<10 人）
- 管理层级本身是落后生产力的副产品
- 公司不再是“人 + 管理”，而是“人 + agent”
这使得“公司”从一个法律/组织概念，退化为一个生产能力单元的集合。
二、OPC 的含义：一种生产单元假设
文中多次出现的“单人公司” (OPC），并非工业、是一种隐含的超级个体生产假设：
-
- 人可以在 agent 的帮助下，承担过去需要一个团队才能完成的工作
- 单个工程师的产出，可以被放大到“公司级别”
- 因此，“人均 100 万美元收入”不是目标，而是门槛
在这个语境中，OPC 更像是：
以超级个体为核心、以 agent 为外延的最小商业与工程单元
这也是为什么作者会反复强调：
-
- 拆解能力
- 结构化思维
- Taste（品味）
这些能力在 OPC 模型中，直接决定单位生产力的上限。
三、工程师角色的转变：从“执行者”到“指挥者”
文中的比喻是：
“以前工程师是琴师，现在工程师是乐队指挥。”
这是在描述一个非常具体的变化：
-
- 执行本身在变得廉价
- 协调、拆解、判断在变得稀缺
- agent 不是工具，而是可并行的“执行层”
在这个结构里，工程师的核心能力不再是：
-
- 写了多少行代码
- 熟悉多少框架
而是：
-
- 能否把模糊需求拆成可执行结构
- 能否判断哪些事情值得让 agent 去做
- 能否对 agent 的输出进行有效校验和组合
四、“熟悉 agent”的含义：长期协作，而非短期使用
原文提到：
和 AI 一起待 2000 个小时，才能摸清它的脾气。
这句话否定了一个常见误解：
用过 agent ≠ 会用 agent
作者强调的是一种长期协作关系：
-
- 固定使用同一类 agent
- 形成稳定的交互模式
- 对其能力边界有直觉判断
这实际上是一种新的“工程熟练度”定义，不再以 API 或语言为中心，而是以协作稳定性为中心。
五、工程思维在 Agent 时代被“放大”
文章明确指出：
软件工程的本质是结构化思维，在 agent 时代这一点被放大了。
这点非常值得强调。agent 并没有消解工程思维，反而：
-
- 放大了架构错误的代价
- 放大了需求不清的后果
- 放大了 Taste 对最终产品的影响
在 agent 加速执行的前提下：
-
- 好结构 → 指数级放大
- 坏结构 → 指数级崩塌
六、这篇文章的隐含前提与现实阻力
需要指出的是，原文隐含了几个前提条件：
-
- agent 成本将持续下降
- agent 的可靠性将持续提升
- 工程师愿意承担更完整的责任闭环
这些前提目前正在成立，但尚未完全成立。因此，OPC 更像是一个正在逼近的形态，而非已经普遍实现的现实。在工程与产品层面，OPC 并非自然演化结果，而是一种高门槛的生产形态。
（1）agent 放大的是“结构”，不是“能力下限”
一个常见误解是：
agent 可以弥补工程能力不足。
但在实践中，agent 的真实作用更接近于：
放大已有能力的杠杆。
-
-
有结构感的人，用 agent 会更快得到正确结果
-
结构混乱的人，用 agent 会更快得到错误结果
-
这意味着：
OPC 对工程师的下限要求其实更高，而不是更低。
（2）执行成本下降，并不等于“决策成本消失”
原文反复强调“代码变便宜”“执行变廉价”，这是事实。但随之而来的，是另一个被低估的问题：
决策密度急剧上升。
当 agent 可以在几分钟内生成：
-
-
多个实现方案
-
多种架构选择
-
大量可运行代码
-
工程师必须承担的，不再是“做不做”，而是：
-
-
选哪一个
-
舍弃哪几个
-
哪些方案不值得继续投入
-
在团队中，这些决策可以分摊；在 OPC 中，它们全部压在一个人身上。
（3）OPC 隐含了“全栈责任制”
传统组织中，责任是被拆分的：
-
-
产品失败 → 产品经理
-
架构问题 → 技术负责人
-
质量问题 → QA
-
节奏问题 → 管理层
-
而 OPC 模型下：
所有失败都会回流到同一个人。
这对工程师提出了一个本质性的转变要求：
-
-
不仅要能写、能想
-
还要能判断“什么时候停”“什么时候不做”
-
这并不是每个优秀工程师都天然具备的能力。
（4）agent 协作的不稳定性，是当前最大的工程摩擦
原文提到“2000 小时熟悉 agent”，是一个非常诚实的判断。
现实中的问题在于：
-
-
agent 行为仍然存在漂移
-
工具链频繁变化
-
上下文长度、记忆、权限边界仍在快速演化
-
这使得 OPC 在今天更像是一种“工程实验态”，而不是可复制的稳定模式。
（5）小结：OPC 是高阶形态，而非普适形态
因此，一个更保守、也更工程化的判断是：
OPC 会存在，但只属于一小部分工程师。
它不是“AI 普及后的自然结果”，而是工程判断力、结构能力、责任意愿同时成立时，才可能出现的形态。
七、结语：这不是未来学，而是工程组织的再定价
这篇文章的价值，并不在于它是否“预测准确”，而在于它完成了一件重要的事情：
它重新定价了工程师、公司和管理的关系。
