软著说明书总写不够字数，按这个章节模板补齐了五千字

开发软件之后想申请软著，软著里最让人头大的材料，往往不是代码，而是那份 5000–8000 字的设计说明书（也叫用户手册）。很多人要么写成了"产品宣传稿"满篇形容词，要么写成了"代码注释合集"全是片段，两种都过不了审查。审查老师看这份文档，主要核对两点：字数够不够、功能描述跟你的源代码对不对得上。

一、必含的六个章节，缺一节都悬

照着下面这个骨架写，基本不会漏：

合计正好落在 5000–8000 区间。注意软件名称和版本号在这六节里必须完全一致，别第一节写"小记 V1.0"第三节写成"记账本 V1.0"——这种低级不一致审查一眼就揪出来。

二、功能模块详述是字数主力，也最容易被打回

这一节占全文一半以上，写法是"一个模块一小节"。每节建议按这个套路展开：

### 3.1 记账录入模块
功能说明：用户填写金额、分类、备注后提交，系统校验金额格式并写入本地存储。
界面描述：顶部为分类选择标签，中部为金额输入框与日期选择，底部为保存按钮。
操作流程：
  1. 用户点击分类标签切换收支类型；
  2. 在金额框输入数字，失去焦点时做非负校验；
  3. 点击保存，数据以 JSON 写入浏览器 localStorage；
  4. 列表实时刷新展示最新一条。

关键点在于：你写的每一步操作，代码里都得有对应实现。比如上面说"失去焦点时做非负校验"，那你的前端代码里确实要有那段 onblur 校验逻辑。审查系统会比对说明书和源码，写了代码没有的功能（或者反过来）都属于"名不副实"，直接补正。

三、几个绝对不能碰的写法

踩过坑之后总结出几条红线：

• 别用"等功能""等模块"这种模糊收尾。审查要求具体，写"支持 Excel 导入、PDF 导出等功能"会被认为描述不清，老老实实把每个功能列出来。
• 别大段复制网络内容。设计说明书要体现你这个软件的特点，照搬别人的模板文风一眼就能看出来，而且和你的代码对不上。
• 别虚构界面。没做的按钮别写进操作流程，没接的接口别列进接口设计。
• 运行环境写真实值。开发语言、依赖版本、运行系统写你实际用的，别为显得"高级"乱填。

如果确实功能比较简单、怕写不满字数，与其注水不如把每个模块的操作流程、边界情况、异常提示写细——“金额输入为负时怎么提示”"分类为空时能否保存"这类细节，既是真实逻辑，又能自然撑起篇幅。

最后总结

软著说明书不是写作文，而是一份"让审查老师相信这软件真实存在且你写的"技术文档。套用引言、总体设计、功能模块、数据库、接口、运行说明这六节骨架，字数自然到 5000–8000；功能模块详述按"说明+界面+操作流程"展开，且每一步都要和源码对得上。避开"等功能"模糊表述、网络照搬、虚构界面这三条红线，说明书基本一次过。写的时候多想"我代码里是不是真有这么个逻辑"，比纠结辞藻有用得多。