AJ Copyright Writer

生成高质量、业务一致的软件著作权登记材料。格式合规只是底线；模块、源码、文档、界面和申请表必须共同呈现该软件的专有业务表达，不能只更换名称后复用同一套代码或文字骨架。

必读资源

全流程与目录约定：references/workflow-contract.md
模块、源码和文档写作：references/material-writing-rules.md
登记材料硬规则：references/software-registration-rules.md
原型风格：references/prototype-ui-style.md
选择操作手册时：references/operation-manual-template.md
选择软件设计说明书时：references/software-design-template.md
操作手册完成后：references/operation-manual-humanizer.md
软件设计说明书完成后：references/design-specification-humanizer.md

国家版权局 2025 年版权政策只可作为行业背景，不把它当作软件登记材料的操作规则。登记规则以《计算机软件著作权登记办法》和本技能的 software-registration-rules.md 为准。

{baseDir} 表示本 SKILL.md 所在目录。所有脚本均使用 {baseDir}/scripts/... 的绝对解析路径执行。

输入与模式

必需输入：SOFTWARE_NAME。

可选输入：

SOFTWARE_VERSION：默认 V1.0。
输出目录：默认 copyright-materials/{software_slug}-{YYYYMMDD-HHMM}/。
MODE：normal 或 correction。只有用户提供补正通知或明确要求补正时才自动选择 correction；首次申请即使提供现有代码或文档仍使用 normal。
现有代码、文档、截图、补正通知和历史材料目录。
实际技术栈。用户未指定时，根据软件类型自动选择一套自洽技术栈。
文档类型：operation-manual 或 design-specification。
原型模式：默认 HTML；用户明确要求图片模型时才使用 image 模式。

补正模式始终创建新的输出目录，不覆盖原材料。先分析旧材料的问题，再重新选择业务内容；禁止只改变量名、同义替换或打乱段落顺序。

正式输出

