DeepSeek生成脚本与测试：从需求描述到安全落地的AI代码实践

简介：这是一份系统讲解 DeepSeek 自动化编程能力的 PDF 技术资料，面向需要提升编码与测试效率的开发者、测试工程师和团队技术负责人，聚焦于如何借助 DeepSeek 批量生成可执行脚本与单元测试，缓解重复劳动和测试覆盖不足的痛点。资源压缩包仅含 1 个 PDF 文件，大小为 1.75MB，但章节组织完整，目录涵盖引言、技术原理、脚本生成流程、测试框架选型、实践案例、挑战应对与未来展望，检索非常方便。从预览看，文中对系统管理、数据处理、自动化部署等脚本类型均有梳理，并给出了明确需求、输入生成、检查调整、运行测试的流程化操作路径；针对单元测试，还涉及 pytest、JUnit 等框架选择以及边界条件、异常处理、分支覆盖等覆盖率提升要点。读者既能直接对照章节获取操作指引，也能从案例分析中理解效果评估与落地风险。目前已有 421 人学习下载，适合作为 AI 辅助开发的入门与进阶参考。

1. 用DeepSeek自动化生成脚本和测试：先搞清楚它能替代哪部分重复劳动

当你在项目里每天要花半小时写数据清洗脚本、又花半小时给函数补测试用例时，DeepSeek这类能直接产出可执行脚本和单元测试的AI模型，确实算得上一次生产力革命。它不是简单的代码补全，而是你给一句自然语言需求，它给你一整套能跑的脚本或测试代码。我实际用下来的感受是：系统管理、数据处理、接口调用这些模式化脚本，以及单元测试的骨架代码，生成质量已经可以进生产环境了，但前提是你得会提需求、会验收。这篇笔记不聊模型原理，只讲我怎么用它生成脚本和测试、提示词怎么写、参数怎么调、哪些地方必须自己兜底。

2. DeepSeek生成可执行脚本：从一句话需求到能跑的代码

2.1 可执行脚本的常见类型与适用边界

DeepSeek能生成的脚本类型，在我们日常开发里主要集中在三类：系统管理脚本、数据处理脚本和自动化部署脚本。这三类有一个共同点：逻辑相对固定、边界清晰，非常适合用自然语言描述后让模型生成代码。以系统管理脚本为例，清理临时文件、检查磁盘占用、定时备份这类任务，本质上就是遍历文件、判断时间戳、执行删除或复制，完全可以用Python的os和shutil库实现。我通常会让DeepSeek生成这类脚本，因为它能把os.walk、getmtime这些API组合得很干净，不容易漏掉异常处理。

数据处理脚本是另一个高频场景，尤其是和pandas相关的操作：读取CSV、去重、筛选、聚合、写出新文件。这类脚本的痛点在于，很多人不熟悉pandas的向量化语法，习惯用for循环一行行处理，性能差不说还容易写错。DeepSeek能在你给出"读取数据、按条件筛选、保存结果"这样明确的自然语言后，直接产出data[data['age'] > 30]这样的向量化写法，比手动写循环省事得多。

自动化部署脚本相对复杂，涉及到Docker Compose、Shell命令、环境变量等，DeepSeek也能生成基本的docker-compose.yml或部署脚本，但这类脚本和具体环境强相关，模型不感知你的服务器配置、网络策略和已有的镜像版本，所以生成结果只能当起点，必须逐行核对。我一般会明确告诉它"使用Docker Compose，web服务依赖db，暴露80端口"，它给出的骨架基本能跑，但镜像tag、卷挂载这些细节还得自己改。

适用边界的判断很简单：凡是需求能在一两句话里说清楚、输入输出明确、不涉及公司私有协议和复杂业务规则的脚本，都适合让DeepSeek生成。反过来，涉及大量业务分支、需要访问内部账号体系、或对执行安全有极高要求的脚本，就别偷懒，手写更好。

2.2 生成流程：需求描述、提示词写法与代码检查

生成脚本的流程我在项目里已经固定下来：先明确需求，再写提示词，然后检查生成代码，最后运行测试。这四步哪一步都不能省，尤其是前两步，直接决定生成结果的质量。

