第一部分：Transformer 架构基础

1.1 什么是 Transformer？从 RNN 到自注意力的范式转变

在深度学习处理序列数据的历史长河中，循环神经网络（Recurrent Neural Network，RNN）曾长期占据统治地位。RNN 通过隐藏状态的传递，能够在理论上处理任意长度的序列数据，但其固有的顺序计算特性导致了严重的并行化瓶颈。当序列长度达到数千甚至数万时，RNN 的训练时间将变得难以接受。此外，长距离依赖问题始终困扰着 RNN 的发展——信息在层层传递中容易衰减，模型难以有效学习序列两端之间的关联。

2017 年，谷歌研究团队发表了开创性论文《Attention Is All You Need》，提出了 Transformer 架构，彻底改变了这一局面。Transformer 的核心创新在于完全摒弃了循环和卷积结构，仅依靠注意力机制来处理序列数据。这一架构设计带来了革命性的变化：首先，注意力机制允许模型同时关注序列中的所有位置，实现了真正的并行计算，训练速度大幅提升；其次，自注意力机制能够直接建立任意两个位置之间的关联，有效解决了长距离依赖问题。

Transformer 架构的出现标志着自然语言处理领域进入了预训练大模型时代。BERT、GPT 系列等影响深远的大模型都建立在 Transformer 基础之上，代码生成模型也不例外。理解 Transformer 的工作原理，是掌握现代代码生成技术的必备基础。

1.2 Encoder-Decoder 架构详解

Transformer 采用经典的编码器-解码器（Encoder-Decoder）架构，这一设计在机器翻译任务中得到了充分验证。整体流程可以概括为：输入序列经过词嵌入和位置编码后，进入编码器进行多层变换，生成上下文表示；解码器则基于这一表示和已生成的输出，逐步预测下一个 token。

编码器（Encoder）由 N 个相同的层堆叠而成，每一层包含两个主要子层：多头自注意力机制（Multi-Head Self-Attention）和位置前馈网络（Position-wise Feed-Forward Network）。每个子层都采用残差连接（Residual Connection）和层归一化（Layer Normalization）进行包裹，确保深层网络的稳定训练。

解码器（Decoder）的结构与编码器类似，但存在关键差异。首先，解码器包含第三个子层——编码器-解码器注意力层（Encoder-Decoder Attention），使得解码器能够关注输入序列的信息。其次，解码器的自注意力层是带掩码的（Masked），确保模型在预测当前位置时只能看到之前的位置，而不能获取未来信息——这正是自回归生成的本质要求。

这种架构设计的精妙之处在于：编码器负责理解输入序列，将其转换为丰富的语义表示；解码器则基于这一表示和已生成的序列，逐步构建输出。两者各司其职又紧密协作，共同完成了从理解到生成的全过程。

1.3 位置编码（Positional Encoding）的作用

Transformer 完全基于注意力机制构建，而注意力计算本质上是位置无关的——无论 token 出现在序列的哪个位置，注意力权重只取决于 token 之间的关系。这意味着，如果我们不显式注入位置信息，模型将无法区分「小狗咬人」和「人咬小狗」这样的语义差异。

位置编码正是为解决这一问题而设计的。Transformer 采用了基于正弦和余弦函数的固定位置编码方案，其公式如下：

PE(pos, 2i) = sin(pos / 10000^(2i/d_model))
PE(pos, 2i+1) = cos(pos / 10000^(2i/d_model))

其中，pos 表示位置索引，i 表示维度索引，d_model 是模型的嵌入维度。这一设计的巧妙之处在于：不同位置具有不同的编码，而相邻位置之间的编码具有平滑的过渡特性；同时，模型能够通过线性组合学习到相对位置关系。

位置编码被直接加到词嵌入向量上，作为输入传递给 Transformer 的第一层。由于注意力机制是加性的，位置信息能够自然地融入到后续的所有计算中。这一简洁而高效的设计，已成为 Transformer 系列的标配。

---

第二部分：注意力机制

2.1 自注意力（Self-Attention）的数学原理

