把结构化数据/笔记转化为 AnyCap…

当用户提供表格、JSON、要点、研究笔记或产品事实等数据优先的输入，需要产出 AnyCap 网站风格的博客/教程/SEO 文章并按需配图时使用。

适用场景

解决思路

1. 先运行 `anycap status` 确认 AnyCap 可用。
2. 编辑前先检查页面结构：找到基础页面、本地化包装文件，确认本地化或重复路由是否只是重新导出基础页面。
3. 把输入数据规范化为工作简报：文章主题是什么、面向谁、数据实际证明了什么、一句话答案或承诺是什么、哪些可以自信陈述、哪些仍未知。
4. 检查 git worktree，不要覆盖用户无关的改动。
5. 写作前先阅读语气与结构参考文件（voice.md、patterns.md、input-brief.md）。
6. 把用户提供的要点、产品事实、竞品笔记、表格导出、JSON、URL、基准数据或粗略观察转化为紧凑的内部简报：目标读者、搜索或页面意图、页面论点、3-6 条支撑事实、缺失的证据或不确定性、推荐的页面形态。
7. 若输入稀疏，谨慎推断，但让文章范围严格限定在数据能支撑的范围内。
8. 按 AnyCap 网站语气起草，默认结构为：短眉题、带一个具体承诺的直接 H1、面向已知类别读者的简洁引言、靠近顶部的答案优先摘要块、一个或多个结构化章节（工作流/对比/清单/用例/FAQ）、引导读者到下一个相关页面的 CTA 或内链。
9. 不要以泛泛的场景铺垫开头，直接从实际问题、约束或有用的结果开始。
10. 根据页面主张匹配证据类型：展示最终成果就生成一张精修主图或展示图；展示转变就先生成粗糙原图再基于同一主体生成精修后图；展示范围或迭代就生成三联图或多变体评审板；支撑基于时间的流程就生成代表简报的配套静帧或关键帧，不要把静态图当作完整视频结果；支撑基于音频的流程就生成情绪图或封面视觉，不要暗示图片是音频输出；支撑流程解释就生成干净的步骤插图或类图表视觉。
11. 如果文章本身已成立，不要强行加媒体证据块，本技能用于有用的证据而非装饰性填充。
12. 若文章需要媒体，先查看实时模型目录与 schema：`anycap image models`、`anycap image models <model> schema --operation generate --mode <mode>`、`anycap video models`、`anycap video models <model> schema --operation generate --mode <mode>`、`anycap music models`、`anycap music models <model> schema --operation generate`。
13. 绝不要假设模式名、参数名或支持的宽高比。
14. 把素材生成到可复用的公共路径，使用描述性文件名并让相关产物放在一起，例如 `mkdir -p web/public/content-evidence` 后运行 `anycap image generate --model <model> --prompt "<subject-specific brief> ... no readable text, no watermark" --param aspect_ratio=16:9 -o web/public/content-evidence/<page-slug>-hero.png`。
15. 生成规则：始终用 `-o` 加描述性文件名；主图或展示块优先用 `16:9`，除非布局需要其他比例；before/after 工作流要清晰分版本或分文件；生成时素材要针对主题，但技能本身保持主题无关；若页面通过包装文件本地化，除非确实需要特定语言图片，否则共享素材。
16. 接入页面前用 AnyCap vision 验证素材：`anycap actions image-read --file web/public/content-evidence/<page-slug>-hero.png --instruction "Describe this image, confirm it matches the intended page claim, and mention any visible text or watermark."`。
17. 编辑工作流要对比原图与修订图：`anycap actions image-read --file web/public/content-evidence/<page-slug>-before.png --file web/public/content-evidence/<page-slug>-after.png --instruction "Confirm whether the second preserves the same subject while improving composition and background cleanliness."`。
18. 若验证发现可见文字、杂散标牌、主体身份错误或提示漂移，先重新提示并重新生成，再改代码。
19. 优化素材并接入可复用代码：视觉差异可接受时把过大 PNG 压缩为 JPG 或 WebP；优先用可复用组件加查找表，而不是在每个页面重复大段 JSX；说明文字要符合事实（静态图可说明是通过 AnyCap 为页面生成，基于时间或音频的页面要明确标注视觉为配套静帧或封面视觉）；若本地化路由只是重新导出基础页面，只编辑基础页面一次；可复用块要足够通用，能直接放入文章、指南或落地页而无需重写组件。
20. 对改动的文件运行针对性检查，例如 `pnpm exec eslint 'src/components/seo/ContentEvidenceBlock.tsx' 'src/lib/content-evidence.ts' 'src/app/(seo)/<section>/<page>/page.tsx'`。
21. 若全仓库类型检查因既有问题失败，记录确切的阻塞文件，并让技能输出聚焦于实际验证过的内容。
22. 默认交付物：从输入数据提炼的紧凑简报、AnyCap 网站语气的文章草稿、稳定公共目录中的生成素材、多个页面需要同一证据模式时的一个可复用内容或 UI 组件、解释素材证明了什么的页面文案、与真实产物匹配的 alt 文本/说明/提示块、覆盖生成/验证/代码检查的简洁验证说明。

适用边界 · 注意事项

• 不要写可属于任何 SaaS 网站的通用「AI 博客」文案。
• 不要让文章超出所提供数据能支撑的范围。
• 不要把答案埋在冗长的暖场之后。
• 当重点就是展示 AnyCap 第一方输出时，不要使用图库素材。
• 不要把静态图片当作视频或音乐模型的实际输出。
• 除非页面明确需要，不要在展示素材中留下可见文字或水印。
• 当包装文件已复用基础页面时，不要重复实现本地化页面。
• 当缺失的是证据时，不要用泛泛文字堆砌页面。