明确需求时，我会把"数据来源、处理规则、输出形式、运行环境"四个要素都写清楚。比如要生成一个数据处理脚本，我会这样描述："写一个Python脚本，读取Excel文件data.xlsx，筛出age列大于30的记录，去掉重复行，把结果保存到filtered_data.xlsx，使用pandas库。"注意我连"使用pandas库"都告诉它，用来限定技术栈。

输入到DeepSeek时，用自然语言描述即可，但有个细节：提示词里最好带上输入输出的示例或字段名。比如"age列"比"某一列"准确得多。下面是一个我实际用过的提示词和生成结果：

import pandas as pd # 读取Excel文件 file_path = 'data.xlsx' data = pd.read_excel(file_path) # 筛选年龄大于30岁的记录 filtered_data = data[data['age'] > 30] # 去除重复行（按所有列去重） filtered_data = filtered_data.drop_duplicates() # 保存结果为新的Excel文件 new_file_path = 'filtered_data.xlsx' filtered_data.to_excel(new_file_path, index=False)

这段代码的逻辑很好理解：用pd.read_excel读入数据，用布尔索引完成条件筛选，再用drop_duplicates去重，最后写出。参数说明一下：drop_duplicates默认按所有列判断重复，如果你只想按某个ID列去重，要传subset参数；to_excel里index=False的意思是写出时不带行号索引，这个参数很容易被漏掉，漏了Excel里会多一列Unnamed。

生成代码后的检查，我一般分三步走：第一步看变量名和函数调用是否和业务语义一致；第二步看异常处理有没有覆盖文件不存在、字段缺失这些常见场景；第三步实际跑一遍，用一小份测试数据验证输出是否符合预期。很多时候DeepSeek生成的代码会把文件路径写死成'your_file.csv'这类占位符，所以替换成真实路径是第一步。

2.3 脚本性能与健壮性优化：向量化、异常处理与日志

生成的脚本往往能跑，但未必高效、未必健壮。我踩过的一个典型坑是：让DeepSeek生成一个处理几十万行数据的脚本，它用了嵌套循环做匹配，结果跑了十分钟还没结束。后来我把它改写成pandas的merge操作，几秒就完成了。所以拿到生成代码后，我会优先检查有没有可以用向量化或内置函数替代的循环。pandas的read_csv、groupby、merge、apply，这些都比手写Python循环快一个数量级。遇到数据处理脚本，我会直接在提示词里加一句"使用pandas向量化操作，避免for循环"，能少走很多弯路。

健壮性优化是第二个重点。生成脚本默认没有try-except，文件不存在会直接抛FileNotFoundError，数据库连不上会让Job直接挂掉。我一般会让DeepSeek补上异常处理，或者手动加包裹。比如读取Excel文件的场景，我通常会写成这样：

import pandas as pd try: file_path = 'data.xlsx' data = pd.read_excel(file_path) filtered_data = data[data['age'] > 30] filtered_data.to_excel('filtered_data.xlsx', index=False) except FileNotFoundError: print(f"Error: File {file_path} not found.") except KeyError: print("Error: Column 'age' does not exist in the data.") except Exception as e: print(f"An unexpected error occurred: {e}")

这段代码把两类最常见的异常单独捕获：文件不存在和字段缺失，前者是因为路径配置错误很常见，后者是因为字段名写错或源数据变更很常见。最后的通用Exception兜底，防止其他意外导致脚本无声失败。注意异常信息里带上了具体变量名，排错时能直接看到是哪个文件或哪个字段出了问题。

日志也是健壮性的重要部分，尤其是部署到定时任务里的脚本。我习惯在关键步骤加print或者logging输出，比如"已删除N条过期记录""库存更新完成，影响行数M"，这样第二天看日志就能判断脚本是否正常执行。DeepSeek生成的代码默认不带日志，我会在检查阶段补上。对于跑批类脚本，建议把所有输出追加到一个文件里，而不是直接打在终端，因为定时任务里没人盯着终端。

3. 自动化生成单元测试：框架选型与提示词设计

3.1 先选对框架：Python的unittest/pytest与Java的JUnit/TestNG

