用户需要一个移动端友好的界面来筛选和查看“谁在招聘”的帖子，因为目前的格式在手机上无法使用。

Hacker News (HN) 是全球开发者和技术极客群体讨论前沿技术、创业和职业机会的核心阵地。其中，“Who is hiring”板块是开发者寻找工作机会的重要信息源。然而，原始证据和用户反馈清晰地指出，这个信息源在移动端的使用体验是灾难性的。

当前 HN 的设计哲学更偏向于“信息流的原始展示”，这在桌面端尚可接受，但在移动设备上，用户必须面对大量非结构化的文本、冗长的讨论串和难以筛选的帖子。对于一个需要快速、高效筛选大量招聘信息的求职者而言，这种体验是极大的摩擦点。

更严重的问题在于，原始的筛选机制在实际使用中存在缺陷。用户无法进行多维度的、组合式的过滤（例如：必须是远程工作 AND 薪资范围在 X 到 Y 之间）。这迫使用户不得不依赖手动阅读和复制粘贴，极大地浪费了时间和精力，严重阻碍了其作为“高效工具”的价值。

用户画像： 核心用户是活跃的、具有技术背景的开发者（软件工程师、数据科学家等）。他们通常年龄在 22-35 岁之间，对技术趋势敏感，并且习惯于在 HN、Reddit 等专业社区获取信息。他们是“信息饥渴型”用户，追求效率和前沿知识。

典型场景： 用户在通勤时间或碎片化时间，习惯性地打开 HN 浏览技术讨论。当他们发现招聘信息时，他们不希望被原始的、难以阅读的文本流打断，而是希望能够立即通过一套结构化的界面，根据自己的职业偏好（如：远程、薪资、技术栈）进行快速筛选，并接收到定制化的提醒。

群体规模感与付费能力： 目标用户群体是全球性的、高价值的。虽然 HN 的用户量难以精确衡量，但其用户粘性和专业性极高。由于求职本身就是一项高价值、高焦虑度的任务，当工具能显著节省时间并提高成功率时，付费意愿会非常强。他们更愿意为“效率”和“信息差”付费。

MVP 范围与核心功能： MVP 的核心是解决“结构化展示”和“多维度过滤”两大痛点。

1. 数据抓取层 (Scraping/API)： 定期抓取或通过 HN 的公开 API 抓取“Who is hiring”板块的原始数据。
2. 数据清洗与结构化 (Parsing)： 这是最关键的一步。需要编写逻辑来从非结构化的文本中提取关键信息，如：公司名称、职位、薪资范围（需要正则匹配）、工作地点（远程/本地）、技术栈等。
3. 前端展示层 (UI/UX)： 构建一个移动优先（Mobile-First）的 Web App。界面必须干净、卡片化，每个职位信息都是一个独立的、可阅读的卡片。
4. 核心功能： 实现多重过滤（Filter by Remote, Filter by Salary Range, Filter by Job Type）和保存的 Job Alert（邮件/Webhook）。

技术实现思路：

• 架构： 采用 Serverless/Headless CMS 架构。前端负责展示，后端负责数据抓取、清洗和存储。
• 关键模块：
  • Scraper/Worker: 使用 Python (Scrapy/BeautifulSoup) 或 Node.js (Puppeteer) 定时抓取 HN 页面。
  • Data Processor: 核心逻辑，使用 NLP/正则匹配技术从文本中提取结构化字段。
  • Database: 存储结构化的职位数据（如 PostgreSQL 或 MongoDB）。
  • Frontend: 负责展示和交互。
• 推荐技术栈：
  • Frontend: Next.js 或 SvelteKit (提供优秀的性能和移动端体验)。
  • Backend/API: Node.js (Express/NestJS) 或 Python (FastAPI) (便于与爬虫逻辑结合)。
  • Deployment: Vercel/Netlify (前端) + AWS Lambda/Google Cloud Functions (后端/定时任务)。
• 一个人多久能做出第一版： 考虑到数据清洗和爬虫的稳定性调试，预计需要 3-4 周。前两周完成爬虫和数据结构化，后两周完成移动端 UI/UX 和订阅系统。

用户现在怎么凑合： 用户目前只能通过阅读原始的、未经优化的 HN 帖子。他们会手动浏览，然后将感兴趣的职位信息复制到 Notion、Google Sheet 或本地文档中进行整理和筛选。

有哪些竞品：

1. 大型招聘网站 (LinkedIn, Indeed)： 覆盖面广，但缺乏开发者社区的“内幕感”和即时性。
2. RSS/聚合器： 只能聚合帖子标题，无法提供结构化的内容和高级过滤。
3. 其他 HN 爬虫/工具： 通常只是简单的信息展示，缺乏用户体验优化和复杂的过滤逻辑。

