specification-writing

说明书撰写：逐节撰写专利说明书

每次审查前，请遵循可选审查者： 通过规范的辅助程序解析器解析调用 → .aris/reviewer.json → Codex 默认设置（全新的原生审查者）， 并通过 reviewer_route.py 保留此审查环节的层级、全新上下文、源文件／图像输入和确定性门控。 下方的 Codex 示例／固定配置仅适用于 backend=codex；其他路由使用各自的首次调用／回复约定。保存路由和实际返回的身份； 无法使用的选择标记为 REVIEW_UNAVAILABLE。根据实际的系列／完成情况／范围对接受情况分类。 将调用中的审查者／模型／推理强度覆盖值传递给包含审查者的子流程。生成工作器保持不变。

根据以下内容撰写专利说明书：$ARGUMENTS

此流程改编自 /paper-write，用于撰写专利说明书。说明书用于支持权利要求——它不是论文。

常量

• REVIEWER_MODEL = gpt-6-astra — 用于评估说明书质量的外部审查者
• JURISDICTION = "auto" — 继承自流水线，或根据参数检测；CN、US、EP、ALL
• OUTPUT_FORMAT = "markdown" — Markdown 草稿；通过 /jurisdiction-format 转换为提交格式
• OUTPUT_DIR = "patent/" — 基础输出目录
• LANGUAGE = "auto" — 根据司法辖区自动选择：CN->中文，US/EP->英文

输入

1. patent/CLAIMS.md — 已起草的权利要求（主要来源）
2. patent/INVENTION_DISCLOSURE.md — 发明分解
3. patent/PRIOR_ART_REPORT.md — 用于背景技术部分
4. 用户提供的图（如有）

共享参考资料

加载 ../shared-references/patent-writing-principles.md，以了解说明书撰写规则、语言指南和附图标记约定。 根据司法辖区加载 ../shared-references/patent-format-cn.md、patent-format-us.md 或 patent-format-ep.md。

工作流

步骤 1：初始化说明书结构

创建输出目录和各节文件：

patent/specification/
├── title.md
├── technical_field.md
├── background.md
├── summary.md
├── drawings_description.md
├── detailed_description.md
└── abstract.md

步骤 2：撰写标题（发明名称）

• 必须符合最宽泛的权利要求范围
• 不得包含商标，也不得使用“改进的”“新的”或“新颖的”
• CN 格式：“一种[领域]的[技术主题]”或“[领域]的[技术主题]装置”
• US/EP 格式：“用于[目的]的[技术主题]”或“[技术主题]及其方法”
• 保持简洁（CN：通常少于 25 个字符；US：少于 500 个字符）

步骤 3：撰写技术领域（技术领域）

用 1-2 个段落说明技术领域：

• “本发明涉及[宽泛领域]，更具体地说，涉及[具体领域]。”
• CN：“本发明涉及[技术领域]，具体涉及[具体领域]。”

步骤 4：撰写背景技术（背景技术）

这不是文献综述，而是直接引出要解决的问题。

结构：

1. 描述最接近的现有技术方案（2-3 个段落）
2. 指出现有技术方案的具体技术缺陷
3. 缺陷必须是技术方面的，而非商业或社会方面的
4. 不得承认现有技术“更优”或“更好”
5. 除非特定专利号属于已知现有技术，否则不得引用；美国的引用应放在 IDS 中，中国的引用应放在背景技术部分

CN 格式：以“背景技术”部分描述现有技术及其缺陷。

步骤 5：撰写发明内容

分为三个部分，直接对应 INVENTION_DISCLOSURE.md：

技术问题（要解决的技术问题）：

• 陈述根据背景技术缺陷得出的问题
• 中文：“本发明要解决的技术问题是……”

技术方案：

• 说明本发明如何解决该问题
• 必须为所有权利要求要素提供支持
• 从最宽泛的权利要求开始，描述核心发明构思
• 中文：“为解决上述技术问题，本发明采用的技术方案是：……”
• 不得包含公式、数学推导或电路模型——这些内容应放在具体实施方式中，而非发明内容中

有益效果：

• 根据结构或技术特征推导出的益处（定性推理）
• 中文：“本发明的有益效果是：……”
• 不得包含具体数值结果（例如“检测限 70μm”“响应时间 105ms”）——这些属于实验结果，而非发明的固有属性
• 从结构角度阐述优点：“由于采用了……结构，因此具有……效果”

步骤 6：撰写附图说明

如果用户提供了附图，则调用 /figure-description 作为子技能：

/figure-description "patent/figures/"

如果用户未提供附图，则根据权利要求说明应有哪些附图。

格式：

• 中文：“图1是……的示意图；图2是……的流程图；”
• 美式英语：“FIG. 1 is a block diagram showing...; FIG. 2 is a flowchart illustrating...”

步骤 7：撰写具体实施方式

调用 /embodiment-description 作为子技能：

/embodiment-description "patent/CLAIMS.md"

本节必须：

• 描述至少一个带有附图标记的完整实施例
• 使本领域普通技术人员能够制造并使用本发明
• 通过明确描述支持每一项权利要求要素
• 包含变型和替代方案，以便对权利要求作更广泛的解释

步骤 8：撰写摘要

各司法管辖区的字数限制：

司法管辖区	字数限制	备注
CN	300 个词（汉字）	包含最具代表性的权利要求引用
US	150 个词（2500 个字符）	便于高效检索，不使用法律用语
EP	约 150 个词	不得陈述优点或价值

摘要应概述：

1. 技术领域
2. 要解决的问题
3. 技术方案（核心特征）
4. 主要优点

步骤 9：核实权利要求支持情况

核实说明书是否支持每一项权利要求要素：

权利要求	要素	说明书章节	段落	附图标记
1	步骤 a	detailed_description	¶3	202
1	步骤 b	detailed_description	¶4	204
X	组件 A	detailed_description	¶2	102

如果任何要素缺少支持，请在继续之前补充必要描述。

步骤 10：由新 Agent 审查（默认采用同一申请族的临时申请）

通过专用 Codex 审查 Agent，以 xhigh 推理级别调用 REVIEWER_MODEL：

先解析此审查者配置项；以下是 backend=codex 示例。

spawn_agent:
  model: gpt-6-astra
  reasoning_effort: xhigh
  message: |
    You are a patent examiner reviewing a specification for completeness.
    CLAIMS: [all claims]
    SPECIFICATION: [all specification sections]

    Check for:
    1. Written description support: Does every claim element have explicit or inherent support?
    2. Enablement: Can a POSITA practice the invention from this specification?
    3. Consistency: Do reference numerals match across figures and specification?
    4. Language quality: Any subjective terms, relative terms without definition, or result-to-be-achieved language?
    5. Missing embodiments: Are there claim features that need additional embodiments?
    6. Background deficiencies: Are they technical and specific enough?

步骤 11：输出

所有说明书章节均位于 patent/specification/。

摘要文件：patent/specification/SPECIFICATION_INDEX.md，包含：

## Patent Specification

### Sections
| Section | File | Word Count | Status |
|---------|------|-----------|--------|
| Title | title.md | | Complete |
| Technical Field | technical_field.md | | Complete |
| Background | background.md | | Complete |
| Summary | summary.md | | Complete |
| Drawings Description | drawings_description.md | | Complete |
| Detailed Description | detailed_description.md | | Complete |
| Abstract | abstract.md | | Complete |

### Claim Support Status
| Claim | Elements Supported | Elements Missing |
|-------|-------------------|-----------------|
| 1 | All | None |
| X | All | None |

关键规则

• 说明书为权利要求提供支持，而非反过来。每一项权利要求要素都必须有支持。
• 术语应保持一致——同一概念始终使用相同词语。
• 不得包含实验结果、准确度指标或实证评估。
• 不得使用主观措辞（“优秀”“令人惊讶”“更优”）。
• 附图标记必须保持一致：同一组件在任何位置都使用相同标记。
• 背景技术部分应描述具体缺陷，而非笼统地提出“需要改进”。
• 多个实施例有助于强化说明书，但并非总是必需。
• 处理大型文件：如果 Write 操作失败，则使用 Bash cat <<'EOF' heredoc 重试。
• 如果当前 Codex 主机不支持委派审查，请停止并要求用户启用 Codex Agent 支持后再继续。