基于AI Agent的ZCF API文档全链路自动化

「文智助手」全场景办公AI助理AI+OPC全流程实践方案(大赛作品) 阅读详情

(一)  前言

在云计算平台的生态建设中,API 是连接产品能力与开发者的核心纽带。一套准确、完整、及时更新的 API 文档,直接影响开发者的接入效率和使用体验。然而,随着平台功能的不断迭代,API 规模持续膨胀,文档维护的压力与日俱增——每次 API 的新增、变更或下线,都需要同步更新开发手册、CLI 参考和 API Explorer。面对大量接口持续变动,如何确保文档与代码一致、统一多种发布格式,并兼顾双语效率与质量,成为 API 文档工程化的核心挑战。

本文从 ZStack ZCF(ZStack Cloud Foundation)API 文档实践出发,围绕 API 文档多通道发布架构、基于 AI Agent 的全链路自动化设计思路、工程落地中的核心难题与攻克方案,向大家全面深入介绍 API 文档全链路自动化的建设实践。

(二)  ZCF API 文档的发布体系与挑战

ZStack Cloud Foundation(ZCF)是多产品能力深度融合的专有云方案,通过统一门户、统一运维、统一算力管理,提供友好、便捷的全栈管理体验。ZCF对外暴露丰富的 RESTful API 接口,涵盖计算、运维、监控告警等多个领域。

围绕 ZCF API,ZStack 建立了多通道、多格式的文档发布体系,以满足不同场景下的用户需求:

  • • PDF 手册:面向正式交付场景,提供中英双语版本,涵盖每个 API 的请求参数、返回字段、Curl 示例和 SDK 代码示例,适用于离线查阅和项目归档。

  • • HTML5 在线文档:面向日常开发场景,开发者可通过浏览器随时检索和浏览,快速定位所需接口。

  • • API Explorer:面向交互式开发场景,现已作为 ZSite 文档中心的 API 参考板块上线,提供全文搜索、分类导航、多语言代码示例,并支持版本变更标记(新增、修改、删除),帮助开发者直观感知 API 的演进。

  • • CLI 参考手册:面向运维和自动化场景,提供每个 API 对应的命令行调用方式与参数说明。

图片

图1. ZCF API 文档多通道发布体系示意图

这套发布体系的底层由两大数据源支撑。其一是 Swagger 规范文件(swagger.json),由后端开发团队随代码自动生成,是 API 接口定义的唯一可信源(Single Source of Truth),包含每个 API 的路径、方法、参数结构、响应模型等结构化元数据。其二是 DITA 结构化文档,作为 ZStack 文档体系的内容底座,以 XML 格式组织文本内容,通过 DITA-OT 工具编译为 PDF 和 HTML5 等目标格式。

在引入自动化之前,ZStack API 文档的更新高度依赖人工,这一模式存在四个突出痛点:

  • • 效率瓶颈:单次版本迭代涉及数十个 API 变更,仅 DITA 编写和翻译通常就需要一到两周甚至更长时间,难以匹配高频发布节奏。

  • • 一致性风险:文档依赖后端提供的 Markdown 参考,若与实际代码不一致,容易引入文档错误,导致开发者获取的信息相互矛盾。

  • • 质量波动:人工编写依赖个人经验,不同工程师产出的文档在结构规范、术语使用、翻译质量等方面参差不齐,缺乏统一的质量兜底机制。

  • • 交互友好性曾是短板:早期流程尚未纳入 API Explorer 功能,缺乏统一的在线交互式能力;随着 ZSite 文档中心和 API Explorer 上线,这一能力已进入用户可访问的在线文档入口。

面对数百个 API 接口的持续演进和多渠道同步发布的刚性要求,传统的人工模式已难以为继。如何从根本上打通从 Swagger 到终端用户的文档全链路,实现"接口一变、文档自动跟",成为亟待解决的工程命题。

(三)  基于 AI Agent 的全链路自动化设计思路

