publish-research-site

发布研究网站

概述

使用此技能编排一个包含四个阶段的工作流：深入研究、生成位图素材、创建可用于生产环境的交互式网站，以及通过 Vercel CLI 部署。将最终成果视为面向公众、可分享的微型网站：内容严谨到足以引用，视觉效果出色到足以传播，而且加载速度足够快，能在移动设备上快速打开。

工作流

0. 部署前检查依赖

在开始研究或实施之前，检查所需技能和 CLI 是否可用。如果命令不在默认 PATH 中，优先使用用户本地 Codex 工具链路径：

export PATH="$HOME/.agent-reach-venv/bin:$HOME/.codex/toolchains/node-current/bin:$HOME/.codex/toolchains/gh-current/bin:$PATH"

for cmd in node npm npx vercel agent-reach mcporter yt-dlp gh; do
  command -v "$cmd" >/dev/null || {
    echo "Missing required dependency: $cmd"
    exit 1
  }
done

agent-reach doctor

还要确认技能文件存在（如果环境提供了本地技能文件夹）：

test -f "$HOME/.agents/skills/deep-research/SKILL.md" || echo "Missing skill: deep-research"
test -f "$HOME/.agents/skills/agent-reach/SKILL.md" || echo "Missing skill: agent-reach"
test -f "$HOME/.agents/skills/frontend-design/SKILL.md" || echo "Missing skill: frontend-design"
test -f "$HOME/.codex/skills/.system/imagegen/SKILL.md" || echo "Missing skill: imagegen"

如果缺少必需的依赖项，请在启动项目之前停下，并请用户安装缺失的前置条件，或授权安装。不要等网站建成后才发现缺少部署工具。

1. 确定命题范围

将用户的论点或主题重述为一份工作简报：

• 核心论点或问题
• 目标受众和期望的语气
• 网站应让受众相信、理解、比较或探索什么
• 任何指定的语言、地区、时间范围或部署偏好

如果意图明确，就自主推进。只有当命题、受众或部署目标过于模糊，无法安全执行时才提问。

2. 开展深入研究

如果现有的 $deep-research 技能可用，就调用该技能。默认使用标准模式；如果网站涉及重大决策、有争议的论点、投资论证、技术架构判断或面向公众的事实报告，则使用深度或超深度模式。

研究结果必须包括：

• 执行摘要式论点及置信度
• 附有引用 ID 的关键论点
• 矛盾、反驳意见和不确定性
• 来源列表，包括 URL、相关发布日期和可信度说明
• 网站应呈现的 5-10 条重要事实
• 证据所提示的 3-5 个视觉呈现机会

只有在证据基础足以支撑论点后，才能构建网站。对于当前议题，要用近期来源核实事实并明确标注日期。

3. 将研究转化为网站简报

编码前先创建一份简明的网站简报。如果项目包含多个部分、许多论点或多个生成素材，请使用 references/site-brief-template.md。

简报必须定义：

• 叙事脉络：引子、证据路径、张力／反面观点、综合分析、行动或结论
• 各部分及交互方式
• 论点与来源的对应关系
• 视觉素材列表和图像提示词
• 框架选择和项目目录
• 验证与部署检查清单

网站文案要简洁。将研究内容转化为便于浏览的公共传播内容，而不是把完整报告直接粘贴到界面中。

4. 生成图像

对于能实质性提升网站效果的光栅图像，请调用现有的 $imagegen 技能：例如主视觉、编辑插画、产品／场景图、说明图、海报、缩略图或社交分享视觉素材。

图像工作流：

• 只生成网站实际会用到的素材。
• 根据研究简报编写提示词，包括主体、构图、风格、纵横比、规避项，以及是否应避免出现文字。
• 除非用户明确需要文字艺术，否则避免在生成图像中放入事实论断或小字。
• 检查生成结果，必要时迭代一两次，并仅保留可用的最终版本。
• 将最终项目素材移动或复制到网站工作区，通常放在 public/assets/ 或相应框架的目录中。
• 在网站简报或最终报告中记录最终提示词和保存路径。

5. 构建交互式网站

如有 $frontend-design，请调用，然后实现实际体验，而不是营销占位页。

默认实现指南：

• 根据工作区和部署需求，优先使用 Vite/React、Next.js 或静态 HTML/CSS/JS 网站。
• 让首屏立即传达核心主张。
• 至少加入一种有意义的交互：叙事滚动、时间线、对比滑块、证据卡片、可筛选的主张图谱、场景切换、图表交互、注释图示、测验或计算器。
• 在主张附近展示支持该主张的引用。
• 提供来源抽屉、备注区或参考资料面板，方便读者核实。
• 确保响应式、快速、无障碍且视觉鲜明。
• 将生成的图像用作实际素材，而不是移除后也不会影响信息传达的装饰。

避免通用占位内容、没有引用的主张、虚构图表、图库风格的视觉素材，或无法帮助用户理解内容的交互。

6. 本地验证

部署前：

• 仅在需要时安装依赖，并保留现有的包管理器风格。
• 如有 lint、类型检查或测试，请运行。
• 运行生产构建。
• 如有需要，启动本地服务。
• 在桌面和移动设备的视口尺寸下使用浏览器验证。
• 确认生成的图像可从项目本地路径加载。
• 在可行时，确认外部链接和引用可访问。
• 修复可见的布局问题、文本重叠、空白画布、控制台错误和失效路由。

除非已实际运行构建和视觉检查，否则不要声称网站已准备就绪；如有无法验证的内容，请明确说明。

7. 使用 Vercel CLI 部署

使用 Vercel CLI 部署。

推荐顺序：

export PATH="$HOME/.codex/toolchains/node-current/bin:$PATH"
vercel --version
npm run build
vercel --yes

仅在用户要求部署到生产环境或任务明确需要生产部署时，才使用 vercel --prod --yes。如果现有的 Vercel 项目或域名可能被覆盖，请在生产部署前征求确认。

如果将 Codex 本地 Node 工具链添加到 PATH 后，本地仍无法使用 vercel 命令，请使用 npx vercel@latest。如果缺少 Vercel 身份验证，请让用户登录或确认替代部署途径；不要擅自改用非 CLI 部署服务。

从 CLI 输出中获取部署 URL，并在浏览器中测试。如果部署成功但远程验证失败，请同时报告 URL 和失败情况。

最终回复

仅报告有用的交付信息：

• 已部署的 URL
• 本地项目路径
• 研究范围和来源数量
• 生成的图像素材路径
• 已运行的验证命令
• 已知限制或未验证事项

最终回复应简洁，并包含用户可立即打开的链接或文件路径。