Archify 场景配方Scenario Recipes基于问题优先的图表模式选择层设计解析【免费下载链接】archifyAgent skill for beautiful, verifiable architecture, workflow, sequence,>项目地址: https://gitcode.com/GitHub_Trending/arch/archify导读面对 architecture、workflow、sequence、dataflow、lifecycle 五种图表渲染模式用户的真实问题往往不能直接映射到某个模式名称上。本篇文章以仓库内研究文档 docs/research-visual-evolution-round-4.md 为主体深入剖析 Archify 的问题优先question-first场景配方机制11 个预置配方如何把系统总览智能体工具调用数据血缘这类真实诉求翻译成带证据契约的图表任务以及archify guide命令如何通过加权双语信号做确定性推荐。读完你将掌握配方数据模型、推荐算法、CLI 用法与测试验收的全套细节并能在实际创作中用配方约束图表产出。问题背景五种模式可用但用户不知道该选哪个Archify 的能力边界是五类强类型图表而非通用绘图画布架构architecture、工作流workflow、时序sequence、数据流dataflow、生命周期lifecycle其类型路由表定义在 archify/SKILL.md 中。但本轮研究文档指出了一个现实困境Five renderer modes are useful only when a user can choose the right one.用户带着我想看清楚一次发布如何从提交走到生产这样的问题而来却必须先在内心完成一次问题 → 图表术语的翻译才能说得出我要一张 workflow 图。如果只给一个类型列表用户被迫学习图表行话如果提供一个包罗万象的通用画布又会诱导用户画出杂乱无章的全景图。本轮Visual Evolution Round 4日期 2026-07-19的目标就是在不动五种渲染器本体、不把 Archify 变成通用绘图平台的前提下加一层问题优先的选择层。外部研究的两个关键启示约束而非模仿研究文档记录了来自两个外部项目的方法论借鉴其核心结论是有用的不是加更多主题而是把每种视觉语言与一个有边界的问题和证据契约绑定。Fireworks Tech Graph视觉风格需要语义契约官方 style-to-diagram 矩阵并不认为每种风格适合每种图面向工程的风格需要领域证据例如 C4 层级与职责、部署归属与边界穿越、事件主题与消费者组、运维信号与故障路径。官方 composition quality contract 让可读性可度量展示画像showcase profile预算零连线交叉、零桥接、至多两次弯折、最小节点间距、容器留白其兜底策略是简化或拆分拓扑。这两条直接印证并强化了 Archify 既有的一条主路径one-main-path与小视图small-view规则——这些规则在 archify/SKILL.md 的创作不变量中体现为One obvious main pathat most 12 primary nodes等约束。Structurizr范围先于符号workspace scope 指导建议把工作区限定在单一软件系统内并警告all-in-one 工作区会变得杂乱。notation 指导刻意使用小词汇表方框 单向箭头并在所有视图中保持一致的样式。由此提炼出的有效理念是约束而非模仿每个配方只回答一个技术问题、保持稳定的视觉语法、提供显式的何时不要用avoid when文案。产品决策11 个小型场景配方覆盖五种既有模式依据上述研究本轮落地为 11 个场景配方分布在 Archify 既有的五种模式上不新增任何渲染器模式配方Architecturesystem overview系统总览deployment ownership部署与归属Workflowagent tool-call智能体工具调用delivery workflow研发交付流程incident runbook事故处置 RunbookSequenceAPI requestAPI 请求链async roundtrip异步往返链路Data flowdata lineage数据血缘event-stream topology事件流拓扑Lifecycleobject lifecycle对象生命周期deployment lifecycle部署生命周期每个配方都定义了六个要素它回答的确切问题question何时使用 / 何时不要使用useWhen / avoidWhen必须出现的四项证据include建议的表现预设、动效与引导视图用法presentation可直接复制的中英文提示词en.prompt / zh.prompt部分配方还带 start.descriptionPrompt 自然语言起步提示用于确定性推荐的加权双语信号signals每条信号带权重。配方数据模型的源码实现单一事实来源全部配方以数据形式定义在唯一的产品数据源 archify/recipes/scenarios.mjs 中。文件先定义RAW_RECIPES数组再通过Object.freeze深度冻结导出为SCENARIO_RECIPES保证运行时不可篡改L255-L265。一个配方的完整字段结构如下字段类型说明idstring小写连字符标识如system-overview同时是 CLI 精确匹配的目标typestring五种渲染模式之一architecture / workflow / sequence / dataflow / lifecycleproofstring该配方对应的仓库示例文件名结构参考非事实来源presentationobject{ preset, motion, views }三项表现建议startobject可选{ en, zh }两个descriptionPrompt用于无需代码库的自然语言起步signalsarray[信号词, 权重]二元组数组中英双语混排供推荐算法打分en/zhobject双语决策文案title / question / summary / useWhen / avoidWhen / include[4] / prompt表现建议presentation与源码的对应关系每个配方的presentation建议直接对应最终 JSON 的meta字段preset对应meta.visual_preset取值为classic、signal-flow、blueprint、editorialmotion对应meta.animationstatic或traceviews对应meta.views的推荐程度optional/recommended。例如system overviewclassicstatic views optional —— 高层概览用静态经典风格即可deployment ownershipblueprinttrace views recommended —— 部署图建议蓝图预设与轨迹动效其余大多数配方采用signal-flowtrace。动效trace在渲染端会写入 SVG 的data-animationtrace属性见 archify/renderers/shared/cli.mjs 的svgRootAttrs。双语起步提示start与仓库证据提示有 5 个配方system-overview、agent-tool-call、api-request、event-stream、object-lifecycle额外定义了start.descriptionPrompt用于用户在没有代码库时用自然语言起步。startPromptsForL271-L284还会为需要仓库证据的场景拼装第二段提示architecture 类型直接复用copy.prompt其他类型会追加先检查仓库证据、不要编造代码无法支持的行为的前缀英文版为Inspect this repository for evidence, then ... Do not invent behavior that the code does not support.。信号权重设计示例推荐算法的输入是带权重的双语信号。以三个配方为例system overviewsystem overview(12)、architecture(10)、trust boundary(8)、components(6)、repository(5)、services(4)、系统总览(12)、架构(10)、信任边界(8)……agent tool-callagent tool call(16)、tool call(12)、approval gate(10)、agent loop(10)、human in the loop(9)、mcp(7)、planner(6)、智能体工具调用(16)、工具调用(12)、审批门(10)……event-streamevent stream(15)、kafka topology(14)、consumer group(11)、dead letter(10)、dlq(10)、topic(8)、事件流(15)、kafka 拓扑(14)、消费者组(11)……权重越高表示该信号对该配方的区分度越强每个配方的信号数量不少于 8 条测试强制校验。确定性推荐算法不加 LLM 分类器推荐逻辑不依赖任何模型或网络服务完全是确定性的加权打分。核心实现在 recommendScenario流程如下语言检测detectGuideLanguageL267-L269用 Unicode 正则/[\u3400-\u9fff]/u判断查询是否含 CJK 字符从而决定默认返回中英文文案文本归一化normalizedL286-L288做 NFKC 归一化、转小写、空白与下划线折叠为单个空格精确匹配优先若归一化文本恰好等于配方 id或 id 去连字符形式直接得 100 分匹配命中该 idL309-L311信号加权打分否则遍历配方 signals凡查询文本包含某信号词即累加该信号权重L313-L320排序与置信度按分数降序、同分按原始顺序排序取第一名置信度规则为score 14 → high、score 7 → medium、否则lowL328诚实回退若第一名分数为 0回退到数组首位system-overview置信度low、匹配信号为空——宁可低置信度兜底也不假装猜中候选替代另取分数大于 0 的其他配方中至多两个作为alternatives供用户参考。此外还有两个面向输出的辅助函数formatScenarioList无查询时打印全部配方列表提示语为Run: archify guide your scenario/可运行archify guide 你的场景与formatScenarioRecommendation把推荐结果排版为推荐 / 要回答的问题 / 适合 / 不要这样用 / 必须包含 / 表现建议 / 可直接复制的提示词 / 其他可能等分节的中英文输出。archify guide零依赖的配方命令行配方层与 CLI 的衔接在 archify/bin/archify.mjs 的commandGuideL1428-L1479通过import(pathToFileURL(guidePath).href)动态导入recipes/scenarios.mjs因此guide命令不依赖任何node_modules用法为archify guide [scenario or question] [--json] [--lang en|zh]--lang只接受en或zh用于强制输出语言不传时由detectGuideLanguage依据查询内容自动判定不带查询参数时输出全部 11 个配方的id [type] title question列表--json则输出结构化listScenarioRecipes结果带查询参数时输出recommendScenario的推荐结果--json输出完整 JSON含mode: recommendation、lang、confidence、matchedSignals、recommendation、alternatives非 JSON 模式则调用formatScenarioRecommendation排版。与 SKILL.md 类型路由器的联动archify/SKILL.md 明确把 guide 命令作为类型路由的兜底手段类型路由表列出五种模式的适用场景后规定When ambiguous, runnode bin/archify.mjs guide scenario --json即当模式选择存在歧义时由配方推荐器接管决策。这也让问题优先真正进入日常创作流而不是停留在产品文档里。交付边界CLI 与静态站点共用同一数据源研究文档强调了一条硬性边界The recipe module underarchify/recipes/is the only product data source.即 archify/recipes/scenarios.mjs 是唯一的产品数据源零依赖 CLI 动态导入它静态 GitHub Pages 选择器chooser也由它生成——通过导出的publicGuideData()L384-L391把双语文案与加权信号序列化给站点端。这一设计从源头杜绝了网站上教的配方与安装到 IDE 里的技能发生漂移。同时本轮明确界定这不是什么不是为每个借来的视觉风格新增一个渲染器不是 LLM 分类器或服务器依赖不是通用模板市场不授权在缺失部署、事件或归属事实时凭空编造。配方如何约束最终产出表现建议与工程画像配方不仅是选型器其建议还会顺着创作链路约束实际产物preset / motion / views建议对应meta.visual_preset、meta.animation、meta.views的取值include四项必含证据定义了图内必须出现的语义要素。例如 deployment ownership 配方要求regions and networks、workload ownership、stateful services、named boundary crossingsdeployment-ownership 配方与工程画像联动当用户确实需要失败即阻断的部署评审时配方提示词要求先征得确认再把meta.engineering_profile设为deployment-ownership。对应的校验逻辑在 archify/renderers/shared/engineering-profiles.mjs一旦启用该画像图内必须至少存在一个region边界和一个security-group边界、每个部署组件必须在tag中写明负责人、必须恰好属于一个 region 边界、跨边界连接必须命名机制engineering/deployment-crossing-mechanism等诊断。这正体现了配方要求证据而不是装饰的设计意图。以 agent tool-call 配方为例其文案完整定义了产出边界questionHow does an agent plan, get permission, act, recover, and report?useWhenExplaining agent runtimes, MCP/tool orchestration, approvals, retries, or observability.avoidWhenThe goal is only to show static agent components or exact API message timing.includerequest and planning; policy or approval gate; tool execution; exception and evidence paths.presentationsignal-flow·trace· views recommended。prompt要求把 user surface、agent runtime、policy boundary、exception handling、tool execution、observability 拆成泳道突出成功主路径并显式展示审批、重试、阻塞与证据路径。对应的参考示例是 archify/examples/agent-tool-call.workflow.json其泳道布局User Interface / Agent Runtime / Policy Recovery / Tool Execution Evidence、mainPath、phasesIntake → Plan route → Execute report与viewshappy-path / safety-gate / evidence-loop恰好与该配方成功主路径 策略门 证据路径的约束一一呼应——示例只作结构参考不作为可复制的事实。验收检查与测试证据研究文档列出了五条验收检查它们在测试 archify/test/guide.test.mjs 中均有对应断言验收项测试断言11 个唯一配方、双语决策文案完整SCENARIO_RECIPES.length 11id 唯一按类型计数为 architecture 2、workflow 3、sequence 2、dataflow 2、lifecycle 2每个配方的question/summary/useWhen/avoidWhen/prompt长度 10include恰为 4 项signals≥ 8 条代表场景路由到专门配方测试用例Show an API request with Redis cache miss→ api-requestShow CI/CD build deploy rollback→ delivery-workflow展示 Kafka topic 消费者组和死信队列→ event-stream梳理 ETL 数仓 PII 数据血缘→>node archify/bin/archify.mjs doctor node archify/bin/archify.mjs demo output-directory用问题而非类型来起步# 列出全部配方 node archify/bin/archify.mjs guide # 中文查询强制中文输出 node archify/bin/archify.mjs guide 展示 Kafka topic 消费者组和死信队列 --lang zh # 结构化 JSON 输出便于 Agent 程序化消费 node archify/bin/archify.mjs guide agent tool call approval gate MCP --json读取配方给出的提示词与证据清单按其 include 四项约束撰写 JSON参考对应模式 schema 与示例schema 在 archify/schemas/示例在 archify/examples/验证与交付node archify/bin/archify.mjs validate workflow candidate.json --quality showcase --json node archify/bin/archify.mjs deliver workflow candidate.json output.html --quality showcase --json工作流类新图使用schema_version: 2其可读布局契约详见 archify/renderers/workflow/README.md。结语Visual Evolution Round 4 的贡献不在于新增视觉能力而在于给五种强类型渲染器装上一个问题优先的入口11 个带证据契约的双语配方、一套确定性的加权信号推荐算法、一个零依赖的archify guide命令以及配方模块为唯一数据源的交付边界。它让用户先回答我要解决什么问题再由配方约束该画什么、必须包含什么、不该如何画最终把选择权从图表术语翻译的负担中解放出来。配方数据源 archify/recipes/scenarios.mjs、CLI 接线 archify/bin/archify.mjs 与测试 archify/test/guide.test.mjs 共同构成了这套机制的完整实现证据读者可直接在仓库中逐一对照研读。【免费下载链接】archifyAgent skill for beautiful, verifiable architecture, workflow, sequence,>项目地址: https://gitcode.com/GitHub_Trending/arch/archify创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Archify 场景配方（Scenario Recipes）：基于问题优先的图表模式选择层设计解析
Archify 场景配方Scenario Recipes基于问题优先的图表模式选择层设计解析【免费下载链接】archifyAgent skill for beautiful, verifiable architecture, workflow, sequence,>项目地址: https://gitcode.com/GitHub_Trending/arch/archify导读面对 architecture、workflow、sequence、dataflow、lifecycle 五种图表渲染模式用户的真实问题往往不能直接映射到某个模式名称上。本篇文章以仓库内研究文档 docs/research-visual-evolution-round-4.md 为主体深入剖析 Archify 的问题优先question-first场景配方机制11 个预置配方如何把系统总览智能体工具调用数据血缘这类真实诉求翻译成带证据契约的图表任务以及archify guide命令如何通过加权双语信号做确定性推荐。读完你将掌握配方数据模型、推荐算法、CLI 用法与测试验收的全套细节并能在实际创作中用配方约束图表产出。问题背景五种模式可用但用户不知道该选哪个Archify 的能力边界是五类强类型图表而非通用绘图画布架构architecture、工作流workflow、时序sequence、数据流dataflow、生命周期lifecycle其类型路由表定义在 archify/SKILL.md 中。但本轮研究文档指出了一个现实困境Five renderer modes are useful only when a user can choose the right one.用户带着我想看清楚一次发布如何从提交走到生产这样的问题而来却必须先在内心完成一次问题 → 图表术语的翻译才能说得出我要一张 workflow 图。如果只给一个类型列表用户被迫学习图表行话如果提供一个包罗万象的通用画布又会诱导用户画出杂乱无章的全景图。本轮Visual Evolution Round 4日期 2026-07-19的目标就是在不动五种渲染器本体、不把 Archify 变成通用绘图平台的前提下加一层问题优先的选择层。外部研究的两个关键启示约束而非模仿研究文档记录了来自两个外部项目的方法论借鉴其核心结论是有用的不是加更多主题而是把每种视觉语言与一个有边界的问题和证据契约绑定。Fireworks Tech Graph视觉风格需要语义契约官方 style-to-diagram 矩阵并不认为每种风格适合每种图面向工程的风格需要领域证据例如 C4 层级与职责、部署归属与边界穿越、事件主题与消费者组、运维信号与故障路径。官方 composition quality contract 让可读性可度量展示画像showcase profile预算零连线交叉、零桥接、至多两次弯折、最小节点间距、容器留白其兜底策略是简化或拆分拓扑。这两条直接印证并强化了 Archify 既有的一条主路径one-main-path与小视图small-view规则——这些规则在 archify/SKILL.md 的创作不变量中体现为One obvious main pathat most 12 primary nodes等约束。Structurizr范围先于符号workspace scope 指导建议把工作区限定在单一软件系统内并警告all-in-one 工作区会变得杂乱。notation 指导刻意使用小词汇表方框 单向箭头并在所有视图中保持一致的样式。由此提炼出的有效理念是约束而非模仿每个配方只回答一个技术问题、保持稳定的视觉语法、提供显式的何时不要用avoid when文案。产品决策11 个小型场景配方覆盖五种既有模式依据上述研究本轮落地为 11 个场景配方分布在 Archify 既有的五种模式上不新增任何渲染器模式配方Architecturesystem overview系统总览deployment ownership部署与归属Workflowagent tool-call智能体工具调用delivery workflow研发交付流程incident runbook事故处置 RunbookSequenceAPI requestAPI 请求链async roundtrip异步往返链路Data flowdata lineage数据血缘event-stream topology事件流拓扑Lifecycleobject lifecycle对象生命周期deployment lifecycle部署生命周期每个配方都定义了六个要素它回答的确切问题question何时使用 / 何时不要使用useWhen / avoidWhen必须出现的四项证据include建议的表现预设、动效与引导视图用法presentation可直接复制的中英文提示词en.prompt / zh.prompt部分配方还带 start.descriptionPrompt 自然语言起步提示用于确定性推荐的加权双语信号signals每条信号带权重。配方数据模型的源码实现单一事实来源全部配方以数据形式定义在唯一的产品数据源 archify/recipes/scenarios.mjs 中。文件先定义RAW_RECIPES数组再通过Object.freeze深度冻结导出为SCENARIO_RECIPES保证运行时不可篡改L255-L265。一个配方的完整字段结构如下字段类型说明idstring小写连字符标识如system-overview同时是 CLI 精确匹配的目标typestring五种渲染模式之一architecture / workflow / sequence / dataflow / lifecycleproofstring该配方对应的仓库示例文件名结构参考非事实来源presentationobject{ preset, motion, views }三项表现建议startobject可选{ en, zh }两个descriptionPrompt用于无需代码库的自然语言起步signalsarray[信号词, 权重]二元组数组中英双语混排供推荐算法打分en/zhobject双语决策文案title / question / summary / useWhen / avoidWhen / include[4] / prompt表现建议presentation与源码的对应关系每个配方的presentation建议直接对应最终 JSON 的meta字段preset对应meta.visual_preset取值为classic、signal-flow、blueprint、editorialmotion对应meta.animationstatic或traceviews对应meta.views的推荐程度optional/recommended。例如system overviewclassicstatic views optional —— 高层概览用静态经典风格即可deployment ownershipblueprinttrace views recommended —— 部署图建议蓝图预设与轨迹动效其余大多数配方采用signal-flowtrace。动效trace在渲染端会写入 SVG 的data-animationtrace属性见 archify/renderers/shared/cli.mjs 的svgRootAttrs。双语起步提示start与仓库证据提示有 5 个配方system-overview、agent-tool-call、api-request、event-stream、object-lifecycle额外定义了start.descriptionPrompt用于用户在没有代码库时用自然语言起步。startPromptsForL271-L284还会为需要仓库证据的场景拼装第二段提示architecture 类型直接复用copy.prompt其他类型会追加先检查仓库证据、不要编造代码无法支持的行为的前缀英文版为Inspect this repository for evidence, then ... Do not invent behavior that the code does not support.。信号权重设计示例推荐算法的输入是带权重的双语信号。以三个配方为例system overviewsystem overview(12)、architecture(10)、trust boundary(8)、components(6)、repository(5)、services(4)、系统总览(12)、架构(10)、信任边界(8)……agent tool-callagent tool call(16)、tool call(12)、approval gate(10)、agent loop(10)、human in the loop(9)、mcp(7)、planner(6)、智能体工具调用(16)、工具调用(12)、审批门(10)……event-streamevent stream(15)、kafka topology(14)、consumer group(11)、dead letter(10)、dlq(10)、topic(8)、事件流(15)、kafka 拓扑(14)、消费者组(11)……权重越高表示该信号对该配方的区分度越强每个配方的信号数量不少于 8 条测试强制校验。确定性推荐算法不加 LLM 分类器推荐逻辑不依赖任何模型或网络服务完全是确定性的加权打分。核心实现在 recommendScenario流程如下语言检测detectGuideLanguageL267-L269用 Unicode 正则/[\u3400-\u9fff]/u判断查询是否含 CJK 字符从而决定默认返回中英文文案文本归一化normalizedL286-L288做 NFKC 归一化、转小写、空白与下划线折叠为单个空格精确匹配优先若归一化文本恰好等于配方 id或 id 去连字符形式直接得 100 分匹配命中该 idL309-L311信号加权打分否则遍历配方 signals凡查询文本包含某信号词即累加该信号权重L313-L320排序与置信度按分数降序、同分按原始顺序排序取第一名置信度规则为score 14 → high、score 7 → medium、否则lowL328诚实回退若第一名分数为 0回退到数组首位system-overview置信度low、匹配信号为空——宁可低置信度兜底也不假装猜中候选替代另取分数大于 0 的其他配方中至多两个作为alternatives供用户参考。此外还有两个面向输出的辅助函数formatScenarioList无查询时打印全部配方列表提示语为Run: archify guide your scenario/可运行archify guide 你的场景与formatScenarioRecommendation把推荐结果排版为推荐 / 要回答的问题 / 适合 / 不要这样用 / 必须包含 / 表现建议 / 可直接复制的提示词 / 其他可能等分节的中英文输出。archify guide零依赖的配方命令行配方层与 CLI 的衔接在 archify/bin/archify.mjs 的commandGuideL1428-L1479通过import(pathToFileURL(guidePath).href)动态导入recipes/scenarios.mjs因此guide命令不依赖任何node_modules用法为archify guide [scenario or question] [--json] [--lang en|zh]--lang只接受en或zh用于强制输出语言不传时由detectGuideLanguage依据查询内容自动判定不带查询参数时输出全部 11 个配方的id [type] title question列表--json则输出结构化listScenarioRecipes结果带查询参数时输出recommendScenario的推荐结果--json输出完整 JSON含mode: recommendation、lang、confidence、matchedSignals、recommendation、alternatives非 JSON 模式则调用formatScenarioRecommendation排版。与 SKILL.md 类型路由器的联动archify/SKILL.md 明确把 guide 命令作为类型路由的兜底手段类型路由表列出五种模式的适用场景后规定When ambiguous, runnode bin/archify.mjs guide scenario --json即当模式选择存在歧义时由配方推荐器接管决策。这也让问题优先真正进入日常创作流而不是停留在产品文档里。交付边界CLI 与静态站点共用同一数据源研究文档强调了一条硬性边界The recipe module underarchify/recipes/is the only product data source.即 archify/recipes/scenarios.mjs 是唯一的产品数据源零依赖 CLI 动态导入它静态 GitHub Pages 选择器chooser也由它生成——通过导出的publicGuideData()L384-L391把双语文案与加权信号序列化给站点端。这一设计从源头杜绝了网站上教的配方与安装到 IDE 里的技能发生漂移。同时本轮明确界定这不是什么不是为每个借来的视觉风格新增一个渲染器不是 LLM 分类器或服务器依赖不是通用模板市场不授权在缺失部署、事件或归属事实时凭空编造。配方如何约束最终产出表现建议与工程画像配方不仅是选型器其建议还会顺着创作链路约束实际产物preset / motion / views建议对应meta.visual_preset、meta.animation、meta.views的取值include四项必含证据定义了图内必须出现的语义要素。例如 deployment ownership 配方要求regions and networks、workload ownership、stateful services、named boundary crossingsdeployment-ownership 配方与工程画像联动当用户确实需要失败即阻断的部署评审时配方提示词要求先征得确认再把meta.engineering_profile设为deployment-ownership。对应的校验逻辑在 archify/renderers/shared/engineering-profiles.mjs一旦启用该画像图内必须至少存在一个region边界和一个security-group边界、每个部署组件必须在tag中写明负责人、必须恰好属于一个 region 边界、跨边界连接必须命名机制engineering/deployment-crossing-mechanism等诊断。这正体现了配方要求证据而不是装饰的设计意图。以 agent tool-call 配方为例其文案完整定义了产出边界questionHow does an agent plan, get permission, act, recover, and report?useWhenExplaining agent runtimes, MCP/tool orchestration, approvals, retries, or observability.avoidWhenThe goal is only to show static agent components or exact API message timing.includerequest and planning; policy or approval gate; tool execution; exception and evidence paths.presentationsignal-flow·trace· views recommended。prompt要求把 user surface、agent runtime、policy boundary、exception handling、tool execution、observability 拆成泳道突出成功主路径并显式展示审批、重试、阻塞与证据路径。对应的参考示例是 archify/examples/agent-tool-call.workflow.json其泳道布局User Interface / Agent Runtime / Policy Recovery / Tool Execution Evidence、mainPath、phasesIntake → Plan route → Execute report与viewshappy-path / safety-gate / evidence-loop恰好与该配方成功主路径 策略门 证据路径的约束一一呼应——示例只作结构参考不作为可复制的事实。验收检查与测试证据研究文档列出了五条验收检查它们在测试 archify/test/guide.test.mjs 中均有对应断言验收项测试断言11 个唯一配方、双语决策文案完整SCENARIO_RECIPES.length 11id 唯一按类型计数为 architecture 2、workflow 3、sequence 2、dataflow 2、lifecycle 2每个配方的question/summary/useWhen/avoidWhen/prompt长度 10include恰为 4 项signals≥ 8 条代表场景路由到专门配方测试用例Show an API request with Redis cache miss→ api-requestShow CI/CD build deploy rollback→ delivery-workflow展示 Kafka topic 消费者组和死信队列→ event-stream梳理 ETL 数仓 PII 数据血缘→>node archify/bin/archify.mjs doctor node archify/bin/archify.mjs demo output-directory用问题而非类型来起步# 列出全部配方 node archify/bin/archify.mjs guide # 中文查询强制中文输出 node archify/bin/archify.mjs guide 展示 Kafka topic 消费者组和死信队列 --lang zh # 结构化 JSON 输出便于 Agent 程序化消费 node archify/bin/archify.mjs guide agent tool call approval gate MCP --json读取配方给出的提示词与证据清单按其 include 四项约束撰写 JSON参考对应模式 schema 与示例schema 在 archify/schemas/示例在 archify/examples/验证与交付node archify/bin/archify.mjs validate workflow candidate.json --quality showcase --json node archify/bin/archify.mjs deliver workflow candidate.json output.html --quality showcase --json工作流类新图使用schema_version: 2其可读布局契约详见 archify/renderers/workflow/README.md。结语Visual Evolution Round 4 的贡献不在于新增视觉能力而在于给五种强类型渲染器装上一个问题优先的入口11 个带证据契约的双语配方、一套确定性的加权信号推荐算法、一个零依赖的archify guide命令以及配方模块为唯一数据源的交付边界。它让用户先回答我要解决什么问题再由配方约束该画什么、必须包含什么、不该如何画最终把选择权从图表术语翻译的负担中解放出来。配方数据源 archify/recipes/scenarios.mjs、CLI 接线 archify/bin/archify.mjs 与测试 archify/test/guide.test.mjs 共同构成了这套机制的完整实现证据读者可直接在仓库中逐一对照研读。【免费下载链接】archifyAgent skill for beautiful, verifiable architecture, workflow, sequence,>项目地址: https://gitcode.com/GitHub_Trending/arch/archify创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考