最新

我们试用了 Claude Code 来修复一个在 10,000 行 Python 代码库中存在的 bug，之前 Codex 和 Gemini 都未能解决。Claude 一次就修复了它，这让我们非常高兴。 然后我们要求进行一个小改进，结果在第二个提示词进行到一半时就达到了 Pro 版本的用量限制。 有其他人遇到过这么快就触发限制的情况吗？ 有什么避免这种情况的技巧吗？或者这属于正常现象？

大家好， 我一直在关注这个版块的帖子，感谢大家分享的所有信息。 我是一名中级软件工程师（~4 年工作经验），进入这个行业是因为我喜欢解决问题，并尽我所能产生影响。之前我陷入了糟糕的办公室政治斗争，不久前才脱身，感觉这让我落后了不少。随着人工智能的进步，以及各种论坛上不断出现关于软件工程师职位即将消失的悲观言论，我想寻求一些建议，同时也想分享一下我的情况，希望能看到前进的道路。 我的经历让我对这个职位有些失望，而且我也感到困境重重，因为我的一些个人因素不允许我离开目前所在的公司。在进入这个行业之前，我通过课程接触过一些机器学习，并且正在尝试将这些工具融入到我的日常工作中，以保持与时俱进。但现在，我觉得如果需要做出改变，机会正在迅速减少。我正在考虑以下几点： 1）切换到新的问题领域：尽管我摆脱了困境，但在从事了一段时间后，新的问题领域现在感觉有点无趣。我想知道我是否应该做出改变，以及合适的过渡期是多久。 2）我是否应该全力投入人工智能，并进行职业转型？这可能意味着在目前我所受的限制下，需要改变地点。 3）保持现状，我可能无能为力。 我知道我可能比其他人好一些，但这件事似乎一直在困扰着我，让我无法发挥应有的影响力。感谢所有回复！

Hi HN， 我做了一个小型的网络实验，名叫“一瓶”。 规则很简单： 每个人只能上传一张图片或一个视频。 不可编辑。 不可重试。 没有点赞。 没有评论。 没有个人资料。 没有时间戳。 一旦上传，瓶子就会被封存，无法更改。 运作方式 上传截止日期为 2026 年 1 月 1 日（太平洋标准时间） 每个账户只能上传一次 内容会经过审核，以屏蔽非法、政治或露骨内容 观看者随机打开瓶子，就像盲盒一样 每个用户每天只能打开有限数量的瓶子 瓶子不会重复 2026 年之后，上传将永远关闭。 该网站将成为一个固定的档案，记录人们在 2025 年选择留下什么。 为什么要做这个？ 大多数平台都致力于优化用户参与度。 而这个平台则去除了它。 “一次机会”的限制改变了人们的选择方式。 没有反馈循环、数据指标或可见性，内容感觉……更安静。 有些瓶子很私密。 有些很无聊。 有些毫无意义。 这正是它的意义所在。 它不是什么 不是社交网络 不是信息流 不是用来扩大受众的地方 这里没有任何东西会随着规模的扩大而改善。 作为一个个人项目构建，现已完全上线。 好奇这个项目（是否）能引起 HN 的共鸣。 很乐意回答技术或设计方面的问题。 — @linghuchong

嗨，HN。<p>项目简介：brig 是一个 CLI 工具，用于基于 devcontainers 规范启动容器，它会根据该规范验证配置，并旨在成为官方 CLI 工具的近乎即插即用的替代品。<p>对我个人而言，验证部分非常重要；我想继续使用我的团队正在使用的 devcontainer.json 文件，并且我希望我对其所做的任何增强功能仍然可以在他们的 VSCode 环境中使用。<p>---<p>我非常喜欢 devcontainers[1] 背后的理念，并且一直推动我的团队在几乎所有代码库中采用它们。我也非常喜欢它们名义上不与 VSCode 绑定（它们只是具有一些便利功能的容器）。多年来，我一直依赖一个简单的 shell 脚本[2] 来启动基于项目 Containerfile/Dockerfile 的容器。<p>直到最近我才开始深入研究该规范；当我这样做时，我发现了相当不错的功能（例如，生命周期脚本），如果没有向我的小 start-dev-container.sh 脚本添加补丁，这些功能会很好用。<p>顺便说一句，我已经很多年没有写过 shell 和 Python 脚本以外的任何东西了（而且自从我为 FLOSS 贡献任何东西以来已经更久了）。由于 Go 在我使用的工具（OpenTofu、Podman、Docker）中被广泛使用，我认为这不失为一个学习 Go 的好借口。<p>我将对 devcontainers 的兴趣和学习 Go 结合起来，这就是结果。<p>虽然我写这个是为了满足我自己的需求，但我希望其他人也能从中找到用处。<p>[1]: <a href="https://containers.dev" rel="nofollow">https://containers.dev</a><p>[2]: <a href="https://github.com/nlsantos/brig/blob/38d4ae10557422c37af349c9df3b460c343d487c/start-dev-container.sh" rel="nofollow">https://github.com/nlsantos/brig/blob/38d4ae10557422c37af349...</a>

大家好，HN， 我是 Post2X 的创建者。我最近离开了从事了 7 年的数据科学工作，开始构建自己的工具。 我遇到的问题是工具碎片化。为了在社交媒体上进行内容营销，我需要在用于文案的 LLM、用于视觉效果的表情包数据库和用于排程的 Buffer 之间来回切换。这效率很低。 我构建 Post2X 是为了将整个流程统一到一个工作流中。我的内部基准是在 1 小时内创建和排程 100 多个帖子，这使我能够批量处理内容营销工作，然后回去写代码。 该工作流程实现这一速度的方式： * 统一草稿（语音和文本）：您提供输入/主题，它使用“声音模仿”层生成草稿，因此输出听起来像您或您提供的用户名，而不是通用的机器人。 * 集成视觉效果：无需切换标签页来查找图像。您可以在编辑器中直接通过提示生成图像，或从热门表情包中提取图像，为您的帖子添加上下文。 * 启发式评分：该工具在您发布之前对草稿进行评分，而不是猜测帖子是否好。注意：这不仅仅是历史回归；它根据特定的写作启发式方法（钩子强度、清晰度、回复性、紧张感等）对文本进行评分。 * 一键排队：我消除了手动排程日期的摩擦。您只需设置一次“时段”，然后只需单击一下即可将内容推送到队列（适用于 X 和 LinkedIn）。 技术栈：TypeScript、Tailwind CSS、Python、Supabase、OpenAI API、Gemini API、X API 免费试用。（无需信用卡） 我很乐意收到关于生态系统流程的反馈。整体体验是否流畅快速，或者是否有任何地方让您感到缓慢或杂乱？