使用人工智能编码助手将应用程序从一种编程语言迁移到另一种编程语言并不像看起来那么容易。这里有三个外卖。
如果说人工智能驱动的代码开发工具有一个通用的体验，那就是它们感觉像魔术，直到它们不神奇。
有那么一瞬间，您正在观看人工智能代理啜饮您的代码库，并对其架构和设计选择进行非常清晰的分析。接下来，它会用“CoreCoreCoreCore”向控制台发送垃圾邮件，直到回滚缓冲区填满，并且您的令牌用完。
随着人工智能驱动的编码和开发工具的进步，我们已经更清楚地了解它们做得好、做得不好，在某些情况下，根本不应该做。从理论上讲，他们通过做那种繁琐或不堪重负的工作来赋予开发人员权力：生成测试、重构、为文档创建示例等。在实践中，这种“赋权”往往要付出代价。人工智慧在前面讓事情變得更容易，只是讓事情在以後變得更難。
我考虑过的一个黄金梦场景是使用人工智能工具将代码从一种语言移植到另一种语言。如果我旋转了一个Python项目，然后决定将其迁移到Rust，人工智能代理会更快地让我坐在驾驶座上吗？或者它至少能和我一起骑猎枪吗？
这样的问题值得亲身回答——是的，即使我最终烧伤了手指。所以，当我尝试使用Claude Code将我的一个Python项目移植到Rust时，发生了以下情况。
项目设置以及我为什么选择Rust
我决定尝试移植我编写的基于Python的博客系统，这是一个生成静态HTML并提供类似WordPress的界面的服务器端应用程序。我选择它的部分原因是它的功能相对较少：每个博客的模板系统、类别和标签，以及一个界面，允许您使用富文本编辑器或通过明文Markdown以HTML格式撰写帖子。
我确保所有功能——模板系统、ORM、网络框架——在Rust生态系统中都有一个或多个相似之处。该项目还包括一些JavaScript前端代码，因此我有可能用它来测试该工具处理混合代码库的情况。
我选择Rust作为移植目标，主要是因为Rust的正确性和安全性保证是在编译时，而不是在运行时。我推理人工智能应该从编译器的有用反馈中受益，这将使移植过程更加富有成效。（希望是永恒的，对吗？）
对于人工智能，我最初选择了Claude Sonnet 4.5，然后当旧版本突然停产时，我不得不升级到Claude Sonnet 4.6。我还使用了谷歌自己的反重力IDE，我之前已经评论过。
第一个指令
我复制了我的Python代码库目录，在那里打开了Antigravity，然后从一个简单的指令开始：
此目录包含一个Python项目，一个博客系统。检查代码，并制定一个计划，如何将该项目迁移到Rust，使用原生Rust库，但保持相同的功能。
在咀嚼了代码后，Claude推荐了以下组件作为“过渡到现代、高性能的Rust堆栈”计划的一部分：
网络层的Axum。
用于数据库交互的SeaORM。
用于模板的Tera。
Tokio用于异步任务处理（取代Python的多处理）。
Claude在为Python库找到合适的替代品或将操作从一种语言映射到另一种语言方面没有任何明显的困难——例如使用tokio进行异步来取代Python多处理。我怀疑这部分相对容易的部分原因是我的原始程序的设计，它不依赖于动态导入等棘手的Python功能。克劳德通过分析和重新实施程序行为而不是单个接口或功能来推进，这也有助于他。（这种方法也有一些局限性，我将在下面讨论。）
我查看了生成的计划，并注意到它没有为新初始化的数据库创建任何占位符数据——样本用户、包含样本帖子的博客等。Claude添加了這個，我透過重新啟動程式和檢查建立的資料庫，確認它有效。到目前为止，很好。
少了几块
下一阶段涉及发现克劳德没有做多少事情。尽管发现并构建了我的应用程序的核心页面渲染逻辑，但它没有创建任何面向用户的基础设施——用于登录、编辑和管理帖子的管理面板。诚然，我的指示没有说那个界面。我应该责怪克劳德不够勤奋，还是责怪自己在最初的指示中没有明确？无论哪种方式，我都指出了遗漏，并得到了做这项工作的计划：
我现在正在通过分析原始的Bottle模板并计划将其迁移到Tera，包括登录屏幕和主仪表板，来解决缺失的管理员用户界面。
注意：Bottle是我用于Python项目的网络框架。这形成了一个自己的考验：克劳德如何应对从鲜为人知的图书馆迁移？事实证明，这本身并不是一个重大问题，但潜伏在其他地方的更大问题。
正是在这一点上，我和克劳德的大部分来往才开始。对于已经使用人工智能工具的开发人员来说，这个周期将很熟悉：提示—>生成—>测试—>重新提示循环。基本上，我会让Claude实现一些缺失的功能（在这种情况下，是管理员UI的每个元素），启动程序为自己测试，遇到各种错误或遗漏，并让Claude修复它们。
我在管理员用户界面中发现的第一个问题是网络模板未捕获的运行时错误，Rust的编译时检查没有解决这个问题。然后，管理面板的登录页面出现空白。然后，在登录页面工作后，它把我带到了一个占位符页面，上面写着“登录逻辑尚未实现”。然后，接受用户名和密码的逻辑被证明是有缺陷的。以此等，通过每个原始应用程序组件。
重大和轻微故障
在某些方面，使用Claude迁移代码反映了我之前在没有人工智能工具的情况下重写或迁移程序的经验。一切都在突即合，看似简单的事情却意外地变得困难。偶尔会发生相反的情况：一些我认为会具有挑战性的事情很快就解决了；一个惊喜。
然而，其中一个主要区别——任何使用过人工智能编码工具的人都会熟悉——是Claude有时会出故障，需要重大干预才能回到正轨。有一次，当我提示Claude继续为每个博客实施管理页面时，它出现了故障，并开始将CoreCoreCoreCoreCore...打印到控制台。我最終有數百行，Core 也開始在各種回覆的末尾隨機顯示：
实施博客详细信息和帖子列表CoreCore我已经实施了博客详细信息和帖子管理功能，修复了类型不匹配，并更新了项目工件。我现在正在通过捕获完整的货物检查输出来深入研究剩余的编译错误，以确保系统已准备就绪。CoreCoreCoreCore
然后，我开始收到警告，提示模型的生成超出了最大输出令牌限制。第二天我重新启动会话后，问题就解决了，但在那之后，我盯着所有输出，以找到类似的奇怪故障。
我注意到的另一件事是，克劳德会从未经测试的关于其环境的假设开始，只有在踬踬脚趾后才会纠正它们，然后并不总是坚持不懈。例如，它倾向于在bash语法中发出shell命令，出错，意识到它正在使用PowerShell，然后才发出适当的命令。
我注意到，这是人工智能代码工具的常见模式：它们往往只做你告诉他们的计划，而且很容易忘记一些需要绘制的细节。你越坚持地为模型定义事物，结果就越一致。（请注意，更一致的只是：并不总是或完全一致的。）
最后，手工检查生成的代码揭示了Claude忽略原始代码意图的许多方式。例如，在我最初的Python程序中，Web UI的所有路由都有一个登录验证装饰器。如果您没有登录，您将被退回到登录页面。Claude几乎完全未能在生成的代码中遵守此模式。管理员用户界面上的几乎所有路线——包括那些执行破坏性操作的路线——都完全不受未经授权的使用保护。
此外，当这些路由确实有验证时，它以插入路由函数顶部的模板代码的形式出现，而不是函数调用、装饰器或宏等模块化的东西。我不知道Claude是否不认识原始的Python装饰器模式，或者对如何有效地将其移植到Rust没有好主意。不管怎样，克劳德甚至没有提到遗漏；我不得不自己艰难地去发现它。
三个外卖
在与Claude推拉了几天后，我将大量原始应用程序的功能迁移到Rust，然后决定暂停并盘点。我想出了三个主要的外卖。
1.了解来源和目标
使用像Claude这样的工具在语言之间迁移并不意味着你可以同时不知道源语言和目标语言。如果您不精通您从或迁移到的语言，您可以要求代理澄清事情并获得一些帮助。但这不能替代能够识别生成的代码何时存在问题。如果你不知道你不知道什么，Claude不会对你有什么帮助。
我在Python方面的经验比在Rust方面更有经验，但我有足够的Rust经验来a）知道仅仅因为Rust代码编译并不能使其没有问题，b）识别代码中缺失的逻辑——例如API路由中缺乏安全检查。我的收获是，在语言之间移植的許多問題不會是大的、明顯的，而是更微妙的問題，需要很好地了解這兩個域。自动化可能会增加体验，但它不能取代它。
2.期望迭代
正如我之前提到的，你的指示越明确和越持久，你就越有可能得到类似于你意图的东西。也就是说，你不太可能在第一次、第二次、第三次甚至第四次尝试时得到你想要的东西——即使是你程序的任何一个方面，更不用说整个事情了。读心，更不用说准确了，还有很远的路要走。（谢天谢地。）
为了得到你想要的东西，一定的来回走动似乎是不可避免的，特别是如果你用另一种语言重新实施一个项目。好处是，你被迫面对每组变化，并确保它们发挥作用。缺点是这个过程可能会让人筋疲力尽，而且不像自己进行迭代更改那样。当你进行自己的更改时，是你与电脑的对比。当代理为您进行更改时，是您与代理与计算机。计算机本身的决定性被代理的不确定性所取代。
3.对结果承担全部责任
我最后的收获是准备好对项目中生成的每一行代码负责。你不能仅仅因为代码运行就决定没关系。就我而言，Claude可能是生成代码的代理，但我在那里对它说好，并在每一步都签署决定。作为开发人员，您仍然有责任——而不仅仅是确保一切正常。结果如何很好地利用目标语言的隐喻、生态系统和成语很重要。
有些事情只有有专业知识的开发人员才能带来。如果您对正在使用的技术感到不舒服，请先考虑学习景观，然后再破解Claude提示。
