夜雨聆风
AI Coding 正在重估软件价值:功能可复制,质量不可复制
AI Coding 热点解读 · 质量工程实践 · 测试价值重构
当 AI Coding能快速生成相似功能时，测试工程师的价值不应停留在页面能点通、流程能跑完，而要转向证明系统背后的复杂度、稳定性、可维护性和质量资产
核心观点
AI 可以更快生成一个“看起来能用”的软件原型，但它很难一次性复刻长期沉淀下来的业务规则、异常场景、权限边界、数据一致性、性能稳定性、可观测性和测试资产。功能越来越容易生成，质量反而会成为更关键的护城河
01｜AI 复制软件，说明了什么？
近日，FT 报道了一个很有意思的案例：Bain 在软件并购尽调中使用 “vibecoding”，也就是通过 AI 快速复制目标软件的部分组件，从而判断这个产品是否容易被复制，技术护城河是否真实存在。
这个视角对测试工程师很有启发
过去我们评价一个软件，常常看功能是否完整、流程是否跑通、页面是否可用。但当 AI 可以在很短时间内生成一个相似的功能原型时，单纯的“功能可用”就不再足以证明软件价值
真正有价值的东西，开始转向那些不容易被 AI 一次性生成出来的部分：复杂业务规则、异常场景处理、权限边界、数据一致性、性能稳定性、可观测性、历史缺陷沉淀、自动化测试资产、质量门禁体系，以及团队对业务风险的长期理解。
一句话判断
AI 复制软件真正暴露的问题是：功能表层越来越便宜，质量深度越来越重要
02｜为什么“功能可用”不等于“软件有护城河”？
很多测试工作过去容易停留在一个层面：功能是否符合需求文档
比如按钮能不能点击，表单能不能提交，接口能不能返回 200，流程能不能走完，页面有没有明显报错
这些当然重要，但它们只能证明“功能能跑”，不能证明“系统可靠”
真正的软件护城河，往往藏在更深的质量层里
业务规则：状态流转、计费规则、库存扣减、审批逻辑是否准确
异常场景：超时、重试、重复提交、脏数据、第三方失败是否可控
权限边界：多角色、多组织、多租户下是否存在越权访问
持续交付：代码变更后，核心链路是否能被快速、稳定、自动化地验证
AI 可以生成一个看起来相似的页面，但很难一次性生成一个经过多年业务沉淀、质量验证和风险治理的系统
这就是测试工程师真正要证明的东西
03｜测试工程师能证明哪些不可复制的质量资产？
第一类：业务规则资产
一个成熟系统最难复制的不是页面，而是业务规则。比如订单状态、审批流、计费规则、库存扣减、权限继承、数据同步、异常回滚，这些逻辑往往不是单个需求文档能完整描述的
测试工程师要把这些隐性经验显性化，形成规则清单、状态机图、业务流转矩阵和高风险场景库
第二类：异常场景资产
真正拉开质量差距的，不是正常流程，而是异常流程
重复提交、接口超时、弱网重试、并发修改、脏数据、权限越权、缓存不一致、第三方服务失败、消息重复消费、任务中断恢复，这些场景是 AI 复制原型时最容易遗漏的部分
第三类：自动化回归资产
一个系统是否能持续迭代，不只看当前版本能不能跑，还要看每次代码变更后，核心链路是否能快速验证
高价值的自动化测试，不是简单堆脚本数量，而是能够覆盖核心业务链路、稳定运行、定位失败原因，并和 CI/CD、质量门禁、缺陷管理、测试报告形成闭环
第四类：Diff 风险分析资产
AI 时代，代码变更会越来越快。测试工程师不能每次都靠人工判断“这次要测哪里”，而要建立基于 Diff 的风险识别能力
这类能力可以帮助团队判断：本次改动影响哪些模块？是否触碰核心链路？是否涉及权限、金额、状态、数据一致性？应该精准回归，还是触发全量回归
第五类：质量报告资产
过去的测试报告常常只是“通过多少、失败多少、缺陷多少”。但 AI 时代更有价值的质量报告，应该回答“本次版本最大的质量风险是什么”
它要说明哪些风险已经被自动化覆盖，哪些风险仍需要人工判断，哪些模块长期不稳定，哪些缺陷正在重复出现，哪些质量问题会影响产品护城河
可以落到一条简单链路
Step 1：识别代码 Diff 与业务影响范围
Step 2：匹配风险场景、自动化用例和人工验证点
Step 3：执行精准回归，并把失败结果归因到代码、环境、脚本或数据
Step 4：生成质量报告，支撑上线决策
04｜工具也在提醒我们：测试对象变复杂了
Playwright 这类自动化测试工具的更新，也在说明测试正在从“点页面”走向“验证复杂系统行为”
例如，Playwright 1.61 在工具侧强化了 WebAuthn passkeys、Web Storage、网络安全信息、视频保留模式、WebSocket 进入 HAR/trace 等能力。这些能力背后，指向的是身份认证、状态管理、网络链路、协议交互和运行时诊断
这意味着，测试工程师不能只会写 UI 自动化脚本，还要理解系统风险
工具升级背后的变化
今天的测试对象不只是 UI 页面，还包括身份认证、会话状态、网络协议、Agent 行为、数据流转、权限边界和可观测性验证
05｜AutoJack 给测试工程师的另一个提醒
Microsoft 披露的 AutoJack 案例，说明 AI Agent 带来的风险不是单点功能问题，而是运行时系统风险
当一个 Agent 可以浏览网页、调用工具、访问本地服务、连接 MCP、读写文件或执行命令时，传统的测试边界会被打破
Agent 场景下要重新检查的问题
Agent 会不会被不可信内容诱导？
本地服务是否默认信任 localhost？
MCP 工具调用是否有权限控制？
Agent 能否访问不该访问的文件、接口或命令？
关键操作是否需要人工确认，执行过程是否可追踪、可回放、可审计？
这说明 AI 质量治理不是“给测试加一个大模型”，而是要重新设计测试边界、权限边界和运行时防护
06｜AI 时代，测试工程师应该怎样表达价值？
测试工程师未来要少说“我测了多少条用例”，多说“我证明了哪些风险被控制住”
更有价值的表达方式
我证明了核心业务链路在关键场景下是稳定的
我证明了权限边界没有被越权绕过
我证明了数据在异常、并发、重试场景下仍然一致
我证明了本次代码变更没有破坏核心路径
我证明了质量报告能支撑上线决策
可以复用的 Diff 风险分析提示词
请基于以下代码 Diff，识别本次变更可能影响的业务模块、核心链路、权限边界、数据一致性风险、异常场景和需要回归的自动化用例输出格式：1. 变更摘要2. 风险等级3. 影响模块4. 必测场景5. 建议自动化回归范围6. 是否建议阻断发布结尾：功能可以被复刻，质量才是护城河
当 AI 能快速复制一个软件的功能原型时，测试工程师的工作就不能停留在“功能能跑”这个层面
因为功能越来越容易生成，真正稀缺的是质量
复杂业务规则、异常场景、数据一致性、权限边界、性能稳定性、可观测性、自动化回归体系、Diff 风险分析能力、质量门禁和质量报告，这些才是一个软件产品真正难以复制的部分
未来的测试工程师，不只是功能验证者，而是质量资产的建设者
参考信息源
FT：Bain tests software takeover targets by vibecoding AI replicas
Microsoft Security Blog：AutoJack: How a single page can RCE the host running AI Agent
Playwright Release Notes：Playwright 1.61