GPT使用实例:分析如何通过iVX来开发低代码平台(NocoBase)

协同平台前端技术全景(九):低代码表单与流程引擎 某装备制造企业协同平台采用双引擎低代码架构:VForm3(本地UMD包)实现动态表单,自研EasyProcess管理审批流程,二者通过formFieldData无缝联动。表单模板可配置、无需发版,真正实现“改表单不改代码”,显著提升业务响应效率。 阅读详情

给GPT提供的基础文档列表

NocoBase相关文档:

  1. https://docs-cn.nocobase.com/welcome/how NocoBase 如何工作
  2. https://docs-cn.nocobase.com/development/server/collections 参考《数据表和字段》
  3. https://docs-cn.nocobase.com/development/server/resources-actions 参考《资源与操作》
  4. https://docs-cn.nocobase.com/development/client/ui-schema/what-is-ui-schema参考《UI Schema》
  5. https://github.com/nocobase/nocobase/tree/main/.github github相关代码

iVX相关文档:

  1. 文档中心-iVX官网 iVX简介

设置GPT的“Custom Instructions”

iVX概念:

iVX是一种通用图形化的编程语言,并配套开发了完整的“IDE”和工具链。iVX的核心思想是“面向组件编程”,并通过“图形化逻辑编排”将各种组件连接起来,形成应用的完整逻辑,并最终通过编译器/解释器生成应用前后台完整代码(可独立编译)。在组件足够丰富的情况下,这种方式既保证了整个应用可以“无代码”开发,又可以生成“指定语言/框架”的代码,并且根据不同用户的需求,用户可以选择在开发过程中是否使用“代码”或“SDK”,这种高度灵活性,对“不懂代码的编程学习者”和“懂代码的程序员”都非常友好。

前端可以选择生成vue或react框架代码,后台生成Java SpringBoot框架代码。

iVX IDE的基本结构:

iVX IDE包括“组件面板”、“属性面板”、“对象树面板”、“事件面板”、“数据流面板”、“导航栏”、“菜单栏”、“舞台辅助配置栏”、“逻辑组件栏”。

所有添加的组件都会被作为对象添加到对象树面板中,并实例化,例如Page,以及Page下面容器,容器内的元素等等。任何组件都是对象化设计,因此都包括“属性”、“触发条件”、“方法/函数”这三部分。在对象树中,任何对象的后面都可以添加一个“事件”组件,点击这个“事件”组件,会打开一个“事件面板”,在这个面板中包含“条件块”、“动作块”、“循环块”,通过面板块的组合可以实现图灵完备的逻辑表达;通常都是基于触发的逻辑,例如A对象发生了什么操作(即出发条件),B对象执行一个什么函数(Function),其中B可能包含A。“事件面板”可以完成多层的“条件块”、“动作块”、“循环块”的添加,因此灵活性和代码类似,只是去掉了代码中的语法部分。

还有一种有面板的组件叫“数据流”组件,这种组件配搭一个“数据流面板”,这个面板包括“开始节点”、“结束节点”、“对象节点”、“函数节点”、“条件节点”、“循环节点”、“事件节点(这个是数据流面板内部节点)”等。整个数据流图是一个有向无环图,数据在节点之间进行流动,一个节点的出参(流出数据output)正好是下一个连线节点的入参(流入数据input)这个过程也和面向函数编程类似,一个函数的出参正好是下一个调用函数的入参;一个结点output数据输出到多个结点作为input。

iVX的组件:(iVX IDE的另外一个特点就是“面向组件编程”,所以设计了海量的组件1000+)

iVX前端组件,包括各种“可视组件”按钮、图片、视频等等;“容器组件”;“变量组件”;“通信组件”,包括API、Socket、mqtt等;“Canvas组件”;“第三方接口”、AI组件...

iVX后台组件,把云计算的产品都封装成标准组件,包括各种数据库、MQ、Redis、中间件、定时服务、第三方接口、AI模型后台组件...

iVX IDE采用“面向组件编程”的设计思想:相对于“代码Code编程”,“面向组件编程”站在一个更高的维度(比组件高一个维度),而又可以很好的隔离代码,帮助不懂代码的人快速学习编程。

iVX IDE中组件设计:

每个组件都实现了面向对象的封装,包括“触发条件”、“属性”、“函数”三个部分,这样就可以通过事件面板结合组件对象,实现完整的应用逻辑的构建和表达。

