夜雨聆风一个人做 AI 产品，边界在哪里？
这段时间，我一直在迭代一个农业 AI 小程序。
“一开始，我想得很直接：用户拍一张照片，AI 识别作物问题，然后给出结果和建议。
从技术流程上看，这件事并不复杂。拍照、上传、调用大模型、返回结果，小程序就能跑起来。
但真正测试以后，我很快发现了一个问题：
AI 能识别，不代表用户觉得有用。
更准确地说，当前版本确实能识别一些作物和表面现象，但在具体病害判断和处理建议上，效果还不够好。
这不是一个可以靠再改几句提示词就完全解决的问题。
一、真正的问题不是"能不能识别"，而是"能不能解决问题"
早期版本里，AI 通常能看出一些表面现象：
叶片发黄。
叶片有斑点。
可能存在病虫害。
可能和水肥管理有关。
建议加强田间管理。
必要时咨询专业人员。
这些话从技术上看并不算错。
但对真实农户来说，价值很有限。
因为很多农村用户本身就有多年种植经验。他们不是完全不懂农业，也不是不知道要"加强管理"。
他们真正想知道的是：
这到底是什么病？
严重不严重？
今天要不要处理？
先排水，还是先用药？
要不要拔掉病株？
几天后能不能看出效果？
如果继续扩散，下一步怎么办？
如果 AI 只是把几种可能性都列出来，其实是在把判断责任重新丢回给用户。
这也是我这次最大的感受：
农业 AI 的核心不只是识别，而是诊断之后的处置决策。
二、为什么"一拍就准"没有想象中简单
很多人对农业 AI 的期待是：
拍一张照片，AI 直接判断是什么病，然后立刻给出解决方案。
这个体验当然是理想状态。
但真正做起来以后，我发现它背后需要的东西非常庞大：
大量真实田间图片。
准确的人工标注。
不同作物、不同病害、不同阶段的样本。
早期、中期、严重期的图像对比。
同一症状下不同病因的区分。
针对作物的垂直模型训练。
完整的病害知识库。
可执行的防治建议库。
持续的用户反馈和结果校正。
不同地区、不同天气、不同管理方式下的适配。
这不是一个人短时间内能完整搭起来的系统。
尤其是农业病害识别和普通图像识别不一样。
同样是黄叶，可能是缺肥，也可能是肥害，可能是积水烂根，也可能是病害早期。
同样是斑点，可能是炭疽，也可能是叶枯，也可能是高温灼伤，甚至可能只是照片光线造成的误判。
如果没有足够多的真实样本和反馈数据，只靠通用大模型看图，很容易得到一个"看起来合理，但不够具体"的回答。
“这也是之前版本识别效果不够好的核心原因。
不是流程没跑通，而是要达到用户想象中的"准确诊断 + 具体方案"，背后需要的是一个完整的农业病害识别系统，而不是简单接入一个大模型。
三、通用大模型不适合直接做最终诊断
最初，我把太多判断交给了大模型。
用户上传照片以后，大模型直接看图、直接诊断、直接给建议。这个流程实现起来最快，但结果并不稳定。
“大模型擅长描述现象。
比如它能看出叶片发黄、局部斑点、疑似虫咬、根部信息不足。
但农业病害判断不是简单的图像分类。
它需要结合：作物品种、生长阶段、近期天气、田间湿度、土壤情况、施肥情况、发病部位、传播速度、是否成片发生、是否有根部腐烂、是否有虫卵虫粪霉层。
这些信息不是一张照片就能完全判断的。
如果只靠提示词让大模型自由诊断，它很容易输出一段看起来合理、但实际很泛的建议。
所以我决定调整架构：
“大模型负责看图提取现象，知识库和规则库负责生成结果。
AI 不再是唯一的"诊断专家"，而更像是一个"看图助手"。先提取现象，再由专项知识库生成更稳定的主判断和处理建议。
这个方案没有"万能 AI"听起来那么炫，但更可控，也更接近真实产品。
四、不是接个大模型就能解决的问题
外部看起来，现在的 AI 好像什么都能识别。
拍一张猫，它能识别猫。拍一棵植物，它能识别植物。
所以很多人会自然觉得，拍一张作物照片，AI 应该也能直接识别出是什么病，并给出处理方案。
但真正做过以后，我发现这件事没有那么简单。
“农业病害识别和普通图像识别完全不是一个难度。
识别一只猫，大多数时候只是在判断图片里有没有猫。
但识别作物病害，面对的是一整套复杂的真实场景：
田间照片光线不稳定。
拍摄角度和距离不统一。
叶片可能重叠、遮挡、模糊。
早期病害特征并不明显。
同一种症状可能对应完全不同的原因。
同一种病害在不同阶段表现也不一样。
不同作物、不同地区、不同天气下，判断依据都会变化。
要真正做到"拍一下就准确识别病情，并给出可靠处理方案"，背后需要大量真实田间图片、专业标注、垂直模型训练、病害知识库、规则体系、处置建议库，以及持续的用户反馈和校正。
这也不是产品设计上多加一个按钮就能解决的。
事实上，这个小程序从第一版到现在，业务逻辑、交互流程、结果页文案和 UI 都已经调整过很多次。
从"让用户选择症状"，到"让用户确认 AI 识别结果"；
从"直接给诊断结果"，到"先描述现象，再给主判断和处理建议"；
从"通用农作物识别"，到现在准备收缩为"生姜专项识别"。
每一次调整背后，都是在真实场景里发现：AI 能力本身只是其中一部分，产品怎么组织判断流程、怎么控制不确定性、怎么让用户理解并愿意继续操作，同样重要。
所以这不是"接通大模型就轻松搞定一切"的问题。
“它本质上是数据、模型、知识库、交互流程和真实用户反馈长期迭代的问题。
对于一个独立开发者来说，我必须承认这个边界。
五、一次真实项目带来的认知
这次做"种养一拍"，对我来说还有一个很重要的收获：
我第一次更完整地感受到，一个功能从"想法"到"可用"，中间到底隔着多远。
在需求描述里，它可能只是一句话：
“用户拍一张照片，AI 识别病害，并给出处理建议。
但真正做起来以后，背后涉及的是：
“用户怎么拍。照片不清楚怎么办。AI 识别错了怎么办。结果说得太泛怎么办。用户不相信怎么办。文案怎么写才不误导。
哪些建议能说，哪些不能说。是否要让用户确认。失败页怎么反馈。历史记录要不要保存。结果怎么分享给家人或农技员。
如果后续扩品类，知识库怎么组织。如果识别效果不好，产品责任边界怎么处理。
这些问题不真正做一遍，很难凭空想明白。
以前在大厂做项目时，分工往往非常细。
设计师负责交互和界面，产品经理负责需求和排期，工程师负责实现，算法同学负责模型能力，运营负责反馈。
这种分工当然有它的效率，但副作用是，每个人都很容易只看到自己负责的那一段。
一个功能在需求文档里可能很简单，在设计稿里也很完整，但真正进入开发、接入、测试、用户使用和后续迭代时，复杂度才会一点点暴露出来。
这次自己完整做一遍以后，我对这一点感受很深。
也正因为一个人把链路跑了一遍，我才更明显地看到：
很多产品里的冗余、妥协和低效，并不是某一个角色的问题，而是大家都只对自己那一段负责，却没有人真正从头到尾对用户结果负责。
这种认知，在分工很细的环境里很难自然获得。
“而一个独立项目最大的价值，恰恰是逼着自己跨过这些边界。
你会知道一个需求从"看起来应该很简单"，到"真的能被用户用起来"，中间隔着多少判断、取舍和代价。
即使当前识别效果还没有达到理想状态，我也不觉得这次尝试失败了。
因为它让我更清楚地看到了 AI 产品落地的真实复杂度。
这不是听一门课、看一篇文章能获得的认知。
结语
产品不是把功能列出来。AI 也不是接一个接口就结束了。
一个真正可用的产品，需要在技术能力、业务逻辑、交互体验、用户预期和风险边界之间反复平衡。
既然已经看清楚了这个边界，下一步就是在边界里把事情做扎实。
至于怎么调整方向、为什么决定收缩到单一作物、接下来具体怎么做——下一篇继续说。
