按当前字段准备提交物料

Product Hunt 的字段会更新。以下规格来自 2026 年 8 月查阅的官方提交指南，制作前仍应以实际表单为准。^[1]

主链接

提交直接可访问的产品页面，通常是官网、应用商店或代码仓库。官方表单不接受短链接和带追踪参数的主链接。团队可以依靠 Product Hunt referrer、专用落地页路径、站内事件和注册来源问题完成归因，不要通过规避字段规则强塞追踪链接。

产品名称

只填写真实产品名，不把描述、夸张形容或促销文案塞进名称。Emoji 只有在确实属于品牌名时才适合出现。

Tagline

当前上限为 60 个字符。它需要快速说明产品做什么，避免「终极」「革命性」一类无法验证的宣传。首页用户先看到的是有限信息，清楚通常比新奇更重要。

可以使用一个基础结构：

帮助哪类用户 + 完成什么任务或得到什么结果

Tagline 不必列出全部功能，也不要使用只有内部团队才理解的分类词。

Description

当前上限为 500 个字符。用简短段落补充用户、问题、主要能力和使用方式。先写价值和场景，再写少量关键功能。

Launch Tags

当前可以选择最多 3 个相关标签。标签应与真实用途一致，方便平台把产品放入合适的发现页面。多选无关热门标签会降低表达准确度。

Thumbnail

当前要求方形图片，官方建议 240×240，文件小于 3MB。GIF 并非成功条件，也不会自动播放，只在悬停时动起来。第一帧需要独立成立，避免闪烁、快速切换和不可读文字。

Gallery

当前至少需要 2 张 Gallery 图片，官方建议 1270×760。图片顺序适合围绕用户任务组织：问题或结果、核心操作、关键差异、完成状态。裸界面截图可以使用，最好加上简短解释，让陌生人知道应该看哪里。

Video 与交互演示

视频目前为可选项，官方提交只支持 YouTube 完整链接。没有必要制作昂贵宣传片，一段能展示真实输入、操作和结果的短 Demo 往往更实用。垂直或较难理解的产品，可以增加交互演示，降低试用前的理解成本。

Makers、定价、优惠与 Shoutouts

提前准备共同 Maker 的 Product Hunt 用户名；准确选择免费、付费或带免费方案／试用的定价状态。优惠应写清内容、代码和截止日期，不把优惠作为换取 upvote 的奖励。Shoutouts 用于说明帮助构建产品的关键工具，按当前表单限制选择最相关项。

First Comment

Maker 的第一条评论负责补充页面没有讲完的背景。适合包括：为什么做这个产品、服务什么用户、这次发布了什么、仍有哪些边界，以及希望社区测试或反馈什么。

评论应由 Maker 真实撰写。它不是一篇夸张的创始人宣言，也不需要堆满功能清单。具体问题更容易带来有用讨论，例如：「如果你经常把访谈录音整理成研究笔记，希望了解哪一步最影响继续使用。」

Landing Page 要承担转化和归因

Product Hunt 页面负责发现，产品自己的 Landing Page 负责解释和转化。页面最好围绕一个主要 CTA，减少与本次发布无关的导航、活动和多重请求。^[2][1]

页面至少要连接以下内容：

• 与 Product Hunt Tagline 一致的价值表达；
• 一眼可见的使用、下载、试用或购买入口；
• 真实截图、Demo 和结果；
• 价格、适用条件和限制；
• 常见疑问和支持方式；
• Analytics 和核心事件；
• 隐私合规的错误与行为监测；
• 新用户完成任务后的下一步。

归因不能只依赖 Product Hunt 显示的 points 或评论。站内需要记录到达、注册、激活、付款和后续使用，并写清时区和观察期。如果专门准备了 Product Hunt 优惠或页面，也要将优惠用户与自然用户分开，避免把折扣后的短期注册当成长期留存。

日期和时间服从目标与承接能力

官方 Launch Guide 当前建议，在没有其他约束时可以从太平洋时间 00:01 开始，以覆盖平台按太平洋时间运行的完整 24 小时周期。该建议不等于固定最佳答案。^[1]

