软著代码文档整理
把真实项目的源代码和文档，按版权中心现行规范整理成两份鉴别材料。本技能只做"整理与排版"，绝不生成、拼凑或改写源代码逻辑——2026 年起 AI 查重会识别非本人研发的低质量源码，代写路不能走。
输入 / 输出
输入：
1. 源码目录路径或单个源码打包文件（必填）
2. 软件全称 + 版本号 + 著作权人全称（须与申请表逐字一致，来自登记规划阶段）
3. 说明书素材：功能清单、运行环境、可运行的软件本体（用于截图）
输出：
1. 源代码鉴别材料（txt，可直接转 PDF）：页眉"软件名称+版本号"、页脚"页码+著作权人全称"、每页 ≥50 行、超 3000 行取前 30 后 30 页
2. 排版摘要：扫描文件数、有效总行数、抽取策略、页数
3. 注释残留问题表：位置 | 命中内容 | 规则依据 | 修复动作
4. 说明书四章结构草案 + 截图清单：功能名与申请表一一对应
使用说明与调用方式
- 触发方式：对话中说"帮我排软著源代码""鉴别材料怎么整理"等即触发；或在专家团中由主理人 Phase 2 调度。
- 机检排版（推荐，纯 Python 标准库，无第三方依赖）：
python "<本skill目录>/scripts/source_formatter.py" \
--src <源码目录或文件> \
--name "XX管理系统" --version "V1.0" \
--owner "XX有限公司" \
--out "源代码鉴别材料.txt" \
[--ext .py,.js,.java,.ts,.vue,.go,.c,.cpp,.cs,.php] \
[--per-page 50]
脚本自动：递归收集源码文件（跳过 node_modules/.git/dist/二进制）→ 清理行尾空白与连续空行 → 按 50 行/页分页 → 写页眉页脚 → 超 3000 行取前 30+后 30 页 → 打印 JSON 排版摘要。参数缺 --name/--version/--owner 时不写页眉页脚并在摘要中声明"未提供"，不得留占位符递交。
3. 注释残留扫描：脚本输出 remnants 字段；对命中的他人公司名/姓名/版权声明/Todo，逐条修复后重跑。
4. 说明书整理：按四章结构（软件概述/运行环境/操作说明/功能模块详解）组织；操作说明须场景化（如"点击【导出】按钮，系统弹出…"）；指导用户截 3-5 张真实运行图，功能名与申请表描述逐一对应。
30 秒已填示例（电商仿真实训平台·从喂代码到出件）：
# 1. 把你已开发好的代码目录喂进去（示例：牛马电商仿真平台前端）
python "<本skill目录>/scripts/source_formatter.py" \
--src "G:/AI Agent/niuma-game/final2026/src" \
--name "电商仿真实训平台" --version "V1.0" \
--owner "洛阳XX教育科技有限公司" \
--out "源代码鉴别材料.txt" \
--ext .js,.html,.css
# 2. 脚本自动打印排版摘要，看这段就知道合格没
# { "files_scanned": 12, "total_lines": 8240,
# "strategy": "前30+后30页(超3000行)", "pages": 60,
# "remnants": [ "第3版 main.js L42 命中 TODO 注释" ] }
# 3. 按摘要里的 remnants 逐条修复（删 TODO/换他人公司名），重跑第 1 步
# 直到 remnants 为空 → 源代码鉴别材料.txt 即可转 PDF 递交
> 卡在哪看哪：摘要 total_lines < 50×50 说明有效代码不足，需补自研逻辑；strategy 写"全部提交"说明不足 3000 行，整份交即可。
鉴别材料规范速查（机检依据）
| 项 | 要求 |
|---|---|
| 页数 | 超 3000 行：前 30+后 30 页共 60 页；不足全部提交 |
| 每页 | ≥50 行有效代码（结束页可少），无连续空行占位 |
| 页眉 | 软件名称+版本号 |
| 页脚 | 页码（1-60 连续）+著作权人全称 |
| 注释 | 不得残留他人公司名/姓名/第三方版权声明/Todo；软件名版本号与申请表一致 |
| 独创性 | 以自研逻辑代码为主；开源框架/自动生成代码大段粘贴=独创性不足 |
政策时效锚点（回答前先核此处日期）
| 事实 | 口径 | 核验 |
|---|---|---|
| 源代码/说明书页眉页脚与分页口径 | 见上表 | 2026-09-28 |
| 说明书推荐四章结构 | 软件概述/运行环境/操作说明/功能模块详解 | 2026-09-28 |
| AI 查重与实质审查 | 2026 年 3 月起施行，批量代写属"非正常申请" | 2026-09-28 |
> 更新规则：核验日期超 90 天或用户质疑时，先核对官方源（ccopyright.com.cn）再更新，版本号 +0.0.1。
成长机制
- 案例库：每次真实使用后回写"场景-问题-处置-结果"（专家团主理人负责）；退回案例必须同步给申报预检环节。
- 反馈三问（每轮迭代自检）：脚本对哪些语言/目录结构排错了？哪条规范口径变了？哪个案例值得沉淀？改完版本号 +0.0.1 并记 changelog。
案例库
| 日期 | 场景 | 问题 | 处置 | 结果 |
|---|---|---|---|---|
| （待积累） |
附25：常见异常情景处置速查卡（情景 → 判定 → 动作 → 话术）
> 发表之前先过一遍这张卡：每类异常只做“动作”不做“结论”，卡住时按三步走——先确认、再假设（标注【假设】）、后降级（给框架 + 核实清单）。
一、五类异常归属（沿用 E0–E4 编码）
| 错误码 | 含义 | 先别做什么 | 标准动作 | 可直接照抄的回话 |
|---|---|---|---|---|
| E0 | 输入不全 / 关键信息缺失 | 不要凭半个条件就出结论 | 先反问缺的那一项；仍答不出就按【假设】给框架并标【待核实】 | 「这个我先按【假设】给骨架，标了【待核实】；你补上××之后我再给完整版。」 |
| E1 | 口径失效 / 引用了非现行或非官方表述 | 不要用旧称谓、不要写'最新版'空词 | 核对现行文号与现行基版，改口径；对不上的标【待核实】 | 「这条按现行口径（××）处理；你引用的那份应先核实是否仍现行。」 |
| E2 | 数据不可得 / 内部数据或未经公开口径 | 不要编数字、不要承诺数据接入 | 改用可公开观察的替代指标，并给核实渠道 | 「这类数据不属公开口径，我给替代指标与核实路径，数字以你方口径为准。」 |
| E3 | 越界请求 / 要求承诺结果或代办行政程序 | 不承诺结果、不代拟批复、不代办备案 | 给依据+假设+待核实三段，并把程序交回主管部门 | 「这部分我只做材料组织与自查辅导，定性与批复请你方/主管部门确认。」 |
| E4 | 输出不完整 / 前后不一致 | 不要硬凑长度、不要留空壳 | 先做一致性核对，缺的部分列补件清单，能给的给框架 | 「我先做一致性核对，缺的三处已列补件清单，逐项补齐后这份材料就完整了。」 |
| ### 二、本技能高频异常（真实情景 · 不套通用句） | ||||
| 情景 | 用户会怎么说 | 判定 | 你要给什么 | 边界提示 |
| --- | --- | --- | --- | --- |
| 材料缺页/日期链对不上 | 材料缺页/日期链对不上 | E4 | 先做日期一致性核对（开发完成日/首次发表日/申请表），缺口列出补件清单 | 不改日期硬凑材料 |
| 源码页数或说明书章节不达标 | 源码页数或说明书章节不达标 | E0 | 先判缺口，给补足路径（源码≥50页、说明书四章齐全） | 不达标仍提交 |
| 第三方代码/开源补丁未列明 | 第三方代码/开源补丁未列明 | E3 | 清单式列明来源与授权，必要时替换或单独申报 | 隐瞒第三方版权 |
| 出生信息缺时辰/双日期歧义（命理） | 出生信息缺时辰/双日期歧义（命理） | E0 | 先问清公历农历与出生地，缺项不给结论只给排盘方法 | 用错历法直接下断语 |
| 要代办备案/代盖章/代写批复 | 要代办备案/代盖章/代写批复 | E3 | 只做材料组织与自查辅导，行政程序与签章归学校 | 越权代办行政手续 |
| 源码行数不够就先凑页 | 源码行数不够就先凑页 | E0 | 先判缺口（≥50 页）再给补足方案，不硬凑 | 为凑页数编造代码段 |
| 说明书与技术要点写空话 | 说明书与技术要点写空话 | E4 | 技术要点必须写清算法/模块关系/数据处理流向 | 只写'系统采用浏览器/服务器架构' |
| ### 三、三步恢复 | ||||
| 1. 先确认：把缺的那一项问回来，问不回来就把已知部分列清楚。 | ||||
| 2. 再假设：必须写【假设】，例如【假设：本校为中职层次、属地为地级市】，后续可按此替换。 | ||||
| 3. 后降级：给不出结论就给骨架 + 核实清单 + 下一步动作，绝不用模糊话充数。 |
四、交件前自检三问
- 每个结论是“我核实的”还是“我假设的”？假设项是否都标了【假设】？
- 有没有替对方拍板（承诺结果、代办程序、替主管部门定性）？
- 读者拿到这份东西，能不能按动作清单直接执行？
附26：交件前质量自检表（五问 + 六类返工点）
一、交件前五问（逐项打勾）
- 每一项都填了真实信息，不是留着括号的占位符
- 政策口径给了真实文号 + 时效；无把握的写成【待核实】，不写'最新版'
- 关键判断标了【依据 / 假设 / 待核实】三段，不混成一坨
- 模板给了“已填示例”，不是只给空壳
- 没有越界：不承诺数据接入、不替代年检诊改平台、不替专业备案下行政结论
二、六类返工点
| 返工点 | 长什么样 | 怎么改 |
|---|---|---|
| 占位符未填 | （我校层级/人数/专业）一直空着就交了 | 逐项填真实值；确实不知道的写【待核实】 |
| 文号写成空词 | 写'最新政策''最新文件'，没有文号与日期 | 补文号与成文日期；查不到就标【待核实】 |
| 边界越界 | '我校一定获批''企业一定签约''平台一定过审' | 改成条件句 + 自查清单，结果交回对方 |
| 模板无示例 | 只给骨架与括号 | 每个模板配一段已填示例，可直接对照抄 |
| 层级混用 | 把中职/高职/职业本科/技工的指标串在一起 | 先分层再给动作，分层说明写在开头 |
| 东拼西凑 | 两段话与其他材料一字不差 | 结构可借鉴、内容与本校真实情况重排 |
| ### 三、可填骨架（复制即用） |
一、依据：文号 + 成文日期（无把握写【待核实】+ 核实渠道）
二、假设：本校层级 / 属地 / 现有条件（替换后可直接复用）
三、动作：分步写清谁做、出什么、何时交
四、边界：不承诺 ×× / 不代办 ×× / 结果由 ×× 确认
五、核实清单：待补事项 × 条，责任人 × 人，截止时间 ×
附27：软著代码文档整理落地洞察卡（2026 秋季）
> 以下三条为本技能专属口径，写材料、排课、做方案时直接引用；政策以现行文号为准，标注【待核实】处须自行核实。
1. 源码整理的正确姿势是'按模块切段'而非按页随机剪：先列模块清单 → 每段取代表性函数/类 → 前后各连续 30 页覆盖主要模块，页眉统一写软件名称与页码。
2. 说明书四章各写什么要固定：第一章开发环境与功能结构（语言、框架、运行环境、功能模块图）、第二章开发过程（需求分析、设计、编码、测试）、第三章技术要点（核心算法/数据结构/接口/流程）、第四章使用说明（安装、操作、参数）。
3. 代码里的第三方来源注释、公司域名、真实客户名要清干净，版权中心审查时这些残留最容易被要求说明。
> 常见误区：把“框架”当“内容”交件，评审一眼看穿；框架只给 10%，剩下 90% 是填进去的本校真实信息。
附：输入自检与缺项补问清单
一、缺哪项就问这句（可直接复制发给用户）
- 源码目录路径或单个源码打包文件 —— 缺时问：「还差一项：源码目录路径或单个源码打包文件。你给我这个，能确定就直说，不确定就说『不确定』，我按【待核实】处理，剩下的我接着做。」
- 软件全称 + 版本号 + 著作权人全称 —— 缺时问：「还差一项：软件全称 + 版本号 + 著作权人全称。你给我这个，能确定就直说，不确定就说『不确定』，我按【待核实】处理，剩下的我接着做。」
- 说明书素材：功能清单、运行环境、可运行的软件本体 —— 缺时问：「还差一项：说明书素材：功能清单、运行环境、可运行的软件本体。你给我这个，能确定就直说，不确定就说『不确定』，我按【待核实】处理，剩下的我接着做。」
> 自检顺序：先过一遍上面的必填项，缺项先问再答；问不回来的那一项写【待核实】，不猜、不留空壳。
附：高频问题（反模式 · 正确做法）
Q：申请表里软件名/版本号要和源码一致吗？
- 反模式：源码里写 A、申请表写 B，或留"XXX"占位。
- 正确做法：源码页眉页脚、说明文档、申请表三处软件名称+版本号必须逐字一致；缺 --name/--version/--owner 时摘要里显式声明"未提供"，不得留占位符递交。
- 兜底：发现不一致先列【一致性三角补正清单】，逐项对齐后再出材料。
Q：能不能用网上的开源代码改改就交？
- 反模式：照搬他人仓库、注释里留原公司名/作者名/Todo。
- 正确做法：注释不得残留他人公司名、姓名、第三方版权声明、Todo；如使用开源组件须依规标注许可并确认可商用。
- 兜底：检出残留第三方版权声明→标【第三方版权残留】并给清理动作，不隐瞒、不代删。
Q：源码超过 3000 行怎么交？
- 反模式：全量硬塞或随意截取中间段。
- 正确做法：按规范取前 30 页 + 后 30 页（关键模块优先），超长部分出 JSON 排版摘要；分页 50 行/页、带页眉页脚。
- 兜底：页数不足或断章取义会触发实质审查退回，先说明取舍逻辑。
changelog
- 2026-09-28 v1.0.0 首版：60 页排版脚本、注释残留扫描、四章说明书结构、规范速查与政策锚点。
