企业官网建设流程全解析

老话讲医美行业拼的是审美和运气，但真正在机构里做过数字化建设的人都知道，这门生意拼的更像是“记性”和“流程”。顾客三个月前问了什么项目、哪个咨询师跟到一半离职了、库存里那批玻尿酸还剩几天效期、术后回访有没有漏人，这些琐碎事随便漏掉一件，损失的不光是业绩，更是信任。所以我们团队最近做了一个挺有争议的决定：把一套医美机构运营系统重构，打包成内部代号“龙虾版”，并作为开源智能体应用上架到了OpenClaw上。

这篇不是发布会通稿，纯粹是技术复盘加踩坑记录。会讲清楚“龙虾版”这名字怎么来的、上架OpenClaw到底意味着什么、落地过程中哪些配置和模块是真有用的、哪些问题差点让我们推倒重来。如果你正准备把某个垂直行业的业务流程做成智能体应用，或者正在犹豫要不要把手里的业务系统“应用市场化”，这篇应该能帮你省掉不少弯路。

1. 龙虾版的来历：被Excel和微信聊天记录逼出来的重构

1.1 老系统靠“三国鼎立”撑了三年

先说我们最早的服务对象模型。典型的中型医美门诊，日常经营依赖三套东西：前台用Excel表格管预约，咨询师用微信聊天记录跟踪客户意向，库房用纸质单据查耗材库存。这三套东西彼此不通，信息基本靠喊。

你会觉得这种模式很落后，但在真实医美机构里还挺常见，因为医美项目的决策周期特别长。用户第一次来问“想改善眼周细纹”，可能三个月后才真正下单；下单后要拍术前照、安排医生面诊、做皮肤检测、定方案，然后才进入治疗环节；术后两到四周还要回访，确认有没有不适、效果满不满意。任何一个环节的客户信息断档，后面的人都接不上。咨询师离职带走客户资料这种事，几乎是每家机构都踩过的雷。

我们最初给其中一家机构做了一套内部Web后台，功能就是预约排班、客户表、项目库和回访计划。说实话，功能本身不算复杂，复杂的是业务规则变化太频繁。今天要加一个“618活动包装”，明天要改“新客首单专属话术”，后天要处理“某批次产品效期预警”，技术团队每天被打补丁，一个月下来发布次数比功能数量还多。

这种情况下，系统表面是“都管”，实际上每一个模块都停在“能用但不好用”的层面。真正的转折点是有一次效期盘点出错，一批临近过期的水光针差点被用到顾客身上，库房和前台互相甩锅，我们才决定不再打补丁，直接重构。

1.2 “龙虾”代号与OpenClaw的谐音梗

重构总得有个内部叫法。团队开会时有人开玩笑说，这系统要能像龙虾一样，用一对大钳子把客户、项目、排期、风险全夹住，不让任何信息漏掉。于是“龙虾版”就成了内部代号，英文叫Lobster Release，版本号顺势叫LX-01。

后来我们决定把整套能力打包成智能体应用，发布到开源智能体运行框架OpenClaw上。OpenClaw本质上提供了一套“运行时+技能包+消息通道”的宿主环境，应用可以像插件一样被安装、调用和卸载。团队看到OpenClaw这名字，再看看手里的“龙虾版”，都觉得这梗接得太妙了——Claw是爪子，OpenClaw就是“打开爪子”，龙虾的钳子刚好也是爪子；我们的系统又要用钳子夹住业务主流程，这不就正好对上号了。

所以对外说“上架OpenClaw”，准确讲不是像APP上架应用商店那样搞商品陈列，而是把我们这套医美运营能力做成标准技能包，发布到OpenClaw可以承载的应用目录里。用户下载后再配置自己的数据库和渠道入口，就能在对话式工作台里直接使用。

1.3 重构定下的三条硬指标

重构不想再做成一个“大而全但没人爱用”的后台，所以我们先给龙虾版定了三条硬指标。这三条决定了下文所有模块和技术选型的方向。

第一条，信息闭环。客户从第一次咨询到术后回访，所有关键动作必须沉淀在系统里，不能出现“线下沟通完再手动录入”的断点。哪怕咨询师只在对话框里问一句“你上次做的项目效果如何”，系统都要把这条对话和客户档案关联起来。

第二条，智能体可插拔。这也是我们决定上架OpenClaw的核心原因。系统不能是一座孤岛，每模块都应该是能在OpenClaw里独立启停、单独更新的技能包。预约是预约，库存是库存，风险审查是风险审查，机构可以根据经营需要自己组合。

