CGL SCRM / assets
资产清单
数据量、二维码、模板、交付物
这一页讲「手上有什么」
数据、文件、账号、二维码——这四样东西现在各有多少、放在哪、谁能拿。
69
数据表
1,129 个字段
6
可交付的文件
手册、技能包、字典…
56
页面模板
后台 + 手机端
8
前端资源
样式、脚本、图
可以拿给别人的文件
体积和文件数是现场读磁盘算出来的，不是写在这一页上的—— 这类数字最容易过期（本项目的安装手册就出过「写着 10 页、实际 11 页」）。
| 东西 | 版本 | 实际体积 | 在哪 | 说明 |
|---|---|---|---|---|
| AI 接入安装手册 | v1.3 | 1,952,951 B（单个文件） | dist/manual/CGL-SCRM-AI-Access-Handbook-v1.3.pdf | 发给市场部与同事，可直接转发；不含任何人的 Key |
| 出厂技能包 | — | 50,200 B（4 个文件） | skill/cgl-scrm/ | SKILL.md + CLI + MCP 桥 + API 清单；给 WorkBuddy / 豆包 用 |
| 本展示站（源） | — | 133,434 B（20 个文件） | deploy/showcase/ | 模板 + 样式 + facts.json；渲染产物在 dist/showcase/。由 scripts/gen_showcase.py 从代码生成 |
| 模型列名字典 | — | 17,716 B（单个文件） | docs/MODEL_REFERENCE.md | 第 9 道闸门 check_generated_docs 守着 |
| 服务层接口字典 | — | 34,914 B（单个文件） | docs/SERVICE_REFERENCE.md | 同上 |
| 模板上下文契约 | — | 9,416 B（单个文件） | docs/TEMPLATE_CONTRACT.md | 同上 |
手册里为什么不写「多少页」：
装订页数会随着重新排版变化，写死了就一定会有一天对不上。
所以发给同事时干脆不提页数——
会在多个地方重复出现的数字，要么立一道检查守着，要么干脆不说。
运行时真正在用的东西
这些东西不在代码仓库里，但它们决定了系统能不能正常跑。
| 类别 | 在哪 | 说明 |
|---|---|---|
| 后台账号 | deploy/seed_accounts.json | 生产账号唯一来源（只存 bcrypt 哈希，不含明文口令） |
| API Key 体系 | api_token 表 | 服务端只存 sha256；明文只在签发那一刻打印一次 |
| 二维码 | 永久码（QR_LIMIT_STR_SCENE） | 不可撤销；指向 scrm.jxccwx.com（自有域名） |
| 海报模板 / 海报 | wechat_poster + COS | 生成物落 COS 桶 |
| 微信服务号配置 | wechat_config | 回调 /wechat 与 /video/index/index（与原站一致） |
数据现状
本地那列是开发库的读数（跑完自检后复原的状态）；生产那列从线上自报取。
| 数据 | 本地（复原后） | 生产 |
|---|---|---|
| lead | 11,352 | 11,348 |
| event_signup | 9,927 | 9,924 |
| event | 160 | 160 |
| content_item | 27 | 25 |
| content_tag | 14 | 10 |
| questionnaire | 4 | 3 |
| traffic_source | 61 | 61 |
| lead_tag_rel | 1,464 | — |
开发库里一共 69 张表（含数据库自己建的内部表）， 业务表是 69 张。
页面模板都在哪
| 分组 | 文件数 | 管什么 |
|---|---|---|
| (根) | 4 | 公共骨架与错误页：每个页面都套用的外壳、404、500 |
| auth | 1 | 登录页 |
| h5 | 8 | 客户在手机上看到的页面：活动落地、报名、问卷、分享 |
| manager | 43 | 后台页面：看板、线索、活动、问卷、内容、账号、审计、报表 |
前端资源（样式 / 脚本 / 图）
| 文件 | 体积 |
|---|---|
| css/app.css | 15,502 B |
| css/h5.css | 6,956 B |
| img/cgl-logo.png | 5,988 B |
| img/favicon.ico | 8,156 B |
| img/material-sample.png | 21,538 B |
| img/poster-sample.png | 15,024 B |
| js/app.js | 7,307 B |
| js/h5.js | 7,865 B |
前端一共 8 个文件、88,336 字节—— 刻意保持很小：页面主要是服务器拼好发过来的，前端只负责一点点交互。
自动生成、且有人守着的文档
docs/ 下这几份是从代码生成的。
它们的风险是「代码改了、文档没跟着改」——所以项目里专门有一道关卡每天检查它们新不新鲜。
| 文件 | 行数 | 体积 |
|---|---|---|
| docs/MCP与技能包-使用说明.md | 223 | 9,064 B |
| docs/MODEL_REFERENCE.md | 465 | 17,716 B |
| docs/SERVICE_REFERENCE.md | 475 | 34,914 B |
| docs/TEMPLATE_CONTRACT.md | 362 | 9,416 B |
| docs/attribution_match.md | 107 | 4,914 B |
| docs/部署-子域名隧道.md | 165 | 7,432 B |
| docs/顾问归因-操作手册.md | 153 | 6,788 B |
二维码：一个不可逆的细节
线上用的是「永久码」。
微信的二维码分两种：临时的（有有效期、可以重新生成）和永久的（一旦生成就不能撤销）。
我们选了永久码——因为活动物料、印刷品上的码一旦发出去就收不回来，
临时码过期会造成「印着码的海报全部作废」。
代价是：码里的内容一旦定下来就改不了。 所以生成之前必须先确认好地址——这是为什么「到底该用哪个域名」这件事在本项目里被反复核对， 甚至专门做了自动检查（交付物里出现那个打不开的默认域名，会把检查弄红）。
代价是：码里的内容一旦定下来就改不了。 所以生成之前必须先确认好地址——这是为什么「到底该用哪个域名」这件事在本项目里被反复核对， 甚至专门做了自动检查（交付物里出现那个打不开的默认域名，会把检查弄红）。
每条码扫了多少次也有记录，方便看哪个渠道真的有效。这些码挂在
wechat_qrcode 这张表里，图片本身存在对象存储。