iVX对开发人员友好,支持前后台直接嵌入代码、支持上传Java/Python/Node.js/Android SDK;支持手写SQL、CSS、HTML代码;支持上传npm包;支持各种前端库导入,例如elementUI等。

相比传统编程语言,iVX学习更容易、开发更快、维护更方便、也具备很高的代码质量。

GPT可以开始工作了

(使用4o模型由于上传了图片附件,不能使用o1)

用中文回答:

  1. NocoBase本身能生成代码吗?它和其它低代码平台有什么区别吗?它的主要优势有哪些?

NocoBase本身不能直接生成传统意义上的代码(如Java、Python等),它更多是通过插件和微内核的架构来定义应用的生命周期,并在前端以可视化的方式构建业务逻辑。和其他低代码平台相比,NocoBase最大的不同在于它的微内核架构和插件化设计。通过插件化的方式,NocoBase能够灵活扩展功能,降低模块之间的耦合度,这使得其具备了很强的定制化能力。用户可以通过自定义插件来扩展数据模型、HTTP API、界面组件等多种功能。

NocoBase的主要优势包括:

  • 插件化设计:几乎所有功能都可以通过插件实现,灵活扩展。
  • 易于二次开发:它开放了多个层次的接口,从数据模型、HTTP API 到前端界面,开发者可以方便地进行扩展。
  • 无代码/低代码融合:即便是无代码用户,也能通过图形化界面实现复杂的业务逻辑,而有技术背景的开发者则可以通过插件和自定义逻辑进行更深入的开发。
  1. NocoBase的主要的潜在问题有哪些?

    1. 扩展的复杂性:虽然插件化设计带来了高度的灵活性,但对于不具备一定开发经验的用户来说,过多的定制化可能会增加复杂度,学习曲线较高。
    2. 性能瓶颈:在处理大规模数据或者复杂业务逻辑时,如何保证系统的性能和响应速度可能成为一个问题。
    3. 插件兼容性:随着插件的扩展和不同开发者的参与,插件之间的兼容性和版本控制也可能会引发一些问题。
    4. 安全性:开放式架构和丰富的插件化接口在带来灵活性的同时,也可能带来安全隐患,需要格外注意权限控制和接口安全。
  2. NocoBase的workflows是使用现成的开源产品还是他们团队自行研发的?

NocoBase的workflow配置文件主要依赖于GitHub Actions,这是一个非常常见且广泛使用的开源产品,用于自动化构建、测试和部署流程。从配置文件中可以看到,它使用了多种GitHub Actions的标准操作,如actions/checkout、actions/setup-node、actions/upload-artifact等。整体来看,这些工作流主要是基于开源的GitHub Actions进行自动化配置和执行,而非NocoBase团队自行研发的。

  1. NocoBase如果都是采用workflows的模式来实现业务逻辑,是否会造成运行效率降低?是否存在明显瓶颈?

采用workflows来实现业务逻辑,在某些场景下确实可能导致效率的降低,特别是对于高度实时性或高频繁交互的系统,使用基于工作流的模式可能无法满足性能要求。工作流编排和触发的过程往往需要依赖一系列的事件调度和状态存储,这可能在处理复杂业务逻辑时增加系统的响应时间。

潜在的瓶颈包括:

  • 延迟:由于工作流依赖事件触发和流程编排,复杂的流程可能导致响应时间延长。
  • 资源消耗:频繁的工作流执行可能导致更多的系统资源消耗,尤其是涉及外部API调用或数据处理的任务。
  • 并发限制:如果大量任务同时触发工作流,系统的并发处理能力可能成为瓶颈,尤其是在数据库查询或写入操作较多的场景下。

总的来说,工作流的灵活性和可扩展性适合处理复杂、低频的业务场景,但对于实时性要求高的场景可能并不是最佳选择。

  1. NocoBase更像是一个完整的应用,只是这个应用比较灵活,容易扩展,本质还是一个应用的完整实现,这种理解对吗?

是的,你的理解是正确的。NocoBase确实是一个功能完整的应用程序,它的核心功能是通过插件化和微内核架构实现的。虽然它具备了较强的扩展性和灵活性,但它的核心依然是一个带有前后端界面的应用程序。用户可以通过配置和扩展来实现特定的业务需求,但这些功能都是基于NocoBase的基础架构和业务逻辑框架之上的。

