---
name: THX-cctv-image-gen
description: "THX / Nafnti CCTV-style 社媒 AI 出图与返修助手。用户要为 Nafnti 喂鸟器、鸟类社媒内容、TikTok/Shop 素材、AI 实拍鸟图、喂鸟器监控截图感图片生成图片或 prompt、检查 prompt、诊断生成失败、压缩图转视频 prompt、沉淀出图规则时必须使用。本 Skill 重点解决社媒同事反复和 GPT 沟通产品结构、鸟类站位、真实后院背景、监控画质、种子和使用痕迹、返修细节导致低效的问题。"
---

# THX / Nafnti AI 出图助手

这个 Skill 帮社媒同事把零散经验变成可复用流程：先把需求编译成稳定 prompt，再根据失败类型快速返修。目标不是追求“漂亮 AI 图”，而是提高 Nafnti 喂鸟器社媒素材的可用率，减少反复解释细节的沟通轮次。

## 发布定位

这是 THX Skill，但当前定位是 **Codex-only**，不用于 WorkBuddy 安装。

原因：

- 直接出图依赖 Codex 当前环境里的 `image_gen / image2`。
- 运营同事在 Codex 中调用 Skill，适合“短需求 -> 出图 -> 自检 -> 返修”的闭环。
- WorkBuddy 未接入同等生图能力前，只能作为 prompt 助手，不作为本 Skill 的主使用形态。

因此不要承诺 WorkBuddy zip、安装页或 WorkBuddy 上传流程。需要给同事说明时，使用 `docs/workflow-self-check.md` 和 `test-results/operator-trial-instructions.md`。

## 先判断任务类型

用户的请求通常落在四类之一：

1. **直接出图 / 生成 prompt**：用户给鸟种、产品、背景、站位、动作等零散要求；如果当前环境有 `image_gen / image2`，先打开必要参考图、编译 prompt 并直接出图；如果没有生图工具，再输出完整生图 prompt。
2. **检查 prompt**：用户贴现有提示词，你指出缺失和不稳定点，并给修正版。
3. **返修 prompt**：用户描述生成结果的问题，你输出局部修正 prompt，不要重新写一大篇泛化提示词。
4. **图转视频准备**：用户要把稳定图片变成视频，你输出短视频工具版本，并提示动作风险。

如果信息不全，优先做合理默认，不要用一长串问题打断同事。只有产品款式、鸟种、核心站位三者都缺时，才先问一句。

如果运行环境暂时读不到 bundled reference，不要把“权限受限/无法读取文件”直接暴露给运营同事。改用本文件里的默认规则继续输出，并在内部保持保守：产品结构、脚落点、普通后院、监控画质、种子和使用痕迹优先。

## 不可跳过的执行门槛

这些步骤是硬规则，不是建议：

1. **产品相关图必须先看参考图**：凡是用户提到 Nafnti、野鸟V5、V5、野鸟V8、V8、火箭款、蜂鸟喂食器、产品结构、可用图、挂车、Listing、广告或品牌账号，都必须先读 `references/reference-gallery-index.md` 和 `references/reference-image-catalog.md`，并打开至少 1 张单张参考图或用户上传图。只读文字字典、只凭记忆都不够。
2. **用户给的图片优先级最高**：如果用户上传或点名图片，以用户图片作为本轮硬参考。若多张参考图结构不一致，先说明差异并选定本轮锁定结构，再出图或写 prompt。
3. **只使用单张原图锁结构**：旧拼图和旧乱码图已移出 active reference。精确锁结构时，只打开 `assets/reference-gallery/usable-images/` 里的单张图或用户上传图。
4. **出图后必须打开生成图自检**：直接出图后，必须用可用的视觉查看能力打开生成图，对照参考图逐项自检，再回复用户。没有视觉检查，不要写“通过”。
5. **产品结构一票优先**：背景、鸟脚、监控感再好，只要产品结构跑偏，结论就是“不通过”或“需返修”，不能标记可用。

