提示词工程实战：用DeepSeek把低效代码改写成工业级实现

最近这一个月，我基本泡在一件事里：用 DeepSeek 这类代码模型批量重构一个老项目的中枢模块。一开始我的用法特别糙，就是把老代码直接扔给模型，丢一句“帮我优化一下”。模型确实会给出一版新代码，但仔细看下来，大多只是改了改变量名，性能没提升，可读性也没质变。后来我逐步调整了“代码改写提示词”的写法，把目标、约束、边界和验收标准一条条写清楚，结果才真正开始不一样——不仅能拿到符合生产要求的代码，还能让模型解释每一步修改的理由。

这篇文章准备把我打磨提示词的全过程拆给你看：为什么会失效、怎么写才管用、实战里如何一步步把低效代码改写成工业级实现，以及我踩过的那些坑。适合正在折腾 AI 辅助开发的程序员，特别是想用提示词工程提升代码质量，又不想被 AI 改出“看起来花哨，跑起来出事”的结果的人。

1. 先想清楚：提示词凭什么能把代码改成工业级

1.1 模型改代码的机制，不是玄学是工程

很多人把 AI 改写代码理解成“扔进去一段代码，吐出来一段新代码”，这个理解没错，但太粗了。DeepSeek 这类模型本质上是一个基于海量文本训练出来的条件概率模型，它生成每一行代码，都是在预测“在当前上下文里，下一个 token 最可能是什么”。你给它的上下文越明确、约束越具体，它预测出来的内容就越靠近你真正想要的方向。

这跟找一位资深工程师评审代码是一样的。你直接把一段代码拍在桌上说“帮我优化”，对方能做的多半只是局部调整，因为他不知道业务背景、不知道性能目标、不知道哪些函数是外部依赖的边界。但如果你提前整理好接口契约、性能瓶颈数据和改动的限制条件，他就能有针对性地做架构调整、算法替换和防御性编程。

提示词的作用就是把这些“评审前应该提供的背景信息”打包成文字，塞进模型的上下文窗口。它不是魔法咒语，而是信息压缩协议。理解了这一点，你就会明白为什么“帮我优化一下”这种写法效果差——信息量太少了，模型只能做最保守的猜测，或者干脆按训练数据里的通用套路来一套模板化重构。

我在实际测试中还发现一个有意思的现象：同样一段低效代码，如果你在提示词里补充了“这个函数会被高频调用，平均单次耗时在 300 毫秒左右”，模型会更倾向于选择算法层面的优化，而不是只在循环里抠几个小细节。这说明上下文里的量化信息真的会影响模型的优化策略。

1.2 为什么很多人的提示词没效果

我前后写过几十版提示词，外加对比过身边同事的习惯，发现提示词失效通常不是因为模型不行，而是因为这几个原因。

第一，目标过于模糊。“优化一下”“改善代码质量”这类描述没有提供任何可验证的指标。模型只能按自己的理解随意发挥，完全随机。更关键的是，模糊目标会导致输出结果的评判标准也模糊——你拿到新代码后，根本说不清楚它到底算不算达标。

第二，缺少约束边界。你本来只打算让它优化一段函数，但模型可能会“顺手”把函数签名改了、把依赖库换了、把数据结构推倒重来。如果代码库里有多个模块调用这段逻辑，这种过度重构会直接引发连锁故障。

第三，没有指定差异说明和验证要求。多数人拿到的 AI 改写代码里，模型不会自动告诉你“我改了什么、为什么这么改、有没有引入新的副作用”。这就导致人工 review 的难度极高，只能逐行去比对新旧代码，效率很低。

第四，不会利用示例对齐格式。想让模型按特定格式输出，或者按特定的代码风格改写，最好的办法是给一小段输入-输出示例。光用语言描述“请用类型注解和 dataclass 风格”，远不如贴一个示例来得直接。

