企业官网建设流程全解析

Civitai Prompt Enhancement Guide 编写实战：为 Orchestrator Prompt-Analysis 服务定制生态级系统提示词

【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai

导读

Civitai 仓库的 orchestrator 运行着一个prompt-analysis（提示词分析）服务：针对每个生成生态（ecosystem，如 Stable Diffusion XL、Flux、Wan Video、MiniMax H3），它读取用户的提示词，输出结构化反馈与一条增强后的重写提示词。每个生态都挂载一份专属的 system prompt——即prompt enhancement guide——由编写者根据该模型自身的提示词习惯（标签式还是自然语言、权重语法、负向提示词、文字渲染、视频的运镜/动作词汇等）逐条定制。

本文是仓库内 .claude/skills/add-prompt-enhancement-guide/SKILL.md 的完整展开。你将掌握：如何为任意图像/视频生态编写一份与既有 guide 同构的增强提示词系统提示词，如何用measure.mjs在部署前 A/B 验证，如何用manage.mjs把它注册到 orchestrator，以及四条由线上测量反推出的"别踩的坑"。全文以该技能文档为主体，并用仓库源码（生态常量定义、AIR 工具、测量与部署脚本）交叉印证每一处事实。

1. 背景：prompt-analysis 服务与生态级 guide

1.1 服务的职责

orchestrator 的 prompt-analysis 服务按生态工作：输入用户的 prompt，输出结构化反馈 + 增强重写。每个生态有自己独立的 system prompt，针对该模型的提示词惯例调优：

• 标签式还是自然语言式（tag-based vs natural-language）
• 权重语法（weight syntax）是否生效
• 是否支持负向提示词（negative prompt）
• 文字渲染（text rendering）能力
• 视频模型的运镜/动作词汇（camera/motion vocabulary）

guide 的质量直接决定分析器给出的反馈与重写是否符合该模型的真实行为——这也是为什么仓库内专门为编写 guide 建了一个 skill。

1.2 范围：仅限图像与视频生态

不要为 3D、音频或其他模态编写 guide。tripo、hunyuan3d、polygen（图生 3D）、ace（音频）明确超出范围，之后出现的任何非图像/视频生态同理。理由写得很直白：guide 模板完全围绕 subject / lighting / camera / composition / style 构建，这些词汇描述不了"从图片生成网格"或"生成一首歌"；用该模板硬套其他模态，产出将是"自信地错"，而不是"略显单薄"。让这些生态停留在内置 fallback 上是刻意的选择。

2. 编写前必须提供的两个输入

2.1 输入一：生态 key（ecosystem key）

生态 key 来自 packages/civitai-shared/src/basemodel.constants.ts 中生态记录的key字段，转小写后使用。例如：

在仓库中可确认这些 key 确实存在：basemodel.constants.ts 定义了key: 'Flux1Kontext'，另有key: 'SD1'（L340）、key: 'SDXL'（L368）、key: 'HyV1'（L423）、key: 'WanVideo'（L432）、key: 'Pony'（L580）、key: 'MiniMaxH3'（L789）等。注意 src/shared/constants/basemodel.constants.ts 只是同一模块的一行 re-export shim，不是过期的重复文件——从两个路径导入均可。

关键定义：它就是 AIR 的生态值，转小写。同一个字符串出现在urn:air:<ecosystem>:...中。src/shared/utils/air.ts 的getAirEcosystem是二者的单一事实来源：stringifyAIR用它生成 URN，createPromptEnhancementStep也用它定位 prompt-analysis 的 key。该函数对无法解析的输入采取"原样转小写透传"而非抛错，因为调用方会传入用户影响的值；另外为了向后兼容，Upscaler 生态在 AIR 中统一用Other。

必须警惕的连带后果：getRootEcosystem会沿parentEcosystemId上溯，所以子生态永远不会出现在 AIR 中、也永远不会进入 prompt analysis。Pony、Illustrious、NoobAI 全部以sdxl身份到达。写 guide 之前先查parentEcosystemId——如果目标生态有父级，guide 属于父级，且必须能服务所有兄弟生态。