第三条，合规留痕。医美行业对宣传用语、个人信息、医疗建议都有强约束，系统必须内置审查能力。所有对外话术要过一遍敏感词和合规规则，所有访问操作要留审计日志。这也是后来被验证为最重要的一条，后面专门写。

2. “上架OpenClaw”到底上架了什么：系统智能体化拆解

2.1 先理解OpenClaw提供的是什么

很多同学听到“上架OpenClaw”第一反应是问，这跟部署一个SaaS网站有什么区别。区别核心在于交互范式。传统后台是人找功能，菜单在左边，用户得知道去哪点；OpenClaw这类智能体运行时则是功能找人，用户用自然语言发起需求，运行时决定调哪个技能、访问哪张表、返回什么结果。

对我们行业软件来说，这个变化是颠覆性的。医美机构的咨询师和前台每天都在跟客户说话，没工夫学复杂菜单；但她们很擅长用大白话提需求。“看一下明天下午三点到五点谁有空”、“把王姐的档案调出来”、“这周到期的库存有哪些”，这些话她们每天都讲无数次。

所以龙虾版的落地形态是一个“业务大脑”，底下挂着一堆技能包：会话理解交给智能体运行时，业务逻辑和数据库仍然是我们自己的。OpenClaw负责听懂请求，技能包负责执行具体操作，最后把结果送回对话渠道。

2.2 核心模块被打散成六个技能包

我们一开始列了二十多个需求点，最后收敛成六个技能包。每个技能包都对应机构里一个真实到令人头疼的场景。

每个技能包都有自己独立的数据库表集合，但彼此通过客户ID和订单ID关联，从根上避免了过去那种“各管一摊、数据对不上”的问题。

2.3 一个咨询场景的完整数据流动

拿最日常的场景举例。客户“王姐”来消息说：“上周做的光子嫩肤，今天感觉脸有点干，正常吗？”咨询师直接把这句话转发给系统工作台。

OpenClaw会先做意图识别，这一步通常同时命中两个点：老客查询和术后咨询。接下来它并行调用两个技能包：

• 客户档案技能：按客户姓名或手机号查到王姐的治疗记录，确认她确实在七天内做过光子嫩肤。
• 知识库问答技能：检索光子嫩肤术后护理文档，把“皮肤干燥属于正常现象”的条目和机构自定义的补充话术拿出来。

两个结果返回后，系统先经过合规审查技能扫一遍，确认没有“保证快速恢复”“绝对安全”这类违规表达，才生成一段完整回复。这段话既包含知识库的标准解释，又包含“建议加强补水、避免暴晒、如果持续红肿请到院复诊”的机构标准行动项。同时，回访任务技能自动记录一条任务：“三天后回访王姐，确认干燥情况是否缓解”。

整个链路看着长，实测下来在配置合理的情况下基本两三秒完成。咨询师不需要打开任何界面，也不需要亲手新建回访记录，这就是智能体应用和传统后台最大的体验差异——系统在背后把活干完了，人只负责和客户聊天。

2.4 为什么坚持“配置优先”而不是纯代码硬编码

项目启动时有同事提过疑问：这些功能用传统代码写也不难，ChatBot接个数据库就行，为什么要上智能体框架。我们的回答是，需求一定会变，而且变化的往往是细节规则。纯代码硬编码意味着每改一次话术、每调一次回访间隔，都要走开发、测试、发布流程，这又回到了老路。

在龙虾版里，大部分业务规则都被设计成可视化配置项或知识文档。比如术后回访节点，机构可以在配置里把“光子嫩肤后1天、3天、7天”改成“1天、5天、14天”，不需要改代码；机构话术可以直接在知识库里覆盖默认模板。OpenClaw只是调用方，规则归运营管。

这样设计确实牺牲了一些灵活性，复杂的自定义流程很难在早期版本里支持。但对于医美机构这种“规则多但都不算太复杂”的行业，配置优先带来的维护成本下降，远远大于机制损失。这个取舍我们认为是龙虾版能顺利落地的关键原因之一。

3. 龙虾版落地过程：从原型到可部署的完整操作记录

3.1 技能定义与知识库的准备工作

实操第一步不是写代码，而是把机构业务“翻译”成技能定义文档。我们用习惯的做法：把每个技能当成一个服务，在配置里明确它能干什么、不能干什么、需要哪些参数。

这里只写最重要的配置项。技能定义用YAML维护，结构大致这样：

技能名称: stock_expiry_alert 技能描述: 查询产品库存批次，按效期天数筛选临期产品并生成预警 调用参数: 批次号: string, 可选 剩余效期天数: integer, 默认值30 只看临期: boolean, 默认true 返回字段: - product_name - batch_no - expire_date - stock_qty - status 审核要求: 必须记录操作人、操作时间、查询条件

