企业官网建设流程全解析

答辩前一周，我们项目文档的标题还叫《基于视觉感知与物联网数据的龙虾养殖辅助系统》，直到演示前一天才改成《养一只自己的龙虾吧》。为什么改？因为评审看了十分钟PPT，最后记住的关键词只有“龙虾”，什么“多模态感知”“决策闭环”一个没记住。这次参加高校AI智能体创新大赛的经历，是我们几个人在大学期间做过最值的一次项目——我们真的把一个会看数据、会推理、会聊天的AI智能体“养”了出来，而且在一群做内容助手、通用问答机器人的队伍里，靠一只龙虾杀出了辨识度。

这篇文章想把整个项目从头到尾复盘一遍，包括选题思路、核心模块拆解、联调阶段踩过的坑、答辩现场被追问的问题，以及如果让我再参加一次会怎么做。适合正在准备各类AI创新赛事的同学参考，也适合所有想了解一个“完整智能体应用”到底由哪些环节组成的人。

1. 从“养龙虾”这个点子到正式立项：我们盯上了大家都不愿意碰的领域

1.1 为什么别人都在卷智能助手，我们却选了个养殖场景

那届智能体创新大赛的要求很简单：做一个能解决真实问题的AI智能体，提交方案文档、演示视频，现场答辩。我看了往届优秀作品，清一色是个人助理、知识库问答、代码生成助手、客服机器人。不是说这些不好，而是同质化太严重，评委看十个队有八个在做同一件事，后面的队伍很难拉开差距。

我们队四个人当时列了一个候选清单：医疗问答、校园服务助手、农业养殖、二手交易解析、自习室预约智能体。划掉校园和自习室这两个“安全牌”之后，我们把目光放在农业养殖上。原因是和学校附近的一家养殖基地有过合作基础，那边愿意开放场地和数据给我们做调研。更重要的是，养殖这个场景里，智能体的价值链条非常清晰：环境数据需要感知，生长情况需要判断，病害问题需要分析，日常管理需要建议——这不是单一模型能搞定的，恰恰是智能体这种“工具编排+对话交互”的形态最擅长应付的问题。

你去看那些大而全的智能体产品，什么都想做，最后什么都做不深。养殖不一样，它有一个非常具体的实体对象：龙虾。我们后来的项目名“养一只自己的龙虾吧”其实藏着两层意思：一层是帮助养殖户养好真实的龙虾，另一层是让普通用户认养一只虚拟龙虾，由智能体根据真实环境和生长数据驱动它的状态变化，相当于把严肃的养殖管理做成了有温度的产品。

1.2 走访养殖基地后，我们提炼出的三个核心痛点

立项之前我们去做了一次实地调研，和基地的负责人聊了整整一个下午。他说的几件事我到现在都记得很清楚：

第一个痛点是水质判断全凭经验。他说自己入行八年，看水色就知道要不要换水，但新招的工人完全看不懂，只能靠浑浊程度猜，经常判断失误。水温、pH、溶氧、氨氮这些指标不是没有仪器，而是仪器只负责把数字显示出来，没有人告诉工人“这几个数字组合在一起意味着什么”。

第二个痛点是生长数据几乎没有记录。一池龙虾养了三个月，绝大多数养殖户只记得总产量和总饲料投入，完全不知道个体规格分布是怎么变化的、什么时候出现了长势分化、哪些批次可以提早上市。没有数据就谈不上优化投喂策略。

第三个痛点是病害发现得太晚。龙虾染病初期外在表现非常细微，工人巡塘时用肉眼很难看出来，等明显发病往往已经扩散了。

这三个痛点摆在一起，你会发现它们正好对应智能体的三个核心能力：感知（视觉识别+物联网数据）、分析（生长模型+水质诊断）、交互（用自然语言给出可执行建议）。所以我们在立项答辩时给评委的核心逻辑是：智能体不是做出来“炫技”的，而是因为农业养殖的天然复杂性本身就要求各环节联动，单做一个识别App解决不了问题。

1.3 立项时我们反复自问的三个问题

确定场景之后，我们内部开了三次会，每次都在过三关：

这项目完成得完吗？赛程给了两个半月。视觉识别、生长预测、知识库问答、Web前端、演示部署，哪一项单独拿出来都不算难，合在一起就是个大工程。我们最后把范围严格控制住了：不做多智能体协作，不做复杂权限管理，不做移动端，只做一条闭环——环境数据进来，视觉模型判定个体状态，生长模型预测趋势，大模型整合输出建议。