面对上述挑战,ZStack 从 AI Agent 的视角重新审视 API 文档的生产流程:将文档工程师的手工操作拆解为可编排、可验证、可复现的自动化阶段,由 AI Agent 统一调度执行。不同于传统 CI/CD,AI Agent 具备语义理解能力,能够解析 Swagger 与 DITA 规范,在质量关卡进行通过/阻断判断,并以自然语言反馈各阶段执行情况。

整体架构采用"六阶段流水线"设计,以后端代码仓库中 swagger.json 的 Git 变更为驱动信号,依次完成从差异检测到终端发布的全链路自动化闭环。

图片

图2. 全链路自动化流水线架构图

1.  阶段一:差异检测与内容生成(Generate)

流水线以 Swagger 变更检测为起点,当后端代码仓库中的 swagger.json 发生 Git 提交时,系统自动获取变更前后的版本,对其进行深度语义比对——递归解析 $ref 引用和 allOf 组合,精确识别每个 API 操作的变更类型——新增、修改或删除,并输出结构化的变更清单。随后,针对每种变更类型执行不同的处理策略:新增操作自动生成完整的 DITA 主题文件(含请求参数表、返回字段表、Curl 示例和 SDK 代码示例),并将其插入中英双语的 Ditamap 目录;修改操作定位已有文件并原地重新生成内容;删除操作则同步清理文件与目录引用。

2.  阶段二:静态模拟验证(Test)

生成的 DITA 文件在此阶段接受"文档 vs 规范"的交叉校验。系统从 DITA 源文件中解析出 API 元数据,与 Swagger 规范中的原始定义进行七个维度的逐项比对:API 名称、请求路径、必填参数、请求体字段、Curl 示例、返回示例、SDK 示例。该阶段无需启动任何后端服务,完全基于静态分析完成,可在秒级返回每个 API 的验证结果。

3.  阶段三:规则化双语翻译(Translate)

经过验证的中文 DITA 文件在此阶段被翻译为英文版本。由于机器生成的 API 文档具有高度结构化、词汇封闭的特点,系统采用纯规则化的确定性翻译策略,通过九步字符串替换流水线完成中英转换——无需调用任何大语言模型。翻译完成后,系统自动扫描输出文件中是否残留未翻译的中文字符,作为翻译完整性的兜底审计。

4.  阶段四:质量门禁(Review)

质量门禁是整条流水线的核心关卡,也是唯一的"硬门禁"——任何一条错误级别的审查发现都将阻断流水线,防止问题内容进入后续的编译和发布环节。系统对中英双语文件同时执行 22 条编码化的质量规则,覆盖六大检查类别:文档结构完整性(S)、API 内容准确性(A)、标题规范性(T)、表头一致性(H)、行内标签正确性(L)、翻译质量(Q)。每条规则均为纯函数实现,输入文件内容与语言标识,输出结构化的检查发现——确保质量标准可追溯、可复现、不因人而异。

图片

图3. 质量门禁的六大检查类别示意图

5.  阶段五:双语编译发布(Build)

通过质量门禁后,系统分别编译中文和英文的 Ditamap,调用 DITA-OT 工具链生成 PDF 格式的开发手册。编译过程实时流式输出构建日志,并在完成后提取结构化结果(成功/失败、阻断性错误、警告信息、产物路径),供 Agent 解读和决策。

6.  阶段六:API Explorer 同步(Explorer)

最后一个阶段将变更同步至已上线的 API Explorer 平台。API Explorer 目前作为 ZSite 文档中心的一部分对外提供服务,入口为 https://docs.zstack.io/docs/api-explorer/zh-cn。 系统基于Swagger 差异生成变更清单(Change Manifest),然后重建 Explorer 所需的全套数据制品——包括每个 API 操作的详情文件、多语言代码示例、分类导航树、全文搜索索引等。新增和修改的 API 会被标记变更标签,已删除的 API 则以“近期删除”类别保留,确保开发者可感知接口的完整演进轨迹。

