标签归档:AI

未来的组织形式

20年前,也就是2006年。我刚毕业一年,对小公司内部的政治斗争了无兴趣,就离开了。差不多时候离开的是一位斗争中无奈失败的清华校友/师兄。他之前是这个小公司的CTO,找到投资,就离开创业了——还是从事这一本行。

几个月后,我去他公司找他聊天,他给我展示他公司的管理后台,就是公司的信息系统页面(虽然他不是做IT的)。我很惊讶地发现,整个页面以及流程、模块划分,都跟之前的公司的后台系统一模一样。想问为什么,他的意思是,这毕竟不是他的主要方向,能用就用了,也省去了设计的烦恼。另外一点挺关键的,他从原公司挖了一批人,这些人也对这样的后台熟悉,就无缝过渡了。

然而我不以为然,怎么能因为使用习惯,就把这么关键的公司组织设计的工作给省略了呢?

及到我2009年又回到了之前离职的这家公司,一直做到2023年,老板说,划这部分人给你,内部创业,成立一家新公司,继续做。跟IT/财务/行政的讨论了一下,毕竟人和经验都是那样,也没必要标新立异,就把原来的系统复制一份,数据库划分一下,就可以起来了。(还有一句没有公开说的话,万一你公司做不起来,这些人也是可以直接回来的嘛)

确实,当时按这个思路走,3个月左右,就什么都畅顺了。

当然了,我整体来说是一个奥卡姆法则的践行者,既然可以省事,就没必要再发明一套,沿用旧系统和旧的组织模式是最方便的了。

直到我去年底,彻底离开了原有的集团公司和子公司。

我开始思考,组织的发展过程、组织的形态,以及AI Native的公司又该如何。

1.为什么会有公司?

公司的本质不是“一群人”,而是 “一种持续创造、交付和获取价值的机制”。工业时代之所以需要一群人,是因为信息传递和决策的带宽有限,必须靠分工和科层来规模化。但在AI时代,这个物理约束正在消失。

2.创始团队是怎么形成公司的?

随着业务的成功壮大,一部分的创始团队,也可能是夫妻档,就不得不招聘更多的专业人士加入其团队,于是就有了内部事务的划分,产品研发、市场、销售、供应链、财务、人力资源。一开始是一两个人处理某一项的内部事务,虽然事情越来越多,就需要增加人手,形成部门。

部门逐渐壮大,老板不可能直接对接到个人,于是需要有经理的出现,也就是中层干部。继续壮大,老板和经理之间的副总也出现了,经理和一线员工之间的主管也出现了。

3.什么是奥卡姆法则?

奥卡姆法则:“如无必要,勿增实体”。就是如果跟终极目的不相关的事情,不要因为纵向的历史/经验,横向的同行/对手,而引入对你没有帮助的实体。

4.什么是第一性原理?

Elon Musk提出/遵循的第一性原理,要求探讨问题的时候,关注终极的最简单的事实。然后重新设计系统/解决方案。

5.根据第一性原理,只保留核心团队/个人,核心问题是什么?

单一人类的有限认知与无限市场需求之间的矛盾。其架构必须解决:如何用一个人的“意图”和“判断”,驱动持续增长/无限规模的“执行”。

6.AI Native是什么?

人遇到的所有问题,从AI那里寻求帮助,而不是看传统的人是怎么做的。

7.AI Native 对问题5的答案是什么?

  • 核心模型:意图-执行双循环架构
    • 内循环(人类心智层):核心团队只负责三件事——设定使命与边界(什么不做)、定义价值判断标准(什么是好结果)、进行关键决策(基于AI提供的预测与选项)。这是公司的“宪法”层。
    • 外循环(AI代理层):由一组自主智能体(可能是集群)组成。每个智能体负责一个完整的业务功能(如市场洞察智能体、产品设计智能体、代码生成智能体、客户成功智能体、财务合规智能体)。它们之间通过事件驱动API契约进行协作,无需人类介入。
  • 架构特征:可组合的智能体网格
    • 没有“部门”,只有“能力函数”。例如,传统公司的“市场部”被一个市场感知智能体取代,它持续扫描全网,输出趋势信号。
    • 没有“流程”,只有“状态机”。例如,客户需求 -> 需求解析智能体 -> 价值评估智能体(与人类心智层交互) -> 任务拆解智能体 -> 执行智能体集群 -> 交付验证智能体。整个过程是一个自动流转的状态机。
    • 记忆即数据库:所有交互、决策、结果都以向量和结构化数据的形式存入长期记忆池。这是公司的“集体无意识”,支撑智能体的持续进化。

