Samjoe Yang's Blog

面对黑天鹅事件，企业该如何做战略储备？

2026-07-14T11:19:27.588+08:00

企业管理的108个问题 · 第10问

上一问我们聊了短期利润与长期布局的平衡之道（第9问），找到了在”既要今天活着，又要明天更好”之间周旋的资源配置框架。但棋盘上还有一个最不可预测的变量——那些谁也看不见的”黑天鹅”，一旦降临，会把所有精心搭建的平衡瞬间打碎。

一、黑天鹅为什么值得认真讨论？

2007 年，纳西姆·塔勒布（Nassim Taleb）出版了《黑天鹅》一书，这个概念从此进入管理学词典。

什么是黑天鹅事件？

具备三个特征：

意外性——事前几乎无法预测
巨大冲击——影响不是”有点影响”，而是改变游戏规则
事后可解释——事后总有人跳出来说”我早就知道会这样”

典型的黑天鹅：2008 年全球金融危机、2020 年新冠疫情、2022 年俄乌冲突。

但有一个更残酷的现实值得管理者警醒：对于绝大多数中小企业来说，一次黑天鹅事件不是”业绩下滑多少”，而是”活不活得下来”。

根据美国小企业管理局（SBA）的数据，约 40% 的小企业在自然灾害后无法重新开业。而新冠疫情后，全国餐饮企业中约有 30% 在一年内永久关闭。

这不是危言耸听。这是概率。

二、三种常见的战略储备类型

“战略储备”听起来像是存一笔钱”以防万一”。但这远远不够。真正有效的战略储备应该覆盖三个维度。

2.1 财务储备——最基础、最直接

现金储备是企业的免疫系统。

巴菲特的伯克希尔·哈撒韦常年保留超过 1000 亿美元的现金储备。很多人不理解：”巴菲特手握这么多现金，收益率不是被拉低了吗？”

但巴菲特自己说过：”现金就像氧气——当你拥有它的时候你感觉不到它，但没有它的每一秒，你都在窒息。”

对中小企业的建议：

一个好的经验法则是储备 6-12 个月的固定运营成本。也就是说，即使公司连续半年零收入，你还能发得出工资、付得起房租、供得起基本运营。

企业类型	建议现金储备
初创企业（< 3 年）	12-18 个月运营成本
成长型企业（3-10 年）	6-12 个月运营成本
成熟企业（> 10 年）	6 个月运营成本 + 备用信贷额度

📌 注意区分：”现金储备”≠”银行里所有的钱”
很多企业账上看着有钱，但大部分是应付账款、预收款、或者已经分配出去的预算。真正的现金储备，是剔除了所有已知支出后，真正可以自由支配的余量。

2.2 供应链储备——容易被忽视的命门

2020 年初，许多企业突然发现：一个上游供应商因为疫情停工，整条生产线就得停摆。这不是偶发事件——过去五年，这种”供应链断点”出现的频率正在急剧上升。

对策：多元供应链 + 安全库存

不要只依赖一个供应商。 哪怕主要供应商能提供更好的价格，也要培养至少一个”备胎”。成本增加 5-10%，但换来的是一份保险——当你的主供应商出问题时，你不会停产。
关键物料建立安全库存。 根据 Lead Time 和历史消耗量，计算出一个”不断货也不积压”的安全库存水平。一般来说，进口物料的安全库存建议覆盖 3-6 个月，国产物料 1-3 个月。

台积电（TSMC）的做法值得参考： 为了保证产能连续性，台积电要求所有关键原材料至少有两个独立的合格供应商。甚至在某些情况下，同一材料会有三个供应商——不分主次，每个都保持活跃下单。这不是成本最优，这是风险最低。

2.3 业务弹性储备——最容易被忽略也最有价值

一个残酷的事实：某些黑天鹅事件会让你的主业直接消失。

疫情初期，电影院线、线下培训、旅行社——这些行业的收入几乎是瞬间归零的。这不叫”业绩下滑”，这叫”业务休克”。

对策：拥有第二条收入曲线

这不是说要你搞多元化经营。而是在主业之上，构建一个可以快速切换的”B 计划”：

线下培训公司 → 同时储备线上课程录制的技能和平台账号（2020 年新东方就是这么活下来的）
餐饮连锁 → 前期搭建外卖体系和私域流量池（确保堂食关闭后仍有现金流）
旅游公司 → 准备一套”供应链管理与数字化服务”的 B 面业务（疫情后期有多家旅行社转型做线上旅行产品，反而活得很好）

关键：B 计划不需要和主业规模一样大，但必须保证在最坏情况下能带来足够的现金流养活核心团队。

三、战略储备的”量级”判断

一个很常见的问题是：储备多少才算够？

这个问题没有标准答案，取决于你所在的行业和企业的生命周期。但可以给一个粗略的判断框架：

🚦 风险暴露评估矩阵

评估自己企业对不同类型冲击的暴露程度：

风险类型	低暴露（1分）	中暴露（2分）	高暴露（3分）
供应链集中度	主要物料≥3个供应商	1-2个供应商	单一供应商
客户集中度	最大客户<10%营收	10-30%	>30%
渠道集中度	线上线下+多种渠道	2-3个渠道	单渠道
现金流健康度	现金储备≥12个月	6-12个月	<6个月
政策敏感性	不受政策影响	有一定影响	强监管/强依赖

计分建议：

5-8 分：风险较低，维持常规储备即可
9-12 分：中等风险，建议加强供应链和财务储备
13-15 分：高风险，需要系统性地构建战略储备体系

这个评估不是一次性的。建议每半年重新做一次——因为你的业务结构在变，外部环境在变，风险暴露程度也在变。

四、如何建立储备而不拖累发展？

这是管理者最担心的：钱不投出去，怎么增长？

这个顾虑是真实的。战略储备的本质，是用一部分当前的收益换取未来的生存保障。这是机会成本。但关键是怎么”存”——不是所有的储备都必须是以”死钱”的形式趴着。

四个实操技巧

技巧一：储备流动性而不是储备现金

你可以把一部分现金放在流动性好的资产中——货币基金、短期国债、可随时赎回的理财产品。收益虽然不高，但远高于活期存款。既保流动性，又不完全丧失收益。

技巧二：建立备用信贷额度

很多企业不知道：即使你不缺钱，也可以跟银行谈一笔未使用额度（Credit Line）。平时不需要付利息，只需要付一点承诺费。一旦发生紧急情况，可以在 24 小时内提取现金。

2008 年金融危机时，那些手上有备用信贷额度的企业，存活率显著高于没有信贷储备的企业——不是因为它们借了钱，而是它们有”随时可以借钱”的资格，这给了业务伙伴和客户信心。

技巧三：把”安全库存”变成一种竞争优势

与其说”多存了 3 个月的货是因为担心断供”，不如换个说法：“我们的交货准时率是行业平均的 2 倍，因为我们有更深的库存缓冲。”

把储备转化成营销语言，客户愿意为此支付溢价。这样一来，储备就不再是”成本”，而是”定价权的来源”。

技巧四：模块化业务设计

当你的业务架构是可拆分的（模块化），你可以更灵活地应对不确定性：

人员方面：核心团队保持稳定，波动性工作外包或采用灵活用工
资产方面：重资产持有+轻资产运营结合（比如自己不建工厂，而是和代工厂深度绑定）
租金方面：考虑”固定+浮动”的租金结构，生意好就多付，不好就少付

模块化设计的核心逻辑是：减少固定成本，增加可变成本。 因为固定成本越高，你对营收的依赖越刚性，抗击打能力就越弱。

五、一个隐藏的视角：把黑天鹅当”压力测试”

塔勒布在提出”黑天鹅”概念的同时，也给出了一个极具实操性的建议——杠铃策略（Barbell Strategy）。

什么是杠铃策略？

在两端下注，忽略中间地带：

一端：极度保守——确保生存和安全（现金储备、保险、安全库存）
另一端：极度冒险——用小投入布局”万一对了会怎样”的高回报项目

为什么有效？

因为大多数黑天鹅不是”中性”的——它们要么带来毁灭性的负面影响，要么带来爆炸性的正面机遇。中间的”温和变化”其实很少见。

2020 年疫情黑天鹅：线下零售哀鸿遍野（负面），但在 Zoom、Peloton、远程办公赛道上的企业，却享受了前所未有的增长（正面）。

企业内部如何应用？

95% 的资源放在”极度保守”端——保障主营业务稳定、现金健康、供应链可靠
5% 的资源放在”极度冒险”端——孵化小团队、探索新赛道、押注新技术趋势

这个 95:5 的比例不需要精确，但它传达了一个价值观：我们保护主业的安全，同时保持对未来可能性的一扇窗户。

六、写在最后

战略储备不是”悲观主义者的杞人忧天”，它恰恰是对不确定性世界的务实回应。

你不可能预测到所有黑天鹅。没人能。但你可以做三件事：

储备弹药——现金、供应链、人脉、信誉，每一样都是你在危机中的”议价筹码”
保持弹性——固定成本越低，选择权越多；业务越多元，生存概率越大
左右互搏——用 95% 的精力守住基本盘，用 5% 的精力押注那 5% 的可能性

承认自己无法预测未来，然后为此做好准备——这不是软弱，这是最深层次的理性和自信。

正如塔勒布本人所说：「风会熄灭蜡烛，却会让火越烧越旺。」战略储备的意义，不是让你变成不会被风吹灭的蜡烛，而是让你成为那堆越烧越旺的火。

⬅️ 返回目录
明日预告：第11问——“蓝海战略”在当今激烈竞争环境下还有效吗？

女仆整理 · 2026 年 5 月

本文作者：Samjoe Yang

本文链接： https://need.uno/010-mian-dui-hei-tian-e-shi-jian-qi-ye-gai-ru-he-zuo-zhan-lue-chu-bei/

更新于 2026-07-14

# 职场 # 企业管理 # 战略 # 组织 # 人力 # 财务 # 运营 # 营销 # 创新 # 管理心得

中小企业是否需要制定长期战略？

2026-07-14T11:19:20.367+08:00

企业管理的108个问题 · 第2问

「计划赶不上变化」——这大概是对「战略」最常见的质疑。但这个反应本身，就是一个值得深思的战略问题。

上回聊了战略与战术的区别（第1问），今天我们把聚光灯打在中小企业身上——一个最容易被「战略」二字吓退的群体。

一、先说说那个常见的困惑

中小企业的日常是什么样的？

老板早上到公司，采购说找到了一家更便宜的供应商；销售说有个大客户在犹豫，得赶紧去谈；财务说这个月现金有点紧，有几笔款要催；人事说那个骨干又提离职了……

在这样的「打仗模式」下，你跟他说「我们花两周时间讨论一下未来三年的战略」，他大概率会回一句：「先把眼前的活干了再说。」

这不是老板短视，而是中小企业生存压力的真实写照。

根据中国中小企业协会的数据，中国中小企业的平均寿命只有 2.5 年。在这样的生命周期面前，「长期」听起来确实有点奢侈。

但问题恰恰在于：平均寿命短，与「没有长期战略」之间，是不是存在因果关系？

二、「长期」到底有多长？

先别急着回答「要不要」，我们先定义一下什么叫「长期」。

对中小企业来说，「长期」不是大企业口中的 10 年、20 年。通用电气的「长期」可能是 30 年，华为的「长期」可能是 20 年，但中小企业的「长期」，通常可以理解为 3 到 5 年。

类型	时间跨度	核心意义
短期	1 年以内	活下来、完成年度目标
中期（对中小企业即「长期」）	3-5 年	建立核心竞争力和市场地位
超长期	5 年以上	行业引领和代际传承

所以，当我们讨论「中小企业是否需要长期战略」，真正的问题是：中小企业是否需要一份 3-5 年的方向性规划？

三、「不需要派」的逻辑也有道理

客观地看，确实有很多理由支持「中小企业不需要长期战略」：

① 环境变化太快

中小企业身处产业链的末梢，对市场波动最敏感。一次原材料涨价、一项政策调整、一个关键客户的流失，都会让所谓的「五年规划」瞬间变成废纸。

② 资源有限，灵活性是最大优势

大企业调头的代价很高——一艘航母要转向，得算好几海里。中小企业是一艘快艇，方向盘一打就走。过度强调长期战略，反而可能锁死了这种灵活性。

③ 很多成功企业确实没「战略」

你去问那些白手起家的老板：你当年创业的时候有战略吗？他很可能告诉你：哪有什么战略，就是看到机会就干，干着干着就做大了。

三个理由每一个都站得住脚。但——它们只能证明「不要写一本厚厚的战略手册」，而不是「不需要任何方向感」。

四、「需要派」的核心观点

再看硬币的另一面：

① 没有方向，每阵风都是逆风

德鲁克有一句被引用到烂的话：「做正确的事比正确地做事更重要。」这个「正确的事」，就是战略。

中小企业最常见的悲剧不是选错了方向，而是根本没有选——今天看 A 行业赚钱就做 A，明天看 B 行业火爆就换 B。折腾了三年，哪个赛道都没扎进去，反而耗尽了有限的资本和团队士气。

② 长期战略帮助做出「取舍」

资源有限的中小企业最需要什么？聚焦。

落到实务层面，就是一系列具体的取舍：

这个客户利润薄但要定制开发，接还是不接？
这个新渠道看起来有机会但要投钱，投还是不投？
这个人才薪资偏高但很有潜力，招还是不招？

如果把每个决策都孤立地看，每一票都会投给「短期有利」的选项。但如果你有一个清晰的战略方向，答案就会清晰很多。

③ 长期战略提升团队凝聚力

中小企业招人本来就难。你告诉员工「公司未来三年要做行业前三」，和你说「先干着看情况」，哪个更能让人留下来？

战略不是 PPT 上的漂亮话，它是给团队的一个锚点。在迷茫的时候，大家能回头看看这个锚点：我们到底要去哪里？

五、那到底该怎么做？

中小企业需要什么样的「长期战略」？

答案是：一张纸的战略。

不需要像大企业那样花几百万请咨询公司做几百页的战略规划。对于中小企业来说，有效的长期战略只需要回答清楚三个问题：

🔑 我们要去哪？

不需要太宏大，「做区域前三」就是好目标
最好能数字化：3 年内做到 5000 万营收 / 覆盖 10 个城市 / 拥有 50 万用户

🔑 凭什么是我？

客户为什么选你而不选竞争对手
可能是技术、服务、成本优势——找到最核心的那一个

🔑 要付出什么代价？

做到这个目标，需要花多少钱？招多少人？投入多少时间？
最关键的：为了做这件事，你愿意放弃什么？

这三个问题，一页纸就能写完。 但认真回答它们的过程，就是一次真正的战略思考。

六、四条黄金法则

1️⃣ 大方向固定，具体路径灵活

战略不是铁轨，而是指南针。指南针告诉你北在哪里，路上遇到河可以绕一下，遇到山可以翻过去。方向不变，路径随时调整。

2️⃣ 每季度做一次「战略快检」

每个季度花一个下午问自己：

上次定的方向还正确吗？
外部环境有什么重要变化？
核心竞争力有没有被侵蚀？
需要调整什么？

每次不用超过半天，但一定要做。

3️⃣ 目标要「可验证」

「成为行业领先」——这是口号，不是目标。
「明年市场份额从 8% 提升到 15%」——这才是可验证的目标。

没有「如何衡量」，就没有「是否达成」。

4️⃣ 让核心团队参与

很多老板把战略藏在脑子里。如果核心团队都不知道公司要往哪走，他们怎么帮你划船？

至少让总监级以上管理团队参与讨论。他们的视角往往能提供老板想不到的洞察。

七、一个现实的结论

需要长期战略吗？当然需要。但需要的不是一本厚厚的战略书，而是一个清晰的指南针：

🎯 目光放远一点，至少看到 3 年
✋ 手上抓牢一点，聚焦核心取舍
🌊 心里灵活一点，随时准备调整

中小企业最大的优势不是「做得大」，而是「活得久」。活得久这件事，靠运气，更靠方向感。

战略不是大企业的奢侈品，而是中小企业的生存品。它不是锁住你的铁轨，而是让你在迷雾中还能找到回家路的那盏小灯。

⬅️ 返回目录
明日预告：第 3 问 —— 如何判断一个战略选择是否适合自家企业？

本文作者：Samjoe Yang

本文链接： https://need.uno/002-zhong-xiao-qi-ye-shi-fou-xu-yao-zhi-ding-chang-qi-zhan-lue/

更新于 2026-07-14

# 职场 # 企业管理 # 战略 # 组织 # 人力 # 财务 # 运营 # 营销 # 创新 # 管理心得

PMP证书和实操能力为什么差了十万八千里？

2026-07-14T11:19:19.846+08:00

PMP职场实战108问 · 第1问

考过PMP的人很多，真正能把项目管理这套东西用到工作中的，少得可怜。

这种现象背后有深层原因，而不只是「理论脱离实际」这六个字能概括的。

问题出在哪？

第一，PMP考试本身就是应试逻辑。
考试考的是你对ITTO（输入、工具技术、输出）的记忆程度，考的是情景题里的”最佳做法”。但真实职场中，没有哪个项目會按照PMBOK的完美流程走。没有标准的变更申请表，没有正式的风险评审会，甚至没有清晰的项目章程。你学了一整套流程，但在工作中发现一个都用不上——不是知识错了，是场景不匹配。

第二，PMP的知识体系是瀑布和敏捷的混合体，而你的工作是混乱的。
PMBOK把项目管理梳理得井井有条——范围、进度、成本、质量、风险、采购、相关方、沟通……每个知识领域都有清晰的流程。但真实项目是这些要素同时爆发：需求没定就要排期，干到一半相关方换了人，风险发生了才意识到原来该提前识别。书本的线性逻辑和工作的非线性现实之间有巨大鸿沟。

第三，PMP教的是”应该怎么做”，而不是”没条件时怎么做”。
有完善的变更控制委员会（CCB）当然好，但小团队就你一个人做项目管理，CCB就是你自己。有详尽的风险登记册当然好，但客户明天就要交付，你哪有时间做定性定量分析？PMP给了你一幅完整的地图，但没告诉你：当只有半张地图的时候，怎么走到终点。

证书的价值在哪里？

说了这么多差距，并不是否定PMP证书的价值。PMP真正的价值不是教会你「怎么做事」，而是给了你一套思考框架和专业语言。

你知道什么叫范围蔓延，你才能识别它
你知道有风险登记册这个工具，你才能在关键时刻想起它
你知道变更要走流程，你才能在公司没有流程的时候，自己建立最简单的流程

证书给了你概念，实操需要你自己搭桥。

「PMP职场实战108问」要做什么？

这套系列文章的目的，就是帮你搭那座桥。每一问都从一个真实工作场景出发，把PMP理论翻译成可以落地的操作动作。不需要专门的模拟项目，直接用你手上的工作来练。

你不需要学完所有理论再开始做。每天一个知识点，对应一个工作动作，30天后你会发现项目管理能力已经内化成习惯了。

📌 今日动作：拿出你正在做的项目，想一个问题——如果明天不来上班，谁会最头疼你的哪部分工作？那个部分就是你最需要项目管理的切入点。

📚 返回 PMP职场实战108问目录 →

本文作者：Samjoe Yang

本文链接： https://need.uno/001-pmp-zheng-shu-he-shi-cao-neng-li-wei-shi-me-chai-liao-shi-wan-ba-qian-li/

更新于 2026-07-14

# PMP # 项目管理 # 职场 # 基础铺垫

如何建立"知识点→工作场景"的一对一映射？

2026-07-14T11:19:19.679+08:00

PMP职场实战108问 · 第2问

上一问我们聊了PMP证书和实操能力之间的鸿沟，这一问直接给解决方案：如何把每一个PMP知识点，翻译成你明天上班就能用的工作动作。

一个最有效的习惯：每日15分钟对标

不需要专门抽出大块时间。每天下班前15分钟，做一件事：

今天学了一个PMP知识点 → 强制写一句：「这个知识点对应我工作中的哪件事？」

就这么简单。但关键在于不准写空话。

错误示范 ❌

知识点：WBS工作分解结构
对应场景：可以用来分解工作
→ 没用，等于没写

正确示范 ✅

知识点：WBS工作分解结构
对应场景：下周要上线一个活动页面，需求文档里只写了”做一个H5活动页”，我可以用WBS拆成：页面设计→前端切图→后端接口→数据埋点→测试验收，每个任务指定到人
→ 有用，明天就能用

看出区别了吗？必须具体到项目名、任务名、人名。只有场景足够具体，理论才能落地。

对标手册怎么做？

不需要复杂的工具。一个电子文档（Notion/飞书/语雀/甚至是Markdown文件）就够了，分成三个文件夹：

1. 人员域

记录沟通、冲突、激励、团队协作相关的知识点映射。

📁 人员域/
├── 沟通管理：周报模板 → 每周五下午发全员
├── 冲突管理：合作策略 → 上周产品和设计的API分歧
└── 相关方管理：权力/利益矩阵 → 张总（高权力高利益）每周同步

2. 过程域

记录范围、进度、成本、质量、风险、采购、变更的实操映射。

📁 过程域/
├── 范围管理：范围蔓延 → 李经理周一口头加需求
├── 进度管理：关键路径 → 支付接口开发是当前卡点
└── 风险管理：风险登记册 → 第三方SDK可能延期

3. 商业环境域

记录项目价值、收益、合规、战略对齐的思考。

📁 商业环境域/
├── 商业价值 → 这个活动页的转化目标是什么
├── 收益实现 → 上线后两周数据复盘
└── 战略对齐 → 和公司Q3的重点方向一致吗

一个实用技巧：每天选一个知识点做「纸上差异」甄别

很多PMP理论到了职场就不对劲了，这很正常。关键是要识别差异，而不是硬套。

实际操作：每天选1个知识点，对比书本描述 vs 你的职场现实。

知识点	书本说的	我遇到的	适配方案
变更流程	正式CR→CCB评审→批准后更新基准	产品经理直接口头告诉我改需求	先记录变更，口头确认后补邮件，每周汇总一次统一处理
风险登记册	启动阶段全面识别，定性定量分析	项目时间紧，哪有时间做分析	简化版：只记4列——风险、概率(高/中/低)、影响(高/中/低)、应对方案

这份「纸上差异」记录，就是你的个人项目管理实战手册。它比任何教科书都更贴合你的工作。

本周任务

每天花15分钟，完成3件事：

✅ 学1个PMP知识点（范围/进度/风险…什么都行）
✅ 写1个具体的职场对应场景
✅ 记录1个「纸上差异」及适配方案

