云选通智能选址系统
产品经理作品集
1社会困境与机会洞察
在中国,近 500 万大龄孤独症人群的就业率不足 5%,背后是数百万个渴望融入社会的人生和家庭沉甸甸的期待。团队深入浙江 7 市 15 县调研,发现大龄星青年服务具备广阔市场和巨大发展潜力,但现实降下三重枷锁:
| 问题层 | 现场表现 | 对产品设计的要求 |
|---|---|---|
| 机构支持薄弱 | 社会服务集中在早期干预,成年后的岗位与支持不足 | 不能只做一次培训,须覆盖评估、上岗和在岗支持 |
| 大龄服务断层 | 成年后政策帮扶断崖,传统辅助就业依赖捐赠难持续 | 须让岗位嵌入真实经营,用营收承担部分成本 |
| 社会融合机制缺失 | 即便经过培训,劳动效率仍难达到完全竞争市场要求 | 须设计有壁垒保护的就业环境,而非直接推向竞争 |
当前社会面向心智障碍青年的传统帮扶模式与技能培训,无法将其推向完全竞争的劳动力市场。团队访谈 10+ 企业、5 位残障服务专家、30+ 孤独症家庭,明确三大核心需求目标:孤独症青年上岗路径、商业造血能力、规模化复制机制。



2第四空间:有壁垒保护的就业环境
第四空间不同于传统的居住(第一空间)、工作(第二空间)和公共社交(第三空间)三类空间,通过制度支持、技术赋能与场景共创,使星青年在一个有支持、可持续的场景中创造真实价值——定义为生产、销售和公益活动一体化空间。它包含四个同时成立的产品层:
| 层级 | 内容 | 为什么必要 |
|---|---|---|
| 制度支持 | 政企协同、公益合作、场地准入、责任边界 | 解决普通商业项目难以进入特定载体的问题 |
| 技术赋能 | 智能选址、点位评估、就业档案、运营监测 | 让经验可沉淀和复制 |
| 生产销售 | 生产、零售、团体订单和活动服务 | 形成真实业务和岗位 |
| 价值循环 | 公益活动、社区互动、企业 ESG 和品牌传播 | 让社会价值反向带来场地、订单与合作 |

3第一层 · 破局点:政策特许型商业点位
本项目针对轻餐饮与零售场景
在完全开放的市场中,仅靠公众爱心难以持续,项目的可持续性必须源于结构性优势。突破口在于:通过项目的公益属性,获取"特许经营资格"的独特资源——许多场地原本无法进行商业开发,但一旦承载"残疾人融合就业"的使命,便能获得政府、残联及物业的多方支持,突破常规商业限制,转化为具有选址优势和稳定性的助残点位。
政策特许型准入的四大场景
| 场景类别 | 具体载体 |
|---|---|
| 国资载体 | 交通站点、市民中心、社区服务点/办事处、慈善基地、景区、城投社区商铺 |
| 商业空间 | 商场、文创街区公益专属铺位 |
| 产业校园 | 高校、企业园区、科创产业园配套商铺 |
| 公共点位 | 公园、广场合规点位 |
不把特殊青年直接推向激烈竞争市场,而是优先发现低竞争、高扶持的切入点——这构成了可持续商业模型的基石。我们的核心能力之一,便是系统化地发掘、评估与开发这类政策特许型商业点位。为此,我独立研发了云选通智能选址系统(Part II 详述),整合客流、商圈评估、政策支持与可行性、公益无障碍等多维数据,精准锁定适合星青年就业且具备商业潜力的位置,形成项目坚实的竞争壁垒。

4第二层 · 支撑体系:全流程赋能模型
点位只是起点,支撑其长期稳健运营才是关键。我们摒弃简单安置,为星青年构建"有支持、可成长"的工作环境。
融合编组与岗位拆解
人员配置采用 1+N+N 融合工作动态配比模型(店长 + N 普通员工 + N 星青年员工)作为基础配置,按任务复杂度、变化频率和社交要求拆解岗位,而非按诊断标签分工:普通员工负责统筹运营、核心制作、客户对接和带教星青年等变化快、社交复杂的环节;店长负责异常处理与灵活决策;星青年承担"结构化、低变化、弱社交"的标准化基础岗,按茶咖、烘焙、零售等业态的客单节奏、制作复杂度与社交压力测算最优人力结构,在成本可控与服务质量之间取得平衡。
星青年在点位中承担的具体岗位
| 星青年岗位 | 工作内容 | 岗位拆解依据 |
|---|---|---|
| 烘焙制作 | 按标准配方和流程完成烘焙品的搅拌、成型、烘烤 | 流程固定、可重复,动作精细度可训练 |
| 咖啡饮品制作 | 按标准菜单完成咖啡和饮品的制作与出杯 | 步骤明确、配方定量,社交交互集中在递杯环节 |
| 包装陈列 | 负责成品包装、标签贴附和货架陈列维护 | 视觉有序性强、任务边界清晰 |
| 店铺清洁 | 维护操作台、设备和公共区域清洁 | 固定时段、固定区域、低社交压力 |
| 扫码收银 | 使用扫码设备完成商品结算 | 操作标准化,顾客交互短促可控 |
| 基础顾客服务 | 迎客引导、简单问询应答和秩序维护 | 语言交互量小,可预设话术模板 |
岗位设计拆解点位的真实业务需求,将复杂工作流程分解为备料、包装、收银、清洁等标准化、可重复的结构化岗位,让星青年在能力适配的岗位上创造真实价值,避免纯安置性就业。
服务标准:12 项 SOP 手册
牵头制定覆盖点位运营全流程的 12 项标准化操作手册,包括出餐动线、卫生管控、库存管理、星青年在岗支持规范等,将经验固化为可复制、可培训的操作指引,确保新点位快速上手、老点位稳定输出。
就业档案 SaaS 系统 + 三全培育
建立"人-岗-点"三方资源库,整合星青年能力画像、点位运营数据与岗位需求清单;利用 SaaS 持续追踪就业表现,基于数据分析反向优化培训、岗位适配规则与支持策略。岗前实施"全面培训、全心陪练、全程陪护"的三全培育,利用就业点位的真实场景开展模拟实训,由就业导师等特教人员提供在岗支持;在岗以星青年兴趣特长为核心,实行"评估—培训—上岗—督导"全流程支持,确保自然支持体系建立与人岗精准匹配。