让AI生成单元测试之前，必须先确定用哪个测试框架。同一个需求，用unittest和pytest的生成结果完全不同，提示词里不写清楚框架，DeepSeek默认出来的可能不是你们项目里想要的风格。Python里最常见的是unittest和pytest。unittest是标准库，零依赖，结构规范，适合要求严格的团队和基础教学；pytest语法更简洁，支持自动发现测试文件，断言直接用assert，插件生态丰富，现在大多数项目都偏向pytest。我在让DeepSeek生成测试时，通常会提示"使用pytest风格，测试文件名为test_xxx.py，使用assert断言"。

Java这边主要是JUnit和TestNG。JUnit 5是目前的主流，注解和断言设计得很干净，和Spring Boot项目配合也好。TestNG的优势在于数据驱动、参数化和并行执行，适合复杂测试场景。如果你的项目用Maven管理，JUnit是默认选择；如果用TestNG，需要额外配置文件。DeepSeek对JUnit 5的掌握程度比JUnit 4好，如果项目还在用JUnit 4，提示词里要明确说明。下面是两种Python框架的对比表：

选框架不只看流行度，还要看你的项目已经用什么。如果你的项目已经有一堆unittest的测试用例，就别让DeepSeek生成pytest风格的，否则两个框架并存会让CI配置变得很啰嗦。我一般会先看一眼项目根目录的requirements.txt和pytest.ini，确认现有测试风格再写提示词。

3.2 让DeepSeek生成测试用例的输入方式

生成单元测试时，给DeepSeek的输入要包含两部分：被测代码本身，以及测试目标描述。代码可以是函数、类或整个模块，放进提示词时我会把函数定义连同docstring一起贴进去，这样模型能理解参数含义。比如下面这个订单金额计算函数，我贴进去并附上说明后，DeepSeek生成的测试用例几乎覆盖了所有正常分支。

def calculate_order_total(order_items, discount=0, shipping_fee=10): """计算订单总金额。 参数: order_items: list of dict，每个dict含price和quantity字段 discount: float，0到1之间，表示折扣比例 shipping_fee: float，运费 返回: float，订单总金额 """ total = sum(item["price"] * item["quantity"] for item in order_items) total = total * (1 - discount) if shipping_fee > 0: total += shipping_fee return total

然后我给出的测试目标是这样一句话："为calculate_order_total生成pytest单元测试，覆盖正常订单、折扣订单、免运费订单，以及订单为空时的情况。"生成的代码大致如下：

import pytest from order import calculate_order_total def test_normal_order(): order_items = [{"price": 10, "quantity": 2}, {"price": 20, "quantity": 1}] assert calculate_order_total(order_items) == 2 * 10 + 20 + 10 def test_order_with_discount(): order_items = [{"price": 10, "quantity": 2}, {"price": 20, "quantity": 1}] result = calculate_order_total(order_items, discount=0.1) assert result == pytest.approx((2 * 10 + 20) * 0.9 + 10) def test_free_shipping(): order_items = [{"price": 10, "quantity": 2}, {"price": 20, "quantity": 1}] assert calculate_order_total(order_items, shipping_fee=0) == 2 * 10 + 20 def test_empty_order(): assert calculate_order_total([], shipping_fee=0) == 0

这段代码里几个细节值得注意：test_order_with_discount用了pytest.approx来处理浮点精度问题，这是AI生成代码里难得做对的地方，因为0.1在二进制里是无限循环小数，直接等号比较可能失败；test_empty_order覆盖了边界条件。但这里有个隐藏风险：discount参数没有做范围校验，如果传了负数或大于1的数，函数会给出错误结果，AI生成的测试不会主动测这种情况，需要我们自己在检查阶段补上。

除了函数代码，我还会把被测类的构造函数参数、依赖的外部对象写清楚。AI不知道你的数据库Mock怎么搭，如果被测函数需要连接数据库，你直接用真实连接会让测试变慢还不稳定。这种情况我一般会在提示词里加一句"使用mock替换数据库连接"，DeepSeek就会生成monkeypatch或unittest.mock的代码。

