AI 跨界开发：从完成任务到理解代码

在上一篇文章里，我聊了怎么与 AI 协作、检查代码，以及在任务结束后留住自己的理解。那些做法有一个前提：我对正在做的事情比较熟，知道哪些写法可能有问题，也大致清楚该怎么验证。但现在，AI 让我们能接手的工作越来越多。前端开发者也可以去改后台服务、客户端、C++ SDK，或者做数据分析。需求和上下文说清楚以后，AI 往往能继续把代码写出来，可我们未必有足够经验判断它写得合不合适。

　　在熟悉的前端项目里，读代码时我会发现一些问题：状态放错了地方，这层抽象没有必要，另一个入口可能也需要修改。换成陌生语言和复杂工程，这些经验就不一定够用了。代码能运行，AI 的解释也看得懂，自己却仍然有不少地方拿不准。把自己没弄明白的代码交出去，我不能接受；可实际排期又很少允许我们先学完整个技术栈，再开始做需求。这篇文章想聊的，就是怎么在这个约束下把工作做好：

1. 围绕眼前的任务，先补哪些知识，才能看懂这次改动？
2. 缺少领域经验时，怎么判断方案和代码是否合适？
3. 怎样请专业同事帮忙 CR，并把这次学到的东西留下来？

一、跨界开发的难处

　　AI 让我们有机会做以前没做过的工作，但解释方案、维护代码和处理故障，还是需要相应的知识。语法和类型问题，编译器及检查工具能帮忙发现不少；编译通过了，运行条件和业务逻辑却未必正确。跨界时更麻烦的是，我们可能根本不知道某类问题需要留意，自然也不会要求 AI 检查。过去的前端经验能帮我判断职责、接口和状态管理是否合理，但其他语言怎样执行、资源怎么释放、目标项目有哪些特别约定，还需要另外了解。

　　比如有这样一项客户端需求：JavaScript 通过原生模块调用一个 C++ SDK，原本的同步初始化会阻塞主线程，现在希望改为后台执行，完成后再把结果通知 JavaScript。AI 可能为异步任务保存一个 C++ 上下文，并通过引用计数保证它在任务结束前不会被释放。单看这部分代码，似乎已经考虑了对象的生命周期，正常启动时也能拿到结果。但如果用户在初始化尚未结束时退出客户端，就还需要考虑另一种情况：JavaScript 运行环境已经销毁，后台任务却还没有完成。这时，即使 C++ 对象仍然存活，也不能继续访问已经失效的 JavaScript 环境。要判断这份修改是否合适，就得弄清任务在哪个线程完成、退出时怎样清理，以及环境销毁后如何处理尚未结束的任务和回调。给每行代码加上中文注释，并不一定能让我们意识到这些问题。

　　所以，看懂语句只是开始，还要知道它们在什么条件下运行。对于本次改动，我需要说清每部分代码为什么要改、怎样满足需求、依赖什么前提，失败后会怎样，又会影响哪些调用。关键地方拿不准，就继续读相关代码或查资料。这不要求把所有依赖源码都读一遍，也不意味着马上具备领域专家的水平，但至少应该知道自己为什么接受这份实现，以及还有哪些地方需要专业同事确认。

二、跨界开发，学习绕不过去

　　遇到陌生技术，先找教程学一遍是很自然的想法。问题是，学完语法以后，还有框架、构建流程和项目约定。如果全部放在开发之前，手头任务可能迟迟无法开始；完全不学，代码写出来又不知道怎么审。我更倾向于围绕当前任务补知识：先让 AI 帮忙梳理本次修改经过哪些模块、在哪里改变状态、用到了什么机制，再对着代码确认哪些地方自己不懂。这比一上来先列出一长串概念去学更容易安排时间，也更容易知道学到的东西能用在哪里。

