PTC 模式深度实战：测试驱动开发的 Agent 化

上周我接了个需求要给一个内部工具写个文件差异对比模块——就是那种对比两个文本文件然后高亮标出增删改的功能。说难不难说简单吧边界情况一堆大文件怎么办、编码不一致怎么办、二进制文件要不要跳过。我第一反应是直接开干。但转念一想这不正好拿 PTC 模式试试水吗PTC 是 Plan-Test-Code 的缩写翻译过来就是先规划、再写测试、最后写代码。听着是不是特别像 TDD测试驱动开发说实话我第一次看到 PTC 的时候也觉得这不就是 TDD 换个马甲嘛。但真正跑了一次之后我发现这玩意儿跟 TDD 是两码事——TDD 是人写测试驱动人写代码PTC 是人写测试驱动 AI 写代码。你定标准和验收条件Agent 去干活角色完全反过来了。我先把需求拆了拆对比模块需要支持行级 diff、输出统一格式类似 unified diff、能处理大文件流式读取、还要区分二进制和文本文件。放到 PTC 的 Plan 阶段就是让 Agent 先出一份实施方案。有意思的是Agent 给的 Plan 比我预想的细得多。它不光列了要做哪些函数还把每个函数的输入输出、异常处理、边界条件都写在了测试用例里。比如当两个文件完全相同时返回空 diff当文件不存在时抛出 FileNotFoundError——我本来只想了三个测试场景它一口气列了十几个。你别说看到这份 Plan 的时候我有点心虚。因为我自己写代码通常是想好主干逻辑就开始敲了边写边修边界。但 PTC 这种先写测试再写代码的流程逼着你在一开始就把所有可能出错的地方想清楚。这就像装修前先画施工图——你可以在图纸上改一百遍但上了墙再改成本就大了。然后进入 Test 阶段。Agent 开始基于 Plan 自动生成测试用例。这里有个坑——我第一次跑 PTC 的时候Agent 生成的测试代码依赖了它自己还没写的模块结果测试跑不起来。搞了半天才明白PTC 的 Test 阶段生成的不是能独立运行的测试而是描述预期的测试骨架。你得自己把骨架里的 mock模拟对象和 fixture测试夹具补全让它能真正跑起来。笑死我当时还在想不是说好 AI 帮我写测试吗怎么还得我动手。后来想通了——测试的价值在于你对需求的理解是否正确。如果测试全是 AI 写的你只是无脑说好通过那跟没测有啥区别PTC 的哲学是人定义正确AI 负责实现。补完测试骨架之后我跑了一遍——全红。正常因为还没写实现代码。Code 阶段才是真正惊艳我的地方。Agent 拿到测试用例之后开始逐个实现函数。每实现一个就跑一遍测试红了就改绿了就下一个。这个过程是自动进行的你可以盯着终端看它怎么自己跟自己较劲。我印象最深的是处理大文件那个场景。我写的测试用例要求超过 100MB 的文件不能一次性读入内存必须分块处理。Agent 第一次实现用的是readlines()直接读全部行——测试跑挂了。它自己看了错误信息换成readline()逐行读测试通过了。整个过程没人干预它自己 Debug 自己改。你想想这跟让一个 junior 工程师干活有啥区别你告诉他需求他写代码跑不通自己改。但 PTC 的 Agent 不会累、不会烦躁、不会先这样吧回头再修。我那个 diff 模块一共 7 个函数从 Plan 到全部测试通过大概花了 15 分钟。换我自己写光写测试就得半小时再写实现、调 bug一个上午下不来。当然PTC 也不是万事大吉。诚实地说有两个问题我到现在还没完全解决。一个是测试本身的维护成本。当你的测试用例从十几个涨到几十个每次改需求都得同步更新测试——这不光是 Agent 的事你作为定标准的人也得跟着改。我那个 diff 模块后来加了忽略空白符的功能结果有 7 个测试用例要调整。虽然不是不能接受但确实比直接改代码多了一步。另一个是复杂场景的测试覆盖。Agent 倾向于写路径最优的测试——正正常常输入、正正常常输出。那些刁钻的边界条件比如并发写入、文件锁、权限拒绝Agent 基本不会主动覆盖。你得自己补充这些坏心眼的测试用例。所以我的感受是PTC 不是把 TDD 自动化了而是把 TDD 的角色重新分了工。你负责坏心眼——想那些刁钻的、不常见的、用户可能瞎操作的情况。Agent 负责搬砖——把正常的、可预期的、文档里写清楚的功能实现好。你们两个合起来才算一个完整的小团队。你觉得这种人定标准、AI 实现的协作方式未来会不会成为主流还是说最终我们还是会走到AI 自己定标准、自己实现那一步