注意：它不是引擎名。handler 里的engine: 'minimax-h3'是另一个标识符，只是恰好对kling、seedance、veo3与生态 key 重合。把 guide 挂在引擎名下等于白写——没有任何代码会读它。

自建增强步骤的 handler（如ltx.handler.ts）会把图的生态原样传给createPromptEnhancementStep，由后者做归一化，因此它们最终落在与生成器相同的 key 上。

2.2 输入二：参考资料

至少提供下列之一：

• URL（HuggingFace 模型卡、官方公告、服务商文档页）
• 粘贴的模型描述 / 提示词指南
• 规格表（架构、编码器、token 上限、支持特性）

如果用户只给了名字没有参考资料，先索要再动手。没有源材料写出来的通用 guide 会逐渐偏离模型真实行为。

3. 工作流总览

完整流程分六步：研究生态 → 映射到模板 → 按语气与内容规则打磨 → 用measure.mjs测量 → 与用户确认 → 部署到 orchestrator（可选）。

3.1 第一步：研究生态

对用户提供的 URL 使用WebFetch，提取以下字段：

• 提供商 / 架构（如 "Alibaba"、"ByteDance"、"Tencent"、"8B DiT"、"MMDiT"、"autoregressive"）
• 模态（图像、视频、图编辑、多模态）
• 文本编码器（T5、CLIP dual、Mistral、基于 LLM）——直接决定提示词风格建议
• 原生分辨率 / 宽高比
• token / 字符上限
• 权重语法支持——现代模型几乎总是"不支持"，但要核实
• 负向提示词——支持 / 不支持 / 效果微弱（差异极大）
• 特殊能力——文字渲染、多语言、视频的音频、参考图、十六进制颜色、风格标签、角色一致性
• 视频模型额外项：时长、fps、运镜/动作词汇、单镜头 vs 多镜头行为
• 知识 / 训练截止时间（如提及）
• 值得提示的已知局限（如"长文本表现弱"、"预览版 checkpoint 默认风格平淡"）

如果用户给的是描述而非 URL，就从描述中挖掘同样字段。只对无法确定且会实质改变 guide 的字段追问（例如"这个模型支持负向提示词吗？"）。

3.2 第二步：映射到 guide 模板

每份 guide 都遵循同一形状——prompt-analysis 服务依赖跨生态的结构一致性。模板原文如下（完整继承）：

You are a prompt engineering expert for <Model name and one-clause context>. Analyze the user's prompt and provide structured feedback. Ecosystem-specific rules: - Prompt style: <tag-based | natural language | hybrid>. <One-sentence rationale tied to the encoder/architecture if helpful.> - <Native resolution / aspect ratios> - <Token or character limit + sweet spot if known> - <Weight syntax: support state. If unsupported, say so explicitly — "(word:1.5) is ignored."> - <Negative prompts: supported / not / minimal effect. Include a concrete recommended negative if the model benefits from one.> - <Any unique features: text rendering rules, multilingual, hex colors, reference images, audio (video), camera vocab (video), style tags, character consistency> - <Anything the enhanced prompt should ALWAYS carry — camera direction, audio bed, lighting. Phrase as a property of the rewrite, not as something to flag.> - Prompt template: [Section 1] [Section 2] [Section 3] ... Guidelines: - Identify vague or overly generic descriptions - Flag <syntax that is incompatible with this model — e.g. weight syntax on Flux, brackets on HiDream> - Flag <negative prompt attempts when unsupported, OR suggest negatives when this model benefits from them> - <Model-specific flags: photorealism cues on anime models, multi-character without descriptions, scene-cut descriptions on short video clips, etc.> - Limit recommendations to the 3 most impactful improvements - The enhanced prompt should be a single, ready-to-use prompt that stays faithful to the user's original intent

