软著申请资料生成
本项目基于 Fokkyp/SoftwareCopyright-Skill 1.3 进行了大范围修正、增补与重构；来源、许可继承与主要变化详见 README.md。
本 skill 生成可审阅、可追溯的软著申请资料。详细规则拆分于 references/ 之下，按阶段需要读取；本文件仅保留跨阶段的核心原则与严格顺序化的执行步骤。
创建任何材料或中间产物前，必须先读取 references/output_directory_rules.md，确定目标项目根目录与本阶段唯一允许的写入位置。
运行条件
- 需要 Python 3.10 或更高版本。
- 推荐安装
python-docx；不可用时可选用pandoc作为 DOCX 降级路径。 - 处理操作视频时需要
ffmpeg与ffprobe，仅用于提取具有时间覆盖保证的画面帧。 - 代码鉴别材料的 PDF 由脚本直接渲染，推荐安装可选依赖
fpdf2（pip install fpdf2）。该份材料的分页本就由脚本算定（每页 50 行、页间显式分页符），直接渲染无信息损失，无需办公套件；fpdf2不可用时降级至 Microsoft Word 或 LibreOffice。 - 操作手册的 PDF 仍需 Microsoft Word 或 LibreOffice 其中之一，因其目录是 Word 域，页码须经渲染回填。两者皆不可用时，该份 PDF 须由用户自行导出，其页数不受硬性校验，不阻断流程。
- 三条路径均不使用
python-docx输出 PDF：该库只读写 DOCX 的 OOXML 结构，不含排版渲染引擎，既不计算分页，也不解析目录域，更不具备 PDF 输出能力。
脚本目录
本文档全部命令中的 ${SKILL_DIR} 指本 SKILL.md 所在目录的绝对路径。执行第一个脚本前必须先确定该路径并导出，否则后续全部脚本调用将因路径解析失败而中断：
bashexport SKILL_DIR=<本 SKILL.md 所在目录的绝对路径>
若当前运行环境已注入表示 skill 所在目录的变量，直接以该变量赋值即可。导出后须先行确认，通过后再进入第 1 步：
bashtest -f "${SKILL_DIR}/scripts/check_environment.py" \ && echo "SKILL_DIR 可用" \ || echo "SKILL_DIR 未正确设定，请重新确认本 SKILL.md 所在目录"
核心原则
- 固定输出根目录为
<目标项目根目录>/软件著作权申请资料/。运行使用相对默认路径的脚本前须先进入目标项目根目录；仅在测试 Skill 自身时方可显式指定隔离的临时目录。完整目录树、归类、命名、禁止事项与旧项目兼容原则详见 references/output_directory_rules.md。 - 先生成 Markdown 草稿，用户确认后再生成正式 Word/TXT；正式可交付或可上传材料只能写入
正式资料/，版权中心操作记录、签章页、回执与状态证据只能写入提交记录/，不得散落于输出目录根部或混入正式资料。 - 正式 Word/TXT 的文字一律使用默认黑色字体，不生成蓝色超链接、主题色标题或其他彩色文字；Markdown 链接写入 Word 时必须转为普通文本。
- 正式资料中的软件名称、代码 Word 页眉版本号必须与
草稿/申请表信息.md已确认的「软件全称」「版本号」字段一致；正式生成时以已确认字段为准。 - 代码材料必须来自真实项目源码，禁止由模型编造代码。
- 操作手册与申请表中关于功能行为的每一处陈述，均须回到源码逐条核对，不得仅凭 README、设计文档或业务理解推断。项目自述文件本身可能与实现不符：一次真实使用中，README 称趋势图在缺数据处「曲线断开」，而实现是剔除该点后连成连续折线；README 称报告正文「不含任何统计数字」，而提示词保留了总评总分；README 称统计数值不外发，而报告请求实际携带时长、字数与三类问题词次数。这三处若照抄，材料即为失实陈述，其中数据流向一条还涉及隐私声明。凡涉及数值口径、数据流向、状态判定、操作步数与控件文案的表述，一律以源码为准。
- 手册中引用的按钮、输入框、页签与菜单名称，须与界面文案逐字一致。同一次使用中曾出现「后端」与实际的「AI 后端」、「表达风格」与实际的「我想要的表达风格」等十一处不一致，审核员对照截图即可发现。
- 撰写申请表与操作手册前，必须先形成模型研判后的
草稿/业务理解.md/json，以理解软件业务、行业、目标用户、核心价值与操作流程；详见 references/business_understanding_rules.md。 - 若用户能够提供该软件的真实操作演示视频，操作视频优先于纯代码推断：典型操作流程、操作手册的操作步骤与界面截图均应优先以视频中实际观察到的内容为准。视频处理仅负责抽帧，每一帧所呈现的操作内容必须由模型逐张查看后判定，不得仅按文件名或时间顺序推测。
- 脚本只能收集项目证据、校验字段与生成文件；行业判断、功能抽取、代码抽取选择、操作手册结构必须由模型阅读项目后决定，不得依赖脚本关键字表或固定范本。
- 生成代码材料前，必须先生成代码文件候选清单，由模型理解项目后填写抽取文件与选择理由，再交用户确认或修改；详见 references/code_selection_rules.md。
- 代码鉴别材料的分页、页数规则详见 references/copyright_material_rules.md。
- 操作手册的叙述性正文一律由模型撰写，脚本不造句、不改写模型写下的文字，仅承担排版、装配与校验。原因在于，按结构化字段拼装句子必然产出模板化正文与病句，与本 skill 的核心原则相违背。
- 操作手册成稿应呈现为真实软件随附的操作说明，而非研发说明、功能清单或机器生成的汇总文。章节分为必备与项目自定两类：必备章节固定，其余章节一律由模型阅读项目后自行判断设立，本 skill 不提供可选章节清单，脚本亦不解释章节语义。凡「本可以是另一种做法而选择了这一种」之处必须写明真实原因，功能章节必须写明可预见的边界情形；技术性表述按所解释的对象区分，并非全文禁止。完整要求、写作口径、图注规范与自检要求详见 references/manual_structure.md。
- 申请表信息各字段的口径、默认值与一致性要求详见 references/application_fields.md。
- 在中国版权保护中心完成 R11 官网填报、保存草稿、确认填报、打印及上传签章页时，读取 references/ccopyright_submission_workflow.md。
- 申请表信息中的硬件/系统环境必须由用户确认或填写，不能硬编码。
- Word 生成优先使用
python-docx；不可用时依次降级至pandoc与基础 OOXML，不得引用本 skill 之外的 DOCX 生成目录或工具。
⛔ 强制人工确认点
凡涉及用户选择、确认或补充信息的阶段，必须先停止当前执行，不得继续调用下一步脚本。即使处于自动审核、自动继续或无人值守模式，仍必须将 STOP_FOR_USER 与 NEXT_ACTION 原样告知用户，并等待用户输入后再继续。
禁止使用「用户未选择则默认继续」的逻辑。用户回复确认后，先以确认脚本记录对应确认点，再进入下一阶段：
bashpython3 ${SKILL_DIR}/scripts/confirm_stage.py --workdir 软件著作权申请资料 --stage <阶段名> --note "<用户确认内容>"
必须停止并等待用户确认的环节共七处。其中 business、code-selection、screenshot-method、application-fields、markdown 五处每次运行均会留下确认记录文件，environment 仅在 DOCX 环境缺失时才需要记录，二者合计六处由校验脚本核查；project 发生在材料目录建立之前，不留记录文件，须由执行者自行守住。
environment：python-docx与pandoc均不可用时，用户必须在「安装 python-docx」与「使用基础 DOCX 降级路径继续」之间作出选择。project：存在多个项目候选目录时，用户必须指定项目目录。business：草稿/业务理解.md生成后，用户必须确认行业、目标用户、核心功能与申请口径。application-fields：草稿/申请表信息.md生成后，用户必须补全并确认硬件、系统环境、著作权人、日期等字段；软件全称含有商标文字时，确认内容须包含用户对商标文字的处理选择。code-selection：草稿/代码文件选择.json生成后，用户必须确认或修改抽取文件。screenshot-method：操作手册截图前，用户必须在操作视频、浏览器自动化截图能力、桌面操作截图能力、用户自行截图四种方式中选择一种（是否提供操作视频已在第 3 步询问，此处正式记录最终采用的方式，视频未覆盖的部分可补充说明所采用的处理方式）；用户明确表示「现在不截图/先跳过截图」时，记录为skip。markdown：全部 Markdown 草稿完成后，用户必须确认可以进入 Word/TXT 生成。
工作流
1. 环境检查
先进入已确定的目标项目根目录，再创建固定输出目录并检查运行能力：
bashpython3 ${SKILL_DIR}/scripts/check_environment.py \ --out-dir 软件著作权申请资料
输出：
软件著作权申请资料/环境检查.md软件著作权申请资料/环境检查.json
环境检查必须向用户说明以下事项：
- 材料将生成于「目标项目根目录/软件著作权申请资料」之下。
- Markdown 草稿、TXT、基础 DOCX 是否可用。
python-docx是否可用（决定是否采用规范 Word 排版路径）。python-docx不可用时，pandoc是否可用作降级路径。fpdf2是否可用（决定代码鉴别材料能否脱离办公套件直接生成 PDF）。
用户选择：
- 若
python-docx已可用，直接继续，无需用户选择。 - 若
python-docx不可用而pandoc可用，继续以pandoc降级生成，同时提示用户可执行pip install python-docx以获得更规范的排版控制。 - 若
python-docx与pandoc均不可用，必须停止并等待用户在「安装 python-docx」与「使用基础 OOXML 降级路径继续」之间作出选择；不得自动继续。
需要用户选择时，用户回复后记录确认点：
bashpython3 ${SKILL_DIR}/scripts/confirm_stage.py \ --workdir 软件著作权申请资料 \ --stage environment \ --note "<用户选择>"
不得延至最终验证阶段才发现 DOCX 生成环境不可用；该信息必须在流程开始时给出。
2. 项目定位
用户通常将项目置于当前文件夹之下。先扫描当前目录，排除本 skill、自身输出目录、node_modules、构建产物与隐藏目录，确定最可能的项目根目录。
存在多个候选项目时，必须停止并询问用户选择；仅有一个明显候选项目时，可直接使用。
3. 操作视频（可选）
在分析项目并撰写业务理解、操作手册之前，须先停止并询问用户是否具备该软件的真实操作演示视频（录屏）。若有，该视频优先于纯代码推断，并同时用于后续的业务理解、操作手册撰写与截图三个环节。
- 用户没有视频时，跳过本步骤，继续第 4 步；截图方式留待第 9 步在浏览器自动化截图能力、桌面操作截图能力、用户自行截图三者中选择其一。
- 用户能够提供视频时，获取文件路径后运行：
bashpython3 ${SKILL_DIR}/scripts/process_operation_video.py \ --video <视频文件路径> \ --out-dir 软件著作权申请资料/操作视频
该脚本按时间均匀抽帧（默认最密为每秒 1 帧，帧数上限 120 张，抽帧间隔按视频总时长自动拉伸；--max-frames 可调高该上限），并叠加一次画面突变检测以补充额外的帧。抽取哪些帧不单独依赖画面突变检测判定，原因在于真实界面录屏多呈现为「大部分画面不变、仅有一小块区域变化」，纯突变检测的分值常低至无法测出，会导致真实发生的状态变化被静默遗漏，因此必须以按时间均匀取样作为基础覆盖。视频较长（超过数分钟）时应调高 --max-frames，否则平均帧间隔将被显著拉大，可能遗漏密集的操作步骤。每一帧所进行的操作及界面所含内容，必须由模型使用当前环境可用的图片查看能力逐张检查 软件著作权申请资料/操作视频/帧/*.png 后自行判定，不得仅凭文件名或时间戳推测画面内容。
输出：
操作视频/帧/*.png：按时间均匀取样并叠加画面突变检测抽取的帧，附带时间戳。操作视频/视频证据.md：逐帧时间戳与图片相对路径。操作视频/视频证据.json：同一内容的结构化版本。
第 1 步环境检查显示 ffmpeg 不可用，或视频处理脚本报错时，必须停止并交由用户选择：安装 ffmpeg 后重试，或放弃视频、改用第 9 步的其他截图方式。不得跳过用户选择而径行假定视频可用或视频不存在。
4. 项目分析
运行：
bashpython3 ${SKILL_DIR}/scripts/analyze_project.py \ --project <项目目录> \ --out 软件著作权申请资料/analysis/project.json
分析内容包括：
package.json、README、脚本命令、依赖- 前端框架与主要编程语言
- 入口文件、路由、页面、组件、接口、状态管理
- 源码文件数量与源程序行数
- 软件名称候选、主要功能候选、运行命令候选
5. 业务理解
本步骤首次以 --software-name 使用软件全称，因此运行前须先与用户初步确定软件全称，并完成商标核查：由模型审阅其中是否含有商标文字（品牌名、自造词、第三方平台名称或带 ®、™ 标识的文字）。含有商标文字时，须向用户指明具体文字，说明版权中心可能要求提供商标注册证明或权利声明，并请用户选择「去除商标文字，改用描述性名称」或「保留原名称并提供商标注册证复印件或权利声明」。用户作出选择前不得运行本步骤脚本。识别口径、两种处理方式的适用条件与记录方法详见 references/application_fields.md。
在撰写申请表与操作手册之前，先由脚本收集项目证据：
bashpython3 ${SKILL_DIR}/scripts/generate_business_context.py \ --project <项目目录> \ --analysis 软件著作权申请资料/analysis/project.json \ --software-name "<软件全称>" \ --out-dir 软件著作权申请资料/草稿
输出：
草稿/业务理解证据.md草稿/业务理解证据.json草稿/业务理解模型稿模板.json
本步骤仅收集证据，不决定最终业务口径。其后必须由模型阅读 业务理解证据.md/json、README、PRD/BRD、页面文案、路由、接口、必要源码、用户补充资料，以及第 3 步生成的 操作视频/视频证据.md（用户提供了操作视频时），自行判断行业、目标用户、核心价值、应写入的功能、典型操作流程与操作手册章节结构，生成业务理解模型稿 JSON。存在操作视频时，operation_flow（典型操作流程）应优先反映视频中观察到的真实操作顺序，而非仅按代码路由结构推断。字段清单与 manual_modules 子字段要求详见 references/business_understanding_rules.md；模型不得依据脚本关键字表决定行业、功能与结构。
项目材料不足、业务类型较新，或用户明确希望参考竞品时，可联网检索相近产品与行业资料；外部调研仅用于理解行业表达，不能编造项目不存在的功能，调研摘要应写入业务理解草稿并区分「项目证据」与「行业参考」。
模型完成研判后运行：
bashpython3 ${SKILL_DIR}/scripts/generate_business_context.py \ --project <项目目录> \ --analysis 软件著作权申请资料/analysis/project.json \ --software-name "<软件全称>" \ --out-dir 软件著作权申请资料/草稿 \ --model-context <模型生成的业务理解JSON>
输出：
草稿/业务理解.md草稿/业务理解.json
生成后必须停止，等待用户确认或修改；业务理解确认前，不得生成申请表与操作手册。业务理解仍不充分时，先请用户补充产品说明。用户确认后运行：
bashpython3 ${SKILL_DIR}/scripts/confirm_stage.py \ --workdir 软件著作权申请资料 \ --stage business \ --note "<用户确认内容>"
6. 申请表字段确认
根据分析结果，按官网实际表单顺序向用户确认申请表全部字段（软件全称、版本号、著作权人、硬件/系统环境、主要功能等）。可由项目推断的字段可先给出建议值，但硬件/系统环境必须允许用户选择建议值或手动填写。完整字段清单、默认值与一致性要求详见 references/application_fields.md。
软件全称的商标核查已在第 5 步运行前完成。本步骤中用户若更改软件全称，须对新名称重新执行商标核查，并重新运行第 5 步、重新确认业务理解，以免 业务理解.md/json 沿用旧名称。
本阶段须先停止并等待用户输入；收到用户回复后，可整理为 answers JSON 传入申请表草稿生成。申请表字段的最终确认于 草稿/申请表信息.md 生成后记录（见第 8 步）。
7. 代码文件选择确认
生成代码材料前，先运行候选文件分析：
bashpython3 ${SKILL_DIR}/scripts/propose_code_selection.py \ --project <项目目录> \ --analysis 软件著作权申请资料/analysis/project.json \ --out-dir 软件著作权申请资料/草稿
输出：
草稿/代码文件候选清单.md：供用户查阅的候选说明。草稿/代码文件选择.json：可编辑的选择文件。
脚本生成的候选清单仅列举证据，不默认选定文件。模型必须先阅读业务理解、候选文件、入口文件、页面文件与必要源码，判断哪些源码最能体现软件的真实功能与运行逻辑，再修改 代码文件选择.json 中每个文件的 selected 与 model_reason。选择优先级与边界详见 references/code_selection_rules.md。用户确认并记录 code-selection 确认点后，代码抽取仅读取 代码文件选择.json 中选中的完整文件。用户确认后运行：
bashpython3 ${SKILL_DIR}/scripts/confirm_stage.py \ --workdir 软件著作权申请资料 \ --stage code-selection \ --note "<用户确认内容>"
8. Markdown 草稿生成
运行代码材料抽取：
bashpython3 ${SKILL_DIR}/scripts/extract_code_material.py \ --project <项目目录> \ --analysis 软件著作权申请资料/analysis/project.json \ --selection 软件著作权申请资料/草稿/代码文件选择.json \ --software-name "<软件全称>" \ --version "<版本号>" \ --out-dir 软件著作权申请资料/草稿
代码分页与页数规则（每页行数、代码-前后各30页.md/代码-全部.md 的生成条件、前后各满 30 页的对齐方式、注释剔除规则、候选源码不足时的停止条件）详见 references/copyright_material_rules.md。同时生成 代码提取清单.md 与 代码提取清单.json，用于追溯代码来源与各文件的行数构成。抽取时一律剔除全部注释（中国版权保护中心要求代码材料不含注释），剔除后页数不足时按提示在 代码文件选择.json 中补选文件；终端或清单提示「仅剔除整行注释」的文件，须人工检查行尾注释是否残留。
生成申请表信息草稿：
bashpython3 ${SKILL_DIR}/scripts/generate_application_info.py \ --analysis 软件著作权申请资料/analysis/project.json \ --code-manifest 软件著作权申请资料/草稿/代码提取清单.json \ --business-context 软件著作权申请资料/草稿/业务理解.json \ --software-name "<软件全称>" \ --version "<版本号>" \ --out-dir 软件著作权申请资料/草稿
生成后必须停止，交由用户检查并补全 草稿/申请表信息.md。字段补全并确认后运行：
bashpython3 ${SKILL_DIR}/scripts/confirm_stage.py \ --workdir 软件著作权申请资料 \ --stage application-fields \ --note "<用户确认内容>"
生成操作手册草稿：
bashpython3 ${SKILL_DIR}/scripts/generate_manual_draft.py \ --analysis 软件著作权申请资料/analysis/project.json \ --business-context 软件著作权申请资料/草稿/业务理解.json \ --software-name "<软件全称>" \ --version "<版本号>" \ --out-dir 软件著作权申请资料/草稿
操作手册的全部叙述性正文由模型撰写，脚本不造句：说明章正文写入 manual_overview，功能特点各项写入 manual_feature_highlights，各功能模块章节正文写入 manual_modules 每项的 body，项目自定章节正文写入 manual_extra_sections 每项的 paragraphs。脚本仅负责章节顺序与编号、图注编号、表格渲染、页眉，以及段落数、字数、必备要素覆盖、套话与模板句式的校验；不得改写模型写下的文字，不作术语替换与病句修补，发现问题一律报为待修正项，交由模型重写。manual_modules 中 entry、visible_elements、operation_steps、feedback 四项为硬性核对项，未在正文中体现即报待修正；validation_rules、rationale、boundary 三项为提示性核对项，未体现时只列出具体条目供模型判断。两类字段均只供校验，不用于拼装句子。功能章节仍按 manual_modules 逐个成章；必备章节之外的章节由模型按项目实际情况自行判断设立，写入 manual_extra_sections，脚本仅按其 position 与 order 插入并原样渲染，不解释章节语义，该字段为空时不生成任何自定章节。功能章节、功能特点与常见问题解答面向普通用户，避免以代码、框架、接口等实现术语解释用户动作；「说明」章与全部项目自定章节允许并且应当出现技术性表述。第 3 步提供了操作视频时，凡能在视频中找到对应画面的模块，其操作步骤、界面元素与操作结果描述均应以模型逐帧查看 操作视频/视频证据.md 后观察到的真实内容为准，而非仅凭代码结构或业务理解推断；视频未覆盖的模块仍按现有方式基于业务理解与源码证据撰写。完整的骨架、写作口径、「去除机器生成特征」要求与自检记录规范详见 references/manual_structure.md。撰写过程中由 agent 自行循环检查、压缩重复内容并补正缺失信息。每个核心模块正文通常为 2 个短段落，普通模块目标约 120 至 220 个中文字符，复杂模块上限 400 字；保留真实入口、主要动作、关键规则、结果反馈与独立截图预留，不因凑足字数而复述背景。完整草稿完成后仅向用户发起一次整体确认，确认前不得进入正式 Word/TXT 生成。
9. 截图方式选择与获取
先检查第 3 步是否已提供并处理操作视频（即 软件著作权申请资料/操作视频/视频证据.md 是否存在）：
- 视频证据存在时：对于操作手册中能在视频里找到对应画面的模块，模型先使用 Read 工具逐帧查看
操作视频/帧/*.png，为每个模块挑选最能体现该模块界面与操作结果的一帧或数帧，复制至软件著作权申请资料/截图/并按模块命名（例如项目管理-列表页.png），不能仅按时间顺序机械分配，也不能为一个模块配置多张无关的帧。仅当操作手册中存在视频未覆盖的模块时，才需从下述三种方式中另选一种处理该部分缺口。 - 视频证据不存在时：从下述三种方式中选择一种，覆盖整本操作手册。
必须给出的截图方式（视频已覆盖时，以下三种仅用于处理缺口模块）：
- 浏览器自动化截图能力：适用于已在浏览器中打开的 Web 项目，优先用于网页全页截图。当前常见实现包括 Playwright MCP、Chrome DevTools MCP、Browser Use、Stagehand 与 Browserbase，具体以当前运行环境实际提供的工具为准。
- 桌面操作截图能力：适用于需要通过桌面应用或浏览器界面点击、切换、查看状态后截图的场景。当前常见实现为各家的 computer use 类桌面控制工具，具体以当前运行环境实际提供的工具为准。
- 用户自行截图：由用户将 PNG/JPG/JPEG/WebP 图片放入
软件著作权申请资料/用户截图/，agent 仅负责整理与引用。
选定方式后，先与用户确认软件中是否存在需要系统授权或会产生用户数据的功能（麦克风、摄像头、定位、通讯录等）。此类界面若要截图，须由用户决定是否授权：一次真实使用中，录音进行中的界面因不宜触发麦克风授权而整章缺图，最终以待命态、专注模式与深色主题三张同界面的不同状态替代，并在图注中如实说明所示状态，未声称是录音场景。这样处理可以接受，但须在生成报告中写明哪些功能未取得截图及其原因，不得以其他状态的截图冒充。
另须注意，截图过程本身可能改变用户数据：同一次使用中，为截取「粘贴逐字稿」的分析结果，软件强制归档而在用户数据目录新增了一条训练记录。凡此类副作用，须在报告中如实列出新增或改动的文件路径，由用户决定是否清理。
用户明确表示「现在不截图」「先跳过截图」「这次不截图」时，同样必须记录截图方式的确认，方法填 skip。跳过截图不阻塞正式资料生成，但操作手册中每个核心功能模块必须保留可见的截图预留文字，例如：【截图预留：请在此处插入"项目管理"页面或操作结果截图。】。不得使用 HTML 注释作为截图占位，原因在于该形式在正式 Word 中不可见。
用户选择后，先记录确认点（视频已完全覆盖时，方法填 video；以视频叠加其他方式补足缺口时，方法填实际用于处理缺口的方式，并在 --note 中说明视频覆盖了哪些模块）：
bashpython3 ${SKILL_DIR}/scripts/confirm_stage.py \ --workdir 软件著作权申请资料 \ --stage screenshot-method \ --method <video|browser-automation|desktop-automation|user-supplied|skip> \ --note "<用户选择>"
然后按用户选择检查当前能力并执行：
- 选择 video：无需额外工具，按前文「视频证据存在时」所述方式从
操作视频/帧/中挑选并整理至截图/；操作手册中仍有模块未被视频覆盖时，返回上述三选一处理该部分缺口。 - 选择浏览器自动化截图能力：先通过工具发现能力确认当前环境是否存在浏览器自动化工具，且同时具备「列出页面」「抓取页面快照」「截图」三项操作（工具名前缀通常形如
mcp__playwright__、mcp__chrome_devtools__）。可用时，先列出当前浏览器页面确认目标，再按页面或路由逐个截图并保存至软件著作权申请资料/截图/；不可用时停止，并告知用户须重新选择截图方式或手动提供截图。 - 选择桌面操作截图能力：先通过工具发现能力确认当前环境是否存在桌面控制工具，且同时具备「读取当前应用状态或屏幕画面」「点击」「按键」三项操作（工具名前缀通常形如
mcp__computer_use__）。可用时，先读取目标应用或浏览器的当前状态，再按操作手册的需要导航并截图；若该工具仅能返回会话内截图而无法直接保存图片文件，则须说明该项限制，并请用户改选浏览器自动化截图能力，或将截图放入用户截图/。 - 选择用户自行截图：创建
软件著作权申请资料/用户截图/，提示用户将截图文件放入该目录；用户放入后运行下述整理命令，将图片复制至软件著作权申请资料/截图/并生成截图清单.json。 - 选择跳过截图：不运行截图工具，继续保留操作手册中的可见截图预留文字；在生成报告中说明用户选择暂不截图，正式操作手册已预留截图位置。
bashpython3 ${SKILL_DIR}/scripts/capture_screenshots.py \ --manual-dir 软件著作权申请资料/用户截图 \ --out-dir 软件著作权申请资料/截图
截图成功后，将截图引用补入 草稿/操作手册.md；截图失败或用户选择暂不提供截图时，继续生成带截图预留位的文字版，并在报告中说明「操作手册截图未生成或未插入，已保留截图预留位置」。
10. Markdown 草稿确认
生成 Word 前，必须由用户确认 软件著作权申请资料/草稿/ 下的 Markdown。
重点检查：
- 软件名称与版本号是否一致
- 代码材料（前 30 页 + 后 30 页，按完整文件边界对齐、合并为一份文档，页码连续）页眉的软件名称与版本号是否与
申请表信息.md的「软件全称」「版本号」一致；文件名所称页数与文档首行标题、申请表「页数」三者是否一致 - 代码材料中是否已无注释；
代码提取清单.md标注「仅剔除整行注释」的文件，行尾注释是否已人工处理 - 操作手册 Word 页眉是否与代码材料页眉一致，均使用
申请表信息.md的「软件全称」与「版本号」 业务理解.md是否准确反映软件的真实业务、行业与目标用户申请表信息.md中「待用户确认」的字段是否已确认- 代码材料是否仅来自用户确认的完整文件
- 操作手册是否符合审核员阅读场景，普通读者能否理解模块用途与操作方式
- 操作手册每个章节是否具备段落内容，核心模块是否写清模块用途、操作过程与结果反馈
- 必备章节是否齐全；项目自定章节是否逐项满足三条判定标准且能指向具体证据，有无为凑足章节数而设立、或应当设立却缺失的章节；章节顺序与编号是否连续
- 「原因在于……」式说明是否来自真实约束，将软件名替换为任意其他软件后是否仍然成立（仍然成立即属空话，须删除或改写）
- 功能章节是否写明可预见的边界情形，例如数据缺失时显示何种内容、前置条件未满足时哪些功能仍可使用
- 截图是否按「图 <章号>-<章内序号>」编号，每幅是否具备独立图注且未简单复述正文
- 常见问题是否为软件真实会出现的故障与提示，排查步骤是否可依次执行
- 截图是否正确；若用户跳过截图，正式操作手册是否保留可见截图预留位置
用户确认后，必须记录 markdown 确认点；未记录时不得生成正式 Word/TXT。
bashpython3 ${SKILL_DIR}/scripts/confirm_stage.py \ --workdir 软件著作权申请资料 \ --stage markdown \ --note "<用户确认内容>"
11. 正式 Word 与 TXT 生成
用户确认后运行：
bashpython3 ${SKILL_DIR}/scripts/build_docx_from_md.py \ --workdir 软件著作权申请资料 \ --software-name "<软件全称>" \ --version "<版本号>"
正式生成脚本必须重新读取 草稿/申请表信息.md 中已确认的「软件全称」与「版本号」，并据此生成正式资料文件名、代码 Word 页眉与操作手册 Word 页眉。操作手册页眉必须与代码材料页眉格式一致：左侧为「软件全称 版本号」，右侧为「第 <页码> 页」。若命令参数 --software-name / --version 与申请表字段不同，以申请表字段为准，并在 正式资料/生成报告.md 中记录提示。
输出：
正式资料/申请表信息.txt- 代码达到或超过 60 页：
正式资料/<软件全称>-代码(前30页+后30页).docx（前后段按完整文件边界对齐、合并为一份文档，页码连续编号；抽取环节已自动调整文件顺序使前后各满 30 页，未能对齐时文件名会改为反映真实页数）
- 代码不足 60 页：
正式资料/<软件全称>-代码(全部).docx
正式资料/<软件全称>_操作手册.docx正式资料/生成报告.md
12. 转换为 PDF
平台上传只接受 PDF，正式 Word 生成后须执行本步骤。本步骤由 agent 直接执行，不得停下征询用户意见：转换属于材料生成的组成部分，而非提交动作，且代码 PDF 的实际页数是第 13 步校验申请表「页数」字段的判据，缺少 PDF 将使该项校验降级为分页符推算。仅当用户在此前已明确表示只要 Word、暂不提交时方可跳过。
bashpython3 ${SKILL_DIR}/scripts/convert_to_pdf.py --workdir 软件著作权申请资料
输出：
正式资料/<软件全称>-代码(前30页+后30页).pdf正式资料/<软件全称>_操作手册.pdf
两份材料的生成路径不同。
代码鉴别材料优先由 scripts/render_code_pdf.py 从中间 Markdown 直接渲染，不经办公套件。其排版规格与 Word 版严格对齐：A4、正文 7.2pt、行距精确 14pt、每页 50 行、页眉左「软件全称 版本号」右「第 N 页」，页码起始值取中间 Markdown 的首页页号（后 30 页文档自 31 起）。中文字体子集嵌入 PDF，不依赖阅读器自备字体。fpdf2 不可用或渲染失败时，自动降级至 Word 与 LibreOffice 的转换链路。
操作手册仍走转换链路：macOS 上优先驱动 Microsoft Word，先更新域再重新分页，然后导出 PDF。更新域这一步不可省略：操作手册的目录是 Word 域，未更新即导出会使目录页码全部印成 1。Word 不可用时降级至 LibreOffice，此时须另行核对首页目录是否正确。
无论走哪条路径，脚本都会校验 PDF 是否存在、非空、未加密，并输出实际页数；代码 PDF 的页数须与申请表「页数」字段一致，不一致即判失败，该份 PDF 被改名为 .pdf.invalid 以免被后续校验误当作判据。
退出码的含义须据此理解：代码 PDF 生成或校验失败时退出码为 1，必须排查后重新执行，不得带着缺失的代码 PDF 进入第 13 步；代码 PDF 已成功、仅操作手册 PDF 因无 Word 与 LibreOffice 而未产出时退出码为 0，终端会打印提示，此时可继续第 13 步，并在提交前告知用户自行导出操作手册 PDF。
13. 三轮验证
至少执行三轮验证并修复发现的问题：
- 文件完整性：目标 Word 与 TXT 是否存在且非空。PDF 的存在性、加密状态与页数由第 12 步的转换脚本当场校验。
- 代码真实性：抽样检查代码片段能否回溯至项目源码。
- 业务真实性：申请表与操作手册中的行业、目标用户、主要功能、操作流程能否回溯至
业务理解.md与项目文档；其中涉及数值口径、数据流向、状态判定、操作步数与控件文案的陈述，须回到源码逐条核对，不以 README 为准。 - 一致性与格式：软件名称、版本号、页数规则、申请表字段、操作手册标题与截图引用是否一致。其中申请表「页数」与 PDF 实际页数由校验脚本自动比对（无 PDF 时降级为 Word 的分页符计数）；代码文件名所称页数与文档首行标题目前须人工核对。
第 13 步的实际执行分为两步，两步均完成方为完成：
第一步，运行程序化校验脚本（覆盖上述第 1、4 两条中可自动判断的部分，以及命名一致性、页数、套话黑名单、截图尺寸、确认记录等更细的检查项）：
bashpython3 ${SKILL_DIR}/scripts/verify_materials.py --workdir 软件著作权申请资料
任何 [FAIL] 均必须修复后重新运行，直至全部为 [PASS]/[WARN]；报告同时写入 软件著作权申请资料/校验报告.md。
第二步，将上述第 2、3 两条（代码真实性、业务真实性）以及截图匹配度、行业定位合理性、操作手册文风，委派给一个独立的验证 agent 逐项核实，清单与具体做法详见 references/verification_checklist.md 第二部分。委派时应向独立 agent 提出原始问题（例如「审计这份操作手册是否存在编造内容与截图错位」），不得提出「验证已生成的材料是否正确」一类表述，以避免确认偏误；生成材料的 agent 不能作为唯一的验证方。
其他可用命令：
bashpython3 -m py_compile ${SKILL_DIR}/scripts/*.py
打开生成的 .docx 文件，人工检查排版、页眉与分页是否正常。环境检查.md 显示 python-docx 不可用时，表明当前采用 pandoc/基础 OOXML 降级路径。用户明确选择不安装 python-docx 并记录 environment 确认点后，继续生成 Markdown、TXT 与降级 DOCX，并在报告中说明当前使用降级路径。
三轮验证全部通过后，向用户报告正式资料清单与关键数值，包括软件全称、版本号、代码 PDF 页数、操作手册 PDF 页数与 正式资料/ 的实际路径，随后主动询问是否继续提交至中国版权保护中心。该处是整个流程中唯一的提交决策点：用户明确答复之前不得进入第 14 步，不得打开平台页面。用户表示暂不提交时，任务在此结束，材料留存于 正式资料/ 待用。
14. 中国版权保护中心官网填报与签章页
用户在上述询问中答复继续提交时，读取 references/ccopyright_submission_workflow.md，按已验证的 R11 页面顺序操作。本阶段的目标并非重复制作材料，而是将已确认的 正式资料/申请表信息.txt、代码 PDF 与操作手册 PDF 准确录入平台，并推进至用户授权的停止点。
关键边界：
- 登录、短信验证码、图形验证码等身份验证由用户完成；不得索取或保存密码。
- 「保存至草稿箱」属于可恢复操作，可在字段与材料回读无误后执行，并在用户中心确认条目状态为「暂存」。
- 「确认填报」将把草稿推进至正式申请及签章流程。点击前必须由用户确认申请信息；后续出现任何声明、承诺或签署内容时，必须由申请人本人阅读并决定，agent 不得接受可能不实的声明。
- 确认填报后，主要工作为等待平台生成签章页；生成后由用户打印并签字或盖章，再上传扫描件。上传完成后返回用户中心核对平台显示的实际状态，不对是否已经受理作出推测。
- 每个项目单独记录流水号、当前状态与材料文件路径，禁止复用其他项目的流水号或签章页。
- 全部版权中心过程记录、签章页、回执与状态证据统一写入
软件著作权申请资料/提交记录/，不得放入正式资料/；命名与归档规则详见输出目录规范。
须询问用户的情形
以下场景必须询问并停止，等待用户输入后再继续：
- 存在多个项目候选目录，须由用户选择。
- 启动环境检查发现完整 DOCX 环境缺失时，询问用户是否安装完整环境。
- 定位项目后，须先询问用户是否可提供操作视频；如有，则优先用于业务理解、操作手册与截图三个环节。
- 业务理解草稿生成后，请用户确认软件用途、行业、目标用户、核心功能与申请口径。
- 软件全称、著作权人、日期、硬件/系统环境等登记字段须经确认。
- 软件全称含有商标文字时，须于第 5 步运行前由用户在「去除商标文字」与「保留原名称并提供商标证明」之间作出选择。
- 代码文件候选清单生成后，须由用户确认或修改
代码文件选择.json。 - 操作手册截图前，须确认操作视频是否已覆盖全部模块；未覆盖或无视频时，须由用户在浏览器自动化截图能力、桌面操作截图能力、用户自行截图三种方式中选择一种；选择后再检查对应工具是否可用。
- Markdown 草稿是否确认、可否进入 Word 生成，须由用户决定。
- 三轮验证通过、正式材料齐备后，须询问用户是否继续提交至中国版权保护中心；用户未明确要求前不得进入官网填报阶段。
- 官网需要登录、验证码或其他身份验证时，由用户完成后再继续。
- 点击「确认填报」前，必须由用户确认最终申请信息；遇到声明、承诺、签名或盖章内容时，由申请人本人阅读并决定。
反向约定：正式 Word 生成后的 PDF 转换（第 12 步）属于材料生成的组成部分，由 agent 直接执行并当场校验，不列入上述询问范围。
