从一句想法，到一套可讨论的园林方案

本系统面向园林设计师、方案顾问和客户，将场地资料、客户需求、园林知识、三维空间编辑、仿真校验与造价估算整合到一个可持续对话和修改的平台中。

系统不是“输入提示词后生成一张效果图”，而是维护一个有尺寸、有对象身份、有约束、可回退的语义化园林空间模型。客户可以通过自然语言、点击和参数面板提出调整，AI将需求转换为结构化设计意图和受约束的空间操作；设计师审查后，系统提交新方案版本，并同步更新三维场景、植物清单、材料清单、预算和关键仿真结果。

首期产品定位：

园林设计师与客户共同使用的AI空间方案平台，而不是无人审核的自动设计师。

推荐先限定在100—500平方米的私家庭院，支持3—5种常用风格、100—300种常用植物和标准化构筑物/材料组件。MVP预计需要8—10人的跨职能团队，约6个月完成可用于真实客户项目的版本。完整产品化预计需要12—18个月。

2.1 产品目标

1. 将客户的模糊表达转化为可确认的结构化设计需求。
2. 在真实场地模型上生成2—3个满足约束的可交互方案。
3. 支持自然语言与直接操作相结合的持续修改，而不是每轮重新生成无关场景。
4. 每次变更同步更新空间、清单、预算和仿真结果。
5. 保存完整的版本、决策依据、冲突说明与设计师审核记录。
6. 将确认方案作为后续施工数字交付和智能设备空间映射的基础。

2.2 业务成功标准

• 方案初稿制作时间下降30%以上。
• 客户需求确认轮次下降20%以上。
• 常用标准项目的清单和概算生成时间下降50%以上。
• 试点客户中，70%以上能够独立完成至少一次有效的交互修改。
• 设计师认为系统建议“可用或修改后可用”的比例达到80%以上。
• 系统未造成未经设计师确认的工程承诺。

2.3 首期非目标

• 不自动输出可直接施工的全专业施工图。
• 不替代注册设计、结构、给排水、电气等专业责任主体。
• 不承诺任意风格、任意地形和任意项目规模的通用生成。
• 不以生成式图片或视频作为项目的唯一真实数据。
• 不让大模型直接修改正式方案数据或绕过规则校验。
• 不在首期实现精确排水、水力、结构安全和植物病害预测。

核心用户旅程：

1. 设计师创建项目并导入场地资料。
2. 系统形成基础空间模型，标出低置信度区域供人工确认。
3. 客户通过问卷、语言、图片和案例表达需求。
4. AI生成结构化需求卡片，客户和设计师共同确认。
5. 系统生成候选方案及差异说明。
6. 客户以自然语言或直接操作提出修改。
7. AI生成“修改计划”，规则引擎校验后展示预览和影响。
8. 设计师批准、调整或拒绝，系统提交新版本。
9. 系统输出提案、漫游链接、清单、概算与待确认事项。

1. 场景数据优先：图片是输出，语义化场景才是事实来源。
2. AI只提议，系统负责执行：AI输出结构化操作；场景服务校验并提交。
3. 确定性计算优先：尺寸、碰撞、间距、成本等由几何或规则系统计算，不交给大模型猜测。
4. 人机共创：高影响操作必须由设计师确认。
5. 所有变更可解释、可回退：任何方案都能追溯到需求、操作和审核人。
6. 先标准化再智能化：先做限定面积、风格、植物和组件，再逐步扩大范围。
7. 模型与供应链一致：植物、材料和构件尽量绑定真实可采购条目。

flowchart TB
    U["客户与设计师"] --> X["交互工作台"]
    X --> A["AI设计编排"]
    A --> S["语义场景服务"]
    A --> K["园林知识与规则"]
    S --> V["仿真与造价"]
    S --> R["三维渲染"]
    S --> D["空间数据存储"]
    V --> X
    R --> X
    K --> V
    S --> O["方案与交付输出"]

    classDef user fill:#dbeafe,stroke:#2563eb,color:#172554
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764
    classDef core fill:#dcfce7,stroke:#16a34a,color:#052e16
    classDef check fill:#fef3c7,stroke:#d97706,color:#451a03

    class U,X user
    class A ai
    class S,D,R core
    class K,V,O check

架构分层说明：

6.1 项目与场地管理

输入格式建议支持：DWG/DXF转换结果、IFC、GeoJSON、Shapefile、点云、正射影像、常见图片和人工绘制边界。原始文件应保留不变，转换后形成统一坐标系下的内部场地模型。

主要能力：

• 项目、地块、建筑、边界和标高管理；
• 坐标系、单位、朝向和基准点确认；
• 地形、已有植物、道路、构筑物、管线和禁建区标注；
• 扫描或识别结果的置信度显示；
• 手工校正和测量工具；
• 原始数据、处理结果与人工修订分层保存。

