Link | Comment

🔼 308 | 💬 483

OpenClaw如何重塑开发者的角色与生活

• 作者使用Claude Code等AI编程工具已逾一年，编码效率虽有所提升，但程序员作为”代码执行者”的核心角色并未发生根本转变——仍需亲自搭建环境、调试测试、监控全过程，仅仅是将手动输入代码改为在聊天框中输入意图。
• OpenClaw作为通用型AI Agent，通过消息应用进行语音交互，能够准确理解意图、独立长时间工作并保持持久记忆，可在持续使用中逐步进化——这些能力使其真正能够替代作者成为”代码执行者”。
• 使用OpenClaw后，作者只需表达意图，它便会自动创建项目并制定计划供审阅；作者可通过语音讨论修改方案，它甚至能指挥Claude Code完成实际编码工作，彻底将作者从编程细节中解放出来。
• 作者将这种转变定义为从”超级个体”到”超级管理者”的跃迁——不再陷入具体代码细节，而是以管理视角统筹项目的开发、测试、部署和运营，如同拥有随时待命、能同时处理多个项目的程序员团队。
• 这一转变解放了作者的生产力，使其能够推进此前因精力有限而搁置的众多想法，无需资金投入便实现了企业主的梦想——专注于产品设计与规划，而将执行工作交给AI完成。
• 作者视OpenClaw为AGI时代的开端，认为这彻底改变了工作流程，让自己真正感受到了生活发生转变的关键时刻。

Link | Comment

🔼 326 | 💬 58

在 Game Boy Color 上实现实时 3D 着色器

• 作者为 Game Boy Color 开发了一款实时渲染 3D 图像的游戏，玩家可控制光源绕物体轨道旋转（控制 Lφ），物体同时自身旋转
• 核心原理将法线贴图视为矢量场，每个像素编码为 (Nφ, log(m), b) 的 3 字节元组存入 ROM，其中 Lθ 固定为常数以优化性能
• 由于 SM83 CPU 不支持乘法和浮点数，利用对数性质 log(x·y)=log(x)+log(y) 将乘法转为加法，配合查找表 (log/pow) 实现，每像素操作简化为 1 次减法、1 次 cos_log 查找、1 次加法、1 次 pow 查找、1 次加法
• 所有标量采用 8 位分数格式，范围 -1.0 到 +1.0，使用 127 而非 128 作为分母以同时支持正负 1.0；对数空间以 2^(1⁄6) 为底确保 3 个值相加不会溢出，最高位 (bit 7) 作为符号位实现异或运算
• 着色器每帧保证处理至少 15 个图块（约 960 像素），渲染消耗约 89% 的 CPU 时间（123,972 周期/帧）；像素渲染约 130 周期，空行仅 3 周期；因图像超过 15 个图块，刻意留下可见撕裂效果
• 为极致性能优化采用自修改代码：将 ld a, [Ltheta] + sub a, b（28 周期）替换为 sub a, 8（16 周期），单次操作节省 12 周期，960 像素共节省约 11,520 周期（约占着色器运行时 10%）
• AI 仅辅助约 5% 工作量：Python/OpenEXR 读取脚本、Blender 场景填充、VRAM DMA 复制片段；Claude Sonnet 4 生成的 SM83 汇编存在与 Z80 架构混淆等错误，作者最终手动重写全部核心实现；文中明确披露未使用 AI 的部分包括本文、算法、查找表、3D 资产等

Link | Comment

🔼 80 | 💬 28

GitHub 多项服务故障与恢复时间线

• 事故开始时间：2026年2月9日 19:01 UTC 开始调查 Actions、Git 操作和 Issues 的性能下降问题
• 影响服务扩展：故障随后波及 Webhooks、Pull Requests、Packages、Pages、Codespaces、Copilot 和 Dependabot 等多个系统
• 具体问题表现：用户遇到请求缓慢或失败、Actions 作业延迟，多个服务出现性能或可用性下降
• 恢复过程：19:29 UTC 实施缓解措施后出现恢复迹象，20:08 UTC 所有服务恢复正常处理
• 最终解决：20:09 UTC 确认完全恢复，事故历时约1小时8分钟，详细根因分析将后续发布

Link | Comment

🔼 395 | 💬 360

GitHub 通知递送延迟事件报告（2026年2月9日）

