提交源代码或伪代码有什么讲究？
简答
代码在软件专利中是实施例层面的佐证材料：核心算法用伪代码加少量关键实现最稳妥，整库粘贴既无必要也有泄露风险；提交到什么粒度，取决于说明书公开充分的需要，而不是越多越好。
展开说明
代码在说明书中的地位
权利要求写的是技术方案，用的是步骤、模块与功能语言，不是某一种编程语言的源代码；代码出现在说明书里，定位是支撑公开充分、支持权利要求的实施例材料。
审查实践同样认可：涉及计算机程序的发明可以用流程图、伪代码等方式描述，只要本领域技术人员能够实现。也就是说，伪代码是合格的表达方式，逐行真实源码从来不是必需品。反过来，只有代码而没有步骤说明，往往同时招致清楚性与公开充分两方面的质疑。
提交粒度怎么拿捏
推荐做法：核心算法给伪代码或流程图，对实现敏感的关键环节（例如数值稳定性处理、边界条件）补一段函数级的关键实现；与发明点无关的界面代码、工程胶水代码不要贴。若是算法类发明，伪代码里应把数据预处理、模型训练、推理三个阶段各自的输入输出写清楚，方便与权利要求的步骤一一对应。
常见的反向错误有两类：一是只贴几百行真实代码却说不清算法步骤，审查员无法把代码映射到权利要求的特征，公开不充分的质疑反而更大；二是伪代码抽象到没有输入输出与数据结构，写了等于没写。实施例如何撑住保护范围，可进一步参考软件专利的实施例怎么写才撑得住保护范围？。
公开与秘密的权衡
说明书自申请公布起对公众可见，授权后维持公开，代码一旦写入无法撤回。含密钥、真实账号逻辑、精选参数的内容必须先抽象再写入，数据与字段的抽象思路可与涉敏感数据的算法申请怎么脱敏撰写？合并考虑。
拿不准一段代码该不该贴时，用「删掉它说明书还能不能实现」来检验：能实现就不贴，转按商业秘密管理；不能实现就抽象到能实现的最小粒度再贴。工程上更省事的做法是在设计文档阶段就把可公开的抽象层与留作秘密的实现层分开标注，避免申请前反复删改。
各国口径的差异
中国口径如上，伪代码加流程图是主流做法；美国实践中同样接受伪代码、流程图与功能描述，但对应的是充分公开与明确性要求，实施例要足以支撑较宽的权利要求，相关风险见美国专利申请的 101 与 112 风险怎么防？；欧洲审查则更看重技术特征与技术效果的对应关系。
走 PCT 或多国布局时，建议在母案阶段就把伪代码写扎实：进入国家阶段后再补充实现细节，很可能被认定超出原始公开范围。母案把关键接口与数据结构的含义写清，比堆代码更能为多国程序提供支撑。附图部分的表达规范可参考流程图与附图在软件专利里的规范？。程序类发明的官方审查口径可参考《专利审查指南》(2023) 计算机程序审查标准解读。
参考来源
引用均为官方文件或公开报道，访问日期 2026-11-06。