#software engineering

Go 官方博客宣布了一项新的 JSON API，核心是 \encoding/json/v2\ 的设计，面向所有依赖 Go 标准库处理 JSON 的开发者。现有条目未提供完整接口清单或可用时间，具体兼容性仍需查阅官方文档。社区讨论主要集中在迁移成本、\MarshalIndent\ 等常用接口的取舍，以及 \jsontext\ 包在解析性能和错误信息上的表现。

LWN 发布了一篇由 Tyler Langlois 撰写的 Nix flakes 解释文章，面向希望在跨发行版项目中固定依赖、构建环境和测试流程的开发者。文章说明 flake.nix 用 URL 式 inputs 和 outputs 定义包、开发环境等产物，nix flake lock 生成 flake.lock，把每个输入锚定到具体的上游提交，类似 Cargo.lock 或 Gemfile.lock。文章还强调 flakes 仍属实验特性，启用时需在命令中加入 --experimental-features &\x27;nix-command flakes&\x27;，或在 nix.conf 中设置该选项，而其稳定化路径仍不确定。

Hacker News 上的一则 Ask HN 讨论聚焦开发者交付自己未完全理解的 AI 生成代码时的不安与工程风险，起因是一位自称 Meta 工程师的 LinkedIn 帖称这种“黑盒”式交付正在成为新常态。讨论并非发布新工具或研究结果，多位评论者交流的做法包括：先由人确定抽象层级和设计，再让 LLM 补全实现；以及用大量测试和发布前门禁验证行为。讨论呈现的是实践经验，而非统一结论。

Anthropic 的 Claude Code 团队发布博文，介绍其内部如何处理代码审查：大部分流程自动化，人的注意力被引导到风险所在处；评测会随每次事故增长，对审查器的每次改动都会用整个评测集打分。评论区引用的博文内容还显示，文档、文案、内部功能以及藏在开关后的增量改动被列为低风险，在自动审查和安全检查通过后无需人工审查。这些是 Anthropic 对其内部实践的描述，而非独立测量的结果，完整博文也未被提供。

软件工程界知名人物 Rich Hickey 发表文章《AI Is Not a Tool》，主张不应把对话式 AI 系统简单称为“工具”。根据 Hacker News 讨论中的引述，Hickey 承认 LLM 本身可看作一种用自然语言查询、内置摘要的有损知识库；他批评的是把这类系统包装成做作业、研究、编程、写作的“工具”的说法。该文在 Hacker News 上引发关于 LLM 的能动性、工具与代理边界以及软件工程实践的讨论；帖子本身只给出 gist 链接，未提供更多技术细节。

Ars Technica 的一篇文章及 Hacker News 上的讨论指出，AI 编码代理虽然让代码产出量上升，却没有带来等比例的软件交付成果，瓶颈转移到代码审查与代码质量上。讨论中的从业者表示，代码审查原本就是显著瓶颈，在代理式编码下更加突出；尝试更多依赖自动化审查迄今没有转化为实际改善。有评论提醒，相关研究描述的是研究进行时的状况，主要涉及 Claude 3.5 至 Sonnet 4.5、GPT-4.1 至 GPT-5、Gemini 2.5 等模型，论文写作与发表存在滞后，因此反映的是 2025 年前后的图景，未必代表当前模型能力。需要说明的是，所依据的材料为分析摘要与社区讨论，未包含原文全文。