个人做过开发，不过没有做过 C 端的，做过 B 端的，B 端逻辑本身可能会更复杂一点，开发本身没有大家想象的那么难，多少书系统难度不会高于你做一个图书管理系统太多，很多公司的中台都很粗制滥造，套的开源前端框架壳子，后端骨架也有很多通用的，至于 DDD 啥的，大多数不会对你的功能产生太多影响。不过这个前提是负责的开发项目不是流量千万上亿的大型项目，那种项目估计踩得坑会特别多。不过正常难度的开发，在 AI 时代，有点悟性的年轻人，学个几天基础的东西，用 AI 是很快能做出成品的，至于有没有打磨那就是另说了

由于没看到原平台样子，我大概根据你得描述推断一下，正常来说，数据资产是数据治理这个大方向的前提基座，类似于一个图书馆的检索系统，把散落在各种地方的表，以及附带的属性和业务域都收拢来统一管理。有了数据资产，就可以开始贯穿数据生产全链路，追求高质量和高可用性和高交付，比如指定数据口径（比如原子指标，派生指标，指标修饰词），管理数据模型，监控数据质量，追溯表血缘（如果数据有问题，好通过血缘关系定位）。一般来说数据的使用方和业务方挺多，有些甚至是老板直接看，比如核心资金的看板，营收之类，财务口径的数据，以及对外财报以及一些核心进销存之类的。在这个层次下，又会分化数据权限，那就是谁能看这些数据，以及数据挖掘，比如指导精细化运营，做客户画像加工，或者把数据做成数据服务，对接后端直接提供计算好的数据结果之类的，数据资产平台本身可能是更服务于业务的，但是不知道你们公司建设到了什么程度，一般鼻祖是 dataworks 这种高度成熟化的产品做自己自研的借鉴的

一般看你公司的主体是什么赚钱的，我举个例子，如果是电商行业，比如得物，那么数仓建设肯定是庞大的，分资金域，交易域，供应链域，人力域 (个人觉得次要)，财务域，其他子域，你说一个公司有没有一个人能把所有域的数据流转吃透？我个人认为在 AI 未到来时代，是巨大困难，绝无仅有的，比如淘宝，阿里是不可能有任何一个产品任何一个架构能把里面的所有细节铺全的。那么放在现在，数仓的资产主要是 ETL，血缘关系，数据本身就在诉说着业务语言背后的逻辑，也就是所谓的数据洞察，一般来说是产品经理来主导，但是产品经理有个什么短板？一。对数据本身链路绝对是不太理解的，他对业务的洞察能力是在第一层也就是客户层，洞察了市场能力不等于你这个能力在下面能得到有效落地，那么这个能力就是 AI 产线规划师（我个人命名的，后时代 AI 赋能的），他是有技术基础的 + 平时在测试数据有绝对性的数据洞察能力和业务体感 + 绝对性的面向业务的交付能力 + 往前推动资产建设的能力（看人）。在这基础上，你能解决业务痛点的可发挥点就非常多了。至于怎么构建，大多数是依据 ETL 反推血缘，梳理 ETL 和实际业务的对标性，这里不仅仅是指标映射这种陈述性建设，而是基于业务痛点的图的发散性线索建设，比如新华字典懂吧，你得知识的建设需要有索引，锚点，这些都需要你在一线打趴打趴，绝对不是 AI 能帮助你做的，因为这需要你得沟通能力，你沟通好之后再结合 AI 梳理 ETL 的对应问题和建设

测试岗位目前最受 AI 红利的应该属于大数据测试岗，从这个岗位里做的好了，可以延伸出垂直领域的知识库，大数据测试是最接近公司核心资产的岗位之一了，甚至大数据开发都没有大数据测试了解。在 AI 发展时代，各种 AI 模型或者工具只能覆盖公司业务浮在海面上的百分之 20，百分之 80 都需要公司私域资产的构建，但是如何构建在几十年来是个填不完的坑，如果一个岗位能从运用 AI+ 业务双重抓手去靠近公司实际盈利，运营增长体系，我个人觉得方向会更利好，不要局限在测试基础的用例这一亩三分地上，抓业务，抓数据，去反推公司的增量痛点。到时候就算裁员，也是最大限度的留存率高的（当然你得打破部门墙等一系列难关）

