世界纪录，Qwen 3.8 27B 单台 125 token！

经过昨天一晚上的调优，懒猫 AI 算力仓单台跑 Qwen 3.8 27B 的性能测试结果：prefill 速度 3754 TPS（思考更快），长代码解码速度 125 TPS（写代码更快），八会话代码解码速度 231 TPS（性能压榨到极限），显存占用 70GB。

Qwen 3.8 27B 这种模型，虽然看着很小，但是它是稠密型的模型，它的 27B 是专注于写代码的，我最近都是在本地用它写代码，它的最大的好处就是单台就可以跑，而且永远不降智，我最近 GPT 降智非常严重。

相对于 Mac Studio 优势是，英伟达芯片 prefill 性能高很多，并发能力强很多，兼容 CUDA 生态，而且价格便宜太多了。

所以说老板们不要等了，我们还有优惠的机器，赶紧冲吧！这时候买，不但享受我们顶级 AI 模型团队给你做世界上最好的性能调优，而且价格是非常优惠的，千万不要错过，评论区打 1。

via https://manateelazycat.github.io/feed.xml

Invalid media: image

Qwen 3.8 27B YaRN 768K 上下文实测

有人建议测一下开启 YaRN 扩展上下文后的表现，说 Qwen 3.8 27B 可以扩展到 1M 上下文。

我试了一下，Qwen 3.8 27B 通过 YaRN 技术最多可以把上下文从原版 265K 增加到 768K。

1M 上下文主要是 KV Cache 就需要 84GB 显存，差 3GB 显存😂

在这台 128GB 机器上的具体测试结果：

● 1M：启动失败，KV Cache 需要约 83.68 GiB，可分配约 80.32 GiB
● 768K：可启动，KV 容量约 882K token，max_model_len=786432
● 512K：可启动，10 万 token 请求成功
● 接近上限时 TTFT 极长，760K/500K 测试未在测试窗口内产生首 token

当前统一内存约使用 107.5/125.8 GB，可用约 17 GB，因此这台 128GB 机器目前实用上限是 768K，不是 1M。

我一会试一下这个 768K 上下文的时候，在日常的编程中能不能打，不能光看参数，我要去实战压测一下😎

via https://manateelazycat.github.io/feed.xml

Invalid media: image

vLLM 默认多模态参数导致 Qwen 3.8 27B 报错

NND，今天正在用 Pi Agent + Qwen 3.8 27B 整活呢，突然就报错了，我最开始还以为是 Pi Agent 配置和 Qwen 不兼容，最后发现不是。

然后我又以为是我部署的 Qwen 3.8 27B 模型有问题，看了一圈不对啊，Qwen 3.8 27B 本身就是多模态的模型呀。

最后发现，NND，原来是部署的时候 vLLM 默认加了下面这两个参数：

--limit-mm-per-prompt.image 2
--limit-mm-per-prompt.video 0

第一个的意思是，如果上下文超过 2 张图片，vLLM 就直接报错，第二个的意思是，禁止发送视频文件给大模型。

我把这两个参数删除以后，重启 Docker，世界安静了，Qwen 3.8 27B 又开始干活了。

via https://manateelazycat.github.io/feed.xml

Invalid media: image

挑战成功，Qwen 3.8 27B 实现 900K 的代码上下文。

利用 YaRN 技术实现 Qwen 3.8 27B 模型从 786K 提升到 900K 的挑战，整个模型占了 120GB 的显存。

900K 的上下文无限接近于 1M 上下文，意味着世界上 99% 的代码项目，利用 Qwen 3.8 27B 本地 AI 都很难遇到因为上下文不足而降智的问题。

做个对比：

● 懒猫 AI 算力舱单流可以实现 133 Tokens 的速度，4090 只能实现 40 ~ 50 Tokens
● 懒猫 AI 算力舱上下文可以达到 900K，4090 因为显存太小最多只能实现 128K 的上下文
● 4090 上你只能跑 Qwen 3.8 27B，但是你一旦遇到大型的代码项目，马上就会因为上下文不足降智

懒猫 AI 算力舱跑 Qwen 3.8 27B 不但速度超快，还可以不降智地支持 99% 的大型代码项目稳定运行。

via https://manateelazycat.github.io/feed.xml

Invalid media:
image
image

算力舱AI模型适配实录：

DeepSeek V4 Flash

通过两台协同计算的方式，一台计算一半最终对结果，实现稳定 70 TPS 的效果，顺带把上下文从 131K 拉到了 382K。主打日常 Agent 全能。