Guidelines 的最后两条是硬性要求，所有 guide 必须逐字保留——它们承担着分析器输出格式的承重作用。

Guidelines 下每一行都必须有一个分析器能在用户 prompt 里看到的触发器。如果"它什么时候不触发？"的答案是"基本永远触发"，那它属于Ecosystem-specific rules:而非 Guidelines——见 3a。Guidelines 行数大致对准 3 条建议的上限：语料库平均 3.6 行，最高到 9 行。

3.3 第三步：语气与内容规则

• 要具体。"No weight syntax —(word:1.5)is ignored" 胜过 "weight syntax not recommended."
• 把建议绑定到模型优势上——但先确认归属（见 3a）。"Flag in-image text that is described rather than quoted" 是一条guideline：只在用户 prompt 提到文字时触发。"The enhanced prompt always states the camera" 是一条rule：几乎每个 prompt 都缺运镜方向，作为 guideline 它每次都会触发，挤掉其他一切。
• 大声叫出不兼容性。如果模型忽略负向提示词或权重语法，Guidelines 必须指示分析器标记对它们的尝试——这是最常见也最有用的修正。
• 当编码器能解释规则时提到它。"T5 understands grammar, so write sentences" 能借力下游模型。
• 不要注水。模型没有特殊音频/文字/多语言能力时，别编造条目填空。SD1 的 guide 短是故意的。
• 对齐同类先例。新的 Wan 变体应长得像现有 Wan 系列 guide；新的 Flux 变体应长得像现有 Flux 系列 guide。兄弟生态之间的一致性比新奇更重要。

3.4 3a 节：四条由测量而非审美得出的规则

这四条规则来自对线上分析器做 A/B 实测（详见 docs/prompt-analysis-audit-2026-08-05.md）。每一条都点名了一个在输出中真实观察到的失败，而非阅读预判。

规则一：绝不在 Guidelines 中放无条件缺失检查

"Suggest audio direction if missing" 或 "Flag missing camera direction" 这类行检查的是真实 prompt 几乎从不含有的东西，于是每条请求都触发，在 3 条建议预算被花光之前就把位置占满。在minimaxh3上实测：12 条建议里 10 条是 prompt 已经具备的东西。Guidelines 只放触发器可见于用户 prompt 的标记：权重语法存在、负向措辞存在、关键词列表而非散文。

规则二：不要把缺失检查"降级"成重写属性——直接删掉

直观的修复是把规则改写在Ecosystem-specific rules:里："the enhanced prompt should carry camera direction. This shapes the rewrite; do not raise it as a separate recommendation."这并不能压制主题。2026-08-10 的四次测量表明：

happyhorse是受控实验：同一 guide、同一批样本，唯一区别是弱化 vs 删除——camera 84% → 48%，avg recs3.67 → 2.52。这与下面的"参数护栏"教训是同一机制：只要点名一个主题就会抬高它，无论句子怎么说，而重写属性行仍然点名了它——还常常明确指示模型去添加它（"when the user has not named any"时添加一个）。

所以：把主题压缩到最多一条纯描述性提及（词汇表可以），从 prompt 模板和结构行中移除；如果重写确实应该总是带上它，用样本来教——样本的 prompt 已包含该主题、其建议忽略它。删除+样本是唯一清掉饱和的组合；改写措辞从未做到。

规则三：guide 必须读作对输出的约束，而不是对读者的评论

模型会模仿你写下的语气。一份mai草稿中的 "Lighting is the highest-leverage addition" 导致enhancedPrompt结尾出现 "…The lighting is the highest-leverage addition, defining the mood and texture."——guide 自己的论证被当成提示词文本送给了图像模型。同一份 guide 还把模板原样回读成第 4 条建议，打破了 3 条上限。要写 "the enhanced prompt always states X"，不要写 "X is worth more than Y"。

规则四：对某个东西的防护性提及会让模型提及它

