软著代码、手册与截图如何保持一致

以真实软件版本为起点，把功能说明、源程序、使用文档和截图逐项对应。本文给出版本锁定、材料映射、文档编写与提交前复核方法，并区分一般交存规则和内部质量建议。

整理软著材料时，程序来自一个版本、手册沿用旧模板、截图却取自另一个环境，容易让同一项功能出现不同名称和操作结果。解决这一问题，不是把所有文件的页眉统一改名，而是先找到真实软件版本，再建立各份材料之间的对应关系。

本文侧重程序、文档与截图的内部质量检查，适合已经有真实软件、需要整理材料的团队。截图在这里是解释实际功能的辅助内容，不意味着每种软件都必须单独提交一套截图，也不意味着所有软件都具有可视化界面。

配图说明：封面图为内部质量检查示意，不是官方材料模板；程序、文档与截图应反映真实软件。

一、锁定材料对应的真实版本

先记录软件名称、版本标识、代码位置、实际运行环境和本次材料整理日期。团队使用发布标签或提交标识时，可以将其保留在内部记录中，便于后续复核；不要把内部整理日期直接当作软件开发完成日期。

确认本次范围内哪些功能已经实现，哪些仍是设计或规划。临时演示页、尚未接通的按钮和未来计划不应写成既有能力。材料准备期间如发生功能调整，先判断是否影响本次版本，再决定同步更新哪些文件，避免不同人员各自选择一个“最新版本”。

按实际业务流程列出主要功能，每项记录功能名称、程序位置、文档章节和可用于核对的运行结果。有界面的软件可补充页面位置；无界面的软件则可以根据真实情况整理运行方式、输入输出或接口说明，不为凑材料制作不存在的界面。

对应表是内部检查工具，不是额外的官方表格。它的价值在于让编写手册的人能够向开发人员提出具体问题，例如“这一段描述对应哪个入口”，而不是凭产品介绍猜测软件如何运行。

《计算机软件著作权登记办法》第九、十条规定了申请材料类别和一般交存方式：源程序与一种文档各取前后连续30页；不足60页的提交全部。除特定情况外，程序每页至少50行、文档每页至少30行。

上述规则不能解释成必须把短程序“凑够”固定页数，更不能通过重复无关代码、放大行距或复制模板制造真实软件不存在的内容。应先确定材料来源及适用情形，再按实际要求整理；不要把本文的检查顺序当作登记系统的操作步骤。

涉及保密内容时，办法第十二、十三条另有例外交存、封存安排，不能理解为可以任意删改或涂黑后提交。具体是否适用、如何办理，应向登记机构核实。本文不提供未经核实的上传格式、当前系统声明或办理时长。

编写使用说明时，可以依次说明软件用途、运行条件、角色或权限、主要操作、结果查看和常见异常。不是每一项都适用于每个软件，应按实际功能选择。章节标题写得再完整，也不能替代可核对的内容；对于尚未验证的步骤，应先由了解软件的人确认。

操作示例应使用适当的演示数据，而不是暴露真实客户姓名、联系方式、账号密码或访问令牌。示例数据可以用于展示已经实现的功能，但不应伪装成真实客户、业务成绩或成功案例。程序材料中的敏感信息如何处理，也应与合法、真实的交存要求一并确认，而非自行改变软件事实。

尽量从与本次版本对应的受控环境获取截图，保留清晰的功能区域和必要上下文。页面显示名称与申请名称不同，先查明是品牌展示、旧版本残留还是另一套软件，不直接用修图把差异覆盖掉。需要更新界面时，应基于真实软件的实际修改重新核对材料。

截图不宜过度裁切到只剩按钮，也不必包含无关桌面、聊天窗口或浏览器个人信息。可读性、隐私和说明目的要同时考虑。提交前查看最终导出文件，而不仅是编辑器中的原稿，确认图片没有错位、文字没有被截断、章节顺序没有变化。

将问题分为已修正、已说明和待确认，待确认项不要在提交时悄悄消失。最终留存提交版本、复核日期和修改说明，后续收到具体问题时，能够知道对方看到的是哪一套材料。内部复核可以帮助发现不一致，但不代表已经通过登记审查。

需要协助梳理材料时，可先提供软件用途、开发方式、版本范围和现有文档目录，再确认服务内容及需要共享的信息。使用超级 PM 或其他整理工具，不应被理解为已经满足登记条件或能够获得特定结果。提交软著材料咨询。

资料核对日期：2026年9月12日。本文为一般性整理建议；具体办理请核对登记机构的现行指南和个案要求。