不会写代码，就不能玩转 AI 应用？未必！本文将以作者在 dify 平台搭建工程选型应用的实践为例，拆解 AI + 自动化的真实落地过程，帮你掌握“让 AI 写代码”的实操技巧，轻松跨过技术门槛，搭建属于自己的 AI 工具。
最近在dify上搭建公司内部的AI应用，比如某些机械组件的选型，工程师自己做可能需要一两小时，现在通过AI应用选型，一两分钟就能搞定，又快又准，而且还能输出完整的文档。当然过程中也经历了一些曲折，走了一些弯路。
以电机选型举例，用户输入参数后，首先要用参数计算，根据计算结果从电机的数据库表做初步筛选，然后利用初筛出来的电机参数进行计算，再一次筛选，最后给出符合条件的电机型号。那么整个过程至少有两次计算、两次筛选，开始通过大模型（LLM）节点进行计算、筛选（把常用型号表导入资源库），但很快发现了问题。
第一，常用型号表导入资源库后，只能支持关键字检索和语义检索，却不支持条件查询，无法准确筛选。这个问题倒是很快解决，把型号表导入数据库，在dify上利用SQL执行节点去查表，一下就把符合条件的型号初筛出来了。
当然SQL执行节点需要前置一个参数提取节点，提取前面的计算结果，才能形成完整的SQL查询语句。
第二个问题更棘手一些，通过LLM去计算，不仅时间长，还容易出岔子，不靠谱。Qwen算得倒是快，但失误率比较高，特别是多个复杂的计算，不准的概率可能有30%以上；DS-R1，准确率高一些，但也有10%左右的次数出问题，而且时间很长，动不动需要6~8分钟，甚至还超时。但选型计算的准确率需要100%。
后来反思发现，用LLM去做运算可能方向就错了，LLM不一定适合复杂运算，运算就应该用代码程序实现，不会出错，而且秒出结果。所以还是尝试用代码执行节点完成计算（用http服务也可以，但需要开发协助）。
产品大多不会写代码，但AI会写，那就把输入参数、运算逻辑都告诉AI，让它帮忙写，后贴到代码执行节点。开始发现这有点像碰运气，代码执行老是报错，只能不断地把报错结果告诉AI，让它修改代码，反反复复，搞得筋疲力尽。但还好，经过一两个应用跑通后，关于如何让AI（一般用豆包）准确生成能在dify中跑通的代码，我也总结了一些规律：
- 关于代码中用到的参数、运算逻辑，一定要写得尽量详细、准确，没有任何歧义。有时候可能就是参数取错了，甚至参数的数值类型弄差了，代码就会报错
- 在dify中对代码执行节点设置的返回参数以及格式，需要同步给豆包，这些会内化在代码中。如果代码返回结果及其格式，与在dify中设置的不一致，那么一定报错
- 报错后，除了把报错结果，还应该把可以把节点的输入内容完整发给豆包，这样AI更容易发现问题
- 如果是类似的情况，把之前的正确代码给豆包学习，比如都是类似的运算，把之前跑通的代码给到它，往往更容易生成你想要的代码
- 如果代码不论如何修改，反复报同一个错，那可能是设置的问题，不一定是代码的问题。对2、3、4这三点重新审视。
当你输入代码需求后，经过一两次修改AI输出的代码就能在dify中跑通，这种感觉还是蛮爽的。如果顺利的话，一个应用很快就能搞定。最费时间的反而是，梳理业务逻辑，整理报告格式等。
所以在AI时代，对B端产品经理的核心要求依然是业务的调研和理解能力。AI只不过扩展我们的能力边界。快速学习相关技能后，以前依赖于开发的事情，现在产品也能做。当然学习能力很重要，一定要动手，学中做，做中学，利用AI为公司创造更大的价值，未来可期。
作者：白水未央，多年B端经验；个人公众号：文字小站
本文由@白水未央 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Pixabay，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。提供信息存储空间服务。
