企业官网建设流程全解析

直接说结论：这个项目就是典型的“AI Coding把想法变成产品”的缩影。我接到这个需求时，客户给的周期是20天，要交付一个基于大模型、能分析体温、心率、血压、血氧等体征数据的医学辅助分析系统。如果按传统开发流程，需求梳理、架构设计、后端联调、前端打磨一圈下来，怎么也得一个半月。但这一次，我用AI编程工具辅助编码，硬是在20天内连带着知识库构建、算法调优、报告生成一起交了货，还留出了两天的缓冲做测试。

整个过程走下来，我的体会是：AI Coding不是帮你少写几行代码那么简单，它真正改变的是你从一个“打字员”变成一个“架构师”和“评审者”的效率。你能把更多精力放在业务逻辑、数据质量和模型行为控制上，而不是被繁琐的样板代码拖死。这篇博文，我就把整个项目的思路、技术选型、实操细节、踩坑记录都拆开讲清楚，给也想用AI Coding快速落地一个垂直领域大模型应用的朋友做个参考。

1. 项目整体设计与技术选型

这个项目的名字叫“Ai体征分析助手”，表面上看是“大模型+数据分析”，但真正做起来，你首先要面对一个灵魂拷问：医学场景的数据，到底该不该让大模型直接碰？答案是不能。不是说大模型能力不够，而是它的“幻觉”和“不确定性”在医学语境下是不可接受的。你可以让模型帮你写诗、写文案，出错了无伤大雅，但当你告诉用户“你的血氧偏低，可能存在呼吸衰竭风险”时，这句话必须是可追溯、有依据、经得起推敲的。

1.1 核心需求解析：不是聊天机器人，是“辅助决策工具”

需求方是一家做社区健康管理的小团队，他们手里有大量的体征采集设备，能拿到用户的心率、血压、血氧、体温、呼吸频率这些基础数据。他们找我做系统的原因也很直白：数据是有了，但缺少一个能把这些数字“翻译”成人话、并给出健康建议的智能化层。

所以这个系统的核心需求有三层：

第一层是数据接入与清洗。设备上传的数据格式乱七八糟，有JSON、有CSV、甚至有手工录入的Excel，单位还不统一，血压有的是mmHg有的是kPa，体温有的报摄氏度有的报华氏度。不解决数据归一化，后面什么都白搭。第二层是智能分析。系统需要根据多维度体征数据，结合用户的基础信息（年龄、性别、既往病史）给出风险评级和倾向性诊断建议。第三层是人机交互。用户可以通过自然语言对话的方式查询分析结果，比如“我最近的血压趋势怎么样？”、“我的血氧持续偏低需要注意什么？”，系统要能自动调取数据，结合医学知识生成通俗易懂的回答。

这本质上不是一个聊天机器人，而是一个面向健康管理场景的辅助决策工具。它要做的是将体征数据映射到医学知识体系里，用大模型的推理能力连接“数据”和“知识”，但最终结论必须建立在结构化规则和权威知识库之上。

1.2 技术方案选型：为什么用LlamaIndex而不是LangChain

选型阶段，我纠结过LangChain和LlamaIndex。坦白说，LangChain生态更丰富、社区更大，但在这种“以数据检索和知识增强为核心”的场景下，LlamaIndex的数据接入能力明显更顺手。它能直接把PDF、CSV、数据库统一抽象成文档，然后通过索引结构做向量检索和关键词检索的混合召回，省去了我大量胶水代码的编写工作。

模型层面选择了国产的Qwen系列，原因很实在：一是中文医学语义理解更稳，二是部署成本可控，三是在医学知识问答的测试集上它的表现比同体量的其他开源模型更扎实。我采用API调用的方式而不是本地私有化部署，主要是考虑开发周期只有20天，本地部署一个7B模型虽然可行，但团队里没人有精力去运维推理服务。

至于底层的向量数据库，用了Chroma。它轻量、零配置，适合项目早期快速跑通业务逻辑。数据量一旦上来再迁移到更专业的向量库也不迟，因为LlamaIndex的存储抽象层做得比较干净，换存储引擎不用动业务代码。

