首页/新闻资讯/正文详情

高校软著申请:著作权人归属与材料避坑指南

发布时间:2026/9/25 4:46:21 来源:云帆数科 栏目:资讯中心
高校软著申请:著作权人归属与材料避坑指南
高校学生做软著申请这件事看起来只是填几张表、交一份代码但真正卡住人的往往不是技术而是著作权人到底写谁。我带过几届学生的创新创业项目也帮实验室整理过一批软著材料发现一个很普遍的现象很多同学闷头把代码写完、说明书排版好结果到提交那一刻才发现——著作权人填的是自己但项目是学校的经费支持的或者反过来学校要求单独持有而学生想把自己名字加上去。这两种情况对应的材料准备、签章流程、后续权益归属完全不一样。这篇内容就是把这套东西讲透尤其是“学校单独持有”和“学校个人共同持有”这两条路径分别要注意什么、材料怎么准备、哪些坑一踩就退回。适合正在准备软著的高校学生、刚进实验室要帮导师整理材料的低年级同学以及带学生做项目的老师参考。1. 先把著作权人这件事想清楚再动手写代码1.1 为什么著作权人填错是最致命的错误软著申请里著作权人这一栏决定了这个软件的法律归属。很多同学以为这只是个“署名”问题填谁都行实际上它直接影响到后续的权益分配、成果认定、甚至毕业时的材料审核。我见过最典型的一个案例一个学生用实验室的设备、数据和导师的课题经费开发了一套数据处理工具申请时顺手把著作权人写成了自己。结果学校科研管理部门在成果统计时发现这个软著不在学校名下无法计入课题结题材料最后只能走著作权人变更流程白白多花了两个月。这里要区分两个概念开发者和著作权人。开发者是实际写代码的人著作权人是法律上拥有这个软件权利的主体。对于高校学生来说如果开发过程中使用了学校的物质技术条件比如实验室设备、学校购买的开发工具、导师课题经费那么按照大多数高校的科研管理规定这个软件的著作权应当归属学校或者至少是学校与个人共有。具体怎么定取决于你所在学校的规定和项目的资金来源。提示在动手写代码之前先去学校科研处或知识产权管理部门问清楚一件事——你这个项目属于哪种情况著作权人应该怎么填。这一步花十分钟能省后面两个月。1.2 学校单独持有 vs 学校个人共同持有差别在哪这两种模式在实际操作中的差异远不止“多写一个名字”那么简单。我把核心区别整理成一张表方便你对照自己的情况对比维度学校单独持有学校个人共同持有著作权人栏填写只填学校全称学校全称 个人姓名签章页要求仅需学校盖章学校盖章 个人签字权益归属全部归学校按约定比例共享成果认定计入学校科研成果双方均可使用学生后续使用需学校授权作为权利人可直接使用申请材料复杂度相对简单多一份共有协议常见适用场景课题经费支持、职务作品自筹资金、学校政策允许共有从实操角度看学校单独持有的流程更简洁因为只需要走学校的盖章流程不需要额外的共有协议。但缺点是学生自己后续如果想把这个软件用于个人项目、创业或者参加某些比赛可能需要学校的书面授权。而学校个人共同持有虽然多了一道手续但学生作为权利人之一对自己的成果有更直接的控制权。我个人的经验是如果你的项目完全是自筹资金、自己利用课余时间开发、没有使用学校的特殊资源那么可以争取共同持有如果项目明确是课题的一部分、用了导师的经费那大概率是学校单独持有这时候不要硬争按规矩来反而顺利。1.3 怎么判断你的项目属于哪一种判断标准其实不复杂问自己三个问题资金来源开发过程中用的钱是学校课题经费、导师项目经费还是你自己掏的资源使用有没有用到学校特有的设备、数据、软件授权比如实验室的服务器、学校购买的专业软件、课题组的独家数据集。学校规定你所在学校对软著著作权人有没有明文规定有些学校规定凡是用学校名义申请的项目著作权人必须是学校。如果前两个问题的答案都是“学校的”那基本就是学校单独持有。如果都是“自己的”且学校规定允许那可以走共同持有。如果一个是学校的一个是自己的那就需要和导师、学校科研管理部门沟通看学校的具体政策。注意不同学校的政策差异很大。有的学校对共同持有很开放有的学校则要求凡是涉及学校资源的必须单独持有。不要参考其他学校的做法一定要以你本校的规定为准。2. 申请材料里最容易出问题的几个地方2.1 签章页看起来简单退回率最高签章页是软著申请材料中最容易出问题的一环没有之一。我统计过我们实验室近两年提交的软著申请被退回的材料里有超过一半是因为签章页不合格。具体问题集中在几个方面学校单独持有的情况签章页上只需要盖学校的公章。但这里有个细节——盖的必须是学校公章不是学院章、不是科研处章、不是课题组的章。很多同学拿着材料去学院办公室盖了个学院的章就提交了结果直接被退回。学校公章通常需要到学校办公室或者指定的用章管理部门去盖流程可能需要提前预约、填写用章申请单。学校个人共同持有的情况签章页上既要有学校公章也要有个人签字。个人签字必须是本人手写签名不能打印、不能代签。而且签字的位置要和著作权人栏的填写顺序对应——如果著作权人栏写的是“某某大学、张三”那签章页上学校章在前、个人签字在后顺序不能乱。还有一个容易被忽略的点签章页的版本。软著申请系统里下载的签章页是有固定格式的不能自己用Word重新排一个。有些同学觉得系统下载的签章页排版不好看自己重新做了一个结果格式不符被退回。记住签章页必须用系统生成的版本打印出来签字盖章后再扫描上传。2.2 源代码文档的格式要求源代码文档是另一个高频退回点。软著申请对源代码文档有明确的格式要求但很多同学不看要求就直接把整个项目的代码打包上传了。正确的做法是页数要求源代码文档一般要求提交前30页和后30页共60页。如果代码总页数不足60页就全部提交。每页行数每页不少于50行代码。如果某页不足50行需要调整排版。页眉要求页眉需要包含软件名称和版本号且必须与申请表上填写的一致。代码连续性前30页和后30页必须是连续的代码不能跳着选。去除注释和空行虽然有些说法认为可以保留注释但为了保险起见建议去除大段注释和连续空行让代码更紧凑。我见过有同学提交的源代码文档前30页全是import语句和配置文件后30页全是自动生成的代码结果被审查员认为“不能体现软件的独创性”而退回。所以选代码的时候要有策略——前30页放核心业务逻辑后30页放另一个核心模块让审查员能看到你的软件确实有实质性的技术内容。2.3 软件说明书怎么写才不会被挑毛病软件说明书是展示你软件功能的主要材料也是审查员判断软件是否具有独创性的重要依据。很多同学的说明书写得像产品宣传册全是“本软件功能强大、界面友好”这类空话这种最容易被打回。一份合格的软著说明书应该包含软件概述简要说明软件的开发目的、主要功能、适用领域。运行环境硬件环境CPU、内存、硬盘等、软件环境操作系统、支持软件等。功能模块说明这是核心部分要逐个模块说明功能、操作流程、输入输出。界面截图每个主要功能界面都要有截图截图要清晰、完整能看出软件的实际运行状态。操作步骤配合截图说明具体的操作流程让审查员能理解软件是怎么用的。这里有个实操技巧截图要带真实数据。有些同学为了“干净”把界面截图里的数据都清空了结果审查员看到的是一个个空表格无法判断软件的实际功能。正确的做法是填入一些测试数据让界面看起来是真实运行的状态。当然数据不能涉及真实个人信息或敏感内容。提示说明书的页数没有硬性要求但一般建议在15到30页之间。太短了说不清楚功能太长了审查员也看不完。重点是把核心功能讲透每个功能配一张截图和一段说明。3. 从提交到拿证的完整流程拆解3.1 申请前的准备工作清单在正式提交之前你需要准备好以下材料。我按重要程度排序建议逐项核对软件名称和版本号名称要规范一般格式是“XXX软件V1.0”或“XXX系统V1.0”。版本号一旦确定所有材料上必须完全一致。著作权人信息学校全称必须与公章上的名称完全一致、个人姓名如共同持有。源代码文档按前30页后30页的要求整理好生成PDF。软件说明书包含功能说明和界面截图生成PDF。签章页从系统下载打印后签字盖章再扫描成PDF。身份证明个人身份证复印件如共同持有学校营业执照或事业单位法人证书复印件一般由学校科研管理部门提供。共有协议如果是共同持有需要一份双方签署的著作权归属协议说明各自的权利比例。这份清单看起来简单但每一项都有细节。比如软件名称有些同学提交后想改那就只能撤回重新申请。所以名称一定要在提交前反复确认确保所有材料上的名称、版本号完全一致。3.2 系统填报的细节和常见报错软著申请现在都是通过线上系统填报。系统本身不算复杂但有几个地方容易出错第一著作权人信息的填写。学校名称必须写全称不能写简称。比如“北京大学”不能写成“北大”“清华大学”不能写成“清华”。个人姓名要和身份证一致。如果共同持有两个著作权人之间用顿号或逗号分隔具体看系统的提示。第二软件分类的选择。系统里会让你选择软件的分类比如应用软件、系统软件、嵌入式软件等。这个分类要和你的软件说明书内容匹配。我见过有同学做的是嵌入式设备上的控制程序但分类选了“应用软件”结果审查员认为分类不符被退回。第三开发完成日期和首次发表日期。开发完成日期要合理不能晚于提交日期。首次发表日期如果还没发表就选“未发表”如果已经发表过就填实际日期。这里要注意如果软件已经在GitHub等平台开源那就算已经发表需要如实填写。第四上传文件的格式。系统一般要求PDF格式且单个文件有大小限制。源代码文档和说明书如果太大需要压缩。但压缩的时候要注意保持清晰度不能压到看不清代码和截图。3.3 提交后的审查周期和补正处理提交之后一般会经历这几个阶段形式审查检查材料是否齐全、格式是否符合要求。这个阶段通常1到2周。实质审查审查软件是否具有独创性、是否符合著作权法保护的条件。这个阶段可能需要1到3个月。补正通知如果材料有问题会收到补正通知要求在规定时间内修改并重新提交。发证审查通过后会下发软件著作权登记证书。补正通知是最让人头疼的环节因为一旦收到补正整个周期就要重新算。补正的原因五花八门我遇到过的主要有签章页不清晰、源代码页数不够、说明书截图模糊、著作权人名称与公章不一致等。收到补正通知后一定要仔细看补正意见按要求逐项修改不要自作主张改其他没被指出的地方。注意补正是有时间限制的一般是收到通知后30天内。如果超期未补正申请会被视为撤回。所以提交后要定期登录系统查看状态不要提交完就不管了。4. 那些没人告诉你但很重要的实操经验4.1 关于盖章流程的时间成本学校公章不是随时去随时盖的。大多数高校的用章流程是填写用章申请单→导师签字→学院盖章→科研处审核→学校办公室盖章。这一套流程走下来快则两三天慢则一周以上。如果赶上寒暑假或者学校有重大活动时间更长。我的建议是提前把签章页准备好和其他材料一起走盖章流程。不要等所有材料都准备好了才去盖章因为盖章本身可能成为瓶颈。另外有些学校要求软著申请必须通过科研处统一提交不接受学生个人提交这种情况下盖章流程会和科研处的审核流程合并时间上要留出更多余量。还有一个细节盖章的份数。签章页一般需要盖两份一份用于提交一份自己留存。有些学校还要求科研处留档一份所以最好多准备几份。盖章的时候一次性多盖几份比后面再跑一趟要省事得多。4.2 共同持有时的协议怎么写如果走学校个人共同持有的路径一份清晰的共有协议是必须的。这份协议不需要太复杂但要把几个关键点写清楚双方信息学校全称、个人姓名和身份证号。软件信息软件名称、版本号、开发完成日期。权利归属明确双方各自享有的权利比例比如学校占70%、个人占30%或者双方各占50%。使用权限双方各自在什么范围内可以使用这个软件比如学校用于科研和教学个人用于个人学习和非商业项目。处分规则如果要将软件转让或许可给第三方需要双方同意收益按比例分配。这份协议需要双方签字盖章学校方面一般由科研处或指定部门代表签字。协议的原件要妥善保管申请时提交复印件或扫描件。我个人的经验是协议里的权利比例不要写得太复杂50/50是最简单的也最容易通过审核。如果学校有固定模板直接用学校的模板不要自己另起炉灶。4.3 软著拿到之后还能做什么软著证书拿到手之后它的用途比很多人想象的要广毕业材料很多学校把软著作为创新创业学分或毕业成果的认定材料。评奖评优软著可以作为奖学金评定、优秀毕业生评选的加分项。考研复试软著证书可以证明你的实践能力在复试中是一个加分项。求职简历尤其是应聘软件开发相关岗位软著是实实在在的成果证明。项目结题如果软著是课题的一部分它是结题材料中的重要一项。但要注意软著证书上如果著作权人是学校单独持有你在使用时可能需要提供学校的授权说明。如果是共同持有你作为权利人之一使用起来会更方便。所以回到最开始的那个问题——著作权人怎么填真的会影响你后续的很多操作。4.4 几个高频问题的快问快答问软著申请需要多长时间答顺利的话从提交到拿证一般3到6个月。如果遇到补正时间会延长。建议提前规划不要等到需要用了才申请。问源代码可以用Python、Java等高级语言吗答可以任何编程语言都可以。关键是代码要能体现软件的独创性不能是自动生成的模板代码。问软件说明书里的截图需要是真实运行的吗答最好是真实运行的截图。如果软件还在开发中可以用原型图代替但要在说明书中说明。不过用原型图被退回的概率会高一些。问学校单独持有的软著学生毕业后还能用吗答可以使用但需要获得学校的授权。具体授权流程看学校规定。如果只是用于个人简历展示一般不需要特别授权如果用于商业用途则需要正式授权。问共同持有的软著个人可以单独转让自己的份额吗答可以转让自己的份额但需要通知学校方且学校方一般有优先购买权。具体看共有协议的约定。5. 嵌入式软著和AI相关软著的特殊注意点5.1 嵌入式软著的说明书要突出硬件交互嵌入式软件的软著申请和普通应用软件有一个明显区别说明书里要体现软件与硬件的交互关系。普通应用软件的说明书主要讲界面和功能但嵌入式软件需要说明软件运行在什么硬件平台上、如何控制硬件、硬件接口是什么。具体来说嵌入式软著的说明书应该包含硬件平台说明主控芯片型号、外设模块、通信接口等。软件架构软件的分层结构比如驱动层、中间层、应用层。硬件交互流程软件如何初始化硬件、如何读写硬件寄存器、如何处理硬件中断。关键代码片段在说明书中可以适当引用关键代码展示软件对硬件的控制逻辑。我帮实验室申请过几个嵌入式软著审查员对硬件交互部分的关注度明显高于普通软件。如果说明书里只讲软件功能不讲硬件交互很容易被要求补正。5.2 AI模型相关软著的代码文档怎么选现在越来越多的同学做的是AI模型相关的项目比如训练一个图像分类模型、做一个自然语言处理工具。这类项目的软著申请有一个特殊问题代码文档怎么选。AI项目的代码通常包括数据处理、模型定义、训练循环、推理部署等部分。如果直接把训练脚本提交上去审查员可能看不懂因为训练脚本里大量是超参数配置和循环逻辑。我的建议是前30页放模型定义的核心代码展示你的网络结构设计。后30页放推理部署的代码展示模型如何在实际场景中使用。说明书中重点说明模型的输入输出、应用场景、与普通方法的区别。另外AI项目的说明书里最好有模型效果的展示比如准确率曲线、混淆矩阵、实际推理结果的截图。这些能帮助审查员理解软件的技术价值。提示AI模型的训练数据如果涉及第三方数据集要在说明书中说明数据来源和使用权限。如果数据是自采集的也要说明采集方式。这一点在审查中越来越被重视。5.3 模型软著和传统软著在材料上的差异模型软著和传统软著在材料准备上的差异主要体现在说明书和源代码文档上。传统软著的说明书侧重功能描述和操作流程模型软著的说明书则需要额外说明模型架构用了什么网络结构为什么选这个结构。训练过程训练数据规模、训练参数、训练时长。评估指标用什么指标评估模型效果达到了什么水平。推理流程模型如何接收输入、如何处理、如何输出结果。源代码文档方面模型软著要避免提交大量自动生成的代码比如用工具生成的模型代码因为这类代码缺乏独创性。应该提交手写的、有设计逻辑的核心代码。6. 把软著申请当成项目管理来做6.1 时间线的合理规划软著申请不是一个孤立的任务它应该被纳入你的项目时间线中。我建议的时间规划是项目启动阶段确认著作权人归属了解学校政策。开发中期开始整理源代码文档不要等到代码写完才整理。开发完成撰写软件说明书准备签章页。提交前预留至少两周时间走盖章流程。提交后定期查看系统状态及时处理补正。这个时间线看起来简单但很多同学的问题是把所有事情都堆到最后。代码写完了才想起来要申请软著然后发现盖章要一周、说明书要写三天、源代码要整理两天结果错过了项目结题或者毕业材料提交的截止日期。6.2 材料归档和版本管理软著申请涉及的材料很多而且经常需要修改。我强烈建议建立一个专门的文件夹按以下结构归档软著申请-软件名称/ ├── 01-源代码文档/ │ ├── 源代码-前30页.pdf │ └── 源代码-后30页.pdf ├── 02-软件说明书/ │ └── 说明书-v1.pdf ├── 03-签章页/ │ ├── 签章页-已盖章.pdf │ └── 签章页-空白.pdf ├── 04-身份证明/ ├── 05-共有协议/ └── 06-申请信息记录.md最后那个“申请信息记录”很重要里面记录软件名称、版本号、著作权人、申请日期、受理号、当前状态等信息。软著申请的周期长中间可能经过多人之手有一个记录文件能避免信息混乱。6.3 和学校科研管理部门的沟通技巧和学校科研管理部门打交道有几个技巧第一提前问清楚流程。不要等到材料准备好了才去问而是在项目启动阶段就去了解学校的软著申请流程、需要哪些材料、盖章怎么走。第二准备好问题清单。去科研处之前把你要问的问题列出来比如“著作权人怎么填”“共有协议有没有模板”“盖章需要哪些材料”“提交后多久能拿到证书”。一次性问清楚比来回跑要高效。第三保持耐心。科研管理部门的老师通常要处理很多事务回复可能不及时。提交材料后定期跟进但不要频繁催促。如果遇到问题礼貌地说明情况寻求帮助。第四留好沟通记录。重要的沟通内容比如著作权人归属的确认、盖章流程的说明最好通过邮件或办公系统留痕。万一后续出现争议有记录可查。6.4 一个真实的踩坑复盘最后分享一个我亲身经历的踩坑案例。有一次帮实验室申请一个软著著作权人是学校单独持有。所有材料都准备好了签章页也盖了学校公章提交后等了两个月收到补正通知说“签章页上的学校名称与营业执照上的名称不一致”。我们检查后发现签章页上盖的公章是学校的旧章名称里有一个字和营业执照上的新名称不同。原因是学校前段时间更名了但旧章还在某些部门使用。这个问题我们完全没预料到因为平时大家写学校名称都是用简称或者习惯叫法没人注意过公章上的全称和营业执照上的全称是否完全一致。解决办法是重新盖章用新章。但重新走盖章流程又花了一周多整个申请周期延长了将近一个月。这个坑给我的教训是所有材料上的学校名称必须以营业执照或事业单位法人证书上的名称为准一个字都不能差。包括签章页上的公章、申请表上的著作权人名称、说明书里的学校名称全部要统一。这个经验后来我每次带学生做软著都会强调一遍。看起来是小事但真的会卡住整个流程。软著申请这件事技术含量不高但细节极多。把著作权人这件事想清楚把材料准备做扎实把时间线规划好基本上就不会有大问题。最怕的是闷头做技术忽略了这些流程上的细节最后卡在某个意想不到的环节上。希望这些经验能帮你少走一些弯路。

