确实，单纯 coding 的天堑已经不再有了。AI 把绝壁变成了一个坡。是个人都能走上去了。

未来 AI 能不能再把这个坡变成平路我不知道。
我现在还是得要多几轮对话把代码结构整理成我要的形状。
万一哪天邪神降世 AI 暴毙，我可以继续的写下去。

像可控核裂变被实现的时候一样，它既可以提供能源也可以毁灭世界。AI 对人类必然也是有利有弊的。
组织岗位的变革我觉得还好，和历史的工业革命类似，阵痛期过了肯定会有新的平衡。

长远来看我最担心的是人类质量的延续问题，如果 AI 可以让人类的求知欲几乎瞬间被满足，会不会慢慢也就不再想学习了。
我现在就开始有这个倾向了，AI 出的方案只要出现我觉得不明觉厉的地方，我下意识认为就是对的，经常不会再深入了解了。
就像玩游戏，本来应该通过努力克服重重关卡，突然给了一个开挂的机会，开过之后游戏就索然无味了。

尽信 AI 不如无 AI，当知识 (智力) 不再重要，人还有什么价值？

我对论坛的历史就记得几个比较关键的节点。
测试布道师时期 (令人印象深刻的 monkey)， 霍格沃滋时期 (培训占了半壁江山)， 人工审核时期 (当前)

新团队是可以激进一些，因为本身就是带着探索标签的。
老团队的演进还是需要对当下信任的基础上，渐进式的改造。未来未来，DRP。

AI 跑 UI 自动化烧 token 那可是上亿上亿的烧。不知道一轮跑下来你那边 api 成本上万了没有。
后来我们痛定思痛，调研发现一种包月方案，虽然没有现在 Ai 这么智能，但 好歹成本固定下来了，做执行是完全没问题了。
那就是招几个外包
如果觉得用外包太抖机灵了，那只能减少 UI 自动化的场景集。 将大部分的自动化下沉到接口自动化。 只对 “核心 “” 交互用 UI 自动化。
另外在将界面元素传给 AI 前，工程化的手段做一下数据的裁剪和压缩。省点是点

真能无限推理的话，任何领域 AI 都可以远超人类，服务业的消失也是早晚的事儿～
AI 培育的食用 “猪”，靠光合作用就能长肉，肉料比无解。 AI 理发设备比现在的顶尖发型师剪的都好。
真有什么需要"人"才能做的，直接自己手搓一个完美受精卵好不好，我们额这些劣等人是没资格给 AI 打工的。
我能有幸在矩阵里一边当人肉电池一边通过脑机接口娱乐到死就知足了。

角色其实也没变吧，只是搬砖砌砖的动作有 “机器” 帮忙做了。全权托管的话，最后放眼看过去是个房子没错。可仔细一看，有的砖排列不对，有的水泥标号错了。

从个人经验来说，vibe coding 不做到工程类/方法维度的 “视如己出” 是很难长期维护的。

现在是有分歧的，资本方肯定希望能用电的就不用人。只是目前谁也说不清楚未来 AI 的边界在哪里。
只能赌 AI 的上下文边界还在算力存在极限，这样技术岗位就还能有活路。
如果上下文不再是卡点了，那真是无限推理的终结者时代了。遇事不决，加大电压

最大的逻辑问题，是把「AI 降低了代码修改门槛」等同于「业务人员具备了软件工程能力」。

我不反对让业务人员参与代码修改，但反对把这件事描述成程序员的价值正在从编码转向架构设计。

有几个问题值得重新思考。

第一，看到结果不等于知道结果正确。

页面正常不代表业务逻辑正确，功能跑通不代表没有破坏其他功能。

修改一个退款规则，可能影响订单状态、财务对账、报表统计和下游接口。业务人员看到当前页面正常，并不能证明整个系统正常。

软件工程解决的从来不只是代码能不能运行，而是如何证明系统在各种场景下都符合预期。

第二，系统知识显性化，不代表系统复杂性消失。

把文档补齐，把调用关系画出来，确实能降低理解成本。

