image-to-code

1实现原理 · 为什么它能做到

强制三段式流程：图像生成 → 深度分析 → 实现，顺序被写成硬规则；『视觉为主的任务此顺序强制』，禁止先自由编码。

依赖宿主图像生成能力而非自带工具：正文反复以『when image generation is available』限定，Codex 内执行最强规则。

『1 section = 1 image』按区段粒度出图：明确写出 1-10 sections 各自对应生成张数，反对一张长图塞全站。

禁裁旧图、鼓励整区重生成：裁剪会毁掉间距/字号比例/边距等提取信息，宁可生成一张新的同语言独立区段图。

分析环节被规定成『提取设计系统』而非看个大概：明文列出可提取要素（文字、字型、字号关系、间距、栅格、按钮层级、色板、圆角逻辑、图像处理等），并允许为看不清的细节再生成特写图。

实现阶段用 copy-discipline + anti-drift 双约束：忠实于参考图，禁止在编码时『顺手改进』成通用模板。

重复重申式 prompt 工程：同一规则（如『不要偷懒少出图』、『禁 cards-in-cards』、『hero 干净』）在多节以不同详略反复出现，构成强制语气梯度。

2核心能力

4管控建议与判定依据

5第二遍独立确认

• [ok] 目录资产面（含隐藏/未跟踪文件） — git ls-files + ls -A 双查：该 skill 目录仅 1 个文件 SKILL.md，无 scripts/references/模板/数据/隐藏文件，无可执行代码。
• [ok] 执行类 token 扫描 — 逐文件扫描 bash/exec/child_process/curl/wget/fetch/axios/process.env/API_KEY/.env/fs./writeFile/.github 等零命中（brutalist 一处 'sans-serifs.' 单词结尾 fs. 为误报，人工复核排除）。
• [ok] 引文逐条 grep -F 字节复核 — 本 JSON 所用全部 quote 均以 grep -F 在 pin commit 工作树中逐条验证存在，无 paraphrase 冒充。
• [ok] 元数据与 pin 核对 — 本地 git HEAD == 任务 pin ccbc15639c97057cbfcf32ecebc38ef716e4bb37（README 显示该提交为 docs/sponsor 修订 #102，2026-08-24）；GitHub API 实查 stars=85698、MIT、pushed_at=2026-08-24T15:23:56Z。frontmatter name 与任务给定名一致。
• [ok] 功能声明 vs 实际能力夸大检查 — description 声称均由 SKILL.md 正文纯 prompt 机制兑现，无脚本可调用、无越界承诺（详见本文件 how_it_works 引文）。
• [ok] 『generate the design image(s) itself』的实现主体 — 文件全部以指令口吻要求模型出图（'you must first generate the design image(s) yourself'），并自限『when image generation is available』；实际图像工具属宿主能力，在 skill 文件内不可定位实现——此为能力前提而非 skill 缺陷，已在 how_it_works/traits 明示。
• [ok] 读取中途出现的省略号是否为文件内容（影响引证准确） — raw 复查+grep：文件内不存在字面 '…' 行；先前读取中的省略是展示层对重复行的压缩，全部引文均已逐条 grep -F 复核，无受影响条目。
• [ok] Codex 内外规则是否冲突 — Codex 内一区一图（§4）与 Codex 外『may still allow more compact multi-section composition』明确按宿主分流，非矛盾；§18 亦以 'Inside Codex' 为界重申 section-first 生成规则。

6结论