相关推荐

Windows照片查看器复活指南:四把注册表锁深度解析
Windows照片查看器复活指南:四把注册表锁深度解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/25 4:46:21

VirtualBox增强工具安装与排错:Windows和Linux客户机全攻略
VirtualBox增强工具安装与排错:Windows和Linux客户机全攻略

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/25 4:46:21

Hippy iOS 3.x SDK 集成实战:CocoaPods 接入、HippyBridge 接入代码与多引擎切换
Hippy iOS 3.x SDK 集成实战:CocoaPods 接入、HippyBridge 接入代码与多引擎切换

跨平台移动开发前端 【免费下载链接】Hippy Hippy is designed to easily build cross-platform dynamic apps. 👏 项目地址: https://gitcode.com/gh_mirrors/hi/Hippy 点击查看 免费下载 本文基于 Hippy 官方文档《Hippy iOS 3.x SDK集成指引》及配套… · 2026/9/25 4:46:21

cube-ui Input 输入框组件完整指南:v-model 双向绑定、清空按钮与密码眼睛实战解析
cube-ui Input 输入框组件完整指南:v-model 双向绑定、清空按钮与密码眼睛实战解析

前端UI组件移动开发 【免费下载链接】cube-ui :large_orange_diamond: A fantastic mobile ui lib implement by Vue 项目地址: https://gitcode.com/gh_mirrors/cu/cube-ui 点击查看 免费下载 导读 本文基于 cube-ui 官方中文文档 input.md 并结合仓库源码&#… · 2026/9/25 5:17:57

