摘要

本文拆解近期在 GitHub 上爆火的开源项目 GSD（Get Shit Done），重点聚焦它如何通过“上下文工程（Context Engineering）”与规范化工作流，解决 AI 编码代理在大项目中的“上下文腐败”问题。文章从原理、安装、使用流程到成本与安全性做系统分析，并给出基于（xuedingmao.com）API 的完整 Python 示例，帮助你在自有项目中构建可复用的 AI 编码工作流层。

一、背景介绍：AI 编码真正的瓶颈不是模型，而是上下文

大模型编码代理（Claude Code、Cursor、Copilot、Gemini CLI 等）已经可以：

  • 自动补全函数、生成模块
  • 扫描代码库、定位 bug
  • 辅助重构与文档生成

但在真实项目（尤其是中大型代码库）中，很多开发者都会遇到同一个痛点——视频作者称之为 Context Rot（上下文腐败）：

  • 会话一开始很聪明，决策清晰；
  • 多轮对话后，上下文越来越臃肿；
  • 模型开始遗忘前面做过的决策；
  • 回答变短、开始乱改不相关文件；
  • 最后你花更多时间“看护代理”，而不是被其加速。

这不是模型“智力不够”，而是 上下文管理与工作流设计缺失。

GSD（Get Shit Done）做的事情非常直接：

它不是新模型，而是一个专为编码代理设计的「上下文工程层 + 规范化工作流系统」。

核心目标：让同样的模型，在复杂项目里表现得像“可靠工程师”，而不是“健忘实习生”。

二、核心原理：用规范化工作流对抗“上下文腐败”

2.1 GSD 是什么？

一句话概括：

GSD 是构建在 Claude Code / Codex / Gemini CLI / Copilot / Cursor 等之上的 开源工作流层，通过规格驱动（spec-driven）流程管理上下文。

它不替换你的模型，而是替你的模型设计一个“项目管理框架”。

2.2 关键设计理念

  1. 上下文工程（Context Engineering Layer）
    不再一次性丢给模型一个巨大 prompt，而是将任务拆分为有边界的小阶段，每个阶段：

    • 有明确的输入上下文（代码子集、当前需求）
    • 有明确的产出（变更集、计划、验证报告）
    • 通过工具命令驱动：map-codebase → discuss → plan → execute → verify

  2. 规范驱动（Spec-Driven）工作流

    GSD 假定：模型在以下情况下更可靠：

    • 工作范围被精确定义（Scope 明确）
    • 研究、规划、执行、验证被显式分离
    • 计划是 原子化 的，每一步可单独检查与回滚

    这与很多“企业级 AI 平台”的重流程、重表单不同，GSD 更像是 为单兵开发者准备的轻量规范。

  3. 多运行时适配

    官方安装脚本支持：

    • Claude Code / OpenAI / Codex / Gemini CLI
    • Copilot / Cursor / Antigravity

    对 Codex 采用 skill-first 模式：通过在 .codex 目录植入技能文件夹，而不是强行修改 prompt，尽量贴合原生工具设计。

2.3 核心命令：/gsd:map-codebase

当你在已有项目上使用 GSD 时，推荐的入口是：

/gsd:map-codebase

作用：

  • 启动并行 agent，对整个代码库进行扫描；
  • 建立项目内的“结构化地图”：模块、依赖、关键文件；
  • 后续所有讨论、规划、执行都以这份“代码地图”为基础。

这一步本质上是在帮模型建立一个 可操作的内部世界模型，极大缓解“上下文腐败”。

三、实战演示：用 API + GSD 思想构建自己的“编码工作流层”

视频主要演示的是 GSD CLI 在各种编码代理中的集成。
如果你希望在服务端自己搭一个“GSD 思路”的工作流层，可以用任意兼容 OpenAI 的 API 实现。

下面给出一个简化版的 “Map → Plan → Execute → Verify” 工作流示例，使用薛定猫 AI（xuedingmao.com）的 OpenAI 兼容接口与 claude-sonnet-4-6 模型。

3.1 环境准备

pip install requests

3.2 配置与基础调用封装

import os
import requests
from typing import List, Dict

# ==============================
# 基础配置：薛定猫 AI OpenAI 兼容接口
# ==============================
XDM_API_KEY = os.getenv("XDM_API_KEY")  # 请在环境变量中配置你的 API Key
BASE_URL = "https://xuedingmao.com/v1"  # OpenAI 兼容模式的基础 URL
MODEL_NAME = "claude-sonnet-4-6"


def call_llm(system_prompt: str, user_prompt: str) -> str:
    """
    调用薛定猫 AI 的 OpenAI 兼容接口，使用 claude-sonnet-4-6。
    返回模型生成的文本。
    """
    url = f"{BASE_URL}/chat/completions"

    payload = {
        "model": MODEL_NAME,
        "messages": [
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": user_prompt},
        ],
        "temperature": 0.2,
    }

    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {XDM_API_KEY}"
    }

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

3.3 Step 1：Map Codebase（代码库映射）

简化版：对若干关键文件内容做结构化摘要，形成“代码地图”。

