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 Composeweb服务依赖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, indexFalse)这段代码的逻辑很好理解用pd.read_excel读入数据用布尔索引完成条件筛选再用drop_duplicates去重最后写出。参数说明一下drop_duplicates默认按所有列判断重复如果你只想按某个ID列去重要传subset参数to_excel里indexFalse的意思是写出时不带行号索引这个参数很容易被漏掉漏了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, indexFalse) except FileNotFoundError: print(fError: File {file_path} not found.) except KeyError: print(Error: Column age does not exist in the data.) except Exception as e: print(fAn 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框架的对比表对比项unittestpytest来源Python标准库第三方库需pip安装测试发现需要手动加载或特定命名按test_前缀自动发现断言方式self.assertXXX方法原生assert简洁夹具支持setUp/tearDownfixture机制更灵活报告输出简单文本插件扩展可用pytest-html选框架不只看流行度还要看你的项目已经用什么。如果你的项目已经有一堆unittest的测试用例就别让DeepSeek生成pytest风格的否则两个框架并存会让CI配置变得很啰嗦。我一般会先看一眼项目根目录的requirements.txt和pytest.ini确认现有测试风格再写提示词。3.2 让DeepSeek生成测试用例的输入方式生成单元测试时给DeepSeek的输入要包含两部分被测代码本身以及测试目标描述。代码可以是函数、类或整个模块放进提示词时我会把函数定义连同docstring一起贴进去这样模型能理解参数含义。比如下面这个订单金额计算函数我贴进去并附上说明后DeepSeek生成的测试用例几乎覆盖了所有正常分支。def calculate_order_total(order_items, discount0, shipping_fee10): 计算订单总金额。 参数: order_items: list of dict每个dict含price和quantity字段 discount: float0到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, discount0.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_fee0) 2 * 10 20 def test_empty_order(): assert calculate_order_total([], shipping_fee0) 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它不会自己想到测discount1折扣100%时总金额为0、discount负数、order_items中包含quantity为0项等情况。这些业务层面的边界只有了解业务的人能提出来所以我的习惯是AI生成第一版测试我只删掉明显错误的然后人工再补3到5条针对业务规则的用例。这套组合拳下来覆盖率从40%提到80%左右是常见的。覆盖率工具方面Python推荐pytest-cov跑完之后会输出行覆盖率报告。注意行覆盖率不等于分支覆盖率后者需要配合coverage的branchTrue参数。我一般会把分支覆盖的目标写入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/21.5却没有测除数为0时抛异常的场景。我的解决方法是两层。第一层提示词里显式列出场景清单覆盖以下场景空输入、单元素、最大值、除零、类型错误、if-else的每个分支。第二层先把AI生成的第一版测试跑出覆盖率报告然后把未覆盖的行号反馈到提示词里比如请补充覆盖order.py第24行到第27行的用例。这个反馈式生成比整体重拍准确得多因为模型能精准定位缺的是什么。我一般会循环两轮第一轮生成基础用例第二轮针对未覆盖行补漏第三轮就只做人工review了。注意覆盖率数字不要盲目追求100%业务核心模块覆盖到80%以上、工具类函数覆盖到60%对大多数项目来说已经能挡住大部分回归问题。4.3 现象生成的脚本能跑但有安全风险比如SQL拼接、硬编码密码这是我最警惕的一个坑。AI训练数据里有大量教程代码很多教程为了演示方便会把密码写进代码或者用字符串拼接SQL。生成脚本如果直接照搬就会把安全隐患带进项目。我亲眼见过同事让DeepSeek生成的数据库脚本直接用了password123456这种硬编码还提交到了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不聪明而是先复盘提示词里缺了哪个信息是字段名没给还是比较方向没说还是场景清单不够完整。从那以后我每个提示词都强制写入输入输出示例边界条件禁止事项生成结果的返工率明显下降。希望帮到你。本文还有配套的精品资源点击获取