Software Certificate Skill

软件著作权申请资料生成器

面向用户的默认体验

用户只需说“为当前项目生成软件著作权申请资料”。先用通俗语言说明：

• 将读取并分析当前真实项目，不套用虚构业务；
• 将集中收集一次无法可靠推断的登记事实；
• 将让用户一次选择截图方式；
• 后续项目分析、业务理解、源码选择、截图、写作、排版、转换、检查、修复和打包由 Agent 完成；
• 申请表信息.txt 用于复制到登记系统；正式 PDF 按登记系统当日要求上传；DOCX 用于 Word/WPS 复核；质量报告只用于内部留档。

不要先展示脚本、路径参数、JSON、置信度或内部阶段。用户明确要求高级细节时再展开。

最终交给普通用户的正式资料只包含：

软件著作权申请资料/
  正式资料/
    申请表信息.txt
    <软件全称>_操作手册.docx
    <软件全称>_操作手册.pdf
    <软件全称>-代码(前30页).docx/.pdf  # 源码达到60页
    <软件全称>-代码(后30页).docx/.pdf  # 源码达到60页
    <软件全称>-代码(全部).docx/.pdf    # 源码不足60页

生成报告、校验报告、代码来源、截图索引、待确认清单、哈希、证据图谱、转换诊断和回滚状态仅供 Agent 内部验证与续作，不进入“正式资料”，最终回复也不逐项展示。

默认把上述内部文件写入操作系统临时运行区，不写进目标项目。成功发布后，目标项目的 软件著作权申请资料/ 下只能存在 正式资料/；不得留下 .工作区、质量检查、历史版本、草稿、截图副本、信息卡、JSON、Markdown 或哈希文件。只有开发者显式启用调试保留时才保留临时运行区，且仍不得污染交付目录。

只向普通用户显示这些进度：正在检查运行环境、正在分析项目、正在理解软件业务、正在整理申请表、正在选择真实源码、正在获取页面截图、正在生成操作手册、正在生成代码材料、正在渲染并检查文档、正在自动修复问题、已完成可以检查并提交。

执行入口

把本文件所在目录解析为 SKILL_ROOT。输出始终写入目标项目，不写入 Skill 安装目录。

1. 内部执行 python SKILL_ROOT/scripts/product_workflow.py prepare --project PROJECT_ROOT。
2. 将生成的“一次性基础信息表”作为一张集中表单呈现；优先复用会话、项目或历史材料中的已确认事实。
3. Agent 在系统临时运行区完成 business-understanding.json，不得让普通用户填写技术或业务推断表。
4. 展示一张截图方式选择卡；已有明确选择时直接采用。
5. 信息齐全后内部执行 python SKILL_ROOT/scripts/product_workflow.py resume --project PROJECT_ROOT。
6. 依据工作流状态继续未完成阶段；不要重复扫描、重复询问或创建重复目录。

在有 bundled Python/文档运行时的平台优先使用该运行时。代码材料 PDF 默认由内置确定性渲染器按固定行格直接绘制：页数由构造保证，系统 TrueType 字体以子集内嵌，毫秒级完成；环境缺少可用字体时自动回退办公套件转换。操作手册 PDF 必须由 LibreOffice（优先）或 Microsoft Word 真实转换并逐页渲染；每份文档有独立时限、进程组、失败清理及 stdout/stderr/进度诊断，不得用空文件、旧文件或改扩展名代替。

一次性登记事实

只集中确认：软件全称、简称、版本、著作权人类型/名称/证件、完成日期、开发方式、原创或修改、发表状态及条件日期、权利取得方式、权利范围、必要权属说明、截图方式。

自动推断：软件分类、用途、用户、行业、核心价值、主要功能、技术特点、语言、开发与运行环境、源程序量、操作流程、手册模块和源码范围。

内部保存每个推断的建议值、证据、置信度、理由、是否影响登记事实和是否需确认。冲突优先级：已确认申请事实 > 正式配置 > 真实运行结果 > 其他项目资料。只有名称、版本、权属、日期、发表状态或多个独立申请范围发生实质冲突时，才集中询问一次。

业务证据

