嘿！
我经常发现自己想使用自动化，但又觉得它们目前的工作方式受到限制。我经常发现一个脚本有我需要的东西，而我需要这部分能在另一个脚本的上下文中工作。
这似乎在很大程度上与自动化目前的工作方式和设置方式有关。我希望看到将它们拆分为触发器和操作。
这种设置将允许：
最终，我认为自动化有很大的潜力，但每个脚本都是孤立的，这使得它很难根据个人需求进行定制。每个脚本目前都假设可用的操作对每个人都适用。
我开始用我的个人助理 Jarvis 玩弄这个想法：
你觉得怎么样？它甚至还有一个交互式演示。
我确实觉得这个 触发器 → 过滤器 → 操作 → 操作 链条非常吸引人。它使自动化更加灵活和清晰。
我非常喜欢这个提议！它似乎解决了自动化目前存在的大部分（如果不是全部）痛点。
它也感觉更具可扩展性，可以添加新的触发器（Triggers）和操作（Actions）。我设想这会为轻松添加额外的触发器打开大门——比如 theme_created 或 theme_updated——而无需担心它们如何与预先存在的脚本交互。新的触发器将立即获得访问所有现有操作的权限（Slack 通知、私信、LLM 调用等）。为创建额外的操作（如 assign_badge、add_to_group、add_to_logs_and_screening 等）也是同理。
哦，还有“模拟运行”（Dry run）和“执行日志”（Execution logs）也恰到好处——对事物实际运行情况有这种程度的可观察性简直是救星。
我只是快速说一下：除了触发器/过滤器/动作之外，能够添加延迟将非常宝贵。
（示例：入职/提醒，在加入社区一周后发送消息，然后在两个月后，或者如果成员在加入后 x 天内没有发帖或阅读等，则执行某些操作……我们的社区肯定不会使用，但对于像我们这样的活跃支持社区类型来说，它会很有用！）
虽然这仍处于概念阶段，但我会继续集思广益 
关于条件，我一直在想实际可以构建多少灵活性。很高兴能实现类似截图中的功能，让用户完全控制条件的构建方式。允许用户从 trigger_context 中选择数据，定义如何评估它，并设置评估标准——同时让他们在 AND / OR 逻辑之间进行选择。
这将解锁更复杂的场景，同时保持易于理解和直观，例如：
if {{category}} is one of {{user selected value}} ANDif {{tag}} is not {{user selected value}}截图还包括了条件检查后要做什么，但这可能只适用于分支管道——对于线性管道（涵盖大多数情况），那么它可能只是简单地结束
