用 AI 编程最大的坑：只问逻辑，不问落地

数据存在哪？AI 没告诉我它只在内存里跑，进程重启数据就没了。

用户怎么看结果？AI 只写了个后端接口，前端没人做。

数据什么时候清理？三个月后表涨到 500G，方案里没有过期策略。

报错了怎么排查？try-catch 打了行空日志，等于没写。

这些问题 AI 不会主动跟你提。你问了它才说，你不问它就当你不需要。

一次明确的教训

有次让 AI 设计工作流引擎。

它给了一套完整方案——状态机、节点执行器、回调、重试。看起来没什么问题。

问他几个问题：“持久化怎么做？工作流存哪？用户在哪看进度？前端哪个接口展示？”

他都说抱歉，还没做。

那时候我才意识到：方案里有 bug 能发现，但方案里缺了什么是很难发现的。AI 不知道你忘了问什么，它只会回答你问了什么。

落地检查清单

之后我定了条规则：每次让 AI 出方案之前，先过一遍这个清单。

1. 数据模型——表怎么设计？字段够不够？跟现有表的关系？
2. 持久化——数据存哪里？什么时候写？生命周期多久？需要清理吗？
3. API 设计——需要几个接口？请求响应格式？有没有现有的能复用？
4. 前端展示——用户在哪个页面看到它？什么形式展示？怎么交互？
5. 用户体验——空状态、加载态、错误态分别显示什么？
6. 边界情况——没数据、输入错误、断网、后端不可用，分别怎么处理？
7. 权限——谁可以读、谁可以写？多租户数据怎么隔离？
8. 可扩展性——以后加功能，现在的设计好不好改？

放到Claude.md文件。

对比

没清单的时候：

我：设计一个用户积分系统。
AI：积分表这样建，每次下单加积分，每月清零。
上线后发现：积分列表没分页、前端一次拉 10 万条卡死、管理员看不到排行榜。

有清单之后：

我：设计一个用户积分系统，先过一遍清单。
AI：

1. 数据模型：user_points 和 point_logs 两张表
2. 持久化：下单事务同步写入，point_logs 保留 2 年，定时清理
3. API：GET 分页查询、POST 管理员手动授分、GET 排行榜
4. 前端展示：积分卡片、虚拟列表、排行榜独立页面
5. 边界处理：用户不存在 404、扣成负数 400
   ……

差距很明显。

为什么

这个做法本质上是 Harness Engineering。

Mitchell Hashimoto 的定义：每次发现 AI Agent 犯了一个错误，就花时间设计一个方案，让这个错误不再发生。

我的错误是"只考虑逻辑不考虑落地"。解决方案不是"下次多想一点"，而是把检查清单写进协作规范里。每次出方案之前强制过一遍，不填完不开工。

建议

如果你用 AI 写代码时也觉得产出不太够用，可以试试：

1. 不要只问"逻辑对不对"，还要问"还需要什么才能落地"
2. 列一份自己的检查清单，让 AI 出方案时逐条回复
3. 每次发现问题就往清单里加一条