5第三层 · 盈利与循环:供应链服务
点位只是起点,供应链的规模化运作是项目自我造血的核心。对 13 家设备商、原料商比价谈判敲定集采目录,设备统一供应、原材料集中采购;建立补货台账与进销存动态库存管控,结合点位销售数据分析与成本测算,以采养点。自营品牌输出并支持加盟,统一采购原料与设备、标准化管理,用规模效应支撑多点位复制。

6商业闭环、收入结构与落地验证
前五节分别回答了“为什么做、在哪里落地、如何支持上岗、怎样规模复制”。本节集中说明各方如何交换价值、项目如何形成收入,以及收入如何反哺点位与就业支持。
价值交换与收入来源
| 对象 / 轨道 | 项目提供的价值 | 合作方获得的价值 | 项目收入或关键资源 |
|---|---|---|---|
| To G 政府、残联、街道 | 就业信息档案 SaaS、星青年人岗匹配、社区融合就业点位和项目执行能力 | 完成公共就业服务与基层助残目标,获得可追踪、可复制的项目成果 | SaaS 与技术服务、政府购买服务、项目采购,以及政策和空间资源支持 |
| To B 企业、园区、加盟方 | 智能选址 SaaS、可量化 ESG 方案、结构化岗位、标杆场景、品牌输出、供应链与标准化运营 | 获得可审计的选址决策依据、社会价值案例及员工与客户参与场景,并降低加盟点位的开店和运营门槛 | 智能选址 SaaS 与决策服务、ESG 项目服务、加盟及点位分成、企业采购、设备与原材料供应利润 |
| To C 消费者 | 烘焙、饮品、零售商品和活动服务,以及可感知的融合就业消费场景 | 获得商品与服务,同时通过日常消费参与社会融合 | 商品销售和活动服务收入,并持续验证产品、价格与点位模型 |
| 生态支持 NGO、基金会、特教机构 | 就业信息档案 SaaS、星青年人岗匹配与就业追踪工具,以及联合项目载体、真实就业场景和可衡量的社会影响 | 将学生就业信息、专业导师、志愿者、公益资金与传播能力转化为可持续、可追踪的项目成果 | 项目资源、专业支持、公信力和成本协同,不作为单一商业收入计算 |
盈利逻辑:智能选址 SaaS 与决策服务、设备与原材料供应、加盟及项目服务和 To C 商品销售共同构成核心经营收入;政府购买服务与企业采购进一步扩大项目规模,政策、空间及公益资源用于降低固定成本。经营结余继续投入产品迭代、新点位拓展、培训和在岗支持,形成“产品与经营收入 → 就业支持 → 点位复制 → 数据沉淀与规模采购”的回流。

合作与资金回流
政府和街道提供政策、空间与公共服务连接,NGO 和特教机构提供专业支持与公信力,企业和加盟方提供岗位、订单、场景及经营网络,消费者贡献持续交易。项目方将这些资源组织成“吸纳—培训—上岗—经营—反哺”的闭环:加盟方聚焦经营与人员支持,星青年获得收入和职业成长,项目方以供应链、服务和经营收入继续扩大点位与赋能体系。

