维护开源项目最艰难的任务之一，就是对一个看似合理的好想法说“不”。用户提出一个设计精良、实用且无明显技术缺陷的新功能，但你仍必须拒绝。对用户而言，这令人困惑；对维护者而言，这是守护项目灵魂的必要之举。 多年参与并维护Prefect、FastMCP等开源项目，以及在Apache Airflow中推动第三个项目的经验让我明白：真正的核心工作不是堆砌功能，而是构建清晰的愿景，并让项目与用户心智模型相契合。正如Prefect的CTO Chris White所言：“人们选择软件，是因为它的抽象方式符合他们的思维方式。” 维护者的第一要务，是确立这种思维模型，然后坚定不移地用代码去体现它。一个表面有用但精神上不合拍的功能，其破坏力可能不亚于一个缺陷。 随着项目规模扩大，如何守护这份“灵魂”？关键在于提前阐明“为什么”。清晰的开发指南和项目宗旨，是第一道防线。它们在代码诞生前就定义了项目的哲学，吸引志同道合的贡献者。这些贡献反过来强化愿景，形成良性循环。此时，流程不再是官僚负担，而是对齐共识的工具。维护者可以自信地拒绝PR，因为“证明责任”在提交者——他们必须不仅展示功能价值，更要证明其与项目核心理念一致。 然而，大语言模型的兴起让这一平衡被打破。过去，写代码成本高，贡献者会先讨论再动手；如今，代码变得廉价，大量PR直接以“完成品”形式出现，缺乏对项目理念的理解。这些代码满足了用户请求，却背离了项目精神。 并非所有未请求的贡献都应被拒。偶尔出现的完美修复或小功能补丁，令人欣喜。但如今，未经过讨论的高投入PR已成常态，信号与噪声比严重失衡。 为此，我们在FastMCP尝试要求每个PR必须先有Issue。结果却出现“一句话Issue秒开”的新问题。更有效的做法，是明确表达：我们不认为项目应承担某些责任。如果贡献者想说服我们，那正是推动项目进步的契机。但必须记住：证明责任永远在贡献者，而非项目本身。 另一个深层挑战是维护负担。合并一个PR意味着永久承担维护责任——若出错、混乱或引发更多需求，最终都由维护者扛下。为此，我们引入“contrib模块”：包含可能不适合核心项目的实用功能，由作者独立维护，不承诺兼容未来版本。许多这类功能更适合独立成项目，但这种方式让协作更包容。 我亦反思自身：早年Prefect承诺15分钟响应，如今若遇低质量提问，我也常以同样低效回应。我更愿意看到清晰、简洁的问题附带最小可复现案例，而非一整段LLM生成的文本。 这看似是一种“手工艺式”的开源态度，在“ vibe coding”盛行的时代显得格格不入。但我始终相信，正是这种审慎、深思的守护，让项目从“可用”走向“卓越”。我曾参与MCP协议委员会会议，亲眼见证一群人在面对海量需求时，仍坚持追问：“这是个好主意，但这是协议该做的事吗？” 这种对“不”的坚守，正是技术走向成熟的标志。 那一刻，我确信：真正的开源精神并未消亡，它正以更坚定的方式，在那些愿意为愿景负责的人手中延续。