/code2patent

专利名称反向澄清卡模板

本模板用于用户只提供专利名称、标题或一句话方向时。 目标是先把标题还原成可验证的技术方案候选，再由用户或研发确认。 未完成确认前，不应直接生成技术交底书、权利要求布局或专利初稿。

一、输入摘要

1. 原始标题

[填写客户提供的原始专利名称或一句话方向]

2. 客户已补充信息

[列出已有的业务场景、产品目标、PRD、沟通纪要或口头说明；未提供则写“未提及”]

3. 代码与文档来源

[填写本次可读取的代码仓库、PRD、README、架构文档、会议纪要等]

二、标题可能指向的技术解释

至少给出 1 个、最多给出 3 个候选解释。不要只因为代码里搜到某个关键词，就把第一个结果当成最终方案。

候选解释 A

• 可能的技术方案：
• 拟解决的技术问题：
• 最小技术闭环：
• 相关模块或证据线索：
• 与原始标题贴合度：高 / 中 / 低
• 偏题风险：
• 是否建议作为独立申请点：是 / 否 / 待确认

候选解释 B

• 可能的技术方案：
• 拟解决的技术问题：
• 最小技术闭环：
• 相关模块或证据线索：
• 与原始标题贴合度：高 / 中 / 低
• 偏题风险：
• 是否建议作为独立申请点：是 / 否 / 待确认

候选解释 C

• 可能的技术方案：
• 拟解决的技术问题：
• 最小技术闭环：
• 相关模块或证据线索：
• 与原始标题贴合度：高 / 中 / 低
• 偏题风险：
• 是否建议作为独立申请点：是 / 否 / 待确认

三、推荐确认版本

1. 建议方案名称

[把原始标题调整为更准确的技术方案名称；如果不建议调整，说明理由]

2. 推荐申请方向

[说明建议围绕哪一个候选解释继续做技术交底书]

3. 不建议纳入本方案的内容

[列出容易跑偏、证据不足或更适合拆成其他申请点的内容]

四、交底书表达方向

1. 背景问题应重点写什么

[写客户或行业中的实际技术问题，不写代码背景]

2. 技术方案应重点写什么

[写机制、流程、模块协同、状态变化、数据流、权限或调度逻辑]

3. 技术效果应重点写什么

[写可由方案直接支撑的效果；没有指标时不要量化夸大]

4. 代码证据应如何放置

[说明哪些内容进入正文，哪些内容只放证据附录]

五、待用户或研发确认问题

1. [该标题实际想保护哪个技术闭环？]
2. [是否接受建议方案名称？]
3. [哪些模块或实现必须纳入？]
4. [哪些内容不应纳入本申请？]
5. [是否已有技术效果、测试结果或线上反馈？]

六、确认记录