AABB碰撞检测 + 分层Prompt：AI图形零重叠背后的6项关键技术

Loo国昌2026-02-12 15:08

开发 AI 驱动的图形应用？这 6 个技术难题你一定会遇到

从 SmartArchitect AI 项目的实战经验中，提炼出 AI 图形生成、流式渲染、增量编辑等领域的通用解决方案。本文基于 Prompt Engineering、HTTP 协议标准、容错解析理论等学术研究和工业实践，为 AI 图形应用开发者提供系统化的技术指南。

作者 : SmartArchitect Team
适用场景 : AI 图形生成、可视化工具、白板应用、架构图工具
技术栈: FastAPI, React, OpenAI/Claude/Gemini API, Server-Sent Events

📦 开源项目 : SmartArchitect AI on GitHub
⭐ 如果这篇文章对你有帮助，欢迎给项目一个 Star！你的支持是我们持续更新的动力 🙏

为什么写这篇文章？

2025 年，AI 已经深入到各类应用中，但当我们尝试把 AI 集成到图形生成工具时，发现了很多官方文档不会告诉你的坑：

  • 你以为调用 OpenAI API 很简单？等等，用户说要接入第三方代理服务，结果 SDK 被拦截了...
  • 你以为 AI 返回 JSON 很稳定？然而第 469 行缺了个逗号，整个应用崩了...
  • 你兴高采烈地实现了流式渲染，结果在 1134 个 tokens 时浏览器卡死...
  • 你让 AI 做增量编辑，它理解成了"修改现有节点"而不是"新增节点"...

这些问题在官方文档里找不到答案，Stack Overflow 上也很少讨论，因为它们属于AI 应用开发的"无人区"------新兴领域、快速变化、缺乏最佳实践。

经过半年的实战和踩坑，我们总结出了 6 个核心技术难题的解决方案，希望能帮助更多开发者快速上手 AI 图形应用开发。

本文的理论基础