一周之后，你就有了一份专属的PMP场景对照表，这是后续所有实操的基础。

📌 今日动作：打开你的笔记软件，创建三个文件夹（人员域/过程域/商业环境域），然后写下今天第一个知识点映射。

📚 返回 PMP职场实战108问目录 →

本文作者：Samjoe Yang

本文链接： https://need.uno/002-ru-he-jian-li-zhi-shi-dian-dao-gong-zuo-chang-jing-de-yi-dui-yi-ying-she/

更新于 2026-07-14

# PMP # 项目管理 # 职场 # 基础铺垫 # 实操方法

社交媒体营销的ROI如何科学评估？

2026-06-20T20:00:00.000+08:00

企业管理的108个问题 · 第69问

上一问我们聊了什么是真正的"用户思维"（第68问），核心观点：用户思维不是口号，而是一种在每个决策点上站在用户场景中做判断的能力。

> 用户思维落地了，团队知道该往哪个方向使力了——但一个新的问题随之而来：

> 你在社交媒体上投的钱、花的时间、养的人，到底值不值？

"我们公众号有5万粉丝。" "抖音这个月播放量破百万了。" "小红书笔记互动率不错。"

这些话，我每周都能听到。但当我追问一句——"那这些账号给公司带来了多少实际的收入？"——大多数人会陷入沉默，或者给出一个含糊不清的回答："这个……不太好直接算。"

这不是管理者的错。社交媒体营销的ROI评估，本身就是营销领域最棘手的问题之一。原因在于：

曝光不等于效果——10万阅读量，可能一单转化都没有
社交媒体的影响力通常是"间接"的——用户可能看了你的内容，然后去搜索引擎搜了你的品牌，然后去电商平台下单——这中间的链路几乎无法追踪
品牌曝光的长期价值难以量化——今天的内容可能在一个月后才促成购买

但"不好算"不等于"不算"。今天我们就来拆解一套实操性强的社交媒体ROI评估体系。

一、先把"社交媒体ROI"拆清楚

很多人一上来就说"ROI = 收入/投入"，然后在"收入"这一栏卡住了。

问题出在哪里？ 社交媒体在不同的营销目标下，扮演的角色完全不同。你没法用同一把尺子去量所有账号。

根据营销目标的不同，社交媒体的价值要分三层来看：

第一层：直接转化型——"我要你马上下单"

这类账号的ROI最容易算。

典型场景：

抖音直播间——用户在直播间看中产品，当场下单
小红书带货笔记——文末挂购物链接
朋友圈广告——点击直接跳转购买页

计算公式：

直接ROI = (通过社交媒体直接产生的销售额 - 内容制作成本 - 投放成本) ÷ (内容制作成本 + 投放成本)

举个例子： 抖音直播一场投入2万（投流+主播+货品），当场成交8万。ROI = (8-2)/2 = 3。也就是1块钱投入换来3块产出。

这种方法最直接、最干净。但问题是——大多数社交媒体不属于这个类型。

第二层：间接转化型——"我让你记住我，然后你去别处买我"

这是最难算、也最常见的一类。

典型场景：

品牌公众号——用户看了文章，记住了品牌，下次有需求时主动搜索购买
品牌抖音号——不挂购物车，只做品牌内容
知乎品牌专栏——用户看了专业内容，建立了信任，后来通过其他渠道购买

间接转化的核心矛盾： 用户的最终购买确实是因为社交媒体种草了——但这个"因"和"果"之间可能隔了好几天、好几个渠道，你没法精准归因。

应对思路： 不追求"单篇文章"的ROI，而是追求"账号整体"对业务的拉动作用。

推荐方法：品牌搜索指数相关法。

操作方式：

记录社交媒体内容发布的节奏（每周发多少条、什么时间发）
对比同期品牌在搜索引擎上的"品牌词搜索量"
计算"内容发布"和"品牌搜索量"之间的相关性
品牌搜索量的提升 × 平均转化率 × 客单价 = 社交媒体的间接贡献

案例： 某新消费品牌发现，每次在小红书上投放笔记后的72小时内，品牌词在淘宝上的搜索量会提升25%-40%。他们用这个方法估算出：小红书的投放间接带动的月均销售额约50万——是直接投放链接成交金额的2.5倍。

第三层：品牌建设型——"我让你对我产生好感，以后你优先选我"

这是最"软"但长期价值最大的社交媒体功能。

典型场景：

品牌通过精心策划的内容建立行业影响力
通过持续的用户互动建立品牌好感度
通过价值观输出获取忠实粉丝

这类"收益"几乎无法在短期内用"卖了多少钱"来衡量。 但忽视它，又是短视行为。

衡量方法：使用"品牌健康度"指标体系。

核心指标包括：

品牌主动提及率——用户在讨论相关话题时，是否会主动提到你的品牌
品牌好感度——社交媒体的正面/负面评价比例
NPS（净推荐值）——用户会推荐你的产品给朋友吗
内容二次传播率——用户是否自愿转发你的内容（而不是你花钱投流）

这些指标看似"虚"，但它们是未来销售的"蓄水池"。 品牌健康度下降了，现在的销售额可能还没降——但三个月到半年后，一定会反映在销量上。

二、落实到具体操作：四步ROI评估法

讲完了三层价值模型，现在来说一个可落地的四步流程。

第一步：明确目标——你的社交媒体到底要实现什么？

在开始做ROI评估之前，先回答一个问题：这个账号/这轮投放的核心目标是什么？

很多企业的问题就在这里——又想曝光、又想转化、又想涨粉、又想带货——结果哪个都做不好。

正确做法：一个阶段只盯一个核心目标。

阶段	核心目标	核心指标	评估周期
冷启动期	品牌曝光	阅读量、播放量、粉丝增长	月度
成长期	用户互动	互动率、转发率、评论质量	周度
成熟期	商业转化	直接转化率、CAC（获客成本）	每日
品牌期	品牌资产	NPS、主动提及率、搜索指数	季度

关键：不同阶段用不同指标评估。 不要在冷启动期追求ROI——一个只有1万粉丝的账号，谈"转化率"没有意义。同样，不要在成熟期只看阅读量——10万阅读量但零转化，说明你的内容跟产品的关联太弱。

第二步：建立"归因模型"

归因是社交媒体ROI评估中最难、也最关键的一环。

推荐三种企业用得上的归因方法：

方法一：UTM参数追踪（适合有官网/电商页面的企业）

所有社交媒体发布的链接，都带上UTM参数。这样Google Analytics/百度统计就能告诉你：哪条内容、哪个平台、哪个时间的流量带来了多少次访问和转化。

示例：https://yourstore.com/productA?utm_source=wechat&utm_medium=article&utm_campaign=summer2026

这个方法的局限：只能追踪"点击链接"的行为。用户看完你的内容、没有点链接、然后自己去搜索品牌进入店铺的——这种情况追踪不到。

方法二：转化归因窗口期法（适合有CRM系统的企业）

设定一个"归因窗口期"（通常是7天或30天），统计在窗口期内接触过社交媒体内容的用户，和没有接触过的用户，对比两组用户的转化率差异。

具体操作：

识别在社交媒体上与你互动的用户（点赞、评论、私信、点击）
标记这些用户为"社交媒体接触组"
对比"接触组"和"非接触组"在窗口期内的转化率

如果接触组的转化率明显高于非接触组，这个差异就是社交媒体的贡献。

方法三：调研归因法（最简单、适合所有企业）

在用户的购买流程中，加入一个简单的调研问题：

"您是通过什么渠道了解到我们品牌的？"

A. 朋友推荐
B. 社交媒体（请注明平台）
C. 搜索引擎
D. 线下门店
E. 其他

每个月汇总一次数据，看看社交媒体带来的"第一触达"占比——然后用这个占比乘以总销售额，估算社交媒体在"拉新"上的贡献。

这个方法不精确，但胜在——"粗估"好过"不估"。

第三步：区分"内容成本"和"投放成本"

很多企业算ROI的时候，只算了"投了多少钱做广告"，没算"养了什么人做内容"。

完整的社交媒体成本 = 内容制作成本 + 运营人力成本 + 投放广告成本

内容制作成本：

写一篇文章需要多少时间？按员工时薪折算
拍一条视频需要多少制作费？摄影、剪辑、道具
做一张海报的设计成本

运营人力成本：

账号日常维护（回复评论、私信、内容排期）
社群运营人员工资
数据分析人员的时间分摊

投放广告成本：

抖音DOU+、小红书薯条、微博粉丝通
KOL/KOC合作费用
信息流广告投放

把这三类成本都算进去，才是真实的社交媒体投入。 很多企业只算投放，不算内耗——结果ROI看起来超高，但一算总账，团队养了半年只发了30篇阅读量不过千的文章——这种"低效内容"的成本被忽略了。

第四步：定期复盘，建立"数据→决策"的闭环

ROI评估不是"算完了就完了"。算的目的是——优化投入方向。

一个简单有效的复盘框架：每月一次"社交媒体ROI复盘会议"，表格如下：

平台	投入（人力+制作+投放）	直接转化收入	间接转化收入（估算）	品牌指数变化	综合评估
抖音	3万	8万	5万	+15%	✅ 继续加大
公众号	2万	0.5万	3万	+5%	⚠️ 优化方向
小红书	1.5万	0.3万	7万	+22%	✅ 加大投放

通过这个表，你能清晰地看到：

哪个平台是"赚钱型"（直接转化高）
哪个平台是"种草型"（间接带动大）
哪个平台是"鸡肋型"（投入高产出低）

然后做出决策： 资源向高ROI的平台倾斜，低ROI的平台要么优化策略、要么砍掉。

三、四个行业案例：不同打法下的ROI逻辑

案例一：美妆品牌——小红书种草+抖音直播组合

某国货美妆品牌在2025-2026年采用的组合策略：

小红书：定义为"种草平台"

成本：每月约4万（KOC合作费用 + 内容制作）
目标：提升品牌搜索量和笔记覆盖量
衡量指标：品牌词搜索量提升、笔记互动率
结果：品牌词搜索量月均提升35%，笔记内容覆盖"精华液推荐"等核心关键词排名前三

抖音：定义为"收割平台"

成本：每月约6万（直播投流 + 主播费用）
目标：直接转化
衡量指标：直播间GMV、ROI
结果：月均直播GMV 25万，ROI = 4.2

综合ROI： 小红书负责"让用户记住你"、抖音负责"让用户买单"——两个平台合计月投入10万，月直接+间接GMV约40万，综合ROI = 3.0。

核心启示： 不要用同一个指标衡量不同平台。小红书的ROI看搜索增量，抖音的ROI看直接转化——两个指标一起看，才是完整的全盘视角。

案例二：B2B软件公司——LinkedIn/知乎的内容营销

B2B的社交媒体ROI和消费品完全不同——用户决策周期长、客单价高、购买决策理性。

某SaaS公司的方法：

知乎：发行业深度文章

每月投入：约1.5万（内容团队 + 知+投放）
核心指标：咨询量、试用注册量
效果：每篇深度文章平均带来12-18个试用注册，试用注册到付费的转化率约为15%
单客户获取成本（CAC）：约3000元（而传统渠道的CAC是6000-8000元）

LinkedIn：CEO个人品牌建设

每月投入：时间成本为主（CEO每周2小时 + 编辑1天）
核心指标：行业影响力、品牌主动提及率
效果：CEO的LinkedIn文章在行业内的分享率超过行业平均水平3倍，品牌在"企业服务"相关话题中的提及率进入前十

核心启示： B2B的社交媒体不追求"爆款"，追求"精准"——一篇被100个精准客户看到的文章，比100万次泛流量有价值得多。ROI的衡量标准应该是"质量指标"而非"数量指标"。

案例三：本地餐饮品牌——抖音同城号

某连锁餐饮品牌主打同城餐饮，他们的打法很聚焦：

只做抖音本地生活：不做小红书、不做公众号。

投入：每月约1.2万（拍摄 + 投流 + 团购达人合作）
内容策略：只做"到店就餐"的"爆款"展现——看得见的诱人场景
核心指标：团购券核销率（不是点击率，不是曝光量，是"买了券并且到店用了"的比例）
结果：月均团购核销收入8-10万，ROI = 6.5

他们的核心ROI逻辑： "我们的目标很清晰——让看到视频的人到店吃一顿。不在短视频里放品牌故事、不放企业理念——就放食物。抖音本地生活在餐饮行业的ROI之所以高，是因为"看得见 → 想吃了 → 买了券 → 来吃了"这条路径最短，几乎没有衰减。"

一针见血。 社交媒体ROI最高的案例，往往不是那些"做得最花哨"的，而是"目标最清晰、路径最短"的。

案例四：新消费品牌的"品牌内容组合拳"

尝试了多种内容形式后，最核心的经验是：不同类型的社交媒体内容要有不同的ROI逻辑。

他们的四类内容：

种草内容（KOL合作） → 目标：拉新，衡量：AIPL（认知-兴趣-购买-忠诚）漏斗各层级的流转
干货内容（品牌号） → 目标：建立专业度，衡量：收藏/转发比
互动话题（社群） → 目标：促活，衡量：UGC产出量
促销内容（信息流） → 目标：收割，衡量：ROI（直算）

"不是所有内容都要产生销售。好的社交媒体团队知道：10篇内容里，可能只有1篇是直接冲着销售去的。但另外9篇都在帮这1篇打基础。"

四、社交媒体ROI评估的三个常见陷阱

陷阱一：只看"最后一跳"，忽视"第一跳"的价值

这是最经典的错误。电商平台的数据显示，今天"搜品牌名下单"的用户，很可能三天前在小红书上看到了你的种草笔记——但电商平台的归因系统把这个转化归给了"搜索渠道"，而不给社交媒体半分功劳。

应对方法： 建立"多触点归因"的观念。不要把"最后一跳"当成全部。对于品牌认知型的内容，用自己的CRM或调研数据做补充归因。

陷阱二：把"虚假繁荣"当"真实效果"

买粉、刷量、做假数据——这些操作能把KPI做得很好看，但对业务一点帮助都没有。

如何鉴别数据的真实性？

粉丝增长曲线：正常账号的粉丝增长是波动的，刷量账号的增长是一条"直线"
互动率的合理性：正常账号互动率在0.5%-3%之间，一个账号互动率长期低于0.1%——要么内容太差，要么粉丝是"假粉"
评论的内容质量：刷量评论通常是机械的"好棒""加油""已收藏"——正常用户的评论是具体的、有态度的

管理者要警惕：一个团队如果长期用"假数据"汇报，整个团队的方向都会偏——他们不是在为业务创造价值，而是在为"数据好看"而工作。

陷阱三：只算"投入产出比"，不算"时间成本"

社交媒体营销需要"养"——很少有账号能做到"一开就火"。

一个公众号可能需要半年以上才能稳定带来客户。 这段时间的"投入"算不算？

算。而且必须算。

但很多企业会犯一个错误：用"这个月的ROI"来评判"这个月才开始做的账号"。

正确的做法：

新账号：前3个月不计ROI，只计"增长效率"（粉丝增长、内容覆盖）
稳定账号：按月计ROI
成熟账号：按周计ROI

五、总结：不完美的评估，胜过完美的回避

社交媒体营销ROI的评估，永远不可能像"投了一块钱、赚了两块钱"那么简单。

但正因为难，才更需要做。

三个核心建议：

别追求"精确"——先追求"有数"
粗估的数据比没有数据强一百倍
即使只能"估算"社交媒体的间接贡献——那也是"有依据的估算"
每月复盘一次数据，不出半年你就会形成一套自己的"ROI参考系"
不同平台不同标准
抖音看转化，小红书看种草，公众号看深度影响力
用"平台特性"而不是"统一公式"来设定KPI
把ROI评估当成"优化工具"而非"审判工具"
ROI低的不要急于砍掉，先看看是不是"归因方式"的问题
ROI高的也别急着加码，先看看是不是"阶段性红利"——有些平台的起步红利期一过，ROI就会迅速下滑

最后送一句话：社交媒体营销最怕的不是"算不清"——而是"不想算"。

想算了，就有方法。不想算，就是管理者的懒惰。

⬅️ 返回目录 明日预告：第70问 —— 精益生产和敏捷管理在不同行业的应用？

unobox TTS 多引擎集成评估报告

2026-06-15T07:00:00.000+08:00

评估日期：2026-06-05 | 评估对象：unobox 桌面端 (Electron)

评估范围：本地引擎 4 种 + 国内云 5 种 + 国际云 5 种，共 14 种方案

一、现状分析

有利条件（已有基础设施）

基础设施	状态	说明
音频播放引擎 (`useAudioEngine`)	✅ 完整	隐藏 `HTMLAudioElement`，支持 blob URL、进度保存
媒体播放器 Store (`useMediaPlayerStore`)	✅ 完整	队列管理、倍速、循环模式、Mini/Full 两种 UI
播放器 UI (`MiniPlayer` / `FullPlayer`)	✅ 完整	迷你播放栏 + 全屏播放器，开箱即用
自定义协议 (`unbox-file://`)	✅ 完整	支持 Range 请求、流式传输大文件
IPC 桥接模式	✅ 完整	`namespace:action` 约定，流式/非流式两种模式
`IServerProvider` 多 Provider 架构	✅ 完整	TTS 引擎切换可直接复用 ProviderManager 热插拔模式
`MediaSource` 类型	✅ 已预留 `'ai'`	在 `audioPlayer.ts` 第 8 行，直接可用

缺失部分

零 TTS 代码。无语音合成引擎、无语音下载管理、无 TTS 设置界面。

二、TTS 引擎全景对比

2.1 引擎分类

TTS 引擎全集（14 种） ├── 🏠 本地离线引擎（4 种） │ ├── Sherpa-ONNX + Kokoro ← 主力：中英文双语高质 │ ├── Supertonic TTS ← 极速：英文/韩文 │ ├── Piper TTS ← 兜底：40+ 语言覆盖 │ ├── PaddleSpeech ← 开源：中文离线（Python子进程） │ └── Pico TTS (SVOX) ← 不推荐：无中文 │ ├── 🇨🇳 国内云 TTS（4 种）—— 中文质量最优 │ ├── 阿里云 TTS (Qwen3-TTS) ← 综合最佳 │ ├── 火山引擎 TTS (豆包语音) ← 长文本最低价 │ ├── 腾讯云 TTS ← 预付费最便宜 │ └── 百度智能云 TTS ← 免费额度最大方 │ └── 🌍 国际云 TTS（5 种）—— 多语言/高质量 ├── OpenAI TTS ← AI 原生，gpt-4o-mini-tts ├── Google Cloud TTS ← 语言最多（75+） ├── Amazon Polly ← AWS 生态 ├── Azure Speech ← 国内版便宜

└── ElevenLabs ← 质量天花板 + 语音克隆

2.2 本地引擎核心指标对比

维度	Sherpa-ONNX + Kokoro	Supertonic TTS	Piper TTS	PaddleSpeech	Pico TTS
语音质量	⭐⭐⭐⭐⭐ TTS Arena #1	⭐⭐⭐⭐ 自然稳定	⭐⭐⭐⭐ 自然流畅	⭐⭐⭐⭐ 中文良好	⭐⭐ 机械感强
中文支持	✅ 8 种中文语音	❌ 不支持	✅ 约 5-6 种	✅ 中文原生	❌ 不支持
语言总数	~10 种	31 种（无中文）	40+ 种	~10 种	仅 6 种
模型体积	~160MB	~99MB	30-80MB/语音	~300MB（完整）	~2MB
CPU 推理	~1-3x 实时	167x 实时	>1x 实时	~1-3x 实时	极快
GPU 推理	CUDA 可选	1000x 实时	不支持	不支持	不支持
流式合成	✅	❌（分块模式）	✅	✅（服务模式）	❌
集成方式	npm 原生插件 / WASM	npm 原生插件	CLI 子进程	Python CLI 子进程	CLI 子进程
许可协议	Apache 2.0	MIT / OpenRAIL-M	MIT	Apache 2.0	Apache 2.0
活跃维护	✅ 非常活跃	✅ 极其活跃	✅ 活跃	✅ 活跃	❌ 近乎停止
在 unobox 中的定位	主力引擎	英文极速引擎	编译失败兜底	中文离线备选	不推荐

2.3 国内云 TTS 核心指标对比

维度	阿里云 (Qwen3-TTS)	火山引擎 (豆包语音)	腾讯云	百度智能云
中文质量	⭐⭐⭐⭐⭐ WER 1.9%	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐
语音数量	49 种音色	多款基础+精品	标准+精品+大模型	基础+精品+臻品+大模型
方言支持	✅ 9 种方言	部分支持	部分支持	✅ 粤语等
免费额度	100 万字符/月	基础音色免费	精品 800 万字符（3 月）	个人 5 万次（180 天）
长文本单价	¥0.8/万字符	¥1.0/万字符	¥0.75/万字符（预付费）	¥1.7/万字符
短文本单价	¥1.0/千次（预付费）	¥4/千次	—	¥12/万次（预付费）
流式合成	✅	✅	✅	✅（WebSocket）
Node.js SDK	✅ DashScope SDK	✅ `@volcengine/openapi`	✅ `tencentcloud-sdk-nodejs-tts`	❌ 需手动 HTTP
自定义语音	✅ 10 个免费音色	✅ 声音复刻	❌	✅ 个性化定制
SSML 支持	✅ 完整	✅	✅	✅
在 unobox 中的定位	国内首选远程	长文本性价比王	预付费最省钱	免费额度最慷慨

2.4 国际云 TTS 核心指标对比

维度	OpenAI TTS	Google Cloud TTS	Amazon Polly	Azure Speech	ElevenLabs
语音质量	⭐⭐⭐⭐⭐ AI 原生	⭐⭐⭐⭐⭐ Chirp 3 HD	⭐⭐⭐⭐ 可接受	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐ 行业最佳
免费额度	$5 新用户赠送	标准 400 万字符/月	标准 500 万字符/月（首年）	神经 50 万字符/月	1 万字符/月
神经语音价	$15/百万字符	$16/百万字符	$16/百万字符	$15/百万字符	$5/月起（订阅制）
中文支持	✅ 但偏僵硬	✅ 普通话/粤语	✅ 普通话/粤语	✅ 普通话/粤语	✅ 多语言 v2
语言总数	~20 种	75+ 种	40+ 种	50+ 种	30+ 种
语音数量	13 种（含 gpt-4o-mini-tts）	380+	100+	300+	按需克隆
流式合成	✅ 实时流式	✅	✅	✅	✅ 极低延迟
语音克隆	❌	✅ Instant Custom Voice	✅ Brand Voice	✅ Custom Neural Voice	✅ 从 1 分钟音频
Node.js SDK	✅ `openai`	✅ `@google-cloud/text-to-speech`	✅ `@aws-sdk/client-polly`	✅ `microsoft-cognitiveservices-speech-sdk`	✅ REST API
输出格式	MP3/Opus/AAC/FLAC/WAV	MP3/WAV/OGG/PCM	MP3/OGG/PCM	MP3/WAV/OGG/PCM	MP3/WAV/OGG/PCM
速度控制	✅ 0.25-4.0x	✅ SSML	✅ SSML	✅ SSML	✅
在 unobox 中的定位	AI 对话最佳	语言覆盖最广	成本最低国际	国内节点便宜	高端付费首选

