1实现原理 · 为什么它能做到
以单体 SQLite 元素库 elements.db 为唯一素材源:1246 条可复用提示词片段(element)构成生成素材池,生成器不做自由创作,只做检索 + 拼接。
- **总元素数**: 1246
人像路径是「框架驱动」:prompt_framework.yaml 用 7 大类字段(subject/facial/styling/expression/lighting/scene/technical)定义人像结构,并把每个字段映射到数据库 category;framework_loader.py 负责加载、依赖推导与 Intent 校验,再按字段查库选元素。
# 人像提示词生成框架 - 7大类模板
Skill 本身不是运行时程序,而是「给 agent 的作业指导书」:SKILL.md 让 agent 自己执行 Python 代码去调 core/ 引擎,skill 的智能体现在让 LLM 承担语义补充与候选挑选。
os.chdir('/Users/serva/.claude/skills/skill-prompt-generator')
v2.0 统一入口按输入自动三分类路由:portrait(纯人像)/ cross_domain(人物 + 动作特效)/ design(海报卡片),再由 CrossDomainGenerator.generate 分派到三个子生成器。
generation_type = self.classify_generation_type(intent)
跨 domain 组合:analyze_required_domains 按 Intent 累加所需 domain(有人物→portrait,有动作/能量→video,有 3D/蜡像→art,设计词→design,并始终加入 common),再按各 domain 的 category 清单逐一查库,把元素利用率从 40.3% 提到 79.9%。
required_domains = self.analyze_required_domains(intent)
设计模式是 SQLite 元素 + YAML 变量的双源融合:design_bridge 一边从库里取主体/技术元素,一边从 YAML 采配色、边框、装饰,再由 build_final_prompt 拼成完整设计规范。
yaml_variables = self.yaml_sampler.sample_variables(style=design_style)
变量采样避免重复:SQLiteVariableSampler 维护最近 100 次采样历史,配合 element_variables 表对元素做参数化采样,命中变量时用采样结果替换模板。
self.max_history = 100 # 保留最近100次采样历史
常识推理来自硬编码知识库:人种→典型眼色/发色、导演风格→光影关键词、人物属性类别保护等映射写在 IntelligentGenerator.load_knowledge(),用于补全用户未明说的属性并防止风格词污染人物属性。
'ethnicity_typical_eyes': {
自学习闭环:prompt-extractor 先做语料清洗/聚类/模块化提取,universal-learner 按 6 步流程(类型识别→领域分类→元素提取→打标签→复用性打分→写库)把元素写回 elements.db,且明确是半自动、需人工审核。
**学习方式**: 半自动(生成报告 + 人工审核)
2核心能力
3外部依赖
| Kind | Dependency / Endpoint |
|---|---|
| package | pyyaml>=6.0 |
| package | anthropic>=0.7.0(声明依赖但全仓 Python 代码零 import,仅 learner.md 伪代码示例引用) |
| cli | python3(运行 core/ 引擎、preprocessor.py、xray_helper.py) |
| cli | bash(skill 自带测试脚本 shell) |
| cli | python3 prompt_tool.py(prompt-master 旧架构声明的 CLI,脚本在 pin commit 的仓库内不存在) |
4管控建议与判定依据
- scripts/: 执行本地脚本或命令: core/cross_domain_generator.py(SKILL.md 指示 agent 在宿主执行:from core.cross_doma
- 本地工作目录: 文件读写与工件输出: extracted_results/elements.db —— save_generated_prompt 写 generated_prompts
5第二遍独立确认
- [ok] 主入口判定(skill.path 该写哪一个) — .claude/skills/ 下确为 12 个 skill 目录(art-master / design-master / domain-classifier / intelligent-prompt-generator / product-master / prompt-analyzer / prompt-extractor / prompt-generator / prompt-master / prompt-xray / universal-learner / video-master)+ learner.md。定位依据两条:claude.md 项目架构段「**入口**:`.claude/skills/intelligent-prompt-generator/skill.md`」(实测文件名为大写 SKILL.md,属大小写笔误);路由指南把 portrait domain 与人像请求固定指向 intelligent-prompt-generator。另注 prompt-master 自己标注「⚠️ 旧架构」,故不选它作入口。本条目录已写入 skill.path。
- [ok] .codex/skills 与 .claude/skills 是否内容相同 — diff -rq .claude/skills .codex/skills 无任何输出(完全一致);两侧各 35 文件、320,220 字节;md5 抽查 intelligent-prompt-generator/SKILL.md 均为 39dc6f78ad6b580eae2dbdedfcd64bfc、prompt-extractor/preprocessor.py 均为 c8d488bdb22a29334eb15b8025bce14d、SKILL_ROUTING_GUIDE.md 均为 d59be53db785d50d68f6962ab2bacb14。平台差异只在 claude.md vs codex.md:5 处(标题、入口路径 .claude→.codex、两处平台名、一处 「Claude Code 有多强」→「Codex Code 有多强」)。
- [discrepancy] README/claude.md 宣传的 12 个 skill 是否都存在 — claude.md 与路由指南反复推荐设计类请求调用 `prompt-crafter`(⭐,20万+组合),但 .claude/skills 与 .codex/skills 下都没有 prompt-crafter 目录(grep 命中仅在 README.md/claude.md/codex.md/core/yaml_sampler.py/schema_migration_v1.sql/README_v2.0.md/UPGRADE_GUIDE_v2.0.md 的文本里)。其声称的能力实际由 core/yaml_sampler.py + core/design_bridge.py 实现,并挂在 intelligent-prompt-generator 的 Design 模式下。README 第 33 行另列了 `prompt-writer`,同样不存在,且该行自相矛盾地写「12个专业领域Skills」却列出 13 个名字。
- [discrepancy] 文档引用的脚本/数据文件是否真实存在 — 实测 MISSING:prompt_tool.py(prompt-master/skill.md 的 20+ 条 python3 prompt_tool.py ... 命令全部指向它)、prompt_analyzer.py(prompt-analyzer/SKILL.md 的 from prompt_analyzer import analyze_prompt_detail)、learner.py、facial_features_library.json(prompt-master 的旧数据源)、module_library.json、extracted_modules.json(universal-learner 声明的输入)、universal_elements_library.json(element_db.export_library 的输出名)。.gitignore 显示这些被当作「临时开发脚本/大 JSON」排除,即用写作期本机文件而非仓库可交付资产。
- [discrepancy] 元素数量声明三处互相矛盾 — README.md 声明 1246 且分领域明细(portrait 502/common 208/design 166/...)与 sqlite 实测 elements 表逐项吻合;但 claude.md 架构表写「1103元素,12领域」「intelligent-prompt-generator | portrait | 491」,路由指南同样写 491/51/59/77/49;而数据库 domains.total_elements 汇总只有 967(portrait 491/common 203/interior 79/product 77/design 59/art 51/video 49/prompt_writing 9),是早期快照未随 elements 表刷新。结论:README 的 1246 可信,claude.md 与路由指南的 491/1103 属过期数字。
- [discrepancy] 「20万+ 组合」能否复算 — YAML 里可枚举的离散选项:37 个色值 × 每风格边框 (corner_radius 5 × box_shadow 3 × border 2 = 30) × 装饰 9 种 ≈ 9,990,量级差 20 倍。要把数字推到 20 万级需要把装饰的 count_range/rotation_range/size_range/opacity_range 这些连续区间按整数粒度展开计数(如星星 count 3-8 = 6 档 × rotation ±15 = 31 档 × size 16-32 = 17 档…),代码里并无这种展开逻辑(sample_variables 只是 random.choice 抽一组)。故「20万+」是营销口径的上界估计,非可复现统计。
- [ok] 是否存在网络调用(含间接依赖) — 字符串扫描 requests/urllib/http://|https:///socket/curl/wget 在 15 个脚本中零命中;全部 import 清单实测为 os/json/sqlite3/re/yaml/sys/csv/random/time/re/Path/typing/collections/datetime 以及本项目内部模块(core.*、intelligent_generator、framework_loader)。requirements.txt 的 requests/pandas 被注释为可选,未安装也未使用。结论:零网络外发,security.network_calls 填空数组是准确而非漏查。
- [ok] 是否存在凭证/环境变量读取 — os.environ/getenv/keychain 零命中;.env 仅出现在 .gitignore 的忽略规则里(仓库内无 .env 文件)。requirements 声明 anthropic>=0.7.0 但全仓 grep anthropic 只命中 requirements.txt 与两份 learner.md,且 learner.md 自述「当前实现中,AI辅助提取功能返回空列表,需要集成真实的LLM API」——即不上传任何 key,也不调用任何模型 API。
6结论
c4376bb8c7682856…