它们差在哪，你的切入点： 现有方案最大的缺陷是缺乏针对 HN 社区特性的深度理解和优化。

• 差距点 1 (UX)： 缺乏移动优先的、卡片化的、极简的阅读体验。
• 差距点 2 (功能)： 无法实现多维度的、组合式的、基于文本内容的智能过滤。
• 你的切入点： 你不是一个通用的招聘网站，你是一个**“HN 招聘信息的结构化、移动端增强阅读器”**。你的价值在于将一个“信息源”转化为一个“高效的工具”。

变现模式： 采用 Freemium (免费增值) 订阅模式。

• 免费层级 (Free)： 基础的职位列表展示，支持单维度过滤（如：只看远程工作）。
• 付费层级 (Premium)： 核心价值所在。包括：
  • 高级过滤： 多重组合过滤（如：远程 + 薪资范围 + 特定技术栈）。
  • 智能提醒 (Alerts)： 设定关键词和过滤条件，系统自动通过邮件/Webhook 发送新匹配的职位通知。
  • 数据导出： 允许用户将筛选结果导出为 CSV/JSON 格式。

定价建议： $5/月订阅。这个价格定位在“高价值的效率工具”范畴，对于一个专业开发者群体来说，每月节省 2-3 小时的时间，远超这个成本。

为什么用户愿意付费： 用户愿意为**“时间成本的节省”和“信息获取的确定性”**付费。

1. 时间价值： 开发者的时间非常宝贵。如果你的工具能将原本需要手动筛选 30 个帖子才能找到的 3 个优质机会，缩短到 30 秒内完成，那么 $5/月是极具吸引力的。
2. 信息差价值： 提前知道某个热门技术栈的招聘需求，或知道某个公司正在招聘，本身就是一种信息优势。

趋势与技术：

1. 远程工作（Remote Work）的常态化： 远程工作模式的普及，使得“远程”成为最重要的筛选条件之一，这使得过滤功能的需求空前高涨。
2. 移动互联网的绝对主导地位： 现代信息消费几乎全部发生在移动端。任何在移动端体验差的工具，都注定会被淘汰。
3. 开发者工具链的成熟： 现代前端框架（如 Next.js）和 Serverless 计算的成熟，使得开发者可以以极低的成本和极快的速度，构建出高性能、高可用性的 Web 应用，降低了技术门槛。

主要难点：

1. 数据抓取稳定性 (Anti-Scraping)： HN 作为一个老牌社区，可能会加强反爬机制。需要持续投入资源来维护和优化爬虫的健壮性。
2. 数据清洗的准确性： 从非结构化的文本中准确提取薪资范围、技术栈等信息，需要复杂的正则匹配和 NLP 模型，这是技术上的最大挑战。
3. 用户留存： 仅仅提供一个工具是不够的。需要通过提供高质量的“Job Alert”和社区反馈，将用户从“工具使用者”转化为“社区依赖者”。

可能的护城河或壁垒：

1. 数据清洗的深度和准确性： 如果能建立一套比通用爬虫更智能、更准确的“开发者术语-结构化字段”映射模型，这将形成强大的技术壁垒。
2. 社区粘性与品牌定位： 将产品定位为“HN 社区的官方增强阅读器”，建立起与 HN 社区的深度绑定关系，形成品牌壁垒。
3. 用户体验的极致优化： 持续迭代，使其成为市场上最流畅、最直观的求职工具。

第一批用户从哪来： 第一批用户必须是 HN 社区的活跃成员。

1. Hacker News 本身： 将产品作为“HN 招聘信息增强阅读器”在 HN 社区内进行推广。
2. Reddit 社区： 重点投放于 r/developers, r/jobs, r/cscareer 等高密度、高意图的开发者子版块。
3. Twitter/X： 在开发者和招聘相关的 KOL 账号群组进行分享。

用什么渠道和动作起量：

1. Build in Public (公开构建)： 在 Twitter/X 和个人博客上，记录开发过程中的挑战（如：爬虫被封、数据清洗的困难），吸引关注。
2. 提供极简的免费价值： 初期不收钱，只提供“基础的、优于 HN 原生体验”的免费功能。例如，免费提供基础的移动端浏览和单维度过滤。
3. 建立反馈循环： 在所有推广渠道设置一个明显的“反馈入口”，鼓励用户提交他们认为缺失的过滤条件或数据字段，让用户参与到产品的迭代中，增强归属感。