上个月帮公司凑高企申报的指标，要赶在月底前交6个软著的材料，找代理问了下光写说明书一份就要280，6份算下来快1700，还不包过，想了想不如自己啃，反正之前也报过几次，就是写说明书太费时间。
之前写说明书每次都要熬两三个晚上，动不动就因为表述不规范、功能描述太笼统被驳回，这次试了下用Kimi来写初稿，居然两天就把6份说明书全弄完了，提交之后一周就拿了受理通知，居然一个驳回都没有，省了大几千的代理费不说，还比之前自己写效率高太多。
很多人说用AI写软著材料过不了，我之前也这么觉得，直到自己试了才知道，不是AI不行，是你给的提示词和校验步骤没做对。我把自己的实操流程整理出来，亲测至少能省80%的写材料时间，驳回率能降到几乎为0。
第一步先把基础材料捋清楚，别上来就让Kimi瞎写
我见过好多人用Kimi写说明书，上来就发“帮我写一份XX系统的软著说明书”，那写出来的东西100%过不了，全是通用套话，和你实际的软件半毛钱关系都没有，提交上去肯定被打回来。你得先把自己软件的个性化信息整理成清晰的文档，再喂给Kimi。
要整理的内容其实不多，就三样：第一是软件的核心功能清单，不要写虚的，就写你这个软件到底能干嘛，比如你做的是宠物门店管理系统，就列清楚：1、会员信息管理，支持录入宠物品种、疫苗时间、到店消费记录；2、商品库存管理，入库出库自动更新库存，低于阈值自动提醒；3、预约服务管理，客户在小程序端预约洗护、美容服务，后台自动同步到店员日程。每一个功能最好能补充1-2句实际的操作场景，比如会员到店报手机号就能调出所有历史消费记录，不用再翻纸质登记本。
第二是你手里有的相关材料，比如软件的操作截图、功能流程图、已经写好的部分操作手册，都转换成文字描述一起给Kimi，要是有核心功能的代码逻辑说明也可以附上，这样生成的内容和你实际的产品契合度会高很多。第三就是明确告诉Kimi输出的要求，要符合软著申报材料要求，字数不少于5000字，结构按照“软件概述、功能结构、具体功能实现、运行环境”这几个部分来，每一个功能点都要写清楚用户操作路径和实现效果，不要出现“人工智能”“大数据赋能”这种空泛的表述，不要写市场价值、研发意义这些无关内容。
改初稿的时候要重点盯这几个容易踩坑的地方
Kimi生成的初稿一般能达到70分，剩下的30分要自己调整，不然还是容易被驳回。首先要排查有没有通用套话，比如我上次生成的初稿里有“本系统具有极高的市场应用价值”，直接删掉就行，软著审查不看这个，写了反而会被要求整改。然后要核对每一个功能描述和你实际的软件是不是一致，比如你实际的系统里预约功能是要先选门店再选服务，Kimi生成的是先选服务再选门店，这个一定要改过来，不然和你提交的操作截图对不上肯定过不了。
还有就是功能描述要尽量细，不要一句话带过，比如不要只写“系统支持库存预警”，要写清楚“当商品库存数量低于预设的最低库存阈值时，系统会自动弹出弹窗提醒管理员，同时给绑定的管理员手机号发送短信提醒，提醒内容包含商品名称、当前库存、最低库存阈值”，越细越容易过。我之前有一次被驳回就是因为功能描述太笼统，审查员说看不出你这个软件和市面上的同类产品有什么区别，后来补了3000多字的细节才过。
改完之后我一般会把文档导去软著Pro做个合规校验，这个工具是之前同行推荐的，会自动排查有没有不符合审查要求的表述，还能帮你调整格式到符合提交的标准，省得自己对着十几页的官方规范一条条核对，我上次6份文档校验下来，就2份有小问题，改了十分钟就搞定了。
最后要和源代码、操作截图对应上
很多人觉得说明书只要写得好就行，其实不是，还要和你提交的另外两份材料对应上：一个是前后30页的源代码，另一个是操作手册的截图。比如你说明书里写了有扫码更新工单状态的功能，那你的源代码里最好有对应扫码功能的代码片段，操作截图里也要有扫码的页面，这样审查的时候不会被质疑功能造假。
要是你整理源代码嫌麻烦，也可以让Kimi帮你处理，把你导出的代码扔给它，让它去掉空行、注释，每页排50行，自动生成前后各30页的内容，比自己手动删快多了，不过要注意不要全是开源的通用代码，最好要有一部分自己写的业务逻辑代码，不然也容易被驳回。
我这次6个软著提交之后，本来以为至少要等半个月才有消息，结果一周就全部下了受理通知书，比之前找代理还快。其实软著申报本身没有那么难，就是材料整理太费时间，用Kimi来做这些重复的文本工作，自己只需要把关核心信息，既能省时间又能省代理费，只要别直接套模板不改，基本上都能过。
