software-copyright-writer

name	software-copyright-writer
description	根据真实代码仓库、官网页面、运行界面、模块范围和目标软著数量，分析软件著作权（软著）申报方向，拆分可申报主题，检查 Logo、版权、备案、截图和源码等材料约束，生成 3w-4w 字正文、局部代码片段、源码原文、网页截图证据和 .docx 文档。Use when Claude needs to prepare or split legitimate software copyright registration materials from code repositories, product pages, running UI screenshots, module scopes, or source evidence.

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 中一行源码对应一行内容

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

[此处添加对应图片]

7. 质检

生成结果后，逐项复核：

• 名称后缀是否合规
• 多个主题是否明显重叠
• 正文和截图是否对得上
• 正文是否使用产品说明口径，且没有把 GitHub、仓库、README、提交记录等内部分析信息写进去
• 标题编号是否严格递进，是否符合 ## 3. -> ### 3.1 -> #### 3.1.1 的层级关系
• 版权所有 是否完全一致
• 域名是否配有备案页证据
• Logo 是否配有商标证
• 正文是否达到约 30 页且总字数达到 3w-4w
• 局部代码片段是否与当前主题强相关且数量适中
• 源码文件是否为原始代码而不是解释文档
• 源码文档是否按“文件名 -> 原始代码”分段排版
• 源码范围是否可落到具体目录和文件
• 是否误带第三方版权信息

如果发现高风险问题，先列问题和修正建议，不要把明显会被打回的材料当成成品交出去。

Scripts

scripts/fetch_web_evidence.py

用这个脚本调用浏览器访问页面并生成截图。

适用场景：

• 用户只给了仓库 URL 和官网 URL，没有配套截图
• 需要给正文补“来源明确、可追溯”的页面证据
• 需要保存页面标题、URL 和抓取时间
• 需要自动访问产品界面并截取实际运行界面
• 产品界面需要登录时，可复用 Playwright storageState 登录态

公开页面示例：

python3 scripts/fetch_web_evidence.py \
  --url https://github.com/openai/openai-cookbook \
  --url https://openai.com \
  --output out/evidence

产品页面示例：

python3 scripts/fetch_web_evidence.py \
  --url https://example.com/dashboard \
  --wait-selector "#app" \
  --selector "main" \
  --viewport-width 1440 \
  --viewport-height 1200 \
  --output out/evidence

需要登录的产品界面示例：

python3 scripts/fetch_web_evidence.py \
  --url https://example.com/dashboard \
  --auth-state auth-state.json \
  --ready-text "工作台" \
  --wait-selector "#app" \
  --output out/evidence

需要人工登录时，可以先用可视化浏览器窗口：

python3 scripts/fetch_web_evidence.py \
  --url https://example.com/dashboard \
  --headed \
  --profile-dir out/browser-profile \
  --ready-text "工作台" \
  --save-auth-state auth-state.json \
  --output out/evidence

认证文件规则：

• --auth-state auth-state.json：读取 Playwright storageState 登录态文件，文件路径由调用者指定。
• --save-auth-state auth-state.json：截图结束后把当前登录态保存到指定 JSON 文件。
• --profile-dir out/browser-profile：使用持久化浏览器目录，cookie、localStorage 等登录态保存在这个目录里，适合多次复用后台登录。
• 不要把用户日常 Chrome Profile 当作 --profile-dir，避免污染用户浏览器数据。
• 如果使用 --ready-text 且页面没有进入登录后状态，--headed 模式会提示用户在弹出的浏览器里登录，并等待最多 --login-timeout-ms。非 --headed 模式会直接报错，不截登录页冒充产品界面。
• 只有当用户明确强制不登录继续时，才添加 --allow-unauthenticated；该模式不会等待登录，会直接截取当前页面。

脚本会输出：

• 截图文件
• manifest.json，用于后续自动插入 .docx
• summary.md

输入文件也支持批量页面配置：

首页 | https://example.com/dashboard | main
订单页面 | https://example.com/orders | #app

需要点击页面菜单后再截图时，可以使用 JSON 配置：

{
  "pages": [
    {
      "name": "产品资料上传界面",
      "url": "https://example.com/workbench",
      "click_texts": ["资料中心", "产品资料库", "新建/导入", "文本资料"]
    }
  ]
}