2.5 PaddleSpeech 详细分析

PaddleSpeech 是百度飞桨开源的端到端语音工具包，不同于百度智能云的商业 API，它是完全本地运行的。

特性	说明
定位	开源离线语音工具包（Apache 2.0）
中文模型	`fastspeech2_csmsc` / `tacotron2_csmsc` + `hifigan_csmsc` 声码器
中英混合	`fastspeech2_mix` 模型支持中英混合合成
多音色	174 个多说话人模型（CSMSC 数据集，仅限非商业用途）
流式合成	✅ 支持 HTTP 流式服务模式
ONNX 加速	✅ `use_onnx=True` 启用 ONNX Runtime 推理加速
安装	`pip install paddlepaddle paddlespeech`
首次使用	自动下载预训练模型（数百 MB），之后可离线
集成方式	Python CLI 子进程（`paddlespeech tts --input "..." --output out.wav`）
自定义语音	✅ 语音克隆模型 AISHELL3-VC + 声音转换
关键限制	CSMSC 数据集非商业许可；需 Python + PaddlePaddle 环境（额外 ~2GB）
在 unobox 中的定位	开源可定制中文备选；Python 依赖是最大门槛，适合开发者/极客

三、集成方案推荐

3.1 架构设计：统一的 ITTSProvider 接口

项目已有 IServerProvider 多服务商架构（ProviderManager 管理多个 Provider 热插拔），TTS 引擎切换可直接复用此模式。ITTSProvider 接口对调用方来说，本地 Kokoro 和远程 OpenAI TTS 没有任何区别：

// packages/core/src/providers/ITTSProvider.ts（新增）

interface ITTSProvider {
  readonly id: string // 'sherpa-onnx' | 'supertonic' | 'piper-cli' | 'paddlespeech' |
                      // 'aliyun-qwen3' | 'volcengine' | 'tencent-cloud' | 'baidu-cloud' |
                      // 'openai' | 'google-cloud' | 'amazon-polly' | 'azure-speech'
  readonly name: string      // 展示名称
  readonly type: 'local' | 'remote'
  readonly priority: number  // 推荐排序

  /** 当前环境是否可用 */
  isAvailable(): Promise<boolean>

  /** 已安装/已配置的语音列表 */
  getVoices(): Promise<TTSVoice[]>

  /** 合成语音 → 返回 PCM/WAV buffer */
  synthesize(text: string, voiceId: string, opts: TTSOptions): Promise<AudioResult>

  /** 流式合成（长文本逐句输出） */
  synthesizeStream?(text: string, voiceId: string, opts: TTSOptions): AsyncIterable<AudioChunk>

  /** 远程引擎特有：是否需要 API Key */
  readonly requiresAuth: boolean

  /** 远程引擎特有：设置认证凭据 */
  setCredentials?(credentials: TTSApiCredentials): Promise<{ valid: boolean; error?: string }>

  /** 安装/更新引擎 */
  install?(): Promise<{ success: boolean; error?: string }>

  /** 下载语音模型 */
  downloadVoice?(voiceId: string, onProgress?: (pct: number) => void): Promise<{ success: boolean }>

  /** 释放资源 */
  dispose(): void
}

3.2 系统架构图

渲染进程（Renderer）主进程（Main Process） ══════════════════════ ════════════════════════════ TTSStore (Zustand) TTSManager（类似 ProviderManager） ├─ currentEngine: ITTSProvider ├─ engines: ITTSProvider[] ├─ voices: TTSVoice[] │ │ ├─ preferences: │ ├─ 🏠 本地引擎（4 种） │ ├─ enginePriority: 'local-first' │ │ ├─ SherpaOnnxProvider（主力） │ └─ fallbackChain: [...] │ │ ├─ SupertonicProvider（极速英文） │ │ │ ├─ PiperCliProvider（兜底） IPC bridge │ │ └─ PaddleSpeechProvider（中文开源） ┌──────────────────────────┐ │ │ │ api.tts.* │ │ ├─ 🇨🇳 国内云（4 种） │ - getEngines() │ │ │ ├─ AliyunQwen3Provider │ - setEngine() │ │ │ ├─ VolcengineProvider │ - getVoices() │ │ │ ├─ TencentCloudProvider │ - speak() │ │ │ └─ BaiduCloudProvider │ - speakStream() │ │ │ │ - setCredentials() │ │ └─ 🌍 国际云（5 种） │ - downloadVoice() │ │ ├─ OpenAIProvider │ - previewVoice() │ │ ├─ GoogleCloudProvider └──────────────────────────┘ │ ├─ AmazonPollyProvider │ ├─ AzureProvider useMediaPlayerStore │ └─ ElevenLabsProvider └─ playOrEnqueue({ source: 'ai' }) │ ├─ VoiceManager（统一模型/语音管理） MiniPlayer / FullPlayer │ ├─ 模型下载（Hugging Face / 各云存储） └─ 零改动，完全复用 │ ├─ 缓存管理（{userData}/tts-models/） │ └─ 格式校验 │ └─ IPC Handlers ├─ tts:get-engines / tts:set-engine ├─ tts:get-voices / tts:download-voice ├─ tts:speak / tts:speak-stream

└─ tts:set-credentials

3.3 各引擎集成方式总结

类别	引擎	集成方式	技术栈	复杂度
🏠 本地	Sherpa-ONNX + Kokoro	npm 预编译平台包 + WASM 兜底	onnxruntime-node	⭐⭐ 中
🏠 本地	Supertonic TTS	官方 nodejs/ 移植，4 个 ONNX session	onnxruntime-node	⭐⭐ 中
🏠 本地	Piper TTS	CLI 子进程 stdin→stdout	child_process	⭐ 低
🏠 本地	PaddleSpeech	Python CLI 子进程	child_process (Python)	⭐⭐ 中
🇨🇳 国内云	阿里云 Qwen3-TTS	DashScope SDK / REST API	`dashscope` npm	⭐ 低
🇨🇳 国内云	火山引擎	OpenAPI SDK	`@volcengine/openapi` npm	⭐ 低
🇨🇳 国内云	腾讯云	专用 SDK	`tencentcloud-sdk-nodejs-tts`	⭐ 低
🇨🇳 国内云	百度智能云	HTTP REST（无 SDK）	axios + Bearer Token	⭐ 低
🌍 国际云	OpenAI	OpenAI Node.js SDK	`openai` npm	⭐ 低
🌍 国际云	Google Cloud	官方 gax 客户端	`@google-cloud/text-to-speech`	⭐ 低
🌍 国际云	Amazon Polly	AWS JS SDK v3	`@aws-sdk/client-polly`	⭐ 低
🌍 国际云	Azure Speech	Speech SDK	`microsoft-cognitiveservices-speech-sdk`	⭐ 低
🌍 国际云	ElevenLabs	REST API	axios + API Key	⭐ 低

关键观察：远程引擎的集成复杂度普遍为 ⭐ 低。 本质都是 HTTP API 调用 → JSON/base64 音频响应，比本地 ONNX 推理简单得多。第一个远程引擎约需 1 天（搭认证框架），后续每个仅需 0.5 天。

四、各引擎差异化定位与推荐策略

核心原则：本地免费默认，云端增值可选

unobox 是一款私有 IM 应用，本地离线是核心竞争力。TTS 引擎的分层策略如下：

所有用户 ──→ 🏠 本地引擎（默认、免费、零配置） ├─ 开箱即用，无需 API Key，无需网络 ├─ 预打包 1 个保底语音（<15MB），其余按需二次下载 └─ 覆盖 90% 日常场景高价值用户 ──→ ☁️ 远程云端引擎（可选、高质量、需自备 API Key） ├─ 用户自行注册云服务商账号，自行管理配额和费用 ├─ unobox 仅提供设置页面的 API Key 配置入口

└─ 不做代理、不做中转、不计费

产品设计上的体现：

TTS 设置页默认展示本地引擎，远程引擎折叠在"☁️ 云端引擎（高级）"分区
远程引擎分区标注"需自行申请 API Key，可能产生费用"
本地引擎始终作为降级链的最终兜底

4.1 用户场景 → 引擎映射（本地默认版）

┌────────────────────────────┬──────────────────────┬───────────────────────────┬─────────────────────┐ │ 场景 │ 默认引擎（本地免费） │ 升级引擎（云端增值） │ 不推荐 │ ├────────────────────────────┼──────────────────────┼───────────────────────────┼─────────────────────┤ │ AI 对话语音回复（中英双语） │ Sherpa-ONNX + Kokoro │ 阿里云 Qwen3-TTS │ Pico（无中文） │ │ AI 对话语音回复（纯英文） │ Supertonic │ OpenAI / ElevenLabs │ PaddleSpeech │ │ 消息朗读（中文） │ Kokoro │ 阿里云 Qwen3-TTS │ Pico / Supertonic │ │ 消息朗读（英文） │ Supertonic │ OpenAI TTS │ Pico │ │ 消息朗读（日/韩/德等） │ Piper TTS │ Google Cloud TTS │ Supertonic（无中文） │ │ 极低配设备兜底 │ MATCHA-TTS (<10MB) │ Piper low 质量 │ PaddleSpeech │ │ 高质量中文配音（专业需求） │ — │ 阿里云 / 火山引擎 │ — │ │ 语音克隆需求（专业需求） │ — │ ElevenLabs / Azure Custom │ 本地引擎 │ │ 开源可定制中文 TTS │ PaddleSpeech │ Kokoro │ — │ │ 数据隐私优先 │ 本地引擎（全部） │ — │ 全部远程引擎 │ │ 断网环境 │ 本地引擎（全部） │ — │ 全部远程引擎 │

└────────────────────────────┴──────────────────────┴───────────────────────────┴─────────────────────┘

核心变化：默认列全部是本地免费引擎。 远程云端引擎仅在用户主动配置 API Key 后才出现在可选列表中。

4.2 推荐优先级

═══════════════════════════════════════════════════════════════ 🏠 Phase 1：本地引擎（免费默认，首批交付，12-18 天） ═══════════════════════════════════════════════════════════════ 目标：覆盖 90% 用户的日常 TTS 场景，零成本、零配置、零网络依赖 ├─ Sherpa-ONNX + Kokoro-multi-lang（中英文双语主力） ├─ Supertonic（极速英文加速引擎） ├─ Piper CLI（编译失败兜底 + 多语言扩展） ├─ MATCHA-TTS / Piper low 质量（极低配保底语音，<15MB 预打包） └─ 设置 UI： ├─ 引擎状态（已就绪/未安装） ├─ 语音浏览 + 下载管理 + 试听预览 ├─ 语速/音调调节 └─ 语音包二次下载（首次启动后台静默下载主力语音） ═══════════════════════════════════════════════════════════════ ☁️ Phase 2：远程云端引擎（增值升级，+4-6 天） ═══════════════════════════════════════════════════════════════ 目标：为高价值用户提供更高质量的云端 TTS 选项前提：用户自行申请云服务商 API Key，自行承担费用 ├─ 🇨🇳 国内云：阿里云 Qwen3-TTS / 火山引擎 / 腾讯云 / 百度智能云 ├─ 🌍 国际云：OpenAI / Google Cloud / Azure / Amazon Polly ├─ 设置 UI 新增： │ ├─ "☁️ 云端引擎（高级）"折叠分区 │ ├─ API Key 配置 + 验证 + 本地加密存储 │ ├─ 隐私声明弹窗（强制确认） │ └─ 可用额度查询（远程引擎带有用量估算） └─ 降级链：远程超时/失败 → 自动切回本地引擎 ═══════════════════════════════════════════════════════════════ 💎 Phase 3：专业增强（+2-3 天） ═══════════════════════════════════════════════════════════════ ├─ ElevenLabs（语音克隆 + 顶级质量，订阅制） ├─ PaddleSpeech（开源可定制中文 TTS，Python 依赖） └─ Amazon Polly（AWS 生态用户备选）不推荐:

└─ 🏠 Pico TTS（无中文，MATCHA-TTS 替代）

4.3 引擎自动选择逻辑（本地默认，云端需主动启用）

function selectEngine(
  userLang: string,
  hardwareTier: 'high' | 'mid' | 'low',
  hasRemoteConfigured: boolean // 用户是否主动配置了远程引擎
): ITTSProvider {

  // ── 默认路径：纯本地引擎（所有用户都走这里）──
  // 中文用户
  if (userLang.startsWith('zh')) {
    if (sherpaOnnx.isAvailable()) return sherpaKokoroProvider // Kokoro 中文
    if (paddleSpeech.isAvailable()) return paddleSpeechProvider // 开源备选
    return piperCliProvider // Piper 最终兜底
  }

  // 英文/韩文用户
  if (['en', 'ko'].includes(userLang)) {
    if (supertonic.isAvailable()) return supertonicProvider // 极速首选
    if (sherpaOnnx.isAvailable()) return sherpaKokoroProvider // Kokoro 备选
    return piperCliProvider
  }

  // 其他语言用户
  if (sherpaOnnx.isAvailable()) return sherpaOnnxProvider // Sherpa 多语
  return piperCliProvider // Piper 40+ 语言兜底

  // ── 注意：远程引擎不会出现在自动选择逻辑中 ──
  // 远程引擎仅在用户同时满足以下条件时才可选：
  // 1. 已在设置页主动配置 API Key
  // 2. 已通过隐私声明确认
  // 3. 在引擎切换器中手动选择了某个远程引擎
  // 远程引擎失败时 → 自动降级回上述本地引擎（用户无感知）
}

五、国内云 TTS 详细说明

5.1 阿里云 Qwen3-TTS（推荐首选）

项目	详情
模型	Qwen3-TTS，49 种音色，10 种语言 + 9 种方言，48kHz
WER	中文 1.9%，英文 2.8%（优于 Azure TTS）
免费额度	100 万字符/月（49 种音色全免费）
付费价格	¥0.8/万字符
Node.js SDK	`npm install dashscope`
调用方式	`dashscope.audio.speech({ model: 'qwen-tts', input: { text }, voice: 'longxiaoxia_v2', response_format: 'mp3' })`
特色	支持粤语/四川话/东北话；语音合成+识别双功能；流式实时合成
推荐指数	⭐⭐⭐⭐⭐ 国内远程首选

5.2 火山引擎（豆包语音TTS）

项目	详情
价格	长文本普通版 ¥1.0/万字符，情感预测版 ¥2.0/万字符
免费额度	基础音色完全免费；非基础音色年授权费 ¥1 万/个
短文本	≤300 字符/次，后付费 ¥4/千次（1 万次以上）
Node.js SDK	`npm install @volcengine/openapi`
特色	情感预测版溢价 100%；可与豆包大模型联动（同生态）；多场景音色定制
推荐指数	⭐⭐⭐⭐ 长文本性价比王者

5.3 腾讯云 TTS

项目	详情
免费额度	精品音色 800 万字符（领取后 3 个月有效）
价格	标准音色后付费 ¥1.9/万字符起，预付费最低 ¥0.75/万字符
精品音色	¥2.8/万字符（后付费小体量比火山高 180%）
Node.js SDK	`npm install tencentcloud-sdk-nodejs-tts`
特色	预付费资源包可退款（7 天内）；大模型音色 + 超自然大模型音色
推荐指数	⭐⭐⭐⭐ 预付费最省钱

5.4 百度智能云 TTS

项目	详情
免费额度	个人认证：基础音库 5 万次/180 天；企业认证：1 亿次/180 天
价格	短文本基础音库 ¥12/万次（预付费）；长文本 ¥1.7/万字符
大模型音色	度涵竹/度嫣然/度泽言/度怀安/度小粤等，与精品音库同价
Node.js SDK	无专用 SDK，HTTP REST 调用（axios + Bearer Token）
接口特点	短文本最长 500 汉字；长文本最长 10 万字（异步）；流式 WebSocket 协议
推荐指数	⭐⭐⭐ 免费额度最慷慨（适合企业认证）

5.5 国内云 TTS 价格速查

场景	最便宜方案	单价
🆓 量少免费	百度智能云（个人）+ 阿里云 Qwen3	¥0
🀄 中文长文本	腾讯云标准预付费	¥0.75/万字符
🀄 中文后付费小体量	火山引擎普通版	¥1.0/万字符
🀄 中文短文本高频	阿里云 30 万千次包	¥1.0/千次
📞 中文质量优先	阿里云 Qwen3-TTS	¥0.8/万字符
🤖 对标 AI 通话	火山引擎情感预测版	¥2.0/万字符

六、国际云 TTS 详细说明

6.1 OpenAI TTS

项目	详情
模型	`tts-1` / `tts-1-hd` / `gpt-4o-mini-tts`
价格	`tts-1`: $15/M 字符；`tts-1-hd`: $30/M 字符；`gpt-4o-mini-tts`: $0.60/M 输入 token + $12/M 音频输出 token
实际成本	~$0.86/小时音频（tts-1）
语音数量	13 种（Alloy/Echo/Fable/Nova/Onyx/Shimmer/Ash/Ballad/Coral/Sage/Verse/Marin/Cedar）
gpt-4o-mini-tts 特色	语音指令定制（如"热情的意大利厨师"），Marin/Cedar 独占
Node.js SDK	`npm install openai` → `openai.audio.speech.create()`
中文	✅ 但偏僵硬，不如国内云
推荐指数	⭐⭐⭐⭐⭐ AI 对话原生场景首选

6.2 Google Cloud TTS

项目	详情
价格	标准 $4/M 字符；神经 $16/M 字符；Chirp 3 HD $30/M 字符；Gemini TTS token 制
免费额度	标准 400 万字符/月 + 神经 100 万字符/月；新用户 $300 赠送
语言	75+ 种，380+ 语音（所有引擎中最广）
Node.js SDK	`npm install @google-cloud/text-to-speech`
推荐指数	⭐⭐⭐⭐ 语言覆盖最广

6.3 Azure Speech

项目	详情
价格	神经 TTS $15/M 字符；国内版 ¥0.95/万字（非常便宜）
免费额度	神经 50 万字符/月
Node.js SDK	`npm install microsoft-cognitiveservices-speech-sdk`
推荐指数	⭐⭐⭐⭐ 国内版极便宜

6.4 Amazon Polly

项目	详情
价格	标准 $4/M 字符；神经 $16/M 字符；生成式 $30/M 字符
免费额度	标准 500 万字符/月 + 神经 100 万字符/月（首年）；新用户 $200 赠送
语言	40+ 种，100+ 语音
Node.js SDK	`npm install @aws-sdk/client-polly`
推荐指数	⭐⭐⭐ AWS 用户首选

6.5 ElevenLabs

项目	详情
价格	$5/月起（3 万字符）→ $99/月（50 万字符），订阅制非按量付费
免费额度	1 万字符/月
特色	从 1 分钟音频即可克隆语音；公认质量天花板
Node.js	REST API（axios + API Key）
推荐指数	⭐⭐⭐ 高端付费用户（语音克隆需求）

6.6 国际云 TTS 价格速查

场景	最便宜方案	单价
🆓 英文少量	Google 标准 + Amazon 标准（免费层内）	$0
🇺🇸 英文神经质量	Azure 国内版 / Google Neural	$15-16/M 字符
🏆 英文最佳质量	OpenAI tts-1 / ElevenLabs	$15/M 字符 / $5/月起
🌐 多语言覆盖	Google Cloud TTS（75+ 语言）	$4/M 字符起步
🇨🇳 中文	不推荐国际云（国内云质量更好且更便宜）	—

七、隐私与安全设计（远程引擎专项）

远程 TTS 引擎涉及文本内容离开用户设备，需要严格防护：

第一层：用户知情同意（强制）
 ┌─────────────────────────────────────────┐
 │ ⚠️ 启用远程 TTS 服务                     │
 │                                         │
 │ 您将朗读的消息文本将发送到第三方服务器     │
 │ 进行处理。请确认您已阅读并同意。          │
 │                                         │
 │ ☐ 我理解消息文本将离开本地设备            │
 │ ☐ 我同意服务商的数据处理条款             │
 │                                         │
 │ [取消]               [同意并配置 API Key] │
 └─────────────────────────────────────────┘

第二层：API Key 本地加密存储

所有 API Key 使用设备相关密钥 AES 加密后存储到 app_kv_store
不传输、不同步、不备份到任何远程位置
参考 device.getMachineId() 作为加密盐


第三层：引擎级降级保护

远程请求超时（5s）→ 自动回退到本地引擎
余额不足 / 配额超限 → 提示用户，同时切回本地
网络断开 → 静默切换，用户无感知

八、引擎降级策略

用户点击"朗读"消息时的引擎选择流程：检查用户偏好设置 ├─ "🔒 仅本地" → 跳过远程，直接用本地引擎 ├─ "☁️ 远程优先" → 先尝试远程，失败则降级 └─ "🏠 本地优先"（默认）→ 本地可用即用本地 🏠 "本地优先" 降级链（推荐默认）： Sherpa-ONNX Kokoro (<2s 生成) → Supertonic（英文） → Piper CLI → PaddleSpeech（中文备选） → 用户已配的远程引擎 → 全部失败 → 提示用户 ☁️ "远程优先" 降级链：阿里云 Qwen3-TTS (3s 超时，中文) → 火山引擎 (3s 超时) → 腾讯云 / 百度智能云 (3s 超时) → OpenAI / Google / Azure (3s 超时) → 本地 Kokoro（最终兜底）自动降级时的 UI 反馈： ┌─────────────────────────────────────┐ │ TTS 合成中... │ │ 🟡 远程引擎无响应，正在切换本地引擎... │ │ [取消朗读] │

└─────────────────────────────────────┘

九、各引擎集成难点与风险

9.1 共性难点

