https://www.deepseek.com/harness/
蹭一下 dsh 的热度，哈哈
工作记录
从测试转全栈
公司要求从测试转全栈开发，陆陆续续开始接一些开发的需求，从实际工作下来看，在 cc 的帮助下，确实没有什么难度
了解底层原理和业务流程，对代码架构有一定了解，让 ai 分析后编写相关代码，完全可胜任。
虽然如此，我开发后还是加了 3 个开发人员 review code，作为测试人员谨慎一点。
项目测试与文档仓库
项目的测试工作主要还是我来负责，全栈以后新建了一个仓库，结合 obsidian 来管理项目相关的文档
目前来看效果不错，需求分析、测试分析和生成的用例质量都提升，
整体使用渐进式披露设计，其他新人下载仓库以后都能很快上手，了解业务和进行测试
前期搭建：离不开人审核的三个环节
对于前期搭建来说，几个地方还是离不开人的审核，
1. 需求审核
第一是需求分析整理，这一块可以借助 ai 整理，但是人一定要审核
很多时候是让自己清楚这个迭代要做些什么东西，看需求和开发排期是否对得上，以及一些文档中模糊的东西甄别出来落实
特别是 ai 工具使用多了以后，ai 的幻觉会转换为人与人之间的幻觉
2. 测试分析
第二是测试分析，一般结合系分、仓库中历史数据，以及你的描述，生成一个测分内容，
需要人审核确认，对错误、模糊的内容需要二次确认、修改、优化等
3. 测试用例
第三是测试用例，生成的测试用例需要审核，修改，完善
我觉得这三个部分在前期搭建 ai 测试流程中不可或缺，当仓库建立完善后，慢慢审核的内容就会变少，
后续 ai 生成的文档内容不会漂移
后期提效
后期文档仓库成熟以后，提效明显，我刚开始做已经感觉到很不错了
自动化：从"手搓"到 AI Native 的思考
对于自动化来说，我也算老油条了，毕竟去年还在手搓自动化代码，思维固化，对于自动化用例框架的使用
但最近我在思考，这样的自动化其实不够另外，不够 ai native，ai 还是按照你编写的案例去编写、执行，不过灵活
如何将上面的测试流程的东西和 ai 自动化结合起来，我有一些基础的想法
接口自动化：AI 命令行工具
对于接口自动化来说，使用 AI 开发一个命令行工具给 ai 来使用，通过说明文档、skill 等指导这个命令工具的用法，
从前后端开发代码直接同步相关的接口信息，登录获取认证，去做单接口的调用和编排，这一块目前还在实践中
没有真正的 run 起来，因为之前只是想做个命令行工具，后面发现可以给 ai 直接调用
这块后面有时间了可以写个工具，自己玩一下，如果可以好用的话可以分享一下；
UI 自动化：ai-ui-testing
另外一块是 ui 自动化，这一块其实我做得不多，因为本身我们产品跟关注底层的引擎和资源的调度，
所以一直没有补齐相关的自动化，但是这一块其实可以去做的，我的想法很简单，我希望有个工具，我给 ai 说访问什么地方，怎么操作
ai 自己去尝试写自动化用例，生成后自己总结用例和索引，以及使用方法等，后面 ai 可以调用，我也可以进行 ci
所以昨天晚上用 dsh 写了一个工具，今天到公司尝试了一些，可以解决自己的编写自动化用例的问题
告诉资源地址，告诉他目标，然后 ai 就在后台自己调试写用例，写好告诉我，我就让他有头跑一下，实际效果还不错
整体实现也很简单，有需要的可以看下：https://pypi.org/project/ai-ui-testing/0.2.2/
写代码 + 发布到 pypi，使用 deepseek-v4-flash 大概花了 3 块钱左右吧
DeepSeek Harness 体验
另外一块就不得不提 deepseek harness，从 deepseek 发布新的 flash 和 pro 以后，我就一直在关注
发布后发现居然是 web 应用，通过 npm 我是没安装成，还是源码构建的方式安装了
实际体验很丝滑，我一句话完成了博客的创建，自动对接了 meoo cli 并发布了应用
https://cooklikehoc.soilzhu.su/
哈哈，这里插播一个之前看到的别人发的菜谱网站
https://ex805e7x7n8p.meoo.pub/
目前还在探索中，一切皆插件的思想确实很爽，claude code 还在用，但比较费 token，自己环境可能都优先使用 pi
测试集群部署 dsh
办公本身有 token 额度，所以不怎么用 dsh，而且我们的内部工具内嵌了 deepseek harness，所以我就没怎么折腾了
但是对应到上面的仓库，实际驱动还是 ai，所以我的想法是在测试集群部署一个 dsh 供大家来一起使用
说干就干，进入测试集群，我先从源码构建了 dsh，运行起来准备访问，我靠，居然只能 127.0.0.1，--host 指定 0.0.0.0 不行
试了一圈方法，ai 提供的方法都有问题，进入 dsh 后发现模型配置加载不出来，反正各种问题
后面尝试了一些插件，让 dsh 支持--host 0.0.0.0，但多多少少都有 bug，前端无法配置自定义模型
但是好就好在源码构建，直接 ai 分析源码，现场编写了一个支持--host 0.0.0.0 的创建插件，大概花了 5 毛钱就完成
安装新写的插件后就可以配置自定义的大模型服务了，配置了 qwen3.5-35b-a3b，虽然只有 256k 的上下文，
但是用来排查集群 pod 日志，去 skill 调用前面仓库写的 ui 和接口自动化已经完成没有问题
后续考虑部署新出的 qwen3.8-27B，目前的卡资源可能只能勉强部署 FP8 版本，长上下文 Kvcashe 占用比较大
后续考虑将一些问题排查经验变成文档或 skill，放到对应的项目目录中，其他人访问 dsh 对应的项目就能方便的使用排查了，
所有项目人员都可以通过对话的方式进行测试、日志排查等操作了。
在对接一些聊天软件的 webhook，做监控，定时任务什么的都很方便，或者在集群中测试，故障注入什么的都可以
这样一部署，思路瞬间打开，我自己都想 high 了
泼一盆冷水：安全与管控
但必须泼一盆冷水，虽然能力开放，但是还要注意安全，这种方式如果没有防火墙等限制，公网就是活靶子，而且还要考虑数据安装
因为我们对接自定义模型，所以风险会小一些
另外就是对大模型的限制，harness 不好，限制好模型，小心模型闯祸
实际搭建这一些简单，但是如果组织好使用、管理好，防止 ai 闯祸是我们更应该思考的，也是我现在担心和在想办法优化的地方
结尾
以上就是最近工作的一些记录，自己想 high 了，忍不住说两句，哈哈哈
插播一下 qwen ai 的 39 code plan 是坑，办公分分钟用完，建议别买