这里我特别想强调验证闭环。提示词工程里有一条经验法则：你的提示词必须明确要求模型给出验证方案，比如测试命令、边界用例，或者必要的运行结果。否则你拿到的就是未经证明的代码——看着很好，跑起来可能立刻爆炸。我在后文会专门展开这一点。

2. 一套能复用的代码改写提示词框架

2.1 五段式提示词模板：角色、任务、约束、示例、输出格式

经过反复迭代，我把代码改写提示词固定成了一套五段式结构，表格对比一下各部分的作用会更清楚。

下面是我常用的一版模板，可以直接复制去改：

【角色】 你是一名有十年一线开发经验的资深工程师，擅长在保证行为不变的前提下对代码做工业级改进。 【任务】 请分析以下 Python 函数，拆解其性能瓶颈和潜在缺陷，并给出优化版本。 【约束】 1. 保持函数签名和对外行为完全不变 2. 不引入新的第三方依赖 3. 保持代码风格与项目现状一致，优先使用标准库 4. 改完后必须保证原有调用方无需任何改动 【示例】 输入（低效版）： def get_names(ids): result = [] for id in ids: for u in users: if u.id == id: result.append(u.name) return result 输出（高效版）： def get_names(ids): lookup = {u.id: u.name for u in users} return [lookup.get(i) for i in ids] 【输出】 1. 先用一段话说明原代码的问题 2. 给出完整优化后的代码，放在代码块中 3. 用列表说明新增的测试用例或验证方式 4. 指出所有涉及行为不变假设的风险点

这个模板最核心的地方在于把“约束”和“示例”放到了同等重要的位置。约束用来框定模型的发挥空间，示例则用来对齐模型的表达格式。两者缺一个，输出结果都会跑偏。

2.2 参数细节：上下文窗口与生成温度的影响

除了提示词内容本身，模型调用参数也在悄悄影响改写质量。如果你用的是 API 方式调用，有两个参数值得关注。

第一个是 temperature。这个参数控制输出的随机性，取值范围通常在 0 到 1 之间。代码改写任务是强逻辑任务，不是创意写作，我会把 temperature 调到 0.1 到 0.3。温度太高时模型可能在语义等价的位置换用完全不同的实现方式，看起来有创造性，但稳定性很差。温度太低则可能让它过度保守，只是做表面调整。

第二个是上下文窗口的利用方式。DeepSeek 这类模型都有上下文长度限制，但并不是说塞得越满越好。多次实践下来，我的体会是：代码改写任务的上下文里，最有价值的是被改模块的依赖接口定义、关键业务规则说明，以及调用方的使用方式。无关文件、超长历史输出、重复的对话轮次，都会稀释模型的注意力。

还有一点经验：如果代码库非常大，千万不要一次性把所有相关代码都塞进对话里。先只给目标函数和它直接依赖的少量类型定义，让模型完成初步改写，再逐步迭代。这就像给人类工程师看代码，你一次性给他五百个文件，他反而记不住重点；只给一张模块图和几个核心接口，他能在最短时间内找到问题所在。

3. 实战拆解：一段低效代码如何变成工业级实现

3.1 低效代码样本

我们用一段典型的老项目遗留代码来演示。这段函数从一批用户记录里筛选出指定 ID 的用户名，并按输入顺序返回。它的问题非常普遍，兼具性能、可读性和健壮性三个维度的问题。

def get_user_names(ids): result = [] for i in ids: for u in users: if u['id'] == i: result.append(u['name']) break return result

我来说说为什么这段代码让人头疼。第一，嵌套循环导致时间复杂度达到 O(n*m)，当 ids 有几千个、users 有几万个时，运行时间立竿见影地拉胯。第二，代码里没有类型注解，也没说明 users 和 ids 的数据来源与格式，几个月后连写它的人自己都要重新猜。第三，如果 ids 里存在重复值或者根本不存在的 ID，这段代码会要么重复返回，要么直接忽略，逻辑不够明确。第四，一旦 users 列表为空或 id 键不存在，还会引发异常，看不出代码的作者有防御性编程的意识。

