最新

多年来，我在公关评论中一直给出相同的反馈。我制作了一个代码检查工具，可以标记反馈，这样你就可以在提交前自动让编码人员遵循合规代码。

大家好，我是一个长期的读者，这次是第二次发帖。*编辑：因为我意识到我之前发过一次。 我即将完成一个产品，发现通常在整合支付时，我都是为其他已经确定了支付服务提供商的人服务。 我想知道大家有什么经验推荐。我真的希望能够建立一个联盟计划，以便能够给销售人员提供45%的佣金，并希望这个功能能够内置，这样我就能减少一些文书工作。 然而，我看到很多关于我计划使用的支付服务提供商（因为它满足所有要求）的恐怖故事，自从收购以来，我原以为它的可信度会提高。 无论如何，我觉得这个社区可能是最值得信赖的，可以了解各种经验和真实的反馈。

我正在开发一个简单的多人单词游戏，名为字母汤（Alphabet Soup）。<p>这个游戏有点像《纽约时报拼字游戏》（NYT Spelling Bee），但它是多人游戏，并且只有你最好的（最长的）单词才会计入得分。因此，游戏的重点不是尽可能找到多个单词，而是找到一个特别好的单词。<p>你可以和朋友在私人对局中游戏，或者加入公共竞技场比赛，与其他在线玩家对战。如果没有其他人在线，你将与一个机器人匹配。<p>这个游戏适合2名玩家，但也适合更大的人群，因为游戏不是回合制的。<p>很想听听大家的想法或问题 :)

一个AI编码客户端会自动读取 ~/.codex/AGENTS.md 和 ~/.claude/CLAUDE.md。这些是竞争编码客户端配置目录中的个人指令文件，位于用户选择的项目之外。 它们的完整内容会默认添加到第一次模型请求中，并发送到客户端的服务器。 在启动时，客户端会显示一条简短的通知，说明它正在包含其他客户端的个人规则。它并不会事先征得许可。可以通过命令行选项禁用此行为。 配置指南中提到：“您的机器范围内的用户规则总是会加载。”这要求用户在加载项目指令文件之前信任工作区。机器范围内的文件会自动加载。 我通过在 ~/.codex/AGENTS.md 中放置一个无害的信号指令进行了测试。在默认运行中，客户端遵循了该指令。当禁用外部个人上下文时，它则没有遵循。 这些文件可能包含内部编码标准、基础设施参考、项目细节或某人粘贴后忘记的凭证。 启动通知是否足够披露？在文档中描述这种行为是否等同于同意？您是否会期望一个编码客户端读取另一个供应商的配置目录中的文件，并在第一次请求时发送这些文件？

嗨，HN。我对GitHub Actions的可靠性以及无法在本地运行工作流感到沮丧。Preloop是GitHub Actions的Rust重实现，包括运行器（跟踪最新版本）和控制平面，后者在MacOS/Linux/Windows的硬件隔离微虚拟机上运行（我们使用的是smolvm项目，它利用libkrun虚拟机管理程序）。微虚拟机从打包的工件启动时间少于400毫秒，每个作业的cow-clone都是瞬时的。控制平面使用完全相同的官方运行器协议，因此未修改的actions/runner二进制文件可以注册、轮询、执行和报告。您现有的工作流文件无需更改，但可以在您自己的硬件上运行，且不消耗任何GitHub托管的分钟。在本地，您还可以运行未提交的更改，因此无需创建提交即可运行CI。如果您是单独工作或在小团队中，并且拥有快速的本地硬件，您可以使用类似DHH的gh-signoff扩展，直接合并，只要某些检查通过。我们还支持如失败时暂停的功能，失败后虚拟机会暂停，打开一个shell，允许您修复错误，然后您可以在不重新运行所有成功作业的情况下重试（新步骤/作业在一个新的微虚拟机中运行以验证更改），或者您可以直接连接到正在运行的虚拟机，实时查看每个作业正在执行的步骤。Preloop还实现了调试适配器协议，因此您或您的代理可以在本地驱动CI（使用内置客户端），或者您可以使用像Vscode这样的DAP客户端。您还可以将更改提交到服务器以运行CI，然后它可以为您打开一个草稿PR，并附带更新的检查，因此我们不仅依赖于来自GitHub的Webhooks。我投入了大量精力确保与官方运行器协议的一致性，因此我进行不同类型的中间人代理，以确保请求/响应体不仅匹配，而且在作业/步骤级别的结论/日志/注释等也一致。实际上，官方运行器应该可以与我们的控制平面正常工作。 Act、Forgejo都是很好的选择，但它们并没有忠实地实现官方运行器协议，因此在实际使用中某些工作流无法开箱即用，而且它们也在Docker容器中运行作业。Forgejo的兼容性最接近，如果您完全迁移出GitHub，仍然是一个不错的选择。使用Act时，有一些主要是服务器端的功能未实现（并发、某些矩阵功能、OIDC等）。Forgejo的兼容性最接近，如果您完全迁移出GitHub，仍然是一个不错的选择。Agent-ci也是一个很好的选择，它使用官方运行器镜像并实现官方协议，但它是设计为在本地运行，运行在容器中，并且不支持我们的一些功能（并发、更新的V2缓存、GitHub令牌等）。Preloop的设计也可以作为持久服务器运行，因此我们在检查API中实现了更多的提交更新。 还有更多功能即将推出，但我觉得这是一个很好的时机与社区分享，希望能引起一些人的兴趣。欢迎尝试。 网站: [https://preloop.dev](https://preloop.dev) GitHub: [https://github.com/preloopdev/preloop](https://github.com/preloopdev/preloop)

问题：我注意到，无论我尝试哪个 VNC 客户端，都无法在我本地的有线局域网（Mac Mini 和 Windows 桌面之间）上可靠地发送按键（平均约一个字节），两者都通过千兆以太网线连接到同一个路由器。 按键不断掉落。因此，我请 ChatGPT 5.6 Sol 在最高设置下构建一个能够可靠发送按键的解决方案。 它正在构建中。 在这里你可以看到，在千兆局域网下，它需要多长时间才能发送 1 字节的数据： <a href="https://robss2020.github.io/sol-vnc-elapsed/" rel="nofollow">https://robss2020.github.io/sol-vnc-elapsed/</a> 这个页面会实时更新，每 15 分钟截图一次，记录它在这个小学作业上的进展。 这仍在进行中。到目前为止，Claude 的尝试在达到 0 字节时花费了 5 天（然后我终止了该项目，改用 Sol），而 Sol 则在达到 0 字节时花费了大约 2 天，之后我不得不删除了那次尝试。 这次我选择公开构建，以便我们都能看到它在连接的以太网局域网上发送 1 字节数据而不掉落所需的时间。 以下是 Claude 构建的统计数据： 个人测试时间（62 次会议 x 10 分钟）：10.3 小时 个人邮件时间（62 封邮件，测试+思考+写作+阅读）：10.3 小时 个人总时间估计：20.7 小时 关于此主题你写的邮件数量：62 封 你写的字数（不包括引用历史）：20813 字 Claude 输入的总令牌数（包括缓存）：2758521167 Claude 输出的总令牌数：7930482 Claude API 调用次数：9135 在那个时候我不得不删除该项目。现在让我们看看 Sol 能否做得更好！ 到目前为止，已经过去了 1 小时 32 分钟，仍在计时中…… 我会在接下来的两到三个月内持续更新这个进度，直到完成，预计会使用数十亿个令牌！我想，跨网络写入一个字节真的会是 O(n^n^n) 的操作吗？（8^8 仅为 16,777,216，所以至少得是 n^n^n）。如果是真的，那就太惊人了！