这一段有点抽象,我再简单一点:

核心就三样东西:

  1. 核心管理团队(只做最重要的决定:定方向、定底线、定什么赚钱)
  2. 一群AI“小工”(每个AI专门干一件具体的事)
  3. 一个共享的大脑记忆(所有AI都记得公司发生过什么)

8.奥卡姆法则如何协助达成AI Native?

传统公司里有一堆“多余的东西”:

  • 🛜 经理(因为信息传不过去,所以需要人转达)
  • 🛜 会议(因为大家信息不同步)
  • 🛜 流程审批(因为怕出错)
  • 🛜 日报周报(因为老板不知道大家在干嘛)

在AI公司里,这些东西统统扔掉:

  • 不用经理 → AI之间直接说话,契约自动执行。
  • 不用开会 → 所有信息存在共享记忆里,任何AI随时查。
  • 不用审批 → 只有违反你定的“底线规则”时才通知你,比如“这个单子低于成本价,请老板定夺”。
  • 不用写日报 → 你的老板界面就是一张仪表盘:今天接了500单,赚了2万块,3个用户投诉颜色不对(AI已经自动处理了2个)。

最终AI Native公司的形态就是:

一个人类核心团队(目标/边界) + 一组自治智能体(执行/协调) + 一个共享记忆系统(数据/知识) + 一系列外部API(能力/市场)线 = 一家公司

没有其他多余的人、多余的步骤、多余的管理。

9.这样的公司如何壮大以适应更大市场需求?

不靠加人,靠加AI能力,而且让外面的人也用你的AI能力。

方式1:把你的AI小工复制很多份

  • 原来你一个设计AI同时只能做10张图。
  • 市场大了,需要同时做1万张图。
  • 怎么办?复制1000个设计AI同时跑。你不需要招1000个设计师,只是云服务器多开几个进程。成本非常低。

这叫“水平扩展”:像复印机一样复印你的AI劳动力。

方式2:不再是只卖海报,而是变成“海报流水线”的指挥

  • 你发现很多小店主也需要做海报,但他们不会用你的AI(嫌麻烦)。
  • 你提供一个极简的API:别的公司(甚至别的一人公司)只需发一行文字“我需要一张火锅店开业海报”,你的AI集群自动出图、自动改、自动交付。
  • 于是你从“自己做海报”变成“让别人也能调你的AI能力”。你可以服务无数个下游公司。

这叫“能力平台化”:卖铲子比挖金子赚得多,而且规模可以极大。

方式3(终极形态):你的AI自动开子公司

  • 你发现除了海报,还有很多人需要做短视频封面、PPT模板、电子书封面……
  • 你告诉你的主AI:“去训练三个新的AI,分别专门做封面、模板、电子书,各自独立运营。”
  • 主AI自己调数据、自己训练、自己上线、自己接单、自己记账,然后把利润汇总给你。
  • 你什么都没多干,但你手下已经自动长出了三家公司。

这叫“递归扩张”:你的AI帮你管理一群小AI公司,你只当最终老板。

10.为何这个回答里面,有时候以一个人来表达,有时候以人类核心团队来表达?

因为一个人总揽所有业务的风险非常高,在AI自主并不成熟的时候,有可能因为人的偶尔缺席而带来严重的后果。所以考虑的是一个核心团队,能对边界作出合理的限制,也可以互为备份和补充,降低个人的偶发风险(生病 / 意外等)

(这文章并不太完善,我后续再行修改。)

