别把 Skill 当滤镜
照片没上传、RAW 直接喂、示例被当模板、原图文字遭重绘，是使用 photo-abstract-editorial 最常见的失败点。本文从真实 Issue 与项目约束出发，给出可复现的安装、输入预处理、提示词编排和验收方法。
title: “别把 Skill 当滤镜” description: “照片没上传、RAW 直接喂、示例被当模板、原图文字遭重绘，是使用 photo-abstract-editorial 最常见的失败点。本文从真实 Issue 与项目约束出发，给出可复现的安装、输入预处理、提示词编排和验收方法。” topic: “ai” type: “hot” github: “ZzzLc0405/photo-abstract-editorial” pubDate: 2026-06-30 level: “intermediate” sources:
- “GitHub Trending”
- “GitHub Issues”
- “GitHub Pull Requests”
photo-abstract-editorial 不是 Photoshop 滤镜，也不是独立生图模型，而是一套供支持 Skills 与图像生成工具的 AI Agent 使用的编辑规范：它把一张上传照片与由该照片提炼出的抽象面板，组合成干净的竖版杂志视觉。项目要求忠实保留摄影主体，再从空间、色调、比例、节奏和负空间中提取少量几何关系。它在 2026 年 8 月上线数日便获得 1944 Star，原因不只是成品醒目，更在于它把“审美提示词”包装成可复用、可审查的工作流；与此同时，输入格式、调用插件和示例边界也迅速成为真实 Issue 与 PR 的焦点。
1. 为什么安装后没有自动生成图片？
Issue #1 的典型现象是：在 Windows 桌面端进入 Codex 标签后，Agent 只尝试寻找本地图形工具，无法直接调用用户预期的图像模型。根因是 Skill 只负责告诉 Agent 怎样分析、怎样构图以及不能做什么，自身不包含模型权重或渲染器；仓库作者也明确回复需要使用 image gen 插件。因此，“仓库已安装”不等于“图像能力已接通”。
先把仓库放进客户端支持的 Skills 目录，并确认目录根部仍有 SKILL.md：
git clone https://github.com/ZzzLc0405/photo-abstract-editorial.git
mkdir -p ~/.agents/skills
cp -R photo-abstract-editorial ~/.agents/skills/photo-abstract-editorial
ls ~/.agents/skills/photo-abstract-editorial/SKILL.md然后在具备图像生成工具的会话中上传照片，并明确说：“使用 photo-abstract-editorial Skill 和 image gen，只输出一张最终成品。”若工具列表里没有图像生成器，换提示词也无效，应先处理客户端能力或插件配置，而不是让 Agent 假装完成渲染。
2. RAW、HEIC 或动态 GIF 为什么处理失败？
常见现象包括读不到 DNG、HEIC 色彩偏灰，以及动态 GIF 被随机抽帧。PR #4 正是为这类歧义补充输入契约：Skill 直接接受 JPEG/JPG、PNG、WebP 和静态 GIF；RAW、DNG、CR2/CR3、NEF、ARW、RAF、HEIC、TIFF、SVG、PDF 都不是直接输入格式。根因在于不同运行环境的解码器、色彩管理和 RAW 默认曲线并不一致，Agent 若声称“直接处理”，结果便无法复现。
正确做法是保留原文件，额外导出中性的 sRGB JPEG 或 PNG；转换阶段不要创意调色、裁切、修图或生成式扩图。例如使用 ImageMagick 处理 HEIC：
magick input.heic -auto-orient \
-colorspace sRGB -strip -quality 95 output.jpgRAW 应优先通过相机厂商软件或可靠 RAW 工具做中性显影。动态 GIF 则先由用户选定代表帧。环境无法保证中性转换时，直接要求用户提供渲染后的 JPEG/PNG，比静默改变照片更符合 Skill 的“忠实保留”原则。
3. 为什么结果像套模板，甚至抄了示例配色？
用户容易把 assets/examples 里的五张图当成待处理输入或固定模板，于是模型复用夕阳横带、建筑轮廓、标题位置和既有色彩。PR #4 指出文档与提示词契约曾发生漂移：README 把图库称为输入示例，但它们其实是完整成品；其中两张还出现了输出规则禁止的新加色卡。
解法是把示例当作“行为测试”，而不是视觉素材。提示词应先要求模型从当前照片独立识别三到六个决定性事实，再设计下方面板：
先列出但不要展示：主体关系、尺度、主轴、重叠、明暗角色与负空间。
仅从本次上传照片提炼抽象形状和颜色。
不得复用仓库示例的主题、色板、母题、标题或布局。
保持原摄影区域不被重画、滤镜化、矢量描摹或生成式扩展。“参考”应理解为学会压缩关系：宽阔落日可变成稀疏横带，人群可变成不规则节奏，建筑可保留少量身份线索；它不意味着每次都复制同一种杂志版式。
4. 原照片有招牌和数字，应该全部删除吗？
不少图像提示词强调“不要文字”，模型便可能擦除店招、车牌、建筑编号，或者重画成乱码。PR #4 对此修正规则：原照片里已有的文字和数字必须原样保留；被禁止的是模型新增的日期、编号、地点说明、色卡、图例、签名、Logo、水印等内容，最终主标题与可选副标题除外。
提交任务时应把“源内容”和“新增内容”分开声明：摄影区域保持像素语义忠实，不删除、不翻译、不纠正既有字样；抽象面板只允许一个确定的标题和必要副标题，不输出候选标题列表。验收时放大检查招牌边缘、细小数字和文字笔画。如果出现乱码，优先重做并加强“不得重绘摄影区域”，而不是用二次生成局部修补，因为后者更容易继续篡改原片。
5. 怎样判断成品真的遵守了 Skill？
“看起来好看”不是充分条件。这个项目的核心过程是 DECONSTRUCT → SELECTIVE PRESERVATION → ABSTRACT / DISTILL → RECONSTRUCT：先拆出关系，再选择性保留，最后重组；失败结果通常表现为整张照片被海报化、下方面板凭空添加小物件、人物变成整齐胶囊图标，或背景不再均匀。
可在每次生成后执行四项验收：第一，摄影区域的主体、裁切、文字与色彩角色是否忠实；第二，抽象元素能否逐一映射到照片里的轴线、间隔、重叠或明暗；第三，是否出现照片不存在的对称、建筑细节或真实小物件；第四，除标题与可选副标题外，是否新增了任何文字、数字、色卡和水印。未通过时不要泛泛要求“更高级”，而要按条目返工，例如：“删除新增色卡；保留原图招牌；将规则化人形改为不等距、不同尺度的简化标记。”这种约束式反馈比追加风格词更稳定。