software-copyright-materials

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

软著申请资料生成

Software Copyright Application Materials Generation

这个 skill 生成可审阅、可追溯的软著申请资料。核心原则：

固定输出目录：当前工作目录下的
```
软件著作权申请资料/
```
。不要默认写到
```
/tmp
```
、
```
/private/tmp
```
或其他临时目录。
只有测试 skill 自身时才允许显式指定临时目录；面向用户生成材料时必须写入当前目录。
先生成 Markdown 草稿，用户确认后再生成正式 Word/TXT。
正式 Word/TXT 只能写入
```
软件著作权申请资料/正式资料/
```
，不要散落在输出目录根部。
正式 Word/TXT 的文字一律使用默认黑色字体，不生成蓝色超链接、主题色标题或其他彩色文字；Markdown 链接写入 Word 时必须转成普通文本。
正式资料中的软件名称必须与
```
草稿/申请表信息.md
```
的“软件全称”字段一致；正式生成时以已确认的申请表软件全称为准。
正式代码 Word 页眉中的版本号必须与
```
草稿/申请表信息.md
```
的“版本号”字段一致；正式生成时以已确认的申请表版本号为准。
代码材料必须来自真实项目源码，禁止 AI 编造代码。
写申请表和操作手册前，必须先形成模型研判后的
```
草稿/业务理解.md/json
```
，理解软件业务、行业、目标用户、核心价值和操作流程。
脚本只能收集项目证据、校验字段和生成文件；行业判断、功能抽取、代码抽取选择、操作手册结构必须由模型阅读项目后决定，不得依赖脚本关键字表或固定范本。
优先抽取前端代码：入口、路由、页面、核心组件、接口封装、状态管理、工具函数。
生成代码材料前，必须先生成代码文件候选清单；模型理解项目后填写抽取文件、行段和选择理由，再让用户确认或修改。
代码优先抽取模型和用户确认的、最能体现软件真实功能和运行逻辑的源码；不足 60 页时，从其他相关源码文件补充到 60 页；候选源码仍不足 60 页时，才生成全部代码文档。
操作手册面向审核员，用通用语言说明软件用途和操作流程。
操作手册草稿必须按章节写成通顺段落，不能只给功能列表；每个核心模块都要用普通人能看懂的语言说明模块用途、操作过程和结果反馈。避免代码、框架、接口、状态管理、异步任务等技术化表达；撰写过程中由 agent 自行循环检查、扩写和修正，完整草稿完成后只向用户发起一次整体确认。
操作手册必须去除明显“AI 味”：避免空泛赞美、营销口号、万能句式、每章同一结构、过度对称的排比、没有项目细节的正确废话、频繁使用“旨在、赋能、一站式、智能化、高效便捷、显著提升、强大能力、丰富功能”等套话。每段都应能回答“这个项目里这个功能具体做什么、用户看见什么、操作后有什么结果”。
操作手册生成必须同步输出
```
草稿/操作手册自检记录.md
```
和
```
草稿/操作手册自检记录.json
```
，记录初稿、按项目流程扩写、去制式表达等自检轮次；如果前 3 轮仍发现问题，必须继续补写修正，直到问题清零或记录无法自动修复的原因后再停止。
截图方式必须先让用户选择：Chrome DevTools MCP、Codex Computer Use、用户自行截图。用户选完后，再检查当前 MCP / Computer Use 能力是否可用；如果用户说现在不截图、先跳过截图或截图失败，操作手册仍必须保留清晰可见的截图预留位置，正式 Word 中也要能看到。
申请表信息中的硬件/系统环境必须让用户确认或填写，不能硬编码。
Word 生成能力必须使用本 skill 内置的
```
vendor/docx-toolkit
```
；不得引用外部 DOCX 目录。

This skill generates reviewable and traceable software copyright application materials. Core principles:

Fixed output directory:
```
软件著作权申请资料/
```
under the current working directory. Do not write to
```
/tmp
```
,
```
/private/tmp
```
or other temporary directories by default.
Explicitly specifying a temporary directory is only allowed when testing the skill itself; when generating materials for users, they must be written to the current directory.
Generate Markdown drafts first, then produce official Word/TXT documents after user confirmation.
Official Word/TXT documents must only be written to
```
软件著作权申请资料/正式资料/
```
, do not scatter them in the root of the output directory.
All text in official Word/TXT documents must use the default black font; do not generate blue hyperlinks, theme-colored headings or other colored text; Markdown links must be converted to plain text when written to Word.
The software name in official materials must match the "Full Software Name" field in
```
草稿/申请表信息.md
```
; the confirmed full software name from the application form shall prevail during official generation.
The version number in the header of the official code Word document must match the "Version Number" field in
```
草稿/申请表信息.md
```
; the confirmed version number from the application form shall prevail during official generation.
Code materials must come from real project source code; AI-generated code is prohibited.
Before writing the application form and operation manual, a model-judged
```
草稿/业务理解.md/json
```
must be created first to understand the software's business, industry, target users, core value and operation process.
Scripts can only collect project evidence, verify fields and generate files; industry judgment, function extraction, code extraction selection, and operation manual structure must be determined by the model after reading the project, and must not rely on script keyword lists or fixed templates.
Prioritize extracting front-end code: entry points, routes, pages, core components, interface encapsulation, state management, utility functions.
Before generating code materials, a candidate list of code files must be generated first; after understanding the project, the model fills in the extracted files, line segments and selection reasons, then lets the user confirm or modify.
Code extraction prioritizes source code confirmed by the model and user that best reflects the software's real functions and operation logic; if it is less than 60 pages, supplement from other relevant source code files to reach 60 pages; if candidate source code is still insufficient for 60 pages, generate all code documents.
The operation manual is for reviewers, explaining the software's purpose and operation process in general language.
The operation manual draft must be written as coherent paragraphs by chapters, not just a list of functions; each core module must explain the module's purpose, operation process and result feedback in language that ordinary people can understand. Avoid technical expressions such as code, frameworks, interfaces, state management, asynchronous tasks; during writing, the agent shall self-circulate to check, expand and revise, and only initiate one overall confirmation to the user after the complete draft is finished.
The operation manual must remove obvious "AI-style" content: avoid empty praises, marketing slogans, universal sentence patterns, identical structure in each chapter, overly symmetrical parallelism, correct nonsense without project details, and frequent use of clichés such as "aims to, empowers, one-stop, intelligent, efficient and convenient, significantly improves, powerful capabilities, rich functions". Each paragraph should answer "what this function specifically does in this project, what the user sees, what results after operation".
When generating the operation manual,
```
草稿/操作手册自检记录.md
```
and
```
草稿/操作手册自检记录.json
```
must be output synchronously, recording self-inspection rounds such as initial draft, expansion according to project process, removal of formalized expressions, etc.; if problems are still found in the first 3 rounds, continue to supplement and revise until problems are cleared or the reason for automatic repair failure is recorded before stopping.
Screenshot method must first be selected by the user: Chrome DevTools MCP, Codex Computer Use, user-provided screenshots. After the user selects, check whether the current MCP / Computer Use capability is available; if the user says not to take screenshots now, skip screenshots first or screenshot fails, the operation manual must still retain clearly visible screenshot reserved positions, which must also be visible in the official Word document.
The hardware/system environment in the application form information must be confirmed or filled in by the user, and cannot be hard-coded.
Word generation capability must use the built-in
```
vendor/docx-toolkit
```
of this skill; external DOCX directories must not be referenced.

