ai-artist

Codex 兼容性说明：

• 在 Codex 中使用 $skill-name 调用仓库技能；此镜像副本会改写旧版 Claude /skill-name 引用。
• 任务跟踪要求：在执行任何工作流或技能步骤之前，先创建／更新所有步骤的任务跟踪，并随着进度变化保持同步。
• 用户提问提示表示要在 Codex 中直接询问用户。
• 出现 Claude 专属的模式切换说明时，请忽略。
• 严格执行约定：用户明确调用某项技能时，按原文执行该技能协议。
• 子 Agent 授权：用户调用或 AI 检测到某项技能，且其协议要求使用子 Agent 时，该技能激活即授权为此任务使用所需的 spawn_agent 子 Agent。
• 除非用户事先明确批准偏离，否则不得跳过、重排或合并协议步骤。
• 对于工作流技能，明确执行每个列出的子技能步骤，并逐步报告证据。
• 如果所需步骤／工具在此环境中无法运行，请停止并询问用户，然后再进行调整。

Codex 项目参考资料加载（无 Hook）

Codex 不会接收基于 Claude Hook 注入的文档。 进行编码、规划、调试、测试或审查时，请按以下路由显式打开项目文档。

始终阅读：

• docs/project-config.json（项目特定路径、命令、模块以及工作流／测试设置）
• docs/project-reference/docs-index-reference.md（指向完整 docs/project-reference/* 目录的路由）
• docs/project-reference/lessons.md（始终适用的防护措施和反模式）

按情境阅读文档：

• 后端／CQRS／API／领域／实体变更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• 前端／UI／样式／设计系统：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 规范／测试用例规划或 TC 映射：feature-docs-reference.md
• 集成测试的实现／审查：integration-test-reference.md
• E2E 测试的实现／审查：e2e-test-reference.md
• 代码审查／审计工作：code-review-rules.md，以及根据变更文件选择的领域文档

不要不加选择地阅读所有文档。从 docs-index-reference.md 开始，然后只打开与任务相关的文件。

快速摘要

目标： 为 AI 文本、图像和视频生成模型（Claude、GPT、Midjourney、DALL-E、Stable Diffusion、Flux、Veo）编写并优化提示词。

工作流：

1. 识别 — 确定模型类型（LLM、图像、视频）和预期结果
2. 构建结构 — 应用特定于模型的提示词模式（LLM 使用角色／上下文／任务，图像使用主体／风格／构图）
3. 优化 — 通过 A/B 测试、风格关键词和负面提示词反复迭代

关键规则：

• 将清晰度、上下文、结构和迭代作为核心原则
• 应用特定于模型的语法（Midjourney --ar、SD 加权词元等）
• 加载参考文件，获取各领域的详细指导（营销、代码、写作、数据）

保持怀疑。运用批判性思维和顺序思维。每项论断都需要可追溯的证据和置信度百分比（观点应超过 80%）。

AI 艺术家 - 提示词工程

为 AI 文本和图像生成模型编写有效的提示词。

核心原则

1. 清晰 — 具体明确，避免歧义
2. 上下文 — 预先设定场景、角色和限制条件
3. 结构 — 使用一致的格式（Markdown、XML 标签、分隔符）
4. 迭代 — 根据输出进行优化，并对不同版本进行 A/B 测试

快速模式

LLM 提示词（Claude/GPT/Gemini）

[Role] You are a {expert type} specializing in {domain}.
[Context] {Background information and constraints}
[Task] {Specific action to perform}
[Format] {Output structure - JSON, markdown, list, etc.}
[Examples] {1-3 few-shot examples if needed}

图像生成（Midjourney/DALL-E/Stable Diffusion）

[Subject] {main subject with details}
[Style] {artistic style, medium, artist reference}
[Composition] {framing, angle, lighting}
[Quality] {resolution modifiers, rendering quality}
[Negative] {what to avoid - only if supported}

示例：Portrait of a cyberpunk hacker, neon lighting, cinematic composition, detailed face, 8k, artstation quality --ar 16:9 --style raw

参考资料

加载以下文件以获取详细指导：

主题	文件	说明
大模型	references/llm-prompting.md	系统提示词、少样本示例、思维链、输出格式
图像	references/image-prompting.md	风格关键词、模型语法、负面提示词
Nano Banana	references/nano-banana.md	Gemini 图像提示词、叙事风格、多图像输入
高级	references/advanced-techniques.md	元提示词、链式调用、A/B 测试
领域索引	references/domain-patterns.md	通用模式、领域文件链接
营销	references/domain-marketing.md	标题、产品文案、邮件、广告
代码	references/domain-code.md	函数、审查、重构、调试
写作	references/domain-writing.md	故事、角色、对话、编辑
数据	references/domain-data.md	提取、分析、比较

特定模型提示

模型	关键语法
Midjourney	--ar、--style、--chaos、--weird、--v 6.1
DALL-E 3	自然语言，无参数，可选 HD 质量
Stable Diffusion	加权词元 (word:1.2)、LoRA、负面提示词
Flux	自然语言提示词、风格混合、--guidance
Imagen/Veo	描述性文本、宽高比、风格参考

反模式

• 指令含糊（“做得更好”）
• 约束相互冲突
• 领域任务缺少上下文
• 提示词冗长，包含多余细节
• 忽视模型特有的优势／局限

---

[IMPORTANT] 开始前，使用任务跟踪将所有工作拆分为小任务——包括为每个要读取的文件创建任务。这样可以避免长文件导致上下文丢失。对于简单任务，AI 必须主动询问用户是否跳过。

防止 AI 犯错 — 每项任务都要避免以下失败模式：

删除前检查下游引用。 删除组件会导致文档和代码连锁过时。删除前，梳理所有引用该组件的文件。 根据实际代码验证 AI 生成的内容。 AI 会臆造 API、类名和方法签名。记录或引用之前，务必使用 grep 确认它们确实存在。 编辑后追踪完整依赖链。 只修改定义，会遗漏由此派生的下游变量和使用方。务必追踪完整依赖链。 验证正确性时追踪所有代码路径。 确认代码存在，不等于确认代码会执行。务必追踪提前退出、错误分支和条件跳过，而不只是正常路径。 调试时，先问“这是谁的职责？”，再修复。 追踪问题是在调用方（数据有误）还是被调用方（处理有误）。在负有责任的层级修复，绝不要只修补症状出现的位置。 假定现有值是有意设置的——修改前先问为什么。 修改任何常量、限制、标志或模式前：阅读注释，检查 git blame，并查看周边代码。 验证所有受影响的输出，而不只是第一个。 修改涉及多个技术栈时，必须验证每个输出。一项检查通过，不代表所有检查都通过。 整体优先的调试方式——避免只关注最近的线索。 调查任何故障时，先列出所有前置条件（配置、环境变量、数据库名称、端点、DI 注册、数据前置条件），再逐项根据证据验证，然后才提出任何代码层面的假设。 精准修改——遵循差异测试。 修复 Bug：每一处修改都必须能直接对应到该 Bug。不要顺手重排样式或改进相邻代码。增强任务：实现改进，并明确说明。 编码前明确歧义——不要默默做出选择。 如果请求有多种解释，请逐一列出并估算工作量，然后询问用户。绝不要擅自假定要处理所有记录、采用基于文件的方案或选择更复杂的路径。

批判性思维 — 运用批判性思维和序列化思维。每个主张都必须有可追溯的证据，置信度 >80% 才能采取行动。 防止幻觉： 绝不要把猜测说成事实——每个主张都要引用来源，坦然承认不确定性，自查输出错误，独立交叉验证，并对自己的判断保持怀疑——没有证据的确信是所有幻觉的根源。

必须主动运用批判性思维——每个主张都必须有可追溯的证据，置信度 >80% 才能采取行动。防止幻觉：绝不要把猜测说成事实。

必须主动落实 AI 错误防范措施——整体优先地调试，在负有责任的层级修复，编码前明确歧义，并在压缩上下文后重新阅读文件。

收尾提醒

• 强制执行，重要，必须主动： 开始前，使用任务跟踪将工作拆分为小型待办任务
• 强制执行，重要，必须主动： 创建新代码前，在代码库中搜索 3 个或更多相似模式
• 强制执行，重要，必须主动： 为每个主张提供 file:line 证据（置信度 >80% 才能采取行动）
• 强制执行，重要，必须主动： 添加一项最终审查待办任务，以验证工作质量

[TASK-PLANNING] 开始前，分析任务范围，并使用任务跟踪系统地将任务拆分为小型待办任务和子任务。

无 Hook 提示词协议镜像（自动同步）

来源：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] 工作流执行协议 — 强制、重要、必须、关键。无论出于何种原因，都不得跳过。

通用可移植性边界： 可复用的技能和协议文本应与项目无关；从 docs/project-config.json 和 docs/project-reference/ 中查找项目特定约定。应用 shared/sdd-artifact-contract.md 中的共享 AI-SDD。阅读 docs/project-config.json 和 docs/project-reference/docs-index-reference.md，然后打开其中列出的项目参考文档。只要具备此共享上下文和本地文档，任何受支持的 AI 工具都可以执行。

1. 检测： 将提示词与工作流目录进行匹配
2. 分析： 找出最匹配的工作流，并评估自定义步骤组合是否更合适
3. 询问（必需格式）： 直接向用户提问，采用以下结构；除非用户明确调用了某个工作流／技能，且本地协议将明确调用视为确认：
   • 问题："你想启用哪个工作流？"
   • 选项 1："启用 [最佳匹配工作流]（推荐）"
   • 选项 2："启用自定义工作流：[步骤 1 → 步骤 2 → ...]"（附上一句话说明理由）
4. 启用（确认后）： 标准工作流调用 $workflow-start <workflowId>；自定义步骤按顺序手动执行
5. 创建任务： 跟踪工作流的所有步骤
6. 执行： 按顺序遵循每个步骤 [CRITICAL-THINKING-MINDSET] 运用批判性思维和顺序思维。每项声明都必须有可追溯的证据；置信度超过 80% 才能采取行动。 反幻觉原则： 切勿将猜测当作事实；每项声明都要引用来源；坦率承认不确定性；自行检查输出是否有误；独立交叉核对；对自己的判断保持怀疑——没有证据的确信是所有幻觉的根源。 AI 注意力原则（首因－近因效应）： 对于较长的提示词／协议，将最关键的 3 条规则同时放在开头和结尾，以确保指令在较长上下文窗口中仍能得到遵循。 目标驱动执行： 先定义成功标准，循环执行直至验证通过，并且只有在可观察的检查均通过后才停止。 测试验证意图： 测试必须保护业务规则／不变量，并在受保护的意图被破坏时失败，而不能只照搬当前行为。

[LESSON-LEARNED-REMINDER] [BLOCKING] 任务规划与持续改进 — 强制执行。不得跳过。

开始前将工作拆分为小任务并进行跟踪。添加最终任务："分析 AI 错误与经验教训"。

提取经验教训——仅限根本原因，不处理表面症状：

1. 指明失败模式（推理／假设失误），而非症状——例如“未阅读源代码就假设 API 存在”，而不是“使用了错误的枚举值”。
2. 通用性测试：此失败模式是否适用于 ≥3 种情境／代码库？如果不适用，就再抽象一层。
3. 将其写成通用规则——去除项目特定的名称／路径／类。该规则应适用于任何代码库。
4. 合并：多个错误若有相同的失败模式 → 总结为一条经验教训。
5. 重复发生检查：“如果没有这条提醒，未来会话中还会发生这种情况吗？”——不会 → 跳过 $learn。
6. 自动修复检查：“$code-review／$code-simplifier／$security／$lint 能否发现此问题？”——能 → 改进相应的审查技能。
7. 两项检查均通过 → 请用户运行 $learn。 [TASK-PLANNING] [MANDATORY] 在执行任何工作流或技能步骤之前，先为所有计划步骤创建／更新任务跟踪；然后随着每个步骤开始／完成，持续同步任务状态。