说实话，现在有这个 agent 的基本技术和认知去转型产品吧...做测试没出路了，你有这个底子还是好走一些产品设计的

hhh，大佬夸奖了，另外这篇是我看到一篇喜欢写思辨的人写的文章，转发过来的，因为感觉写的很有意思，转过来的，希望能让看到文章的行业朋友看事情更透一点，不内耗自己，需要我标记原作者吗，因为不知道论坛规矩，所以没写原作者

就我目前来看，AI 在测试领域，一些我不懂的地方我就不谈了。。我感觉只有在大数据，数仓里面做各种 skill，业务知识串接，工作流定向分析有帮助，因为这些工作跟日常页面或者接口功能不一样，越贴近数据，是越好用 ai 帮忙的，也是越贴近业务，也是最好往上升的（但是其实和数据分析和大数据开发有职能重叠了，不过测试嘛..哪里都想伸个手进去）。至于其他的用 ai 加身做所谓的测试技术...额，老生常谈了，如果对加薪有用就行，实际是没得 B 用的

从不同角度来说，分为两派:
一类人是都知道 AI 的这些问题，但我就是不说
二类人是真不知道这些问题，我听别人说 ai 这么搞可以
第一类人大多数想要成为既得利益者的，能不能干无所谓，能给我加钱就行
第二类大多数人是不怎么去接触和学习的，或者说没啥兴趣的

额。。我认为公司是想产出实际业务收益，也就是赚钱的，如果 token 大量花费在自动化测试上，要不然就是财大气粗瞎搞都没事，不然就是纯视觉公司，不然只有一个点了，为了 ai 而 ai，别说产出收益了，是疯狂倒贴钱还永远不会收回的

可能现在 base 承接不住那么多的了，可能跟个人还无关

在极窄领域（比如只处理 REST API 的测试用例生成，且每一步都能访问完整 API 规范），加上人工检查点，还是能产生生产力的,但是如果妄想什么都搞的很精准，那就没辙了

感觉一切问题都是上下文压缩问题，压缩了必定丢内容，也说不好到底有哪些次要被丢弃的刚好又是很关键的信息。说起来，除开特定工作流，类似这种什么生成自动化用例啊，读取代码生成巴拉巴拉啥的，得首先理解你得大模型在一个 session 里面，在百分比多少的时候会开始离散信息，什么时候你需要开始压缩信息持久化了。但是持久化压缩之后的信息必定不会等价于原生完整的信息。类似 subagent 这种，读取大量信息，然后 summary 汇总算是一种方式，但是这种方式也只是暂缓，所以这也是为什么在目前 AI 没有阶段性突破动态权重这环节的时候，任何你要 AI 自主驱动的东西，都是不切实际的，除非你跟人家那位授权 100 个 cc 工作，一个月花费几百万成本去搞所谓的用例...

跟你想的如出一辙，但是我目前没有像你这样做的很精细，因为我是大数据场景，因为是数据流转，所以必须精通业务才知道数据后面的业务背景，那么对于大模型来说，我给了一个总结，叫做 最小认知单元。这个东西不是什么字典，也不是什么指标定义，而是就跟我们大脑一样，我为什么会知道要这么做？这个就跟里说的一样了。目前我是让它根据一份 ETL 生成一份最小认知清单。让它有一个像人一样的工作认知。确实我是认为这个思路是正确的

可惜了，这个前端工程并不重要,model 才是核心，我甚至认为这是 Anthropic 刻意有意发布出去的，为了让市场无形的手来打造属于 CC 的生态圈

我感觉 ai 要做到非常完善的压缩前文，上下文，要参考大脑的存储了，比如我们记忆东西，很多东西就是长久灌输，有了外部环境的灌输才知道的，虽然现在参数还没我们大脑神经元突触的数量级那么大，但是我感觉把，真要到这个指数级了。开放云端的 ai 个体互相互补，真就是一个群居社会 ai 的雏形了，真就云上大脑了，想想都贼恐怖，毕竟不知道某个特性的涌现效应的条件是什么，可能突然某一天就触发了这个客观存在的涌现条件了