强制人工门禁

Mandatory User Confirmation Gates

凡是涉及用户选择、确认或补充信息的阶段，必须先停止当前执行，不得继续调用下一步脚本。即使处于自动审核、自动继续或无人值守模式，也必须把

STOP_FOR_USER

和

NEXT_ACTION

原样告知用户，并等待用户输入后再继续。

禁止使用“用户未选择则默认继续”的逻辑。用户回复确认后，先用确认脚本记录对应门禁，再进入下一阶段：

bash

python3 scripts/confirm_stage.py --workdir 软件著作权申请资料 --stage <阶段名> --note "<用户确认内容>"

必须停住的门禁：

```
environment
```
：完整 DOCX 环境缺失时，用户必须选择“安装完整环境”或“使用基础 DOCX 兜底继续”。
```
project
```
：存在多个项目候选目录时，用户必须指定项目目录。
```
business
```
：
```
草稿/业务理解.md
```
生成后，用户必须确认行业、目标用户、核心功能和申请口径。
```
application-fields
```
：
```
草稿/申请表信息.md
```
生成后，用户必须补全并确认硬件、系统环境、著作权人、日期等字段。
```
code-selection
```
：
```
草稿/代码文件选择.json
```
生成后，用户必须确认或修改抽取文件和行段。
```
screenshot-method
```
：操作手册截图前，用户必须在 Chrome DevTools MCP、Codex Computer Use、用户自行截图三种方式中选择一种；如果用户明确说“现在不截图/先跳过截图”，记录为
```
skip
```
。
```
markdown
```
：全部 Markdown 草稿完成后，用户必须确认可以进入 Word/TXT 生成。

At any stage involving user selection, confirmation or supplementary information, the current execution must be stopped immediately, and the next script must not be called. Even in automatic review, automatic continuation or unattended mode,

STOP_FOR_USER

and

NEXT_ACTION

must be informed to the user as they are, and wait for user input before continuing.

Prohibit the logic of "default to continue if user does not select". After the user replies with confirmation, first use the confirmation script to record the corresponding gate, then enter the next stage:

bash

python3 scripts/confirm_stage.py --workdir 软件著作权申请资料 --stage <阶段名> --note "<用户确认内容>"

Gates that must stop:

```
environment
```
: When the complete DOCX environment is missing, the user must choose "Install complete environment" or "Continue with basic DOCX fallback".
```
project
```
: When there are multiple candidate project directories, the user must specify the project directory.
```
business
```
: After
```
草稿/业务理解.md
```
is generated, the user must confirm the industry, target users, core functions and application caliber.
```
application-fields
```
: After
```
草稿/申请表信息.md
```
is generated, the user must complete and confirm fields such as hardware, system environment, copyright holder, date, etc.
```
code-selection
```
: After
```
草稿/代码文件选择.json
```
is generated, the user must confirm or modify the extracted files and line segments.
```
screenshot-method
```
: Before taking screenshots for the operation manual, the user must choose one of the three methods: Chrome DevTools MCP, Codex Computer Use, user-provided screenshots; if the user clearly says "don't take screenshots now/skip screenshots first", record it as
```
skip
```
.
```
markdown
```
: After all Markdown drafts are completed, the user must confirm that they can proceed to Word/TXT generation.

工作流

Workflow

1. 启动环境检查

1. Initiate Environment Check

一开始先在当前工作目录创建输出目录并检查运行能力：

bash

python3 scripts/check_environment.py \
  --out-dir 软件著作权申请资料

输出：

软件著作权申请资料/环境检查.md

软件著作权申请资料/环境检查.json

环境检查必须告诉用户：

当前会在“当前目录/软件著作权申请资料”下生成材料。
Markdown 草稿、TXT、基础 DOCX 是否可用。
内置
```
vendor/docx-toolkit
```
的完整 OpenXML 环境是否可用。
如
```
.NET SDK
```
缺失，询问用户是否安装完整环境。

用户选择：

如果用户愿意安装完整环境，按
```
vendor/docx-toolkit/scripts/setup.sh
```
的要求安装依赖，再继续。完整环境生成和校验更规范。
如果用户不安装，继续使用兜底方案生成 Markdown、TXT 和基础 DOCX。
如果完整 DOCX 环境缺失，必须停止并等待用户选择；不得自动继续。

用户回复后记录门禁：

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage environment \
  --note "<用户选择>"

不要等到最后验证阶段才发现完整 DOCX 环境不可用；这个信息必须在流程开始时给出。

