一套自己已经复制到几个项目里的样式，交到另一位开发者手上，还会一样好用吗？Tailwind 早期的一段经历，把这个问题变得很具体。
Adam Wathan 在 2020 年 8 月 2 日的回顾里写到，2015 年他和 Steve Schoger 想做一个叫 Digest 的链接分享项目。项目后来搁置了，样式文件却留了下来。按他的记忆，这些文件又被带进至少四五个项目。
复制的次数增加后，他发现了一种变化：处理间距等细节的工具类越来越多，原来带有特定设计风格的组件代码反而越来越少。新的设计需要新的按钮和卡片，但一些更小的样式能力能够继续使用。
后来，他在公开制作另一个项目 KiteTail 时，不断被观众问到 CSS。Jonathan Reinink 也想把这套东西用在自己的 SaaS 改版里。Adam 特别提到，两人的设计完全不同，要同时支持它们，迫使框架更少依赖某一个项目。
这一步值得停下来想一想。前面几次复用，都由熟悉原代码的作者完成；换一个使用者和一套设计，原来可以凭习惯绕过去的问题，就必须被处理了。
可配置性也有代价。Adam 说，为了让早期基于 Less 的实现满足要求，代码逐渐变得难懂，修改时很难有把握。在 David Hemphill 的建议下，他开始尝试用 PostCSS 和 JavaScript 来实现框架。2017 年 11 月 1 日，Tailwind 0.1.0 发布。这些是作者对早期过程的回忆，不是今天的技术选型建议。
我从这段故事里得到的判断是：准备把内部工具交给别人用时，可以主动寻找一个会暴露差异的第二现场。两次使用都很顺利，如果它们几乎一样，提供的证据仍然有限。
把这个验证思路借到你自己开发的表单工具里：假设你从预约页面提取了一套组件，准备给其他开发者使用。再做一个换了颜色的预约页，可能很快完成。把它放到设备管理后台，问题会更具体：一行需要放多少字段？错误提示放在哪里？一个保存动作会影响当前行，还是整个页面？这是假设案例，不是 Tailwind 团队做过的测试。
可以用下面这张小卡片记录差异：
| 原先默认的做法 | 第二个场景的需要 | 本次决定 |
|---|---|---|
| 提交整张表单 | 保存当前一行 | 明确提交的作用范围 |
| 错误提示显示在页顶 | 用户正在编辑表格中部 | 让错误能定位到对应字段 |
| 为一次提交显示忙碌状态 | 多行可能同时保存 | 单独记录每次保存的状态 |
关键是保留做决定的原因。某个要求确实只属于第二个项目，可以留在那个项目里；如果每次接入都要复制组件、改一段内部逻辑，就应重新检查公共部分到底承担什么。
第二个现场通过了，适用范围仍然需要写清。下一次修复时，同时回到两个场景检查，观察是否出现只能顾一头的情况。这样留下的既有使用示例，也有适用范围，后来的使用者更容易判断要不要接入。
这段历史没有证明每个内部工具都应该变成框架。它提供了一个很实在的动作：在宣布通用之前，让一个不完全照着自己习惯工作的人，用它完成一件不同的事。
资料：Adam Wathan，《Tailwind CSS: From Side-Project Byproduct to Multi-Million Dollar Business》，2020-08-02，作者原文。2026-11-07 查阅。历史经过来自作者回顾；表单案例、记录卡和后续验证方法为本文推导。
