第一次听说用Kimi写软著说明书，是在一个项目快收尾的时候。当时开发还在改最后几个接口，老板已经开始催软著申请材料，理由很简单：申报窗口、应用市场上架、后面项目验收都可能用到。按理说，代码是自己团队一行行写的，整理一份说明书不该有多难，可真坐到文档前才发现，难的不是写功能，而是把一个还在迭代的系统，整理成一份格式、逻辑、截图、代码都能对上的申报材料。
我一开始也图省事，直接把产品名称、功能清单丢给Kimi，让它“生成一份软著说明书”。出来的内容看着很像样：有引言、运行环境、功能模块、操作流程，语言也规整。但仔细一读就不对了。系统里明明没有“会员积分商城”，文档里却写了一大段；后台角色只有管理员和审核员，它硬是加了个“普通用户中心”；有些按钮名称跟实际页面完全不一样。这种材料如果直接提交，审查员一对照截图，很容易要求补正。
后来我换了个用法。不是让Kimi凭空创作，而是先自己把底稿准备好。底稿不用漂亮，但必须真实。我一般会列三样东西：软件全称、版本号、开发完成日期；系统里实际存在的模块和角色；每个核心页面的入口、按钮、操作结果。信息来源也不复杂，产品原型、测试环境、接口文档、菜单权限表都能用上。哪怕只是按操作顺序写几行大白话，也比让AI猜强。
我现在用Kimi整理说明书的实际流程
拿到底稿后，我不会一次性让Kimi写完整本。先让它根据我给的模块名称，整理说明书目录。目录要控制在软著说明书常见的范围内，通常包括软件概述、运行环境、安装或登录过程、主要功能操作流程、异常提示等。如果是Web系统，我会少写“安装”，多写浏览器访问、账号登录、各菜单操作；如果是客户端或App，再补安装、启动、升级这些内容。
第二步是分模块生成正文。比如把“客户管理”页面的实际字段丢给Kimi，让它按操作步骤写：进入菜单、点击新增、填写客户名称和联系人、保存后列表如何展示、如何查询和编辑。提示词里我会明确要求：不要新增我没提供的功能，不要写营销口号，不要使用“智能化赋能”“全方位管理”这类虚词，每段只描述页面上能看到、能操作的内容。这样生成出来的文字会稳很多。
第三步是人工校口径，这一步省不掉。软著材料里，软件名称、版本号、公司名称、完成日期、功能名称，最好从头到尾完全一致。我见过有人前面叫“订单管理系统”，截图标题里变成“订单服务平台”，代码里的工程名又是另一套，最后自己解释起来都费劲。用Kimi写文字很容易顺手写同义词，所以我最后会统一搜索一遍，把模块名、角色名、按钮名固定下来。
截图也要提前规划，不要等文档写完再随便补图。我的习惯是先列出需要截图的页面，再去测试环境走一遍主流程：登录页、首页、列表页、新增或编辑弹窗、详情页、审核或统计页。截图里尽量带上软件名称或系统菜单，页面数据不要出现真实客户信息、手机号、身份证号。每张图下面配一两句说明，说明文字和图里的按钮要一致。Kimi可以帮我把图片说明写得规范，但图里有什么，还得自己核对。
最容易踩坑的，反而是这些细节
一个坑是功能写得过满。很多人觉得软著材料写得越高级越好，于是让AI加上大数据分析、AI推荐、自动风控之类的内容。可截图里没有对应页面，代码材料里也没有相关逻辑，反而显得材料不真实。软著说明书不是商业计划书，不需要把系统包装得多么厉害，能清楚表达软件的功能和操作即可。
另一个坑是说明书和源代码文档脱节。比如说明书重点写了支付回调、消息推送，但提交的代码节选全是基础实体类和工具类，两边对应不上。虽然软著材料通常不需要逐行证明每个功能，但整体上应当像同一个软件。我的做法是在整理代码前，先根据说明书目录回看项目结构，尽量让代码材料中出现登录、业务模块、数据处理等相关类名或文件名。
还有一个很常见的问题：代码格式临时乱调。页码、页眉、空行、括号、中文注释，这些看似小，真正打印或转PDF时都可能出问题。尤其是从IDE里复制代码到Word，缩进和换行经常乱掉。建议代码文档尽早定好版式，前后各30页或按代理要求准备，每页行数尽量稳定，页眉中的软件名称、版本号保持统一。别等到提交前一晚才开始调，非常容易漏页。
如果是第一次申报，我还建议把申请表、说明书、源代码三份材料放在一起交叉检查。申请表里的软件简称、用途、技术特点，要能在说明书里找到依据；说明书里出现的核心模块，代码材料里最好也有痕迹。Kimi擅长把零散信息整理成通顺文字，但它不知道你们系统真实长什么样，也不会替你承担补正成本。把它当成一个效率很高的材料助理，而不是全自动代办，心态会更准确。
我后来还会把整理好的说明书初稿和截图清单放到软著Pro这类工具里对照检查。它更像一个顺手的材料辅助站点，适合在提交前看名称、版本、文档结构和常见缺项，比自己盯着Word反复看更容易发现不一致。当然，工具只能减少低级错误，真正决定材料质量的，还是你有没有把软件本身讲清楚。
给Kimi的提示词，宁可具体也别偷懒
我常用的写法不会只写“帮我写软著说明书”，而是会把边界交代清楚。例如：“以下是某后台系统的实际模块和页面字段，请按软件著作权说明书的写法描述操作流程；只使用我提供的功能，不增加新模块；语言客观，不写市场前景；每个功能包含入口、操作步骤、保存结果；输出为中文正文。”如果某一段写虚了，我会继续追问：“把这段改成按钮级操作说明，去掉没有页面依据的描述。”
遇到系统功能比较复杂时，我会让Kimi先复述模块关系，而不是直接成文。比如管理员如何创建账号、审核员如何处理工单、数据状态如何变化。等关系理顺了，再让它落正文。这样能避免AI把角色权限写串，也能减少前后矛盾。
说实话，用Kimi写软著说明书确实能省不少时间，尤其是把一堆粗糙的操作笔记改成正式文档，效率比以前高很多。但软著申报拼的不是谁生成得快，而是材料是否真实、完整、前后一致。你给它的事实越准确，它输出的内容越能用；你只给一个产品名就想拿到能直接提交的稿子，大概率还要返工。把截图、代码、申请表和说明书放在同一条线上核对，最后提交时心里才踏实。