数据从哪来？这是最大的风险点。基地同意帮我们采集环境数据，但视觉训练需要大量带标注的现场图像，我们一开始低估了工作量，实际上光标注就花了两周。

凭什么说这是“智能体”而不是普通软件？这是我们在文档里反复强调的区别：整个系统不是固定规则触发的，而是用户在自然语言对话中提出目标，由大模型自主判断需要调用哪些工具、检索哪些知识、给出什么建议。工具是插件式的，后续可以不断扩展。

这三关都想清楚了，我们才正式把名字定为“养一只自己的龙虾吧”，准备开干。

2. 三个核心模块拆解：视觉体检、生长预测、对话式养殖顾问

2.1 视觉体检模块：教智能体“看”一只龙虾

视觉模块是“养龙虾”里最直观的部分，主要做两件事：检测画面里的龙虾个体，判断它的规格和状态。我们在养殖池上方布了两个固定摄像头和一个补光灯，每隔10秒抓拍一帧，持续采集了两周，筛选出有效图像3000多张。标注内容包括三块：目标位置框、体长等级（以已知直径的PVC管做参照物换算）、状态标识（正常/蜕壳/疑似患病/活跃度低）。

模型选型上，我们没有追求最先进的大结构，而是选了轻量级目标检测框架做迁移学习，用预训练权重初始化，只在我们的数据上微调了全部层。这样做的原因有两个：一是数据量不大，从头训练小模型容易欠拟合；二是答辩现场用的是普通笔记本，大模型推理速度撑不住演示。

推理部分代码非常简洁：

import cv2 from detector import load_model, run_inference model = load_model("lobster_det.pt") frame = cv2.imread("pond_latest.jpg") boxes, labels, scores = run_inference(model, frame, conf_threshold=0.45) for box, label, score in zip(boxes, labels, scores): length_cm = estimate_cm(box, ref_pipe_cm=5.0) status = classify_status(frame[box[1]:box[3], box[0]:box[2]]) print(f"detected {label}, conf={score:.2f}, est_length={length_cm:.1f}cm, status={status}")

在实际测试集上，我们最后的mAP在0.85左右，体长估算误差能控制在2厘米以内。这对辅助决策完全够用，但训练过程中也暴露了一个问题：水下图像有折射导致测量偏差，室外光照变化会让误检率飙升。我们后来加了白平衡校正和参照物动态标定，误检率才降下来。这里必须提醒一句：视觉模块80%的时间不是在调模型，而是在处理图像采集环境和标注质量的问题，这部分时间一定要提前预留。

2.2 生长预测模块：用环境数据推算“这周该喂多少”

养殖基地提供了三个多月的传感器历史数据，字段包括水温、pH、溶氧、氨氮、投喂量、光照时长，每10分钟一条。我们的目标不是做精确到克的预测，而是预测未来一周的个体平均体重增长率，然后转换为投喂调整建议。

模型选型时我们放弃了一上来就上时序神经网络的想法。理由很直白：数据量只有几千条，LSTM这类模型在小样本上很容易过拟合；更关键的是养殖户需要知道“为什么这么建议”，树模型可以直接输出特征重要性，“水温影响最大，溶氧其次”这种结论本身就能给养殖户带来认知增量。

特征设计上，我们没有把原始10分钟粒度的数据直接灌进去，而是先做了聚合：过去7天的平均水温、最高水温波动、平均溶氧、最低溶氧、平均pH、平均氨氮、累计投喂量、近三天投喂变化率。目标的特征工程比模型本身更重要，这话在结构化数据场景里永远是真理。

最终用的是LightGBM做回归，预测未来7天体长增长率，平均绝对百分比误差在15%左右。对于一个辅助决策工具来说，这个精度已经能提供不错的参考价值，特别是当模型输出趋势判断（“未来一周生长速度会放缓”）而不是绝对数值时，养殖户更容易接受。

这里放一下特征表和模型输出的配合逻辑：

模型跑出来的结果会和视觉模块的个体状态识别做交叉验证：如果视觉告诉你龙虾活跃度下降，环境数据又显示溶氧偏低，系统就会给出一条综合预警，而不是只看单一数据源。

2.3 对话式智能体模块：让用户觉得自己在和一个懂养殖的人聊天