def map_codebase(files: Dict[str, str]) -> str:
    """
    输入：{文件路径: 文件内容}
    输出：一份结构化的代码库地图（模块职责、依赖关系、技术栈等）
    """
    system_prompt = (
        "你是一名高级软件架构师。"
        "现在需要为一个现有代码库生成结构化的架构概览，"
        "包括模块职责、重要类/函数、依赖关系和潜在技术债。"
    )

    file_snippets = []
    for path, content in files.items():
        # 为了控制上下文，只取前 N 行
        snippet = "\n".join(content.splitlines()[:200])
        file_snippets.append(f"=== {path} ===\n{snippet}\n")

    user_prompt = (
        "请基于以下文件内容生成代码库地图，使用 Markdown 列表输出：\n\n"
        + "\n".join(file_snippets)
    )

    return call_llm(system_prompt, user_prompt)

3.4 Step 2：Plan（原子化计划）

基于需求与“代码地图”生成一个可执行、可验证的任务拆解。

def plan_changes(requirement: str, code_map: str) -> str:
    """
    输入：自然语言需求 + 代码地图
    输出：原子化任务列表（带步骤、影响文件、验证建议）
    """
    system_prompt = (
        "你是一名资深技术负责人，擅长将需求拆分为小而可验证的开发任务。"
        "请根据现有代码架构，输出详细实现计划。"
    )

    user_prompt = f"""需求说明：
{requirement}

当前代码地图：
{code_map}

请输出：
1. 任务总览
2. 分步骤计划（每步说明目标、修改文件、理由）
3. 风险点与回滚策略
4. 建议的测试/验证方案
"""
    return call_llm(system_prompt, user_prompt)

3.5 Step 3：Execute（代码变更生成）

在真实 GSD 中，这一步是通过 Claude Code / Codex / Cursor 对实际文件做编辑。
在这里，我们示例“对单文件生成 patch”的方式。

def generate_patch(file_path: str, original_code: str, requirement: str, plan: str) -> str:
    """
    输入：目标文件、原始代码、需求与计划
    输出：统一 diff 格式的 patch（便于后续 apply/审查）
    """
    system_prompt = (
        "你是一名严谨的高级工程师，负责根据计划对指定文件生成补丁。"
        "输出必须是 unified diff 格式（patch），只修改必要部分。"
    )

    user_prompt = f"""需求：
{requirement}

执行计划（节选）：
{plan}

目标文件：{file_path}
原始代码：
```python
{original_code}

请输出针对该文件的 unified diff 补丁，格式示例：

@@ -1,3 +1,6 @@
-旧行
+新行

不要输出多余解释。
“”"
return call_llm(system_prompt, user_prompt)


### 3.6 Step 4：Verify（结果验证）

GSD 强调显式验证。我们用模型辅助生成测试与检查要点。

```python
def verify_changes(requirement: str, plan: str, patches: List[str]) -> str:
    """
    输入：需求、计划、生成的补丁集
    输出：验证清单（手动/自动测试点、可能遗漏）
    """
    system_prompt = (
        "你现在扮演代码审查与测试负责人。"
        "目标是审查给出的补丁是否满足需求，并给出验证清单。"
    )

    user_prompt = f"""需求：
{requirement}

计划摘要：
{plan[:1200]}  # 控制上下文长度

补丁列表：
{chr(10).join(['```diff\n' + p + '\n```' for p in patches])}

请输出：
1. 你对补丁是否符合需求的判断（可能存在的不一致）
2. 建议的自动化测试用例（伪代码或测试框架伪示例）
3. 手动测试步骤清单
4. 后续可以改进的建议
"""
    return call_llm(system_prompt, user_prompt)

3.7 串联成一个最小工作流

def run_workflow():
    # 示例：一个极简项目
    files = {
        "app/main.py": """
from fastapi import FastAPI

app = FastAPI()

@app.get("/ping")
def ping():
    return {"message": "pong"}