自注意力是 Transformer 的核心组件，其本质是一个加权求和过程：对于序列中的每个位置，模型根据与其他位置的关联程度，赋予不同的注意力权重，然后加权求和得到新的表示。

自注意力的数学公式如下：

Attention(Q, K, V) = softmax(QK^T / √d_k) V

其中，Q（Query）、K（Key）、V（Value）矩阵都源自输入序列的嵌入表示。具体而言，输入序列首先通过三个独立的线性变换，得到 Q、K、V 三个矩阵。注意力权重的计算通过 Q 与 K 的点积得到，除以 √d_k（d_k 是 K 的维度）是为了防止点积结果过大导致梯度饱和。Softmax 函数将权重归一化，使其和为 1，最后将权重应用于 V 矩阵，得到加权和。

这一机制的美妙之处在于：每个位置的输出都融合了序列中所有位置的信息，而融合的比例由它们之间的相关性决定。相关性高的位置获得更高的权重，从而在表示中占据更重要的地位。通过这种方式，模型能够灵活地捕获长距离依赖，而不受限于序列的实际距离。

2.2 多头注意力（Multi-Head Attention）如何工作

单一的自注意力机制虽然强大，但可能无法同时捕获不同类型的关系。设想一句话中同时存在语法关系、语义关联、指代消解等多种信息，单一注意力头难以同时处理好所有任务。多头注意力应运而生，通过并行运行多个注意力函数，让模型能够在不同的子空间中学习不同的关系。

多头注意力的计算过程如下：

MultiHead(Q, K, V) = Concat(head_1, ..., head_h) W^O
其中 head_i = Attention(QW_i^Q, KW_i^K, VW_i^V)

模型使用 h 个不同的注意力头，每个头有独立的 Q、K、V 投影矩阵。各个头独立计算注意力，得到 h 个输出向量。这些输出被拼接（Concat）起来，再通过一个线性变换 W^O 得到最终输出。

在实践中，Transformer 通常使用 8 个或 16 个注意力头。每个头可以学习关注不同的关系：有的头关注语法结构，有的头关注语义关联，有的头关注位置关系。这种多样化的表示使得模型能够更全面地理解序列信息。在代码生成场景中，不同的头可以分别关注代码的语法结构、变量引用关系、函数调用模式等，从而生成更准确的代码。

2.3 注意力机制在代码生成中的实际应用

注意力机制在代码生成中发挥着至关重要的作用，其应用远不止于理解自然语言描述。代码本身是一种高度结构化的序列，蕴含着丰富的语法和语义信息，注意力机制能够帮助模型有效捕获这些信息。

在代码理解阶段，注意力机制帮助模型建立代码元素之间的关联。例如，当模型处理一段 Python 代码时，注意力机制能够让函数定义与其调用位置建立关联，让变量引用与变量赋值建立关联。这种关联对于理解代码逻辑至关重要。

在代码生成阶段，注意力机制指导模型逐 token 生成符合语法规则的代码。解码器中的注意力层使得模型能够「回顾」已经生成的代码片段，确保新生成的代码与上下文一致。同时，编码器-解码器注意力层让模型能够「参照」输入的自然语言描述，将用户的需求准确转化为代码。

现代代码生成模型还发展出了一些特殊的注意力机制变体。例如，StarCoder 采用多查询注意力（Multi-Query Attention），多个查询头共享同一组键和值矩阵，在保持性能的同时显著降低了推理时的显存占用。这些创新使得大规模代码生成模型能够在消费级硬件上运行，推动了技术的普及应用。

---

第三部分：LLM 代码生成原理

3.1 代码理解：tokenization 与 AST 的结合

代码生成的第一步是理解代码。与自然语言不同，代码具有严格的语法结构，传统的词嵌入方法难以直接处理。代码分词（Tokenization）需要平衡粒度：太粗会丢失细节，太细又会导致序列过长。

现代代码生成模型普遍采用字节对编码（Byte-Pair Encoding，BPE）进行分词。BPE 最初用于数据压缩，后来被引入自然语言处理领域。其核心思想是从字符级别开始，逐步合并高频出现的字符对，最终形成包含常用词根、前缀、后缀的词表。在代码场景下，BPE 能够学习到编程语言的语法结构，如 def、class、import 等关键词，以及常见的变量命名模式。

