Python 脚本转 JS，用 AI 逐段核对语义生成双语对照表

一句话结论

把 Python 脚本转成 JS，别让 AI 直接重写：先按函数逐段做语义对照，人只负责裁决差异，拿着双语对照表再动手改。

这篇解决什么问题

上个月我要把一个跑了两年多的订单清洗脚本从 Python 挪到 Node 服务里，一共四百来行，逻辑不复杂，坑全在细节。

初版我直接让 AI「翻译成 JS」，看着像模像样，跑起来日期少了一天，排序结果也跟原来对不上。

适用：脚本里有真实业务逻辑、改错要付代价的迁移场景。不适用：几十行的一次性小工具，重写比迁移快。

开始前要准备什么

• DeepSeek 网页版，有免费额度，长脚本够用
• Claude，遇到语义争议时追问几轮更稳
• 原始 .py 文件，先在本地跑通一次
• 一份基准输出，存成 JSON 备用
• Node.js 18 以上，能跑对照脚本
• 时间：中等脚本通常 1~2 小时

具体怎么做

第 1 步 · 先让它读懂，不许写代码

初版我就栽在这一步，上来就要代码，AI 给得特别顺，问题全埋在后头。

这次反过来，先只让它拆结构、标风险，代码一行都不要。

你接下来是我的代码迁移搭档。我要把一个 Python 脚本改写成 JavaScript（Node.js 18，不引入第三方库）。现在先不要写任何代码。
请你做四件事：
1. 按函数或顶层代码块编号，一句话说明它负责什么，输出成列表；
2. 标出你判断最容易在迁移中走样的地方，重点看这几类：整数除法与取整、浮点精度、字符串编码、日期与时区、字典键顺序、排序稳定性、异常捕获范围、空值与 None 的处理；
3. 指出脚本里哪些逻辑依赖了 Python 特有的写法，比如推导式里的作用域、可变默认参数、is 比较；
4. 告诉我为了做语义核对，还需要我补充什么材料：输入样例、边界值、依赖库版本。
下面是我要迁移的脚本全文，分隔线之间的内容就是原始代码：
=== 脚本开始 ===
【把你的 .py 文件全文粘贴在这里】
=== 脚本结束 ===

预期产出：一份函数清单加风险点标注，通常十分钟以内能拿到。

第 2 步 · 按函数切块，逐段对照

一次贴四百行，AI 对中间几个函数的描述会明显变粗，我是分三批喂的。

每批只处理一到两个函数，描述写得越具体，后面挑错越省力。

现在只处理我上一步清单里的第 N 个函数，函数名是 foo。
请输出两列对照：
左列写它现在做的事，用自然语言描述，不要贴代码；
右列写等价的 JavaScript 写法，凡是语义可能有差别的地方，用一句话注明差异。
要求：
– 左列统一按「输入什么、做了什么判断、输出什么」的结构写；
– 如果这个函数依赖外部状态或全局变量，单独列出来；
– 不确定的地方直接写不确定，不要猜；
– 只给这一个函数，不要输出整个文件。
原始函数代码：
=== 代码开始 ===
【粘贴这个函数的完整代码】
=== 代码结束 ===

预期产出：双语对照表的初稿，左边是 Python 原逻辑，右边是 JS 等价写法。

第 3 步 · 让它自己挑自己的错

同一条对话里它是顺着上一轮说的，天然偏向自证。换个身份重问一遍，命中率高不少。

我在这一步抓到了浮点格式化和空数组处理两处隐患，都是我没想到的。

现在请你扮演一个挑错的审查者，不要站在原作者一边。
针对上面这份对照表，逐行找出「Python 和 JS 结果可能不一样」的地方，按影响程度分两档：
A 档：会导致输出结果或数据不一致；
B 档：只影响写法习惯和可读性，结果一致。
每一项写清楚：出现在哪个函数、差异是什么、什么输入条件下才会暴露、用怎样一段最小代码能验证它。
如果没有发现 A 档问题，请明确写「A 档为空」，不要为了凑数硬找。

预期产出：一份差异清单，分两档，每条都带验证方法。

第 4 步 · 人工裁决，写回对照表

这一步 AI 帮不上忙。哪些差异可以接受、哪些必须和原来一模一样，只有业务方说了算。

我的判断标准很简单：这个字段下游有人看吗，有就一律等价，没有才允许「有意为之」。

下面是我逐条确认过的判定结果，请整理成一张 Markdown 表格。
列名固定为：函数 / 原逻辑（Python） / 迁移写法（JS） / 判定 / 备注。
规则：
– 「判定」只允许填三个值：等价、有意为之、待验证；
– 「备注」写一句话，说明为什么这么判定，或者给出验证方式；
– 表格按函数在文件中出现的顺序排列；
– 我标为「有意为之」的条目，在备注里写清改动理由，方便以后回查。
我确认的判定如下：
【粘贴你的逐条判定，例如：normalize_amount 从四舍五入改成保留两位、sort_rows 增加稳定排序、parse_date 从本地时区改为 UTC】
【再列几行化名示例：函数 calc_fee 判定等价；函数 trim_desc 判定有意为之，去掉了全角空格】

预期产出：定稿的双语对照表，一行一个函数，状态清晰可回查。

第 5 步 · 用基准输出做回归

对照表再漂亮，跑不出一样的数字也是白搭。这一步必须真跑一次。

我要验证迁移后的 JS 脚本输出是否和原 Python 一致，请给我一套对比方案。
第一部分：一个 Node.js 脚本，读取 old.json 和 new.json，按主键 id 对齐，逐条比较每个字段，输出「id / 字段名 / 旧值 / 新值」的差异列表，只打印有差异的条目。
第二部分：一段 Python 代码，把原脚本的输出导出成 old.json，字段顺序保持一致。
注意三点：浮点数按保留两位小数后比较；日期统一转成 ISO 格式再比；数组字段先按内容排序再比较，避免顺序干扰。

预期产出：新旧输出的差异列表，和对照表的最终版本一起归档。

实测记录

整个迁移我花了不到两个小时，其中大半时间在裁决，打字改代码反而是快的。

手工那条路我也试过：一行行读 Python 再写 JS，一个下午只过了一半，还漏了两处。AI 不一定更准，但它不会累，同一段可以反复追问。

返工集中在第一轮回归，三处不一致全是数值格式化，跟语义无关，但没做基准比对就发现不了。

最容易错的 3 个地方

1. 一次全贴进去，中间的函数会被忽略；按函数切块再问。
2. 把「能跑通」当成语义一致，边界值要靠基准输出比对。
3. 只留代码不留对照表，三个月后没人说得清哪行是故意改的。

可复用的东西

五段提示词拆开看就三件事：读懂、对照、裁决。前两段直接复用，把函数名和脚本换掉就行。

第三段那个「挑错的审查者」最值得留着，我后来做接口重写、配置迁移也拿它审过一遍，效果比让它正向输出好得多。

第五段的对比脚本建议固化成一个文件放进仓库，下次迁移省得重写。语义这关过了，语法问题都只是时间问题。你手上那份要迁移的脚本，最容易出岔子的是哪一块？

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接