　　这些知识解决的问题也不一样。语法和常见写法，让我们读懂代码在说什么；项目结构和构建流程，让我们知道该改哪里、怎样让修改生效；线程、生命周期等运行机制，则帮助我们判断代码实际会怎么执行。就像前面的回调，参数和返回值可能很容易读懂，但还要知道谁会调用它、在哪个线程调用，以及那时相关对象是否仍然有效。不必严格按这几个层次依次学习，读不下去时先分辨自己卡在哪里就行。只补语法，很可能仍然回答不了方案是否合理。

　　边开发边补知识也有先后顺序。如果一个机制直接决定方案能否成立，比如回调可能晚于宿主销毁，就应该在大量修改之前确认；局部写法和辅助工具，可以在阅读过程中逐步熟悉。AI 能帮忙解释概念、寻找线索，重要结论还是要对照项目代码、可靠资料或实际结果。看完以后，可以试着自己讲一遍执行过程，或者换一个条件，想想结果会不会变。讲不清、预测不了的地方，就是还要继续了解的内容。理解代码需要时间，我们能做的是把时间用在当前真正需要的知识上，减少无关学习和反复返工。

三、如何判断 AI 编写的代码是否合适

参考已有实现，也要知道它为什么适用

　　刚进入一个陌生项目，现成的规范和代码很有帮助。类似功能、诊断工具和历史记录，可能已经包含一些我们还没意识到的限制。让 AI 先读规范、找参考实现，可以减少不合项目习惯的写法，人也更容易对照着看。但找到相似代码以后，还需要确认它为什么适用。两个看起来相同的接口调用，可能运行在不同线程；两段相似的销毁逻辑，可能面对不同的宿主生命周期。沿用之前，让 AI 说明相关条件，自己再顺着调用关系核对，才能知道这次是否可以照着做。

　　代码之外的工程条件也得留意。比如，在使用预编译依赖的项目里，修改了本地源码，运行时不一定用得上。如果当前配置仍然链接预编译产物，编译成功也不能说明修改已经得到验证。这时需要查看构建配置、依赖选择和实际加载的产物，而不是继续盯着业务逻辑找原因。这个例子说明，跨界时除了学习代码怎么写，还得了解目标项目平时怎样开发和验证。项目提供的工具、说明和排障记录，正好能帮我们补上这些知识。

　　与此同时，已有的软件工程经验仍然能派上用场。职责划分是否清楚，依赖和状态是否合理，接口是否前后一致，新增复杂度是否值得，这些都可以帮助审查。SOLID 等原则也可以用来讨论设计，但没必要为了符合某个原则，要求 AI 增加没有实际用途的抽象。结构清楚的代码仍可能有生命周期问题，符合语言习惯的写法也可能违反项目约定。设计方面可以借助通用经验判断，涉及具体运行机制的地方，还得继续查清楚。

AI 的解释，还需要对照代码和结果

　　自己不熟悉的东西，很容易想让 AI 再讲详细一点。解释当然有帮助，但如果代码和解释都来自同一个错误假设，听起来再顺也发现不了问题。此时值得追问的是：它为什么认为这件事成立，我可以去哪里确认？接口是否保证线程安全，可以查当前版本的文档或声明；对象什么时候释放，可以追踪调用链和释放位置；某个时序是否可能发生，可以设计一个有针对性的实验。疑问具体以后，我们才更容易决定下一步查什么，也知道自己缺的是哪一块知识。

　　以前面的桥接场景为例，只验证正常初始化和成功回调，还没有检查退出过程。代码在独立测试里运行正常，也不意味着宿主销毁环境时会同样正常。验证时要看本次修改依赖哪些条件，再选择相关检查，不必把所有想到的测试都做一遍。但也不能因为代码在 mock、独立运行时或示例工程里跑通了，就认为真实项目也已经验证通过。哪些行为测过、在什么环境下测过、还有哪里暂时没有条件检查，都应该说得清楚。

　　测试预期本身也需要理解。如果“什么结果才算正确”正是自己不懂的部分，AI 写出一份通过的测试，并不能解决这个疑问。预期要从需求、项目契约、可靠资料或专业同事那里确认，再看实现是否符合。换模型评审可以帮助发现遗漏，但几个模型意见相同，也不能单独确认一项专业判断。决定正确性的地方，如果自己还解释不清，也没有可靠依据，就需要继续调查或求助。确实无法确认时，应当把问题和影响说明白，必要时重新讨论交付范围。

