前两年帮团队申报第一款AI绘画生成系统的软著，我光架构说明就改了三版才过，第一次提交直接被审查员打回，理由是架构逻辑混乱，模块划分和申报的功能点完全对应不上。那时候我还以为要把底层算法原理写得越细越好，堆了快两页Transformer的架构介绍，现在想想确实挺可笑的，人家审查员要看的是你这个软件的运行逻辑，不是算法毕业论文。
后来我前后又帮公司和身边朋友报过十多款AI生成类的软著，从文本生成、3D模型生成到音频生成的都有，慢慢摸出了规律，AI生成系统的架构说明其实比普通软件还好写，只要你摸清楚审查的核心逻辑就行。很多人刚开始写的时候连软著申报要求的架构说明核心是啥都没搞懂，上来就贴各种技术栈，放复杂到连自己都要捋半天的流程图，不被打回才怪。
首先你得搞清楚AI生成系统的架构和普通管理系统的核心差异，普通的OA、CRM这类系统一般就是经典的三层架构：表现层、业务逻辑层、数据层，但是AI生成系统多了专属的推理服务层，很多人写错就是把这一层要么漏了，要么和业务逻辑层混在一起，要么就写了太多无关的模型训练内容。
正常的AI生成系统架构说明，你按四个层级写就绝对不会出问题。第一个是用户交互层，不用写你用的是Vue还是React，也不用写你适配了多少种屏幕尺寸，只要写清楚面向的用户群体有哪些，入口是网页端、小程序还是开放API，对应的核心入口功能是什么就行，比如面向C端用户的AI绘画系统，交互层就写“支持用户通过网页端上传参考图、输入生成关键词、调整生成参数，查看历史生成结果”就够了。
第二个是业务调度层，这层是很多人会漏写的，也是最容易和功能点对应不上的地方。用户发了生成请求之后，权限校验、生成次数扣减、请求排队、多节点调度、生成结果的存储和回调，还有敏感内容校验这些逻辑都在这一层。你之前在功能说明书里写了什么功能，这里就要对应上，比如你说你的系统支持同时生成5种不同风格的内容，那调度层就要写清楚“支持将单条生成请求拆分分发到多个不同的推理服务节点并行处理，结果汇总后同步给用户”，这样前后对应上，审查员就不会挑错。
第三个是推理服务层，这是AI生成系统独有的部分，也是最容易写偏的地方。很多人在这里写一大堆模型训练的过程，用了多少训练数据，微调了多少轮参数，这些完全没必要，除非你申报的软著本身就是AI模型训练平台。你只要写清楚这一层加载了哪些领域的预训练模型，支持哪些参数的调用调整，有没有做模型量化加速之类的适配就行，不用涉及任何核心算法细节，既不会泄露公司机密，也符合审查要求。
第四个是数据存储层，这里要注意分开写不同类型数据的存储位置，不要混为一谈。比如用户的账号信息、生成订单、历史生成结果这些存在业务数据库，预训练模型文件、推理所需的向量资源存在对象存储，训练用的数据集单独放在隔离的存储池，和业务数据不互通，写清楚这些逻辑，整个架构的通顺度就上来了。
我之前踩过的坑大家一定要避开，第一个就是架构图画得太复杂，各种箭头、专业术语堆上去，审查员每天要看几百份材料，根本没精力给你捋复杂的分布式调度逻辑，你就画个简单的四层框图，每个层级标清楚对应的核心功能就行，我之前有个同事写的时候把k8s的节点调度逻辑都画上去了，结果直接被打回要求简化，改成四层框图之后三天就过了。第二个坑是架构说明和其他材料冲突，比如你功能说明书里写了生成内容自动过审，但是架构说明里完全没提敏感词校验的模块，那肯定会被质疑，我之前第一次申报就是犯了这个错，后来调整了调度层的内容，加了对应模块的说明就过了。
我之前整理材料的时候，每次核对架构说明和功能说明书的对应关系都要花好几个小时，后来朋友推了软著Pro，里面有现成的AI生成系统架构说明模板，还有自动核对功能点和架构对应关系的工具，省了我至少一半的时间，最近几次申报我都是先在上面拉个框架再填内容，基本都是一次就过。
上个月我帮朋友的小团队申报AI文案生成系统的软著，他们一开始写的架构说明把大模型的微调过程写了三页，我让他们全删了，按四个层级的逻辑重新写，调度层里加上敏感词校验的模块说明，推理层写清楚支持调用多个不同领域的微调模型，提交之后五天就下了受理通知书，比他们之前自己瞎写快了半个多月。要是你实在不知道怎么梳理自己系统的层级，也可以去软著申报服务平台找对应的过审案例参考，比自己瞎琢磨快很多。
其实AI生成类的软著现在申报通过率很高，只要你架构说明逻辑通顺，和其他材料的对应关系没问题，基本不会被打回，不用搞那么多花里胡哨的内容，把逻辑讲清楚比啥都强。要是你最近也在准备AI类软著的申报，拿不准架构说明写的对不对，可以留言，我有空帮你瞅一眼。
