去岁，吾辈始用AI编程之器，众皆以为代码之成速矣。然岁终，吾得一异象：编代码之时虽减，而Code Review之时反增。曩者，审一PR，略观其理，提二疑即可毕。今每改一行，必反复审之：此段乃AI所撰抑人为？边界之理备乎？有无隐匿之性能之患？审至末，较吾自为之犹劳。

一、AI成代码速，然审之缓

今年初，吾承团队之核心项目。同僚数人皆用Cursor与Copilot，产出实高。然轮吾审之，总觉非宜。

举一例，有同僚呈一功能之模，代码运行无碍，然吾逐行观之，见一组件中悬三useEffect，其中二者功能重叠。作者言其未察，乃AI自动补全所致。此类之题，已成常事：AI所生之代码，虽能运行，然结构乱杂、逻辑重沓、缺边界之审。

昔人工所撰之码，犹可察其心路。今AI所成之码，若杂烩一锅，看似包罗万象，然实令人不快。审阅之际，非惟察其理之当否，亦须助作者删冗余、补阙漏、理结构。如是者，光阴悄然已倍。

二、数种人工智能之码，其弊同此

吾尝总括数端，乃审阅之际，常睹之AI之迹也。

1. 逻辑无谬，边界无碍

人工智能善通主脉，然空指、超时、并流之患，非其所能自解。譬如查询之口，AI为之则云data.list.map(...)然不能辨之data空耶？审阅时须为之补之。data?.list?.map或。if (!data) return null。

2. 过度设计，简问题而繁之

时，AI或能化简事为繁。譬如增防抖，则撰一整之自定义Hook，内用useRef、useCallback、useEffect，洋洋洒洒四五十行。然实一debounce函数足矣。审此码，须先明其理，再辨其是否过矣。

3. 注释与命名似机译。

AI所生变量名，常为data、items、config，义不明。函数注释或阙，或为“取数据”之虚言。审时宜助更名，补注，否则后辈难解。

三、吾之策略：何以使审阅不至苦痛

历半载有余，吾悟数法，尚可应验：

• 使AI先审AI：献PR之前，命作者复以AI（易一模型）审其码，依其议改之。
• 别异而待之：工具体、单元测、文注可委诸AI；核业逻辑宜手书或深改。
• 立微规：如“useEffect必具清理函”、“API唤必载loading与error状”。AI未必尽遵，然审时可速照之。

此法不能绝患，然至少可缩审时于可受之域。

四、反思

吾今之于AI编程，心有矛盾。一则，诚能省吾繁复之劳；二则，复将重负移于审阅之途。曩者，一人撰码，众共察之；今，一人撰AI之码，复有他者替其察漏。

此非AI之咎，亦非工具之愆，实乃吾辈未谙与AI协作者也。或未来有更善之审阅之序，或AI能自审其漏。然就今而言，AI未使吾减加班，惟使吾加班之务，自“撰”变为“审”耳。。

五、终焉

若汝亦历此感，点赞以示同慨，使吾知非独吾一人。诸君于评论区论之：汝之团队，有无因AI之码而审阅迟缓者？