算法与软件类发明交底书格式规范
本规范沉淀自参考材料中的技术交底书模板、算法/调度方法类样本和官方说明书/权利要求书模板。 适用于软件、算法、Agent 系统、调度优化、状态表示、特征提取、上下文编排、鉴权、记忆和文件系统等以代码实现为主的发明方案。
一、核心结论
算法与软件类技术交底书应当更接近“说明书前置稿”，而不是“代码实现盘点”。
默认正文主线为：
方案基本信息
技术领域
背景技术
发明内容
附图说明
具体实施方式
技术效果
替代实施方式
代码证据摘要与附录索引
待研发 / 代理师确认事项其中“代码证据摘要与附录索引”用于保留可追溯性，但不应进入正文核心位置。
二、技术交底书模板抽取
参考材料中的通用技术交底书模板实际只要求四类核心信息：
- 背景：要解决什么问题；现有方案是什么；现有方案有什么缺点；为什么需要新的方案。
- 发明要点：核心想法是什么；采用本方案有什么优势；实现原理是什么。
- 详细描述：用文字、框图、流程图描述方案如何工作、如何实现；说明书应具体，并尽量提供多个实施例。
- 替代实现：针对详细描述部分，是否存在其他方式实现同样发明目的。
在 code2patent 中，这四类信息应映射为：
| 交底书模板字段 | code2patent 输出位置 |
|---|---|
| 背景 | 技术领域 + 背景技术 |
| 发明要点 | 发明内容中的技术问题、总体方案、核心创新点 |
| 详细描述 | 具体实施方式中的步骤 S1...Sn、输入输出、状态/数据流、参数和实施例 |
| 替代实现 | 替代实施方式、优选实施方式、待确认事项 |
三、算法类说明书结构
算法、软件和调度方法类样本通常采用以下说明书结构：
- 技术领域
- 用一句话写明所属领域和具体方向。
- 示例方向：车间调度、智能体运行时、动态上下文组装、会话鉴权、文件系统隔离、记忆召回等。
- 背景技术
- 先写现有系统或现有技术路线。
- 再写复杂场景下的约束、瓶颈或不足。
- 最后自然引出“如何解决某个具体技术问题”。
- 发明内容
- 先写本发明为解决什么问题提出什么方法。
- 再给出总体步骤 S1...Sn。
- 再给出进一步限定，例如关键状态、特征向量、约束、模型、计算方式、更新方式。
- 最后写技术效果。
- 附图说明
- 至少建议流程图或系统框图。
- 算法类方案优先建议：整体流程图、数据/状态流图、模型结构图、时序图、效果对比图。
- 具体实施方式
- 用一个可理解的示例场景展开。
- 逐步说明输入、初始化、核心计算、判断/更新、输出。
- 对关键步骤补充参数、状态、数据结构、触发条件、边界条件和替代实现。
四、架构与实现方式的转译规则
代码项目的架构必须理解，但不应按工程模块原样展示。参考样稿中的“异构图模型”“两阶段进化策略”“多情景下界计算框架”等写法，本质上是在描述技术对象、关系、状态、动作和时序，而不是描述用了哪些代码模块。
将代码架构转译为说明书语言时，按以下顺序抽取：
- 技术对象
- 系统处理的对象是什么，例如会话、任务、工序、机器、AGV、文件视图、候选解、上下文片段。
- 对象关系
- 对象之间如何连接、约束或协同，例如节点-边关系、前后序关系、权限链、候选关系、父子任务关系。
- 状态表示
- 哪些状态、特征、向量、集合、队列、档案或索引用于表达当前运行状态。
- 动作与更新
- 系统如何选择动作、执行校验、更新状态、推进时间、回写结果或触发下一轮处理。
- 层级与协同
- 如存在多阶段、多层决策、多单元协同，应写成“第一阶段/第二阶段”“区域选择层/算子选择层”“感知层/决策层/执行层”等机制协同。
- 输出与效果
- 输出什么结果，以及该结果如何支撑技术效果。
正文中可以说明“架构”或“框架”，但必须落到上述抽象技术机制。不要写成“前端模块、后端模块、数据库模块、某框架、某服务”等技术选型列表。
五、权利要求与说明书的镜像关系
参考样稿通常采用同一组步骤贯穿摘要、独立权利要求、发明内容和具体实施方式：
- 摘要
- 用 1 段压缩写明技术领域、技术问题、核心步骤和主要效果。
- 独立权利要求
- 写完整方法步骤 S1...Sn，只保留解决技术问题必不可少的步骤。
- 从属权利要求 / 进一步限定
- 按步骤逐项展开关键对象、状态表示、参数、约束、计算方式、更新方式和替代条件。
- 发明内容
- 先给总体构思，再列 S1...Sn，再写进一步限定和技术效果。
- 具体实施方式
- 用同一组 S1...Sn，在具体示例中把输入、初始化、状态更新、计算、判断、输出完整跑一遍。
因此，code2patent 不应为交底书、布局卡、证据矩阵和初稿分别创造不同的步骤链。步骤编号、技术对象名称和技术效果口径应保持一致。
六、发明内容写法
发明内容内部固定按以下顺序组织：
- 要解决的技术问题
- 不写泛泛业务目标。
- 要能对应背景技术中的不足。
- 总体技术方案
- 用 1-2 段概括“通过什么技术手段解决什么问题”。
- 软件/算法方案应写成方法、系统或运行时机制，而不是“某模块实现某功能”。
- 方法步骤 S1...Sn
- S1 通常写输入、初始化、对象识别或模型构建。
- 中间步骤写核心计算、筛选、调度、更新、校验、映射、召回、注入等。
- 最后一步写输出、执行、回写、拒绝、告警、优化结果或上下文更新。
- 进一步限定
- 对关键步骤补充节点、边、状态、特征、阈值、优先级、约束、权重、缓存、回退或鉴权。
- 这部分通常是从属权利要求和具体实施方式的来源。
- 技术效果
- 每条效果应能回到一个或多个技术步骤。
- 没有实验数据时，不写量化提升。
- 可按“方法层面”和“应用层面”拆分：方法层面写建模、计算、状态更新、特征提取、搜索效率；应用层面写系统响应、资源利用、调度质量、风险控制等。
七、具体实施方式写法
具体实施方式应满足“代理师能继续扩展为说明书”的要求，至少包含：
- 示例场景
- 例如某个智能体会话、某个任务板、某类调度系统、某个多对象交互场景。
- 输入对象
- 会话信息、用户身份、工作案例、任务目标、图结构、候选视图、调度工件、资源状态等。
- 模型或状态表示
- 命名空间、异构图、状态机、特征向量、权限链、记忆强度、候选集合等。
- 步骤展开
- 按 S1...Sn 展开，不写成本地函数调用链。
- 可说明每一步的判断条件、更新方式和输出结果。
- 参数与边界条件
- 阈值、权重、排序条件、触发条件、终止条件、权限范围、降级策略。
- 输出与效果
- 输出文件视图、上下文、认证状态、调度结果、候选解、风险结论、审查动作等。
- 优选与替代实施
- 不同数据结构、不同模型、不同触发条件、不同部署方式、不同安全策略。
- 示例跑通
- 样稿通常会给一个具体算例、输入数据、参数或场景，并按 S1...Sn 展示系统如何执行。
- 对代码项目，也应选择一个典型用户会话、任务流、文件操作、调度请求或上下文构建过程，把步骤完整跑通。
- 公式、规则或伪代码
- 如涉及评分、排序、阈值、向量、图结构、时间推进或资源约束，可用公式、规则表或伪代码说明。
- 这些内容属于实现方式，不等于本地代码函数。
八、代码证据放置规则
代码证据是内部核验材料，不是正文主线。
默认拆分为：
04-方案代码证据映射-<方案名>.md- 可列路径、函数、字段、接口、事件、测试、配置、调用链。
05-技术交底书-<方案名>.md- 正文只保留证据状态摘要和附录索引。
- 不在正文核心章节放“代码来源”“重点模块”“代码实现对应关系”。
05B-权利要求-证据矩阵-<方案名>.md- 用于把权利要求特征逐项回勾到证据。
正文中只有在代码细节能说明必要技术特征、区别点、技术效果或充分公开时，才可摘要提及。
九、公式与符号体例
软件、算法和调度类方案常涉及评分、排序、阈值、向量、图结构和时间推进等可形式化内容。当正文出现公式或形式化符号时，按下述体例执行，避免交底书、布局卡、证据矩阵、初稿和具体实施例之间出现符号不一致、维度标签被误读、同一字母多义等问题。这些是算法类专利代理师审稿时的高频返工点。
1. 符号表先行
正文首次出现公式前，先集中列出符号表。建议按以下顺序分组：
- 任务或对象下标：如第 i 个任务、第 j 个候选、第 k 轮迭代。
- 节点、资源或环境下标：如节点 n、资源类型 r、时段 t。
- 标量、向量与矩阵：明确区分标量、向量和矩阵。
每项符号至少包含：符号、含义、下标含义、量纲或取值范围。示例：
| 符号 | 含义 | 下标含义 | 量纲 |
|---|---|---|---|
| $b_i$ | 第 i 个任务的需求向量 | i：任务编号 | 资源量 |
| $g_{n,r}$ | 节点 n 在资源 r 上的可用量 | n：节点；r：资源类型 | 资源量 |
| $\mathrm{score}(i,n)$ | 任务 i 与节点 n 的匹配分 | — | 无量纲 |
2. 维度与下标
多维属性用下标表达，不用上标。上标只保留给幂次、转置等运算，避免维度标签被误读为指数。
- ✓：$b_{i,\mathrm{cpu}}$（任务 i 的 CPU 维需求）
- ✗：$b_i^{\mathrm{cpu}}$（上标易被读作 $b_i$ 的 cpu 次幂）
多个维度并列时按下标序列书写，如 $b_{i,\mathrm{cpu},t}$。
3. 符号唯一性
同一字母不得在同一方案中兼表两种含义。任务侧与节点侧应使用不同字母族，避免同一个 $b$ 同时表示"任务需求"和"节点供给"。
- ✓：任务需求用 $b$，节点供给用 $g$，用 $b_i \leq g_n$ 表达"任务需求不超过节点供给"。
- ✗：任务需求和节点供给都写 $b$，靠上下文区分。
4. 公式分隔符统一
全文公式分隔符各选定一种，不混用：
- 行内公式：$...$ 或 (...) 二选一。
- 块级公式：$$...$$ 或 [...] 二选一。
同一份交底书或初稿内不一致会干扰代理师转排和后续排版。
5. 跨节同形
同一组符号和公式在以下位置必须逐字一致：
- 符号表（本节第 1 点）
- 发明内容中首次出现的定义式
- 具体实施方式中展开的计算式
- 参数表中的"符号"列
- S1...Sn 步骤描述中引用的符号
若具体实施方式需要引入新符号，应回填到符号表，不就地另起命名。交底书、布局卡、证据矩阵和初稿之间共享同一组符号，不为不同产物各自命名。
6. 公式与代码证据的关系
公式用于表达技术机制，不等于本地代码函数。代码中的实现细节（变量名、循环结构、临时变量）默认进入证据映射或附录，不进入公式正文。若某公式对应明确代码证据，可在证据矩阵中登记，但正文公式保持说明书语言。
7. 正反例对照
以"任务-节点匹配评分"为例：
| 场景 | 正确写法 | 易错写法 | 原因 |
|---|---|---|---|
| 任务 CPU 维需求 | $b_{i,\mathrm{cpu}}$ | $b_i^{\mathrm{cpu}}$ | 上标易误读为幂次 |
| 节点综合饱和度 | $\rho_n = \frac{1}{R}\sum_{r} \frac{g^{\mathrm{used}}{n,r}}{g{n,r}}$ | $\rho_n = \sum_r g^{used}{n,r}/g{n,r}/R$ | 缺分隔、used 未转义、运算顺序歧义 |
| 匹配分加权求和 | $\mathrm{score}(i,n) = \sum_{r} w_r \cdot f(b_{i,r}, g_{n,r})$ | $\mathrm{score} = \sum w \cdot f(b,g)$ | 缺下标、维度不清、同字母多义 |
十、下笔前检查
生成交底书、布局卡或初稿前，先检查：
- 是否已先读取用户提供的清单、模板、PRD、沟通纪要或参考样本。
- 是否能用一句话说明技术问题、核心技术手段和技术效果。
- 是否已经把代码证据与说明书式正文拆开。
- 是否已经把核心步骤整理成 S1...Sn。
- 是否明确哪些特征进入独立权利要求，哪些只进入从属权利要求或实施例。
- 是否存在把第三方库、模型平台或框架默认能力写成申请人创新的风险。
- 是否已将项目架构转译为技术对象、关系、状态、动作、时序和输出，而不是模块清单。
- 是否能用一个具体实施例把 S1...Sn 跑通。
- 若正文涉及公式或形式化符号，是否已按"公式与符号体例"设符号表、维度用下标、符号唯一且跨节同形。