纵观整条流水线,以下四项设计原则贯穿始终:

  • • 增量驱动:以 Swagger 差异为唯一触发信号,仅处理发生变更的 API 操作,避免全量重建带来的资源浪费和不必要的文件变动。

  • • 报告链式传递:每个阶段输出标准化的 JSON 报告,下游阶段自动从上游报告中提取输入参数,实现松耦合与可独立调试。

  • • 确定性优先:六个阶段均基于确定性 Python 逻辑,保证相同输入得到一致输出,AI 仅参与编排与解读。

  • • 单一可信源:以 swagger.json 和 DITA Ditamap 为唯一信源,统一派生 PDF 与 API Explorer,消除多通道不一致。

(四)  ZCF API文档全链路自动化实际建设难题与攻克

1.  混合智能:AI 与确定性规则的策略性分工

在 API 文档自动化中,"翻译"是贯穿全链路的关键能力,但不同翻译对象的特性截然不同。API 名称要求严格一致——同一 operationId 必须稳定映射为一致的中文标题,否则会引发开发者困惑;而 API 描述属于自然语言,更强调流畅与语义准确。若统一交由大模型处理,名称易产生波动;若完全依赖规则,描述质量又难以保证。

为此,系统采取"确定性规则 + AI"的混合策略,按翻译对象的特性精准匹配技术手段。对于 API 名称翻译,自研结构化语义解析引擎:首先维护 570+ 条精确覆写映射,处理不规则命名;未命中时将 operationId 按 PascalCase 拆解,依次进行动词识别、By{Scope} 模式检测,以及 4→3→2→1 级短语匹配,生成结构化中文标题,整个过程为确定性计算,保证输入输出一致。同时,API 描述翻译则交由大语言模型批量处理,并通过术语约束与字数限制(≤60 字符)控制质量。

此外,在阶段三的中英翻译中同样贯彻了"确定性优先"原则。由于机器生成的 API 文档词汇集合是封闭的,系统通过九步字符串替换流水线完成全部翻译,并在末尾以 Unicode 范围扫描审计残留中文字符——若未来生成器引入新词汇而翻译表未同步更新,审计机制会自动报警,而非静默产出漏翻内容。

图片

图4. API 名称翻译的结构化语义解析流程

2.  复杂 Swagger 规范的深度语义解析

Swagger/OpenAPI 规范在理论上是结构清晰的接口描述标准,但在实际工程中,由后端框架自动生成的 swagger.json 往往存在大量边界情况。ZCF 大量 API 操作涉及复杂的数据模型嵌套,系统在解析过程中面临三类典型挑战。

  • • 循环引用问题: 部分数据模型通过 $ref 形成环状依赖。系统在递归解析中引入“已访问引用集合”,检测到重复即终止,避免无限展开。

  • • allOf 组合模式: 多个 Schema 通过 allOf 继承时,简单合并会丢失约束。系统采用深度合并:required 去重并集,properties 递归合并,确保约束完整保留。

  • • 异常描述文本: 部分描述为拼接字段名(如 alertintegrationplatformuuid)。系统通过正则识别后跳过直译,将字段按驼峰规则拆分并结合术语表翻译,生成可读描述。

3.  编码化质量门禁与多层验证闭环

在全自动化流水线中,如何确保产出的文档质量不低于人工编写水准,是最核心的信任问题。传统方案依赖人工评审,不仅耗时且标准因人而异。系统构建了三层递进式的自动化质量保障体系,将质量标准从"经验"转化为"代码"。

第一层是阶段二的静态模拟验证。基于 Swagger 与 DITA 进行七维交叉比对(名称、路径、参数、请求体、Curl、返回、SDK),无需启动服务即可发现偏差;请求体采用“参数表 + Curl”双源校验,覆盖不同生成方式。

第二层是阶段四的编码化质量门禁。22 条规则覆盖结构、内容、格式与翻译质量,以纯函数实现;中英文同轮审查,任一错误即阻断流水线,避免问题进入 PDF 构建。

