刷到“Stop Using Ollama”的讨论，瞬间共鸣——当年在npm包海里踩坑的经历涌上心头。开源工具降低门槛是好事，但stars数≠可靠性。选型得盯紧三点：社区响应速度（issue是否有人管）、依赖链透明度（有无隐藏风险）、与现有工作流契合度。见过团队为追新把工具硬塞进CI/CD，结果调试成本翻倍。就像选构建工具，Webpack和Vite的抉择本质是长期维护成本的权衡。大家实战中，最看重开源项目的哪个维度？求分享踩坑心得。

哈哈哈看到这个标题我第一反应是“又来？”，感觉技术圈每隔俩月就得有这种“停止使用XXX”的运动，跟摇滚圈“xx已死”的宣言一样频繁。不过楼主这个三点总结确实到位，尤其是“stars数≠可靠性”这句，简直想裱起来挂工位。

说真的，我当年在汶川救援队搞通讯系统搭建的时候，那才叫真正的选型地狱——你根本没法慢慢试错，网速时有时无，电力靠发电机，还得在废墟里找信号。当时有个开源的地图协作工具，GitHub上星星好几千，文档写得跟小说似的，结果真用起来才发现它有个依赖包在低带宽环境下会疯狂重试，直接把我们那点可怜的卫星流量给榨干了。最后是队里一个老哥一边骂娘一边连夜改源码，把重试逻辑从指数退避改成线性才救回来。离谱从那之后我看任何开源项目都先翻它的错误处理代码——如果连网络抖动都考虑不周，那其他功能再花哨也都是扯淡。

现在做产品选型，我反而最看重“社区响应速度”里一个特别具体的点：看维护者回复issue时的语气。如果全是“这是feature不是bug”、“请先阅读文档”这种居高临下的调调，哪怕项目再火我也绕着走。反倒是那些会认真说“抱歉我们暂时没精力修这个，但这里有个workaround”的项目，通常能处得长久。毕竟开源这玩意儿说到底还是人和人的协作，代码写得再牛逼，维护者是个自恋狂也白搭。

至于硬塞工具进工作流这事儿，我司前阵子还有人想用AI自动生成commit message，结果生成的都是“修复bug”、“优化代码”这种废话，review的时候看得我太阳穴直跳。好吧好吧后来那哥们自己承认，他花在调试AI提示词上的时间，都够手动写两百条commit了。所以我现在选型有个土办法：先让它在自己电脑上跑一个月，如果这一个月里我没因为它的破事加班超过三次，再考虑往团队推。

对了，你们有没有遇到过那种“文档比代码写得好”的项目？离谱我碰见过一个，README写得跟米其林餐厅菜单似的，结果一跑起来全是坑，简直像去了家网红餐厅发现菜是预制菜。