3.3 覆盖率提升：边界条件、异常路径与分支覆盖

AI生成的测试用例，最常见的问题是"快乐路径全覆盖，边界和异常路径一片空白"。这不能怪模型，因为你给的提示词就是围绕正常场景写的。想让覆盖率上去，得在提示词里主动点名要测边界和异常。

边界条件包括：输入为空、只有一个元素、达到最大值、恰好是0、字符串为空、列表长度超限。异常路径包括：除数为零、文件不存在、网络超时、非法参数类型。分支覆盖更多是针对if-else逻辑，要求每个分支至少有一个用例。我会把这三类要求拆成三条提示，让DeepSeek分别生成，比一次性给一个长提示词效果稳定。

看一个分支覆盖的例子。假设有个函数check_number，根据正负返回不同字符串，DeepSeek默认会生成三个正常分支的测试：正数、负数、零。但如果我们要求它补充边界和异常，它会再生成一个传None的用例，验证是否抛出TypeError。对于这类简单函数，AI做得还算不错。但对于复杂业务函数，比如上面那个calculate_order_total，它不会自己想到测discount=1（折扣100%时总金额为0）、discount负数、order_items中包含quantity为0项等情况。这些业务层面的边界，只有了解业务的人能提出来，所以我的习惯是：AI生成第一版测试，我只删掉明显错误的，然后人工再补3到5条针对业务规则的用例。这套组合拳下来，覆盖率从40%提到80%左右是常见的。

覆盖率工具方面，Python推荐pytest-cov，跑完之后会输出行覆盖率报告。注意行覆盖率不等于分支覆盖率，后者需要配合coverage的branch=True参数。我一般会把分支覆盖的目标写入CI配置，作为合并代码的硬性门槛。别指望AI一次生成就达到你的覆盖标准，把它当脚手架，你是最终的质检员。

4. 避坑与常见问题：生成结果不理想时的排查路径

4.1 现象：生成的代码不符合预期，逻辑和需求对不上

我遇到过最典型的情况是：让DeepSeek写一个"清理过期商品"的脚本，结果它把过期判断写成了expiration_date > current_date，也就是删了还没过期的商品，保留了过期商品。原因很简单，提示词里没有明确"过期日期小于当前日期才是过期"，模型只能靠自己的常识猜。这种逻辑反了个方向的错误，如果直接跑生产，后果很严重。

解决方法是把需求拆成可执行的自然语言五要素：输入是什么、处理规则是什么、输出是什么、依赖什么库、有什么特殊要求。我常用一个模板："用{python}写一个{脚本/函数}，读取{路径}，对{字段}执行{规则}，输出{结果}，注意{边界条件}。"还是用上面这个例子，正确的提示词应该是："写一个Python脚本，连接MySQL，查询products表中expiration_date小于当前日期的记录并删除，删除前先备份到backup表。"把比较方向"小于"写进去，模型就不会擅自改逻辑。如果第一版不对，不要反复用同一句提示词硬问，而是把AI输出的代码里错误的地方直接指出来，说"第X行逻辑错了，应该改为..."，这样引导比重新生成更高效。我试过用这种指错式对话，第二版基本就对了。

4.2 现象：生成的单元测试覆盖不全面，跑完覆盖率只有30%

用pytest --cov跑一遍生成的测试，经常发现覆盖率数字惨不忍睹。原因不是AI懒，而是你没有告诉它需要覆盖边界和异常。AI默认会按最常见的输入组合生成用例，比如一个除法函数，它只测了正常的3/2=1.5，却没有测除数为0时抛异常的场景。

我的解决方法是两层。第一层，提示词里显式列出场景清单："覆盖以下场景：空输入、单元素、最大值、除零、类型错误、if-else的每个分支。"第二层，先把AI生成的第一版测试跑出覆盖率报告，然后把未覆盖的行号反馈到提示词里，比如"请补充覆盖order.py第24行到第27行的用例"。这个反馈式生成比整体重拍准确得多，因为模型能精准定位缺的是什么。我一般会循环两轮，第一轮生成基础用例，第二轮针对未覆盖行补漏，第三轮就只做人工review了。注意覆盖率数字不要盲目追求100%，业务核心模块覆盖到80%以上、工具类函数覆盖到60%，对大多数项目来说已经能挡住大部分回归问题。