与之相比,iVX则是一个图形化编程的IDE,它的主要目标是生成完整的前后端代码。通过iVX,用户可以使用可视化的方式设计和生成不同的应用,iVX并不是一个预设的应用,而是一个用于创建和定制应用的工具。因此,iVX与NocoBase有很大的不同,iVX的重点在于提供一个灵活的编程平台来生成代码,而不是一个业务应用的框架。

  1. 通过iVX来开发一个类似NocoBase的应用,现有iVX组件如何在NocoBase上重用?引入iVX的数据流和事件面板是否合理?

使用iVX开发一个类似NocoBase的应用是可行的,而且引入iVX的数据流和事件面板可能会大大增强应用的灵活性和运行效率。iVX的数据流面板和事件面板是面向图形化编程的强大工具,能够用直观的方式编排逻辑,生成直接可执行的代码。这比NocoBase基于工作流的逻辑编排方式在效率上可能更高,因为iVX是直接生成并运行代码,而不是依赖事件触发器和状态管理来进行流程控制。

如果在NocoBase的架构中引入iVX的这些功能,可以让NocoBase的业务逻辑实现更加高效和灵活,特别是在涉及复杂的数据流处理和实时逻辑编排时,iVX的数据流和事件面板可以帮助降低复杂度并提高性能。

合理性分析:

  • 性能提升:iVX直接生成代码的机制比基于工作流的运行方式更高效,可以减少事件调度和状态管理的开销。
  • 灵活性增强:iVX的图形化逻辑编排使得开发者能够以更直观的方式设计复杂业务流程,这会大大提升系统的可维护性和扩展性。
  • 重用现有组件:iVX现有的前后端组件可以封装成NocoBase的插件或扩展模块,通过插件化的方式重用这些组件也是非常合理的方式。

7.如果用NocoBase开发各种不同的应用或系统,这些应用和系统需要同时运行吗?

  1. 在NocoBase中,不同的应用或系统是可以通过插件和微服务的方式来扩展和运行的。这意味着理论上你可以在同一个NocoBase实例中同时运行多个应用或系统,尤其是当这些应用之间有相同的基础需求时,比如数据表管理、权限控制等通用模块。
  2. 需要同时运行吗? 具体取决于业务需求。如果这些应用之间有数据共享或工作流相互关联的需求,那么可能需要同时运行。但如果这些应用是完全独立的,那么它们可以分别运行,不需要完全同步。

8.不同应用和系统之间会有相互影响和干扰吗?

NocoBase通过插件和数据模型来管理不同的应用逻辑,因此理论上不同的应用可以做到相互隔离,尤其是在数据表和业务逻辑层次上有清晰的边界时。插件系统可以确保不同应用之间的逻辑分离,这样就能减少应用间的相互干扰。

可能的相互影响:

    1. 如果不同应用使用的是共享的数据源,或者存在跨应用的数据依赖,那么可能会有数据层面的相互影响。
    2. 如果工作流或事件处理逻辑被错误配置,多个应用的流程可能会互相干扰。

解决这些问题的关键是确保数据模型和业务逻辑的隔离,同时通过合理的权限控制和工作流管理避免冲突。

系统消耗和性能: 如果在一个NocoBase实例中运行多个复杂应用,同时加载大量插件和工作流处理逻辑,确实可能导致较高的系统消耗,尤其是在数据库查询、工作流调度等方面。

    1. 资源占用:工作流、数据表、业务逻辑等会占用数据库和内存资源,过多的并发处理可能会影响性能。
    2. 性能影响:如果所有应用都需要频繁地处理复杂的业务逻辑和大量数据请求,NocoBase的性能可能会受到影响,尤其是在高并发情况下。

如上所述,NocoBase通过插件化架构运行多个应用是可行的,但如果同时运行大量应用,特别是涉及复杂的数据处理和业务逻辑,可能会产生性能瓶颈。例如,工作流调度、数据库查询的效率可能会降低,尤其是在高并发或大数据量的情况下。

9.由于不能生成代码,多个无关应用可能需要购买或搭建两套/多套NocoBase系统的问题

如果你在企业内部需要开发完全不相关的应用,NocoBase在这方面的表现会受到限制,因为它的架构设计是共享数据和服务框架的。在以下几种情况下,你可能会考虑搭建多套NocoBase系统:

