作者分享了利用 Claude (Opus 5.5) 重构个人网站的经历，在未编写一行代码的情况下，实现了复杂且具交互性的 3D 视觉效果。
通过使用 Claude Projects，作者指挥了一组 AI 智能体来协同处理并行任务。这些完全在云端运行的进程涵盖了从 Blender 程序化 3D 建模、复杂的路径追踪光照，到声音合成和视频制作的各个环节。作者担任创意总监，采用了“管理式”工作流：设定目标、提供灵感，并依靠对抗性质量保证（QA）线程来把控质量，而非手动检查代码。
该项目包括一部模仿沃纳·赫尔佐格纪录片的 CGI 短片，且主要通过移动设备完成，凸显了创意工作方式的转变。尽管作者也意识到人们对 AI 辅助设计“机械化”的担忧，但他们认为这些工具起到了平衡器的作用，使其能够以空前的速度将内在愿景转化为现实。通过将技术实现外包给 AI，作者成功跨越了从创意构思到实际落地的鸿沟，标志着其专业工作流的重大演进。
每日HackerNews RSS
Claude Opus 5.5 较前代产品有显著提升，包括更快的令牌生成速度、更强的智能体编程能力以及更精准的视觉数据处理。由于“思考”功能现已默认开启，既有的提示词建议进行重新评估，而非直接迁移。 **关键优化策略：** * **努力程度校准：** 不要沿用旧设置，应针对具体应用场景测试新模型的努力程度（低/中/高/超高/最高）。通常情况下，现在的“中”等级别表现已优于旧版的“高”。 * **智能体工作流：** 为防止任务过早终止，请明确指示模型：在任务未完成时，不要以总结陈词结束对话轮次。对于无人值守的任务，应使用系统级指令强制要求提供进度更新并持续执行。 * **视觉与多应用任务：** 该模型在读取复杂视觉数据方面表现出色；请优先提供高分辨率输入，仅在必要时才提供裁剪/缩放工具。对于多应用工作流，应指示模型在采取行动前先探索相关来源（如电子邮件、文档）。 * **提示词与安全性：** 移除所有旧有的“无需思考”类指令。使用自定义标签界定用户粘贴的内容，以防范间接提示词注入。针对多轮对话，如果延迟成为问题，可指示模型将之前的回答视为既定事实，除非另有要求。
受一条称 JSON 不适合“真正™开发者”的评论启发，作者着手构建了一种自定义的二进制序列化格式。最初只是为了进行简单的字节打包实验，最终演变成了一个名为 **jBin** 的完整、基于模式的二进制序列化系统。 该项目利用 LEB128 可变长整数来高效编码数据，并实现了一种自定义模式语言来定义结构体、枚举、联合体和映射。通过利用模式来指定类型，它消除了重复的头部信息，从而实现了类似 C 语言结构体的效率。 开发者完全使用 C++ 从零构建了整个生态系统，包括： * **词法分析器和语法分析器：** 用于处理自定义模式语法。 * **语义分析器：** 用于验证类型并处理依赖关系。 * **动态打包器：** 能够通过引用模式将 JSON 直接转换为二进制格式。 * **多语言代码生成器：** 使用访问者模式（Visitor pattern）来生成原生语言结构。 最终，与标准 JSON 相比，jBin 的有效载荷大小减少了约 **80%**。该项目成为了 Protobuf 等大型工具的一种稳健且无需依赖的替代方案，证明了二进制序列化既可以高度高效，又可以成为一种有趣的实现过程。
这篇 Hacker News 的讨论聚焦于创建自定义二进制数据格式与使用现有标准之间的权衡。
许多参与者认为，虽然编写自定义二进制打包程序是一种有趣的实践体验，但它往往是在“重复造轮子”。批评者指出，自定义格式通常缺乏魔数头、版本控制、校验和以及对 Unicode 的支持等必要功能。
与手动实现相比，参与者提出了几种替代方案：
* **压缩：** 仅对现有的 JSON 使用 GZIP 或 Zlib 通常就能达到足够的效率。
* **标准化格式：** 使用 MessagePack、CBOR 或 BSON 等成熟的自描述二进制格式，可以在不牺牲兼容性的前提下提高效率。
* **基于模式的协议：** 对于需要高性能和严格类型检查的场景，推荐使用 Protocol Buffers 等方案，尽管它们与 JSON 不同，需要预先定义模式。
* **优化文本：** 一些人认为，手动编写紧凑的基于文本的格式既能显著节省空间，又保持了可读性。
归根结底，大家的共识是：尽管自定义二进制解析在资源优化（尤其是针对内存受限环境）方面是一种有益的练习，但开发者仍应在这些优势与现有行业标准解决方案的稳健性和可维护性之间进行权衡。
关于 新闻 版权 联系我们 创作者 广告 开发者 条款 隐私 政策与安全 YouTube 工作原理 测试新功能 © 2026 Google LLC
作者挑战了软件工程正在消亡的观点，认为它实际上正在经历一场重生。虽然人工智能编程代理能够处理编写样板代码或调试语法等枯燥、低价值的任务，但该职业的核心依然完好。 工作并没有消失，只是从手动实现转向了方向把控、判断和架构责任。通过消除“偶然复杂性”带来的负担，这些工具使工程师能够专注于更高层次的问题解决、探索新领域，并实现那些以往因耗时过长而无法进行原型的创意。 尽管作者承认关于就业保障、初级工程师培养以及盲目自动化风险的合理担忧，但他们认为这些属于组织和纪律层面的挑战，而非对该行业本质的生存威胁。归根结底，软件工程的核心不在于敲代码，而在于理解系统并做出明智的权衡。软件工程远未到“葬礼”之时，它正在演变成一个更具创造力、更广阔且更具影响力的领域，使我们能够以以往无法想象的规模去解决复杂问题。
圣奥古斯丁在其《忏悔录》（6.3.3）中描述了他的导师安布罗修默读的情景——奥古斯丁显然认为这种做法不同寻常。这一观察已成为威廉·A·约翰逊和阿尔贝托·曼古埃尔等学者的关注焦点，他们探讨了在以朗读为既定规范的古代世界中，默读是否属于反常现象。奥古斯丁推测，安布罗修默读是为了避免被打扰、管理时间或保护嗓子免于嘶哑。 除了学术辩论外，该文还指出了《忏悔录》作为一部著作的历史重要性，并特别提到了约翰·门特林于1470年印制的版本。此外，2010年的电影《圣奥古斯丁的一生》因其历史准确性而受到赞誉，特别是在真实呈现从古代书卷到早期抄本的过渡方面。总而言之，这些参考资料强调了古代晚期阅读习惯及文本物理形态的演变。
关于 新闻 版权 联系我们 创作者 广告 开发者 条款 隐私 政策与安全 YouTube 的运作方式 测试新功能 © 2026 Google LLC
arXivLabs 是一个允许合作者直接在我们的网站上开发并分享 arXiv 新功能的框架。与 arXivLabs 合作的个人和组织都认同并接受我们关于开放、社区、卓越和用户数据隐私的价值观。arXiv 始终致力于这些价值观，并仅与遵循这些价值观的合作伙伴进行协作。如果您有能为 arXiv 社区增加价值的项目构思，欢迎了解关于 arXivLabs 的更多信息。
本文评估了“表格基础模型”（如 TabICL 和 TabPFN），这类模型通过“上下文学习”在无需传统训练或超参数调优的情况下对新数据进行预测。
作者在十四个数据集上将这些模型与“经过调优的 XGBoost”进行了对比测试。研究结果表明表格数据工作流可能迎来范式转变：
* **性能：** 在 AUC 指标上，TabICL 在每个数据集上的表现均优于经过调优的 XGBoost。在准确率方面，除了少数例外，其表现始终具有竞争力或更胜一筹。
* **效率：** 其主要优势不仅在于准确率，还在于省去了耗时的超参数调优这一“繁琐流程”。XGBoost 通常需要数秒甚至数小时来优化，而基础模型往往能在不到一秒的一次前向传递中提供高质量的结果。
* **可扩展性：** 即使数据集规模增加到 32,000 行，这一优势依然存在。
* **局限性：** 在“宽”表格（数百列）上性能会下降，这很可能是受限于 Transformer 的注意力机制。此外，与轻量级树模型相比，部署过程更为复杂，且部分模型的最新版本增加了限制性的许可壁垒。
**结论：** 对于典型表格（不超过 30,000 行，少于 100 列），基础模型提供了更优、近乎瞬时的基准，是快速探索的理想选择。
Golang: Crypto/fips140: 避免不必要地臃肿加密代码 Golang: Crypto/fips140: do not bloat crypto code unnecessarily
47 天前
本提案建议将 Go 语言 FIPS 140 加密代码的默认配置更改为 `GOFIPS140=disabled`。目前，即便绝大多数用户并不需要，符合 FIPS 标准的加密代码（包括复杂的随机数生成器 (RNG) 以及各种算法实现）仍会被编译进几乎所有的 Go 二进制文件中。 这种“冗余”给不需要 FIPS 认证的应用程序带来了不必要的代码量、内存占用和二进制文件体积开销。本提案建议将 `fips140.Enabled` 变量转换为编译时常量。通过将默认值设为 `disabled`，Go 编译器可以利用死代码消除技术，剔除与 FIPS 相关的实现、分支及相关依赖。 作者认为，应当将 FIPS 功能进行隔离，确保只有明确选择启用的用户才需要承担这些额外复杂性带来的开销。目前已开发出一系列变更列表 (CL) 来实现此项调整，同时确保必要的测试基础设施保持稳健，从而使 Go 标准库回归到适用于通用应用程序的精简、高效状态。
这篇 Hacker News 帖子讨论了开发者 zx2c4 为 Go 语言 FIPS 140 实现提交的补丁所引发的争议。zx2c4 认为当前的实现造成了不必要的代码臃肿。
技术层面的争论焦点在于代码体积的实际影响。评论者指出，“臃肿”代码与补丁建议之间的差异极小——在剥离符号后的二进制文件中仅约 75kB——这表明对“二进制臃肿”的担忧可能被夸大了。其他人则认为，如果如此小的体积差异至关重要，开发者通常会使用 `tinygo` 等工具或对二进制文件进行剥离。
除技术细节外，讨论还涉及了管理 FIPS-140 合规性的挑战以及未来集成后量子密码学（PQC）的问题。一些用户还质疑了该开发者的沟通方式，指出虽然 zx2c4 技术高超，但其沟通风格仍是摩擦的来源。此外，对于该问题的紧迫性也存在质疑，部分参与者认为在维护者有合理的响应时间之前，不应将此事带到 Hacker News 上讨论。