Qwen 3.8 27B

稠密计算模型小钢炮，通过 DFlash2 优化，最终实现单流 125 ~ 133 TPS、8 并发 231 TPS 的效果。虽然 27B 稠密模型计算非常耗费性能，但是显存消耗不多，可以做大量 KV Cache。最终通过 YaRN 技术把上下文从官方的 265K 拉到恐怖的 900K，代码智力爆表 + 超大上下文。主打离线代码 GPT。

Qwen 3.8 Flash Next

相对于社区两台方案，昨晚实现单台就可以稳定跑。昨晚首先测试了 n-gram 的方案，虽然 decode 速度最高可以到 92 TPS，但发现这个方案纯粹是噱头——只有抄重复代码的时候快，Prefill 只有 100 多，而且上下文太小只有 64K。最后还是换传统的 MTP 方案，现在日常解码稳定在 60 TPS，Prefill 2232 TPS，上下文也增大了 265K，这样的数据更适合日常写代码。

看看我晚上能优化到什么水平？

等 Qwen 3.8 Flash Next 优化完，我准备继续挑战两台 GLM 5.3 Flash。大佬们你们想要我移植什么 AI 模型？评论区留下你的建议 😎

via https://manateelazycat.github.io/feed.xml

介绍一家最近去的头马 Toastmasters 演讲俱乐部

via Owen - Featured posts

Qwen 3.8 27B：算力舱还是 Mac Studio？

最近在优化 Qwen 3.8 27B 模型的过程中，发现一个值得分享的现象。

像 Qwen 3.8 27B 这种稠密型 + 超级重思考的 AI 模型，其实非常适合算力舱这种 2070T 算力的机器。Prefill 轻松可以干到 3500 ~ 4000 TPS。

原因在于，Qwen 3.8 27B 70% ~ 80% 的时间都在思考而不是在 decode，所以 Prefill 的性能至关重要。算力舱凭借英伟达的芯片能力，在 Prefill 阶段表现非常出色，正好契合这类模型的特性。

Mac Studio 的短板

Mac Studio 这种显存带宽很大的机器反而不适合 Qwen 3.8 27B 这类模型。因为 Mac 的绝对芯片能力还是离英伟达很远，Prefill 能力不行——你会发现 Apple 只宣传显存带宽，但从来不宣传 Prefill 速度。

当模型把大部分时间花在思考上时，思考时间过慢就成了瓶颈。Mac Studio 的 Prefill 速度跟不上，导致整体推理效率大打折扣。

Mac Studio 更适合什么

Mac Studio 更适合那种非思考模型——想得很少、一顿狂干的那种。对于不需要大量 CoT（Chain of Thought）推理的模型，Mac Studio 的大显存带宽优势才能发挥出来。

小结

选择硬件不能只看显存带宽，还要看模型的推理范式。对于重思考的稠密模型，算力舱这类英伟达方案在 Prefill 上的优势是决定性的；而对于轻思考的模型，Mac Studio 的大显存带宽才是真正的杀手锏。

via https://manateelazycat.github.io/feed.xml

懒猫读书 iPad OOM 问题排查与修复

20 年古法编程，非遗手法就是 “远程把脉”。

今天有一个用户反映懒猫读书会导致平板卡死，我一看，好家伙，超大文件 PDF 彩印文件。

排查过程

1. 先排除是不是机械盘 IO 问题——用户说用的固态盘，排除 IO 瓶颈。
2. 扫描 PDF 的后台有渲染进程，问题肯定出在这条逻辑支流上。
3. 问了一下用户，是打开就卡死，没有做缩放操作，排除缩放分支。
4. 让用户试一下手机，手机没问题。再问平板内存，iPad 6。

原因很清楚了：PDF 过于大，首屏渲染高清图片加上后面几页预加载，瞬间内存过大触发了果子家的 OOM，直接把前端 WebView 进程干死了。

修复方案

做更精细的视口渲染，保持清晰度和操作不变的情况下，让后端只发屏幕区域和缩放比例的图，把内存占用控制在常量，减少 90% 的内存占用，这样果子就不会杀进程了。

远程定位问题，三下五除二找到根因，这就是二十年老程序员的手感。

via https://manateelazycat.github.io/feed.xml

世界纪录，Qwen 3.8 Flash Next 单台 102 TPS！