deepseek的风格

跟codex一样,我规划了一个我认为给予了足够信息的项目+文档,然后告诉了deepseek(+Claude Code),希望它能从头到尾解决这事情。

两天后,终于出了一些认知上的问题。

就是,不尊重我给的文档,自行用模型中内置的其他知识去替代。


 错误原因只有一个:我没有读 ***** 规范中旋转矩阵的定义,直接用了我熟悉的列向量约定(OpenGL 习惯)。

怎么办?骂醒它。

我现在对于降智的codex,国产的kimi、deepseek,都用过国骂了。

codex是参与创作的时候的不足,还算是情有可原吧

kimi是一个git clean,把自己做的事情都冲掉了

deepseek则是这个,因为没有思考过程,所以感觉它就是做错了,然后说它不知道怎么做。同样的问题,kimi有思考过程,我瞄一眼也大概能知道哪里有问题,纠正起来快。

还是不敢让它们一直做到底,因为你不知道它里面有多少固化下来的微小的认知障。

百鸟朝凤的真相

别被骗了!百鸟朝凤根本不是朝圣,是鸟类黑帮亡命追杀

你脑补的梧桐神凤、万鸟跪拜,全是古人编出来的温柔谎言。
真实的百鸟朝凤,残忍又猎奇,就是一场天空公开处刑、以多欺少的群殴追杀。

1、神话完美掩盖真相

传说凤凰救灾救众鸟,被万物感恩朝拜。
可宋代正史只冷冰冰记着:凤凰现身城楼,数百飞鸟紧紧尾随,仓皇飞向远方。

古人当成天降祥瑞,可动物学家一眼看穿:
成群鸟紧跟大鸟,从来不是臣服,是追着驱逐、死缠不放。

2、鸟类天生抱团霸凌Mobbing

自然界常态:小鸟拉帮结派,疯狂围殴猛禽。
乌鸦追猫头鹰、燕子撵老鹰,俯冲尖叫、轮番骚扰,靠数量碾压体型巨大的天敌。
温柔祥瑞?不存在。
这是鸟界最肮脏的抱团欺压,赶不走绝不罢休。

3、更阴暗反转:小鸟会借刀杀鸟

颠覆三观的野外实验证实:
白头翁遭遇天敌领角鸮,发出惨叫不是呼救同伴,而是召唤天敌的天敌——苍鹰、大冠鹫。

打不过就叫更大的狠角色过来灭口,借刀杀人,鸟界心机恐怖到离谱。

4、凤凰压根就是落难逃犯

古籍里的神鸟,大概率只是孔雀、红腹锦鸡这类珍奇大鸟。
误入鸟群领地,遭到全城鸟类围攻追杀,漫天逃窜。

历代帝王为了皇权正统,强行把狼狈逃亡美化成百鸟朝拜。
高高在上的凤神,不过是被一群小杂鸟围堵、无处落脚、亡命飞天的可怜大家伙。

千年浪漫神话,撕开真相只剩惊悚:
百鸟朝凤,从来不是朝拜。
是鸟界黑帮集结,一场血腥又荒诞的天空围猎。

AI味重不重?

sed

kimi还有一个破毛病,喜欢用sed来编辑脚本。

出了几次反复修改改错代码的问题。我终于忍不住问DeepSeek为什么。

这是一个很敏锐的观察。AI(比如我)在生成 `sed` 命令时确实容易出错,主要原因可以归结为以下几点:

### 1. 分隔符冲突
`sed` 默认使用 `/` 作为分隔符,但 AI 常常忽略目标字符串中也包含 `/` 的情况。

-   **错误例子**:你想把路径 `/bin/bash` 改成 `/usr/bin/zsh`。AI 直接生成 `sed ‘s//bin/bash//usr/bin/zsh/’` —— 这会导致语法错误,因为 `/` 提前结束了模式。
-   **正确做法**:需要转义 `/`(`\/`),或者改用其他分隔符,比如 `#` 或 `|`:`sed ‘s#/bin/bash#/usr/bin/zsh#’`。AI 常常忘记处理这种冲突。

