最新

<a href="https://www.hetzner.com/pressroom/standardization-and-price-adjustment-of-our-server-products/" rel="nofollow">https://www.hetzner.com/pressroom/standardization-and-price-...</a>

我越是使用 Claude Code 来生成大块的系统，就越觉得我们缺少很多实践和工具。 第一个让我非常恼火的问题是缺乏对提示（prompts）的跟踪。有很多小的输入信息会影响系统应该做什么，而这些信息似乎非常短暂。从那以后，我开始在代码库中跟踪这些提示。 另一个观察是，如果你想获得良好的代理（agentic）输出，你需要在上下文窗口（context window）中提供大量的信号。看来，对进入上下文窗口的内容保持严谨是关键。使用 AI 生成输入文件可能会很危险，因为它会给人类信号增加熵/噪声。 我开始实践的一种方法是按照特定的方式组织我的项目： * `/specs` - 纯粹的人类信号，如产品愿景、需求、设计等。 * `/prompts` - 代理的“食谱”，如技能、任务、AI 模式。 * `/references` - 可用于上下文窗口的参考资料（品牌资产、文档、Figma 导出、数据集等）。 * `/plans` - 项目的代理计划。这些计划通常会有迭代。 * `/build` - 从计划和提示交互中构建的代码库和传统的单体仓库。 （我在 rekallai/craft 的公共 GH 仓库中有一个包含上述内容的 AGENTS.md 文件） 我对这个结构还不完全满意。我觉得 `/plans` 这个名字随着我使用它的增多，有点名不副实（例如，我经常需要生成关于代码库或其他数据集的报告）。 我非常想知道其他（拥抱代理编码的）开发者是如何组织他们的项目的。我的目标是在我的团队中标准化这一点。

我一直在致力于 Deconvolution，这是一个全面的 Rust 图像去卷积和复原库。Deconvolution 实现了 28 种不同的图像去卷积/复原方法，涵盖了从实用的模糊去除技术到研究级的科学成像算法。 特性： - 顶层函数使用 `image::DynamicImage` 并返回图像 - 逆滤波、维纳滤波、Richardson-Lucy、约束滤波、近端滤波、Krylov 方法、最大似然估计复原 - 盲 Richardson-Lucy、盲最大似然估计、参数化 PSF 估计 - Kernel2D、Kernel3D、Transfer2D、Transfer3D、Blur2D/Blur3D - 高斯模糊、运动模糊、散焦模糊、显微成像模型、支持工具、PSF/OTF 转换 - 边缘渐缩、归一化、范围归一化、NSR 估计 - 确定性模糊、噪声、合成固定件生成 - 支持 ndarray 用于 2D 图像数组和 3D 体积 当然，这个项目还在进行中 :)