最新

我正在用 C 语言积极开发一个任意精度算术库，目标是提供一个与 GNU 的 LibGMP 速度相近的替代方案，但采用 MIT 许可证。作为一个全日制大学生，独自完成这项工作有点枯燥，但进展缓慢而稳定。 GitHub 链接：https://github.com/EpsilonNought117/libapac 我的 API 和命名方案受到了 GMP 公共 API 的启发，但内部实现（据我所知）完全是我自己的。该库目前在 x86-64 CPU 上使用运行时分发到特定于微架构的汇编函数版本，适用于类 Unix 和 Windows 操作系统，未来计划在两者上都支持 ARM64。我手写了所有汇编例程（从写作风格可能很明显），使用了 MASM 和 GAS 汇编器，并使用编译器内部函数编写了一些基于 SIMD 的例程。 到目前为止，性能似乎与 GMP 在中小型大整数方面相当（性能图表在 README 中）。我已经实现了一些算法，例如 Karatsuba 算法和分治除法（平衡和不平衡），并且会根据需要添加更多算法。《现代计算机算术》（作者：Brent 和 Zimmerman）和《黑客的喜悦》（作者：Henry Warren Jr.）这两本书确实帮助很大。 目前仍处于 WIP（进行中）阶段。 欢迎任何反馈和/或批评。乐于回答任何问题。

我希望用通俗易懂的语言来测试移动应用，而不是依赖像 XPath 或辅助功能 ID 这样容易失效的选择器。 使用基于视觉的代理，这部分实际上效果很好。它可以查看屏幕，理解意图，并在 Android 和 iOS 上执行操作。 更大的问题出现在测试的定义和维护方面。 当测试流程保留在代码库之外（手动编写或从产品需求文档中生成）时，它们很快就会与应用不同步。保持它们的更新需要大量精力，并且随着时间的推移，它们会失去可靠性。 然后，我尝试直接从代码库（通过 MCP）生成测试。这提高了同步性，但引入了高令牌使用率和较慢的生成速度。 对我来说，转变的关键在于意识到测试生成不应该是一次性的步骤。测试需要与代码库一起存在，这样它们才能保持同步并拥有更多上下文。 我保留了基于视觉的执行方式（没有容易失效的选择器），但将测试生成移到了更靠近代码库的位置。 我已经开源了核心部分： 1. 从代码库上下文生成测试 2. 基于 YAML 的测试流程 3. 跨 Android 和 iOS 的基于视觉的执行 代码库：<a href="https:&#x2F;&#x2F;github.com&#x2F;final-run&#x2F;finalrun-agent" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;final-run&#x2F;finalrun-agent</a> 演示：<a href="https:&#x2F;&#x2F;youtu.be&#x2F;rJCw3p0PHr4" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;rJCw3p0PHr4</a> 在演示视频中，您将看到“开发后的交接”。AI 在 IDE 中构建一个功能，Finalrun 立即为其生成并执行基于视觉的测试，以验证 AI 开发的功能。

我当时在构建一个代理，用于从 LLM API 调用中剥离 PII（个人身份信息），然后意识到零宽度 Unicode 字符基本上会破坏所有现有的 PII 过滤器。如果你在一个名字中插入一个零宽度空格，比如 T om，Presidio 的 NER（命名实体识别）模型就再也无法识别它是一个名字了。对于社保号和电话号码的正则表达式也是如此。因此，我构建了一个规范化层，在运行检测之前删除所有这些内容。<p>代理本身非常简单。你将 OpenAI 的基本 URL 更改为指向 Veil，它会在请求发出之前将 PII 移除，然后在响应中放回真实值。它也适用于流式传输，老实说，这是最难的部分。<p><a href="https:&#x2F;&#x2F;veil-api.com" rel="nofollow">https:&#x2F;&#x2F;veil-api.com</a>，免费套餐每月 100 次请求。