我做了一个 AI 工具,把 GitHub 仓库 5 分钟转成专利交底书
一、缘起
去年团队搞高新认证,每位研发人员都被强制要求交3篇专利交底书。

团队里直接炸了锅——写代码是件爽事,写专利文档那简直就是渡劫。
深入这个场景后会发现,这其实是一个真实需求明确、付费意愿强、但市面上又缺乏趁手工具的细分市场。
于是就有了「案流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 参数(那样不安全),而是采取了如下措施:
- 在Docker镜像内创建一个专门的
mermaid用户:
RUN useradd -m -s /bin/bash mermaid
USER mermaid
- 嵌入中文字体(不嵌入的话,渲染出来的全是方框):
RUN apt-get install -y fonts-wqy-microhei
RUN fc-cache -fv
- 运行时切换用户调用 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安卓最新版
- 热门软件 | 12.3M
-
- GitHub手机版官方下载
- 热门软件 | 15.1M
- 效率