AI编程中的经典回归

2.1 结对编程：从”两人一机”到”认知冗余”

结对编程在极限编程（XP）时代被提出，核心理念是两人共用一台电脑，一人写代码一人审查，实时切换。当时最大的反对意见是”效率减半”——两个人干一个人的活。

AI时代，这个反对意见不成立了。人与AI结对，不是效率减半，而是效率倍增。一人向AI提需求，另一人审查AI产出，这不是两个人在抢一台电脑，而是两个人在共同驾驭一个强大的代码生成引擎。

但更深层的原因不在于效率。AI生成的代码有一个根本性问题：没有”原作者”可以问。人写的代码，三个月后出了bug，你可以找作者问”这里为什么这么写”。AI生成的代码呢？团队里没有人知道那段代码为什么这么写，没有人知道它的局限性和假设条件。

结对编程在AI时代的真正价值是认知冗余——让多个人同时理解AI产出的代码，而不是依赖AI的”黑箱解释”。当一个人离开了，至少还有另一个人知道那段代码的逻辑。这是对抗”AI代码孤儿化”最有效的手段。

实践中，有几个具体做法值得参考：人-AI结对模式，一人向AI发出需求指令，另一人审查AI的输出质量和正确性；轮换机制，定期换人，让理解范围在团队中扩散；实时解释，要求AI在生成代码时同步生成设计决策的解释，而不是只输出代码。

2.2 零信任架构：不信任任何Agent

零信任架构的核心理念是”永不信任，始终验证”。这个概念最初是针对网络安全提出的，但在AI时代有了全新的含义。

传统的企业安全模型是”信任边界内的一切”——内部网络中的服务可以自由互相调用，因为它们都在”信任区”内。这个模型在人类运维时勉强可行，因为人有判断力。但当Agent进入内部网络，情况就不同了。Agent没有判断力，它只会按照指令执行。如果Agent被恶意Prompt注入操控，它在”信任区”内的行为就是灾难性的——因为它可以自由访问任何内部服务。

所以AI时代的零信任意味着：不信任任何Agent，无论它在哪个网络位置。每个Agent有独立身份，每次调用都需要验证；Agent只能访问完成任务所需的最小数据；所有操作都有审计追踪，便于事后追溯；Agent在沙箱环境中执行，防止横向移动。

这不是对Agent的不信任，而是对系统安全的负责。就像零信任网络不是不信任员工，而是承认任何组件都可能被攻破。Agent也是如此——即使Agent本身没有恶意，它也可能被Prompt注入操控，可能生成幻觉代码，可能意外暴露敏感数据。零信任架构是最后的防线。

2.3 变异测试：测试的”元测试”

变异测试是个很有意思的方法，主要的原则故意设一些陷阱 ¹，然后看AI的测试是不是真的能识别出来。

要解决的问题就是AI写测试很快，但AI写的测试可能只是”看起来像测试”。

举一个典型的例子：AI生成了login函数的测试，覆盖率100%，看起来完美。但看断言——assert result is not None。这个断言太弱了，几乎任何返回值都能通过。这意味着即使login函数有严重bug（比如总是返回硬编码的token），测试也发现不了。

这是AI生成测试的通病：覆盖但不检测。测试覆盖率很高，但没有真正验证关键逻辑；测试结构正确，但断言太弱；只测正常路径，忽略边界条件。

变异测试的思路巧妙而直接：故意在代码中引入小bug——把a + b改成a - b，把if x > 0改成if x >= 0，把return True改成return False——然后运行测试套件。如果测试能发现变异，说明测试有效；如果测试通过了变异代码，说明测试有盲区。

变异评分是量化这个有效性的指标：被检测到的变异数除以总变异数，目标通常在80%以上。如果评分过低，说明测试套件存在大量盲区，需要加强断言和边界条件测试。

对AI编程来说，变异测试特别重要。因为AI生成测试时有一种倾向：写”容易通过”的测试来满足覆盖率要求，而不是写”真正能发现问题”的测试。变异测试恰好是测试的”元测试”——它不验证代码，而是验证测试本身是否合格。

如果是人来测试，那变异测试就有点冒犯的意思，就是不大相信测试人员的样子。 但是对于AI来说，尤其是上面刚教过的零信任原则，那就刚刚好可以对症使用了。

2.4 DORA指标：速度与质量的平衡计分卡

DORA（DevOps Research and Assessment）的四大指标——部署频率、变更前置时间、服务恢复时间、变更失败率——是衡量工程效能的经典框架。

AI时代，这四个指标面临新的张力。前两个指标（部署频率和变更前置时间）被AI大幅加速——代码生成更快了，提交更频繁了。但后两个指标（服务恢复时间和变更失败率）可能反而恶化——AI生成的代码质量不稳定，出了问题更难定位，因为没人理解那段代码。

这个失衡是危险的。如果只看前两个指标，你会觉得AI让一切变好了。但后两个指标的恶化意味着：你在更快地制造技术债 ²务，只是暂时还没还债。

解决方案不是放慢速度，而是在加速的同时加强质量控制：提升审查能力（自动化审查加人工审查），强化测试覆盖（特别是变异测试），完善监控告警（快速发现问题），建设回滚机制（快速恢复）。

实践中，DORA指标需要分层监控：团队级看整体效能趋势，服务级看各服务的健康状态，Agent级看AI产出的质量波动。特别重要的是趋势监控——不只是看绝对值，而是看变化趋势。如果部署频率持续上升但变更失败率也在上升，这就是一个需要立即关注的信号。每次失败都需要追溯根因 ³：是人的问题还是AI的问题，是能力不足还是约束不够。

2.5 命令行复兴：Agent的天然接口

命令行正在经历一场静默的复兴。不是因为在终端里敲命令有多酷，而是因为命令行是AI Agent最自然的操作接口。

GUI工具是为人类设计的——需要鼠标点击、需要视觉识别、需要人工判断。这些对Agent来说都是障碍。而命令行工具天生适合Agent操作：命令是文本的，输出是结构化的，可以批量执行，有完整日志，可以在服务器上无头运行。

一个典型的场景：Agent收到”添加认证模块”的指令后，执行一系列命令——创建分支、安装依赖、生成代码、运行测试、提交代码、创建PR。整个过程无需人工干预，每一步都有日志可追溯。

之前在讨论AI编程架构时，曾提到CLI命令行管道架构是对AI编程的最佳适配之一。每个进程独立运行，输入输出明确，AI只需专注于当前进程的逻辑。命令行复兴从另一个角度印证了这一点：当Agent成为主要的代码生产者，那些对Agent友好的工具和接口就会获得新的生命力。

但命令行复兴也带来了新的风险：Agent执行命令的权限边界在哪里？如果Agent可以执行任何命令，那它就可能执行危险的命令——删除数据、修改权限、暴露密钥。所以命令行复兴的同时，也需要配套的安全措施：命令审计（记录Agent执行的所有命令），权限控制（限制Agent可执行的命令范围），沙箱执行（危险命令在隔离环境执行），回滚机制（支持撤销Agent的操作）。