应用之间没有关联:如果开发的应用之间完全没有任何业务关联(数据模型和逻辑都不同),且这些应用需要完全独立的管理和运行环境,那么是的,可能需要购买或搭建两套NocoBase系统来避免相互干扰。

  • 比如一个应用是企业内部的客户管理系统,另一个应用是供应链管理系统,它们的数据模型、业务逻辑完全不相关,分别由不同的部门或团队维护。此时,如果将它们强行集成到同一个NocoBase实例中,可能会带来不必要的复杂性和风险,如权限管理、数据隔离等问题。
  • 避免系统资源竞争:由于NocoBase是基于插件化架构运行的,如果在一个实例上运行多个完全不同的应用,虽然可以通过插件实现功能的独立,但共享资源(如数据库、服务等)可能会导致资源竞争问题,影响应用的性能。为此,搭建多套NocoBase系统可以确保每个应用有独立的资源池,避免资源争夺。

解决方案的选择:

  • 多实例部署:如果企业需要开发多个完全不相关的应用,建议可以部署多个NocoBase实例。每个实例可以专注于一个或一类相关的应用,这样可以减少应用之间的相互干扰,同时提升管理的便捷性。尽管这可能会增加一些部署和运维成本,但能确保应用的独立性和稳定性。
  • 考虑其他技术方案:如果企业需要实现生成代码的能力,可以考虑结合NocoBase与其他平台,如iVX这样的代码生成平台。iVX可以用来生成具体的应用代码,而NocoBase负责实现无代码/低代码的管理功能。如果通过iVX生成的代码与NocoBase的插件系统能良好集成,企业就能在不搭建多套系统的前提下,得到更多的灵活性。

通过iVX来开发一个类似NocoBase的应用,现有iVX组件如何在NocoBase上重用?引入iVX的数据流和事件面板是否合理?

使用iVX开发一个类似NocoBase的应用是可行的,而且引入iVX的数据流和事件面板可能会大大增强应用的灵活性和运行效率。iVX的数据流面板和事件面板是面向图形化编程的强大工具,能够用直观的方式编排逻辑,生成直接可执行的代码。这比NocoBase基于工作流的逻辑编排方式在效率上可能更高,因为iVX是直接生成并运行代码,而不是依赖事件触发器和状态管理来进行流程控制。

如果在NocoBase的架构中引入iVX的这些功能,可以让NocoBase的业务逻辑实现更加高效和灵活,特别是在涉及复杂的数据流处理和实时逻辑编排时,iVX的数据流和事件面板可以帮助降低复杂度并提高性能。

合理性分析:

  • 性能提升:iVX直接生成代码的机制比基于工作流的运行方式更高效,可以减少事件调度和状态管理的开销。
  • 灵活性增强:iVX的图形化逻辑编排使得开发者能够以更直观的方式设计复杂业务流程,这会大大提升系统的可维护性和扩展性。
  • 重用现有组件:iVX现有的前后端组件可以封装成NocoBase的插件或扩展模块,通过插件化的方式重用这些组件也是非常合理的方式。

因此,如果通过iVX开发一个类似NocoBase的系统,并引入iVX的数据流和事件面板,能够充分利用iVX的图形化逻辑设计能力,同时实现更高效的业务逻辑处理,这是一种非常合理且可行的做法。

总结一下

  1. 低代码平台本身存在一些“原生问题”,例如:只能通过“工作流”来控制逻辑,而不是直接生成代码(性能问题);例如:多个大量应用或不同属性应用的兼容问题和重复部署问题;例如:前端和后台需要代码扩展问题(功能本身限制问题)。
  2. 通过iVX开发一个类似Nocobase这样的低代码平台,完全可行,而且性能和使用效率都会有明显提升。
基于 SpringAI 整合 DeepSeek 模型实现 AI 聊天对话 很多云平台都提供了一键部署大模型的功能,这里不再赘述(阿里云百炼平台、火山方舟-火山引擎等)Ollama。 阅读详情

相关推荐

信号完整性分析学习--16--传输线效应

传输线效应 说到传输线效应,大多数人都会想到一个经验法则,那就是: “当互连线的长度大于1/6倍的信号上升时间的空间延伸时,互连线就体现出传输线效应。” 上升时间越小越容易体现传输线效应。 由此可见,同一根互连线,它是否体现传输线效应,要看它要传输什么样的信号。下图所示,一根延时为15ps的互连线,当它传输上升时间为60ps的信号时就会体现传输线效应;当它传输上升时间为180ps的信号时就不体现传输线效应。

