AI编程的利刃：同步生成测试脚本

⏳️那个最消耗人的循环

你一定经历过这个场景。

让AI写了一段功能代码。它写得很快，语法漂亮，逻辑看起来也没问题。烧进板子，跑起来，发现不对。打开串口日志，在一堆输出里翻找线索。找到一处可疑的地方，截图，回到AI对话，描述问题。AI重新生成代码。再次烧录，再次测试，再次发现问题，再次截图，再次描述。

这个循环跑三轮，你就累了。跑五轮，你开始漏掉关键信息。跑十轮，你已经忘了最初的问题是什么。

这个循环里，最慢的不是AI生成代码的速度。最慢的是你。

你的注意力有限，你的描述可能不准确，你在反复多次后会疲惫、会漏掉、会不想继续。调试，才是整个开发流程中最消耗人的环节。

但很少有人意识到：调试这个环节，完全可以不经过人的手。

🔑我的解法：把调试交给AI自己

后来我养成了一个习惯。每次让AI生成功能代码时，我同时要求它生成一个测试脚本。这个测试脚本不只是跑一遍功能看对不对，它里面嵌入了负日志——不是记录"发生了什么"，而是断言"什么必须发生"。

超时了，有输出。期望事件没等到，有输出。状态迁移没在规定时间内完成，有输出。

当测试运行时，两股日志流同时产生。功能代码输出它做了什么，测试脚本输出它期望什么但没等到。两股日志流汇在一起，完整地喂回给AI。

AI不需要我去描述问题。它自己读日志，自己发现哪里不对，自己修改代码，自己再次运行测试，自己再次读日志。

人从这个循环里消失了。不是人不管了，是人退到了最后一道关口。AI跑完整个循环，告诉我"收敛了，所有测试通过"。我只需要做最后的确认。

⚡利刃出鞘：完整工作流

第一步：同时生成功能代码和测试脚本

告诉AI：

"请为这个外设生成驱动代码，同时生成一个测试脚本。测试脚本必须包含负日志：用EXPECT_WITHIN检查外设是否在规定时间内响应。如果期望事件未发生，测试脚本必须输出[NEGATIVE]开头的日志。"

第二步：AI自动运行测试，收集两股日志

测试脚本运行。功能日志记录正常的数据流，负日志记录那些"应该发生但没发生"的事件。两份日志，一份说"我做了什么"，一份说"我期望什么但没等到"。

第三步：AI自行分析日志，自行修复

把两股日志完整喂回给AI，不需要任何人工描述。AI自己读，自己定位问题，自己生成修复代码，自己同步更新测试脚本以覆盖新发现的边界条件。

第四步：循环直到收敛

AI生成修复代码，再次运行测试，再次分析日志。这个循环自动运行，直到所有测试通过，且连续两轮无新的负日志出现。

第五步：人做最终确认

AI报告收敛完成。人检查最终结果，确认无误。决策写入决策账本。

💡为什么这是最锋利的利刃

因为它把调试——这个最消耗人的环节——从人的工作流里彻底剥离了出去。

传统模式下，调试依赖人的注意力、人的判断力、人对日志的解读能力。这些能力人确实比AI强，但人有限。人会累，会漏，会在深夜失去耐心。而AI有无限的耐心和无限的注意力。它不会漏掉日志里的任何一行，不会因为疲惫而误判，不会因为情绪跳过细节。

把调试交给AI，就是把最消耗人的事交给最擅长做重复劳动的对象。

而这一招，完全符合你整个体系的哲学内核。你定义了法则：功能代码和测试代码必须同步生成，日志格式必须统一，负日志必须断言期望事件，收敛标准必须明确。AI在法则内执行：生成代码、运行测试、读取日志、发现偏离、自行修复、再次验证。

🎁这把利刃的价值

它带来的改变是实实在在的。

你的时间不再消耗在反复的调试循环里。你的注意力不再被琐碎的日志分析吞噬。你的AI不再是需要你手把手教的学徒，而是一个能自己发现问题、自己修复问题、自己验证修复的工程伙伴。

而你，从调试的泥潭中解脱出来，去思考更重要的事。去定义方向，去判断边界，去设计法则。

这才是AI编程真正的价值：不是AI帮你写了一行代码，而是AI帮你省下了所有不该由你来消耗的时间。

现在就可以开始

不需要搭建复杂的系统，不需要安装任何新工具。你只需要在下一次让AI生成代码时，多说一句话：

"同时生成测试脚本，测试脚本必须包含负日志。把功能日志和测试日志一起输出，后续你自行分析日志并修复问题，直到所有测试通过。"

这一句话，就是你整个体系在实践中最锋利的利刃。它让AI从一个被动的代码生成器，变成了一个能自我调试、自我修复、自我收敛的工程伙伴。

而我，从不自己写测试代码。测试脚本是AI写的，测试是AI跑的，日志是AI读的，Bug是AI自己改的。我做的，只是在它报告"收敛了"的时候，看一眼，点个头。