用 AI 写测试与文档：从提示词到 CI 的进阶实践
AI 写测试和文档，真正的难点不是“让模型生成一段代码”，而是让输出符合现有架构、测试策略和团队规范。更可靠的做法是把 AI 当作代码库中的协作者：先提供可验证的上下文，再要求它生成小范围变更，最后用测试、静态检查和人工审查闭环。
先建立可复用的上下文
不要直接输入“给这个函数写测试”。先让 AI 读取目标文件、相关类型定义、错误处理方式，以及已有测试目录中的两三个代表性案例。提示词应明确技术栈、测试框架、覆盖目标和禁止事项。例如：要求使用 Jest，不修改生产代码，覆盖成功、空输入、边界值、依赖异常和重复调用五类场景，并遵循现有的 mock 命名规则。
对于大型仓库，可以先让模型输出“依赖关系摘要”和“测试计划”，确认计划后再生成代码。这样能减少模型误解接口、虚构数据库字段或重复测试的情况。把稳定规则写入仓库级说明文件，例如测试命令、目录约定、禁止使用的 mock 方式和文档语气，后续调用时就不必反复解释。
让 AI 生成高价值测试，而非堆覆盖率
- 从行为出发：要求测试验证公开行为和业务不变量，而不是验证私有实现细节。这样重构内部代码时，测试不会大量失效。
- 补齐边界：明确要求检查空数组、极大数值、时区、重复请求、超时、部分字段缺失和权限失败等容易遗漏的输入。
- 区分测试层级：让 AI 分别建议单元测试、集成测试和端到端测试，避免把所有依赖都 mock 掉，导致测试看似通过却没有真实保护作用。
- 加入性质测试：对排序、序列化、金额计算和解析器，可要求生成 property-based testing 思路，例如“序列化后再反序列化应保持等价”。
生成后不要只运行一次测试。先执行格式化、类型检查和目标测试，再运行完整测试套件。若条件允许，使用 mutation testing 检查测试是否真的能捕获逻辑变化。可以把失败日志连同相关代码再次交给 AI，并要求它先解释失败原因，再提出最小修复，避免模型盲目修改断言。
用 AI 补全文档并保持长期准确
文档生成应绑定代码事实。让 AI 根据函数签名、配置项、错误类型和真实调用示例编写 API 文档，同时明确要求：不猜测未出现的行为；对不确定内容标记为“待确认”；列出输入约束、返回值、异常和权限要求。对于 README，可要求输出快速开始、环境变量、常见错误和升级注意事项，而不是泛泛介绍产品。
更进一步，可以让 CI 定期检查文档漂移：比较公开接口变更、配置字段和文档中的示例，发现不一致时创建待审查任务。AI 负责提出差异摘要和文档补丁，人类维护者负责确认语义。这样比每次发布前临时让模型“重新写一遍文档”更稳定。
低成本接入 Claude 与 GPT 工作流
如果频繁使用 Claude Code、Codex 或 OpenAI SDK，模型调用成本会迅速累积。59API 提供兼容 Claude 和 OpenAI SDK 的 API 中转服务，接口基地址为 https://api.59api.com，可按量使用 Claude Opus、Sonnet、Haiku、Fable 及 GPT 模型。它采用原生官方质量模型，不做低质降级，适合把高难度代码审查交给更强模型，把批量注释、测试初稿等任务交给更经济的模型。
实践中可将 API 密钥放入环境变量，并在项目脚本中区分模型用途：架构分析使用高能力模型，批量生成测试和文档使用低成本模型；提交前再让另一模型进行独立审查。这样既能控制预算，也能降低单一模型遗漏问题的风险。开发者可注册 59API 开始按量调用，并通过推荐返利进一步降低长期使用成本。
一套可落地的审查清单
- 测试是否验证业务行为，而非复制实现细节。
- 是否覆盖异常、边界、并发和外部依赖失败。
- 文档中的示例是否能实际运行，配置名是否与代码一致。
- 是否执行格式化、类型检查、完整测试和安全扫描。
- AI 提交的每个修改是否足够小，便于回滚和人工审查。
把 AI 放进“计划—生成—执行—审查—持续检查”的流程，而不是只当作代码补全工具，才能同时提升测试覆盖质量、文档准确性和开发速度。