这是整个系统最“智能体”的部分。我们设计了一条工具调用链路：用户提问后，先经过一个规则过滤器把简单查询直接分发给对应工具，比如“水现在多少度”直接查数据库返回；只有复杂问题才进入大模型做意图理解和任务规划。

这么做是有教训的。最初我们全部交给大模型自由调用工具，结果用户问“水温多少”，模型绕了一大圈调用了生长预测工具，答非所问还浪费token。加了一个意图分类前置之后，这种低级错误基本绝迹了。

我们对大模型的系统提示词做了非常严格的设计，核心内容是这样的：

你是“养一只自己的龙虾吧”的智能养殖顾问。 你可以调用以下工具： - vision_check: 分析最新池塘图像，获取龙虾个体状态 - query_water: 查询最新环境数据和历史趋势 - predict_growth: 预测未来一周生长情况 - search_knowledge: 检索养殖知识库 规则： 1. 用户询问实时状态时，先调用对应工具，基于工具返回结果回答，禁止编造数字。 2. 只有工具返回异常时，再结合知识库给出处理建议。 3. 涉及用药建议时，只提示咨询专业兽医，不直接给治疗方案。 4. 回答必须附带数据来源，例如“根据今天上午10点的水质数据”。

知识库方面，我们整理了常见病害图谱、水质管理手册、龙虾习性资料、养殖常见问答，一共约两百多个条目，切分后存入向量库，采用检索增强生成的方式让大模型在回答具体养殖问题时先检索再作答。效果非常明显，模型的幻觉率大幅下降，很多之前会随口乱编的答案都会变成“我去查一下养殖手册再回答你”。

整个对话过程用户感知是：问一个模糊问题“我的龙虾最近不怎么动”，智能体会自动去调视觉分析、查水质、看生长预测，然后给出复合回答——“视觉检测发现活跃度偏低，近三天溶氧均值略低于正常水平，预测下一步生长速度会放缓，建议先加大增氧，今晚减少投喂量观察一下。”

3. 开发和联调阶段：数据、识别、任务编排三个大坑

3.1 网上找来的数据集根本不能用

这是整个项目我们摔得最疼的一跤。刚开始训练视觉模型时，为了快点跑通流程，我们直接从公开网络上下了一堆龙虾图片凑数据集。当时觉得“AI不就是这样吗，网上找数据，标一标，训练”，结果第一版模型在真实养殖池画面上的表现惨不忍睹，识别率低到队友想放弃。

回头分析原因其实不复杂：网上的龙虾图大多是菜品图、养殖环境特写、标本图，拍摄角度在正上方俯拍的极少；背景干净整洁，水色清晰，而我们实际场景里的水面有浮游生物、有气泡、有阴影，画面杂乱得多。领域偏移(data domain shift)四个字，我们用了十几天才真正体会到。

后来我们调整策略，在基地架设了两台设备做定向采集，专门模拟真实使用场景，再配合弱光条件下的补光增强，才逐步把识别效果拉回来。这个过程让我彻底明白了一个道理：AI项目的效果上限从来不是在模型网络结构上决定的，而是在数据采集和数据标注阶段就定死了。后面有人再问训练技巧，我会先问一句：你的数据和真实推理场景匹配吗？

3.2 视觉模型从“能跑”到“跑得动”的取舍

比赛现场答辩的电脑是我们自己的笔记本，性能有限。最初的实验版本用的是较大尺寸的检测模型，精度不错，但在CPU上推理一帧要好几秒，如果是GPU也才勉强达到每秒十几帧。现场演示如果卡到这种程度，评委体验会很糟糕。

我们花了大概一周时间做模型轻量化：先换用更小的输入尺寸，再尝试了不同规模的网络结构，最后选定了一个在精度和速度之间相对均衡的版本。实测在笔记本GPU上能达到每秒20帧左右的推理速度，展示效果足够流畅。另外，我们把“识别到龙虾后的状态分类”拆成了一个更小的分类网络，这样目标检测只需要负责定位，状态判断可以并行处理，整体延迟反而降了30%。

还有两个工程细节值得分享：一是摄像头抓拍时间不固定，如果正好在投喂导致的浑浊期抓图，效果会很差，我们干脆把抓拍逻辑改成“水质浊度超过阈值就跳过本帧”，从源头减少脏数据；二是现场演示时网络环境不可控，我们把视觉服务改成了本地调用，所有模型文件随项目打包，确保断网也能演示。

