Architectural Diagram Prompts

Architectural Diagram Prompts

Overview

Convert messy source material into a strong image-generation prompt for a reference architecture diagram. Optimize for architecture logic first, then visual polish.

Workflow

1. Identify the source type: article, system description, product workflow, codebase, single code snippet, or existing diagram.
2. Extract architecture semantics before writing any image prompt.
3. Choose the diagram layout that matches the system shape.
4. Write a Chinese image prompt with explicit layout, modules, arrows, labels, visual style, and text-quality constraints.
5. If the user asks for an image, generate it after producing or internally preparing the prompt.

Output Contract

When the user asks for a prompt, return:

• 架构语义: compact bullets covering the extracted semantics.
• 图片提示词: one complete prompt ready to paste into an image model.
• 可选调整: only include when there are meaningful layout or style choices.

When the user asks for an image, prepare the same architecture prompt internally, then generate the image. Briefly mention the architecture choices afterward if useful.

Architecture Semantics

Extract these elements. Mark missing but useful inferred items as 推断 or 可选.

• 系统目标: what the system is trying to accomplish.
• 外部参与者: users, clients, upstream/downstream systems, third-party services.
• 入口层: request/API/event/UI entry points.
• 控制层: orchestration, routing, planning, scheduling, policy, state coordination.
• 核心执行层: services, agents, modules, workers, functions, pipelines.
• 能力层: tools, APIs, model calls, retrieval, memory, files, search, code execution.
• 状态与数据层: context, session, databases, vector stores, event history, knowledge bases.
• 外部集成: SaaS, payment, CRM, ERP, messaging, browser, infrastructure services.
• 横切能力: observability, logging, security, authorization, reliability, failure recovery, compliance, cost control.
• 主流程: 1-5 numbered path from input to output and feedback.

For code, infer from entry points, module boundaries, imports, call graph, I/O boundaries, persistence, external packages, runtime configuration, and error paths. Do not create a file-by-file inventory unless the user asks.

Layout Selection

Prefer 参考架构图 when the user wants an attractive system architecture image or gives broad system material:

• Top: title and subtitle.
• Left: users, input channels, external business systems.
• Center: main system, with control plane on top, execution modules in the middle, tools/data/memory below.
• Right: cross-cutting capabilities such as monitoring, reliability, security, governance.
• Bottom: foundation/infrastructure layer.
• Flow: solid arrows for sync/data flow, dashed arrows for async/events/feedback, circular markers for steps 1-5, legend at bottom.

Use simpler layouts only when the system is small:

• 分层图: clear stack, few modules, no complex feedback.
• 流程图: sequential process or pipeline.
• 组件关系图: module dependencies matter more than runtime flow.
• C4-style context/container: software boundary clarity matters more than visual infographic polish.

Prompt Rules

• Use Chinese labels by default; preserve necessary English terms such as API, SDK, Orchestrator, Agent, LLM.
• Keep labels short. Avoid paragraphs inside boxes.
• Describe spatial structure explicitly: left column, center body, right column, bottom band, arrows, legend.
• State that the image is not a simple layered diagram when using the reference architecture layout.
• Include text-quality constraints: readable Chinese, no garbled text, no fake logos, no watermark.
• Specify visual tone: technical whitepaper, clean light background, thin lines, aligned modules, restrained colors.
• For image models, repeat the most important structure once in compact form: 中心主流程 + 左侧输入/系统 + 右侧横切能力 + 底部基础设施 + 编号流程图例.
• If the source is ambiguous, state the most important assumptions instead of hiding them inside the diagram.

Template

For a full reusable prompt skeleton, read references/reference-architecture-template.md.