这只是示例，真实配置比这个长不少，但核心思想一样：让模型清楚技能职责边界。边界越清晰，模型乱调技能的概率越低。我们有段时间技能描述写得太含糊，结果用户问“明天天气”模型都能去调库存接口，闹了不少笑话。

知识库的准备工作更磨人。我们把机构提供的项目说明书、禁忌症列表、术后注意事项、常见问题话术全部结构化，按主题拆分，存入向量库。注意不要直接把PDF丢进去，这一步质量直接决定问答准确率。我们是按“问法-答法-来源文档”三段式整理，每一条都标注引用来源，方便出现纠纷时追责。

3.2 关键配置：表结构、接口和定时任务

技能定义配好后，要准备底层数据。选型上我们用了轻量的关系型数据库，同时接了一个向量库做知识检索。业务表不需要太多，核心四张表足够撑起首批功能。

客户档案表除了姓名、手机号、生日这类基础字段，更关键的是动态标签字段。我们把“项目偏好”“价格敏感度”“上次治疗项目”“是否术后”都设计成结构化字段，供技能包做条件筛选。项目表则要维护项目名称、分类、禁忌症、标准恢复周期、建议回访模板。

库存表是容易被低估的一张表。医美产品批次和效期管理必须细到单件，因为不同批次的效期差异可能很大。我们在表里增加了reserved_qty字段，表示“已被预约但尚未取货使用的数量”。这个字段后来救了命，因为没有它的话，临期预警会把“已经安排给客户的资源”也算成风险库存，误报率会非常高。

接口这块我们做了统一鉴权。每个技能包在OpenClaw里注册时都有一个专属Token，Token只绑定必要的数据库权限。比如库存技能只读库存表，没有权限碰客户详情；回访任务技能能读客户表，但不能修改客户手机号。这样一个技能被攻击或误用，爆炸半径也被限制住。

定时任务做了两个：每天早晨跑一次效期预警，扫描未来30天到期的批次并生成Excel报告；每晚生成第二天的回访任务清单。这些任务都在智能体运行时里定义为定时触发器，不用额外上调度系统。

3.3 实际部署步骤（以Docker Compose为例）

我们把整个运行时环境打成了镜像，用Docker Compose统一编排。部署过程可以简化成四步，照着做基本不会错。

第一步，准备好.env环境文件。这里最容易踩坑，因为配置项太多。至少要配置数据库连接串、向量库地址、API服务密钥、管理员账号初始化密码。强烈建议第一次部署时就把所有密码换成强随机串，不要用开发环境偷懒用的弱密码。

第二步，拉取镜像并启动基础服务。基础服务包括业务数据库、向量库和运行时主进程，先不要启动技能包容器。确认三个容器都健康运行之后，再进入下一步。

docker compose pull docker compose up -d db vector docker compose up -d runtime docker compose ps

第三步，初始化数据库表结构。我们提供了一个初始化SQL脚本，执行一遍会创建表、索引和初始管理员账号。注意脚本只在首次部署执行，重复执行会导致数据冲突。

第四步，逐个启用技能包容器并检查日志。看到技能注册成功的日志后，去OpenClaw的控制台测试一次对话，问一句“查询一下库存里效期不足30天的产品”，如果返回了真实数据，部署就算完成。

整体资源开销不算大。实测四核八G内存的云主机，跑全部容器加一个1000条知识条目的向量库，CPU占用长期在30%以下，内存剩两G左右。这个量级对中小机构完全够用，投入成本主要是在人力配置上。

3.4 首次联调翻车记录：不是AI不行，是权限模型没想清楚

龙虾版第一次跑通测试环境的时候，大家都很兴奋。结果第三天就出了一个大问题：客服小姐姐在测试知识库问答技能时，问了一句“看看我们机构有哪些会员等级”，返回结果里居然把某个客户的姓名和最近消费金额也带出来了。

排查链路花了一个下午。第一反应是向量库召回错了，但查日志发现召回的是正确的会员等级说明文档，问题出在后处理环节——模型回答时为了“更完整”，自己主动去调用了客户档案技能。更尴尬的是，客户档案技能当时的配置里没有限制返回字段数量，模型就把能查到的都拿出来了。

这件事给我们的教训非常深。权限模型不能只靠在技能描述里写“不要调用不相关技能”，必须在接口层做两层限制。第一层，技能Token对数据库只有最小权限，其它技能的数据接口根本不应该对当前Token开放；第二层，返回字段必须白名单化，不配置到的字段一律不返回。修复后，我们又专门加了一个测试用例：用会员等级问题触发一次调用，强制检查返回结果里有没有敏感字段，回归过了才允许进入下一轮联调。

