AI做工具,先写测试题

让 AI 做一个小工具时，很多人会直接说：“帮我做一个能记账的网页。”等第一版出来，才发现没有想清楚谁来用、在哪运行、哪些功能先不做，也没有办法判断它到底完成没有。

更稳的起点不是先写代码，而是先写测试题。测试题会反过来逼你把需求、边界和完成标准说清楚。

先把第一版缩到能验证

AI 编程很适合从小版本开始：先完成一个最小目标，运行一次，记录问题，再增加功能。

如果第一版同时包含登录、同步、报表、权限和多端适配，任何一个地方出错，都很难判断是需求没写清，还是实现出了问题。先砍掉可选功能，只留下一个可以被真实使用和检查的核心动作。

例如，第一版只做“新增一笔记录并能按月份查看”，比一开始要求完整的家庭财务系统更容易验收。

一张需求卡写四块

开工前，先在一张卡片上写四块内容：

1. 用户与场景
   谁在什么设备上使用，想解决哪一个具体问题；
2. 核心功能
   第一版必须完成的动作，最多列三项；
3. 暂不做的边界
   哪些功能明确放到后面，哪些情况不在本次范围内；
4. 运行环境
   程序在哪里运行，需要什么版本、依赖和启动方式。

这四块能防止“功能越写越多”，也能让 AI 在生成方案前知道真实约束。工具怎么选，不应该先于使用场景和交付方式。

把测试题写在开工前

围绕第一版功能，至少写四类测试题：

1. 正常场景
   输入完整、操作顺利时，应该得到什么结果；
2. 边界场景
   空值、极端长度、重复提交或超出范围时，应该怎样处理；
3. 错误场景
   文件缺失、格式不对或运行环境不满足时，应该提示什么；
4. 通过条件
   什么现象出现，才算这项功能完成。

测试题不需要一开始就很专业，但必须能让另一个人照着操作。它们会帮助 AI 和人使用同一条完成标准，而不是各自凭感觉说“差不多了”。

看到问题，回到需求节点

如果测试发现问题，不要只在代码表面补一行。先问它属于哪一块：是用户场景漏了，是功能边界太宽，是环境没准备好，还是通过条件写得太模糊？

定位到需求节点后，再让 AI 做局部修改，并同步更新测试题。这样需求、代码和验收会一起迭代，下一版也不容易越改越乱。

一段可以直接复制的开工说明

我要解决的问题：……

使用者和运行环境：……

第一版只做：……；暂不做：……

请先列出正常、边界、错误三类测试题和通过条件，再给出最小实现方案；每次只改相关部分，修改后按测试题复测。

把测试题提前写出来，不会让 AI 编程变慢，反而能让每一轮修改都有明确的下一步。

想从需求拆解、思维导图到测试用例，系统练习如何让 AI 做出可运行的小工具，课程完整介绍与学习入口，请点击文末“阅读原文”。