qq_29476769的博客 7272

记录nocobase的部署、搭建及其插件开发技巧

Nocobase 开发常见问题与插件开发指南 摘要:本文总结了 Nocobase 开发中的两个常见问题:1) MySQL 5.6 版本需使用 Docker 部署时遇到的 yarn install 问题;2) 版本不匹配导致的编译问题,强调必须严格对应官方要求的 MySQL、Node.js 和 Yarn 版本。同时提供了插件开发的基本步骤:创建插件、处理 yarn.lock 文件、编写 API 接口代码。文中还展示了一个自定义 API 接口的示例代码,包括权限开放设置和请求处理逻辑,最后给出了访问接口的 UR

化州陈陆亮 1642

告别黑窗口:XShell+X11转发图形化界面的5分钟保姆级教程(附Xming配置)

本文详细介绍了如何使用XShell和X11转发技术快速实现Linux图形化界面的远程访问。通过5分钟快速配置指南,包括服务端设置、客户端工具选择及XShell+Xming的完美配置,帮助用户高效运行GUI应用程序,提升远程工作效率。特别适合需要图形化操作的开发者和运维人员。

weixin_29223603的博客 326

新客户入场 7 天实施计划:从环境落地到验收移交的每日清单驰骋BPM驰骋低代码低代码工作流引擎

把「个人跑通 Demo」延伸成「团队 7 天落地」:D1 环境与组织、D2 表单、D3 极简流程、D4 权限与消息、D5 集成联调、D6 生产部署与版本锁定、D7 验收移交,每天有目标、有交付物、有验收标准。

开源驰骋工作流引擎 166

Docker部署FRP实现内网穿透

FRP是一款开源内网穿透工具,通过在公网服务器部署服务端(FRPS),内网设备运行客户端(FRPC)实现外部访问。支持TCP、UDP、HTTP等多种协议。部署时需配置服务端(如群晖NAS使用Docker)和客户端(如Windows下载可执行文件)。服务端需设置监听端口、控制面板及Token认证,客户端需指定服务器地址和相同Token。完成配置后可通过公网IP或域名访问内网资源,并在控制面板监控连接状态。

波哥技术栈 1599

网络调试和分析工具 Proxyman Premium

它支持MacOS、iOS和iPadOS等操作系统,提供丰富的功能,如查看和编辑HTTP/HTTPS请求和响应、设置断点、过滤请求等。Proxyman Premium还支持WebSocket、GraphQL和gRPC等现代网络协议调试,并通过直观且图形化的操作界面,使用户能高效地监控和操纵网络数据流。此外,它还具备多种高级功能,如WebSocket支持、DNS欺骗、自定义SSL证书等,为开发人员提供极大的便利。同时,由于软件版本更新和界面调整,上述步骤可能会有所变化,建议您参考最新版本的官方文档进行操作。

llhf688的博客 1997

实体类管理系统如何诊断:两条特征与状态的多维性驰骋BPM驰骋低代码低代码工作流引擎

人力资源、固定资产、车辆管理这类系统与交付类系统的形状完全不同:业务围绕一条记录发生,记录本身长期存在,同时还要围绕实体集合做查询、统计与批处理。本文给出实体类管理的两条特征、一套五问清单,以及实体状态在时间点上一维、在不同管理视角下多维的处理方式。

开源驰骋工作流引擎 166

SAP FICO 内部往来对账功能开发说明书(包括测试样例、程序代码仅作参考,不保证一定可以运行)

SAP FICO 内部往来对账功能开发说明书(包括开发源代码、测试样例、FS)

我好像病了的博客 1223

实体流程 GPE_FlowEntity 设计方案:流程与业务实体的五种关系驰骋BPM驰骋低代码低代码工作流引擎

流程与业务实体的关系可以归纳为五种:独立、多实例、单实例、新增、修改。本文记录这套关系的配置存储设计、领域类职责、引擎挂点时机与三端同步约束。

开源驰骋工作流引擎 167

16、天文时间序列分类:基于人工神经网络的研究

本研究探讨了基于人工神经网络的天文时间序列分类方法,重点比较了MLP、LSTM和CNN等模型在BRITE和开普勒K2数据集上的表现。研究发现LSTM不适用于此类数据,而结合特征提取与PSO超参数优化的多层感知器(MLP)在开普勒K2数据上实现了98.55%的二分类准确率。通过精细的数据预处理和高置信度样本选择,显著提升了分类性能。研究成果为恒星变异性识别提供了高效工具,并对天文学与机器学习交叉领域具有重要参考价值。