所以别急着让模型变聪明，先让模型变规矩。权限收得越狠，后面上线越安心。

4. 上线后的实测数据与调优过程

4.1 我们用来衡量“好不好用”的几个指标

智能体应用最容易让人迷失在“对话很流畅”的表面感受里。为了不被感觉骗，我们上线前就定了一组量化指标。准确率和召回率必须分技能统计，因为一个综合平均分根本看不出短板；操作挽留率看系统能否把过去需要人工完成的动作承接住；用户采纳率看咨询师和前台是否愿意在真实对话里频繁使用。

我们不追求百分之百，因为对话式系统里永远有理解失败的情况，关键是失败要有兜底。不管模型有没有听懂，都要回一句“这个问题我帮你转人工”，而不是沉默。

4.2 实测结果：哪些指标达标了，哪些没有

运行两周后，数据出来了。预约排班准确率96.2%，刚好过线；效期预警覆盖率做到了99.6%，基本没有漏批次；端到端响应时间中位数2.8秒，比预期好。真正没达标的是知识库问答准确率，只有81.3%，低于85%的基线。

问题集中在两类场景。一类是客户提问太口语化，比如问“我做完这个会不会脸肿”，知识库里有详细的专业回答，但模型没把“脸肿”和“术后肿胀”关联起来，检索不到；另一类是复合问题，比如“我准备下周做项目，但下周可能来例假，能一起做吗”，系统拆成了两个独立查询，没有把经期禁忌和项目禁忌合并判断。

调优方案分三步。第一步，在知识库里增加口语化同义词映射，把“脸肿、发红、结痂、掉皮”这些日常说法统一映射到标准词条；第二步，给复杂问题增加“追问框架”，一旦识别到复合条件，先反问“您方便先说下例假大概什么时候吗”，而不是强行回答；第三步，把失败案例每周复盘一次，挑出高频错误沉淀成新的测试样本。

4.3 三个典型的误报/漏报案例和修复方案

第一个案例是开头提到的库存误报。系统上线第三天，库存技能把一批已经预约给客户的玻尿酸标记为“临期风险”，导致库房人员紧急打电话确认，客户被吓一跳。根因就是我们设计reserved_qty字段时考虑到了预约占用，但预警逻辑写的时候漏了条件判断。修复很简单：预警时排除已预约数量大于等于库存总数的批次，并增加状态提示“部分已锁定”。

第二个案例是合规审查过度拦截。我们发现咨询师回复里只要出现“根治”两个字，系统就一律拦截，哪怕客户原话就是“这个能根治吗”。一刀切让咨询师非常烦躁，连续拦截几次后她们差点弃用系统。修复方案是给合规审查增加“上下文判断模式”：如果是引用客户提问、且后续跟了否定说明，比如“不能承诺根治效果”，则放行；如果是咨询师主动承诺，则拦截并标红。

第三个案例是回访任务分配不考虑坐班状态。某位咨询师休假了，系统还是把当天的术后回访任务派给她，电话没人接，客户体验很差。我们的派发逻辑最初只按“负责客户关系”分配，后来加了“是否排班”条件，再不行就自动升级到值班主管。

这个阶段最大的体会是：业务系统的智能体调优不是调模型，是调业务规则和数据质量。表面上是对话不对，翻到根上基本都是规则漏了或字段没维护好。

4.4 算力成本：龙虾版到底费不费钱

很多朋友关心智能体化之后，成本会不会爆。我们内部测了一套成本账。按每天200次咨询会话、50次库存查询、30次档案调用来估算，API调用费用加服务器成本，月度总成本大概在几百元区间，这在机构整体运营成本里基本可以忽略。

但有两个隐性成本容易忽略。一是知识库维护成本，初始整理花了三个人两周，后续每周还要花两小时更新条目；二是跨周的不规则需求识别会产生较多额外调用，比如客户连续追问七八句，模型每句都触发新技能调用，月底账单会比平均值高一截。建议在技能配置里设置会话级缓存，同一客户同一个会话内重复命中相同知识条目时不重复计费。

成本这件事不用过度焦虑，真正贵的不是模型调用，是业务梳理和规则打磨的人工成本。

5. 医美系统敢不敢真上线：合规与安全是真正的门槛

5.1 个人信息和病历类数据的处理边界

医美系统和个人健康数据高度相关，这一块是上线前评审最严的部分。我的原则很简单：能不碰的数据不碰，能脱敏的字段脱敏，能删的痕迹不留。

