热门搜索:和平精英 原神 街篮2 

您的位置:首页 > > 教程攻略 > ai教程 >我做了一个 AI 工具,把 GitHub 仓库 5 分钟转成专利交底书

我做了一个 AI 工具,把 GitHub 仓库 5 分钟转成专利交底书

来源:互联网 更新时间:2026-06-09 07:29

一、缘起

去年团队搞高新认证,每位研发人员都被强制要求交3篇专利交底书。

我做了一个 AI 工具,把 GitHub 仓库 5 分钟转成专利交底书

团队里直接炸了锅——写代码是件爽事,写专利文档那简直就是渡劫。

深入这个场景后会发现,这其实是一个真实需求明确、付费意愿强、但市面上又缺乏趁手工具的细分市场。

于是就有了「案流AI」(CaseFlow-AI)这个SaaS产品。本文不聊推广,重点分享三个工程化决策背后的思考。

二、技术架构

┌──────────────────────────────────────┐
│前端: React + Vite + TailwindCSS      │
│├─ Auth                                │
│├─ Dashboard                           │
│├─ ProjectSetup                        │
│├─ Pipeline (SSE 实时进度)             │
│└─ Editor (Markdown + 预览 + AI 对话)  │
└──────────────┬───────────────────────┘
               │ JWT + REST + SSE
┌──────────────▼───────────────────────┐
│后端: FastAPI + SQLite                 │
│├─ Scanner (GitHub/docx 解析)          │
│├─ Mining (LLM 创新点挖掘)             │
│├─ PriorArt (国知局+Google Patents)    │
│├─ Builder (模板化生成器)              │
│├─ Renderer (mermaid → PNG)            │
│└─ Export (md → docx)                  │
└──────────────┬───────────────────────┘
               │
        ┌──────┴──────┐
        ▼              ▼
    DeepSeek      Gemini 2.5 Pro

三、3 个工程化决策

决策 1:防 LLM 幻觉的「abstract 锚定」

问题

最初版本的设计是,直接让 LLM 从50条候选公开号里判断哪些与本案相关。结果令人头疼——幻觉严重。

LLM经常返回类似“CN123456789A 与本案高度相关,方案是XXX YYY ZZZ”这样的结论。真去Google Patents一查,要么公开号不存在,要么方案描述与真实的摘要完全对不上。

解决方案

解决方案其实很直接:强制要求每条公开号必须先抓取到真实的abstract,然后让LLM基于这个真实摘要去做相关性判断。

async def get_real_abstract(pub_number: str) -> str:
    """从 Google Patents 详情页抓取真实 abstract"""
    url = f"https://patents.google.com/patent/{pub_number}/zh"
    html = await fetch(url)
    # 优先 meta description
    meta = re.search(r'

效果立竿见影:相关性判断准确率从60%直接拉升到95%以上。

这里有一个通用经验:LLM不擅长事实判断,但它非常擅长基于给定的事实去做推理。核心在于,永远给它一个可靠的事实锚点。

决策 2:国知局 WAF 的 4 级降级链

问题

国知局的公布公告站 epub.cnipa.gov.cn 可以说是查新领域的“圣杯”,但它的反爬机制严苛到令人发指。

用Playwright headless模式去访问,等了180秒甚至300秒,检索框 #searchStr 愣是不出现。如果直接放弃,用户就拿不到对比文献——而这是产品的核心功能。

解决方案

最终设计了一套4级降级链:

async def search_prior_art(keyword: str) -> List[Patent]:
    # 1. 优先尝试国知局公布公告 (Playwright)
    try:
        return await cnipa_epub_search(keyword)  # 走 Playwright
    except WAFTimeout:
        pass
    # 2. 降级到国知局简化接口 (requests)
    try:
        return await cnipa_simple_api(keyword)
    except SSLError:
        pass
    # 3. 降级到 curl 子进程 (绕过 Python OpenSSL 握手问题)
    try:
        return await fetch_via_curl(keyword)
    except subprocess.CalledProcessError:
        pass
    # 4. 最终降级到 Google Patents (海外稳定)
    return await google_patents_search(keyword)

每一级降级都会记录到SSE流中,让用户清晰地看到“系统在为我尝试一切可能”。

这背后的通用经验是:垂直AI产品的核心壁垒根本不是模型本身,而是数据可达性。一个设计良好的降级链,往往能把“做不到”变成“几乎总能做到”。

决策 3:Linux root 跑 Chrome 沙箱的玄学

问题

后端服务以root用户部署,调用 mmdc (mermaid-cli) 渲染图片时,报了个很经典的错误:

[FATAL:zygote_host_impl_linux.cc(127)] Running as root without --no-sandbox is not supported.

解决方案

当然不是简单地加一个 --no-sandbox 参数(那样不安全),而是采取了如下措施:

  1. 在Docker镜像内创建一个专门的 mermaid 用户:
RUN useradd -m -s /bin/bash mermaid
USER mermaid
  1. 嵌入中文字体(不嵌入的话,渲染出来的全是方框):
RUN apt-get install -y fonts-wqy-microhei
RUN fc-cache -fv
  1. 运行时切换用户调用 mmdc:
subprocess.run(["sudo", "-u", "mermaid",
                "mmdc", "-i", input_md, "-o", output_png,
                "--puppeteerConfigFile", puppeteer_config])

这里也有一个通用经验:浏览器自动化在生产环境中的坑远比想象中要多。一个基本原则是——永远不要用root用户去跑浏览器。

四、产品当前状态

  • ✅ 流水线跑通:扫描 → 挖掘 → 查新 → 生成 → 渲染 → 导出
  • ✅ 支持 GitHub 仓库 / docx / pptx 输入
  • ✅ mermaid 自动渲染高清 PNG 嵌入 Word
  • ✅ 对话式迭代 + 自动版本管理(时间戳)
  • ✅ 项目隔离(用户数据完全隔离)

五、后续规划

  • 支持 GitLab / Gitee 仓库导入
  • 增加 PDF 直接解析
  • 开源 docx_to_md / cnipa_epub_search 等工具到 GitHub
  • 支持英文专利(USPTO / EPO 查新)
  • 增加权要书自动生成(可选模块)

六、写在最后

垂直领域AI产品的护城河从来不是模型能力,而是工程化深度加上对领域的深刻理解。

只有真正深入过这个领域的真实流程,才能精准分辨出哪些环节是真实的痛点、哪些只是伪痛点、哪些可以用AI替代、哪些环节则必须保留人工。

GitHub安卓最新版
GitHub安卓最新版

类型:热门软件

大小:12.3M

语言:简体中文

平台:互联网

游戏下载

热门手游

相关攻略

手机号码测吉凶
本站所有软件,都由网友上传,如有侵犯你的版权,请发邮件haolingcc@hotmail.com 联系删除。 版权所有 Copyright@2012-2013 haoling.cc