第三层是面向运行时的文档-接口一致性验证。发布后将文档内容与实际运行的 API 服务进行比对,覆盖多个质量维度(如请求参数、响应结构、示例数据等),以运行时行为作为最终校验依据。三层验证层层递进:静态比对确保"文档与规范一致",编码化门禁确保"文档符合工程标准",运行时校验确保"文档与真实行为一致",共同构成从生成到发布的质量闭环。

此外,针对少数 Swagger Schema 本身定义错误的情况(如返回模型结构与实际 API 行为不符),系统预置了精确的 Schema 覆写补丁,在解析阶段即完成纠偏——将业务逻辑层的修正前移至数据源层,而非在下游生成环节反复打补丁。

(五)  ZCF API文档全链路自动化价值

1.  全流程自动化,显著提效

基于 AI Agent 的全链路自动化,将 API 文档的更新流程从"逐一比对、手工编写、分头翻译、分别构建"压缩为"后端提交 Swagger 变更,文档全链路自动跟进"。在实际工作流中,系统通过 Git 版本控制监测 Swagger 文件的变动,一旦检测到变更即自动触发后续全部阶段,全程无需人工介入。同时,增量驱动机制确保系统仅处理发生变更的 API 操作,而非全量重建,进一步提升处理效率。无论是日常的小版本迭代还是大规模的 API 变更,均可快速、稳定地完成全通道文档发布。

图片

图5. 流水线执行过程与阶段报告

图片

图6. 自动生成的 PDF 开发手册页面

图片

图7. API Explorer(已上线 ZSite 文档中心)

目前,ZSite 文档中心已正式上线,API Explorer 作为其中面向开发者的核心板块同步开放。用户可以在同一入口完成产品文档检索、API 分类浏览、关键字搜索、多语言代码示例查看与版本变更追踪,从“查产品文档”自然延伸到“查接口、看示例、理解变更”。查看ZStack API Explorer,请访问https://docs.zstack.io/docs/api-explorer/zh-cn;更多产品文档,欢迎访问:https://docs.zstack.io/zh。

2.  质量可控、标准统一

平台将文档质量标准从"依赖个人经验的主观判断"转化为"22 条编码化规则的自动执行",确保每一份产出的文档都经过相同尺度的严格审查。中英双语文件在同一轮检查中同时受审,任何错误级别的发现自动阻断流水线,从机制上杜绝不合规内容进入发布环节。同时,确定性的生成与翻译逻辑保证了可复现性——相同的 Swagger 输入,无论何时执行、由谁触发,始终产出完全一致的文档内容,彻底消除多人协作中的风格差异和质量波动。

(六)  结束语

API 文档的工程化演进,本质上是对"准确、及时、一致"这一质量三角的持续追求。ZStack 文档团队通过引入 AI Agent 作为编排引擎,将 Swagger 规范变更到多通道文档发布的全链路打通为一条自动化流水线,在效率与质量之间找到了可持续的平衡点。这一实践验证了"AI 与确定性工程互补"的技术路线——让 AI 发挥其在语义理解和智能决策上的优势,同时让确定性规则守住一致性和可复现性的底线。

未来,我们将持续探索 AI 在文档工程领域的更多可能,也期待与业界同行共同推动这一方向的发展。

船载 OpenHarmony AIS 航海工作台:告警与防碰撞预警系统 船载OpenHarmony AIS航海工作台的告警与防碰撞系统,集成十余类告警(超速、偏航、会遇、SOS等),通过网格空间索引实现高效邻近判定,保障实时性。告警管理器统一调度规则、去重、通知与日志,支持悬浮球、语音、跑马灯、弹窗多渠道触达,确保航行安全。SOS紧急通道独立运行,避免干扰。系统设计强调性能优化与多场景适配,为航海安全提供核心支撑。 阅读详情

相关推荐

