需要为 Web 应用生成可部署营销展示网站时，用真实截图和…

当你要为一个 Web 应用（尤其是复杂或 AI/Agent 类应用）制作营销展示站点时，通过浏览运行中的应用、捕获截图与工作流动画，生成多页面可部署的展示网站。

适用场景

解决思路

1. 先确定深度级别：quick 为单页（hero+功能+CTA，15-20 分钟）；standard 为多页站点（首页、功能页、how-it-works 带截图，1-2 小时）；thorough 为综合站点（首页、每功能独立页、动画 GIF 演示、用例页、对比页、文档式演示，3-6 小时）；默认 standard。
2. 开始前检测可用的浏览器工具：优先 Chrome MCP（mcp__claude-in-chrome__*，适合需登录的应用），其次 Playwright MCP（mcp__plugin_playwright_playwright__*，适合公开应用），再次 playwright-cli（用于脚本化流程）。
3. 收集输入信息：应用 URL（必填）、应用名称（必填）、标语、目标受众、定价信息、CTA 文案与链接、用户评价（可选）。
4. 用 bin/ 中的 capture-screenshots 捕获截图，比每次生成 Playwright 脚本更快更一致。快速捕获示例：capture-screenshots http://localhost:5173 --pages /,/dashboard,/contacts,/settings --output showcase/screenshots --prefix screen --mobile --dark，一次生成桌面（1280x720）、移动（375px）和暗色模式变体。
5. 对需登录的应用加 --auth user:password 参数捕获。
6. 捕获内容包含：a) 第一印象（主页/仪表盘作为 hero 图）；b) 功能（用 --pages 列出所有导航路径，捕获 6-10 个关键屏）；c) How It Works 流程（用 --prefix workflow-step 多次运行捕获各步骤）；d) 细节特写（用 --full-page 捕获可滚动内容）；e) 明暗两种模式（--dark 自动捕获，hero 选最好看的模式）。
7. 捕获后优化：img-process batch showcase/screenshots --action optimise --max-width 1920 -o showcase/screenshots-opt。
8. 提取价值主张：不要只列功能，对每个功能回答“用户为什么在意”。例如不要写“联系人管理页”，要写“一屏看到每个客户的历史和待办事项”；不要写“搜索功能”，要写“秒级找到任何东西——语义搜索理解你的意思，而不只是你打的字”。
9. 生成站点结构：quick 模式为单个 HTML 文件（hero+功能网格+CTA）；standard 模式为多页站点（index.html、features.html、how-it-works.html、screenshots/ 目录、styles.css）；thorough 模式为综合站点（index.html、features/ 下每功能独立页、how-it-works.html、use-cases/ 场景页、compare.html 可选、screenshots/ 含 hero、每功能截图集和 workflows GIF、styles.css）。
10. 首页包含：带动画 GIF 或关键截图的 hero、3-4 个最佳功能亮点（不是全部）、三步 How It Works 摘要、CTA。
11. 功能页包含：每个功能配真实截图和以收益为中心的描述，6 个以上时按类别分组，每个功能有足够空间解释其作用。
12. How It Works 页包含：主工作流的分步可视化指南，每步配截图（或动画 GIF）、标题和 2-3 句话，回答“用它实际是什么样子”。
13. thorough 模式的每功能深度页包含：功能运行中的 hero 截图、“它做什么”1-2 段价值说明、“它如何工作”分步截图或 GIF、“为什么重要”解决的问题、边界情况或高级技巧、指向下一个功能的链接。
14. thorough 模式的用例页：故事驱动，如“周一早上你打开仪表盘看到……”，用截图走一遍真实工作流，展示结果——用户用了这个应用后有什么不同；这是最难解释的应用最有说服力的页面。
15. 对比页（可选）：诚实的“为什么选 [app] 而非替代品”，功能表、关键差异点、最适合谁。
16. 制作动画 GIF 演示：1) 导航到起始状态；2) 以约 2fps 开始录制截图；3) 执行工作流（点击、输入、导航）；4) 停止录制；5) 合成帧为 GIF。用 capture-screenshots 加顺序前缀捕获各步骤，再用 Python Pillow 合成：python3 -c "from PIL import Image; import glob; frames = [Image.open(f) for f in sorted(glob.glob('.jez/screenshots/workflow-*.png'))]; frames[0].save('showcase/screenshots/workflows/create-client.gif', save_all=True, append_images=frames[1:], duration=500, loop=0)"。
17. 要动画化的内容：主要的“创建某物”流程（2-4 秒）、搜索/筛选交互（展示结果出现）、拖拽或重排操作、暗色模式切换、任何“魔法时刻”（AI 分类、即时搜索、实时更新）。
18. GIF 规范：最长 10 秒/20 帧，越短越好；以 1280x720 捕获、以 640x360 显示（半尺寸减小文件）；最后一帧加短暂停顿（3 帧）让观众看到结果；持续循环，不要“点击播放”；若超过 5MB 则减少帧数或裁剪到相关区域。
19. 在 HTML 中用浏览器边框 mockup 展示截图：.browser-frame 加圆角、阴影、边框，.browser-frame-bar 加浅灰背景和三个圆点，无需编辑图片即可获得精致的“浏览器中的应用”外观。
20. 为 Agentic/AI 应用采用有效模式：before/after（用户以前手动做什么 vs 现在 agent 做什么）、timeline（跨小时/天展示 agent 工作）、result showcase（跳过过程直接展示输出，如“agent 挖掘 1200 封邮件 → 89 个客户、340 个联系人、2100 条知识事实”）、side-by-side（agent 工作与人工工作并排）、magic moment GIF（最令人印象深刻的一件事的动画）。
21. Agentic 应用文案技巧：以结果而非技术开头（“了解每个客户的历史”而非“AI 驱动的 CRM”）；展示量级（“处理了 1200 封邮件”比“处理你的邮件”更有说服力）；用时间对比（“过去 2 小时现在 30 秒”）；避免术语（“在你的数据中发现联系”而非“带 RAG 的语义向量搜索”）。
22. 多页站点导航：所有页面粘性导航、当前页高亮、移动端汉堡菜单、导航中始终可见 CTA 按钮。
23. 输出后告知用户：预览用 python3 -m http.server -d showcase 然后打开 http://localhost:8000；部署可拖拽 showcase/ 文件夹到 Cloudflare Pages、Netlify 或任意静态托管；列出需替换的占位内容；说明生成了哪些 GIF 及其文件大小。
24. 设计模式：若应用有明确品牌色则提取为主色，否则用中性色板（slate/blue）；用系统字体栈（无外部请求）；移动优先响应式，截图上移动端垂直堆叠；三态暗色模式切换（light/dark/system）用 CSS 自定义属性；懒加载截图、Tailwind CDN 样式、无构建步骤。
25. 让截图看起来高级：截图前确保应用有真实数据（不是“Test Client”和“asdf@example.com”）；所有截图统一视口宽度（1280x720）；截图内不含浏览器 chrome，用 CSS 浏览器边框 mockup 代替；截图展示某功能时让该功能处于激活状态（弹窗打开、筛选已应用、项目已选中）。
26. 视觉叙事：以仪表盘开场（hero 截图应显示有数据、鲜活有用的应用）；展示应用在工作（结果的截图优于空表单的截图）；渐进揭示（hero 展示大图、how-it-works 展示流程、features 展示细节）；以回报结尾（CTA 前最后一节展示结果——生成的报告、完成的任务、管理的客户）。
27. 混合使用截图与 mockup：hero 用浏览器边框 mockup 中的真实截图；How It Works 可用简化 mockup 插图（CSS 形状、图标、箭头）配真实截图细节；功能网格用真实截图；移动展示用 CSS 手机边框 mockup；仪表盘/概览用真实截图。
28. 用纯 CSS 动画：@keyframes fadeInUp 让区块滚动时淡入；@keyframes float 让 hero 截图轻微浮动；提取应用主色用于区块的微妙渐变背景。
29. 部署选项：1) Cloudflare Workers 静态资源（推荐，若应用已在 Cloudflare，在 showcase/ 目录创建 wrangler.jsonc 含 name、main、compatibility_date、assets.directory，然后 npx wrangler deploy，可绑自定义域名）；2) Cloudflare Pages 拖拽上传；3) 任意静态托管（Netlify、Vercel、GitHub Pages）。
30. 自定义域名：专业展示应始终用自定义域名，如 myapp.com 为展示站、app.myapp.com 为应用，或 www.myapp.com 为展示、app.myapp.com 为应用。
31. 添加联系/咨询表单：方案 1 用 Formspree/Formsubmit（无需后端，form action 指向 https://formspree.io/f/YOUR_FORM_ID，免费额度够展示用量，提交发到邮箱）；方案 2 用 Cloudflare Worker 端点（如 /api/enquiry 路由，通过 SMTP2Go、Resend 发送或存 D1）；方案 3 用 Turnstile + 邮件防垃圾（加 cf-turnstile div，服务端验证 token）。
32. 表单应捕获：姓名（必填，个性化跟进）、邮箱（必填，回复渠道）、公司/角色（可选但有用，筛选线索）、留言/“你在找什么”（可选但有用，回复上下文）、电话（可选）。提交后重定向到感谢页或显示内联确认，不要静默重置表单。
33. 考虑生成额外页面：定价页（有定价时）、关于页（有故事的产品）、更新日志（已发布产品，显示活跃开发）、文档链接（若有 app-docs）、博客/文章（若有内容）、隐私/条款（始终要有，即使占位）、状态页（SaaS）。
34. SEO 基础：每页有 title（[App Name] — [Tagline]）、meta description（一句话价值主张）、og:title、og:description、og:image（screenshots/hero.png）、canonical 链接；多页时每页有独立 title 和 description，不要所有页用同一 meta；若产品服务特定地点可用 seo-local-business 技能加 JSON-LD。
35. 质量规则：1) 只截图真实功能，不捏造应用没有的能力；2) 挑选最佳截图，不是每页都值得展示，选能讲产品故事的；3) 写以收益为中心的文案；4) 不造假用户评价，没有就省略该区块；5) 不编造统计数据，没有真实数据就留空统计块；6) 部署到真实 URL，不要只留本地文件，展示站需要可分享。

适用边界 · 注意事项

• 应用尚未运行或无法访问时（截图捕获依赖可访问的 URL）
• 没有真实数据或真实功能可展示时（质量规则要求不捏造能力和统计）
• 只需要一个简单落地页而非完整展示站时（quick 模式虽可，但更简单的 landing-page 方案可能更合适）