摘要

本文从工程实践视角拆解 AI 编码中的核心痛点——上下文衰减（context rot），并深入解析开源工作流系统 GSD 如何在 Open Code 等多模型编码 Agent 之上，通过「讨论–规划–执行–验证」闭环和波浪式并行执行，构建稳定、可重复的 AI 编码流程。文中结合 Python 调用多模型平台 API（以薛定猫 AI 为例）给出可直接运行的示例代码，帮助你在真实项目中落地工程化的 AI 编码工作流。

一、背景介绍：为什么 AI 编码越用越「崩」

使用 AI 编程助手（Cursor、Copilot、Claude Code 等）做过真实项目的开发者，大多经历过类似体验：

  • 前几轮对话生成的代码结构清晰、逻辑合理
  • 会话轮次到 10+ 之后：
    • 模型忘记之前写过的模块/约定
    • 重复实现同一业务逻辑
    • 修改不该动的文件，引入新的 bug
  • 最终花在「修 AI 的代码」上的时间 > 自己写代码

这一现象的本质，是大模型在长会话下的 上下文衰减（Context Rot） 问题：

  1. Token 上限导致历史对话被截断 / 总结
  2. 模型在单个上下文窗口里要同时：
    • 记忆整个项目历史决策
    • 跟踪当前任务状态
    • 执行复杂重构或特性开发
  3. 任意一环丢失，就会出现：
    • 忽略约定（异常处理策略、日志规范）
    • 改写已经验证过的代码
    • 生成与当前架构风格不匹配的实现

如果只靠「把所有说明都塞进一个巨型 prompt」来对抗这个问题，随着项目规模增长，失败是必然的。

二、核心原理：GSD 在 Open Code 之上的「上下文工程层」

2.1 Open Code：模型无关的终端优先 AI 编码 Agent

Open Code 本身是一个终端优先的开源 AI 编程助手，用 Go 编写，特征包括：

  • 启动快、资源占用小
  • 支持多种形态：Terminal UI、桌面应用、IDE 扩展
  • 最大的差异点：完全模型无关（model agnostic）
    • 支持 75+ LLM 提供商：Claude、GPT 系列、Gemini、DeepSeek、Mistral…
    • 支持通过 Ollama 接入本地模型
    • 可以直接使用 GitHub Copilot、ChatGPT Plus 账户
  • 内置能力：
    • Plan 模式：只分析、不改代码
    • Build 模式：真正写文件、修改工程
    • 多会话工作流：并行运行多个 Agent
    • LSP 集成：获取更精确的代码语义上下文

但：即便有这些能力，Open Code 仍然无法避免长会话下的 context rot。

2.2 GSD：为 AI 编码加上一层「工程化上下文管理」

GSD 的定位不是新的 IDE 或模型，而是：

运行在现有 AI 编码 Agent 之上的「上下文工程层（Context Engineering Layer）」

它做的事情可以拆解为：

  1. 项目分阶段：不再让 Agent 持续在一个无边界的长对话中工作，而是拆成多个小任务/阶段
  2. 每个阶段运行一个完整的 Discuss → Plan → Execute → Verify 循环：
    • Discuss：澄清需求，收集约束
    • Plan：拆解子任务，生成执行计划
    • Execute：按计划修改代码
    • Verify：基于「可测试交付物」逐条验证
  3. 每个任务都运行在全新的上下文窗口：
    • 干净状态，无历史噪音
    • 只注入本任务所需的关键信息
    • 减少模型「脑补」历史的空间

这带来两个直接效果：

  • 上下文保持新鲜，输出质量在长项目中更稳定
  • 任务边界更清晰，便于回滚、审查和代码评审（PR）

2.3 端到端切片 + 波浪式并行：面向结果而非「横切层」

传统拆分方式是按技术层级水平切分：

  • 先做「所有数据库」
  • 再做「所有 API」
  • 最后做「所有前端」

这会带来大量合并冲突和模糊的任务边界。GSD 采用的是：

端到端功能切片（End-to-End Slices）

例如：

  • 完整实现「登录功能」（DB + API + 前端）
  • 再完整实现「设置页面」

配合 Open Code 的多会话工作流，GSD 使用 Wave-based Execution：

  • Wave 1：若干端到端特性并行开发
  • Wave 2：基于上一波结果继续扩展或重构

每个 Wave 内的任务 上下文相互隔离，避免「全局大锅乱炖」，同时又能充分利用多 Agent 并行能力。

2.4 Verify：把「验证」内建为一等公民

大多数 AI 编码工具的「完成条件」是：

  • 代码能编译
  • 单元测试通过

然而从用户角度看，很多逻辑仍然可能是「能跑但不可用」。GSD 在设计上把验证提升到一等公民：

  • 从 Plan 中抽取 可测试交付物（Testable Deliverables）
  • 通过 /gsd verify work 引导你逐项检查
  • 验证不再是事后补救，而是主循环的一部分

这一步对减少「返工成本」非常关键，尤其是多人协同与未来维护阶段。