然而，单纯基于文本的 tokenization 难以完全捕获代码的层次结构。为此，一些研究探索了将抽象语法树（Abstract Syntax Tree，AST）信息融入模型的方法。AST 是代码的树状表示，精确描述了代码的语法结构。通过在注意力计算中引入 AST 的结构信息，模型能够更好地理解代码的逻辑组织，生成更符合语法规范的代码。

代码分词还需要处理一些特殊挑战：缩进在 Python 等语言中具有语法意义，空格和制表符的处理方式会影响代码的语义；特殊符号如 ->、::、=> 需要作为独立 token 或组合 token 建模；注释通常应该被忽略或特殊处理。这些细节的处理直接影响模型对代码的理解质量。

3.2 代码生成：自回归解码与 beam search

理解了输入序列之后，模型需要生成代码的下一个部分。代码生成采用自回归（Autoregressive）解码方式：给定已生成的序列，预测下一个 token；将预测的 token 加入序列，继续预测下一个；如此循环，直到生成完整的代码片段。

自回归解码的数学原理可以表示为：

P(y_t | y_<t, x) = softmax(W * h_t + b)

其中，y_t 是当前时间步要预测的 token，y_<t 是之前已经生成的 token 序列，x 是输入的上下文，h_t 是解码器在当前时间步的隐藏状态。模型输出一个概率分布，表示每个可能的下一个 token 的概率。

在贪婪解码（Greedy Decoding）中，模型在每一步都选择概率最高的 token。这种方法简单直接，但容易陷入重复或次优解。Beam Search 是更常用的解码策略：每一步保留概率最高的 k 个候选序列（称为 beam），所有候选序列并行扩展，最终选择总分最高的序列。Beam search 在生成多样性和质量之间取得了较好的平衡。

代码生成还需要考虑一些特殊约束。首先是语法约束：生成的代码必须符合目标编程语言的语法规则，否则无法执行。其次是语义约束：代码需要正确实现用户描述的功能需求。此外，代码风格约束要求生成的代码保持一致的缩进、命名规范等。

为了提高生成质量，现代模型还引入了多种采样策略。温度采样（Temperature Sampling）通过调整概率分布的平滑程度来控制生成的多样性；Top-k 采样限制模型只在概率最高的 k 个 token 中选择；Top-p（核）采样则动态调整候选 token 的范围。这些技术可以单独使用，也可以组合使用，以获得不同风格的生成结果。

3.3 代码补全、解释、转换的典型流程

代码生成并非单一任务，而是包含多种子场景的系统能力。让我们梳理几种典型场景的流程。

代码补全是最常见的应用场景。当开发者编写代码时，IDE 可以基于上下文自动推荐后续代码。流程通常如下：获取当前文件的上下文（包括已编写的代码和导入的模块）；将上下文发送给代码生成模型；模型预测最可能的补全内容；IDE 将预测结果显示为建议或自动插入。代码补全要求模型具有很强的局部上下文理解能力，能够根据当前代码的语法和逻辑推断下一步的合理内容。

代码解释要求模型理解代码并用自然语言表述其功能。流程包括：解析待解释的代码段；分析代码的语法结构、数据流、控制流；生成自然语言描述。为了提高解释的准确性，通常会在 prompt 中要求模型先分析代码的输入输出和关键逻辑，再给出整体描述。

代码转换涉及将代码从一种语言或风格转换为另一种。例如，将 Python 代码转换为 JavaScript，或将面向过程的代码重构为面向对象的代码。这类任务要求模型同时理解源语言和目标语言的语法语义，并在生成过程中进行恰当的映射。Prompt 设计时，明确指定源语言和目标语言、提供转换规则说明，都能提高转换质量。

3.4 Codex、StarCoder、CodeLlama 等模型对比

当前主流的代码生成模型各有特色，让我们对比分析几款代表性模型。

