工具笔记
让 AI 给 Node 命名脚本写第一批回归测试
先把可验证的规则从命令行入口拆出来。
资料核验2026.11.12 · Node.js · 小型服务与命令行工具
一个整理文件名的小脚本只有几十行，测试框架搭得比脚本还复杂，维护成本容易倒挂。Node 自带的测试运行器就能覆盖第一批规则。
让助手从这一步开始
把三个文件名和期望结果给 Codex，要求先把命名逻辑从读目录和改名操作拆出来，再用 node:test 写一组行为断言。命令行入口仍要保留一条能从外部运行的检查。
把终端输入和命名规则分开
把命名规则提成接收字符串、返回新名字的函数。测试直接传入空格、中文和已经规范的名字，用严格断言比对结果。命令行入口只读取参数并调用函数。用 node --test 跑测试，哪一条规则出错就从名字里看出来。
再留一条入口验收，传入非法参数，检查它会失败并给出可读提示。这样能防住函数测试全绿、终端用户却得不到错误的情况。
真的要改磁盘时，用临时目录放测试数据，别拿项目里的真实素材当夹具。
把问题变成可重跑的样例
固定三条样例 Q4 report.txt、中文计划.txt、ready.txt。先由你写下目标名字，再让助手实现转换。额外给脚本一个不支持的命令参数，用子进程捕获退出码。期望值不要从被测试的函数重新计算。
核对这几项输出
- 含空格文件名被规范化。
- 合法中文保留。
- 已规范名字再次处理不变。非法参数从子进程观察为非零退出，且真实文件没有被改动。
怎么判断改动能不能收
检查测试是否复述了实现，例如把同一条替换正则放进预期值。固定样例的期望应该由产品规则独立给出。若需要测试真实改名，另建临时目录，避免把家目录文件当成夹具。
将换行、重复空格或扩展名等新规则按产品需求逐条加样本。让助手只抽取确实可独立验证的逻辑，避免为了测试把一个简单脚本拆成许多模块。若命名会与现有文件碰撞，还需单独定义冲突处理。