6.2 语义场景服务

语义场景是系统的单一事实来源。每个对象至少包含：唯一ID、类型、几何、位置、尺寸、属性、来源、置信度、版本和关系。

场景服务只接受有限、可验证、可回退的操作：

• ADD_OBJECT：新增植物、道路、灯具、构筑物等；
• MOVE_OBJECT：移动对象；
• REPLACE_OBJECT：替换植物、材料或构件；
• UPDATE_PROPERTY：修改尺寸、颜色、密度等属性；
• DEFINE_ZONE：创建功能区、种植区、灌溉区或禁建区；
• APPLY_TEMPLATE：应用风格或场景模板；
• DELETE_OBJECT：逻辑删除对象；
• ROLLBACK_VERSION：回退到历史版本。

每个操作包含前置条件、影响范围、幂等键和撤销操作。AI不能提交任意脚本，也不能绕过场景服务直接修改几何或数据库。

6.3 需求与偏好管理

需求来源包括文字、语音转写、问卷、案例图片、设计师访谈和历史项目。系统将其归一化为：

• 功能：会客、用餐、儿童活动、宠物、种植、展示等；
• 风格：现代自然、中式、日式、度假等；
• 约束：预算、面积、工期、维护投入、过敏、宠物安全；
• 空间关系：邻接、遮挡、视线、通行、安静和采光；
• 运营目标：低维护、低用水、四季效果、夜景体验；
• 优先级：必须、应该、可选；
• 证据与确认状态：客户原话、AI解释、客户确认、设计师确认。

存在冲突时，系统必须展示冲突而不是静默决定。例如“需要高私密性”和“保持开阔视野”同时出现时，应要求用户确定位置或优先级。

6.4 园林知识库

知识库由结构化数据和可检索文档组成。

结构化植物数据建议包含：

• 学名、中文名、别名、品种和供应规格；
• 适生区域、耐寒/耐热性、光照、水分、土壤和酸碱偏好；
• 初始尺寸、成年高度、冠幅、生长速度和季相；
• 花期、果期、落叶、香味、刺、毒性、过敏和宠物风险；
• 推荐间距、群落关系、维护频次与替代品；
• 供应商、价格区间、更新时间和数据来源。

材料与构件数据建议包含尺寸、材质、颜色、适用风格、防滑/耐候属性、安装条件、价格、维护和三维资产引用。

规则分为三类：

1. 硬规则：安全距离、禁建区、道路最小宽度、对象碰撞等，不满足时不得提交。
2. 软规则：风格协调、推荐间距、维护偏好等，可以提交但必须提示。
3. 评分规则：预算、遮挡、季相、维护和生态目标，用于方案排序。

知识更新必须经过“编辑—复核—发布”，并记录来源、适用区域和有效期。

6.5 AI设计编排器

AI层采用供应商中立的模型网关。首期不训练空间基础模型，使用具备结构化输出和工具调用能力的多模态大模型，并以公司知识库增强。

标准工作流：

flowchart LR
    I["理解需求"] --> P["生成修改计划"]
    P --> T["调用设计工具"]
    T --> C["规则与几何校验"]
    C --> E["展示差异和影响"]
    E --> H["设计师确认"]
    H --> M["提交新版本"]

    classDef think fill:#f3e8ff,stroke:#9333ea,color:#3b0764
    classDef check fill:#fef3c7,stroke:#d97706,color:#451a03
    classDef done fill:#dcfce7,stroke:#16a34a,color:#052e16
    class I,P,T think
    class C,E,H check
    class M done

AI编排器必须做到：

• 只通过已注册工具进行场景操作；
• 输出符合JSON Schema的结构化数据；
• 在信息不足或冲突时先澄清；
• 为每个建议提供依据、假设和影响；
• 将高影响操作标记为强制审核；
• 模型切换时保持工具协议和场景语义不变；
• 对同一请求保存提示、模型版本、工具调用和结果摘要。

6.6 生成式方案引擎

方案生成不应由大模型直接“画完”，而应采用“模板＋约束求解＋候选评分”的方式：

1. 根据场地和需求选择布局原型；
2. 确定功能分区和主要动线；
3. 布置构筑物、水景和硬质铺装；
4. 根据光照、空间、季相和维护目标生成种植组合；
5. 运行硬规则校验；
6. 计算预算和多目标评分；
7. 生成2—3个差异明确的候选方案；
8. 使用生成式图像或高质量渲染增强表达，但不改变正式场景数据。

候选方案应体现真实取舍，例如“更强私密性”“更低维护”“更丰富季相”，而不是只换材质或色调。

