我前两个月帮公司集中申报3个办公类软著的时候，第一次尝试用Kimi写软著说明书，之前每次自己写都要熬两个大夜，光是凑够要求的30页内容就要翻好多旧资料，那次摸索下来，算上修改调整的时间，3份材料总共只花了两天半，比之前效率高了不止一倍。不过最开始踩的坑也挺头疼的，第一次生成的初稿我没怎么改就提交了，等了快两周收到补正通知，说功能描述太虚，和提交的程序运行截图完全对不上，白等了好久。
要是你也打算用Kimi来写软著说明书，千万别上来就直接甩一句“帮我写个XX系统的软著说明书”，那样出来的内容90%都是通用套话，交上去大概率被驳回。最先要做的是把自己软件的基础信息理清楚：核心是干嘛的、面向什么用户、有哪3-5个独有的功能、用的什么技术栈，最好提前存好3张以上的实际运行截图，这些信息整理成100-200字的基础说明，是给Kimi的核心参考，不然它根本不知道你要的是什么内容。
写prompt的时候也要把要求说的足够细，我自己常用的prompt结构是：先甩基础信息，然后明确要求“按照版权局软著申报的说明书要求撰写，内容要包含技术架构说明、核心功能模块的操作逻辑、具体使用流程、核心代码片段，总字数不低于1.5万字，不要出现任何宣传类、夸大类表述，所有功能描述要贴合我给出的实际功能”，有时候我还会把之前过审的同类型说明书摘几页喂给它，让它照着结构和语气来写，出来的初稿合格率会高很多。
初稿出来之后绝对不能直接用，第一步要先核对所有功能描述，Kimi有时候会把同类型其他软件的功能揉进去，比如我上次写的是内部员工考勤系统，它居然给我加了个客户关系管理的模块，要是没删掉交上去，审查员一眼就能看出来内容是生成的，直接就给驳回了。要是你不知道当前最新的审查规则，可以去软著Pro上查最新的要求，我之前就是对照上面的模板改的内容，省了好多翻版权局公告的时间。
第二个要重点改的是代码部分，Kimi生成的核心代码大多是通用开源片段，你得把自己程序里的核心代码替换进去，至少开头30行和结尾30行要完全是你自己的代码，中间的部分可以适当留一些通用的，但是不要全抄生成的，现在软著审查对代码的重合度查的越来越严，要是和已经登记的代码重合度太高，也会要求补正。还有要注意代码里不要带其他公司的版权声明、开源协议标识，这些都要提前删掉。
内容改完之后还要调整排版，软著说明书对格式是有明确要求的，页眉要统一标注软件全称+版本号，页码要从正文第一页开始连续标注，所有截图不能有水印、不能有其他无关的内容，每个功能描述下面最好配上对应的运行截图，审查员翻的时候一眼就能看到对应功能是真实存在的，过审概率会高很多。Kimi生成的内容排版一般都是乱的，你要按照软著说明书的规范要求调整，标题层级要清晰，功能模块不要交叉混乱。
我上次被补正之后，就是对着这些要求改了一遍，把多余的功能全删了，替换了自己的代码，每个功能下面都加了对应的截图，调整好排版之后重新提交，7天就收到了登记通过的通知，比第一次快了一倍。后来我帮朋友申报两个电商类的软著，也是用这个方法，提前把他的店铺后台功能理清楚，给Kimi的prompt写的足够细，初稿改了不到两个小时就搞定了，提交之后也是一次性过审，省了他找代理花的几千块钱。
还有几个小细节要注意，比如所有材料里的软件名称、版本号一定要统一，Kimi生成内容的时候有时候会乱加版本号，你要全部改成你申请表上填的那个，比如填的V1.0就全文档都用V1.0，不要一会出现V2.0的字样。还有不要出现“首创”“领先”“最优”这类宣传词汇，软著是版权登记，不是评奖项，出现这类词汇百分之百会被要求补正，直接删掉就好。
现在我身边好多做开发的朋友申报软著，都是先让Kimi出初稿，再自己调整内容，只要把前面说的几个坑避开，基本不会出问题，比自己从零开始写要省太多时间，要是你平时工作忙，抽不出太多时间整理材料，这个方法真的可以试试。