01.spec/spec.md
02.modules/01.md ... 10.md
03.prototype.style/selection.md
03.prototype.html/*.html 或 03.prototype.prompt/*.md
04.prototype/batch.json、*.jpg
05.code/01-模块名称.txt ... 10-模块名称.txt
06.document/${SOFTWARE_NAME}_操作手册.md/.docx
或 06.document/${SOFTWARE_NAME}_软件设计说明书.md/.docx
07.code.full/${SOFTWARE_NAME}_代码.docx
08.application-info/${SOFTWARE_NAME}_软著申请表信息.txt
09.originality-audit/source-manifest.json
09.originality-audit/originality-report.json
09.originality-audit/originality-report.md

09.originality-audit 是内部质量检查目录，不得把其中的文字复制到 01—08 正式材料。正式材料不得出现“本文为草案”“AI 生成”“模板化材料”“基于推断扩展”“扩展设定”“独创性审计结果”等生成过程说明；软件名称和真实业务术语中的 AI、合同模板 等必须正常保留。

工作流

1. 调研与业务锚点

使用软件名称检索官网、产品资料、行业规范和权威业务资料。
提炼软件专有的业务对象、字段、状态、规则、计算口径、异常场景、角色和行业术语。
把这些内容写成正式的软件规格说明，包括定位、用户、场景、业务流程、架构、数据对象、功能和非功能要求。
不在正式规格中写资料来源分级、假设声明或生成说明。

业务锚点是后续一致性的唯一口径。代码、界面、文档和申请表不得回退到与任何系统都适用的通用表述。

2. 固定生成 10 个核心模块

恰好生成 02.modules/01.md 到 10.md，每个模块包含 3—5 个功能点。
至少 8 个模块必须是行业或业务核心模块；登录、用户、角色、权限、日志、字典、设置、帮助等通用模块合计不得超过 2 个。
模块名、功能名、字段、状态、业务规则和异常分支必须使用本软件的行业语义。
每个模块在“模块定位”中说明它如何体现本软件的代表性能力，但不要使用夸张宣传或审查话术。
禁止使用 数据管理 / 信息维护 / 统计分析 等泛化名称占据核心模块。

生成后运行：

python3 {baseDir}/scripts/validate_outputs.py \
  --spec-md 01.spec/spec.md \
  --module-dir 02.modules

3. 选择代表性文档

原则上只生成一种鉴别文档，按以下优先级选择：

用户明确指定的文档类型。
交互、审批、调度、运营类软件选择操作手册。
算法、后台服务、数据处理、设备接入、协议解析类软件选择软件设计说明书。
收到“文档模板化程度较高”补正意见时，选择更能呈现代表性业务表达的类型；若核心价值体现在内部处理规则上，优先设计说明书。

每套材料只选择一种主要鉴别文档，不机械同时生成两种。在内部记录选择结果与理由，正式文档只呈现软件内容。

设置 DOCUMENT_TYPE=operation-manual|design-specification、DOCUMENT_BASENAME和 DOCUMENT_SELECTION_REASON。选择设计说明书时，必须先读 software-design-template.md，并在成稿后执行其专业性检查。

4. 生成原型与截图

需要界面材料时，先读 prototype-ui-style.md，推荐行业匹配风格并让用户确认。生成 selection.md 后再写 HTML 或图片 prompt。

HTML 必须自包含，使用中文业务字段、真实状态和合理 mock 数据，固定 1920×1080，不依赖 CDN、远程字体或接口。页面不得出现版权归属、开发公司、技术支持、出品方或承建单位署名。

操作手册至少生成 10 个模块首页，并为 40%—60% 的复杂功能点生成独立截图。只有软件确有账号登录流程时才生成 00-login；无登录流程时使用真实入口、首页或任务起始页，并在截图与验证命令中使用 --no-login。软件设计说明书只使用能证明系统结构、核心流程或关键处理结果的代表性视图，不为凑数量制作空白后台页面。

HTML 模式：

python3 {baseDir}/scripts/screenshot_html_prototypes.py \
  --html-dir 03.prototype.html \
  --output-dir 04.prototype \
  --module-dir 02.modules \
  --batch-file 04.prototype/batch.json \
  --viewport 1920x1080

软件没有登录流程时，在截图脚本以及后续 validate_outputs.py 命令中追加 --no-login。

5. 生成代表性源程序

技术栈

优先采用用户真实技术栈；否则按软件类型选择一套自洽方案。
技术栈必须贯穿规格、代码、设计文档和申请表。
10 个代码文件按架构职责和业务模块组织，不要求每个文件同时包含前端和后端。
源码必须语法连贯、类型和接口一致，不写“仅作示例”式伪代码。

入选内容

优先包含领域服务、状态流转、规则判定、计算或匹配算法、数据转换、协议解析、复杂校验、权限边界、异常恢复和审计轨迹。

排除：

只有 import、package、using 或依赖声明的文件；
环境配置、构建配置、启动胶水和纯路由注册；
纯 getter/setter、无业务行为的 DTO 或实体；
空方法、空接口、空组件、TODO 和占位页面；
自动生成客户端、第三方库和框架源码；
仅替换类名或字段名的重复 CRUD；
无业务含义的重复注释。

不要从入选业务文件中机械删除必要 import。应排除低价值文件，同时保持入选源码的结构完整和可读性。

行数与顺序

05.code 恰好包含 10 个 编号-模块名称.txt 文件。
不设置单文件统一行数；复杂模块自然包含更多代码。
10 个文件合计至少 3000 个非空源码行，以满足 60 页、每页 50 行。
注释只解释业务口径、状态转换、边界和非显而易见逻辑，不设机械注释率目标。
05.code 可以保留正常的源码空行以维持可读性；统计和代码 DOCX 组版时忽略空行。源码不得包含 copyright 字样。

6. 编写正式鉴别文档

操作手册基于真实任务组织章节，针对任务办理、审核闭环、监控处置、分析查询、批量导入和规则配置采用不同写法，不让所有功能重复同一种段落骨架。所有按钮、字段、状态和提示语必须能在对应界面找到。

软件设计说明书围绕架构视图、领域模型、状态转换、核心处理流程、算法输入输出、接口契约、数据一致性和异常恢复组织内容。正文直接说明业务对象、触发条件、处理动作和结果，不用“旨在”“赋能”“全面提升”“形成闭环”等空泛表达。不把十个模块机械扩写成十段同构说明，不在章节末追加“对应文件”或“本节由…落地”等生成式映射句。如确需体现设计与实现的可追溯性，仅在文末使用“设计—实现追踪表”集中列出逻辑组件、核心类/服务和关键方法，不显示内部目录、编号代码包文件名或文件扩展名。成稿后按 design-specification-humanizer.md 做一次语言清理，不改动已核实的字段、状态、规则和实现符号。

正式 Markdown 直接写入 06.document，不保存带 .draft 名称的正式产物。转换 Word：

python3 {baseDir}/scripts/markdown_to_docx.py \
  --input "06.document/${DOCUMENT_BASENAME}.md" \
  --output "06.document/${DOCUMENT_BASENAME}.docx" \
  --template "${DOCUMENT_TEMPLATE:-}"

未提供模板时，转换脚本使用 A4 中文技术文档样式：正文中文为宋体 10.5 pt，英文与数字为 Times New Roman；标题中文为黑体，英文为 Arial。字体同时写入 Word 的东亚字体和西文字体属性，不依赖系统默认字体。表格、图题和列表沿用同一套字体规则。

7. 执行内部独创性审计

在生成正式代码 DOCX 前运行：

python3 {baseDir}/scripts/audit_originality.py \
  --code-dir 05.code \
  --module-dir 02.modules \
  --document "06.document/${DOCUMENT_BASENAME}.md" \
  --document-type "${DOCUMENT_TYPE}" \
  --document-selection-reason "${DOCUMENT_SELECTION_REASON}" \
  --output-dir 09.originality-audit

用户提供历史材料时追加 --comparison-corpus /path/to/history。

审计阻断以下问题：空实现、明确占位代码、低价值文件、过量精确重复代码块、超过两个通用模块、多组模板化文档段落、文档漏掉核心模块，以及与历史材料高度相似。结构相似度等不确定指标只给警告。审计阈值是内部质量启发式，不是登记机关公开标准。

若审计失败，回到模块、代码或文档步骤实质性重写；不得使用 --allow-high-risk 生成正式交付。

8. 生成 60 页代码文档

python3 {baseDir}/scripts/build_code_docx.py \
  --code-dir 05.code \
  --source-manifest 09.originality-audit/source-manifest.json \
  --originality-report 09.originality-audit/originality-report.json \
  --output "07.code.full/${SOFTWARE_NAME}_代码.docx" \
  --software-name "${SOFTWARE_NAME}" \
  --software-version "${SOFTWARE_VERSION:-V1.0}"

代码文档必须是 60 个代码页，每页 50 行，宋体小五、左对齐、单倍行距。页眉名称和版本与申请表一致，右上角为页码。超过 3000 行时按普通交存口径取连续源码流的前 1500 行和后 1500 行，最后一页为程序结束部分。

9. 生成申请表信息

生成 08.application-info/${SOFTWARE_NAME}_软著申请表信息.txt。硬件环境、操作系统、开发工具、运行平台、支撑环境、开发目的、行业各不超过 50 字符；主要功能不超过 200 字；技术特点不超过 100 字。

编程语言和版本从 source-manifest.json 读取，源程序量使用 10 个代码文件的非空行总数。软件类型从 APP、游戏软件、教育软件、金融软件、医疗软件、地理信息软件、云计算软件、信息安全软件、大数据软件、人工智能软件、VR软件、5G软件、小程序、物联网软件、智慧城市软件 中选一个。

10. 最终验证

python3 {baseDir}/scripts/validate_outputs.py \
  --code-dir 05.code \
  --source-manifest 09.originality-audit/source-manifest.json \
  --originality-report 09.originality-audit/originality-report.json \
  --document-md "06.document/${DOCUMENT_BASENAME}.md" \
  --document-docx "06.document/${DOCUMENT_BASENAME}.docx" \
  --code-docx "07.code.full/${SOFTWARE_NAME}_代码.docx" \
  --application-info-txt "08.application-info/${SOFTWARE_NAME}_软著申请表信息.txt" \
  --software-name "${SOFTWARE_NAME}" \
  --software-version "${SOFTWARE_VERSION:-V1.0}"

交付检查

是否恰好有 10 个模块和 10 个编号代码文件，且至少 8 个是业务核心模块。
技术栈是否自洽，是否清除了 import-only、配置、访问器、空壳、生成代码、第三方代码和重复 CRUD。
正式文档类型是否适合软件，是否避免重复句式并覆盖全部核心模块。
设计说明书是否不含编号源文件名、扩展名、内部目录及“由…落地”等生成式表达。
文档、截图、代码和申请表中的名称、字段、状态、技术栈和版本是否一致。
内部审计是否为 pass，源码指纹是否仍与审计时一致。
代码 DOCX 是否为 60 页、每页 50 行，页眉和页码是否正确。
正式材料是否没有草案标记、AI 生成、模板化材料、基于推断扩展和内部审计结果等过程说明，同时保留软件名称和真实业务术语。

最终回复只列输出目录、文档类型、核心文件、所用技术栈、模板使用情况、验证结果和未完成项，不把整份代码或文档粘贴到聊天中。

aj-copyright-writer