标杆案例:成功运营"众 E 空间"烘焙工坊、爱心餐车、蓝星超市等标杆案例,为政府、企业提供了可量化、可复制的全流程赋能服务与 ESG 解决方案。
合作伙伴:携手阿里巴巴公益、众安慈善基金会、余杭区残联、云上公益等机构建立深度合作。
落地数据
项目获得央视新闻等国家级媒体关注和领域专家高度认可。
1行业痛点与产品定位
聚焦的痛点:轻餐饮与零售选址场景下,门店、餐车、第四空间三类点位的选址面临四个行业级问题:
| 痛点 | 现状 | 后果 |
|---|---|---|
| 选址周期长 | 人工收集信息、整理对比、多方确认 | 决策方畏难,开店/扩张受阻 |
| 决策难度高 | 客流、商圈、政策、竞品信息分散在各处 | 无法快速判断"先实勘哪里" |
| 政策类选址无工具适配 | 现有选址软件不识别公益属性带来的准入机会 | 融合就业项目被迫与普通项目正面竞争 |
| 信息可信度低 | 大量依赖经验判断,缺乏可追溯的证据 | 决策质量无法评估和复现 |
产品定位:面向轻餐饮与零售行业的连锁品牌加盟商、品牌自营选址人员与小微品牌/创业者的 AI 辅助选址决策平台,用真实 POI、空间分析、政策证据和多 Agent 协作,筛选更值得实勘的点位。产品位于选址漏斗的"需求定义 → 初筛 → 证据分析 → 实勘决策"阶段,不是租赁成交平台。
目标用户:三类角色带着不同的决策情境使用同一平台
目前聚焦轻餐饮与零售行业
品牌扩张中需要快速筛出值得实勘的铺位——系统以 3 个附成本解释的候选点替代无边界搜索,缩短从意向到实勘的周期
需要批量调研、口径统一、结论可沉淀——系统提供统一报告、版本与审计轨迹,分析资产不随人员流失
缺少选址经验与判断框架——系统理解个性化需求,直接给出选址建议与 30 天行动项
三类用户均分为普通类型与特殊群体融合就业类型——平台以完整的普通商业选址能力为基础,融合就业的政策能力从普通商业型中分叉嵌入,不压窄用户群体。两者的差异体现在:仅当项目类型选择"政策特许 / 减免申请型"时,才能选择第四空间载体;且多目标优化加权评分算法的权重不同:
残障/特殊青年不直接使用系统选址:他们在培训机构完成培训后,被分配至选址完成的点位上岗;若有开店意愿,则以加盟商身份进入系统。特殊群体赋能机构同理不参与选址,由品牌运营方完成选址。
2三大核心差异化
针对上述痛点,云选通形成三点传统选址软件不具备的差异化:
| # | 创新点 | 传统选址软件 | 云选通 |
|---|---|---|---|
| 1 | 第四空间与餐车作为独立经营载体纳入选址 | 仅关注普通门店,最多区分商场店/街边店 | 将第四空间(生产+销售+公益活动一体化空间,仅政策特许型可选)与餐车(移动/固定)作为两类独立经营载体纳入选址,让融合就业项目能寻找适合培训、就业、经营与社区互动同时发生的复合空间 |
| 2 | 识别政策减免/补贴 + 发现公益准入点位 | 按商圈热度、租金、客流或竞品排序,无法表达公益属性带来的场地机会 | ① 当选择项目类型为政策特许 / 减免申请型时,自动识别选址区域的政策减免与补贴机会;② 发现"普通店铺无法准入但因公益属性可以准入"的点位(社区指定服务点、国资公共载体、慈善基地、高校/园区配套等)——不把特殊青年直接推向激烈竞争,而是优先发现低竞争、高扶持的切入点 |
| 3 | 真正的 AI 智能选址决策 | 各维度信息分散,需人工从海量数据中整理;工作流固定;无个性化需求识别;无交叉分析;不输出决策结论 | AI 理解个性化需求 → 多维度交叉分析(客群×商业×交通×政策×无障碍)→ 生成决策结论(候选排序+风险+行动项)。从"信息工具"升级为"决策工具" |
3产品架构与设计
3.1 功能结构与用户流程图
graph TD L[注册 / 登录] --> A[工作台
选址需求输入] A -->|点击「开始调研」| B[AI 调研流程
意图理解 + 四专项并行 + 综合决策] B --> C[选址调研
任务状态 + 四大专项分析] C --> C1[客流分析] C --> C2[商圈评估] C --> C3[政策分析] C --> C4[公益无障碍] B --> E[数据洞察
综合推荐 + 偏好建议 + Top 3 对比] C -->|复核专项依据| E B -.-> D[地图探索] D --> D1[客流热力] D --> D2[交通覆盖] D --> D3[消费潜力] D --> D4[竞争环境] D -->|交叉核验| E E -->|选择点位| F F -->|生成报告| G[报告中心
查看 / 下载 / 归档] E -->|收藏备选| H[收藏夹
持续跟踪 / 返回对比] H --> E I[系统设置
权限与规则配置] -.-> A
流程说明:用户注册登录后在工作台输入选址需求,点击"开始调研"后,系统先理解个性化诉求并完成候选召回与硬条件校验,再并行执行四项专业分析,最后由综合决策 Agent 识别跨维协同、冲突与取舍并形成排序。完成后,用户可在选址调研页查看任务状态和专项依据,在数据洞察页完成综合推荐、偏好建议与 Top 3 对比,并通过地图探索交叉核验;选定候选点后生成报告,在报告中心查看、下载和归档,未入选但值得复核的点位可加入收藏夹持续跟踪。
3.2 信息架构与数据模型
数据从原始需求到可追溯的决策报告,18 张 PostgreSQL 数据表完整呈现如下。所有业务表启用 PostgreSQL 行级安全(RLS),按 tenant_id 自动隔离租户数据。图中同时标注中文业务名称与英文表名:
graph TB
subgraph IDENTITY[租户与身份 · 5 张]
ORG[组织
organizations] --> MEMBER[组织成员关系
user_organizations]
USER[用户
users] --> MEMBER
USER --> SESSION[登录会话
sessions]
ORG --> SETTING[租户设置
tenant_settings]
end
subgraph BUSINESS[选址业务 · 4 张]
RESEARCH[调研任务
research_runs] --> AGENT[Agent 执行记录
agent_runs]
RESEARCH --> CANDIDATE[候选点快照
candidates]
RESEARCH --> REPORT[报告版本
generated_reports]
CANDIDATE -->|选定点位| REPORT
end
subgraph POLICY[政策知识库 · 3 张]
SOURCE[政策来源
policy_sources] --> VERSION[政策版本
policy_versions]
VERSION --> CHUNK[政策分块与向量
policy_chunks]
end
subgraph GOVERNANCE[运行治理 · 6 张]
AUDIT[审计日志
audit_logs]
ERROR[应用错误
application_errors]
SCHEDULE[调度记录
scheduler_runs]
RUNTIME[运行时文档
runtime_documents]
MIGRATION[迁移任务
migration_runs] --> SCHEMA[数据库版本
schema_migrations]
end
ORG --> RESEARCH
ORG --> AUDIT
RESEARCH --> AUDIT
AGENT -.记录政策引用.-> CHUNK
SCHEDULE -.定时同步.-> SOURCE
RUNTIME -.保存权威状态.-> RESEARCH
ERROR -.关联请求.-> AUDIT
18 张 PostgreSQL 数据表分为四层:
| 数据层 | 核心表 | 职责 |
|---|---|---|
| 租户与身份 | 组织(organizations)、用户(users)、组织成员关系(user_organizations)、登录会话(sessions)、租户设置(tenant_settings) | 多租户隔离、RBAC 权限、会话管理 |
| 选址业务 | 调研任务(research_runs)、Agent 执行记录(agent_runs)、候选点快照(candidates)、报告版本(generated_reports) | 保存需求、证据、Agent 判断、候选结果与正式报告 |
| 政策知识库 | 政策来源(policy_sources)、政策版本(policy_versions)、政策分块(policy_chunks,含 pgvector 1024 维向量列) | 政策全文版本管理、分块向量化、混合检索 |
| 运行治理 | 审计日志(audit_logs)、应用错误(application_errors)、调度记录(scheduler_runs)、运行时文档(runtime_documents)、迁移任务(migration_runs)、数据库版本(schema_migrations) | 审计、错误追踪、调度、运行状态与迁移治理 |
3.3 目标决策链路
统一评分口径:推荐分 = 四项专业得分按本次需求权重加权 + 跨维影响调整,最终限制在 0–100 分。专业 Agent 可在证据基础分上做有界校正(高/中/低置信度分别最多 ±8/±5/±2 分);综合决策 Agent 可根据跨维协同或冲突给出 −10~+10 分调整,并因此改变相近候选的名次。调整必须引用同一候选至少两个不同专项的证据;高/中/低置信度由服务端再限制为 ±10/±6/±3 分,证据不足则归零。
不可突破的边界:AI 不能恢复被硬条件排除的点位,也不能改写地址、坐标、租金、POI 数量等客观事实;最终数值、引用有效性、调整幅度和排序均由服务端校验与计算。模型不可用时自动降级为确定性结果。
3.4 Agent 架构选型
| 候选架构 | 为什么没有选 | 与本项目的关系 |
|---|---|---|
| 单 Agent | 上下文混杂、专业边界弱,难判断结论来自哪类证据 | 不利于四维独立比较与审计 |
| ReAct | 开放式“思考—调用—观察”循环会让调用次数与耗时波动 | 选址链路稳定,不需要无上限探索 |
| Plan & Execute | 每次先动态规划会增加一次规划成本,且同类任务计划高度重复 | 适合开放任务,不适合本项目固定决策链 |
| Router + Skill | 路由到单个能力会漏掉必须同时比较的客流、商圈、政策、公益四维 | 本项目不是“选一个专家”,而是“四项必做后再综合” |
| Blackboard | Agent 自由读写共享黑板虽然灵活,但归因、并发冲突和结果复现更难 | 当前只需要受控共享状态,无需开放式协商 |
| 受约束 Graph Multi-Agent | 固定依赖、并行专项、结构化输入输出、服务端统一校验 | 兼顾智能性、响应效率、成本预算、审计与降级,是本项目最合适的组合 |
6 个 AI 节点与模型分工(单次选址调研模型成本约 0.05 元,耗时约 30 秒)
| 节点 | 职责 | 模型策略 | 选择理由 |
|---|---|---|---|
| 意图理解节点 | 在不覆盖显式表单的前提下,提取软偏好、取舍、缺失信息和四维权重 | Qwen Flash | 输入短、结构固定,需要快速稳定的 JSON 输出 |
| 客流 Agent | 判断客群来源、时段互补、转化条件及需核验的客流假设 | Qwen Flash | 证据已结构化,主要任务是逐点比较与因果表达 |
| 商圈 Agent | 判断配套、竞品、成本与载体适配之间的机会和挤压关系 | Qwen Flash | 结构化商业诊断可用快速模型完成 |
| 政策 Agent | 结合官方政策 RAG 比对适用条件、支持机会、限制与办理路径 | Qwen 3.7 Plus | 涉及长文本、条件推理和引用一致性,质量优先 |
| 公益无障碍 Agent | 判断交通与公共服务是否支持稳定通勤、就业运营和现场无障碍 | Qwen Flash | 以结构化站点和设施证据为主,需低延迟并行 |
| 综合决策 Agent | 跨四维发现协同、冲突和取舍,给出有证据引用的影响调整与排序理由 | Qwen 3.7 Plus | 承担全局比较和反事实权衡,是最需要推理能力的节点 |
4核心功能展示
4.1 工作台
用户注册/登录后进入工作台首屏,在一屏内完成选址需求的全量配置。系统将表单字段映射为统一的 ResearchIntent——显式槽位优先,自由文本补充提取。表单字段及规则如下:
| 字段 | 可选值 | 规则约束 |
|---|---|---|
| 项目类型 | ① 政策特许 / 减免申请型 ② 普通商业型 | 选择基准权重方案:政策型更关注政策与公益适配,普通商业型更关注客流与商圈;意图理解节点再结合核心诉求和自由文本调整软权重并归一化为 100% |
| 经营形态 | 普通门店 / 餐车(移动/固定) / 第四空间 | 三种形态使用不同载体适配规则和成本模型;第四空间仅在项目类型为"政策特许 / 减免申请型"时可选 |
| 目标城市 | 杭州市(固定,其他城市置灰不可选) | 首期聚焦杭州,后续扩展 |
| 杭州区域 | 13 个市/县全选或区域筛选 | 上城、拱墅、西湖、滨江、萧山、余杭、临平、钱塘、富阳、临安、桐庐、淳安、建德 |
| 门店面积 | 20㎡ 起步,一档递增,最高 180㎡ | 普通门店限定 20–180㎡;餐车固定按 20㎡ 设备规格核验,面积不可调;第四空间面积必须大于 60㎡——定义为生产、销售、公益活动的一体化空间 |
| 月租预算 | 2000 元/月 起步,一档递增,最高 20000 元/月 | 硬约束:超预算候选不得进入最终结果,优先级高于评分 |
| 核心诉求 | 高客流 / 政策支持 / 临近地铁(多选) | 选中的诉求影响 Agent 分析重点和报告排序说明 |
| 其他要求 | 自由文本输入 | 可补充"临街、可外摆、邻近学校/园区、公益合作、无障碍设施"等长尾需求,系统用 AI 提取为隐式槽位 |
表单联动规则:选定项目类型后,系统切换基准权重方案,核心诉求与自由文本用于形成个性化分析权重;第四空间载体仅在"政策特许 / 减免申请型"下开放。选定经营形态后,面积范围自动适配——选择"第四空间"时面积下限强制设为 60㎡,选择"餐车"时面积固定 20㎡ 且不可修改。预算、面积、区域和载体准入始终是硬条件,不因 AI 偏好而放宽。


