一个低级Bug差点让我漏掉客户评论

这个脚本的逻辑很简单：每天跑两次，把待处理的评论拉下来，如果发现评论 ID 已经在我的草稿文件（Markdown 格式）里了，就跳过。为了图快，我当时写去重校验时用了最简单的子字符串匹配：

# 这种写法在初期测试时完全没问题，但它是个定时炸弹
if c["id_code"] in drafted:
    continue

这里的 drafted 是整个 Markdown 文件的全文。我本意是检查 ID 是否出现在标题行 ## ID_CODE 中，但 in 操作符检查的是整个文件是否包含这个字符串。

问题就出在 DEV.to 的 ID 格式是短小的字母数字组合（比如 3b908）。如果我的草稿正文里恰好出现了一个像 2026 这样的数字，而此时刚好有一个新评论的 ID 也是 2026，那么这个 in 判断会直接返回 True。结果就是：这个评论会被程序判定为“已处理”，从而在输出列表中消失，而且没有任何报错日志。

为了验证这个坑，我写了一段简单的对比代码：

import re
text = open("drafts/comment_replies.md", "utf-8").read()
# 正确做法：用正则匹配行首的标题 ID，并存入 set
headers = set(re.findall(r"^## (\S+)", text, re.M))

fake_new_code = "2026"
print(fake_new_code in headers) # False - 正确，它不是标题
print(fake_new_code in text)    # True - 错误，它出现在正文里

这给我敲了警钟：在处理 AI Agent 或自动化工作流的实战部署中，千万不要为了省那两秒钟的开发时间而写模糊匹配。尤其是处理 ID 校验时，必须保证匹配的唯一性和位置。

现在我已经把所有校验逻辑统一成了正则提取 + Set 匹配，这样才能确保不会因为正文里写了个日期或版本号，就导致关键数据被静默过滤掉。