pz8901234的博客 112

AutosarMCAL开发——基于EB MCU驱动

本文为博主个人学习总结记录,如有不正,欢迎指正。

qq_45583706的博客 920

生产环境版本锁定与升级 SOP:从 Ver 号对账到回滚预案驰骋BPM驰骋低代码低代码工作流引擎

把「版本一直在更新」这件事拆成可执行的运维规范:以 Ver 号与 commit 锁定版本、dev 到 prod 逐级晋级、备份后升级、验证后观察,以及不可逆变更下的回滚预案。

开源驰骋工作流引擎 183

Python APP反爬实战:Frida+Charles抓包,破解签名校验

Charles抓包定位参数 → jadx-gui反编译找函数 → Frida Hook拿密钥/规则 → Python还原签名算法;Frida的核心价值:Hook住APP的加密函数,拿到“输入(密钥/参数)+输出(签名)”,无需懂复杂的逆向底层;严格对齐APP的参数排序、拼接规则、加密算法,差一点都会验证失败。

专注于Python爬虫开发,分享爬虫技巧、项目实战与反爬经验,使用Scrapy、BeautifulSoup等工具,解决数据抓取难题。 1535

实体类管理系统万能公式:定对象、定状态、列业务驰骋BPM驰骋低代码低代码工作流引擎

实体类系统的设计可以归纳为三步:先确认要管理的对象并按规范补齐六个必要属性,再确定这个对象一生会经历哪几个状态,最后理清每个状态下可以发生哪些业务,形成状态与业务的矩阵。实现手段在流程、实体方法、通用组件三者之间按规矩轻重取舍,并补齐查询、权限与报表等集合能力。

开源驰骋工作流引擎 99

复分析 阿尔福斯(Ahlfors) 第三版答案 英文

答案分为十章,有部分习题没有答案,全英文复分析阿尔福斯(Ahlfors) 第三版答案

Devexpress16.2.6破解工具

Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具

RAG-FastGPT安装

今天开始学习RAG安装,选择FastGPT,环境是Windows 11。

w8827130的博客 89

精雕软件(JDpaint) 5.5 绿色版

精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版

Spring AI + GPT-5.5 + Ollama 配置教程:Base URL、超时与流式调用

由于不同 Spring AI、Spring Boot 小版本之间仍可能存在差异,创建项目时应检查 Spring Initializr、Spring AI BOM 和官方兼容矩阵,不要直接复制旧教程中的 Starter 名称和版本号。多人项目最好隔离不同客户端,并在脱敏前提下记录最终 URL、状态码、请求耗时、请求 ID 和模型 ID。Spring AI 接入模型 API,至少要同时确认 Starter、Base URL、请求路径、API Key、模型 ID、连接超时、读取超时和流式客户端这 8 项。

2601_95893075的博客 223

蓝牙模块HM-10手册

蓝牙模块HM-10手册,该手册对蓝牙模块HM-10进行了详细的介绍和使用方法以及一些AT指令。

GPT Image 2.6 的 Flare 与 Sunburst:双版本怎么分工,附一套迁移回归测试

GPT Image 2.6 在 11 月 4 日上线,API 里多了 Flare 和 Sunburst 两个变体。Flare 走速度与布局,Sunburst 走画质与多轮编辑一致性。这篇讲清三个新参数的用法边界,并附一套两三个小时能跑完的迁移回归测试:四类 case、五项打分、5 次里 4 次过前三项才算可用。

weixin_47592901的博客 352

GPT Image 2.6 编辑验收实战:保留项清单、接口骨架与排错流程

