# 功能请求 - 将自动化拆分为触发器和操作
**URL:** https://meta.discourse.org/t/feature-request-split-automations-into-triggers-and-actions/384262
**Category:** Feature
**Tags:** automation
**Created:** [2025 年9 月 29 日 11:15 UTC](https://meta.discourse.org/t/feature-request-split-automations-into-triggers-and-actions/384262 "2025-09-29T11:15:32Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@noahl](https://meta.discourse.org/u/noahl)
#### Post date: [2025 年9 月 29 日 11:15 UTC](https://meta.discourse.org/t/feature-request-split-automations-into-triggers-and-actions/384262/1 "2025-09-29T11:15:32Z")
嘿！
我经常发现自己想使用自动化，但又觉得它们目前的工作方式受到限制。我经常发现一个脚本有我需要的东西，而我需要这部分能在另一个脚本的上下文中工作。
这似乎在很大程度上与自动化目前的工作方式和设置方式有关。我希望看到将它们拆分为触发器和操作。
- 示例触发器：
- 创建/更新主题时
- 创建/更新帖子时
- 网站设置更改时
- 关闭主题时
- 用户获得徽章时
- 等等。
- 示例操作：
- 创建一个横幅主题
- 关闭一个主题
- 回复一个主题
- 创建一个主题
- 标记一个主题
- 运行 LLM 调用
- 发送 Slack 消息
- 等等。
这种设置将允许：
- 在触发器后分配多个操作（例如，当主题被创建时 \> 运行 LLM 调用 \> 标记帖子 \> 回复主题）
- 允许触发器负载数据\*（以及后续操作提供的数据 - 例如，LLM 调用响应）\*在操作中动态使用
最终，我认为自动化有很大的潜力，但每个脚本都是孤立的，这使得它很难根据个人需求进行定制。每个脚本目前都假设可用的操作对每个人都适用。
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [2026 年3 月 9 日 04:31 UTC](https://meta.discourse.org/t/feature-request-split-automations-into-triggers-and-actions/384262/2 "2026-03-09T04:31:54Z")
我开始用我的个人助理 Jarvis 玩弄这个想法：
> **[Discourse Automations Need Pipelines — wasnotwas](https://wasnotwas.com/writing/discourse-automation-pipelines/?b)**
>
> A proposal to redesign Discourse's automation system: separate triggers from conditions from actions, enable pipelines, and stop every script from being a kitchen sink.
你觉得怎么样？它甚至还有一个交互式演示。
我确实觉得这个 触发器 → 过滤器 → 操作 → 操作 链条非常吸引人。它使自动化更加灵活和清晰。
---
### Author:  [@noahl](https://meta.discourse.org/u/noahl)
#### Post date: [2026 年3 月 9 日 10:41 UTC](https://meta.discourse.org/t/feature-request-split-automations-into-triggers-and-actions/384262/3 "2026-03-09T10:41:47Z")
我非常喜欢这个提议！它似乎解决了自动化目前存在的大部分（如果不是全部）痛点。
它也感觉更具可扩展性，可以添加新的触发器（Triggers）和操作（Actions）。我设想这会为轻松添加额外的触发器打开大门——比如 `theme_created` 或 `theme_updated`——而无需担心它们如何与预先存在的脚本交互。新的触发器将立即获得访问所有现有操作的权限（Slack 通知、私信、LLM 调用等）。为创建额外的操作（如 `assign_badge`、`add_to_group`、`add_to_logs_and_screening` 等）也是同理。
哦，还有“模拟运行”（Dry run）和“执行日志”（Execution logs）也恰到好处——对事物实际运行情况有这种程度的可观察性简直是救星。
---
### Author:  [@stephtara](https://meta.discourse.org/u/stephtara)
#### Post date: [2026 年3 月 9 日 23:34 UTC](https://meta.discourse.org/t/feature-request-split-automations-into-triggers-and-actions/384262/4 "2026-03-09T23:34:13Z")
我只是快速说一下：除了触发器/过滤器/动作之外，能够添加延迟将非常宝贵。
（示例：入职/提醒，在加入社区一周后发送消息，然后在两个月后，或者如果成员在加入后 x 天内没有发帖或阅读等，则执行某些操作……我们的社区肯定不会使用，但对于像我们这样的活跃支持社区类型来说，它会很有用！）
---
### Author:  [@noahl](https://meta.discourse.org/u/noahl)
#### Post date: [2026 年3 月 10 日 00:02 UTC](https://meta.discourse.org/t/feature-request-split-automations-into-triggers-and-actions/384262/5 "2026-03-10T00:02:33Z")
虽然这仍处于概念阶段，但我会继续集思广益 😃
关于条件，我一直在想实际可以构建多少灵活性。很高兴能实现类似截图中的功能，让用户完全控制条件的构建方式。允许用户从 `trigger_context` 中选择数据，定义如何评估它，并设置评估标准——同时让他们在 `AND` / `OR` 逻辑之间进行选择。
这将解锁更复杂的场景，同时保持易于理解和直观，例如：
- `if {{category}} is one of {{user selected value}}` **AND**
- `if {{tag}} is not {{user selected value}}`
_截图还包括了条件检查后要做什么，但这可能只适用于分支管道——对于线性管道（涵盖大多数情况），那么它可能只是简单地结束_