阅读 README、产品说明、配置、路由、页面、组件、控制器、服务、API、模型、状态管理、测试、部署、既有截图和真实运行结果。文件名与关键词只作阅读线索，不能直接成为业务结论。

每项关键功能至少绑定页面、路由、代码、测试、文档、截图或已确认事实之一。正式手册不得出现项目中不存在的菜单、按钮、角色、数据、接口、提示或结果。

详细模型见 references/evidence-model.md 与 references/product-workflow.md。

截图方式

• Chrome DevTools：推荐给 Web 系统；检查工具、启动/连接项目、等待就绪、执行登录/点击/输入/滚动，在控件或文本断言通过后截图。记录 URL、角色、动作、时间、尺寸、SHA-256、控制台与失败请求，写回截图索引与证据图谱；CI 使用真实本地项目完成端到端验证。
• Computer Use：推荐给桌面端、Electron、模拟器和复杂交互。先读取当前应用状态，再操作和保存原图；用 computer-use-session.json 记录启动、登录、动作和截图收据，再由确定性脚本检查图片、哈希、时间、角色、窗口/URL和证据映射。
• 用户自行截图：生成简短任务清单；导入 用户截图/ 后按计划 ID 自动排序、去重、清晰度检查、统一命名和章节匹配；检测到浏览器窗口壳（标签栏、地址栏）时自动裁剪为纯网页区域并在收据中记录裁剪框与原图哈希，桌面应用截图不受影响。
• 暂时跳过：只有一次性基础信息表明确将 screenshot_policy 设为 draft_allowed 时，才生成带可见截图预留位置的草稿；正式资料默认要求截图全部完成。正式模式发现缺图、启动失败、登录失败或断言失败时，在截图阶段直接暂停，不继续生成手册和代码材料。

截图状态必须明确为 skipped_by_user、awaiting_capture、failed 或 captured。非主动跳过场景中，空截图列表永远不能通过正式发布检查。

Web 正式取证优先使用一次性基础信息表中的 screenshot_base_url 和 screenshot_server（command、cwd、health_url、startup_timeout_seconds）。截图计划保存业务、源码、地址和构建指纹；任一指纹变化都会归档旧计划、旧索引和旧图片并重新取证，避免复用过期界面。

Web 自动化细节见 references/screenshot-automation.md。

源码与代码材料

默认自动选择真实应用入口、路由、页面、核心组件、业务服务、API封装、状态、模型、算法、工具和必要后端逻辑。自动排除依赖、构建物、压缩/生成代码、锁文件、测试夹具、示例、重复/无关模块、敏感信息及来源不清代码。识别项目架构范围（纯前端/纯后端/全栈）：后端按服务端目录、框架导入与代码量三路归因，强归因实现足量即认定全栈，不因前端体量大而漏判；全栈材料中后端享有最低行数配额并与前端按占比混排，架构范围不明但两侧均有实质源码时同样混排兜底，交存卷缺失后端时发布门禁阻断。纯前端仓库中疑似后端实现默认排除并写入待确认清单以核实归属；纯前端申请的运行支撑环境必须注明需配合后端/接口服务，否则发布门禁阻断。

使用完整源文件顺序，保留路径、原始行号、文件哈希和显示换行映射。空行不进入鉴别材料：每页 50 行全部为非空有效代码行（审查按有效代码计行，空行凑页是常见补正原因），最后一页允许不足。显式分页；行距按 A4 版心高度精确均分，使每页代码排满版面、页底不留成片空白；换行按等宽显示列计算，中文字符按双列宽度处理。页眉统一为左侧软件全称+版本号、右侧页码，页脚留空。达到 60 页时分别生成连续前30页与后30页，页码连续编排；不足60页时生成全部。

如项目存在上游框架、旧品牌或第三方版权边界，将识别出的字面标识写入一次性基础信息表的 source_forbidden_markers；选择器会排除命中文件并在来源报告中留痕，不会机械改写包名或版权头。网页截图可用 screenshot_forbidden_markers 做 DOM 文本预检。

