这是一篇技术 + 产品分享，讲我做的「案流 AI」是怎么把 GitHub 代码仓库转成符合国标的专利交底书的，以及背后的工程化思考。
一、缘起
去年我所在的团队搞高新认证，每个研发被强制要求交 3 篇专利交底书。
整个组直接哀嚎遍野------写代码很爽，写专利文档简直是渡劫。
我做产品的本能告诉我：这是一个有真实需求 + 有付费意愿 + 没有好用工具的细分市场。
于是我做了一个 SaaS，叫「案流 AI」（CaseFlow-AI），地址 https://patent.aipoyuan.top。
本文不打软广，主要分享 3 个有意思的技术决策。
二、技术架构
bash
┌──────────────────────────────────────┐
│ 前端: 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 基于真实摘要判断相关性。
python
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'<meta name="description" content="([^"]+)"', html)
if meta:
return meta.group(1)
# 备选: og:title
og = re.search(r'<meta property="og:title" content="([^"]+)"', html)
return og.group(1) if og else ""
# 喂给 LLM 的 prompt
prompt = f"""
本案技术方案: {our_solution}
候选专利:
- 公开号: {pub_number}
- 真实摘要 (来自国知局): {real_abstract} ← 这是事实锚点
判断这条专利与本案的相关性...
"""效果：相关性判断准确率从 60% 提升到 95%+。
通用经验 ：LLM 不擅长事实判断，但擅长基于给定事实做推理。永远给它锚点。
决策 2：国知局 WAF 的 4 级降级链
问题
国知局公布公告站 epub.cnipa.gov.cn 是查新的"圣杯"，但反爬极其严厉。
Playwright headless 等了 180 秒、300 秒，检索框 #searchStr 都不出现。
如果直接放弃，用户就拿不到对比文献------这是核心功能。
解决方案
设计 4 级降级链：
python
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) 渲染图片时报错：
csharp
[FATAL:zygote_host_impl_linux.cc(127)] Running as root without --no-sandbox is not supported.解决方案
不是简单加 --no-sandbox（不安全），而是：
- Docker 镜像内创建专门的
mermaid用户：
dockerfile
RUN useradd -m -s /bin/bash mermaid
USER mermaid- 嵌入中文字体（不嵌入会全是方框）：
dockerfile
RUN apt-get install -y fonts-wqy-microhei
RUN fc-cache -fv- 运行时切换用户调用 mmdc：
python
subprocess.run([
"sudo", "-u", "mermaid",
"mmdc", "-i", input_md, "-o", output_png,
"--puppeteerConfigFile", puppeteer_config
])通用经验 ：浏览器自动化在生产环境的坑远超想象。永远不要 root 跑浏览器。
四、产品当前状态
- ✅ 流水线跑通：扫描 → 挖掘 → 查新 → 生成 → 渲染 → 导出
- ✅ 支持 GitHub 仓库 / docx / pptx 输入
- ✅ mermaid 自动渲染高清 PNG 嵌入 Word
- ✅ 对话式迭代 + 自动版本管理（时间戳）
- ✅ 项目隔离（用户数据完全隔离）
内测期免费，邀请码 CaseFlow2026（限时给掘金读者）
五、后续规划
- 支持 GitLab / Gitee 仓库导入
- 增加 PDF 直接解析
- 开源
docx_to_md/cnipa_epub_search等工具到 GitHub - 支持英文专利（USPTO / EPO 查新）
- 增加权要书自动生成（可选模块）
六、写在最后
垂直领域 AI 产品的护城河不是模型能力，是工程化深度 + 领域 know-how。
只有你深入过这个领域的真实流程，你才知道哪些环节是真痛点、哪些是伪痛点、哪些可以用 AI 替代、哪些必须保留人工。
如果你也在做垂直 AI 产品，欢迎交流。
如果你正在被专利交底书折磨，去试试 patent.aipoyuan.top，邀请码 CaseFlow2026。
下次见。
💡 评论区回复策略
- 「会开源吗」→ 部分工具会开源到 GitHub，SaaS 主体闭源（毕竟要养活团队）
- 「Token 怎么算钱」→ 内测期免费 3 次/月，付费版预计 99/月（无限次 + 高级模型）
- 「Gemini 不是被墙了吗」→ 已做了国内可用通道，无需用户自己科学上网
- 「数据安全」→ 项目隔离，非管理员不可见其他用户数据，核心代码建议传脱敏 docx