为什么你用 AI 做出的小工具,总是卡在最后 10%?

你可能已经感受到了：现在用 AI 写代码，真的没有以前那么难了。

你打开 Cursor，或者让 Claude Code / Codex 帮你干活，说一句“帮我做一个周报汇总工具”“帮我写一个客户反馈分析脚本”“帮我做一个网页表单”，AI 很快就能给你一堆代码。

有时候甚至十几分钟，就能跑出一个看起来像样的 demo。

但真正麻烦的地方，往往从这里才开始。

第一版能跑。第二天你真拿来用，发现表格格式一变就报错；字段多一个就识别错；数据为空时没有提示；复制到另一个电脑跑不起来；你让 AI 改一下，它又把原来能用的地方改坏了。

这时候很多人会得出一个结论：

AI 编程也就那样，玩玩可以，真用不行。

我不太同意。

更准确的说法是：

AI 已经能帮你把一个想法快速做出来，但能不能把它改到真正可用，考验的不是 AI，而是你有没有一套验收和迭代方法。

普通人 AI 编程最难的不是开始，而是最后 10%。

这 10%，决定了你做出来的是一个玩具，还是一个真正能帮你省时间的工具。

1. 先别急着换工具，你的问题可能不是工具问题

很多人一遇到 AI 写出来的东西不好用，第一反应就是换工具。

Cursor 不行，换 Claude Code。Claude Code 太难，换 Codex。再不行，换一个国产工具。

工具当然有差异。但对新手来说，很多问题不在工具，而在你给 AI 的任务太模糊。

你说：“帮我做一个周报汇总工具。”

这句话对 AI 来说，其实缺了太多东西：

周报从哪里来？飞书文档、Excel、聊天记录，还是表单？

汇总成什么格式？按人、按项目、按风险，还是按本周完成 / 下周计划？

异常怎么处理？有人没交、格式乱写、字段缺失，要不要提醒？

最后输出给谁看？自己看、老板看，还是发到群里？

这些东西你不说，AI 就会自己猜。

AI 一猜，你就会得到一个“看起来能跑，但跟真实工作差一口气”的半成品。

所以第一条判断很简单：

AI 编程不是把一句想法丢给工具，而是把一个模糊需求压缩成可验收的任务。

如果你连“什么叫做完成”都没定义清楚，AI 做出来的东西大概率只能停在 demo。

2. 小工具能不能用，不看界面，看 5 个验收点

很多 AI 编程教程喜欢教你怎么生成界面，怎么接 API，怎么让页面动起来。

这些当然重要，但不够。

真正能进入工作流的小工具，至少要过 5 个验收点。

第一，输入是否稳定。

你不能只拿一份最标准的样例去测。真实工作里，表格会缺列，名字会写错，日期格式会混乱，甚至有人直接把备注写进标题里。

如果工具只能处理“最乖”的输入，它就还不能叫可用。

第二，输出是否可检查。

AI 给你生成一段总结、一张表、一个分类结果，你要能看懂它为什么这么输出。至少要保留原始字段、关键依据、处理时间和异常提示。

否则它错了，你连错在哪里都不知道。

第三，异常是否有提示。

工具最怕的不是报错，而是悄悄错。

比如客户反馈分析工具，漏掉 20 条数据却不提示；周报汇总工具，把两个人的内容合并错了却不报警；发票整理工具，金额识别错了还继续输出。

这种工具越自动，风险越大。

第四，修改是否可回退。

新手最常见的崩溃场景是：让 AI 改一个小功能，结果它顺手重构一堆文件，原来能跑的版本也没了。

所以哪怕你不懂 Git，也至少要保留版本备份。比如每次改动前复制一个目录，或者让 AI 明确告诉你“本次改了哪些文件、为什么改、怎么恢复”。

第五，结果是否进入真实流程。

一个工具放在本地跑一次，不等于它已经帮你提效。

它要么减少了你重复复制粘贴的时间，要么降低了出错率，要么让你更快拿到判断依据。否则它只是一个技术玩具。

这 5 个问题答不上来，说明你缺的不是更强模型，而是一套最小验收框架。

3. 为什么 AI 做 demo 很快，改到能用却很慢？

因为 demo 只需要“看起来成立”。

真正可用，需要处理边界。

写代码的人都知道，系统里最花时间的地方，从来不是主流程，而是各种边界情况。

