一周热榜

免责声明：本帖讨论的是人工智能及其在工程领域的应用。 我是一名资深工程师，从业 12 年了，对是否应该使用人工智能以及如何使用人工智能，我完全没有头绪。 这种感觉就像我离开之前的宗教一样：置身于一个新世界，我正在努力寻找自我认同，以及我真正的价值观是什么。 我重视工匠精神——但也重视把事情做好。 我一直提倡使用最强大的工具，主张使用调试器而不是打印调试，使用现代编辑器功能，如 LSP 等。 我重视独特性而非一致性，重视创造力而非死记硬背。 其中一些价值观支持使用人工智能，而另一些似乎强烈建议避免使用。 就像二战期间和之后通过可怕的手段发明的一些东西一样； 我觉得人工智能具有难以置信的潜力，但与此同时，它也在剥夺版权，毒害生态系统和社区。 我必须保住我的工作，这样才能养家糊口，但我不想从事任何需要我放弃任何价值观的工作。 然而，在工作中，我看到工程师们严重依赖人工智能的产出，而且这些产出往往质量很差——当然，并非总是如此。 我读了那篇“使用人工智能就像老虎机”的帖子，并且感同身受，但它难道不是一个可以节省我们时间的强大工具吗？ 如果我没有充分使用人工智能，我是不是会落后，并且再也无法从事我一生挚爱的这个行业了？ 我知道这就像对着虚空呐喊； 但你们中肯定有人在听，对吧？

Anthropic 重写了 Claude Code 的终端渲染器，发现问题不在于 React，而在于 Ink 的行级重写。我将他们的方法构建成了一个独立的库。 CellState 使用自定义的 React 协调器，直接渲染到单元格网格，并在单元格级别逐帧进行差异比较。由于它在内联模式下运行而不是在备用屏幕上运行，因此保留了原生终端行为（滚动、文本选择、Cmd+F）。 React 的协调器只处理发生变化的子树，而单元格差异比较只覆盖视口，而不是整个回溯。 在 250 条消息（33KB 内容）的情况下，单个单元格更新会向终端写入 34 字节，与内容大小无关。Ink 为同样的更改写入 41,955 字节。完整的渲染流程（协调、布局、栅格化、单元格差异比较）需要 2.54 毫秒，而 Ink 需要 36.93 毫秒。 基准测试和方法：https://github.com/nathan-cannon/tui-benchmarks https://github.com/nathan-cannon/cellstate

我厌倦了浏览采样库、购买插件，以及拼命想用Suno创作原创音乐和声音设计。 我开发了一款DAW（数字音频工作站），音乐制作人或内容创作者可以免费试用！你可以独立生成单独的音轨、单次采样和音效，也可以在工作室模式下进行。 你还可以即时分享和混音作品，这在现有的音频领域里是难以想象的。 如果你想和我一起开发这款产品，请给我发邮件：kindred@sonurastudio.com :)

我一直在构建一个 GPT-2 的交互式 3D + 2D 可视化。它显示了从 GPT-2 Small (124M) 中提取的真实激活值和注意力分数，这些数据是在前向传播过程中获得的。目标是通过展示模型内部发生的事情，来帮助大家更容易地学习 LLM（大型语言模型）的工作原理。<p>3D 部分使用 Three.js 构建，2D 部分使用纯 HTML/CSS/JS 构建。<p>很想听听您的想法或反馈！

我的朋友、同事们，以及我自己，几乎每天都在使用 OpenCode 搭配 AI 编码助手。问题在于，当有人在编程过程中需要帮助时，你只能分享屏幕或者站在他们旁边。没有办法直接参与进来。这个过程让我想起了“橡皮鸭调试法”。 我开发了 Qwack 来解决这个问题。一个人负责托管 AI 助手，其他人可以加入。所有人共享相同的上下文，看到相同的输出，并且可以发送提示来帮助引导 AI 助手。托管者的机器运行所有程序，服务器只是一个 WebSocket 中继。 GitHub: <a href="https://github.com/qwack-ai/qwack" rel="nofollow">https://github.com/qwack-ai/qwack</a>