我把这段代码放进最初那版“帮我优化一下”的提示词里，得到的结果是：模型把变量名改顺眼了，加了点注释，但时间复杂度一点没变。问题出在哪里？出在我的提示词没有强调性能目标和边界条件。

3.2 实战提示词与 AI 改写过程

于是我换成了上面那套五段式模板，结合业务场景做了微调。针对这段代码，我实际使用的是下面这版提示词。

【角色】 你是一名有十年一线开发经验的资深工程师，擅长 Python 代码的工业级优化。 【任务】 优化以下函数 get_user_names，当前实现使用嵌套循环完成用户 ID 到用户名的映射，性能较差，且缺少类型标注和异常处理。 【约束】 1. 保持函数签名 get_user_names(ids) 不变 2. 不引入第三方依赖，只使用 Python 标准库 3. users 是全局变量列表，元素为字典，必须兼容缺失 id 或 name 键的情况 4. 返回顺序必须与传入 ids 的顺序一致 5. 如果某个 id 在 users 中不存在，应跳过并继续 【示例】 输入: get_user_names([3, 1]) 预期输出: ['alice', 'bob'] 【输出】 1. 先用一段话说明原代码的问题 2. 给出完整优化代码 3. 列出你新增的边界测试用例 4. 指出潜在风险点

你注意看我加的几条约束：保持函数签名不变、只使用标准库、兼容缺失键、保持顺序、跳过不存在 ID。这五条约束让模型的优化方向收敛到了一个明确目标——在不改变对外行为的前提下，把嵌套循环换成哈希查找。

模型在收到这版提示词后，给出的核心优化思路也清晰了：先把 users 按 id 建立字典索引，把查找复杂度从 O(n) 降到 O(1)，再用列表推导式完成顺序映射。这个方案与我手写的优化思路完全一致，而且它还顺手加了类型注解和些许注释，让代码的自解释性更强。

3.3 改写结果对比与要点解析

下面就是这版提示词实际生成的代码，我做了一些格式整理，使它看起来更工整，逻辑上则完全保留了模型输出的样子。

from typing import Any, Dict, List, Union users: List[Dict[str, Any]] = [ {"id": 1, "name": "bob", "age": 25}, {"id": 2, "name": "alice", "age": 30}, {"id": 3, "name": "carol", "age": 35}, ] def get_user_names(ids: List[Union[int, str]]) -> List[str]: """根据传入的 id 列表返回对应的用户名列表。 保持输入顺序，并在 users 中不存在的 id 时跳过，不做异常抛出。 """ user_map = {str(u["id"]): u["name"] for u in users if "id" in u and "name" in u} result = [] for i in ids: key = str(i) if key in user_map: result.append(user_map[key]) return result print(get_user_names([3, 1])) # ['carol', 'bob'] print(get_user_names([99, 2])) # ['alice']

我建议你实际对比一下新旧代码，感受其中差异。性能上，改动前嵌套循环最坏要走 n乘以m 次，改动后只需要构建一次哈希表然后逐 id 查表，时间复杂度接近 O(n + m)。如果 users 有十万条，ids 有一万条，这种提升在数据量大的场景里是肉眼可见的。

可读性方面，新代码加了类型注解、函数注释和变量命名规范。不要小看这些“表面功夫”，在团队协作里，类型注解能直接省掉后人大量猜谜时间。健壮性方面，代码兼容了缺失键、不在集合中的 ID 和空列表，不会因为某个脏数据直接崩溃。可测试性方面，新代码用两个 print 用例说明了输入输出行为，如果再配合 pytest 就能快速覆盖核心场景。