6.7 仿真与校验服务

按优先级实施：

所有仿真结果应带精度等级、输入条件和“是否可作为工程依据”的标记。

6.8 三维交互工作台

建议采用浏览器优先的交付方式，设计师可使用增强桌面端或高性能模式。

主要界面：

• 三维场景、二维总平面和属性面板；
• AI对话与结构化需求卡片；
• 对象选择、拖拽、替换、测量和区域绘制；
• 修改前后对比、版本树和一键回退；
• 日照、视线、成长和预算图层；
• 客户简化模式与设计师专业模式；
• 设计师审批队列和风险提示。

系统应优先做到“操作稳定、差异清楚”，再追求照片级实时效果。

6.9 造价与交付

概算由场景对象和参数确定，不由语言模型自由生成。价格应包含区域、供应商、规格、损耗、人工、运输、税费口径和更新时间。

输出包括：

• 在线可交互方案；
• 方案说明与需求满足矩阵；
• 总平面示意、主要视角和场景漫游；
• 植物、材料和构件清单；
• 概算及方案间差异；
• 日照、视线、成长等分析摘要；
• 未解决风险、假设和待确认事项；
• 面向后续深化设计的数据包。

场景对象关系至少支持：位于、邻接、遮挡、连接、依赖、替代、属于群落和受约束于。关系必须可以被规则与AI查询。

以下为参考实现，不要求一次锁死供应商：

OpenUSD适合复杂三维资产的组装、非破坏编辑和跨工具交换；PostGIS适合空间对象的存储、索引与几何查询。Apple RoomPlan证明消费级LiDAR可以输出带尺寸和对象类型的参数化空间模型，但户外园林仍需摄影测量、专业扫描或人工测量补充。

建议按领域提供API，不让前端或AI直接访问数据库：

• /projects：项目与成员；
• /sites/import：场地导入与处理任务；
• /scenes/{id}：场景读取、差异和版本；
• /scene-operations/preview：预览操作及影响；
• /scene-operations/commit：经校验后提交；
• /intents：需求、冲突和确认；
• /proposals/generate：候选方案任务；
• /simulations：仿真请求与结果；
• /estimates：工程量和概算；
• /reviews：审批与意见；
• /exports：交付物生成。

关键领域事件：

• SiteImported
• IntentConfirmed
• ProposalGenerated
• SceneOperationProposed
• ConstraintViolated
• SceneVersionCommitted
• SimulationCompleted
• EstimateUpdated
• ProposalApproved
• ExportCompleted

所有写操作要求项目权限、版本号和幂等键。版本冲突必须提示用户合并或重新应用，不能静默覆盖。

10.1 权限边界

• AI只能调用白名单工具；
• 正式提交必须经过场景服务和规则引擎；
• 删除大范围对象、超过预算、涉及安全规则等操作强制设计师审核；
• 外部网页、客户文档和图片均视为不可信输入；
• 检索内容不能改变系统权限或工具策略。

10.2 输出可信度

系统区分三类内容：

1. 事实：来自场地、目录或已审查知识库；
2. 计算结果：来自确定性算法，显示输入和精度；
3. AI建议：显示理由、假设和需要确认的部分。

AI不得虚构植物参数、价格、法规或工程结论。缺少数据时应返回未知或请求补充。

10.3 隐私与数据治理

• 项目级租户隔离和角色权限；
• 传输与存储加密；
• 客户数据、项目文件和模型训练授权分别管理；
• 默认不使用客户项目训练通用模型；
• 提供保留期限、导出和删除机制；
• 对人脸、住址、家庭习惯等敏感数据最小化采集；
• 具体合规要求由项目所在地的专业法律顾问确认。

11.1 性能目标

• 典型500平方米项目首次加载不超过10秒；
• 常规对象移动、替换和属性调整预览在2秒内响应；
• AI修改计划在10秒内返回，复杂候选方案可异步完成；
• 典型日照、视线和概算任务在2分钟内完成；
• 浏览器端采用分级细节、实例化植被和按需加载。

11.2 可靠性

• 正式版本写入必须具备事务性；
• 任意已提交版本可回退；
• 计算任务可重试且不会重复提交结果；
• 原始文件不可被处理任务覆盖；
• 生产环境目标可用性99.5%，设计会话自动保存。

11.3 可观测性

需要监控：

• 每类AI请求的成功率、延迟、成本和人工修改率；
• 场景操作失败原因和规则冲突分布；
• 仿真任务耗时与失败率；
• 资产加载、帧率和客户端错误；
• 方案采用率、回退率和设计师审批时长。

推荐云端SaaS＋本地可选处理节点：