> 本文由 AceDataCloud 来源文章改编并经 AI 辅助整理。示例使用占位凭据;具体参数、计费、权限和区域可用性以当前模型目录与接口文档为准。 “接口返回了一张图”不等于编辑成功。对商品图和内容素材来说,真正困难的是判断:模型是否只改了该改的部分,原来已经正确的商品结构、文字和光影有没有被破坏。 ![纸面标注需要修改的位置](https://i-blog.csdnimg.cn/dir

jakeycis123的博客 232

OpenAI 公开物理工程加速:Astra/GPT‑6 一周设计 Codex 对话设备,BenchCAD 内部模型 0.875 vs Astra 0.594

OpenAI 官方博文(2026-11-03)《Accelerating engineering for the physical world》分享模型如何帮助工程师设计、仿真与制造物理产品。重点:用 Astra(多模态+computer use)与 GPT‑6 端到端设计可对话 Codex 的测试设备,两人侧项目约一周、合同制造商约一个月内小批量原型;量产就绪仍需多轮人工审阅。自 February 起硬件团队 token 用量增 23-fold。

weixin_49016065的博客 154

OpenAI 11月4日发布 GPT Image 2.6:原生直出 SVG/GIF、涂鸦精准修图

OpenAI 于11月4日正式推出 GPT Image 2.6(ChatGPT Images 2.6),带来 sunburst 和 flare 双模型矩阵。本次更新不仅彻底打通了原生 SVG 矢量图 与 GIF 动图 生成,还上线了颠覆性的 Markup(标记引导)修图功能 和 complexity 规划深度控制。

蓝星空的专栏 172

GPT-6 Cyber 正式发布——以子之矛,攻子之盾

已经被AI攻破,人脸识别可能要“失业”了给WorkBuddy接上LibTV,直接解锁专业AI视频创作!还能搭建自动化视频工厂GPT-Image-2.6全量上线!直出GIF和SVG,6.2 Astra也即将现身等等各种AI消息层出不穷,已经追不上AI了。学不完,根本学不完…今天我们要讲一点不一样的,有关AI安全,强大的矛盾关系。大家好!我是天府云创.直接开讲!

Enweitech Software Works 176

GPT-6.1 Terra是什么?gpt-6.1-terra API实测:视觉理解、电脑操作、写作与JSON输出

GPT-6.1 Terra把视觉理解、界面操作、写作和结构化输出放在同一个快速模型中。它能读懂截图里的文字与控件位置,能把界面任务拆成带校验的动作序列,也能按要求生成文案并输出固定格式的数据。对于内容、运营和自动化类应用,它是值得优先评估的一档;复杂编程和高风险的端到端执行,则应与GPT-6.1 Sol或GPT-6 Astra对照后再决定。

2601_96207100的博客 379

zeekeai怎么用GPT-6.1 Sol做教学大纲?

本文介绍如何通过ZEEKEAI平台整合GPT-6.1 Sol等多模型,实现教学大纲的高效生成。采用“文献提炼—结构化输出—配图生成”的工程化工作流,结合五段式专家Prompt与三大场景模板,可快速产出逻辑严密、格式规范、符合学情的高质量大纲。强调格式层级、学时校验、知识点适切性及配图建议,避免常见翻车点。最终实现从“手工排版”到“智能提效”的教研跃迁,显著提升备课专业度与效率。

Xiaofeng3693的博客 471

GPT-6.1 Terra:Agent 开始比拼“谁更划算”

OpenAI 发布 GPT-6.1 Terra,主打更便宜、更快、更能看屏操作电脑。对 Agent 落地来说,旗舰能力之外,单位任务成本正在变成硬指标。

攻城狮7号的博客 2724

zeekeai上GPT-6.1 Sol生成政务公文怎么样

在体制内公文写作中,GPT-6.1 Sol 依托 zeekeai 多模型协同平台,实现格式规范、语言克制、逻辑严密的高效输出。实测显示,其在通知、讲话稿、调研报告等场景下表现卓越,配合 Claude 审核与 Gemini 提炼,构建“初稿生成—合规审查—重点提取”闭环流程。关键避坑指南包括禁用绝对化词汇、杜绝政策编造、严格层级格式,并强调“AI辅助,人工把关”的核心原则。成本低、效率高,真正实现政务公文从“苦差”到“利器”的转变。

Xiaofeng3693的博客 322

GPT Image 2.6 接入指南:Flare、Sunburst 怎么选,编辑失败如何排查

> 本文基于 AceDataCloud 原文改编,并由 AI 辅助整理,重点补充面向开发者的模型选择、接入流程与编辑排错思路。原文:[《GPT Image 2.6 正式发布:更快生成、更准编辑,AI 图像进入生产力时代》](https://platform.acedata.cloud/blog/gpt-image-2-6-launch-faster-generation-precise-editi

jakeycis123的博客 231
上一篇: 为什么说开源也不能解决低代码的核心问题
下一篇: 当前LLM生成代码的关键缺陷及iVX 图形化编程优势分析
Zero-code Fighter
博客等级 码龄7年 258粉丝 165原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值