普通视图

发现新文章,点击刷新页面。
昨天 — 2026年1月12日首页

Tailwind 因为 AI 的裁员“闹剧”结束,而 AI 对开源项目的影响才刚刚开始

2026年1月12日 06:53

Tailwind 还是相当明白「会哭的孩子有奶吃」这个道理,“裁员风波”才刚开始,立马就收到谷歌 AI Studio 、Vercel 和 Lovable 的相关赞助:

这个风波其实并不是最近才开始的,早在去年年底,Bun 被 Anthropic 收购加入 Claude Code 阵营的之后,Tailwind CSS 的创始人 Adam Wathan 就发出过灵魂警告:

因为现在很多 AI 公司,比如 OpenAI 、Claude、Gemini 等,都在前端 AI 上都大量使用了 Tailwind,因为很大程度上, Tailwind CSS 训练数据多、表达方式离散可拼装、可控性强、出错成本低 ,例如:

<div class="p-4 rounded-xl shadow-md bg-white">

对 AI 来说,Tailwind 的 class 写法非常像在拼积木,每个 token(p-4 / rounded-xl / shadow-md)都是一个“语义单元”:

  • 既能局部修改(把 p-4p-6
  • 又能组合叠加
  • 还能按响应式/状态扩展(md:p-6 hover:bg-xxx)

在这方面,模型向来更擅长生成离散符号序列(token),而不擅长维护抽象结构,同时 class 贴在元素上所见即所得,符合 AI 追求的尽可能“生成代码一次就能跑”

特别是谷歌的 AI Studio 在这方面倾向特别明显。

那这对 Tailwind 有什么影响?这不是代表着框架在 AI 时代很流行吗?为什么还会出现”裁员“问题?这个影响其实就类似 AI 对 Stackoverflow 的影响,原网站没流量了:

Tailwind 这次的本质矛盾在于,AI 让 Tailwind 使用量更大,但把它原本的赚钱路径(流量 to 转化)给切断了,所以反而出现“越火越穷”的情况。

Tailwind 本体是开源免费的,但是它的典型商业模式是:

Google/搜索 → Tailwind 官网文档/教程 → 认同与依赖 → 购买增值产品(模版、文档、企业合作、教程和顾问咨询等)。

这其实也是很多开源项目的盈利方式,特别国内很多 gitee 的项目更明显,放出简陋开源版本,付费提供文档和完整商业版本,而这些付费产品严重依赖:文档流量 + 心智依赖 ,还有用户在官网停留时间和访问频率,但是现在 AI 在掐断了这个路径

Tailwind 在线文档的流量下降了 40%,收入下降了 80%,实际上写技术文章和公众号的应该也有感受,现在的开发者越来越不喜欢读和找技术文章了,就算读也是让 AI 直接总结

当然,这波闹出来的裁掉 75% 的工程师的事件,多少也有一些标题党的味道,因为工程团队原来有4 个工程师,这次裁掉了 3 个,所以比例高达 75%

实际应该就是剩下创始人+ 1 个工程师+ 1 个兼职的团队规模。

当然,这波赞助风波其实对于 Tailwind 危机来说,也只是解救近期的燃眉之急,因为它不像 Bun ,Bun 对 Anthropic 来说是强战略资产,因为运行时/工具链直接影响 AI 编码产品的性能与交付:

一体化 runtime/toolchain,和 AI coding 产品的工程链路强绑定,收购能立刻减少外部依赖、提升稳定性与性能上限。

所以 Bun 卖的是“工程基础设施能力”(速度/工具链/交付体验),而 Tailwind 虽然十分流行,但是主要商业化通常靠“围绕开源的增值产品/服务漏斗”,成不了核心体系的,简单说:

  • Bun 属于“可控的关键基础设施(runtime/toolchain)”,收购后可以把关键工具链进化成自有资产
  • Tailwind 属于“可替代的开发者体验层(UI styling layer)”,买它不太会给你护城河

在链路上的差距,也导致了它们之间命运的走向不同,当然 Tailwind 深知“发声”的重要性,所以这波闹腾之后,也暂时性解决了生存问题,只是:

赞助只能覆盖一时的资金问题,但解决不了当前开源项目的的商业模式窘境。

AI 切断流量是致命的,StackOverflow 在这方面表现最为明显也最为明显,所以 Tailwind 这波于开发者和开源领域来也是很明显的警钟:

就像我朋友,上午还问有没有什么记账软件推荐,结果下午就直接用 AI 做了一个符合心意的应用,AI 对于个人开发者的影响未来也会越来越明显,如果 AI 可以直接 A2UI 直出功能和结果的时候,是否其他独立产品还有存在的意义?

image-20260111143806306

所以, AI 对于开发者和开源项目的影响才刚刚开始,以前的项目增长和流水靠的是:

  • Google 搜索
  • 文档流量
  • StackOverflow
  • 博客/教程
  • GitHub star 传播

但是现在 AI 时代之后,开源的影响力不再去取决于:

  • 文档写得多好
  • SEO 做得多好

现在的项目是否流畅,越来越由取决于 AI :

  • 训练语料里出现得够不够多
  • 模型偏好它还是偏好别的库
  • 它是否“更适合生成”

而项目能否赚到钱,更要取决于你在 AI 链路里扮演的角色,这也是 Tailwind 这波表现出来的趋势:

虽然你在 AI 时代很多,但是越火,流量却越少。

昨天以前首页

Flutter 3.38.1 之后,因为某些框架低级错误导致提交 Store 被拒

2026年1月5日 09:24

如果你近期已经升级到 3.38.1 之后的版本,包括 3.38.5 ,你就有概率发现,打包提交 iOS 的包会出现 The binary is invalid 的相关错误,简单来说,就是App Store 拒绝了某个二进制文件,因为它包含了无效的内容

那么这个内容是怎么来的?大概率是模拟器架构的 Framework 被错误地打包进了正式发布的 App ,具体原因还要提到最新版本增加的 Native Assets 功能。

Native Assets 的目标是让在 Flutter/Dart 包中集成 C、C++、Rust 或 Go 代码,可以像集成普通 Dart 包一样简单,也就是它允许 Dart 包定义如何构建和打包原生代码,开发者不需要深入了解每个平台的底层构建系统,也是 Dart FFI 未来的重要基建。

详细可见:《Flutter 里的 Asset Transformer 和 Hooks ,这个实验性功能有什么用》

那它怎么导致了这次这个低级问题的出现?实际上这是一个构建脚本逻辑缺陷导致的“脏构建”问题,当 Flutter 构建依赖于 Native Assets(比如 sqlite3 等库)的 Plugin 时,这些原生资源会被编译并输出到 build/native_assets/$platform 目录(例如 build/native_assets/ios)。

因为在现有的构建脚本(xcode_backend.dart)在打包时,会简单粗暴地将 build/native_assets/ios 目录下的所有框架复制到最终的 App Bundle (Runner.app/Frameworks) ,例如:

  • 先运行了模拟器跑应用,这时模拟器专用的框架(如 sqlite3arm64ios_sim.framework)就会被生成并留在了 build/native_assets/ios 目录
  • 接着,开发者在没有运行 flutter clean 的情况下,直接运行了 Release 构建
  • 构建脚本会把之前遗留的“模拟器框架”也一并复制进了 Release 包
  • App Store 检测到 Release 包中含有模拟器架构的代码,因此拒绝接收

所以说,大厂也有大厂的草台。

当然,这个问题解决起来也很简单,就是发布前 flutter clean 清理一下,当然,如果你之前打过包了,那么 Xcode 的构建缓存也需要清理下,因为可能存在即使你通过 flutter clean 删除了 Flutter 的构建产物,但是 Xcode 可能仍然认为某些中间文件(Intermediate Build Files)存在可用。

比如 DerivedData 缓存

那么这么低级的问题,修复下也很简单,所以 sqlite3 的作者也提交了一个 #179251 ,简单来说就是,针对 Native Assets :

  • 读取构建过程中生成的 native_assets.json 文件
  • 解析文件,获取当前构建真正引用的依赖列表
  • 仅复制 native_assets.json 中列出的框架,忽略目录中残留的其他无关文件(如模拟器文件)

这个修复其实很简单,但是在流程上,因为目前 PR 还缺少 integration test ,所以一直卡在了等待 Review 阶段,除非有人申请豁免,不然这个 PR 的合并还会继续卡着。

只能说,一代人有一代人的草台。

参考链接

❌
❌