阅读视图

发现新文章,点击刷新页面。

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

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 被拒

如果你近期已经升级到 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 的合并还会继续卡着。

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

参考链接

❌