论文、专利、软著、博客都能用：我把 AI 知识产权写作做成了一个 Skill

作者： HOS(安全风信子) 日期： 2026-02-26 主要来源平台： GitHub（HOS_SKILL_WORKFLOW） 读完你能学到： 一套覆盖论文、专利、软著、书籍、博客、润色六大场景的 AI 知识产权写作 Skill 体系，以及如何用"共享上下文 + 跨技能管线"把同一个研究成果一次性沉淀为多种知识资产。

目录

• 先看问题场景
• 一、AI 写作最大的误区：生成文字 ≠ 专业写作
• • 1.1 那个把权利要求写成"产品说明书"的坑
  • 1.2 五大硬伤，一条条说透
  • 1.3 为什么"多写提示词"救不了你
• 二、HOS-IP-Writing 到底是什么
• • 2.1 一句话定位
  • 2.2 仓库里的真实家底
  • 2.3 六大场景到底覆盖了什么
  • 2.4 版本与合规信息（从仓库核实）
• 三、为什么要统一成一个 Skill
• • 3.1 散装的坏处，统一的好处
  • 3.2 路由机制长什么样
  • 3.3 [IP-Context 摘要]：信息不丢失的"交接棒"
• 四、六大写作模式全景
• • 4.1 六张身份证
  • 4.2 每个模式都配了"质量门禁"
  • 4.3 四条跨技能管线（统一性的最终体现）
  • 4.4 约定俗成的输出规范
• 五、论文模式：把"混乱的线性过程"变成"可控的五阶段系统"
• • 5.1 定位与触发
  • 5.2 五阶段全流程
  • 5.3 投稿类型适配表（仓库真实数据）
  • 5.4 IMRAD 大纲模板与篇幅分配
  • 5.5 项目初始化与进度跟踪（别跳过，这才是工程化）
  • 5.6 审稿回复：一个最容易翻车但也最值钱的场景
• 六、专利模式：权利要求书写得像产品说明书？那是因为没人教你结构
• • 6.1 官方定位
  • 6.2 三种专利类型速查（仓库真实数据）
  • 6.3 专利写作的八步工作流
  • 6.4 发明交底书：给代理人的"投名状"
  • 6.5 权利要求书：整份专利的灵魂
  • 6.6 说明书五部分与摘要
  • 6.7 OA 回复：决定专利生死的 4 个月
• 七、软著模式：输入一个 Repo URL，生成一套申请材料
• • 7.1 官方定位
  • 7.2 五阶段工作流
  • 7.3 时间规划（仓库给的估算）
  • 7.4 仓库分析阶段到底分析什么
  • 7.5 软件说明书必备章节
  • 7.6 格式规范（决定生死的细节）
  • 7.7 常见驳回原因（对照自查）
  • 7.8 风险控制表（仓库原文）
• 八、博客模式：一篇内容，五个平台
• • 8.1 官方定位
  • 8.2 六阶段流程
  • 8.3 五种标题类型（直接可抄）
  • 8.4 SEO 检查清单（仓库真实标准）
  • 8.5 多平台适配：格式差异比你想象的大
• 九、AI 润色模式：去 AI 味，是每个写作者的新刚需
• • 9.1 官方定位
  • 9.2 四类 AI 写作痕迹（仓库原文）
  • 9.3 语境匹配策略
  • 9.4 学术化改写对照（HOS 中文扩展）
  • 9.5 四阶段流程与三段式输出
  • 9.6 四大约束
• 十、如何把一个研究成果转换成多个知识资产（本文最值得收藏的一节）
• • 10.1 一次研究，五种产出
  • 10.2 管线一：知识产权保护（patent → copyright → paper）
  • 10.3 管线二：学术全流程（paper → review → 投稿）
  • 10.4 管线三：技术影响力（blog → book → review）
  • 10.5 管线四：内容工厂（blog 多篇 → review → book）
  • 10.6 共享上下文：这一切能串起来的根本
  • 10.7 生态集成：它不是孤岛
• 十一、常见问题 FAQ（大家问得最多的五个）
• 本文核心观点回顾
• 学完本文你能做什么

先看问题场景

“我让 AI 帮我写专利申请，结果权利要求写得像产品说明书。”

这是我一个做安全工具的朋友的真实遭遇。他把自己的代码混淆工具丢给大模型："帮我写个发明专利。"AI 很快吐出两千字，读起来通顺、结构完整、语句优美。他满心欢喜地发给专利代理，结果代理当场把它批得一文不值：

“你这哪是权利要求书？独立权利要求里堆满了从属细节，把保护范围缩成了针眼；'大约 10cm’这种模糊用语直接违反清楚性要求；说明书五个部分缺了两块；摘要超过 300 字。重写吧，这稿子连提交都不够格。”

类似的故事每天都在上演：写论文的，AI 帮他"生成"参考文献，打开一查全是编的；写博客的，AI 一篇接一篇地发，评论区却有人问"这是 AI 写的吧"；申请软著的，材料交上去被打回，理由是"软件名称用了英文缩写"“说明书缺运行环境章节”。

问题到底出在哪？

不是 AI 不够强，而是"生成文字"和"专业写作"之间，隔着一整条工业流水线。

AI 擅长的是"把 token 接得通顺"，而论文、专利、软著、书籍、博客这些知识产权写作，靠的是结构、证据、格式、门禁——这些恰恰是裸奔状态下的大模型最不擅长的地方。

我一度以为只能靠"多写几句好提示词"来救。直到我挖开 GitHub 上 lxcxjxhx/HOS_SKILL_WORKFLOW 仓库里的 S-07-HOS-IP-Writing 模块，思路才真正打开：把专业写作的"行规"全部固化成 Skill，让 AI 按工序、按门禁、按交付标准来干活。

本文不吹概念。所有内容都来自我对该仓库的真实抓取，六大模式逐一拆解，关键代码全部标注来源。读完你能直接把这套 Skill 装进你的 AI IDE，并理解它是怎么把"一次研究"变成"多种知识资产"的。

（免责说明：本文所有技术细节均来自仓库真实文件，代码片段均标注【来源：HOS_SKILL_WORKFLOW/S-07-HOS-IP-Writing/<文件名>】；无法从仓库核实的部分我会明确标注【需核实】。）

一、AI 写作最大的误区：生成文字 ≠ 专业写作

本节核心收获： 认清裸奔 AI 写知识产权的五大硬伤（结构、证据、专业表达、格式、重复率），你才知道为什么需要 Skill 兜底。

1.1 那个把权利要求写成"产品说明书"的坑

先复盘我朋友那份"AI 专利"到底错在哪，因为这就是裸奔 AI 的典型死法。

把他的话转述给专业代理后，对方列了五条，条条致命：

1. 结构不对。专利申请文件是有法定结构的：权利要求书、说明书、摘要各司其职，说明书内部又分技术领域、背景技术、发明内容、附图说明、具体实施方式五个部分。AI 把所有内容混成一锅粥，代理根本没法直接套用。
2. 证据不足。权利要求书要求"技术特征 → 技术效果"一一对应，有益效果要有数据支撑。AI 编出来的"显著提升了系统性能"既没有实验数据，也没有量化指标。
3. 专业表达错误。专利文件严禁"大约"“左右”"preferably"这类模糊用语，AI 随手就是一堆。
4. 格式不符合要求。摘要限 300 字以内、独立权利要求只能有一个主题、引用关系必须正确……这些"行规"AI 一概不知。
5. （最隐性的）重复率与可信度风险。AI 生成的文本天然带有训练语料的"平均脸"，查重、查 AI 痕迹都容易中招。

1.2 五大硬伤，一条条说透

我把裸奔 AI 写知识产权的通病归纳为五类，你可以对照自己的经历看：

先统一几个贯穿全文的术语，避免歧义：

Skill（技能） 一个包含 SKILL.md、workflows、templates 等文件的目录包，AI IDE 加载后即获得该领域的标准作业流程。 IP（知识产权） Intellectual Property 的缩写，本文指论文、专利、软著、书籍、博客等文字类知识产权产出。 IMRAD Introduction（引言）、Methods（方法）、Results（结果）与 Discussion（讨论）四段式论文结构的缩写。 质量门禁 每个阶段必须通过的验收标准，不通过则不允许进入下一阶段。

铁律第一条：AI 是优秀的"起草秘书"，但绝不是合格的质量经理。 起草之后的每一道闸门，都得由"规则"来把守——这就是 Skill 存在的意义。

1.3 为什么"多写提示词"救不了你

也许你会说：我可以在提示词里把要求写全啊。问题是：提示词是一次性的，Skill 是可复用的；提示词靠你记忆，Skill 靠文件沉淀。

论文要"五阶段流程"，专利要"八步工作流"，软著要"五阶段材料流程"，博客要"六阶段发布流程"，还有一堆"质量门禁"要逐条卡——这些内容加起来上万字，你不可能每次写都敲一遍。而 Skill 恰好就是干这个的：把标准作业程序（SOP）固化成一个可以被 AI IDE 自动加载的文件包。

金句一：提示词是写给小白的便签，Skill 是写给工业的图纸。

二、HOS-IP-Writing 到底是什么

本节核心收获： 看懂这个 Skill 的整体架构——六大子技能 + 统一路由 + 共享上下文 + 四条跨技能管线 + 质量门禁。

2.1 一句话定位

根据仓库 S-07-HOS-IP-Writing/SKILL.md 的官方描述：

HOS-IP-Writing 是一个统一的知识产权写作技能体系，覆盖论文、专利、软著、书籍、博客、润色六大场景。系统采用智能路由机制，根据用户意图自动激活对应的子技能，并支持跨技能协作管线。

也就是说，它不是"一个写论文的提示词"，也不是"六个互不相干的文件夹"，而是一个带路由、带上下文、带门禁、带管线的写作操作系统。

2.2 仓库里的真实家底

模块 README.md 给的架构图（原文）是这样的：

S-07-HOS-IP-Writing/
├── SKILL.md                     # 本文件 — 统一路由与编排
├── README.md                    # 快速入门
├── ATTRIBUTION.md               # 开源来源标注
│
├── shared/                      # 共享上下文层
│   ├── context-schema.md        # 跨技能数据协议
│   ├── quality-gates.md         # 质量门禁标准
│   ├── output-conventions.md    # 输出格式约定
│   └── hos-integration.md       # HOS 生态集成点
│
├── pipelines/                   # 跨技能管线
│   ├── academic-paper.md        # 学术全流程
│   ├── tech-influence.md        # 技术影响力建设
│   ├── ip-protection.md         # 知识产权保护
│   └── content-factory.md       # 内容工厂
│
├── paper/SKILL.md               # 论文写作子技能
├── patent/SKILL.md              # 专利写作子技能
├── copyright/SKILL.md           # 软著写作子技能
├── book/SKILL.md                # 书籍写作子技能
├── blog/SKILL.md                # 博客写作子技能
└── review/SKILL.md              # 文本润色子技能

【来源：HOS_SKILL_WORKFLOW/S-07-HOS-IP-Writing/README.md】

注意，这还只是"目录骨架"。往下一层，每个子技能都自带 workflows/（工作流）和 templates/（模板）。我按真实文件清单数过：

• paper/：2 个工作流（论文写作完整工作流、审稿回复工作流）+ 4 个模板（项目初始化、大纲、章节模板、质量检查清单）
• patent/：3 个工作流（专利写作、专利类型指南、OA 回复）+ 6 个模板（交底书、权利要求书、说明书、摘要、附图说明、OA 回复）
• copyright/：3 个工作流 + 10 个模板（软件信息、说明书、模块设计、功能说明、算法描述、数据库设计、流程图、创新点、截图指南、申请材料）
• blog/：3 个工作流（写作、平台适配、SEO）+ 9 个模板（博客、教程、案例 + 5 个平台指南 + SEO 清单）
• book/：3 个工作流（写作、章节开发、出版）

这不是 PPT 式的空架子，是真的能落地的文件。

2.3 六大场景到底覆盖了什么

仓库 README 里有一张"选择你需要的技能"表，我用它快速带你扫一遍：

2.4 版本与合规信息（从仓库核实）

• 模块版本：2.0.0，创建日期 2026-07-21，最后更新 2026-07-26，维护者 HOS-IP-Writing Team [^1]
• 许可证：自研部分 MIT，集成部分遵循原项目许可证
• 集成来源（ATTRIBUTION.md 确认）：
  • 论文写作基于 SNL-UCSB/paper-writing-skill（MIT）和 kgraph57/paper-writer-skill 二次开发
  • 文本润色基于 stephenturner/skill-deslop 二次开发
  • 专利、软著、书籍、博客写作：HOS 完全自研
• 所属仓库 HOS_SKILL_WORKFLOW 本体采用 AGPLv3，兼容 Claude Code、OpenAI Codex、Cursor、Gemini CLI、VSCode AI IDE、Trae 等平台【需核实：仓库 README 如此声明，实际兼容性以各平台官方为准】

这里值得多说一句：连"开源来源标注"都要单独开一个 ATTRIBUTION.md 来维护，这个细节很能说明它的工程化程度——它不是一个人拍脑袋的产物，而是按开源合规标准在运营的项目。

三、为什么要统一成一个 Skill

本节核心收获： 理解"统一"的三重价值——路由不用选、上下文不丢失、多技能能串成流水线；掌握 [IP-Context 摘要] 这一核心机制。

3.1 散装的坏处，统一的好处

市面上并不缺"论文写作提示词"“专利写作模板”，但它们是孤岛：论文写完，没人帮你自动润色；专利写完，没人帮你把技术方案递给软著模块；博客写了一批，没人帮你整理成书。

HOS-IP-Writing 的统一设计解决了三个散装方案解决不了的问题：

1. 路由不用选：你说"帮我申请软著"，系统自动路由到 copyright；你说"去 AI 味"，自动路由到 review。意图模糊时，它会列出匹配子技能让你选。
2. 上下文不丢失：所有子技能共享一套 project / author / output 上下文数据结构，写专利时填过的技术栈、创新点，写论文时不用再填第二遍。
3. 多技能能串成流水线：仓库预定义了 4 条跨技能管线，覆盖"学术全流程"“技术影响力”“知识产权保护”"内容工厂"四大高频场景。

3.2 路由机制长什么样

SKILL.md 里的路由表（真实内容节选）：

【来源：HOS_SKILL_WORKFLOW/S-07-HOS-IP-Writing/SKILL.md】

用 Mermaid 表示，这个路由就是一张决策图：

路由规则（SKILL.md 原文）：意图明确 → 直接激活；意图模糊 → 列出匹配子技能供用户选择；意图跨多个子技能 → 激活对应管线。

3.3 [IP-Context 摘要]：信息不丢失的"交接棒"

这是整个体系里我认为最聪明的设计。Markdown 技能没法做编程级状态管理，那怎么在子技能之间传信息？仓库的答案是三重传递机制（shared/context-schema.md 原文）：

1. 会话内传递：同一对话中 AI 记住之前子技能产出的核心信息
2. 文件传递：各子技能将产出写入约定路径，后续子技能读取
3. 显式摘要：切换子技能时输出 [IP-Context 摘要]，确保信息不丢失

摘要模板长这样（真实内容）：

[IP-Context 摘要]
- 项目名称: {project.name}
- 核心技术: {project.description}
- 创新点: {project.innovations}
- 技术栈: {project.tech-stack}
- 当前阶段: {当前子技能} → {下一个子技能}
- 传递产物: {具体产出文件列表}

【来源：HOS_SKILL_WORKFLOW/S-07-HOS-IP-Writing/shared/context-schema.md】

举个实际场景：你先用 patent 写完权利要求书，AI 会输出一段这样的摘要；切到 paper 写论文时，AI 直接读这段摘要，就把技术方案和创新点带过去了，连"我上次说过什么"都不用再重复。

过渡一下：明白了"统一"的价值，下一步就该看这套体系到底有哪些"模式"可用。六大模式我逐个讲——先给你一张全景表，再挑论文、专利、软著、博客、润色五个最常用的深入拆解，书籍模式因为和博客强相关，会在最后跟"成果转化"一起讲。

四、六大写作模式全景

本节核心收获： 6 个子技能各自的定位、触发条件、核心能力一览，以及"质量门禁"为什么是整套体系的分水岭。

4.1 六张身份证

4.2 每个模式都配了"质量门禁"

这是我认为它区别于普通模板的分水岭：仓库专门维护了 shared/quality-gates.md，每个子技能的每个阶段都卡验收标准。举几个真实的门禁例子：

• paper Stage 1：研究问题可用一句话表述；贡献点 3-5 个；目标投稿类型已确定
• patent Phase 2：独立权利要求包含所有必要技术特征；从属权利要求层次分明
• copyright Phase 2：软件说明书包含所有必需章节（引言/概述/环境/使用说明）
• blog Phase 4：平台格式适配完成；SEO 检查通过；标签/分类已设置
• review Phase 4：润色后文本通过自然度检查；原意保留

另有 5 条通用门禁适用于所有子技能：触发条件匹配、输入完整性、输出完整性、格式合规、无虚构内容。

写到这里我要强调一个反直觉的结论：质量门禁才是这个 Skill 最值钱的部分，而不是那些模板。 模板帮你"写出来"，门禁帮你"写对"。多数人用 AI 写作失败，卡的就是"写对"这一关。

4.3 四条跨技能管线（统一性的最终体现）

管线执行规则（README 原文）：

1. 按链路顺序依次激活子技能
2. 每个子技能完成后，输出 [IP-Context 摘要] 传递给下一个
3. 每个阶段必须通过对应的质量门禁才能进入下一阶段
4. 用户可在任意阶段暂停或修改

4.4 约定俗成的输出规范

shared/output-conventions.md 里还规定了全体系统一的"排版宪法"，这直接影响最终交付质量：

• 文件格式默认 Markdown（.md）；编码 UTF-8；换行 LF
• 标题层级从 ## 开始（# 保留给文档标题）
• 代码块必须标注语言（如 ```python）
• 中文排版：中英文之间加空格；全角标点；数字与中文之间加空格

顺手说一句：本文通篇其实就在执行这套规范——比如"AI 能做什么"里的空格、"HOS-IP-Writing 模块"的排版。写作的"体面"，藏在排版细节里。

五、论文模式：把"混乱的线性过程"变成"可控的五阶段系统"

本节核心收获： 掌握 paper 子技能的五阶段流程（Brainstorm→Architecture→Draft→Integration→Compression）、IMRAD 大纲、写作顺序、篇幅分配、项目初始化与质量门禁。

5.1 定位与触发

paper 子技能的官方一句话（SKILL.md 原文）：

将论文写作从「混乱的线性过程」转化为「可控的五阶段迭代系统」。

触发场景包括：开始写论文、“论文大纲”、“写 Introduction”、审稿回复、整理参考文献、投稿选择。同时明确声明不触发：非论文类写作（博客→blog，书籍→book，专利→patent）。

5.2 五阶段全流程

用 Mermaid 把论文写作流程画出来就是这样：

【注：此图为本人依据仓库五阶段流程整理，阶段名与仓库一致】

五个阶段的真实细节如下：

Stage 1: Brainstorm（头脑风暴）

• 用一句话描述研究问题；追问"你的方法与现有方法有什么不同？"；“读者读完论文后应该记住什么？”
• 产出研究问题陈述、核心贡献列表（3-5 点）、目标读者画像、初步 Related Work 方向
• 质量门禁：研究问题可用一句话表述；贡献点 3-5 个；目标投稿类型已确定

Stage 2: Architecture（架构设计）

• 基于 Brainstorm 产出生成 IMRAD 大纲；每个章节写 2-3 句要点摘要；设计图表清单
• 检查逻辑链：Introduction 的 gap → Methods 的方案 → Results 的验证 → Discussion 的解读

Stage 3: Draft（初稿撰写）

• 写作顺序是反直觉的：Methods → Results → Discussion → Introduction → Conclusion → Abstract
• 每个段落遵循"主题句 → 支撑证据 → 小结/过渡"
• Methods 要足够详细让他人复现；Results 只陈述事实不做解读；Discussion 才解读结果
• Introduction 按"漏斗结构"：大背景 → 具体问题 → 现有不足 → 你的贡献
• Abstract 最后写，五要素公式：背景(1句) → 问题(1句) → 方法(1-2句) → 结果(1-2句) → 意义(1句)

Stage 4: Integration（整合审查）

• 通读全文：Abstract 是否准确概括全文？Introduction 的 promise 是否被 Conclusion 兑现？
• 术语一致性、数学符号一致性、图表是否在正文中被引用和解读、引用格式统一
• 数学符号一致性抓的就是这类细节：比如 O(n2) 和 O(N2) 混用、R2（决定系数）忽而写"R-squared"、H2O 写成 H2O——同一概念必须同一符号，这是审稿人最常抓的"不严谨"信号
• 质量门禁：术语一致性 100%；图表全部在正文中引用；Abstract 准确概括全文

Stage 5: Compression（压缩精炼）

• 删除不增加信息量的文字；被动语态改主动语态（“We propose” 而非 “It is proposed”）；删除冗余副词（very, quite, rather, basically）；长句拆短句
• 篇幅门禁用公式表示就是：目标篇幅与实际篇幅的偏差不超过 10%：

• 英文每句 ≤ 25 词

小技巧：Compression 阶段不妨用可读性指标自查，比如平均句长、被动句占比（越低越好），甚至算一算 Flesch 可读性得分；中文写作则盯住"每段是否有冗余句"这一条就够用。

5.3 投稿类型适配表（仓库真实数据）

【来源：HOS_SKILL_WORKFLOW/S-07-HOS-IP-Writing/paper/SKILL.md】

5.4 IMRAD 大纲模板与篇幅分配

仓库的 paper/templates/paper-outline.md 给出了可直接套用的章节篇幅分配（这是很多新手不知道的"黄金比例"）：

5.5 项目初始化与进度跟踪（别跳过，这才是工程化）

paper/workflows/paper-writing-workflow.md 开篇就给了全流程时间表：

它还有一个"项目初始化文档"（templates/paper-project-init.md），要求你在动笔前先填：研究问题陈述、核心贡献、目标读者、Related Work 方向、投稿类型确认、项目时间线。先填表、再动笔，这一步治好了我多年的"提笔不知道写啥"。

进度跟踪用这张表（原文）：

5.6 审稿回复：一个最容易翻车但也最值钱的场景

这个模块的 paper/workflows/paper-review-revision.md 是我个人最欣赏的文件之一。它把"收到审稿意见"这件事拆成了六步：

收到审稿意见 → 情绪管理与初步分析 → 审稿意见分类 → 制定修改计划 → 执行修改 → 撰写 Response Letter → 最终检查与提交

其中几个细节特别实战：

• 先冷静 24 小时再动笔——“审稿意见是针对论文，不是针对你个人”
• 把意见分成五类：A 必须修改 / B 应该修改 / C 可以修改 / D 不同意 / E 误解
• Response Letter 结构固定：感谢 → 逐条回复 → 标注修改位置（页码/行号）
• 绝对不要做的五件事：忽略任何一条意见、使用对抗性语言、过度道歉、虚假承诺、回复中包含未修改的内容

踩坑案例（我亲历）：有次我急着回意见，把"礼貌反驳"写成了"硬刚"，直接怼"审稿人显然没读懂"。结果二审拖了四个月。后来按这套工作流的模板写，同样的观点换成：

“We thank the reviewer for raising this point. However, we respectfully disagree… because [reason with evidence].”

语气专业、证据在前、姿态放低，二审一次通过。同一句话，换个包装，结局完全不同。 这就是工作流模板的价值。

过渡：论文是"证明你厉害"，专利是"圈住你厉害"。前者要讲清楚，后者要护住地盘。下面看专利模式。

六、专利模式：权利要求书写得像产品说明书？那是因为没人教你结构

本节核心收获： 掌握专利四种产出物（交底书/权利要求书/说明书/摘要）的结构要点、三种专利类型的选择逻辑，以及 OA 回复的正确姿势。

6.1 官方定位

patent 子技能（SKILL.md 原文）：

从技术方案到完整专利文档，支持发明、实用新型、外观设计三种类型。符合国家知识产权局（CNIPA）格式规范。

触发词：写专利、申请发明专利、技术交底书、回复 OA、专利类型咨询。不触发：软著申请（→ copyright），论文写作（→ paper）。

6.2 三种专利类型速查（仓库真实数据）

【来源：HOS_SKILL_WORKFLOW/S-07-HOS-IP-Writing/patent/workflows/patent-types-guide.md】

特别注意两条容易被忽略的规则：

• 实用新型不能保护方法，只保护产品；无固定形状的物质（液体、气体、粉末）也不受保护
• 外观设计只保护外观不保护功能（GUI 可以保护，2021 年修改后还新增了局部设计）

类型选择的判断规则（原文）：

• 涉及方法/工艺/算法 → 发明专利
• 涉及产品结构改进、创新程度一般 → 实用新型专利
• 涉及产品外观设计 → 外观设计专利
• 创新程度高，需要长期保护 → 发明专利
• 需要快速获得授权 → 实用新型专利

还有一条组合策略很值钱：发明 + 实用新型同时申请——实用新型先授权（6-12 月）快速获得保护，发明专利后授权（2-3 年）获得更长期限，发明授权时放弃实用新型。需要申请时声明，且两件申请的权利要求不能完全相同。

6.3 专利写作的八步工作流

patent/workflows/patent-writing-workflow.md 给出的完整链路：

技术方案收集与分析 → 专利类型确认 → 发明交底书整理 → 权利要求书撰写 → 说明书撰写 → 摘要撰写 → 附图说明撰写 → 全文审查与优化

它连时间都给估算好了：总计约 5-10 小时，其中权利要求书 60-120 分钟，说明书 120-240 分钟。

第一步"技术方案收集与分析"要先回答四个问题（原文）：现有技术存在什么问题？本发明要解决什么技术问题？技术方案的具体组成和各部分关系？与现有技术相比区别特征是什么？——先搞清楚"我到底发明了什么"，再谈怎么写。

6.4 发明交底书：给代理人的"投名状"

交底书是发明人写给专利代理人的技术说明，结构如下（SKILL.md 原文）：

## 发明名称
## 技术领域
## 背景技术（现有技术及其不足）
## 发明内容
  - 要解决的技术问题
  - 技术方案（核心）
  - 有益效果
## 具体实施方式（结合附图）
## 附图说明

【来源：HOS_SKILL_WORKFLOW/S-07-HOS-IP-Writing/patent/SKILL.md】

质量门禁：技术问题、技术方案、技术效果三要素完整。

6.5 权利要求书：整份专利的灵魂

先看独立权利要求的法定句式模板（仓库模板原文）：

[主题名称]，其特征在于，包括：
[技术特征 A]；
[技术特征 B]；
...
[技术特征 N]。

从属权利要求：

根据权利要求 [X] 所述的 [主题名称]，其特征在于，所述 [引用特征] 进一步包括：
[附加技术特征]。

【来源：HOS_SKILL_WORKFLOW/S-07-HOS-IP-Writing/patent/templates/claims-template.md】

四大撰写原则（仓库原文）：

1. 清楚性原则：禁止"大约"“左右”“preferably"等模糊词汇；数值范围要写"10-20mm"而不是"10mm 左右”
2. 支持性原则：权利要求必须得到说明书支持，不得超出说明书公开范围
3. 层次性原则：独立权利要求 = 最大合理保护范围；从属权利要求逐层缩小，形成多层防线
4. 单一性原则：一项权利要求只描述一个发明构思

再给你一个仓库里的正反对照（原文），这就是我朋友那个坑的教科书级解释：

❌ 错误示例：一种装置，包括处理模块。
   （"处理模块"过于上位，可能得不到说明书支持）
✅ 正确示例：一种装置，包括处理器，所述处理器被配置为执行 [具体功能]。

❌ 错误示例：所述部件的长度约为 10cm。
   （"约"字导致范围不清楚）
✅ 正确示例：所述部件的长度为 10cm。或所述部件的长度为 9-11cm。

6.6 说明书五部分与摘要

说明书必须五部分齐全（SKILL.md 原文）：

1. 技术领域：一句话说明所属技术领域
2. 背景技术：描述现有技术及其不足（客观评价，不贬低）
3. 发明内容：技术问题 + 技术方案 + 有益效果
4. 附图说明：各附图名称和简要说明
5. 具体实施方式：结合附图详细描述，提供具体实施例

摘要门禁：≤ 300 字，包含技术问题+方案+效果；选择最能说明技术方案的摘要附图。

6.7 OA 回复：决定专利生死的 4 个月

发明专利从申请到授权往往要 2-3 年，中间大概率收到审查意见通知书（OA）。patent/workflows/oa-reply-workflow.md 给出的关键信息：

注意：逾期未答复的，申请将被视为撤回。

驳回理由六大类（对应法条）：

• A 新颖性（专利法第 22 条第 2 款）
• B 创造性（第 22 条第 3 款）——最常见的战场
• C 权利要求不清楚（第 26 条第 4 款）
• D 权利要求得不到说明书支持（第 26 条第 4 款）
• E 说明书公开不充分（第 26 条第 3 款）
• F 修改超范围（第 33 条）

创造性驳回最经典的应对是三步法：第一步重新确定区别技术特征；第二步重新确定实际解决的技术问题；第三步论证不存在技术启示。外加一条永远的王道——补充实验数据证明意想不到的技术效果。

常见的五个坑（原文）：遗漏驳回理由、修改超出范围、答复过于笼统、情绪化表达、错过答复期限。

过渡：专利是"技术方案"的保护，软著是"代码表达"的保护。这两者经常被搞混，很多开发者以为有 GitHub 仓库就有版权，其实要拿到登记证书，材料规范程度远超你的想象。下面看软著模式。

七、软著模式：输入一个 Repo URL，生成一套申请材料

本节核心收获： 理解软著申请材料的五阶段生成流程、软件名称规范、代码文档"前 30 页 + 后 30 页"规则、时间规划，以及最常见的驳回原因。

7.1 官方定位

copyright 子技能（SKILL.md 原文）：

从代码仓库自动生成符合中国版权保护中心要求的软著申请材料。输入 Repo URL 即可产出软件说明书、源代码文档等。

触发词：申请软著、从 GitHub 仓库生成软著文档、生成软件说明书、准备软著材料。不触发：专利申请（→ patent），论文写作（→ paper）。

7.2 五阶段工作流

copyright/workflows/copyright-workflow.md 把整个流程画成五个阶段：

准备（需求确认/信息收集/环境准备）→ 分析（仓库分析/代码提取/技术识别）
→ 生成（文档生成/代码整理/截图准备）→ 审核（内容审核/格式检查/材料整合）
→ 提交（填写申请/提交材料/进度跟踪）

7.3 时间规划（仓库给的估算）

7.4 仓库分析阶段到底分析什么

Phase 1 的真实操作步骤：

1. 读取仓库 URL 或本地路径
2. 提取 README.md 内容
3. 分析项目结构（目录树）
4. 识别技术栈（package.json / requirements.txt / pom.xml 等）
5. 提取核心模块和功能列表
6. 识别关键算法和技术亮点

质量门禁：技术栈识别完成；核心模块列表 ≥ 3 个。

7.5 软件说明书必备章节

Phase 2 要求生成 9 大章节（SKILL.md 原文）：

1. 引言（编写目的、背景）
2. 软件概述（功能、性能）
3. 运行环境（硬件、软件）
4. 使用说明（安装、配置、操作）
5. 模块设计说明
6. 功能详细说明
7. 关键算法描述
8. 数据库设计
9. 流程图说明

辅助文档还有创新点总结、截图指南、材料清单——模板目录里我数了真实文件：software-info、software-description、module-design、function-description、algorithm-description、database-design、flowchart-description、innovation-points、screenshot-guide、application-materials，一个不落。

7.6 格式规范（决定生死的细节）

仓库给出的硬性要求（copyright/SKILL.md）：

• 软件名称规范：全称格式 XXX软件 或 XXX系统；简称不能用英文缩写；版本号 VX.X
• 说明书页数：一般 10-60 页
• 代码文档：前 30 页和后 30 页（每页 50 行）
• 字体字号：宋体小四或仿宋_GB2312 小四

7.7 常见驳回原因（对照自查）

1. 软件名称不规范
2. 功能描述过于简单
3. 缺少必要章节
4. 截图不清晰或缺失
5. 代码文档格式不符合要求

7.8 风险控制表（仓库原文）

踩坑案例：我曾给一个 CLI 工具做软著，AI 生成的软件名称用了项目代号"OSS-Scanner"，被以"简称不能使用英文缩写"为由退回。改成"开源漏洞扫描系统 V1.0"后一次通过。这类细节，纯靠人肉记忆根本防不住，只有把它写进门禁规则里才靠得住。

八、博客模式：一篇内容，五个平台

本节核心收获： 掌握博客六阶段流程（需求→大纲→正文→平台适配→SEO→输出）、五种标题类型、SEO 检查清单、SEO 报告结构，以及多平台格式差异。

8.1 官方定位

blog 子技能（SKILL.md 原文）：

一篇内容，多平台适配。支持 CSDN、掘金、知乎、Medium、Dev.to 的格式自动转换与 SEO 优化。

8.2 六阶段流程

blog/workflows/blog-writing-workflow.md 的完整链路：

需求分析 → 大纲生成 → 用户确认 → 正文写作 → 平台适配 → SEO 优化 → 最终输出

需求分析阶段必须先确认六件事：文章主题、目标平台、文章类型（博客/教程/案例研究）、目标读者、核心要点、可选的文章长度/代码示例/图表需求/参考资料。

写作顺序也有讲究：引言 → 背景 → 核心内容 → 实战演示 → 总结。段落规范：每段不超过 5 行（移动端友好）；重要信息放在段首；代码块必须标注语言且可运行；图表优先用 Mermaid。

8.3 五种标题类型（直接可抄）

仓库给出的标题生成规则，就是爆款标题的五个套路：

1. 数字型：7 个方法掌握 Python 异步编程
2. 问题型：如何高效使用 Python 异步编程？
3. 指南型：Python 异步编程完整指南
4. 对比型：同步 vs 异步：Python 并发编程实战
5. 清单型：Python 异步编程最佳实践清单

每次生成 3-5 个候选标题等用户确认。

8.4 SEO 检查清单（仓库真实标准）

• 关键词：核心关键词出现在标题 + 第一段；密度 1%-3%；避免堆砌
• 标题：长度 15-25 字；包含核心关键词
• Meta description：120-160 字；包含关键词
• 结构：H1 只能有 1 个；标题层级不跳级
• 图片：每张图有 alt 描述，alt 包含关键词

用公式表示关键词密度的要求就是：

【注：此公式为本文件者依据仓库"关键词密度 1%-3%"要求整理，具体计算口径以各 SEO 工具为准】

SEO 优化完成后还要输出一份报告（blog/workflows/blog-writing-workflow.md 原文结构）：

## SEO 优化报告
### 关键词分析
- 核心关键词：{{关键词}}
- 关键词密度：{{百分比}}
### 标题评估
- 标题长度：{{字数}}
- 评分：{{分数}}/100
### 描述评估
- Meta description 长度：{{字数}}
### 结构评估
- H1 数量：{{数量}}
### 综合评分
- 总分：{{分数}}/100
- 等级：{{优秀|良好|一般|较差}}
### 优化建议
1. {{建议1}}
2. {{建议2}}

【来源：HOS_SKILL_WORKFLOW/S-07-HOS-IP-Writing/blog/workflows/blog-writing-workflow.md】

8.5 多平台适配：格式差异比你想象的大

【来源：HOS_SKILL_WORKFLOW/S-07-HOS-IP-Writing/blog/SKILL.md】

多平台适配的输出命名规则（仓库 shared/output-conventions.md）：

{date}-{slug}.md              # 原始版本
{date}-{slug}-{platform}.md   # 平台版本
{slug}-seo-report.md          # SEO 报告

博客文件头（front matter）模板（原文）：

---
title: "{标题}"
date: {YYYY-MM-DD}
tags: [{标签1}, {标签2}]
platform: {目标平台}
---

【来源：HOS_SKILL_WORKFLOW/S-07-HOS-IP-Writing/shared/output-conventions.md】

发布阶段还有一套"发布建议"：最佳发布时间、发布顺序（先主平台后分发平台）、推广建议、互动建议（及时回复评论、关注数据反馈）。写完只是第一步，发布策略决定阅读量。

过渡：内容写得再多，如果一眼被看出"AI 味"，前面的功夫全白费。压轴登场的润色模式，就是专门干这个的。

九、AI 润色模式：去 AI 味，是每个写作者的新刚需

本节核心收获： 掌握去 AI 味的四类痕迹清单、四种语境匹配策略、学术化改写对照表、四阶段流程，以及 review 的三段式输出格式。

9.1 官方定位

review 子技能（SKILL.md 原文）：

去除 AI 写作痕迹，让文本更自然、更专业。支持学术论文、技术博客、商业文档等多种语境。

关键边界：不触发从零写作（→ paper/blog/book），本技能专注于已有文本的润色。

9.2 四类 AI 写作痕迹（仓库原文）

【来源：HOS_SKILL_WORKFLOW/S-07-HOS-IP-Writing/review/SKILL.md】

9.3 语境匹配策略

9.4 学术化改写对照（HOS 中文扩展）

• 口语化 → 学术用语：“用” → “采用”；“做” → “实施”
• 引用格式规范化：APA / MLA / Chicago / GB/T 7714
• 段落结构改进：主题句 → 支撑句 → 结论句
• 论证逻辑强化

9.5 四阶段流程与三段式输出

文本分析（识别类型）→ 问题诊断（标记填充词/被动语态）→ 润色执行（去套路/转主动/具体化）→ 质量验证（连贯性/专业性/自然度/原意保留）

每次润色固定输出三部分：

1. 润色后文本（完整输出）
2. 修改说明（逐条列出修改内容及理由）
3. 质量评分（1-10 分，含评分依据）

我按这个格式演示一段（示意，非仓库原文）：

【润色前】值得注意的是，该算法在性能上表现很好，能够显著提升系统效率。
【润色后】在三个公开数据集上，该算法的吞吐量较基线方法平均提升 18.2%。
【修改说明】
  - 删除填充短语"值得注意的是"
  - "表现很好"→ 具体指标"吞吐量较基线平均提升 18.2%"
  - "提升系统效率"→ 明确场景与量级
【质量评分】8/10（原意保留完整，具体化充分；若补充数据集名称可再提分）

9.6 四大约束

1. 保留原意：润色不改变原文核心观点
2. 适度改写：避免过度润色导致失去作者风格
3. 语境一致：保持全文语体风格统一
4. 渐进改进：优先处理最明显的 AI 痕迹

到这儿，六大模式里最常用的五个已经讲完了（书籍模式在下一节跟着"成果转化"一起讲，因为它和博客的联动才是精髓）。最后也是最值得你记住的一节：这套体系真正的王炸，不是任何一个单一模式，而是把同一个研究成果复制成多种知识资产的能力。

十、如何把一个研究成果转换成多个知识资产（本文最值得收藏的一节）

本节核心收获： 学会用"知识产权保护"“学术全流程”“技术影响力”"内容工厂"四条管线，让一次研究产出论文、专利、软著、博客、书籍五重资产，并理解"先专利后论文"的新颖性红线。

10.1 一次研究，五种产出

先上全篇最重要的一张 Mermaid 图：

这张图的含义：同一个研究，输入一次，通过四条管线分别流向五类资产。

10.2 管线一：知识产权保护（patent → copyright → paper）

pipelines/ip-protection.md 开篇就划了一条红线：

重要原则：先专利后论文。论文发表会破坏专利的新颖性，必须在专利申请提交后再发表论文。

执行链路：

1. patent：收集技术方案 → 确定专利类型（发明/实用新型）→ 生成交底书/权利要求书/说明书/摘要
2. copyright：读取专利技术方案 → 分析代码仓库（如有）→ 生成软著材料
3. paper：确认专利已提交（关键检查点） → 写论文时不泄露专利核心权利要求内容 → 重点阐述方法论和实验验证 → Related Work 中可引用自己的专利

这条管线最值钱的是三个风险提示：

1. 新颖性风险：论文发表前必须确保专利申请已提交
2. 内容泄露风险：论文中避免披露专利权利要求的核心技术特征
3. 时间线风险：发明专利申请到授权通常 2-3 年；论文可在提交申请后约 6 个月发表【需核实：原文表述为"专利申请到授权通常需要 2-3 年（发明专利），论文可在提交申请后 6 个月发表"】

10.3 管线二：学术全流程（paper → review → 投稿）

链路：paper（Stage 1-5）→ review（学术润色）→ 投稿。

润色环节的验收标准非常硬：AI 填充词清零；主动语态 > 80%；术语一致。投稿准备阶段按目标类型查篇幅、模板、引用风格，生成投稿检查清单。

10.4 管线三：技术影响力（blog → book → review）

链路：blog（系列文章，建议 5-15 篇）→ book（整理成书）→ review（全书润色）。

这个思路特别适合技术人做个人品牌：先发系列博客试水，验证主题有读者；攒够了就整理成书；出版前统一润色。

说到 book，顺手把书籍模式补全（book/SKILL.md 真实内容）：

每章的标准结构（原文）：章节引言（问题引入、学习目标）→ 理论讲解 → 代码示例 → 实战案例 → 常见问题（FAQ/陷阱提示）→ 本章小结（要点回顾）→ 练习题（选择题、编程题，分难度）。

博客转书流程（原文五步）：

1. 读取所有博客文章
2. 分析主题，重新组织为书籍目录
3. 补充章节过渡和引言
4. 统一术语和风格
5. 生成前言和附录

出版方式选择（仓库给的对比）：

10.5 管线四：内容工厂（blog 多篇 → review → book）

批量生产内容的链路：确定主题矩阵（核心主题 1 篇深度长文 + 相关主题 3-5 篇不同角度 + 实践主题 1-2 篇教程/案例）→ 逐篇生成 → 统一润色 → 合集整理。

它还能和 HOS 生态里的 Fuck-Demo 内容工业流水线联动：Fuck-Demo 产出的 PPT 脚本、视频脚本、项目介绍可以作为 blog 的输入素材，进一步扩展成：

Fuck-Demo (内容包) → blog (适配发布) → review (统一润色) → book (合集)

10.6 共享上下文：这一切能串起来的根本

为什么一次输入能流向五类资产？因为 shared/context-schema.md 定义了三个字段域：

project（项目信息）：name、description（200 字以内）、tech-stack、innovations（3-5 个）、code-repo（仓库 URL） author（作者信息）：name、affiliation、email、bio（100 字以内） output（输出偏好）：target-venues、language（zh/en）、style（academic/technical/casual）

各子技能的读写权限（原文）：

这套设计的妙处：创新点（innovations）和项目描述（description）是"母体"，专利的独立权利要求、论文的贡献列表、软著的功能说明、博客的核心论点、书籍的章节大纲，全都从这个母体派生。写一次，复用五次。

用公式表达复用度就是：

其中

是共享上下文直接派生的内容量，

是最终五类产出的总内容量。共享上下文设计得越规范，复用度越高。【注：此公式为本人基于仓库共享上下文机制提炼的分析指标，非仓库原文】

10.7 生态集成：它不是孤岛

shared/hos-integration.md 列出了与 HOS 生态其他模块的集成点，举例几个：

• 代码示例超过 20 行 → 调 HOS-Sec-Engine 扫描安全漏洞、硬编码密钥
• 写论文 Results → HOS-Silly-Mock 检测实验数据是否为用户真实提供
• 生成代码示例 → HOS-Vibe-Guard 检测是否属于"表面可运行但无实质逻辑"的 Vibe Coding
• 博客完成后 → hos-skills 运营模块适配到多平台、纳入周报、检查品牌一致性

这套"写作 + 安全 + 质检"的联动，才是企业级写作技能该有的样子。

十一、常见问题 FAQ（大家问得最多的五个）

本节核心收获： 一次讲清安装、原创性、专利软著关系、人工审核、生态边界五个高频疑问。

Q1：这套 Skill 需要写代码吗？ 完全不需要。整个 S-07-HOS-IP-Writing 是纯 Markdown 文件，AI IDE（Claude Code / Cursor / TRAE / Codex / Gemini CLI）能自动识别加载。安装方式仓库给了四种：Claude Code 自动识别、TRAE 技能市场安装、Cursor 导入 S-07-HOS-IP-Writing 目录、或者 git clone 后进入目录使用。

Q2：AI 生成的内容算原创吗？会不会被查重查出来？ 要分两层看。内容层面，仓库第一条约束就是"无虚构内容：不编造数据、引用、代码、实验结果"，并要求"生成文档需人工审核"。AI 痕迹层面，这正是 review 子技能存在的意义——填充短语清除、主动语态转换、模糊量词具体化，都是降低"AI 味"的硬手段。但归根结底：Skill 是工具，学术诚信责任永远在作者本人。

Q3：专利和软著能同时申请吗？ 能，而且这就是"知识产权保护"管线（patent → copyright → paper）设计的初衷。但注意顺序红线：先专利，后论文。论文一旦公开会破坏专利的新颖性；软著则与专利不冲突，可以并行。

Q4：我用它写完专利，能直接提交 CNIPA 吗？ 仓库明确写了法律免责声明："生成的专利文档仅供参考，正式提交前建议咨询专利代理人。"尤其是权利要求书和 OA 回复，策略性极强，AI 能帮你把结构和格式做到位，但保护范围怎么定、怎么和审查员博弈，建议让专业人士把关。

Q5：它和 HOS 生态里其他模块什么关系？ S-07-HOS-IP-Writing 是 HOS_SKILL_WORKFLOW 仓库的第 7 个模块（S-07），专司"知识产权写作"；同仓库还有 Sec-Engine（安全测试）、Silly-Mock（反假数据）、Vibe-Guard（防 Vibe Coding 退化）、Fuck-Demo（内容工业流水线）等。写作模块通过与它们集成获得安全扫描、数据真实性校验、代码质量护栏等能力。

本文核心观点回顾

1. 生成文字 ≠ 专业写作。AI 的强项是"接 token"，论文/专利/软著/博客靠的是结构、证据、格式、门禁——裸奔 AI 的五大硬伤（结构失效、证据缺失、表达失准、格式违例、痕迹过重）必须靠 Skill 兜底。
2. HOS-IP-Writing 是一个写作操作系统，不是提示词合集：六大子技能 + 智能路由 + 共享上下文（project/author/output）+ 四条跨技能管线 + 全程质量门禁。
3. 质量门禁比模板更值钱。模板帮你"写出来"，门禁帮你"写对"。
4. 专利的命门在权利要求书：独立权利要求做宽、从属权利要求层层设防；禁止"大约/左右"；说明书五部分齐全；摘要 ≤ 300 字。
5. 软著的死穴在格式细节：名称不能用英文缩写、代码前 30 页 + 后 30 页每页 50 行、字体宋体小四。
6. 去 AI 味是刚需：填充短语直接删、被动语态转主动、模糊量词换数据、按语境匹配策略。
7. 一次研究，五种资产：知识产权保护管线（patent→copyright→paper）教你先专利后论文，别让论文毁掉专利新颖性；技术影响力管线（blog→book→review）教你把博客变成书。
8. 上下文共享是复用率的源泉：创新点、项目描述写一次，五类产出各取所需。"先专利后论文"这条红线，值得刻在每一个研究者的工位上。

金句二：写作是手艺，Skill 是把手艺变成工艺。

学完本文你能做什么

• 在 Claude Code / Cursor / TRAE 里导入 S-07-HOS-IP-Writing 目录（仓库 README 给了三种安装方式：Claude Code 自动识别、TRAE 技能市场安装、Cursor 导入目录），或者 git clone https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW.git 后进入 S-07-HOS-IP-Writing 目录使用
• 用 paper 子技能按五阶段流程启动下一篇论文，自觉卡住"贡献点 3-5 个"“篇幅 ±10%”"每句 ≤ 25 词"这些门禁
• 用 patent 子技能把技术方案走完"交底书 → 权利要求书 → 说明书 → 摘要"，并在收到 OA 后按三步法回复
• 把你的 GitHub 仓库 URL 丢给 copyright，生成一套符合版权保护中心要求的软著材料
• 用 blog 子技能写一篇发 CSDN 的文章，套用五种标题类型 + SEO 检查清单，再让 review 去一遍 AI 味
• 最值得做的：把"知识产权保护"管线跑一遍——先专利、再软著、后论文，让同一个研究产出三重资产

如果你想亲手把这套东西用起来，去 GitHub 搜 HOS_SKILL_WORKFLOW（仓库地址：https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW），进入 S-07-HOS-IP-Writing/ 目录，README、SKILL.md、六个子技能的 workflows/templates 全是开箱即用的 Markdown。觉得有用，顺手点个 Star，让更多被"AI 写专利写成产品说明书"折磨过的人看到它。

参考链接：

• 主要来源：HOS_SKILL_WORKFLOW 仓库 → https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW
• S-07-HOS-IP-Writing 模块 README → https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW/tree/main/S-07-HOS-IP-Writing
• 论文写作集成来源：SNL-UCSB/paper-writing-skill → https://github.com/SNL-UCSB/paper-writing-skill
• 论文写作集成来源：kgraph57/paper-writer-skill → https://github.com/kgraph57/paper-writer-skill
• 润色集成来源：stephenturner/skill-deslop → https://github.com/stephenturner/skill-deslop

附录（Appendix）：

• 附录 A：本文引用的仓库文件清单（按真实目录结构整理）：
  • S-07-HOS-IP-Writing/README.md、SKILL.md、ATTRIBUTION.md
  • shared/context-schema.md、quality-gates.md、output-conventions.md、hos-integration.md
  • pipelines/academic-paper.md、tech-influence.md、ip-protection.md、content-factory.md
  • paper/SKILL.md、paper/workflows/paper-writing-workflow.md、paper/workflows/paper-review-revision.md、paper/templates/paper-outline.md、paper/templates/paper-project-init.md、paper/templates/paper-quality-checklist.md、paper/templates/paper-section-templates.md
  • patent/SKILL.md、patent/workflows/patent-writing-workflow.md、patent/workflows/patent-types-guide.md、patent/workflows/oa-reply-workflow.md、patent/templates/claims-template.md、patent/templates/description-template.md、patent/templates/abstract-template.md、patent/templates/invention-disclosure.md、patent/templates/drawings-description.md、patent/templates/oa-reply-template.md
  • copyright/SKILL.md、copyright/workflows/copyright-workflow.md、copyright/workflows/repo-analysis-workflow.md、copyright/workflows/document-generation-workflow.md、copyright/templates/（software-info、software-description、module-design、function-description、algorithm-description、database-design、flowchart-description、innovation-points、screenshot-guide、application-materials）
  • book/SKILL.md、book/workflows/book-writing-workflow.md、book/workflows/chapter-development-workflow.md、book/workflows/publishing-workflow.md
  • blog/SKILL.md、blog/workflows/blog-writing-workflow.md、blog/workflows/platform-adaptation-workflow.md、blog/workflows/seo-optimization-workflow.md、blog/templates/（blog-post-template、technical-tutorial、case-study、platform-csdn、platform-juejin、platform-zhihu、platform-medium、platform-devto、seo-checklist）
  • review/SKILL.md
• 附录 B：任务式自查清单（你可以拿着它检查一篇 AI 产出的专业文档）：
  • 论文：研究问题一句话可说清；贡献点 3-5 个；IMRAD 齐全；篇幅 ±10%；术语 100% 一致
  • 专利：独立权利要求无模糊用语；从属权利要求层次分明；说明书五部分完整；摘要 ≤ 300 字
  • 软著：软件名称含"软件/系统"后缀；代码前后各 30 页每页 50 行；说明书画上 9 个章节
  • 博客：标题含关键词；关键词密度 1%-3%；H1 唯一；代码可运行
  • 通用：无虚构数据/引用；无 AI 填充短语；主动语态为主
• 附录 C：脚注
  • [^1]：HOS-IP-Writing 模块版本 2.0.0，创建于 2026-07-21，最后更新 2026-07-26，出自仓库 README.md 的"许可证"一节。

关键词： HOS-IP-Writing, AI Skill, 知识产权写作, 论文写作, 专利申请, 软著申请, 博客写作, AI 润色

在这里插入图片描述