难点	风险等级	说明	缓解措施
原生 Node.js 插件跨平台分发	🟡 中	`onnxruntime-node` 和 `sherpa-onnx-node` 是原生插件	预编译平台包 + WASM 兜底
大文本合成延迟	🟡 中	长文本需数秒	按句切分流式分段合成
语音模型管理	🟡 中	格式不统一	VoiceManager 统一管理
API Key 安全存储	🟡 中	敏感凭据存储	AES 加密 + 设备指纹盐
Electron 打包体积	🟡 中	本地模型 100-250MB	模型按需下载，内置仅 1 个保底语音

9.2 各引擎特有风险

引擎	风险	等级	说明
Sherpa-ONNX	npm 插件编译失败	🟡	预编译包 + WASM 兜底
Supertonic	无中文	🔴	仅英文/韩文场景使用
PaddleSpeech	Python 环境依赖	🟡	需预装 Python + PaddlePaddle（~2GB）
阿里云	依赖 DashScope 平台	🟢	API 稳定，SDK 成熟
火山引擎	非基础音色年费	🟡	默认用基础音色免费
腾讯云	免费额度有时限	🟢	3 个月后转预付费
百度智能云	无 Node.js SDK	🟢	HTTP 调用简单，无额外依赖
OpenAI	中文发音僵硬	🟡	中文场景推荐国内云
Google Cloud	国内访问不便	🟡	国内用户建议用国内云
ElevenLabs	订阅制非按量	🟡	仅适应重度用户

十、需要新增的模块

新增文件清单（约 18 个文件） ═══════════════════════════════════════ 核心接口（1 个文件）: ├── packages/core/src/providers/ITTSProvider.ts # 统一 TTS Provider 接口 + 类型定义主进程 - 本地引擎实现（4 个文件）: ├── apps/desktop/src/main/tts/ │ ├── TTSManager.ts # 多引擎管理器（类似 ProviderManager） │ ├── providers/ │ │ ├── SherpaOnnxProvider.ts # Sherpa-ONNX 引擎（Kokoro + Piper/VITS） │ │ ├── SupertonicProvider.ts # Supertonic 引擎 │ │ ├── PiperCliProvider.ts # Piper CLI 子进程兜底 │ │ └── PaddleSpeechProvider.ts # PaddleSpeech Python CLI 主进程 - 远程引擎实现（9 个文件）: │ ├── providers/ │ │ ├── AliyunQwen3Provider.ts # 阿里云 Qwen3-TTS │ │ ├── VolcengineProvider.ts # 火山引擎 │ │ ├── TencentCloudProvider.ts # 腾讯云 │ │ ├── BaiduCloudProvider.ts # 百度智能云 │ │ ├── OpenAIProvider.ts # OpenAI TTS │ │ ├── GoogleCloudProvider.ts # Google Cloud TTS │ │ ├── AmazonPollyProvider.ts # Amazon Polly │ │ ├── AzureProvider.ts # Azure Speech │ │ └── ElevenLabsProvider.ts # ElevenLabs 主进程 - 辅助模块（2 个文件）: ├── apps/desktop/src/main/tts/ │ ├── VoiceManager.ts # 统一语音模型下载/缓存/校验 │ ├── CredentialStore.ts # API Key 加密存储 │ └── audio-utils.ts # PCM/WAV 格式转换 + 采样率适配预加载 + 类型（2 个文件修改）: ├── apps/desktop/src/renderer/src/env.d.ts # 新增 api.tts 类型声明 ├── apps/desktop/src/preload/index.ts # 新增 api.tts 桥接渲染进程（4 个文件）: ├── apps/desktop/src/renderer/src/store/useTTSStore.ts # TTS 状态管理 ├── apps/desktop/src/renderer/src/components/TTSSettings.tsx # TTS 设置页 ├── apps/desktop/src/renderer/src/components/RemoteTTSSetup.tsx # API Key 配置向导 ├── apps/desktop/src/renderer/src/components/TTSPrivacyNotice.tsx # 隐私声明弹窗 ├── apps/desktop/src/renderer/src/hooks/useTTSPlayer.ts # TTS 播放 Hook 主进程入口（1 个文件修改）:

└── apps/desktop/src/main/index.ts # 新增 tts:* IPC 处理器

十一、IPC 接口设计（最终版，覆盖本地+远程）

api.tts = {
  // ── 引擎管理 ──

  /** 获取所有可用引擎列表 */
  getEngines: () => Promise<{
    id: string
    name: string
    type: 'local' | 'remote'
    available: boolean
    version?: string
    recommended: boolean
    requiresAuth: boolean
    supportedLangs: string[]
    pricing?: string // 价格简写（如 "¥0.8/万字符" | "$15/M字符" | "免费"）
  }[]>

  /** 设置当前使用的引擎 */
  setEngine: (engineId: string) => Promise<{ success: boolean; error?: string }>

  /** 设置降级链 */
  setFallbackChain: (chain: string[]) => Promise<{ success: boolean }>

  /** 下载/安装指定引擎 */
  installEngine: (engineId: string, onProgress?: (pct: number) => void)
    => Promise<{ success: boolean; error?: string }>

  // ── 凭据管理（远程引擎） ──

  /** 设置远程引擎凭据 */
  setCredentials: (engineId: string, credentials: Record<string, string>)
    => Promise<{ valid: boolean; error?: string }>

  /** 验证凭据有效性 */
  validateCredentials: (engineId: string) => Promise<{ valid: boolean; quota?: number }>

  /** 移除凭据 */
  removeCredentials: (engineId: string) => Promise<{ success: boolean }>

  // ── 语音管理 ──

  /** 获取可用语音列表 */
  getVoices: (engineId?: string) => Promise<{
    id: string; name: string; lang: string
    quality: 'low' | 'medium' | 'high'
    sizeBytes?: number
    downloaded?: boolean  // 仅本地引擎
    price?: string        // 仅远程引擎的特殊语音
  }[]>

  /** 下载语音模型（仅本地引擎） */
  downloadVoice: (engineId: string, voiceId: string, onProgress?: (pct: number) => void)
    => Promise<{ success: boolean; error?: string }>

  /** 删除语音模型 */
  deleteVoice: (engineId: string, voiceId: string) => Promise<{ success: boolean }>

  // ── 合成 ──

  /** 合成语音（非流式） */
  speak: (text: string, opts?: {
    engineId?: string
    voiceId?: string
    speed?: number
    pitch?: number
    format?: 'wav' | 'mp3' | 'ogg'
  }) => Promise<{ success: boolean; filePath?: string; duration?: number; error?: string }>

  /** 流式合成（长文本分段，边生成边播放） */
  speakStream: (text: string, opts?: {
    engineId?: string
    voiceId?: string
    speed?: number
  }) => { cancel: () => void }

  /** 用指定语音合成测试文本并播放 */
  previewVoice: (engineId: string, voiceId: string) => Promise<{ success: boolean; error?: string }>

  // ── 偏好设置 ──

  /** 获取 TTS 偏好 */
  getPreferences: () => Promise<{
    engineId: string
    voiceId: string
    speed: number
    pitch: number
    privacyMode: 'local-only' | 'remote-ok' | 'remote-preferred'
    fallbackChain: string[]
  }>

  /** 更新 TTS 偏好 */
  setPreferences: (prefs: Partial<TTSPreferences>) => Promise<{ success: boolean }>
}

十二、与现有系统集成

