一次外部合作邀约，引出一个更该回答的问题
买一个应用，
还是建一座底座？
对方带来一套做好的 AI 应用；我们手里，是三条已经在跑的数据线。
内部数据 + 外部数据 → 管理参考与经营指导。没有底座，AI 只会把噪声反射得更快。
仅使用公开渠道信息与站点实测
41 个场景清单与分期成本测算
推断类内容均已单独标注
对方到底拿来了什么？
先看清对面。只列公开查得到的事实，不做评价；事实本身会说话。全部来自公开渠道与站点实测，时间为 2026-11-03。
录本仓（成都）企业管理集团
2023-02 成立 · 注册资本 50 万 · 参保 11 人 · 未见融资
新设、小规模、无外部资本。持续投入与抗风险能力，只能靠合同条款兜底，不能按规模假设。
软件著作权 0 件 · 专利 0 件
没有为软件产品做过确权登记。软著登记成本低、周期短，这项为零，是产品化程度的一个反证。
/app /login /demo /pricing 均返回 404 · 无具名客户案例
公开层面没有可试用、可验证的产品。对外呈现的是预约制项目服务，不是标准化产品。
/privacy /terms /legal 均 404 · 未见 SOC2 / ISO / 等保 · 无“不用于训练”承诺
没有可签署、可审计的安全基线。接入经营数据前，缺的不是态度，是文件。
纯静态站 + Vercel 托管 · 20+ 个手写 CSS，多为 review-polish 这类补丁命名 · 无构建、无埋点
低成本快速上线，工程化程度低。界面可以做得像，系统能力不能靠界面证明。
页面仍保留“Pinterest 视觉参考占位 · 仅用于内部评审”
说明上线前缺少发布检查。对外站点尚且如此，交付到我们这里的质量，必须写进验收。
9 个模型 logo 自带“不表示均已接入” · 英文页写 “Deployed project”，中文页写“示意对话”
模型名单不能当技术证据。中英文口径不一致，案例强度被高估。
500 万/年 · 233% ROI · 自标“不是已实现的客户结果”
这是测算目标，不是实测值。立项不能拿它当依据，验收口径要按我们自己的基线另定。
公平记录 / FAIR NOTE
2025-09 中标成都华润置地驿都“东安湖商业项目品牌故事线设计”询比采购。商业地产的行业理解有真实来源；但这属于设计与品牌咨询交付，不等于 AI 产品被采购过。
推断 / INFERENCE非事实
官网为 AI 辅助 / 模板化快速搭建的置信度；产品本体无法访问，故整体判断低于官网。
对方拿得出的是“人和关系”，拿不出的是“可审计的系统”。这不是道德判断，是交付结构的判断。
交换对等吗？
把两边的能力拆到八个维度。结论不是谁强谁弱，而是谁能替谁，谁不能。
壁垒排序：关系 > 行业语料 > 内容产能 > 技术。我们缺内容产能，对方缺数据与系统。交换不对等，原因在这里。
也要承认一项：对方在品牌设计与内容产出上有真实积累，这一项我们不占优。所以这不是“对方一无是处”，而是“拿我们的数据去换，不划算”。
11 城市场数据，能不能变成可决策的看板？
能。这条链路我们自己走通了：采集、清洗、聚合、发布，全部可重跑，不依赖外部 BI 厂商。
覆盖城市
未清洗
一行 = 一个物理门店
首屏只读结果
本机实测区间
条
清洗不是格式活，它改变结论
同一份数据，去重前后会得出两个不同的品牌榜。这类错误带进汇报，比没有数据更糟。
- 25,141 行在入库时被合并：17,511 行完全重复，7,630 行同城同名
- 未清洗前，品牌门店数第一是良品铺子 1,205 家
- 清洗后降至 757 家，星巴克升至第一
口径：一行 = 一个物理门店；同城同名且无分店后缀的，按指纹合并。原始 292,762 行 → 主档 267,621 行。
停车数据，能不能变成客流和铺位价值？
方案 v9.1 已经把链路画出来了。先把确定的部分讲清楚：规模、现状、路径；没有实测的数，就标“待补”。
B3 + B4 + B5
方案 v9.1
完整运行
反寻繁琐 / 客流缺失
入场车流
出入口抬杆与车牌识别，回答“来了多少车”。
待补车位与周转
总车位已有；周转率回答“车位够不够”。
车位已有 · 周转待补缴费与无感支付
科拓缴费记录，回答“临停贡献多少”。
现有系统分时段峰值
工作日 / 周末 / 节假日，回答“什么时候缺”。
待补商场客流
车流是否转化为人流、停留多久。
精准客流待建铺位价值
可达性 × 停留 × 转化，回到招商与定价。
需合同台账链路怎么读
停车是商场里唯一能全天候、按楼层捕获“到场行为”的传感器。它不直接产生租金，但它决定租金怎么定、铺位怎么调。
车流回答“来了多少”；周转回答“车位够不够”；缴费回答“临停贡献多少”；峰值回答“什么时候缺”；客流回答“人是否真的进店”；铺位价值回答“这一层该不该调改”。这六问，正好接上招商与运营的日常决策。
方案路径：从 B3 往外长
- 一期
B3 · 反寻 + 导航
先解决“找车难”，在不推翻科拓的前提下叠加感知与导航层。
- 二期
B4 · 扩展 + 全场客流 + CRM
车流数据开始与会员、客流打通，支撑楼层级经营分析。
- 三期
B5 · 扩容 + 店铺级客流 + AVP
从“停车管理”走到“商业空间运营”，接入招商调改。
来源：重庆新光城 · 智慧停车场升级建设方案 v9.1（内部方案）。本页只引用规模、分区与路径，不引用供应商报价。
三块数据，靠什么接成一张可信的答案？
三层结构 + 四段流水线 + 一道门禁。缺任何一层，问答都会变成看起来合理的猜。
应用层
部分看板与报告已在用；问答与预警待建。没有 L2，它们只是生成器。
指标与事实层
部分现有看板已有口径文档；字典、版本、owner 与 fact_id 制度待建。
数据与口径层
部分内部经营数据部分
合同、租金、收缴、销售上报、客流、会员、能耗工单；分散在财务、POS、停车与会员系统，POS 覆盖率不足 70% 时 Phase 2 不启动。
外部数据已有 + 待建
11 城商户快照、品牌门店已有；竞品租户、商圈消费力待建。外部数据只做参照，不替代内部台账。
四段流水线：门禁在部署之前
三块实绩，拼起来是什么？
不是三个项目，是一条链的三段：停车给场内客流，BI 给外部参照，底座把两者接起来。
停车
车流、车位周转、缴费与分时段峰值；回答“人有没有来、什么时候来”。
11 城 BI
商户快照、品牌门店、人均价带；回答“同城同业态，我们处在什么水位”。
内部台账
合同、租金、收缴、会员；回答“钱从哪里来、哪里在漏”。
数字底座
L1 数据与口径 → L2 指标与事实 → L3 应用；口径、权限、事实包都在这里收口。
管理参考与
经营指导
结论卡、自动报告、预警、问答；每条结论带 fact_id，可回溯。
分工：内部数据解决“管理与发现问题”，外部数据解决“对标与定价参照”。两者只有同城市、同业态、同口径才可比；跨城、跨业态的差值只能当线索，不能当结论。
这个铺位的租金，在同城同业态里是高还是低？
外部对标 + 内部合同活动期间的客流，是真进店，还是只停了车？
停车 + 会员 / POS收缴率下滑，是哪个业态、哪一层先出问题？
内部台账 + 统一口径缺的不是能力，是算力预算、数据授权，和 1.5–2 个稳定的人。
Phase 2 目标 180+
数字白名单校验
含 40 题陷阱题
千元级
这一票，具体拍什么？
不用现在决定买不买。先批三件事，用约 5.5 个月、三段验收，把答案做出来；每一段不达标就停。
批算力预算
Phase 1 起千元级 / 月；敏感域要不出网，再单独批硬件或专有云。
授数据范围
合同、收款、POS、客流、会员按最小必要开放；先脱敏，后接入。
定指标 owner
每个指标一个 owner、一个定义、一个版本；变更升版本，历史冻结。
零成本证明
只用已有公开数据与看板：3 张“我们 vs 11 城同业态”对标卡、指标字典 v0、合成 Demo 库；不碰内部库、不调模型 API。
一个业务域跑通
财务域先上：收缴率、欠缴账龄、收入结构、租售比异常。80 题准确率 ≥ 90%，数字编造率为 0。
四域打通
运营、招商、财务、营销全部可用；180+ 指标；敏感域切私有化；60 人开通，月活 ≥ 60%。
首年 TCO 对比
不含内部人力机会成本 / 量级估算建议先用公网路线跑 6 个月，用真实的敏感度争议决定是否加钱上私有化，而不是一开始就买 GPU。Phase 2 的前置条件：POS 覆盖率 ≥ 70%、1.5–2 人稳定投入、每个指标有 owner。
买别人的应用层，是一年的使用权；
投底座，是自己的资产。