最新

事情的起因是我用代码写了一个吉他音阶指法生成器。效果还不错，我就开始往里面加东西：和弦，然后是和弦与音阶的相互关系。<p>后来我又加入了其他我玩的一些乐器的图表：钢琴、大提琴、中音竖笛。<p>里面有一个复杂程度切换功能，可以从基础和声切换到扩展/实验性的内容。<p>说实话，这玩意儿现在还主要是个玩具，但我认为其他人可能也会对它感兴趣。源代码在github上，所以很容易在本地运行和fork。<p><a href="https://github.com/aleshh/gtr-scales" rel="nofollow">https://github.com/aleshh/gtr-scales</a>

众所周知，现在的文档需要针对 AI 代理进行优化——我们都在用 Claude Code / Codex / Pi 代理来处理文档，并期望模型能够弄清楚如何实现一个产品。 然而，当编写文档时，这改变了整个优化问题。好的文档现在变得更加客观——你正在解决一个非常具体的问题：一个运行着最简单的模型的“傻瓜”工具能否可靠地实现这个产品？ 人类通常可以弥补术语不一致或页面间上下文分散的问题，但对于代理来说，这通常会浪费时间（甚至完全混淆代理）。 我们一直在围绕这个主题构建一个小项目，名为 dari-docs：用户可以通过网站或 CLI 上传他们的文档，并在不同的提供商上运行代理，以查看它们在哪里出错。你可以上传你的文档，提供一个任务列表，并要求具有不同智能/成本水平的代理并行完成这些任务。当运行完成后，你会收到来自每个代理运行的反馈 markdown 文件列表，并可以根据代理的反馈应用更改。 托管服务：[https://optimize.dari.dev/](https://optimize.dari.dev/)，代码库链接：[https://github.com/mupt-ai/dari-docs](https://github.com/mupt-ai/dari-docs) 这些代理实际上会尝试端到端地使用产品。它们搜索文档，遵循说明，运行命令，尝试示例，并尝试调试失败。重要的是，这不仅仅是对文档的静态 LLM 审查。这些代理实际上是在尝试集成。 你还可以使用测试凭据启用实时验证，以便代理可以根据真实的 API 验证工作流程： ``` dari-docs check . --live-verify --secret-env DARI_TEST_API_KEY --task "创建结账会话" ``` 如果你正在构建 CLI、API、MCP 服务器或 SDK，并且积极地为人类或代理维护文档，我们很乐意与你合作并在真实的工作流程上进行测试！

https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage 每次读到类似这样的文章，我都会对云服务提供商和谷歌感到担忧。考虑到这是一个相对高知名度的客户，他们难道不应该解释一下导致他们暂停账户的原因吗？