First, create the output directory in the current working directory and check the running capabilities:

bash

python3 scripts/check_environment.py \
  --out-dir 软件著作权申请资料

Output:

软件著作权申请资料/环境检查.md

软件著作权申请资料/环境检查.json

The environment check must inform the user:

Materials will be generated under "Current Directory/软件著作权申请资料".
Whether Markdown drafts, TXT, and basic DOCX are available.
Whether the complete OpenXML environment of the built-in
```
vendor/docx-toolkit
```
is available.
If
```
.NET SDK
```
is missing, ask the user whether to install the complete environment.

User options:

If the user is willing to install the complete environment, install dependencies according to the requirements of
```
vendor/docx-toolkit/scripts/setup.sh
```
, then continue. The complete environment generates and verifies more standardized materials.
If the user does not install, continue to use the fallback solution to generate Markdown, TXT and basic DOCX.
If the complete DOCX environment is missing, must stop and wait for user selection; cannot continue automatically.

Record the gate after user reply:

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage environment \
  --note "<用户选择>"

Do not wait until the final verification stage to find that the complete DOCX environment is unavailable; this information must be provided at the beginning of the process.

2. 定位项目

2. Locate Project

用户通常会把项目放在当前文件夹下。先扫描当前目录，避开本 skill、自身输出目录、

node_modules

、构建产物和隐藏目录，找到最可能的项目根目录。

如果有多个候选项目，必须停止并询问用户选择；如果只有一个明显候选项目，可以直接使用。

Users usually place projects in the current folder. First scan the current directory, avoid this skill, its own output directory,

node_modules

, build artifacts and hidden directories, find the most likely project root directory.

If there are multiple candidate projects, must stop and ask the user to select; if there is only one obvious candidate project, it can be used directly.

3. 分析项目

3. Analyze Project

运行：

bash

python3 scripts/analyze_project.py \
  --project <项目目录> \
  --out 软件著作权申请资料/analysis/project.json

分析内容包括：

```
package.json
```
、README、脚本命令、依赖
前端框架和主要编程语言
入口文件、路由、页面、组件、接口、状态管理
源码文件数量和源程序行数
软件名称候选、主要功能候选、运行命令候选

Run:

bash

python3 scripts/analyze_project.py \
  --project <项目目录> \
  --out 软件著作权申请资料/analysis/project.json

Analysis content includes:

```
package.json
```
, README, script commands, dependencies
Front-end framework and main programming languages
Entry files, routes, pages, components, interfaces, state management
Number of source code files and lines of source program
Candidate software names, candidate main functions, candidate running commands

4. 形成业务理解

4. Form Business Understanding

在写申请表和操作手册前，先让脚本收集项目证据：

bash

python3 scripts/generate_business_context.py \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --software-name "<软件全称>" \
  --out-dir 软件著作权申请资料/草稿

输出：

```
草稿/业务理解证据.md
```
```
草稿/业务理解证据.json
```
```
草稿/业务理解模型稿模板.json
```

这一步只收集证据，不决定最终业务口径。接下来必须由模型阅读

业务理解证据.md/json

、README、PRD/BRD、页面文案、路由、接口、必要源码和用户补充资料，自行判断：

应该重点读取哪些文档和源码
软件属于什么行业 / 领域
目标用户是谁
核心价值是什么
哪些功能应写入软著申请资料
典型操作流程如何组织
操作手册适合采用什么章节结构
申请表建议口径如何表达

模型不得用脚本关键字表决定行业、功能和结构；不得把用户给的范本文案、测试项目名称、测试项目流程写成通用规则。

模型完成研判后，生成一个业务理解模型稿 JSON，字段至少包含：

```
product_positioning
```
```
industry
```
```
target_users
```
```
core_value
```
```
business_features
```
```
business_feature_details
```
```
operation_flow
```
```
application_purpose
```
```
main_functions
```
```
technical_characteristics
```
```
manual_sections
```

然后运行：

bash

python3 scripts/generate_business_context.py \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --software-name "<软件全称>" \
  --out-dir 软件著作权申请资料/草稿 \
  --model-context <模型生成的业务理解JSON>

输出：

```
草稿/业务理解.md
```
```
草稿/业务理解.json
```

最终业务理解必须覆盖：

产品定位
面向领域 / 行业
目标用户
核心价值
主要业务功能
典型操作流程
申请表建议口径
证据来源
操作手册结构建议

如果项目材料不足、业务类型较新，或用户明确希望参考竞品，可联网搜索相近产品和行业资料；外部调研只用于理解行业表达，不能编造项目不存在的功能。调研摘要应写入业务理解草稿，并区分“项目证据”和“行业参考”。

生成

业务理解.md/json

后必须停止，等待用户确认或修改。业务理解确认前，不得生成申请表和操作手册。如果业务理解仍不充分，先请用户补充产品说明。用户确认后运行：

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage business \
  --note "<用户确认内容>"

Before writing the application form and operation manual, first let the script collect project evidence:

bash

python3 scripts/generate_business_context.py \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --software-name "<软件全称>" \
  --out-dir 软件著作权申请资料/草稿

Output:

```
草稿/业务理解证据.md
```
```
草稿/业务理解证据.json
```
```
草稿/业务理解模型稿模板.json
```

This step only collects evidence, does not determine the final business caliber. Next, the model must read

业务理解证据.md/json

, README, PRD/BRD, page copy, routes, interfaces, necessary source code and user supplementary materials, and independently judge:

Which documents and source code should be focused on reading
Which industry/field the software belongs to
Who the target users are
What the core value is
Which functions should be included in the software copyright application materials
How to organize typical operation processes
Which chapter structure is suitable for the operation manual
How to express the suggested caliber of the application form

The model must not use script keyword lists to determine industry, functions and structure; must not write user-provided template copy, test project names, test project processes as general rules.

After the model completes the judgment, generate a business understanding model draft JSON, which must include at least the following fields:

```
product_positioning
```
```
industry
```
```
target_users
```
```
core_value
```
```
business_features
```
```
business_feature_details
```
```
operation_flow
```
```
application_purpose
```
```
main_functions
```
```
technical_characteristics
```
```
manual_sections
```

Then run:

bash

python3 scripts/generate_business_context.py \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --software-name "<软件全称>" \
  --out-dir 软件著作权申请资料/草稿 \
  --model-context <模型生成的业务理解JSON>

Output:

```
草稿/业务理解.md
```
```
草稿/业务理解.json
```

The final business understanding must cover:

Product positioning
Target industry/field
Target users
Core value
Main business functions
Typical operation processes
Suggested application form caliber
Evidence sources
Suggested operation manual structure

If project materials are insufficient, business type is new, or the user clearly wants to refer to competitors, search for similar products and industry materials online; external research is only used to understand industry expressions, and cannot fabricate functions that do not exist in the project. The research summary should be written into the business understanding draft, and distinguish between "project evidence" and "industry reference".

After generating

业务理解.md/json

, must stop and wait for user confirmation or modification. Before the business understanding is confirmed, the application form and operation manual cannot be generated. If the business understanding is still insufficient, ask the user to supplement product description first. After user confirmation, run:

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage business \
  --note "<用户确认内容>"

5. 引导用户确认字段

5. Guide User to Confirm Fields

根据分析结果，向用户确认：

软件全称
版本号
著作权人
开发完成日期
首次发表日期或未发表
开发硬件环境
运行硬件环境
开发操作系统
运行平台/操作系统
开发工具（IDE 或编辑器名称）
运行支撑环境/支持软件（项目运行所需 Node.js、Python、Docker、数据库、浏览器、中间件或外部服务）
软件分类
软件技术特点选项

项目可推断字段可以先给建议值；硬件/系统环境必须允许用户选择建议值或手动填写。字段口径必须区分清楚：

软件全称：必须由用户确认。最终正式资料文件名、代码 Word 页眉、操作手册标题和正文中的软件名称，都必须与
```
申请表信息.md
```
的“软件全称”字段一致。
版本号：必须由用户确认。优先读取项目配置中的版本号作为证据；如果项目版本号小于 V1.0（例如 V0.1.0、V0.9.0），必须明确询问用户“软著首次提交通常写 V1.0，本次填写 V1.0 还是项目当前版本号”。最终
```
申请表信息.md
```
的“版本号”字段就是正式资料版本号。
软件开发环境 / 开发工具：填写 IDE 或编辑器名称，例如 Visual Studio Code、WebStorm、IntelliJ IDEA、Cursor；不要把 React、Next.js、Vite、TypeScript 等技术栈写到此字段。
开发该软件的操作系统：填写实际开发电脑的操作系统版本，例如 Windows 10、Windows 11、macOS 14、macOS 15。
该软件的运行平台 / 操作系统：填写软件运行所在的操作系统版本，例如 Windows 10/11 或 macOS 13及以上版本。
软件运行支撑环境 / 支持软件：填写项目运行依赖的软件环境，例如 Node.js、Python、Docker、PostgreSQL、Redis、浏览器、中间件、外部模型或云服务。
开发的硬件环境：优先读取当前电脑 CPU、内存、硬盘、架构等配置作为建议值；读取不到时让用户填写。
运行的硬件环境：默认可沿用开发硬件环境建议值，也可以按实际部署或运行设备修改。

此阶段需要先停止等待用户输入；收到用户回复后，可整理为

answers

JSON 传入申请表草稿生成。申请表字段的最终门禁在

草稿/申请表信息.md

生成后记录。

Based on the analysis results, confirm with the user:

Full software name
Version number
Copyright holder
Development completion date
First publication date or unpublished
Development hardware environment
Running hardware environment
Development operating system
Running platform/operating system
Development tools (IDE or editor name)
Running support environment/supporting software (Node.js, Python, Docker, database, browser, middleware or external services required for project operation)
Software classification
Software technical characteristics options

Inferable fields of the project can be given suggested values first; hardware/system environment must allow users to choose suggested values or fill in manually. The field caliber must be clearly distinguished:

Full software name: Must be confirmed by the user. The final official material file name, code Word header, operation manual title and software name in the text must all match the "Full Software Name" field in
```
申请表信息.md
```
.
Version number: Must be confirmed by the user. Prioritize reading the version number in the project configuration as evidence; if the project version number is less than V1.0 (e.g., V0.1.0, V0.9.0), explicitly ask the user "Software copyright first submission usually uses V1.0, shall we fill in V1.0 or the current project version number this time?" The "Version Number" field in the final
```
申请表信息.md
```
is the version number of official materials.
Software development environment / development tools: Fill in the IDE or editor name, such as Visual Studio Code, WebStorm, IntelliJ IDEA, Cursor; do not write technical stacks such as React, Next.js, Vite, TypeScript into this field.
Operating system for software development: Fill in the operating system version of the actual development computer, such as Windows 10, Windows 11, macOS 14, macOS 15.
Software running platform / operating system: Fill in the operating system version where the software runs, such as Windows 10/11 or macOS 13 and above.
Software running support environment/supporting software: Fill in the software environment required for project operation, such as Node.js, Python, Docker, PostgreSQL, Redis, browser, middleware, external models or cloud services.
Development hardware environment: Prioritize reading the current computer's CPU, memory, hard disk, architecture and other configurations as suggested values; let the user fill in if it cannot be read.
Running hardware environment: The suggested value of the development hardware environment can be used by default, or modified according to the actual deployment or running device.

At this stage, must stop and wait for user input; after receiving the user's reply, organize it into

answers

JSON and pass it into the application form draft generation. The final gate for application form fields is recorded after

草稿/申请表信息.md

is generated.

6. 确认代码文件选择

6. Confirm Code File Selection

生成代码材料前，先运行候选文件分析：

bash

python3 scripts/propose_code_selection.py \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --out-dir 软件著作权申请资料/草稿

输出：