3.3 智能体“乱调用工具”和联调阶段的降级方案

联调阶段最大的麻烦不是模型效果，而是“模型行为不可控”。最开始我们让大模型自由选择工具调用，结果出现各种诡异行为：

• 用户问“氨氮高了一点是怎么回事”，模型没查工具就直接根据常识回答，而且数字是编的；
• 用户问“最近适合上市吗”，模型调用了视觉分析工具（其实应该先查生长预测和市场价格趋势）;
• 用户闲聊“今天天气不错”，模型也尝试调用工具。

这些问题如果不解决，答辩现场很可能翻车。我们逐步加了三层护栏：

第一层是刚才提到的规则过滤器，把60%的简单查询挡在模型调用之前，不消耗token也不给模型犯蠢的机会。

第二层是工具结果强制注入。模型只能基于工具返回的真实数据进行回答，不能自由发挥数字。我们在实现上把工具返回的JSON结构化为上下文片段，拼接到模型生成的请求里，并要求模型“如果数据不足以回答，直接说信息不足”。

第三层是服务降级。视觉服务挂了，智能体自动提示“视觉模块暂不可用，正在基于环境数据和历史记录回答”；生长预测服务挂了，就只提供水质分析和知识库建议。这样即使演示现场某个服务崩溃，系统还是能维持一段对话，不会整个白屏。这层设计评委后来专门提过，说“至少你们考虑了产品在真实世界里会挂的情况”。

系统架构经过这轮折腾后稳定成了下面这个结构：

4. 比赛现场：评委问得最多的问题，我们怎么接住的

4.1 “你们用的模型不都是现成的吗，创新点到底在哪”

这个问题几乎每个做应用型项目的队伍都会被问到。我们当时的回答分了三个层次：第一，创新不在于模型，而在于把目标检测、生长预测、知识检索、大模型对话这四类能力编排成一个能自主决策的闭环，这是传统的单一模型应用做不到的；第二，我们在养殖领域做了数据层面的深度适配，包括现场数据采集标注、领域知识库构建、体长测量标定，这些脏活累活恰恰是通用模型落地的真正壁垒；第三，产品形态本身是创新的，同时服务养殖户和普通用户，这个定位在比赛现场没有第二家。

最后我又补了一句：如果创新只能是“从零发明一个模型”，那绝大部分工程类项目都不该参赛了。实际上的创新大赛看的应该是解决问题的能力。

4.2 “识别准确率不够高，养殖户怎么敢用”

这个问题很尖锐。我们没有回避，直接说了真实数据：当前体长估算误差在2厘米左右，状态识别置信度低于0.45时会自动标记为“无法判断”，不会硬给结论。我们设计的逻辑是“低置信度时建议人工复核”，而不是让系统强撑着做判断。评委追问生产环境能不能做到90分，我们坦诚地说不能，但我们的目标不是替代养殖户的经验，而是帮新手快速接近老师傅的判断水平，同时用数据把经验沉淀下来。评委对这个态度是认可的。

4.3 “不做成大模型对话，做个传统软件不也可以吗”

这个问题其实是我们最有底气的。传统软件的逻辑是固定流程：界面里一堆按钮，用户自己选择“查水质”还是“看生长曲线”。但我们这个场景里，用户往往不知道自己该先看什么，更不会把多个指标组合起来分析。智能体的价值就在于用户只需要用自然语言描述一个模糊目标，系统会自动完成多步检索和工具编排。

养殖户文化水平普遍不高，让他们对着十几个图表做判断不现实。而对话问答的方式几乎零学习成本，这就是“大模型+工具调用”不可替代的地方。

4.4 “项目成本多少，能真的落地吗”

我们在基地做了小范围实测，硬件成本主要是一路摄像头、一个水质传感器集成箱、一台本地推理主机，整体采购成本不算高。大模型API按调用量计费，我们做了规则过滤器之后，每天的调用量其实很有限。所以单点部署成本可控，一个小型养殖池完全承担得起。

我们不吹它能全面替代人工，而是定位成辅助工具：提供更早的预警和更系统的数据记录，把“经验”变成“经验+数据”。基地负责人试用后的原话我记得很清楚：“以前我看水色是猜，现在你们这个系统能让我多一个判断依据，挺好的。”对我们来说这已经是最好的反馈。

