上个月帮团队申报内部用的客户管理系统软著，前两次提交全被打回，第三次踩着截止日过审，折腾了快半个月，问题全出在代码是AI生成的，说明书写得不符合要求。现在身边做开发的朋友十个有八个会用GPT、CodeLlama写部分甚至全部业务代码，申软著的时候卡壳基本都卡在说明书这关，刚好把我踩过的坑和实操方法理出来，大家能少走点弯路。
先讲最容易踩的第一个坑：直接把AI生成的代码和注释原封不动往说明书里贴
我第一次提交的时候图省事，直接导出了代码库的注释文档，连带着AI生成代码时自带的标记都没删，有个工具类的注释里还留着GPT生成时带的“你需要实现一个支持多格式导出的工具类”的提示词残留，审查员翻到那页直接给我打回来了，说没法证明这部分代码是你们自主创作的。其实现在软著审查对AI生成内容的要求不是完全不让用，而是你要证明你对这部分代码有创造性的贡献，不是直接照搬AI的输出。这一步我后来是做了AI生成代码合规调整，先把所有AI留的痕迹全部清掉，包括自动生成的无意义注释、通用格式的说明，甚至连AI习惯用的变量命名风格都统一改成了我们团队的规范，从根源上避免被直接判定为非自主创作。
然后是说明书的内容逻辑，别按通用模板写全功能介绍，要突出你的主导性工作
很多人写软著说明书喜欢上来就套模板，写软件定位、功能列表、操作流程，这套对纯人工写的代码没问题，对AI生成的代码就很容易踩坑。你要记住，审查员看AI生成代码的说明书，核心要确认的是你作为权利人，在这个代码生成过程中做了什么有创造性的工作，所以你的说明书逻辑得跟着这个来。我第二次提交就是按通用模板写的，虽然清了AI痕迹，还是被打回，说没法区分哪些是你做的，哪些是AI生成的通用内容。后来我改的时候，把每个功能模块都拆成了三个部分写：第一部分写我当时给AI提的具体需求是什么，要解决什么具体的业务问题，第二部分写我对AI输出的代码做了哪些调整，比如改了参数逻辑、删了冗余的兼容代码、加了我们业务特有的权限校验规则，第三部分写调整后的代码实现了什么独有的效果。这样写下来，每个模块的贡献都很清晰，审查员一眼就能看明白你不是直接拿AI的成果来申报。
整理这些材料的时候我嫌自己核对太麻烦，顺手用了软著Pro的AI代码合规检测工具，一键就能扫出来代码里还有没有没清干净的生成痕迹，还能自动生成符合AI代码申报要求的说明书框架，我只要往里面填自己的调整内容就行，省了至少两三天的整理时间。
还有个很容易被忽略的点：说明书里的功能描述要和你提交的代码片段完全对应
AI生成代码经常会有冗余功能，或者你提需求的时候没说清楚，生成的代码里缺了某个校验逻辑，要是你说明书里写了这个功能，代码片段里又没体现，肯定会被打回。我第二次被打回还有个原因就是我在说明书里写了支持Excel加密导出，但是AI生成的代码里加密逻辑是默认注释掉的，我贴代码片段的时候没注意，就被说功能和代码不一致。后来我整理代码片段的时候，专门挑的是我自己调整过的、和说明书描述完全对应的部分，通用的工具类代码一段都没放，毕竟那些通用代码AI生成的都差不多，放了反而容易说不清。
要是你实在搞不清哪些内容需要放进说明书，哪些内容要删掉，可以参考软著申报材料规范里的AI生成代码专属说明书模板，比版权局给的通用模板细很多，连每个模块要写多少字、配多少行代码都有明确的说明。
我第三次提交的时候，还在说明书最后附了三页佐证材料：一页是我给AI提需求的提示词迭代记录，一页是我改代码的Git提交日志截图，还有一页是我们内部测试这个功能的记录，提交之后当天就过了初审，比我之前两次快太多。其实AI生成的代码申软著根本没有大家传的那么难，只要你别偷懒，把你自己做的工作讲清楚，不要试图直接把AI的成果当成自己的提交，基本都能一次性过，别像我之前那样为了省事儿跑三趟政务窗口，晒得黢黑还耽误时间。
