Software Copyright Writer

Software Copyright Writer

Overview

使用这个 skill 处理“根据代码仓库和官网材料写软著”的完整流程，而不是只写一篇泛泛的介绍文档。它面向任意软件产品或平台项目，不绑定某个特定产品、技术框架或行业。

先判断仓库里到底能拆出几个像样的软著主题，再补材料、写正文、整理源码原文、抓网页证据、导出 .docx。如果仓库体量根本撑不起用户要的数量，直接指出来，不要硬凑题目。

仓库和 GitHub 只作为内部分析输入。最终软著正文必须使用“软件/系统/平台/产品”的正式说明口径，介绍产品功能、业务流程、运行界面和技术实现，不要写成代码仓库分析报告。

Compliance Boundary

这个 skill 只用于整理真实软件项目的申报材料，不用于伪造软件、伪造截图、伪造权属、虚构功能或包装不存在的源码。

• 不能把设计稿、营销页或登录页冒充实际运行界面
• 不能虚构著作权人、备案页、商标证或版权声明
• 不能为了凑数量强拆高度重复的主题
• 不能把第三方源码、依赖代码或第三方版权信息当作自有源码提交
• 材料不足时必须列缺口和风险，不能直接编造补齐

Output Mode

默认采用“一次性成稿”模式：

• 只有在主题不明确、数量不合理或材料缺失时，才允许停下来提问或给候选方案
• 一旦主题已经确认、材料已经够用，就不要再输出提纲、半成品、分段草稿或中间解释
• 直接一次性输出完整软著正文，目标体量为“每页 30 行、约 30 页、总字数 3w-4w，通常约 3.5w”
• 源码文件同样一次性输出完整结果，不要分批次贴代码
• 如果用户直接要求“给我产 5 份软著”这类批量输出，且信息已经够用，就连续完成全部文档，不逐份中断确认

Workflow

1. 收集输入

先收集这些信息：

• 必填：代码仓库、官网页面、软著数量
• 选填：指定模块、已有截图、Logo/商标注册证、域名备案页、著作权人全称、偏粗拆/细拆

缺少关键输入时，先停在材料确认阶段，不要直接开写。

用 references/intake-checklist.md 检查材料完整性和硬性约束。

2. 理解仓库并生成候选主题

先看仓库结构、README、核心目录和页面入口，判断哪些能力可以独立描述为一个软著主题。

主题必须同时满足这些条件中的大部分：

• 有清晰业务目标
• 有独立功能闭环
• 有可配套的实际运行截图
• 有能指向该主题的代码范围
• 能写出和其他主题明显区分的正文

如果用户指定模块：

1. 先判断模块体量是否足够支撑多个软著
2. 同时给出 粗拆 和 细拆 两套方案
3. 说明每套方案的边界、风险和适用数量

如果用户没有指定模块：

1. 先识别仓库内可独立申报的候选方向
2. 再按用户要求的数量给主题组合建议
3. 如果数量明显超出仓库体量，直接回绝不合理拆分

主题拆分规则和确认模板见 references/splitting-rules.md。

3. 确认主题或直接进入成稿

如果主题、数量和模块边界还不清楚，先输出候选主题让用户确认。

如果用户已经明确给出：

• 申报主体
• 软著数量
• 指定模块或明确主题
• 足够支撑写作的仓库和页面材料

那就不要再重复走“候选主题确认”流程，直接进入完整成稿。

确认输出里至少要包含：

• 主题名称
• 拆分粒度：粗拆 或 细拆
• 主题边界
• 主要功能点
• 预计截图来源
• 预计 8-12 张截图清单，优先 10 张，说明每张截图对应的功能点
• 预计源码范围
• 与其他主题的差异点

软著名称必须以 系统、平台、软件 或 app软件 结尾。

4. 准备材料和证据

用户确认主题后，再准备每个主题的材料。

必须重点检查这些硬规则：

• 出现 Logo 时，必须要求商标注册证
• 文档文字或截图中出现的 版权所有，必须与著作权人全称完全一致
• 界面截图必须是软件实际运行界面，不能是设计稿或效果图
• 出现域名时，必须要求域名备案查询结果页
• 源码需满足前 1500 行和后 1500 行，总计不少于 3000 行；不足则提供全部源码
• 保留源码注释，不要删除注释信息
• 不能保留第三方版权信息
• 正文必须扩写到足够支撑“每页 30 行、约 30 页、总字数 3w-4w，通常约 3.5w”的申报体量
• 每篇软著默认规划 8-12 张界面截图，优先按 10 张准备；除非产品界面确实不足，否则不要只放 3-5 张截图
• 最终正文不得出现 GitHub、仓库、repo、README、开源地址、提交记录、分支、clone 等代码托管或代码分析口径，除非它们是软件自身界面中不可避免的功能名称
• 正文不要写“通过分析仓库发现”“本仓库包含”“GitHub 页面显示”等来源性表述；这些只属于内部分析过程，不属于软著产品介绍

如果用户没有给现成网页截图，优先运行 scripts/fetch_web_evidence.py 调用浏览器访问官网、产品后台、演示环境或其他实际运行页面并生成截图。截图完成后保留 manifest.json，后续导出 .docx 时用 --evidence-manifest 自动把截图插入正文占位符。只有浏览器无法访问、登录态缺失或页面不可达时，才在正文中保留 [此处添加对应图片]。