Eclipse Mosquitto 1.0.1 版本解析:Windows 服务 log_dest 默认值与 Python on_log() 回调修复的源码级解读
Eclipse Mosquitto 1.0.1 版本解析:Windows 服务 log_dest 默认值与 Python on_log() 回调修复的源码级解读

物联网消息队列后端网络/通信 【免费下载链接】mosquitto Eclipse Mosquitto - An open source MQTT broker 项目地址: https://gitcode.com/gh_mirrors/mo/mosquitto 点击查看 免费下载 Mosquitto 1.0.1 是 2012 年 8 月 15 日发布的纯缺陷修复版本,紧… · 2026/9/25 5:17:57

Humanizer StringExtensions.FormatWith 详解:2.x 字符串格式化扩展方法 API 与 3.x 迁移指南
Humanizer StringExtensions.FormatWith 详解:2.x 字符串格式化扩展方法 API 与 3.x 迁移指南

开发工具 【免费下载链接】Humanizer Humanizer meets all your .NET needs for manipulating and displaying strings, enums, dates, times, timespans, numbers and quantities 项目地址: https://gitcode.com/gh_mirrors/hu/Humanizer 点击查看 免费下载 导读 … · 2026/9/25 5:17:51

ESP32-S3麦克风阵列实战:波束成形与回声消除全解析
ESP32-S3麦克风阵列实战:波束成形与回声消除全解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/25 5:17:51

