AI 建站走到源码层面，问题会变得很具体：站点信息存哪张表、生成任务怎么排队、页面生成之后怎么推给搜索引擎。用现成系统的人不用操心这些，代价是数据、提示词、发布链路都在对方手里；拿 Django 自己搭的人要操心这些，换来的是每一层都能按自己的方式改。两种选择没有绝对好坏，分水岭出现在站点变多、需求开始频繁变动的时候。
一套能跑起来的 AI 建站系统，在 Django 里大概长这样：
aisite/├── sites_core/ # 站点、栏目、页面模型├── content_hub/ # 素材库、生成任务、版本记录├── ai_bridge/ # 模型接入、提示词模板、结果清洗├── publisher/ # 模板渲染、sitemap、收录推送└── seo_kit/ # 结构化数据、robots、站点校验五个 app，对应建站、生成、发布三段流程。代码量上这不算大工程，一个熟悉 Django 的后端两三个月能搭出可用版本，难的不是写多少行，而是几处关键设计：数据表怎么分、AI 放在哪一层、站点多起来之后怎么不打架。这几处设计对了，后面加一个站是半小时的事；设计错了，再往后走都是返工。
一、Django 做 AI 建站底层，值钱的是控制权
选 Django 做底层，网上的理由多半是生态成熟、ORM 好用、Admin 开箱即用。这些都对，但从建站运营的角度看，真正拉开差别的是另一件事：系统的每一层都在自己手里。
| 维度 | 现成 SaaS 建站工具 | Django 源码自建 |
|---|---|---|
| 上手速度 | 注册即用，当天就能出页面 | 要先跑通环境与数据模型，起步慢一截 |
| 数据结构 | 平台定好模型，想加字段要提需求 | 表结构自己定，字段跟着业务随时加 |
| AI 接入方式 | 用平台内置的生成能力，提示词与参数不可见 | 模型接口、提示词模板、清洗规则都写在自己代码里 |
| 多站扩展 | 按套餐加站，站间配置受平台规则约束 | 加一个站等于加一条记录，边际成本接近零 |
| 长期成本 | 按站打包月费，站点越多支出越线性 | 服务器与模型调用费用，规模上去后单站成本摊薄 |
| 维护责任 | 平台负责升级、备份与安全 | 版本升级、依赖跟进、安全补丁都是自己的活 |
版本选择上不用纠结太久。Django 6.0 已经在 2025 年底发布，5.2 系列仍是官方长期支持版本，长期运行的项目在 5.2 LTS 和 6.0 之间选，主要看用到的第三方库有没有跟上。这类项目两三年不换大版本很常见，跟着 LTS 走比较稳。
控制权的实际含义，体现在每一次小改动上。想换一家模型服务商，改的是 ai_bridge 一个模块；想给某个站换一套提示词，改数据库里的一条记录；想加一个收录推送渠道，在 publisher 里加一个函数。这些动作都不需要等别人排期，也不会影响其他站。
反过来也要说清楚：自建不是全赢。没有现成的可视化运营界面（Django Admin 能顶一部分，但不算好看），没有客服支持，出了安全漏洞要自己堵。而且这套代码一旦上线，维护它的人就是你，没人替你兜底。
自建买的是控制权，代价是自己当运维，这笔交换值不值，取决于你打算改它多久、改多深。
二、五个 app 的骨架，AI 只占其中一格
这套划分真正的作用是给 AI 划边界。生成只是链路中的一段，不是系统的全部。见过不少项目把模型调用散落在各处，换个服务商要全局搜索替换，测试也没法单独跑，改一次错一次。
站点档案、栏目树、页面实体。一个站一条记录，域名、行业、模板信息都在这里；页面挂在栏目下，天然形成层级结构。
素材库、选题池、生成任务队列。一篇文章生成过几版、哪一版发去了哪个站，翻记录就能查清。
所有对大模型的调用收口在这一层，提示词模板按站点绑定，换模型服务商只改这里。
把文章套上模板渲染成静态页面，生成 sitemap，调用收录推送接口，发布动作全在这一层。
结构化数据、robots、页面标题与描述的规则校验，几个站共用一套，改一次全部生效。
这么分的两个直接好处：换模型只动 ai_bridge，加推送渠道只动 publisher，改动的边界是清楚的；每个 app 可以单独写测试，生成结果不对时先看 ai_bridge 的输入输出日志，不用通读整个项目找问题。
也要承认另一面：只有一个站、页面几十个的场景，这套结构算过度设计，把代码塞进一个 app 里更快。模块化的价值跟着站点数量和改动频率一起涨，站越多、改得越勤，越值。
把 AI 关进一个 app，换模型时全站不用动，这是整套结构里最省钱的一条设计。
三、模型设计定生死，表结构错了后面全是返工
代码结构可以后期重构，数据表一动就是伤筋动骨。三件事在建模阶段最容易被简化掉：站点与内容分不分表、内容有没有来源与版本、生成任务的状态能不能追踪。简化的时候省了半小时，返工的时候花掉两周。
class SiteProfile(models.Model):domain = models.CharField(max_length=128, unique=True)industry = models.CharField(max_length=64)prompt_set = models.ForeignKey('ai_bridge.PromptSet',on_delete=models.PROTECT)class Article(models.Model):site = models.ForeignKey(SiteProfile,on_delete=models.CASCADE)topic = models.CharField(max_length=200)body = models.TextField(blank=True)status = models.CharField(max_length=16, default='draft')source_batch = models.CharField(max_length=32, blank=True)prompt_ver = models.CharField(max_length=16, blank=True)updated_at = models.DateTimeField(auto_now=True)几个字段的解释：status 用 draft / review / published 这类状态值，不要用布尔字段，草稿、待审、已发布是三态而不是两态；source_batch 记下内容属于哪一批生成，某批质量不行时可以整批回查；prompt_ver 记录当时用的提示词版本，改过提示词之后还能对得上历史内容；prompt_set 用 PROTECT 而不是级联删除，防止误删提示词模板把站点配置带塌。
同一篇内容要发去多个站的时候，站点与内容之间加一张中间表，记录"哪个站、发布状态、发布时间"，比在文章表里堆 site1、site2 这种字段干净得多。这些都不是什么高深设计，是常识，但赶工的时候最容易被跳过。
- 站点表不存内容，内容表不存站点配置，两边靠外键关联，各自独立演进
- 所有生成物先进草稿区，人工过审后才允许进入发布流程
- 每次生成留批次号与提示词版本，出问题能定位到"哪一批、哪套词"
还有两个运维层面的小提醒：列表页按站点加状态过滤的查询记得加联合索引，数据量上来后差别很明显；生成任务表膨胀最快，定好归档策略，别让它在一年后变成数据库里最大的那张表。
表结构是给未来三年的自己用的，建模时多花的那点时间，都会在后面的改动里省回来。
四、AI 生成这一层，怎么接进去才不出乱子
初版最容易写成在视图里同步调用模型接口，用户点一下，等几十秒返回。演示阶段这么写没问题，任务一批量化就散架：请求超时、worker 被占住、失败没有重试机会。落到生产要换成异步任务，Celery 配 Redis 是 Django 生态里最顺手的组合，后台点选生成，任务进队列，worker 在后台慢慢跑，页面上看的是任务进度。
提示词不要写死在代码里。多站是这套系统的常态，每个站的定位、行业、语气都不同，提示词如果跟着代码走，改一句话都要发版。放进数据库、按站点绑定，运营的人自己就能在后台调整，不用等开发排期。
| 链路环节 | 实现方式 | 容易踩的点 |
|---|---|---|
| 触发 | 后台手动点选，或定时任务按选题池批量排队 | 一次塞几千条任务把队列堵死，后面全在等 |
| 调用 | 模型服务统一收在 ai_bridge，密钥走环境变量 | API key 写进代码还提交到了仓库 |
| 清洗 | 去掉通用套话、段落级相似度检查、格式规范统一 | 只做同义词替换式的降重，内容反而更别扭 |
| 入库 | 结果写草稿状态，带上批次号与提示词版本 | 直接写发布状态，出问题只能事后批量删 |
| 发布 | 人工过审后进入 publisher 渲染与推送 | 生成即发布，把审核环节整个省掉 |
生成内容要有人对事实负责。数据、资质、效果承诺这类段落必须人工逐句过，涉及医疗、金融等领域的还要按行业要求审核。批量伪原创做不得，收录与排名由搜索引擎决定，推送只是加快发现，不构成任何保证。
队列本身也要盯着。任务失败要落库、要能重试；模型返回空了、超长被截断、格式跑偏，都要有兜底策略，比如自动重试一次，再失败就进人工队列。这套机制不写，系统跑一阵子就会出现"以为生成了、实际什么都没有"的静默失败，比报错更难查。
AI 生成是流水线上的一环，不是流水线本身，把队列、清洗、审核串成链路，它才开始产出可靠的东西。
五、发布与推送：渲染成什么、推给谁
页面生成有两条路：请求来了动态渲染，或者提前渲染成静态 HTML。展示型站内容更新频率不高，静态化更划算，访问速度快、服务器压力小，搜索引擎拿到的也是完整 HTML。Django 模板系统加上缓存框架就能做，发布动作发生时把页面一次性渲染落盘，后面都是静态文件直接吐。
sitemap 用 Django 自带的 sitemaps 框架，挂上去就是几行代码的事；推送放在渲染动作之后，让新页面尽快被搜索引擎发现。
class ArticleSitemap(Sitemap):changefreq = 'weekly'priority = 0.8def items(self):return Article.objects.filter(status='published')def lastmod(self, obj):return obj.updated_at@shared_taskdef push_urls(urls):submit_baidu(urls) # 百度搜索资源平台 链接提交接口submit_indexnow(urls) # IndexNow 协议推送推送渠道用官方接口就够：百度搜索资源平台的链接提交接口按站点配置，新页面发布后调用一次；IndexNow 协议一次推送支持它的多个搜索引擎同步收到。两个渠道的分工也清楚，sitemap 是批量告知的底线，推送是单点实时通知，响应通常在分钟级，比等爬虫自己逛过来快得多。
不打算从零维护这套源码的话，UC 建站系统可以看作同样结构的产品化版本：HTML 直出、内容中台的差异化重组、双通道推送（百度 API 加 IndexNow）都已经做成现成模块，不用自己从 publisher 一层写起。自建的话，参考它的层次划分来设计自己的目录，也能少走一段弯路。
推送解决的是"被发现"，内容质量决定的才是"被留下"，两件事别混为一谈。
六、从第三个站到第五个站，源码要提前留的口子
一个站的时候，很多地方写死也撑得住；两个站开始，会有"复制一份改改"的冲动；到第五个站，问题会以很具体的形式露出来。
- 模板分叉：五个站五套模板，改一个公共组件要动五处，改漏一处就是线上差异
- 提示词漂移：A 站的提示词调过三个版本，B 站还在用旧的，两个站的内容风格对不上
- 配置散落：域名、统计代码、校验文件写在各处，加站或迁移时到处翻
- 动作不齐：有的站发布后自动推送，有的站当时忘了配，全靠人记
这些口子在 Django 里都有现成的位置留。站点配置全部落库，sites_core 的站点档案就是干这个的，settings 里只留环境级变量；站点区分用 django.contrib.sites 框架按域名判断，不要硬编码站点编号；模板走继承结构，公共骨架放 base 层，站点模板只覆盖差异的那部分；提示词按"提示词集"组织，每个站引用一个集合，避免各站散装、版本对不上。
多站运营的底线是每站独立部署、独立配置，各自的备案与资质按实际情况办理。一套模板复制多份、内容原样搬过去的做法不叫多站，同质页面在收录和信任上都会出问题，也不是这套架构的初衷。
管理口子同样要提前想。各站的发布状态、收录情况如果只看各自后台，站一多就顾不过来。用 Django Admin 定制一个总览页能解决一部分需求；UC 建站系统的多站看板是把这类场景做成了现成能力，索引量、排名、流量、异常预警放在一个界面里看，站数上来之后，这种统一监控省下的不只是开发时间。
"第五个站的问题，答案都在初版模型里"
加站不返工的前提，是共性和差异一开始就分开放，配置文件、模板、提示词都遵循这一条。
七、源码自建之前，先算三笔账
技术上能自建，不等于应该自建。动手之前把三笔账摆出来算一遍，比看十篇技术文章都有用。
时间账
2-3 个月
一个人从建模到首站上线的开发周期
人力账
长期 1 人
懂 Django 的人跟版本升级与安全更新
费用账
按量
服务器加模型调用，站点越多单站越摊薄
时间账指的是首版可用系统的开发周期，熟练的 Django 后端两三个月能跑通主流程，前提是需求控制得住。人力账往往被忽略：这套代码上线之后，Django 版本要跟、依赖库要升、服务器要维护，得有一个懂行的人长期负责，哪怕每周只花几个小时。费用账最清楚：服务器和模型调用的开销随规模变化，站点多了之后单站成本会摊薄，但不会归零。
三笔账摆出来，什么情况适合自建就清楚了：团队里有开发能力、站点会长期运营而且数量不止一个、对数据结构或生成逻辑有深入定制的需求，这三点凑齐，自建的投入能收回来。反过来，只想专注内容和运营、不打算碰服务器和代码，现成系统是更省事的选择，把精力花在内容和转化上，收益更直接。
Django 更新到 6.0 了，已经上线的项目要不要跟着升？
安全修复跟到官方支持期内就不用慌，运行中的项目不必追每个大版本。真要升级，安排在业务空窗期，先查用到的第三方库有没有发布兼容版本，再在测试环境跑一遍数据迁移，都跑通之后才动生产环境。
一句话结论：拿 Django 源码自建 AI 建站系统，是用前期的开发投入换长期的控制权；站点数量、改动频率、团队里有不有懂代码的人，决定这笔投入值不值。
账算到这儿，结论其实不复杂：具备开发能力的团队，自建是一次性投入换长期可控，第五个站、第十个站都能按自己的节奏加；只想专注内容的，把技术环节交给现成系统，注意力放在选题和转化上更划算。两条路都能走通，怕的是站在中间，既想省下开发时间又希望随时改到底层，到头来两头落空。
回到源码本身，这套系统的功夫都落在几处关键设计上：表结构把站点和内容分开，AI 收进单独一层，模板、提示词、推送配置提前留好差异化的位置。这几处理顺了，加一个站真的只是加一条记录的事。
（版本与接口口径参考 Django 官方发布说明与百度搜索资源平台、IndexNow 公开文档。）