截图前先做“截图规划”，把当前软著主题拆成更细的功能视角：

• 入口/首页或工作台
• 列表、搜索、筛选或分类视图
• 新建、编辑、配置或导入入口
• 表单、向导、参数配置或上传页面
• 详情页、预览页或结果页
• 状态流转、任务进度或处理结果
• 权限、成员、空间、日志或设置页
• 数据管理、统计、测试或运行反馈页
• 与当前主题强相关的异常提示、空状态或边界状态
• 其他能证明该主题功能闭环的页面

每张截图都必须能对应正文中的一个功能点或业务流程，不要为了凑数量重复截同一个页面。

产品界面截图必须先判断登录状态：

1. 先用 Playwright 打开用户提供的产品界面 URL，并用 --ready-text 或 --wait-selector 判断是否进入登录后页面。
2. 如果检测到需要登录，必须先让用户在 Playwright 弹出的浏览器窗口中完成授权登录，再继续进入目标页面截图。
3. 登录态优先保存到任务输出目录下的 browser-profile/ 或 auth-state.json，不要复用用户日常 Chrome Profile。
4. 如果用户明确要求“不登录也继续”，才允许加 --allow-unauthenticated 继续截图当前页面；此时必须在最终材料中标注截图可能不是完整产品运行界面，必要时保留 [此处添加对应图片]。

5. 生成每个软著的两类文件

每个软著必须输出两个文件：

1. 主题内容文件
2. 源码原文文件

正文模板按主题体量选择：

• 普通单主题：读 references/template-standard.md
• 平台型或流程较长主题：读 references/template-extended.md

源码原文文件规则见 references/source-info-template.md。

正文文件不是短说明，必须按申报口径一次性写到约 30 页、每页 30 行左右、总字数 3w-4w 的体量，通常控制在 3.5w 左右。

正文语言必须是正式软著产品说明语言：

• 以“本软件”“本系统”“该平台”“用户可通过”等表达介绍功能和流程
• 重点写产品功能、界面操作、业务对象、数据处理、运行效果和技术实现
• 可以引用少量局部代码片段说明技术实现，但不要把源码来源、仓库结构、GitHub 页面或 README 内容写进正文
• 多篇软著来自同一项目时，也要用各自产品功能边界来区分，不能用目录名或仓库模块名当正文主叙述

标题层级必须严格递进：

• 一级正文标题用 ## 1. 标题，编号只有一段
• 二级正文标题用 ### 1.1 标题，编号必须包含父级编号
• 三级正文标题用 #### 1.1.1 标题，编号必须包含父级和二级编号
• 所有 Markdown 标题必须顶格写，行首不能有空格、Tab 或全角空格
• 不允许把标题写进列表、引用、缩进段落或表格单元格里
• 3.1 下方如继续拆标题，只能写 3.1.1、3.1.2、3.1.3，不能跳成 3.2.1 或直接写 3.1 模块目标
• 同级标题必须连续编号，不能从 3.1.1 跳到 3.1.3
• 导出 .docx 前会校验标题编号，并会兜底归一化缩进标题；编号不合规时必须先修正文档，不要强行导出

正文里可以加入少量“局部代码片段”，但只能放和当前主题直接相关的关键代码，不能拿大段源码灌水。优先放在：

• 功能模块设计
• 关键业务流程说明
• 关键技术实现

源码文件不要写解释、摘要、目录说明、风险说明。源码文档排版必须按“文件名 -> 原始代码 -> 文件名 -> 原始代码”的顺序组织。

如果已经确认了源码范围，运行：

python3 scripts/assemble_source_code.py \
  --path repo/module-a \
  --path repo/module-b \
  --output out/source-code.txt

该脚本会按“前 1500 行 + 后 1500 行，不足则全量”的规则输出源码原文，并按文件名分段。

6. 导出 .docx

正文和源码原文都生成后，如果用户需要正式交付文档，运行：

python3 scripts/export_ruanzhu_docx.py --content path/to/topic.md --source path/to/source-code.txt --output out/docx

该脚本会分别导出正文 .docx 和源码 .docx 两个文件。

如果已经用 fetch_web_evidence.py 生成截图证据，导出时必须传入 manifest.json：

python3 scripts/export_ruanzhu_docx.py \
  --content path/to/topic.md \
  --source path/to/source-code.txt \
  --evidence-manifest out/evidence/manifest.json \
  --output out/docx

导出脚本会按 manifest.json 中的截图顺序，把正文中的 [此处添加对应图片] 逐个替换为实际图片。也可以用 --image-dir path/to/screenshots 直接读取某个图片目录。

导出排版默认使用：

• 正文：中文 宋体，英文和数字 Times New Roman
• 正文字号：12pt
• 正文行距：1.5 倍
• 一级标题：黑体、16pt、加粗
• 二级标题：黑体、14pt、加粗
• 三级标题：黑体、12pt、加粗
• 源码文档：按文件名分段，文件名单独成行，源码逐行写入，Word 中一行源码对应一行内容

如果正文中需要插入项目截图但当前无法完成截图，必须直接预留占位符：

[此处添加对应图片]