AI 写的代码能跑。问题在后面

有人能讲清这份代码吗

交接时该问的第一个问题。不是界面跑不跑得起来，而是还有没有人能说明白当初为什么这么做。

人写的代码，通常写的人手里握着答案。问一句为什么这里把异常吞掉了、为什么这个值是写死的，都能问出来。用 AI 快速产出的代码，这个位置往往是空的。如果只是把提示词的产物贴上去、跑通了就留下了，那连交付的人自己也讲不清。

所以第一轮检查不是代码审查，而是对话。这个功能应该做什么，哪些情况是故意不做的，眼下已知的问题有哪些。这里能问出来的答案越少，交接要花的时间就越长。

密钥就写在源码里

接手 AI 项目时最常撞上的事故。API 密钥、数据库口令、支付方的 secret，直接写在文件里。示例代码大多长这样，而「以后再挪到环境变量」这种拖延，往往就这么定型了。

危险不只在于仓库是否公开。这些值会跟着部署记录、备份，以及每个协作者的本地副本一路走。一旦泄露，从代码里删掉并不算完，密钥本身必须重新签发。对接手的人来说，这件事会落在第一周。

改是能改，但不知道能不能改

接过一个一行测试都没有的项目，每次修改都成了赌博。你能读懂代码、能改，却没有办法确认这次改动没弄坏别处。于是开发者只碰看起来安全的地方，不敢动的部分就搁着。时间一长，没人敢碰的区域越来越大。

这个毛病在 AI 辅助的代码里更常见，因为功能出得快，验证就容易往后推。交接当口把测试全部补齐并不现实，但涉及钱款流动和数据删除的路径，背后必须有最起码的校验。光是守住这两处，之后的修改就从赌博变回了普通工作。

同一份代码在你机器上跑不起来

接手第一天就会卡住的地方。把仓库拉下来一跑就报错：版本没有锁定、有些文件只存在于本地、混着只有某个账号才通得过的配置。

验证方法很简单。找一台干净的机器，拉下仓库，只按文档写的步骤走一遍。卡住的地方，就是文档缺的内容。交接之前和原开发者一起做一次，之后要花好几天的考古就在当场解决了。

先告诉我们你手上有什么

一个仓库地址就够，一个压缩包加一组登录信息也行。Weple 的代码检视从你拿到的原样开始，把两个问题分开看：今天能不能跑，往后能不能维护。像暴露的密钥这类需要立刻处理的，我们先告诉你；其余的按轻重缓急排好再交回。就算你自己也没理清接过来的是些什么，也没关系。把这份清单列出来，本身就是检视的一部分。