ThingsBoard - 设备接入

设备接入笔记

qq_53839898的博客 1456

视频隐私脱敏工程化:CSRT/KCF追踪算法在本地推理中的实现与边界

在短视频内容合规审查中,动态遮挡(Dynamic Masking)是高频且高耗时的环节。传统手动关键帧打码不仅效率低下,且在目标快速移动或遮挡时极易出现遮罩漂移。本文从计算机视觉工程角度,解析基于CSRT与KCF算法的目标追踪方案在视频隐私处理中的技术路径、性能权衡及落地实践。

Mysssone的博客 384

网课、网页视频倍速播放简单脚本

一个简单的网页视频倍速脚本

huazn612的博客 1万+

AI 问数真的能替代 BI 报表吗?

AI问数赋能自然语言查询,提升临时分析效率,但无法替代传统报表。报表适用于稳定输出与持续监控,AI则擅长探索性提问。企业用好AI问数,关键在于夯实数据模型、统一指标口径、健全权限体系与结果校验机制。合理组合报表、仪表板与AI,才能实现高效、准确的业务洞察。

葡萄城技术团队博客 304

Unity Spine 3.8 (URP) 踩坑(Shader报错修改)

提供了新思路,打算尝试一下URP。但美术使用的spine版本是3.8,项目用的Unity2021.3.11f1c2,直接导入spine URP包,shader报错:half4 不能转成 SurfaceData2D;Spine-Sprite-StandardPass-URP-2D.hlsl 也报这个错,也是同样的改法即可。今天搜索spine优化,看到一篇文章。

hrlr1230的博客 4570

VS2022错误列表高效处理:从复制到Excel表格的完整指南

本文详细介绍了在Visual Studio 2022中高效处理错误列表的实用技巧,重点讲解了如何将错误信息一键复制并粘贴到Excel表格中。通过基础操作、自定义视图、筛选功能及常见问题解决方案,帮助开发者将杂乱的编译错误整理成清晰、可排序、可筛选的数据表,极大提升了团队协作、错误分析和项目管理的效率。

weixin_28837817的博客 362

AI Agent之核心框架

A: 显式 Thought 有三类价值:可解释性(便于人类审计)、可调试性(定位哪一步选错工具)、学习信号(可做监督微调或评估中间步骤质量)。ReAct 把推理与 可执行行动 绑定,每一步行动后都有 真实 Observation 反馈,从而用工具结果约束生成,降低闭卷幻觉。做完不等于结束——还要 评估做得好不好,把 教训 记下来,下次 带着教训重试,反思作为 记忆,影响后续尝试的策略。工作流程:Action → Evaluation → Reflection → Retry。A: 普通 CoT 只在。

剑雨巍巍的博客 267

脱壳--02.exe

程序开始 使用OD打开程序 发现无法利用esp定律 程序直接运行 查找模块间调用 随便找到一个函数的调用 发现是FF15方式调用 所以是vs的程序 vs程序大致分成两种 vs20xx (特征函数:GetSystemTimeAsFileTime)和 vc++6.0(特征函数:GetVersion) 通过链接器版本 发现是vc6.0 直接在GetVersion上下断点 重新运行程序 断点断下 返回到调用处 vc6.0和易语言的第一个CALL都是GetVers...

weixin_45012273的博客 1115

ChatGPT、Perplexity、Gemini 与 AI Overviews 引用对比:谁的引用更可信

AI 引擎的引用机制差异很大:ChatGPT 以行内引用加 Sources 列表呈现来源,Perplexity 几乎逐句可溯源,Gemini 在回答中内嵌相关来源链接,AI Overviews 则把多源聚合答案与来源列表一起放在搜索结果顶部。本文从引用透明度、来源偏好、可干预性 3 个维度对比这 4 个引擎,并给出 GEO 的 3 点启示,帮企业在多引擎环境下提升被引用的概率。

淡然一笑 的专栏 235

用Python实现古诗词填字游戏(三)

