大佬们提示词怎么写的？通用部分分享下？

以后会有提示词工程师么。。。

主要是。。。量太大了。。。而且有些可能我表达的也不是那么清楚的感觉。。。

我现在结合自身的使用场景，我们公司 3 月会招一堆新人进来。我在想能不能反过来用 ai 去查漏补缺他们写的用例。这样反而会好一些，而且更实际一些？

deepseek 不是多模态的，他不能处理图片。

昨晚睡觉又琢磨了会。感觉提示词需要一个共有部分，给他定义最基础共性的东西，然后每个单独的助手区分服务的来定制。但是这里又有的问题是，你没办法让他知道你的前端是什么样子的。单独描述的话，维护成本又非常高。

我在 2012,13 年的时候曾经在 HP 做过一段时间的打印机测试。
当时遇到的问题是，用户的系统多种多样，你也不知道用了啥盗版系统，精简了啥服务，会导致打印机无法工作。

于是我们成立了一个小组，专做盗版系统的兼容性测试，什么大白菜，大毛桃，深度，番茄花园等等，装好之后做好 ghost，每次更新就一个个试过去。

自动化是用于回归的，发现问题永远应该在手动阶段。

你们老板是不是想裁员省钱，想让你用自动化去包揽所有测试啊？

之前做过，遇到了问题，因为是测兼容性，然后我 app 往下滑动，我操作的手机 3 下到底部，但是有个手机要 4 下，然后就觉得，容易乱，就不搞了

会造成资损的功能，重点测试，不要仅仅局限于 UI 方面的问题。

首先，你要选准一个方向。
拿个我熟悉一点的来说，比如 unity，大致上是用 C# 来进行逻辑编写。
那么你就要系统的学习一下 C# 相关。
然后，unity 相关的知识你最少要了解一下吧，什么 MonoBehaviour，什么刚体，什么 shader,什么 canvas 你都要了解一下吧，能深入更好。
公司用的什么开发框架 gameframework 啥的，是自研还是啥，他们的特性，使用方式，你总归要知道吧？

现在很多游戏也是 mvc 分层，你学了 spring 全家桶，知道了很多时候可以直接测 service 层，到了游戏这里其实也是一样，你也可以直接测他的各个层，函数，方法，对属性写脚本进行校验啊。不要把高级游戏测试老是想象成停留在点点点或者是 UI 自动化的层次啊

这个对于测试的要求太高，而且对于开发的编码规范要求也很高。。。

并不是，请注意，这里的喂，不是说去训练一个 AI，而是本身已经有个训练好的 AI，特长是基于 LLM 来进行输入文档的归纳总结。

举个例子，我把所有的文档喂了给他，然后问他，什么时候会调用到内部的 XXX 接口。

他会把你给他的文档里面的相关的东西搜索出来。

其实大概理解就是一个基于 LLM 的搜索工具的意思。

试试这个https://zhuanlan.zhihu.com/p/646649944，可以本地部署。

你可以把所有需规一股脑都喂给他，然后提问。可以做个快速索引。

其实你们都在着重考虑后端的精准实现了。能否再进一步实现前后端的精准打通？

上面有人也提到，精准的最终不仅仅是要关联到自动化用例，手动的也要关联到，但是维护成本太高。

那是否可以这样，后台的代码逻辑关联到各个接口，再通过前端调用接口的逻辑，与前端关联起来，在整理一套前端的映射（如安卓下的，登录接口与 loginactivity 绑定）， 手动用例也标明用例所属的 activity，从而达到手动用例的关联关系？

我不太明白你想做啥。
首先，你的自动生成接口测试用例，请求的字段是每次跑 smoke 测试的时候都会变的么？那你怎么去判断返回值是否是你想要的？
如过不变，那这套东西就无非是普通的接口自动化而已了吧？
而且冒烟测试更多的是看业务逻辑吧？随机生成的字段完全不会考虑到业务逻辑吧？

我们公司的模糊测试是你说的那套玩意，给个 seed，自动去生成一堆乱七八糟的测试数据（具体生成规则我也不清楚，不过应该是一个常用字典 + 一些随机生成方法），跑个 24 小时，狂暴鸿儒所有接口，然后看服务端是否抛出一些异常。

jvmPath = jpype.getDefaultJVMPath()，这里打印出来是啥？是 jvm.dll 么？

看下是否是 32 位，64 位 python 造成的问题。装个 32 位的 python 试下。

我可以跑，不过我是直接加载了一个 class 文件，没有加载 jar 包，然后我跑的时候我记得当时遇到的坑是 64 位的 python 不行，换了 32 的就可以了，包括依赖库也要 32 位的

私钥和公钥不打个码么

这么一想，确实。。。现在没文凭基本不可能了。

目前还有 60 多个要还，每个月去掉两个人的公积金只要还 3K 多，倒是没啥压力
今年 37 了，没有文凭，最高文凭是高中，从入行开始就是外包，一直外包到现在了。也没啥可能跳槽了，不知道会不会要干到 50 岁。。。

我感觉，测开需要什么方面的技能很多时候是和所在公司环境绑定的。

比如我在银行，因为一些规章制度要求，我很多时候都是在研究，如何在不引入一些大家看起来很稀松平常的工具的同时，达到提效目的。

然而正常公司可能直接一个软件就解决了。

尝试去偷懒，去简化你现在的操作。
不要陷入一个误区，自动化是大圆圈，自动化测试是大圆圈下的小圆圈。你可以拿自动化去做很多视频。
我刚开始写代码，第一个项目是我平时测试的时候需要手动去触发多个定时任务，要来来回回复制任务名字和不同系统之间的地址，去搜索触发，很麻烦。于是我就写了一个脚本，执行一下就触发了。然后大家都觉得好用，我就又封装了一个 exe 给大家用，后来发现更新维护还有我想加一些新的功能比较麻烦，我就又去看了 flask 起了个服务，后来大家反馈前端很丑 (没有任何 css 美化的 html 硬写的)，又去看了下 layui 拉了个前端。。。所作所为和待测项目可以说没有任何直接关系，但是确确实实实现了最初想要偷懒提效的目的。
那么，你的工作里面有没有这种重复的劳作？比如日报周报月报季报年报？比如一些测试数据的准备？再比如，想早退摸鱼写个脚本自动一键打卡（教坏小朋友了）？很多地方都有契机，积极寻找力所能及的正反馈点是很关键的一步。

小而美，小而美

先写小工具，锻炼代码熟练程度。
重构，对于自己的代码，需要经常翻新重构，我每次重构感觉自己的设计模式，代码水平都能有很大提升。
不要为了自动化而自动化。自动化不是测试的终极目标。说的不好听点，你是小公司，那么你项目的接口可能就十几个，你去折腾自动化不如每个接口一个 py 文件，数据逻辑直接写死在里面。这样反而更好维护；你是大的公司，项目庞大，那你们的自动化平台也不可能是你一个人的事了。甚至很多公司直接买现成的产品。

家人们啊。。。我把那个 600mb 的文档，丢进了 langchain-chatglm，好像效果还行？

当然是开发用啥你用啥。
抛开上面一点，语言的优势是不是你想要的。
py 的优势是深度学习那块都走的这个，你用的到就学。
go 好像是运维用的比较多？不是太了解。