又是一次干饭时，同事建议用AI检查评审遗漏，’问下就好了’。聊到当前在做的llm代码评审工具时却嘲讽上下文工程：’就是把上下文重组问AI，输出肯定不稳定，不如自己写逻辑’。这两种态度背后，是对大模型基础认知的缺失。
-
-
Agent驱动的测试变更管理系统设计实录
引言：一个看似简单的需求“帮我为项目补充测试用例。” 这个需求听起来很简单，对吧？我最初也这么认为。让AI Agent分析代码，生成测试用例，编译运行，发现问题就修复——听起来就是一个标准的自动化流程。 但当我真正开始设计这个系统时，才发现真正的挑战根本不在代码生成本身，而在于一个更基本的问题：如何管理这些不断产生的变更？ 想象一下这个场景：一个月后，当你看到代码库里多了几十个测试用例，你会... -
从ReAct到混合架构的技术选择艺术
引言：技术选择背后的工程哲学又是一个需要做技术选型的时刻。面对Agent技术栈的多种选择，每一种都有其拥护者，每一种都声称能完美解决我们的问题。这需要我们对常用的技术路径进行深入的分析和讨论。 当我第一次接触到ReAct模式时，被它与人类思维过程的相似性深深吸引。想想我们平时是怎么解决编译错误的：先看错误信息（观察），然后分析可能的原因（推理），接着尝试一个修复方案（行动），再看结果如何（观... -
现有测试自动化方案为何失效？从工具局限到认知负荷的全面分析
引言：自动化的美好愿景与残酷现实上个月，算法工程师小孙完成了一个新的电机控制算法，效果很好，但现在需要为它编写测试用例。想到又要折腾测开那边提供的测试框架不免有些头大。他想起之前听说过一些AI Coding工具可以帮助生成测试代码，于是开始了他的”工具探索之旅”。 首先尝试了Cursor。输入了算法接口后，Cursor确实生成了一些测试代码，看起来很专业。但当他试图在我们的esim环境中运行... -
软件在环测试的重复劳动困境
引言：当第十次遇到相同问题时的思考又是一个周三的下午，电机控制算法工程师小张刚完成了一个新的PID控制器优化，代码只有不到100行，但测试效果很好。现在他需要为这个优化编写测试用例，确保代码质量和防止回归。 这已经是他第十次面对类似的情况了。每次完成功能开发后，都要花大量时间学习如何使用GTest+CMake+esim这套测试框架。每次都要重新搞清楚esim接口和真实硬件的映射关系，每次都要... -
Agent化测试框架的工程实现全链路解析
引言：从设计到实现的工程化之路当我第一次尝试让Agent生成测试代码时，最初的兴奋很快被现实的复杂性所冲击。让Agent偶尔生成一段可用的代码并不难，真正的挑战在于如何构建一个稳定、可靠、可扩展的完整实现链路。 就像设计一条生产线，每个环节都需要精确的思考和规划。需求理解如何避免歧义？工具选择的依据是什么？代码生成怎样保证质量？编译过程如何实现自动恢复？错误处理需要什么样的策略？任何一个环节... -
特征检测算法的工程化之路
几天前更新了iOS，我的Siri突然’聋’了，无论怎么喊都没反应。重启后恢复正常，但这个小插曲让我想起一个技术问题：这些设备如何在7×24小时运行中，从连续音频流里准确捕捉那几个唤醒词？ A few days ago, my Siri went ‘deaf’ after an iOS update, making me wonder about the engineering challenges behind always-on wake word detection.
-
从游戏信号到真实手感：控制系统中的"体验映射"
最近在调试一个游戏设备的力反馈系统时遇到了奇怪现象：明明信号输出正常，用户却说’手感不对’。这让我开始思考一个问题——我们如何将虚拟世界的数字信号转化为用户能感知的真实体验？ Recently debugging a haptic feedback system, I found that perfect signal output doesn’t guarantee the right ‘feel’ for users.