最新

中继架构是一种运行 AI 编码助手的新方法。它不是让一个助手执行你的整个计划直到其性能下降，而是运行一个中继。每个新助手都会阅读完整的计划，从前一个助手那里接收最少量的交接信息，以最佳状态工作，然后将接力棒传递下去。整个团队能够完成单个助手无法持续完成的任务。 它旨在解决的问题是：随着上下文的增加，大型语言模型（LLM）的性能会下降——这是经过测量而非道听途说的（Chroma Research）。目前，每个 AI 编码工具都运行一个从头到尾的单一助手。到了计划的第四阶段，一半的上下文窗口都花在记住已经完成的工作上。我不得不手动重启会话，复制粘贴进度笔记，只是为了保持质量。这根本不是自主开发，而是在“带孩子”。 该架构有四个组成部分：主计划（你的产品需求文档，每个助手都会重新阅读，永远不会在上下文中积累）、接力棒（一个硬性限制为 40 行的交接笔记——这种限制是故意的，臃肿的交接会在下一个助手那里重现上下文腐化）、信号（助手发出的触发短语，以便编排器在不理解代码的情况下进行调度）和上下文预算（实时令牌跟踪，达到阈值时自动交接）。 Tarvos 是 Claude Code 的参考实现。每个会话都在其自己的 git 工作树中运行。接受对你分支的合并，干净地拒绝丢弃。 开源，MIT 许可。现在可用，但存在一些粗糙的细节。

我构建 Parevo Core 是因为我一直在 Go 项目中反复编写相同的身份验证 + 租户 + 权限逻辑。<p>每次都是：JWT 验证、刷新轮换、会话撤销、租户上下文、RBAC 检查、用于 tenant_id 的 SQL 过滤器。相同的模式，不同的代码库。<p>所以我把它提取成一个模块化库。您可以选择您需要的：身份验证、租户、权限、存储、缓存、锁、计费等。每个模块都有接口；您可以插入 MySQL、Postgres、MongoDB 或 Redis。没有框架锁定——适用于 net/http、chi、gin、echo、fiber、GraphQL。<p>包含的内容：<p>身份验证：JWT、OAuth2、SAML、LDAP、API 密钥、WebAuthn、魔术链接 多租户：生命周期、功能标志、SQL 过滤器 权限：RBAC、ABAC、缓存检查 存储适配器：内存、Postgres、MySQL、MongoDB、Redis 额外功能：缓存、锁、健康检查、作业队列、计费、GDPR 导出 我很乐意收到反馈——尤其是在模块边界以及现实世界 SaaS 缺少什么方面。<p>GitHub：<a href="https://github.com/parevo/core" rel="nofollow">https://github.com/parevo/core</a> 文档：<a href="https://parevo.github.io/core/" rel="nofollow">https://parevo.github.io/core/</a>