提示：做垂直领域大模型应用，选型的第一原则不是“哪个框架最火”，而是“哪个框架能让我在最短时间内把核心链路跑通”。时间成本就是最大的成本。

1.3 为什么是20天：周期拆解与工作流设计

20天不是拍脑袋定的，是甲方给的最后期限。我把整个周期拆成了四个阶段，每个阶段都有明确的交付物：

• 第1-3天：需求确认、数据摸底、技术选型、环境搭建，产出项目骨架和核心依赖的验证Demo。
• 第4-10天：数据处理管线和知识库构建，完成体征数据归一化、医学规则配置、知识文档切分入库。
• 第11-16天：核心功能开发，包括对话式问诊流程、RAG问答链路、风险评级算法、报告生成模块。
• 第17-20天：系统联调、Bug修复、安全审查、部署上线。

这个排期里，我把最核心的时间投入到数据与知识工程上，而不是编码上。因为在这个项目里，80%的代码是“翻译层”和“调度层”，本质上是把数据转换成Prompt、把模型输出转换成结构化结果的流水线工作。这些工作对AI Coding工具来说是最擅长的，我只要定义好输入输出的契约，剩下的交给工具生成，我负责review和调整。

2. 体征数据的归一化处理：一切分析的地基

体征分析这个场景有意思的地方在于，看起来是“AI在分析”，实际上“数据质量”决定了AI的上限。我第一天拿到真实数据的时候就发现，数据乱到让人头大。同一个用户，昨天的心率单位是“次/分钟”，今天的记录变成“bpm”，血氧有的记“98%”，有的记“98”，还有的设备上传的血压数值是字符串“120/80”，需要单独解析。

2.1 数据画像与清洗规则

要设计清洗逻辑，先得知道数据都长什么样。我把数据源分成了三类：设备接口直传的设备数据、人工录入的随访数据、以及从历史健康档案里导入的静态数据。这三类数据的时效性不同、完整性不同、可信度也不同。

设备数据信噪比最高，但偶尔会有传感器异常，比如心率掉到个位数、体温超过45℃，这些明显是非生理值。人工录入的数据容易出现单位混淆和错别字，比如“血压120-80”、“体温37.5度”这种非标准格式。历史档案数据的问题是缺失严重，很多人只记录了3年前的体检数据，中间是断档的。

我做的第一件事是建立一套统一的体征数据模型，定义好每项指标的原子字段、标准单位、正常范围、危急值阈值。比如血压统一为mmHg，体温统一为℃，心率统一为次/分钟。清洗规则采用“硬规则+软规则”双层设计：硬规则负责拦截明显非法的值，比如心率超过240或低于20直接丢弃；软规则负责标记可疑值，比如血压130/95，虽在合理范围但舒张压过高，需要结合用户既往数据进行交叉验证。

2.2 医学参考范围表的构建

大模型本身不擅长处理精确的数值判断，它更适合做语义理解和生成。所以我把体征分析拆成了“规则引擎计算+大模型语义解读”两步。规则引擎负责判断每项体征数据是否在正常范围内、偏离程度如何、有没有触发危急值，大模型负责根据这些结构化结果生成解释和建议。

为了让大模型有据可依，我构建了一张医学参考范围表，囊括了常见体征指标的正常区间、异常分级和对应风险提示。比如血氧饱和度，正常范围是95%-100%，轻度缺氧90%-94%，中度缺氧80%-89%，低于80%就是重度缺氧。体温方面，腋下体温36.0℃-37.0℃算正常，37.3℃-38.0℃为低热，38.1℃-39.0℃为中热，超过39℃就是高热。

这张表的意义在于把医学知识“结构化”了。大模型不直接回答“这个体温算不算发烧”，而是先由规则引擎算出结论“体温38.5℃，属于中热”，再让大模型针对这个结论生成解释段落。这样即使模型在语言表达上有点偏差，核心判断也不会出错。

