十月一号，我照例打开几个 watch 着的仓库，看 PR 列表。手已经放在“close with comment”上了。
结果今年没活干。Hacktoberfest 2026 把规则改了：PR 和 MR 不再计入奖励，没有 PR 目标，也没有提交 PR 换周边这一说。官方 FAQ 给的理由很干脆——低成本垃圾 PR 的提交门槛低到地板上，主办方听了一堆维护者的反馈，干脆不再拿 PR 当激励物。
组织方也换了，MLH 和 DEV 跟 DigitalOcean 一起办。奖励改成贴纸：两张必得，MyMLH 登录、填个收件地址就到手；剩下的靠去线下 Fest 签到、抄直播里报的码，或者给 DEV Challenge 投稿，凑够十五张进 raffle，抽 T 恤或者一块 Arduino Uno Q 板子。
我赞成的是“不数 PR”这半边，另外半边砍得有点糙
我不装。看到这消息第一秒我是爽的——每年十月那堆只改一个单词的 README PR，关到手抽筋。画外音：这玩意儿今年被 AI 批量生产得更便宜了，一个 agent 一晚上能给三十个仓库各提一个。
爽完有点别扭。别扭的地方不在贴纸，在于这一刀砍的位置。
我的判断：垃圾 PR 是问题，PR 这个载体不是。主办方砍的是记分板，PR 本身背了不该背的锅。
一份真做完的 PR 教会你什么？fork、开分支、跟上游同步、读你没读过的代码、把项目的测试跑起来、写一段维护者能一口气读完点 approve 的描述、再把 review 意见推回同一个分支而不是另开一个。这些东西没一样能写进简历，但合起来就是“能不能在别人的代码库里干成活”的答案。而且它可验证——仓库是公开的，点了 merge 就是点了 merge，不像简历上那句“熟悉 Git 工作流”，谁都会写。
所以我赞成的其实是另一半：把激励从“提交数量”挪到“人真的到场、真的动手做点东西”，三百多场线上线下的 Fest，围着开源 AI 和开放权重模型做动手的活。这个方向我认。至于顺手把 PR 从记分板上抹掉——行吧，载体确实是最容易砍的那一刀，维护者的时间也是真时间。我只是觉得砍得糙。
砍都砍了，十月总不能空手过去。所以我盯上了另一个东西。
七天，每天五到十五分钟
DevOps Daily 在 Hacktoberfest 期间自己搞了个七天挑战，放在他们那个开源仓库里——一个 DevOps 学习站，五百六十多篇文章、四十五套 quiz、二十七组 flashcard，全拿 Markdown 和 JSON 存着。
话说前头：这不是 Hacktoberfest 官方活动。他们自己在文章里写得明明白白，这个挑战的 PR 不给 Hacktoberfest 贴纸。我一开始就知道，所以下面不会有什么“被骗了”的戏码。
我去的原因跟贴纸没关系。我想验证一件事：五到十五分钟一个 PR 这个粒度，到底成不成立。
Setup 大概十分钟。要求 Git、Node 22.13.1 以上但低于 25、pnpm 10。这种“不低于 X 但低于 Y”的写法我很喜欢，比 ^22 诚实——它承认了上界的存在。
git clone [email protected]:<我>/devops-daily.git
cd devops-daily
git remote add upstream https://github.com/devops-daily/...
pnpm install
pnpm test
第一遍 pnpm install 就挂了。不是仓库的问题，是我 PATH 里有个祖传 corepack 在捣乱，nvm 切到 24.x 才过去。这种破事每次换项目都要重演一遍，我懒得骂了。
pnpm test 跑的是 CI 在每个 PR 上跑的那套。本地先过一遍，能省一轮来回。这个习惯值多少钱，等你被 CI 的 lint 打回来三次就知道了。
每天从上游切一次分支，这件事值得单拎出来
挑战给的开分支命令长这样：
git fetch upstream
git checkout -b hacktoberfest/day-3 upstream/main
关键是 upstream/main 这四个字。fork 完就再没 fetch 过的人太多了，然后 PR 里带着一串别人早就合掉的 commit，diff 一打开，维护者看到的是你的改动混在三十个不相干的 commit 里。这种 PR 不是坏，是无法审。
每天从新鲜的上游切一次，保证一个 PR 只装一天的改动。笨办法。但它是唯一能让 diff 保持干净的办法。
七天的任务不一条条列，说几个印象深的。
Day 1 是写一份专家档案 Markdown，放进 content/experts/，名字、几句 bio、联系方式，五分钟。这是整套里最小的一个 PR，但它要走完 fork→branch→commit→push→PR 全套。设计意图太明显了——第一天根本不是为了产出内容，是为了把管子接通一遍。
Day 5 我觉得最有意思：往已经存在的文章或指南里加一条 tip 或 gotcha，十分钟。这是整个挑战里第一次让你改别人写的东西。
新建文件，你是主人。改别人的段落，你得先把那段读完，判断作者的行文节奏，判断你这条 gotcha 是不是已经被人写过了，判断它该插在哪一段后面。这是 review 的雏形，比写代码难。我改的时候删了自己写的第一版，因为读起来像我硬塞进去的。
Day 6 是去线上站找一个确定的毛病——错字、死链、过时的命令、格式问题，只改一个，PR 描述里把 URL 贴出来。标称十分钟。我花了四十分钟才锁定一个过时的命令。画外音：可见“十分钟任务”的真实成本从来不在改，在找。
Day 7 有个坑，我愣了一下才反应过来。它是在 Day 1 那份 profile 上加一段“My Stack”——你平时跑什么、为什么、会改什么，十五分钟。问题是：如果你的 Day 1 PR 还没合，你按常规从 upstream/main 切分支，那个 profile 文件压根不在你的分支上，你改无可改。所以得从 Day 1 的分支切出来：
git checkout -b hacktoberfest/day-7 hacktoberfest/day-1
这个设计挺诚实的。它承认了“PR 不会当天被合”这个现实——大部分教程假装 PR 一提就合，实际上挂三天是常态，挂三周也不稀奇。
AI 在这套流程里能干的和不能干的
我试过让 Claude Code 帮我起草一条 toolbox 条目——名字、一行描述、链接、分类。它给我的描述是“a powerful, seamless solution for modern DevOps workflows”这种。语法完全正确，一个信息都没有。我全删了。
这就是那个老问题：AI 写的代码和文字要比你自己写的审得更严，不是更松。它太擅长产出“看起来对”的东西，而“看起来对”和“是对的”中间的坑最深。
真正能省事的地方在别处——跑完 pnpm test 把报错贴给它，让它定位是哪个 JSON 字段的形状对不上（quiz 那套是有测试校验题目结构的），这个它做得又快又准。留给自己的判断是另一件事：这条描述到底说没说清楚这个工具是干嘛的。
扯远了，回正题。
我攒下的几条
这些不是最佳实践，是我自己交过学费的：
一个 PR 只装一件事。想顺手把旁边的格式也修了？下一个 PR，或者别提。
push 之前本地跑 pnpm test。CI 也是这套，早发现早改。
描述写两句：改了什么，为什么。两句话，别写小作文。
AI 帮忙起草的内容必须自己过一遍，尤其是文案类的。
review 意见推回同一个分支，别开新 PR。开新 PR 等于让维护者重新读一遍上下文，纯浪费。
第七条挑战里没写，但我觉得该写：分支落后了，rebase 到最新上游，别 merge 上游进来。这条纯属个人偏好，我认。
Day 1 到底合了多少，我也想知道
评论区有人问 Day 1 的 PR 到底合了多少个——这个问题问到点子上，可惜文章没给数字。挑战发出来几个小时就有第一批 PR 进来，这批人里有多少是第一次提 PR，同样没数字。
但我记得另一条评论，大意是五到十五分钟这个粒度，是唯一能和一份正职工作共存的尺度。这条我同意一半。
粒度小确实让人能挤进生活缝隙——通勤路上改个错字，午休时加张 flashcard。但粒度小不等于认知负荷小。Day 5 那种改别人文字的活，五分钟真的不够你进入状态，光把上下文加载进脑子就要十分钟。所以“五分钟任务”说的是动手时间，不是总时间。这点想清楚，就不会因为一天只推进了一点点而心虚。
至于贴纸，我最后手里两张，都是必得的那种。七天 PR 换不来一张，这个我认，规则一开始就写着。我拿到的东西不在这张表上：一套重新跑顺了的 fork→branch→test→PR 流程，还有一次“改别人的字比写自己的字难”的重新确认。
本期缴税：凑够十五张贴纸的耐心我没有，但每天从 upstream/main 切一次分支这个习惯，我留下了。
下次十月见。