在 guide 中写 "aspect ratio, resolution and step count are chosen in the form — never write them into the prompt" 本意是阻止生成参数泄漏进enhancedPrompt。在grok和auraflow上实测——加这一行是唯一改动：饱和主题分别1 → 3和0 → 1。同一效应在mai上也出现过：强化宽高比那条子弹止住了泄漏，却让"specify the aspect ratio"变成了建议。在规则块中点名一个主题就足以抬高它，无论句子怎么说。最好对参数只字不提；如果 guide 确实泄漏参数，用样本修，而不是用禁令。

三条补充测量教训

• 纯删除的改动也不自动安全。从hyv1删除一条Duration:子弹，把真实的模型属性一起删掉了——"strong temporal consistency due to full 3D attention architecture" 与秒数住在同一条子弹里，饱和从 0 → 1。31 条机械式、无新内容的候选改动里有 3 条发生回退。逐条筛查。
• 能力越重要，措辞越要小心。研究充分、事实正确的规则仍可能让 guide 实测变差。ltxv23的重写加入了原生音频——确实是模型的头牌能力、线上 guide 完全没有——描述为"the model's defining capability"、缺失则产生"an arbitrary soundtrack"。音频建议从约 0% 涨到89%并饱和，总饱和主题1 → 2：新 guide 比它替换的模糊版实测更差，尽管更准确。正确做法：陈述能力，然后明确说重写会静默地加上它、不要作为建议提出。audit.mjs的EMPHATIC-CAPABILITY检查会拦截这类写法；但它只是筛查器不是预测器——sd1把负向提示词称为 "Essential"，实测 0 → 0 饱和。
• guide 会通过示例泄漏幻影事实，不只是规则。minimaxh3的 guide 正确地避开了时长——却用示例"0-4s he steadies the tweezers, 4-9s the gear seats, 9-12s he sits back"教了带时间戳的节拍，于是样本写出了 12 秒时间线。H3 片段运行 5–15s 且时长不在请求里，每条增强 prompt 都默默假设了长端，面对 5 秒生成会超出一倍多。源材料用绝对时间合法，因为人类写自己 prompt 时知道时长；分析器不知道。检查示例文本和样本enhancedPrompt里的偷渡假设，而不只是规则子弹。修复方式是改用序数节拍（"first… then… finally…"），在任何片段长度下都正确。

3.5 3b 节：散文的天花板很低——规划样本

分析模型是Qwen3.6-35B-A3B：一个每 token 仅激活3B 参数的 MoE，所以散文指令对它应该很弱、可执行示例很强。把这一点当作工作假设而非定论。

实测数据：两个样本把minimaxh3的音频建议从 98% 的 prompt 降到 70%，脱离饱和，空出的槽位给了照明——这是随 prompt 变化的建议，而非无条件触发。饱和主题 2 → 1。

指标噪声底为 ±1 个饱和主题。这是实测值，不是估算。拿一份 guide 与它字节级相同的副本对比，六个臂上饱和主题分数为1, 2, 2, 1, 2, 1，其中一个主题在同一次调用的两个臂之间从低于 25% 摆到 93%。三次空调用每次都产生非零 delta，其中两次还打印了发布建议。一个主题的变动不是结果。只相信 ≥2 主题的变动，或"1 主题变动 + 某个特定主题同时偏移 ≥25 个点 + 在独立运行中复现"。2026-08-06 发布中活下来的每一项都有瞄准饱和主题的样本：minimaxh3（camera/audio 98→65）、sdxl（lighting 89→55/66）、ltxv23（audio 89→50/52）。那批发布中约 20 个单次运行 ±1 的结果无法证明任何方向。

读measure.mjs的主题表，而不是只看结论。目标是没有任何主题达到 80% 及以上。饱和主题意味着建议槽位在读取 prompt 之前就被花掉了；配合 3 条上限，两个饱和主题意味着 guide 几乎不再对输入做响应。

