给软件开发者准备的优质简报，每日阅读 10分钟。
How I use Claude Code: Separation of planning and execution
我如何使用 Claude Code 进行开发
- 核心理念：在 Claude 写代码前必须审查并批准书面计划，规划与执行分离是核心原则，能避免浪费精力、保持对架构决策的控制，产生更优结果且消耗更少 token
- 第一阶段——研究：要求 Claude 深入理解代码库，使用"deeply"、"in great details"、"intricacies"等词汇防止浅层阅读，将研究发现写入持久化的 research.md 文件作为审查依据，研究阶段是防止在孤立环境中正常但破坏周围系统的错误实现的关键
- 第二阶段——规划：要求 Claude 生成详细的 plan.md，包含代码片段、文件路径和权衡考量，使用自己的 markdown 文件而非内置计划模式以获得完全控制权，可附带开源项目参考代码
- 注释循环：在计划文档中添加内联注释纠正假设、拒绝方案、添加约束或提供领域知识，然后让 Claude 返回修改但明确标注"don't implement yet"，该循环重复 1-6 次，使计划从通用方案转变为完美契合现有系统的方案
- 任务清单：在实现前请求将计划分解为详细的任务清单，包含所有阶段和单个任务，Claude 在执行过程中标记完成项作为进度追踪
- 实现阶段：使用标准化指令"implement it all"，要求 Claude 在计划文档中标记已完成任务，不添加不必要的注释或 jsdocs，不使用 any/unknown 类型，持续运行 typecheck，作者希望实现阶段是"机械的"而非创造性的
- 实现过程中的反馈：使用简短指令甚至单句话纠正问题，视觉问题可附加截图，参考现有代码比从头描述更精确，方向错误时直接回滚并重新缩小范围
- 单一长会话：将研究、规划和实现放在一个连续的长会话中进行，计划文档在上下文压缩后仍完整保留，作为持久化工件随时可引用
Why is Claude an Electron app?
为什么 Claude 仍是一款 Electron 应用？
- Anthropic 在 AI 编码工具领域处于领先地位，甚至斥资 2 万美元让 AI 代理用 Rust 实现了一个 C 编译器，但桌面版 Claude 仍采用 Electron 构建
- Electron 的核心优势在于"一份代码，多平台运行"，可使用 HTML、CSS、JS 构建同时支持 Windows、Mac 和 Linux 的桌面应用，Slack、Discord、VS Code、Teams、Notion 等常用软件均基于此框架
- Electron 应用的缺点明显：每个应用自带 Chromium 引擎导致体积臃肿（最小数百 MB）、运行卡顿、响应迟缓、与操作系统功能集成不佳（虽然可通过针对性开发解决，但很少有人这样做）
- 理论上 AI 代理可根据规范和测试套件生成跨平台原生代码，但实际上它们擅长开发工作的前 90%，最后 10% 的边缘情况处理和持续维护仍困难重重
- Anthropic 自己的 Rust C 编译器项目充分暴露了这一问题——虽快速通过大部分测试，但添加新功能或修复 bug 时频繁破坏现有功能，最终几乎无法使用
- 三个原生平台意味着三倍的 bug 排查和支持工作，目前 Electron 仍是更务实的选择
Be wary of Bluesky
警惕Bluesky：开放协议背后的集中化隐忧
- Bluesky虽基于开放协议ATProto构建，但几乎所有用户的数据实际存储在Bluesky运行的个人数据服务器（PDS）上，自托管率极低
- Bluesky同时控制着去中心化架构的关键层：Relay（数据中继）、AppView（时间线组装）、DID目录（身份解析），理论上任何人都可自行运行，但实际几乎无人这样做
- 每新增一个ATProto第三方应用都要求用户"用Bluesky账户登录"，将更多数据写入Bluesky服务器，形成集中化的反向飞轮——应用越多，用户越难以离开
- 若Bluesky被收购，收购方将同时控制PDS、主Relay、AppView和DID目录，可禁用数据导出、切断第三方应用、插入广告或实施内容审查，影响范围覆盖整个生态系统
- 1.2亿美元VC融资及7亿美元估值意味着投资者需要回报，这种压力与真正的去中心化相悖；技术上的"可以离开"不等于用户实际会行动，email、RSS、XMPP等协议的历史已证明这一点
How Taalas “prints” LLM onto a chip?
Taalas如何将LLM"打印"到芯片上
- Taalas是一家成立2.5年的初创公司，其首款ASIC芯片可在17000 tokens/秒的速度运行Llama 3.1 8B（3/6位量化），约等于每秒生成30页A4纸的内容
- 该芯片采用固定功能ASIC设计，将模型的32层权重直接刻蚀为硅片上的物理晶体管，信号通过物理线路逐层传递，完全绕过传统GPU的内存带宽瓶颈
- Taalas发明了"魔法乘法器"硬件方案，使用单个晶体管存储4位数据并执行乘法运算，大幅降低能耗和延迟
- 芯片不依赖外部DRAM/HBM，仅使用少量片上SRAM存储KV Cache（上下文缓存）和LoRA适配器
- 芯片设计采用通用逻辑门和晶体管网格，仅需定制顶层两个掩膜即可适配不同模型，开发周期仅两个月
- 该方案相比GPU推理在所有权成本、能耗和速度上均提升约10倍
AI uBlock Blacklist
AI内容农场拦截列表项目介绍
- 这是一个用于uBlock Origin的AI内容农场黑名单项目（alvi-se/ai-ublock-blacklist），已获得361个Star、9个Fork和213次提交，采用手动维护方式
- 提供一键订阅链接或手动导入规则URL（
https://raw.githubusercontent.com/alvi-se/ai-ublock-blacklist/master/list.txt）两种安装方式 - 作者创建此列表的核心原因：主动搜索时希望获得真人编写的真实经验而非AI生成内容；AI内容农场充斥着广告和推荐链接，且内容未经审核可能存在危险错误（如AI可能建议执行危险命令或混合化学物质）
- 识别AI内容农场的关键特征包括：不必要的冗长引言和结论、"全面指南"类标题、缺少外部链接和参考资料、到处是推荐链接、短时间内发布海量文章、包含AI生成的图片和Logo、内容模糊空洞、总是占据搜索引擎顶部位置
- 项目明确不采用自动检测，因为算法难以准确判断页面是否为AI生成；作者为意大利人因此列表中意大利网站较多，欢迎通过Issue或Pull Request贡献
- 提供Google Dorks搜索技巧（如搜索"Sure! Here's an article about"或意大利语"Certo! Ecco un articolo"）来发现AI生成页面；另有类似项目对比参考
Show HN: Llama 3.1 70B on a single RTX 3090 via NVMe-to-GPU bypassing the CPU
NTransformer：可在RTX 3090上运行Llama 70B的高效C++/CUDA LLM推理引擎
- 采用三级自适应缓存架构：VRAM常驻层（零I/O）+固定内存H2D传输+NVMe/mmap回退，70B模型在消费级硬件上实现相比mmap基线83倍加速
- 零外部依赖（仅需CUDA Toolkit），支持GGUF格式多量化（Q4_0/Q8_0/Q4_K_M/Q5_K/Q6_K/F16/F32），内置SLEP流式引擎双缓冲流水线重叠NVMe读取、PCIe DMA和GPU计算
- 层跳过功能通过余弦相似度校准可跳过20/80个冗余层，自推测解码利用VRAM常驻层作为draft模型无需额外模型
- 性能表现：Llama 3.1 8B Q8_0达48.9 tok/s（10GB显存全驻留），Llama 3.1 70B Q4_K_M层跳过模式达0.5 tok/s（36层VRAM+44层RAM，22.9GB显存）
- 瓶颈为PCIe Gen3 x8的H2D带宽（约6.5 GB/s），Q4_K_M量化可比Q6_K多容纳10层于VRAM中（36层vs 26层），减少跨层级数据传输
- 提供NVMe直连后端（gpu-nvme-direct），通过用户空间NVMe驱动将模型权重直接读入固定GPU内存，绕过CPU和内核
Andrej Karpathy talks about "Claws"
安德烈·卡帕西谈"Claws"技术概念
- 卡帕西购入Mac Mini来研究Claws技术（店员称其热销且众人困惑），但对运行OpenClaw仍持谨慎态度；他认为Claws是继LLM智能体之后的新层级，负责任务编排、调度、上下文管理、工具调用和持久化。
- "Claw"正成为一类智能体系统的技术术语，泛指类似OpenClaw的智能体系统——通常运行在个人硬件上，通过消息协议通信，既能执行直接指令也能调度任务。
- 卡帕西指出多个小型Claw项目正在涌现，如NanoClaw核心引擎仅约4000行代码，易于理解、审核和灵活使用，默认在容器中运行。
- 其他相关项目还包括nanobot、zeroclaw、ironclaw和picoclaw等，体现了该领域的多样性发展。
- "Claw"配有固定的表情符号🦞（龙虾），已在技术社区中形成一定的文化认同。
Fix your tools
修复你的工具
- 作者在调试自己维护的开源库时遇到一个难以定位的bug，尝试设置断点使用调试器，但程序运行完毕没有在断点处中断
- 作者没有先解决调试器问题，而是修改代码添加日志来诊断，但这种方法未能提供所需的洞察
- 作者意识到应该先修复调试器这个工具，最终发现只需一行配置更改就解决了问题
- 利用调试器观察到的详细信息，作者成功解决了原来的bug
- 作者领悟到一个悖论：急于修复bug的欲望反而阻碍了发现需要先修复工具；写这篇博客的目的是提醒程序员：先修复你的工具！
What is a database transaction?
数据库事务：核心概念与实现机制
- 事务生命周期与原子性：事务通过
begin启动、commit原子性提交所有更改、rollback手动回滚；意外中断（如断电、硬盘故障）时，MySQL和PostgreSQL通过预写日志（WAL）等灾难恢复机制确保数据不丢失 - 一致性读取的实现差异：PostgreSQL采用多版本并发控制（MVCC），每次更新创建新行版本并通过
xmin（创建事务ID）和xmax（替换事务ID）元数据追踪；MySQL则直接覆盖旧行数据，通过undo log记录修改历史供事务重建旧版本；两者在REPEATABLE READ模式下均支持一致性读取 - 四种隔离级别与异常现象：从强到弱依次为Serializable、Repeatable Read、Read Committed、Read Uncommitted；分别阻止或允许脏读（读取未提交数据）、不可重复读（同一行多次读取结果不同）、幻读（同一查询返回不同行数）
- MySQL并发写入处理：使用行级锁机制——共享锁（S锁）允许多事务同时读取，排他锁（X锁）独占写操作；SERIALIZABLE模式下更新必须获取X锁，可能导致死锁并由数据库检测杀死其中一个事务
- PostgreSQL并发写入处理：采用可序列化快照隔离（SSI），通过谓词锁追踪而非阻塞事务，实现乐观冲突解决；检测到违规时终止相应事务而非等待锁释放，应用需实现重试逻辑
Show HN: 3D Mahjong, Built in CSS
VoxJong - CSS麻将接龙游戏
- 一款基于CSS构建的麻将接龙（Mahjong Solitaire）网页游戏
- 游戏包含144张麻将牌，界面显示当前剩余牌数（144/144）
- 支持等轴测视图（Isometric）和顶视图（Top Down）两种模式切换
- 提供缩放功能，玩家可调整游戏界面大小
- 由Layoutit Studio开发，项目开源托管于GitHub