团队还要考虑：

• 目标用户在哪个时区；
• Maker 何时能够在线回复；
• 客服和工程何时能够处理事故；
• 是否要配合媒体、活动或产品更新；
• 同一天有哪些产品和不可控新闻；
• 发布后是否有足够精力继续跟进。

Product Hunt 当前允许在未来 30 天内安排发布，排期后仍可继续编辑草稿，正式时间前页面不会被索引，也不能获得 upvote。^[1]

周几竞争更小、哪类产品某天更容易成功，都只能作为历史观察。不能预知同日产品、编辑选择和外部事件。准备充分、团队能够承接的日期，通常比推测「票少的日子」更可靠。

合规动员只邀请真实体验

发布链接可以分享给现有用户、朋友和长期参与的社区，邀请他们查看产品、体验并提供真实反馈。当前官方规则禁止直接要求 upvote，也禁止群发消息、奖励换票、协同投票、机器人和其他人为增加互动的方式。^[3]

因此，发布通知可以这样写：

产品今天在 Product Hunt 发布。如果这个问题与你有关，欢迎实际体验并告诉团队哪里清楚、哪里卡住。这里是发布页面和产品入口。

通知中不规定对方必须投票、必须评论什么，也不承诺将来交换支持。优惠可以面向所有 Product Hunt 用户公开提供，但不能以 upvote、评论或分享作为领取条件。

还应明确排除：

• 买票或购买所谓高权重账号；
• upvote 互换和投票群；
• 红包、折扣、免费额度换支持；
• 为朋友预写评论；
• 大规模邮件或私信陌生人；
• 用 AI 批量生成评论；
• 只说「Congrats」一类没有体验的批量留言；
• 在无关社区机械复制发布文案。

Product Hunt 当前使用 points 表示排名信号，points 综合 upvote 与有意义的互动，原始 upvote 数量不是唯一因素。平台也会结合自动检测、人工审核和社区举报处理异常互动。试图维持某个「票数与评论比例」没有可靠依据，真实试用和具体讨论才是可保留的信号。^[3]

发布当天围绕访问、反馈和异常工作

发布日可以提前分成几个工作区，即使只有一名 Maker，也要避免一直刷新排名。

检查产品和数据

• 产品页、官网、注册、支付、下载和支持入口正常；
• Product Hunt 上的名称、Tagline、图片、价格和 Maker 正确；
• Analytics 正在收到访问和核心事件；
• 记录发布前基线、正式时间和版本；
• 保留回滚、状态说明和故障联系路径。

发布已有渠道

• 在计划的社交账号、邮件和社区分享；
• 只进入已有关系或明确允许自荐的场景；
• 记录每次发布的实际链接和时间；
• 使用适合各渠道的说明，不复制同一段长文；
• 把用户引向体验和讨论，不指挥投票。

回复评论

• 回答具体问题，说明适用条件；
• 对正面反馈追问使用场景；
• 对负面反馈先确认事实，再解释或邀请继续沟通；
• 对无法复现的问题索取设备、步骤和结果；
• 对竞品比较保持具体、克制，不攻击个人；
• 不制造虚假热闹，也不要求团队批量留言。

官方评论指南鼓励先体验再给出具体、建设性的反馈，并明确反对 AI 生成和批量评论。Maker 同样应把评论区当作产品讨论，而不是榜单任务。^[3]

处理异常

• 阻断注册、付款和核心任务的问题优先；
• 明确影响范围、版本和开始时间；
• 必要时先回滚，再解释；
• 保存高频问题和失败步骤；
• 避免高峰期连续修改非关键文案；
• 修复后主动回复受影响用户。

记录结果

• Product Hunt 位置、points、评论和 reviews；
• 来自平台的有效访问；
• 注册、激活、付款与失败；
• 评论主题、功能问题和用户任务；
• 外部社交、媒体和品牌搜索；
• 每小时变化及重要运营动作。

排名变化可以作为时间线的一部分，不能替代真实业务数据。