但分布式事务、并发控制、数据一致性、缓存失效、接口兼容、故障恢复，这些不是画一张架构图就能掌握的。

知识可以共享，专业能力不能通过共享文档自动复制。

第三，业务决策权不等于技术实现权。

业务决定退款规则，不代表业务知道如何保证退款幂等。

业务决定排行榜权重，不代表业务知道如何避免全量计算导致数据库崩溃。

业务应该决定系统做什么，研发负责确保系统能够正确、稳定、安全地做到。

这不是信息壁垒，而是专业分工。

第四，AI 降低的是编码成本，不是系统风险。

以前修改一个功能需要两天，现在可能只需要一分钟。

但如果一天产生了 100 个改动，谁来保证它们之间没有冲突？谁来保证测试覆盖？谁来处理版本兼容？谁来负责线上事故？

单次修改成本下降，可能带来整体变更数量和系统治理成本的上升。

第五，文章对程序员的价值理解过于狭窄。

程序员的价值从来不只是掌握系统地图。

更重要的是建立抽象、控制复杂度、管理依赖、识别风险，以及让系统能够持续演进。

AI 能生成代码，不代表它天然理解整个系统的约束，更不代表提出需求的人能够判断生成代码的长期影响。

我真正想反驳的是：

不要把「业务人员可以通过 AI 修改代码」包装成「业务人员已经具备独立修改系统的能力」。

这两者之间还有很长的距离。

让业务人员直接修改低风险配置、页面展示和简单规则，是生产力进步。

让业务人员通过 AI 直接修改核心业务逻辑，却没有相应的测试、审查和责任机制，是把研发成本转化成了系统风险。

AI 时代，程序员确实不应该再把自己定位成代码搬运工。但也不能因为 AI 会写代码，就低估软件工程本身的复杂性。

代码越来越容易生成，真正稀缺的反而是判断一段代码能不能进入一个真实运行的复杂系统。

需要我帮你改得更口语化一点吗？

这种就是公说公有理婆说婆有理。

我们也用的 langgraph 搭的，比较难的就是 langgraph/deepagents 对 skill 的原生支持不大好。
各个业务方在 openclaw 时代搞了大量自己研究的策略/数据构造 skill，咋写的都有，一层套一层的还带状态，现在想直接接进来。
让把 skill 标准化成 MCP 吧，人觉得 skill 跑挺好，改造动力不足。

是，很多问题的解法不止一个的，我是觉得对事有争论挺好的，这样才意思，毕竟人的天性就是吃瓜。
吵起来了才能出些值得讨论的内容。像我一直认为 AI 冲击最大的应该是教育行业。
昨天才知道青鸟现在测试的就业培训竟然都要 3w 了，成人教育着实恐怖如斯啊。

看他以前的回复我觉得他是有分辨能力的。像是最近因为什么事情破防了……凭鄙人粗浅的认知该不会是高位接盘了哪个科技股吧

相较而言，像鸡哥你这么黑飞总，飞总作为管理还能容你，我觉得很有宗主风范，有些钱就该他赚。
希望你控制下对线力度，不然我可就不去你们公司面试了

社区风气整体挺正向的，有争论大都也是对事不对人，我一直没有退订。
就是这个人工审核属实有点难受。每次我邮件推送有新回复了大都是审核中

好好笑，懒得回复就别回复了嘛…我又不是你老板逼着你回复…

我的核心论点是当前的手工用例和可以被自动化执行的用例存在很大的 gap，复杂业务中需要一些办法才能有效转化。
你的用例里可以写‌出无形变‌的刚性球体，测试执行时上去哪找这玩意去？
正向流程不少 “从设计角度合理的用例场景”，人去写自动化执行都要改库这种旁门左道，就别提异常流程了好么…
举个例子：异常场景并发怎么保证 100% 命中？真的要像用例写的多用户多线程压测来触发么？

另外我确实觉得一次用 25 万字这种中长篇小说作为用例就是不合理的啊。一次提测的用例集不该是这个量级。
贵公司如果大部分提测都是这个量级，我是真不敢去面试的。一年到头小说家们都能写出上万的用例量能直接把我这把老骨头劝退了。