经过三天的优化，我已经把 Qwen 3.8 Flash Next 在单台算力舱的 Decode 速度实现了从 23 TPS -> 65 TPS -> 102 TPS 的跨越，应该还可以再提升一点。

在 102 TPS decode 速度下，18K Prefill 的速度实现了 2588 TPS，30K TTFT 实现 11.43s。

这个数据估计很多两台 DGX 都很难达到，因为在 FP4 的精度下，我们算力舱的 T5000 芯片的算力是 2070T，DGX G10 是 1000T。相当于算力舱一台的价格，就可以实现两台 DGX G10 组合才能达到的性能。

via https://manateelazycat.github.io/feed.xml

Qwen 3.8 Flash Next：101 TPS + 320K 上下文

Qwen 3.8 Flash Next 在单台懒猫AI算力舱上反复优化，这个应该达到极限了：Decode 100 ~ 102 TPS，Prefill 2070 ~ 2609 TPS，TTFT 5K 1.9s。

接下来把上下文增大。官方是 265K 的上下文，但是显存没用满呀，所以我通过 YaRN 技术把 Qwen 3.8 Flash Next 的 KV Cache 调大到 16GB，这样上下文就从 265K 搞到 320K 了。

除了 Fresh Decode 稍微下降一点点，其他的指标兜没变，甚至 Edit Decode 速度还提升了，哈哈哈哈。

优化了72小时后，Qwen 3.8 Flash Next 终于被我调教的差不多了，明天整要给图形化的部署程序给懒猫AI算力舱的用户用。

而社区DGX GB10要两台才能做到 100+ TPS，为啥算力舱可以一台搞定呢？因为 FP4 的算力，算力舱是GB10的2倍，因为算力够，显存够，一台算力舱直接访问显存的速度要比两台GB10的光口快太多了，反而效率更高。

via https://manateelazycat.github.io/feed.xml

Invalid media:
image
image

离线AI设备买的是什么?

今天用 Qwen 3.8 27B 写代码的时候，和一个用户聊了一晚上，分享一下我对离线 AI 设备的看法。

成本账：深度用户才划算

深度 AI 用户，7x24 小时地用，跑长线任务，肯定硬件划算，一年就赚钱。但是你平常用线上 API 都不超过 2000 块，确实离线 AI 设备帮不了你。

Mac：Decode 优秀，Prefill 很弱

Mac 的显存带宽和 Decode 能力非常优秀，但是 Mac 的 Prefill 非常差，并发也很差，CUDA 不支持。Mac 从来不说这些，所以买东西要理性，多看多对比，理性选择自己想要的东西。

买设备是买认知

你只用线上 API，你在 AI 上的认知就和所有用线上 API 的人的认知是一样的，而 AI 未来的发展一定会让每家每户都有离线 GPT。你早一天用离线设备，就早一天获得竞争性优势，因为你比别人更懂离线 AI，就跟 20 年前你比别人更早玩电脑编程一个道理，那时候大家都还在犹豫要不要买一台笔记本？

所以，买 AI 设备，不能光看成本，要看你能用自己的设备做出哪些不一样的产品来？离线 AI 设备的目的不是否定在线 AI，而是在在线 AI 也用的情况下，你能通过折腾离线 AI 设备获得哪些未来在社会上的竞争力？

简单来说，买设备从来都是投资，而不是省钱，只比省钱是没法赚钱的。

via https://manateelazycat.github.io/feed.xml

30B 稠密模型就能解决个人编码的需求

我今天针对一个 AI 模型做深入分析，Qwen 3.8 27B xhigh 的速度比 GPT 5.6 sol Max 快 5 倍不止，而且 Qwen 3.8 27B 分析的结论非常严密。

包括今天和英伟达的芯片架构师聊过，他的一个观点：

“30B 的稠密模型就能解决个人编码的需求，以后不需要高显存带宽的更贵机器，因为 AI 模型本身会进化”

这句话就像我今晚做的试验一样，Qwen 3.8 27B 的足够能力，让我觉得，其实 GPT 再强大，它后台的服务器集群再牛逼，也许分到每个用户身上，就是 30B 的算力资源。

via https://manateelazycat.github.io/feed.xml

自由泳最关键的是手臂要伸直

这两天受教练的指导发现：其实自由泳最关键的是手要伸直，手没有伸直的时候，侧身就会扭曲导致身体摇摆，而不是自由泳的流线型。

原来手臂一直是弯的

之前一直以为手臂入水是直的，拍了视频才发现是弯的，如同敬礼的状态。

矫枉过正，以毒攻毒