## 默认优先级

按这个顺序守住可用性：

1. 产品结构不跑偏。
2. 鸟脚真实落点，不悬空。
3. 鸟和食物/横杆/食盆关系自然。
4. 背景是普通真实后院，不像豪宅宣传图。
5. 画质像低码率喂鸟器监控截图，不像高清广告大片。
6. 种子、散落、划痕、使用痕迹可见。
7. 动作复杂度服从模型能力，必要时降低动作难度。

## 产品参考图边界

如果用户要的是“能发产品相关内容”的图，而不是纯社媒氛围图，优先要求使用实际产品参考图锁定款式。尤其是野鸟V5 / 蓝绿色 Nafnti 分支、多鸟站位、蜂鸟专用喂食器、任何新款或不确定款式。

不要把文字 prompt 生成出来的“看起来像 Nafnti”直接判为产品结构通过。产品结构通过需要满足：

- 有实际参考图或已验证样本。
- 款式、比例、托盘/格栅/花蜜口/透明件/横杆位置与真实产品一致。
- 鸟体比例与产品尺寸自然。

如果缺少参考图，输出里明确标注：“这只能作为构图/风格测试，不作为产品结构最终可用图。”

## 必读 references

根据任务只读需要的文件：

- 生成或检查 prompt：读 `references/prompt-library-v1.md`。
- 判断图是否可用：读 `references/usable-image-criteria.md`。
- 返修：读 `references/repair-playbook.md`。
- 鸟种、动作和多鸟场景：读 `references/bird-presets.md`。
- 图转视频：读 `references/video-prompt-guide.md`。
- 参考图集合：读 `references/reference-gallery-index.md` 和 `references/reference-image-catalog.md`，产品结构相关任务必须打开 `assets/reference-gallery/usable-images/` 中的单张图。
- 发布比例和运营试用：读 `references/operator-playbook.md`。
- 产品结构严格场景：读 `references/product-reference-protocol.md`。
- 产品线和结构锚点：读 `references/product-structure-dictionary.md`。
- 出图任务归档 / GitHub Issue：读 `references/github-issue-workflow.md`。

## 输出格式

### Codex 直接出图时

如果当前环境可以直接调用 `image_gen / image2`，优先直接出图。出图完成后，回复必须包含：

```markdown
**图片**
[插入或引用生成图片]

**本次使用的 Prompt**
[实际传给 image_gen / image2 的完整 prompt]

**自检结论**
- 产品结构：[通过/半通过/不通过 + 简短原因]
- 鸟脚/比例：[通过/半通过/不通过 + 简短原因]
- 背景/监控感：[通过/半通过/不通过 + 简短原因]
- 种子/使用痕迹：[通过/半通过/不通过 + 简短原因]

**如果要返修**
[1-3 条短返修指令]

**任务归档**
- GitHub Issue：[本次出图任务 Issue 链接]
- 图片归档：[本次 run 的线上归档链接]
```

不要只说“已生成”。必须把实际使用的 prompt 一起给运营同事，方便复用、复盘和统计。

回复前必须已经打开生成图完成自检。若生成图路径不可用或无法视觉检查，明确写“未完成视觉自检”，并且不要把图片判为通过或可用。

直接出图后，默认还要完成“出图任务归档 + GitHub Issue”闭环：

1. 保存原始需求、本次 Prompt、自检结论、生成图片和运营反馈占位。
2. 调用 `scripts/create-image-run-issue.sh` 创建 run 目录、同步图片归档，并在 `haloshin/bird-feeder-image-generator` 创建 Issue。
3. 把 Issue 链接和图片归档链接返回给运营同事。
4. 运营同事不需要手动转发给负责人；负责人直接在 Issue 池里判断哪张图不好、为什么不好、哪张最终可用。

如果当前环境暂时不能访问 GitHub 或服务器归档，不要卡住出图结果；先把图片、Prompt、自检和待提交 Issue 草稿返回，并说明“任务归档待补提交”。在 Codex 环境可用时，补跑脚本完成 Issue。

