最新

我长期以来一直采用 XP/TDD 风格进行工作，因此当 AI 编码工具变得足够实用时，我很快就采用了它们。我遇到的第一个瓶颈不是代码生成，而是验证：AI 可以快速编写代码和测试，但我仍然需要审查实现、点击流程、检查日志、检查数据库状态，并判断结果是否真的正确。 这促使我将验证前移。在实现之前，AI 必须生成测试计划。在实现之后，它也必须执行这些计划：驱动浏览器、检查日志、检查数据库状态、为失败创建工单、修复它们，并重新测试，直到输出收敛。Auth9（[https://github.com/c9r-io/auth9](https://github.com/c9r-io/auth9)）成为了这种方法的试验场。一旦它明显可行，我就开始构建 Agent Orchestrator，这样流程就不再依赖我手动监督每一步。 到二月中旬，我已经开始在 Auth9 内部使用早期的 Orchestrator 风格的自动化。三月中旬，我用它进行了迄今为止风险最高的重构：用原生的 `auth9-oidc` 引擎替换无头 Keycloak 设置。核心替换工作持续了 3 天，并且相同的方法和工具帮助我完成了后续的技术债务，并在月底前完成了社区 OIDC 认证测试。在那时，我开始确信这不仅对新项目有用，而且对管理真实系统中的高风险变更也很有用。 当时，我最关心的是“编排”这个词，这就是该项目得名的原因。后来，OpenAI 的 Harness Engineering 框架为这项工作的更广泛形式提供了更好的名称。该项目今天是一个本地优先的 Rust 控制平面，用于长时间运行的代理工作流程：YAML 资源、SQLite 支持的任务状态、机器可读的 CLI 输出、结构化日志以及围绕基于 shell 的代理的防护措施。 - GitHub: [https://github.com/c9r-io/orchestrator](https://github.com/c9r-io/orchestrator) - 文档: [https://docs.c9r.io](https://docs.c9r.io) - Auth9: [https://github.com/c9r-io/auth9](https://github.com/c9r-io/auth9) - 安装: `brew install c9r-io/tap/orchestrator` 或 `cargo install orchestrator-cli orchestratord` - 许可证: MIT

我们开发 Operator23，是因为看着团队手动在几十个工具之间搭建自动化，说实话，真让人头疼。你用通俗易懂的语言描述你的需求，它就能在 900 多个应用中部署。无需 YAML，无需奇怪的视觉构建器，也不需要集成方面的博士学位。只需告诉它你的需求，剩下的它都会搞定。 我们真正要解决的问题是，如今的自动化过于分散。你的市场团队用一个工具，销售团队用另一个，运维团队还要用三个。把它们连接起来简直是一场噩梦，充斥着自定义脚本和脆弱的集成。Operator23 位于中间，能理解它们所有的语言。你只需专注于你真正想自动化的内容，而不是与 API 和 Webhook 斗争。 我们一直在与自动化团队交流，反馈意见始终一致：他们希望他们的工具能够协同工作，而不用费心。Operator23 就能做到这一点。只需部署一次，就能在你的整个技术栈中实现自动化。说实话，这东西本该几年前就出现了。

我制作了一个表盘，灵感来自平克·弗洛伊德的专辑《月之暗面》。一个棱镜将光线折射成彩虹，用来显示时间。分针是一束光线，彩虹指向小时。 它用 Zig 语言编写，这让我可以针对浏览器（WASM）、树莓派 Zero 2 W 驱动的 13.3 英寸电子墨水屏（作为挂钟）、Pico 2 用于裸机电池供电，最终还有 Pebble Round 2 智能手表。 我用 Claude Code (Opus) 构建它，作为 AI 辅助编码的实验，同时保持对代码的真正掌控。Claude 负责快速迭代，我做架构决策并手动重构。lib/ 中的每一行都经过审查和整理。混合工作流程，而非自动驾驶。 渲染经历了几次迭代。最初使用柯西方程进行物理色散，但为所有 720 种时间组合调整系数是个噩梦，而且有些效果很差。然后我尝试在棱镜内部反射光线，效果更好，但存在丑陋的极端情况。最后我放弃了物理，采用了一条简单的追踪路径，看起来总是很好。360 次提交，学习如何舍弃。