```
草稿/代码文件候选清单.md
```
：给用户看的候选说明。
```
草稿/代码文件选择.json
```
：可编辑的选择文件。

脚本生成的候选清单只列证据，不默认选择文件。模型必须先阅读业务理解、候选文件、入口文件、页面文件和必要源码，判断哪些源码最能体现软件真实功能和运行逻辑，然后修改

代码文件选择.json

：

```
selected: true
```
表示抽取该文件。
```
selected: false
```
表示不抽取该文件。
```
start_line
```
和
```
end_line
```
可用于只抽取某个文件的指定行段。
```
model_reason
```
必须说明为什么选择该文件或行段。

模型选择通常优先考虑前端入口、页面、核心组件、业务交互、数据请求、状态处理等能给审核员看懂软件功能的代码；如果相关前端代码不足 60 页，再补充后端服务、业务处理、配置等相关源码。补充文件同样必须写入

代码文件选择.json

并由用户确认。不要默认抽取全量代码库。用户确认并记录

code-selection

门禁后，代码抽取只读取

代码文件选择.json

中选中的文件和行段。用户确认后运行：

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage code-selection \
  --note "<用户确认内容>"

Before generating code materials, first run candidate file analysis:

bash

python3 scripts/propose_code_selection.py \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --out-dir 软件著作权申请资料/草稿

Output:

```
草稿/代码文件候选清单.md
```
: Candidate description for users to view.
```
草稿/代码文件选择.json
```
: Editable selection file.

The candidate list generated by the script only lists evidence, does not select files by default. The model must first read the business understanding, candidate files, entry files, page files and necessary source code, judge which source code best reflects the software's real functions and operation logic, then modify

代码文件选择.json

```
selected: true
```
means extract this file.
```
selected: false
```
means do not extract this file.
```
start_line
```
and
```
end_line
```
can be used to extract only specified line segments of a file.
```
model_reason
```
must explain why this file or line segment is selected.

Model selection usually prioritizes front-end entry points, pages, core components, business interactions, data requests, state processing and other code that allows reviewers to understand the software's functions; if relevant front-end code is less than 60 pages, supplement with back-end services, business processing, configuration and other relevant source code. Supplementary files must also be written into

代码文件选择.json

and confirmed by the user. Do not extract the entire code library by default. After the user confirms and records the

code-selection

gate, code extraction only reads the selected files and line segments in

代码文件选择.json

. After user confirmation, run:

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage code-selection \
  --note "<用户确认内容>"

7. 生成 Markdown 草稿

7. Generate Markdown Drafts

运行代码材料抽取：

bash

python3 scripts/extract_code_material.py \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --selection 软件著作权申请资料/草稿/代码文件选择.json \
  --software-name "<软件全称>" \
  --version "<版本号>" \
  --out-dir 软件著作权申请资料/草稿

代码分页规则：

每页默认 60 行，并在 Word 中使用紧凑固定行距，尽量写满页面后再换页。

总页数

>= 60

：生成

代码-前30页.md

和

代码-后30页.md

。

总页数
```
< 60
```
且候选源码已用尽：只生成
```
代码-全部.md
```
。
总页数
```
< 60
```
但候选清单还有可补充源码：停止并要求用户在
```
代码文件选择.json
```
中继续选择补充文件。
不为大项目生成超大“全量备份 Word”。
同时生成
```
代码提取清单.md
```
和
```
代码提取清单.json
```
，用于追溯代码来源。

生成申请表信息草稿：

bash

python3 scripts/generate_application_info.py \
  --analysis 软件著作权申请资料/analysis/project.json \
  --code-manifest 软件著作权申请资料/草稿/代码提取清单.json \
  --business-context 软件著作权申请资料/草稿/业务理解.json \
  --software-name "<软件全称>" \
  --version "<版本号>" \
  --out-dir 软件著作权申请资料/草稿

生成后必须停止，让用户检查并补全

草稿/申请表信息.md

。字段补全并确认后运行：

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage application-fields \
  --note "<用户确认内容>"

生成操作手册草稿：

bash

python3 scripts/generate_manual_draft.py \
  --analysis 软件著作权申请资料/analysis/project.json \
  --business-context 软件著作权申请资料/草稿/业务理解.json \
  --software-name "<软件全称>" \
  --version "<版本号>" \
  --out-dir 软件著作权申请资料/草稿

操作手册草稿不得强制套用用户提供的范本文案或固定章节。应先基于模型写入

草稿/业务理解.json

的

manual_sections

和项目页面入口，自主组织适合该项目的手册结构；通常需要覆盖软件概述、适用对象、运行环境、进入软件、主要功能、操作流程和注意事项等内容，但章节标题和顺序可以随项目实际调整。各章节应包含段落化说明，功能模块不能只列标题和步骤，必须写清楚模块用途、用户操作和系统反馈。语言要面向审核员和普通读者，说明“这个模块是干嘛的、用户怎么操作、操作后看到什么”，不要写代码实现、框架名称、接口封装、状态管理、异步队列等技术细节。撰写时由 agent 自行检查章节是否完整、内容是否过薄、语言是否过于技术化，并在草稿内部完成必要补写；完整草稿完成后只让用户做一次整体确认，确认前不得进入正式 Word/TXT 生成。

生成脚本必须同时写出

草稿/操作手册自检记录.md

和

草稿/操作手册自检记录.json

。自检记录至少包含：

第 1 轮：初稿生成，检查章节完整性、截图预留、模块内容厚度和技术化表达。
第 2 轮：按项目真实运行流程扩写模块说明，补足上下游衔接关系。
第 3 轮：去除制式表达和 AI 味，重点检查重复句式、统一套话、空泛赞美、营销口号、过度整齐的排比和没有项目细节的正确废话。
后续轮次：如果仍有问题，继续补写、去重、改写，不能把未修正的问题直接交给用户。

操作手册的模块写作必须从

草稿/业务理解.json

