用 AI 开发项目二十多天后，我发现最重要的不是提示词，而是先定义问题

很多人开始使用 AI Coding 以后，都会经历一个阶段：

看到问题，就把问题交给 AI。

AI 修改完以后，重新运行项目。

发现还有问题，就继续把新的报错和要求发回去。

这样一轮轮循环，表面上每天都在推进，实际却可能一直停留在返工里。

我最近用 AI 和 Remotion 开发知识视频生成系统时，也陷入了这种状态。

整整二十多天，我几乎每天都在修改系统。

文档越来越完整，规则越来越多，组件越来越丰富，检查流程也越来越细。

但我对结果始终不满意。

最后我才发现，真正的问题不一定是模型不够强，也不一定是提示词写得不够好。

很多时候，是我在让 AI 开始执行以前，并没有先定义清楚自己究竟要解决什么。

项目背景：我想用 Remotion 自动生成知识视频

我的目标是搭建一套视频生成系统。

文章输入系统以后，由 AI 负责整理内容、拆分场景、设计画面，再通过 Remotion 生成视频。

一开始，我给自己的目标是：

做出一套优秀的知识视频生成系统。

这个目标听起来没有问题。

但真正开始开发以后，“优秀”却变成了一个无法验收的要求。

画面看起来太像 PPT，我就让 AI 增加动画。

主体不够突出，我就继续调整组件。

视频在电脑上看起来没问题，但缩小到手机上以后文字太小，我又增加移动端字号规则。

中文标题换行不自然，就补标题断行检查。

截图没有证据感，就调整截图容器和布局。

每一项修改都有原因。

类型检查也能通过，验证命令也能通过。

但一个问题刚解决，新的问题很快又会出现。

系统拥有的能力越来越多，我却无法回答：

我离真正想要的结果，到底还有多远？

问题并不是 AI 没有执行，而是目标没有定义清楚

那段时间，我一度认为是模型不够强。

我觉得只要提示词再完整一点，规则再详细一点，组件再丰富一点，AI 就能做出真正令人满意的视频。

后来回头看，我才发现，“优秀的视频”并不是一个可以直接执行和验收的目标。

我希望视频：

• 不像 PPT；
• 动画自然；
• 内容专业；
• 手机端清楚；
• 观众愿意看下去。

这些要求都没有错。

问题是，我没有明确它们之间的优先级，也没有把它们转换成可以检查的标准。

于是，AI 只能根据眼前的问题不断给出局部方案。

字体小，就修改字号。

画面静，就增加动画。

组件不足，就补充组件。

执行本身没有停止，但问题一直没有真正收敛。

直到后来，我才把目标重新定义为：

做一种清楚、可信、有获得感，并且能在手机信息流中正常阅读的知识视频。

这个目标仍然不算特别精确，但它已经能够帮助我作出判断。

“清楚”意味着观众能够快速找到画面重点。

“可信”意味着涉及实验、对比和真实经历时，需要展示支撑结论的证据。

“有获得感”意味着画面不能只是重复口播，而要帮助观众理解信息如何变化。

“适合手机观看”意味着不能只在电脑显示器上检查，需要把画面缩小后重新验收。

目标变化以后，我处理问题的方式也变了。

画面像 PPT，不一定要增加动画，也可能是信息没有发生变化。

场景不好看，不一定是组件不够复杂，也可能是没有明确的视觉中心。

截图没有说服力，不一定是样式问题，也可能是没有说明截图究竟证明了什么。

我开始不再看到一个问题就马上修改，而是先判断：

这是内容问题、表达问题，还是技术实现问题？

一个真实案例：组件通过测试，不代表值得使用

有一次，Codex 为系统增加了列表和步骤的焦点状态。

这个能力可以让当前讲到的内容高亮，帮助观众跟随口播理解进度。

从代码角度看，这次修改完成得不错：

• 新组件已经实现；
• 类型检查通过；
• 验证流程通过；
• 测试没有失败；
• 没有使用项目中禁止的动画方式。

如果只看工程报告，这项任务已经可以标记为完成。

但我重新检查画面后发现，它选择的是一张模板页。

模板页的主要作用，是让观众一次看清完整内容，并且可以暂停截图。

如果逐项高亮，未必能提高理解效率，反而可能干扰完整阅读。

这个案例让我意识到：

测试通过，只能证明代码按照预期运行，不能证明这个功能适合当前产品和场景。

功能是否值得实现，至少需要同时经过三层判断：

第一层：技术是否成立

代码能否正常运行？

类型检查、构建和测试是否通过？

第二层：场景是否适合

这个功能是否解决了当前页面或用户的真实问题？

它会不会引入新的干扰？

第三层：目标是否一致

这个改动是否让项目更接近最终目标？

