软著申请里说明书是最容易在补正环节被点名的材料之一。原因说出来很朴素不是文笔不行是写偏了或者和代码对不上。这两类问题恰好是 AI 能帮上忙的地方——但前提是用对方式让 AI 做「一致性比对」而不是让它「代写」。这篇讲一个我在整理材料时反复用的三步核对法每步都给可执行的判据。—## 先说结论说明书补正基本逃不出这两类登记机构对说明书的审查重点落在「描述的功能是否真实存在」和「各处口径是否一致」。所以补正意见通常长这样- 「说明书描述的功能与提交的源代码不符」- 「说明书截图与正文描述不一致」- 「软件名称在材料各处写法不一致」对应到操作上要防的就是两件事写偏写了软件里没有的功能和对不上名称、版本、功能点在各处不一致。—## 步骤一先把「功能清单」从代码里提出来再动笔这一步的错法很常见坐在那儿回忆软件有什么功能然后照着记忆写。记忆会美化会把「打算做但没做完」的功能也写进去这就是「写偏」的来源。正确顺序是反过来的——先从代码里把功能点提出来形成清单再让说明书对齐这份清单。具体做法1. 先列出真实存在的模块一般 510 个粒度和「界面上的一个功能区」对齐2. 每个模块记三样东西入口菜单/按钮、核心操作、可见结果3. 这份清单就是后续所有描述的唯一基准。AI 在这步能帮什么把真实的代码片段路由表、控制器方法名、菜单配置这类结构化信息交给它让它归纳出模块清单。注意是归纳不是让它凭空列一份通用功能表——那是失真最快的做法。判据清单里每一个模块你都能指出它对应代码里的哪几处指不出来的删掉。—## 步骤二把「三处名称」对齐成一个标准全称这是补正里特别高频、又特别低级的一类错误同一个软件在三处写出了三个名字。需要统一的是这三处| 位置 | 常见错误 ||—|—|| 申请表里的软件全称 | 写了带部门/项目的内部叫法 || 源代码页眉 | 写成简称申请表写「XX管理系统V1.0」页眉写「XX系统」 || 说明书封面 | 又多一个版本或漏了版本号 |做法先定一个标准全称再回头改所有材料而不是每份材料各写各的。名称建议的结构text企业简称 功能描述 软件/系统/平台 V版本号版本号从 V1.0 起页眉里的版本号要和申请表完全一致一个字符都不能差。AI 在这步的用法是做交叉核对把三处的名称字符串贴进去让它逐字符比对差异。这件事人眼很容易扫过去机器比反而更可靠。判据把三处名称复制到同一个文本里对比应当完全一致包括全角半角、空格、大小写。—## 步骤三截图与正文做一次「点对点」抽查第三类问题是「说明书写得漂亮但截图和正文对不上」。典型表现- 正文写「点击导出按钮生成报表」配的截图里根本没有导出按钮- 截图里的菜单名是「数据管理」正文里写的是「数据维护」- 正文说有 6 个功能模块截图只出现 4 个。做法不要通读全文找感觉而是按功能点逐个抽查——每个模块翻到对应那一节看三样东西是否同时成立1. 正文描述的操作截图里能找到对应界面2. 截图里的按钮/菜单文字和正文用词一致3. 这一节配的截图确实是这个模块的不是上一节复用过来的。AI 在这步可以帮你做用词不一致检查把正文和截图说明文字你自己转写的一起给它让它标出同一功能的两种叫法。但截图本身必须由你看——AI 看不到你的软件界面这一步不能外包。判据抽查出来的每一个不一致改正文或改截图不要留着「差不多」。—## 三个最容易出现的失真点结合上面的流程我把最常翻车的三个点拎出来1.功能范围写大把规划中的功能写进说明书。判据——清单里每个功能都要指得出代码位置。2.名称不统一三处名称各写各的。判据——复制到一起逐字符比对。3.用词漂移正文叫法换了一套。判据——按模块抽查同一功能的词必须一致。还有一条边界要划清楚说明书里描述的功能必须是已经实现并且在截图里能看到的。做不到的功能写进去不是描述问题是诚信问题。—## 自查清单- [ ] 功能清单是从代码里提出来的不是凭记忆写的- [ ] 清单里每个模块都能指到代码位置- [ ] 申请表全称 / 页眉 / 说明书封面三处名称逐字符一致- [ ] 版本号三处一致且格式统一- [ ] 按模块抽查过截图与正文的对应关系- [ ] 同一功能在正文与截图里的叫法一致- [ ] 说明书里没有「规划中但未实现」的功能软著是登记制材料规范性对结果的影响远大于写作水平。把上面三步在提交前走一遍能挡掉大部分补正——而且不需要什么特殊工具需要的是顺序和判据。补正只是常规环节不等于被驳回真收到补正通知重点是按通知指出的环节改而不是整份重做。