通义灵码能一键生成单元测试，但默认产出的用例常缺边界场景：正常路径覆盖了，空值、极值、异常分支没照顾到。会点名边界用例的人，才能把 AI 生成的单测用出质量。这篇讲生成入口、边界补充、断言检查与跑通修整的完整流程。单测是接手 AI 代码最可靠的安全网，值得花时间做厚。
单测生成的入口与指令
在 IDE 中选中目标函数，通过通义灵码的生成单测能力发起，具体入口以当前版本界面为准。指令里写明要求：使用项目现有测试框架、覆盖正常路径与异常路径、每个分支至少一个用例。不给指令时它按默认习惯生成，给指令后产出结构明显更完整。生成前确认测试目录与命名规范，让它按项目惯例放置文件。第一次生成后先看文件结构对不对，测试类放错目录会让后续维护一团乱，不对就纠正后再继续。
边界用例要自己点名
AI 不知道你的业务边界在哪，点名才有效：数值参数要求它补零、负数、极大值、临界值；字符串要求补空串、超长串、特殊字符；集合要求补空集合、单元素、海量元素；时间类要求补闰年、月末、时区。业务规则里的边界（比如满减门槛正好等于额度）必须人工指出，这类用例最值钱也最容易漏。也可以把业务规则文档片段直接贴给它，让它从规则里自己提炼边界，提炼结果再人工补漏。
断言质量的检查要点
生成后重点看断言：有没有只跑不断言的假测试，调用了函数却没验证结果；断言值是不是 AI 自己编的，要与函数的真实语义对照；异常路径有没有用断言捕获预期异常，而不是让测试直接崩掉。浮点比较要用近似断言，字符串比较注意编码与空白，这些细节 AI 常漏，逐项过一遍。断言写错的测试比没有测试更危险，绿灯是假的，隐患还在。
让测试覆盖异常分支
明确要求它为每个抛出异常的分支生成用例：外部依赖调用失败、参数非法、状态不允许时的行为。依赖外部的部分让它用打桩或模拟对象隔离，确保测试只验证当前单元。数据库、网络相关代码，让它生成接口抽象层的模拟，具体写法按项目使用的测试工具约定，以官方文档为准。模拟对象的返回值要与真实依赖的行为一致，否则测试过了上线照样出事。
生成后跑通与修整
生成完立刻运行：跑不过的逐个看原因，是断言错、模拟缺失还是环境问题；全部通过后做一次变异抽查，故意改坏一处逻辑，看测试能不能抓住，抓不住说明断言强度不够。变异抽查不用做全套，每次挑两三个核心函数做即可，成本可控收益明显。修整好的测试随代码一起提交评审，AI 生成的部分在评审时说明，方便同事复核重点。测试文件同样要纳入版本管理，改动有迹可循。
AI 生成的单测覆盖率够用吗
- 生成的测试很多，能全盘接受吗？：抽查关键路径的用例质量后再接受，重复或无意义的用例删除，测试数量不等于质量；同一边界出现三四个相似用例的，合并成参数化测试更好维护。
- 历史代码没有测试，适合让 AI 批量补吗？：核心模块优先，边缘模块按改动频率排期，批量生成后统一跑一轮，比逐个补效率高，失败集中的模块单独排查，多半是环境或依赖问题。
- 需求变了单测要重写吗？：改动函数让灵码重新生成或增量补充，旧用例里语义未变的部分保留，评审时确认即可；重生成前把仍然有效的边界点列给它，避免新版本把覆盖丢掉。