的行业、目标用户、核心价值、业务功能和典型操作流程出发。不同模块要写出各自的业务作用，不能统一套用“进入页面、填写内容、提交按钮、查看结果”的固定句式；相近模块也要结合项目真实业务区分各自的操作目的和结果，不得把测试项目的功能名称、业务流程或示例文案写成通用规则。

Run code material extraction:

bash

python3 scripts/extract_code_material.py \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --selection 软件著作权申请资料/草稿/代码文件选择.json \
  --software-name "<软件全称>" \
  --version "<版本号>" \
  --out-dir 软件著作权申请资料/草稿

Code pagination rules:

Default 60 lines per page, use compact fixed line spacing in Word, try to fill the page before turning to the next page.

Total pages

>= 60

: Generate

代码-前30页.md

and

代码-后30页.md

Total pages
```
< 60
```
and candidate source code is exhausted: Only generate
```
代码-全部.md
```
.
Total pages
```
< 60
```
but there are still supplementary source code in the candidate list: Stop and require the user to continue selecting supplementary files in
```
代码文件选择.json
```
.
Do not generate oversized "full backup Word" for large projects.
Generate
```
代码提取清单.md
```
and
```
代码提取清单.json
```
at the same time for tracing code sources.

Generate application form information draft:

bash

python3 scripts/generate_application_info.py \
  --analysis 软件著作权申请资料/analysis/project.json \
  --code-manifest 软件著作权申请资料/草稿/代码提取清单.json \
  --business-context 软件著作权申请资料/草稿/业务理解.json \
  --software-name "<软件全称>" \
  --version "<版本号>" \
  --out-dir 软件著作权申请资料/草稿

After generation, must stop and let the user check and complete

草稿/申请表信息.md

. After fields are completed and confirmed, run:

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage application-fields \
  --note "<用户确认内容>"

Generate operation manual draft:

bash

python3 scripts/generate_manual_draft.py \
  --analysis 软件著作权申请资料/analysis/project.json \
  --business-context 软件著作权申请资料/草稿/业务理解.json \
  --software-name "<软件全称>" \
  --version "<版本号>" \
  --out-dir 软件著作权申请资料/草稿

The operation manual draft must not force the use of user-provided template copy or fixed chapters. It should first organize a manual structure suitable for the project based on

manual_sections

草稿/业务理解.json

written by the model and project page entry points; it usually needs to cover software overview, applicable objects, operating environment, accessing the software, main functions, operation processes and precautions, but chapter titles and order can be adjusted according to the actual project. Each chapter should contain paragraph descriptions, functional modules cannot only list titles and steps, must clearly write the module's purpose, user operations and system feedback. The language should be oriented to reviewers and ordinary readers, explaining "what this module does, how the user operates it, what the user sees after operation", do not write technical details such as code implementation, framework names, interface encapsulation, state management, asynchronous queues. During writing, the agent shall self-check whether chapters are complete, content is too thin, language is too technical, and complete necessary supplements in the draft; only let the user do one overall confirmation after the complete draft is finished, and cannot proceed to official Word/TXT generation before confirmation.

The generation script must also write

草稿/操作手册自检记录.md

and

草稿/操作手册自检记录.json

. The self-inspection record must include at least:

Round 1: Initial draft generation, check chapter completeness, screenshot reservations, module content thickness and technical expressions.
Round 2: Expand module descriptions according to the real operation process of the project, supplement upstream and downstream connection relationships.
Round 3: Remove formalized expressions and AI-style content, focus on checking repeated sentence patterns, unified clichés, empty praises, marketing slogans, overly neat parallelism and correct nonsense without project details.
Subsequent rounds: If there are still problems, continue to supplement, deduplicate, rewrite, cannot directly hand over uncorrected problems to the user.

The module writing of the operation manual must start from the industry, target users, core value, business functions and typical operation processes in

草稿/业务理解.json

. Different modules should write their respective business roles, cannot uniformly apply the fixed sentence pattern of "enter page, fill in content, submit button, view results"; similar modules should also distinguish their respective operation purposes and results combined with the real business of the project, and cannot write function names, business processes or example copy of test projects as general rules.

8. 选择并获取截图

8. Select and Obtain Screenshots

操作手册草稿完成后，先停止并让用户选择截图方式，必须给出三种选项：

Chrome DevTools MCP：适合已在浏览器中打开的 Web 项目，优先用于网页全页截图。
Codex Computer Use：适合需要通过桌面应用或浏览器界面点击、切换、查看状态后截图的场景。
用户自行截图：用户自己把 PNG/JPG/JPEG/WebP 图片放入
```
软件著作权申请资料/用户截图/
```
，agent 只负责整理和引用。

如果用户明确说“现在不截图”“先跳过截图”“这次不截图”，也必须记录截图方式门禁，方法填

skip

。跳过截图不阻塞正式资料生成，但操作手册中每个核心功能模块必须保留可见的截图预留文字，例如：

【截图预留：请在此处插入“项目管理”页面或操作结果截图。】

。不要使用 HTML 注释作为截图占位，因为正式 Word 中看不到。

用户选择后，先记录门禁：

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage screenshot-method \
  --method <chrome-devtools|computer-use|user-supplied|skip> \
  --note "<用户选择>"

然后按用户选择检查当前能力并执行：

选择 Chrome DevTools MCP：先用工具发现能力检查当前环境是否有
```
mcp__chrome_devtools__
```
的
```
list_pages
```
、
```
take_snapshot
```
、
```
take_screenshot
```
。可用时，先
```
list_pages
```
确认当前浏览器页面，再按页面/路由截图保存到
```
软件著作权申请资料/截图/
```
；不可用时停止，告知用户需要重新选择截图方式或手动提供截图。
选择 Codex Computer Use：先用工具发现能力检查当前环境是否有
```
mcp__computer_use__
```
的
```
get_app_state
```
、
```
click
```
、
```
press_key
```
。可用时，先
```
get_app_state
```
查看目标应用或浏览器当前状态，再按操作手册需要导航和截图；如果当前 Computer Use 只能返回会话内截图而不能直接保存图片文件，则说明限制，并让用户改选 Chrome DevTools MCP 或把截图放入
```
用户截图/
```
。
选择用户自行截图：创建
```
软件著作权申请资料/用户截图/
```
，提示用户把截图文件放入该目录；用户放入后运行下面的整理命令，把图片复制到
```
软件著作权申请资料/截图/
```
并生成
```
截图清单.json
```
。
选择跳过截图：不运行截图工具，继续保留操作手册中的可见截图预留文字；在生成报告中说明用户选择暂不截图，正式操作手册已预留截图位置。