DOCX 转 PDF 后核对实际页数、显示行密度、长行、空白/溢出/截断、页眉名称版本、前后卷连续性和 DOCX/PDF对应关系。真实分卷测试必须证明两个 DOCX 与两个 PDF 各为30页、前卷第30页也满足有效行数要求、后卷连续到源码最后一页、显示长行不引入额外页。源码分页和 PDF 渲染均检查非末页有效行数；失败时自动调整字号、宽度、行距、分页或长行策略并重试。最后一页允许不足50行，但不得用复制或虚构代码填充。详见 references/source-selection.md。

操作手册

默认生成审核人员和普通使用者均能理解的操作手册。内容充分的常规业务系统优先编排为40–60页、接近60页；页数随真实功能、操作闭环、截图、结果字段和异常路径调整。小型项目可以低于40页，超过60页时先压缩重复结构并复核鉴别材料交存范围；不得用重复截图、定义、优势或空泛段落凑页。

功能章节按查询、审批、分析、监控、配置、文件处理、数据录入等操作类型自适应组织。禁止所有模块机械套用“用途—表格—步骤—结果—异常”五段式。根据真实字段、状态变化、页面复杂度、截图数量和异常情形选择 2–4 个小节；查询类突出筛选范围与结果字段，录入类突出字段和保存校验，审批类突出核验依据与状态变化，分析类突出范围与指标口径，配置类突出参数边界和生效范围。允许 Agent 为复杂功能提供贴合业务的过程、结果与异常标题。正文使用用户语言，不把框架、接口封装、状态管理或数据库实现当成操作说明。内容门禁检查每项功能厚度、步骤、业务细节、循环套话、重复句式与重复结构。

统一采用 A4 正常软著黑白灰版式：宋体正文、微软雅黑标题、浅灰表头、克制页眉页脚、真实 Word TOC 域与可点击目录。标题的中文、数字和拉丁字符必须显式绑定同一字体族，避免 Word/WPS/LibreOffice 分裂替换。表格单元格不得继承正文首行缩进；正文按中文文档规范首行缩进并两端对齐。图片保持比例，不拉伸、不裁掉关键控件。版式见 references/visual-system.md 与 references/layout-benchmarks.md。

单一事实源、验证与修复

所有材料从临时运行区中的 application-facts.json 派生。名称、简称、版本、权利人、日期、发表状态、开发方式、权利取得、权利范围、功能、源码量、材料页数、标题、页眉页脚、文件名和截图标题必须一致。

申请表字段规则来自 assets/rules/application-field-rules.json，枚举、条件必填、格式、长度与阻断级别均可更新；源程序量输出原始源码行数的纯数字。2026年“主要功能”500–1300字作为当前阻断规则，缺少公开可核验上限的动态字段标记为提交当日复核，不用猜测值阻断。

发布前检查：文件完整性、DOCX结构、真实PDF和逐页渲染、字段规则、事实一致、源码抽样回溯、第三方与敏感信息、页数连续性、业务证据、截图状态/质量/章节匹配、手册内容厚度与重复度、空白/截断/溢出、占位符、哈希与发布包。一般问题自动局部修复；只把登记事实、权属或真实业务范围冲突放入待确认清单。

工作流在系统临时运行区保存机器状态和阶段哈希；重复运行幂等。名称/版本变化只重建依赖材料，补图只重建截图清单、手册和报告。覆盖正式文件前在临时运行区备份；用户手工修改的 DOCX 先归档。product_workflow.py rollback 恢复最近快照。所有内部路径均不进入最终回复。

质量门禁见 references/quality-gates.md。

规则与平台

启动时显示规则快照日期。读取 references/rules-2026.md；规则过旧只提示刷新，不阻塞草稿。区分国家版权局规章、中国版权保护中心/当前系统、政府高校行业办理说明、公开案例经验；保存发布日期、抓取日期、适用范围和等级。经验做法不得表述为统一法定要求。

安装及平台能力见 references/agent-platforms.md。同一证据、事实和生成流程适配 Codex、Claude Code、Cursor、OpenCode、WorkBuddy、QoderWork、TraeWork；仅工具调用层不同，不复制多套业务规则。

最终回复

通过门禁时只列出：正式资料绝对路径、每个文件用途、要上传的PDF、要复制到官网的TXT、必须人工确认的问题、简明提交步骤。门禁未通过时改列草稿绝对路径和阻断项，不把草稿描述成正式资料。高级证据、命令和JSON仅在用户要求时展开。