我正在独自构建一个拥有 3 万行代码的 V12 项目，我的“团队”由 4 个 AI 组成。
5 分•作者: garylauchina•6 个月前
我是一名独立开发者，正在开发一个“复杂系统测量”项目，该项目已经增长到超过 3 万行代码，目前版本为 V12。到目前为止，每一行代码都是由我一个人编写的，研究笔记和设计文档放在一个单独的仓库中：https://github.com/Garylauchina/Prometheus-Research。
在开发过程中，我一直在大量使用 Cursor。这些模型确实很好，它们生成的本地代码通常也很出色，但在一个大型、不断演进的代码库中，我一直遇到同样的问题：上下文限制导致了微妙的架构漂移。AI 会编写干净的函数，但这些函数在全局上是错误的，它们悄悄地破坏了之前的设计决策和长期不变性。
最终有所帮助的是，我不再将“AI”视为一个单一的助手，而是将不同的模型视为具有明确角色和约束的不同团队成员。
我目前的设置如下：
Perplexity + ChatGPT → “产品/研究大脑”
我用它们来处理需求、权衡和高层次的架构草图。它们位于 IDE 之外，用于在编写任何代码之前，明确我正在构建什么以及为什么构建。
Cursor，窗口 1 (GPT-5.2) → “架构师”
这个实例不允许编写生产代码。它负责架构和模块边界、编写设计笔记和开发者指南、定义接口和契约以及审查差异。我把它当作一位高级工程师，其主要输出是散文：迷你 RFC、注释和检查清单。
Cursor，窗口 2 (Sonnet 4.5) → “程序员”
这个实例只实现由架构师描述的任务：特定的文件、函数和重构，遵循明确的书面指令和风格规则。它不能重新设计系统；它只是编写代码。
关键规则是：架构师总是先行动。每个非平凡的更改都从文本开始（设计笔记、约束、示例），然后“程序员”实例将这些文本转化为代码。
这种简单的分离解决了我在使用单一、全能助手时遇到的很多奇怪问题。逻辑漂移少了很多，因为全局结构在自然语言中被反复重申。程序员只看到在那个结构内框架化的本地任务，因此它更难发明新的意外架构。尽管代码库有数万行，但它感觉比之前的、更小的迭代更连贯。
这也改变了我对 Cursor 的看法。我之前很多“Cursor 很笨”的时刻，结果证明是工作流程问题：我要求一个代理，在严格的上下文限制下，同时记住架构、需求和低级实现。一旦我将这些责任分配给不同的模型，并强制所有内容都通过书面指令，相同的工具开始看起来更有能力。
这既不是 Cursor 的广告，也不是对 Cursor 的反驳。这只是一种通过将这些工具视为一个小团队而不是一个神奇的结对编程者，来使它们在一个大型独立项目上工作的方法。
这种设置的一个缺点是：按照我目前的速度，Cursor 愉快地向我收取每天大约 100 美元的费用。如果 Cursor 的任何人正在阅读这篇文章——是否有我错过的“独立开发者构建荒谬大型系统”的折扣套餐？
查看原文
I’m a solo developer working on a “complex systems measurement” project that has grown to over 30k lines of code and is now at V12. Every line so far has been written by one person (me), with the research notes and design docs in a separate repo: https://github.com/Garylauchina/Prometheus-Research.<p>I’ve been using Cursor heavily along the way. The models are genuinely good and the local code they generate is often excellent, but on a large, evolving codebase I kept running into the same problem: context limits caused subtle architectural drift. The AI would write clean functions that were globally wrong, quietly breaking earlier design decisions and long‑range invariants.<p>What finally helped was to stop treating “AI” as a single assistant and instead treat different models as different team members with clear roles and constraints.<p>My current setup looks like this:<p>Perplexity + ChatGPT → “product / research brains”
I use them for requirements, trade‑offs, and high‑level architecture sketches. They live outside the IDE and exist to clarify what I’m building and why before any code is touched.<p>Cursor, window 1 (GPT‑5.2) → “architect”
This instance is not allowed to write production code. It is responsible for architecture and module boundaries, writing design notes and developer guides, defining interfaces and contracts, and reviewing diffs. I treat it like a senior engineer whose main output is prose: mini‑RFCs, comments, and checklists.<p>Cursor, window 2 (Sonnet 4.5) → “programmer”
This one only implements tasks described by the architect: specific files, functions, and refactors, following explicit written instructions and style rules. It doesn’t get to redesign the system; it just writes the code.<p>The key rule is: architect always goes first. Every non‑trivial change starts as text (design notes, constraints, examples), then the “programmer” instance turns that into code.<p>This simple separation fixed a lot of the weirdness I was seeing with a single, all‑purpose assistant. There is much less logical drift, because the global structure is repeatedly restated in natural language. The programmer only ever sees local tasks framed inside that structure, so it’s harder for it to invent a new accidental architecture. The codebase, despite being tens of thousands of lines, feels more coherent than earlier, smaller iterations.<p>It also changed how I think about Cursor. Many of my earlier “Cursor is dumb” moments turned out to be workflow problems: I was asking one agent, under tight context limits, to remember architecture, requirements, and low‑level implementation all at once. Once I split those responsibilities across different models and forced everything through written instructions, the same tools started to look a lot more capable.<p>This isn’t a Cursor ad, and it’s not an anti‑Cursor rant either. It’s just one way to make these tools work on a large solo project by treating them like a small team instead of a single magical pair‑programmer.<p>One downside of this setup: at my current pace, Cursor is happily charging me something like $100 a day. If anyone from Cursor is reading this – is there a “solo dev building absurdly large systems” discount tier I’m missing?