根据给定标准(如时间戳)移动主题的系统创建

请参阅 AI 机器人集成文档:Discourse AI - AI bot - Documentation / Site Management - Discourse Meta

额外说明/编辑:我是自托管的
如果您不想阅读完整的故事,简短版本如下:我想使用 AI 机器人根据“过期日期”移动主题,方法是检查帖子的时间戳。

因此,我一直在思考改善 Discourse 管理以适应我的用例的方法。我经营一个 Roblox 游戏社区,我们使用 Discourse 供我们的版主团队执行游戏版主操作和 Discord 操作的日志记录工作。

我们有几个类别,包括临时封禁。当我们进行日志记录时,它们会作为帖子完成,版主会填写一个格式,并插入与所采取操作相关的“时间戳”,例如 7 天封禁,例如 期限: 2026-03-01T05:00:00Z2026-03-08T05:00:00Z(时间戳在这里)

从管理方面来说,我添加了一个“已存档封禁”类别,用于处理已过期的封禁。以前……您猜对了,我们是手工操作的,每周检查一次封禁。

去年秋天,我制作了一个 Python 实用程序 [见下文],它在本地运行,使用 Discourse API,它会打开一个菜单,我选择我想存档的封禁部分,然后它会处理这些封禁,方法是检查每个帖子是否有有效的时间戳以及该时间是否已过。它运行良好,但我希望进一步改进……

现在我们到了……希望你还在,可能可以把这个总结一下,但嘿,Discourse 是关于对话的,对吧?

我想让我的版主团队,特别是级别最高的成员,能够在不使用 VS 或在他们的机器上下载任何东西的情况下执行此任务。所以,我尝试制作一个插件版本,我承认我使用了 AI 来尝试完成它。我不确定哪里出了问题,我尝试查看文档,甚至提供遵循流程的说明,但都没有成功。

我在通过插件集成方面遇到的问题是,我无法理解(或 AI 无法理解)如何将一个视觉界面集成到界面中(不像 Python 版本那样色彩鲜艳,但以一种可以理解的方式),例如,一个写着“运行存档流程”的大按钮,并利用版主 API(?)来标记那些没有有效日期或有错误的帖子等。

所以……这就是长篇故事的结尾……我想要一些我无法从其他人那里获得的意见,这就是我来这里的原因。

  • AI 机器人有这个能力吗?
  • 如果没有,我应该尝试什么合理的解决方案?
  • 我在插件路径上做错了什么,导致它根本不起作用/很麻烦(就像你刚开始在这个社区时犯过的常见错误一样?)

重视您的意见。谢谢。

1 个赞

我不认为你需要为此求助于人工智能。

当您创建这些主动封禁主题时,为什么不同时创建一个主题计时器,以便在经过一段时间后将其移动到正确的类别,这样它就是自动的。

另外……你为什么要偏离 Discourse 核心功能呢,我们已经有被封禁用户的日志了,为什么不直接授予您受信任的用户访问数据浏览器查询的权限来查看历史记录呢?

该论坛用于记录封禁……这就是其全部目的。论坛上没有玩家……只有游戏/Discord 的版主。我不认为主题计时器会起作用,因为封禁时间各不相同。我不是在远离 Discourse Core,而是在将其用于特定用例。(见下图)

1 个赞

有趣的应用场景!

我确实认为您进行一些更改会更好:

将封禁到期时间移至专用的自定义主题字段

这将允许您在创建新主题时验证每个封禁都有一个到期时间,并使查询已过期的封禁变得轻而易举。

您还可以使用我们的 Introducing Experimental Form Templates(介绍实验性表单模板),它也为您提供了对主题中特定数据的程序化访问。

添加 /filter 自定义过滤器

有了自定义字段或表单模板,现在可以轻松添加新的 /filter 过滤器,例如已过期的封禁、已存档的封禁等。这些将成为您的版主主要工作列表,并且可以添加到侧边栏以便于使用。

整体自动化封禁?

最后一步是让 Discourse 在创建主题时自动在 Roblox 和 Discord 上创建封禁,并在封禁到期时自动移除封禁。

使用定期作业和 API 访问可以很容易地做到这一点。


如果您有 Set up a local Discourse Development Environment(设置本地 Discourse 开发环境),那么您甚至可以将我的帖子作为规范传递给 Claude Code,它会在几分钟内构建出来。

3 个赞

这是一个非常有趣的观点!我会去看看的!特别是自定义字段和模板。感谢您的见解!

提供更多背景信息,因为我的用例似乎引起了你们的兴趣……而且我喜欢为其他游戏社区贡献想法,供他们将来参考……

我的用例确实非常独特。我们使用 Trello 很多年了,但由于他们开始施加的限制,它变得越来越混乱。我们不得不使用 10 个工作区来容纳我们的整个团队。(更不用说他们开始将访问级别限制为付费功能了)

因此,随着与商业模式变更的持续斗争,过渡到一个自托管解决方案要容易得多。我尝试了其他看板风格的软件,但鉴于过去试用 Discourse 的经历,以及它是开源的,并且在后端使用更现代的做法,我简直无法抗拒使用它,并且一直对这个平台作为一个整体所取得的成就和持续的增长感到惊讶。九月是我切换到这里的两周年纪念日,我们已经创建了超过 6,000 个主题!

我试图模仿的功能是类似于那个时代的功能,即在特定触发器(对我们来说是结束日期)下自动从一个列表移动到另一个列表。不幸的是,这是一个我甚至无法再演示的高级功能。

image

我会在完成探索后回来这里,告诉你们进展如何/我做了什么,特别是为了让看到类似用例的人也能获得一些想法!

2 个赞

一旦您的插件开始运行,您也可以像以前一样进行可视化,这要归功于 看板 (Kanban Board)

2 个赞

好了,我又回来了……取得了相当大的进展。我在这上面花了大约 6.5 个小时。

我一开始根据您的建议做了一些概念,但遇到了几个缺点,最终引导我走向了另一个方向,但希望在概念上仍然是一个很棒的方向!

我最初打算使用模板表单(Template Forms),但对每行答案之间的填充(padding)不太满意。我正在寻找更像我当前设置的格式。我也不喜欢必须在代码中手动编写所有内容,这让我望而却步。

我已将我的 Python 脚本移植到了 Discourse 插件中(请注意,大部分移植工作是使用 AI 完成的)。在开始时我遇到了一些问题,现在它已经可以运行了,但我仍然需要对其进行微调。设计有点笨拙,可能还有一些其他零碎的问题。我对 Ruby 不太擅长,所以那方面的审查是尽力而为。

所以,关于这个插件……

概念/目的:能够通过特定触发器更快地将主题从一个类别移动到另一个类别

它有两种操作模式:手动(Manual)和自动(Automated)(计划的)。
要构建触发器,您可以选择到/从类别,然后通过进一步的规格(例如标签)进行筛选。除了筛选过滤器之外,最终的调用/实际触发器是基于结束时间/日期戳(或开始时间)、关闭(Closed)、已解决(Solved)、已存档(Archived)。

还有一个日志功能,包括主题被移动时的情况,您可以决定日志保留多长时间。

截至本次回复,我还没有完全测试关闭、已解决或已存档的触发器。
等我再整理一下,并进一步测试以确保一切正常,我很乐意在插件类别中发布它供他人访问,但目前,我只会将其保留在 GitHub 上。我可能还需要回去检查一下权限,以确保不是任何人都可以运行它。或者具体允许切换此设置。

请随时让我知道您的想法,或者我是否在做这件完全疯狂的事情。

来源:https://github.com/jdc20181/DiscourseTopicMigrationTool