1. 预发布不是“发着玩”，而是工程信任的临界点很多人把npm publish --tag beta当成一个加个标签的快捷操作——就像给代码打个草稿标记。我试过在三个中型前端组件库项目里这么干，结果是：下游团队一边用着带beta.3的包，一边在 Slack 里问“这个 API 是不是还没定稿”，而我自己在凌晨改完第 7 个beta.8版本后，发现package.json里的version字段已经和实际发布的 tag 对不上了。这不是发布流程的问题，是预发布版本管理本身缺乏可推演的契约。真正卡住团队协作效率的，从来不是“能不能发”，而是“下游敢不敢接”。当你发一个1.2.0-beta.1，下游开发者心里其实在快速做三件事：判断这个版本是否包含他急需的修复、确认它会不会破坏现有集成、评估回滚成本有多高。如果这些判断无法通过版本号本身直接得出，那每次集成都变成一次小型风险评审会。AI 编程工具在这里不是来替代人工决策的，而是把人从重复性判断中解放出来——比如自动校验beta版本是否满足语义化约束、自动生成 changelog 摘要、甚至根据 PR 内容建议该走alpha还是rc路径。但前提是，你得先有一套能让 AI 理解、能被机器验证的规则。否则，AI 辅助编程工具再快，也只是在加速一个模糊过程。这篇文章只讲一件事：怎么让beta不再是个模糊概念，而是工程交付链路上一个可测量、可追溯、可自动化的环节。不讲理