2.3 多源数据的时间对齐策略

体征分析还有一个绕不开的坑：时间对齐。用户可能早上测了一次血压，下午又测了一次，第二天上传了一份体检报告，这些数据的时间粒度完全不一致。如果直接把数据拼接起来给模型，模型根本分不清哪条记录是新的、哪条是旧的，给出的分析结果自然没有意义。

我采用的策略是“分段切窗+时间衰减权重”。系统把用户最近30天的体征数据按照时间戳排序，然后划分成一个个分析窗口，每个窗口至少包含一条有效记录。分析时，越近的数据权重越高，比如最近3天的数据权重设为1.0，3-7天的数据权重设为0.8，7天以上的设为0.5。这样能避免陈旧的异常数据拖累当下的整体判断。

另外，我还为每项体征生成了时间序列的变化趋势特征，比如“心率从85降到72，整体呈下降趋势”、“血压在早上8点时段偏高，持续3天”。这些特征被拼进Prompt，让大模型不光是看单一数值，还能感知变化方向和节奏，生成的建议会更贴近真实情况。

3. 对话式体征分析功能的实现

这个系统最核心的用户体验就是自然语言交互。用户不是去看一张满是数字的表格，而是像跟一个健康助手聊天一样，问“我最近血压控制得怎么样”，系统就能自动检索数据、调用规则引擎、生成分析报告。这里涉及两个难点：怎么把用户问题转化为系统可执行的分析任务；怎么让模型回答严谨且不越界。

3.1 从用户查询到结构化分析任务的拆解

我设计了一个“意图识别+槽位填充”的前置模块，而不是直接把用户问题丢给大模型。意图识别本质上是一个多分类任务，系统定义了几个核心意图：查询趋势、查询异常、分析原因、生成报告、获取建议。

当用户问“我最近血压怎么样”，系统会先识别出意图是“查询趋势”，然后抽取槽位“血压”和时间范围“最近（默认7天）”。这些槽位被用于生成SQL查询语句，从数据库里拿到对应的体征数据序列，再传入规则引擎做分析。

这里可能有人会问，为什么不用大模型直接做意图识别？我的经验是：大模型做意图理解确实很准，但它返回的结果不稳定，有时候会多给你点惊喜，有时候会漏掉关键槽位。相比之下，用一个轻量级的分类模型或者基于规则的关键词匹配来锁定意图，再用大模型做实体识别和槽位抽取，这样更稳。

经过反复测试，我用正则+关键词先行粗筛，然后用大模型做二次精修。比如用户说“帮我看看我这几天睡不好，是不是血压高了”，粗筛阶段能命中“血压”和“最近几天”，但“睡不好”这个症状和血压的关联性就需要大模型来理解。系统会把这个完整的Query拼进分析Prompt，由模型判断症状与体征之间的潜在联系。

3.2 结构化提示词的设计与输出约束

医学场景的Prompt设计和通用场景完全不同，不能“想到什么写什么”。我最终采用了一套结构化的Prompt模板，分为四个部分：角色设定、任务描述、输入数据、输出格式。

角色：你是一名全科医生，请根据用户的体征数据与历史记录，给出客观、专业的健康分析。
任务：分析用户的体征异常情况，解释可能的原因，给出合理的生活建议和就医提示。
输入：以下是用JSON格式表示的体征数据和分析指标……
输出：必须遵循以下JSON结构返回：{"异常项":[], "整体状况":"", "可能原因":[], "生活建议":[], "就医提示":""}

这套模板的关键在于“契约明确”。输出必须是合法JSON，异常项必须对应规则引擎标记的结果，所有建议必须是通用性健康指导，不能包含任何用药处方、诊断断言。严禁出现“你可能患有某某疾病”这种词句，统一改成“建议前往专科门诊进一步检查”。

