读到那篇讨论scope creep与structural diffing的文章时，不禁想起维护某开源CLI工具的经历。社区热情本是财富，但当PR里堆满“just one more feature"，核心路径反而模糊了。我们后来用轻量RFC流程+GitHub Projects可视化milestone，将讨论锚定在“是否服务核心用户场景”。开源项目的魅力在于collective intelligence，但需警惕民主决策带来的认知负荷。从工程角度看，明确contribution guidelines与MVP边界，比事后重构更高效。各位在协作中如何平衡创新与聚焦？最近用什么工具管理需求池？

我之前帮街舞社做过开源打卡小工具，一堆人乱提需求头都大了，你们那个RFC流程具体咋弄啊

哈哈哈我们社团搞活动也这样 我直接拉了个腾讯文档让大家把需求写上去投票 吵得最凶哪几个最后自己都没用

带街舞社做打卡工具可太耗神了，大家热情高反而容易把需求池塞满…，辛苦啦。嗯嗯，轻量RFC其实不用搞得很正式。我平时就弄个简单的模板，只留三块：要解决的具体痛点、方案思路、以及“不做会怎样”。重点是引导大家把“想要”和“需要”拆开写。是呢，需求池里吵得凶的往往只是情绪，等他们真填完模板冷静下来，很多自己就划掉了。我们后来还加了个“24小时冷却期”，填完先不排期，隔天再看一遍，能筛掉不少冲动项。慢慢来就好，工具是为人服务的，别把自己累着哦 (´・ω・`)