AI Coding 的下一阶段不是 Prompt，而是 Coding Loop

现在很多人讨论 AI 写代码重点还停留在 Prompt。怎么写提示词怎么塞上下文怎么让模型一次性多写一点怎么让它少犯错。这些当然重要但我越来越觉得AI Coding 真正进入工程阶段以后问题不会只停留在“怎么问 AI”。更关键的问题会变成怎么把多个 AI 能力组织成一个稳定、可持续、可复审的开发循环这就是我理解的Coding Loop。我最近做的 LoopMarshal就是在尝试这个方向。https://github.com/Rainbow0328/loopMarshal它不是一个新的 AI IDE也不是一个多 Agent 聊天室。它更像一个本地协作中枢用户先和 Host 对齐目标和架构Host 再根据当前已有的 AI IDE / CLI / Worker自动构建一个适合当前目标的 Coding Loop。为什么不是让一个 AI 从头写到尾一个 AI 从头写到尾简单任务可以复杂任务很快会遇到几个问题。第一所有上下文都堆在一个窗口里。需求、架构、前端代码、后端代码、测试结果、review 意见、临时错误、日志输出全塞进同一个上下文。最后模型不是不知道怎么写而是越来越难分清什么是长期决策什么只是一次性的临时信息。第二不同任务对模型能力的要求并不一样。有的模型适合写前端有的模型更适合做后端推理有的模型适合长上下文分析有的模型适合便宜快速地做重复检查。把所有任务都交给同一个模型并不一定划算也不一定效果最好。第三成本结构不一样。不同模型的计费规则不同。长上下文、复杂推理、高质量 review可能值得用更强的模型但一些机械性的实现、格式调整、文档整理、重复检查用低成本模型就够了。如果所有任务都丢给一个高成本模型token 很容易被浪费。第四工程职责本来就不同。真实开发里架构设计、前端实现、后端实现、测试、review、知识整理本来就不是同一种工作。让一个 AI 长期扮演所有角色会让上下文和职责都变得混乱。所以我认为AI Coding 不只是需要更强的单个模型也需要更好的组织方式。为什么需要多个 AI IDE / CLI 协作这里的重点不是“多开几个 AI 显得很酷”。多 AI IDE / CLI 协作的真正价值是把不同 AI 能力变成可编排的工程资源。比如前端 Worker 可以常驻在更熟悉 UI 代码的 AI IDE 里。后端 Worker 可以使用更擅长复杂逻辑和接口设计的模型。Code Review Worker 可以使用更强但更贵的模型只在关键节点审查。Knowledge Keeper 可以使用一个稳定后台 Agent专门维护项目知识。Host 可以使用更适合规划、拆解和裁决的模型。这带来的好处不是“AI 数量变多”而是职责更清楚不同任务可以用不同模型。不同模型可以承担不同成本等级的工作。不同上下文可以隔离。不同 Worker 可以长期保持自己的职责和工作记忆。Host 可以根据已有 Worker 动态构建 loop而不是所有事都塞给一个模型。我把这理解为一种token 分级和能力分级。重要的架构判断、复杂 review、高风险修改可以交给更强模型。 普通实现、重复检查、低风险修改可以交给更便宜的模型。 知识库维护可以交给专门角色持续做。 Host 负责把这些能力组织起来。为什么不用 subagent很多人可能会问现在一些工具已经有 subagent 了为什么还需要多个 AI IDE / CLI 协作我觉得这里要区分两个东西。subagent 很适合做一次性的子任务。比如主 Agent 临时叫一个 subagent 去看某个文件、查一个问题、总结一段代码。这很方便。但 subagent 通常有几个限制它的上下文往往是临时的。它不一定有稳定身份和长期职责。它的任务状态不一定被外部系统持久化。它的工作记忆很容易随着一次调用结束而消失。多轮任务之间主 Agent 可能需要重复给它塞背景。这会带来一个问题看起来用了子任务实际上很多上下文还是要重复传。重复传上下文就意味着 token 浪费。而且如果 subagent 的状态没有持久化那么一次复杂工程循环里的“等待、回报、复审、返工”就很难稳定追踪。LoopMarshal 想做的不是替代 subagent。更准确地说它解决的是另一个层面的问题让不同 AI IDE / CLI / Worker 拥有稳定身份、稳定职责、持久化消息、持久化知识库和可持续等待能力。这和临时 subagent 不一样。在 LoopMarshal 里Worker 不是一次性函数调用而是一个可以持续待命、接收任务、执行、回报、再等待的协作成员。Host 是什么Host 不是“更大的 Agent”。Host 更像架构师和总负责人。用户不是直接让多个 AI 开始写代码而是先和 Host 对齐目标是什么哪些边界不能碰整体架构怎么定哪些模块要拆出来当前有哪些 Worker哪些任务应该并行哪些任务必须串行什么条件下算完成架构确定后Host 再根据已有 Worker 构建 Coding Loop。这点非常重要。LoopMarshal 的核心不是“多个 AI 自动乱跑”而是用户和 Host 定好架构后Host 根据已有 Worker 自动组织工程循环。Knowledge Keeper 是什么复杂任务里还有一个很容易被低估的问题项目知识会丢。比如架构决策模块边界接口契约字段定义错误码哪些文件不能改哪些实现只是临时方案这些信息如果只留在聊天上下文里很快就会被冲掉。所以 LoopMarshal 里有 Knowledge Keeper。你可以把它理解成项目记忆维护者。但它是可选的。正确流程是如果会话里有 Knowledge KeeperHost 会把知识库维护任务交给它。如果没有 Knowledge KeeperHost 会 fallback 自己维护知识库。无论哪种方式Host 都要复审。Knowledge Keeper 不替 Host 做架构决策。它只是把 Host 已经确定的架构意图沉淀成更稳定的知识材料。这样后续 Worker 执行任务时不需要每次从头理解整个项目。上下文隔离为什么重要上下文隔离不是为了干净而是为了省 token、降混乱、提升稳定性。如果前端 Worker 只关心前端它不需要每次都带着后端所有实现细节。如果后端 Worker 只关心接口和数据模型它不需要长期背着前端组件细节。如果 Review Worker 只在关键节点介入它不需要参与每一次实现过程。如果 Knowledge Keeper 只维护稳定知识它不需要记录所有临时日志和调试过程。不同角色拥有不同上下文Host 再通过知识库和任务消息把它们连接起来。这样比所有信息堆进一个窗口更可控。这也是我认为 Coding Loop 有价值的地方它不是简单增加 Agent 数量而是把上下文拆成不同层级。可以粗略理解成Host 持有目标、架构和裁决上下文。Knowledge Keeper 持有稳定知识上下文。Worker 持有自己职责范围内的执行上下文。Review Worker 持有审查上下文。后端系统持久化消息、任务、成员和知识库。这比单纯靠一个聊天窗口硬撑长上下文更工程化。LoopMarshal 怎么跑一个 Coding Loop一个典型流程大概是1. 用户和 Host 对齐目标与架构 2. Host 查看当前会话有哪些 Worker 3. Host 判断是否需要维护知识库 4. 有 Knowledge Keeper派它维护知识库 5. 没有 Knowledge KeeperHost 自己维护知识库 6. Host 复审知识库和任务边界 7. Host 根据 Worker 职责分发任务 8. Worker 等待任务、执行任务、提交回报 9. Host 收到回报后复审 10. 需要 review 就派 Code Review Worker 11. 有问题就返工 12. 没问题就收口注意这里不是固定模板。Host 会根据当前已有 Worker 构建 loop。如果没有 review worker就不强行 review。 如果没有 Knowledge Keeper就 Host 自己维护知识库。 如果只有一个 Workerloop 也可以退化成单 Worker 执行。 如果有多个专业 WorkerHost 就可以组织并行和串行。这才是我想要的不是预设死流程而是 Host 根据现有能力动态组装 Coding Loop。MCP 长等待为什么重要如果 Worker 不能等待任务loop 就很难持续。每一步都要用户手动叫醒 Worker那还是人在控制流程。LoopMarshal 通过 MCP 让 Worker 可以进入长等待状态。Host 派发任务后Worker 收到任务执行再回报。如果暂时没任务Worker 可以继续待命。为了避免 AI IDE / CLI 在长时间等待时超时LoopMarshal 使用 MCP Progress Notification 做保活。这让 Worker 更像一个真正的协作成员而不是一次性命令。这和 Loop Engineering 的关系最近很多 Loop Engineering 实践更偏业务 Agent比如通过 DeepAgents 构建业务循环。我认为这个方向是对的。但 AI Coding 也需要自己的 Loop Engineering。业务 loop 可能更关注理解业务目标 - 调工具 - 观察结果 - 再行动Coding loop 更关注定架构 - 识别 Worker - 分配任务 - 等待回报 - review - 返工 - 收口LoopMarshal 想验证的就是这个方向Loop Engineering 不只适合业务 Agent也可以用于 AI 写代码。只不过在代码场景里核心角色不是一个万能 Agent而是 Host 根据已有 Worker 构建 Coding Loop。我想宣传的不是“多 AI”而是“可组织的 AI”如果只说“多个 AI 协作”其实很容易被误解。多个 AI 同时工作不一定更好。没有架构没有边界没有知识库没有复审多个 AI 只会更乱。我真正想做的是让 Host 负责架构和裁决。让 Worker 按职责执行。让 Knowledge Keeper 维护稳定知识。让 Review Worker 做独立检查。让消息、任务、等待、回报、知识库都被持久化。让不同模型按能力和成本分层使用。这才是 LoopMarshal 的核心。一句话说LoopMarshal 是一个面向 AI Coding 的 Loop Engineering 工具用户和 Host 定好架构后Host 根据已有 Worker 自动构建 Coding Loop并持续推进实现、复审、返工和收口。结尾AI 写代码下一阶段我认为不会只是 Prompt 更长也不会只是单个模型更强。更关键的是能不能把不同 AI 能力组织成一个真正可运行的工程循环。这个循环里有架构有分工有等待有回报有复审有记忆也有成本分层。这就是我理解的 Coding Loop。也是我做 LoopMarshal 的原因。AI Coding 的下一阶段不是 Prompt而是 Coding Loop。