4.2 AI 智能选址调研
用户在工作台点击"开始调研"后进入选址调研页,系统执行完整的决策链路:
显式表单字段优先,AI 从自由文本识别软偏好、可接受取舍、缺失信息与四维关注权重
杭州 13 区县网格化搜索;区域、预算、面积、载体准入不满足即排除,AI 无权恢复
基于确定性基础分、区域多样性与最小空间距离保留最多 6 个候选,避免只分析同一区域的相邻点
分别获取每个候选的高德周边 POI、交通站点、成本估算和政策 RAG 证据,不复用第一名数据
按“证据 → 经营影响 → 机会/风险 → 核验动作”分析,并对各自维度基础分做有界校正
按个性化权重计算专业综合分,综合决策 Agent 再识别跨维协同、冲突与取舍,可在证据约束下调整相近候选排名
服务端校验事实、证据引用与调整幅度后计算推荐分,输出排序、主要依据、风险与下一步行动
每个候选点生成独立的证据包,包含基础位置、载体类型、成本估算、周边活力、商业环境、交通、政策和招商线索。

4.3 四大专项分析
在选址调研页点击"查看结果"后,跳转至四个专项 Agent 的详细分析页面,输出候选点证据所代表的经营影响、候选差异、机会、风险与核验动作。
| Agent | 分析职责与输出边界 | 模型策略 |
|---|---|---|
| 客流分析 | 分析餐饮、办公、住宅和教育等 POI 所代表的客群来源、时段互补与转化条件;POI 只作为潜在客流证据,不等同真实人流 | Qwen Flash:证据结构规则、比较任务明确,优先速度与成本 |
| 商圈评估 | 分析商业配套、同类竞品、租金成本和载体适配之间的机会与挤压关系,结论限定在商业经营判断范围内 | Qwen Flash:结构化商业诊断,低延迟并行执行 |
| 政策分析 | 基于官方政策依据分析租金减免、场地合作、优先支持机会及适用条件;引用必须来自检索结果,不承诺审批或减免结果 | Qwen 3.7 Plus + RAG:需要长文本理解、条件比对和引用约束 |
| 公益无障碍 | 分析真实交通站点、公共服务、助残就业运营适配与现场无障碍条件,政策减免结论由政策 Agent 提供 | Qwen Flash:基于结构化交通与公共服务证据快速判断 |
| 共同安全护栏 | 不得虚构客流、订单、租赁报价或补贴金额,不得改写候选名称、地址、坐标、租金及 POI 数量等客观事实;专项校正受证据与置信度上限约束,跨维调整必须引用至少两个不同专项证据;AI 可调整相近候选顺序,但不能恢复被硬条件排除的点位。模型不可用时自动降级为确定性结果。 | |
政策分析 Agent 使用关键词 + pgvector 向量混合检索,从官方政策全文库中检索适用条款。入库来源限定中国政府网、残联、人社局等官方 HTTPS 域名;政策版本支持草稿、发布、归档和回滚,已发布版本不可变并保留 SHA256 哈希;每项引用携带标题、发布机构、条款号、版本号和原文链接,确保可追溯。