4.5 “你们的智能体现在一个人工智能体也没有，算不算套壳”

问这个问题的是一个看起来懂行的评委，当时我们多少有点窘。冷静下来后我们回答：大语言模型是智能体的大脑，但智能体本身的定义是由环境感知、决策规划、工具行动构成的循环，我们实现了感知输入、规划工具调用、生成反馈这个循环，这已经具备智能体的核心结构。我们承认还没有做多智能体协作和长时间自主规划，这是未来方向，但如果拿着“多智能体才算智能体”的标准，市面上大部分参赛项目的复杂度都不够看。

后来我复盘觉得，这种诚实的回答反而比强行辩护加分，评委要的不是你完美无缺，而是你是否清楚自己的边界在哪里。

5. 复盘与建议：如果再参加一次，我们会做哪些不一样的事

5.1 时间线和人力分配：工程项目的排期全部踩歪了

这是我们的真实排期表，对比一下就知道哪些环节被低估了：

总时长比预期超了将近两周，最后能赶在截止时间前交完全靠压缩休息时间。回过头看，最应该提前做的是数据采集，因为真实场景里的图像质量、标注一致性、环境干扰这些不确定因素太多，必须给它们留出足够冗余。

5.2 三个明确的教训：先解决数据再谈模型，先跑通闭环再优化细节

第一个教训是数据优先。我们早期花了大量时间比对各种模型的精度差异，后来发现只要训练数据和真实场景匹配，哪怕模型结构普通效果也差不到哪去。反过来，数据质量不行的时候，换什么模型都没用。

第二个教训是先纵向跑通闭环再横向加功能。我们开发中期一度想把多个高级功能都塞进去，结果主线联调一直没法稳定跑通。最后把所有扩展功能全部砍掉，才在截止前把“水质数据->生长预测->对话建议”这条主线打磨完整。比赛评审看的是主线完成度，不是功能列表长度。

第三个教训是演示环节必须做离线预案。任何依赖外部网络、外部API的环节在答辩当天都可能出问题。我们最后把模型全部本地化，数据库落在测试机上，完整离线走演示流程走了不下十遍，心里才算有底。

5.3 给下一届参赛者的工具箱和三个准备清单

技术栈上，我强烈建议守住“成熟组件+简单集成”的原则，不要临场造轮子。我们用的都是社区成熟方案：Python做核心逻辑，FastAPI做后端，Vue做前端，LightGBM做表格数据建模，向量库做知识检索，目标检测直接用开源框架的预训练权重。这些组合的好处是文档多、案例多，遇到问题搜一下就有答案。

如果让我给下一届参赛者列一个准备清单，我会写这三条：

第一，选题前必须找到真实场景中愿意配合的人和真实数据源，没有数据源就尽早换题。我们见过太多队伍做到一半发现网上数据无法支撑项目，临时转向，最后成品很单薄。

第二，答辩前至少安排三场模拟答辩，每场找两个“会挑刺”的同学来问问题。我们在正式答辩前被队友轮番提问，把很多盲点提前暴露出来了。特别是技术边界类问题（“如果XXX怎么办”），提前演练过，现场答起来区别非常大。

第三，文档要把“为什么这么做”写清楚。评委看文档的速度比我们想象中快，他们首先找的是选题动机和逻辑链条，而不是算法公式。我们文档里专门写了两页“为什么不是传统软件而是智能体”的分析，后来评委提问时明显围绕那边的讨论最多。

5.4 最后说点真心话

比赛结束之后，我们几个人把项目代码封了档，但“养一只自己的龙虾吧”这个项目带来的影响还在持续。前阵子基地负责人还在用我们部署的测试系统记录水质，说他以前完全不看数据，现在每天早上去看一遍趋势图已经成习惯了。

我自己最大的感受是：参加AI智能体创新大赛，比拿奖更有用的是完整经历了一遍“从模糊想法到可用样例”的全过程。做一个通用智能体Demo容易，做一个能落到具体场景里、经得起真实数据检验的智能体，需要的不只是模型能力，更是对问题的理解深度和工程落地的耐心。

“养一只自己的龙虾”这个项目教会我最大的一件事是：AI技术的价值，不在于最多人用的框架，而在于最合适的时间出现在最需要它的场景里。就算那只是一个养殖池边的小小屏幕，也足够让一个项目感到骄傲了。