接手一套没文档、没注释的旧代码，用通义灵码这类 AI 编程助手能明显压缩读懂它的时间：选中函数让它解释、给关键段落补注释、顺着调用链梳理逻辑，把过去翻半天的活压缩到几十分钟。这篇讲具体的问法与用法，以及读代码时的上下文准备。
让灵码解释函数的三种问法
在 IDE 里选中目标函数，用三种粒度提问：一句话版，这个函数的作用是什么；流程版，逐步说明它的执行逻辑；背景版，解释这段代码解决了什么业务问题、为什么这么写。读陌生模块先用一句话版扫一遍全貌，锁定关键函数再用流程版细读，全部用流程版反而低效。遇到看不懂的缩写变量，直接点名让它推断命名含义，推断错了也能给个排查起点。提问时把相关类型定义或配置一并选进去，解释会更准。
给关键段落补注释
让通义灵码为核心函数生成注释，重点补三类信息：函数职责、参数含义与取值范围、副作用（改了哪些外部状态）。生成后逐条核对，AI 偶尔会望文生义，注释错比没注释更害人。确认无误的注释入库提交，团队其他人接手时受益。注释风格与项目现有规范保持一致，中文项目用中文注释，避免一个仓库两种风格。顺手让它检查有没有与代码行为矛盾的旧注释，过时的内容一并清理。
梳理调用链与依赖关系
读代码最难的是建立全局感。让灵码分析某个入口函数的调用链：谁调用了它、它又调用了谁、数据从哪里进来到哪里出去。对于分层架构的项目，可以问业务逻辑分散在哪几层、改一个字段要动哪些文件。把它的回答当作地图，再回到代码里实地走一遍，地图指路与实地验证交替进行，全局感建立得最快。让它用缩进列表表达调用层级，比长段落描述直观得多。
读代码前的上下文准备
喂给 AI 的上下文质量决定解释质量。打开相关文件再提问，让它看到类型定义与常量；项目有 README、接口文档的，先让它读过再问业务问题；报错相关的代码，把完整报错信息与调用栈一起贴上。上下文不足时它只能靠猜，解释看似流畅但可能偏离实际，这是旧代码场景最常见的坑。旧项目常见的全局变量与魔法数字，先让它列一份清单，读懂这些散落的暗号，后面顺得多。
解释结果的核验习惯
AI 的解释要抽查核验：挑一两个它给出的结论，对照代码逻辑手工验证；让它在解释里指出具体行号，行号对不上内容就可疑；关键逻辑的解释，可以让它换一种方式再讲一遍，两次一致的可信度更高。核验成本不高，却能拦住似是而非的误导，长期收益很大。两次解释不一致的地方把两版都存下来，回到代码逐行对照，这段往往就是最复杂的部分。
通义灵码解释长函数会漏内容吗
- 旧代码里全是拼音缩写，能解释吗？：可以，把缩写相关的定义与使用处一并选中，让它根据上下文推断含义，推断结果人工确认后可让它补一份缩写对照注释，放在文件头部，新人接手第一眼就能看到。
- 解释完直接照它说的改安全吗？：解释用于理解，改动仍要自己确认逻辑，重要修改补好单测再动，不要跳过验证直接改；改前把相关调用处都过一遍，心里有地图再动手。
- 整项目太大，先读哪部分？：让灵码先分析目录结构与入口文件，给出模块划分的解读，从被依赖最多的核心模块读起，优先级由它协助判断，再按依赖关系排阅读顺序。