4.4 地图探索 — 四维交叉分析
通过左侧导航栏进入。同一组候选点位在四个维度下分别呈现,用户通过切换标签对比不同维度的空间分布,形成交叉判断。
| 维度 | 回答的问题 | 地图可视化 |
|---|---|---|
| 客流热力 | 周边商业活动有多活跃? | 暖色圆面标注餐饮商业活跃节点,蓝色圆面标注办公需求节点 |
| 交通覆盖 | 候选点 1km 服务圈内交通够不够? | 蓝色服务圈 + 青色交通/公共设施节点 |
| 消费潜力 | 周边有没有消费场景? | 蓝色节点标注办公需求,黄色节点标注购物与餐饮 |
| 竞争环境 | 周边同类竞品多不多? | 紫色节点标注烘焙/甜品竞品,紫色虚线圈标注竞争观察区 |




4.5 数据洞察
通过左侧导航栏进入,也可跳过地图探索直接到达。看板统一展示每个候选的四项专业得分、个性化权重、专业加权分、跨维影响调整与最终推荐分,让用户看清“原始证据如何影响专项判断、专项判断如何形成最终排序”。交叉分析重点呈现协同、冲突与取舍,而不是重复四个专项的结论;用户在此完成“哪个候选更值得优先实勘”的判断并选择点位生成报告。

