上下文工程：AI测试的下一个技术分水岭

📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）

📝 职场经验干货：

软件测试工程师简历上如何编写个人信息（一周8个面试）

软件测试工程师简历上如何编写专业技能（一周8个面试）

软件测试工程师简历上如何编写项目经验（一周8个面试）

软件测试工程师简历上如何编写个人荣誉（一周8个面试）

软件测试行情分享（这些都不了解就别贸然冲了.）

软件测试面试重点，搞清楚这些轻松拿到年薪30W+

软件测试面试刷题小程序免费使用（永久使用）

---

你是不是也有过这样的经历？

每次让AI帮忙写测试，都要写一大段提示词：

"你是一个有10年经验的高级测试工程师，精通Web自动化测试，熟悉Selenium、Playwright等工具。现在有一个电商网站的登录功能需要测试，请注意用户名长度限制、密码复杂度要求、验证码处理、登录失败重试机制..."

然后发现AI还是理解偏了，又得追加一堆补充说明：

"还有，请考虑移动端适配、记住密码功能、第三方登录、以及我们之前讨论过的那个购物车状态保持问题..."

最痛苦的是，下次测试类似功能时，又得重新写一遍，因为AI完全不记得上次的上下文。

更让人崩溃的场景：

• • 团队协作时：同事问你"那个AI测试怎么弄的？"你得把一大段提示词发给他

• • 项目交接时：新人接手项目，看到你的提示词文档，直接懵了

• • 版本迭代时：业务需求稍微一变，整个提示词又得重新调整

• • 多平台适配时：同样的测试逻辑，在不同环境下又得写不同的提示词

如果你也被这种"提示词地狱"折磨过，恭喜你，解药来了。

2025年还在纠结"怎么写好提示词"？真正的AI专家已经开始布局"上下文工程"了。这不是简单的技术升级，而是思维方式的根本转变：从"问得准"到"喂得好"。

🎯 本期重点：深度理论解析 + 典型案例分析 + 举一反三指南

一、什么是上下文工程？从browser-use看本质

1.1 提示词工程的"甜蜜陷阱"

回想一下，我们是怎么一步步掉进"提示词地狱"的？

第一阶段：初尝甜头
刚开始用AI时，写个简单提示词就能得到不错的结果：

"帮我写个登录测试用例"

哇，真香！AI竟然能理解我的需求。

第二阶段：不断加料
发现AI生成的不够准确，开始疯狂增加限定条件：

"你是一个专业的测试工程师，请帮我写登录功能的测试用例，要包含正常流程、异常流程、边界值测试、安全性测试..."

第三阶段：详细到变态
还是不满意，继续增加细节：

"...请注意，我们用的是React框架，后端是Node.js，数据库是MongoDB，登录接口地址是/api/auth/login，用户名字段叫username不是email，密码要求至少8位包含大小写和数字..."

第四阶段：绝望循环
每次新项目都要重写一遍，因为AI不记得之前的对话。你的提示词文档越来越长，像一本小说...

这就是传统Prompt Engineering的本质：我们以为在"训练AI"，实际上是在"训练自己"写更复杂的说明书。

问题是，AI依然缺乏"上下文感知"，就像一个患有严重失忆症的专家，每次都要从头开始介绍整个世界。

上下文工程的核心洞察：不是教AI怎么问，而是给AI完整的"工作环境"。

让我们看一个典型的实现思路（以browser-use为例）：

# 传统提示工程的思路
def prompt_based_test():
    prompt = "请点击页面上的登录按钮"
    return ai.execute(prompt)  # AI只知道指令，不知道环境

# 上下文工程的思路  
def context_based_test():
    context = {
        'current_environment': get_page_state(),      # 环境感知
        'available_actions': get_possible_actions(),   # 能