大模型对这种强约束的输出格式相对听话，但偶尔还是会犯小毛病，比如字段名拼错、JSON里混入了多余文本、或者换行符穿进字符串。我在解析层做了三层兜底：第一层直接用JSON解析，失败则进入第二轮，用正则把模型输出中的JSON片段抠出来再解析，如果还不行就返回“生成失败请重试”。这个兜底机制在实测中挽回了不少体验分。

3.3 体征分析报告生成与多轮追问逻辑

单轮问答只是最基础的功能，真正让这个助手显得“智能化”的是多轮追问。比如用户输入“我血压高”，系统会先给出基础分析，然后追问一句“请问你最近是否有熬夜或者情绪波动？这会影响血压的短期波动”。这个追问逻辑不是靠大模型放飞自我生成的，而是后台配置了一个追问规则表。

规则表的设计思路是：当某个体征指标被判定为异常时，系统自动弹出对应的追问问题。血压异常，追问睡眠与盐摄入；血糖异常，追问饮食结构与运动频率；血氧异常，追问是否处于安静状态、有无吸烟史。这些追问结果会被记录并纳入下一次分析的上下文。

最终的报告生成则基于一个综合数据包，包含：用户基础档案、体征异常清单、综合分析文本、健康建议列表、就医提示。这些内容通过模板拼装成一份结构清晰的分析报告，转成PDF前还会由模型生成一段“总结概述”，放在报告开头。整体跑下来，报告生成速度控制在5秒以内，基本满足交互预期。

注意：在医学分析里，追问不是随意发挥，每一种追问都应该是“有依据的”、能影响分析的。别让模型为了显得智能而乱问，这样不仅干扰用户，也会污染后续的数据判断。

4. 精准检索与知识库构建：让大模型回答有据可依

如果你以为这个系统只要把问题丢给大模型，再结合一点体征数据就能跑，那就大错特错了。大模型的泛化医学知识在通用场景下可用，但到了具体健康管理场景，必须引入外部知识库，把权威的医学常识、异常指标解读、健康建议等内容融合进回答链路。这就是RAG（检索增强生成）要做的事。

4.1 知识库的数据来源与清洗策略

这个项目的知识库来源主要有三块：公开的医学健康科普资料、体征指标解读手册、以及健康管理行业的标准操作规范。我收集了各种来源的资料后，第一时间做的不是切分入库，而是清洗去噪。

为什么清洗放第一？因为公开资料的质量参差不齐，有些科普文章的行文逻辑混乱，有些医学术语使用不严谨，有些内容之间甚至存在互相矛盾的说法。如果把这些原始内容直接切分成chunk丢进向量库，检索的时候很容易召回一些语义相近但信息错误的内容，那分析结果的可靠性就大打折扣了。

清洗策略上，我按章节标题过滤、按段落长度过滤、按关键词黑名单过滤。去掉纯广告宣传内容、去掉过时的诊疗建议、去掉内容空洞的冗余段落。每一份清洗后的文档都标注了来源类别和内容主题，比如“血氧饱和度解读”、“高血压生活方式建议”、“体温异常处理流程”，方便后续按主题做索引。

4.2 文档切分与向量化参数的选择

文档切分是最容易被忽略但最影响检索效果的环节。切得太粗，一个chunk包含多个主题，检索时语义被稀释；切得太细，单个chunk信息量不足，模型拿不到完整的上下文。我反复测试后，采用的切分策略是：优先按章节标题切分，二级标题下如果内容过长，再按段落边界重叠切分。

chunk size设置为512个token，overlap设置为50。512个token大概能覆盖700-800个汉字，对医学知识片段来说刚好能容纳一个完整的知识点；50个token的重叠能避免句子被拦腰截断，保证上下文语义的连贯性。这里要特别说明一下overlap的作用：如果你不设重叠，一个长段落可能在第300个token处被切断，下一段从第301个token开始，那第300和第301个token之间的语义就被割裂了，检索时容易丢失关键信息。

向量化模型用的是bge-large-zh，它对中文语义理解表现优秀，在C-MTEB中文语义基准上的排名是前几位的。embedding维度是1024维，检索时采用余弦相似度作为距离度量。数据量目前约2万多个chunk，对于这个量级，Chroma的索引效率已经足够。

