上周帮朋友修一个 Markdown 编辑器的渲染 bug，顺手翻了下它的 GitHub Issues 页面。发现好几条写着“这个功能太难用了”“为什么不能加个一键排版？”，但没人附截图、没环境信息、也没复现步骤——结果就是，三天过去，没人回复，issue 一直挂着。
提建议前，先看三样东西
不是所有开源项目都欢迎“随便提”。进仓库前，花两分钟扫一眼：CONTRIBUTING.md（贡献指南）、ISSUE_TEMPLATE.md（问题模板）和已关闭的 feature request 类 issue。很多项目早就在模板里写清楚了：“请说明使用场景+当前痛点+期望效果”。比如 VS Code 的 feature request 模板里就强制要求填 “What problem would this solve?” 和 “How do you think this should be implemented?”
一句话建议 = 白说；带上下文的建议 = 有人真看
把“希望加暗色模式”换成：
场景：我在夜间写文档，当前主题刺眼，眼睛容易酸
现状：只能手动调系统亮度，但编辑区文字依然发白
期望：点击右下角小月亮图标，切换到柔和灰蓝底色（参考 Typora 的 #2D3748 主色）
附图：
<img src="dark-mode-idea.png" alt="当前界面 vs 暗色草图">这种写法，维护者一眼就能判断是否值得做、要不要拉 PR、甚至直接抄走当设计稿。
别只扔想法，顺手搭个脚手架
如果你会点代码，比纯文字建议强十倍的做法是：自己 fork 项目，改出最小可行版（哪怕只是改一行 CSS 或加个配置开关），然后开个 PR，标题写明 “WIP: dark mode toggle (proof of concept)”。哪怕代码不完美，也等于帮对方省了 70% 的前期验证时间。很多项目首页 README 就写着 “PRs welcome — even if rough!”。
被拒了？别急着反驳，先查 commit 记录
有次我提了个快捷键优化建议，维护者回：“这个逻辑在 v2.1 已调整，为兼容旧插件保留”。我点开提交历史一看，果然——原来半年前就有讨论，还附了架构图。后来我补了句：“明白了，那我基于新逻辑重写 PR，顺便给插件作者写个迁移提示？” 对方当天就点了 approve。
开源不是提需求的客服窗口，而是协作工地。你递上一块切好的砖，比喊“快盖楼”有用得多。