### 2. 特殊字符未转义
`sed` 中的很多字符有特殊含义:`.`、`*`、`[`、`]`、`^`、`$`、`\`、`&` 等。

-   **错误例子**:你想替换 `IP地址:192.168.0.1` 中的 IP。AI 可能会写 `sed ‘s/192.168.0.1/new_ip/’` —— 但这里的 `.` 会匹配**任意字符**,而不是字面上的点。
-   **后果**:它可能匹配到 `192X168Y0Z1` 这样的奇怪组合,或者替换失败。AI 自动生成时往往忽略对这些元字符的转义(应该写成 `192\.168\.0\.1`)。

### 3. 分组和反向引用的跨平台差异
在 `sed` 中,使用 `()` 进行分组时:

-   **GNU sed(Linux)**:需要用 `\(` 和 `\)` 来转义,反向引用是 `\1`。
-   **BSD sed(macOS、FreeBSD)**:基本 POSIX 模式下,`(` 和 `)` 也必须转义才能作为分组符,不过 `\1` 用法类似。
-   **更混乱的**:有些脚本想用 `-E` 选项(扩展正则)来避免转义,但 AI 生成的命令常常**混用**两种风格,或者不加 `-E` 却用了无需转义的正则写法,导致报错或静默失败。

例如:想交换两个单词 `Hello World` → `World Hello`。正确的 GNU 写法是 `sed ‘s/\(Hello\) \(World\)/\2 \1/’`。如果 AI 忘记转义括号,写成 `sed ‘s/(Hello) (World)/\2 \1/’`,则完全无效。

### 4. `-i` 选项的平台差异
`sed -i`(原地修改文件)的行为在 Linux 和 macOS 上不同:

-   **Linux**:`sed -i ‘s/old/new/’ file`
-   **macOS**:`sed -i ‘’ ‘s/old/new/’ file` —— 必须为备份后缀提供一个空字符串参数,否则会报错。

AI 经常默认用 Linux 语法,导致在 macOS 上运行时出现奇怪的 `sed: -i may not be used with stdin` 或 `undefined label` 错误。

### 5. 边界条件与文件格式
-   **缺少换行符**:如果文件最后一行没有换行符,某些 `sed` 命令(如 `$` 地址匹配)可能表现异常。
-   **Windows 换行符(CRLF)**:`sed` 默认把 `\r` 当作普通字符,导致模式匹配失败(比如你搜 `foo$` 匹配不到 `foo\r\n`)。
-   **空文件**:一些 `sed` 脚本在空文件上会直接报错退出。

AI 在生成命令时,默认假设一个整洁的 POSIX 文本文件,但现实中并不总是如此。

### 6. AI 的“统计学习”问题
大模型的训练数据里包含大量 **错误的、过时的、不兼容的** `sed` 示例。比如:

-   来自 Stack Overflow 上某个未被采纳的答案。
-   来自个人博客里随意测试的片段。
-   来自混合了不同 shell 环境的历史脚本。

模型学会了“最常见”的写法,而不是“在所有情况下都正确”的写法。对于小众边缘情况(如处理路径、JSON、XML),模型更容易编造一个看起来合理但实际错误的命令。

### 7. 对上下文理解不足
用户往往只说“帮我改一下这个配置文件里的 IP”,但不提供文件的具体格式、是否有特殊符号、使用的是哪种 `sed` 版本。AI 只能盲目猜测,而猜测的结果就是容易出错。

### 如何减少错误?
-   **先测试**:运行 `sed` 前,先用 `sed ‘s/pattern/replacement/’ file`(不加 `-i`)看看输出是否正确。
-   **告诉 AI 更多信息**:明确说明“我的文件路径包含斜杠”“我用的是 macOS”“IP 地址里有小数点”。
-   **换工具**:对于结构化的文本(JSON、YAML、XML、CSV),用专门的解析器(`jq`、`yq`、`xq`、`awk`)而不是 `sed`。AI 生成的 `awk` 或 `perl` 命令有时比 `sed` 更可靠,因为语法更一致。
-   **加上 `--debug`**:如果 `sed` 版本支持(如 GNU sed 4.8+),用 `sed --debug` 看它是如何解释命令的。

总的来说,不是 AI 能力不足,而是 `sed` 本身是一个非常“挑剔”、充满历史包袱和平台差异的工具。AI 擅长的是统计规律,而不是绝对正确的语法和边界条件。对于关键的文件操作,**永远不要盲目信任 AI 生成的 `sed` 命令**。

明白了,于是让Kimi把不用sed写到AGENTS.md里。

自以为是的CLI

在调试过程中,我让kimi帮我checkout回git的最新版本。

然后发现它给我git clean了,于是一大堆untracked的目录被干掉了。骂了它十几句。

得到的结果就是我以为,对不起,有没有Time Machine,很废。

于是我告诉它不要用git了,除非我命令它用。

好在前两天都及时git commit过了,损失不算大,就是10美元额度能追回的事情。

有点心理阴影,还是让codex去恢复/重做这些untracked的事情了。

把额度花光

连续几天都把codex两个来源的每日额度都花光了。

我的性格是每天有非常确切的事情做,细到一定地步会非常的充实,也很有存在感。

这种花额度干活的方式,让整个白天工作时间都很饱和……比以前技术管理/公司管理的时候更实在。然后不断地为额度为tokens想着办法花完它。

不过坏处也是有的,欠的阅读清单一直都没有完成。

codex 5.4用了一个月了,然后5.5也来了,不过要pro套餐才行,我在考虑,一个什么样的任务再启动5.5的工作。毕竟目前的任务,都分配好了(kimi:前端系统, codex:三维算法及场景分析),也比较顺利,如无必要,勿增实体,总不好无事换帅吧。

判断何时用算法,何时用人工

在某个细分领域上,你要提升一点点,能参考的东西也不多,好在现在AI的能力很强,但AI会把人带偏,它们会习惯性地用科研的思维去尝试解决问题,这样的做法在工程上有时候是相当不合适的。

比如,做出一个有效算法,样本集和测试集是否足够,算法的复杂度是否足够高,以至于产品化的时候很鸡肋。

相比之下,如果我们在输入端,要求输入的格式就按需求做了某些调整,这样就很大地减少了算法的复杂度。

但谁来做这个决定,肯定是vibe coder了。这就要求viber coder,既懂科研标准,也知道工程限制,更重要的是,知道需求的本质是什么,需求方是否可以妥协。

开了ChatGPT Plus

略复杂:

挖出不用两年的顶配iPhone 11,系统升到最新,注册了新的美区 Apple Account

Gift Card陆续充值,养了一个月,购买一些低价游戏玩了一下

(美区Apple Account不支持中国的信用卡绑定Apple Pay,但可以用美区Gift Card充值,美区Gift Card商店支持中国的支付方式:支付宝等)

下载了ChatGPT,玩了一段free的对话

注册了新的Gmail账号

ChatGPT切换到新的Gmail账号

(新的Gmail账号如果被封,iOS上的ChatGPT更换账号就可以了,但如果Apple Account被封可能就比较麻烦?)

新账号升级到Plus

删掉之前中转站用的auth.json和config.toml

(之前的中转站是API体系,base_url和API_KEY写在那里,触发不了ChatGPT账号登录,ChatGPT账号也可以建立API KEY,但使用API KEY是额外收费的,不在套餐里)

重启codex,用ChatGPT登录。

感觉费用消耗上会比中转站可靠还便宜,对于我的使用度来说(每天100M tokens左右)

(Plus计划没有用量统计,只有用了五小时限额/周限额多少的百分比,如果要看具体的就要部署sub2api的系统了)

先不把话说满,谁知道后面会如何。

Codex 中转站的价格

由于之前的中转站老出问题,月卡差不多算是废了,尽管它的消耗比率目前看来比其他要合理很多。

转向买日卡或者按量充值。

换算公式甚是啰嗦:你消耗的M token数 — 折算成系统的token计价单位:“美元”(理解成赌场上的筹码也可以) — 为了提升服务质量,用什么样的比率消耗这些“美元” — 商家用什么样的汇率来销售这些美元 — 你买的codex服务使用的人民币

作为CLI用户,更关心的是使用的 M tokens 和最终的 RMB的比例。

过程中的赚钱的地方:

  1. tokens的消耗速度,试过有个站用得特别特别快,就是算tokens算多了,就欺负你不去计较它。
  2. 消耗“美元”的比率,最初用的站比较良心,还是1:1的,后来不怎么能用了,到外面看一圈,很多把比率调成2倍或以上。我这两天用的就是2倍的。系统中用1“美元”,计价2“美元”。
  3. 人民币购买“美元”的汇率,有些老牌的商业站,用1:1来销售,但从2.的比率上设成0.2~0.5,也有些新站,汇率是1:30(1 RMB购买30美元),但2.比率就是几倍。

所以2 和 3要乘起来一起看。

还会有更猫腻的地方,如果你用来玩龙虾的话,由于你基本上看不到过程,有可能换其他模型来以次充好。

号池:

中转站的生意其实是黑产/灰产的下游,正正经经自己买号建号池再来分销,(其实也是不符合原厂的用户协议),要赚钱无非是上面几个点位。

很多是从号商处购买各种原厂大模型的商用号。

这些号是怎么来的,一方面是自动注册,另一方面是钻AI原厂的支付漏洞,成本会低得离谱。就是多了一个被封号的风险,所以卖号的会承担部分封号的风险:退款或者换号等。

带来同样的机会就是代充服务……

由于AI中转站是一个非常新兴的特殊的行业,目前看不到后面会怎么发展。如果不看重盈利的话,几个个人 / 团队正规途径合买一些商业号,建中转系统共用,会是一个可靠的模式。(跟当年几个人共用梯子很像吧)

大模型厂商比如OpenAI会怎么看这些问题?估计就是:让子弹飞一会儿吧。

与kimi cli的开发反思

更多的是我在反思,让kimi看看它跟我的理念的差异,造成了一些不顺畅以及技术债务。

节选一下:

## 对 AI 的提示

在后续开发中,当遇到以下信号时,应主动质疑而不是默认实现:

1. 某个功能不在 `ROADMAP.md`、设计文档或用户明确指令中

2. 功能的加入理由是 “xxx 软件也有”

3. 修复一个边缘 bug 需要引入复杂的条件分支

4. 功能在复杂架构下语义不清

5. 正在解决的问题与之前已解决的问题高度相似

6. 同一个模块/功能反复出现相似 bug

此时应优先向用户确认:

> “这个功能不在当前设计范围内,且边界较复杂。建议是 A) 简化实现 B) 直接删除 C) 排期设计。您的偏好是?”

当遇到实现困难时,应优先执行以下检查清单:

1. **搜索当前代码库**:是否有同一模块中已解决的相似问题?

2. **搜索历史修改记录**:CHANGELOG / git history 中是否有相关修复?

3. **查看原始参考**:`xxxxxx/` 原始 C++ 代码中是否有对应逻辑?

4. **检查可复用组件**:是否有公共函数、工具类、或已有模式可以直接套用?

5. 只有在上述四步都没有找到答案时,才允许从零实现。

**注意**:第 1-4 步的参考价值**高于**第 5 步中你可能想到的”通用最佳实践”。参考代码包含了本项目的具体约束和验证过的边界条件。

当脑海中浮现”我知道一个更好的方案”时,应问自己:

1. 这个”更好的方案”是**当前项目真正需要的**,还是**我知识库中恰好有的**

2. 如果用一个简单方案实现 80% 的价值,**剩下 20% 是否值得引入额外的复杂度**

3. 这个方案如果被证明过度设计,**是否容易拆除**

4. 手头的参考代码(第三方源码或项目内已有实现)是否已经给出了**更适合当前约束的答案**