做过软著申报的朋友都知道，源代码文档这块硬骨头最难啃。不管是个人申请还是企业批量申报，要求都摆在那里：前后各30页，总共60页，还要逻辑连贯，代码量不能太少。以前我们都是扒拉以前的项目代码，或者找网上的模板改改，稍微不注意就出现变量名对不上的低级错误，导致补正。这两年AI工具普及了，我试着用大模型来生成这部分材料，效率确实提升了不少，但这里面有些门道，要是直接把AI扔出来的东西交上去，大概率是过不了的。
首先得明确一点，审查员虽然不一定通读每一行代码，但他们一定会看逻辑。你前一个函数里调用了 getUserInfo()，下面几百行代码里愣是找不到这个方法的定义，这肯定是不行的。AI生成代码最大的问题就在这儿，它经常会“画大饼”，在主流程里写得很花哨，引用了一堆子模块，结果你让它展开写这些子模块时，它要么忘了，要么逻辑对不上。所以，我的做法是绝对不让AI一次性生成60页，而是把系统拆解成几个核心模块，比如用户管理、订单处理、数据报表等，针对每个模块单独去问AI，最后再像拼图一样拼起来。
在提示词的编写上，也有不少讲究。我通常会明确要求：“请用Java编写一个订单查询功能，必须包含完整的Service层和Dao层实现，代码风格要传统，不要用Stream流等简写，注释要占代码行的20%左右”。为什么要强调“传统”？因为现代语法太精简了，一行能干以前五行的活，我们要的是凑页数，太精简了你就得写更多函数，反而增加逻辑复杂度。而且，审查员看习惯了那种比较规整的、带点冗余代码的风格，太炫技的代码反而显得像生成的。在生成过程中，我会时不时打断它，让它“继续写上一个方法的实现”，或者“补充异常处理模块”，这样能保证代码的密度和厚度。
还有一个容易被忽视的坑，就是注释。以前我总觉得注释多显得专业，结果AI生成的代码有时候注释比代码还长，或者全是英文注释。审查员看到满屏英文，虽然不一定直接拒收，但印象分肯定打折。我现在都会让AI强制生成中文注释，并且控制比例，看起来像是一个正常国内程序员的手笔。比如让它写“// 判断用户是否登录”而不是“// Check user login status”。这些细节虽然小，但堆积起来就能决定材料看起来是不是“真的”。
代码生成得差不多了，下一步就是整理格式。很多开发环境自带的复制功能会带颜色、带行号，这在软著申报材料里是绝对禁止的。我通常会先把AI生成的代码贴到Notion或者Typora这种纯文本编辑器里洗一遍，把多余的格式去掉，只保留黑白字体。这里顺手推荐一下“软著Pro”，这工具在处理格式转换上挺方便，特别是它能自动去掉那些会导致审查不通过的乱码字符，还能一键帮你调整页眉页脚，省去了在Word里调格式的痛苦。毕竟我们做开发的，最烦的就是在Word里调排版，有个工具能自动处理，能省下不少时间去喝杯咖啡。
把所有模块拼起来后，一定要自己通读一遍。别看是AI写的，里面有时候会混入一些奇怪的包名或者根本不存在的依赖库。我就遇到过一次，AI在代码里import了一个自己编写的工具类，结果整个文档逻辑就断了。如果有些逻辑实在补不上，我就手动写几个简单的Getter/Setter方法，或者加几个简单的工具类填充进去，保证整个文档从第1页到第60页，看起来像是一个完整的、可运行的工程。最后检查一下页码，前30页和后30页有没有重叠部分，虽然现在的审查大多看电子版，但目录和页码的规范性依然是专业度的体现。
其实，用AI辅助写软著源代码，本质上不是“作弊”，而是把我们从重复劳动中解放出来。审查员要的不是一个完美无缺的高性能系统，他们要的是一个符合规范、逻辑自洽的文本材料。只要我们把好逻辑关和格式关，AI完全能成为我们手里的得力助手。把代码搞定后，剩下的用户手册和设计说明就简单多了，毕竟源代码才是最难啃的骨头，啃下这块，后面的流程就顺畅多了。