我们注意到越来越多的开发者在他们的 GraphQL 工作流程中直接使用 AI 编码助手。问题在于，这些助手往往会回归到通用或过时的 GraphQL 模式。
在不断纠正同样的问题后，我们最终将希望助手遵循的 GraphQL 最佳实践和规范打包成可重用的“技能”，并在这里开源发布：<a href="https://github.com/apollographql/skills" rel="nofollow">https://github.com/apollographql/skills</a>
通过 `npx skills add apollographql/skills` 安装后，助手将开始生成带有变量的命名操作、`[Post!]!` 列表模式，以及更一致的客户端行为，而无需在每个提示中重复这些规则。
我们希望助手现在能够以我们自己编写的方式来编写 GraphQL。欢迎试用这个仓库，并告诉我们您的想法。
返回首页
最新
在发现大多数AI代码审查工具完全忽略Bitbucket后，我感到非常沮丧——它们都是优先支持GitHub，其次是GitLab，最后才是Bitbucket。
这个工具使用Claude CLI而不是API，这意味着没有按令牌收费（只需使用您现有的Claude订阅）。该工具接收Bitbucket的webhook，克隆本地仓库，并直接在PR上发布审查评论。
主要特点：
<p>支持Bitbucket Cloud、Server和Data Center
按顺序处理PR，并提供Prometheus指标
可定制的审查模板（专注于安全、性能、快速审查）
您的代码始终保留在您的基础设施内
<p>设置过程大约需要5分钟，使用交互式向导。
GitHub: <a href="https://github.com/TinTinWinata/bitbucket-automatic-pr-reviewer" rel="nofollow">https://github.com/TinTinWinata/bitbucket-automatic-pr-reviewer</a>
我很好奇其他人是如何处理这个问题的：我在某些任务中使用Claude，编程时用Cursor，研究时用ChatGPT，快速查找时用Perplexity。<p>问题是它们之间并不知道我与其他工具讨论过的内容。<p>我发现自己不得不反复重新解释相同的背景，或者从Notion文档中复制粘贴。<p>对于那些大量使用AI工具的朋友们：<p>- 你们是如何管理不同工具之间的共享上下文的？<p>- 你们目前的工作流程是怎样的，以保持AI的“记忆”一致？<p>- 你们找到过什么有效的解决方案吗？<p>特别希望听到那些需要多个人在不同AI会话中访问相同知识库的团队的经验。
我看到的许多用户界面问题并不是视觉上的问题，而是对用户的未经过检验的假设。<p>我开发了一个小工具，可以捕捉用户界面的截图，并将这些假设明确列出，同时指出错误的风险。<p>这个工具旨在作为发布前的快速设计预评估或批评。<p>希望能得到反馈，看看这种批评用户界面的方法是否真的有用。
我一直在使用 cron，但每个现代替代品都让我在仪表盘上点击或写 50 行 YAML。因此，我构建了 crnd（发音为“crowned”）——这只是一个命令行工具，按照你的指令执行。
主要特点：没有提示，没有交互式向导。只有可以在脚本中运行的命令。
`crnd schedule -n backup -s "0 2 * * *" -- rsync -a ~/docs ~/backup`
就这样。任务保存在一个热重载的 toml 文件中。守护进程作为一个真实的操作系统进程运行，而不是某种容器抽象。
还支持一次性调度任务，这是 cron 无法做到的：
`crnd schedule -n reminder -i 5m -- say "stretch break"`
主要是因为我在使用 AI 编码代理，而它们总是无法处理交互式提示。现在它们可以直接解析 --json 输出并调度任务。
没有云，没有 Docker，没有账户。只有一个单一的二进制文件。
<a href="https://github.com/ysm-dev/crnd" rel="nofollow">https://github.com/ysm-dev/crnd</a>
非常希望得到反馈，特别是如果你正在使用脚本或代理自动化某些事情。
我想探索GPU光线追踪技术，因此我制作了一个免费的棋盘，仿佛在现实生活中的咖啡馆里下棋。<p>目标是实现棋局的真实感（OTB）。这是一个基于物理的沙盒环境，您可以手动拖动棋子，移动车以进行王车易位，并自己清除被吃掉的棋子。您甚至可以将棋子撞倒。这个想法最初来自我的朋友Drew Olbrich（lunarskydiving.com），他在90年代于PDI制作了一个基于SGI的版本。<p>我在PDI/DreamWorks和NVIDIA工作了三十年，编写渲染代码。我从零开始在WebGPU中编写了渲染管线。默认情况下，它使用优化的光栅化“快速路径”，但如果您有一块好的GPU，可以在设置中启用实时路径追踪。我使用了4层深度剥离的G-Buffer和层次化Z-Buffer DDA进行光线行进，支持多次反射全局光照和环境贴图重要性采样。<p>场景完全由单个HDRI环境贴图照明，没有局部光源。由于我是一名程序员，而不是灯光艺术家，我已将所有材质设置暴露出来，供您调整和分享。<p>对于多人游戏，我使用了WebRTC（通过PeerJS）来避免中心服务器延迟。该应用程序与Lichess.org集成，可以挑战您现有的朋友，或者您可以与本地的Stockfish网络工作者对弈。每个客户端运行自己的刚体模拟，以保持物理响应性，同时逻辑游戏状态保持同步。<p>该应用程序需要WebGPU（Chrome 113+、Edge 113+或Safari 17.4+）。已在最新的Windows、MacOS、iOS和Android上进行了测试。如果您的网络连接较慢，加载图形资源可能需要几秒钟。<p>我很想听听您在硬件上的性能表现如何，以及对未来功能的建议，比如添加折射、允许观众或注释等？