古诗词做填字游戏的第三部分代码,也是最核心的部分。实现对诗文和关键字的选定,并确定文字的输出位置。

PosPro的专栏 6119

EtherCAT主站SOEM -- 15 -- CIA402伺服驱动器子协议

以上就是EtherCAT主站SOEM – 15 – CIA402伺服驱动器子协议的内容。有不明白的地方欢迎留言;有建议欢迎留言,我后面编写文档好改进。创作不容,如果文档对您有帮助,记得给个赞。

常驻客栈的博客--嵌入式EtherCAT 2736

【从零理解 Spring AI · 12】MCP 的两种角色:做客户端还是做服务端

上一篇讲了 MCP 的概念:标准协议、三大角色、M+N 替代 M×N。

nice_lcj520的博客 581

NOTE: When using the `ipython kernel` entry point, Ctrl-C will not work.解决方案

本文主要介绍了NOTE: When using the `ipython kernel` entry point, Ctrl-C will not work.解决方案,希望能对使用jupyter notebook的同学们有所帮助。 文章目录 1. 问题描述 2. 解决方案

weixin_43178406的博客 11万+

AI 应用开发工程师技术实践:大模型接入、通用组件封装与性能优化

本文提出AI应用从PoC到生产的核心挑战:模型调用的持续可用、可控与可优化。通过构建统一LLM网关实现多供应商路由与故障转移,封装对话、工具调用与RAG组件以解耦业务逻辑,结合前缀缓存、批处理与流式背压治理等性能优化手段,形成“接通→接稳→接快”的工程路径,最终以工程化能力决定AI应用的生产可用性。

2301_79189962的博客 636

OV9734 DATASHEET,完整规格书

OV9734完整规格书,包括电气参数,尺寸规格,寄存器配置表等

Outlook Express 6 (OE6) for Win7/Win8/Win10

英文版 Outlook Express6.0, 兼容Win7/Win10/WinXP,解压就可用。

抽象主义人工智能和生命体AI的内在联系

彭军辉提出“抽象主义人工智能”作为第四大AI范式,批判符号主义、连接主义、行为主义剥离生命本体的误区,确立“智能是现象,生命是本体”的核心公理。主张原生智能必须依附具备存续诉求的生命本体,提出“生命体AI理论”,构建七层演化阶梯与自闭环工程框架,强调智能不可跳过底层存续机制直接模拟语言。该体系为生成式AI提供科学边界,推动从“仿真表象”向“原生智能”的范式跃迁,开辟硅基人工生命新赛道。

抽象主义人工智能和生命体AI 181

假人有限元模型

假人模型,车辆碰撞假人有限元模型,适合做乘员安全的研究者利用

OpenAI Control Room 架构拆解:给企业 AI Agent 加一套可审计的急停系统

OpenAI 公开了用于追踪和停止研究模型工作负载的 Control Room。本文拆解 job_id、推理前鉴权、35 秒撤销窗口与 Fail Closed 设计,并给出企业 AI Agent 急停控制面的数据模型、FastAPI 参考实现、缓存撤销策略和故障演练清单。

jerry764的博客 328

蓝牙模块HM-10手册

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

OpenClaw 深度调查:把 AI 助手做成你自己的控制平面

对 openclaw/openclaw 的完整技术尽调:Gateway 架构、Agent 运行时、工具与沙箱、30 个消息通道、181 个插件、安全信任边界、工程代价与采用建议。17 章 / 10 张图,全部数字标注口径,数据截至 2026-10-31。

厚积薄发 314

AI赋能智慧港口建设|造形家快速生成港口全要素三维场景

随着智慧港口、港口数字孪生项目的持续推进,港口三维场景的需求日益旺盛。传统港口三维建模,往往需要航拍倾斜摄影采集数据,再人工搭建吊机、岸桥、船舶、集装箱等大量工业设施模型,项目周期长、人力成本高,修改迭代繁琐,制约港口可视化项目落地效率。国产AI三维建模工具,依托卫星影像 AI 识别能力,无需航拍作业,一键快速搭建港口完整三维场景,为港口数字孪生、方案汇报、投标演示提供高效的场景解决方案。