然后运行：

python3 scripts/fetch_web_evidence.py \
  --input pages.json \
  --profile-dir out/browser-profile \
  --headed \
  --ready-text "工作台" \
  --output out/evidence

--profile-dir 会复用持久化浏览器登录态，适合任意需要登录的产品后台、管理端或 SaaS 系统。第一次运行时可以在弹出的浏览器里登录，后续同一个目录会继续复用登录状态。

用户强制不登录也继续时：

python3 scripts/fetch_web_evidence.py \
  --input pages.json \
  --ready-text "工作台" \
  --allow-unauthenticated \
  --output out/evidence

为避免误操作，脚本不会自动点击 确认、提交、删除、保存、支付、创建 等可能改变数据的按钮。需要这类动作时，先让用户明确确认，优先只停留在截图所需界面。

scripts/assemble_source_code.py

用这个脚本生成源码原文文件。

适用场景：

• 已经确定某个软著主题对应的源码范围
• 需要按软著规则整理源码
• 需要直接输出原始代码，不要摘要

示例：

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

脚本规则：

• 汇总指定路径内的文本源码
• 保留原始注释
• 按文件名、源码、文件名、源码的顺序排版
• 总行数超过 3000 时，输出前 1500 行和后 1500 行
• 总行数不足 3000 时，输出全部源码
• 不自动添加解释性文字

scripts/export_ruanzhu_docx.py

用这个脚本把 Markdown 草稿导出为 .docx。

适用场景：

• 已经生成正文和源码原文文件
• 需要交付更正式的文档格式

脚本需要本地 Python 环境安装 python-docx。如默认 Python 缺包，可通过 SOFTWARE_COPYRIGHT_WRITER_PYTHON 指定另一个 Python 解释器。

截图脚本需要本地 Node.js、Playwright 和 Chrome/Chromium。默认使用 node、Node 模块解析路径和常见浏览器路径；如环境不同，可通过 SOFTWARE_COPYRIGHT_WRITER_NODE、SOFTWARE_COPYRIGHT_WRITER_NODE_MODULES、SOFTWARE_COPYRIGHT_WRITER_CHROME_PATH 指定。

依赖安装示例：

python3 -m pip install -r scripts/requirements.txt
npm install --prefix scripts
npx --prefix scripts playwright install chromium

References

• references/intake-checklist.md：材料收集和硬性规则检查
• references/splitting-rules.md：主题拆分规则、命名规则和确认输出
• references/template-standard.md：标准版正文模板
• references/template-extended.md：扩展版正文模板
• references/source-info-template.md：源码原文文件规则

Output Rules

默认输出建议：

• 每个软著一个正文 Markdown
• 每个软著一个源码原文文本文件
• 如果抓了网页证据，保留截图和 manifest.json
• 如果导出 .docx，正文和源码分别导出，不要混成一个文件
• 当输入信息已经完整时，正文必须一次性输出完整成稿，不要先输出提纲、目录草稿或分章半成品
• 正文目标总字数必须落在 3w-4w，优先靠近 3.5w
• 源码文档必须按文件名分段，逐行保留源码，不允许压缩成一大段
• 用户明确要求 5 份或其他固定数量时，如果仓库和材料足以支撑，就直接连续产出对应数量的完整文档

文件命名尽量稳定，例如：

• xxx-主题内容.md
• xxx-源码原文.txt
• xxx-主题内容.docx
• xxx-源码原文.docx

Failure Rules

遇到下面这些情况时，先提示风险，不要硬写：

• 用户要求的软著数量远大于仓库可独立拆分的主题数量
• 用户指定模块体量过小，无法合理拆出多个主题
• 只有设计稿，没有实际运行界面截图
• 版权所有 与著作权人名称不一致
• 出现 Logo 但没有商标注册证
• 出现域名但没有备案页
• 正文字数明显达不到 3w 或明显超过 4w
• 源码文件不是原始代码，而是摘要或说明文字
• 源码文档把多行代码压成一坨，无法做到一行源码对应一行文档内容

这种场景下，应该先给用户“缺口清单 + 修正建议 + 可继续的最小范围”。