• 云端负责项目、协作、AI编排、知识库、版本和交付；
• 计算Worker负责模型转换、仿真、渲染和批量生成；
• 大型点云、敏感项目或弱网环境可部署本地处理节点；
• 客户漫游链接使用只读、限时访问令牌；
• 开发、测试、预生产和生产环境隔离；
• AI供应商密钥仅存后端，不进入浏览器或交付模型。

13.1 MVP明确范围

• 私家庭院，面积100—500平方米；
• 输入：基础CAD/平面图、照片和人工确认尺寸；
• 3—5种风格模板；
• 100—300种常用植物；
• 标准铺装、围栏、灯具、座椅和小型水景组件；
• 需求结构化、三维编辑、AI工具调用、版本管理；
• 日照、视线、基础成长、工程量和概算；
• 在线漫游、方案比较和PDF/清单输出；
• 设计师强制审核。

13.2 六个月计划

13.3 团队配置

• 产品负责人1人；
• 园林设计负责人1人，植物/工程专家兼职或1人；
• 技术负责人1人；
• 三维前端工程师2人；
• 后端/AI工程师2人；
• 几何/仿真工程师1人；
• UX设计师1人；
• QA/DevOps 1人或共享配置。

首期研发量约45—60人月，另需三维资产制作、历史项目整理、云资源和试点现场采集投入。若公司尚无稳定数字化设计流程，数据整理和资产标准化可能比软件开发更耗时。

14.1 功能验收

• 可完成项目创建、场地导入、校正、保存和版本回退；
• 支持至少20类标准自然语言修改指令；
• 所有AI操作先预览、后提交，且能展示影响对象；
• 违反硬规则的修改不能进入正式版本；
• 能生成2—3个设计目标不同的候选方案；
• 场景、植物/材料清单和概算保持同步；
• 能输出客户链接、方案摘要和清单文件。

14.2 质量验收

• 在预先标注的测试集中，需求字段识别准确率达到90%以上；
• 标准场景操作执行成功率达到95%以上；
• 场景版本100%可追溯和回退；
• 对目录内标准对象，工程量计算与人工基准偏差不超过5%；
• 对已确认价格口径，概算与人工基准偏差不超过10%；
• 设计师对候选方案“可用或修改后可用”的评价达到80%以上；
• 不出现AI绕过审核提交正式方案的情况。

14.3 试点验收

• 完成至少5个不同场地的端到端项目；
• 至少3名设计师能够不依赖开发人员完成工作流；
• 至少10名客户完成需求确认和一次有效修改；
• 记录与原流程相比的时间、轮次、采用率和返工变化；
• 所有失败案例进入规则、数据或产品改进清单。

Phase 1：AI方案共创

完成需求、三维场景、自然语言修改、基础规则、仿真、概算和交付闭环。

Phase 2：设计深化协同

增加更复杂地形、更多项目类型、供应链价格、专业软件交换、多人协作、审批和区域规则。

Phase 3：施工数字交付

将场景对象映射到施工任务、现场扫描、变更记录、设备点位和竣工模型。此阶段沿用同一对象ID和版本体系。

Phase 4：施工后空间服务

将竣工模型中的区域、植物和设备连接传感器与控制系统，实现养护、节水和有限场景自适应。AI只作场景推断，安全规则与设备控制保持独立。

在正式立项前需要管理层确认：

1. 首个项目类型是否确定为私家庭院；
2. 典型面积、区域气候和服务城市；
3. 当前主要设计软件和现有文件格式；
4. 能否提供10—20个完整历史项目作为金标准；
5. 首期是否需要照片级实时渲染，还是允许异步高质量出图；
6. 概算需要达到销售估价、深化预算还是合同报价级别；
7. 客户是否直接操作，还是由设计师陪同使用；
8. 部署在公有云、私有云还是混合环境；
9. 是否存在必须对接的供应链、CRM、ERP或设计软件；
10. 试点项目、负责人、预算和六个月后的商业目标。

建议立项，但设置三个继续投资门槛：

1. 第4周数据门槛：历史项目能够归一化为稳定的对象、需求和清单模型；否则先暂停AI开发，补数据标准化。
2. 第14周交互门槛：20类标准修改指令成功率达到90%以上，设计师能够理解并纠正AI操作；否则缩小指令和项目范围。
3. 第24周业务门槛：真实试点使方案周期或客户沟通轮次至少改善一项达到20%以上；否则不要扩展到施工中和施工后。

最终建议：以“语义化园林场景＋AI工具编排＋确定性规则仿真”为技术主线，以“设计师审核＋限定场景”为产品边界。空间基础模型可作为视觉生成和空间理解能力来源，但公司的核心资产应是园林数据、约束、组件、项目版本和交付闭环。