bash

python3 scripts/capture_screenshots.py \
  --manual-dir 软件著作权申请资料/用户截图 \
  --out-dir 软件著作权申请资料/截图

截图成功后，把截图引用补入

草稿/操作手册.md

；截图失败或用户选择暂不提供截图时，继续生成带截图预留位的文字版，并在报告中说明“操作手册截图未生成或未插入，已保留截图预留位置”。

After the operation manual draft is completed, first stop and let the user select the screenshot method, must provide three options:

Chrome DevTools MCP: Suitable for Web projects already opened in the browser, preferred for full-page web screenshots.
Codex Computer Use: Suitable for scenarios that require clicking, switching, viewing status in desktop applications or browser interfaces before taking screenshots.
User-provided screenshots: Users put PNG/JPG/JPEG/WebP images into
```
软件著作权申请资料/用户截图/
```
, and the agent only responsible for organizing and referencing.

If the user clearly says "don't take screenshots now", "skip screenshots first", "don't take screenshots this time", must also record the screenshot method gate, fill in

skip

for the method. Skipping screenshots does not block the generation of official materials, but each core function module in the operation manual must retain visible screenshot reservation text, such as:

【截图预留：请在此处插入“项目管理”页面或操作结果截图。】

. Do not use HTML comments as screenshot placeholders, because they cannot be seen in the official Word document.

After user selection, first record the gate:

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage screenshot-method \
  --method <chrome-devtools|computer-use|user-supplied|skip> \
  --note "<用户选择>"

Then check the current capability and execute according to the user's selection:

Select Chrome DevTools MCP: First use tool discovery capability to check whether the current environment has
```
list_pages
```
,
```
take_snapshot
```
,
```
take_screenshot
```
of
```
mcp__chrome_devtools__
```
. When available, first
```
list_pages
```
to confirm the current browser page, then take screenshots according to pages/routes and save to
```
软件著作权申请资料/截图/
```
; when unavailable, stop and inform the user to reselect the screenshot method or provide screenshots manually.
Select Codex Computer Use: First use tool discovery capability to check whether the current environment has
```
get_app_state
```
,
```
click
```
,
```
press_key
```
of
```
mcp__computer_use__
```
. When available, first
```
get_app_state
```
to view the current state of the target application or browser, then navigate and take screenshots according to the operation manual needs; if the current Computer Use can only return in-session screenshots but cannot directly save image files, explain the limitation and let the user switch to Chrome DevTools MCP or put screenshots into
```
用户截图/
```
.
Select user-provided screenshots: Create
```
软件著作权申请资料/用户截图/
```
, prompt the user to put screenshot files into this directory; after the user puts them in, run the following organization command to copy the images to
```
软件著作权申请资料/截图/
```
and generate
```
截图清单.json
```
.
Select skip screenshots: Do not run screenshot tools, continue to retain visible screenshot reservation text in the operation manual; explain in the generation report that the user chose to skip screenshots temporarily, and the official operation manual has reserved screenshot positions.

bash

python3 scripts/capture_screenshots.py \
  --manual-dir 软件著作权申请资料/用户截图 \
  --out-dir 软件著作权申请资料/截图

After successful screenshots, add screenshot references to

草稿/操作手册.md

; if screenshots fail or the user chooses not to provide screenshots temporarily, continue to generate the text version with screenshot reservation positions, and explain in the report that "operation manual screenshots are not generated or inserted, and screenshot reservation positions have been retained".

9. 用户确认 Markdown

9. User Confirm Markdown

生成 Word 前，必须让用户确认

软件著作权申请资料/草稿/

下的 Markdown。

重点检查：

软件名称和版本号是否一致
代码材料前30页、后30页页眉软件名称是否与
```
申请表信息.md
```
的“软件全称”一致
代码材料前30页、后30页页眉版本号是否与
```
申请表信息.md
```
的“版本号”一致
```
业务理解.md
```
是否准确反映软件真实业务、行业和目标用户
```
申请表信息.md
```
中“待用户确认”的字段是否已确认
代码材料是否只来自用户确认的文件/行段
操作手册是否符合审核员阅读场景，普通读者是否能看懂模块用途和操作方式
操作手册每个章节是否有段落内容，核心模块是否写清模块用途、操作过程和结果反馈，是否避免过度技术化语言
截图是否正确；若用户跳过截图，正式操作手册是否保留可见截图预留位置

用户确认后，必须记录

markdown

门禁；未记录时不得生成正式 Word/TXT。

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage markdown \
  --note "<用户确认内容>"

Before generating Word, must let the user confirm the Markdown files under

软件著作权申请资料/草稿/

Key checks:

Whether the software name and version number are consistent
Whether the software name in the header of the first 30 pages and last 30 pages of code materials matches the "Full Software Name" in
```
申请表信息.md
```
Whether the version number in the header of the first 30 pages and last 30 pages of code materials matches the "Version Number" in
```
申请表信息.md
```
Whether
```
业务理解.md
```
accurately reflects the software's real business, industry and target users
Whether the fields "to be confirmed by user" in
```
申请表信息.md
```
have been confirmed
Whether code materials only come from files/line segments confirmed by the user
Whether the operation manual is suitable for the reviewer reading scenario, whether ordinary readers can understand the module purpose and operation method
Whether each chapter of the operation manual has paragraph content, whether core modules clearly write the module purpose, operation process and result feedback, whether overly technical language is avoided
Whether screenshots are correct; if the user skips screenshots, whether the official operation manual retains visible screenshot reservation positions