Codex（12B 参数）由 OpenAI 开发，是代码生成领域的先驱模型。Codex 基于 GPT-3 架构，在 GitHub 公开代码库上进行微调训练。在 HumanEval 基准测试上，Codex 的 pass@1 准确率为 28.8%；通过 100 次采样并选择最佳结果（pass@100），准确率可提升至 70.2%。Codex 的主要贡献在于证明了大规模语言模型在代码生成任务上的可行性，并推动了 GitHub Copilot 等产品的诞生。然而，Codex 在处理长链操作描述和复杂变量绑定时仍存在困难。

StarCoder 是 BigCode 项目推出的开源模型，基于 The Stack 数据集训练，支持 88 种编程语言。StarCoder 采用了多项技术创新：多查询注意力机制降低了推理成本；针对代码场景优化的位置编码更好地处理长代码序列；专门的预训练任务帮助模型学习代码的结构特性。作为开源模型，StarCoder 允许开发者本地部署和微调，为学术研究和商业应用提供了更多可能性。

CodeLlama 是 Meta 基于 Llama 2 架构开发的代码专用模型，提供 7B、13B、34B 三种参数规模。CodeLlama 在 500B 代码 token 的数据集上训练，并补充了大量自然语言文档。除了代码生成，CodeLlama 还支持代码补全、代码调试、代码解释等多种任务。其优势在于继承了 Llama 2 强大的语言理解能力，同时针对代码场景进行了专门优化。

模型	参数量	训练数据	特点
Codex	175B	GitHub	商业先驱，准确率高
StarCoder	15B	The Stack	开源多语言
CodeLlama	7B-34B	500B tokens	开源，可本地部署

选择合适的模型需要综合考虑任务需求、硬件条件、隐私要求等因素。对于简单任务，小型模型足够且响应更快；对于复杂任务，可能需要调用更大规模的模型。开源模型提供了本地部署的可能，适合对数据隐私有要求的场景。

---

第四部分：Prompt 设计工程

4.1 Prompt 设计的基本原则

Prompt（提示词）是与大语言模型交互的核心接口，精心设计的 Prompt 能够显著提升模型输出质量。在代码生成场景中，Prompt 设计需要遵循以下基本原则。

清晰性原则要求明确表达需求，避免歧义。Prompt 应当清楚地说明需要生成什么类型的代码、实现什么功能。例如，「写一个函数」就不如「写一个 Python 函数，接受一个整数列表，返回列表中所有偶数的和」具体明确。

具体性原则强调提供具体的约束条件和示例。包括输入输出的格式要求、函数的签名和参数类型、算法的复杂度约束、代码的风格规范等。这些具体信息能够帮助模型更准确地理解需求，生成更符合预期的代码。

一致性原则要求在 Prompt 中保持术语和格式的一致性。如果在示例中使用了某种术语，在后续描述中也应保持一致；如果指定了某种输出格式，整个 Prompt 中都应遵循这一格式。

渐进性原则建议从简单到复杂逐步引导。对于复杂任务，可以将其拆分为多个子任务，逐个完成后再组合。这比一次性要求模型完成整个复杂任务更容易获得好结果。

反馈循环原则强调基于模型输出持续优化 Prompt。首次生成的代码可能不完全符合要求，此时应当分析问题所在，调整 Prompt 重新生成。这一迭代过程往往能显著提升最终效果。

4.2 零样本 vs 少样本（Few-Shot）Prompt

根据是否提供示例，Prompt 可以分为零样本（Zero-Shot）和少样本（Few-Shot）两种范式。

零样本 Prompt不提供任何示例，模型完全依赖预训练知识完成任务。这种方式的优点是简洁直接，适用于需求清晰、模型熟悉的简单任务。例如：

写一个 Python 函数，计算字符串中每个字符出现的次数，返回一个字典。

模型会根据对「计算字符计数」这一任务的理解，直接生成代码。

少样本 Prompt提供少量示例作为上下文，帮助模型理解任务格式和预期输出。当任务较为复杂或格式要求特殊时，少样本学习能够显著提升效果。例如：

将英文翻译为法文：
English: "Hello, how are you?" → French: "Bonjour, comment allez-vous?"
English: "Good morning" → French: "Bonjour"
English: "Thank you" → French:

最后一个示例留白，模型会根据前两个示例学习到翻译的模式，给出正确的翻译。

在代码生成场景中，少样本 Prompt 特别适用于以下情况：需要生成特定格式的代码（如遵循特定的项目结构）；需要使用特定的算法或设计模式；需要保持与现有代码风格的一致性。通过提供 2-5 个高质量示例，模型能够更好地理解并满足需求。

需要注意的是，少样本示例的质量至关重要。示例应当正确、清晰、与目标任务具有相关性。不恰当的示例反而可能误导模型，导致更差的结果。

4.3 Chain-of-Thought (CoT) 在代码任务中的应用

Chain-of-Thought（思维链，简称 CoT）是一种强大的提示技术，通过引导模型生成中间推理步骤，提升其在复杂推理任务上的表现。CoT 的核心思想是：与其要求模型直接给出答案，不如让它先「展示思考过程」。

CoT 技术的论文发表于 2022 年，其基本做法是在 prompt 中包含推理步骤的示例。例如：

问题：小明有5个苹果，他给了小红2个，然后又买了3个。他现在有多少个苹果？
推理：小明开始有5个苹果。
给了小红2个后，剩下 5 - 2 = 3 个。
又买了3个后，变成 3 + 3 = 6 个。
答案：6个

模型学习到这种推理模式后，在面对新问题时也会生成类似的中间步骤，从而提高推理准确性。

在代码生成任务中，CoT 技术同样适用。我们可以在 prompt 中要求模型先分析问题、设计算法，再编写代码：

# 任务：编写一个函数计算斐波那契数列
# 思路分析：
# 1. 斐波那契数列定义：F(0)=0, F(1)=1, F(n)=F(n-1)+F(n-2)
# 2. 可以用递归或迭代实现
# 3. 递归实现直观但效率低，迭代实现效率高
# 实现：使用迭代方法
def fibonacci(n):
    if n <= 1:
        return n
    a, b = 0, 1
    for _ in range(n-1):
        a, b = b, a + b
    return b

通过先展示思路再给出代码，模型能够更准确地理解需求，生成更合理的实现。对于需要算法设计或问题分解的复杂任务，CoT 技术的效果尤为明显。

4.4 结构化 Prompt 模板设计

在实际工程中，结构化的 Prompt 模板能够提高一致性和可维护性。以下是几种常用的结构化 Prompt 模式。

角色设定 Prompt为模型分配特定的角色，帮助其以正确的视角处理任务：

你是一位经验丰富的 Python 工程师，专长于编写高效、可读、可测试的代码。你的代码遵循 PEP 8 规范，包含完整的类型注解和文档字符串。

任务分解 Prompt将复杂任务拆分为步骤，引导模型逐步完成：

请按以下步骤完成任务：
1. 分析需求，明确输入输出
2. 设计算法和数据结构
3. 编写代码实现
4. 编写测试用例验证正确性

约束条件 Prompt明确列出各种限制和要求：

约束条件：
- 时间复杂度必须为 O(n log n) 或更优
- 空间复杂度必须为 O(1)
- 只能使用 Python 标准库
- 函数签名必须为：def solution(nums: List[int]) -> int

格式要求 Prompt指定输出的结构和格式：

输出格式：
1. 算法说明（2-3句话）
2. 代码实现（包含完整注释）
3. 示例用法（至少2个测试用例）

将以上元素组合，可以构建功能强大的复合 Prompt：

你是一位算法工程师。

任务：实现一个函数，检查链表是否有环。

约束条件：
- 时间复杂度 O(n)，空间复杂度 O(1)
- 使用 Python，定义 ListNode 类

输出格式：
1. 算法思路
2. 代码实现
3. 测试示例

4.5 常见陷阱与避坑指南

Prompt 工程中有一些常见错误需要避免。

信息不足陷阱：过于简略的 prompt 会导致模型猜测，增加输出不确定性。应当提供足够的上下文和约束条件。

矛盾要求陷阱：同时提出相互矛盾的要求会让模型无所适从。例如要求代码「简洁」又「详细」，或者要求「不用循环」又「处理大数据」。应当明确优先级或重新审视需求。