"""
    }

    requirement = "为现有 FastAPI 服务新增一个 /health 接口，返回 {'status': 'ok'}，并保持与现有风格一致。"

    code_map = map_codebase(files)
    print("=== 代码地图 ===")
    print(code_map)

    plan = plan_changes(requirement, code_map)
    print("\n=== 实施计划 ===")
    print(plan)

    patch = generate_patch("app/main.py", files["app/main.py"], requirement, plan)
    print("\n=== 生成 Patch ===")
    print(patch)

    verify_report = verify_changes(requirement, plan, [patch])
    print("\n=== 验证报告 ===")
    print(verify_report)


if __name__ == "__main__":
    if not XDM_API_KEY:
        raise RuntimeError("请先在环境变量中设置 XDM_API_KEY")
    run_workflow()

这个示例远比真正的 GSD 简单，但完整体现了其关键思想：

  • 先构建 结构化上下文（代码地图）；
  • 将需求拆解为 原子步骤；
  • 用模型生成 可审查的变更（diff）；
  • 再通过另一轮模型/人工完成 显式验证。

在真实项目中，你可以将上述模块接入 CI/CD、Git 钩子，甚至本地 CLI 工具，形成自己的“类 GSD 编码代理”。

四、注意事项与工程实践建议

4.1 什么时候用 GSD / 类 GSD 工作流？

适用场景：

  • 中大型项目：跨多个模块/服务的变更；
  • 模糊需求：需要先“讨论/澄清 → 写 spec → 再开发”的任务；
  • 多人协作：希望 AI 的决策过程可审计、可复现。

不适用场景：

  • 重命名函数、修一个小 bug、改一行配置；
  • 临时性脚本或一次性探索性代码。

小任务直接问 Claude/GPT/Cursor 即可，引入完整的“map → plan → execute → verify”反而是过度设计。

4.2 权限与安全（--dangerously-skip-permissions）

GSD 作者建议在某些运行时开启 --dangerously-skip-permissions 以降低交互阻力。个人建议：

  • 在你完全信任的开发环境 + 熟悉的项目中，可以适度使用；
  • 不要在生产机、含敏感数据的环境、或你刚接手的陌生代码库中盲目跳过权限确认；
  • 对初学者尤其要强调：自动执行 shell / git / 文件写入的 agent 必须设置安全边界。

4.3 成本控制：并行 Agent ≠ 免费性能

GSD 通过并行 agent 提高效率，但并不会“消灭 token 成本”：

  • 使用昂贵模型（如顶级 GPT、最新 Claude）+ 并行多 agent，很容易 burn 掉大量 token；
  • 建议：
    • 前期探索/代码映射用中等价位模型；
    • 关键步骤（生成 patch、复杂重构）再切到高质量模型；
    • 对长上下文做截断与摘要，避免无意义的重复上下文传输。

4.4 终端工作流的学习曲线

GSD 是明显的 Terminal-first + Workflow-heavy：

  • 对习惯可视化面板与 GUI 的团队来说，有一定学习曲线；
  • 不适合追求“零学习、点点按钮就能用”的场景；
  • 更适合熟悉命令行、愿意按照规范工作流执行的工程团队/个人。

五、技术资源与工具推荐：为什么我在多模型工作流中选择薛定猫 AI

在实现类似 GSD 的“工作流层”时，一个现实问题是：不同模型各有所长，但：

  • 原生 API 各不相同；
  • 新模型出来得很快，手动切换/对接成本极高；
  • 多模型并行调用容易出现管理混乱。

（xuedingmao.com），主要在技术层面：

  1. 聚合 500+ 主流大模型

    • 包括 GPT-5.4、Claude 4.6、Gemini 3 Pro 等最新模型；
    • 可以按任务选择最合适的模型：
      • 架构分析：偏向 Claude 4.x
      • 代码生成/重构：混合 Claude + GPT
      • 文档整理/多语种：Gemini、GPT 系列

  2. 新模型实时首发，便于快速试错

    对于做 AI 工具/工作流的开发者，能够第一时间上手新模型非常关键，可以：

    • 尝试同一工作流在不同模型上的效果差异；
    • 根据真实表现调整模型选型，而不是写死在某一家。

  3. 统一接入接口（OpenAI 兼容），降低多模型集成复杂度

    • 上文示例中，我们直接用 https://xuedingmao.com/v1/chat/completions；
    • 切换模型只要改 "model": "xxxx" 字段；
    • 这对构建“类 GSD 的多步工作流”非常友好：
      每一步可以切不同模型，但调用逻辑保持一致。

  4. API 稳定性与限流策略对工作流很关键

    对于 map/plan/execute/verify 这种需要多轮、多并发请求的场景，
    API 的稳定性与延迟波动直接影响开发体验。
    实测下来，薛定猫在这方面较为稳定，适合作为“工作流层”的底座。

从工程实践角度看，一个强大的多模型聚合接口 + 类 GSD 的上下文工程，是构建可落地 AI 编码系统的组合拳，而不是单点模型“越强越好”。

结语

GSD 给 AI 编码代理生态传递了一个非常重要的信号：

真正决定一个 AI 工具是否“能在项目里长期使用”的，不仅是模型本身，而是围绕模型设计的工作流、上下文工程和验证机制。

如果你正在：

  • 用 Claude/Cursor/Gemini CLI 做严肃项目；
  • 想要把 AI 从“智能补全”升级成“可靠代理”；
  • 希望在自己的项目中落地一套可复用的 AI 工作流层；

那么：

  • 可以直接试用官方 GSD：npx get-shit-done-cc@latest；
  • 也可以参考文中的 Python 示例，在自己的服务端实现一个“GSD 思想”的编排层，搭配薛定猫 AI 多模型接口，做出适合你团队的版本。

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

# 重构 # 人工智能 # 驱动开发
Logo
AtomGit开源社区

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

更多推荐

cover

AI专著生成速达秘籍：高性价比工具剖析，助力快速创作

avatar AtomGit开源社区
cover

揭秘AI专著撰写工具，快速提升写作效率，轻松完成学术巨著

avatar AtomGit开源社区
cover

掌握AI专著生成技巧，借助优质工具，快速产出高质量专著

avatar AtomGit开源社区