公司本身，也该重做一遍了

上周，我做了个尝试：把一个项目的硬件设计、软件开发和外壳结构设计全部交给 AI。我只提供设计建议和审美倾向，并帮助 Agent 完成所有物理操作。整个过程，没亲手画过一根线，也没写过一行代码。结果，一版成功。

这让我有了一个很明确的判断：AI Native 公司的创业者，要同时开发两个产品。一个是交给用户的东西，一个是能够持续把东西做出来的自主化公司。

给每个人配一个 AI，离这个目标还很远。如果所有任务仍然靠人拆分，背景靠人反复解释，结果靠人在几个聊天窗口之间搬运，那么公司的执行能力，依然被锁在几个人的注意力里。工具再聪明，也要排队等人把下一步接上。

我想要的组织，能够围绕问题组织自己。新需求进来，系统读懂已有的约束，找到相关经验，调动模型、软件和设备，提出方案，执行能够验证的部分，再根据结果继续推进。需要补实验，就明确缺什么；遇到无法判断的问题，就把分歧和证据带回来。没必要给 Agent 复刻一套经理、总监和副总裁，再让它们演一遍办公室。

更大的变化在于，这个组织能够把做过的事情经验留下来，存成记忆。软件缺陷修好了，留下能抓住它的测试；一个设计验证通过了，留下它成立的条件；一套方法跑通了，就整理成后续任务能够调用的 Skill。如果下一次遇到同类问题，人还得从头教一遍，说明这个组织还没有把这项本领掌握好。

这里的标准必须硬一点，也必须有自迭代能力。所有的总结、Skill、MCP，都需要用版本管理维护，经验和能力要在真实的工作中靠类似SFT和RL的方法共同迭代。

人的合作也要接到这个层面。一个人解决的问题，应该让其他人和 Agent 都能往前走。有人补上一种可靠的测试，整个团队以后都能调用；有人确认一条设计约束，后续方案就能少走一段弯路。几个人共同建设的，是一套越来越完整的做事能力。每个人的成果，都能扩大其他人可以完成的事情。

所以，这套系统必须充分接触现实。这次实验的物理操作仍由我完成。往后要继续自动化，就得把制造、测量和使用反馈接进来。实物测试推翻了方案，就修改方案。组织必须允许事实纠正自己，甚至改掉已经习惯的做事方式。

沿着这条路走下去，一家公司的能力，会越来越难从它的人员数量上看出来。经过验证的方法和工具，可以跨越项目继续发挥作用，也可以被不同团队调用、修改和继承。分工围绕问题形成，任务结束，临时的组合可以解散，已经获得的本领继续留下。组织可以不断改变形状，去承接新的问题。公司有多少人、设了哪些部门，将越来越不足以说明它究竟能做什么。

不同规模公司的竞争，也会发生变化。大公司的资金、设备、供应链和客户关系照样有用，多年积累的工程经验如果能被系统用起来，优势还可能扩大。小公司则有机会用很少的人完成一套复杂的研发工作，更早拿出产品，参与原本很难进入的竞争。有些事情，不必等到几个部门都建齐了才开始做。

所以，“大公司”和“人多的公司”，往后得分开说了。人数多的公司，如果每项工作仍然需要人反复解释、协调、检查，业务一扩张，就容易继续缺人。人数少的公司，如果已经把一部分工作做成能够独立运行的系统，就有机会在不增员的情况下继续扩大业务。当然，大公司也能这么做，而且有更多经验和资源可用。双方都得重新考虑，公司要怎么长大。

未来可能会有更多这样的公司：在一个行业里已经举足轻重，员工名单仍然只有一页。要让这样的公司运转起来，旧的分工和协作办法就得重新考虑。创业者在设计产品的时候，也得设计出能够把它做成、并且继续做出新东西的公司。

公司本身，也该重做一遍了。