4.6 报告中心
用户在数据洞察或地图探索中选择候选点后,系统冻结本次证据并生成正式报告。报告面向业务用户使用“推荐分、专业得分、综合影响”等产品化语言,包含候选点信息、最终 Top 3 对比、统一评分构成、成本与减免情景、四项专业判断、跨维协同/冲突、风险、30 天行动计划和政策引用。专项内容按“判断—关键证据—核验动作”去重呈现。支持在线预览、HTML 下载、版本生成和归档。
未确认点位前仅保存调研草稿,不生成对外正式报告。




4.7 权限管控与系统记忆
三级角色权限矩阵
系统采用 RBAC(基于角色的访问控制)+ 多租户隔离架构,所有业务表启用 PostgreSQL 行级安全(RLS),按 tenant_id 自动隔离,确保租户 A 无法读取租户 B 的任何选址记录。
| 权限 | 平台超级管理员 | 平台运营管理员 | 选址用户 |
|---|---|---|---|
| 执行选址调研 | ✓ | ✓ | ✓ |
| 管理自己的报告 | ✓ | ✓ | ✓ |
| 查看系统配置(只读) | ✓ | ✓ | ✓ |
| 管理普通用户 / 重置密码 | ✓ | ✓ | ✗ |
| 查看错误日志 | ✓ | ✓ | ✗ |
| 管理企业 / 创建企业 | ✓ | ✗ | ✗ |
| 管理平台管理员 | ✓ | ✗ | ✗ |
| 政策版本管理 | ✓ | ✗ | ✗ |
| 切换企业数据空间 | ✓ | ✗ | ✗ |
| 查看所有租户选址记录 | ✓ | ✗ | ✗ |
| 修改系统设置 | ✓ | ✗ | ✗ |
运营管理员只能管理普通用户,不能查看或操作平台管理员账号;至少保留一名活跃超级管理员,防止锁死。
安全机制
| 机制 | 实现 |
|---|---|
| 密码存储 | scrypt 哈希(随机盐 + 64 字节密钥),禁止明文存储 |
| 密码策略 | 至少 10 位,必须同时包含字母和数字;首次登录强制改密 |
| 会话管理 | 7 天 TTL,HttpOnly + SameSite=Strict Cookie,Token 经 SHA-256 哈希存储 |
| 登录限流 | 同一 IP + 邮箱组合 5 次失败后封禁 15 分钟 |
| 注册限流 | 同一 IP 每小时最多注册 5 次 |
| 租户隔离 | PostgreSQL RLS 策略,每条业务数据按 tenant_id 强制隔离 |
| HTTPS 强制 | Cookie 在 HTTPS 下自动添加 Secure 标记 |
系统记忆与可追溯性
系统的"记忆"分为四个维度,确保每个决策都可审计、可回溯:
| 记忆维度 | 存储机制 | 作用 |
|---|---|---|
| 政策知识记忆 | policy_versions(不可变)+ policy_chunks(pgvector 1024 维 HNSW 向量索引) | 政策全文版本化存储,已发布版本不可变(SHA-256 指纹),支持草稿→发布→归档→回滚全生命周期;向量索引支持语义检索 |
| 决策过程记忆 | research_runs + agent_runs + candidates | 每次选址调研的输入、意图理解、四专项分析、综合决策执行记录(模型、Token、成本、证据与调整依据)及候选点状态完整保存,可复盘 6 个 AI 节点的决策链 |
| 审计轨迹记忆 | audit_logs | 敏感操作(登录/注册/用户管理/政策发布/报告生成)记录操作者、动作、对象和时间,不可篡改 |
| 运行状态记忆 | runtime_documents(revision + 行锁)+ application_errors + scheduler_runs | 运行时权威状态按事务顺序提交;应用错误记录请求上下文和堆栈;定时任务(如每日备份)记录执行状态 |

