这段时间帮一个AI生成类项目整理软著材料，最花时间的不是填表，而是把技术同事嘴里那些“模型调用”“提示词编排”“结果生成”翻译成一份审查员能看懂、材料之间又能互相对应的AI生成系统架构说明。
一开始我们想得很简单，觉得架构说明不就是画几张图、写几层结构吗？真正动手才发现，软著材料里的架构说明不能只追求技术上正确，还要考虑申报版本、功能边界、代码一致性和文档表达。尤其是AI生成系统，里面涉及大模型接口、知识库、任务调度、内容审核、用户管理等多个模块，如果描述过泛，很容易被看成通用方案；如果写得太细，又可能和提交的源代码、操作说明书对不上。
先把“系统到底保护什么”定下来
写架构说明前，我习惯先把软件名称、版本号、运行环境和核心功能列在一张纸上。别小看这一步，后面所有材料都要围绕这些信息展开。比如我们申报的是一个面向营销文案场景的AI内容生成平台，后端负责任务接收、提示词组装、模型接口调用和结果落库，前端提供模板选择、参数配置、生成记录和人工修改功能。
这里有个坑：团队介绍项目时，往往会把正在规划的能力也讲进去，比如多模态生成、自动投放、企业微信集成等，但这些功能在当前版本代码里并没有实现。软署申报材料讲究一致性，架构图里出现的模块，说明书里最好能看到操作入口，源代码里也要有相应逻辑。否则材料看起来很丰满，实际核对时反而容易出问题。
所以我通常会把功能分成“本版本已实现”“接口依赖但不自称为本系统核心”“后续规划”三类。架构说明只写第一类和必要的第二类，第三类不要放进去。比如第三方大模型服务可以作为外部服务节点出现，但不能把模型本身写成申请人自主开发的内容。
架构说明不要堆概念，要顺着数据流写
AI生成系统最容易写成一份概念拼盘：什么感知层、能力层、应用层，看着很整齐，但每个层到底做什么并不清楚。审查材料不是技术白皮书，架构说明要让人明白软件从接收请求到输出生成结果的完整过程。
我们后来采用的写法是：先给总体架构，再按调用链路展开。用户在前端选择内容类型并填写主题、语气、字数等参数后，请求进入业务后端。后端先完成身份校验和参数检查，再根据场景读取提示词模板，把用户输入、业务变量和知识库片段组装成最终请求。任务服务调用外部AI模型接口，并对返回结果进行解析、敏感词检查、格式规范化和持久化保存。前端拿到生成结果后，支持用户复制、重新生成、编辑和导出。
这条链路写清楚以后，再去划分层次就稳很多。表现层可以写Web前端和管理后台；业务服务层包括用户管理、模板管理、生成任务、结果管理、审核记录等模块；数据层包括用户数据、模板数据、任务记录、生成内容和操作日志；外部接口层主要对接大模型API、对象存储或短信服务。这样既符合常见架构表达，也不会脱离实际代码。
模块描述要能和代码、界面互相对应
我整理材料时，会给每个核心模块补一句“输入—处理—输出”。这句话特别好用，能逼自己把模糊功能写具体。比如提示词管理模块，输入是场景名称、系统提示词、变量占位符和适用模型，处理逻辑包括模板新增、编辑、启用、版本记录和参数替换，输出是可供生成任务调用的完整提示词。
再比如AI生成任务模块，不能只写“调用模型生成内容”。更合适的表达是：系统接收用户提交的生成参数，创建任务编号，根据模板组装请求，调用模型接口，设置超时和重试机制，接收返回文本，完成清洗和审核，再将任务状态、生成结果、消耗字数和时间戳写入数据库。这样描述的好处是，代码里哪怕类名叫TaskService、PromptService或AiClient，也能在功能上对应起来。
很多团队还会忽略日志和异常处理。实际系统不可能永远一次调用成功，网络超时、模型返回为空、接口额度不足、内容审核不通过，都需要有明确状态。架构说明里可以简单写到任务状态流转，比如待处理、生成中、成功、失败、已驳回。这个细节会让材料显得更真实，也更像一个已经运行过的软件系统。
架构图怎么画更容易通过材料检查
图不需要花哨，但信息要完整。我一般会准备两类图：一张总体架构图，一张核心业务流程图。总体架构图从上到下放用户端、业务服务、数据存储和外部AI服务，模块名称尽量与系统菜单、代码包名保持一致。业务流程图则围绕“创建生成任务—组装提示词—调用模型—审核结果—保存返回—用户编辑”展开。
画图时尽量少用纯概念词，比如“智能中枢”“AI大脑”。这类词做汇报可以，放在软著材料里不够具体。图中每个方框都应该能落到一个功能模块或数据表上。比如“模板管理”比“智能策略中心”好，“生成记录表”比“数据资产池”好。
还要注意图片清晰度和版式统一。我之前见过一份材料，架构图里写的是“内容生成模块”，操作说明书里菜单叫“AI写作”，源代码里主要类叫TextGenerateController，三者虽然意思相近，但核对材料时会让人心里没底。后来我们统一术语，把菜单、文档标题、数据库表和架构图都调整成同一套说法，材料顺了很多。
源代码、说明书和架构说明别各写各的
软著申报不是单独交一篇架构文章，而是一整套材料。AI生成系统尤其要处理好“外部模型”和“自有代码”的关系。你可以调用第三方模型接口，但申请保护的是围绕业务场景实现的生成管理系统，包括前端交互、任务处理、模板配置、数据管理、审核和日志等软件功能，不要把材料写成对大模型本身的研发说明。
源代码节选也要避开纯配置片段，别六十页里大量是依赖包、自动生成文件或接口密钥。尽量选择能体现业务逻辑的部分，比如参数校验、任务创建、提示词拼接、接口调用、结果解析、审核状态处理等。页眉的软件名称、版本号、页码也要按代理或申报平台要求统一。
操作说明书中出现的按钮和字段，架构说明里最好有模块承接。比如界面上有“重新生成”“相似度检测”“导出Word”，架构文档里就可以对应到任务重试、结果检测、文件导出。反过来，如果架构图里画了“知识库管理”，那说明书里就要有上传文档、切片、检索或引用相关页面，不能只在图里出现一次。
几个我反复提醒客户的细节
第一，运行环境写真实情况。开发语言、框架、数据库、中间件、部署方式要和项目一致，不能为了显得先进就把没用过的组件全写上。第二，不要在架构说明里暴露第三方密钥、内部地址、账号密码，接口地址可以做适当泛化。第三，AI生成结果可能涉及合规问题，内容审核、敏感词过滤、人工复核这些模块如果系统里有，一定要写清楚。第四，版本时间别混乱，申请表、说明书、代码页眉和材料落款要对得上。
整理这类材料时，我也会用软著Pro这类工具辅助检查材料结构和文档格式。它比较适合在提交前快速查漏补缺，比如源代码页眉、分页、说明文档完整性这些机械工作，能省不少反复调整的时间。但核心内容还得靠自己把系统讲明白，工具只能提高整理效率，不能替你编一个不存在的架构。
说到底，一份靠谱的AI生成系统架构说明，不是把流行技术名词堆上去，而是让没参加过开发的人也能看明白：用户做了什么，系统怎么处理，AI接口在哪里被调用，数据经过哪些模块，最后结果怎样保存和输出。把这条线写实，材料的可信度自然就上来了。
