用 AI 编程最大的坑：只问逻辑，不问落地
问题是怎么发现的
我用 Claude Code 和 Codex 有段时间了。一开始我的提问方式很简单：
- "这个算法复杂度多少？"
- "这个 SQL 会死锁吗？"
- "帮我实现 xx 功能，核心逻辑是......"
AI 每次都能给一个很完整的答案，数据结构合理、边界也处理了。看着没问题就上线了。
然后开始出问题。
问题不是逻辑错了。是这些东西：
数据存在哪？AI 没告诉我它只在内存里跑，进程重启数据就没了。
用户怎么看结果？AI 只写了个后端接口，前端没人做。
数据什么时候清理？三个月后表涨到 500G，方案里没有过期策略。
报错了怎么排查？try-catch 打了行空日志，等于没写。
这些问题 AI 不会主动跟你提。你问了它才说，你不问它就当你不需要。
一次明确的教训
有次让 AI 设计工作流引擎。
它给了一套完整方案------状态机、节点执行器、回调、重试。看起来没什么问题。
后来被问到几个问题："持久化怎么做？工作流存哪？用户在哪看进度？前端哪个接口展示？"
我一个都答不上来。
那时候我才意识到：方案里有 bug 能发现，但方案里缺了什么是很难发现的。AI 不知道你忘了问什么，它只会回答你问了什么。
落地检查清单
之后我定了条规则：每次让 AI 出方案之前，先过一遍这个清单。
- 数据模型------表怎么设计？字段够不够？跟现有表的关系？
- 持久化------数据存哪里？什么时候写？生命周期多久？需要清理吗？
- API 设计------需要几个接口？请求响应格式？有没有现有的能复用？
- 前端展示------用户在哪个页面看到它？什么形式展示？怎么交互？
- 用户体验------空状态、加载态、错误态分别显示什么？
- 边界情况------没数据、输入错误、断网、后端不可用，分别怎么处理？
- 权限------谁可以读、谁可以写？多租户数据怎么隔离？
- 可扩展性------以后加功能，现在的设计好不好改？
每条填完了再动手。
对比
没清单的时候：
我：设计一个用户积分系统。
AI：积分表这样建，每次下单加积分，每月清零。
上线后发现：积分列表没分页、前端一次拉 10 万条卡死、管理员看不到排行榜。
有清单之后：
我：设计一个用户积分系统，先过一遍清单。
AI：
- 数据模型：user_points 和 point_logs 两张表
- 持久化：下单事务同步写入，point_logs 保留 2 年，定时清理
- API：GET 分页查询、POST 管理员手动授分、GET 排行榜
- 前端展示：积分卡片、虚拟列表、排行榜独立页面
- 边界处理：用户不存在 404、扣成负数 400
......
差距很明显。
为什么
这个做法本质上是 Harness Engineering。
Mitchell Hashimoto 的定义：每次发现 AI Agent 犯了一个错误，就花时间设计一个方案，让这个错误不再发生。
我的错误是"只考虑逻辑不考虑落地"。解决方案不是"下次多想一点"，而是把检查清单写进协作规范里。每次出方案之前强制过一遍，不填完不开工。
建议
如果你用 AI 写代码时也觉得产出不太够用，可以试试：
- 不要只问"逻辑对不对"，还要问"还需要什么才能落地"
- 列一份自己的检查清单，让 AI 出方案时逐条回复
- 每次发现问题就往清单里加一条
- AI 不会补全你没问的问题------它没这个能力
AI 挺好用的，但别指望它帮你兜底。
------ 小饼干