My Comment-Reply Queue Draft One Reply to a Thread and It Went Deaf to Every Follow-Up After That

这位开发者的评论管理小工具连续踩了三个坑，而且第三个坑藏得很深，恰恰是因为前两个修得太干净，让人放松了警惕。他写的脚本用来追踪DEV.to文章下面的新评论，先是修复了回复一次后整个对话就被标记为处理完毕、对方再追问也不提醒的bug，又修了只检查第一层回复而漏掉深层嵌套评论的问题。结果今天发现核心判断逻辑里还藏着第三个问题，而且这个bug因为前面两个修复让整份代码看起来太可信，反而更不容易被察觉。这其实反映了编程中常见的困境：一个工具用久了，慢慢积累的小补丁会让你以为它已经很可靠，结果最隐蔽的漏洞恰恰藏在你最放心的角落。虽然这个脚本只是开发者个人的效率工具，但这种教训对任何人都有启发——无论是管理邮件、处理工作流程还是做日常记录，定期用批判眼光重新审视自己用惯了的工具，往往能发现被忽视的盲区。

I have a small script, <code>reply_comments.py</code>, that keeps me from having to re-scan every DEV.to article for new comments by hand. It has two commands: <code>pending</code> (unanswered comments I haven't drafted a reply to yet) and <code>audit</code> (drafted replies I said I'd paste manually but apparently never did). I've already fixed two bugs in this file — one in <code>needs_reply()</code> (a thread stayed "handled" forever after a single reply, even when the other person followed up again) and one in <code>audit()</code> (it only checked direct children, so a reply nested two levels deep was invisible). Today I found a third, in <code>pending()</code> itself, and it's the kind of bug that hides precisely because the first two fixes made everything else in the file look trustworthy. <h2> What <code>pending()</code> actually does </h2> Comments on DEV.to come back from the API as trees — each top-level comment has a <code>children</code> list, and replies can nest arbitrarily deep. <code>pending()</code> walks each article's top-level comments and decides, for each one, whether it needs a reply: <div class="highlight js-code-highlight"> <pre class="highlight python"><code>def pending(): try: drafted_text = open(DRAFTS, encoding="utf-8").read() except FileNotFoundError: drafted_text = "" drafted_codes = set(re.findall(r"^## (\S+)", drafted_text, re.M)) out = [] for a in api(f"/articles?username={ME}&per_page=100"): if not a["comments_count"]: continue for c in api(f"/comments?a_id={a['id']}"): if not needs_reply(c): continue if c[<span cl