WPS Office CVE-2024-7262:路径解析缺陷导致沙箱逃逸与远程代码执行
WPS Office CVE-2024-7262:路径解析缺陷导致沙箱逃逸与远程代码执行

1. 这不是“普通漏洞”,是WPS Office里一条能绕过所有沙箱的隐秘通道如果你最近在安全圈听到“CVE-2024-7262”这个编号,大概率是在红队演练复盘会上、甲方安全评估报告里,或者某位同事深夜发来的截图——一个看似普通的WPS文档,双… · 2026/9/25 5:17:51

GraphQL Java 后端接入 MongoDB:Connectors 连接器实战与 N+1 查询优化
GraphQL Java 后端接入 MongoDB:Connectors 连接器实战与 N+1 查询优化

【免费下载链接】howtographql The Fullstack Tutorial for GraphQL 项目地址: https://gitcode.com/gh_mirrors/ho/howtographql 点击查看 免费下载 本篇指南基于 HowToGraphQL 开源仓库中的 graphql-java 教程 连接器章节 展开,讲解如何为基于 graph… · 2026/9/25 5:17:44

数值优化(Numerical Optimization)学习系列-03-共轭梯度方法(Conjugate Gradient)
数值优化(Numerical Optimization)学习系列-03-共轭梯度方法(Conjugate Gradient)

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/25 1:00:31

创维E900V22D刷机全攻略:S905L3SB芯片兼容性解析与救砖实战
创维E900V22D刷机全攻略:S905L3SB芯片兼容性解析与救砖实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/25 1:00:31

MQTT协议原理与Broker服务器搭建实战:从Mosquitto到EMQX
MQTT协议原理与Broker服务器搭建实战:从Mosquitto到EMQX

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/25 1:00:37

了解更多?预约专属演示

我们的顾问将为您一对一讲解产品与方案

企业微信二维码