聊聊QECON分享-AI Coding & AI Testing这是鼎叔的第一百四十九篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。欢迎关注公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人专著《无测试组织-测试团队的敏捷转型》已出版（机械工业出版社）。虽然这本书是远古时代（2023年）出版，还未涉及大模型时代的实践，但我认为现在80%的AI工程认知和过往的敏捷理论没有什么两样。鼎叔上周末在QECON全球质量与效能大会的最后一场进行了压轴分享，这也是时隔三年后的第一次业界分享。毫不意外目前所有的分享主题都是围绕AI实践展开，但很少场次的分享是聚焦人和组织的变化。一开始还担心大家是不是更希望听具体项目细节和看实践效果，对我聊的主题兴趣不大。但分享下来感觉氛围很棒，提问很踊跃。很明显，“人和组织”是AI时代最值得深入探讨的维度，这是本源。具体AI实践项目和工具技术细节会随着时间的推移而迅速被替换和升级，但本源的观点是可以跨越时间周期的。这篇列出PPT内容和一些会场上的感想。未来会放出视频。将来还会基于PPT中的具体探讨观点深入撰写调研文章。主题《AI Coding&AI Testing:重塑软件交付的组织管理 》这两天的学习交流收获良多，鼎叔知道很多大厂一线团队在AI工程实践上已经非常成熟了，但听完了分享，感觉还是超出预期，没想到玩得这么溜。当然，PPT上惊人的收益指标可能隐藏了不少限制条件，意味着听众回去很难落地出同样的效果，而现场不到一小时的沟通是远远不够的。由于大家的注意力全放在AI实践了，经验打法上也更加趋同。我以为我的实践感悟只有自己知道，实际上来会场后发现大家都知道。人人必聊harness engineering。第三层，针对复杂项目或者工具平台，给出了成熟方法论或者问题解决框架，方便跨团队，跨公司借鉴。来行业峰会做主题分享，一般要到达这个层次。第四层，如果要在大会上做keynote焦点分享，你要聊什么呢？原则，标准，价值观，远景（和传统工程时代似曾相识，只是定义对象变成了AI时代的现在与未来）。最高的第五层是什么？AI引发的哲学思考。AI对文科或文化理念的冲击，比理工科更大。人和AI未来如何相处，在哲学思考上自会产生新高度。从时机来说，鼎叔始终认为AI变革时代是敏捷教练的新机会。过去，敏捷教练和效能团队在推广方案时挺憋屈，因为想改变普通产研团队的工作习惯是非常困难的，改变认知更是难上加难。敏捷专家来到新团队，如果变革动作偏快，会有人说外部经验不接本地的地气，员工不理解为啥这么做；如果动作谨慎，慢慢来吧，又有人说空有理论，落地速度不行。对每个团队的培训辅导成本很高，一不小心还可能引发信任危机。AI新时代，敏捷教练可以把自己的方（si）法(huo)论内化为AI工作流或skills，大幅降低跨团队推广成本。经典敏捷工程理论，在AI时代是被强化了，而不是过时了。AI是专业能力的放大器，所以我们首先要储备最擅长的能力和经验，再用AI去放大它，这是成功率最高的策略，而不是盲目追求AI创新。另外，鼎叔研究的焦点是人，AI时代给你发工资的依然是人，所以提高员工、管理者、用户的认可度，帮助这三类人实现价值，是引入AI实践的最终目标。基于这个框架，鼎叔分享的PPT可以很长时间不用修改，但是讲述的例子和启发，是可以不断更新的。
回到AI Native这个关键词，它标志着员工和组织的转型要达成的最终目标，想象出AI原生时代的模样，才能推断出目前最重要的事是什么。
AI Coding-文档即代码
参考文章 聊聊AI编程如何改变开发工作流
参考自动驾驶技术给AICoding的成熟度进行分级，有利于我们知道自己企业距离AI native还有多远。
AI Coding时代的开发者应该转身为什么角色？
我认为有这四种角色可以去担任，从而完成从码农到指挥官的蜕变。
精准翻译官。开发者要从编码解决问题转为“定义问题”，这个对综合能力的要求更大。翻译官意味着打通用户（业务）世界到技术世界的壁垒。精准的意思是无歧义，AI容易理解（结构化），并能把复杂需求正交拆解为不遗漏不重复的多个需求（用户故事）。
环境描述者，这是上下文工程的一部分内容，让AI知道自己处于什么环境，有什么资源可以利用，上下游调用者和自己是什么关系。
规范制定者。为了让团队能顺利跑起AI工程并协作良好，我们需要一系列的规范去定义业务模块之间，或agent和agent之间的协议关系。初期是面向员工而写（让小团队协作关系跑起来），以后会逐步变成为了AI而写（让AI自主协作）。
验收驱动者。主导ATDD（测试驱动开发）实践，确保AI产出始终是符合产品预期的，而不是自我发挥。
同时要验收安全合规的红线，人类专家目前在这方面的认知比AI更全，敏感度更高。这块对业务发展是至关重要的护栏。
skills是团队向内的能力，本质上就是特定场景解决特定目的的工作流。MCP是向外的能力，我们的agent作为客户端，轻松接入外部服务，就要特别关注接入服务的规范性、合法性。最大的感受就是，需求评审要一步一步的得到结果，不要企图让AI一次性给出多个不同问题的分析结果，各个步骤最好是循序渐进，越来越接近产研思考的本质。另一个会带来麻烦的地方是生成文档的权限，我们要考虑AI生成结果是否全员可见。为什么我鼓励ATDD实践优先，而不鼓励SDD实践（规范驱动开发）优先？ATDD+TDD是一个逻辑严密的双重闭环，确保研发以终为始，对容易跑偏的AI工程是天然的矫正机制。在过去的人工编程时代，要普及TDD/ATDD实践太难了，在业务浮躁的时代要养成一步步验证的新编程习惯很不容易。但是在AI Coding时代，我们可以理直气壮提要求，实现代码都是AI生成的，让它跑ATDD/TDD不是顺理成章么？SDD的问题在于容易让团队度过磨合期后形成僵化机制，不愿意去破坏已经很熟悉的Spec，而AI工程的特质就是随着模型的升级而消解规范束缚，必须强调变化。我认为是为产研部门提供确定性信息。BUG只是其中最重要的一类信息。初级测试团队只把精力放在BUG这类信息上，但是高级测试团队提供的确定性信息就多很多。所以，AI工程时代，测试的本质工作-提供确定性，将更重要，更有价值。这几年带过不同团队，会发现部分测试人员是排斥参与AI创新实验的。究其原因，消极情绪主要来自于这几点：一 开发vibe产生了大量代码，都指望测试人员来兜底么？很多AI代码，看起来能正常工作，实际上线后引发一堆莫名其妙的问题。DEMO功能用的产品，和生产环境中的产品，在设计细节上有巨大的差距。这肯定不是从表面肤浅的vibe coding能想得到的。代码层面coding得再牛，也不能替代更高层次的测试，如端到端的功能验收，性能压测，安全合规检查，外部联调，易用性，兼容性，升级降级，等等。系统测试的范围很大，AI实践的空间和机会也大，但进度远远跟不上AI coding的发展速度，我们也严重缺乏高层次AI测试的封装平台。前两年AI生成的测试用例大部分都是大路货，乏善可陈。测试人员筛选有效用例的时间，还不如人工写用例呢。有些同学笑称：我不当小白鼠，只要我学得足够慢，我就什么AI都不用学。随着harness实践的成熟，AI用例的采纳率会大幅提升。但从采纳率低的现象进行反思，我们能找到很多提升用例有效性的因子，针对性地生成更好的用例集。后面围绕这些困惑和因子探索，还会输出更详细的解读文章。下一期继续讲完PPT的后半部分思考，以及现场听众的犀利问题。
夜雨聆风