教练最后说，你这种自学的人，直接来个矫枉过正，以毒攻毒吧，你手臂入水的时候用八字方式入水。

果然，这一下手臂入水直了，身体摆动和游速都快多了。

via https://manateelazycat.github.io/feed.xml

快速入睡技巧：仰卧在床上，做 10 组“4-7-8 呼吸法”（吸气 4 秒，屏息 7 秒，呼气 8 秒）。 然后从 300 开始，以 3 为单位倒数。呼吸能减缓心率，而倒数则能防止思绪纷飞。这种方法效果极佳，简直就像服用了安必恩一样。

— Michael Breus

4-7-8 呼吸法，我感觉有点难做到。Apple Watch 上正念冥想 App 里有这个呼吸的工具，对我来说没什么用。

但是头脑中摸摸倒数对助眠非常有用，我最近一周都在用这个方法。不过我没有用以 3 为单位倒数（今晚可以试一下！），直接倒序 300，299，298 这样对我来说已经很管用了。有的时候我倒数到 1 依然还没睡着，这时我会再开始一轮，第二轮我会从 500 开始，有时第一轮也会直接从 500 开始（当我预测自己还不够困的时候）。

这个助眠方法比我以前用的任何方法都管用。因为我的睡不着，主要原因就是思绪乱飞，强制自己倒数的话，思绪也会乱飞，但是重点是你会意识到，并且继续回到倒数中，直到睡着。

推荐有睡眠问题的朋友试一下。

via Owen - Featured posts

如何摆脱多巴胺文化?

● 有很多人因为无法抗拒划屏的冲动，而放弃了生活中必不可少的事情： ● 那些宁愿刷屏也不愿睡觉的人 ● 那些只顾刷屏而不进行体育锻炼的人 ● 那些只顾刷屏，却不去寻找人生伴侣，也不去与有血有肉的人建立联系的人 ● 那些只顾刷屏，却不去学习技能、找工作或追求职业发展的人
● 担心这些“屏幕僵尸”不读书，听起来几乎有些古板。简单的事实是，由于硅谷强加给他们的技术变革，他们整个生活正日益受到影响。但更令人不安的是，全球最大的企业正投入数十亿资金，以推广和加速人们对其技术工具的这种强迫性使用。
● 以下是我们可以采取的措施，以建立与科技之间更健康的关系。 ● 你不必扔掉手机——但明智的做法是尽量减少对滚动和滑动界面的依赖。 ● 走入世界，重新发现在我们还没有数字应用程序之前，真正的应用程序是什么样子的 ● 我从未加入过童子军（这个故事我改天再讲），也几乎从未为此感到遗憾。不过有一点例外——我很喜欢“功绩徽章”这个概念。要获得一枚徽章，就得走入社会，掌握一些应对现实生活的新技能。 ● 因此，你可以学习钓鱼、攀岩、园艺、急救、摄影、射箭、划船、背包旅行，以及许多其他技能。 ● 那便是我们还没有“应用”之前的“应用”。 ● 这些活动你现在依然都可以参加，每一项都不例外。而且你不需要穿童子军制服。 ● 如果你对户外活动不太感兴趣，也可以选择室内活动——烹饪课、读书会、瑜伽、戏剧，等等。 ● 这就是现实世界。这就是你在现实世界中培养自信和掌握技能的方式。这不仅仅是为了学习技能——做这些事情还能让你与社区以及其他人建立联系。没有任何一款应用程序能比得上这种个人能力的提升。

 ★ 

via Owen - Featured posts

如果你想卖音乐，就必须热爱那些歌曲。如果你想在新闻界取得成功，就必须热爱那些报纸。如果你想在电影界取得成功，就必须热爱电影。

— honest-broker.com

via Owen - Featured posts

如果你不希望自己的孩子接触它，却又靠出售它获利，那你就是在做伦理上自相矛盾的事。Tony 由此主张，产品创造者不能只说“我们是中性平台”，而应明确告诉用户这个在线社会相信什么、禁止什么。餐厅会把骚扰其他客人的人赶出去，技术平台同样可以设定边界、管理私人空间。所谓社会责任，在他看来不是事后加一套公益项目，而是在产品建立时就决定什么值得被鼓励、什么不应该被允许。

— chatgpt.com

via Owen - Featured posts

Firefox 插件注册、检测和自动签名方法

最近给 Firefox 做插件，才发现 Firefox 和 Chrome 的离线插件安装方式完全不一样。

