简介这份PDF资料面向希望借助AI提升编码效率的开发者与测试人员系统讲解如何用DeepSeek自动化生成可执行脚本与单元测试解决手动编码耗时、测试覆盖不足等痛点。内容涵盖DeepSeek的多语言支持、智能补全与代码生成能力并展开系统管理、数据处理、自动化部署等脚本的生成流程与优化技巧同时介绍单元测试框架选择、测试用例生成及覆盖率提升方法还结合实践案例与挑战应对策略。资源包共1个PDF文件大小约1.75MB结构完整、目录清晰便于按章节检索学习。目前已有421人学习下载适合初中级开发者快速上手AI辅助开发也能为团队引入自动化测试与持续集成提供可落地的参考思路。1. 代码生产力革命当脚本和单测都能被自动生成如果你最近在团队里听到有人讨论「代码生产力革命」大概率绕不开一个具体场景把一段自然语言需求丢给模型让它直接吐出可运行的脚本和配套单元测试。标题里的 DeepSeek 就是当前被频繁拿来干这件事的模型之一而「可执行脚本 单元测试」这两个词才是真正的重点——前者决定能不能跑后者决定敢不敢改。我所在的团队维护着一批数据清洗和接口联调脚本过去写一个 CSV 字段归一化脚本加上边界用例测试熟练工也要四十分钟。引入模型生成后初稿压缩到五分钟以内剩下的时间全花在审查和补边界上。这篇文章不讲空泛的「AI 提效」而是把「用 DeepSeek 生成可执行脚本与单元测试」拆成可复现的流程提示词怎么写、生成结果怎么验、参数怎么调、哪些坑我踩过。适合已经会写 Python 或 Shell、但还没把模型生成纳入日常工具链的工程师也适合想给团队定一套生成规范的技术负责人。2. 先搞清楚 DeepSeek 生成脚本的边界在哪2.1 它擅长什么、不擅长什么把 DeepSeek 当成一个「见过大量开源代码的实习生」来定位最准确。它擅长的是模式化任务文件读写、字符串处理、正则提取、HTTP 请求封装、pytest 用例骨架、参数校验。这些任务的共同点是训练语料里出现频率极高模型能稳定复现结构。它不擅长的是强上下文依赖的任务需要读取你本地某个私有库的返回值结构、依赖特定版本的冷门 API、涉及复杂业务状态机的脚本。这类任务模型会「自信地编造」一个看起来合理但跑不通的接口。我的经验是凡是需要模型「猜」你环境的地方都要在提示词里显式喂给它否则生成结果一定翻车。另一个边界是长度。单文件脚本控制在 150 行以内模型生成质量最稳定超过 300 行后后半段容易出现变量名前后不一致、函数调用参数错位。常见做法是拆成多个小脚本分别生成再人工拼接。2.2 生成流程的四个阶段我把整个流程固定成四步每步都有明确的输入输出避免「一把梭」导致返工。第一步需求结构化。把「帮我写个脚本」改写成包含输入、输出、异常处理、依赖库四个字段的说明。第二步生成脚本主体要求模型只输出代码不输出解释。第三步基于脚本反向生成单元测试要求覆盖正常路径、边界值、异常输入三类。第四步本地执行验证把报错信息回喂给模型做定向修复。这个流程的价值在于每一步的产物都可检查。如果第一步的需求描述含糊后面三步全是浪费。我一般会花两分钟写需求比直接让模型自由发挥省下至少十分钟的调试时间。2.3 一个最小可复现的生成示例下面这段提示词是我日常用的模板针对「读取 CSV 并做字段归一化」这个任务。# 提示词模板实际使用时作为字符串发给模型 prompt 你是一名资深 Python 工程师。请生成一个可执行脚本要求 1. 输入一个 CSV 文件路径包含列 name, age, email 2. 处理name 去首尾空格age 转为整数非法值置为 Noneemail 转小写 3. 输出清洗后的 CSV写入新路径 4. 异常文件不存在时抛出 FileNotFoundError 并打印友好提示 5. 依赖仅使用标准库 csv 和 argparse 6. 只输出 Python 代码不要任何解释文字 逻辑说明这段提示词的关键在于把「输入、处理、输出、异常、依赖」五个约束全部写死。模型在没有约束时会自由选择 pandas而 pandas 在轻量脚本里是过度依赖。参数说明age 转为整数非法值置为 None这种写法比「处理 age 列」精确得多模型能据此生成 try/except 分支。生成结果拿到后不要急着运行先做一次静态检查看 import 是否都是标准库、看函数入口是否有if __name__ __main__、看异常分支是否真的会触发。这三项能过滤掉大部分低级问题。3. 让单元测试跟着脚本一起生成3.1 反向生成测试的提示词设计脚本生成完紧接着让它生成测试但不要在同一轮对话里让它「顺便写测试」——那样测试往往只覆盖正常路径。正确做法是把生成的脚本作为上下文单独发一轮测试生成请求。# 测试生成提示词 test_prompt 以下是待测脚本的完整代码 {script_code} 请为它生成 pytest 单元测试要求 1. 使用 tmp_path fixture 创建临时 CSV不依赖真实文件 2. 覆盖三类用例正常数据、age 含非法值、文件不存在 3. 每个测试函数只断言一个行为 4. 只输出测试代码 逻辑说明把脚本代码作为变量注入模型能准确知道函数名和参数签名避免测试里调用不存在的函数。参数说明tmp_path fixture是 pytest 内置的临时目录机制用它替代硬编码路径测试才能在任何机器上跑通。每个测试函数只断言一个行为这条约束能防止模型写出一个巨型测试函数出问题时定位困难。3.2 测试用例的三层覆盖策略模型生成的测试通常集中在正常路径需要你手动补两类。我习惯按三层检查层级覆盖目标典型用例正常路径标准输入产出标准输出三列合法数据验证输出文件内容边界值空文件、单行、超长字段空 CSV 应产出空结果不报错异常输入非法类型、缺失文件age 为 abc 应置 None 而非崩溃这张表可以直接作为审查清单。模型生成的测试如果只覆盖第一层就手动补后两层或者把这张表塞进提示词让它按层生成。3.3 本地执行与失败回喂生成完脚本和测试执行命令固定为# 运行测试并显示详细输出 python -m pytest test_clean.py -v --tbshort参数说明-v显示每个用例名称--tbshort让报错堆栈只显示关键行避免刷屏。如果测试失败把完整的报错信息复制回模型附一句「根据以下报错修复脚本只输出修改后的完整代码」。这个回喂循环通常一到两轮就能收敛。需要提醒的是模型修复时可能引入新问题所以每轮回喂后都要重新跑全部测试不能只看失败的那个用例。我吃过这个亏修好了 A 用例B 用例悄悄挂了因为模型改了公共函数的返回值。4. 参数调优与生成质量的关联4.1 温度参数对代码生成的影响调用 DeepSeek 接口时temperature 是影响代码质量最直接的参数。我的实测经验生成脚本主体时用 0.2 到 0.4生成测试用例时用 0.3 到 0.5。温度过低接近 0会导致输出过于保守遇到需要变通的地方直接卡住温度过高超过 0.8会开始编造不存在的库函数。# 调用示例伪代码替换为实际 SDK 调用 response client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: prompt}], temperature0.3, # 脚本生成偏低保证稳定 max_tokens2000, # 单文件脚本足够 top_p0.9 # 配合温度使用控制采样范围 )参数说明max_tokens设太小会导致代码被截断生成到一半就停表现为「函数没写完」。我一般给脚本留 2000给测试留 1500。top_p保持默认 0.9 即可不需要和 temperature 同时大改否则两个参数互相干扰很难判断是哪个导致的质量波动。4.2 提示词里的「负向约束」怎么写正向约束告诉模型要做什么负向约束告诉它不要做什么后者往往更关键。常见的负向约束包括不要使用未在依赖列表里的库、不要生成交互式 input 调用、不要写死绝对路径、不要用 print 代替日志。这些约束不是一次写完的而是踩坑后逐步积累。我维护了一个「禁止清单」每次生成前贴进提示词。比如「不要用 print 代替 logging」这条是因为模型生成的脚本在批量执行时print 输出混在结果里导致下游解析失败。4.3 生成结果的静态检查清单在跑测试之前我会快速过一遍这几项能省下大量调试时间import 是否全部在依赖白名单内是否存在硬编码的绝对路径如/home/user/...异常处理是否只写了except: pass这种吞异常写法函数是否有明确的返回值还是靠副作用变量命名是否前后一致模型常见问题是中途换名这份清单不需要工具肉眼扫一遍三十秒。其中「吞异常」是最危险的模型为了「让代码不报错」经常写except Exception: pass结果错误被静默吃掉排查时毫无线索。5. 避坑生成脚本与单测的五个高频翻车点5.1 现象脚本本地能跑换台机器就报 ModuleNotFoundError原因模型根据训练语料习惯性引入第三方库如 pandas、requests但你的环境没装提示词里也没限制依赖。解决在提示词里显式写「仅使用标准库」或列出允许的库清单生成后检查 import 段。我现在的模板里固定有一句「依赖仅限csv, json, argparse, os, re」超出范围的直接打回重生成。5.2 现象测试全绿但脚本实际输出是错的原因模型生成的测试和脚本「同源」两者对同一个错误理解一致导致测试断言本身写错了。比如脚本把 age 非法值置为 0测试也断言 0两边一起错。解决测试断言必须由人根据需求独立写一遍或者至少人工核对断言值是否符合业务预期。这是最隐蔽的坑因为测试通过会给人虚假的安全感。5.3 现象生成的脚本处理大文件时内存爆掉原因模型默认用readlines()或csv.reader一次性读入全部内容小样本测试没问题生产环境几百 MB 文件直接 OOM。解决在提示词里加「使用流式处理逐行读写不一次性加载全部数据」。生成后检查是否有list(reader)这类全量物化操作。5.4 现象回喂报错后模型把无关代码也改了原因回喂时只给了报错信息模型为了「确保修复」会顺手重构其他部分引入新 bug。解决回喂时明确说「只修改与报错相关的函数其余代码保持原样」并在拿到结果后做 diff 对比确认改动范围可控。我一般用git diff看一眼改动超过十行就警惕。5.5 现象中文注释和变量名混用导致编码报错原因模型生成的中文注释在某些执行环境下编码不一致尤其是 Windows 环境默认 GBK。解决在脚本头部强制声明编码或要求模型「注释用英文」。我倾向于后者因为跨平台协作时英文注释更省事。如果必须中文加# -*- coding: utf-8 -*-并确保文件保存为 UTF-8。6. 把生成流程固化成可复用的技巧走到这里单次生成已经能跑通。但真正提升生产力的是把流程固化让下次生成不用从零写提示词。我的做法是维护一个「生成配置」目录里面放三类文件提示词模板、依赖白名单、静态检查脚本。提示词模板按任务类型分文件处理类、HTTP 请求类、数据校验类。每类模板里预置好该类型的常见约束。比如文件处理类默认带「流式读写、异常捕获、编码声明」三条。下次遇到同类任务改几个字段就能用。依赖白名单是一个纯文本文件列出团队环境里确定存在的库。生成前把它贴进提示词生成后用它做 import 检查。这个白名单要随环境更新否则会拦住合理的依赖。静态检查脚本我写了一个简单的 Python 脚本用 ast 模块解析生成代码检查是否有裸 except、是否有硬编码路径、import 是否在白名单内。跑一次不到一秒比肉眼可靠。# 静态检查脚本核心逻辑 import ast def check_script(code: str, whitelist: set) - list: issues [] tree ast.parse(code) for node in ast.walk(tree): # 检查裸 except if isinstance(node, ast.ExceptHandler) and node.type is None: issues.append(f第{node.lineno}行裸 except会吞掉所有异常) # 检查 import 是否在白名单 if isinstance(node, ast.Import): for alias in node.names: if alias.name.split(.)[0] not in whitelist: issues.append(f第{node.lineno}行未授权依赖 {alias.name}) return issues逻辑说明用 ast 解析而非正则匹配能准确识别语法结构避免误报。参数说明whitelist是允许的顶层包名集合alias.name.split(.)[0]处理import os.path这类写法取顶层包名判断。这个脚本不追求覆盖所有问题只拦最高频的两类够用就行。最后一个习惯每次生成后把「提示词 生成结果 修改记录」存一份到本地笔记。积累十几条后你会发现自己反复在补同样的约束这时候就该把约束固化进模板。模型在进化但你的约束清单才是真正沉淀下来的资产。我现在的模板已经迭代到第七版前六版踩过的坑都变成了模板里的一行约束。希望帮到你。本文还有配套的精品资源点击获取
简介这份PDF资料面向希望借助AI提升编码效率的开发者与测试人员系统讲解如何用DeepSeek自动化生成可执行脚本与单元测试解决手动编码耗时、测试覆盖不足等痛点。内容涵盖DeepSeek的多语言支持、智能补全与代码生成能力并展开系统管理、数据处理、自动化部署等脚本的生成流程与优化技巧同时介绍单元测试框架选择、测试用例生成及覆盖率提升方法还结合实践案例与挑战应对策略。资源包共1个PDF文件大小约1.75MB结构完整、目录清晰便于按章节检索学习。目前已有421人学习下载适合初中级开发者快速上手AI辅助开发也能为团队引入自动化测试与持续集成提供可落地的参考思路。1. 代码生产力革命当脚本和单测都能被自动生成如果你最近在团队里听到有人讨论「代码生产力革命」大概率绕不开一个具体场景把一段自然语言需求丢给模型让它直接吐出可运行的脚本和配套单元测试。标题里的 DeepSeek 就是当前被频繁拿来干这件事的模型之一而「可执行脚本 单元测试」这两个词才是真正的重点——前者决定能不能跑后者决定敢不敢改。我所在的团队维护着一批数据清洗和接口联调脚本过去写一个 CSV 字段归一化脚本加上边界用例测试熟练工也要四十分钟。引入模型生成后初稿压缩到五分钟以内剩下的时间全花在审查和补边界上。这篇文章不讲空泛的「AI 提效」而是把「用 DeepSeek 生成可执行脚本与单元测试」拆成可复现的流程提示词怎么写、生成结果怎么验、参数怎么调、哪些坑我踩过。适合已经会写 Python 或 Shell、但还没把模型生成纳入日常工具链的工程师也适合想给团队定一套生成规范的技术负责人。2. 先搞清楚 DeepSeek 生成脚本的边界在哪2.1 它擅长什么、不擅长什么把 DeepSeek 当成一个「见过大量开源代码的实习生」来定位最准确。它擅长的是模式化任务文件读写、字符串处理、正则提取、HTTP 请求封装、pytest 用例骨架、参数校验。这些任务的共同点是训练语料里出现频率极高模型能稳定复现结构。它不擅长的是强上下文依赖的任务需要读取你本地某个私有库的返回值结构、依赖特定版本的冷门 API、涉及复杂业务状态机的脚本。这类任务模型会「自信地编造」一个看起来合理但跑不通的接口。我的经验是凡是需要模型「猜」你环境的地方都要在提示词里显式喂给它否则生成结果一定翻车。另一个边界是长度。单文件脚本控制在 150 行以内模型生成质量最稳定超过 300 行后后半段容易出现变量名前后不一致、函数调用参数错位。常见做法是拆成多个小脚本分别生成再人工拼接。2.2 生成流程的四个阶段我把整个流程固定成四步每步都有明确的输入输出避免「一把梭」导致返工。第一步需求结构化。把「帮我写个脚本」改写成包含输入、输出、异常处理、依赖库四个字段的说明。第二步生成脚本主体要求模型只输出代码不输出解释。第三步基于脚本反向生成单元测试要求覆盖正常路径、边界值、异常输入三类。第四步本地执行验证把报错信息回喂给模型做定向修复。这个流程的价值在于每一步的产物都可检查。如果第一步的需求描述含糊后面三步全是浪费。我一般会花两分钟写需求比直接让模型自由发挥省下至少十分钟的调试时间。2.3 一个最小可复现的生成示例下面这段提示词是我日常用的模板针对「读取 CSV 并做字段归一化」这个任务。# 提示词模板实际使用时作为字符串发给模型 prompt 你是一名资深 Python 工程师。请生成一个可执行脚本要求 1. 输入一个 CSV 文件路径包含列 name, age, email 2. 处理name 去首尾空格age 转为整数非法值置为 Noneemail 转小写 3. 输出清洗后的 CSV写入新路径 4. 异常文件不存在时抛出 FileNotFoundError 并打印友好提示 5. 依赖仅使用标准库 csv 和 argparse 6. 只输出 Python 代码不要任何解释文字 逻辑说明这段提示词的关键在于把「输入、处理、输出、异常、依赖」五个约束全部写死。模型在没有约束时会自由选择 pandas而 pandas 在轻量脚本里是过度依赖。参数说明age 转为整数非法值置为 None这种写法比「处理 age 列」精确得多模型能据此生成 try/except 分支。生成结果拿到后不要急着运行先做一次静态检查看 import 是否都是标准库、看函数入口是否有if __name__ __main__、看异常分支是否真的会触发。这三项能过滤掉大部分低级问题。3. 让单元测试跟着脚本一起生成3.1 反向生成测试的提示词设计脚本生成完紧接着让它生成测试但不要在同一轮对话里让它「顺便写测试」——那样测试往往只覆盖正常路径。正确做法是把生成的脚本作为上下文单独发一轮测试生成请求。# 测试生成提示词 test_prompt 以下是待测脚本的完整代码 {script_code} 请为它生成 pytest 单元测试要求 1. 使用 tmp_path fixture 创建临时 CSV不依赖真实文件 2. 覆盖三类用例正常数据、age 含非法值、文件不存在 3. 每个测试函数只断言一个行为 4. 只输出测试代码 逻辑说明把脚本代码作为变量注入模型能准确知道函数名和参数签名避免测试里调用不存在的函数。参数说明tmp_path fixture是 pytest 内置的临时目录机制用它替代硬编码路径测试才能在任何机器上跑通。每个测试函数只断言一个行为这条约束能防止模型写出一个巨型测试函数出问题时定位困难。3.2 测试用例的三层覆盖策略模型生成的测试通常集中在正常路径需要你手动补两类。我习惯按三层检查层级覆盖目标典型用例正常路径标准输入产出标准输出三列合法数据验证输出文件内容边界值空文件、单行、超长字段空 CSV 应产出空结果不报错异常输入非法类型、缺失文件age 为 abc 应置 None 而非崩溃这张表可以直接作为审查清单。模型生成的测试如果只覆盖第一层就手动补后两层或者把这张表塞进提示词让它按层生成。3.3 本地执行与失败回喂生成完脚本和测试执行命令固定为# 运行测试并显示详细输出 python -m pytest test_clean.py -v --tbshort参数说明-v显示每个用例名称--tbshort让报错堆栈只显示关键行避免刷屏。如果测试失败把完整的报错信息复制回模型附一句「根据以下报错修复脚本只输出修改后的完整代码」。这个回喂循环通常一到两轮就能收敛。需要提醒的是模型修复时可能引入新问题所以每轮回喂后都要重新跑全部测试不能只看失败的那个用例。我吃过这个亏修好了 A 用例B 用例悄悄挂了因为模型改了公共函数的返回值。4. 参数调优与生成质量的关联4.1 温度参数对代码生成的影响调用 DeepSeek 接口时temperature 是影响代码质量最直接的参数。我的实测经验生成脚本主体时用 0.2 到 0.4生成测试用例时用 0.3 到 0.5。温度过低接近 0会导致输出过于保守遇到需要变通的地方直接卡住温度过高超过 0.8会开始编造不存在的库函数。# 调用示例伪代码替换为实际 SDK 调用 response client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: prompt}], temperature0.3, # 脚本生成偏低保证稳定 max_tokens2000, # 单文件脚本足够 top_p0.9 # 配合温度使用控制采样范围 )参数说明max_tokens设太小会导致代码被截断生成到一半就停表现为「函数没写完」。我一般给脚本留 2000给测试留 1500。top_p保持默认 0.9 即可不需要和 temperature 同时大改否则两个参数互相干扰很难判断是哪个导致的质量波动。4.2 提示词里的「负向约束」怎么写正向约束告诉模型要做什么负向约束告诉它不要做什么后者往往更关键。常见的负向约束包括不要使用未在依赖列表里的库、不要生成交互式 input 调用、不要写死绝对路径、不要用 print 代替日志。这些约束不是一次写完的而是踩坑后逐步积累。我维护了一个「禁止清单」每次生成前贴进提示词。比如「不要用 print 代替 logging」这条是因为模型生成的脚本在批量执行时print 输出混在结果里导致下游解析失败。4.3 生成结果的静态检查清单在跑测试之前我会快速过一遍这几项能省下大量调试时间import 是否全部在依赖白名单内是否存在硬编码的绝对路径如/home/user/...异常处理是否只写了except: pass这种吞异常写法函数是否有明确的返回值还是靠副作用变量命名是否前后一致模型常见问题是中途换名这份清单不需要工具肉眼扫一遍三十秒。其中「吞异常」是最危险的模型为了「让代码不报错」经常写except Exception: pass结果错误被静默吃掉排查时毫无线索。5. 避坑生成脚本与单测的五个高频翻车点5.1 现象脚本本地能跑换台机器就报 ModuleNotFoundError原因模型根据训练语料习惯性引入第三方库如 pandas、requests但你的环境没装提示词里也没限制依赖。解决在提示词里显式写「仅使用标准库」或列出允许的库清单生成后检查 import 段。我现在的模板里固定有一句「依赖仅限csv, json, argparse, os, re」超出范围的直接打回重生成。5.2 现象测试全绿但脚本实际输出是错的原因模型生成的测试和脚本「同源」两者对同一个错误理解一致导致测试断言本身写错了。比如脚本把 age 非法值置为 0测试也断言 0两边一起错。解决测试断言必须由人根据需求独立写一遍或者至少人工核对断言值是否符合业务预期。这是最隐蔽的坑因为测试通过会给人虚假的安全感。5.3 现象生成的脚本处理大文件时内存爆掉原因模型默认用readlines()或csv.reader一次性读入全部内容小样本测试没问题生产环境几百 MB 文件直接 OOM。解决在提示词里加「使用流式处理逐行读写不一次性加载全部数据」。生成后检查是否有list(reader)这类全量物化操作。5.4 现象回喂报错后模型把无关代码也改了原因回喂时只给了报错信息模型为了「确保修复」会顺手重构其他部分引入新 bug。解决回喂时明确说「只修改与报错相关的函数其余代码保持原样」并在拿到结果后做 diff 对比确认改动范围可控。我一般用git diff看一眼改动超过十行就警惕。5.5 现象中文注释和变量名混用导致编码报错原因模型生成的中文注释在某些执行环境下编码不一致尤其是 Windows 环境默认 GBK。解决在脚本头部强制声明编码或要求模型「注释用英文」。我倾向于后者因为跨平台协作时英文注释更省事。如果必须中文加# -*- coding: utf-8 -*-并确保文件保存为 UTF-8。6. 把生成流程固化成可复用的技巧走到这里单次生成已经能跑通。但真正提升生产力的是把流程固化让下次生成不用从零写提示词。我的做法是维护一个「生成配置」目录里面放三类文件提示词模板、依赖白名单、静态检查脚本。提示词模板按任务类型分文件处理类、HTTP 请求类、数据校验类。每类模板里预置好该类型的常见约束。比如文件处理类默认带「流式读写、异常捕获、编码声明」三条。下次遇到同类任务改几个字段就能用。依赖白名单是一个纯文本文件列出团队环境里确定存在的库。生成前把它贴进提示词生成后用它做 import 检查。这个白名单要随环境更新否则会拦住合理的依赖。静态检查脚本我写了一个简单的 Python 脚本用 ast 模块解析生成代码检查是否有裸 except、是否有硬编码路径、import 是否在白名单内。跑一次不到一秒比肉眼可靠。# 静态检查脚本核心逻辑 import ast def check_script(code: str, whitelist: set) - list: issues [] tree ast.parse(code) for node in ast.walk(tree): # 检查裸 except if isinstance(node, ast.ExceptHandler) and node.type is None: issues.append(f第{node.lineno}行裸 except会吞掉所有异常) # 检查 import 是否在白名单 if isinstance(node, ast.Import): for alias in node.names: if alias.name.split(.)[0] not in whitelist: issues.append(f第{node.lineno}行未授权依赖 {alias.name}) return issues逻辑说明用 ast 解析而非正则匹配能准确识别语法结构避免误报。参数说明whitelist是允许的顶层包名集合alias.name.split(.)[0]处理import os.path这类写法取顶层包名判断。这个脚本不追求覆盖所有问题只拦最高频的两类够用就行。最后一个习惯每次生成后把「提示词 生成结果 修改记录」存一份到本地笔记。积累十几条后你会发现自己反复在补同样的约束这时候就该把约束固化进模板。模型在进化但你的约束清单才是真正沉淀下来的资产。我现在的模板已经迭代到第七版前六版踩过的坑都变成了模板里的一行约束。希望帮到你。本文还有配套的精品资源点击获取
能视为闭环吗？数学等价与物理反馈的本质区别)