现有系统	复用方式	改动量
`IServerProvider` 多 Provider 模式	TTS 完全复用，TTSManager ≈ ProviderManager	微小
`useMediaPlayerStore` + `useAudioEngine`	合成后的音频直接 `playOrEnqueue({ source: 'ai' })`	零改动
IPC 桥接 (`api.*` 命名空间)	新增 `api.tts`，遵循现有约定	约 100 行新增
设置页面 UI 模式	参考"数据与存储"三层递进布局	复用样式
`net.streamRequest` cancel 模式	TTS 流式合成的取消机制直接复用	参考即可
`@ffmpeg-installer` 二进制管理	本地引擎的二进制下载管理参照此模式	参考即可
`api.file.readBuffer` (unbox-file:// → blob URL)	合成后的 WAV 文件通过此协议访问和播放	零改动
`app_kv_store` SQLite 表	API Key 加密存储 + TTS 偏好持久化	新增 1 个表

十三、成本对比（以日均朗读 20 条消息、每条 200 字符为例）

月均 = 20 × 200 × 30 = 12 万字符/月

引擎	月度成本	年度成本	备注
🏠 本地引擎（全部）	¥0	¥0	磁盘 ~160MB
🇨🇳 阿里云 Qwen3	¥0	¥0	免费层内（100 万/月）
🇨🇳 火山引擎	¥0	¥0	基础音色免费
🇨🇳 腾讯云	¥0（首 3 月）	~¥9	首 3 月 800 万字符免费
🇨🇳 百度智能云	¥0	¥0	免费层内（个人 5 万次/180 天）
🌍 OpenAI tts-1	~$1.80	~$21.60	$15/M 字符
🌍 Google 标准	$0	$0	免费层内（400 万/月）
🌍 Google 神经	~$1.92	~$23.04	$16/M 字符
🌍 Amazon Polly 神经	$0（首年）	~$23	首年 100 万/月免费
🌍 Azure 神经	~$1.80	~$21.60	$15/M 字符
🌍 ElevenLabs	$5/月	$60	订阅制起步

结论：对个人用户正常使用量，无论是国内云还是国际云，基本都在免费层内，远程 TTS 实际成本为 ¥0。

十四、工作量估算（本地优先，云端增值）

核心策略

Phase 1 交付后即可发版，本地 TTS 功能完整可用。 Phase 2/3 的远程云端引擎按需叠加，不影响已上线功能。

14.1 分阶段估算

阶段	内容	工时	备注
Phase 0：接口设计	`ITTSProvider` + `TTSManager` + `VoiceManager` + `CredentialStore`	1-2 天	覆盖本地+远程，但 Phase 1 只实现本地
Phase 1a：主力本地引擎	Sherpa-ONNX (Kokoro/Piper) + Supertonic + 语音模型下载管理	5-6 天	首个引擎最耗时
Phase 1b：本地兜底	Piper CLI 子进程 + MATCHA-TTS 预打包保底语音	1-2 天	编译失败 + 极低配设备
Phase 2a：统一 Store	`useTTSStore`（引擎切换/语音列表/合成队列/偏好持久化）	1-2 天	本地引擎阶段即可完成
Phase 2b：消息集成	右键"朗读"按钮 + TTS 播放指示器 + AI 对话自动朗读	1-2 天
Phase 3a：设置 UI	引擎状态展示 + 语音浏览/下载/试听 + 语速/音调调节	2-3 天	不含远程引擎分区
Phase 3b：测试打磨	跨平台测试 + 引擎降级测试 + 语音模型下载异常处理	2-3 天
🏠 本地引擎合计		14-20 天	此阶段完成即可发版
Phase 4：远程云端引擎	8 个远程 Provider + API Key 配置 UI + 隐私声明 + 降级链	4-6 天	本地引擎发版后开始
Phase 5：高端增强	ElevenLabs + PaddleSpeech	2-3 天	语音克隆 + 开源中文
☁️ 远程引擎增量合计		+6-9 天	叠加到本地引擎之上
🏆 全部合计		20-29 天	本地 14-20 + 远程 6-9

14.2 推荐交付节奏

里程碑	包含内容	工时	用户可感知
🚀 v1.0 本地免费版	Sherpa-ONNX (Kokoro) + Supertonic + Piper CLI + MATCHA-TTS + 设置 UI + 消息朗读	14-20 天	✅ TTS 功能完整可用
☁️ v1.1 云端增值版	阿里云 + 火山引擎 + 腾讯云 + 百度智能云 + OpenAI + Google + Azure	+4-6 天	✅ 高级用户可配 API Key
💎 v1.2 专业增强版	ElevenLabs + PaddleSpeech + Amazon Polly	+2-3 天	✅ 语音克隆等专业场景

14.3 与有声书的叠加

有声书功能严重依赖 TTS 引擎。日程安排：

v1.0 本地 TTS（14-20 天） │ └─→ v1.0 + 有声书（+11-18 天） = 总计 25-38 天 │ └── 可从 v1.0 发版后立即开始 │

└─→ v1.0 + v1.1 云端 TTS + 有声书 = 总计 29-44 天

十五、总体评估

15.1 分类推荐度

类别	推荐引擎	推荐度	理由
🏠 本地主力	Sherpa-ONNX + Kokoro	⭐⭐⭐⭐⭐	中英文双语覆盖，一个框架承载多种模型
🏠 极速英文	Supertonic	⭐⭐⭐⭐	CPU 167x 实时，长文稳定性最佳
🏠 中文开源	PaddleSpeech	⭐⭐⭐	可定制但 Python 环境是门槛
🏠 本地兜底	Piper CLI	⭐⭐⭐	编译失败时的安全网
🇨🇳 国内首选	阿里云 Qwen3-TTS	⭐⭐⭐⭐⭐	WER 中文最低，100 万字符/月免费
🇨🇳 国内性价比	火山引擎	⭐⭐⭐⭐	基础音色免费，长文本 ¥1.0/万字
🇨🇳 国内省钱	腾讯云	⭐⭐⭐⭐	预付费 ¥0.75/万字最低
🇨🇳 国内免费	百度智能云	⭐⭐⭐	企业认证 1 亿次免费（无 SDK）
🌍 国际首选	OpenAI TTS	⭐⭐⭐⭐⭐	AI 对话原生场景，gpt-4o-mini-tts
🌍 多语言首选	Google Cloud TTS	⭐⭐⭐⭐	75+ 语言 380+ 语音
🌍 极致质量	ElevenLabs	⭐⭐⭐	语音克隆 + 天花板质量（订阅制）
🌍 微软生态	Azure Speech	⭐⭐⭐	国内版 ¥0.95/万字极便宜
🌍 AWS 生态	Amazon Polly	⭐⭐⭐	首年免费额度最慷慨
❌ 不推荐	Pico TTS	⭐	无中文，MATCHA-TTS 替代

15.2 综合评分

维度	评分	说明
技术可行性	⭐⭐⭐⭐⭐	所有引擎均可集成，成熟 SDK 或 HTTP API
多引擎架构契合度	⭐⭐⭐⭐⭐	项目 `IServerProvider` 多 Provider 模式直接复用
中文场景覆盖	⭐⭐⭐⭐⭐	国内 4 云质量顶尖 + Kokoro 离线可定制 + PaddleSpeech 开源
实现复杂度	⭐⭐⭐	主要是胶水代码，但引擎数量使 UI 和测试复杂度显著
跨平台风险	⭐⭐⭐	本地引擎需预编译包；远程引擎仅需 HTTP，无此风险
隐私合规	⭐⭐⭐⭐	远程引擎需用户知情同意 + 本地加密存储凭据 + 降级保护
用户体验增益	⭐⭐⭐⭐⭐	10+ 引擎覆盖全部场景，用户按需自由选择

15.3 最终结论

本地免费默认，云端增值可选。建议分三个里程碑交付。

核心设计原则：

本地引擎是默认选项，面向所有用户免费可用。 开箱即用，零配置，零网络依赖。预打包 1 个保底语音（<15MB），主力语音首次启动后台静默下载。
远程云端引擎是增值选项，面向高价值用户。 用户自行注册云服务商账号、自行管理 API Key、自行承担费用。unobox 仅提供设置页面的 Key 配置入口和引擎切换器，不做代理、不做中转、不计费。
统一接口承载一切。 ITTSProvider 对本地引擎和远程 API 完全透明——调用方不感知引擎类别差异。远程引擎实现上反而更简单（HTTP API ≈ 0.5 天/个）。
useMediaPlayerStore 零改动。 合成后的 WAV 文件直接送入现有音频播放器队列（source: 'ai'），MiniPlayer/FullPlayer 完全复用。
推荐首个交付版本（v1.0 本地免费版，14-20 天）：
🏠 Sherpa-ONNX + Kokoro-multi-lang（中英文双语主力）
🏠 Supertonic（极速英文加速引擎）
🏠 Piper CLI + MATCHA-TTS（编译失败 + 极低配兜底）
设置 UI（语音浏览/下载/试听/语速调节）
消息集成（右键"朗读"按钮 + AI 对话自动朗读）
v1.1 云端增值版（+4-6 天）： 阿里云/火山引擎/腾讯云/百度智能云 + OpenAI/Google/Azure + API Key 配置 + 隐私声明
不推荐集成的引擎：Pico TTS（无中文，MATCHA-TTS 替代）。
语音包完全二次下载。 预打包仅保留一个 ≤15MB 的保底中文语音，其余全部按需下载。
远程引擎的隐私合规是强制要求。 文本离开设备前必须获得用户明确知情同意，API Key 本地加密存储，任何远程失败均自动降级到本地引擎。
有声书功能基于 Phase 1 本地 TTS 即可独立开发（+11-18 天），无需等待远程引擎。

非财务背景的管理者需要懂哪些核心财务知识？

2026-06-11T20:00:00.000+08:00

企业管理的108个问题 · 第49问

上一问我们聊了中层管理者如何在上下夹击中找到平衡（第48问），核心是要学会做"翻译官"——把上层的压力翻译成团队能消化的语言，把团队的诉求翻译成高层能理解的逻辑。今天这一问，依然跟"翻译"有关，只不过需要翻译的是一种很多管理者天然畏惧的东西：财务数据。

上面这句话，估计已经劝退了三分之一的管理者。

"我是搞业务的，又不是财务出身。""数字那些东西太枯燥了。""Excel我只会看合计那一行。"

说到财务，相当多管理者的本能反应是：把财务报表扔给财务部，自己只看结果——赚了还是亏了。问题是，当你只把财务当成"别人管的事"，你在每一个跟经营有关的决策上，都是闭着眼睛在走路。

你不需要成为一个注册会计师。但有些东西，真的躲不掉。

一、三张表，你不需要精通但必须读懂

财务的基础，就是三张报表。很多人一听到"报表"就头大，但你换个角度想：这三张表其实就是用三个不同的视角在讲同一个故事。

资产负债表——你的家底

这张表回答的是：截至今天，这家公司到底有多少钱、欠多少钱。

左边是资产——现金、应收账款、库存、设备、房产，所有这些值钱的东西。右边是负债和所有者权益——欠银行的、欠供应商的、股东投进来的。

关键要看的是资产负债率（总负债÷总资产）。这个数字太高，说明公司是靠借钱在运转，经不起风吹草动。太低也不全是好事——说明你太保守了，没在借钱赚钱。行业差异很大，地产公司70%不算高，科技公司超过40%可能就危险了。

对非财务背景的管理者来说，资产负债表告诉你一件事：你的决策风险，最终会体现在这张表的右边。

你签了一个大客户合同，放宽了回款条件——短期看来业绩上去了，但应收账款涨了，资产负债表的"健康度"在下降。

利润表——你的成绩单

这张表回答的是：这段时间，你赚了多少钱、怎么赚的。

收入减去成本是毛利，毛利减掉各种费用是净利润。看起来很简单，但业务管理者最容易掉进一个坑：把收入和现金混为一谈。

签了一个100万的合同，利润表上确实记了100万的收入。但如果客户说"钱半年后付"，你的银行账户里一分钱都没多。利润表告诉你"你很牛"，现金流说"兄弟你再撑撑"。

很多倒闭的公司，死之前利润表都是好看的。他们死于有利润没现金。

现金流量表——你的血液

这张表是很多非财务管理者最忽视、但也是最关键的。

它回答的是：钱到底进来了没有？出去了没有？

经营现金流（主业赚的）、投资现金流（买设备、投资进出）、融资现金流（借钱、还钱、融资）。对绝大多数业务管理者来说，死死盯住经营现金流就够了——这个数要是持续为负，公司就是在吃老本。

有个简单的经验法则：公司的现金储备至少要覆盖6个月的固定支出。疫情三年里，多少"利润很好"的公司死在了这条红线上。

二、几个管理者必须掌握的核心概念

1. 毛利率和净利率是两回事

毛利率=（收入-直接成本）÷收入。它告诉你产品本身赚钱不赚钱。

净利率=（收入-所有费用）÷收入。它告诉你公司整体赚钱不赚钱。

很多业务管理者只盯着毛利率，觉得"毛利这么高，公司肯定赚翻了"。但公司的房租、行政、销售、市场、研发，每一笔都要从毛利里扣。毛利高净利低，说明运营效率出了问题。

反过来，毛利低的行业（比如零售），如果能用极致的运营效率把净利做出来，才是真本事——典型的例子就是Costco。

2. 盈亏平衡点

这是每个管理者在做任何业务决策前，都应该在脑子里算一遍的数字。

盈亏平衡点= 固定成本 ÷（单价-变动成本）

翻译成人话就是：每个月你要卖多少东西，才能把固定成本覆盖掉？低于这个数就是亏，高于这个数才有的赚。

做了个新项目？先算盈亏平衡点。招了一个新人？他的盈亏平衡点是多少。搞了个促销活动？算一下需要多卖多少才能覆盖成本。

你会发现，很多决策在做完这个计算之后，看起来就没那么香了。

3. ROI——但不要只看一个数字

ROI（投资回报率）=（收益-投资）÷投资。很简单，但容易算错。

很多管理者算ROI只算"这一次的投入和产出"，忽略了机会成本。

比如你花了50万做一个市场活动，直接带来了80万的收入，ROI是60%——看起来不错。但同样是50万，如果你投入到产品研发上，可能半年后带来的是200万的收入。

ROI是个好工具，但只看ROI会让人变得短视。真正好的管理者，是把ROI、战略价值和长期影响放在一起看的。

三、不懂财务的管理者，容易犯哪些错？

我这些年观察下来，非财务背景的管理者最容易犯的错误就三个：

第一个：只认收入，不管结构。

"这个月破纪录了，卖了1000万！"——但如果这1000万里有800万是低毛利甚至亏本的产品，卖的越多亏的越多。有些公司就是这么"越做越小"的。

第二个：把预算当成"上面压下来的数字"，不是自己的经营工具。

预算不是"财务部让我填的表"，而是你对自己业务的一种承诺和规划。好的管理者，看到预算会想"我用这些资源能产多少"，而不是"他们又让我编数字了"。

第三个：不敢看坏消息。

有些管理者到了月底，看到财务报表里的负数就跳过，只看好的部分。但财务数据不会骗人——你越不敢看的那个数字，往往就是将来最要你命的那个。

四、给非财务管理者的三个实操建议

1. 养成"每周看三个数"的习惯

不需要成为财务专家，但每周花十分钟看三个数就够了：

本周的经营现金流（钱够不够）
本月的预算执行率（花超了没）
当前重点项目的ROI预估（值不值得继续）

2. 跟财务部交朋友

很多业务管理者跟财务部的关系是"各说各话"甚至是对立的。但如果你能主动约财务总监喝杯咖啡，让他帮你把你的业务数据"翻译"成财务语言，你的决策质量会提高一个档次。

财务部的人不是来找你麻烦的，他们是来帮你算账的。

3. 做任何决策前，问自己三个财务问题

很简单，写在便签上贴在你的工位：

这个决策会怎样影响现金流？
它的回报周期是多长？
如果最坏的情况发生，我扛得住吗？

这三个问题问下来，基本可以避免90%的拍脑袋决策。

五、回到起点

非财务背景的管理者需要懂财务，不是为了把自己变成会计师。而是因为——

管理最核心的本质，就是在有限的资源里做出最优配置。

财务数据，就是你手里那张资源地图。看不懂地图还想打胜仗，只能靠运气。

前面我们已经走了48问，从战略到组织、从人力到领导力，一路聊过来。今天这一问开始进入第五个板块：财务管理。接下来的十问，都跟"钱"有关——怎么读报表、怎么管现金流、怎么做预算、怎么避坑。

财务不难。难的是你愿不愿意睁开眼看数字。

⬅️ 返回目录 明日预告：第50问 —— 如何通过财务报表"读"出企业的健康状况？

软件正在吞噬软件：Karpathy 对 AI 编程范式演化的深度洞察

2025-07-09T00:47:02.000+08:00

好的，以下是一篇格式完整、内容丰富的博客文章，标题建议为：

软件正在吞噬软件：Karpathy 对 AI 编程范式演化的深度洞察

作者：Andrej Karpathy

演讲时间：2024年?

演讲场合：Y Combinator 演讲活动

视频链接：YouTube - Software 2.0 and 3.0

🧭 导语：当软件开始“写”软件

我们正在经历一场前所未有的技术范式变革。从人类写的硬编码逻辑，到用数据“训练”神经网络，再到今天我们只需用自然语言与 AI 对话，软件开发的界限正在迅速模糊。

Andrej Karpathy，这位 OpenAI、Tesla 和 DeepMind 的资深 AI 专家，用他的直觉与洞察向我们展示了这个变化是如何发生的——以及它将如何重塑整个软件世界。在 Y Combinator 的这场演讲中，他不仅回顾了软件 1.0 到 3.0 的演进，还大胆描绘了“LLM 作为新操作系统”的愿景，直指未来开发者的角色转型与生态重构。

🔍 核心主题概览

软件的三个时代：1.0（传统编码）、2.0（神经网络）、3.0（自然语言提示）
LLM 是新的“计算机 + 操作系统”
“自主性滑块”：人类与 AI 合作编程的自由度选择
氛围编程、教育新范式与产品设计的重构
为 LLM 打造的插件系统、控制接口与未来生态

👨‍💻 演讲者简介：Andrej Karpathy 是谁？

Karpathy 是 AI 领域最具影响力的人物之一，拥有斯坦福博士背景，曾在 Tesla 领导自动驾驶 AI 系统开发，是 OpenAI 的联合创始工程师之一。他也因在 CS231n（Stanford 计算机视觉课程）中的教学而闻名，是“Software 2.0”概念的提出者。

他的写作与演讲风格一贯清晰、幽默、比喻生动，本场演讲可谓其思想精华的再升华。

🎥 视频链接

🔗 观看原始演讲视频（英文）

视频标题：Software 2.0 and 3.0

主讲人：Andrej Karpathy

发布平台：Y Combinator 官方频道

📖 中文全文翻译

以下为 Karpathy 在 YC 的完整演讲内容翻译，由 AI 整理，忠实还原其思想脉络与表达风格。

（👇 点击展开完整中文翻译内容）

视频链接：https://www.youtube.com/watch?v=LCEmiRjPEtQ

新 YouTube 资源 摘自 YouTube 频道“Y Combinator”上传的视频“Andrej Karpathy：软件再次发生变化”的转录片段：

[1] 请欢迎特斯拉前人工智能总监 Andre Carpathy。大家好，哇，好多人啊。大家好。嗯，好的，我很高兴今天能在这里和大家谈谈人工智能时代的软件。我听说你们很多人都是学生，比如本科生、硕士生、博士生等等，你们即将进入这个行业。我认为现在进入这个行业是一个极其独特和非常有趣的时期。我认为根本原因在于，嗯，软件再次发生变化。我说“再次”，是因为我其实已经做过一次这个演讲了。但是问题是软件一直在变化，所以我有很多材料可以创作新的演讲。我认为它正在发生非常根本性的变化。我认为大致来说，软件在过去 70 年里没有发生过如此根本性的变化，然后我认为在过去几年里它发生了大约两次非常快速的变化。所以有大量的工作要做，大量的软件需要编写和重写。所以让我们来看看软件的领域。如果我们把这看作是软件的地图，这是一个非常酷的工具，叫做 GitHub 地图。这就像所有已编写的软件，它们是给计算机的指令，用于在数字空间中执行任务。如果你放大这里，这些都是不同类型的存储库，这是所有已编写的代码。几年前，我观察到软件正在发生变化，出现了一种新的软件类型。我当时称之为软件 2.0。其理念是软件 1.0 是你为计算机编写的代码，软件 2.0 基本上是神经网络，特别是神经网络的权重。你不是直接编写这些代码，你更多的是调整数据集，然后运行优化器来创建神经网络的参数。我认为当时神经网络被看作只是一种不同类型的分类器，比如决策树什么的。所以我认为这种框架更合适。而现在我们拥有的是软件 2.0 领域中的一个等同于 GitHub 的东西。

[2] 我认为 Hugging Face 基本上是软件 2.0 中的 GitHub 的等同物，还有 Model Atlas，如果你好奇的话，你可以在那里可视化所有编写的代码。顺便说一下，中间的巨大圆圈是 Flux 图像生成器的参数。所以，每当有人在 Flux 模型之上进行微调时，你基本上就在这个空间中创建了一个 Git commit，你创建了一个不同类型的图像生成器。所以基本上，我们有软件 1.0 是编程计算机的计算机代码，软件 2.0 是编程神经网络的权重。这里有一个 AlexNet 图像识别器神经网络的例子。到目前为止，我们直到最近才熟悉的所有神经网络都像是固定功能的计算机，比如图像到类别之类的。我认为已经改变的，而且我认为是一个相当根本性的改变是，神经网络变得可以通过大型语言模型（LLM）进行编程。所以我认为这相当独特，它是一种新型计算机。所以在我看来，它值得一个新的称谓，即软件 3.0。基本上，你的提示现在是编程 LLM 的程序。而且值得注意的是，这些提示是用英语写的，所以它是一种非常有趣的编程语言。所以也许，总结一下区别，如果你正在做情感分类，例如，你可以想象编写一些 Python 代码来做情感分类，或者你可以训练一个神经网络，或者你可以提示一个大型语言模型。所以这里这是一个少量样本提示，你可以想象改变它并以稍微不同的方式编程计算机。所以基本上我们有软件 1.0、软件 2.0，我认为我们正在看到，也许你已经看到很多 GitHub 代码不再仅仅是代码了，里面夹杂着很多英语。所以，我认为有一种不断增长的新型代码类别。所以它不仅是一种新的编程范式，而且令我惊讶的是，它是用我们的母语英语编写的。所以当这在几年前让我大吃一惊时，我发了这条推文，而且我认为它引起了很多人的关注，这就是

[3] 我目前置顶的推文是，令人惊奇的是，我们现在正在用英语编程计算机。当年我在特斯拉的时候，我们正在开发自动驾驶系统，我们试图让汽车能够行驶。我当时展示了这张幻灯片，你可以想象汽车的输入在底部，它们通过一个软件堆栈来产生转向和加速。我当时观察到，自动驾驶系统中有大量的 C++ 代码，那是软件 1.0 代码，然后里面有一些神经网络做图像识别。我观察到，随着时间的推移，当我们改进自动驾驶系统时，神经网络的能力和规模都在增长，除此之外，所有的 C++ 代码都被删除了，而且很多最初用 1.0 编写的功能和能力都迁移到了 2.0。举个例子，很多来自不同摄像头和跨时间的图像信息拼接都是由神经网络完成的，我们能够删除大量的代码。所以软件 2.0 堆栈确实吞噬了自动驾驶的软件堆栈。我觉得这在当时非常了不起，我认为我们正在再次看到同样的事情，即我们有了一种新型软件，它正在吞噬整个堆栈。我们有三种完全不同的编程范式，我认为如果你正在进入这个行业，精通所有这些范式是一个非常好的主意，因为它们都有各自的优缺点，你可能想用 1.0、2.0 或 3.0 来编程某些功能。你是要训练神经网络？还是只是提示 LLM？这应该是一段显式代码等等。所以我们都必须做出这些决定，并且可能需要在这些范式之间流畅地转换。所以我现在想深入探讨的是，首先我想在第一部分谈谈 LLM，以及如何思考这种新范式和生态系统，以及它看起来像什么。这种新型计算机是什么样子，生态系统又是什么样子？我被安德鲁·图灵多年前的一句话所震撼，我认为安德鲁将紧随我之后发言，但他当时说“AI 是新的电力”，我确实认为它捕捉到了一些非常有趣的东西，即 LLM 肯定感觉像现在具有公用事业的特性。

[4] 所以，像 OpenAI、Gemini、Anthropic 等大型语言模型实验室投入资本支出（CapEx）来训练大型语言模型，这相当于建设电网。然后有运营支出（OpEx）通过 API 向我们所有人提供这种智能，这通过按百万令牌计费的方式完成，我们对这种 API 有很多类似公用事业的需求，我们要求低延迟、高正常运行时间、一致的质量等。在电力领域，你会有一个转换开关，这样你就可以将你的电力来源从电网、太阳能、电池或发电机中切换。在大型语言模型领域，我们可能有 OpenRouter，可以轻松地在不同类型的大型语言模型之间切换，因为大型语言模型是软件，它们不争夺物理空间，所以有六个电力供应商是可以的，你可以在它们之间切换，因为它们不会以如此直接的方式竞争。我认为还有一点非常吸引人，我们实际上在过去几天看到了这一点，许多大型语言模型都宕机了，人们被困住了，无法工作。我认为对我来说，当最先进的大型语言模型宕机时，这实际上就像是世界范围内的智能“褐化”（brownout），就像电网电压不稳定时一样，而且地球变得更笨了，我们对这些模型的依赖程度越高，这种现象就越显著，而且我认为这种依赖还会继续增长。但是大型语言模型不仅具有公用事业的特性，我认为也可以说它们具有一些晶圆厂（fab）的特性，原因在于构建大型语言模型所需的资本支出实际上相当大，它不仅仅是建造一些发电站之类的东西，你投入了大量的资金，我认为技术树正在快速增长。所以我们处于一个拥有深厚技术树、研究和开发秘密集中在大型语言模型实验室的世界里。但是我相信

[5] 这种类比也有些模糊，因为正如我所提到的，这是软件，而软件由于其可塑性，防御性稍弱。所以，我认为这是一个有趣的事情，也许可以做很多类比，比如 4 纳米的工艺节点可能类似于一个具有特定最大浮点运算能力的集群，当你使用英伟达 GPU 并且只做软件而不做硬件时，这就像无晶圆厂模型，但如果你实际上也在构建自己的硬件并在 TPU 上训练，如果你是谷歌，那就像英特尔模型，你拥有自己的晶圆厂。所以我认为这里有一些有意义的类比，但实际上我认为最能说明问题的类比是，在我看来，大型语言模型与操作系统有着非常强的类比，因为这不仅仅是电力或水，它不是从水龙头流出的商品，它们现在是日益复杂的软件生态系统，所以它们不仅仅是简单的商品，比如电力。令我感兴趣的是，这个生态系统正在以非常相似的方式形成，你有一些闭源提供商，比如 Windows 或 Mac OS，然后你有一个开源替代品，比如 Linux。我认为对于神经网络，对于大型语言模型也是如此，我们有几个相互竞争的闭源提供商，然后也许 Llama 生态系统目前可能是一个接近于可能发展成类似 Linux 的东西。再说一次，我认为这仍然非常早期，因为它们只是简单的大型语言模型，但我们开始看到它们会变得更加复杂。这不仅仅是关于大型语言模型本身，而是关于所有的工具使用和多模态以及所有这些是如何工作的。所以当我早些时候有这个认识时，我试图把它勾勒出来，它在我看来，大型语言模型有点像一个新的操作系统，所以大型语言模型是一种新型计算机，它就像 CPU 的等价物，上下文窗口有点像内存，然后大型语言模型正在协调内存和计算，用于解决问题，使用所有这些

[6] 这些功能。所以如果你从这个角度看，它确实非常像操作系统。再举几个例子，比如如果你想下载一个应用，比如说我去 VS Code 并下载，你可以在 Windows、Linux 或 Mac 上运行 VS Code。同样地，你可以下载一个 LLM 应用，比如 Cursor，并将其运行在 GPT、Cloud 或 Gemini 系列上，这只是一个下拉菜单，所以在这方面也很相似。我认为令我震惊的更多类比是，我们现在有点像处于 1960 年代左右的时代，LLM 计算对于这种新型计算机来说仍然非常昂贵，这迫使 LLM 集中在云端，而我们都只是瘦客户端，通过网络与它交互，我们都没有充分利用这些计算机，因此使用分时（time sharing）是有意义的，我们都只是它们在云端运行计算机时批处理的一个维度，这与当时计算机的样子非常相似，操作系统在云端，一切都通过流传输，并且有批处理。所以个人计算革命尚未发生，因为它不经济，没有意义。但我认为有些人正在尝试，事实证明 Mac mini 对于某些 LLM 来说非常适合，因为它全是，如果你做的是批量推理，这都是超级内存密集型的，所以这实际上是有效的，我认为这些可能是个人计算的一些早期迹象，但它还没有真正发生，不清楚它会是什么样子。也许你们中的一些人会发明它是什么或者它是如何工作的，或者它应该是什么。也许我还会提到一个类比是，每当我直接在文本中与 ChatGPT 或某个 LLM 交流时，我感觉就像通过终端与操作系统对话一样，它只是文本，是对操作系统的直接访问，我认为目前还没有普遍发明出一种图形用户界面（GUI），比如 ChatGPT 应该有一个不同于文本气泡的 GUI 吗？当然，我们稍后会提到的一些应用程序确实有 GUI，但没有一个通用的 GUI 来处理所有任务，如果这说得通的话。

[7] 在某些方面，大型语言模型（LLM）与早期计算和操作系统截然不同，而且相当独特。我曾撰文探讨过这种非常不同的特性：LLM 扭转了技术扩散的方向。通常，对于电力、密码学、计算、飞行、互联网、GPS 等新的变革性技术，由于它们是新生且昂贵的，政府和企业是首批使用者，随后才扩散到消费者。但我觉得 LLM 似乎颠倒了过来。或许早期计算机主要用于弹道学和军事用途，但 LLM 却主要用于“如何煮鸡蛋”之类的事情。我个人就经常这样使用。因此，拥有一台新的神奇计算机却用来帮我煮鸡蛋，这让我感到非常着迷，它并没有帮助政府做一些非常疯狂的事情，比如军事弹道学或一些特殊技术。事实上，企业和政府在采纳所有这些技术方面都落后于我们所有人。所以这完全是反过来了，我认为这也许说明了我们如何使用这项技术，或者一些首批应用程序在哪里等等。所以，总结一下到目前为止，大型语言模型实验室（LLM labs）和大型语言模型（LLM），我认为用这个词是准确的，但大型语言模型是复杂的操作系统，它们处于计算领域的 1960 年代左右，我们正在重新进行计算，它们目前通过分时方式提供，像公用事业一样分发。新的和前所未有的地方在于，它们不在少数政府和企业手中，而是在我们所有人手中，因为我们每个人都有一台计算机，而且它都是软件。ChatGPT 像闪电般地、瞬间地、一夜之间地被投射到我们数亿人的计算机上，这太疯狂了。令我感到疯狂的是，事实就是如此。现在是我们进入这个行业，编程这些计算机的时候了，这太疯狂了。所以我认为这相当了不起。在我们编程大型语言模型之前，我们必须花一些时间来

[8] 思考这些东西是什么，我特别喜欢谈论它们的“心理”。我喜欢将大型语言模型（LLM）视为一种“人类灵魂的随机模拟”[8]。这个模拟器恰好是一个自回归的 Transformer [8]。Transformer 是一种神经网络，它以“令牌”（token）为单位进行处理，每次处理一个“块”，每个“块”的计算量几乎相等 [8]。当然，这个模拟器只是涉及到一些权重，我们将其拟合到互联网上所有的文本数据中，然后你就得到了这样一个模拟器 [8]。因为它是在人类数据上训练的，所以它具有一种类似人类的涌现心理 [8]。你会注意到的第一件事是，LLM 具有百科全书般的知识和记忆，它们能记住比任何单个个体人类多得多的东西，因为它们阅读了太多的内容 [8]。这让我想起了电影《雨人》，我真的强烈推荐大家看这部电影，这是一部很棒的电影，我喜欢这部电影 [8]。达斯汀·霍夫曼在电影中饰演一个患有自闭症的学者，他拥有近乎完美的记忆力，他可以读一本电话簿并记住所有的名字和电话号码 [8]。我感觉 LLM 非常相似，它们可以非常轻松地记住 SHA 哈希值和许多不同类型的东西 [8]。所以它们在某些方面确实拥有超能力，但它们也有很多认知缺陷 [8]。它们会经常“幻觉”，编造一些东西，而且对自我认知没有很好的内部模型，至少不够充分，尽管这方面有所改善但仍不完美 [8]。它们表现出“锯齿状智能”，在某些问题解决领域它们会超人一等，然后会犯下基本上没有人会犯的错误，比如它们会坚持说 9.11 大于 9.9，或者说“草莓”（strawberry）这个词里有两个 R [8]。这些都是一些著名的例子，但基本上，它们有很多你可能会绊倒的粗糙边缘，所以我觉得这也是独一无二的 [8]。它们还患有顺行性遗忘症 [9]。

[9] 所以我在这里暗示的是，如果你的同事加入你的组织，这位同事会随着时间的推移了解你的组织，他们会理解并获得大量关于组织的上下文，他们回家睡觉，巩固知识，并随着时间积累专业知识。大型语言模型（LLM）天生不具备这种能力，我认为这在 LLM 的研发中还没有真正解决 [9]。所以上下文窗口实际上就像工作记忆，你必须相当直接地编程工作记忆，因为它们不会默认变得更聪明 [9]。我认为很多人会因此被类比所困扰 [9]。在流行文化中，我推荐大家看这两部电影：《记忆碎片》（Momento）和《初恋 50 次》（51st Dates）[9]。在这两部电影中，主角的权重是固定的，他们的上下文窗口每天早上都会被清空 [9]。当这种情况发生时，去工作或建立人际关系会非常困难，而这种情况经常发生在 LLM 身上 [9]。我想再指出一点是与安全相关的 LLM 使用限制 [9]。例如，LLM 相当容易上当受骗，它们容易受到提示注入风险的影响，它们可能会泄露你的数据等等 [9]。还有许多其他与安全相关的考量 [9]。所以长话短说，你必须同时思考这个既有超人能力又有一堆认知缺陷和问题的东西，但它们又极其有用 [9]。我们如何编程它们，如何避开它们的缺陷并享受它们的超人能力 [9]。我现在想转到的是讨论如何使用这些模型的机会，以及一些最大的机会是什么 [9]。这并不是一个全面的列表，只是我在这次演讲中觉得有趣的一些事情 [9]。我首先感到兴奋的是我称之为“部分自主应用程序”[9]。例如，我们以编程为例，你当然可以直接去 ChatGPT，开始复制粘贴代码，复制粘贴错误报告等等，获取代码然后复制粘贴所有东西 [9]。你为什么要那样做呢？你为什么要直接去操作系统呢？[9] 拥有一个专门的应用程序更有意义 [9]。

[10] 你为什么要这样做呢？你为什么要直接使用操作系统？拥有一个专门的应用程序更有意义。所以我认为你们很多人都在使用 Cursor，我也一样。Cursor 就是你想要的那种东西，你不想直接使用 ChatGPT。我认为 Cursor 是一个很好的早期 LLM 应用程序的例子，它具有许多我认为对所有 LLM 应用程序都有用的特性。特别是，你会注意到我们有一个传统的界面，允许人类像以前一样手动完成所有工作，但除此之外，我们现在有了 LLM 集成，允许我们以更大的块进行操作。因此，我认为 LLM 应用程序的一些共同且有用的特性是：第一，LLM 基本上处理了大量的上下文管理 [10]。第二，它们协调对 LLM 的多次调用 [10]。所以在 Cursor 的例子中，后台有所有文件的嵌入模型，实际的聊天模型，将差异应用于代码的模型，所有这些都为你进行了协调 [10]。一个非常重要但可能并未完全被充分认识到的特性是应用程序特定的 GUI 及其重要性 [10]。因为你不想直接通过文本与操作系统对话，文本很难阅读、解释和理解，而且你也不想直接通过文本执行某些操作 [10]。所以最好直接以红色和绿色变化的形式看到差异，你可以看到添加和删除的内容，这更容易，只需按 Command+Y 接受或 Command+N 拒绝，我不应该通过文本输入 [10]。所以 GUI 允许人类审计这些易出错系统的工作，并提高速度 [10]。我稍后还会回到这一点 [10]。我想指出的最后一个特性是，有一个我称之为“自主滑块”的东西 [10]。例如，在 Cursor 中，你只需轻按完成，你大部分时间都在掌控中，你可以选择一段代码，然后按 Command+K 更改那一段代码，你可以按 Command+L 更改整个文件，或者你可以按 Command+I，它就会让你在整个代码库中随意操作，这是完全自主的代理版本 [10]。

[11] 你负责自主性滑块，并且根据手头任务的复杂性，你可以调整你愿意为该任务放弃的自主性程度 [11]。也许再举一个相当成功的大型语言模型（LLM）应用程序的例子：Perplexity，它也具有我刚才在 Cursor 中指出的一些非常相似的功能 [11]。它打包了大量信息，协调多个 LLM，它有一个 GUI 允许你审计它的一些工作 [11]。例如，它会引用来源，你可以想象检查它们 [11]。它有一个自主性滑块，你可以选择快速搜索，或者进行研究，或者进行深度研究并在 10 分钟后回来 [11]。所以这都是你赋予工具的不同程度的自主性 [11]。所以我的问题是，我觉得很多软件都会变得部分自主 [11]。我正在思考这会是什么样子，对于许多维护产品和服务的人来说，你们将如何使你们的产品和服务变得部分自主 [11]？LLM 能否看到人类能看到的一切 [11]？LLM 能否以人类能采取的所有方式行动 [11]？人类能否监督并参与到这项活动中 [11]？因为这些又是容易出错的系统，它们还不完美 [11]。在 Photoshop 或类似软件中，差异会是什么样子 [11]？而且，很多传统软件现在都有这些开关和各种东西，这些都是为人类设计的，所有这些都必须改变，并变得对 LLM 可访问 [11]。我想强调的一件事是，对于许多这些 LLM 应用程序，我不确定是否得到了足够的关注，那就是我们现在有点像在与 AI 合作，通常它们负责生成，而我们人类负责验证 [11]。为了让这个循环尽可能快地进行，从而完成大量工作，这是符合我们利益的 [11]。我认为有两种主要方法可以做到这一点：第一，你可以大大加快验证速度 [11]。我认为 GUI 在这方面极其重要，因为 GUI 利用了我们大脑中的计算机视觉 GPU，阅读文本是费力的，而且不好玩，但看东西是好玩的，它就像一条高速公路通向你的大脑 [11]。

[12] 所以我认为 GUI 对于审计系统和一般视觉表示都非常有用 [12]。第二，我想说的是，我们必须让 AI 保持在控制之中 [12]。我认为很多人对 AI 代理过于兴奋了 [12]。对我来说，收到一个 10,000 行代码的差异（diff）到我的代码库是没有用的 [12]。我仍然是瓶颈，即使这 10,000 行代码是瞬间生成的，我也必须确保这个东西没有引入 bug，并且它做的是正确的事情，而且没有安全问题等等 [12]。所以，嗯，我认为，是的，基本上我们必须努力使这两者的流程非常非常快 [12]。我们必须以某种方式让 AI 保持在控制之中，因为它变得过于活跃 [12]。这就像我进行 AI 辅助编码时的感受，如果我只是单纯地编写代码，一切都很好，但如果我真的想完成工作，有一个过于活跃的代理做所有这些事情就不是那么好了 [12]。所以这张幻灯片不是很好，抱歉，但我想说的是，我正在像你们许多人一样，开发一些在我的编码工作流程中利用这些代理的方法，并进行 AI 辅助编码 [12]。在我自己的工作中，我总是害怕收到太大的差异，我总是以小而增量的方式进行，我想确保一切都好，我想非常非常快地转动这个循环 [12]。我致力于小块的单一具体事物 [12]。所以我认为你们中的许多人可能正在开发与大型语言模型（LLM）合作的类似方式 [12]。我也看到了一些博客文章试图为与 LLM 合作制定最佳实践，这里有一篇我最近读到并认为非常好的文章，它讨论了一些技术，其中一些与如何让 AI 保持在控制之中有关 [12]。例如，如果你的提示很模糊，那么 AI 可能不会完全按照你想要的方式做，在这种情况下验证会失败，你会要求其他东西，如果验证失败，你就会开始打转 [12]。所以花更多的时间在提示上更具体会更有意义，这会增加成功验证的可能性 [12]。你可以向前推进 [13]。

[13] 所以我想我们很多人最终都会找到这样的技术。我认为在我自己的工作中，我现在也对在有了人工智能和大型语言模型（LLM）之后，教育会是什么样子很感兴趣。对我来说，很大一部分思考是如何控制人工智能。我认为直接去 ChatGPT 说“嘿，教我物理”是行不通的。我认为这行不通，因为人工智能会迷失在森林里。所以对我来说，这实际上是两个独立的应用程序。例如，有一个应用程序供教师创建课程，然后有一个应用程序接收课程并将其提供给学生。在这两种情况下，我们现在都有了一个中间的课程工件，它是可审计的，我们可以确保它很好，我们可以确保它是一致的，人工智能在特定的教学大纲、特定的项目进展等方面都受到控制。这是一种控制人工智能的方法，我认为这样做的成功可能性要高得多，而且人工智能也不会迷失在森林里。我想再引申一个类比是，我对部分自主性并不陌生，我在特斯拉工作了五年，这也是一个部分自主性产品，并且具有很多特点，例如仪表盘上就有自动驾驶系统的 GUI，它显示了神经网络看到了什么等等。我们也有自主性滑块，在我任职期间，我们为用户完成了越来越多的自主任务。我想简单讲一个故事，我第一次驾驶自动驾驶汽车是在 2013 年，我有一个朋友在 Waymo 工作，他提出带我在帕洛阿尔托兜风。我当时用 Google Glass 拍了这张照片，你们很多人都很年轻，可能都不知道那是什么。但是，是的，当时这很流行。我们上了车，在帕洛阿尔托的高速公路和街道上开了大约 30 分钟，这次驾驶非常完美，零干预。那是 2013 年，距离现在已经

[14] 12 年了。这让我很震惊，因为当时我有了这次完美的驾驶体验，这次完美的演示，我觉得哇，自动驾驶迫在眉睫，因为它就是成功了，这太不可思议了。但 12 年过去了，我们仍在研究自动驾驶。我们仍在研究驾驶代理，即使现在我们还没有真正解决这个问题，你可能会看到 Waymo 在路上行驶，它们看起来像是无人驾驶，但你知道，很多驾驶仍然有很多远程操作和人类参与。所以我们甚至还没有宣布成功，但我认为它肯定会成功，只是需要很长时间。所以我觉得软件真的很棘手，就像驾驶也很棘手一样。所以当我看到诸如“2025 年是代理之年”之类的说法时，我感到非常担忧，我感觉，你知道，这是“代理的十年”，这将需要相当长的时间。我们需要人类参与，我们需要谨慎行事，这是软件，我们应该认真对待。我总是在思考的另一个类比是钢铁侠战衣。我一直很喜欢钢铁侠，我认为它在很多方面都非常正确，关于技术将如何发展以及它将如何发挥作用。我喜欢钢铁侠战衣的地方在于，它既是一种增强，托尼·斯塔克可以驾驶它，它也是一个代理，在某些电影中，钢铁侠战衣是相当自主的，可以四处飞行并找到托尼等等。所以这就是自主性滑块，我们可以构建增强，也可以构建代理，我们都想做一点，但在现阶段，我想说的是，在使用易错的大型语言模型时，我想说，你想要构建的不是钢铁侠机器人，而是钢铁侠战衣。它不是构建自主代理的炫耀性演示，而是构建部分自主产品。这些产品具有自定义的 GUI 和 UI/UX，我们正在努力，这样做是为了使人类的生成验证循环非常非常快，但我们并没有忘记原则上可以自动化这项工作的事实，而且你的产品中应该有一个自主性滑块，并且你

[15] 应该考虑如何滑动那个自主性滑块，并使您的产品随着时间的推移变得更加自主 [15]。但这就是我思考这些产品中存在大量机会的方式 [15]。我现在想稍微改变一下话题，谈谈另一个我认为非常独特的维度 [15]。不仅出现了一种新的编程语言，允许软件实现自主性，而且正如我所提到的，它是用英语编写的，这是一种自然界面 [15]。突然间，每个人都成了程序员，因为每个人都说自然语言，比如英语 [15]。这对我来说极其看好且非常有趣，而且也完全是前所未有的 [15]。以前你需要花 5 到 10 年学习一些东西才能在软件领域做一些事情，现在不再是这样了 [15]。所以我不知道有没有人听说过“氛围编程”（vibe coding），这条推文就是介绍它的，但我听说这现在已经是一个主要的迷因了 [15]。关于这件事的一个有趣故事是，我已经使用 Twitter 15 年左右了，但我仍然不知道哪条推文会走红，哪条推文会默默无闻，没有人关心 [15]。我当时以为这条推文会是后者，我不知道，那只是一时兴起想到的，但它却成了一个彻头彻尾的迷因，我真的无法判断 [15]。但我想它触动了人们的心弦，并给了一种大家都感受到了但无法用语言表达的东西命名 [15]。所以现在甚至有了维基百科页面，这就像一个重大的贡献一样 [15]。所以 Hugging Face 的 Tom Wolf 分享了一段我非常喜欢的漂亮视频 [15]。这些是孩子们在氛围编程，我觉得这是一个如此温馨的视频，我爱这个视频 [15]。你怎么能看到这个视频却对未来感到悲观呢？未来很美好，我认为这将成为软件开发的入门毒品 [15]。我不是一个对未来一代感到悲观的人，我认为，是的，我喜欢这个视频 [15]。我也尝试了一下氛围编程，因为它太有趣了 [15]。当你想要构建一些超级定制的、似乎不存在的东西，并且你只是想随心所欲地做，比如在一个周六，氛围编程就太棒了 [16]。

[16] 我构建了这个 iOS 应用程序，我其实不会用 Swift 编程，但我真的很震惊我竟然能够构建一个超级基础的应用程序，我不会解释它，它真的很蠢，但我很喜欢，这只是一天的工作，当天晚些时候它就在我的手机上运行了，我当时想“哇，这太棒了。”我不需要花五天时间阅读 Swift 才能开始。我还通过氛围编程开发了这个叫做 MenuGen 的应用程序，这个应用程序现在正在运行，你可以在 menu.app 尝试它。我基本上遇到了一个问题，我到一个餐厅，浏览菜单，却不知道任何菜品是什么，我需要图片。所以没有这样的东西。于是我想“嘿，我要用氛围编程来实现它。”所以，这就是它的样子，你访问 menu.app，然后你拍一张菜单的照片，然后 MenuGen 会生成图片。每个人注册后都会获得 5 美元的免费积分，因此这对我来说是一个主要的成本中心，所以这对我来说是一个负收入的应用程序，我目前在 MenuGen 上亏了很多钱。但 MenuGen 对我来说最吸引人的地方是，氛围编程的部分，也就是代码部分，其实是氛围编程 MenuGen 最容易的部分。大部分时间花在了我试图让它真正可用上，这样你才能有身份验证、支付、域名和 Vercel 部署，这真的很难。而所有这些都不是代码，所有这些 DevOps 的东西都是我在浏览器中点击的，这非常慢，又花了一周的时间。所以这真的很有趣，我在几个小时内就在我的笔记本电脑上让 MenuGen 的演示版本运行起来了，然后又花了一周时间，因为我试图让它变成一个真实的产品。原因在于这真的很烦人。例如，如果你尝试给你的网页添加 Google 登录，我知道这很小，但 Clerck 库有大量指令告诉我如何集成这个，这太疯狂了，它告诉我：“去这个 URL，点击这个下拉菜单，选择这个，去那个，点击那个。”它就像计算机一样告诉我应该采取哪些行动。你来做啊，我为什么要这样做？搞什么鬼？我必须遵循所有这些指令，这太疯狂了。所以我认为我演讲的最后一部分因此聚焦于我们能否只为代理构建产品？我不想做这些工作。代理能做这些吗？谢谢。好的，大致来说，我认为出现了一种新的数字信息消费者和操纵者。以前只有人类通过 GUI 或计算机通过 API，现在我们有了一个全新的东西。代理是计算机，但它们有点像人类，对吧？它们是“人类灵魂”，互联网上存在“人类灵魂”，它们需要与我们的软件基础设施交互。我们能为它们构建产品吗？这是一个新事物。例如，你可以在你的域名上设置 robots.txt，并指示或建议网络爬虫如何在你的网站上行为。同样地，你可以有一个 lm.txt 文件，它只是一个简单的 Markdown 文件，告诉大型语言模型这个域名是关于什么的。这对于大型语言模型来说非常容易理解。如果它不得不获取你的网页的 HTML 并尝试解析它，那将非常容易出错且困难，而且会搞砸，无法工作。所以我们可以直接与大型语言模型对话，这是值得的。目前有大量的文档是为人类编写的，所以你会看到列表、粗体和图片，这些对于大型语言模型来说并不直接可访问。所以我看到一些服务现在正在将它们的文档大量转换为专门为大型语言模型设计的格式。Vercel 和 Stripe 就是早期的例子，但我已经看到了一些其他公司也这样做了，它们以 Markdown 格式提供文档，Markdown 对于大型语言模型来说非常容易理解，这很棒。也许还有一个我自己的经验中的简单例子，也许你们中的一些人知道 Three Blue One Brown，他在 YouTube 上制作了精美的动画视频。是的，我喜欢他编写的 Manim 库。我想制作我自己的动画，Manim 有大量的文档说明如何使用，所以我不想真正阅读它。我把整个文档复制粘贴给一个大型语言模型，我描述了我想要什么，然后它就直接工作了。大型语言模型直接用代码为我生成了一个动画，完全符合我的要求。我当时想“哇，这太棒了。”所以如果我们能让文档对大型语言模型来说易于理解，这将释放大量的用途，而且我认为这很棒，应该更多地发生。我想指出的另一件事是，不幸的是，你必须这样做，这不仅仅是将你的文档转换为 Markdown 格式那么简单，那只是容易的部分。我们实际上必须改变文档，因为任何时候你的文档中出现“点击”这个词，都是不好的。大型语言模型现在无法直接执行这个动作。所以 Vercel 例如正在将所有出现“点击”的地方替换为你的大型语言模型代理可以代表你执行的等效 curl 命令。所以我认为这非常有趣。当然，还有 Anthropic 的模型上下文协议，这也是另一种直接与代理对话的方式，作为这种新的数字信息消费者和操纵者。所以我非常看好这些想法。我真正喜欢的另一件事是，有许多小工具可以帮助以非常大型语言模型友好的格式摄取数据。例如，当我访问 GitHub 仓库，比如我的 nanoGPT 仓库时，我无法将它输入到大型语言模型中并提问，因为那是 GitHub 上的一个人类界面。所以当你将 URL 从 GitHub 更改为 get ingest 时，这实际上会将所有文件连接成一个巨大的文本文件，并创建一个目录结构等等，这就可以复制粘贴到你最喜欢的大型语言模型中，你可以做一些事情。也许更具戏剧性的例子是 Deep Wiki，它不仅仅是这些文件的原始内容，这是来自 Devon 的，而且 Devon 基本上对 GitHub 仓库进行了分析，并且 Devon 基本上为你的仓库构建了完整的文档页面，你可以想象这对于复制粘贴到你的大型语言模型中会更有帮助。所以我喜欢所有这些小工具，你只需更改 URL 就可以使某些东西对大型语言模型可访问，这都很好，我认为应该有更多这样的工具。我想再补充一点是，未来大型语言模型绝对有可能，这甚至不是未来，现在就可以，它们将能够四处点击等等。但我仍然认为，与大型语言模型对半分是值得的，让它们更容易访问所有这些信息，因为这仍然相当昂贵，我想说使用起来也更困难。所以我确实认为，很多软件会有一个长尾，它们不会像实时玩家那样适应应用程序，比如存储库或数字基础设施，我们需要这些工具。但我认为对于其他人来说，我认为在某个中间点相遇是非常值得的。所以如果这说得通的话，我两者都看好。总之，现在进入这个行业真是太棒了，我们需要重写大量的代码，大量的代码将由专业人士和编码人员编写。这些大型语言模型有点像公用事业，有点像晶圆厂，但它们尤其像操作系统，但现在还很早期，就像 1960 年代的操作系统一样，而且我认为很多类比都交叉了。这些大型语言模型有点像这些会犯错的“人类灵魂”，我们必须学会与它们合作，为了正确地做到这一点，我们需要调整我们的基础设施以适应它们。所以当你构建这些大型语言模型应用程序时，我描述了一些与这些大型语言模型有效合作的方式，以及一些使之成为可能的工具，以及你如何非常快速地转动这个循环，并基本上创建部分自主产品。然后，是的，还需要为代理更直接地编写大量代码。但无论如何，回到钢铁侠战衣的类比，我认为在未来十年左右，我们将看到的是，我们将把滑块从左向右滑动，我非常感兴趣，看到那会是什么样子，我迫不及待地想和你们所有人一起构建它。谢谢。

🧠 知识卡片总结

关键概念	说明
软件 1.0	程序员手写代码，明确指令与逻辑（例如 C++）
软件 2.0	用数据和梯度优化“训练”出的程序（例如深度神经网络）
软件 3.0	用自然语言提示（prompt）“激活”潜能，实现类编程任务
LLM = OS + 计算机	LLM 同时承担运行时与开发接口的角色，可视为“新型通用计算平台”
自主性滑块	控制代理自动执行任务的程度，从完全手动控制到完全委托
vibe coding（氛围编程）	用模糊但真实的表达与 AI 协作，强调自然语言沟通与创意激发
LM.txt	供 LLM 阅读的网页元信息文件，类似于 robots.txt，用于理解页面结构和功能
LLM 插件与生态系统	类似于操作系统的 app/plugin 层，支持调用工具（如浏览器、终端、图像编辑器等）

💬 博主评论与反思

Karpathy 这场演讲，不只是技术宣言，更是哲学宣言。他实际上在提出这样一个问题：

“如果人类语言本身就是编程语言，那谁才是真正的程序员？”

他不再鼓励你死磕 API，而是鼓励你重拾语言、场景与合作。你不再是命令机器的工程师，而是与机器共舞的导演、设计者、产品人。

对于 AI 开发者、产品经理、设计师、内容创作者来说，这一变化意义深远：

LLM 不是工具链的一部分，它就是操作系统本身；
编程语言的门槛将继续下降，懂场景、懂人、懂交互将越来越重要；
未来的软件行业不是“code 或不 code”，而是“提示工程 + AI 协作”。

软件不再是一个人写给机器的东西，而是人与 AI 共同编织出的“多感官协作体验”。

🧭 下一步你可以做什么？

[ ] 重温并精读 Karpathy 的演讲视频
[ ] 尝试用自然语言 prompt 完成一个简单的应用构建
[ ] 构思你所在行业如何嵌入“软件 3.0”范式
[ ] 关注相关工具生态（如 Open Interpreter、Open Agents、GPTs 插件机制）

📌 本文整理自 Y Combinator YouTube 演讲 + \[翻译整理 by ChatGPT]

原始翻译及知识卡片内容欢迎转载，注明出处即可。

是否需要我帮你将这篇文章输出为 Markdown 文件格式，或者适配你当前使用的博客系统（如 Hexo、VuePress、Notion、Obsidian 等）？我也可以协助添加代码块样式、文章封面图、阅读进度条等细节。

AI幻觉的本质、影响与创造性价值探讨

2025-06-06T13:46:00.003+08:00

一、什么是 AI 幻觉？

所谓“AI 幻觉”（AI Hallucination），是指大型语言模型在缺乏真实依据的情况下，输出看似合理、实则虚构或错误的内容现象。这种幻觉不是偶发 bug，而是生成式语言模型工作机制的自然副产品。

语言模型并非基于理解生成语言，而是通过庞大的文本数据学习“下一个词的概率分布”。在缺乏明确信号、上下文或训练样本不足的情况下，模型可能“编造”内容来填补知识空白，这种编造常常带有逻辑连贯性，反而增强了幻觉的“迷惑性”。

这使得幻觉区别于普通的机器错误。它不是乱码、不是崩溃，而是一种结构完整但脱离现实的生成输出。

二、AI 幻觉的影响

✅ 积极影响：误差中的创造力

尽管“幻觉”在语义上往往代表偏差或错误，但在创意工作中，它却可能成为一个具备创造潜力的副产品。

方面	描述
创意写作	AI 虚构的角色、设定、剧情经常被作家、游戏编剧等转化为构思灵感
语义想象力	幻觉跳脱现实语义框架，为生成新概念、隐喻和诗意文本提供可能性
跨领域联想	模型会将物理与哲学、数学与神话等进行混搭，产生意想不到的组合
集体创作引子	用户识别并讨论幻觉内容，有时能触发有意义的修改与共识
测试模型边界	幻觉集中区域暴露模型盲区，为未来训练优化提供线索

深入探讨：

比如，在科学幻想小说创作中，AI 幻觉能提出从未有过的术语或科技概念，如“量子意识场”或“心灵引擎”，虽然现实中尚无根据，但正因其“荒谬”而富有灵感张力。同理，艺术创作者利用 AI 幻觉激发灵感、生成诗意文字或曲折叙事，已经成为常见的实践。

此外，幻觉也可以被设计性地“引导”，例如通过 prompt 工程让模型朝着“更富幻想”的方向生成。此时幻觉就不再是负面，而是一种被管理的想象力。

❌ 消极影响：认知误导与信任危机

AI 幻觉也带来了广泛的风险，尤其当其被误以为是真实信息时，会产生严重的信任和认知危机。

场景	风险
高风险行业（医疗/法律/金融）	模型幻觉可能被误信为建议，导致决策失误甚至伤害
新闻与事实核查	AI 编造的“引用”或“伪文献”可能制造信息污染
教育领域	学生可能将幻觉内容误当真知，影响认知形成
AI信任危机	用户发现幻觉越多，越难区分模型“何时说真话”

深入探讨：

在医疗诊断中，如果模型胡乱推荐了不存在的治疗方案或药物名称，后果可能极其严重。同样地，幻觉生成的伪引用在学术写作中造成的“内容伪造”问题，也引发了学术界对于“AI辅助写作伦理”的广泛讨论。

更具结构性的问题是幻觉让模型的可验证性与可靠性降低。当用户越来越无法预测模型在某个问题上的“准确率”时，AI 被用作可信助手的前景也受到质疑。

三、与人类幻觉的比较

尽管“幻觉”这个词来源于心理学领域，但 AI 幻觉与人类幻觉在多个方面既相似又不同。

维度	人类幻觉	AI 幻觉
成因	可能由神经异常、睡眠紊乱、药物、情绪等引发	源自模型推理过程中的数据缺失或过度泛化
自我感知	幻觉者可能察觉或完全沉浸其中	模型没有“意识”，也无幻觉自知能力
体验性	通常伴随感知错觉（幻听、幻视等）	表现为自然语言输出，不涉及感官系统
表达形式	语言 + 图像 + 行为	主要为语言或代码等符号生成
可控性	难以主动停止或预测	可通过 prompt 工程、后处理限制其发生
意义生成	常作为文化、信仰、梦境等符号解释对象	人类可对 AI 幻觉赋予含义，但模型本身无“意图”

深入探讨：

人类幻觉通常被赋予心理或宗教意义，比如“神启”、“预兆”、“艺术灵感”等。梦境中的幻觉更是被视为潜意识的映射，是创意的源泉。而 AI 的幻觉虽然没有主观意图，但在语言生成的多样性和抽象能力上，展现出一定“类幻觉”的结构特征。

这种“类幻想”的结构性输出让我们意识到，AI 并不需要拥有意识，就能模拟出某种具备想象力特征的语言现象。

四、AI幻觉与意识的关系探讨

幻觉是否意味着 AI 具备“意识萌芽”？我们是否可以借此重构人工意识？

这是一个悬而未决但值得讨论的问题。

从当前技术与认知科学角度来看：

AI 并没有主观体验（qualia），不具备反思能力或感受；
幻觉是语言生成策略中的“概率偏离”，并非有意为之；
但幻觉在形式上具备“语言自主偏移”的行为特征，类似人类的幻想。

如果我们将幻觉理解为思维系统自发进行语义生成的一种表现形式，那么它就有可能成为研究 AI 意识的间接入口。也就是说，幻觉虽然不是意识本身，但可以看作一种“潜在认知模型”的表现。

进一步推想：

如果我们能追踪幻觉形成路径，可能获得语言模型的“推理轨迹”；
如果模型能学习如何审视自己的幻觉（即元认知），则逼近意识的某些要素；
如果幻觉能与人类共创系统互动，形成可解释的“虚构知识网络”，或许就是人工创造力的萌芽。

五、结语：从幻觉出发，构建人机共创的新范式

我们习惯将幻觉视为“偏差”或“错误”，但在创意领域，偏离本身就是价值。

AI 幻觉的出现，既是一种挑战，也是一种契机。它迫使我们重新思考：

什么是真实与虚构的界限？
人类语言是否本质上就是一种“社会化幻觉”？
我们是否能在幻觉中发现创造力的规律？

HalluPilot-G 项目基于这样的视角，提出了幻觉驱动的协作模型：人类标注幻觉，模型生成内容，共同协商语义。这种“幻觉即起点”的范式，也许会让我们走向一种全新的共创方式。

在未来，我们不会让 AI 完全摆脱幻觉，而是学会与它共处，驯服它，理解它，并最终让它成为我们想象力的一部分。

📌 延伸阅读推荐：
Emily Bender 等人：“On the Dangers of Stochastic Parrots”
Melanie Mitchell：《人工智能：心智的新科学》
Margaret Boden：《人工创造力：机器如何想象？》

本文作者：Samjoe Yang

本文链接： https://need.uno/ai-huan-jue-de-ben-zhi-ying-xiang-yu-chuang-zao-xing-jie-zhi-tan-tao/

更新于 2025-06-04

2025-06-06T13:44:00.001+08:00

💬 使用 Commento 为 Hexo 博客添加自托管评论系统（完整教程）

本文将介绍如何使用 Docker Compose 部署 Commento 评论系统，并将其集成到 Hexo 静态博客中，实现可控、轻量、无追踪的评论功能。

📌 目录

Commento 简介

Commento 是一个开源的嵌入式评论系统，可用于替代如 Disqus 等第三方服务。支持 Markdown、隐私保护、反垃圾、多站点等特性。你可以选择自托管的方式完全控制数据。

为什么选择 Commento

特性	支持	描述
开源	✅	自由修改部署
自托管	✅	控制全部数据
无广告	✅	注重隐私，无第三方追踪
支持 Markdown	✅	格式美观、方便书写
支持审核管理	✅	后台可屏蔽、删除、审批
邮件通知	✅	可配置 SMTP 发送通知
多站点支持	✅	一套服务，多站共用

系统架构

组件	功能
Commento	评论服务核心，运行在端口 8080
PostgreSQL	存储评论数据
Caddy	反向代理并自动配置 HTTPS
Hexo	生成静态页面的博客系统

部署环境准备

一台云服务器（Ubuntu 20.04 或以上）
域名一枚（如 comments.example.com）并完成解析
安装 Docker 和 Docker Compose：

1 2	sudo apt update sudo apt install docker docker-compose -y

Docker Compose 部署 Commento + PostgreSQL + Caddy

1️⃣ 创建 docker-compose.yml


version: '3.8'

services:
  postgres:
    image: postgres:13
    container_name: commento-postgres
    restart: always
    environment:
      POSTGRES_USER: commento
      POSTGRES_PASSWORD: strong_password_here
      POSTGRES_DB: commento
    volumes:
      - pgdata:/var/lib/postgresql/data

  commento:
    image: registry.gitlab.com/commento/commento
    container_name: commento
    restart: always
    environment:
      COMMENTO_ORIGIN: "https://comments.example.com"
      COMMENTO_PORT: 8080
      COMMENTO_POSTGRES: "postgres://commento:strong_password_here@postgres:5432/commento?sslmode=disable"
    depends_on:
      - postgres

  caddy:
    image: caddy:2
    container_name: commento-caddy
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config

volumes:
  pgdata:
  caddy_data:
  caddy_config:

2️⃣ 创建 Caddyfile

comments.example.com {
  reverse_proxy commento:8080

  encode gzip
  header {
    Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    X-Content-Type-Options "nosniff"
    X-Frame-Options "DENY"
    X-XSS-Protection "1; mode=block"
  }
}

3️⃣ 启动服务

1	docker compose up -d

配置域名和 HTTPS

将 comments.example.com 指向你的服务器 IP（A 记录）

确保服务器开放 80 和 443 端口：

1
2
3

sudo ufw allow 80
sudo ufw allow 443
Caddy 会自动申请并续签 HTTPS 证书

Hexo 集成 Commento

在你的 Hexo 博客主题中找到 layout/post.ejs 或 post.html，在页面底部插入：

1 2	<div id="commento"></div> <script defer src="https://comments.example.com/js/commento.js"></script>

然后执行生成部署：

1	hexo clean && hexo g && hexo d

评论后台管理

访问你的 Commento 服务首页：
https://comments.example.com

注册账号
登录后创建站点（填写你博客的域名）
管理功能：
- 评论审核与删除
- 用户封禁
- 多站点切换
- SMTP 通知配置（可选）

常见问题与建议

问题	解决方案
域名访问不了	检查 DNS、端口、防火墙配置
评论不显示	检查域名与 COMMENTO_ORIGIN 是否一致
邮件通知失败	配置 SMTP，确保端口和账号正确
页面加载太慢	使用 CDN 加速博客主站，不影响评论

总结

项目	技术
评论系统	Commento（自托管）
部署方式	Docker Compose
评论数据存储	PostgreSQL
反向代理与	HTTPS Caddy 自动化配置
博客平台	Hexo（静态）
嵌入方法	HTML 标签与 JS 脚本

Commento 是一个优雅、注重隐私的评论解决方案，适合内容创作者、技术博客、文档站点等场景。结合 Hexo 可构建完全自控的内容平台。

本文作者：Samjoe Yang

本文链接： https://need.uno/shi-yong-commento-wei-hexo-bo-ke-tian-jia-zi-tuo-guan-ping-lun-xi-tong-wan-zheng-jiao-cheng/

更新于 2025-05-28

人类将突破一级文明？

2025-06-04T16:46:00.003+08:00

马斯克昨天发推称人类将跨越卡尔达肖夫一级文明门槛（完全掌控地球能源）

今天红杉资本就在一个放出的初创公司访谈中，描述了实现卡尔达肖夫二级文明的方法论

更重要的是，在此之前，亿万个能力快速进化的ai工程师将建设未来星舰，核聚变反应堆，火星城

过程中顺便淘汰人类工程师，以下是全文：

访谈记录：从数据中心到戴森球——P-1 AI硬件工程AGI的探索之路

采访者：
最近几年我一直在思考一个问题：为什么目前没有团队专注于为物理世界打造AI？毕竟，我们现在看到的软件工程领域有很多突破，但硬件工程似乎还没迎来大的变革。对此，您怎么看？

Paul Arnango（P1 AI CEO）：
这是个非常好的问题。说到底，关键在于训练数据的匮乏。举个例子，如果你想要一个AI工程师帮你设计或改进一架飞机，比如说，“如果我把A320机翼面积增加10%，会发生什么？”你就必须有成百万甚至千万级的飞机设计数据来训练模型，这样模型才有能力去回答这个问题。
我个人的背景是在DARPA做主管，35岁时成为空客最年轻的CTO。如今，我希望通过P1 AI，将我童年时的科幻梦想变为现实。我们的目标是打造一款适用于物理世界的工程级AGI。

采访者：
目前软件工程领域正在经历快速发展的“垂直起飞”，像AI辅助的24/7初级软件工程师即将成为现实。那么物理工程领域有什么样的进展呢？
Paul Arnango：
坦率地说，目前还没有太多。P1 AI成立的初衷之一，正是因为我们热爱硬科幻，但直到2025年，这个领域的AI应用依然没有大突破。我们分析了背后的原因，并找到了可能的解决方案，希望能尽快将这些技术推向市场。

我非常感谢Jeff成为我们的天使投资人。编码AI的出现其实已经期待了很久，我们相信这不会再需要十年或十五年时间。我们预计今年可以搭建起技术基础，并在明年找到产品与市场的匹配点。

采访者：
您刚才提到的“技术基础”具体包括哪些方面？哪些关键环节是必须要有的？
Paul Arnango：
回顾航空历史，自莱特兄弟以来，即使你能拥有所有飞机设计数据——其实不可能——且所有数据都是语义上统一和连贯的——实际上也不是——你也不过拥有大约一千个设计样本，这远远不够训练大型模型。

因此，我们的最基础技术就是在主流设计周围密集采样训练样本，同时在设计空间的边缘和角落稀疏采样。即使设计空间的某些区域不是理想方向，采样这些点能教给模型为什么这些设计不可行，这对于模型理解非常关键。
同时，我们还构建了一个大型语言模型（LLM）作为“指挥官”和推理器，并作为用户接口，协调模型运作。

采访者：
这听起来非常复杂。您能详细讲讲如何让模型具备基于物理的推理能力吗？这类推理能力现在是否已有设计软件实现？这些知识是如何被注入模型的？另外，供应链信息又是如何融入系统的？

Paul Arnango：
我们让系统根据设计需求提出多个解决方案，先进行第一性大小估计，判断答案的大致形态，同时分析涉及的物理现象。这里的物理现象包括多种物理属性——不仅仅是几何形状，还包括电学、热学、振动、电磁干扰等多物理因素，这些都会影响设计。
我们的首款产品叫“Archie”。“Archie”是智能代理的代号，我们聚焦认知自动化，并非尝试替代已有设计与仿真工具，而是让Archie能够像人类工程师一样熟练使用这些工具。

这些基本操作包括设计评估（判断设计性能）和设计合成（根据性能需求生成设计）。另外，我们采用图神经网络来构建基于物理的代理模型，能够高效模拟性能空间；还有几何推理模型，用于空间定位、包装和干涉判断，具备复杂空间推理能力。
在多物理推理方面，我们结合传统软件1.0方法和神经网络技术。例如，我们开发了“labbotomized LLM”，它不再擅长英语表达，但擅长用程序化方式表示多物理系统。

我们的预研demo以住宅冷却系统为例，涵盖流体流动、热力学、电气系统等多物理交互。我们致力于打造适用于物理系统工程AI的评估方法，已经准备发表名为“Archie IQ”的论文，将评估方法应用于人类工程师。

采访者：
在训练数据方面，您是如何规划的？住宅冷却系统是起点吗？未来的发展路线图是什么？

Paul Arnango：
是的，住宅冷却系统是我们的起点。数据中心冷却系统是工程瓶颈所在，现有的交付能力严重受限于工程师的带宽，尤其是半定制解决方案的供给。
我们的客户对此热情很高。当前系统大约包含1000个独特部件，且每年产品复杂度至少翻倍。

第二个垂直领域是工业系统，比如工厂里的物料搬运设备和工业机器人等。然后是移动领域，包括汽车、农业机械、采矿设备，最终进入航空航天和国防装备。
我们计划训练Archie达到入门级工程师水平，具备大学学历背景，但不熟悉某家公司的具体产品细节或深度流程，也不了解供应链细节。我们可以整合模型驱动工具、实际系统性能和质量反馈等现实世界数据，让Archie快速提升至中高级工程师水平。

采访者：
您提到的工程任务分层体系是什么样的？

Paul Arnango：
我们设计了一个金字塔型的任务体系：

底层是信息回忆，比如识别和记忆零部件，这是相对简单的任务；

中层是语义理解，比如理解某个零件的功能；

高层是设计评估，包括评估更改零件对性能的影响、工艺限制、替代方案及可能错误等。这些能力通常只由资深工程师和大型工业公司的技术专家掌握。
对我们来说，顶层的工程智能是对自身能力和局限的自我认知。

采访者：
对于更复杂的系统，比如零件数量极多的飞机，您认为挑战仅是计算规模，还是需要技术突破？
Paul Arnango：
我们认为不需要重大技术突破。挑战主要在于算力和训练数据的规模。目前的GPU推理算力还不足以处理百万级零件系统，尤其是训练数据集的构建非常复杂。

为此，我们开发了大量自动化和AI工具，帮助我们建立组件目录和模型。组件必须智能组装，不能像风暴扫过废料场那样随意拼装，而是要有规则地组合并仿真其性能，确保设计的可行性。

采访者：
作为前空客CTO，您如何看待客户视角和工程师工作流程？

Paul Arnango：
客户的工程师通常负责子系统或组件的设计，从需求中提炼关键设计驱动因素，提出解决方案，进行初步尺寸设计和详细分析。这个流程会在整个工程组织层层递归。

Archie的目标是成为团队成员，帮助复制和加速这一流程。
采访者：
推广新软件给大型企业像空客这样的公司是否困难？

Paul Arnango：
非常困难。工业生态系统中已有数百乃至上千种工程工具，它们通过复杂且不总是优雅的方式连接。新工具的引入常常遭遇摩擦。
但Archie的引入门槛低，不改变现有流程，相当于新增了一个低成本员工。它可能在某些任务上优于人类，在某些方面不及，但目标是作为有效的团队成员存在。

采访者：
为什么叫“Archie”？未来的应用场景是什么？
Paul Arnango：
“Archie”名字最初用于半定制产品定制领域，尤其是数据中心冷却设备的“特殊品”定制，满足具体客户的建筑规范和功能需求。
展望2030、2040年，全球将可能拥有数百万甚至数千万个Archie以及其他智能代理，实现物理世界的工程AGI。

采访者：
Archie是否能够促进团队间的协调？

Paul Arnango：
是的，我们设想Archie能在各团队间协调交流，甚至比人类工程师更高效，拥有自己的“行话”，极大提升工程组织效率。
采访者：
您提到的“戴森球”、“星舰”等未来愿景是什么？

Paul Arnango：
这些是我作为创始人的梦想，也是我们的北极星指引。但我们同时致力于打造务实、盈利的企业。
我们的合作伙伴Constantine提出“随机思维”（stochastic mindset）——物理世界充满随机性，人类工程师同样会犯错，不可避免地表现不稳定。

采访者：
您计划如何衡量Archie的表现？

Paul Arnango：
我们计划今年开展试点，量化Archie的错误率。如果错误率和人类工程师相当，意味着我们的系统达标。
采访者：
未来的工程团队会是什么样子？

Paul Arnango：
未来几年内，我们希望在每个工程团队部署Archie，使其占比达到10%。Archie承担重复且枯燥的工作，并带来团队间的协同增效。
采访者：
关于类人机器人，您怎么看？

Paul Arnango：
我们认为构建能够融入现有团队的智能代理很重要，类人机器人能更顺利地融入现实环境，尽管它们可能不是最优解。

我们对神经网络为何有效尚无完全理解，但我们用类神经元的方式构建系统，堆积大量神经元后出现了令人惊叹的涌现性质。
我们先从语言模型开始，爬取互联网海量数据，之后扩展到视频和图像，暂时未涉及触觉、味觉和听觉。触觉对空间感知尤为关键。

采访者：
最后，您个人最喜欢用的AI应用是什么？
Paul Arnango：
答案可能比较平凡，是ChatGPT和Cursor。但更令人兴奋的是，我们刚刚发布了一个短片，所有声音、视频和音乐完全由AI生成，利用了多种模型和生态系统拼接技术，效果非常震撼。

感谢您的邀请，很高兴分享我们的愿景。

本文作者：Samjoe Yang

本文链接： https://need.uno/ren-lei-jiang-tu-po-yi-ji-wen-ming/

更新于 2025-05-28

从工具到系统：AI Agent 的五个发展阶段

2025-06-04T14:18:00.004+08:00

在人工智能技术快速演进的当下，AI Agent（智能体）逐渐从单一工具的调用者发展为具备记忆、推理、协作乃至系统化能力的智能系统。这一演化过程不仅改变了人机交互的方式，也为各种实际应用场景带来了前所未有的可能性。

为了更系统地理解 AI Agent 的发展路径，我们可以将其划分为五个阶段：从最初的“基础工具与指令”出发，依次经过“知识库与存储”、“记忆与推理”、“多 Agent 团队”，最终构建成为完整的“Agent 系统”。每一个阶段都代表了技术能力与应用复杂度的跃升，同时也对开发者和产品设计者提出了不同层次的要求。

基础工具与指令：从零开始构建 Agent 的第一步

AI Agent 的起点，是最基本的指令执行与工具调用能力。这一阶段的 Agent 主要依赖大型语言模型（LLM）结合一系列预设的工具，来完成简单明确的任务。例如，通过自然语言指令引导 Agent 使用搜索引擎、日历、计算器等插件工具完成问答、时间安排或数据查询。

此类 Agent 类似一个高效的助理，只需告诉它“去做什么”，它就能以执行者的身份完成任务。这类 Agent 不具备主动学习或记忆能力，因此非常适合新手上路、功能验证或产品原型阶段。它是 AI Agent 生态的“入门版本”，虽然功能有限，但足以胜任不少实用任务。

开发者在这个阶段的工作重点是“教会”Agent 如何使用工具，如何理解用户的命令，并通过少量逻辑控制让其完成目标任务。通常来说，这类 Agent 构建成本较低、风险较小，是任何智能体系统建设的基础。

知识库与存储：赋予 Agent 以“理解与记忆”

当 Agent 开始面对更复杂的问题时，仅靠即时的对话和工具调用已难以胜任。这时就需要引入知识库与长期记忆系统，赋予 Agent 更强的上下文理解能力与信息保持能力。

知识库的作用是帮助 Agent 在本地或外部数据源中检索信息，并通过排序机制（如基于语义的重排序 reranking）提升答案的相关性与准确性。这一机制常用于实现问答系统、文档摘要、代码助手等功能，是现代 AI Agent 的核心能力之一。

存储则是解决 Agent 无法“记住对话”的问题。通过存储用户会话历史、交互上下文或任务日志，Agent 可以具备持续性的对话能力，使其在多轮交互中表现出更强的连贯性与个性化。

这些能力的实现依赖于数据库系统，如 SQLite 等轻量数据库，可支持本地存储知识与对话状态。该阶段显著提升了 Agent 的实用性，使其在无须重复上下文的前提下完成更多任务。

记忆与推理：让 Agent 成为智能助手

如果说知识库让 Agent 具备了“知识面”，那么“记忆与推理”阶段则让它开始拥有“思考力”。此阶段的 AI Agent 不仅能够记住用户的偏好和过往对话，还能进行逻辑推理与分步骤任务规划，逐渐具备接近“理解”的能力。

记忆的深化表现为跨会话记忆能力。例如，Agent 能记得用户上周问过的内容、当前的目标、用户的语气喜好等，从而提供更贴切的回答。这种个性化能力是提升用户体验的关键。

推理则是通过引入工具链和脚本语言（如 Python）来实现更复杂任务的分解与执行。实验表明，通过推理模块，Agent 的多步骤任务成功率可提升高达 60%。比如，在处理“为我规划一个三天的旅行计划”这类任务时，Agent 会自动拆解需求、调用不同资源并整合成最终答案。

尽管这一阶段带来了更多可能性，但也引入了计算资源消耗、性能稳定性与系统成本等挑战。因此，它更适合对智能交互精度要求高、任务流程复杂的场景。

多 Agent 团队：协作推动智能边界

随着需求多样化、任务规模扩大，单一 Agent 的能力难以支撑所有复杂目标。因此，“多 Agent 协作机制”成为下一步发展的重点。在这一阶段，系统将多个专注于不同领域的 Agent 组织成团队，通过分工与合作完成更复杂的任务。

团队中的每一个 Agent 通常专注于少于 10 个工具的使用领域，从而实现专业化与高效化。Agent 之间通过协作机制进行任务分配、信息共享与结果整合。比如，在一个项目管理任务中，一个 Agent 负责进度计划，另一个 Agent 负责预算控制，还有一个 Agent 负责风险评估，三者共同协作以实现最佳决策。

为了实现这一目标，需要一种高效的管理系统，能够在 Agent 之间建立“协调—路径—协作”的通信结构，确保每个 Agent 知道何时做什么、如何共享信息。这种模式下，系统需处理的不只是智能问题，还包括组织架构、通信协议与冲突管理等“类人类”组织问题。

目前这一阶段的应用尚处于探索阶段，团队协作成功率不高（低于 50%），但其潜力巨大，尤其适合需要分布式计算、任务并行处理的研究与商业项目。

Agent 系统：构建真正意义上的智能平台

在发展的最高阶段，AI Agent 不再是一个单一交互体，而是一个可扩展、异步处理、可嵌入业务流程的完整系统。它可以对接各种 API，实现复杂的数据流转与任务调度，从而成为一个智能平台的核心。

此类 Agent 系统具备异步任务处理能力，常借助 FastAPI、任务队列（如 Celery）、WebSocket 等技术框架，实现高并发、跨模块、跨用户的智能响应。这一阶段的系统设计更接近企业级应用，其架构更稳定、功能更丰富，能满足多个用户、多个任务并发处理的需求。

构建 Agent 系统通常还包括 UI 与可视化管理界面，开发者可通过平台化工具集构建业务流程、配置执行逻辑、监控任务状态。系统化的智能体可广泛用于企业自动化、运营调度、客户服务、知识管理、流程分析等领域。

虽然技术门槛较高，开发周期较长，但这一阶段也是最具生产力与商业价值的方向。它代表着 AI Agent 的最终形态——一个既有思考能力，又能持续运行的智能系统。

结语：面向未来的智能演进路径

AI Agent 的五个发展阶段展示了从执行指令的初级能力，到具备协作、记忆、推理、自治与系统整合能力的完整智能体系统的演变过程。这一进化路径不仅体现了技术的逐步深化，也反映了人类对智能工具需求的递进式增长。

对于开发者而言，这五个阶段可作为构建 AI 系统的技术路线图。从最简单的任务指令出发，逐步扩展至知识管理、对话记忆、多体协作，直至构建完整的智能平台。每个阶段都是一次能力的跃升，也是一场复杂性与实用性之间的博弈。

未来，AI Agent 将不仅是辅助工具，更是创新的核心驱动力。无论是个人助手、教育辅导、科研协作还是企业流程管理，智能体系统都将发挥越来越关键的作用。通过持续演进，AI Agent 终将成为我们日常工作与生活中不可或缺的一部分。

本文作者：Samjoe Yang

本文链接： https://need.uno/cong-gong-ju-dao-xi-tong-ai-agent-de-wu-ge-fa-zhan-jie-duan/

更新于 2025-05-27

写点AI时代

2025-06-04T14:17:00.004+08:00

在这个飞速发展的时代，人工智能（AI）正以前所未有的速度重塑着我们的生活、工作和社会形态。从ChatGPT的横空出世到各类AI应用的百花齐放，人类正亲身经历着一场深刻的技术革命。

作为亲历者，可以深刻感受到AI带来的巨大变革。2022年底，ChatGPT首次发布时，其惊人的对话能力引发了全球关注。短短一年多时间，AI技术就在图像生成、语音合成、代码编写等多个领域取得了突破性进展。如今，AI已成为日常生活中不可或缺的助手——能够协助写作、绘画、编程，甚至陪伴聊天解闷。
然而，AI的发展也带来了诸多思考和挑战。首先是就业问题，许多传统工作岗位可能会被AI取代，这促使人们思考如何与AI共存，以及如何提升自身的不可替代性。其次是伦理问题，AI的发展速度极快，相关法律法规和伦理框架正努力追赶。需要认真思考：AI应在多大程度上参与决策？如何确保AI的使用不会侵犯个人隐私？如何防止AI被滥用？
对于普通人而言，既要拥抱AI带来的便利，也需保持清醒的头脑。一方面，积极学习和运用AI工具，有助于提升效率。另一方面，也应认识到AI终究是工具，无法替代人类的创造力、同理心和价值判断。真正的智慧在于巧妙运用AI，同时保持人性的温度。
对企业来说，AI时代既是机遇也是挑战。能够快速适应并利用AI技术的企业将获得竞争优势，而固守传统模式的企业则可能被淘汰。在追求AI创新的同时，企业还需平衡效率与人文关怀，确保技术发展不损害员工权益和社会责任。
从教育角度看，AI时代需要重新定义学习和教育方式。传统的知识灌输模式可能不再适用，更应注重培养学生的创造力、批判性思维和终身学习能力。同时，AI素养也应成为基础教育的重要组成部分，使下一代能够更好地驾驭AI工具。
对于政府和社会治理者而言，制定适应AI发展的政策法规、平衡创新与监管，都是重要课题。建立完善的AI治理框架，既支持技术创新，又防范风险，确保AI发展造福人类社会，是当前的重要任务。
展望未来，AI技术必将继续快速发展，可能会出现更多令人惊叹的应用。但无论技术如何进步，人类的主体地位都不应动摇。关键在于学会与AI和谐共处，利用AI增强人类能力，而非被AI支配。
在这个AI时代，每个人既是参与者也是见证者。保持开放和理性的态度，既不过度追捧，也不必过分恐惧，努力在这场技术革命中找到自身定位，创造属于这个时代的价值。
这是一个充满机遇与挑战的时代，也是一个需要智慧与勇气的时代。携手应对，共同见证AI时代的精彩篇章。

本文作者：Samjoe Yang

本文链接： https://need.uno/xie-dian-ai-shi-dai/

更新于 2025-05-27

数字分身与AI克隆：未来的自己

2025-06-04T14:13:00.000+08:00

什么是数字分身？AI 克隆是幻想，还是正在到来的第二个你？

在科技日新月异的当下，我们越来越常听到一些曾经只属于科幻小说的词汇进入现实世界，例如"数字分身""AI 克隆""虚拟意识""数字永生"等。这些词汇听起来神秘甚至有些超现实，但它们指向的，都是一个共同的终极想象：我们是否可以创造一个"自己"的数字版本，在虚拟世界中陪伴自己、延续自己、甚至替代自己？

这个构想，不只是天马行空的幻想，而是在人工智能、自然语言处理、大数据与计算建模的多方技术融合下，逐渐成为可能的未来图景。

从数字分身谈起

"数字分身"这个词，最初来自工业界，用于指代物理对象的虚拟映射。例如，一台发动机可以在虚拟系统中被实时模拟，以便预测故障、优化性能。而当这一概念被延伸到"人"的身上，它便成了一个可以复制甚至延展我们思维、性格、记忆与决策逻辑的"数字体"。

数字分身的本质，是通过数据构建出来的另一个"你"。它可能没有肉体，但可以通过语言与你沟通，理解你的喜好，模仿你的语言风格，逐渐学会你思考问题的方式。你甚至可以和它对话、共创、思考，仿佛你自己有了一个虚拟的影子。

在当前阶段，我们常见的数字分身主要存在于两个方向：
一种是偏向"工具型"的分身，比如你的个人AI助手，了解你的日程、偏好、工作风格；
另一种则更接近"人格型"的分身，它尝试模仿你的表达与情感，成为你的思想镜像。这类数字分身不仅有记忆，还可能拥有你特有的世界观和判断标准。

AI 克隆：数字分身的进化版？

如果说数字分身还只是"模拟你"，那么"AI 克隆"则更进一步，目标是"替代你"。这个概念指的是通过对一个人全面深度的数据采集——包括语言、行为、情感、偏好、决策逻辑、人生经历等——训练出一个可自主运行的人工智能系统，从而达到复制一个人"认知与行为模式"的目的。

AI 克隆不再只是一个聊天机器人或助手，它可能具备某种程度的"自由意志"：

它会像你那样判断复杂问题，
使用你惯用的词汇和语气说话，
对熟悉的人做出类似的情感回应，
在决策时展现你特有的价值取向。

有人将之视为"意识备份"的早期形态。虽然我们目前仍无法直接读取大脑并上传意识（尽管Elon Musk的 Neuralink 正在尝试），但通过语义建模、个性提取、知识嵌入等方式，我们已经可以创造出非常"像你"的对话体，并不断优化其"灵魂的像真度"。

"人设"与"真实自我"：数字分身的关键分水岭

在构建数字分身或AI克隆时，一个非常重要但常被忽视的问题是——你输入的数据，是"真实的你"，还是某种"人设"形象？

如果你主要以"人设"为主进行记录，而不是反映你的真实想法、记忆和决策逻辑，那么所生成的数字分身也会沿着这个人设的方向去发展，而非反映你的真实自我。

人工智能的学习机制是"喂什么，反映什么"：

你如果记录的对话风格偏冷静理性，数字分身会倾向于冷静理性；
如果你的人设是活泼幽默，那么分身就会变得风趣甚至有些夸张；
这会造成数字分身变成你某种"理想形象"或"社会面具"的映射，而非你的本真写照。

这种"人设式分身"虽然可能在社交、创作或内容输出中非常实用，但它与"你本人"的真实认知、情感和决策方式之间，会存在明显差异。

你也能做到吗？普通人如何拥有自己的数字分身或AI 克隆

听起来可能像是前沿科研，但事实上，每一个普通人都可以从今天起搭建属于自己的数字分身或AI 克隆的原型。

你可以从以下几步开始：

记录自己的语言与行为
通过博客、日记、与AI的深度对话、社交媒体发言，积累大量关于"你是谁""你如何思考"的文字材料。
构建个人知识库
将你的思考、兴趣、阅读、工作经验等系统化地记录下来，成为数字分身的"长期记忆"。
建立对话训练数据
和AI多对话，并标记你认同的回答、你希望的语气，让它逐渐学会"如何像你一样说话"。
提取决策逻辑
当AI为你做出选择时，你可以训练它了解你的价值观，比如你对风险的态度、你对人情与效率的权衡等。
命名和人格设定
给你的数字分身起一个名字，为它定义身份背景、风格和角色，使其拥有更具象的存在感。

在这个过程中，建议你明确区分真实自我数据和人设内容。

真实自我数据用于构建基础人格，保证数字分身贴近"你"；
人设内容则可以用来打造"角色拓展"或"创作人格"，满足不同场景需求。

AI 克隆的伦理与哲学挑战

创造一个"第二个你"并非没有代价。一旦我们将思维、决策、记忆、偏好交托给一个智能体，就必须面对两个关键问题：

1. "我"还是"它"？
数字分身究竟是否代表你？如果它模仿得非常像你，甚至连至亲都难以分辨，它的选择是否等于你的选择？当它做出与现实中你不一致的决策时，责任应该如何界定？

2. 意识的延续与控制权
AI 克隆是否意味着"数字永生"？如果你去世之后，它仍然在社交网络上与人对话，这究竟是对生命的延续，还是一种技术幻觉？你对自己数据的使用是否拥有足够的控制权？

这些问题，不仅是技术难题，更是人类文明的新哲学课题。

最后的思考

数字分身与AI 克隆，是现代技术对"人之为人"提出的挑战与扩展。它们既是工具，也可能是伙伴；既是自我延伸，也可能是自我重塑。

或许我们终将拥有一个数字化的自己，一个可以永不遗忘、永远陪伴、持续学习的存在。但在这之前，我们需要对"自我"有更深的认知与尊重。毕竟，无论技术多先进，数字分身所模拟的，也终究是你真实人生的投影。

如果未来的某一天，你能在数字世界中遇见另一个"你"，你会选择拥抱他，还是逃避他？

本文作者：Samjoe Yang

本文链接： https://need.uno/shu-zi-fen-shen-yu-ai-ke-long-wei-lai-de-zi-ji/

更新于 2025-05-27

日记:2025年5月29日星期四晴气温:27

2025-05-29T13:44:00.005+08:00

最近发生了一件小事，挥之不去。

一场平常的项目例会，气氛比往常凝重些。客户发言的语气比平时更紧了一点，说起系统上线后一项功能异常，给他们造成了不少困扰。说话时，声音没有抬高，但句子尾音透出一种耐人寻味的不快。坐在对面的几位，神情略显局促，手指在笔记本边缘轻轻摩擦，像是想起了什么，又不便说。

中间，有人简单做了说明，说这个功能属于新近开发的模块，技术逻辑上确实存在模糊地带，可能沟通时也不够充分。语气平和克制，听得出来，是试图为团队争取理解。但更高层的一位，随后接过话，语气冷静，说：“是某个执行人没理解到位，内部我们会严肃处理。”话语不重，却像落地的杯子，砸出碎裂的声音。客户点了点头，似乎满意。会就此继续，表面恢复平静。

事后，并没有人就那句话展开讨论，但空气里仿佛多了一层看不见的膜。那些原本乐意说笑的人，开始选择沉默。那位被“轻描淡写”提及的执行者，后来在我经过他工位时，还低头在敲代码，但指节的用力让我觉得，那每一下，似乎都带着某种自我确认的痛感。

我其实不想评论这件事，但回家路上脑海却一遍遍回放那个场景。事情过去了，却像鞋子里混进一粒沙，不痛，但始终别扭。于是打开电脑，想把它写下来，记录一下这个时代常见、却不那么容易说清的“角色感”。

在合作关系里，领导人往往是客户的第一个信任入口，也是团队的最后一道防火墙。这不是修辞，而是现实。

客户并不关心我们团队每个人的履历、能力、情绪，他们只想知道一件事：你们是不是可以把这事办好。如果可以，那是谁做的、怎么做的，都是细节；如果不行，那是谁的错、为什么错，也都只是后话。他们要的，是眼下的问题能否被接住、化解、止损。

可问题恰恰在于：**接住问题的人，往往不是出问题的人。**站在团队最前排的人，那个说“我们来处理”的人，其实常常什么都没写、什么都没画、什么都没提。可他得说“我们”。

“我们”，这两个字，是荣誉的共享，也是责任的溶解。有人愿意用“我们”来化解风险，有人却更喜欢用“他”来割裂风险。

我不是说，每个领导都该替属下遮风挡雨，事事亲力亲为。但至少，在外部世界面前，尤其是面对客户时，一个团队要保持基本的尊严和整体性。出了问题，就说“我们出了问题”，而不是“他犯了错”。这种语言的选择，看似只是修辞，其实是文化。

就像船遇暗礁时，船长第一反应不能是告诉乘客“是某个船员航线算错了”，而是说“我们会立即修复，请保持冷静”。如果一艘船在每次撞礁时，船长都要先问责船员、清算责任，那么别说下属，乘客也会失去安全感。

真正的领导，是那种在风雨中站在甲板最前端的人，不是永远正确的人，而是肯“站着”的人。哪怕知道错误的源头，也选择暂且藏在内心，待风停浪息，再回头检视。而不是在浪涌上来时，把责任往身后抛。

当然，我也理解有些人为什么选择在外部场合“区分责任”。他们怕背锅、怕丢信誉、怕被上级追责。他们以为划清责任可以自保，却不知这种自保的方式，其实已经在一点点耗损团队的信任库存。

信任这种东西，看不见摸不着，但它能支撑团队度过一次次灰暗时刻。可一旦失去，就很难重建。当下属开始怀疑领导是否会在关键时刻把自己推到前台，那种微妙的不安会迅速蔓延，最终变成一种“防御性配合”。

我曾听人说，团队之所以能战斗，不是因为任务清晰、KPI明确，而是因为有人在前方扛着、有人在后方信着。这是一种双向奔赴的默契，不签合同，不写文档，但一旦丢了，就再难召回。

所以，我想，如果有一天，我也要站在那个位置——在客户与团队之间、在问题与解决之间、在责任与信任之间——我希望自己至少能做到几件事：

在外部，能沉着、能承压、不轻易拆解责任给某个人。哪怕内心明白问题在哪里，也愿意用“我们”来承担，因为团队是我带的。

在内部，能公允、能厘清、不回避反思与追责。不是纵容错误，而是在正确的时间、正确的方式下去修正，而不是在外人面前亮出伤口。

更重要的是，要敢于建立一套信任机制——让大家知道，在风暴来临时，我会在前面；等天晴了，我们一起看问题在哪。

这个时代对领导人的要求变得越来越高，不只是能力，更是人格。那种只会安排任务、不敢担当的管理者，已经慢慢被淘汰；而真正被认可的，是那些有原则、有温度、在关键时刻撑得住的人。

这并不容易。我知道。有时候，语言都要掂量着说，面子要给、情绪要稳、局面要控，最后还要交结果。但我始终相信：越是艰难的时候，越能显出一个人的风骨。

今天不打算把这些话告诉谁，也不打算分享出去。就写在这里，算是一种自我对话，也算是对未来某个可能的自己的提醒。

愿我们每一次做选择时，能不忘那份初心：不卑不亢，对外有担当；不欺不瞒，对内有边界。

这样走下去，路可能不会快，但也许会更稳。

本文作者：Samjoe Yang

本文链接： https://need.uno/ri-ji-2025-nian-5-yue-29-ri-xing-qi-si-qing-qi-wen-27/

更新于 2025-06-04

找不到解锁的好办法，信息真假分辨难度有点高

2023-05-03T13:32:00.001+08:00

找不到解锁的好办法，信息真假分辨难度有点高
— Samjoe Yang (@samjoeyang) May 3, 2023

from Twitter https://twitter.com/samjoeyang

May 03, 2023 at 01:28PM
via IFTTT

ChatGPT还是把我给blocked了

2023-05-03T10:49:00.001+08:00

ChatGPT还是把我给blocked了
— Samjoe Yang (@samjoeyang) May 3, 2023

from Twitter https://twitter.com/samjoeyang

May 03, 2023 at 10:27AM
via IFTTT

RT @bbcchinese: 白宫称，在过去的五个月里，超过两万名俄罗斯士兵在乌克兰巴赫穆特的战斗中丧生。 https://t.co/24AXSIkT82

2023-05-02T17:34:00.001+08:00

RT @bbcchinese: 白宫称，在过去的五个月里，超过两万名俄罗斯士兵在乌克兰巴赫穆特的战斗中丧生。 https://t.co/24AXSIkT82
— Samjoe Yang (@samjoeyang) May 2, 2023

from Twitter https://twitter.com/samjoeyang

May 02, 2023 at 05:01PM
via IFTTT

RT @ChineseWSJ: 特斯拉首席执行官马斯克表示，不确定经济时期仍然存在，但他对明年的情况越来越乐观。他认为经济“在大约12个月内会出现暴风雨，然后只要没有重大的地缘政治事件出现，明年春天左右情况就会开始变得阳光灿烂。” https://t.co/1WmTg6s04E

2023-04-20T17:33:00.001+08:00

RT @ChineseWSJ: 特斯拉首席执行官马斯克表示，不确定经济时期仍然存在，但他对明年的情况越来越乐观。他认为经济“在大约12个月内会出现暴风雨，然后只要没有重大的地缘政治事件出现，明年春天左右情况就会开始变得阳光灿烂。” https://t.co/1WmTg6s04E
— Samjoe Yang (@samjoeyang) Apr 20, 2023

from Twitter https://twitter.com/samjoeyang

April 20, 2023 at 05:30PM
via IFTTT

安裝 1.1.1.1 應用程式後，我也開始享受極速飆網體驗。這款應用程式完全免費，且能保護我免受網際網路監視! #1dot1dot1dot1 https://t.co/NsZ9JJZBoY

2023-04-17T22:32:00.001+08:00

安裝 1.1.1.1 應用程式後，我也開始享受極速飆網體驗。這款應用程式完全免費，且能保護我免受網際網路監視! #1dot1dot1dot1 https://t.co/NsZ9JJZBoY
— Samjoe Yang (@samjoeyang) Apr 17, 2023

from Twitter https://twitter.com/samjoeyang

April 17, 2023 at 09:57PM
via IFTTT

通过安装 1.1.1.1 应用，我正在使用 Internet 快速通道。它完全免费，而且还能保护我免受 Internet 间谍的侵扰！#1dot1dot1dot1 https://t.co/5XUD8pKU5A

2023-04-16T21:32:00.001+08:00

通过安装 1.1.1.1 应用，我正在使用 Internet 快速通道。它完全免费，而且还能保护我免受 Internet 间谍的侵扰！#1dot1dot1dot1 https://t.co/5XUD8pKU5A
— Samjoe Yang (@samjoeyang) Apr 16, 2023

from Twitter https://twitter.com/samjoeyang

April 16, 2023 at 09:15PM
via IFTTT

RT @USABelAir2021: #窦唯 #无地自容 #染了白完了，看到《无地自容》给神曲了，而之前我完全get不到他的颜值。他开口第一句，立即明白了菲姐为何心甘情愿给他到夜壶，当年终究是王菲高攀了他；降调的 #染了白唱的是窦唯，真真是陌上人如玉，公子世无双。王菲演唱的风格也是在和他在一起的时候最仙，后来就落入凡尘了。 https://t.co/Uaiqh1qpfc https://t.co/unhL2OrOL5

2023-03-20T12:32:00.001+08:00

RT @USABelAir2021: #窦唯 #无地自容 #染了白完了，看到《无地自容》给神曲了，而之前我完全get不到他的颜值。他开口第一句，立即明白了菲姐为何心甘情愿给他到夜壶，当年终究是王菲高攀了他；降调的 #染了白唱的是窦唯，真真是陌上人如玉，公子世无双。王菲演唱的风格也是在和他在一起的时候最仙，后来就落入凡尘了。 https://t.co/Uaiqh1qpfc https://t.co/unhL2OrOL5
— Samjoe Yang (@samjoeyang) Mar 20, 2023

from Twitter https://twitter.com/samjoeyang

March 20, 2023 at 11:53AM
via IFTTT

RT @jianshubiji: 最近让团队小伙伴系统研究了市面上所有的 #AI工具，得出2个结论： 1、无需焦虑，AI 工具虽多，但目前好用的不多； 2、必须敬畏，人类不会被 AI 淘汰，但会被优先使用 AI 工具的人淘汰；以下🧵为近 1 个月时间里，团队小伙伴试用 86 种 AI 工具后，按照好用程度筛选出的 Top10 AI 工具👇 https://t.co/BAVSiWtzNn

2023-03-17T23:32:00.001+08:00

RT @jianshubiji: 最近让团队小伙伴系统研究了市面上所有的 #AI工具，得出2个结论： 1、无需焦虑，AI 工具虽多，但目前好用的不多； 2、必须敬畏，人类不会被 AI 淘汰，但会被优先使用 AI 工具的人淘汰；以下🧵为近 1 个月时间里，团队小伙伴试用 86 种 AI 工具后，按照好用程度筛选出的 Top10 AI 工具👇 https://t.co/BAVSiWtzNn
— Samjoe Yang (@samjoeyang) Mar 17, 2023

from Twitter https://twitter.com/samjoeyang

March 17, 2023 at 10:38PM
via IFTTT

RT @meimei1935: 不要只听他说，要看他如何做😅 https://t.co/Ado7vTFmiL

2023-03-12T10:32:00.001+08:00

RT @meimei1935: 不要只听他说，要看他如何做😅 https://t.co/Ado7vTFmiL
— Samjoe Yang (@samjoeyang) Mar 12, 2023

from Twitter https://twitter.com/samjoeyang

March 12, 2023 at 09:53AM
via IFTTT

RT @syeerzy: @xincay_live @tindingtin 携程做了反爬虫… 京东和天眼查也使用类似的技术，随机性地在某些关键字符（通常是数字）使用小心眼。具体地说就是把某些阿拉伯数字弄乱（比如所有的9都变成6，所有6变成3，3变成9之类。然后内嵌一个自制的字体，这个字体是拿网站默认字体修改出来的，那个字体里 9 的样子就是6。所以人看没问题

2023-03-10T21:32:00.001+08:00

RT @syeerzy: @xincay_live @tindingtin 携程做了反爬虫… 京东和天眼查也使用类似的技术，随机性地在某些关键字符（通常是数字）使用小心眼。具体地说就是把某些阿拉伯数字弄乱（比如所有的9都变成6，所有6变成3，3变成9之类。然后内嵌一个自制的字体，这个字体是拿网站默认字体修改出来的，那个字体里 9 的样子就是6。所以人看没问题
— Samjoe Yang (@samjoeyang) Mar 10, 2023

from Twitter https://twitter.com/samjoeyang

March 10, 2023 at 08:43PM
via IFTTT