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 服务与生态级 guide1.1 服务的职责orchestrator 的 prompt-analysis 服务按生态工作输入用户的 prompt输出结构化反馈 增强重写。每个生态有自己独立的 system prompt针对该模型的提示词惯例调优标签式还是自然语言式tag-based vs natural-language权重语法weight syntax是否生效是否支持负向提示词negative prompt文字渲染text rendering能力视频模型的运镜/动作词汇camera/motion vocabularyguide 的质量直接决定分析器给出的反馈与重写是否符合该模型的真实行为——这也是为什么仓库内专门为编写 guide 建了一个 skill。1.2 范围仅限图像与视频生态不要为 3D、音频或其他模态编写 guide。tripo、hunyuan3d、polygen图生 3D、ace音频明确超出范围之后出现的任何非图像/视频生态同理。理由写得很直白guide 模板完全围绕 subject / lighting / camera / composition / style 构建这些词汇描述不了从图片生成网格或生成一首歌用该模板硬套其他模态产出将是自信地错而不是略显单薄。让这些生态停留在内置 fallback 上是刻意的选择。2. 编写前必须提供的两个输入2.1 输入一生态 keyecosystem key生态 key 来自 packages/civitai-shared/src/basemodel.constants.ts 中生态记录的key字段转小写后使用。例如生态常量文件中的 key转小写后的 guide keyMiniMax H3MiniMaxH3minimaxh3Flux1 KontextFlux1Kontextflux1kontextWan Video 2.5 I2VWanVideo-25-I2Vwanvideo-25-i2vHunyuan Video V1HyV1hyv1在仓库中可确认这些 key 确实存在basemodel.constants.ts 定义了key: Flux1Kontext另有key: SD1L340、key: SDXLL368、key: HyV1L423、key: WanVideoL432、key: PonyL580、key: MiniMaxH3L789等。注意 src/shared/constants/basemodel.constants.ts 只是同一模块的一行 re-export shim不是过期的重复文件——从两个路径导入均可。关键定义它就是 AIR 的生态值转小写。同一个字符串出现在urn:air:ecosystem:...中。src/shared/utils/air.ts 的getAirEcosystem是二者的单一事实来源stringifyAIR用它生成 URNcreatePromptEnhancementStep也用它定位 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 输入二参考资料至少提供下列之一URLHuggingFace 模型卡、官方公告、服务商文档页粘贴的模型描述 / 提示词指南规格表架构、编码器、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 users 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 users original intentGuidelines 的最后两条是硬性要求所有 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 的四次测量表明Guide主题携带不要单独提出这句删除该句后seedanceaudio98%70 / 72%由样本推动与句子无关wanvideo-25-t2vcamera89%41 / 50%wanvideo-22-t2v-a14bcamera89%35%happyhorsecamera84%v2弱化48%v3删除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 models 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 发布中活下来的每一项都有瞄准饱和主题的样本minimaxh3camera/audio 98→65、sdxllighting 89→55/66、ltxv23audio 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所有状态变更调用都要求--writableput之后会校验回读实现见 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 --writableguide 以纯文本文件经--prompt-file传入——它包含反引号、换行和引号会破坏 shell 转义。--file接受完整 JSON body需要samples时用。模型绑定PromptAnalysisGrain.DefaultModelId现在已是 qwen3 URNcivitai-orchestrationPR #297所以全新生态上的put不传--model会继承正确模型。但显式传--model urn:air:qwen3:repository:huggingface:Civitai/Qwen3.6-35B-A3B-Abliterated-AWQmain.tar仍是更安全的习惯——它能在常量未来变更后存活且每份现存 guide 都是这么存的。改绑现有 guide 而不动文本用set-modelnode .claude/skills/add-prompt-enhancement-guide/manage.mjs set-model key \ --model urn:air:qwen3:repository:huggingface:Civitai/Qwen3.6-35B-A3B-Abliterated-AWQmain.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.csGET 也会注册。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 字符 guideset-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 fsrequire(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-AWQmain.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 外还有五个脚本构成完整的编写-审查-测量-部署闭环文件职责manage.mjs列出/读取/写入/删除 orchestrator 的/v1/manager/prompt-analysis/*管理端点所有写操作要求--writable读取项目.env中的ORCHESTRATOR_ENDPOINT与ORCHESTRATOR_ACCESS_TOKENmeasure.mjs以主题浓度为指标用prompts.json的通用语料对 guide 打分--runs控制轮数--candidate支持不改注册表的 A/Baudit.mjs静态审计 guide 文本含EMPHATIC-CAPABILITY等检查硬编码的OUT_OF_SCOPE集合ace、tripo、hunyuan3d、polygen与 SKILL.md 的范围约定一致prompts.json共享通用测量语料——测量时使用它避免围绕某份 guide 写语料带来的美化偏差rewrite.mjs、run-queue.mjs重写与批量运行辅助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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考