4.3 混合检索与重排序策略

只用向量检索是不行的。医学文本里有很多专有名词，比如“心肌梗死”和“心梗”在向量空间里的距离可能很远，但语义上是同一个东西。这时候需要借助关键词检索来兜底。我采用“向量检索+BM25关键词检索”的混合方案，两个通道各自召回Top50，然后合并去重，再用rerank模型对结果重排序。

重排序的目的不仅是提升相关性，更是为了剔除那些“看似相关实际无效”的内容。比如用户问“血氧低于90怎么办”，向量检索可能召回一段讲“血氧饱和度正常范围”的文章，虽然相关但不针对问题。重排序模型我选用了一款开源的交叉编码器模型，它把query和每个doc拼接后作为一个整体输入模型，打分结果比单纯的双塔向量模型要准确得多。

最终取Top5的文档片段，连同用户的体征数据和规则引擎分析结果一起拼入Prompt，生成最终回答。这个链路的好处在于：模型生成的内容不再是无源之水，它的每一个判断都有知识库中的段落作为背景支撑，准确性和可信度明显提升。

5. 项目管理与AI Coding的协作模式

聊完技术，我想说说这20天里最重要的软技能：怎么用好AI Coding工具来提效。网上有很多人用AI编码，但大多是拿来写小脚本、做Demo。真正把一个完整系统压进20天交付，需要一套自己的协作方法论，不是让工具随便生成代码然后祈祷能跑就行。

5.1 AI Coding工具在项目里扮演的角色

我把整个项目的编码工作拆成了三类：一类是“胶水代码”，比如数据库连接、HTTP接口、数据格式转换、前端基础组件，这类代码最适合交给AI生成，量大、重复性高、逻辑简单；二类是“业务逻辑代码”，比如体征数据的归一化、规则引擎、RAG链路编排，这部分我会写清楚接口定义和设计要求，让AI生成初版，我再review修改；三类是“关键算法与模型代码”，比如重排序策略、Prompt模板的拼接逻辑，这部分我坚持手写核心部分，因为它的稳定性直接影响系统质量。

所以我跟AI Coding工具的协作模式是“我定义需求骨架，AI负责填充血肉”。我会先把整个项目的目录结构、关键接口的数据契约、模块之间的调用关系都用文档定义清楚，然后让AI按照这些约束去生成具体实现。这比那种直接说“帮我写一个体征分析系统”然后让AI自由发挥的方式要可靠得多。

5.2 分支管理、代码审查与AI生成的上下文管理

AI生成的代码也不是拿来就能用的。项目中期我遇到一个深刻的教训：AI生成的代码在单测场景下表现正常，但整合到主分支后，因为某个数据格式假设不一致，直接导致查询接口在特定参数下返回空结果。这个Bug整整耗费了一天排查。

从那以后，我建立了一套强制规则：AI生成的所有代码必须先过“代码审查清单”。审查清单包括数据边界检查、异常处理、空值判断、日志记录。每次AI完成一个功能节点，我就把功能代码提交到一个独立分支，跑完接口测试再合并主分支。这套流程虽然增加了工作量，但避免了AI代码“掺沙子”式的隐性污染。

上下文管理也是一个不容忽视的问题。Coding工具能记住的上下文有限，超过阈值后它会忘掉项目早期的设计约定。我的对策是：在项目根目录维护一份“开发约定”文档，包含技术栈、数据模型定义、接口命名规范、页面路由结构，每次让AI生成新功能前，先让它阅读这个文档。这就像给AI编程助手喂了一颗“长效记忆药丸”。

5.3 20天周期的效率杠杆：模板化、组件化、自动化

真正让20天交付成为可能的，不只靠AI Coding工具的生成能力，还要靠工程上的效率杠杆。我用三个手段把时间压缩到极致。

