推荐列表越刷越长，却找不到真正想看的内容。多数人会再刷新一次，Karpathy 则把这份烦恼做成了一个小工具。
他在本周的X 帖文中自述，让 Claude 从 Hacker News 长期评论数据里筛选反复被推荐的视频，约两小时完成 HackerTube。他也交代了人工处理的事项，包括获取视频元数据所需的配置、服务器和域名。网站在本次读取时可访问。
这不是人人都能两小时复刻同样结果的保证。它给求职者更有用的启发，是项目题目可以来自一个自己确实理解、又能说明取舍的小问题。
你不一定需要再做一个通用助手
许多学生项目从工具开始：想用一个新模型，再寻找能套进去的场景。结果往往是功能很广，却很难解释谁会反复使用。
个人烦恼提供了另一个起点。你知道什么时候会遇到问题，也知道现在怎样凑合解决。这些信息可以帮助你判断哪些功能值得先做，哪些只是看起来先进。
例如，资料经常找不到，可能需要的是一个更清楚的筛选入口，而非覆盖所有文件的万能聊天框。一个常用信息源噪声太多，可能适合先做特定主题的整理，而非复制完整推荐平台。
这些是选题思路，不是未经调查就确认的市场需求。自己遇到问题，可以支持先做个人工具；要推广给更多人，还需要了解他们是否也有相同困难。
数据来源决定了工具能看见什么
HackerTube 使用 Hacker News 评论中的推荐线索。这个来源具有自己的群体偏好，不能直接代表所有视频观众。数据里反复被提及的内容，也不必然适合每个用户。
对于学生项目，交代这种范围并不会削弱成果。它能帮助使用者理解为什么推荐偏向某些主题，也能提醒作者不要把一个局部视角包装成普遍质量排名。
还要区分推荐次数与推荐理由。同一个链接可能在不同讨论中出现，但有的提及是赞许，有的可能是批评或举反例。若只数链接，不理解语境，排序就可能偏离原来的目标。
可从少量记录中抽查这种区别，保留一两条误判及修正方式。没有完成大规模独立核验，就不要宣布已经获得最优推荐结果。
做减法 也是一种产品决定
Karpathy 的帖文强调无需登录、使用视频中间帧作为缩略图等选择。这些设计回应了他对原有体验的不满，而不是把平台能做的功能全部再做一遍。
学生也可以为自己的工具写一份“不做什么”。不做社交、不保存长期账号、不处理某类资料，都可能帮助项目在有限条件下完成。需要说明取舍带来的代价，而不是把缺失功能都解释成优势。
以一个资料筛选工具为例，不提供个性化可能减少配置负担，却也意味着结果难以适合每个人。选择是否合理，要回到目标用户与任务。
作品集若能把一项删除功能的决定讲清楚，会比列出十几个工具名更容易形成讨论。面试官可以看到你怎样控制范围，也能判断你是否理解使用体验。
快速生成以后 仍然需要确认基础行为
个人工具一旦分享出去，就会遇到不同设备、数据缺失和访问异常。最初为自己做的假设，可能不再成立。
可以先检查几项核心行为：链接是否指向正确内容，缺失记录怎样展示，筛选是否真的改变结果，刷新以后状态是否符合说明。这些检查直接关系到工具是否解决原来的烦恼。
不要因为作者是知名技术人物，就照搬每一个部署步骤。自己的预算、权限与维护能力不同，适合的方案也可能不同。选用托管服务或更简单的实现，都需要结合项目条件。
若只做了本地版本，就如实说明；如果分享了在线入口，再补充实际访问检查。把状态写准确，比借用他人的“两小时”叙事更能展示本人工作。
从一个烦恼里选出最小的问题
可以连续几天记录自己在哪一步反复找资料、切换页面或重新整理信息。先描述行为，不急着决定使用哪种模型。这样更容易区分偶尔不方便，与真正重复发生的问题。
从记录中选一个范围小、输入可获得、结果容易判断的任务。比如只整理一个允许使用的信息源，只做一个主题的入口。若需要登录、付费或使用受限资料，先确认条件，不必把第一版做成全能平台。
为它准备几条会让系统难堪的记录：重复链接、已经失效的内容、标题与实际材料不一致的情况。观察工具会怎样展示，必要时允许留下未知，而不是生成一个看似完整的说明。
再写一句能够被否定的目标，例如希望减少一次特定查找中的重复步骤。用真实过程检查目标，而不是补一个未经记录的效率比例。没有改善，也可以据此重新定义问题。
最后让一位同学试用，比较他的困难与你是否相同。如果不同，先保留差异，不急着把个人工具改成所有人的产品。独立完成一个有边界的小工具，已经可以形成完整作品。
从个人工具 走到一份可以讨论的作品
求职展示可以从一次真实使用开始：你原来要花哪些步骤，工具现在替你省掉了什么，仍有哪些麻烦。若没有记录使用前后的时间，就不要临时编一个效率百分比。
接着展示一次来自使用的修改。某项排序不符合预期，一个筛选让结果过窄，或一处信息缺失让页面失去作用，都可以成为解释产品判断的材料。
若邀请同学试用，应当记录他们实际提出的问题，而非把礼貌评价当成需求验证。几位同学的反馈可以帮助发现问题，不能代表已经验证了整个市场。
HackerTube 的故事值得关注，不只是因为速度，而是因为问题、数据与取舍之间有清楚联系。对学生来说，下一份项目未必需要更宏大的题目，也许只需要把一个常常让自己皱眉的地方，认真解决到别人也看得懂。
读者常问
应该照着 Karpathy 的技术栈做吗
不必。案例能提供选题与取舍的启发，自己的资源和限制仍要单独考虑。使用更简单的实现也可以有价值。面试官需要理解你为什么选择当前方案，而不是看你复述知名作者采用的工具。
个人工具没有商业用户 会不会不够有分量
可以展示真实问题、使用过程和修改，但不能借此宣称市场需求已经验证。项目价值与商业规模不是同一件事。若以后邀请更多人使用，再根据实际反馈决定是否扩展，并准确记录进展。
数据量很小 还能做推荐或筛选项目吗
可以先限定信息源和目标，研究清楚数据里什么信号值得使用。小数据项目需要如实说明范围，也可以帮助发现语境、重复和失效记录问题。不要为了数字好看，加入自己没有理解的数据。
怎样把工具参与说清楚
说明 AI 完成了哪些生成或执行工作，以及你如何确认需求、处理配置、检查结果和调整方案。没有必要隐瞒工具，也不应把所有自动步骤都算成个人独立实现。真实分工更方便展开追问。
结合目标岗位，梳理已有经历、本人贡献和可核查的项目成果，讨论下一步准备重点。