我们的解决方案不是拍脑袋的经验总结，而是建立在以下学术研究和工业标准之上：

  • Prompt Engineering : 基于 GPT-3 论文[1](#1)提出的 Few-Shot Learning 和 OpenAI/Anthropic 的官方最佳实践[2](#2)[3](#3)
  • HTTP 协议标准 : 遵循 RFC 7231 (User-Agent)[4](#4)、W3C Server-Sent Events[5](#5) 等规范
  • 容错解析理论 : 参考 Defense in Depth 安全策略[6](#6)和 JSON5/JSONC 宽松解析标准[7](#7)
  • 差分算法 : 基于 Myers' Diff Algorithm[8](#8)和 RFC 6902 JSON Patch 标准[9](#9)
  • 碰撞检测算法 : 采用计算机图形学中的 AABB (Axis-Aligned Bounding Box)[10](#10)方法

阅读提示：文中的上标数字 [^n] 表示学术引用，详见文末"参考文献"部分。

目录

  1. [难题 #1：如何兼容各种 AI API 代理服务？](#1：如何兼容各种 AI API 代理服务？)
  2. [难题 #2：AI 返回的 JSON 总是格式错误怎么办？](#2：AI 返回的 JSON 总是格式错误怎么办？)
  3. [难题 #3：如何写出高质量的 AI Prompt？](#3：如何写出高质量的 AI Prompt？)
  4. [难题 #4：增量生成怎么做？要用 Diff-based 吗？](#4：增量生成怎么做？要用 Diff-based 吗？)
  5. 难题 #5：流式渲染为什么会卡死浏览器？
  6. [难题 #6：AI 生成的节点为什么总是重叠？](#6：AI 生成的节点为什么总是重叠？)
  7. [特别篇：Excalidraw Prompt 工程的黄金法则](#特别篇：Excalidraw Prompt 工程的黄金法则)

难题 #1：如何兼容各种 AI API 代理服务？

问题背景

你的应用支持 OpenAI、Claude、Gemini 等多个 AI 服务，用户也能配置自己的 API 密钥。一切看起来很完美，直到用户说：

"我想用 [某某代理服务] 来降低成本，但是你们的应用报错 Your request was blocked！"

你一看日志，发现：

  • linkflow.run (某代理服务)：✅ 工作正常
  • ikuncode.cc (另一代理服务)：❌ 请求被拦截

为什么会这样？

答案是：这些代理服务会检测请求的 User-Agent [4](#4)。当你使用官方 SDK（Anthropic SDK、OpenAI SDK）时，它们会在请求头中添加特定的 User-Agent（如 anthropic-python/0.8.1），某些代理服务会直接拦截这些请求。

技术原理：User-Agent Sniffing

根据 HTTP/1.1 协议规范 RFC 7231[4](#4)，User-Agent 请求头用于标识发起请求的客户端软件。这本是为了服务器统计和内容协商，但在反爬虫和访问控制领域，User-Agent 检测（User-Agent Sniffing）已成为常见的流量过滤手段：

复制代码 
# 官方 SDK 的典型 User-Agent
anthropic-python/0.8.1 Python/3.12.5
openai-python/1.12.0

# 代理服务可能拦截的模式
if "anthropic-python" in user_agent or "openai-python" in user_agent:
    return 403  # Forbidden

这种技术广泛应用于 CDN、API Gateway 和反爬虫系统中，用于区分正常用户流量和自动化请求。

业界有哪些解决方案？

我们调研了业界的做法，发现主要有 3 种方案：

方案 A：统一使用原始 HTTP（放弃 SDK）
python 复制代码 
# 不使用任何官方 SDK，全部用 httpx/requests 发送
import httpx

async with httpx.AsyncClient() as client:
    response = await client.post(
        url="https://api.example.com/v1/messages",
        headers={
            "content-type": "application/json",
            "x-api-key": api_key,
            # 不带 SDK 的 User-Agent
        },
        json={...}
    )

优点 ：最大兼容性，适用所有代理
缺点：失去 SDK 便利性（类型提示、自动重试）、需要手动实现 SSE 解析

方案 B：SDK + Raw HTTP 双模式（推荐⭐）
python 复制代码 
# 检测特定代理，降级为 Raw HTTP
use_raw_http = (
    provider == "custom" and
    "ikuncode.cc" in base_url.lower()  # 黑名单
)

if use_raw_http:
    # 使用 Raw HTTP
    async with httpx.AsyncClient() as client:
        async with client.stream("POST", url, ...) as response:
            # 手动解析 SSE
            ...
else:
    # 使用官方 SDK
    stream = client.messages.stream(...)
    with stream as s:
        for text in s.text_stream:
            yield text

优点 ：兼顾性能和兼容性，大部分场景用高效 SDK
缺点：需要维护黑名单

方案 C：自动探测降级

首次请求用 SDK，失败后自动降级 Raw HTTP，并缓存决策。

优点 ：自动适配
缺点：首次请求必定失败，用户体验差

我们的实战经验

在 SmartArchitect 项目中，我们采用了方案 B（双模式）。关键代码：

python 复制代码 
# backend/app/api/chat_generator.py

# 1. 精确识别问题代理
use_raw_http = (
    provider == "custom" and
    "ikuncode.cc" in base_url.lower()
)

if use_raw_http:
    # Raw HTTP 路径
    async with httpx.AsyncClient() as client:
        async with client.stream("POST", url, headers=headers, json=data) as response:
            current_event = None
            buffer = ""

            # 🔑 关键：使用 aiter_bytes() 而非 aiter_lines()
            async for chunk in response.aiter_bytes():
                buffer += chunk.decode('utf-8')

                # 手动按行分割
                while '\n' in buffer:
                    line, buffer = buffer.split('\n', 1)

                    # Claude SSE 格式：event: 和 data: 是分开的行
                    if line.startswith("event: "):
                        current_event = line[7:]
                    elif line.startswith("data: "):
                        data_json = json.loads(line[6:])
                        if current_event == "content_block_delta":
                            text = data_json["delta"]["text"]
                            yield f"data: [TOKEN] {text}\n\n"
else:
    # SDK 路径（linkflow.run 等）
    stream = client.messages.stream(...)
    with stream as s:
        for text in s.text_stream:
            yield f"data: [TOKEN] {text}\n\n"

关键技术细节

1. 真实流式的秘密：aiter_bytes() vs aiter_lines()
python 复制代码 
# ❌ 错误：aiter_lines() 会缓冲整行，失去实时性
async for line in response.aiter_lines():
    process(line)

# ✅ 正确：aiter_bytes() 逐字节读取，真正实时
async for chunk in response.aiter_bytes():
    buffer += chunk.decode('utf-8')
    # 手动维护 buffer 和行分割
2. Claude SSE 格式的坑

Claude 的 SSE 格式有个特殊之处：event: 和 data: 是分开的行。

复制代码 
event: content_block_start
data: {"type":"content_block_start","index":0}

event: content_block_delta
data: {"type":"content_block_delta","delta":{"text":"Hello"}}

event: content_block_delta
data: {"type":"content_block_delta","delta":{"text":" world"}}

你必须跟踪 current_event 状态，只在 content_block_delta 时提取文本：

python 复制代码 
if line.startswith("event: "):
    current_event = line[7:]
elif line.startswith("data: "):
    data_json = json.loads(line[6:])
    if current_event == "content_block_delta":  # 关键判断
        text = data_json["delta"]["text"]
        yield text
3. URL 清理逻辑

Anthropic SDK 会自动添加 /v1，导致 URL 变成 /v1/v1/messages：

python 复制代码 
# 问题：base_url = "https://example.com/v1"
# SDK 会拼成: "https://example.com/v1/v1/messages"

# 解决：去除末尾的 /v1
clean_base_url = base_url.rstrip("/v1")
url = f"{clean_base_url}/v1/messages"

推荐方案总结

场景 推荐方案
企业内部工具（可控环境） 方案 A (统一 Raw HTTP)
多代理 SaaS 方案 B (双模式) ⭐
开源工具 方案 B (双模式)
实验性项目 方案 C (自动探测)

最佳实践：

  • ✅ 先实现 SDK 路径（覆盖 80% 场景）
  • ✅ 遇到问题代理再添加 Raw HTTP
  • ✅ 维护黑名单（2-3 个常见问题代理即可）
  • ✅ 提供配置选项让用户手动选择模式

难题 #2：AI 返回的 JSON 总是格式错误怎么办？

问题背景

你兴高采烈地让 AI 生成一个包含 25 个节点的架构图 JSON，然后收到这样的输出：

json 复制代码 
{
  "nodes": [
    {"id": "node-1", "label": "API Gateway"}
    {"id": "node-2", "label": "User Service"}  // ❌ 缺逗号！
    ...
  ]
}

json.loads() 直接报错：Expecting ',' delimiter: line 2 column 47

你心想："这不是 AI 的问题吗？我去调 temperature、换个模型试试..."

结果发现：无论怎么调参，AI 偶尔总会出错。

这不是 bug，这是现实。AI 生成结构化数据时，格式错误是常态，你需要的是健壮的修复策略。

理论基础：Defense in Depth (纵深防御)

我们的 JSON 修复策略借鉴了信息安全领域的 Defense in Depth（纵深防御） 理念[6](#6)。该策略最早由美国国家安全局（NSA）在 2012 年提出，核心思想是：

单一防御层必然有弱点，多层独立防御策略能显著提升系统可靠性。

在 JSON 解析场景中，我们设计了以下防御层级：

  1. 第一层：标准 JSON 解析器（最快，覆盖约 60% 正常情况）
  2. 第二层：正则表达式修复（处理常见错误，覆盖额外 20%）
  3. 第三层 ：宽松 JSON 解析库（如 JSON5[7](#7)，处理复杂错误，覆盖额外 10%）
  4. 第四层：括号补全算法（处理截断情况，覆盖额外 5%）
  5. 第五层：Fallback 策略（返回 Mock 数据，保证永远有输出）

这种多层策略能将 JSON 解析成功率从 60% 提升到 90-95%，同时保持低延迟（大部分情况下只执行第一层）。

业界有哪些修复策略？

我们总结了 4 种主流方案：

方案 A：正则表达式修复（Regex Repair）

用正则匹配常见错误模式，直接替换修复。

python 复制代码 
def repair_json_with_regex(text: str) -> str:
    # 1. 移除 markdown 代码块
    text = re.sub(r'^```json\s*', '', text)
    text = re.sub(r'\s*```$', '', text)

    # 2. 修复缺少逗号（同行）
    text = re.sub(r'}\s+{', '}, {', text)

    # 3. 修复缺少逗号（跨行）
    text = re.sub(r'}\n\s*{', '},\n{', text)

    # 4. 修复数字后缺逗号
    text = re.sub(r'(\d+)\s+(")', r'\1, \2', text)

    # 5. 修复布尔值后缺逗号
    text = re.sub(r'(true|false|null)\s+(")', r'\1, \2', text)

    return text

覆盖率 ：约 70-80%
优点 ：速度快（< 1ms）、无依赖
缺点：只能修复预定义模式

方案 B：JSON Repair 库（jsonic）

使用专门的宽松 JSON 解析库。

python 复制代码 
import jsonic

def repair_json_with_library(text: str) -> dict:
    try:
        return jsonic.loads(text)  # 宽松解析
    except:
        # 降级到正则修复
        return json.loads(repair_json_with_regex(text))

覆盖率 ：约 85-90%
优点 ：处理更复杂的错误
缺点：依赖外部库

方案 C：LLM 二次修复（Self-Healing）

将错误 JSON 和错误信息发回 LLM，让它修复。

python 复制代码 
async def generate_with_self_healing(prompt: str, max_retries: int = 2):
    for attempt in range(max_retries):
        try:
            result = await ai.generate(prompt)
            return json.loads(result)
        except json.JSONDecodeError as e:
            if attempt == max_retries - 1:
                raise

            # 构造修复 prompt
            prompt = f"""
            You generated invalid JSON:
            {result}

            Error: {str(e)}

            Fix it and output ONLY the corrected JSON.
            """

覆盖率 ：约 95%+
优点 ：能处理任意复杂错误
缺点：延迟增加、Token 成本翻倍

方案 D：多层防御（推荐⭐）

结合多种方案，按优先级尝试，每层失败后降级。

python 复制代码 
def repair_json_multilayer(text: str) -> dict:
    # 层级 1: 直接解析
    try:
        return json.loads(text)
    except json.JSONDecodeError:
        pass

    # 层级 2: 正则修复
    try:
        repaired = repair_json_with_regex(text)
        return json.loads(repaired)
    except json.JSONDecodeError:
        pass

    # 层级 3: JSON Repair 库
    try:
        return jsonic.loads(text)
    except:
        pass

    # 层级 4: 补全闭合括号
    try:
        completed = complete_brackets(text)
        return json.loads(completed)
    except:
        pass

    # 层级 5: 返回 None 触发 fallback
    logger.error(f"All repair strategies failed. First 500 chars: {text[:500]}")
    logger.error(f"Last 500 chars: {text[-500:]}")
    return None

覆盖率 ：约 90-95%
优点 ：可靠性最高、性能可控
缺点：实现复杂度中等

我们的实战案例

在 SmartArchitect 的 Excalidraw 生成功能中，AI 返回了一个 10965 字符的 JSON，在第 469 行缺少逗号。我们使用方案 D（多层防御）+ Mock Fallback：

python 复制代码 
# backend/app/services/excalidraw_generator.py

def _safe_json(self, payload: str) -> dict:
    """多层 JSON 解析，失败返回 None"""

    # 层级 1: 直接解析（覆盖 ~60% 场景）
    try:
        return json.loads(payload)
    except json.JSONDecodeError:
        pass

    # 层级 2: 正则修复（覆盖额外 20% 场景）
    try:
        repaired = self._repair_with_regex(payload)
        return json.loads(repaired)
    except json.JSONDecodeError:
        pass

    # 层级 3: 补全括号（处理截断情况）
    try:
        completed = self._complete_brackets(payload)
        return json.loads(completed)
    except:
        pass

    # 失败：返回 None 触发下游 fallback
    logger.error(f"All JSON repair strategies failed. Payload length: {len(payload)}")
    return None

def _validate_scene(self, ai_data: dict, width: int, height: int):
    """验证场景，失败返回 mock"""

    # 处理 None（JSON 修复失败）
    if ai_data is None or not isinstance(ai_data, dict):
        logger.warning("Invalid ai_data, returning mock scene")
        return self._mock_scene()  # 返回一个猫脸图标

    # 验证元素
    elements = ai_data.get("elements", [])
    cleaned = [elem for elem in elements if self._is_valid_element(elem)]

    # 无有效元素：返回 mock
    if not cleaned:
        logger.warning("No valid elements, returning mock scene")
        return self._mock_scene()

    return ExcalidrawScene(elements=cleaned, appState={...})

效果：

  • 第 469 行缺逗号 → 层级 2 正则修复成功 ✅
  • 如果修复仍失败 → 返回 mock 场景（猫脸图标）✅
  • 用户永远看到有效输出（生成或 fallback）

推荐方案总结

场景 推荐方案
生产环境 方案 D (多层防御) + Mock Fallback ⭐
原型开发 方案 A (正则修复)
高可用需求 方案 D + Mock Fallback
成本敏感 方案 A + B（避免额外 API 调用）

最佳实践：

  • ✅ 使用多层防御（90%+ 覆盖率）
  • ✅ 最后一层返回 None（明确失败信号）
  • ✅ 业务层提供 Mock Fallback（永远有输出）
  • ✅ 记录失败的 JSON 样本（持续改进修复策略）
  • ❌ 避免使用 LLM 二次修复（成本高、延迟大）

难题 #3：如何写出高质量的 AI Prompt？

问题背景

你写了一个 Prompt 让 AI 生成流程图：

复制代码 
Generate a flowchart in JSON format.
Requirements:
- Minimum 220px horizontal spacing
- Minimum 160px vertical spacing

结果 AI 生成的节点重叠了 26.8%，间距只有 183px（需要 220px）。

你心想："我明明写了要求啊！为什么 AI 不遵守？"

答案是：Prompt 太模糊了。

"Minimum 220px spacing" 对你来说很清楚，但对 AI 来说是模糊的。它不知道：

  • 220px 是指中心距离还是边缘距离？
  • 如果冲突，是优先间距还是优先保持原布局？
  • 怎么计算节点宽度？矩形多宽？圆形多大？

好的 Prompt 应该像给实习生写代码规范：假设对方什么都不懂，把每一步都写清楚。

Prompt Engineering 的学术基础

Prompt Engineering（提示工程） 作为一个正式的研究领域，起源于 GPT-3 论文 "Language Models are Few-Shot Learners" (Brown et al., 2020)[1](#1)。该论文首次系统性地展示了通过精心设计的输入提示来引导大语言模型完成任务，而无需重新训练模型。

核心概念

  1. Zero-Shot Learning（零样本学习）

    • 仅通过任务描述，无示例
    • 例："Translate this to French: Hello"

  2. Few-Shot Learning（少样本学习） [1](#1)

    • 提供 2-5 个示例来引导模型行为
    • 论文证明：3-shot 能使任务准确率提升 30-70%
    • 例："Q: 2+2? A: 4. Q: 3+5? A: 8. Q: 7+9? A: ?"

  3. In-Context Learning（上下文学习）

    • 模型从 prompt 上下文中学习任务模式
    • 不需要梯度更新，纯推理时学习
工业界最佳实践

我们的策略基于 OpenAI[2](#2) 和 Anthropic[3](#3) 的官方 Prompt Engineering 指南：

A. 指令层级设计（Instruction Hierarchy）

  • 来源：Anthropic Prompt Engineering Guide[3](#3)
  • 原理：优先级从高到低排列，防止后续指令覆盖关键约束
  • 结构：System Rules → Constraints → Examples → Task

B. 约束生成（Constrained Generation）

  • 来源：CTRL 论文 (Keskar et al., 2019)[11](#11)
  • 原理：限定选择空间，减少模型生成的随机性
  • 例：choose from ["A", "B", "C"] 比 choose a value 错误率低 40-60%

C. 链式思考（Chain-of-Thought, CoT）

  • 来源："Chain-of-Thought Prompting" (Wei et al., 2022)[12](#12)
  • 原理：要求模型显式输出推理步骤
  • 效果：在复杂推理任务中准确率提升 50%+

D. 自我验证（Self-Verification）

  • 我们的改进：结构化 CoT + 算法化验证清单
  • 原理：在输出前执行显式验证步骤
  • 例："Before output: verify all N(N-1)/2 node pairs"*

业界有哪些 Prompt 策略？

策略 A：Few-Shot Prompting（最简单、最有效⭐）

在 Prompt 中提供 2-5 个完整示例，展示"正确输出"和"错误输出"。

python 复制代码 
prompt = f"""
Generate a flowchart in JSON format.

**EXAMPLE: Adding a cache layer**

Existing:
{{
  "nodes": [
    {{"id": "service-1", "label": "User Service"}},
    {{"id": "db-1", "label": "User DB"}}
  ]
}}

User request: "Add Redis cache"

✅ CORRECT Output (2 existing + 1 new = 3 total):
{{
  "nodes": [
    {{"id": "service-1", "label": "User Service"}},  // PRESERVED
    {{"id": "db-1", "label": "User DB"}},           // PRESERVED
    {{"id": "cache-{timestamp}", "label": "Redis"}}  // NEW
  ]
}}

❌ WRONG Output (modified existing label):
{{
  "nodes": [
    {{"id": "service-1", "label": "User Service + Cache"}}  // WRONG!
  ]
}}

Now generate for: {user_input}
"""

优点：

  • ✅ 效果显著（30% → 70% 成功率）
  • ✅ 实现简单（只改 Prompt，无需代码改动）
  • ✅ 适用性广

缺点：

  • ⚠️ Token 消耗增加（每个示例 ~200 tokens）

效果提升：30% → 70%

策略 B：Structured Chain-of-Thought (SCoT)

要求 AI 使用结构化步骤推理，输出前自我验证。

python 复制代码 
prompt = f"""
Before generating JSON, follow these steps:

**STEP 1 (List Existing):**
- List all {len(existing_nodes)} existing node IDs
- Verify count: {len(existing_nodes)} nodes

**STEP 2 (Analyze Request):**
IF user wants to "add cache":
  THEN action = "create_cache_node"
  required_nodes = ["Redis Cache"]

**STEP 3 (Generate New Nodes):**
FOR EACH node in required_nodes:
  new_node = {{
    "id": f"{{type}}-{{timestamp}}",
    "position": {{"x": max_x + 300, "y": ...}}
  }}

**STEP 4 (Merge):**
final_output = {{
  "nodes": COPY(existing_nodes) + new_nodes
}}

**STEP 5 (Verification):**
assert len(final_output["nodes"]) > {len(existing_nodes)}

Now output the final JSON:
"""

优点：

  • ✅ 推理过程透明（便于调试）
  • ✅ 适合复杂任务

缺点：

  • ⚠️ Token 消耗大（推理步骤也要生成）
  • ⚠️ 对推理模型（o3-mini）效果有限

效果提升：50% → 80%

策略 C：分层 Prompt 设计（适合长期维护⭐）

将 Prompt 分为多层：系统规则、配置参数、验证清单、任务描述。

python 复制代码 
# 层级 1: 系统规则（基础约束）
SYSTEM_RULES = """
**FUNDAMENTAL RULES:**
1. Output MUST be valid JSON
2. NO overlapping nodes under ANY circumstances
3. ALL coordinates must be positive integers
"""

# 层级 2: 布局配置（具体参数）
LAYOUT_CONFIG = f"""
**NODE DIMENSIONS:**
- Rectangle: 180px × 60px
- Circle: 60px × 60px

**SPACING REQUIREMENTS:**
- Horizontal: 220px minimum (center to center)
- Vertical: 160px minimum (center to center)
"""

# 层级 3: 验证清单（输出前检查）
VALIDATION = """
**PRE-OUTPUT VALIDATION:**
1. Count all node pairs: N*(N-1)/2
2. For each pair: verify dx ≥ 220px OR dy ≥ 160px
3. If ANY violation: STOP and fix coordinates
4. Only output JSON when 100% pass
"""

# 层级 4: 任务
TASK = f"""
Now generate flowchart for: {user_input}
"""

# 组合
prompt = f"{SYSTEM_RULES}\n\n{LAYOUT_CONFIG}\n\n{VALIDATION}\n\n{TASK}"

优点：

  • ✅ 职责清晰（便于维护）
  • ✅ 可复用组件（SYSTEM_RULES 通用）
  • ✅ 易于 A/B 测试

缺点：

  • ⚠️ Prompt 长度增加

效果提升：持续优化

我们的实战案例：从 26.8% 重叠率到 0%

在 SmartArchitect 的图片转架构图功能中，初始重叠率高达 26.8%。我们使用分层 Prompt 设计（参考 FlowPilot），将 Prompt 优化为：

python 复制代码 
# 层级 1: 优先级系统（非常重要！）
"""
**STRICT PRIORITIES (Non-Negotiable Order):**
1. PRIORITY 1: Zero Coordinate Collisions
2. PRIORITY 2: Minimum Spacing Enforcement
3. PRIORITY 3: Preserve Image Layout

⚠️ If conflict: collision-free > layout preservation
"""

# 层级 2: 精确参数（具体到公式）
"""
**NODE DIMENSIONS:**
- rectangle/task: 180px × 60px
- circle (start/end): 60px × 60px
- diamond: 80px × 80px

**SPACING CALCULATION FORMULA:**
Horizontal neighbors (same row):
Node1.x + Node1.width + 20px gap + Node2.width/2 ≤ Node2.x
Example: Node1 at x=100 (width 180) → Node2 at x=100+180+20+90=390 MINIMUM
"""

# 层级 3: 验证算法（手把手教 AI）
"""
**PRE-OUTPUT VALIDATION (MANDATORY):**
Step 1: List all N*(N-1)/2 node pairs
Step 2: For each pair (i, j):
  - Calculate dx = |center_i.x - center_j.x|
  - Calculate dy = |center_i.y - center_j.y|
  - If in same row (dy < 80): verify dx ≥ 220px
  - If in same column (dx < 80): verify dy ≥ 160px
Step 3: If violations: STOP and adjust coordinates
Step 4: Only output JSON when 100% pass
"""

效果：

  • 重叠率: 26.8% → 0% ✅
  • 布局相似度: 30% → 75% ✅
  • AI 正确率: ~20% → 70-85% (预期)

关键因素：

  1. ✅ 明确优先级（碰撞 > 布局）
  2. ✅ 精确参数（220px 公式，不是"合理间距"）
  3. ✅ 算法化验证（N*(N-1)/2 对检查）

Prompt 优化的黄金法则

  1. 具体化：用公式代替形容词

    • ❌ "合理间距"
    • ✅ "Node1.x + 180 + 20 + 90 ≤ Node2.x"

  2. 优先级明确：冲突时如何取舍

    • ❌ "保持布局，避免重叠"（谁优先？）
    • ✅ "PRIORITY 1: 零重叠，PRIORITY 2: 保持布局"

  3. 示例胜过千言万语

    • ✅ 提供 1-3 个完整示例
    • ✅ 包含"正确"和"错误"对比

  4. 自我验证：让 AI 输出前检查

    • ✅ "Before output, verify: ..."
    • ✅ "If violations: STOP and fix"

  5. 分层设计：便于长期维护

    • ✅ 系统规则（通用）
    • ✅ 配置参数（可调）
    • ✅ 验证清单（可扩展）

推荐方案总结

场景 推荐策略 Token 成本 效果提升
格式生成任务 Few-Shot +20-30% 30% → 70%
复杂决策任务 SCoT +40-60% 50% → 80%
长期维护项目 分层设计 +30-50% 持续优化
组合使用 分层 + Few-Shot +50-80% 70% → 90% ⭐

最佳实践：

  • ✅ 从 Few-Shot 开始（最简单、效果好）
  • ✅ 添加自我验证清单（提升 10-15%）
  • ✅ 分层设计便于长期维护
  • ❌ 避免过度使用 CoT（推理模型效果有限）

难题 #4：增量生成怎么做？要用 Diff-based 吗？

问题背景

用户已经创建了一个包含 25 个节点的架构图，现在他说：

"在 User Service 和 User DB 之间添加一个 Redis 缓存节点。"

你把现有的 25 个节点和用户请求一起发给 AI，期待它返回 26 个节点（25 个原有 + 1 个新增）。

结果 AI 返回了：

  • 15 个节点，label 都被修改了（"User Service" 变成了 "User Service + Cache"）
  • 0 个新增节点

AI 把"追加"理解成了"修改"！

这就是增量生成的核心难题：如何让 AI 理解什么是"新增"而不是"修改"？

理论基础：Diff-based Approach

Diff-based（基于差分的） 方法并非我们原创，而是建立在以下计算机科学基础之上：

1. Myers' Diff Algorithm (1986)

Eugene W. Myers 在 1986 年论文 "An O(ND) Difference Algorithm and Its Variations" [8](#8) 中提出了经典的差分算法。该算法计算两个序列的最小编辑距离（Minimum Edit Distance），广泛应用于：

  • Git diff：代码版本对比
  • Unix diff：文件差异分析
  • 代码审查工具：GitHub、GitLab 的 diff 视图

核心思想：不传输完整文档，只传输变化部分（操作序列）。

2. RFC 6902: JSON Patch (2013)

IETF（互联网工程任务组）在 2013 年制定了 RFC 6902 JSON Patch 标准 [9](#9)，定义了描述 JSON 文档部分修改的格式。

标准操作类型：

json 复制代码 
{
  "op": "add",       // 添加
  "op": "remove",    // 删除
  "op": "replace",   // 替换
  "op": "move",      // 移动
  "op": "copy",      // 复制
  "op": "test"       // 测试（验证值是否匹配）
}

工业应用：

  • GitHub API v3 ：使用 PATCH /repos/:owner/:repo 更新仓库信息
  • RESTful API：部分更新资源的标准方法
  • 实时协作工具：Google Docs、Figma 的增量同步
3. Incremental Generation in NLP

在自然语言处理领域，增量生成（Incremental Generation） 是一个活跃的研究方向[13](#13)。典型工作包括：

  • "Incremental Decoding for Phrase-Based SMT" (Grissom II et al., 2014)
  • "Streaming Translation" 研究：边接收输入边生成输出

我们的贡献 ：将 Diff-based 思想应用到 AI + JSON 结构化输出 场景，结合 Few-Shot Prompting 提升成功率。

业界有哪些方案？

方案 A：Diff-based Prompting (JSON Patch)

来源：JSON Whisperer 论文（2025）、OpenAI GPT-4.1 官方 cookbook

核心思想：让 AI 只生成 RFC 6902 JSON Patch（修改部分），而不是完整文档。

python 复制代码 
# Prompt
prompt = f"""
Base document:
{{
  "nodes": [...25 existing nodes...],
  "edges": [...]
}}

User request: "Add Redis cache"

Output format: RFC 6902 JSON Patch

✅ CORRECT:
{{
  "patches": [
    {{"op": "add", "path": "/nodes/-", "value": {{"id": "cache-1", ...}}}},
    {{"op": "add", "path": "/edges/-", "value": {{...}}}}
  ]
}}

❌ WRONG (full document):
{{
  "nodes": [...all 26 nodes...]
}}
"""

# 后端应用
import jsonpatch

patches = ai_response["patches"]
updated = jsonpatch.apply_patch(base_document, patches)

Token 分析：

  • Request: 2500 tokens (base doc) + 700 tokens (prompt) = 3200 tokens
  • Response: 200 tokens (只有 patch) = 200 tokens
  • 总计: 3400 tokens（vs 4700 tokens 全量生成）
  • 节省: 27.7%

优点：

  • ✅ Token 节省 27-38%（Response 减少 91%）
  • ✅ 语义明确（op: "add" 清楚表达意图）
  • ✅ 行业标准（RFC 6902）

缺点：

  • ❌ Request 仍需发送完整 base document
  • ❌ AI 需要学习 JSON Patch 格式（few-shot 示例）
  • ❌ 前端需要理解 patch（或后端预先应用）
  • ❌ 实现复杂度高（1 周开发时间）

适用场景：高频增量编辑、Token 成本 > $100/天

方案 B：全量生成 + 后端验证修复（推荐⭐）

核心思想：AI 生成完整文档，后端自动修复错误（删除的节点恢复、修改的 label 还原）。

python 复制代码 
def validate_incremental_result(
    original_nodes: List[Node],
    ai_nodes: List[Node]
) -> List[Node]:
    """验证 AI 输出，自动修复"""

    original_ids = {n.id for n in original_nodes}
    ai_ids = {n.id for n in ai_nodes}

    # 1. 检测删除的节点
    deleted_ids = original_ids - ai_ids
    if deleted_ids:
        logger.warning(f"AI deleted {len(deleted_ids)} nodes, recovering...")
        # 自动恢复
        recovered = [n for n in original_nodes if n.id in deleted_ids]
        ai_nodes.extend(recovered)

    # 2. 检测修改的节点 label
    for orig in original_nodes:
        ai_node = next((n for n in ai_nodes if n.id == orig.id), None)
        if ai_node and ai_node.data.label != orig.data.label:
            logger.warning(f"AI modified label: {orig.id}, restoring...")
            ai_node.data.label = orig.data.label  # 还原 label

    # 3. 检测重复 ID
    id_counts = {}
    for node in ai_nodes:
        id_counts[node.id] = id_counts.get(node.id, 0) + 1

    duplicates = {id for id, count in id_counts.items() if count > 1}
    if duplicates:
        # 重命名重复节点
        for dup_id in duplicates:
            dup_nodes = [n for n in ai_nodes if n.id == dup_id]
            for i, node in enumerate(dup_nodes[1:], 1):
                node.id = f"{dup_id}-dup-{i}"

    return ai_nodes

Token 分析：

  • Request: 2500 tokens
  • Response: 2200 tokens (完整 27 节点)
  • 总计: 4700 tokens

优点：

  • ✅ 实现简单（1 天开发时间）
  • ✅ AI 使用熟悉格式（完整 JSON）
  • ✅ 前端无需改动

缺点：

  • ❌ Token 浪费（传输完整数据）

适用场景：快速实现、Token 成本不敏感

方案 C：Two-Stage Generation

核心思想：阶段 1 LLM 生成自然语言计划，阶段 2 后端解析计划并构造节点。

python 复制代码 
# 阶段 1: AI 生成计划
prompt = """
List nodes to add.
Existing: {node_labels}
Request: {user_input}

Output (plain text):
- Add node: [name] (type, position hint)
- Add edge: [source] → [target]
"""

ai_plan = """
- Add node: Redis Cache (type: cache, between User Service and User DB)
- Add edge: User Service → Redis Cache
- Add edge: Redis Cache → User DB
"""

# 阶段 2: 后端构造节点
for node_desc in parse_plan(ai_plan).nodes:
    new_node = Node(
        id=generate_id(node_desc.type),
        position=calculate_position(node_desc.hint, existing_nodes),
        data=NodeData(label=node_desc.name)
    )
    nodes.append(new_node)

优点：

  • ✅ AI 任务简化
  • ✅ 后端完全控制节点创建

缺点：

  • ❌ 需要实现 NLP 解析器（复杂）
  • ❌ 两次 API 调用（延迟增加）

适用场景：高度结构化任务

我们的实战经验：先验证可行性，再考虑优化

在 SmartArchitect 项目中，我们采用了方案 B（全量生成 + 验证）：

  1. 第一步：基础实现（1 天）

    python 复制代码 
    # 构建增量 Prompt
prompt = f"""
EXISTING ARCHITECTURE (DO NOT DELETE):
{json.dumps(existing_nodes)}

USER REQUEST: {user_input}

OUTPUT: Complete JSON with ALL nodes (existing + new).
"""

# 验证并修复
ai_nodes = await ai.generate(prompt)
validated = validate_incremental_result(original_nodes, ai_nodes)

    效果：成功率 ~30%（AI 经常修改 label）

  2. 第二步：添加 Few-Shot 示例（2 小时，计划中）

    python 复制代码 
    prompt = f"""
...

**EXAMPLE:**
Existing: 2 nodes
Request: "Add cache"
Output: 3 nodes (2 existing + 1 new)  // NOT 2 modified!

...
"""

    预期效果：成功率 30% → 70-85%

  3. 第三步（可选）：迁移到 Diff-based（1 周，如果 Token 成本过高）

    • 只在成本 > $100/天时考虑
    • 需要重构 Prompt、后端、前端

Diff-based 真的值得吗？我们的可行性分析

我们详细分析了 Diff-based 方案（参考文档 diff-based-feasibility-analysis.md），结论是：

短期不建议采用，原因：

  1. Token 节省有限（27% vs 预期的 60%）

    • Request 仍需发送完整 base document
    • Prompt 长度反而增加（需要解释 JSON Patch 格式）

  2. 实现复杂度高

    • 需要改动 5 个模块（Schema, Prompt, 后端应用, 验证, 前端）
    • 预计开发+测试: 3-5 天

  3. 风险高

    • AI 不熟悉 JSON Patch 格式（错误率可能更高）
    • 前端复杂度增加

  4. 当前问题的根源不在格式

    • AI 不理解任务（"追加"="修改 label"）
    • Diff-based 不解决理解问题，只解决 Token 问题

我们的建议：

  • ✅ 先用 Few-Shot 提升成功率到 70-85%
  • ⏳ Token 成本 > $100/天时再考虑 Diff-based
  • ⏳ 1-2 周后评估效果，决定是否重构

推荐方案总结

场景 推荐方案 开发时间 Token 节省 成功率
快速原型 方案 B (全量+验证) 1 天 0% 70-85%
高频使用 方案 A (Diff-based) 1 周 27-38% 85-95%
企业级 方案 B + Few-Shot ⭐ 2 天 0% 70-85%
成本敏感 方案 A (Diff-based) 1 周 27-38% 85-95%

最佳实践：

  • ✅ 渐进式优化：先简单方案，效果不够再升级
  • ✅ 先实现方案 B（快速验证可行性）
  • ✅ 添加 Few-Shot 示例（提升 20-30%）
  • ✅ Token 成本 > $100/天时考虑 Diff-based
  • ❌ 避免 Two-Stage（NLP 解析器太复杂）

难题 #5：流式渲染为什么会卡死浏览器？

问题背景

你兴高采烈地实现了 AI 流式生成 Excalidraw 场景，测试时一切正常（159 个 tokens）。

但当你用复杂 prompt 时，收到了 1134 个 tokens，然后...

浏览器崩溃了。

控制台显示"此页面存在问题"，CPU 100%，内存爆炸。

但后端测试显示 API 完全正常！问题出在哪？

理论基础：Server-Sent Events (SSE)

我们的流式渲染基于 W3C Server-Sent Events (SSE) 标准 [5](#5)，这是 HTML5 规范的一部分，用于服务器向客户端推送实时数据。

SSE vs WebSocket vs Long Polling
技术 协议 双向通信 浏览器支持 适用场景
SSE HTTP/1.1 单向（服务器→客户端） 95%+ 实时通知、AI 流式输出
WebSocket WS/WSS 双向 98%+ 聊天、游戏、协作编辑
Long Polling HTTP 模拟双向 100% 旧浏览器兼容

SSE 的优势：

  • ✅ 协议简单（基于 HTTP，无需特殊握手）
  • ✅ 自动重连（浏览器内置）
  • ✅ 事件 ID 支持（断线续传）
  • ✅ 与 RESTful API 兼容

SSE 标准格式（RFC 8 draft）：

复制代码 
data: This is a message\n\n

event: custom-event\n
data: {"key": "value"}\n\n

id: 123\n
data: Can resume from here\n\n
React 性能优化：Batching vs Throttling

我们的性能问题涉及两个前端性能优化概念：

A. Automatic Batching (React 18) [14](#14)

  • React 18 引入的自动批处理特性
  • 将多个 setState 合并为一次重渲染
  • 但高频 setState 仍会导致性能问题

B. Throttling vs Debouncing [15](#15)

  • Throttling（节流）：限制函数执行频率（如每 50ms 执行一次）
  • Debouncing（防抖）：延迟执行，只执行最后一次（如输入框搜索）
  • 我们使用 Throttling：每 50 tokens 更新一次 UI

致命错误：在循环中动态导入模块

检查前端代码，你发现：

typescript 复制代码 
// ❌ 致命错误：每个 token 都会动态导入一次！
for (const token of tokens) {
  const { safeParsePartialJson } = await import("@/lib/excalidrawUtils");
  // 解析 token...
}

如果收到 1134 个 tokens → 动态导入 1134 次！

每次导入都会：

  • 创建新的模块实例
  • 分配内存
  • 执行模块代码

结果：内存爆炸 + CPU 100% + 浏览器崩溃

三个致命的性能杀手

杀手 #1：循环中动态导入
typescript 复制代码 
// ❌ 错误（导入 1134 次）
for (const token of tokens) {
  const utils = await import("@/lib/utils");
}

// ✅ 正确（只导入 1 次）
const utils = await import("@/lib/utils");
for (const token of tokens) {
  // 使用 utils...
}
杀手 #2：每个 Token 都解析 JSON
typescript 复制代码 
// ❌ 错误（解析 1134 次）
for (const token of tokens) {
  buffer += token;
  const parsed = JSON.parse(buffer);  // 每次都解析！
}

// ✅ 正确（降低频率，每 50 tokens 解析一次）
let tokenCount = 0;
for (const token of tokens) {
  buffer += token;
  tokenCount++;

  if (tokenCount % 50 === 0) {  // 降频！
    const parsed = safeParsePartialJson(buffer);
  }
}

效果 ：从 1134 次解析 → 约 23 次解析（98% ↓）

杀手 #3：每个 Token 都更新 UI
typescript 复制代码 
// ❌ 错误（1134 次 setState，触发 1134 次重渲染）
for (const token of tokens) {
  setScene(parseScene(buffer));  // 每次都触发重渲染！
}

// ✅ 正确（降低频率，每 20 tokens 更新一次）
let tokenCount = 0;
for (const token of tokens) {
  tokenCount++;

  if (tokenCount % 20 === 0) {  // 降频！
    setScene(parseScene(buffer));
  }
}

效果 ：从 1134 次 UI 更新 → 约 57 次更新（95% ↓）

我们的完整修复方案

typescript 复制代码 
// frontend/lib/store/useArchitectStore.ts

generateExcalidrawSceneStream: async (prompt) => {
  // ✅ 关键 1: 只在函数开始时导入一次（不要在循环中！）
  const { safeParsePartialJson, sanitizeExcalidrawData } = await import("@/lib/excalidrawUtils");

  let accumulatedJson = '';
  let tokenCount = 0;

  const response = await fetch('/api/generate-stream', {...});
  const reader = response.body.getReader();
  const decoder = new TextDecoder();

  while (true) {
    const { done, value } = await reader.read();
    if (done) break;

    const chunk = decoder.decode(value);
    const lines = chunk.split('\n');

    for (const line of lines) {
      if (line.startsWith('data: [TOKEN]')) {
        const token = line.replace('data: [TOKEN]', '').trim();
        accumulatedJson += token;
        tokenCount++;

        // ✅ 关键 2: 降低解析频率（每 50 tokens）
        if (tokenCount % 50 === 0) {
          const parsed = safeParsePartialJson(accumulatedJson);
          if (parsed?.elements) {
            // ✅ 关键 3: 降低 UI 更新频率（每 50 tokens）
            set({ excalidrawScene: parsed });
          }
        }

        // ✅ 关键 4: 降低日志频率（每 100 tokens）
        if (tokenCount % 100 === 0) {
          console.log(`[Streaming] Tokens: ${tokenCount}, Accumulated: ${accumulatedJson.length} chars`);
        }

        // ✅ 关键 5: 降低进度提示更新频率（每 20 tokens）
        if (tokenCount % 20 === 0) {
          set(state => {
            const logs = [...state.generationLogs];
            if (logs.length > 0 && logs[logs.length - 1].startsWith("🤖")) {
              logs[logs.length - 1] = `🤖 Generating... (${tokenCount} tokens)`;
            }
            return { generationLogs: logs };
          });
        }
      }
    }
  }
}

性能对比

操作 修复前 修复后 优化比例
模块导入 1134 次 1 次 99.9% ↓
JSON 解析 1134 次 ~23 次 98% ↓
日志打印 1134 行 ~11 行 99% ↓
UI 更新 1134 次 ~57 次 95% ↓
结果 浏览器崩溃 流畅显示 ✅ 完美

流式渲染的黄金法则

  1. 永远不要在循环中使用 dynamic import

    typescript 复制代码 
    // ❌ 致命错误
for (...) {
  const module = await import("...");
}

// ✅ 正确
const module = await import("...");
for (...) { ... }

  2. 降低高频操作的执行频率

    • 解析：每 50-100 tokens
    • UI 更新：每 20-50 tokens
    • 日志：每 100 tokens

  3. 使用节流（throttle）或采样（sampling）

    typescript 复制代码 
    if (tokenCount % 50 === 0) {  // 采样
  // 执行昂贵操作
}

  4. React 状态更新要批量处理

    typescript 复制代码 
    // ❌ 多次 setState
setA(valueA);
setB(valueB);
setC(valueC);

// ✅ 批量更新
set(state => ({
  a: valueA,
  b: valueB,
  c: valueC
}));

  5. 大数据量场景必须进行压力测试

    • 小数据（< 200 tokens）：可能正常
    • 大数据（> 1000 tokens）：可能崩溃
    • 必须测试极端情况

推荐方案总结

场景 推荐方案
聊天应用 纯文本流式（最简单）
代码生成 增量 JSON 解析 + 降频优化 ⭐
图形生成 服务端增量发送（最可靠）

最佳实践：

  • ✅ Import 工具只在函数开始时
  • ✅ 解析频率降低到每 50-100 tokens
  • ✅ UI 更新频率降低到每 20-50 tokens
  • ✅ 日志频率降低到每 100 tokens
  • ✅ 大数据量场景必须压力测试
  • ✅ 使用 useMemo 缓存解析结果

难题 #6：AI 生成的节点为什么总是重叠？

问题背景

你让 AI 把一张流程图截图转成架构图，结果生成的节点重叠率高达 26.8%！

节点挤在一起，完全无法使用。

你在 Prompt 里明明写了：

复制代码 
Requirements:
- Minimum 220px horizontal spacing
- Minimum 160px vertical spacing

但 AI 生成的节点间距只有 183px！

为什么 AI 不遵守规则？

问题的本质：Prompt 太模糊

"Minimum 220px spacing" 对你来说很清楚，但对 AI 来说是模糊的：

  • 220px 是指中心距离还是边缘距离？
  • 节点宽度是多少？矩形？圆形？
  • 怎么计算？有公式吗？

AI 需要的是精确的公式，而不是模糊的要求。

理论基础：AABB 碰撞检测算法

我们的后端修复策略使用了计算机图形学和游戏开发领域的经典算法：AABB (Axis-Aligned Bounding Box) 碰撞检测 [10](#10)。

AABB 算法原理

AABB 是最简单高效的 2D 碰撞检测算法，时间复杂度 O(1)，广泛应用于：

  • 游戏引擎：Unity、Unreal Engine 的物理系统
  • UI 框架：React Flow、Excalidraw 的元素定位
  • CAD 软件：AutoCAD、SolidWorks 的对象选择

核心思想：将所有形状简化为矩形边界框（Bounding Box），检测两个矩形是否重叠。

数学公式：

复制代码 
两个矩形 A 和 B 不重叠，当且仅当：
  A.right < B.left  OR
  B.right < A.left  OR
  A.bottom < B.top  OR
  B.bottom < A.top

反之，重叠条件为：
  NOT (A.right < B.left) AND
  NOT (B.right < A.left) AND
  NOT (A.bottom < B.top) AND
  NOT (B.bottom < A.top)

优势：

  • ✅ 极快（纯算术运算，无需三角函数）
  • ✅ 精确（保证无漏检）
  • ✅ 简单（易于实现和调试）
更高级的碰撞检测算法（可选扩展）

对于复杂形状（圆形、多边形），可以使用：

  • GJK (Gilbert-Johnson-Keerthi)：通用凸多边形碰撞检测
  • SAT (Separating Axis Theorem)：多边形碰撞检测
  • Circle-Circle Detection：欧几里得距离公式

但在 2D 节点布局场景中，AABB 已经足够。

业界有哪些方案？

方案 A：AI 自我约束（Prompt 优化）

在 Prompt 中提供精确的布局规则和验证算法，让 AI 生成前自我检查。

python 复制代码 
prompt = f"""
**STRICT PRIORITIES (Non-Negotiable Order):**
1. PRIORITY 1: Zero Coordinate Collisions
2. PRIORITY 2: Minimum Spacing Enforcement
   - Horizontal: 220px (center to center)
   - Vertical: 160px (center to center)
3. PRIORITY 3: Preserve Layout

**NODE DIMENSIONS:**
- Rectangle: 180px × 60px
- Circle: 60px × 60px
- Diamond: 80px × 80px

**SPACING CALCULATION FORMULA:**
Horizontal neighbors (same row):
Node1.x + Node1.width + 20px gap + Node2.width/2 ≤ Node2.x

Example: Node1 at x=100 (width 180)
→ Node2.x must be ≥ 100 + 180 + 20 + 90 = 390 MINIMUM

**PRE-OUTPUT VALIDATION (MANDATORY):**
Step 1: List all N*(N-1)/2 node pairs
Step 2: For each pair (i, j):
  - Calculate dx = |center_i.x - center_j.x|
  - Calculate dy = |center_i.y - center_j.y|
  - If in same row (dy < 80): verify dx ≥ 220px
  - If in same column (dx < 80): verify dy ≥ 160px
Step 3: If violations: STOP and adjust coordinates
Step 4: Only output JSON when 100% pass
"""

优点：

  • ✅ AI 生成时就正确（无需后处理）
  • ✅ 保持原始布局意图

缺点：

  • ⚠️ 依赖 AI 能力（成功率 70-85%）

成功率：70-85%

方案 B：后端碰撞检测修复（推荐⭐）

AI 自由生成，后端检测并修复所有碰撞。

python 复制代码 
def fix_node_overlaps(nodes: List[Node]) -> List[Node]:
    """
    Simple Collision Detection Algorithm

    Algorithm:
    1. Process nodes in order
    2. For each node, check if it overlaps with ANY placed node
    3. If overlap: push right (or wrap to next row)
    4. Keep checking until no overlaps
    """

    MIN_H_SPACING = 220  # px (center to center)
    MIN_V_SPACING = 160  # px
    MIN_GAP = 20         # px buffer

    placed_nodes = []

    for node in nodes:
        x, y = node.position.x, node.position.y
        max_iterations = 20

        for iteration in range(max_iterations):
            # 收集所有重叠节点
            overlapping = []
            for placed in placed_nodes:
                if check_collision(node, placed, dims, MIN_GAP):
                    overlapping.append(placed)

            if not overlapping:
                break  # 无碰撞，放置成功

            # 推到最右侧重叠节点右边
            rightmost = max(overlapping, key=lambda n: n.position.x)
            x = rightmost.position.x + rightmost_width + MIN_H_SPACING

            # Canvas 宽度限制：1400px 换行
            if x > 1400:
                x = 100
                y += 200  # 下一行

            node.position.x = x
            node.position.y = y

        placed_nodes.append(node)

    return placed_nodes

def check_collision(n1, n2, dims, buffer):
    """Bounding box collision detection"""
    # 计算边界
    x1_left, x1_right = n1.position.x, n1.position.x + dims[n1.type]["width"]
    y1_top, y1_bottom = n1.position.y, n1.position.y + dims[n1.type]["height"]

    x2_left, x2_right = n2.position.x, n2.position.x + dims[n2.type]["width"]
    y2_top, y2_bottom = n2.position.y, n2.position.y + dims[n2.type]["height"]

    # 检查重叠（加 buffer）
    h_overlap = not (x1_right + buffer < x2_left or x2_right + buffer < x1_left)
    v_overlap = not (y1_bottom + buffer < y2_top or y2_bottom + buffer < y1_top)

    return h_overlap and v_overlap

优点：

  • ✅ 100% 成功率（保证无碰撞）
  • ✅ 不依赖 AI 能力
  • ✅ 可预测的行为

缺点：

  • ⚠️ 可能破坏原始布局（推移距离可能过大）

成功率：100%

方案 C：自动布局算法（dagre/elk）

AI 只生成节点和边的逻辑关系，使用专业布局算法计算位置。

typescript 复制代码 
import dagre from 'dagre';

function autoLayout(nodes, edges) {
  const g = new dagre.graphlib.Graph();
  g.setGraph({
    rankdir: 'TB',
    nodesep: 100,
    ranksep: 150
  });

  nodes.forEach(node => g.setNode(node.id, { width: node.width, height: node.height }));
  edges.forEach(edge => g.setEdge(edge.source, edge.target));

  dagre.layout(g);

  return nodes.map(node => ({
    ...node,
    position: { x: g.node(node.id).x, y: g.node(node.id).y }
  }));
}

优点：

  • ✅ 最美观的布局
  • ✅ 支持复杂图结构

缺点：

  • ❌ 完全丢失原始布局

适用场景：纯逻辑图生成

我们的实战经验：多层防御策略

在 SmartArchitect 项目中，我们采用方案 A + B（Prompt 优化 + 后端修复）：

1. Prompt 层（参考 FlowPilot）：

我们分析了开源项目 FlowPilot（90% 布局相似度），学习了它的 Prompt 设计模式：

  • 严格的优先级系统：碰撞检测 > 间距要求 > 布局保持
  • 精确的参数表格：所有节点类型的宽高
  • 算法化的验证清单：逐步检查所有 N*(N-1)/2 对

2. 后端层（100% 兜底保证）：

python 复制代码 
# 应用到所有图片转图端点
result.nodes = fix_node_overlaps(result.nodes)

效果：

指标 优化前 优化后
重叠率 26.8% 0% ✅
布局相似度 30% 75% ✅
AI 正确率 ~20% 70-85% (预期)

碰撞检测的关键技术细节

1. 使用 Bounding Box 检测，不要用中心距离
python 复制代码 
# ❌ 错误：只比较中心距离
dx = abs(node1.center.x - node2.center.x)
if dx < MIN_SPACING:
    collision = True

# ✅ 正确：Bounding Box 检测
x1_right = node1.x + node1.width
x2_left = node2.x
h_overlap = not (x1_right + BUFFER < x2_left or x2_right + BUFFER < x1_left)
2. 推移算法要收集所有重叠节点
python 复制代码 
# ❌ 错误：只推过第一个重叠节点
for placed in placed_nodes:
    if check_collision(node, placed):
        node.x = placed.x + placed.width + MIN_SPACING
        break  # ❌ 停止检查，可能还有其他重叠！

# ✅ 正确：收集所有重叠节点，推到最右边
overlapping = [p for p in placed_nodes if check_collision(node, p)]
if overlapping:
    rightmost = max(overlapping, key=lambda n: n.position.x)
    node.x = rightmost.x + rightmost.width + MIN_SPACING
3. Canvas 宽度限制要换行
python 复制代码 
if x > 1400:  # 超过 canvas 宽度
    x = 100      # 回到左边
    y += 200     # 下一行

推荐方案总结

场景 推荐方案 布局保持 碰撞率
图片转图 方案 A + B ⭐ 75% 0%
逻辑图生成 方案 C (dagre) 0% 0%
快速原型 方案 B 50% 0%

最佳实践：

  • ✅ 多层防御（AI 约束 + 后端兜底）
  • ✅ Prompt 提供精确公式（不要模糊描述）
  • ✅ 使用 Bounding Box 检测（不要 center 距离）
  • ✅ 后端日志记录修复情况（持续优化）
  • ✅ 考虑用户场景（是否需要保持布局）

特别篇：Excalidraw Prompt 工程的黄金法则

为什么 Excalidraw Prompt 值得单独讲？

Excalidraw 是一个非常复杂的 JSON 结构（每个元素有 20+ 个字段），AI 生成时很容易出错。这使得它成为 Prompt Engineering 的极限挑战场景，能够全面检验我们的 Prompt 设计能力。

Prompt 设计的理论框架

我们的 Excalidraw Prompt 综合运用了以下学术研究和工业实践：

1. Role Prompting（角色提示）

理论来源 ：OpenAI Prompt Engineering Best Practices[2](#2)

定义：通过明确指定角色身份，激活模型在预训练中学到的相关领域知识。

实证研究：

  • "Persona-based Prompting" 研究表明，角色定义能使生成内容与任务领域更相关（相关性提升 30-40%）
  • 角色越具体，效果越好："You are an expert" < "You are an Excalidraw expert"

我们的应用：

复制代码 
You are an Excalidraw expert. Produce a finished, readable diagram as pure JSON (no prose).
2. Instruction Hierarchy（指令层级）

理论来源 ：Anthropic Prompt Engineering Guide[3](#3)

定义：按优先级从高到低排列指令，防止后续指令覆盖关键约束。

标准结构：

  1. OUTPUT FORMAT（最高优先级）：定义输出格式
  2. CRITICAL RULES（核心约束）：不可违反的规则
  3. REQUIRED ELEMENTS（必需内容）：数量和类型要求
  4. LAYOUT & STYLE（配置参数）：可调整的参数
  5. USER REQUEST（任务描述）：最后才是用户需求

为什么这样排列：

  • AI 倾向于优先处理前面的指令
  • 用户需求可能含糊，放在最后避免覆盖系统规则
3. Constrained Generation（约束生成）

理论来源 ：CTRL 论文 (Keskar et al., 2019)[11](#11)

定义：限定生成空间，减少模型的随机性和错误率。

约束类型：

  • 枚举约束 ：choose from ["A", "B", "C"]
  • 数值约束 ：Total 12-18 elements
  • 格式约束 ：must be valid JSON

效果验证：

  • 无约束：错误率 60-70%
  • 有约束：错误率 20-30%
  • 错误率降低 40-60%

我们的应用：

复制代码 
strokeColor: choose from ["#1e1e1e","#2563eb","#dc2626","#059669"]
backgroundColor: choose from ["transparent","#a5d8ff","#fde68a","#bbf7d0"]
Total 12-18 elements. At least 6 shape nodes, 4 connectors, 2 text labels.
4. Schema-First Design（架构优先）

理论来源：我们的实践经验 + JSON Schema 验证标准

定义：在 Prompt 开头立即展示完整的目标结构，让 AI"看到"期望输出。

心理学原理：

  • 模型倾向于模仿它"看到"的结构
  • 预先定义结构 > 事后描述结构

我们的应用：

json 复制代码 
OUTPUT FORMAT (must be valid JSON):
{
  "elements": [...],
  "appState": {},
  "files": {}
}
5. Self-Verification（自我验证）

理论来源 ：Chain-of-Thought Prompting (Wei et al., 2022)[12](#12)

定义：要求模型在输出前执行显式验证步骤。

我们的改进 ：结构化验证清单（比 CoT 更适合生成任务）

标准模板：

复制代码 
BEFORE OUTPUT:
1. Verify: Total elements in range?
2. Verify: All required fields present?
3. Verify: JSON syntax valid?
4. If ANY violation: STOP and fix
5. Only output when 100% pass
6. Negative Prompting（负面约束）

理论来源：Stable Diffusion 社区实践 + GPT-4 官方文档

定义：明确告诉 AI"不要做什么"，补充正面指令。

为什么有效：

  • 正面指令：AI 知道"目标"
  • 负面指令：AI 知道"边界"
  • 两者结合：减少意外行为

我们的应用：

复制代码 
✅ DO: Use basic shapes (rectangle, ellipse, diamond)
❌ DO NOT: Return images/icons/photos
❌ DO NOT: Stop generation early
❌ DO NOT: Add explanatory text outside JSON

我们的 Excalidraw Prompt 完整代码

这是 SmartArchitect 项目中的实际生产代码（backend/app/services/excalidraw_generator.py:125-162），融合了上述 6 个理论框架：

python 复制代码 
def _build_prompt(self, prompt: str, style: Optional[str], width: int, height: int) -> str:
    """
    Build Excalidraw generation prompt.

    Theory Framework:
    1. Role Prompting (OpenAI Best Practices)
    2. Instruction Hierarchy (Anthropic Guide)
    3. Constrained Generation (CTRL paper)
    4. Schema-First Design (JSON Schema)
    5. Self-Verification (CoT variant)
    6. Negative Prompting (GPT-4 practices)
    """
    return f"""You are an Excalidraw expert. Produce a finished, readable diagram as pure JSON (no prose).

OUTPUT FORMAT (must be valid JSON):
{{
  "elements": [...],
  "appState": {{}},
  "files": {{}}
}}

CRITICAL RULES:
1) For "line"/"arrow": include "points" (e.g. [[0,0],[50,50]]) and set "startArrowhead"/"endArrowhead" when directional.
2) Every element must have: id (string), type, x, y, width, height, angle, strokeColor, backgroundColor, fillStyle, strokeWidth, strokeStyle, roughness, opacity, groupIds (array), boundElements (array), seed, version, versionNonce, isDeleted=false.
3) Use "arrow" to connect shapes; prefer "text" for labels (include "text", "fontSize", "textAlign").
4) Do NOT return images/icons; use basic shapes and arrows only. Ensure the JSON is closed (ends with "}}}").

REQUIRED ELEMENT MIX:
- Total 12-18 elements.
- At least 6 shape nodes (rectangle/ellipse/diamond) for the main content.
- At least 4 connectors (arrow/line) linking the shapes into a flow.
- At least 2 text labels to annotate nodes or flows.

LAYOUT:
- Canvas: {width}x{height}px. Keep a 40px margin; avoid overlap; distribute nodes evenly left-to-right/top-to-bottom.
- Make connectors clean and direct; avoid zero-length points.

STYLE (hand-drawn):
- strokeColor: choose from ["#1e1e1e","#2563eb","#dc2626","#059669"]
- backgroundColor: choose from ["transparent","#a5d8ff","#fde68a","#bbf7d0"]
- fillStyle: "hachure" or "solid"; roughness: 1 for sketch feel; strokeWidth: 2.

USER REQUEST: "{prompt}"

Return ONLY the JSON structure above. Generate the full set of elements; do not stop early."""

黄金法则解析：理论到实践的映射

让我们解析这个 Prompt 如何应用前面的 6 个理论框架：

Prompt 部分 对应理论 核心作用 效果提升
You are an Excalidraw expert Role Prompting ^[2](#1e1e1e",...] Constrained Generation11 限定选择空间 错误率 -40-60% OUTPUT FORMAT 代码块 Schema-First Design 预先展示结构 格式正确率 +20% Do NOT return images/icons Negative Prompting 明确边界 减少意外行为 Total 12-18 elements Self-Verification 数量验证 输出完整性 +15%)^ 激活领域知识 相关性 +30-40%
OUTPUT FORMAT → USER REQUEST Instruction Hierarchy ^[3](#1e1e1e",...] Constrained Generation11 限定选择空间 错误率 -40-60% OUTPUT FORMAT 代码块 Schema-First Design 预先展示结构 格式正确率 +20% Do NOT return images/icons Negative Prompting 明确边界 减少意外行为 Total 12-18 elements Self-Verification 数量验证 输出完整性 +15%)^ 优先级排序 避免规则冲突
choose from ["#1e1e1e",...] Constrained Generation ^[11](#1e1e1e",...] Constrained Generation11 限定选择空间 错误率 -40-60% OUTPUT FORMAT 代码块 Schema-First Design 预先展示结构 格式正确率 +20% Do NOT return images/icons Negative Prompting 明确边界 减少意外行为 Total 12-18 elements Self-Verification 数量验证 输出完整性 +15%)^ 限定选择空间 错误率 -40-60%
OUTPUT FORMAT 代码块 Schema-First Design 预先展示结构 格式正确率 +20%
Do NOT return images/icons Negative Prompting 明确边界 减少意外行为
Total 12-18 elements Self-Verification 数量验证 输出完整性 +15%

这些理论的通用性

这 6 个理论框架不仅适用于 Excalidraw，也适用于：

✅ 代码生成：

  • Role: "You are a Python expert"
  • Hierarchy: Language → Framework → Libraries → Task
  • Constraint: "Use only Python 3.10+ features"

✅ JSON/XML 生成：

  • Schema-First: 展示完整 JSON 结构
  • Verification: "Verify all required fields present"
  • Negative: "Do NOT include comments"

✅ 图形设计：

  • Constraint: 限定元素类型、颜色、数量
  • Hierarchy: 格式 → 样式 → 内容 → 用户需求

✅ 复杂结构化输出：

  • Role + Schema + Constraint + Verification = 高质量输出

核心设计原则总结

1. 具体 > 模糊

  • ❌ "合理间距"
  • ✅ "40px margin"

2. 限定 > 开放

  • ❌ "choose a color"
  • ✅ "choose from ['#1e1e1e', '#2563eb']"

3. 简洁 > 详细

  • 30 行核心规则 > 200 行详细说明
  • OpenAI 实践：简洁清晰的指令比冗长的描述更有效

4. 分层 > 平铺

  • OUTPUT FORMAT → CRITICAL RULES → LAYOUT → USER REQUEST
  • 不要把所有规则堆在一起

5. 验证 > 信任

  • 多层 JSON 修复（正则 → 库 → 补全）

  • Mock Fallback 保证永远有输出
    }

    为什么这样写：

    • AI 看到目标结构，知道要生成什么
    • 避免 AI 自己"创造"结构

    3. CRITICAL RULES 列出绝对约束

CRITICAL RULES:

  1. For "line"/"arrow": include "points" ...

  2. Every element must have: id, type, x, y, ...

  3. Use "arrow" to connect shapes; ...

  4. Do NOT return images/icons; ...

    为什么这样写：

    • "CRITICAL" 强调重要性
    • 编号清晰，易于验证
    • 包含正面指令（"must have"）和负面指令（"Do NOT"）

    4. REQUIRED ELEMENT MIX 保证输出质量

REQUIRED ELEMENT MIX:

  • Total 12-18 elements.

  • At least 6 shape nodes ...

  • At least 4 connectors ...

  • At least 2 text labels ...

    为什么这样写：

    • 防止 AI 生成太少元素（< 6 个）或太多元素（> 50 个）
    • "at least" 保证最低标准

    5. LAYOUT 提供精确的布局参数

LAYOUT:

  • Canvas: {width}x{height}px.

  • Keep a 40px margin; avoid overlap; distribute nodes evenly ...

  • Make connectors clean and direct; avoid zero-length points.

    为什么这样写：

    • 具体数字（40px margin）比"合理边距"更清楚
    • "avoid overlap" 明确指出要避免的问题

    6. STYLE 提供有限的选择范围

STYLE (hand-drawn):

  • strokeColor: choose from ["#1e1e1e","#2563eb","#dc2626","#059669"]

  • backgroundColor: choose from ["transparent","#a5d8ff","#fde68a","#bbf7d0"]

  • fillStyle: "hachure" or "solid"; roughness: 1; strokeWidth: 2.

    为什么这样写：

    • 限定选择范围（4 种颜色）防止 AI 乱选
    • 提供具体值（roughness: 1）防止 AI 随机生成

    7. USER REQUEST 放在最后

USER REQUEST: "{prompt}"

复制代码 
**为什么这样写**：
- 先设定规则，再给任务
- 避免用户请求覆盖系统规则

#### 8. 结尾强调"只返回 JSON"

Return ONLY the JSON structure above. Generate the full set of elements; do not stop early.

复制代码 
**为什么这样写**：
- "ONLY" 防止 AI 添加解释
- "do not stop early" 防止 AI 截断输出

#### 9. 参考 FlowPilot 的"简洁哲学"

FlowPilot 项目（90% 布局相似度）的核心经验：

> **简洁 > 详细**

不要写 200 行的详细规则，而是：
- 30-40 行核心规则
- 清晰的分层（OUTPUT FORMAT、CRITICAL RULES、LAYOUT、STYLE）
- 具体的数字和选项

#### 10. 验证策略：多层 JSON 修复 + Mock Fallback

即使 Prompt 完美，AI 仍可能出错。我们使用：

```python
def _safe_json(payload):
    # 层级 1: 直接解析
    # 层级 2: 正则修复
    # 层级 3: 补全括号
    # 失败：返回 None

def _validate_scene(ai_data):
    if ai_data is None:
        return self._mock_scene()  # Fallback

效果：

  • AI 生成成功 → 显示 AI 生成的场景
  • AI 生成失败 → 显示 mock 场景（猫脸图标）
  • 用户永远看到有效输出

这些法则的通用性

这 10 个法则不仅适用于 Excalidraw，也适用于：

  • 代码生成：明确语言、框架、输出格式
  • JSON/XML 生成：展示结构、列出必需字段
  • 图形生成：限定元素类型、数量范围
  • 复杂结构化输出：分层、编号、具体数字

核心原则：

  • ✅ 具体 > 模糊（"40px margin" > "合理边距"）
  • ✅ 限定 > 开放（"choose from [A, B, C]" > "choose a color"）
  • ✅ 简洁 > 详细（30 行核心规则 > 200 行详细说明）
  • ✅ 分层 > 平铺（CRITICAL RULES、LAYOUT、STYLE）
  • ✅ 验证 > 信任（多层修复 + Mock Fallback）

💡 想体验完整的 AI 图形应用？

SmartArchitect AI 是一个开源的 AI 驱动架构图设计平台，完整实现了本文所有技术方案：

✨ 核心功能：

  • 🎨 多模态输入：支持自然语言、图片、Mermaid 代码生成架构图
  • 🔄 增量编辑：智能追加节点，自动修复冲突
  • ⚡ 流式渲染：实时显示 AI 生成过程，无卡顿
  • 🎯 零重叠保证：后端自动修复节点碰撞
  • 📊 多格式导出：支持 PPT、Slidev、Excalidraw
  • 🧠 RAG 知识库：上传文档，AI 基于领域知识生成

🔗 项目地址：https://github.com/luguochang/SmartArchitect

⭐ 如果本文对你有帮助，请给项目一个 Star！

你的支持是我们持续更新和开源的最大动力 🙏

技术栈：

  • 后端：FastAPI + ChromaDB + OpenAI/Claude/Gemini API
  • 前端：Next.js 14 + React Flow + Excalidraw
  • 测试：pytest 测试覆盖率 97%+

总结：AI 图形应用开发的 6 大经验

经过半年的实战，我们总结出以下核心经验：

1. 流式 API 兼容性

  • ✅ 使用双模式（SDK + Raw HTTP）
  • ✅ 维护黑名单（2-3 个问题代理）
  • ✅ 真实流式用 aiter_bytes()，不要用 aiter_lines()

2. JSON 格式修复

  • ✅ 使用多层防御（正则 → 库 → Fallback）
  • ✅ 业务层提供 Mock Fallback（永远有输出）
  • ❌ 避免 LLM 二次修复（成本高、延迟大）

3. Prompt 工程

  • ✅ Few-Shot 最有效（30% → 70% 成功率）
  • ✅ 提供精确公式，不要模糊描述
  • ✅ 添加自我验证清单（提升 10-15%）
  • ✅ 分层设计便于长期维护

4. 增量生成

  • ✅ 先用全量生成 + 验证（1 天实现）
  • ✅ 添加 Few-Shot 示例（提升 20-30%）
  • ⏳ Token 成本 > $100/天时考虑 Diff-based

5. 流式渲染

  • ❌ 永远不要在循环中使用 dynamic import
  • ✅ 降低高频操作频率（解析、日志、UI 更新）
  • ✅ 大数据量场景必须压力测试

6. 碰撞检测

  • ✅ 多层防御（AI 约束 + 后端兜底）
  • ✅ 使用 Bounding Box 检测，不要用中心距离
  • ✅ 后端日志记录修复情况（持续优化）

写在最后：持续学习和分享

AI 应用开发是一个快速变化的领域，今天的最佳实践明天可能就过时了。我们会持续更新这份文档，分享更多实战经验。

如果你也在做 AI 图形应用，欢迎交流！你可以：

  • ⭐ Star 项目：https://github.com/luguochang/SmartArchitect
  • 💬 提 Issue：在 GitHub Issues 中分享你的经验和问题
  • 🔀 贡献代码：欢迎提交 Pull Request
  • 📧 技术交流：通过 GitHub Discussions 讨论技术问题

让我们一起推动 AI 图形应用的发展！

🌟 觉得有帮助？请给项目一个 Star！🌟

SmartArchitect AI on GitHub

参考文献与延伸阅读

本文基于以下学术论文、工业标准和官方文档：

学术论文

工业标准与规范

  • 项目链接: https://json5.org/
  • 更宽松的 JSON 解析标准，支持注释和尾随逗号

官方文档与最佳实践

安全与架构

  • 纵深防御安全策略，应用于多层容错设计
  • AABB (Axis-Aligned Bounding Box) 碰撞检测算法
  • 计算机图形学和游戏开发领域的经典教材

延伸阅读

Prompt Engineering 进阶：

  • White, J., et al. (2023). "A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT". arXiv:2302.11382.
  • Liu, P., et al. (2023). "Pre-train, Prompt, and Predict: A Systematic Survey of Prompting Methods in NLP". ACM Computing Surveys.

AI 应用开发：

前端性能优化：

📚 关于 SmartArchitect AI

SmartArchitect AI 是一个开源的 AI 驱动架构图设计平台，本文所有技术方案均已在生产环境中验证。

  • 🔗 项目地址: https://github.com/luguochang/SmartArchitect
  • 📖 文档维护: SmartArchitect Team
  • 📅 最后更新: 2026-02-09
  • 📌 版本: 1.1 (专业版)
  • 🙏 致谢: 感谢所有开源社区和学术界的贡献

⭐ 如果觉得有用，请给项目一个 Star 支持我们！
SmartArchitect AI on GitHub

  1. Brown, T. B., Mann, B., Ryder, N., et al. (2020). "Language Models are Few-Shot Learners" . NeurIPS 2020 . ↩︎ ↩︎ ↩︎

  2. OpenAI. (2023). "GPT Best Practices - Prompt Engineering" . ↩︎ ↩︎ ↩︎ ↩︎

  3. Anthropic. (2024). "Prompt Engineering with Claude" . ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  4. Fielding, R., & Reschke, J. (2014). "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content - RFC 7231" . IETF . ↩︎ ↩︎ ↩︎

  5. WHATWG. (2024). "Server-Sent Events" . HTML Living Standard . ↩︎ ↩︎

  6. NSA. (2012). "Defense in Depth: A practical strategy for achieving Information Assurance in today's highly networked environments" . ↩︎ ↩︎

  7. JSON5 Data Interchange Format. "JSON5 - JSON for Humans" . ↩︎ ↩︎

  8. Myers, E. W. (1986). "An O(ND) Difference Algorithm and Its Variations" . Algorithmica, 1 (1), 251-266. ↩︎ ↩︎

  9. Bryan, P., & Nottingham, M. (2013). "JavaScript Object Notation (JSON) Patch - RFC 6902" . IETF . ↩︎ ↩︎

  10. Ericson, C. (2004). "Real-Time Collision Detection" . Morgan Kaufmann Publishers . ↩︎ ↩︎

  11. Keskar, N. S., McCann, B., Varshney, L. R., et al. (2019). "CTRL: A Conditional Transformer Language Model for Controllable Generation" . arXiv preprint . ↩︎ ↩︎ ↩︎

  12. Wei, J., Wang, X., Schuurmans, D., et al. (2022). "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" . NeurIPS 2022 . ↩︎ ↩︎

  13. Grissom II, A., He, H., Boyd-Graber, J., et al. (2014). "Don't Until the Final Verb Wait: Reinforcement Learning for Simultaneous Machine Translation" . EMNLP 2014 . ↩︎

  14. React Team. (2022). "React 18: Automatic Batching" . ↩︎

  15. Corbacho, D. (2016). "Debouncing and Throttling Explained Through Examples" . ↩︎

相关推荐
九.九6 小时前
ops-transformer：AI 处理器上的高性能 Transformer 算子库
人工智能·深度学习·transformer
春日见6 小时前
拉取与合并：如何让个人分支既包含你昨天的修改，也包含 develop 最新更新
大数据·人工智能·深度学习·elasticsearch·搜索引擎
恋猫de小郭6 小时前
AI 在提高你工作效率的同时，也一直在增加你的疲惫和焦虑
前端·人工智能·ai编程
deephub6 小时前
Agent Lightning：微软开源的框架无关 Agent 训练方案，LangChain/AutoGen 都能用
人工智能·microsoft·langchain·大语言模型·agent·强化学习
偷吃的耗子7 小时前
【CNN算法理解】：三、AlexNet 训练模块(附代码)
深度学习·算法·cnn
大模型RAG和Agent技术实践7 小时前
从零构建本地AI合同审查系统：架构设计与流式交互实战（完整源代码）
人工智能·交互·智能合同审核
老邋遢7 小时前
第三章-AI知识扫盲看这一篇就够了
人工智能
互联网江湖7 小时前
Seedance2.0炸场：长短视频们“修坝”十年，不如AI放水一天？
人工智能
青云计划7 小时前
知光项目知文发布模块
java·后端·spring·mybatis
PythonPioneer7 小时前
在AI技术迅猛发展的今天，传统职业该如何“踏浪前行”？
人工智能
热门推荐
01GitHub 镜像站点02Claude Code + GLM4.7 避坑指南：解决 Unable to connect to Anthropic services03openclaw配置教程（linux+局域网ollama）04UV安装并设置国内源05Linux下V2Ray安装配置指南06openclaw使用nginx反代部署过程 与disconnected (1008): pairing required解决07AI 规范驱动开发“三剑客”深度对比：Spec-Kit、Kiro 与 OpenSpec 实战指南08【Linux操作系统12】Git版本控制与GDB调试：从入门到实践09Vue-skills的中文文档10OpenClaw Chrome扩展使用教程 - 浏览器中继控制