关于 hacker-news-strategy
hacker-news-strategy 是一项面向开发者和产品团队的 Hacker News 参与策略技能，介绍平台文化、投稿方式、标题与评论做法。它也涵盖社区规范、避免内容被标记的行为，以及长期建立真实参与度的方法。
主要功能
- 01分析 Hacker News 社区文化
- 02区分 Show HN 与其他投稿类型
- 03撰写具体、中性的标题
- 04规划发帖时机与评论回应
- 05识别违规行为及内容风险
- 06制定长期参与和积累声誉策略
适用场景
- 01为产品准备 Show HN 发布
- 02撰写技术内容投稿标题
- 03回应发布帖中的技术批评
- 04研究话题并建立社区参与习惯
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/hacker-news-strategy确认已加载。
附带文件README.md
详细介绍
Hacker News 策略
Hacker News 是最具影响力的开发者社区，也是最容易搞砸的社区。本指南介绍真正有效的方法、哪些做法会让你被标记，以及如何建立真实的影响力。
开始之前
- 如果
.agents/developer-audience-context.md存在，请先阅读 - 确认产品／内容确实能引起 HN 受众（黑客、创始人、深度技术爱好者）的兴趣
- 坦诚面对：HN 用户一眼就能看穿营销
了解 HN 的文化
Hacker News 上都有哪些人
| 群体 | 关心的内容 |
|---|---|
| 创始人 | 融资、增长策略、创业经历 |
| 资深工程师 | 深度技术内容、架构、系统 |
| 技术负责人 | 工程管理、团队扩张、流程 |
| 独立黑客 | 个人项目、自力更生、收入 |
| 研究人员 | AI/ML、分布式系统、PLT、安全 |
HN 看重什么
- 技术深度，而非精致的营销包装
- 真正的新意，而非渐进式更新
- 透明坦诚，而非企业套话
- 公开构建，而非秘密发布
- 逆向洞见，而非常规观点
HN 反感什么
- 伪装成内容的自我推广
- 标题党
- 企业公关腔
- 刻意诱导互动（“你们怎么看？”）
- 任何让人觉得像广告的内容
帖子类型及适用场景
Show HN
适用场景：你做出了某个东西，希望获得社区反馈。
| 要求 | 详情 |
|---|---|
| 必须是人们可以试用的东西 | 在线演示、可下载内容或详细操作指南 |
| 必须是新内容 | 不能是转发或小幅更新 |
| 创作者必须在线 | 在评论中回答问题，持续 2-3 小时 |
| 标题格式 | “Show HN: [Name] – [One-line description]” |
好的 Show HN 示例：
- “Show HN: 我开发了一个用于向量搜索的 SQLite 扩展”
- “Show HN: 用 Rust 编写的开源 Heroku 替代方案”
- “Show HN: 浏览器中的实时协作代码编辑器”
不好的 Show HN 示例：
- “Show HN: 我的创业公司刚刚融资 500 万美元”（没有可供试用的东西）
- “Show HN: 我们更新了定价页面”（没什么吸引力）
- “Show HN: 快来看看我们的新功能”（太含糊）
Launch HN
适用场景：公司重大上线或重要融资公告。
| 指南 | 详情 |
|---|---|
| 包含技术细节 | 介绍底层实现和架构决策 |
| 分享历程 | 讲述一路走来的经历和经验教训 |
| 保持在线 | 创始人应亲自回答问题 |
| 避免公关腔 | 像真人一样写，而不是写新闻稿 |
常规投稿
适用场景：分享有趣的内容（自己的或他人的）。
| 有效的内容 | 无效的内容 |
|---|---|
| 有深度的技术博客文章 | 清单类文章和“10 个技巧”类文章 |
| 能带来经验教训的实战故事 | 公司公告 |
| 对问题的深入剖析 | 产品更新 |
| 原创研究或数据 | 重新包装的内容 |
| 逆向的技术观点 | 显而易见或广为认同的观点 |
优化标题
标题原则
| 应该做 | 不应该做 |
|---|---|
| 具体明确 | 使用含糊的流行词 |
| 陈述内容是什么，而非它有多棒 | 使用最高级（“惊艳”“最佳”） |
| 恰当地使用技术术语 | 为了吸引更广泛的受众而简化内容 |
| 保持客观 | 使用标题党套路 |
标题改写示例
| 改写前（不好） | 改写后（好） |
|---|---|
| “在 Node.js 中处理错误的最佳方式” | “Node.js 生产系统中的错误处理模式” |
| “我们让部署速度提升了 10 倍” | “我们如何将部署时间从 20 分钟缩短到 2 分钟” |
| “宣布推出我们令人惊艳的新功能” | “Show HN: [Feature] – [What it does]” |
| “你绝对想不到我们发现了什么” | “[Specific context] 中的 [Specific finding]” |
| “为什么每个人都应该使用 TypeScript” | “TypeScript 的类型系统帮我们发现了 15% 的生产环境缺陷” |
HN 版主会编辑标题
请注意：HN 版主（尤其是 dang）会把耸人听闻的标题改得更加中立。他们也会合并重复投稿，有时还会给值得一看的帖子第二次机会。
时间安排与机制
最佳发布时间
| 时间（PT） | 原因 |
|---|---|
| 6-9 AM | 赶上美国东海岸的早晨和欧洲的下午 |
| 10 AM - 12 PM | 美国活动高峰期 |
| 避开：周末 | 流量较低，但竞争也较少 |
算法
- 前 1-2 小时的初始点赞最重要
- 评论会提升排名（互动信号）
- 点赞过快可能触发“激烈争论检测器”惩罚
- 新账号发布的帖子会受到额外审查
- 有争议的帖子会受到排名惩罚
帖子被扼杀的原因
| 原因 | 为什么 |
|---|---|
| 刷票团体 | 多个账号／朋友点赞会被检测并处罚 |
| 缺少早期互动 | 帖子没有初始势头就会沉寂 |
| 被用户举报 | 多次举报会导致帖子隐藏 |
| 重复内容 | 已经发布过的内容会被合并或扼杀 |
| 自我推广模式 | 多次发布同一家公司的内容 |
评论策略
如果这是你的帖子
| 时间 | 操作 |
|---|---|
| 立即 | 发布一条顶层评论，补充背景、来龙去脉或技术细节 |
| 前 2 小时 | 回复每一条评论，尤其是批评性评论 |
| 全天 | 持续查看并回复后续问题 |
你的首条评论模板：
Hey HN, [your name] here, [role] at [company/project].
Quick backstory: [1-2 sentences on why you built this]
Technical context: [What's interesting under the hood]
Happy to answer any questions about [specific technical areas].
如何回应批评
| 批评类型 | 回复策略 |
|---|---|
| 合理的技术疑虑 | 承认问题，解释理由，并征求建议 |
| 误解 | 澄清事实，不要表现得咄咄逼人 |
| 挑衅 | 不要回应，或只简短地给出事实性回复 |
| 功能请求 | 回复“好主意，我会研究一下”，或说明限制 |
| 竞品对比 | 保持友善，重点说明你的做法 |
切勿：
- 变得防御或讽刺
- 与批评者争论
- 否定合理的疑虑
- 在回复中使用企业腔
评论他人的帖子
通过真诚参与积累 karma：
| 应做 | 不应做 |
|---|---|
| 分享相关的技术经验 | 在他人的讨论帖中推广自己的内容 |
| 提出经过思考的问题 | 留下泛泛的赞美 |
| 补充专业领域的背景信息 | 为了吸引关注而故意唱反调 |
| 礼貌地纠正错误信息 | 挑起争论 |
哪些行为会导致举报／帖子被扼杀
自动触发的红旗行为
| 行为 | 后果 |
|---|---|
| 在任何地方请求点赞 | 帖子被扼杀，可能会被封禁 |
| 从同一 IP／网络投票 | 投票作废，账号受罚 |
| 多个账号点赞 | 账号被封禁 |
| 以负面方式投稿竞品 | 被标记为滥用行为 |
| 在评论中刷好评 | 账号被封禁 |
容易被举报的内容
| 内容类型 | 被举报的原因 |
|---|---|
| 明显的营销内容 | 社区会严厉打击此类内容 |
| 政治性观点 | 不符合 HN 主题 |
| Crypto／Web3（经常如此） | 社区对此已感到厌倦 |
| 付费墙内容 | 令读者不满 |
| 低质量内容 | 未达到质量标准 |
从失败的帖子中恢复
- 至少等待 24 小时再重新发布
- 更改标题，让它更具体／更有吸引力
- 补充更多背景信息，如果原帖不够清楚
- 给版主发邮件（[email protected]），如果你认为帖子被不公平地扼杀
- 考虑一下：也许 HN 并不是适合这篇内容的受众
真诚地积累 Karma
长期策略
| 时间范围 | 策略 |
|---|---|
| 第 1-4 周 | 只评论，不投稿。通过真诚互动积累 karma。 |
| 第 2-3 个月 | 投稿有趣的内容（不是自己的）。展现你是社区的贡献者。 |
| 第 3 个月起 | 偶尔投稿自己的作品，同时参与其他贡献。 |
提升声望的评论
高声望评论的常见模式：
- 补充背景：“我曾在 [company] 参与过类似系统的开发，我们发现……”
- 分享数据：“我们测试这种方法时，基准测试显示 X”
- 提供替代方案：“另一种选择是 Y，适用于……的情况”
- 补充历史背景：“这类似于 Z 在 90 年代解决这个问题的方式”
声望能带来什么
| 声望等级 | 权益 |
|---|---|
| 30+ | 可以对评论点踩 |
| 500+ | 帖子初始时会获得更多信任 |
| 1000+ | 强烈表明你是真正的社区成员 |
平台注意事项
应该做的事
- 要像普通人一样发言，而不是像公司发言
- 要慷慨地分享技术细节
- 要承认局限性和权衡
- 要从容地回应批评
- 要把你的 Show HN 链接分享给团队（让大家知情，而不是协调点赞）
- 要积极参与讨论，即使不是在推广产品
- 要每天阅读 HN，了解社区文化
不该做的事
- 不要请求任何人点赞（会被封禁）
- 不要反复发布相同内容
- 不要使用标题党标题
- 不要在评论中摆出防御姿态
- 不要忽视批评
- 不要用虚假账号刷好评
- 不要把 HN 当作免费的营销渠道
工具
| 工具 | 用途 |
|---|---|
| Octolens | 监控 HN 上对你的产品、竞争对手和相关关键词的提及。讨论出现时接收提醒，以便真诚地参与其中。 |
| HN Search (hn.algolia.com) | 搜索与你的主题相关的历史帖子，了解哪些做法有效 |
| HN Front Page Check | 监控你的帖子是否登上首页以及排名 |
| HN user pages | 在回复前了解评论者的情况 |
Show HN 发布检查清单
发布前：
- 已提供在线演示或可下载版本
- 落地页清楚说明产品的功能
- 价格（如有）透明公开
- 发布后 2-3 小时内创作者会在线
- 已拟好包含背景故事／技术细节的首条评论
- 标题遵循“Show HN: [Name] – [Description]”格式
- 过去 24 小时内未在 HN 发布过内容
- 账号通过真实参与积累了一些声望
相关技能
developer-audience-context— 了解你正在接触的受众reddit-engagement— 社区动态类似，但规范不同dev-to-hashnode— 适用于从 HN 链接过去的长篇内容github-presence— 了解 HN 用户评估项目时会查看什么
评论
支持 Markdown