假设偏差陷阱：prompt 中包含错误的假设会导致生成错误的代码。例如假设输入「总是有效的」，而没有考虑边界情况。

过度指令陷阱：过多的限制和要求反而可能降低质量。应当抓核心需求，给模型一定的灵活空间。

忽略测试陷阱：不包含测试用例验证正确性，可能导致代码存在隐藏 bug。应当要求模型生成测试，或自行验证。

为了避免这些陷阱，建议采用迭代优化的方式：先写出基础的 prompt，评估输出质量，针对问题调整 prompt，重复直到满意。这是一个持续改进的过程，而非一次性完成任务。

---

第五部分：实战案例与最佳实践

5.1 案例 1：用 Prompt 生成完整函数

让我们通过实际案例展示 Prompt 设计的技巧。

需求：实现一个函数，接受一个整数数组和目标值，返回数组中两数之和等于目标值的两个数的索引。

初次 Prompt：

写一个 Python 函数，找到数组中两数之和等于目标值的两个数的索引。

这个 prompt 过于简单，可能导致模型生成功能正确但缺乏优化的代码。

优化后的 Prompt：

你是一位 Python 工程师。

任务：实现两数之和查找函数

输入：
- nums: List[int]，整数数组，假设数组中恰好有一对数字之和等于目标值
- target: int，目标值

输出：
- List[int]，两个索引组成的列表

要求：
1. 使用哈希表实现，时间复杂度 O(n)，空间复杂度 O(n)
2. 返回任意一对满足条件的索引
3. 函数签名：def two_sum(nums: List[int], target: int) -> List[int]
4. 包含完整的类型注解和文档字符串

示例：
输入：nums = [2, 7, 11, 15], target = 9
输出：[0, 1]（因为 nums[0] + nums[1] = 2 + 7 = 9）

这个 prompt 通过明确输入输出格式、算法复杂度要求、函数签名、具体示例等信息，引导模型生成高质量的代码。模型输出了包含哈希表实现的完整函数，代码结构清晰，包含类型注解和文档说明。

5.2 案例 2：用 Prompt 调试和优化代码

Prompt 不仅可以用于代码生成，还可以用于代码调试和优化。

场景：有一段代码运行结果不正确，需要修复。

调试 Prompt：

你是一位 Python 调试专家。

我有一段代码，用于计算列表的平均值，但存在 bug。

原始代码：
    def calculate_average(numbers):
        total = 0
        for i in range(len(numbers)):
            total += numbers[i]
        return total / len(numbers)

测试：
    print(calculate_average([10, 20, 30]))  # 期望：20.0
    print(calculate_average([]))  # 期望：处理空列表，实际：ZeroDivisionError

请分析问题原因，修复代码中的 bug，并解释修复的原理。

模型分析后指出问题：当 numbers 为空列表时，len(numbers) 为 0，导致除零错误（ZeroDivisionError）。修复方案是在除法前检查列表是否为空，并提供合理的默认值或抛出有意义的异常：

def calculate_average(numbers):
    if not numbers:
        return 0.0  # 或 raise ValueError("列表不能为空")
    total = sum(numbers)
    return total / len(numbers)

模型进一步建议使用 Python 内置的 sum() 替代手动累加，使代码更简洁。这个案例展示了 Prompt 调试的有效性——通过提供具体的测试用例，帮助模型快速定位边界条件 bug。

优化 Prompt：

你是一位代码优化专家。

请优化以下代码，在保持功能正确的前提下提高执行效率：

原始代码：
    def is_prime(n):
        if n < 2:
            return False
        for i in range(2, n):
            if n % i == 0:
                return False
        return True

请分析时间复杂度，提供优化后的版本，并解释优化思路。

模型分析指出原始代码时间复杂度为 O(n)，并提供了两种优化方案：只需检查到 √n，时间复杂度降至 O(√n)；如果是频繁调用的场景，可以预先计算素数表。优化后的代码简洁高效，同时包含了详细解释。

5.3 案例 3：多步代码任务的 Prompt 编排

