architect-loop GitHub 仓库 是一个“AI架构师 + AI程序员”的协作框架。
它把不同模型拆成两种角色：
- Claude Fable：负责规划、拆解任务、评审结果
- GPT-5.5 Codex：负责写代码、查资料、执行任务
核心思想很简单：“让擅长思考的模型负责设计，让擅长执行的模型负责干活。”
Agent Loop（智能体循环）。
传统模式：
用户 |
Architect Loop：
用户 |
architect-loop是一套工地管理制度。Claude当设计师坐在办公室画图纸，GPT当工人在现场搬砖，Git仓库当监理日记。设计师不许碰砖，工人不许改图纸，所有事都得写进日记。就这么三条规矩，解决了AI干活最常见的“自己推翻自己”的毛病。
方法很简单：把设计和执行拆开。
让一个人专门负责想，让另一个人专门负责干。
想的那个不能动手，动手的那个不能乱想。
这个architect-loop就是这么干的。它把AI分成两拨。
一拨叫Architect，用的是Claude，负责想清楚要做什么，怎么写规格说明书，怎么验收成果。
另一拨叫Builder，用的是GPT，负责写代码，查资料，把Architect想好的东西实现出来。
Architect不许写代码，Builder不许改设计图。两边各干各的，互相不捣乱。
实际跑一遍流程你就懂了
我们来模拟一个真实场景。假设你要做一个计算器，能加能减能乘能除。你用architect-loop的流程会是这样。
第一步，你告诉Architect你的需求。你说“我要一个计算器，网页版，有数字按钮，有加减乘除按钮，有个显示屏”。Architect听了以后，去写Spec。它写的Spec大概长这样：“计算器应有0-9数字按钮，加减乘除四个运算按钮，等号按钮，清除按钮。显示屏初始显示0。按数字按钮时，显示屏追加数字。按运算按钮时，记住当前数字和运算符。按等号时，计算结果并显示。除数为0时，显示错误信息。”
第二步，Architect写Gate。Gate里写：“代码必须通过ESLint检查。所有函数必须有JSDoc注释。单元测试覆盖率80%以上。提交前必须格式化代码。不能有console.log。不能有未使用的变量。”
第三步，Architect拆任务。它把计算器拆成三个小任务：任务一是写HTML结构和CSS样式，任务二是写前端交互逻辑，任务三是写单元测试。每个任务都分配了一个Builder。
第四步，三个Builder同时启动。每个Builder都拿到了自己那份任务的Spec和Gate，还有整体的Gate。Builder一号开始写HTML和CSS，它照着Spec里的要求，写了一堆按钮和一个显示屏。Builder二号开始写JavaScript逻辑，它写了数字按钮的点击事件，运算符的点击事件，还有计算函数。Builder三号开始写单元测试，它写了各种情况下的测试用例，比如1+1=2，5-3=2，6/2=3，还有除数为0的情况。
第五步，三个Builder都写完了，各自提交了代码。Architect开始审核。它先看Builder一号的代码，发现HTML结构没问题，CSS样式也符合要求，就是有一个按钮的颜色跟Spec不一致。Spec说等号按钮用绿色，Builder一号用了蓝色。Architect打回去让改。Builder一号改了颜色，重新提交。Architect再看，没问题了。然后Architect看Builder二号的代码，发现计算函数没有处理小数点，Spec里没写小数点的事情，但Architect觉得计算器应该支持小数点。Architect就在Spec里加了一条“支持小数点输入”，然后让Builder二号加小数点功能。Builder二号加了以后，Architect再看，没问题了。最后Architect看Builder三号的测试，发现覆盖率只有60%，Gate要求80%。Builder三号又加了几个测试，覆盖率到了85%。Architect通过。
第六步，所有代码审核通过，Architect把它们合并到一起。计算器做好了。你打开网页，看到一个绿色的等号按钮，支持小数点，除法不会崩溃，单元测试全过。整个过程Architect没有写一行代码，Builder没有改一次设计，仓库里留下了所有的Spec、Gate、代码、测试。三个月后你想加一个开平方的功能，打开仓库，看看当年的Spec和Gate，就知道怎么改了。
为什么这套方法最近特别火
最近AI编程工具越来越多，大家发现一个AI写代码不够用了。不是说一个AI能力不行，而是一个AI的注意力有限。你让它写一个一千行的程序，它写到后面已经忘了前面。你让它同时做好几件事，它就会在不同的事情之间跳来跳去，每件都做不好。这就好比让你同时做数学题、写作文、背单词，你肯定也做不好。不是因为你笨，是因为人的注意力只能集中在一件事上。AI也是。
architect-loop火了，是因为它提供了一个思路：不要指望一个AI干所有事，而是让多个AI各干各的，互相配合。这个思路其实在软件工程里很常见。一个大型软件项目，不可能让一个人写所有的代码。一定是分模块，分团队，分阶段。有架构师，有开发工程师，有测试工程师，有项目经理。architect-loop就是把这套管理方法搬到了AI身上。
还有一个原因：现在AI模型越来越多了，每个模型有自己的特长。Claude擅长规划和推理，GPT擅长写代码，Gemini擅长处理长文档。如果你只用其中一个模型，就浪费了其他模型的优势。architect-loop允许你混着用。你可以让Claude当Architect，让GPT当Builder，让别的模型当测试。每个模型都做自己最擅长的事，整体效率就会提高。
另外，architect-loop解决了一个很实际的问题：AI代码的可维护性。以前AI写的代码，你能跑通就不错了，根本不敢改。因为你不知道AI为什么那样写，里面有什么隐含的逻辑。现在有了Spec和Gate，你知道每个功能是为什么做的，每个约束是怎么来的。你想改一个功能，先改Spec，然后让Builder照着新Spec改代码。改完了Architect审核。整个过程是可控的，可追溯的，可重复的。这才是工程化的思路，不是碰运气。
建筑师和工人凭什么不能吵起来
architect-loop这个项目想明白了一件事。
它把AI分成了两个角色，一个叫Architect，一个叫Builder。翻译成人话就是一个是建筑师，一个是建筑工人。
建筑师的任务是什么？是坐在办公室里画图纸，想清楚这栋楼到底要盖成什么样。地基要挖多深，承重墙放哪里，水电怎么走，这些都是建筑师的事。建筑师不用去搬砖，不用去和水泥，他只需要把图纸画清楚。
建筑工人的任务是什么？是照着图纸干活。图纸上写挖两米深的坑，他就挖两米，不多不少。图纸上写用红砖，他就不用青砖。工人不用去想这堵墙为什么要放这里，这跟他没关系，他只需要按图纸施工。
建筑师和工人之间还有个监理。监理负责检查工人干的活有没有按照图纸来。要是工人自己改了一下图纸，监理就拦住，说你不能这么干，回去重做。
architect-loop里面用的具体AI模型是，建筑师角色用的是Claude Fable，工人角色用的是GPT-5.5 Codex。为啥这么分？因为Claude这个模型擅长思考、擅长拆解任务、擅长评审结果。GPT那个模型擅长写代码、擅长查资料、擅长执行具体操作。
这就好比一个大学里学建筑设计的，你去让他砌墙，他可能砌得歪歪扭扭。但是你让他设计一个商场，他能给你画出很漂亮的设计图。另一个是工地上的老师傅，你让他画设计图他画不出来，但是你说砌这道墙，他能砌得又快又直。
那你就让学设计的坐办公室画图，让老师傅在现场干活。别让学设计的去砌墙，也别让老师傅去画图。大家都做自己擅长的事，事情就能做成。
architect-loop就是干了这么一件事。它把“思考”和“干活”彻底分开了。负责思考的模型不许干活，负责干活的模型不许思考。听起来特别简单对吧？但是你想想，人类管个工地不也是这么管的吗？但是到了AI这里，大家就突然忘了这个道理了。
工人要是能随便改图纸会出什么乱子
architect-loop的仓库作者在文档里反复强调一个事情，Gate文件是只读的，Builder不能修改Gate。啥意思呢？Gate你可以理解为一张验收清单，就是建筑师定好的那些标准，必须满足了这些标准，代码才能被合并进去。
比如说建筑师定了一条Gate：登录功能的密码必须加密存储。那工人写代码的时候，不管用什么方法，必须把密码加密了。工人不能自己把这条Gate改成“密码可以不加密”，他没这个权限。工人也没有直接提交代码的权限，他写完代码之后，得让建筑师重新审核一遍，建筑师说没问题了，才能把代码合并进去。
这个设计特别关键。你想想，要是工人能自己改验收标准，那会变成什么样？
你让工人给你盖个车棚。你说车棚高度至少要两米五，不然卡车进不去。工人说好的。干着干着工人觉得两米五太高了，爬上去修屋顶不方便，他自己就把高度改成了一米八。等车棚盖好了，你的卡车开不进去。工人说我觉得一米八够用了啊，你要不要换个矮一点的卡车。
你说这不是胡闹吗。但是AI编程里面这种事天天都在发生。你让AI写一个函数，要求输入必须是数字。AI写着写着觉得字符串也行，就自己把要求改了。最后你的程序跑起来就报错，你问AI怎么回事，AI说我帮你优化了一下。
architect-loop就是不让AI自己优化，不许改标准。工人觉得标准不合理怎么办？他不能自己改，他得回去找建筑师商量。建筑师说行那我改一下标准，工人才能照着新标准干活。这就跟真的工地上一样，工人发现图纸有问题，得找设计师改图，不能自己拿笔在图纸上画两下就算改了。
聊天记录不算数文档才算数
architect-loop还有一个很反常识的设计。它说仓库才是记忆，不是聊天记录。什么意思呢？很多AI编程工具喜欢把聊天记录当记忆，你跟AI聊了什么，它都记着。你今天说我要做个红色的按钮，明天说算了改蓝色的吧，后天又说还是红色的好看。AI把这些全都记在它的上下文里面，上下文越来越长，长到好几十页。AI翻着这几十页的聊天记录，自己也搞不清楚你最终到底要红色还是蓝色了。
architect-loop不一样。它说所有重要的东西都得写进仓库里。仓库就是指你的Git仓库，就是代码放的那个地方。项目状态只存在三个地方，docs文件夹里面的交接文档，docs下面的gates文件夹里面的验收标准，还有docs下面的lanes文件夹里面的任务分解。Git的历史记录也算，因为你能看到每次改动是谁干的。
仓库作者说了句特别狠的话，没写进仓库，就等于没发生。你对着AI说了什么话，不重要。你在聊天框里打字，不重要。只有写进docs文件夹里面的那些文件，才算数。
这就像你在公司上班。你跟同事口头说了一句，明天开会啊。同事嗯了一声。第二天你问同事怎么没来开会，同事说我忘了啊。你说我昨天明明跟你说了，同事说你说啥了我不记得了。但是你要是发了封邮件，抄送给全组，说明天下午两点开会。同事就算忘了，你也能翻出邮件给他看。
仓库里面的文档就是这个邮件。聊天记录就是那个口头说话。口头说话太容易忘了，也太容易搞混了。architect-loop索性就不信聊天记录，只信仓库里的文档。
每次工人开始干活之前，都得先去仓库里面看一遍最新的文档。建筑师改了什么要求，加了什么验收标准，全都写在文档里。工人按照文档干活，干完了把代码提交上去。建筑师再去看代码，检查是不是符合文档。这个过程里，没人需要去翻聊天记录，也没人需要回忆昨天说过什么话。
这就解决了一个特别烦人的问题。以前你用AI写代码，写着写着AI突然问你，你上周说的那个功能还要不要了。你说哪个功能，AI说就是上周三下午三点你说想加的那个。你说我都忘了我说过这个了，AI说那你是要还是不要。你心想我怎么知道我到底要不要，我都想不起来我说了什么了。
architect-loop不让你受这个折磨。你要什么功能，写进文档里。不要什么功能，也从文档里删掉。AI只认文档，不认你的嘴。
每次干活都当第一回干能省很多事
architect-loop还有一个设计是，每次工人启动的时候，都是全新的上下文。工人不记得上次干了什么，也不记得上上次干了什么。它每次都是从头开始读文档，然后根据文档写代码。
你可能会觉得这很笨啊，每次都从头开始，多浪费啊。但是仓库作者的想法是，长上下文容易污染决策。啥叫污染决策？就是AI记得太多东西之后，反而不知道怎么干活了。
你想想，一个AI之前写过一百个项目的代码。这一百个项目里面，有的用了MySQL数据库，有的用了PostgreSQL，有的用了MongoDB。现在你让它写一个新项目，它脑子里装着这一百种做法，它得从里面挑一个。它挑的时候，可能挑了一个最复杂的，因为它觉得复杂的就是高级的。也可能挑了一个它最熟悉的，但其实不适合你这个项目。
如果每次都是全新上下文，AI脑子里就只有当前项目文档里写的东西。文档里说用MySQL，它就用MySQL。文档里说表要建哪几个字段，它就建那几个字段。它不会突然想起以前有个项目用了什么特别花哨的写法，然后抄过来。
建筑师负责审核，也就是负责那个需要长记忆的角色。建筑师记得整个项目的来龙去脉，知道为什么要这么设计，知道之前改过哪些地方。工人不需要记得这些，工人只需要执行。
这就跟流水线上的工人一样。你今天在流水线上拧螺丝，你不需要知道这个螺丝是怎么设计出来的，不需要知道这个产品要卖给谁，你只需要照着作业指导书把螺丝拧紧。明天换了个产品，作业指导书换了，你就照新的拧。你不记得昨天那个产品怎么拧的没关系，因为那是昨天的事。
architect-loop里面，建筑师是那个有长期记忆的角色，它知道项目的完整历史。工人是那个没记忆的角色，它只知道当前文档。这两个角色互相隔离，建筑师不能跑去写代码，工人不能跑来改设计。隔离的好处是，建筑师不会被代码的细节带偏，工人不会被设计的历史搞糊涂。
研究新东西的时候可以派一堆人出去打听
architect-loop提供了两个主要命令。
一个是/architect，用来开发功能，就是我们刚才说的建筑师画图工人干活那一套。
另一个是/architect-research，这个是用在研究任务上的。
啥叫研究任务？就是你不确定怎么做，需要先去调研一下。比如你想知道现在市面上哪个数据库最快，或者想比较一下几个AI模型的优缺点，或者想读一篇论文看看里面讲了什么。这些事不是写代码，是收集信息然后得出结论。
/architect-research的流程是，先让工人做侦察。工人去网上搜资料，去读文档，去把能找到的相关信息都扒拉回来。然后建筑师根据这些初步信息，设计一个研究路线。比如说我们得从哪几个方面去比较数据库，要测试哪些指标，要找哪些类型的资料。
然后建筑师派好几个工人并行出去干活。一个工人负责测MySQL的性能，一个工人负责测PostgreSQL的性能，一个工人负责测MongoDB的性能。他们同时干活，互不干扰。等他们都回来了，把数据交给建筑师。建筑师验证这些数据有没有问题，证据是不是可靠，然后写最终的研究报告。
这个设计也很聪明。资料收集这种事完全可以并行，因为一个人找资料和十个人找资料，速度能差十倍。但是结论生成这种事就不能并行，因为十个人写出十份不同的结论，你该信谁的。所以结论必须由一个角色集中完成。
就像你要写一篇关于全球气候变化的论文。你不能派一个研究生去搜集全世界的资料，那得搜集到什么时候。你应该派十个研究生，一个去查北极的数据，一个去查南极的数据，一个去查海洋的数据，一个去查森林的数据。等他们都查回来了，你把所有数据汇总，自己写论文。你不能让十个研究生各自写一篇论文出来，那样你会收到十篇观点不同的论文，你反而更糊涂了。
/architect-research就是这样，多个工人负责找资料，一个建筑师负责写报告。找资料可以大家一起找，写报告必须一个人写。
用之前先想清楚三件事
如果你想用architect-loop，有三件事要想清楚。
第一，你的项目值不值得花时间搭这套流程。architect-loop不是开箱即用的。你需要配置Claude和GPT的接口，需要写初始的Spec和Gate，需要设计任务的拆分方式。这些准备工作可能要花几个小时甚至几天。如果你只是写一个一百行的小工具，这几个小时够你手写十遍了。只有项目够大，够复杂，需要长期维护，这套流程的成本才值得。
第二，你的任务适不适合拆分成独立的小任务。architect-loop的效率来自于并行。多个Builder同时干活，速度就快了。但如果你的任务是高度耦合的，任务A必须等任务B做完才能做，那就没法并行。比如你要写一个算法，逻辑是一环扣一环的，拆开了反而更慢。这时候用architect-loop可能比用一个AI更慢，因为多了很多管理的开销。
第三，你能不能接受AI之间的沟通成本。Architect和Builder之间不是直接说话的，它们通过Spec、Gate、Review这些文档来沟通。写文档要时间，读文档要时间，审核文档要时间。这些时间加起来可能比让一个AI自己琢磨还长。但是这些时间花得值不值，取决于你的项目需要多高的质量。如果你只要代码能跑就行，那这些管理步骤就是多余的。如果你要代码干净、健壮、好维护，那这些步骤就是必要的。
最后的总结
architect-loop的本质，就是把AI编程从“一个人的战斗”变成“一个团队的协作”。它不再指望一个AI什么都会什么都记住，而是让不同的AI做不同的事，通过文档和规则来协调彼此。它借鉴了软件工程里最经典的管理方法：分工，约束，审核，文档，版本控制。这些方法在人类团队里用了几十年，被证明是有效的。现在把它们用到AI团队里，同样有效。
它的核心就三句话：架构师只画图，工人只搬砖，仓库当记忆本。这三句话听起来简单，但做起来不容易。因为它要求你克制住“让AI自己干”的冲动，愿意花时间写文档，愿意花精力设计规则，愿意忍受AI之间沟通的慢节奏。但如果你真的做到了，你会发现AI写的代码不再是碰运气的产物，而是一个可预测、可控制、可改进的工程产品。
本文介绍GitHub上的architect-loop项目，一个将AI模型分为建筑师（Claude Fable）和工人（GPT-5.5 Codex）角色的协作框架。通过规格说明、验收标准、代码审查三层约束，将AI编程从单模型直接输出代码转变为多模型团队协作模式。
核心设计包括“仓库即记忆”（所有状态存储在文档而非聊天记录）、“每次全新上下文”（工人不保留历史避免决策污染）、“只读验收标准”（工人无权修改设计要求）。
项目提供/architect（功能开发）和/architect-research（研究任务）两个命令。
适合大型项目和多AI协作场景，不适合小型脚本和一次性代码生成。