用户不按你想的方式输入。接口偶尔失败。文件路径不一致。权限不够。数据为空。字段改名。网络超时。旧版本还在被人使用。

这些东西，在 demo 阶段都可以假装不存在。

但只要你真的拿来用，它们就会一个个冒出来。

这也是为什么很多人觉得 AI 编程“前面 80% 很快，后面 20% 很痛苦”。

不是 AI 突然变笨了，而是任务从“生成代码”变成了“管理复杂度”。

AI 擅长生成答案，但系统能不能长期用，靠的是约束、测试、记录和回滚。

这也是技术人和普通 AI 玩家最大的区别。

普通玩家看的是：AI 能不能一口气写出来。

技术人看的是：它错了怎么办？改了怎么验？坏了怎么退？谁来确认？

如果你想真正用 AI 编程，哪怕你不是程序员，也要开始学会用这几个问题指挥 AI。

4. 给新手一个最小可用流程：三步就够

你不需要一上来就学完整的软件工程。

也不需要先补完前端、后端、数据库、部署、测试这些课程。

对刚开始用 AI 编程的人来说，先掌握一个最小流程就够了。

第一步，先写“验收清单”，再让 AI 写代码。

不要一上来就说“帮我做一个工具”。

你可以这样说：

这句话的价值很大。

它会把 AI 从“急着写代码”拉回到“先定义任务”。

第二步，每次只改一个问题。

很多人改工具时，会一次性丢给 AI 十几个要求：这里加个按钮，那里改个样式，再加一个导出功能，顺便优化速度。

这很容易把项目改乱。

更好的方式是：一次只改一个明确问题。

比如：

这不是啰嗦，这是在给 AI 划边界。

第三步，让 AI 自己写测试样例，再用样例验收。

你不懂测试代码也没关系。

你至少可以让 AI 给你列 5 组输入输出样例：正常数据、缺字段数据、空数据、格式错误数据、极端数据。

然后每次修改后，都让它用这些样例跑一遍。

只要这一步做起来，你的小工具稳定性会立刻上一个台阶。

普通人用 AI 编程，不一定要先学会写代码，但一定要学会验收。

5. 真正的分水岭：你是在让 AI 写代码，还是让 AI 做工程？

很多人以为 AI 编程就是“让 AI 写代码”。

这个理解太浅了。

真正有价值的 AI 编程，是让 AI 参与一个完整的工程闭环：理解需求、拆解任务、生成方案、修改文件、运行检查、记录变更、回滚风险。

这也是为什么现在很多 Agent、Hooks、Skills、MCP、CI/CD 这些词开始频繁出现。

它们背后的核心不是炫技，而是同一个问题：

怎么让 AI 不只是会写，而是能在边界内稳定地做事。

对普通人来说，你不需要一开始就搞懂这些名词。

但你要先建立一个判断：

如果一个 AI 工具只能帮你生成第一版代码，它只是写代码助手。

如果它能在你的规则里做修改、跑检查、给证据、留记录、出问题能回退，它才开始接近真正的 AI 工作流。

这就是“玩具”和“工具”的分界线。

也是普通人 AI 编程能不能持续用下去的分界线。

结尾：别追更强工具，先补最后 10%

这篇文章不是劝你别用 AI 编程。

恰恰相反，我认为普通人应该尽快开始用 AI 编程。

因为它正在把很多过去只有技术人能做的事情，变成普通人也能尝试的能力：做一个表格工具，做一个网页，做一个自动化脚本，做一个客户反馈分析器。

但我也想提醒一句：

AI 能帮你跨过“从 0 到 1”的门槛，但“从 demo 到可用”的最后 10%，不能靠兴奋感，要靠方法。

下一次你让 AI 做小工具时，别急着问它“能不能做”。

先问它五个问题：

输入边界是什么？

输出怎么检查？

异常怎么提示？

修改怎么回退？

结果怎么进入真实流程？

这五个问题问清楚，你已经比大多数只会复制 prompt 的人，往前走了一大步。

如果你也在尝试用 AI 做自己的第一个小工具，可以先关注我。

下一篇，我会直接给你一份“AI 小工具验收清单”：不管你用 Cursor、Claude Code，还是其他 AI 编程工具，都可以拿它去检查你的作品到底能不能真正用。