原创 孔某人 2025-08-15 14:39 北京
靠 锤子 试图生产 机床 的时代
题记1
“Dogfooding”，中文常译为“吃自己的狗粮”，是科技行业一个非常流行的术语。它指的是一家公司在向公众正式发布其产品之前，先在内部让自己的员工广泛地使用该产品来完成日常工作。这个说法的背后逻辑非常简单：如果连你自己都不愿意或不能使用自家的产品，又怎能指望外部客户会喜欢并购买它呢？
这个概念据说起源于上世纪80年代的微软。当时一位经理在邮件中引用了一家狗粮公司总裁的广告语——“我会喂我自己的狗吃我公司的狗粮”，以此激励团队使用他们正在开发的软件。从此，“吃自己的狗粮”便流传开来，成为科技公司检验自身产品质量和实用性的重要文化。
题记2
Claude Code相对于同期的OpenAI Codex和Gemini CLI，产品体验是更好的。因为Claude Code实际上是首先在内部原型产品，然后在公司内部会广泛使用，才产品化的。而我相信OpenAI Codex和Gemini CLI在各自公司内部并没有被大范围地作为主力AI Coding使用。
而本文绝非要讨论AI公司是否应该开发自己的AI Coding工具这么狭窄的问题。
企业内Agent Runtime Infrastructure
Agent Runtime Infrastructure是我自己创造的一个词，指：在公司或组织内部，能够让Agent员工充分执行/发挥自己长处的企业内IT基础设施。它不是构建Agent的Infra，所以在名字中插入了Runtime一词。
实际上当你开始在企业内构建这样的东西时，会发现有一大堆的Infra需要准备。最简单来说，所有需要人工通过GUI界面操作的环节，都应该有对应的给Agent的API。
当然GUI Agent模型大概会在今年年底再更新一轮，届时可能会实现一些自动处理，但能做，和能可靠地做还是有差异的。特别是在企业内的各种奇奇怪怪的系统、和奇怪的配置。
到这里我就已经看不到哪个AI公司已经做出来了，确实有一些早期创业公司宣称自己有类似的计划，但是否能真的做好就很存疑。
企业内的下一代协作方式
更大的问题是，虽然AI公司试图在一些方向上给用户一个很好的体验，但AI公司内部的研发流程却相当原始。
从最草台班子的企业到大公司，内部研发协作流程也只是从微信沟通，变成了飞书沟通+一些质量难评的文档。从微信到飞书，说实话沟通方式没有太大的改变。文档方面，很多人写的文档是徒有章节格式，但内容上却缺失很多，且不说内容思考的质量，光信息的缺失程度就会想让研发一脚踹开写PRD的产品，自己去补完。
更别说企业稍微大了一些之后的层层传话，由于工作压力大而导致的健忘，一个信息被沟通几次都是常态，甚至于连在提出者那里都被遗忘。
所以整个组织中，你就能看到那种通过IM/文档沟通够做不明白的情况，说实话能写好Prompt的人不会有这样的问题。有这样问题的人，我担心TA的Prompt能力。
我现在常用的一个模板：定位于XX场景/目标的AI产品，是否无法靠目前的前沿LLM所实现？
当然这不是那种业余AI产品觉得一切都可以靠LLM所实现的低端提问。实际上当你真的找做LLM应用的一些研发来问一些这样的问题时，大家的第一反应是语塞。因为看起来确实是可以做到某个程度的，至少不会说在启动前就放弃。但因为没有人思考这些、没有人致力于推动这些，所以房间里充满了一大堆这样的大象。
这个问题套在这里也一样，我们现在是否做不出来一个更好的内部协作平台？
定位中高端产品的AI公司，如果连内部沟通都如此原始，又能对它指望多大？虽然工具原始，但产品还是可以做的，就像没有C编译器的时候总要能够实现自举。但内部协作这个有这么多前置依赖么？
那么好的AI协作平台应该实现什么样的功能呢？详细地展开讨论就比较复杂，但可以换一个角度。
目前几乎所有的AI产品都应该是类似于某种职能特化的秘书/助理。就想象一个AI飞书，能实现相当于给每个使用该飞书的人类员工，配有一个负责信息沟通和收件的Agent助理，而且这个助理的能力应该跟实际配置了一个人类助理一样。在整体层面，这个系统还应该能够实现一个理想的人类的技术PMO团队的能力，汇总和分发全局的信息，做全局的资源平衡和资源不足预警。
很可惜，这可能不是一个好的创业项目，类似于ChatBI类产品一样，在组织内落地有着巨大的成本。
但至少标榜自己是优秀AI公司的公司应该自己在内部实现这点。
相关文章
互联网公司缺乏类ERP的信息传递系统 | Airbnb CEO访谈
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请加微信，联系方式请点击 -> 专栏简介 及 联系方式 2024。
本文于2025.8.15 首发于微信公众号和知乎，知乎链接：
https://zhuanlan.zhihu.com/p/1939695497561473960