有一个隐藏点你可能没注意到，模型在构建 user_map 时用了 if "id" in u and "name" in u，这个守卫条件是提示词里“兼容缺失 id 或 name 键”的直接产物。如果你不写约束，模型通常不会主动处理这类边界，因为通用训练数据里少见这种防御性细节。这就是为什么我一直强调：约束段决定了 AI 改写代码的下限。

4. 迭代提示词的实操技巧与排查记录

4.1 提示词失效的四种典型症状与对策

就算用了五段式模板，我依然会在实践中遇到提示词“失效”的情况。所谓失效不是模型报错，而是输出结果达不到预期。下面是我遇到最多的四种症状，以及对应的排查方向。

症状一：模型只是复制原代码，几乎没有改动。对策往往是任务段不够具体。你需要补充痛点描述，比如“时间复杂度为 O(n²)”“存在数据竞争风险”“逻辑重复度高”。模型需要明确的优化动机。

症状二：模型过度设计，引入不必要的抽象层。这是最常见的翻车现场。原本只要一个函数，它非要给你拆成三个类加两个接口。对策是把约束段写死，明确说明“禁止引入额外抽象，保持代码结构简单”。

症状三：输出代码没有上下文关联性。比如改了函数名、改了参数顺序、换了返回值形状。根源在于你没有强调“接口兼容”。这时需要在约束段中重复三遍，或者直接复制调用方的调用代码作为上下文。

症状四：格式漂移，模型偶尔只给一段代码，不附解释，也没有测试建议。这时输出段规格要更严格，明确要求“先说明问题，再贴代码，最后列测试”。

4.2 我踩过的坑：上下文污染、约束冲突和验证缺失

在多次实际调试中，有三个坑我反反复复踩，有必要单独拿出来讲。

第一个坑是上下文污染。有一次我把某模块的十几个函数一次性塞进对话，想让模型统一优化。结果是：它改出来的代码东拼西凑，每个函数都改了一点点，但整体风格割裂，甚至有的函数之间出现了循环调用的隐患。后来我把任务拆成一次只改一个函数，再把相关依赖定义作为上下文，效果立刻正常了。记住：上下文窗口不是无限的草稿纸，它是供模型做精确判断的线索集。

第二个坑是约束冲突。有一版提示词我同时要求“保持读秒级别的低延迟”和“不使用任何预计算缓存结构”，结果模型逻辑混乱，最终给出一版既没性能提升又多了很多冗余判断的代码。这类冲突在提示词里其实很隐蔽，因为语言描述不会自动检查逻辑一致性。后来我养成了一个习惯：每次写完提示词，我会自己先读一遍，模拟一下各条约束之间会不会打架。如果约束相互限制，你就要主动取舍，去掉次要目标。

第三个坑是验证缺失。最初我拿到模型改写后的代码，看质量还不错，直接就合入了分支，结果被回归测试打脸。后来我强制要求模型在输出段给出测试建议和边界用例，并且自己补一轮基准测试。这步看着小，实际上直接决定 AI 辅助开发的可持续性。代码模型不会替你做验证，提示词里不写验证要求，就等于你主动放弃质量门禁。

另外一个与验证相关的习惯是：拿到优化代码后，先跑旧逻辑的回归用例，再补新边界用例，最后做一轮基准测试对比。比如上面那个例子，我会构造一个一万用户、一万 ID 的数据集，对比新旧函数的耗时差距。没有这些数据支撑，你很难说服同事“改动值得合入”。毕竟在团队里，代码改动是需要可量化收益的。

最后再分享一个我的真实体会：提示词不是在“命令”模型做事，而是在和未来的自己沟通。写提示词时多想想，如果你是接手这段代码的同事，你需要怎样的信息才能又快又稳地完成任务。想通这一点之后，你会发现每次拿到的结果都变得更加可控。上面这套框架我已经用在了好几个历史项目的重构里，效率比逐行手改提升了不止一倍，而且代码质量稳定在可以直接 review 的水平。你可以先从一段小函数开始试，把五段式模板跑通，再逐步扩展到更大范围的重构场景。