第一是模板化。项目的后端框架使用一套自己沉淀的企业级模板，里面封装了统一的异常处理、日志中间件、权限校验、数据库访问层。AI生成的新接口直接套用模板，不需要每写一个接口都从零开始。第二是组件化。前端所有的表格、表单、趋势图表、报告预览都封装成了通用组件，不同的分析场景复用同一套组件库，只是传入的数据不同。第三是自动化。使用自动化脚本一键构建测试环境，使用自动化接口测试用例一键回归核心功能。这些基础建设花的2天时间，在后期的联调阶段至少省下5天。

这20天走下来，我最大的感受是：AI Coding的能力边界不是由模型决定的，而是由使用者的“定义能力”决定的。你能把需求拆得多细、把数据契约定得多清晰、把结果验收标准设得多明确，AI就能帮你做得多好。反之，如果你自己都说不清楚要什么，AI生成的代码就注定是一团你也不想读的乱麻。

6. 复盘：同类场景的可复制路径

如果有朋友也想像我一样，用AI Coding快速落地一个垂直领域大模型应用，我觉得可以把这条路总结成一套可复制的打法。这20天不是灵光一现，而是一套方法论的自然结果。

6.1 从数据到知识，从知识到决策的链路设计

任何一个行业里的大模型应用，本质上都在做同一条链路的搭建：数据 -> 知识 -> 决策 -> 表达。数据层解决“有什么”，知识层解决“依据什么”，决策层解决“怎么判”，表达层解决“怎么说”。

在你动手写任何代码之前，先把这四层想清楚，每一层的输入输出是什么、用什么东西实现、怎么衔接下一层，这套规划比选什么技术栈重要得多。我在这个项目里，数据层用了关系型数据库存储清洗后的体征记录，知识层用了向量库+BM25索引的RAG架构，决策层用了规则引擎+大模型协同，表达层用了多轮自然语言对话和结构化报告。这个链路不是从哪本书里抄来的，是根据项目的实际场景一点一点磨出来的。

6.2 做垂直领域AI应用的两条铁律

第一条铁律：规则可以处理的，不要交给模型。数值判断、范围校验、格式转换这类任务，用代码写死更简单、更可靠、更便宜。大模型只做语义理解、内容生成、逻辑推理这类“非它不可”的事。第二条铁律：模型输出必须经过校验才能面向用户。尤其是医学、法律、金融这类领域，模型生成的文本里任何一句关键结论，都必须在后台有对应的结构化数据或知识依据支撑，否则宁可截断也不要输出。

这两条铁律看起来简单，但我在实际项目里见过太多人栽跟头。有人让大模型直接算血压是否正常，结果模型一本正经地输出“您的血压稍微偏高，建议减少盐分摄入”，但实际上用户的血压是120/80，完全在正常范围。这就是典型的规则和模型的边界没划清楚。

6.3 医学AI应用的局限与敬畏心

最后我还是想泼一盆冷水。大模型再怎么强大，它也只是工具，不是医生。医学AI应用首先要有安全底线，这种安全底线体现在：永远不要给用户直接下诊断的错觉，永远要在回答里加入“仅供参考、不能替代专业诊疗”的免责声明，永远是发现危重指标先报警而不是先聊天。

这个系统在上线前，我专门做了一个安全审查流程，把模型输出里所有可能出现的高危词句都拉了一个清单。比如“你可能患有”、“根据你的症状判断”这类措辞是绝对禁止的，系统统一转换成“与相关的风险因素需要关注，建议至科门诊进一步检查”。语气上的克制不是胆小，而是对医疗场景的尊重。

20天做一个医学分析系统，时间确实紧，但并非不可能。核心在于用对方法、选对工具、守住安全底线。AI Coding大大降低了编码的体力成本，让你有精力去思考业务、去调教数据、去打磨细节。这套思路不只适用于医学场景，你在任何垂直行业里想做AI应用，都可以参考同样的打法去拆解、去构建、去交付。最后说一句我反复强调的话：对AI生成的一切保持审视，这是所有开发者在AI时代最核心的竞争力。