北京
你有没有发现，最近"open-source"这个写法突然到处都是？
带连字符的那种。
过去一个月，我走到哪儿都能看到这个词——技术博客、产品公告、甚至学术论文。起初以为是巧合，但频率高到让人警觉：背后有股力量在推动这件事。查了一圈，罪魁祸首找到了：大语言模型。
这不是小题大做。一个连字符的位置，直接决定了你看到的是真开源，还是"看起来像开源"。
先厘清概念。开源领域有两个截然不同的术语：
Open Source（大写，无连字符）：特指符合开源促进会（OSI）定义的许可证，比如MIT、GPL、Apache-2.0。这些许可证必须满足十项标准，包括自由再分发、源代码可得、允许修改和衍生作品等。
open source（小写，无连字符）：泛指一切公开代码的行为，没有统一审核机制。Elastic License 2.0、Business Source License（BUSL）、Hippocratic License都归在这一类——你可以看代码，但使用受限，甚至无法贡献回去。
关键区别？大写Open Source是认证过的"有机标签"，小写open source是菜市场自称的"绿色食品"。
连字符的问题更隐蔽。开源促进会明确声明：Open Source从不使用连字符。这是既定规范，不是风格偏好。但当大模型开始批量生产内容时，规则被悄悄改写了。
我做了个简单测试。用同一问题询问多个主流模型："如何描述MIT和GPL这类许可证？"
结果惊人一致：绝大多数模型回答时都用了"open-source"——带连字符的错误写法。Gemini、Claude、GPT-4系列、Llama，几乎全军覆没。只有一个例外坚持正确格式。
这意味着什么？当你用AI辅助写作、润色邮件、生成技术文档时，它正在"纠正"你用对的写法，换成错的。更麻烦的是，这种错误具有传染性：读者被反复暴露于错误格式，逐渐习以为常；新入行的开发者直接复制AI输出，误以为这就是标准；最终，错误写法通过"大模型生成→人类采纳→更多训练数据"的循环自我强化。
企业尤其喜欢这种模糊地带。把代码往GitHub一扔，新闻稿写"我们开源了"，实际用的是BUSL——六个月内禁止商业竞争使用。这叫Openwashing（开源漂绿），本质是营销话术蹭开源的光环，却规避其义务。
连字符虽小，却是识别这种操作的第一道防线。当"open-source"成为默认写法，大小写区分的重要性被稀释，读者更难察觉许可证背后的权利陷阱。
技术社区曾花了二十年建立这套共识：大写是承诺，小写是描述，连字符是错误。现在，大模型用几个月时间就动摇了它。
这不是反对AI写作工具。但当你看到"open-source"时，值得多问一句：这是人写的，还是模型生成的？如果是后者，它想让你忽略什么？
词语是有重量的。Open Source的重量，在于它背后可执行的法律定义和社区监督。当这个术语被随意改写、hyphenation被默认接受、大小写不再被区分，我们失去的不只是语法规范，而是判断"真开源"与"假开源"的能力。
下次写技术文档时，检查一下：你用的是Open Source，open source，还是open-source？
如果是最后一个，模型正在替你思考——而且想错了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
