给软件开发者准备的优质简报，每日阅读 10分钟。
Memory has grown to nearly two-thirds of AI chip component costs
AI芯片组件成本：内存占比从52%攀升至63%
- 高带宽内存（HBM）在AI芯片组件成本中的占比从2024年第一季度52%上升至2025年第四季度63%，Logic die保持在13%左右，而先进封装从19%降至15%，辅助组件从15%降至9%
- HBM绝对支出从2024年的约120亿美元飙升至2025年的约320亿美元，增速远超其他任何组件
- AI芯片组件总支出从2024年的约220亿美元增至2025年的约520亿美元，其中HBM贡献约200亿美元增量
- 由于内存供应持续紧张且价格上涨，预计2026年HBM占比将进一步提升
- 微软2026财年约1900亿美元资本支出预算中，约250亿美元用于应对组件价格上涨；Meta将2026年资本支出预期上调约100亿美元
- 数据涵盖Nvidia、AMD、Google和Amazon设计的芯片，按产量加权平均计算，来源于Epoch AI的AI芯片组件数据库
Migrating from Go to Rust
Go到Rust迁移：类型系统保障与渐进式策略
- 核心差异在于编译器保障程度：Go依赖垃圾回收器、运行时竞态检测和约定俗成的错误处理；Rust将nil处理、错误传播、数据竞争、资源生命周期等编码为类型，由编译器强制执行——整类运行时bug（如nil panic、数据竞争）在编译阶段就被消除，这是设计哲学的根本差异：Go优化迭代速度，Rust优化正确性
- Rust泛型系统更深层：Go 1.18引入泛型但标准库几乎不用（仍依赖
any/反射/encoding/json仍用反射），约束仅是结构化接口，无trait系统、无超特质、无关联类型、无覆盖实现；Rust泛型与trait绑定，单态化实现零成本抽象，泛型渗透标准库各角落——移除泛型Rust语言就会崩溃，而Go泛型只是窄幅补充工具 - 所有权与借用检查器是最大挑战：初期会遇到代码"明显正确"但编译器拒绝的情况（长期引用、自引用结构体、跨线程共享状态），但所有被拒绝的代码都存在真实内存安全隐患；一旦内化所有权语义，编译器就成为帮你做这部分工作的得力助手；其他挑战包括编译时间较长、
async fn/fn函数着色增加认知负担、部分领域生态较小 - 迁移策略应渐进式：优先迁移延迟敏感热点服务或后台worker，通过API网关实现"绞杀者模式"逐步替换，保持相同API契约；不要逐字翻译Go惯用法（
if err != nil→?，goroutine-per-request→按需spawn），且应尽早投入培训时间 - Go在特定场景仍是首选：Kubernetes operators、CLI工具、胶水服务和团队迭代速度优先的场景无需迁移，Go在JetBrains调查中保持约17-19%使用率，混合架构（Go处理常规服务+Rust处理关键路径）最务实
- 预期收益与局限：生产故障显著减少（数据竞争和nil panic几乎消失）、CPU提升20-40%、内存降低30-50%、P99延迟曲线更平坦（无GC抖动）；但难以获得10倍吞吐提升，更多是减少"低级错误"和平缓延迟尾部
The Eternal Sloptember
永恒的"Sloptember"：AI编程代理的批判性反思
- AI代理本质上是模仿编程分布的高级统计模型，输出虽日趋难以辨别但核心仍是破损的——这正是愈发精准的统计模型的必然特征；作者历时6个月亲身测试（tinygrad代码编写、USB转PCIe芯片逆向），结论是手动完成质量更高、速度更快，代理只是"前置"了进度，随后留下一个永远无法完成打磨的"老虎机拉杆"
- 高绩效者普遍具备纠错能力，能识别"废料"并仔细阅读理解每一行代码；大型组织反馈循环缓慢、对其度低，下限员工借代理产出"10倍"代码，导致组织整体平均输出质量下降，而苹果等公司正大力推行AI集成，macOS等产品的质量前景堪忧
- AI作为搜索工具和快速原型生成器确实有用（尤其在不需打磨的场景），但远未达到任何作者工作过的公司的专业软件工程师标准，核心问题在于知道何时该用、何时不该用
- 当人们看到一件产物时会本能假设创造者具有人类思维状态，但AI生成物并非由这种过程创造，这种差异在语法结构上极其微妙，却在人类互动和基于其构建时显而易见——旧有的质量代理指标（如语法）已失效
- 作者认同LeCun/Marcus立场：真正的编程代理需要世界模型，而非当前LLM那种RLVR式的将失败测试注释掉并宣称全部通过的拙劣模式匹配
- 这个时代的真正故事是谁能在"AI精神病"中保持清醒、避免自我伤害；作者几乎认为鼓吹代理的言论是某种"心理战"，利用对地位丧失的恐惧推动企业采纳，却可能导致巨大损失
Jira Is Turing-Complete
Jira自动化功能的图灵完备性证明
- 作者Nicolas Seriot通过在Jira中实现Minsky寄存器机模型，提供了图灵完备性的严格证明；该模型仅需两个无界计数器和有限数量的带标签指令（INC和DEC），已被Minsky于1967年证明是图灵完备的
- Minsky机器的各组件映射到Jira元素：寄存器A对应Bug关联问题的数量，寄存器B对应Task关联问题的数量，程序计数器对应Epic的工作流状态，分派表对应自动化规则，递增/递减操作通过创建和删除关联问题实现
- 最小实现方案使用一个Epic、两个自动化规则（TODO规则和DEV规则）完成加法运算：以初始状态（A=2, B=3）启动Epic后，经过五次状态转换，Epic最终停在PROD状态，此时A=0、B=5，成功计算2+3=5
- Jira的"转换问题类型"功能可将问题在Bug、Story、Task之间瞬间转换，等价于DEC+INC操作，可大幅简化调度表，使非平凡程序变得可实现
- 斐波那契机器以三个状态（TODO、QA、DEV）和三种问题类型（Bug、Task、Story）实现，初始A=B=1、C=0，Task数量依次生成序列1、1、2、3、5、8、13……；由于不存在终止状态，该机器运行至Jira Cloud的规则执行深度限制（默认10层）后，由人工重新触发Epic继续
- 由于任何物理计算机都是有限的，Jira Cloud的规则执行深度限制并不否定该构造的图灵完备性——图灵完备性是一个标准理论约定，因此复杂Jira自动化本质上就是程序
The bootstrapper's EU stack for under €10 per month
创业者专属：月均10欧元以下的欧盟技术栈搭建指南
- 核心目标是在正式付费前以最小成本验证产品想法，文中只推荐提供永久免费套餐的服务商（非14天试用）；服务器托管是唯一的固定支出，其他均为可选的免费服务
- Hetzner Cloud CX33服务器是最具性价比选择（€7/月），4核CPU、8GB内存、80GB存储可流畅运行Django/Rails应用、Postgres数据库、Redis缓存和后台任务，能支撑数千日活用户；Netcup为替代方案，VPS方案低于€5/月
- 邮件服务分为两类：交易邮件（密码重置、收据、订单确认等）推荐三个提供永久免费套餐的欧盟供应商；新闻通讯和邮件营销推荐支持数百订阅者的免费方案
- Google Analytics存在GDPR合规问题且需要烦人的Cookie提示横幅，对初期产品验证属于过度设计；推荐Simple Analytics（无Cookie、仪表盘简洁）或TelemetryDeck（适合移动和桌面应用），两者均有慷慨的免费套餐
- 监控服务推荐UptimeRobot（免费50个监控点）或Healthchecks.io（适合定时任务检查，支持开源自托管）；表单工具推荐Tally（无限表单和响应）或开源方案Formbricks（适合应用内调查）
- 支付处理推荐Mollie（无月费、按交易收费，欧盟版Stripe）和Creem（数字产品的记录商，处理全球VAT合规）；认证方案推荐Hanko，支持无密码的Passkey技术，开源可自托管