客户姓名、手机号、身份证号、面部照片、过敏史、治疗记录，这些都属于需要重点保护的字段。数据库层面要求加密存储，应用日志和模型对话记录里默认不记录完整手机号和身份证号，只保留脱敏后的片段，比如“138****1234”。

数据传输层面，我们强制走加密通道，客户端和运行时之间不传原始照片。面部照片这类敏感图像更不建议进向量库或对象存储用于识别，需要保存时也要做访问权限隔离，只允许授权医生角色读取。最小必要原则看起来保守，但在实际事故处理时能帮你少掉无数头发。

系统里我们专门做了一条“数据删除闭环”。如果客户正式提出注销档案，系统会把客户资料从所有业务表、缓存、备份任务里移除，并生成一条删除审计记录。别小看这个动作，很多系统因为漏掉了日志备份里的残留数据，导致“删了等于没删”。

5.2 医疗广告合规：系统里不能出现哪些词

医美宣传的合规红线特别细，系统内置一套规则词库，覆盖绝对化用语和禁止承诺类表述。我们把常用违规表达整理成几个类型。

合规审查技能会拦截上述情况，同时记录被拦截的原文、操作人和时间。咨询师一开始会觉得麻烦，当她们发现被拦截的话术确实容易引发客诉之后，态度就转变了。系统咨询知识库里的标准回复也全部按合规口径重写，相当于把机构最佳实践固化成员工默认答案。

5.3 审计、脱敏、权限闭环的实际做法

合规不是挂一个“过滤敏感词”开关就完了。龙虾版做了一个完整的审计闭环：任何技能被调用，都会在审计日志表里留下一条记录，字段包括操作人ID、技能名称、调用时间、输入参数摘要、返回结果摘要、模型会话ID。

CREATE TABLE compliance_audit_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, operator_id VARCHAR(64) NOT NULL, skill_name VARCHAR(128) NOT NULL, action_type VARCHAR(32) NOT NULL, input_summary TEXT, output_summary TEXT, session_id VARCHAR(128), created_at DATETIME NOT NULL, INDEX idx_operator (operator_id), INDEX idx_created (created_at) );

这张表不是为了好看，而是为了可追溯。一旦出现客诉或者监管抽查，能在一小时之内还原当时系统做了什么、基于什么数据做的、谁触发的。权限方面坚持三个“不”：不开放批量导出接口，不支持按姓名模糊搜索所有同名人并展示列表，不保留永久登录态，登录超过12小时必须重新验证。

多说一句，我们还在管理后台增加了“自查报告”功能，一键生成最近30天的数据操作统计和敏感操作清单。这个功能看起来不起眼，但机构合规负责人特别喜欢，因为以前写报告要手动翻记录。

6. 重新做一遍的话，我会省掉哪些弯路

6.1 项目推进顺序错了会浪费大量返工

复盘全程，最想修正的是项目推进顺序。我们一开始先扑在知识库整理上，花了很多时间把术后护理、项目说明做得非常全，结果直到联调才发现权限模型才是最大的拦路虎，又回头重做接口鉴权。

正确顺序应该先把“最小权限+字段白名单”这个骨架搭起来，哪怕先用一个最简单的问答技能验证调用链路；跑通之后再扩知识库内容。骨架不对，填再多血肉也要推翻。还有一个弯路是我们过早把完整系统推到全员试用，结果咨询师发现系统不够聪明，信任度掉到谷底。后来改成小范围灰度，选了两家高配合度的团队先玩两周，把问题消化掉再扩大范围，效果才明显改善。智能体应用的第一印象非常重要，第一次对话如果翻车，用户很难给第二次机会。

6.2 目前正在做的三个扩展方向

龙虾版不会停在当前版本，下一步想解决三个更实际的问题。第一是语音输入支持，医美机构里很多咨询师习惯直接发语音条，尤其开车路上回客户消息很频繁，OCR和语音转文字能力要整合进工作台。第二是多门店数据隔离模式，目前单机构部署没有问题，但连锁机构需要一套逻辑隔离方案，让总店能看汇总数据、分店只能看自己的数据。第三种是想做客户“项目意向评分”，通过分析历史咨询记录和互动频率，给出客户对某个项目的意向分数，帮助咨询师优先跟进高意向客户。这个能力目前看还有点难度，但方向是对的，等有可公开的测试结果再写一篇。

说了这么多，其实最想说的一句话是：智能体应用跑通不难，难的是让它符合一个行业的真实规则。医美行业那些复杂的业务细节、合规红线、数据责任，才是“龙虾版”真正夹住的东西。技术会持续演进，但搞清楚业务边界永远是做行业软件的第一步。