Chrome 可以打开开发者模式，直接加载解压后的插件。Firefox 正式版和 Firefox ESR 安装 XPI 时会强制检查 Mozilla 签名，未签名的 XPI 即使代码完全正常，也会提示插件损坏或者签名无法验证。

about:debugging 虽然可以临时加载未签名插件，但 Firefox 重启以后插件就没了，只适合开发调试，不能用来给用户发布插件。

下面记录一下 Mozilla Firefox 插件的注册、上传检测和获取 API 信息的方法。

注册 Mozilla 开发者账号

先打开 Mozilla 插件开发者中心：

https://addons.mozilla.org/developers/

点击登录，用 Mozilla Account 登录。没有账号就先注册一个，然后同意 Firefox Add-ons 的开发者协议。

Mozilla 不需要提前单独注册一个插件 ID，第一次上传插件以后，开发者中心会自动创建插件项目。但是 manifest 里面一定要写固定的 Gecko ID，例如：

{
  "browser_specific_settings": {
    "gecko": {
      "id": "my-extension@example.com",
      "strict_min_version": "140.0"
    }
  }
}

这个 ID 相当于 Firefox 插件的身份证。后续更新版本必须继续使用同一个 ID，不能每个版本都随机换。

上传插件并进行检测

登录开发者中心以后，点击“提交新附加组件”，Mozilla 会让你选择发布方式：

1. 在 Mozilla Add-ons 上发布：插件会出现在 Firefox 插件商店里，适合公开发布。
2. 自行分发：Mozilla 只负责检测和签名，签名后的 XPI 由开发者自己放到网站上给用户下载。

如果只是想在自己的网站上提供 Firefox 插件下载，就选择“自行分发”，也就是 unlisted 渠道。

然后上传打包好的 XPI。XPI 本质上就是 ZIP 文件，但是要注意 manifest.json 必须直接位于压缩包根目录，不能在外面多套一层文件夹。

上传以后 Mozilla 会自动检测插件。检测失败就按照页面上的错误逐个修改，常见问题有：

1. manifest.json 格式错误，或者使用了 Firefox 不支持的 Chrome 字段。
2. Gecko ID 缺失，或者新版本和旧版本使用了不同的 ID。
3. 上传过相同的版本号。每次上传新版都必须增加 manifest 中的 version。
4. 插件申请了权限，但是没有正确声明数据收集用途。
5. 压缩包中包含源代码、临时文件或者不需要的构建文件。

Firefox 新版对插件数据收集声明检查得比较严格。比如插件需要读取网页活动和登录信息时，可以在 Gecko 配置中声明：

{
  "browser_specific_settings": {
    "gecko": {
      "id": "my-extension@example.com",
      "strict_min_version": "140.0",
      "data_collection_permissions": {
        "required": ["websiteActivity", "authenticationInfo"],
        "has_previous_consent": false
      }
    }
  }
}

具体声明要和插件真正读取的数据保持一致，不要直接照抄上面的权限。检测页面报错时，也要以 Mozilla 当时给出的字段说明为准。

检测通过以后继续提交。自行分发的插件不需要上架商店，Mozilla 处理完成后会生成一个已经签名的 XPI，下载这个文件才可以在正式版 Firefox 和 Firefox ESR 中长期安装。

安装签名 XPI 的方法是打开 about:addons，点击右上角齿轮，选择“从文件安装附加组件”。

获取 Firefox Add-ons API 信息

每次都在开发者中心手工上传和下载太麻烦，Mozilla 提供了 API，可以用 web-ext 自动上传、检测和下载签名后的 XPI。

登录开发者中心后，打开 API 凭据页面：

https://addons.mozilla.org/developers/addon/api/key/

点击生成新的凭据，页面会显示两项信息：

1. JWT issuer：这就是 API Key，一般长得像 user:123456:xxx。
2. JWT secret：这就是 API Secret。

API Key 不是插件的 Gecko ID，也不是 Mozilla 账号。API Secret 相当于账号密码，不要写进源码，不要提交到 Git，也不要放到公开日志里。如果密钥泄漏了，马上回到这个页面重新生成凭据，让旧密钥失效。

我一般把它们分别保存成两个文件：

firefox_addons_api_key.txt
firefox_addons_api_secret.txt

然后限制文件权限，并加入 .gitignore：

chmod 600 firefox_addons_api_key.txt firefox_addons_api_secret.txt

用 web-ext 自动签名