三、实战演示：结合 GSD 工作流与多模型 API 调度

下面用一个简化示例展示如何在服务端调用大模型，构建类似 GSD 的「规划–执行分离」工作流。为了贴近真实生产，我们使用 薛定猫 AI（xuedingmao.com） 作为统一的 LLM 接入层。

3.1 为什么选择统一多模型平台（以薛定猫为例）

在 GSD + Open Code 的实践中，你通常会：

  • 为「规划/架构设计」选择高质量模型（如 Claude 4.6 / GPT-5.4 / Gemini 3 Pro）
  • 为「代码生成/重构」选择性价比高的模型（如更便宜的编码模型或本地模型）

如果直接接多个厂商 API：

  • SDK/鉴权/报错规范各不相同
  • 切换模型时需要修改大量调用代码
  • 很难做统一的限流、指标和熔断

薛定猫 AI（xuedingmao.com） 提供的价值在于：

  • 统一 OpenAI 兼容接口（URL + KEY + model），屏蔽底层差异
  • 聚合 500+ 主流大模型（GPT-5.4、Claude 4.6、Gemini 3 Pro、DeepSeek、Mistral 等）
  • 新模型实时首发，便于第一时间在规划环节尝试更强模型
  • 接入一次即可在服务端策略层自由切换模型，降低多模型编排复杂度

这非常适合在 GSD 中按「quality / balanced / budget」配置不同的模型 profile。

3.2 Python 示例：规划用 Claude，执行用较便宜模型

下面的示例展示如何在服务端构建一个最小化「规划+执行」工作流。
假设你已经在 xuedingmao.com 创建好 API Key。

import os
import requests

# ========= 基础配置 =========
API_BASE = "https://xuedingmao.com/v1"  # OpenAI 兼容接口
API_KEY = os.getenv("XUEDINGMAO_API_KEY")  # 请在环境变量中设置你的 Key

HEADERS = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json",
}

# 模型选择：规划使用 Claude 4.6 级别模型，执行使用更经济的模型
PLANNER_MODEL = "claude-sonnet-4-6"        # 高质量规划模型
EXECUTOR_MODEL = "gpt-4.1-mini"            # 示例：假设平台中存在更便宜的执行模型名


def call_llm(model: str, messages: list, temperature: float = 0.2) -> str:
    """
    通用 LLM 调用封装，兼容 OpenAI Chat Completions 接口。
    :param model: 使用的模型名称
    :param messages: Chat 消息列表
    :param temperature: 采样温度
    :return: 模型返回的文本内容
    """
    url = f"{API_BASE}/chat/completions"
    payload = {
        "model": model,
        "messages": messages,
        "temperature": temperature,
    }

    resp = requests.post(url, headers=HEADERS, json=payload, timeout=60)
    resp.raise_for_status()
    data = resp.json()
    return data["choices"][0]["message"]["content"]


def plan_feature(feature_spec: str) -> str:
    """
    使用高质量模型进行特性规划：
    - 拆解为端到端子任务
    - 对每个子任务明确输入/输出/验证要点
    """
    system_prompt = (
        "你是一名资深软件架构师，负责将功能需求拆解为端到端开发任务。\n"
        "输出严格使用 Markdown 列表结构，包含：任务编号、描述、涉及模块、验证要点。"
    )
    user_prompt = f"请为以下功能制定端到端开发计划，并适合交给 AI 编码 Agent 执行：\n\n{feature_spec}"

    messages = [
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": user_prompt},
    ]

    return call_llm(PLANNER_MODEL, messages)


def generate_code(task_description: str, project_context: str) -> str:
    """
    使用经济模型进行代码生成：
    - 输入单个子任务描述
    - 注入必要的项目上下文（接口约定、文件结构等）
    """
    system_prompt = (
        "你是一名资深后端开发工程师，现在在现有项目中实现一个子任务。\n"
        "只输出需要新增或修改的代码片段，并在代码块前简要说明修改位置（文件路径/函数名）。"
    )
    user_prompt = (
        f"项目上下文：\n{project_context}\n\n"
        f"当前任务描述：\n{task_description}\n\n"
        "请给出具体的代码修改建议。"
    )

    messages = [
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": user_prompt},
    ]

    return call_llm(EXECUTOR_MODEL, messages)


if __name__ == "__main__":
    # ======= 示例：为“登录功能”做端到端规划 + 单任务代码生成 =======
    feature_spec = """
    我们正在开发一个多页面 Web 应用，需要实现完整的登录功能：
    - 支持邮箱 + 密码登录
    - 使用 JWT 做会话管理，Token 存储在 HttpOnly Cookie
    - 登录失败需要有统一的错误提示
    - 需要后端 API + 前端表单 + 基础日志记录
    """

    # 1. 规划阶段（类似 GSD 的 Discuss + Plan）
    print("=== 规划阶段：生成端到端任务分解 ===")
    plan_markdown = plan_feature(feature_spec)
    print(plan_markdown)

    # 2. 执行阶段示例（选取其中一个子任务进行代码生成）
    # 实战中可以将 plan_markdown 结构化解析后，逐个子任务执行
    example_task = "实现后端 /api/login 接口，校验邮箱和密码并返回 JWT Token。"
    project_context = """
    - 后端使用 Python FastAPI
    - 已有用户表 users(email, password_hash)
    - 使用 PyJWT 进行 Token 生成
    - 所有 API 统一前缀为 /api
    """

    print("\n=== 执行阶段：针对单个任务生成代码修改建议 ===")
    code_suggestion = generate_code(example_task, project_context)
    print(code_suggestion)

