直接说结论这个项目就是典型的“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.03-7天的数据权重设为0.87天以上的设为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个tokenoverlap设置为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时代最核心的竞争力。