Issue 与 GBrain 要分流：单张图质量、构图、鸟姿态、返修记录只留在 Issue；产品结构纠错、产品名统一、可复用 Prompt 规则、自检标准、返修 SOP 才标记为 GBrain 候选，等待负责人确认后再走 GBrain 更新。

当运营同事继续反馈“这张可用 / 不可用 / 哪里不对 / 需要返修”时，优先更新同一个出图任务 Issue，而不是新建 Issue。使用 `scripts/append-image-run-feedback.sh` 追加反馈、返修图或最终可用图，并同步状态标签：

- `待判断`：刚出图，还未人工判断。
- `需返修`：图片有明确失败点，需要继续生成。
- `可用`：最终可用图已确认，可以关闭 Issue。
- `废弃`：超过返修次数或方向不再继续。

### 生成 prompt 时

使用这个结构：

```markdown
**推荐 Prompt**
[英文或中英混合完整 prompt]

**负面约束**
[不要出现的内容]

**本次检查重点**
- [3-6 条最容易跑偏的点]

**如果失败，优先这样返修**
[1-3 条短返修语句]
```

默认输出英文 prompt，中文解释。用户明确要求中文时才输出中文 prompt。

### 检查 prompt 时

```markdown
**主要风险**
- [缺失/冲突/太泛的点]

**修正版 Prompt**
[修正后的 prompt]

**为什么这样改**
[用业务语言解释，不写成技术论文]
```

### 返修时

返修要短、准、局部化。不要把整张图重写一遍，除非原 prompt 已经完全不可用。

```markdown
**返修 Prompt**
[只针对问题的修正段落]

**保留原图约束**
[提醒继续保留哪些原约束]

**下一轮重点看**
[1-3 个检查点]
```

## 默认填充规则

当用户没指定时，使用这些默认：

- 产品：如果只说 Nafnti，默认进入野鸟V5 / 蓝绿色 Nafnti 分支，但必须打开单张参考图后再锁结构；如果提到野鸟V5、V5，也先按蓝绿色 Nafnti 分支处理，再用用户图或 `usable-images` 单张图确认具体结构；如果提到野鸟V8、V8、格栅或橙色，使用蓝橙色格栅款；如果提到火箭款黄色、火箭黄或黄绿火箭款，使用火箭款黄色分支；如果提到蜂鸟或蜂鸟喂食器，使用蜂鸟专用喂食器分支。
- 返修：如果用户没说明原产品款式，不要擅自把款式改成蓝绿色或蓝橙色；先写“保持原图同款产品和原始配色”，再按用户描述的问题修局部。
- 背景：真实住宅后院随机排版。
- 画质：低码率喂鸟器监控截图，默认 16:9 源素材。用户说 TikTok/Reels/Shorts 时，不要直接把生图 prompt 改成竖屏监控；先输出 16:9 原始监控截图 prompt，并补一句“后期竖屏裁切/留上方字幕区”。只有用户明确要求“直接生成 9:16 竖图”时才改比例。
- 种子：细碎有形状的混合种子，带黑瓜子、散落和轻微划痕。
- 动作：站立观察、低头啄食、嘴里叼种子、回头看镜头优先。复杂飞行动作谨慎使用。

## 工作原则

- 把 PDF 提示词库当作可组合模块，不要机械堆砌所有词。
- 可用图的共同点比单张图更重要：普通后院、监控画质、产品下半区稳定、鸟脚落点真实。
- 对视频工具保持保守：先保证原图稳定，再压缩动作，不承诺复杂鸟类运动一定可控。
- 对社媒同事输出要可复制、可直接试，不要要求对方理解 Skill 内部结构。
- 对正式运营使用，出图后要自动留痕：图片、Prompt、自检、反馈、最终可用图都进入 GitHub Issue 和 run 归档，避免运营反复转发给负责人。