这个示例对应 GSD 的核心理念：

  • 规划和执行使用不同模型 profile（quality vs budget）
  • 每个子任务在 干净上下文中单独执行（你可以把 project_context 控制在合理大小）
  • 输出格式可进一步约束为「补丁 / 指定文件修改」，便于与 Open Code 的 Build 模式结合自动应用

在真实项目中，你可以：

  1. 用 GSD + Open Code 在本地管理「Discuss/Plan/Execute/Verify」循环
  2. 在服务端使用类似上面的调用模式，通过薛定猫 AI 的统一接口，按不同 profile 调用不同模型
  3. 逐步扩展为 CI/CD 中的自动 Review Bot、自动 Test 生成器等工具

四、实践注意事项与工程经验

4.1 上下文设计比「模型大小」更关键

  • 不要追求「一个 Chat 走完整个项目」
  • 保持阶段粒度：
    • 一个任务 = 明确的业务结果 + 清晰的验收标准
  • 控制每次注入的上下文：
    • 当前任务必需信息（接口签名、数据结构、约定）
    • 最多附带极少量上游任务摘要

这比简单升级到更大的模型更有效。

4.2 端到端切片优先，减少跨层依赖

  • 优先围绕用户可感知的功能切任务，而不是围绕「数据库层/API 层」
  • 每个切片尽量独立可合并，减少长期分支和大规模冲突
  • 对已有项目的重构，可以按「一个功能流」为单位逐步迁移

4.3 成本控制：模型组合与 profile 策略

GSD 本身也强调 Token 成本问题——在规划与执行阶段会启多个子 Agent：

  • 规划/签名设计/关键架构 = 高质量模型（更贵）
  • 批量代码生成/简单重构 = 便宜模型或本地模型

利用类似薛定猫 AI 这类统一多模型平台，可以在一处配置不同环境下的 profile：

  • quality：生产环境规划、关键决策
  • balanced：日常开发
  • budget：批量重构、文档生成

通过请求层的配置或环境变量即可切换，无需侵入业务逻辑。

4.4 终端优先工具的学习曲线

GSD 和 Open Code 都是Terminal First：

  • 没有可视化仪表盘
  • 操作主要是命令 + Markdown 文件

对习惯 GUI 的开发者会有一定学习曲线，但带来的回报是：

  • 更易脚本化、自动化集成（CI/CD、Git Hooks）
  • 更接近 Git / shell 的工作方式，便于版本管理与审计

建议的实践是：

  • 从单一功能开始：例如用 GSD 管理「某个中等复杂特性」
  • 熟悉之后再把整个项目 Gradually 迁移到「AI 工作流优先」的模式

技术资源

  • GSD 项目主页：用于在现有 AI 编码 Agent 之上添加工程化工作流
  • Open Code：终端优先、模型无关的 AI 编码助手，适合与 GSD 搭配
  • 薛定猫 AI（xuedingmao.com）：
    • 聚合 500+ 主流大模型（GPT-5.4 / Claude 4.6 / Gemini 3 Pro / DeepSeek / Mistral / 本地模型等）
    • OpenAI 兼容接口，统一调用方式，便于在 GSD/Open Code 的不同 profile 中自由切换模型
    • 新模型实时首发，方便在规划阶段第一时间尝试更强模型，执行阶段使用性价比更高的模型

在实际工程中，将 GSD 的上下文工程 + Open Code 的多会话工作流 + 薛定猫的多模型统一接入 组合使用，可以在不更换现有 IDE 和项目结构的前提下，将「AI 编码」从玩具级提升到可控、可扩展的生产级实践。

#AI #大模型 #Python #机器学习 #技术实战

# 人工智能
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

AI绘画 AI视频 omfyUI 2026 最新版开箱即用｜新手到进阶安装使用教程

avatar AtomGit开源社区

如何正确使用豆包（新手完整版使用教程）

正确使用豆包的核心并不是“让AI帮你偷懒”，而是让AI成为你的高效工具。只要掌握精准提问方法、明确需求、规范格式，豆包可以极大提升学习效率、写作效率、工作效率，是学生和职场人士最实用的免费AI助手。会提问，就会用好AI。

avatar AtomGit开源社区

基于神经网络的非线性模型预测控制，告别模型失配：基于神经网络的非线性模型预测控制(NN-based NMPC)从理论到实践

真实工程中的非线性挑战（无人机、机械臂、化工CSTR例子）传统MPC的线性化局限，配上对比图。

avatar AtomGit开源社区