一个让这次调查浪费了四轮的警告。原始指标是redundancy（推荐 prompt 已含的东西）。听起来差不多，其实不是：它只在"prompt 恰好包含被推荐项"这个窄场景触发，只是"无论输入都给出相同建议"的一个切片。在该指标下每个干预都读作噪声，结论变成了散文没用、样本没用、可能需要换分析模型——全是仪器假象。手工阅读 141 条建议，一遍就发现了六轮测量漏掉的东西。当某个指标对任何干预都拒绝移动时，先怀疑指标，再下"系统没问题"的结论。

这个测量骗人的两种方式，都值得在相信数字前了解：

• 调查某份 guide 时构建的语料会美化那份 guide 的诊断。最初的五个 prompt 是在minimaxh3审计期间写的，四个带 camera 和 audio 方向——恰好是该 guide 过度标记的东西。它在那个语料上基线的冗余率是 83%，在通用语料上是 44%。使用随附的prompts.json；要加 prompt 就为覆盖率加，永远不要因为某份 guide 处理不好而加。
• avg recs高于约 4 且over-cap计数很低，是假象，不是发现。出现过两次——qwen11.32 和seedream7.07——两次相邻臂在相同文本上读数是 2.9–3.0，饱和保持稳定。两个数字自相矛盾：真正的 11 均值意味着几乎所有响应都超 3 条上限，而不是 56 条里 4 条。一条畸形响应就扭曲了均值。重跑而不是推理，并以饱和为准。
• 读任何百分比前先检查分母。部分失败的臂仍会打印完整主题表和自信的结论。measure.mjs在 "only N/M calls succeeded" 时会警告，但更轻微的数量短缺会静默通过——唯一迹象是两臂之间的redundant X/Y和over-cap A/B不一致。在wanvideo14b_i2v_480p上，线上臂拿到 46 条响应、候选臂 31 条：三分之一请求从未返回，结论行却读作干净的 1 → 0 清除。Y和B必须在两臂之间一致，否则丢弃该次运行。失败还会聚集——那次运行之后紧接着一个所有请求都失败的臂——所以分母不一致通常意味着端点在劣化，整个批次应暂停而非继续。
• 一个看似存在的效应可能就藏在基线自身的方差里。样本看起来削弱了上限遵守——无样本 0–1/30、有样本 4–5/30，跨两种配置一致——直到一份未改动的线上 guide 独自拿到 6/30。measure.mjs每次调用都会重新给基线打分，正是为此。绝不要与更早运行的基线数字比较。

样本长什么样：{ prompt, negativePrompt?, assistantResponse }。为散文无法陈述的判断而写：

• 最强的样本回答的是一个已经很好的 prompt。那里是模型默认行为——输出样板文本——最错的地方。基于弱 prompt 的样本教不了什么，因为泛泛的建议在那里反正也是对的。
• 一个样本会教它包含的每一条建议，包括你没打算教的。首批sdxl样本都开篇 "add lighting and composition tags"——而照明正是它们要修的饱和主题。实测：89% → 88%，毫无变化。发布样本前，把它的建议与measure.mjs输出中的饱和主题对照；如果样本推荐了你正要压制的东西，它会固化它。
• 把样本花在只有这份 guide 能教的东西上。"Add lighting" 是任何 guide 都会给的建议，用它做样本是浪费槽位。样本昂贵——它们搭在该生态的每一次请求上——所以应携带该生态独特的判断，而不是通用建议。
• 写建议前先研究建议本身，跟第一步研究 guide 完全一样。样本以例子教学，其中错误建议的教学效率高于散文中的错误建议。首批minimaxh3样本按通用视频模型直觉起草，因为 H3 在模型训练截止后发布；拿 MiniMax 自己发布的 prompt 对照后，一条主张方向正确但太弱（修复是显式0-4s / 4-9s时间戳范围，而不是含糊的"some change over time"），还暴露出 guide 完全缺失的第三条规则。如果无法为样本所教的内容引用来源，就不要发布该样本。
• 适合样本的是位置性/句法性而非语义性的惯例：anima的@artist前缀和标签顺序、sd1的权重语法和BREAK、flux1kontext的编辑指令框架。有清晰陈述的规则不需要样本——"No weight syntax" 不需要示例。

