从Python翻译Go代码谈起：AI辅助编程的现状与展望

最近，一位同学使用GPT-4o将一个约300行的Python程序转换成Golang，正确率达到了90%。这引发了一个有趣的讨论：如果是整个项目规模的代码转换，准确率会如何？作为被@的对象，我决定深入探讨这个话题，并借此机会分享一些关于AI辅助编程的见解。

AI代码转换的成功率取决于项目复杂度

AI代码转换的准确率很大程度上取决于项目的规模和复杂度：

1. 对于单文件、仅使用标准库的Python项目，准确率通常很高。只要给出适当的指令以防止模型出错，有经验的用户往往能一次性完成转换。

2. 当项目包含多个文件，且总代码量超出大模型的处理窗口时，难度会显著增加，往往需要人工干预。

3. 如果项目依赖大量第三方库，难度会进一步提升。这要求大模型在众多库中进行选择和匹配，可能需要更多的代码改写。在这种情况下，人工干预和迭代几乎是不可避免的。

## 实现100%AI生成代码的可能性

虽然看似困难，但实现100%由AI生成代码的项目是可能的，关键在于人工进行合理的任务拆解和指导。使用如Claude 3.5 Sonnet这样的先进模型，再配合像auto-coder.chat这样的工具，大部分项目都有可能实现全AI生成。

这并不意味着人工完全不参与，而是工作重心从编码转移到了代码审查（review）上。这种方式可能与传统开发流程有所不同，但实际上可以提高整体效率。

高效的Try/Revert策略

一个高效的工作流程是采用"try/revert"策略：

1. 将需求拆解成适合当前模型处理的粒度。

2. 通过/coding 质量让AI模型完成这个粒度的需求并提交代码（commit）。

3. 如果结果不理想，可以执行/revert 指令立即回滚。

4. 调整需求描述，重新尝试，直到满意为止。

这个过程看似繁琐，但实际上非常高效。关键在于用户能否熟练使用像auto-coder.chat 这样的工具。通常经过两周到一个月的训练，一个有悟性的开发者可以将拆解后的单次，实现一次成功率达到80%左右。这意味着，AI可以在几十秒内完成可能需要人工半小时甚至几小时的多文件修改任务。

AI辅助编程的实际应用

以我个人为例，现在已经能够在很大程度上依赖AI进行开发。比如，我可以在四小时内完成一个完整的前后端小程序开发，即使是第一次接触小程序开发的情况下。整个项目的代码都是由AI生成的，而且后端代码质量通常优于1-2万月薪水平的工程师所写的代码。

## AI模型的局限性

尽管如此，现阶段的AI模型仍有其局限性：

1. 需求拆解仍然需要人工完成。虽然有人尝试让AI自主拆解需求，但效果不佳，容易陷入死循环。

2. 即使是目前最优秀的编码模型（如Claude 3.5 Sonnet），在我看来也只能算是入门级别。其他模型可能连入门都算不上。

3. GPT-4系列虽然在生成小型脚本时表现不错，但在处理大型项目或进行代码迭代时，表现却差强人意。它们更适合生成独立的小脚本，而不是在现有大型项目基础上进行开发。

4. Claude 3.5 Sonnet的优势在于它能更好地理解开发者的意图，并与现有代码进行更好的整合。很重要的是，在前面的基础上，它还能生成非常规范的diff/editblock文本可以直接合并到项目中。

## AI时代的编程方式展望

AI很可能改变未来的编程方式。以下是两个无责任的推测：

1. 软件开发中的协作成本可能大幅降低。传统开发中，协作需要大量的管理，同时多人维护代码也需要不断重构以保持可维护性。在AI时代，这些问题可能会减少或消失。AI可以轻松处理复杂的代码结构（如回调地狱），而不会像人类开发者那样感到压力。

2. 开发团队的角色可能会发生变化。高级工程师可能会承担更多一线编码工作，而初级开发者则可能转向代码审查或编写单元测试，成为最后一道质量保障。

总的来说，AI辅助编程正在快速发展，并将深刻改变软件开发的方式。虽然还有许多挑战需要克服，但未来的编程可能会更加高效、灵活，并且更加依赖于人机协作。

=====分割线======

hmmm,上面的内容实际上是AI根据我的一篇初稿改写的。写文章和写代码是一样的，我把聊天记录放到了一个文件，然后通过下面的一句话让他改成了上面的内容。

这是我的操作：

下面是我的原文：

有位同学用GPT4o 把一个python程序转换成Golang，总共大概300行代码，然后写对了大约90%。然后大家就在说那整个项目的准确率会怎么样。于是有人就 at 我，请我回答下。

