zuoa 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 生成、模板化材料、基于推断扩展和内部审计结果等过程说明，同时保留软件名称和真实业务术语。
最终回复只列输出目录、文档类型、核心文件、所用技术栈、模板使用情况、验证结果和未完成项，不把整份代码或文档粘贴到聊天中。