你的AI编程助手在“忽悠”你（AI编程助手中不确定性的隐性成本）
关于Devin一个月的使用体验——Answer.AI
Answer.AI最近对Devin的评测揭示了一个关键但常被忽视的AI编程助手问题：它们令人抓狂的不确定性。虽然人们更多关注的是它们的原始能力，但对于专业开发者来说，真正的挑战不仅在于这些工具能做什么，更在于知道何时使用它们。
老虎机问题
每次与AI编程助手互动本质上都是一场赌博。这次查询会帮你节省30分钟，还是会浪费你3小时？能力的边界不仅模糊，甚至具有误导性。一个工具可能某天能出色地处理复杂的API集成，但第二天却连基本的字符串操作都搞砸。这种差异让经验丰富的开发者不得不持续付出认知成本。
最阴险的部分不是失败本身，而是对决策过程的不确定性“税”。你是否应该尝试用AI助手来完成这个特定功能？没有明确的经验法则。任务的复杂性并不能可靠地预测结果，与之前成功互动的相似性也无法保证。每次决定使用AI助手都像抛硬币，赌注在你投入之前并不明确。
破坏专业流程
专业软件开发高度依赖确定性知识和可预测的工具。当资深开发者写一行代码时，他们不仅在解决眼前的问题，还在更新对整个系统的心理模型。他们确切地知道做出更改后会发生什么，这使他们能够推理复杂的交互和副作用。
AI助手通过在一个本应是确定性的过程中引入随机性元素，破坏了这种流程。这就像给一位大厨一把有时切得完美、有时却把食材搅成糊的刀，而且无法预测结果。或者给专业摄影师一台焦距随机变化的相机。这种不确定性不仅会减慢当前任务的速度，还会干扰专业知识的积累。
边界错位
AI编程助手的营销常常将它们包装成“AI软件工程师”或“结对程序员”，但这种拟人化实际上是有害的。人类开发者有明确的能力边界——他们可能擅长前端开发但不擅长数据库优化，或者精通Python但对Rust一窍不通。这些边界清晰、一致，并且与可识别的知识领域相对应。
相比之下，AI助手的能力边界与传统软件工程类别并不一致。它们可能擅长编写正则表达式，却在基本的for循环上栽跟头；可能精通复杂的TypeScript类型定义，却无法正确关闭文件句柄。这些边界不仅跨越了传统的专业领域，甚至似乎违背了任何合理的分类。
原始提示：意外的赢家
尽管自主编码代理的演示令人印象深刻，但许多开发者发现，简单、集中的基础语言模型提示仍然是最可靠的方法。关键区别在于控制和可预测性。当你提示GPT-4生成特定函数时，你是在明确的约束下操作。范围有限，上下文可控，最重要的是，你始终牢牢掌握着方向盘。
这种对原始提示而非自主代理的偏好并不是技术的失败，而是对可预测性和控制是功能而非缺陷的认识。精确界定和限制AI参与的能力使开发者能够保持他们的心理模型和工作流程，同时仍然利用AI的能力。
未来方向：重新定义AI编程辅助
为了让AI编程助手真正对专业开发者有用，我们需要摆脱“AI作为同事”的模式，转向更能反映这些工具真实本质的东西。一些潜在方向：
- 能力聚类：与其承诺广泛的软件工程能力，不如专注于特定、明确的任务，在这些任务中它们始终表现出色。
- 信心信号：AI助手可以提供清晰、可靠的处理特定类型任务的信心指标，让开发者能够明智地决定何时使用它们。
- 有限自主性：与其追求完全自主，不如让工具在明确定义的约束下运行，减少开发者必须应对的不确定性空间。
- 模式识别：社区可以努力识别和记录AI能力和失败的实际模式，而不是试图将它们强行纳入传统的软件工程类别。
AI编程辅助的未来可能不在于创造完美的自主代理，而在于开发能够补充人类开发者优势并诚实地承认其局限性的工具。目标应该是减少决定何时使用AI辅助的认知负担，让开发者专注于他们最擅长的事情：构建可靠、可维护的软件系统。
在我们能够更好地定义和预测AI编程助手的能力之前，它们仍将是强大但不靠谱的工具——在特定情况下有用，但在部署前需要仔细考虑。挑战不仅在于让这些工具更强大，还在于让它们的能力更可预测。