m0_69539167的博客 66

从设备增点到治理闭环:老旧小区物业数智化落地实践

系统连接合同审批、银行流水、收费记录与项目台账,执行到期提醒、收入核验、异常标色和月度对账,让每一笔资金来源明确、去向可查。针对设施老旧、诉求响应慢、公共收益不透明等问题,津南以6类小区为试点场景,统一建设物业数字化底座,关联楼栋、单元、房屋、业主、空间、设施设备、工单、公共收益等核心数据。系统采用统一编码管理,将摄像头、路灯、井盖、道路、绿化等设施纳入资产台账,解决纸质记录更新滞后、故障责任难追溯的问题。基于历史工单建立分类模型和知识库,辅助识别照明、给排水、电梯、环境秩序、秩序维护等问题;

wuyeshuzhihua的博客 137

企业微信iPad协议详解:接口接入、实时消息同步与语音转码实践

深入解析企业微信iPad协议的技术架构与开发思路,涵盖API接口接入、长连接通信、实时消息同步、Silk语音转码、异常重连及高并发优化,帮助开发者了解企业微信自动化系统的设计与实现。

欢迎来到祖安! 470

Product Hunt 热榜 2026-11-13:Plurai Simulation、YouArt Desktop App、Omnigraph

2026-11-13 Product Hunt 新产品精选:Plurai Simulation、YouArt Desktop App、Omnigraph。汇总 15 款产品的中文介绍、功能关键词和产品链接。

LaughingZhu的博客 550

【AI Agent面试系列】AI Agent可观测、评测、安全相关的知识点

之前的文章介绍了和,本文主要介绍AI Agent的测评、可观测等知识。

361

Docling 原理解读:是什么、为什么、怎么样

从论文视角拆解 Docling 的整体架构、DoclingDocument 数据模型、PDF 预处理、版面分析、OCR、TableFormer 双解码器、阅读顺序与装配流程,并解释版面框与 OCR 框的区别。

PLANTTHESON的博客 385

WorkBuddy 实战:一句话需求 → 七屏可交互原型,户外徒步 App 的 AI 设计全流程

WorkBuddy 实战:一句话需求 → 七屏可交互原型,户外徒步 App 的 AI 设计全流程,跟着博主一起来还原整个过程。

夜郎King的博客 5073

从认识人工智能到理解机器学习:我的 AI 入门第一课

正式开始学习人工智能之前,我对 AI 的认识其实比较模糊:知道 ChatGPT、知道大模型,也知道现在很多岗位都在谈 AI,但如果有人问我“人工智能到底是什么”“机器是怎么学会识别一只猫的”,我未必能从头到尾讲清楚。上午的课程更偏向行业全景:人工智能的发展、研究方向、NLP、岗位分工、学习路线和 AI Coding 工具。下午的课程更偏向技术基础:机器学习的原理、有监督学习、深度学习、模型训练和评估方法。

chh563的博客 533

影视场景怎么用AI生成3D镜头预演?从概念图、场景白模到网页审片

概念图有氛围,不代表能直接用于镜头预演。本文围绕剧本拆镜、资料与尺度假设、场景白模、机位走位、动作节拍和网页审片,介绍 AI 生成 3D 场景的预演流程。通过稳定对象与相机编号、统一镜头表、意见关联版本和三轮审核,让讨论落到具体镜头,同时明确白模与网页预演不能替代真实场地勘景及现场安全判断。

Solange__的博客 604
上一篇: ZStack ZVF——VMware替代的一条完整链路,从迁移到容灾不留缺口
下一篇: ZSTACK · 答客问 | 什么时候该升级,什么时候再等等
ZStack开发者社区
博客等级 码龄2年 682粉丝 257原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值