现在搞时间序列算法...我是感觉我写的没 ai 给我得好，已经两周不写一行代码了，只做结果 check。。。

我还是比较认可你说的，至少我目前看到的，你这个实践是最符合我体感的，生成用例这块我觉得就是属于死党 - 上下文少不行，上下文多也不行，受限于模型本身能力。加上人工迭代等等。除开少数业务是那种定向分析的，能开拓一下分析视角。我个人觉得 ai 还是用于编码方面是更适配的，强行拉到测试这个版子有点过于强求了

我在刚接触测试的时候就有一个疑问，xx 自动化,xx 自动化，如果需要维护，大部分人还觉得是个负担，那个这个东西他就是没意义的，什么叫自动化？像流水线一样，像智驾一样，自动开车，自动收付款，自动农耕一样的自动播种，浇水，即使需要维护也是中长期跨度的维护。到了测试这边，所谓的 ui 自动化测试投入的东西毫无意义，或者有人说你觉得没意义是因为你 xxx 还不够深入，我对这种是很嗤之以鼻的，除开少数公司非常特殊特定的业务以及独立的环境之外，其他的百分之 99 都是没意义的，如果有人觉得有意义，那你就是对的

跑步干呕太写实，咱也是这样..

其实现在如果是数仓里面的数据测试，其实在现在一站式平台发展的比较好的期间，垂直某个领域的业务能力可能更加重要了。比如以前在实时数据还需要手动写 flink 代码的时候，现在阿里云一些优秀的工具都能写 flinksql 来解决百分之 99 的问题。然后如果是离线数据，这一点倒是你现在可以进步的，你需要非常熟悉 ETL 过程，也就是 hivesql 这些 sql。要能在一千甚至几千行里面梳理清楚数据脉络，以及数据源是业务库的哪些表，这个期间有良好的文档梳理能力也是很好的，这给后续做数据治理也有帮助。然后也要思考怎么结合业务，做数据质量监控体系。对业务数据进行质量分级，因为大多数数据都会在应用层 ads 给大老板，或者对接的中台，一些核心数据是有必要做质量体系的。另外你说的验证数据量，数据增量，主键一致这种比较通用的是可以抽象成统一测试模板，在对数据进行测试的时候，先过这一类统一的三板斧，然后在对数据质量中蕴含的业务进行梳理。其实大数据测试是在你有充足的综合前后端知识，优秀的 SQL 能力的前提的，能够更好的接近公司核心业务，向上走的一个很好的发展职位

是的，有兴趣吗

飞哥，你应该不是没想起来，可能确实很久没用，但是飞哥你想一下你可能就记起来了，比如 SELECT sales_person, SUM(amount) as total_sales
FROM sales
WHERE region = 'East' -- 先过滤行
GROUP BY sales_person
HAVING SUM(amount) > 1000; -- 再过滤组
按着思路写出来其实就发现是先 where 做数据行过滤，再用聚合函数对整体过滤出来的组数据再过滤了。不过飞哥你说的也对，很多技术如果自己没有正在做，就算是很粗钱的，也会第一时间卡克，比如 UI 自动化的 webdriver 很基础吧，但是现在让我手写 ui 自动化的用 webdriver 打开百度我都忘记了。所以我也觉得是简历上有什么就考察什么。当然如果简历是瞎写的就其次了。而且 5-10 年的测试，其实真的来讲，约到后面越看重公司的人情世故和站队方向，大多数技术如果不是天天在用，基本都是面试的之前半个月恶补的...

大方向上可能有问题，如果你是面向 kpi 可以捣鼓各种花里胡哨的，如果你是真想测试解决问题，不妨分析一下每次 bi 展示出错，是开发搭建组件 BI 操作失误，还是数据集本身 sql 逻辑问题，不是所有问题都可以自动化测试或者迁移到 UI 自动化测试或者接口自动化上面。database 本身是一个健壮性本身很强的工具了，不存在动了一个数据集或者仪表盘，其他模块出问题的情况。可以分析历史原因的 bug，哪些本身是口径上的问题还是什么。总而言之在 BI 和看板上考虑自动化不是很明智和 ROI 回报率高的选择。最好更注重数据集本身中的业务含义和背景

看来看去健身网教比较靠谱哈哈哈哈

fastapi 既视感