Building an Intelligent Code Repair Assistant: Architecture and Implementation Guide

In the current wave of AI applications, independent developers and small teams often face the dilemma of having "many ideas, but difficult implementation." particularly for teams looking to build vertical-domain AI code assistants (e.g., tools specifically for refactoring legacy code or fixing specific bugs), converting the capabilities of Large Language Models (LLMs) into actual productivity stably and efficiently is a massive technical challenge.

This article will use the construction of an "Intelligent Code Repair Assistant" as an example to deeply analyze the full-chain architecture design from model integration to generating executable patches, helping you land projects quickly with limited resources.

I. Business Pain Points: Why Are Simple API Calls Not Enough?

Many developers' initial attempts often stop at a simple Chat interface call. However, in real-world engineering scenarios, this "toy-grade" application faces three core pain points:

1. Model Fragmentation and High Trial-and-Error Costs: GPT-4 is capable but expensive and has high latency; Claude 3.5 Sonnet is excellent for coding but has a different API format; open-source models (like DeepSeek Coder) are cheap but require self-hosted inference. If adapting code needs to be rewritten for every model switch, it creates a huge maintenance burden for small teams.
2. Context Loss and Hallucination Issues: Code repair is not just about generating a piece of text, but precisely locating the problem. LLMs often "forget" file paths, generate non-existent variables, or output code formats that cannot be parsed by automation tools, causing the generated repair suggestions to fail to convert into code patches.
3. Uncontrollable Output Formats: Ordinary conversational models like to "ramble," mixing explanatory text in the output, leading to failures in subsequent automated parsing. What we need is structured JSON or standard Diff format, not Markdown text blocks.

II. Architecture Design: Building a Stable AI Code Pipeline

To solve the above pain points, we need to design a middleware architecture that decouples "model capabilities" from "business logic." The core architecture is divided into three layers:

1. Input Parsing Layer: Responsible for receiving repository context, error logs, and extracting key information (such as stack traces and relevant code snippets).
2. Intelligent Orchestration Layer: Responsible for Prompt engineering, context window management, and model invocation strategies.
3. Unified AI API Gateway: This is the key component for reducing maintenance costs, located between the orchestration layer and model providers.

Why Can a Unified AI API Gateway Reduce Maintenance Costs?

For independent developers and small teams, maintaining multi-model interfaces is a nightmare. OpenAI, Anthropic, Google Gemini, and domestic LLM providers all have different API specifications, authentication methods, and error code definitions.

The core value of a Unified AI API Gateway lies in "Standardization" and "Switchability":

• Interface Standardization: The gateway exposes a unified RESTful interface (usually compatible with OpenAI format) to the outside. Whether the underlying call is to GPT-4 or DeepSeek, your application code only needs to maintain one SDK. This eliminates duplicate code for adapting to different vendor SDKs.
• Unified Billing and Monitoring: Small teams often don't have the energy to build complex billing systems. The gateway aggregates Token consumption from different vendors, providing a unified dashboard that lets you see the cost structure at a glance, avoiding "bill explosions" caused by abnormal model calls.
• Flexible Routing and Disaster Recovery: When the primary model (e.g., GPT-4) goes down or times out, the gateway can be configured with automatic downgrade strategies to seamlessly switch to a backup model (e.g., Claude 3.5), while your business code remains unaware. This "hot-swap" capability significantly improves the system's SLA (Service Level Agreement).

By introducing a gateway, your team can be freed from tedious infrastructure maintenance to focus on Prompt optimization and business logic.

III. Key Implementation Steps: From Error Logs to Code Patches

Next, let's implement an automated bug repair process through specific steps.

Step 1: Context Construction and Information Compression

Large models cannot directly read an entire code repository. We need to use AST (Abstract Syntax Tree) or RAG (Retrieval-Augmented Generation) technology to extract code snippets relevant to the error.

Goal: Construct a Prompt containing the file path, error stack, and relevant function code.

Step 2: Prompt Engineering and Structured Output Constraints

To make the model output parsable patches, JSON format output must be enforced.

System Prompt:
你是一位资深的高级工程师。你的任务是根据提供的错误日志和代码片段，生成修复代码。
请严格遵循以下 JSON 格式输出，不要包含任何 Markdown 标记或其他解释性文字：
{
  "file_path": "需要修改的文件绝对路径",
  "bug_cause": "简要描述 Bug 原因",
  "