前两个月公司要报5个软著凑高企申报的资质，我之前自己手写过两次，每次都要熬两三个通宵，还被打回过一次，就想着试试用Kimi来写初稿，省点力气。最开始以为直接把软件名丢给Kimi就能生成能用的内容，结果第一次提交就被审查员打回来了，说内容太泛，和实际软件功能不符，后来慢慢摸出了门道，后面4个软著全部一次性过审，算下来比我之前全手写省了至少3天的时间。
给Kimi提需求的时候，千万不要只说“帮我写一个XX软件的软著说明书”，这种模糊的需求生成的内容90%都是套话，根本过不了审。你得先把自己软件的核心信息整理好，我一般是先列清楚这几个点：软件的全称、面向的用户群体、核心的3-5个功能模块分别是什么、每个模块能解决用户的什么问题、软件的实际运行环境是什么样的，还有有没有必须要写进去的专属功能点。
我当时怕自己提的需求不符合审查要求，还特意去软著申报的交流站找了最新的审查标准，把“不能出现通用类表述、功能描述要和实际产品一致、需要图文对应”这些要求一条条放到prompt的最前面，让Kimi严格按照这个规则生成，而且要求它按照“软件概述、运行环境、核心功能模块说明、典型使用流程、技术优势”这个结构来写，每部分都要具体到可落地的描述，不能有虚话。
第一次生成的初稿我当时粗看觉得挺像那么回事，仔细翻就发现很多问题，比如我做的是面向美术培训机构的学员课时管理系统，Kimi写的软件概述里居然有“支持多行业通用的学员管理”这种表述，运行环境更是写了“支持Windows、Mac、Linux全系统部署”，但我们这个实际就是个微信小程序，根本没有PC端。这些内容要是直接提交，肯定直接被打回，你得逐段核对，把不符合实际情况的内容全部改掉。
功能模块部分是最容易出问题的，Kimi有时候会自动补一些根本不存在的功能，比如我那个系统根本没有线上缴费的功能，Kimi生成的内容里居然写了“支持学员线上支付课时费、自动生成缴费凭证”，要是没注意到就提交，轻则补材料，重则被认为是造假，耽误下证时间。所以你改内容的时候，一定要对着自己的实际产品一条条捋，每个功能都要和你手里的产品截图、后续要提交的源代码对应上，不能有半点儿虚的。
很多人不知道软著说明书里的功能描述要写到多细，我之前也踩过这个坑，以为写清楚有什么功能就行，后来才知道要把操作逻辑也写进去。比如你写有“课时扣除”功能，不能只写“系统支持课时扣除”，得写“老师在班级管理页选择对应学员，点击课时扣除按钮，输入扣除的课时数量、上课日期、课程内容，确认提交后系统自动同步到学员的课时账户，同时给学员家长推送课时消耗通知”，越具体越容易过审，要是你不知道怎么展开写，可以把对应的操作截图丢给Kimi，让它按照截图的内容补全描述，出来的内容基本都能用。
全部改完之后，你要自己通读两遍，首先排查有没有前后矛盾的地方，比如前面写是SaaS模式，后面又写支持本地部署，这种低级错误Kimi偶尔也会犯，得你自己核对。其次要看看有没有太技术化的底层实现描述，比如Kimi可能会写“使用Redis实现缓存优化、采用分布式架构保证稳定性”，这些内容其实没必要写，软著审查看的是功能，不是你用了什么技术，你改成“系统支持1000人同时在线操作，页面响应速度不超过2秒”就行，太专业的技术描述反而容易让审查员觉得你是套模板。
要是你不确定自己改完的内容符不符合要求，可以去找个官方的模板对着比，我之前是在软著说明书模板页下了个过审的案例，对着结构和内容粗细程度调整的，比自己瞎琢磨要快很多。
我当时弄前4个软著的时候，都是自己写prompt、自己改内容，到第5个的时候刚好赶项目上线，连轴转了3天实在没精力改了，就把Kimi生成的初稿导出来，直接传到了软著Pro上，他们有专门做软著材料审核的老师，帮我把不符合要求的地方都改好了，还帮我调整了截图的排版，我直接提交就过了，连补材料的通知都没收到，省了我至少半天的功夫，赶在高企申报截止前把所有软著都拿到了。
其实用Kimi写软著说明书真的能省很多事，但你不能完全撒手不管，毕竟AI不知道你产品的实际情况，你得给它足够明确的信息，再花几十分钟核对调整，出来的内容基本都能过审，比你自己从零开始写要高效太多。我现在身边朋友要报软著，我都让他们先用Kimi生成初稿，再按照这个流程调整，基本都没踩过坑。