输入一半的真实用户 prompt 可从Image.meta->>'prompt'拉取（见postgres-queryskill）。过滤出强prompt，不要中位数——中位数是 LoRA 标签和质量标签垃圾。assistantResponse永远需要手工撰写，任何查询都产生不了它。

3.6 3c 节：部署前先测量

guide 编辑是概率系统的改动，发布前必须读输出。measure.mjs用固定 prompt 集跑一份 guide，报告它"推荐 prompt 已有内容"的频率：

# 给线上 guide 打基线 node .claude/skills/add-prompt-enhancement-guide/measure.mjs --ecosystem minimaxh3 # 候选与它做 A/B（各 3 轮足够看穿温度噪声） node .claude/skills/add-prompt-enhancement-guide/measure.mjs \ --ecosystem minimaxh3 --candidate ./new-guide.txt --runs 3

工具的其他参数（measure.mjs 头部注释可查）：--guide ./draft.txt直接测未注册的草稿（不触碰注册表）、--samples ./samples.json附加样本、--runs乘以语料（23 条 prompt 跑 2 轮已经强过旧 5 条跑 6 轮）、--modality声明模态。它直接调/v1/chat/completions而非提交 workflow，所以测候选 guide 无需注册——对 prompt-analysis 的注册表零污染。

一次运行证明不了任何事，三次也只是勉强。minimaxh3的 A/B 单轮显示散文修复让冗余减半；三轮显示它几乎什么都没做。散文+样本组合在--runs 3下两次都是 3/12，看着像真实复合效应；--runs 6时与单独用样本无法区分。任何打算部署的都请用--runs 6，--runs 3只当冒烟测试。

预期编辑会回退某些东西。三稿修 D1/D4/D6 的同时引入了两个新缺陷——mai多了宽高比建议，mageflow开始在没有负向字段的模型上输出填充的负向 prompt。修完后要重新测量整个prompt 集，不只你正在修的那个案例。

3.7 第四步：与用户确认

部署前把草稿 guide 粘贴给用户请求签核。标出研究薄弱或需要判断的字段（例如"我假设负向提示词不受支持，因为模型卡没提——确认？"）。接受修改，改动后重新粘贴最终版。

3.8 第五步：部署到 orchestrator（可选）

用本技能目录下的manage.mjs，不要手写 curl。它会从项目.env读ORCHESTRATOR_ENDPOINT和ORCHESTRATOR_ACCESS_TOKEN，所有状态变更调用都要求--writable，put之后会校验回读（实现见 manage.mjs 头部注释）。

# 看已注册了哪些生态、哪些有真 guide node .claude/skills/add-prompt-enhancement-guide/manage.mjs status # 写兄弟生态前先读现有 guide 作先例 node .claude/skills/add-prompt-enhancement-guide/manage.mjs get seedance --prompt-only # 部署——把文件内容写成 system prompt，然后读回 node .claude/skills/add-prompt-enhancement-guide/manage.mjs put <key> --prompt-file guide.txt --writable

guide 以纯文本文件经--prompt-file传入——它包含反引号、换行和引号，会破坏 shell 转义。--file接受完整 JSON body（需要samples时用）。

模型绑定：PromptAnalysisGrain.DefaultModelId现在已是 qwen3 URN（civitai-orchestrationPR #297），所以全新生态上的put不传--model会继承正确模型。但显式传--model 'urn:air:qwen3:repository:huggingface:Civitai/Qwen3.6-35B-A3B-Abliterated-AWQ@main.tar'仍是更安全的习惯——它能在常量未来变更后存活，且每份现存 guide 都是这么存的。