5技术实现与部署
技术栈
| 层级 | 技术 | 选型理由 |
|---|---|---|
| 前端 | HTML5 + CSS3 + 原生 JS | 轻量无框架依赖,适合快速迭代 |
| 后端 | Node.js 24 + Express | 高并发 IO,前后端同语言 |
| 数据库 | PostgreSQL 16 + pgvector | 关系型数据 + AI 向量记忆,事务/行级安全/全文索引 |
| 地图 | 高德地图 JavaScript API | POI 检索、路径规划、可视化覆盖物 |
| 大模型 | 阿里云百炼 Qwen Flash / Qwen 3.7 Plus | 意图理解、客流、商圈和公益用快速模型;政策与综合决策用推理模型,在质量、时延和成本间分层 |
| 向量模型 | text-embedding-v4(1024 维) | 政策文本向量化 |
| 部署 | 阿里云轻量应用服务器(120.55.77.5)+ Docker Compose + Nginx | 编排 app、PostgreSQL + pgvector、Nginx 与备份服务;数据库不暴露公网,并配置健康检查与每日备份 |
系统架构
graph TD
UI[HTML/CSS/JS 前端] --> API[Node.js API 与业务服务]
API --> AUTH[身份认证与租户权限]
API --> SEARCH[全杭州空间召回与硬条件校验]
API --> AGENT[受约束 Graph Multi-Agent 编排]
API --> REPORT[报告生成与版本管理]
SEARCH --> AMAP[高德地图与真实 POI]
AGENT --> BAILIAN[阿里云百炼 Qwen]
AGENT --> RAG[政策混合检索]
RAG --> PG[(PostgreSQL + pgvector)]
AUTH --> PG
REPORT --> PG
NGINX[Nginx 反向代理 :80] --> API
subgraph Docker Compose
NGINX
API
PG
BACKUP[每日备份容器]
end
BACKUP --> PG
测试体系
21 项自动化测试(architecture 4 项 + infrastructure 5 项 + citywide-search 12 项)覆盖架构安全、数据治理和选址引擎三个层面,使用 Node.js 原生 node:test 框架,通过率 100%。测试既验证 AI 可以基于有效跨维证据调整排名,也验证硬条件、候选事实、引用边界和成本上限不会被模型突破。
用例集 A:AI 架构安全(architecture.test.js)
| 编号 | 测试项 | 前置条件 | 测试步骤 | 通过标准 |
|---|---|---|---|---|
| A-01 | 政策库来源合规 | 政策知识库已初始化 | 遍历全部政策来源 URL 并执行检索 | ① 来源数量 ≥ 4;② 100% 为 HTTPS 且域名以 .gov.cn 结尾(非官方来源 0 条);③ 检索返回引用 ≥ 4 条;④ 含"公益预留点位"机会且状态为证据已找到;⑤ 法律边界表述包含"不自动豁免" |
| A-02 | 模型不可用降级 | 未配置百炼模型(available=false) | 对标准调研报告执行 Agent 增强 | ① 运行模式 = deterministic_fallback;② 政策 RAG 引用仍 ≥ 4 条;③ 政策来源显示"官方政策知识库";④ 公益 Agent 不越界输出政策/租金结论;⑤ 政策证据带【P#】编号;⑥ 客流分析不串入竞品数据 |
| A-03 | 受约束的个性化重排 | 模拟意图理解、4 个专项 Agent 和综合决策 Agent 返回差异化结论 | 注入专项校正与有/无跨维证据的调整,并对比重排前后的候选事实 | ① 模型调用次数 = 6;② 运行模式 = ai_decision;③ 有效跨维证据可使候选 2 升至首位;④ 中置信度调整请求被服务端限制为 6 分,无证据调整归零;⑤ 地址、坐标、租金和基础指标完全不变;⑥ 4 个专项 Agent 均符合 agent/v2 契约 |
| A-04 | 模型出口域名校验 | 环境变量指向非法地址 | 设置 DASHSCOPE_BASE_URL=https://example.com 并调用解析 | 抛出异常且提示"阿里云官方",非阿里云域名拦截率 100% |
用例集 B:数据治理与报告策略(infrastructure.test.js)
| 编号 | 测试项 | 前置条件 | 测试步骤 | 通过标准 |
|---|---|---|---|---|
| B-01 | 政策版本全生命周期 | 本地临时政策仓库 | 同一 URL 入库两次(不同正文)→ 发布 v1 → 回滚发布 v1 | ① 版本号严格递增(v1→v2);② 旧版本发布后自动转 archived;③ 回滚后 currentVersionId = v1;④ 已发布版本内容不可变 |
| B-02 | 引用可追溯性 | 政策仓库含 ≥ 4 条已发布政策 | 执行政策检索并检查全部引用 | ① 引用数量 ≥ 4;② 100% 携带 versionId 与 contentSha256 指纹;③ 仓库状态 ok |
| B-03 | 同步入口安全 | — | 对官方/第三方域名、公网/内网 IP、HTML 正文分别校验 | ① gov.cn 域名放行、example.com 拦截;② 127.0.0.1、192.168.x.x 识别为内网并拦截,8.8.8.8 放行;③ HTML 转正文保留标题与条款结构 |
| B-04 | Agent 评测器 | 构造包含四专项、官方引用、调整依据与运行成本的完整报告 | 执行 evaluateAgentReport 评测 | ① 评测通过 passed=true;② 专项执行与模型透明度达标;③ 政策引用可追溯且无越界承诺;④ 候选事实保持不变;⑤ 本次调用成本不超过预算上限 |
| B-05 | 报告状态机安全 | 分别构造自动/手动报告设置 | 生成初始报告元数据 → 执行候选点选择 | ① 自动模式仅产出 draft 归档,selectedCandidateId 为空(自动确认率 = 0);② 手动模式停留在 analysis 不进列表;③ 用户显式选择后才产生 selectedCandidateId 并可见 |
用例集 C:选址引擎核心逻辑(citywide-search.test.js)
| 编号 | 测试项 | 前置条件 | 测试步骤 | 通过标准 |
|---|---|---|---|---|
| C-01 | 全市网格覆盖 | 杭州分区配置 | 校验搜索分区列表 | ① 分区数量 = 13 且无重名;② 覆盖淳安县、建德市等远郊;③ 每区半径在 7–16km 区间(不依赖单一中心点) |
| C-02 | POI 分类准确性 | 构造商场/蛋糕店/地铁站/写字楼混合 POI | 执行分类并核对四个专项列表 | 分类准确率 100%(商业 1、烘焙竞品 1、交通 1、办公 1,无串类) |
| C-03 | 候选多样性 | 构造 3 个上城相邻高分点 + 3 个外区次高点 | 执行多样化选择(Top 4) | ① 返回 4 个候选覆盖 4 个不同区县(区域多样性 100%);② rank 连续编号 1–4;③ 相邻重复点可被识别(距离 < 3km) |
| C-04 | 候选锚点纯净度 | 构造商场、产业园与正在营业的餐厅、烘焙店 | 提取候选锚点 | ① 仅保留商场、产业园等可调研载体(2/2);② 营业商户误判为铺位数 = 0 |
| C-05 | 政策特许准入矩阵 | 构造写字楼、商场、慈善基地、企业园区、社区服务、高校、文创街区、公园、景区等 11 类载体 | 对普通型/特许型 × 店铺/餐车逐一校验准入 | ① 普通型排除纯写字楼与慈善基地;② 特许型准入慈善基地/园区/社区资产/高校/文创街区/景区;③ 公园仅特许餐车准入、店铺不准入;④ 载体画像 kind 归类准确率 100%(8/8) |
| C-06 | 位置信息组装 | 含行政区、街道地址、楼层铺位的 POI | 组装完整位置描述 | ① fullAddress 含市/区/路名;② floorRoom 含楼层与铺位号;③ 标注精度来源说明 |
| C-07 | 载体适配评分 | 商场 vs 社区街区两类载体 | 对餐车/第四空间/店铺三种形态计算适配分 | ① 餐车:商场 ≥ 街区;② 第四空间(121–180㎡):商场 > 街区;③ 店铺(20–40㎡):街区 > 商场;④ 预算比 0.8 优于 1.8;宽容预算档优于严格档 |
| C-08 | 餐车成本模型 | 同等商业潜力下测算商场内/外广场餐车与 60㎡ 门店 | 对比三种月成本 | ① 商场餐车 0.12–0.45 万元/月;② 外广场餐车 0.05–0.28 万元/月;③ 餐车成本 < 门店成本;④ 计费模式标注落位方式 |
| C-09 | 预算硬过滤 | 构造 2 个预算外高分点 + 3 个预算内次高点 | 执行预算过滤选择(Top 3) | ① 高分但预算外候选入选数 = 0(硬约束优先于分数);② 返回 3 个候选租金全部落在 0.6–0.8 万元预算区间内 |
工程规模
1产品复盘
产品设计考量
- 从真实商业瓶颈切入:把“能否找到兼具经营潜力与合作准入条件的点位”识别为融合就业规模复制的前置问题,让智能选址系统直接服务点位扩张与 To B 决策收入,而不是脱离商业模式的独立功能
- 兼顾通用市场与特殊场景:以轻餐饮和零售的普通商业选址为基础能力,将融合就业、政策合作与公益无障碍作为可配置分支嵌入,既扩大产品适用面,也保留差异化壁垒
- 形成从需求到行动的决策闭环:串联需求理解、全市召回、硬条件筛选、逐点证据、四项分析、综合比较、报告与实勘动作,最终回答“先看哪里、为什么、风险是什么、下一步确认什么”
- 让规则、数据和 AI 各司其职:规则守住预算、面积和事实边界,地图与政策库提供证据,Agent 负责经营解释和跨维取舍,服务端完成限幅与最终计算,避免把智能等同于自由生成
- 把政策能力做成可治理资产:官方来源、版本、内容指纹、混合检索、引用与回滚共同保证结论可追溯,使政策分析从一次性搜索升级为可维护的产品能力
- 完成从商业方案到工程交付的连接:商业侧已有点位、就业与营收验证,产品侧具备数据库、租户隔离、审计、测试、部署和降级机制,形成可以继续积累数据和迭代模型的基础
关键取舍
- 决策辅助,而非自动签约:首期聚焦实勘前筛选与优先级判断,把租赁、消防、用途和合作准入留给现场及书面确认
- 通用主干,特殊能力分支:不为融合就业另建一套孤立系统,通过项目类型、权重和规则切换复用同一选址引擎
- 先保可用,再增加智能:预算、面积和载体准入先做硬过滤;AI 只在合格候选中解释经营影响、识别冲突并有限调整排序
- 覆盖广度与分析深度分阶段:先用 13 区县网格完成全市召回,再对最多 6 个候选逐点精查,避免一次性精查全城带来的延迟与接口成本
- 速度与推理质量分层:结构化比较使用快速模型并行执行,政策长文本和综合决策使用推理模型;所有节点设置调用、token、费用和降级边界
- 数据不足时不制造确定性:缺少真实客流、成交租金和现场无障碍数据时使用代理指标,并把不足转化为实勘核验动作
- 政策更新与发布分离:自动采集保证更新效率,人工发布控制适用性风险;首期聚焦杭州,先积累可靠样本后再扩展城市
下一阶段路线图
| 阶段 | 规划 |
|---|---|
| P0 | 增加实勘反馈表和点位状态追踪;建立报告数字一致性持续检查,并补齐端到端耗时、地图接口调用与现版本单次成本监控 |
| P1 | 接入公开招商信息和经核验的场地联系人;建立租金样本库校准估算模型 |
| P2 | 将城市规则、政策来源和区域网格配置化;扩展绍兴、宁波等城市 |
| P3 | 场景扩张——特殊人群种类从孤独症扩展至智力、听力、肢体障碍等群体(按各群体能力画像拆解适配岗位);经营业态从轻食烘焙门店扩展至洗车服务、社区便民、手工艺品售卖等,不局限于餐饮。扩张后载体适配规则、岗位拆解模板和评分权重按业态配置化,以分叉嵌入方式让引擎在保持普通商业选址能力的同时,服务更多类型的融合就业项目 |
2能力映射
| 产品经理能力 | 在本项目中的体现 |
|---|---|
| 用户研究 | 10+ 企业、5 位残障服务专家、30+ 家庭访谈,转化为三组产品需求与双类型产品策略 |
| 商业模式设计 | 与团队共创融合就业商业模式,设计 To G/B/C 三轨驱动的资源闭环 |
| 产品架构 | 以功能流程、数据模型、目标决策链和 Agent 选型系统化拆解复杂产品 |
| AI 产品设计 | 受约束 Graph Multi-Agent + 意图识别 + 专项并行分析 + 政策 RAG + 证据约束的跨维重排 |
| 技术全栈 | 独立完成前端/后端/数据库/AI/部署全链路,18 张表 + 21 项测试 |
| 项目落地 | 从设计到线上部署,持续迭代修复线上问题 |