4.3 现象：生成的脚本能跑但有安全风险，比如SQL拼接、硬编码密码

这是我最警惕的一个坑。AI训练数据里有大量教程代码，很多教程为了演示方便会把密码写进代码，或者用字符串拼接SQL。生成脚本如果直接照搬，就会把安全隐患带进项目。我亲眼见过同事让DeepSeek生成的数据库脚本，直接用了"password='123456'"这种硬编码，还提交到了git仓库，好在是内部平台。

代码检查阶段必须做两个动作：一是全局搜索password、token、api_key这类词，发现硬编码就改成从环境变量或配置中心读取；二是检查所有数据库操作是否用了参数化查询。举个例子，AI可能生成这样的代码：

# 不安全的写法：直接拼接SQL query = "SELECT * FROM users WHERE name = '" + username + "'"

这种写法在AI输出里出现的概率不低，如果username是用户输入，就会被SQL注入。我会让DeepSeek改成参数化写法，或者自己改成：

# 安全的参数化查询 query = "SELECT * FROM users WHERE name = %s" cursor.execute(query, (username,))

这个改动成本很低，但能堵住一个高危漏洞。另外，调外部API时如果涉及密钥，千万不能让AI把真实密钥写进代码，哪怕是非公开仓库也有泄露风险。我的习惯是让DeepSeek代码里用os.getenv占位，运行前再注入。凡是生成结果里出现"your_password"这类占位符，都要在提交前全局搜索一遍。

4.4 现象：DeepSeek服务不稳定，或模型更新后生成结果风格变化大

依赖外部AI服务做开发，难免遇到服务超时或模型版本更新导致的输出飘移。有一次我早上用的提示词，下午再提交一次，生成的代码结构完全不同，一个用了循环，一个用了列表推导式，虽然都能跑，但和我们项目的代码规范明显不一致。原因不是玄学，而是模型在服务端随时可能更新，同样的输入不会保证同样的输出。

我的应对策略是把AI生成当作一个可复现的辅助步骤，而不是黑匣子。具体来说：把每次高效的提示词、生成版本、人工修改记录存进团队的知识库，形成提示词模板。这样即使模型更新，跑出来的结果变了，你也能对照模板快速发现问题。对于重要脚本，我还会在文件头部注释里写明生成工具和日期，方便回溯。另外，涉及生产环境的脚本，即使AI生成也要走和手写代码一样的评审和测试流程，不要因为来源是AI就降低标准。宁可晚一天上线，也不能把一个没经过review的生成代码直接推到主分支。

5. 把AI生成代码接入工作流：验证、版本管理与团队协作

最后聊聊怎么让这套方法稳定落地。我现在的项目组已经形成一套约定：AI生成的脚本和测试，必须先过"三查三跑"流程。三查是查硬编码密钥、查SQL拼接、查死循环风险；三跑是跑单测、跑静态检查（如flake8）、跑一次真实小数据验证。这套流程刚开始显得繁琐，但用久了会发现，它其实是把AI输出的不确定性隔离在开发环境里，不让它直接污染主分支。

版本管理上，AI生成的代码和手写代码没有区别，一定要走git分支和Pull Request。我会在提交信息里标注"AI-generated with review"，这样代码review时评审者会额外关注边界处理和安全性。团队协作时，提示词模板是最大的资产。我们把常用的脚本提示词、测试提示词整理成Markdown模板，新人来了照着用，效率直接翻倍。比如"生成一个pandas数据处理脚本，要求向量化、带异常处理、输出日志"这句话，已经成了我们组里数据清洗任务的默认起点。

我还有一个习惯：每次AI生成结果不好时，我不去抱怨AI不聪明，而是先复盘提示词里缺了哪个信息，是字段名没给，还是比较方向没说，还是场景清单不够完整。从那以后，我每个提示词都强制写入"输入输出示例+边界条件+禁止事项"，生成结果的返工率明显下降。希望帮到你。

本文还有配套的精品资源，点击获取