还是只是因为技术上可以做，所以顺手做了？

从那以后，我要求 Agent 在提出修改建议时，不要只给出文件列表和实施方案。

它还需要先解释：

后来，Codex 提出给流程图增加运动连接线时，就换了一种解释方式。

它没有只告诉我准备新增一个组件，而是用导航地图举例：

只看到“家、地铁站、公司”三个地点，用户并不知道怎样从一个地方到另一个地方。路线被逐段画出来以后，移动过程才真正清楚。

通过这个例子，我可以立即判断：

这种能力适合流程、因果关系和阶段演进。

但不适合模板页、金句页和需要一次性完整展示的内容。

这时，我不再只是判断“代码能不能实现”。

我能够先判断：

这件事有没有必要实现？

AI Coding 中最容易被忽略的三个问题

这次经历让我发现，很多低效的 AI Coding 并不是因为 AI 不会写代码。

而是人在执行前跳过了三个问题。

1. 真正要解决什么？

“继续优化项目”并不是一个清楚的问题。

“页面不够高级”也不是。

更有效的表达应该指出具体差距，例如：

当前页面在手机宽度下，标题和正文层级不明显，用户无法快速找到主要信息。

AI 只有先知道问题发生在哪里，才有可能选择合适的修改方式。

2. 什么样的结果才算做好？

如果没有验收标准，AI 可以一直优化下去。

页面可以更精致，代码可以继续重构，功能也可以不断增加。

但项目需要明确停止条件。

例如：

• 手机宽度下文字仍然可读；
• 当前场景只有一个明确视觉中心；
• 动画需要对应信息变化；
• 修改不能影响其他场景；
• 新增能力必须有实际使用场景。

3. 用什么方式证明完成了？

AI 说“已经修复”不能作为完成依据。

不同任务需要不同证据：

• 代码问题：构建、类型检查、单元测试、实际运行；
• 页面问题：关键尺寸截图、交互检查、移动端预览；
• 内容问题：事实检查、逻辑检查、人工审阅；
• 视频问题：关键帧、完整预览、实际手机观看。

如果没有事先确定验证方式，“完成”很容易只是一句执行报告。

一份可以直接使用的 AI 执行前检查清单

现在，我在把复杂任务交给 AI 以前，会先写清楚以下内容：

任务目标：
这次真正要解决的问题是什么？

问题证据：
我根据什么判断这个问题存在？

允许范围：
哪些文件、模块或内容可以修改？

禁止范围：
哪些部分不能顺手重构或扩大修改？

完成标准：
达到什么条件以后，这项任务才算完成？

验证方式：
使用哪些命令、截图、测试或人工检查验证结果？

方案价值：
为什么这项修改值得现在做，而不是仅仅因为技术上可以实现？

这份清单不会让 AI 突然变得完美。

但它能够减少一种很常见的返工：

AI 快速执行了一个看起来合理、却没有解决真正问题的方案。

AI 是工具，工具越强，人越要保留判断

Linux 创始人 Linus Torvalds 最近在公开对谈中谈到 AI 编程时，将 AI 看作能够提高生产效率、但仍然需要开发者理解和检查结果的工具。

这个观点和我的经历非常接近。

AI 可以帮助程序员生成代码，但它不会天然知道这个功能是否值得开发。

它可以快速完成修改，但不会自动判断方案是否符合真实需求。

它可以通过类型检查和测试，却不能仅凭这些结果判断用户体验是否成立。

AI 会改变程序员的工作方式，也可能减少一部分重复、标准化的开发工作。

但执行成本越低，以下能力反而越重要：

• 定义问题；
• 判断价值；
• 选择方案；
• 验证结果；
• 承担最终责任。

程序员的价值不能只建立在“代码写得比别人快”上。

因为生成代码这件事正在变得越来越便宜。

真正难以被自动完成的，是判断应该写什么、为什么这样写，以及最终结果是否真的解决了问题。

AI 时代，哪些思维最重要？

回头看，我认为至少有四种思维需要保留下来。

第一是问题意识。

不要把模糊的不满意直接交给 AI，而要先定位真正的问题。

第二是判断意识。

AI 可以给出方案，但方案是否值得执行，仍然需要人判断。

第三是验证意识。

AI 的解释和执行报告不能代替真实结果，所有“完成”都应该有证据。

第四是工具意识。

把重复、机械的执行交给 AI，把人的精力留给问题、方向和结果。

现在，每次把复杂任务交给 AI 以前，我至少会问自己：

我真正要解决什么？
什么样的结果才算做好？
我准备用什么判断它已经完成？

AI 可以很快。

但越是这样，越不能跳过开始之前那段思考。

因为一个没有定义清楚的问题，不会因为执行速度提高，就自动变成正确的答案。