尧图网页设计 
【免费下载链接】superplaneOpen source factory for one-shot engineering项目地址https://gitcode.com/gh_mirrors/su/superplane点击查看免费下载SuperPlane 是一键式工程的开源工厂仓库根目录见 README.md它通过集成Integration与外部服务相连把第三方工具变成工作流中的触发器Trigger与动作组件Action。本篇指南围绕仓库中定义的标准研究流程展开当你已经拥有一个 SuperPlane 集成希望为它扩展更多组件时如何用可用性优先usability-first的思路做调研、定方向最终产出一批真正贴合用户使用场景的新组件。读完你将掌握这套可复用的研究方法、它与新建集成流程的区别以及如何把调研结论落地到仓库的真实结构中后端pkg/integrations/、前端 mappers、组件文档与测试。这套方法从哪来本流程的权威定义位于仓库内的 .cursor/commands/research-extension.md它是一个可被 Cursor 类 AI 助手直接调用的研究命令command并引用配套的技能定义 .cursor/skills/superplane-integration-research/SKILL.md。仓库里还有它的孪生命令 .cursor/commands/research-integration.md负责全新工具的集成调研两者共享同一技能、同一方法论区别只在输出物新集成建议2 个起步组件1 触发器 1 动作扩展集成建议少量契合的追加组件。这套方法论与仓库的工程化文档链是贯通的docs/contributing/building-an-integration.md 定义了选集成 → 研究连接方式 → 实现 → 提 PR的高层步骤docs/contributing/integrations.md 给出了后端与前端的具体实现模式docs/contributing/component-design.md 则规定了组件的产品设计标准。本指南的调研环节正是这些实现文档的上游——先把方向想清楚再动手写代码。核心定位这是一份可用性研究而非工程研究命令开篇即声明了研究者的身份与职责边界You are aresearch helperforextendingan existing SuperPlane integration. Focus onusability: whats the tools priority function, what use cases were not covering yet, what the API allows.研究助手只回答三个问题这个工具的优先功能是什么、我们还没覆盖哪些使用场景、API 允许我们做什么。然后据此建议契合的追加组件。连接细节连接方式、鉴权参数、约束属于工程师的范畴研究者只需要知道能访问到什么不需要产出连接规格书。这条边界在技能定义中被进一步固化.cursor/skills/superplane-integration-research/SKILL.md 明确写出你不以连接方法或工程实现开场连接细节留给实现者去探索你只需要连接层面的洞察例如他们提供 webhooks所以可以做事件触发器有 REST API可以做部署动作来支撑组件建议不要把 Auth / API / Constraints 作为交付物。五步工作流从已有组件走到新增组件清单.cursor/commands/research-extension.md 定义了研究者的完整工作方式共五个步骤从我们已有什么开始。先回答一个短句集成里已经有啥依据docs/components/下的组件文档或 docs。紧接着给出这个工具的主要工作是什么以及我们可能遗漏的使用场景。然后看 API。API 还暴露了哪些契合这些场景的能力有哪些限制只要足够判断可行性即可——不需要连接规格。建议几个追加组件。每个一行匹配优先功能与使用场景。随后询问用户想增加或删减哪些。当用户准备好锁定输出简短总结 已有组件 追加组件。连接方式仅在相关时用一行带过。红线Never不以连接方法开场、不做长报告、不输出工程向内容。最终目标通过对话收敛出一小组对用户如何使用该工具而言合理的追加组件。研究时的关注顺序五个维度层层递进技能文件给出了研究者每次调研都应遵循的五个维度按序执行顺序关注点要回答的问题1工具是什么它是干什么的优先功能用户主要用它做的事是什么2好的使用场景用户什么时候想在 SuperPlane 工作流里用到它它解决什么问题3API 与限制API 实际让我们做什么事件 → 触发器操作 → 动作。有什么限制或怪癖4连接方式只需了解到可能做到什么的程度如有 webhooks可做事件触发器REST API 可做部署不产出连接规格5建议组件基于 优先功能 使用场景 API 允许范围 来建议新集成给 2 个起步组件1 触发器 1 动作扩展给少量契合组件其中事件 → 触发器、操作 → 动作的映射是贯穿始终的主线SuperPlane 集成由两类构件组成——触发器监听外部事件、启动工作流执行和动作组件响应上游事件执行操作。判断某个 API 能力该做成哪一类看它本质上是被动接收的事件还是主动发起的操作。已有的相似集成最有效的建议捷径技能定义里给了研究者一条高效策略如果目标工具与仓库已有的某个集成相似用一行话点出并复用它的组件作为模式模板。例如If the tool is similar to one we have (e.g. Railway ↔ Render), mention it in one line and use it as a pattern for components.这也是扩展已有集成调研独有的优势仓库 pkg/integrations/ 下已有数十个集成github、gitlab、slack、pagerduty、sentry、semaphore、render、datadog、jira、linear 等每个都在 docs/components/ 有对应的组件文档可以直接作为该类型工具通常该有哪些组件的参照系。组件的设计语言调研者该懂的判断标尺要让建议的组件合理需要理解 SuperPlane 组件的基本设计语言详见 docs/contributing/component-design.md它们是建议是否靠谱的检验标准触发器 vs 动作触发器监听外部事件启动工作流执行无输入通道动作响应上游事件执行操作有输入通道左把手可订阅上游节点事件。输出通道一个还是多个组件可定义具名输出通道passed、failed、approved、timeout……用于把执行结果路由到不同下游分支。判断依据是大多数用户会不会针对这个结果走不同的后续处理场景通道设计部署类动作Deploysuccess/failed两个通道用户几乎总要区分成败审批类组件approved/rejected天然决策分支纯数据转换、成功/失败标准因人而异单一default通道让用户用 Filter 自行分流状态failed 与 error 必须分清这是组件设计中最关键的一处区分也是调研者在判断该组件适合哪些使用场景时应牢记的语义failed预期内的失败结果组件成功执行了但结果是失败HTTP 返回 404、CI 流水线失败error非预期故障组件没能完成执行网络超时、凭证无效、内部异常。每个组件必须支持error状态即使只定义了approved之类的自定义状态也不能例外。Payload 结构面向表达式设计组件向下游发射 JSON payload含data、timestamp、type三部分用户在后续节点用表达式访问如$[Create Issue].issue.number。规则表达式路径超过 3 层就是太深。对于外部 API 原生返回的数据GitHub、Slack 等倾向于保留原始结构而非强行扁平化因为用户对照外部 API 文档时更熟悉原生格式。默认配置要贴近最常见用例.cursor/commands/research-extension.md 与技能均强调建议组件时要考虑默认行为。集成开发指南 docs/contributing/integrations.md 也给出了最佳实践默认配置应覆盖最常见的使用场景并避免产生不必要的事件例如github.onPush触发器默认只监听main分支的提交。调研者在建议触发器组件时应同时想清楚它的默认过滤条件。落地路径调研结论如何在仓库中兑现调研锁定的组件清单最终通过以下仓库结构落地细节见 docs/contributing/integrations.mdpkg/integrations/app-name/ # Go 后端集成主文件、client、各触发器/组件 web_src/src/pages/workflowv2/mappers/app-name/ # TypeScript 前端渲染器 docs/components/AppName.mdx # 组件文档可用 make gen.components.docs 生成 pkg/integrations/app-name/*_test.go # 单元测试集成在init()中通过registry.RegisterIntegration(...)注册若需要管理 webhook则改用registry.RegisterIntegrationWithWebhookHandler(...)参考 pkg/integrations/render/render.go。主文件实现Configuration()配置字段、Actions()动作列表、Triggers()触发器列表、Sync()配置校验与就绪状态等接口。以 Render 集成为例一次扩展调研的成品形态Render 集成是理解扩展结果的绝佳样例其组件文档见 docs/components/Render.mdx后端实现位于 pkg/integrations/render/。它的组成正好对应研究方法论中的两类构件触发器 2 个render.onBuild、render.onDeploy监听构建/部署事件默认分别监听build_ended、deploy_ended属于事件 → 触发器动作 9 个Deploy、Cancel Deploy、Rollback Deploy、Get Deploy、Get Service、Purge Cache、Add/Remove Custom Domain、Update Env Var属于操作 → 动作。从 pkg/integrations/render/render.go 可以看到这两个列表的源码注册形态。多个等待型动作Deploy、Cancel Deploy、Rollback Deploy都复用同一个deploy_endedwebhook 并带轮询兜底这印证了技能里连接洞察只需够用的原则——研究者在调研阶段只要知道Render 有 webhooks 可做事件触发器、有 REST API v1 可做部署/回滚/域名管理等动作就足以提出组件建议。调研够用即可的源码例证Webhook 共享机制技能明确要求研究者不写连接规格但理解连接能力边界仍然必要。Render 的 webhook_handler.go 展示了连接层面的核心机制CompareConfig决定两个 webhook 配置是否等价可复用Merge合并多个触发器的监听事件类型。这意味着同一个集成内多个触发器/组件可以共享一个 webhook——调研者据此就能判断哪些组件建议成本低、易落地。交流风格像同事一样对话拒绝八股两份命令文件对响应方式有明确、可执行的约束简短、会话式几句话或 2–3 个要点即可每次一轮一个发现然后询问用户下一步想了解什么例如要我看看 API 还暴露了什么吗不要灌水不写正式的小节标题、不写全面概述像同事一样说话结束时若用户准备锁定输出简短总结工具是干什么的 建议组件每个一行可选一行连接方式看起来是 X——工程师可以细化不要让连接成为主要输出。这种风格本身就是设计决策它把研究当作与用户的协作对话而非一次性交付报告从而在每一步都让用户有机会纠正方向最终收敛到真正被认可的小组件集合。与新建集成流程的分工对全新工具使用 .cursor/commands/research-integration.md输出 2 个起步组件1 触发器 1 动作并对相似集成如 Render做一行类比对已有集成本指南主题使用 .cursor/commands/research-extension.md先盘点已有组件再建议少量契合的追加组件。两者共享技能 superplane-integration-research都遵循工具是什么 → 使用场景 → API 能力 → 连接洞察 → 组件建议的同一骨架也都坚持可用性优先、工程细节后置的立场。调研完成后如何验证与提 PR组件锁定后进入实现阶段docs/contributing/building-an-integration.md 给出了收尾流程实现后端于pkg/integrations/name/前端 mappers 于 web_src/src/pages/workflowv2/mappers/文档写在集成包内用make gen.components.docs生成测试make format.go make lint make check.build.app、make test、make check.build.ui并考虑 E2E 测试见 docs/contributing/e2e-tests.md提 PR 时遵循 docs/contributing/integration-prs.md 的规范标题、描述、issue 链接、视频演示、CI 与 DCO 签名提交。小结把扩展变成有依据的决策.cursor/commands/research-extension.md 定义的扩展研究流程本质是把为已有集成加组件从拍脑袋变成结构化决策先盘点现状再以优先功能 使用场景 API 允许范围三角收敛候选组件用仓库中相似集成的既有模式做参照最后以简短总结锁定成果。这套方法论与 docs/contributing/component-design.md 的设计标尺触发器/动作、输出通道、failed 与 error 语义、payload 扁平度互为表里与 docs/contributing/integrations.md 的落地结构无缝衔接。对任何想在 SuperPlane 生态中扩展集成的开发者或 AI Agent 来说这是从调研到交付的最短可靠路径。赞分享【免费下载链接】superplaneOpen source factory for one-shot engineering项目地址https://gitcode.com/gh_mirrors/su/superplane点击查看免费下载相关推荐Formily扩展组件第三方UI库集成指南Formily扩展组件第三方UI库集成指南 在现代前端开发中表单是用户交互的核心组件之一。然而不同项目可能采用不同的UI组件库如何将这些UI库与Form前端UI组件LoopBack与Express集成如何扩展现有Express应用的完整指南LoopBack与Express集成如何扩展现有Express应用的完整指南 LoopBack是一个强大的开源Node.js框架它能够轻松构建需要复杂集成的后端Web框架API设计Tunasync多数据库后端支持Bolt、Badger、Redis、LevelDB对比分析Tunasync多数据库后端支持Bolt、Badger、Redis、LevelDB对比分析 Tunasync作为一款强大的镜像任务管理工具提供了多种数据库后上一篇3步掌握Fooocus让AI图像生成变得像说话一样简单下一篇pgmpy性能优化利用Torch后端加速大规模网络推断创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SuperPlane 集成扩展研究指南：用“可用性优先“方法论为现有集成新增组件
【免费下载链接】superplaneOpen source factory for one-shot engineering项目地址https://gitcode.com/gh_mirrors/su/superplane点击查看免费下载SuperPlane 是一键式工程的开源工厂仓库根目录见 README.md它通过集成Integration与外部服务相连把第三方工具变成工作流中的触发器Trigger与动作组件Action。本篇指南围绕仓库中定义的标准研究流程展开当你已经拥有一个 SuperPlane 集成希望为它扩展更多组件时如何用可用性优先usability-first的思路做调研、定方向最终产出一批真正贴合用户使用场景的新组件。读完你将掌握这套可复用的研究方法、它与新建集成流程的区别以及如何把调研结论落地到仓库的真实结构中后端pkg/integrations/、前端 mappers、组件文档与测试。这套方法从哪来本流程的权威定义位于仓库内的 .cursor/commands/research-extension.md它是一个可被 Cursor 类 AI 助手直接调用的研究命令command并引用配套的技能定义 .cursor/skills/superplane-integration-research/SKILL.md。仓库里还有它的孪生命令 .cursor/commands/research-integration.md负责全新工具的集成调研两者共享同一技能、同一方法论区别只在输出物新集成建议2 个起步组件1 触发器 1 动作扩展集成建议少量契合的追加组件。这套方法论与仓库的工程化文档链是贯通的docs/contributing/building-an-integration.md 定义了选集成 → 研究连接方式 → 实现 → 提 PR的高层步骤docs/contributing/integrations.md 给出了后端与前端的具体实现模式docs/contributing/component-design.md 则规定了组件的产品设计标准。本指南的调研环节正是这些实现文档的上游——先把方向想清楚再动手写代码。核心定位这是一份可用性研究而非工程研究命令开篇即声明了研究者的身份与职责边界You are aresearch helperforextendingan existing SuperPlane integration. Focus onusability: whats the tools priority function, what use cases were not covering yet, what the API allows.研究助手只回答三个问题这个工具的优先功能是什么、我们还没覆盖哪些使用场景、API 允许我们做什么。然后据此建议契合的追加组件。连接细节连接方式、鉴权参数、约束属于工程师的范畴研究者只需要知道能访问到什么不需要产出连接规格书。这条边界在技能定义中被进一步固化.cursor/skills/superplane-integration-research/SKILL.md 明确写出你不以连接方法或工程实现开场连接细节留给实现者去探索你只需要连接层面的洞察例如他们提供 webhooks所以可以做事件触发器有 REST API可以做部署动作来支撑组件建议不要把 Auth / API / Constraints 作为交付物。五步工作流从已有组件走到新增组件清单.cursor/commands/research-extension.md 定义了研究者的完整工作方式共五个步骤从我们已有什么开始。先回答一个短句集成里已经有啥依据docs/components/下的组件文档或 docs。紧接着给出这个工具的主要工作是什么以及我们可能遗漏的使用场景。然后看 API。API 还暴露了哪些契合这些场景的能力有哪些限制只要足够判断可行性即可——不需要连接规格。建议几个追加组件。每个一行匹配优先功能与使用场景。随后询问用户想增加或删减哪些。当用户准备好锁定输出简短总结 已有组件 追加组件。连接方式仅在相关时用一行带过。红线Never不以连接方法开场、不做长报告、不输出工程向内容。最终目标通过对话收敛出一小组对用户如何使用该工具而言合理的追加组件。研究时的关注顺序五个维度层层递进技能文件给出了研究者每次调研都应遵循的五个维度按序执行顺序关注点要回答的问题1工具是什么它是干什么的优先功能用户主要用它做的事是什么2好的使用场景用户什么时候想在 SuperPlane 工作流里用到它它解决什么问题3API 与限制API 实际让我们做什么事件 → 触发器操作 → 动作。有什么限制或怪癖4连接方式只需了解到可能做到什么的程度如有 webhooks可做事件触发器REST API 可做部署不产出连接规格5建议组件基于 优先功能 使用场景 API 允许范围 来建议新集成给 2 个起步组件1 触发器 1 动作扩展给少量契合组件其中事件 → 触发器、操作 → 动作的映射是贯穿始终的主线SuperPlane 集成由两类构件组成——触发器监听外部事件、启动工作流执行和动作组件响应上游事件执行操作。判断某个 API 能力该做成哪一类看它本质上是被动接收的事件还是主动发起的操作。已有的相似集成最有效的建议捷径技能定义里给了研究者一条高效策略如果目标工具与仓库已有的某个集成相似用一行话点出并复用它的组件作为模式模板。例如If the tool is similar to one we have (e.g. Railway ↔ Render), mention it in one line and use it as a pattern for components.这也是扩展已有集成调研独有的优势仓库 pkg/integrations/ 下已有数十个集成github、gitlab、slack、pagerduty、sentry、semaphore、render、datadog、jira、linear 等每个都在 docs/components/ 有对应的组件文档可以直接作为该类型工具通常该有哪些组件的参照系。组件的设计语言调研者该懂的判断标尺要让建议的组件合理需要理解 SuperPlane 组件的基本设计语言详见 docs/contributing/component-design.md它们是建议是否靠谱的检验标准触发器 vs 动作触发器监听外部事件启动工作流执行无输入通道动作响应上游事件执行操作有输入通道左把手可订阅上游节点事件。输出通道一个还是多个组件可定义具名输出通道passed、failed、approved、timeout……用于把执行结果路由到不同下游分支。判断依据是大多数用户会不会针对这个结果走不同的后续处理场景通道设计部署类动作Deploysuccess/failed两个通道用户几乎总要区分成败审批类组件approved/rejected天然决策分支纯数据转换、成功/失败标准因人而异单一default通道让用户用 Filter 自行分流状态failed 与 error 必须分清这是组件设计中最关键的一处区分也是调研者在判断该组件适合哪些使用场景时应牢记的语义failed预期内的失败结果组件成功执行了但结果是失败HTTP 返回 404、CI 流水线失败error非预期故障组件没能完成执行网络超时、凭证无效、内部异常。每个组件必须支持error状态即使只定义了approved之类的自定义状态也不能例外。Payload 结构面向表达式设计组件向下游发射 JSON payload含data、timestamp、type三部分用户在后续节点用表达式访问如$[Create Issue].issue.number。规则表达式路径超过 3 层就是太深。对于外部 API 原生返回的数据GitHub、Slack 等倾向于保留原始结构而非强行扁平化因为用户对照外部 API 文档时更熟悉原生格式。默认配置要贴近最常见用例.cursor/commands/research-extension.md 与技能均强调建议组件时要考虑默认行为。集成开发指南 docs/contributing/integrations.md 也给出了最佳实践默认配置应覆盖最常见的使用场景并避免产生不必要的事件例如github.onPush触发器默认只监听main分支的提交。调研者在建议触发器组件时应同时想清楚它的默认过滤条件。落地路径调研结论如何在仓库中兑现调研锁定的组件清单最终通过以下仓库结构落地细节见 docs/contributing/integrations.mdpkg/integrations/app-name/ # Go 后端集成主文件、client、各触发器/组件 web_src/src/pages/workflowv2/mappers/app-name/ # TypeScript 前端渲染器 docs/components/AppName.mdx # 组件文档可用 make gen.components.docs 生成 pkg/integrations/app-name/*_test.go # 单元测试集成在init()中通过registry.RegisterIntegration(...)注册若需要管理 webhook则改用registry.RegisterIntegrationWithWebhookHandler(...)参考 pkg/integrations/render/render.go。主文件实现Configuration()配置字段、Actions()动作列表、Triggers()触发器列表、Sync()配置校验与就绪状态等接口。以 Render 集成为例一次扩展调研的成品形态Render 集成是理解扩展结果的绝佳样例其组件文档见 docs/components/Render.mdx后端实现位于 pkg/integrations/render/。它的组成正好对应研究方法论中的两类构件触发器 2 个render.onBuild、render.onDeploy监听构建/部署事件默认分别监听build_ended、deploy_ended属于事件 → 触发器动作 9 个Deploy、Cancel Deploy、Rollback Deploy、Get Deploy、Get Service、Purge Cache、Add/Remove Custom Domain、Update Env Var属于操作 → 动作。从 pkg/integrations/render/render.go 可以看到这两个列表的源码注册形态。多个等待型动作Deploy、Cancel Deploy、Rollback Deploy都复用同一个deploy_endedwebhook 并带轮询兜底这印证了技能里连接洞察只需够用的原则——研究者在调研阶段只要知道Render 有 webhooks 可做事件触发器、有 REST API v1 可做部署/回滚/域名管理等动作就足以提出组件建议。调研够用即可的源码例证Webhook 共享机制技能明确要求研究者不写连接规格但理解连接能力边界仍然必要。Render 的 webhook_handler.go 展示了连接层面的核心机制CompareConfig决定两个 webhook 配置是否等价可复用Merge合并多个触发器的监听事件类型。这意味着同一个集成内多个触发器/组件可以共享一个 webhook——调研者据此就能判断哪些组件建议成本低、易落地。交流风格像同事一样对话拒绝八股两份命令文件对响应方式有明确、可执行的约束简短、会话式几句话或 2–3 个要点即可每次一轮一个发现然后询问用户下一步想了解什么例如要我看看 API 还暴露了什么吗不要灌水不写正式的小节标题、不写全面概述像同事一样说话结束时若用户准备锁定输出简短总结工具是干什么的 建议组件每个一行可选一行连接方式看起来是 X——工程师可以细化不要让连接成为主要输出。这种风格本身就是设计决策它把研究当作与用户的协作对话而非一次性交付报告从而在每一步都让用户有机会纠正方向最终收敛到真正被认可的小组件集合。与新建集成流程的分工对全新工具使用 .cursor/commands/research-integration.md输出 2 个起步组件1 触发器 1 动作并对相似集成如 Render做一行类比对已有集成本指南主题使用 .cursor/commands/research-extension.md先盘点已有组件再建议少量契合的追加组件。两者共享技能 superplane-integration-research都遵循工具是什么 → 使用场景 → API 能力 → 连接洞察 → 组件建议的同一骨架也都坚持可用性优先、工程细节后置的立场。调研完成后如何验证与提 PR组件锁定后进入实现阶段docs/contributing/building-an-integration.md 给出了收尾流程实现后端于pkg/integrations/name/前端 mappers 于 web_src/src/pages/workflowv2/mappers/文档写在集成包内用make gen.components.docs生成测试make format.go make lint make check.build.app、make test、make check.build.ui并考虑 E2E 测试见 docs/contributing/e2e-tests.md提 PR 时遵循 docs/contributing/integration-prs.md 的规范标题、描述、issue 链接、视频演示、CI 与 DCO 签名提交。小结把扩展变成有依据的决策.cursor/commands/research-extension.md 定义的扩展研究流程本质是把为已有集成加组件从拍脑袋变成结构化决策先盘点现状再以优先功能 使用场景 API 允许范围三角收敛候选组件用仓库中相似集成的既有模式做参照最后以简短总结锁定成果。这套方法论与 docs/contributing/component-design.md 的设计标尺触发器/动作、输出通道、failed 与 error 语义、payload 扁平度互为表里与 docs/contributing/integrations.md 的落地结构无缝衔接。对任何想在 SuperPlane 生态中扩展集成的开发者或 AI Agent 来说这是从调研到交付的最短可靠路径。赞分享【免费下载链接】superplaneOpen source factory for one-shot engineering项目地址https://gitcode.com/gh_mirrors/su/superplane点击查看免费下载相关推荐Formily扩展组件第三方UI库集成指南Formily扩展组件第三方UI库集成指南 在现代前端开发中表单是用户交互的核心组件之一。然而不同项目可能采用不同的UI组件库如何将这些UI库与Form前端UI组件LoopBack与Express集成如何扩展现有Express应用的完整指南LoopBack与Express集成如何扩展现有Express应用的完整指南 LoopBack是一个强大的开源Node.js框架它能够轻松构建需要复杂集成的后端Web框架API设计Tunasync多数据库后端支持Bolt、Badger、Redis、LevelDB对比分析Tunasync多数据库后端支持Bolt、Badger、Redis、LevelDB对比分析 Tunasync作为一款强大的镜像任务管理工具提供了多种数据库后上一篇3步掌握Fooocus让AI图像生成变得像说话一样简单下一篇pgmpy性能优化利用Torch后端加速大规模网络推断创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考