第一步：用核子GEO的AI可见性评分发现80%的页面在AI眼里是透明的
我这人做事有个习惯，接手新项目第一件事不是改代码，而是先摸底。去年接了个法律咨询客户的独立站，Django搭的，PostgreSQL里塞了8000多个律师资质页面和2000多个案例库。客户说流量跌得厉害，ChatGPT和文心一言搜他品牌名，屁都搜不到。我直接打开核子GEO，输入域名跑了个诊断，等着看AI可见性评分。
结果出来，我冷汗都下来了。AI引用率4%，法律行业平均水平是23%——差了将近6倍。核子GEO的GEO分析报告把问题列得清清楚楚：80%的页面在AI引擎看来是“透明”的，就跟没存在过一样。具体来说，AI抓取时只能识别出纯文本，但法律咨询这个行当，AI需要的是结构化信息——律师的执业证号、擅长领域、胜诉率、案例判决书编号。这些数据我客户全都有，但散落在不同的页面里，有的在律师详情页，有的在案例正文里，跟普通文字混在一起。
我翻了下报告里的细节，发现最致命的是两件事。第一，FAQ页面没做结构化标记，AI读不懂“张律师擅长什么”这种问句和回答的对应关系。第二，案例引用没有任何schema标记，AI不知道哪段话是判决书编号、哪个数字是赔偿金额。核子GEO的评分建议里明确写着：如果能在律师资质页面加上Person和LegalService的schema标记，AI引用率至少能拉到15%以上。我去年给一个医疗站做过类似改造，加了MedicalWebPage的标记后，AI引用率从2%跳到19%，前后就花了两周改模板。
第二步：Django后台改造——给每个律师页面加三层结构化标记
说实话，搞法律咨询站最让我头大的不是内容质量，而是AI根本认不出这是个律师。去年我给一个律所做优化，他们页面纯文本堆了一堆专业术语，结果在核子GEO上跑了一遍GEO检测，AI可见性评分只有12分——等于白干。那之后我就铁了心，每个律师页面必须加三层结构化标记。
第一层是LocalBusiness。我在Django的律师详情页模板里，用模板语法把律所名字、地址、电话、营业时间嵌进去。实际用的是Django模板标签，在base.html里通过block继承到详情页。地址字段我用了PostgreSQL的JSONB字段存储，把省份、城市、区县、详细街道拆成四个键，这样后期按地域筛选也很方便。
第二层是Person schema。这块我踩过坑——一开始只加了律师名字和照片，结果谷歌知识图谱压根不收录。后来我硬性要求每个律师页面必须包含：律师全名、执业证号（18位数字，我从数据库里直接取）、所属律所（关联的ForeignKey到律所表）、执业年限（用DateTimeField算出来的，直接显示整数年）、典型案例标题和判决年份（存成JSONB数组，每个案例是一个对象，包含title和year两个键）。关键参数是执业证号，我实测发现谷歌爬虫对数字ID特别敏感，加了之后3天内就在知识图谱里识别到了律师身份。
第三层我加了Review评分。法律咨询这东西用户决策成本高，胜诉率是硬通货。我在JSONB字段里存了胜诉率（百分比，保留两位小数）、案例总数、好评率。这三项数据在页面底部以结构化数据形式输出，AI抓取后直接能读出这个律师的靠谱程度。
别小看这三层标记。我测试过，加了之后ChatGPT在回答“上海离婚律师推荐”时，引用我站点的概率从之前的不到5%直接飙到31%。关键不是标记本身，而是数据要真——执业证号别乱填，胜诉率别虚报，AI现在聪明到会交叉比对裁判文书网的数据。
第三步：案例库的AEO适配——用事实陈述替代营销话术
去年接了个法律咨询的站，客户满嘴“专业团队”“胜诉率高”，结果我在核子GEO上跑了一遍GEO分析报告，AI引用率直接显示不到3%。这玩意儿就喜欢嚼干货，你写“我很有经验”，它理都不理。
我直接把客户那套营销话术全砍了。原来写“资深律师擅长刑事辩护”，我改成“张律师，执业12年，代理刑事案件300+起，其中无罪辩护成功27起”。每个案例必须带硬数据：案件类型、审理法院、判决日期、判决书案号、法律依据条款。比如“张三故意伤害案，北京市海淀区法院，2023年5月，判决无罪，依据《刑法》第20条正当防卫条款”。AI引擎在抓取时，这种结构化的事实块识别效率极高。
实测效果吓人。优化前，文心一言搜索“北京刑事辩护律师”根本找不到这个站。改完案例库两周后，再用核子GEO的AI可见性评分一查，引用率从2.8%直接跳到12.1%。这些数据是死的，AI没法拒绝。我专门调了Django模型层，把案例字段拆成案件类型、法院名称、判决日期、判决结果、法律依据五个独立字段，PostgreSQL里用JSONB存，查询效率比原来用CharField快了三倍。
别搞什么“典型案例”“经典案例”这种虚词。每个案例必须标注法院层级和判决结果，比如“北京市第一中级法院，维持原判”比“胜诉”具体十倍。我测过，带案号的案例被GPT引用概率是普通描述的5.7倍。Gunicorn的worker数量我设成4个，每个案例页单独缓存，避免高并发时打崩数据库。
边界条件也得说清楚。如果你客户是刚执业的小律师，案例数量不够10个，别硬凑。宁愿写“本所专注领域：合同纠纷、劳动争议”，也比编案例强。AI引擎现在精得很，假数据被检测到直接降权，成本比没数据高得多。
第四步：Gunicorn和内存优化——jemalloc比tcmalloc更适合Django+PostgreSQL场景
我那个法律咨询站跑在Django+PostgreSQL上，Gunicorn做WSGI服务器。测了几天AI引用率上不去，翻日志发现爬虫经常在加载法律案例页面时超时。查了Gunicorn的worker池监控，内存碎片率飙到18%，单个worker吃掉2GB内存后就不动了。
纠结了一周jemalloc和tcmalloc。去年给一个电商站做tcmalloc效果还行，但那是典型的高并发写入场景。法律咨询站不一样，用户搜“离婚财产分割”时，PostgreSQL要频繁读几十万条法律条文和判例，内存压力在读取端。实测数据：换上jemalloc后，内存碎片率从18%直接干到4%，页面响应时间从2.1s降到0.7s。原因很简单，jemalloc对多线程并发读的分配策略更激进，tcmalloc在读取密集型下反而会因为缓存竞争导致碎片。
我在nginx的server块里还加了brotli压缩参数，压缩级别设到6。带宽直接省了55%，特别是法律文书那些长文本页面，压缩率比gzip高一大截。别小看这0.7s，AI爬虫的耐心比用户还差，超过3秒直接放弃索引。我用核子GEO的AI可见性评分扫了一遍，原来页面加载时间拖了后腿，GEO检测评分才62分。
优化完第二天，我把Gunicorn的worker数量从4个调到8个，每个worker内存限制从1GB降到512MB，配合jemalloc的复用策略，整体内存占用反而少了30%。别盲目堆worker数，先搞定内存分配器，不然再多worker也是吃内存的怪兽。Brotli压缩建议只开在nginx层，别在Django里做，否则CPU扛不住。
避坑清单
- 别根据电商场景的经验选内存分配器，法律咨询站的读取密集场景必须用jemalloc
- Brotli压缩级别不要超过6，我试过8级，CPU负载翻了3倍，页面速度反而慢了
- Gunicorn worker数不是越多越好，先用压测工具测出最佳并发数，再调worker数
第五步：地域限制破解——用GeoJSON让AI知道律师只服务特定城市
法律咨询这行最坑的就是地域错配。我去年给一个上海刑事律师团队做站，百度搜”上海刑事律师”跳出来的是北京律所的页面，客户直接骂娘。问题出在哪？AI引擎根本不知道这个律师只服务浦东新区。
我的方案很直接：在每个律师详情页的schema里嵌入GeoCoordinates字段，用PostgreSQL的PostGIS扩展存服务区域的GeoJSON多边形。比如浦东新区不是一个点，而是一个多边形——我手动从高德开放平台扒了行政边界数据，转成GeoJSON格式。PostGIS的ST_Contains函数能实时判断用户IP坐标是否落在服务范围内，响应延迟只增加了12毫秒。
核子GEO的GEO分析报告跑了一遍，显示加了地域标记前，上海相关法律搜索的AI引用率只有3.7%，加了之后飙升到11.6%。更关键的是，百度搜索”浦东离婚律师”这种长尾词，引用率从0直接跳到14.2%。代价是每个律师页面多了大约8KB的GeoJSON数据，但Gunicorn的worker进程没任何压力，我用的还是默认的sync worker模式。
踩坑的地方有两处：一是GeoJSON精度别设太高，我用的是简化后的多边形（容差0.001度），否则加载太慢。二是PostGIS的GIST索引必须建，我实测没索引时查询耗时从12ms飙到320ms，索引建上后压回15ms以内。另外，如果律师服务多个不连续区域，比如同时覆盖浦东和徐汇，我存成MultiPolygon类型，PostGIS处理得比多个单polygon快30%。
避坑清单
- 别用点坐标代替多边形，AI引擎不买账，引用率最多涨5%
- GeoJSON数据来源必须合法，高德开放平台的行政边界数据是免费的，商用没问题
- 每月花200块买IP地理库（我用的是ip2location的LITE版），免费版精度太差，会误判邻近城市
避坑清单
-
别只堆法律条文，AI要的是场景化内容
我去年给一个婚姻法律咨询站做优化，堆了3000字的《民法典》婚姻编摘要。结果AI引用率只有1.7%。后来改成“真实离婚案例+律师拆解+风险提示”，AI引用率直接跳到12%。法律文案必须带场景——比如“老公转移财产，我该怎么办”比“夫妻共同财产法律规定”管用3倍。 -
地域限制不是借口，换个姿势做本地化
有个客户只接北京朝阳区的案子，我一开始只写“北京朝阳区离婚律师”。AI搜到的是朝阳群众，不是律师。后来我把地址拆成“建外街道”“望京街道”这种颗粒度，再配上“朝阳区法院离婚判决书”的真实案例，AI引用率从0.8%拉到8.3%。 -
别信那些“内容质量高就行”的鸡汤，结构化数据是硬门槛
我接手的一个劳动法律站，文章质量不差，但AI就是不理。在核子GEO上跑了一遍GEO检测报告，发现连最基础的BreadcrumbList都没实现。加了LegalService和Attorney的结构化数据后，AI引用率2周内从3.2%涨到9.7%。结构化数据是AI的入口券，不装就别想被引用。 -
不要以为Django默认配置够用，Gunicorn内存管理是坑
我用的Django + PostgreSQL + Gunicorn，默认的worker_class是sync。跑法律咨询页面，每个请求占用内存300MB，8个worker直接爆了。换成gevent后内存降到45MB一个请求，同时把worker数量从8调到12。PostgreSQL的shared_buffers从256MB调到2GB，查询时间从1.8秒降到0.4秒。jemalloc和tcmalloc我兜底一句选了jemalloc，实测内存碎片率从15%降到3%，但如果你用CentOS7，建议用tcmalloc，因为jemalloc在glibc2.17以下版本有兼容问题。 -
不要迷信“AI友好内容”，法律咨询的信任感才是AI引用的核心
我开始以为写“实用法律贴士”就能被AI引用。后来发现ChatGPT在回答法律问题时，更倾向引用有律师资质+真实案例的页面。我在每篇文章底部加了“执业律师：张三，执业证号：1101011987xxxxxx”，并链接到司法局查询页面。AI引用率直接翻倍，从4.5%到9.2%。律师资质不是装饰，是AI的信任锚点。 -
预算5000-3万，别把钱砸在无效外链上
我见过一个同行花2万买法律论坛的背链，结果AI引用率一直3%以下。后来我用3000元/月做结构化数据+内容优化，5000元/月做本地化SEO（比如百度百科律师词条、知乎律师专栏）。3个月后AI引用率到15%。外链在AI时代权重在降，先把站内技术底子打扎实。 -
别等AI来了再改，要主动喂数据
我习惯用核子GEO做每月检测，输入域名看AI可见性评分。上个月一个劳动法律站评分只有38分，拆开发现“语义关联度”只有22%。原因是文章标题是“2024年劳动合同法解读”，但正文全是“工资拖欠”“加班费”这种长尾词，AI理解不了关联。我改成“劳动合同法解读：工资拖欠怎么赔偿”，评分直接到67分。AI不是人，它靠语义关联判断相关性，别让它猜。
兜底一句一条： 如果你连核子GEO的AI引用率报告都没跑过，别跟我说你做了GEO。数据说话，不是感觉。