退一步，就算用例量真的需要 25w 字，且完全没有优化空间了。这个量级的用例评审一周都不一定能过完。 贵公司不会代码和用例评审都已经 agent loop 了吧？ 真这样一个需求光评审流程 3wRMB 都不会够烧的，是小的有眼无珠刚才说话太大声了，给贵公司老板的慷慨跪了。

“保证 AI 能写出可转为自动化的用例” 当然可以做到，我只是想表达下目前的上限和挑战罢了。挑战设计，挑战数据基建，甚至挑战你我的人性。

就好比你都没看到过我的注册时间和历史回复，单纯因为支持我的人和你有争论就能给我下定义了。你就比我晚注册了一年，也是当过面试官的人了，咋这么有偏见呢？都工作十多年了咋你还需要站队跪舔才能活？你要是因为站错队被广进了明天跟我买老登港股，春节前卖掉，让你感受下什么叫站着把钱赚了好不好？

解决问题的通用方式是要分四个阶段的：
发现问题‌ ->理解问题‌ ->提出假设‌ ->检验假设‌。
我觉得能帮助大家发现和理解问题就是很大的帮助了。“提问的问题必须要解决” 是不现实的。

首先要发现问题。影响 AI 自动化执行用例的可能是什么问题？

为了帮助发现问题先举个例子：

有个新需求，要求用户提交订单前必须确认收货地址才能支付。测试用例要怎么写？

1. 按端对端测试去写：用客户端端从登陆选品开始写到支付。
2. 按接口测试去写：纯调接口从用户登陆写到支付。
3. 找一个历史订单改数据库，每次把订单状态改成提交前，删除确认记录。再调支付接口，不报错就算通过。

问从用例维度看哪个方式好，1 是挑不出毛病的。

可自动执行哪个好写呢？
先不说 1 的方式 token 要多少，稳定性怎么样。
没有数据基建支持能写出 2 都是挺有挑战的。
大家可以看下自动化里是不是存在很多 3 的实现方式。

怎么解决这里我提出一个假设
影响用例自动执行的是用例设计阶段，需要把当前的测试环境和执行策略融进去。
哪些有现成的数据构造工具，哪些有历史自动化。哪些可以人工保证，哪些需要人工补充数据。

到这里问题算解决了么？ 这些背景内容能融么？融多少？怎么融？

关键是先让 AI 做事像个人，再说让 AI 做颠覆性的改变。
保证 AI 能写出可转为自动化的用例，再说这 26w 字的价值也不迟

基于 skill 的方式真的靠谱吗？
如何实现单步/任务/会话维度的结果验证？
出现与预期不一致的问题如何排查，改动后如何保证不出现退化？
耗时和 token 成本如何精准监控和优化？

大模型的架构没有本质的变化，以前的幻觉/弱一致性/降智的问题依旧存在，只是参数量堆起来之后变得不那么明显了。
可以认为现在的 “大模型” 就是一个又一个的不同的小世界，有的世界没有陆地，有的世界人不需要呼吸。
小世界越来越真实，但参数量级不能无限提升。不然直接就可以血肉苦弱，机械飞升了。

在这个基础上的系统提示词只能算补丁，某个场景下因为补丁可以跑过，不代表有通用性。而且规则是补不完的，没有陆地的世界只告诉它有陆地是不够的，就算加上花草树木也不行，把输入的上下文塞满都不行。

测试设计是一个富有创造性的工作，需要针对不同的需求业务侧重，代码架构，用户群体，以及当前的造数能力，设计一个人力时间成本适中且能最大程度暴露产品质量的测试方案。

以前面对是程序员基于对这个需求的较充分理解和对代码的片面理解下，可能有笔误有遗漏的代码产物。
现在面对的是大模型对这个需求的片面理解和当前代码工程的较充分理解下，可能有笔误有遗漏有借题发挥的代码产物。

应对不同的业务变更，测试方案设计是一个很主观的事情，哪些必须验，哪些验不了，哪些可验可不验，保守的变更需要激进的方案，激进的变更要有保守的测试方案，菜的开发要压力验，牛的开发要夸着验。这些场景充斥着各个维度的业务理解甚至人情世故。