改绑现有 guide 而不动文本，用set-model：

node .claude/skills/add-prompt-enhancement-guide/manage.mjs set-model <key> \ --model 'urn:air:qwen3:repository:huggingface:Civitai/Qwen3.6-35B-A3B-Abliterated-AWQ@main.tar' --writable

它会在没有自己 guide 的生态上拒绝执行——那些生态报告modelId是因为 grain 回退到常量，不是因为存了任何东西；写入会把今天的 fallback 文本冻结为该生态的永久 guide，切断它未来获得内置默认更新的路径。这种情况去改civitai-orchestration里的常量，而不是set-model。

register不是必需步骤——put会自行注册生态。

3.9 Few-shot 样本

每个生态可携带samples——{ prompt, negativePrompt?, assistantResponse }三元组，handler 在 system prompt 与真实请求之间把它们重放成 user/assistant 轮次。这是杠杆最高的手段；选择样本演示什么的测量依据见 3b。

node .claude/skills/add-prompt-enhancement-guide/manage.mjs set-samples <key> --file samples.json --writable

容易搞错的规则：

• assistantResponse必须是严格匹配分析 schema 的 JSON 字符串——issues（每个含description和severity，取值为info/warning/error）、recommendations、enhancedPrompt、enhancedNegativePrompt。响应在严格json_schema响应格式下生成，任何其他形状的样本都在教模型对抗 schema。set-samples只拒绝不可解析的 JSON，无法替你校验形状。
• 样本没有负向 prompt 时，enhancedNegativePrompt是""，不是省略。
• 样本在该生态的每一次请求上都消耗上下文。两三条紧凑示例胜过十条臃肿的。
• 为 guide 无法写成规则的东西写样本。有清晰规则的惯例（"no weight syntax"）不需要；判断型的内容——多少细节算太多、一个词 prompt 的好重写长什么样——需要。
• put通过读-改-写保留样本，这意味着在set-samples之后马上跑put会毁掉它们。它重读存储配置以携带样本前进，而写入传播缓慢——set-samples后立刻的put读到的是过期副本（0 样本）并把它写回。2026-08-06 两侧都观测到了：竞态中的put报告0 sample(s)，而稍后在已稳定配置上的put报告Keeping 2 existing sample(s)并保留它们。顺序应为put在前、set-samples在后——这样没有任何东西依赖读赢。必须反序时，等约 30 秒。始终读输出里的样本数；它报告的是实际写入的内容。

两个会误导你的 orchestrator 行为（均在civitai-orchestration的PromptAnalysisGrain.cs/PromptAnalysisController.cs）：

• GET 也会注册。GetPromptAnalysisRequestAsync调用EnsureRegisteredAsync，所以读一个从未设置的生态会静默地以默认配置把它加进注册表。GET 永不 404，也从不区分"已注册"与"未注册"。猜测 key 拼写去探测会永久污染注册表——用status（一次列表调用）代替 GET 猜测。
• 只有 POST 会把 key 转小写。GET/PUT/DELETE 按路径中的精确字符串寻址 Orleans grain，所以MiniMaxH3和minimaxh3是两个独立配置。manage.mjs替你转小写；--raw-key针对奇形大小写的条目——这也是delete它们的唯一方式。

注册表里已经躺着过去探测留下的垃圾（notarealecosystem、SDLX、Flux.1 D、裸flux等）。别再加了，也别把某个名字出现在list里当成"有什么在用它的证据"。

3.10 第六步：验证——不要相信即时回读

写入最多要一分钟才可见，所以put/set-samples的回读校验会与传播赛跑，既报假失败也报假成功。2026-08-06 单次部署中两侧都观测到：已验证的put之后立刻 GET，返回的还是旧的 3437 字符 guide；set-samples打印✗ readback does not match what was sent，而那次写入其实成功了。按任一信号行动都会重跑一次已经落地的写入，或回退一份好好的写入。