然后回答很长，我有点舍不得那些文字，所以干脆整理成一篇文章，让大家对AI辅助编程有一些更多的了解。

首先这个成功率还是要看项目的大小，

1. 如果你的项目比如就一个python文件，用的标准库 这种准确率就很高 尤其是你稍微给出点要求防止模型错误，基本上有经验能够一次过。

2. 如果你的项目有很多文件并且所有文件和新产生的文件超出了大模型窗口大小，那么难度会增长很多 很难没有人工干预了。

3. 如果你的项目还依赖大量库，那么难度又会增长很多，这意味着大模型要大量的选择匹配的库，包括做更多的改写。基本只能靠人工进行干预迭代。

但是确实有机会做到百分百AI生成，但是会需要人工做拆解做指导。很多人会对这个百分之百有疑问，觉得会很困难，实际上让AI百分百生成是不难的，可能和大家的直觉有违。

如果你用的是sonnet3.5 并且搭配 auto-coder.chat  那么实际上大部分项目都可以做到百分百AI生成。但是只是人工不写代码，但就像等能量守恒定于一样，人工有个工作会增大，就是review。

那你可能会有疑问了，如果需要大量review,是不是导致整体效率还是上不去？实际上不是的，try/revert的效率实际上很高，但是需要一定的培训。这里所谓的try/revert 是指，你人工将一个需求拆解成适合当前模型的粒度，然后让大模型帮你完成这个粒度的需求并进行commit，如果觉得不好，随时回滚/revert，然后再重新描述需求，直到满意。似乎看起来很低效，但这里主要就是看你能否熟练的使用类似 auto-coder.chat 操作AI了。 熟练和不熟练，差距很大。一般有点悟性的 经过两周到一个月的训练 需求拆解和拆解后需求一次成功率可以到80% 左右。这意味着，基本你说一个已经拆解好的需求，AI可以在几十秒的时间里帮你完成多个文件的修改，如果是人工的话，可能需要半个小时，甚至几个小时。

对于常规软件开发，比如我的话，现在已经可以完全 free 。举个简单的例子，我四个小时可以完成一个完整前后端小程序开发，而且是第一次接触小程序的时候情况下，整个项目百分百全部由AI生成的代码。后端代码质量会好于1-2万薪资的工程师。

有人就有疑问了，能不能让大模型自己拆解需求？实际上很多人试了，效果差强人意。现阶段需要人。通过agent拆解效率太低，很容易陷入死循环。比如 auto-coder.chat 唯一没有使用agent的地方就是coding部分，其他诸如代码阅读，项目解读等等都大量使用了包括COT之类的技术。

实际上，现在最好的编码模型 sonnet 3.5 在我看来只是个入门级别的编码模型。其他的模型连入门都不算。你可能会反问，那么GPT4系列呢？GPT4 系列我之前反复强调了，它适合生成一些脚本，如果是对老项目做迭代，你会发现它差的一塌糊涂，简直就是失智。所以很多人觉得GPT4系列效果挺好呀 代码生成，实际上都是给个小需求，用来写点小脚本，不太结合已有项目的，然后惊呼，效果好好呀。

在有大量文件做上下文的情况下，你的需求略微粗糙些，GPT4系列就完全get不到你在讲啥了。sonnet3.5 惊艳的地方是真的很像人，能get到你说啥，以及和老的代码怎么结合，最后应该怎么改，最最重要的是，它生成的diff/editblock 文本可以直接合并。

最后再强调下，GPT4系列对齐的结果是面向人的，你会发现他的代码，尤其是在生成很多代码，而且这些代码已经出现在你给他的代码里，他会偷懒，比如用一些缩略词，比如//如上述代码。也就是他实际上产生的代码是不完整的，是给人看的，导致无法实现自动化的合并，也难以产生真正项目化的代码。

最后有同学问，AI有没有可能改变未来的编码方式呢？就像现在有测试工程师，未来可能就有review 工程师。

答案是肯定的，下面是AI 时代编程的两个无责任推测：

1. 软件开发中协作带来的两个巨大成本会消失。协作需要大量的管理，这个成本高到可怕。其次是多人维护代码，需要代码具有可维护性，大量的重构时刻在发生。 在AI时代，这些可能会减少或者消失。比如 长文翻译 小程序，如果我自己写，我肯定要引入 async await，先做一通包装。但大模型写 回调 hell 一点压力都没有，改起来也一样，能耗也一样，如果是人，脑力会被干爆。

2. 现阶段，高阶工程师会变成一线码农，而初级码农则作为reviewer 或者 作为单元测试提供者，为最后一站质量背锅。