对于复杂的多步任务，需要精心设计 Prompt 编排策略。

需求：实现一个简易的 ToDo 应用，包含任务添加、删除、完成标记功能。

整体 Prompt 编排：

第一步，定义数据结构和接口：

定义一个 Task 类和 TaskManager 类，包含：
- Task: id, title, completed, created_at
- TaskManager: add(), remove(), complete(), list_tasks()
只输出类定义，不需要实现。

第二步，实现核心功能：

基于以下类定义，实现 TaskManager 的方法：

class Task:
    def __init__(self, id: int, title: str):
        self.id = id
        self.title = title
        self.completed = False
        self.created_at = None  # 稍后实现

class TaskManager:
    def __init__(self):
        self.tasks = {}
        self.next_id = 1

    def add(self, title: str) -> Task:
        # 实现

    def remove(self, task_id: int) -> bool:
        # 实现

    def complete(self, task_id: int) -> bool:
        # 实现

    def list_tasks(self, show_completed: bool = True) -> List[Task]:
        # 实现

第三步，添加时间戳功能：

在 Task 类的 __init__ 中添加时间戳：
- 使用 datetime 模块
- created_at 存储任务创建时间
- 修改 list_tasks 方法支持按创建时间排序

第四步，添加持久化：

为 TaskManager 添加 JSON 文件持久化功能：
- save(filepath): 保存任务到 JSON 文件
- load(filepath): 从 JSON 文件加载任务
- 自动保存和加载

通过这种分步编排策略，每个步骤的目标清晰明确，模型能够专注于当前任务，最终组合成完整的解决方案。这种方法比一次性要求生成完整应用更易于控制质量。

5.4 最佳实践清单

综合全文内容，以下是代码生成 Prompt 工程的最佳实践清单：

需求明确化：

• 明确输入输出的数据类型和格式
• 说明具体的业务逻辑和算法要求
• 列出边界情况和异常处理需求

约束具体化：

• 指定时间、空间复杂度要求
• 明确代码风格规范（命名、注释、格式）
• 限制可使用的库和工具

示例高质量：

• 提供 2-5 个相关且正确的示例
• 示例格式与期望输出保持一致
• 包含典型的边界情况

结构化设计：

• 使用角色设定明确模型视角
• 使用任务分解引导逐步完成
• 使用格式要求规范输出结构

迭代优化：

• 基于输出质量持续调整 Prompt
• 记录有效的 Prompt 模式
• 针对不同任务类型设计不同模板

验证不可少：

• 自行运行生成的代码验证正确性
• 编写测试用例覆盖边界情况
• 对比不同 Prompt 版本的输出质量

---

结语

本文系统梳理了 LLM 代码生成的技术全貌，从 Transformer 架构的基础理论出发，深入解析了注意力机制的数学原理，阐述了代码理解与生成的完整流程，并通过 Codex、StarCoder、CodeLlama 等主流模型的对比，呈现了代码生成领域的技术演进。在实践层面，本文详细介绍了 Prompt 设计的核心原则、零样本与少样本提示的适用场景、Chain-of-Thought 技术的应用方法，以及结构化 Prompt 模板的设计技巧。三个实战案例从不同角度展示了这些技术在实际开发中的具体应用。

代码生成技术正在快速演进，从辅助代码补全到智能代码审查，从自动化单元测试生成到代码架构优化，大语言模型正在深刻改变软件开发的生产方式。然而，我们也应清醒认识到当前技术的局限性：模型可能生成看似正确但实际存在 bug 的代码，可能在处理复杂业务逻辑时出现理解偏差，可能难以保证代码的安全性和隐私合规性。因此，代码生成应被视为开发者的智能助手而非替代者，最终的代码质量和安全性仍需人类开发者把控。

掌握 Prompt 工程技能，是有效利用大语言模型能力的关键。正如本文所展示的，同样的模型在不同 prompt 设计下可能产生截然不同的结果。清晰的需求描述、合理的示例引导、适当的约束条件、迭代优化的思维，这些都是写出高质量 Prompt 的必备要素。随着技术的不断发展，持续学习和实践将是保持竞争力的最佳途径。