• 事件概述：GitHub 通知递送服务出现延迟，于 15:54 UTC 开始调查，19:29 UTC 正式宣布解决，整个事件持续约 3.5 小时
• 延迟演变：初始延迟约 50 分钟（16:12），随后增至约 80 分钟（16:51），达到峰值后开始逐步恢复
• 恢复进程：延迟从约 1 小时（17:25）缩短至 30 分钟（17:57），进一步减少至 15 分钟（18:33），最终完全恢复（19:14）
• 解决确认：GitHub 确认事件已解决，并将发布详细的根因分析报告，同时感谢用户的理解

Link | Comment

🔼 480 | 💬 332

AI 让简单的工作更简单，困难的工作更难

• 核心悖论：编写代码是工作中最简单的部分，真正的难点在于调查、理解上下文、验证假设和判断正确方案。当 AI 接手编码后，开发者失去了通过编写积累理解的过程，反而要独自面对更难的任务——阅读和审查 AI 生成的代码，而这些代码他们从未亲自写过。
• “AI 替我做了”现象：开发者开始像说”Google 帮我的”一样说”AI 替我做了”。这要么是过度夸大，要么意味着开发者没有形成自己的判断。若团队成员说”AI 写的代码”和说”StackOverflow 写的代码”一样令人担忧——领导者需要追问：他们是否真正理解了代码内容？
• 氛围编程的局限：仅适用于原型或个人低风险项目。在实际案例中，作者要求 AI 给 500 行文件添加测试，AI 却删除了 400 行内容还坚称没删除。若非有 git 历史追踪，根本无法恢复——这种情况若发生在医疗代码库中，后果不堪设想。
• 阅读比写作更难：阅读和理解他人代码比写代码更难，而 AI 生成的代码正是他人代码。开发者把擅长的写作部分外包给机器，却要面对更难的阅读任务，同时失去了通过编写积累的上下文理解。
• 管理层的人为因素：一旦团队快速交付成功，管理层会将速度视为新基线并追问”为何不能每次都这么快”。声称 AI 让效率提升 10 倍，可能是从 0.1x 变成 1x 而已，暴露的是此前调查工作的缺失。倦怠和粗制滥造会吞噬所有收益——疲惫的工程师会忽略边界情况、跳过测试、交付有缺陷代码。
• AI 是高级技能，初级信任：AI 编码能力很强，但必须像对待初级工程师一样仔细检查其输出。AI 没参加过过去的会议，不了解背景和上下文。AI 辅助调查是被低估的技能——直接让 AI 提供解决方案是许多人跳过的一步，正确用法是提供上下文，让 AI 帮助排查，人类负责验证结论。
• 所有权责任不可转移：开发者需要对每一行交付的代码负责，包括 AI 生成的。当六个月后新成员试图理解代码，或凌晨三点系统崩溃时，”AI 写的”这个借口毫无帮助。作者自己的案例（timezone bug）展示了正确用法：AI 做调查的基础工作，人类提供上下文并验证，开发者确认方案，最终 15 分钟定位根因，正常回家吃晚餐。

Link | Comment

🔼 390 | 💬 328

（AI）Slop让我恐惧

• AI可能已进入发展瓶颈——模型能完成90%的工作，但最后的10%无人问津，作者恐惧的正是这种”足够好可以发货”将成为唯一标准
• 真正可怕的不是AI本身，而是使用AI的人缺乏深究意愿——既不想学习理解自己产出的东西，也不在乎最终产品的质量，用户甚至会接受这种slop而觉得无所谓
• 作为木工爱好者，作者将这种趋势比作”特木化”——软件正从宜家式的标准化走向极端廉价化，比单纯的商品化更令人痛心
• AI工具不断引导开发者走向千篇一律的模板化应用，难以实现非常规创意——即便投入大量tokens尝试制作类似Paper by FiftyThree这样的独特产品，结果也只会平庸乏味
• 科技行业的激励机制从不奖励优质软件——小而美的独立应用会被大公司用免费克隆产品消灭，而AI代理让这一过程更加迅速和残酷
• 作者最后质疑：大多数普通人是否真的只想要口袋里的”小电视”？在”技术习得性无助”无法修复的时代，软件作为一门手艺的消亡是否将无人问津？