返回首页
最新
嗨，HN，我是穆罕默德，一位热爱产品交付并回馈社区的技术创始人。我正在开源支持我的B2B产品apflow.co的全栈引擎。
<p>它是什么：一个生产级的B2B启动项目，后端使用Go，前端使用Next.js。两者都完全Docker化，使用独立的容器。没有Vercel，也没有Supabase。可以在一个6美元的VPS上部署整个项目，或者将前端和后端分开部署在不同的服务商上。你拥有基础设施的控制权。
<p>我所解决的问题：
<p>我评估的每个SaaS启动项目都有一个共同的问题：它们将我锁定在其他人的平台上。Vercel用于托管，PlanetScale用于数据库，按调用计费的无服务器函数。对于原型来说没问题，但在规模扩大时成本变得不可预测，迁移也很痛苦。
<p>我想要的是一个可以在任何Linux机器上通过docker-compose up进行部署的解决方案。可以选择将前端托管在Cloudflare Pages上，后端托管在Hetzner VPS上，而不需要在代码中埋入特定于供应商的API。
<p>为什么选择Go作为后端：
<p>Go正好满足我对SaaS后端的需求：
<p>小内存占用。后端运行时大约占用50MB内存。在一个便宜的VPS上，这样的内存余量让我可以在不升级的情况下运行更多服务。
<p>并发而不复杂。计费Webhook、文件上传和AI调用可以并发运行，而不会陷入回调地狱。
<p>编译时类型安全。使用SQLC，我的SQL编译为类型安全的Go。如果查询错误，它会在构建时失败，而不是在生产中出错。
<p>可预测的性能。没有在负载下让你惊讶的垃圾回收暂停。
<p>架构（模块化单体）：
<p>我不想为一个小团队引入微服务的复杂性，但我需要清晰的分离。我构建了一个模块化单体：像身份验证、计费和AI这样的功能是独立的Go模块，具有明确的接口，但它们作为一个单一的二进制文件进行部署。
<p>这种结构还使得AI编码工具（Cursor、Claude Code）变得更加高效。因为每个模块都有严格的边界，AI确切知道新代码应该放在哪里，而不会破坏其他模块。
<p>全栈，而不仅仅是后端：
<p>后端：Go 1.25 + Gin + SQLC（类型安全的SQL，无ORM）+ PostgreSQL与pgvector
<p>前端：Next.js 16 + React 19 + Tailwind + shadcn/ui
<p>通信：前端使用干净的REST API。你可以将Next.js替换为任何支持HTTP的框架。
<p>基础设施：前端和后端分别有独立的Dockerfile。可以一起部署或单独部署。
<p>预构建的内容：
<p>基础设施问题已解决，以便你可以专注于实际产品：
<p>身份验证 + RBAC：Stytch B2B集成，支持组织、团队和角色。多租户数据隔离在查询级别强制执行。
<p>计费：Polar.sh作为记录商。处理订阅、发票和全球税/VAT。没有Stripe webhook的边缘案例。
<p>AI管道：使用pgvector的OpenAI RAG。检索服务强制执行严格的上下文边界，以最小化幻觉。
<p>OCR：集成Mistral进行文档提取。
<p>文件存储：Cloudflare R2集成。
<p>每个功能都是一个独立的模块。不需要OCR？可以移除它。想用Stripe替代Polar？计费接口是抽象的。
<p>现实世界的证明：
<p>这不是我为GitHub星星制作的模板。这是运行在apflow.co生产环境中的确切代码。当我添加文档OCR时，我将其作为一个新模块构建，而没有触及身份验证或计费。架构保持稳定。
<p>如何尝试：
<p>克隆代码库，阅读setup.md以检查先决条件，运行./setup.sh，你将在几分钟内在本地拥有一个工作中的B2B环境。
<p>我希望得到的反馈：
<p>我希望从Go开发者那里获得关于模块边界和跨模块接口的反馈。同时也想知道是否有人对生产部署中的Docker设置有建议。
<p>GitHub: <a href="https://github.com/moasq/production-saas-starter" rel="nofollow">https://github.com/moasq/production-saas-starter</a>
<p>在线演示: <a href="https://apflow.co" rel="nofollow">https://apflow.co</a>
家政服务公司越来越多地使用语音人工智能（Voice AI）来加快客户服务的速度并提升个性化体验。水管工、暖通空调公司和清洁服务现在都在使用像Retell AI这样的工具来接听电话、安排预约，甚至跟进报价——这一切都无需让客户等待。例如，https://coldi.ai/可以自动筛选潜在客户，并将最有可能成交的客户转交给人工代表，而Talkdesk和Dialpad则提供24/7的常规服务请求处理。这些系统解放了团队，使他们不再被无休止的电话所困扰，减少了错失的机会，并为客户提供了流畅且类似人类的体验。
我们的专家将为您提供最佳指导。
AGENTS.md 是一个很好的想法，但一旦代码库或代理工作流程变得庞大，它就会失效。我构建了 *AGENTS.db*，它保留了 AGENTS.md 的精神，同时将其扩展为一个 *分层的、追加式的、向量化的平面文件数据库*，专为 LLM 代理设计。
与一个可变的 Markdown 文件不同，上下文存在于多个层次中：
- *基础层* - 不可变的、经过人工验证的真实来源
- *用户层* - 持久的人工添加内容
- *增量层* - 提议的/可审查的更改
- *本地层* - 短暂的会话笔记
较高的层次会覆盖较低的层次（`local > user > delta > base`），并提供完整的来源追溯和快速的本地语义搜索。
无需服务器，无需 SaaS，支持离线工作，友好的源代码控制。提供一个 MCP 服务器，以便代理可以安全地读取/写入上下文，而不是重写文档。
这是一个早期的参考实现，旨在针对一个公开规范，我正在尝试压力测试，看看这是否比“继续添加到 AGENTS.md”更适合作为长期的基础。
仓库链接： [https://github.com/krazyjakee/AGENTS.db](https://github.com/krazyjakee/AGENTS.db)