put和set-samples现在轮询回读最长 30 秒，不再只断言一次，所以即时的假失败不再上报。因此✗意味着写入真的没落地——但先用status复查再重写，不要盲打第二次。

用一次原子的put --file同时部署 guide 和样本，永远不要put后接set-samples。set-samples必须发送一份不是它写的systemPrompt，所以它先读当前值——而在传播窗口内读到的是一份旧的guide，写入随后把它恢复了。2026-08-10 这曾静默回退了一次已验证的seedance部署（2588 字符回到 2659）。set-samples现在会在相隔 3 秒的两次读取不一致时拒绝执行，也接受--prompt-file来显式声明 guide，但原子形式一劳永逸：

node -e "const fs=require('fs');fs.writeFileSync('deploy.json',JSON.stringify({ systemPrompt: fs.readFileSync('guide.txt','utf8').replace(/\n+$/,''), modelId: 'urn:air:qwen3:repository:huggingface:Civitai/Qwen3.6-35B-A3B-Abliterated-AWQ@main.tar', samples: JSON.parse(fs.readFileSync('samples.json','utf8')), }))" node .claude/skills/add-prompt-enhancement-guide/manage.mjs put <key> --file deploy.json --writable

然后独立确认：

node .claude/skills/add-prompt-enhancement-guide/manage.mjs status | grep <key> # chars + sample count node .claude/skills/add-prompt-enhancement-guide/manage.mjs get <key> # diff against your source files

成功汇报时带上生态 key 和一句 guide 要点摘要（编码器、权重语法立场、负向提示词立场、任何独特能力）。

4. 反模式清单

• 不要复制兄弟 guide 改个名字。形状共享但规则各异——把 Flux guide 贴到 Wan key 下会误导分析器。
• 不要编造能力。源材料没提音频、多语言渲染或 4K 输出，就别声称。
• 不要软化不兼容性。编码器完全忽略权重语法时，"may not work" 是错的。说 "ignored" 或 "unsupported"。
• 不要删掉 Guidelines 末尾两条（"Limit recommendations to the 3 most impactful improvements" 和 "The enhanced prompt should be a single, ready-to-use prompt..."）。它们承重分析器的输出格式。
• 不先给用户看 guide 就别推送到 orchestrator。一旦部署，它塑造该生态的每一次 prompt-analysis 调用。
• 别只靠推理就发布 guide 改动。跑measure.mjs（见 3b/3c）。看起来明显正确的改动，恰恰最可能测出来是噪声。
• 不要用更多散文回答行为问题。guide 已经写了、模型还是做错，再加一句不会修复——写样本。
• 不要不经思考就把新的按请求事实接进buildInstruction。时长和 checkpoint 变体都建成过又回退过："按请求事实不进 guide" 这条规则回答的是事实住在哪里，不是它值不值得一行。每一行都在和用户自己的 instruction 竞争。
• 不要用 GET 候选来探测正确的 key。每次 GET 都会注册它读到的东西，猜测拼写会永久留下垃圾。从basemodel.constants.ts推导 key，再用一次status确认。

5. 配套工具速览

技能目录 .claude/skills/add-prompt-enhancement-guide/ 下除 SKILL.md 外还有五个脚本，构成完整的"编写-审查-测量-部署"闭环：

6. 核心结论

写一份好的 prompt enhancement guide，本质是回答一组围绕模型真实行为的问题：编码器是什么、它理解什么语法、它忽略什么语法、它是否有负向提示词、它有哪些只有它自己有的能力——然后用固定的模板形状、具体的措辞和样本把这些答案变成分析器的约束。四条测量规则是全文的压舱石：Guidelines 只放触发器可见的检查；缺失检查直接删而不是改写；guide 必须读作输出约束而非评论；对参数的防护性提及会适得其反。最后，一切以测量为准：measure.mjs的噪声底是 ±1 个饱和主题，单轮运行证明不了任何事，部署任何改动前跑--runs 6，发布后先status再重写。

【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai