代码证据抽取规范
本规范用于将候选专利方案映射到代码中的真实实现，并形成可供研发人员和专利代理师协作的证据材料。 抽取结果应服务于权利要求布局和具体实施方式，不应把模块、接口、函数或配置清单作为技术交底书正文。
一、目标
代码抽取阶段应尽量回答：
- 技术方案在代码中是否已经实现
- 可拆成哪些方法步骤 S1...Sn、技术特征 F1...Fn 和实施例要素
- 哪些技术特征有直接代码证据，哪些只是归纳实现
- 每个步骤或特征由哪些证据 E1...En 支撑
- 哪些内容仍需研发补充，不能直接写成既有实现
- 哪些证据只适合放入内部证据映射，哪些可以转译为交底书正文、从属权利要求或具体实施方式
二、抽取顺序
建议按以下顺序展开：
- 以候选方案为单位建立映射，不要混写多个发明点
- 先用一句话锁定技术问题、核心技术手段和技术效果
- 再将核心处理流程整理为步骤 S1...Sn
- 为每个步骤提炼技术特征 F1...Fn 和具体实施方式要素
- 将项目架构事实转译为技术对象、对象关系、状态表示、动作更新和输出结果
- 最后回到代码中定位证据 E1...En，记录路径、函数、字段、接口、配置和测试
- 将证据整理成内部证据映射表
- 把可申请的机制转译为说明书式交底书语言，不把证据表直接当成交底书正文
三、证据分级
| 级别 | 含义 | 使用要求 |
|---|---|---|
| A 级证据 | 代码、配置、文档中有直接实现依据 | 可支撑权利要求必要特征或具体实施方式，但正文仍需转译为技术步骤 |
| B 级证据 | 需要结合多个文件或运行逻辑做合理归纳 | 可支撑从属权利要求、优选实施例或“基于实现归纳”的说明 |
| C 级证据 | 当前仓库中未找到实现依据，只是推测或未来方向 | 不写成既有实现，应标为“待研发确认/可选实施例” |
起草层使用规则
- A 级证据特征可进入独立权利要求骨架
- B 级证据特征优先进入从属权利要求、优选实施例或“基于实现归纳”的说明
- C 级证据特征只能进入“待研发确认”“替代实施例”或风险提示，不能写成既有实现
交底书层使用规则
- 交底书正文只吸收能说明“技术问题、方案构思、实施方式、技术效果”的证据
- 文件路径、函数名、字段名、测试路径和内部事件名默认放入证据摘要或附录
- 如果一个段落主要由代码路径组成，应改写为处理步骤、技术特征、数据/状态流转或具体实施方式
- 代码证据充分不等于交底书合格；仍需说明该实现为什么构成一个可申请的技术方案
- 交底书主体默认不设置“代码来源”“重点模块”“代码实现对应关系”等工程盘点章节
- 只有当代码细节能帮助代理师理解必要技术特征、区别点或充分公开时，才可在正文中摘要提及
四、每条技术特征必须回答的问题
- 该特征对应的技术问题是什么
- 该特征对应哪个步骤 S1...Sn 或从属限定
- 该特征在权利要求中应写成必要特征、附加特征还是实施例要素
- 与常规实现相比，差异点在哪里
- 是否足以支撑技术效果
- 是否需要研发补充参数、阈值、条件或边界说明
- 哪些代码证据 E1...En 支撑该特征
- 在交底书正文中应表达为哪一种机制、步骤、状态流、数据流或单元协同
- 哪些模块、类、函数、接口或配置仅作为证据位置，不进入正文主线
- 哪些工程细节应只留在证据附录中
推荐内部编号：
S1...Sn：方法步骤F1...Fn：拟进入权利要求或实施例的技术特征E1...En：代码、配置、文档或测试证据A1...An：架构事实到专利表达的转译项
正文优先写 S 和 F，证据表再列 E。不要反过来用 E 的文件路径和函数名组织正文。
架构信息优先写成 A 的转译结论，例如“运行时文件视图生成机制”“会话状态更新机制”“多层搜索策略”，不要写成原始模块名。
五、从代码证据到交底书的转译规则
1. 不要直接写成代码盘点
以下表达不适合作为交底书正文：
- “某文件实现了某函数”
- “某接口调用某服务”
- “某字段取值为某状态”
- “某测试文件覆盖某流程”
- “重点模块包括 A、B、C”
- “代码来源为某本地绝对路径”
这些内容应进入证据映射表或代码证据附录。
2. 转成发明叙事
应把工程事实转成专利代理师可理解的表达：
| 代码证据写法 | 交底书正文写法 |
|---|---|
| 某服务校验 assignmentMode 与 assignee 字段 | 系统在任务创建阶段通过互斥校验区分直接分派、自动分派和待认领三类分派意图 |
| 某运行时读取 prompt script 并调用 next() | 系统以中间件式脚本链动态组装智能体上下文，使不同渠道和用户场景下的提示词可响应式调整 |
| 某模块生成 mount 并写入 sandbox policy | 系统根据会话、用户、工作空间和技能授权生成运行时文件视图，并通过沙箱策略限制可见路径 |
3. 保留必要证据
交底书正文可以保留少量证据摘要，例如：
- “代码证据显示，该机制已覆盖创建校验、状态回写和出站事件三个环节”
- “具体证据详见《方案代码证据映射》中的 A1-A5”
但不应在正文中连续堆叠多个路径或函数名。
4. 正文筛选阈值
将某个工程细节写入交底书正文前，先问四个问题：
- 它是否对应拟保护的必要技术特征
- 它是否解释了本方案相对现有方式的区别
- 它是否支撑某个技术效果
- 它是否有助于代理师理解可替代实施方式或充分公开
四个问题均无法回答时，该细节只能放入证据映射表或附录。
5. 输出拆分规则
04-方案代码证据映射-<方案名>.md 可以保留路径、函数、字段、接口、事件和测试。
05-技术交底书-<方案名>.md 应默认采用算法/软件类说明书式结构：技术领域、背景技术、发明内容、附图说明、具体实施方式、技术效果、替代实施方式、证据附录。
05A / 05B / 06 中的步骤编号应沿用 05-技术交底书 中的 S1...Sn，不得重新发明一套步骤链。
六、引用要求
- 优先引用代码仓库中的相对路径
- 对关键实现注明模块、类、函数、接口、配置项或任务流名称，但只作为证据位置
- 不大量粘贴代码，重点写清楚“代码做了什么”
- 没有找到依据时明确写“未在当前代码中定位到直接证据”
七、不宜直接写成专利特征的内容
- 纯业务规则、运营策略、文案逻辑
- 通用 CRUD 流程
- 仅是开发框架默认能力
- 完全来自第三方库或平台的固有机制
- 无法对应具体技术效果的常规工程做法
八、标准产出
建议形成以下文档：
04-方案代码证据映射-<方案名>.md05-技术交底书-<方案名>.md05A-权利要求布局卡-<方案名>.md05B-权利要求-证据矩阵-<方案名>.md06-发明专利初稿-<方案名>.md06A-发明专利初稿自检表-<方案名>.md07-研发补充问题清单.md
其中 04-方案代码证据映射-<方案名>.md 为核心前置产物，但它不是技术交底书正文。
04 的推荐表头为：步骤编号、技术特征、权利要求/实施例位置、证据编号、证据位置、证据等级、待确认事项。不要以“模块名称、模块功能、对应文件”为主表头。