After user confirmation, must record the

markdown

gate; official Word/TXT cannot be generated without recording.

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage markdown \
  --note "<用户确认内容>"

10. 生成正式 Word/TXT

10. Generate Official Word/TXT

用户确认后运行：

bash

python3 scripts/build_docx_from_md.py \
  --workdir 软件著作权申请资料 \
  --software-name "<软件全称>" \
  --version "<版本号>"

正式生成脚本必须重新读取

草稿/申请表信息.md

中已确认的“软件全称”和“版本号”，并用它们生成正式资料文件名、代码 Word 页眉和操作手册 Word。若命令参数

--software-name

--version

与申请表字段不同，以申请表字段为准，并在

正式资料/生成报告.md

中记录提示。

输出：

```
正式资料/申请表信息.txt
```

代码达到或超过 60 页：

正式资料/<软件全称>-代码(前30页).docx

正式资料/<软件全称>-代码(后30页).docx

代码不足 60 页：

正式资料/<软件全称>-代码(全部).docx

正式资料/<软件全称>_操作手册.docx

```
正式资料/生成报告.md
```

After user confirmation, run:

bash

python3 scripts/build_docx_from_md.py \
  --workdir 软件著作权申请资料 \
  --software-name "<软件全称>" \
  --version "<版本号>"

The official generation script must re-read the confirmed "Full Software Name" and "Version Number" in

草稿/申请表信息.md

, and use them to generate official material file names, code Word headers and operation manual Word. If the command parameters

--software-name

--version

are different from the application form fields, the application form fields shall prevail, and a prompt shall be recorded in

正式资料/生成报告.md

Output:

```
正式资料/申请表信息.txt
```

If code reaches or exceeds 60 pages:

正式资料/<软件全称>-代码(前30页).docx

正式资料/<软件全称>-代码(后30页).docx

If code is less than 60 pages:

正式资料/<软件全称>-代码(全部).docx

正式资料/<软件全称>_操作手册.docx

```
正式资料/生成报告.md
```

11. 三轮验证

11. Three Rounds of Verification

至少执行三轮验证并修复发现的问题：

文件完整性：目标 Word/TXT 是否存在且非空。
代码真实性：抽样检查代码片段能回溯到项目源码。
业务真实性：申请表和操作手册中的行业、目标用户、主要功能、操作流程能回溯到
```
业务理解.md
```
和项目文档。
一致性和格式：软件名称、版本号、页数规则、申请表字段、操作手册标题和截图引用是否一致。

可用命令：

bash

python3 -m py_compile scripts/*.py
bash vendor/docx-toolkit/scripts/docx_preview.sh <生成的docx>

完整 DOCX 环境检查和安装必须直接恢复/构建

vendor/docx-toolkit/scripts/dotnet/DocxToolkit.Cli/DocxToolkit.Cli.csproj

，不要对

vendor/docx-toolkit/scripts/dotnet

目录或

.slnx

文件执行隐式 restore/build。

如果

环境检查.md

或

vendor/docx-toolkit/scripts/env_check.sh

显示

.NET SDK

缺失，说明完整 DOCX OpenXML 校验环境未就绪。用户明确选择不安装并记录

environment

门禁后，继续生成 Markdown、TXT 和基础 DOCX，并在报告中说明当前使用兜底路径。

Execute at least three rounds of verification and fix found problems:

File integrity: Whether the target Word/TXT exists and is non-empty.
Code authenticity: Sampling check that code fragments can be traced back to project source code.
Business authenticity: The industry, target users, main functions and operation processes in the application form and operation manual can be traced back to
```
业务理解.md
```
and project documents.
Consistency and format: Whether the software name, version number, pagination rules, application form fields, operation manual title and screenshot references are consistent.

Available commands:

bash

python3 -m py_compile scripts/*.py
bash vendor/docx-toolkit/scripts/docx_preview.sh <生成的docx>

Complete DOCX environment check and installation must directly restore/build

vendor/docx-toolkit/scripts/dotnet/DocxToolkit.Cli/DocxToolkit.Cli.csproj

, do not perform implicit restore/build on the

vendor/docx-toolkit/scripts/dotnet

directory or

.slnx

files.

环境检查.md

vendor/docx-toolkit/scripts/env_check.sh

shows that

.NET SDK

is missing, it means the complete DOCX OpenXML verification environment is not ready. After the user clearly chooses not to install and records the

environment

gate, continue to generate Markdown, TXT and basic DOCX, and explain in the report that the current fallback path is used.

何时询问用户

When to Ask the User

以下场景必须询问并停止，等待用户输入后再继续：

多个项目候选目录需要选择。
启动环境检查发现完整 DOCX 环境缺失时，询问用户是否安装完整环境。
业务理解草稿生成后，请用户确认软件用途、行业、目标用户、核心功能和申请口径。
软件全称、著作权人、日期、硬件/系统环境等登记字段需要确认。
代码文件候选清单生成后，需要用户确认或修改
```
代码文件选择.json
```
。
操作手册截图前，需要用户在 Chrome DevTools MCP、Codex Computer Use、用户自行截图三种方式中选择一种；选择后再检查对应工具是否可用。
用户是否确认 Markdown 草稿并进入 Word 生成。

Must ask and stop in the following scenarios, wait for user input before continuing:

Multiple candidate project directories need to be selected.
When the initial environment check finds that the complete DOCX environment is missing, ask the user whether to install the complete environment.
After the business understanding draft is generated, ask the user to confirm the software purpose, industry, target users, core functions and application caliber.
Registration fields such as full software name, copyright holder, date, hardware/system environment need to be confirmed.
After the code file candidate list is generated, the user needs to confirm or modify
```
代码文件选择.json
```
.
Before taking screenshots for the operation manual, the user needs to choose one of the three methods: Chrome DevTools MCP, Codex Computer Use, user-provided screenshots; check whether the corresponding tool is available after selection.
Whether the user confirms the Markdown draft and proceeds to Word generation.