最新

自从 vibe 编码问世以来，我一直在尝试构建各种产品。我的一些产品面向消费者，而另一些则是昂贵软件的内部克隆。然而，从一开始我就知道一件重要的事情——vibe 技术栈的成本很高。 我最初尝试了很多工具——Bolt、v0、Replit、Lovable 等，其中 Replit 给我的结果最好（是的，我可能因为选择的应用而有偏见）。但我经常每月支付 25 到 200 美元的费用。其他费用，比如 API、模型等，使得每月账单超过 300 美元。与雇佣开发者相比，这样的成本是否划算？是的。但是否物有所值？不。 因此，经过几个月的优化，我将整个技术栈调整为内部使用时要么免费（或成本极低），要么在面向消费者的产品中保持较低的成本。 以下是目前整个技术栈的情况： - IDE - 谷歌的 AntiGravity（100% 免费，如果使用学生证可以获得更高的访问权限） - AI 文档 - SuperDocs（100% 免费且开源） - 数据库 - Supabase（Nano 计划免费，足够满足基本需求） - 认证 - Stack Auth（免费至 1 万用户） - LLM（AI 模型） - OpenRouter 或 Gemini 通过 AI Studio 进行测试，以及 Unsloth AI 提供的定制调优模型用于生产（你可以在 Google Colab Notebook 中使用 Unsloth 进行模型微调） - 版本维护/分发 - Github/Gitlab（两者均完全免费且开源） - 更快的部署 - Vercel（免费套餐足够供爱好者使用） - 分析 - PostHog、Microsoft Clarity 和 Google Analytics（这三者都是免费的，适用于不同的跟踪，我建议同时使用它们） 这就是开发者们的清单！我知道我可能遗漏了一些内容。如果有，请随时问我或在评论中列出。如果你有任何具体问题，也可以问我。

受到tsoding最近视频的启发，我想在终端的限制下探索3D渲染的极限。<p>该项目使用Odin构建，没有使用任何外部库。

我是一名独立开发者，正在进行一个“复杂系统测量”的项目，该项目已经发展到超过3万行代码，目前处于第12个版本。到目前为止，所有代码都是由我一个人编写的，研究笔记和设计文档存放在一个单独的代码库中：https://github.com/Garylauchina/Prometheus-Research。 在这个过程中，我大量使用了Cursor。它生成的模型确实很好，生成的本地代码通常也很优秀，但在一个大型、不断演变的代码库中，我不断遇到同样的问题：上下文限制导致了微妙的架构漂移。人工智能会编写出干净的函数，但在全局上是错误的，悄悄地破坏了早期的设计决策和长期的不变性。 最终帮助我解决这个问题的是停止将“人工智能”视为一个单一的助手，而是将不同的模型视为不同的团队成员，各自有明确的角色和约束。 我目前的设置如下： Perplexity + ChatGPT → “产品/研究大脑” 我用它们来处理需求、权衡和高层架构草图。它们存在于IDE之外，旨在在任何代码被触及之前，澄清我正在构建的内容和原因。 Cursor，窗口1（GPT-5.2）→ “架构师” 这个实例不允许编写生产代码。它负责架构和模块边界，撰写设计笔记和开发者指南，定义接口和合同，并审查差异。我把它当作一名高级工程师，其主要输出是文档：小型RFC、评论和清单。 Cursor，窗口2（Sonnet 4.5）→ “程序员” 这个实例只实现架构师描述的任务：特定的文件、函数和重构，遵循明确的书面指令和风格规则。它不负责重新设计系统；它只负责编写代码。 关键规则是：架构师总是优先。每一个非平凡的变更都以文本形式开始（设计笔记、约束、示例），然后“程序员”实例将其转化为代码。 这种简单的分离解决了我在使用单一通用助手时遇到的许多奇怪问题。逻辑漂移大大减少，因为全局结构在自然语言中反复重申。程序员只看到框架内的本地任务，因此更难以创造出新的意外架构。尽管代码库有数万行，但相比之前较小的迭代，它感觉更加连贯。 这也改变了我对Cursor的看法。许多我之前认为“Cursor很笨”的时刻，实际上是工作流程的问题：我在紧张的上下文限制下，要求一个代理同时记住架构、需求和低级实现。一旦我将这些责任分配到不同的模型中，并通过书面指令强制执行，这些工具开始显得更有能力。 这不是一则Cursor广告，也不是反对Cursor的抱怨。这只是通过将这些工具视为一个小团队而不是一个单一的神奇配对程序员，来使它们在大型独立项目中发挥作用的一种方式。 这种设置的一个缺点是：以我目前的进度，Cursor每天愉快地向我收费大约100美元。如果有Cursor的工作人员在看这个——是否有我错过的“独立开发者构建异常庞大系统”的折扣层级？

嗨，HN， 我不是专业开发者，但我一直对“人类熵”的概念充满热情。随着量子计算的兴起，我开始思考：我们能否创造出一种随机序列，使得任何机器都无法预测，因为它的来源是人类行为的不可预测性？ 我使用Flutter和Firebase构建了这个网络应用。这个想法很简单：用户在网页客户端上执行操作，这些独特的交互哈希会被发送到一个安全的Firestore池中。然后，一个服务器端的云函数（对客户端隐藏）每天将这些哈希连接起来，生成一个庞大且非确定性的随机字符串。 关键安全措施： - 应用检查：防止机器人驱动的熵。 - 单向写入：用户只能向池中追加数据，无法读取或修改现有数据。 - 隐藏逻辑：实际的连接过程发生在云端，因此核心逻辑不会在前端暴露。 这个项目仍在进行中，目前由一个15人的小社区支持。我非常希望能听到你们对逻辑的反馈，更重要的是，希望你们能向这个池中贡献你们自己的“熵”。 网址：https://entropygrid.net 期待进行一次严肃但诚实的技术讨论！