北京
你让AI写了一个函数，它返回的代码看起来没毛病，甚至能跑通。大多数工程师到这儿就停了——看到绿色的通过标记就继续往下走了。但这个习惯会悄无声息地给你埋雷。
像GitHub Copilot、Cursor和Claude这类AI编程工具确实很实用。但它们是非确定性的，意味着同样的提示词不同时间可能产出不同的结果。AI给出的代码常常看起来合理，却微妙地藏着错误，或者只在理想路径下能跑，碰到边界情况就崩。如果你没有一套系统的方法来评估AI产出的代码，基本上就等于在把未经测试的第三方代码直接部署上线，全凭运气。
要说清楚这个问题，可以先想一下人类同事写的代码。你可以在评审时问他们思路，可以看提交历史去追溯上下文。但AI写的代码完全不一样——成品直接丢到你面前，还经常带着自信十足的注释，你很容易因为表面的工整就默认代码质量过硬。更麻烦的是，AI模型是在海量公开代码上训练的，这些代码里本就包含着大量不良实践和反模式。模型可能流利地复现这些问题，写出的代码初看没问题，但在真实负载、特殊输入或安全审查面前就会出状况。
对AI代码做评估，不是说不信任AI，而是要用对待任何进入代码库的代码一视同仁的工程纪律。
你能做的最有效的一件事，是在让AI写实现之前，先把测试写好。这其实就是测试驱动开发的理念，把它搬到AI辅助的工作流里特别合适。当你把“什么叫正确”事先定义清楚，AI返回代码的那一刻你就有了一把客观的标尺——不是靠肉眼凭感觉，而是直接拿你写好的契约去跑。
举个简单的例子。假设你想让AI写一个解析价格字符串的函数，比如把“$12.99”转成浮点数。在给出提示词之前，你可以先写好这样一个测试：
def test_parse_price():
assert parse_price("$12.99") == 12.99
assert parse_price("$0.00") == 0.0
assert parse_price("$1,299.99") == 1299.99
assert parse_price("") is None
assert parse_price("free") is None
然后再去提示AI：“用Python写一个叫parse_price的函数，接收类似‘$12.99’或‘$1,299.99’这样的价格字符串并返回浮点数，对无效输入返回None。”AI一返回代码就立刻运行这些测试。它可能通过五条中的四条，你立刻就知道哪里需要修，甚至不用读一行实现代码就定位到了缺口。
第二个值得养成的习惯是构建一个“黄金数据集”——也就是一小批带有已知正确结果的输入。可以把它看成任何AI生成功能的一个永久性测试套件。开始时你只需要准备五到十个示例，把输入和预期输出记录好。每次AI重新生成或修改代码，都先跑一遍这批数据。这样你就不必每次都重新从头理清什么是对的，变更过程中也更容易发现AI无意间退化的部分。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
