如何查找 Telegram 频道正文中提到的 @username

“我想知道 @username 今天说了什么”在群组和广播频道里代表两种不同任务。群组消息可能带有成员发送者；广播频道的帖子通常以频道身份发布，正文里的 @username 只是一个被提到的字符串。把两者混在一起，会得到看似合理但身份错误的答案。

如果产品当前只支持广播频道，更准确的问题是：“频道今天有哪些消息提到了 @username，这些消息说了什么？”本文只讨论这种正文提及，不把它解释为该用户亲自发言。

先区分三种对象

一个频道可以引用别人的用户名、转述观点、发布采访内容或提醒用户关注某账号。命中 @username 只能证明频道正文出现了它，不能证明账号本人写了这条帖子，更不能完成真实身份认定。

用准确用户名做第一轮搜索

先保留 @ 输入完整用户名，例如 @example_user。再尝试去掉 @ 的形式，因为正文可能只写 example_user，也可能把它放在 t.me/example_user 链接中。

建议记录三组变体：

1. 当前完整用户名；
2. 不带 @ 的用户名；
3. 已知显示名称、品牌名或旧用户名。

用户名可能被更改或转让。当前用户名搜索不到旧消息时，不代表过去没有提及；旧消息里保存的文字可能仍是之前的名字。反过来，同一个字符串在不同时间也未必指向同一实际主体。

把时间和语境写进问题

不要只问“这个用户说了什么”。可以改成：

找出当前频道今天正文中提到 @example_user、Example Labs 或 example_user 链接的消息。按时间排序，说明每条是在引用、推荐、批评还是发布联系方式，并给出原消息。不要判断该账号本人发言。

若频道信息很多，再加入项目名、地点或事件。时间范围应使用页面实际显示的起止日期，尤其要注意“今天”对应的时区。

处理转发、引用和截图文字

转发消息可能保留可见来源，也可能只剩频道自己的正文。引用块里的用户名仍然只是当前帖子展示的文字。截图、视频字幕或附件内部的用户名，普通正文搜索未必能够发现。

因此结果应说明它搜索的是可查询消息文字和已提供的元数据，而不是所有图片、语音与文件内容。用户明确知道用户名在截图里时，应直接打开相应日期附近的媒体，而不是把文字搜索零结果理解为不存在。

如何整理命中结果

一个可核验列表至少包含：消息时间、出现的名称变体、简短上下文、频道消息链接。还可以增加“提及类型”字段，但只使用原文能够支持的分类：

• 联系方式或账号推荐；
• 引用或转述；
• 事件参与者；
• 风险提醒或投诉；
• 无法从上下文确定。

不要仅根据语气推断账号和频道之间的关系。频道写“我们的朋友”不等于法律、雇佣或商业关系已经得到证明。

用户名变化后如何保持可追溯

保存研究结果时，应记录消息当时显示的用户名文字，而不是只保存后来解析出的账号。原消息链接和消息时间比当前显示名称更稳定，也更便于解释“为什么当时会命中”。

链接可能因为访问条件、频道用户名变化或消息删除而无法打开。此时可以说明来源目前不可用，但不能凭空补写原文，也不能把旧用户名自动映射到一个未经核实的新账号。

asktele 可以回答到什么程度

asktele 可以在一个选中的广播频道中查找正文提及，按自然语言整理相关消息，并提供可用的消息出处。它不能把正文里的 @username 变成群组发送者字段，也不能证明现实身份、账号控制权或某句话确由该用户本人发表。

如果问题真正需要“某个群成员今天发过什么”，当前产品的频道范围并不适合，应使用 Telegram 群组自身的发送者搜索和管理能力。产品边界写清楚，比返回一个身份错误的完整答案更重要。