这次我们来看一个能解决 AI 画图“丑”问题的工具Diagram Design。如果你尝试过用 Midjourney、Stable Diffusion 这类 AI 工具生成架构图、流程图大概率会失望——元素错位、逻辑混乱、文字乱码是常态。Diagram Design 瞄准的正是这个痛点它不是一个通用的文生图模型而是一个专门为生成专业级技术图表如架构图、流程图、时序图而设计的 AI 工具或系统。它的核心价值在于能够理解你描述的系统逻辑和组件关系并输出符合工程规范、可直接用于文档或演示的矢量图表。这背后通常结合了大型语言模型LLM对文本的理解能力和专业的图表渲染引擎。对于开发者、架构师、产品经理和技术写作者来说这意味着你可以用自然语言描述一个复杂系统然后快速获得一张编辑级的图表草稿极大提升文档产出效率。本文将带你全面了解 Diagram Design 的核心能力、使用门槛以及如何将其集成到你的工作流中。我们会重点关注它是否支持本地部署或私有化对硬件有什么要求是否提供 API 以便自动化生成以及最重要的——实际生成的效果到底能不能用如果你受够了手动调整绘图工具里的每一个方框和箭头这篇文章值得你仔细阅读。1. 核心能力速览在深入细节之前我们先通过一个表格快速把握 Diagram Design 的关键特性。这些信息综合了其设计目标和常见同类工具的能力具体实现可能因不同版本或分支项目而异。能力项说明与评估核心功能将自然语言描述转换为专业的技术图表支持架构图、流程图、时序图、状态图等。输出质量目标是“编辑级”即元素对齐规范、连线清晰、带有基础样式可直接嵌入文档。通常输出为 SVG、PNG 或图表定义文件如 Mermaid、Graphviz DOT。理解能力依赖集成的 LLM如 GPT、Claude 或开源模型来解析用户需求提取实体、关系和行为。部署方式可能提供多种方式云服务 API、本地 Docker 容器、或与现有绘图工具如 Draw.io、Mermaid Live Editor的插件集成。硬件门槛如果完全本地化部署包含 LLM则需要较强的 GPU 和显存例如 16G 显存用于运行 7B/13B 参数模型。如果仅使用其图表渲染部分调用云端 LLM API则对本地硬件要求极低。输入输出输入纯文本描述、结构化提示词、甚至可能是代码片段。输出图像文件PNG/SVG或标准图表定义代码便于二次编辑。是否支持 API是这是此类工具的核心。通常提供 RESTful API接受文本返回图表图像或中间代码。是否支持批量潜在支持。通过 API 可以编程化批量处理多个描述生成多个图表适合文档自动化场景。集成与扩展可能支持与 Markdown 编辑器、文档系统如 Wiki、CI/CD 流水线集成实现“文档即代码”中的图表自动化。2. 适用场景与使用边界在决定投入时间尝试之前先明确它适合谁以及不适合做什么。最适合的三大场景快速原型与头脑风暴在技术方案讨论初期用几句话快速生成一张可视化的草图比白板画图更快且易于保存和分享。文档自动化在编写大量技术文档、设计文档时手动维护图表非常耗时。通过将图表描述写在 Markdown 注释中利用 CI 工具调用 Diagram Design API 自动生成并嵌入图表确保文档与代码同步更新。教育与演示制作教程、课件时需要清晰的技术示意图。用语言描述生成基础框架再微调比从零开始绘制效率高得多。需要谨慎或不适用的场景高度定制化与像素级完美主义如果图表需要完全遵循公司特定的设计规范如精确的配色、图标库、边框样式AI 生成的图表可能只是一个起点需要人工深入调整。极其复杂的交互逻辑对于包含多重条件判断、异常流程、并发处理的超复杂流程图自然语言描述可能变得冗长且易歧义AI 可能无法一次性准确理解所有边界情况。完全离线的封闭环境如果项目要求必须在内网无互联网环境下使用且无法部署本地大模型那么依赖云端 LLM API 的方案将不可行。涉及核心机密的设计将未公开的系统架构详细描述发送给第三方云服务 API 存在信息泄露风险。此时必须采用可本地私有化部署的完整方案。合规与版权提醒输入内容确保你的描述不包含他人受版权保护的特定设计、商业秘密或个人信息。输出内容生成的图表元素如通用图标、布局通常不涉及版权问题但若直接用于商业产品说明书建议进行最终的人工审核和美化。工具本身如果使用开源版本的 Diagram Design注意其许可证如 MIT, Apache 2.0对商业使用的规定。3. 环境准备与前置条件部署或集成 Diagram Design 前需要根据你选择的模式来准备环境。这里我们分两种主要路径来说明A) 使用云端 API 服务轻量、快速和B) 完全本地化部署可控、私有。3.1 模式 A云端 API 集成模式推荐初学者这是门槛最低的方式。你只需要一个能调用外部 HTTP API 的环境。操作系统任意Windows, macOS, Linux。网络可访问公网用于调用 Diagram Design 的云服务或其依赖的 LLM 云 API如 OpenAI, Anthropic。编程环境可选如果你计划写脚本调用需要 Python/Node.js 等并安装requests,axios等 HTTP 库。账户与密钥可能需要注册相关服务并获取 API Key。3.2 模式 B完全本地部署模式追求控制权此模式将图表生成逻辑和 LLM 都部署在本地或私有服务器对硬件有一定要求。操作系统Linux推荐 Ubuntu 20.04或 WindowsWSL2 为佳。硬件CPU现代多核处理器如 Intel i7/AMD Ryzen 7 以上。内存至少 16GB推荐 32GB。GPU关键如需本地运行 LLM则需要高性能 GPU。例如运行 7B 参数模型可能需要 8-10GB 显存13B 模型可能需要 16GB 显存。RTX 3060 12G、RTX 3080/4080、RTX 4090 是常见选择。纯 CPU 推理也可行但速度会慢很多。软件栈Python3.8 - 3.11 版本。CUDA/cuDNN与你的 GPU 和 PyTorch 版本匹配如果使用 GPU。Docker Docker Compose如果提供容器化部署。Git用于克隆代码库。磁盘空间至少预留 20-50GB 空间用于存放模型文件、依赖包和生成缓存。4. 安装部署与启动方式由于 “Diagram Design” 可能指代一个概念或一类工具而非某个特定开源项目这里我们以两种典型的实现方式来举例说明部署流程。你可以根据手头项目的具体文档进行调整。4.1 方式一作为独立服务部署假设项目提供假设存在一个名为diagram-design-server的开源项目。# 1. 克隆代码仓库 git clone https://github.com/example/diagram-design-server.git cd diagram-design-server # 2. 创建 Python 虚拟环境推荐 python -m venv venv source venv/bin/activate # Linux/macOS # venv\Scripts\activate # Windows # 3. 安装依赖 pip install -r requirements.txt # 4. 配置环境变量例如设置LLM API密钥或本地模型路径 cp .env.example .env # 编辑 .env 文件填入你的 OPENAI_API_KEY 或本地模型配置 # 例如LLM_TYPEopenai或 LLM_TYPElocal MODEL_PATH./models/llama-2-7b-chat # 5. 启动服务 # 方式A: 使用内置Web服务器 python app.py --host 0.0.0.0 --port 8000 # 方式B: 使用Gunicorn生产环境 gunicorn -w 4 -b 0.0.0.0:8000 app:app启动成功后访问http://localhost:8000应该能看到 Web UI或者查看http://localhost:8000/docs获取 API 文档。4.2 方式二作为绘图工具的插件/脚本使用另一种常见思路是利用 LLM 生成标准图表定义代码如 Mermaid、Graphviz然后用现有工具渲染。这里以“Mermaid 本地 LLM”为例展示一个简单的本地工作流。# diagram_generator.py - 一个简单的本地脚本示例 import requests import subprocess import os from typing import Optional class DiagramGenerator: def __init__(self, llm_api_base: str http://localhost:1234/v1): self.llm_api llm_api_base def generate_mermaid_code(self, description: str) - Optional[str]: 调用本地LLM API将描述转换为Mermaid代码 prompt f你是一个专业的图表生成助手。请将以下技术描述转换为一个准确、简洁的Mermaid.js代码。 只输出代码块不要任何解释。 描述{description} try: response requests.post( f{self.llm_api}/chat/completions, json{ model: local-model, # 你的本地模型名 messages: [{role: user, content: prompt}], temperature: 0.1, max_tokens: 500 }, timeout30 ) response.raise_for_status() result response.json() # 假设返回内容在 choices[0].message.content 中 mermaid_code result[choices][0][message][content].strip() # 清理可能的 markdown 代码块标记 mermaid_code mermaid_code.replace(mermaid, ).replace(, ).strip() return mermaid_code except Exception as e: print(f生成Mermaid代码失败: {e}) return None def render_diagram(self, mermaid_code: str, output_path: str output.png): 使用 mermaid-cli 将代码渲染为图片 # 需要先安装 mermaid-cli: npm install -g mermaid-js/mermaid-cli with open(temp.mmd, w) as f: f.write(mermaid_code) try: subprocess.run([mmdc, -i, temp.mmd, -o, output_path, -t, default], checkTrue) print(f图表已生成: {output_path}) os.remove(temp.mmd) return True except FileNotFoundError: print(错误: 未找到 mermaid-cli (mmdc)。请通过 npm install -g mermaid-js/mermaid-cli 安装。) return False except subprocess.CalledProcessError as e: print(f渲染图表失败: {e}) return False if __name__ __main__: generator DiagramGenerator() desc 一个简单的Web应用架构包含用户浏览器、反向代理Nginx、Web服务器和应用数据库。用户通过浏览器访问请求先到Nginx再转发到Web服务器Web服务器读写数据库。 code generator.generate_mermaid_code(desc) if code: print(生成的Mermaid代码:) print(code) generator.render_diagram(code, web_architecture.png)这个脚本展示了核心逻辑本地 LLM 服务负责“理解与转换”成熟的图表工具负责“高质量渲染”。你需要先部署一个本地 LLM 服务如使用ollama、text-generation-webui或vLLM并确保mermaid-cli已安装。5. 功能测试与效果验证部署完成后我们需要系统性地测试其核心能力。以下测试用例适用于大多数 Diagram Design 类工具。5.1 测试一基础架构图生成测试目的验证工具能否从一段简单的系统描述中生成结构清晰的架构图。输入描述“展示一个微服务架构包含 API 网关、用户服务、订单服务和产品服务。所有服务都注册到服务发现中心并连接到一个共享的 MySQL 数据库。使用箭头表示服务间的 HTTP 调用关系。”操作步骤在 Web UI 的输入框中粘贴上述描述或通过 API 发送包含此文本的请求。选择图表类型为“架构图”或“C4图”如果支持。点击生成或调用 API。预期结果与成功标准成功生成一张图表其中包含“API Gateway”、“User Service”、“Order Service”、“Product Service”、“Service Registry”、“MySQL”等节点。节点排列有序箭头从调用方指向被调用方如 API Gateway - User Service。图表整体布局合理无重叠或混乱的连线。输出格式获得 PNG/SVG 图片或得到一段结构化的 Mermaid/Graphviz 代码。效果验证检查关键组件是否齐全关系是否正确。这是最基础的“可用性”测试。5.2 测试二复杂流程图生成测试目的验证工具处理条件判断、循环和并行流程的能力。输入描述“绘制一个用户登录流程图。开始于用户访问登录页面。用户输入用户名和密码后系统验证凭证。如果验证成功跳转到首页如果失败检查失败次数。如果失败次数小于3次返回登录页并显示错误信息如果等于或大于3次则锁定账户并结束流程。”操作步骤同上选择“流程图”类型。预期结果与成功标准成功图表应包含“开始”、“输入凭证”、“验证”、“成功”、“失败计数”、“3?”、“3?”、“显示错误”、“锁定账户”、“跳转首页”、“结束”等节点。菱形判断框如“成功”应有明确的“是/否”分支。流程走向清晰能准确反映描述中的逻辑。进阶验证检查流程图是否符合标准规范如开始/结束用椭圆操作用矩形判断用菱形。5.3 测试三时序图生成测试目的验证工具对时间顺序和消息交互的刻画能力。输入描述“生成一个简单的 HTTP 请求时序图。参与者包括客户端Client、负载均衡器Load Balancer、Web 服务器Web Server和数据库Database。流程是1. 客户端向负载均衡器发送 HTTP 请求。2. 负载均衡器将请求转发给一个 Web 服务器。3. Web 服务器查询数据库。4. 数据库返回数据。5. Web 服务器响应负载均衡器。6. 负载均衡器最终将响应返回给客户端。”操作步骤同上选择“时序图”类型。预期结果与成功标准成功生成标准的时序图顶部是参与者Client, Load Balancer, Web Server, Database下方是垂直的生命线。从左到右的箭头表示消息如HTTP Request、Forward Request、SQL Query、Response。消息的顺序必须与描述严格一致。效果验证这是检验 AI 是否真正理解“时序”的关键。如果箭头顺序错乱或参与者缺失则理解能力不足。5.4 测试四长文本与细节描述测试目的验证工具处理复杂、冗长描述的能力以及是否忽略次要细节。输入描述一段更长的、包含冗余信息的描述“我需要一个关于电商平台订单处理状态的流程图。注意这个平台很大每天处理百万订单。流程从用户提交订单开始然后系统要检查库存库存检查很重要如果库存不足就要通知用户并取消订单。如果库存充足就进入支付环节支付可以用支付宝、微信或者银行卡。支付成功后订单状态变为‘待发货’然后仓库会拣货、打包最后发货。发货后状态是‘已发货’用户收到货后可以确认收货状态变为‘已完成’。如果用户退货则进入售后流程。哦对了在支付环节如果支付失败应该允许用户重试。”操作步骤输入长描述生成流程图。预期结果与成功标准成功图表应准确提取核心状态和转换“提交订单” - “检查库存” - (“库存不足” - “取消订单”; “库存充足” - “支付”) - (“支付失败” - “重试支付”; “支付成功” - “待发货”) - “拣货打包” - “已发货” - “确认收货” - “已完成”以及“退货” - “售后流程”的旁支。冗余的描述如“平台很大”应被忽略。效果验证检查图表是否抓住了主干逻辑是否被无关信息干扰。好的工具应该具备“摘要”和“聚焦”能力。6. 接口 API 与批量任务对于需要集成到自动化流程中的用户API 是重中之重。一个设计良好的 Diagram Design 服务应提供清晰的 REST API。6.1 API 调用示例假设服务启动在http://localhost:8000并提供/v1/generate/diagram端点。import requests import json import base64 def generate_diagram_via_api(description: str, diagram_type: str flowchart, output_format: str png): 调用Diagram Design API生成图表 api_url http://localhost:8000/v1/generate/diagram headers {Content-Type: application/json} # 假设需要API密钥认证 headers[Authorization] fBearer YOUR_API_KEY_HERE payload { prompt: description, type: diagram_type, # flowchart, sequence, architecture, state, etc. format: output_format, # png, svg, mermaid, dot style: default, # 可选如 dark, colorful width: 1200, # 可选输出图片宽度 height: 800 # 可选输出图片高度 } try: response requests.post(api_url, headersheaders, jsonpayload, timeout60) response.raise_for_status() result response.json() if output_format in [png, svg] and image_data in result: # 假设返回base64编码的图片数据 image_data base64.b64decode(result[image_data]) filename fdiagram_{hash(description[:10])}.{output_format} with open(filename, wb) as f: f.write(image_data) print(f图表已保存为: {filename}) return filename elif code in result: # 返回的是图表定义代码 print(f生成的{output_format.upper()}代码:) print(result[code]) return result[code] else: print(未知的返回格式:, result) return None except requests.exceptions.RequestException as e: print(fAPI请求失败: {e}) return None # 使用示例 desc 客户端发送请求到服务器服务器处理并返回响应。 generate_diagram_via_api(desc, diagram_typesequence, output_formatpng)6.2 批量任务处理在文档自动化场景中批量生成是核心需求。你可以通过遍历一个包含多个描述的列表或文件来实现。import csv import time from concurrent.futures import ThreadPoolExecutor, as_completed def batch_generate_from_csv(csv_file_path: str, output_dir: str): 从CSV文件批量生成图表 os.makedirs(output_dir, exist_okTrue) with open(csv_file_path, r, encodingutf-8) as f: reader csv.DictReader(f) tasks [] for row in reader: diagram_id row[id] description row[description] d_type row.get(type, flowchart) tasks.append((diagram_id, description, d_type)) print(f开始处理 {len(tasks)} 个图表生成任务...) def process_task(task): diag_id, desc, d_type task # 为每个任务生成唯一文件名 filename os.path.join(output_dir, f{diag_id}.png) # 这里调用上面定义的 generate_diagram_via_api 函数或直接封装请求 success generate_and_save(desc, d_type, filename) # 假设的封装函数 return diag_id, success # 使用线程池控制并发避免对服务器造成过大压力 with ThreadPoolExecutor(max_workers3) as executor: future_to_id {executor.submit(process_task, task): task[0] for task in tasks} for future in as_completed(future_to_id): diag_id future_to_id[future] try: diag_id, success future.result() status 成功 if success else 失败 print(f任务 {diag_id}: {status}) except Exception as exc: print(f任务 {diag_id} 产生异常: {exc}) print(批量处理完成。) # 假设的CSV文件格式 (diagrams.csv): # id,description,type # fig_001,用户登录流程图,flowchart # fig_002,系统架构图,architecture # fig_003,API调用时序图,sequence batch_generate_from_csv(diagrams.csv, ./generated_diagrams)批量任务最佳实践限流与重试在process_task函数中加入延时和失败重试机制避免被服务端限流。日志记录详细记录每个任务的开始、结束、成功/失败状态以及可能的错误信息。结果校验生成后可以添加简单的校验步骤例如检查输出文件是否为空、尺寸是否合理。资源管理根据本地或服务器性能调整max_workers数量。7. 资源占用与性能观察性能是评估工具是否实用的关键。我们需要关注响应时间、资源消耗和稳定性。1. 响应时间分析云端 API 模式延迟主要来自网络往返和云端服务处理时间。一次生成通常在 2 到 10 秒之间取决于描述复杂度和服务负载。观察点使用time模块记录从发送请求到收到完整响应的时间。本地部署模式含LLM延迟取决于本地 LLM 的推理速度。首次生成可能较慢需要加载模型后续生成会快一些。对于 7B 模型在 RTX 3060 12G 上生成一段 Mermaid 代码可能在 3-15 秒。观察点监控服务日志中的生成耗时。2. 资源占用观察GPU 显存如果本地运行 LLM使用nvidia-smi命令观察显存占用。一个 7B 的量化模型如 INT4推理时可能占用 5-8GB 显存。13B 模型则可能需要 10-14GB。CPU 与内存即使使用 GPUCPU 和内存也会被占用。使用htopLinux或任务管理器Windows观察。图表渲染部分如mermaid-cli会额外消耗 CPU 和内存尤其是生成高分辨率图片时。磁盘 I/O主要发生在加载模型文件和保存生成图片时。确保系统盘或数据盘有足够的 IOPS。3. 性能优化建议模型量化使用 GPTQ、AWQ 或 GGUF 等量化格式的模型能显著降低显存占用和提升推理速度对精度损失很小。服务预热对于本地服务可以在启动后先进行一两次简单的生成请求让模型和缓存预热。描述优化给 AI 清晰、简洁、结构化的描述比冗长模糊的描述能更快得到准确结果减少反复生成的开销。缓存结果对于相同的或相似的描述可以实现一个简单的缓存层直接返回已有的图表避免重复计算。8. 常见问题与排查方法在部署和使用过程中你可能会遇到以下问题。这里提供通用的排查思路。问题现象可能原因排查方式解决方案服务启动失败1. 端口被占用2. 依赖包缺失或版本冲突3. 环境变量未正确配置4. 模型文件路径错误1. 查看启动日志错误信息。2. 使用netstat -tulnp | grep 端口号检查端口。3. 运行pip list检查关键包。1. 更换端口修改启动参数。2. 重新创建虚拟环境严格按requirements.txt安装。3. 检查.env文件或命令行参数。4. 确认模型文件已下载且路径正确。Web UI 可访问但生成图表失败1. 集成的 LLM 服务未启动或不可达。2. API 密钥无效或配额用尽。3. 输入描述格式有误或触发内容过滤。1. 查看浏览器开发者工具F12中网络请求的返回错误。2. 检查后端服务日志看 LLM 调用是否报错。3. 尝试一个极其简单的描述测试。1. 确保 LLM 服务本地或云端正常运行且网络连通。2. 检查并更新 API 密钥。3. 简化描述或查看服务端对输入的限制。生成的图表逻辑错误1. 描述本身存在歧义。2. LLM 理解能力有限。3. 提示词Prompt设计不佳。1. 将你的描述给同事看确认是否清晰无歧义。2. 尝试更换更强大的 LLM 模型。3. 分析生成错误的案例优化你的提示词。1. 学习如何编写更精准的图表描述。2. 在提示词中明确指定图表规范如“使用Mermaid语法”“节点用矩形”。3. 对于复杂图表尝试拆分成多个简单步骤生成。生成速度非常慢1. 本地 LLM 模型过大或未量化。2. 服务器资源CPU/GPU不足。3. 网络延迟高云端API。4. 渲染高分辨率图片耗时。1. 使用nvidia-smi或top监控资源使用率。2. 测试一个最简单的描述看是否是模型问题。3. 使用ping或curl测试 API 延迟。1. 换用量化版本的小模型。2. 升级硬件或优化服务器配置。3. 考虑使用离你更近的云服务区域。4. 降低输出图片的分辨率。批量任务中途失败1. 部分描述导致服务端错误。2. 网络不稳定或超时。3. 达到服务端速率限制。1. 查看失败任务的具体描述和错误日志。2. 检查批量脚本的异常处理和重试逻辑。1. 在批量脚本中加入健壮的错误处理和重试机制。2. 在任务之间增加随机延时。3. 将失败的任务记录到文件稍后手动或自动重试。输出图片模糊或布局差1. 图表渲染引擎如Mermaid、Graphviz的默认样式或布局算法导致。2. 输出分辨率设置过低。1. 检查生成的中间代码如Mermaid代码看逻辑是否正确。2. 将中间代码复制到在线的 Mermaid Live Editor 中查看效果。1. 尝试在提示词中指定布局引擎如layout: circofor Graphviz。2. 调整渲染参数如图片宽度、高度、主题。3. 对于重要图表将 AI 生成的代码导入专业绘图工具进行手动美化。9. 最佳实践与使用建议为了更高效、更可靠地使用 Diagram Design 类工具遵循以下实践能让你事半功倍。从简单到复杂不要一开始就扔给它一个极其复杂的系统描述。从一个简单的流程图或时序图开始验证工具的基本能力再逐步增加复杂度。结构化你的描述像写代码一样思考。使用清晰的主语、谓语和宾语。明确标出组件、关系、顺序和条件。例如“当用户点击提交按钮时前端向/api/submit发送一个 POST 请求。然后后端服务验证请求数据。如果验证成功则写入数据库否则返回错误信息。” 这样的描述 AI 更容易解析。善用“种子”或“参考”如果工具支持可以提供一张类似的图表或一段标准的图表代码作为参考让 AI 模仿其风格和结构。将 AI 作为助手而非替代者接受 AI 生成的图表是一个高质量的“初稿”。你需要扮演编辑的角色检查逻辑是否正确布局是否美观并根据公司规范进行调整。AI 的价值在于节省从零到一的绘制时间。建立可复用的模板和提示词库对于经常绘制的图表类型如微服务架构、数据流图可以总结出最有效的提示词模板。例如“请用 C4 模型中的容器图绘制一个包含 [组件A]、[组件B]、[组件C] 的系统它们之间的关系是……”。版本控制你的图表描述将生成图表的文本描述即你的“提示词”与生成的图片或代码一起存入 Git。这样当需要修改时你只需修改描述并重新生成而不是手动调整图片实现了“图表即代码”。集成到文档流水线在 CI/CD 流程中加入一个步骤自动从 Markdown 文件中的特定注释块如!-- mermaid: ... --提取描述调用 Diagram Design API 生成图表并替换或插入到最终生成的文档中。这能确保文档中的图表永远是最新的。Diagram Design 代表了 AI 在专业领域落地的一个有趣方向它不追求通用的“绘画”能力而是聚焦于解决一个具体、高频、且存在明确规范和痛点的任务——绘制技术图表。对于技术团队而言它的价值不在于生成最终交付物而在于极大地加速了从想法到可视化草稿的过程打破了工具使用的惯性让文档和沟通变得更加敏捷。最先应该验证的是它对基础逻辑顺序、分支、循环的图表化能力这是判断其是否“可用”的底线。最容易踩的坑是期望过高试图用一句模糊的话生成完美的终稿。正确的做法是将其视为一个强大的“结对编程”伙伴你负责提供清晰的需求和最终的品控它负责完成繁重的初稿绘制。下一步你可以探索如何将它与你团队现有的工具链如 Confluence、GitBook、VS Code、Read the Docs深度集成打造一个无缝的、自动化的图表生成与管理工作流。当编写技术文档不再是体力活时整个团队的技术沉淀和知识传播效率都会迈上一个新台阶。