先确保待签名目录中包含 manifest.json 和插件需要的所有文件，然后执行：

export WEB_EXT_API_KEY="$(<firefox_addons_api_key.txt)"
export WEB_EXT_API_SECRET="$(<firefox_addons_api_secret.txt)"

npx --yes web-ext@latest sign \
  --channel unlisted \
  --source-dir ./firefox-extension \
  --artifacts-dir ./artifacts

unlisted 表示自行分发。web-ext 会把插件上传给 Mozilla，等待检测和签名，再把签名后的 XPI 下载到 artifacts 目录。

不要把 API Key 和 Secret 直接写在命令行参数中，否则可能进入 Shell 历史或者被进程列表看到。用环境变量传递会稳妥一些，自动构建程序也应该避免打印这两个变量。

每次生成新版 Firefox 插件前，要先增加 manifest 中的 version。同一个 Gecko ID 和同一个版本号不能重复签名，否则 Mozilla API 会直接拒绝。

怎么确认 XPI 已经签名？

可以解压 XPI，检查里面是否存在 Mozilla 的签名文件：

unzip -l my-extension.xpi | grep META-INF

正常会看到类似下面的文件：

META-INF/mozilla.rsa
META-INF/mozilla.sf
META-INF/cose.sig

不过最终还是要在正式版 Firefox 或 Firefox ESR 中实际安装一次。能通过 about:addons 正常安装，并且重启 Firefox 后插件仍然存在，才算整个签名和发布流程真正跑通。

简单总结一下：开发阶段用 about:debugging 临时加载，交付用户时走 unlisted 自动签名，想公开推广时再发布到 Firefox 插件商店。三种方式不要混在一起，就不会一直被 Firefox 的签名错误折腾。

via https://manateelazycat.github.io/feed.xml

GPT负责设计，离线27B负责执行：我超高效率但超省钱的工作流

分享我超高效率但是超省钱的工作流方式：

1. 和GPT深入探讨设计和方案
2. GPT在A项目中给出设计方案，我直接让离线的27B去执行
3. 27B执行的时候，我在和GPT讨论B项目的设计方案

和GPT深入探讨设计和方案

设计环节用线上GPT的全局规划能力。如图：我让Codex在全局列一下需求，回答尽量简洁，这样内容少了才好全局思考，把需求收拢成几条清晰的要点。

让离线的27B在后台慢慢用电干活

GPT给出设计方案后，我直接把方案丢给离线的27B执行。如图：Qwen 3.8 27B在AIPod上以vLLM方式运行，在Pi里无审查地执行“生成LPK并安装LPK”任务，23分45秒跑了22条命令，中途遇到本机缺unzip、sudo要密码这类问题也自己补了个node版unzip shim解决掉了。

兼具线上模型的能力与线下模型的省钱

看到了吗？利用线上GPT的全局规划能力，我和GPT在协作设计的时候，27B在后台慢慢用电来干活，而不是用订阅来干活。

这样我兼具了线上GPT模型的能力和线下模型的省钱，因为只要设计好，线下模型现在非常能打了。关键给我节省了90%的订阅费。

via https://manateelazycat.github.io/feed.xml

Invalid media:
image
image

高质量商业软件构建的秘密，这是我 20 年的经验，分享给大家，不一定对，供你们参考。

一、追求简单

越是顶尖的工程师，越要追求用最简单的技术去满足用户的需求。

很多年轻的工程师为了炫技，喜欢构建非常复杂的系统，沉迷于复杂的系统而无法自拔。但是复杂的系统会带来非常大的质量隐患，它却不一定会增加软件的健壮性，甚至有时候会拖慢软件的性能。

二、减少内耗

在 AI 时代，大家都明白，其实我们只是把世界的知识来回搬运，通过一定的信息差和知识差来满足用户的需求赚钱。

但是 AI 时代告诉我们，其实知识就在那里。执行已经不是问题的时候，千万不要沉迷于跟别人抬杠，或者为了证明自己。当你为了证明自己、或者要跟别人比的时候，其实你消耗了大量获取知识的能量，去跟陌生人抬杠，这是毫无意义的。

三、重视用户反馈

很多初级的工程师是很鄙视用户的意见的，但是你知道，这个世界上所有的经济学都建立在相互交换之上。

如果你鄙视付钱给你的客户，其实你就失去了赚钱的商业能力，这是最简单的一个道理。因为世界上没有人愿意把钱给一个鄙视他自己的人。

via https://manateelazycat.github.io/feed.xml