5分钟AI工具推荐：GitHub仓库转专利交底书实测
一、缘起
去年团队申报高新技术企业认定，每位研发人员被强制要求提交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 详情页抓取真实摘要"""
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)
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 替代、哪些必须保留人工审核。