Longcat-2.5-preview 生成的一段函数，通常能跑通主路径，主路径之外能不能直接用，取决于空输入、极长输入、零值和非法类型这几类分支有没有被覆盖过。稳妥的做法是把它当草稿：单独存成文件，补四类用例，用断言跑一遍，失败落在哪一行就回看哪一段分支条件，再决定改动范围，而不是整段重写。适用场景是单个纯函数或可独立调用的工具函数；依赖数据库、网络请求、框架上下文的代码，需要先拆出可单独调用的部分再验。

判断：生成的函数可以先按草稿用，但不要直接接进主流程。操作方向是隔离到独立文件，补正常、空、边界、异常四类用例，用断言跑一次，按失败行回看分支条件，改完后重跑同一组用例对比前后结果。边界：涉及环境依赖的部分不在这一轮覆盖范围内，仍需单独确认；断言只说明给定输入下的行为，不代表所有输入都安全。

把生成的函数单独存成一个文件

先把生成结果里的函数复制到一个独立文件，作用是让验证过程和正式项目隔离：不用改主流程的导入，可以反复重跑，失败也不影响现有代码。目录可以先这样放：

verify/
  keywords.py       # 生成的函数，只保留必要依赖
  test_keywords.py  # 用例文件

函数文件里只留被验证的那段逻辑，去掉项目内的 config、logger、数据库连接。需要外部参数就显式写进函数签名，例如 max_len=64，不要从全局配置里读，否则用例输入和实际行为对不上。这一阶段先不要接进主流程，也不要让调用方指向这个文件。

def split_keywords(raw, max_len=64):
    parts = [p.strip() for p in raw.split(',')]
    result = []
    for p in parts:
        if not p:
            continue
        if len(p) > max_len:
            continue
        if p not in result:
            result.append(p)
    return result

这段函数保留了必要依赖，没有外部 import，适合直接跑用例。如果原生成代码里带了日志或缓存调用，先注释掉或改成参数传入，别让验证过程依赖运行环境。

补四类用例：正常、空、边界、异常

用例不用多，四类各一条起步，覆盖生成代码最容易漏掉的输入情形。每条都要写清输入值和期望结果：

• 正常：输入 'a, b ,a'，期望 ['a', 'b']，检查去空格、去重、保持顺序。
• 空：输入 ''，期望 []；再加一条 ' , , '，期望 []，检查全为空白片段时不产生空字符串元素。
• 边界：输入 'x' * 10000，期望 []，检查单个超长片段被过滤；输入 'a' 且 max_len=0，期望 []，检查零值参数不产生意外结果。
• 异常：输入 None，期望抛出 TypeError，检查非法类型不会被当成可迭代对象直接处理。

import pytest
from keywords import split_keywords

def test_normal():
    assert split_keywords('a, b ,a') == ['a', 'b']

def test_empty():
    assert split_keywords('') == []
    assert split_keywords(' , , ') == []

def test_boundary():
    assert split_keywords('x' * 10000, max_len=64) == []
    assert split_keywords('a', max_len=0) == []

def test_invalid_type():
    with pytest.raises(TypeError):
        split_keywords(None)

极长字符串用表达式生成，不要把一万个字符贴进用例文件。写期望结果时要写具体值，不要写“返回不为空”这类无法判断对错的断言。

用断言跑用例，看失败落在哪一行

在 verify 目录下执行 pytest -q，一次运行就能替代肉眼检查。断言统一写成“函数返回值 == 期望值”的形式，例如：

got = split_keywords('a, b ,a')
assert got == ['a', 'b'], f'normal got={got!r}'

失败时看两块信息：一是失败用例名，对应上面四类里的哪一类；二是 E 行里的 assert ... == ...，左边是函数实际返回值，右边是用例里写的期望值。如果 E 行显示 AttributeError 而不是断言不相等，说明函数在进入比较之前就报错了，多半是没做类型判断，比如对 None 直接调用 split。

需要单独打印中间变量时，可以在断言前加 print，用 pytest -s 让输出显示出来；更省事的做法是在断言消息里带上关键输入，写成 assert got == exp, f'raw={raw!r} got={got!r} exp={exp!r}'。这样不用反复加删 print。没有 pytest 时，用 try/except 包住调用并打印输入值，也能达到同样目的。

对失败用例回看生成代码的分支条件

用例失败不要立刻改断言，先按下面的步骤回到函数里定位：

1. 从失败用例取出具体输入值，比如 raw='a'、max_len=0，确认是哪一类输入触发。
2. 在函数里找到处理这类输入的语句，是 if 判断、continue 还是提前 return。
3. 核对条件表达式本身：len(p) > max_len 和 len(p) >= max_len 只差一个边界；if not p 是否能覆盖 '' 和纯空格片段；有没有对 raw 做字符串类型判断。
4. 确认返回值路径：是被 continue 跳过后落到末尾 return，还是中途 return 提前返回。
5. 记录这次改动对应的用例编号，避免改一处又影响别的用例。

常见情况有两类：一是漏判某种输入，比如没处理 None，导致抛出的异常类型和期望不一致；二是多做了一层处理，比如先去重再截断，导致超长片段把同名短片段也顶掉了。定位到具体分支后，只改这一段，不要顺手重写整个函数。

改完后重跑同一组用例并记录前后差异

改完立刻重跑原来的用例文件，不要只跑新增的那一条。按下面这张表记录，用例编号沿用第四小节里的对应关系：

关键在于看正常用例有没有从通过变成失败，这类回归比原来的失败更容易被忽略。仍然不通过的用例，标记为待人工处理，写清是哪条输入、期望什么、实际什么，不要为了让用例变绿而放宽断言或删掉用例；如果确认是期望写错了，也要单独记一行说明改了哪条用例和原因。验证到此只说明给定输入下的行为符合预期，是否可以接进主流程，还需要结合调用方的实际数据和使用场景再判断。