先理解自己的改动，再请专业同事 CR

　　专业同事的 Code Review 很重要。他们熟悉语言惯例、项目约束和常见问题，有些我们不知道该检查的地方，他们更容易发现。但这需要占用对方的时间，也不能假定随时有人帮忙从头看一遍。因此，在请求最终评审之前，自己的部分要先做好：读完差异，了解相关调用，弄清每处修改的目的，核对关键假设和验证结果。这样，对方才能集中检查专业方面的遗漏，不必先替作者理解整份实现。

　　理解代码以后，仍然可以有需要请教的问题。例如，已经查清某段回调和销毁逻辑的执行顺序，但不确定目标项目是否还有别的退出入口。这时就可以把自己的理解和依据交代清楚，请熟悉宿主的同事重点核对。评审材料也可以围绕这些问题组织：需求是什么，改了哪里，为什么选这个方案，已经验证了什么，还有哪一两处最拿不准。比起只留一句“麻烦帮忙看看”，这些信息能让对方更快进入具体问题，也减少重复查找背景的时间。

　　拿到评审意见后，先确认提到的情况是否适用于当前实现，再弄清原来的判断漏了什么、修改怎样处理这个问题，以及是否需要重新验证。只让 AI 照着改，自己仍然不理解，下次换个条件可能又会遇到相同困难。如果接任务时就知道有些专业判断需要帮助，也应该尽早沟通支持安排。暂时找不到人复核，就向相关人员说明缺少哪些依据、会影响什么，不能因为排期到了便当作已经确认。第一次跨界未必能省下很多时间，理解、验证和他人支持的投入都需要算进去。

四、沉淀跨界开发的经验

　　上一篇提过，我会用提交信息和 MR 说明简单变更，把复杂任务中有价值的 AI 对话与完整上下文归档到个人私有 Git 仓库。跨界任务里，探索过程尤其值得保留：当时不懂什么，排除了哪些猜测，查了什么资料才弄清一个机制，专业同事又提醒了什么。以后遇到相关问题，可以顺着记录重新理解当时的过程，也可以把有关材料提供给 AI。不过，原始对话里的早期猜测和最终结论需要分清，重新使用前还要核对它们是否适用于当前代码。

　　如果某些知识以后会经常用到，可以在完整归档之外，再整理一份方便查阅的笔记，写清概念、调用过程、验证办法和适用条件。记录时最好把文档写明的事实、项目里的约定和自己的推断区分开，避免以后把未确认的猜测记成事实。也不必每次任务都写长文，能帮助后续理解和维护就有价值。如果一个领域以后要长期负责，仅靠零散的排障记录还不够，需要把多次任务中反复遇到的问题整理出来，逐步补足基础。

　　自己是否有进步，可以看下一次遇到类似任务时有什么变化：能不能更早发现某个前提不成立，能不能看出方案中不合适的地方，知道先查什么资料或运行结果。对持续维护的机制，值得保留亲自实现和调试的机会；偶尔涉及的工作，也需要理解本次改动及其相关限制，只是未必马上展开整个领域的系统学习。完成过任务、留下了资料，都有用，但还需要看看哪些认识已经能由自己独立使用。

五、总结

　　AI 让我们能够参与更多陌生领域的工作，却没有免掉理解代码所需的投入。排期通常不允许先学完整个领域再开发，那就先围绕任务补知识，把影响方案的机制查清楚；借助项目已有的规范、实现和工具，再用代码与验证结果核对自己的判断。自己理解了本次改动，再带着具体问题请求专业 CR，也能让对方更容易帮到我们。

　　这份理解可以随着开发逐步建立，但在交付之前，该确认的部分仍然需要确认。任务结束后，把有价值的上下文留下，反复遇到的知识缺口继续补上。希望下一次再做类似工作时，自己能少一些拿不准的地方，也更清楚哪些问题还需要请教别人。