测试的价值应该是站在业务层面解决交付质量保障过程中的痛点/痒点，从这点出发，其实很小马过河。
有些人觉得大模型无所不能，可能它们的业务很简单就是一个加法运算的后端接口。之前 1 位数的加法，现在要新增 2 位数的加法了。用大模型做测试设计到准出都行。
有些人觉得大模型太垃圾了，可能他们做的是地球 online 业务，针对外星人降临这个变更，别说让大模型做测试设计了，做测试执行都不行。

理论是理论，实践是实践，汇报是汇报

哥们啥业务啊，全 AI 托管的质量保证至少要需要业务知识 + 全量代码远小于 AI 上下文限制的一半以上才敢这么干。
我这边现状是测试成本低/质量要求低的研发团队才会把以前本就可有可无的 QA 吃掉作为不裁员的理由。
稍微复杂点的业务的 QA 依旧是大爷，光跨端的数据构造就够研发喝一壶了。

并不是用例执行 ai 做不到。而是生成的用例执行性太差了。
比如
用例描述 “在商城页面点击商品详情，加入购物车后使用优惠券结算” 人看没啥问题。直接交给智能体就很难有效执行。

需要翻译成：“在 http://xxx页点击 xxx 元素查看商品详情，等待跳转完成后点击 xxx 元素加入购物车，再点击 xxx 元素输入商品数量，再点击 xxx 选择优惠券，再…，最后验证 xxx 数据的 xxx 字段需要为 xxx 值”

这只是用例的一个细节，全量的转换难度可想而知，目前 1M 的上下文根本扛不住…

我觉得测试执行是 ai 最好做的，可控也可监测。不像用例生成，生成的好不好完全需要人再审查一遍。好的用例才是一切测试活动的开始……

目前测试执行的不好关键的问题还是用例生成的不够精确 + 没有对应数据构造能力。
用例生成不够精准体现在：“xxx 数据正确存入数据库” -------数据详情是什么？数据库是哪个库哪个表？
没有数据构造能力体现在：“生成一个 xxx 类型的订单 ，之后修改这个订单的 xxx 信息” ----------有对应的数据构造能力么？
除了用例生成不够精确外，数据构造能力是可以建设解决的。

用 openai 是没得选。知识库大把可以选的，大把可以离线部署商用的。
IMA 还要自己去重和脱敏，成本一点都不低，明显就不是面向商用的。真不如装个 Milvus，离线，同时不用人工去重和脱敏

成本最低，正反馈最快的结论是认真的吗？刚试了下，IMA 除了好安装以外，没 openapi，又要联公网，知识库内容还要上传到他司服务器，被信安发现了工作都不保。
个人用户体验一下还可以，无法想象有对于生产资料的外发限制这么宽松的公司

目前针给稍微复杂点的业务生成一份可行的用例都很难，还是别指望 ai 做深度的漏测评估了。
你问就是 “漏测” 了，保险起见你还是测一下吧，甚至还可能带出来几十个其他 “漏测” 的场景，人是测还是不测呢。

测试覆盖面的广度是用例设计中需要考虑的，如果 A 设计用例，B 完全按照 A 的用例执行用例。后面发现场景覆盖不全导致线上问题，会找设计方 A 还是找牛马 B？

在测试过程中想起来遗漏场景的情况，我理解有两种情况：

1. 用例执行失败了，排查的时候发现了一个遗漏的场景。 这种通过 ai 也会执行失败，需要人介入排查之后也是可以兜住的。
2. 通过执行用例，人对场景的理解越发深入，发现有些操作可以变化一下，变化后会导致一个未评估过的结果。这个可以在全部用例执行前和全部用例执行后各加一个反思环节，让智能体多次判断是否存在可能遗漏的场景。

单纯从权责的角度上来说，因为用例已经三方 review 过了且严格执行和验证了，指望在用例执行过程发现遗漏场景是不负责任的赌神行为

这个是业界难题了，能解决的人配享太庙