一周热榜

嗨，HN， 我正在研究用于软件开发的 AI 代理。这些代理会自动启动短暂的应用实例——例如，每个拉取请求、每个任务或每个实验——每个实例都有其自己的临时 URL。 身份验证采用标准方式处理： - OAuth2 / OIDC - 外部身份提供者 - 重定向 URL 必须提前注册并且是静态的 这与短暂应用的特性产生了严重冲突： - URL 是动态且不可预测的 - 重定向 URL 实际上无法提前注册 - 身份验证成为了一个完全自动化工作流中唯一非短暂的部分 我看到团队通常采取的替代方案包括： - 在预览环境中禁用真实身份验证 - 将所有回调路由通过一个稳定的环境 - 使用通配符重定向或代理设置，这些方法感觉像是变通方案 对于 AI 开发代理来说，这尤其尴尬，因为它们假设基础设施是可丢弃的并且完全自动化——没有手动的身份提供者配置参与其中。 所以我很好奇： 1. 如果你使用短暂的预览应用，你是如何处理真实身份验证的？ 2. 是否有适用于动态 URL 的清晰 OAuth/OIDC 模式？ 3. 静态重定向 URL 的假设在这里仍然是正确的模型吗？ 4. 在生产环境中，什么方法实际上有效？ 我在寻找真实的设置和失败故事，而不是理论。

为了使人工智能系统的自动分析、复制和学习变得困难，编程语言应该具备哪些特征？你有什么想法吗？

我想给正在研究小型加密交易平台的朋友们发个安全提醒。 如果你遇到CZR交易所，请务必保持高度警惕。在加密货币领域，一个常见的风险并不是“价格风险”，而是权限风险：一旦你将钱包连接到一个未知的去中心化应用（dApp）或将资产发送到一个未验证的地址，你可能无法找回任何东西。 以下是一些适用于此处（以及任何地方）的基本安全步骤： - 不要将你的钱包连接到无法独立验证的网站。 - 不要仅仅因为某个页面或支持账号告诉你，就向平台发送USDT/BTC。 - 将“即时提现”、“限时验证”或“紧急存款以解锁资金”视为重大警告信号。 - 在测试任何新服务时，使用一个新的钱包/最少的资金，并撤销你不认识的授权。 - 如果有人有可验证的证据（交易哈希、存档页面、签名消息、带时间戳的清晰截图），请分享。如果没有，请保持客观，避免猜测。

有时候我被困在Windows上，只能在WSL中使用Claude Code。一直检查官方应用程序真让人烦。感谢Claude Code。<p>直接在Windows中安装Claude Code是无法使用的。<p>这是macOS应用程序的移植版 <a href="https://github.com/richhickson/claudecodeusage" rel="nofollow">https://github.com/richhickson/claudecodeusage</a>