二十万条讨论，为什么还不能告诉你谁会买
一条记录，经过处理后变成了什么
一条给开源项目添加集成的 PR，经过数据处理，成了“用户求助”。
开发者只是交了一份代码。表格替他喊了一声救命。
这发生在一份端侧 AI 研究的数据里。分类字段叫 support_issue，读起来很清楚：有人用了产品，遇到问题，正在寻求帮助。可原记录的身份，是一次代码变更。
这种差别值得顺着文件往下看。2026年10月10日核对的主数据快照共有211,088行，其中2,092行来自GitHub；这2,092行全部使用同一个support_issue标签。按链接识别，其中598行指向PR。相同数量也出现在打标后的视图里。
这不是对整个互联网的抽样判断，而是对一组指定本地文件的逐行扫描。行数不等于用户数，PR也不意味着无价值。但如果有人拿“支持问题数量”讨论购买障碍，这个分类就会把不同性质的事情合并成一个看似明确的指标。
标签悄悄增加了一层原文没有的意思
顺着记录回到脚本，可以看到一个非常直接的规则：只要来源平台是GitHub，默认返回support_issue。主数据构建随后检查日期、文本质量和主题相关性，并去重。现有规则里没有在这一步把PR与问题报告拆开。
问题不在于“有没有做清洗”。这份数据已经做了不少处理。问题在于，处理程序把来源身份转换成了行为身份：来自一个技术平台，变成了使用者正在求助。两者之间缺少一次判断。
AI眼镜研究里也有类似规则。定向抽查的五条关键词命中记录，在主数据中仍然可以找到，其中包括测试者招募、产品点子和交易叙述。这些材料可能帮助理解供给、开发兴趣或市场话题，但它们并不能自动回答使用者在哪个场景遇到了什么困难。
把月份调平，解决不了记录角色的问题
端侧项目还保存了按月平衡的视图。它有121,786行，其中1,395行来自GitHub，352行链接指向PR，GitHub记录仍都沿用support_issue标签。
按月平衡解决的是时间分布：某个月的数据过多，可能掩盖其他时期的声音。记录角色解决的是含义：这句话是使用经历、功能提案、开发动作，还是推广信息。调整月份不会改变一句话的身份。
所以清洗不能只看最终保留了多少行。对于准备讨论的具体问题，需要知道哪些类别仍然混在一起。要分析开发生态，PR可以是有用材料；要分析用户遇到的障碍，它首先需要被单独识别，再看里面是否包含可以归因的实际问题。
删掉PR，也还没得到购买者
即使把598条PR全部移出支持问题统计，剩下的1,494条issues链接也不能直接叫作1,494个用户痛点。issue里可以写建议、项目计划、教程、新闻转载；真实故障也可能有多条重复描述。
进一步说，一个人已经愿意安装本地模型，不代表他愿意买一台专用硬件。一个兼容性报错，不代表他希望用硬件产品解决。原文能支持的是哪一层，结论就应该停在哪一层。
我更愿意沿着具体经历往下问：他原来想完成什么；问题造成了什么损失；他怎样绕过；后来继续用了没有；谁承担解决成本。记录不足时，就把这些写成访谈问题。这样做会减少可以报出来的“需求条数”，却让留下来的材料更接近一个产品选择。
报告数字也有自己的版本
旧扩源报告记录的主数据规模是210,581行；同日扫描的当前文件是211,088行。两者不同，本身还不能证明旧报告当时写错了，也不能说明新增记录都有效。它说明报告和数据快照之间需要一条明确的对应关系。
如果把早期报告的样本构成、后来数据的总量、最新分类器的标签放进同一张表，它们可能各自都真实，放在一起却没有共同的统计口径。
一个足够务实的做法，是让每次用于文章的统计都带着文件哈希、计算脚本和筛选条件。研究不需要向读者展示每一项工程细节，但作者应当能回答：这句话究竟来自哪一版材料。
更值得留下的研究资产
这次复核没有逐条人工标注全部 GitHub 记录，也没有完成其他来源的同类审计，因此不足以重判整份研究。能够确定的，是这个支持问题标签的生成方式和它在指定下游文件中的延续。
下一步应当先把平台来源与内容角色拆开，再挑与具体文章有关的记录做语义复核。统计修正后，检查哪些论点确实依赖这组数量；不依赖它的判断，不必为了显示谨慎而全部推倒。
下次看到“分析了二十万条用户反馈”，我会先问：里面有多少条，确实是用户在谈自己的经历？
这个问题比数据量小得多，也难回答得多。
数据说明
本文来自个人研究资料的本地快照复核，核对日期为2026年10月10日。主数据、打标视图和月度平衡视图存在重叠，不能相加。数字是记录行数，不是人数；PR链接只标识记录类型，不等于判断该记录没有研究价值。
公开计数与方法说明列出六个视图的汇总、计算条件与整文件哈希。原始平台文本、用户标识和内部路径不公开；公开汇总可核对本文数字，不能独立重跑完整语料。这里的分类问题不改变历史快照本身，也不等于推翻其他来源的判断。