问题
在分开部署 staging/production 实例的 n8n 团队中，每次临时测试线上工作流“都被强制先保存”，导致生产/暂存环境的存储版本被意外修改，事后还要人工恢复，被描述为 tedious and error-prone。另一类用户在排障时如果修改了失败节点之前的节点，“不得不选择 debug 并手动运行执行”，无法从执行历史直接从头重跑。两类用户的共同痛点是：n8n 的调试流程会把“试错”和“持久化修改”耦合在一起，出错成本高。
目标用户
自托管 n8n、并将 staging 与 production 分实例部署的中重度自动化用户和小团队（signals 中的两条请求均来自此类场景）。这是 devtools 中的细分人群，规模有限但使用频率高、对调试效率敏感。
解决方案
- 免保存测试执行：把当前编辑器中的工作流 JSON 推送到隔离的临时执行环境跑一遍，完成后自动清理，不修改实例上已保存的版本
- 自动快照与回滚：每次测试前对目标工作流打快照，试错结束后一键恢复到测试前状态
- 执行历史从头重跑：在 executions 页面修改了失败节点之前的节点后，一键以原输入数据从工作流第一步重新执行到失败点
- 暂存/生产隔离视图：明确标示当前执行目标实例，避免误改生产
AI 在这里的角色有限，核心是执行编排与版本管理工程；可作为辅助用 LLM 对失败执行做原因摘要。
MVP 范围
第一版做：
- 一个轻量 CLI 或浏览器插件，读取当前编辑器中的工作流 JSON，通过 n8n API 以临时副本执行，不触碰生产/暂存实例上保存的版本
- 执行前自动创建工作流快照，测试后可一键恢复
- 在执行历史中增加“从头重跑”入口：修改了失败节点之前的节点后，自动以旧执行数据从第一步重跑到失败点
明确不做：
- 不做通用工作流引擎，只服务 n8n
- 不做团队协作、权限管理
- 不做执行监控告警等周边功能
风险
- 平台依赖（核心风险）：功能完全建立在 n8n 的 API 和内部行为之上，n8n 版本迭代或官方直接实现这两个功能请求都会让产品失去存在意义
- 集成深度受限：n8n 编辑器是自托管 Web 应用，“免保存执行”可能需要逆向或非官方接口，实现可能脆弱
- 需求真实性弱：两条请求 engagement 极低（0 条评论），痛感评分仅 3/10，可能只是小众困扰
- 变现路径不明：功能请求者默认这是官方应免费提供的能力，第三方付费工具接受度存疑
已有产品
| 产品 | 定位 | 价格 |
|---|---|---|
| n8n | 官方平台本身，两条功能请求都直接指向 n8n，官方最有可能自行实现这些调试功能 | — |
信号证据
这张卡片依据的原始讨论。摘录保持原文，点“原文”查看上下文。
n8n 社区 · 功能请求9月30日功能请求▲ 00 条评论
“Every time we have an issue, if we end-up changing the nodes before the failed node, we have to select debug and manually run the executions.”
When editing nodes before a failed node, users have to manually debug and rerun executions instead of being able to rerun the workflow from the beginning from the executions history.原文
n8n 社区 · 功能请求9月30日功能请求▲ 10 条评论
“Today, every one of those experiments forces a save of the workflow. On prod/staging that means modifying the stored workflow just to try something, then remembering to revert it afterwards.”
在 n8n 中调试线上工作流时,每次临时测试都被强制先保存工作流,导致生产/暂存环境的存储版本被意外修改且难以回退。原文