驾驭 AI：三个让我印象深刻的实战教训

上一章讲完大模型的五个固有缺陷，很多人可能会问：知道缺陷之后，具体怎么避免？

这一章不讲理论，只讲三个我亲身经历、或者身边人经历的案例。每一个案例都对应一个核心教训。这些教训看起来简单，但每一个都曾让我付出过时间代价。

案例一：规范没定好，再贵的模型也白搭

背景

Growth 项目里有一个 Skill，叫 create-web-module，放在 D:\DEV\CODE\Automator\Client\.qoder\skills\create-web-module\SKILL.md。它的作用是让 AI 根据需求自动创建前端模块。

这个 Skill 写得不算差，但有一个问题：里面所有样式都是内联 CSS。没有统一的 CSS 规范，没有 Tailwind 的使用约定，没有 Rush Package 的模板约束。

现象

每次让 AI 生成新的前端模块，出来的结果总是：

样式风格不统一，有的用 style=，有的用 CSS Modules，有的直接写 <div className="...">
布局在不同页面看起来相似但不一致
代码频繁报错，类型对不上、依赖缺失、文件路径引用错误
换模型试过，DeepSeek V4 Pro、QianWen 3.6 Max、GLM 5.0 都试过，效果时好时坏

那时候我觉得是模型不够强。于是不断换更强的模型、写更详细的提示词，问题依旧。

转折

后来我做了一件事：

把 Skill 里的内联 CSS 全部替换为 Tailwind CSS 规范
定义了统一的 Rush Package 模块模板
在 AGENTS.md 里写明：所有新模块必须基于模板创建，禁止自行发挥目录结构
用 Rule 约束：样式必须使用 Tailwind 工具类，禁止内联样式

改完之后，我用最便宜的模型——DeepSeek V4 Flash——重新跑同一个需求。

结果：一次成功。代码风格一致、依赖正确、类型通过、直接可编译。

教训

误区	真相
模型不够强，所以做不好	大多数编码问题不是模型能力问题，是约束条件不清晰
换模型能解决问题	在模糊的规范下，越强的模型越有自己的"想法"，反而更难统一
提示词写得越细越好	与其每轮重复约束，不如把约束写进 Skill / Rule / AGENTS.md

核心原则：

当规范不确定时，AI 会用自己的训练数据默认值来填补空白。你看到的"风格不一致""代码报错"，本质上都是规范缺失的副作用。

这个案例让我彻底改变了对 AI 编码的看法：重要的不是让 AI 写出多聪明的代码，而是让它在既定轨道内不出轨。

案例二：方向错了，再大的模型也会死磕

背景

这个案例来自 2026 年 6 月我们处理的一个 RTMP 推流问题。相关排查文档有两份：

0617-100000-RTMP推流FLV-Header立即写入修复.md
0617-161848-RTMP推流首帧延迟与连接时序优化.md

问题现象是：RTMP 推流到 SRS 服务器，连接建立后大约 22-30 秒，服务端主动关闭连接，客户端写帧时报 End of file。

第一次方向

我一开始给 AI 的指令是：

"基于当前已有的修复方案，继续优化 RTMP 推流首帧延迟问题。"

AI 很听话。它基于我已经给出的方案，做了很多微调：

调整 x264 的 rc-lookahead 和 sync-lookahead
优化 av_write_frame 和 av_interleaved_write_frame 的调用
修改 max_delay 参数
尝试减少 KeyFrameSynchronizer 的缓冲

每次改完，延迟从 32 秒降到 28 秒、23 秒，但始终无法根治。

我连续换了好几个模型，DeepSeek V4 Pro、DeepSeek V4 Flash、Kimi 2.6、QianWen 3.7 Max、QianWen 3.7 Plus，甚至刚出来的 GLM 5.2 都试过，结果都一样——它们在同一个方向上越做越深，但方向本身有问题。

方向错了

后来我仔细看了日志时间线，发现一个关键事实：

T+0s      avio_open 完成，TCP 连接建立
T+23s     首个视频关键帧产出
T+23s     写入视频帧失败：End of file

问题在于：连接建立后 23 秒内没有任何媒体数据发送，SRS 等不及就断连了。而 23 秒的延迟来自 x264 在 1fps + bframes=3 + preset=medium 参数下的首帧延迟。

我之前的所有优化，都是在"连接已经建立"之后做文章。但真正的根因是连接建立得太早。

新方向

我给 AI 换了一个完全不同的方向：

"不要在启动时立即连接 RTMP。让编码器先运行，等第一个视频关键帧准备好之后，再调用 avio_open 建立连接并写入 FLV header。"

这就是"首帧就绪后再连接"方案。

AI 只花了 10 分钟就给出一套完整的实现：

RtmpOutput.StartAsync 只准备 FormatContext 和 SPS/PPS，不调用 avio_open
新增 _lazyConnect 标志
首个视频关键帧到达时触发 LazyConnect
此时才执行 avio_open + avformat_write_header，然后立即发送首帧

这个方案彻底解决了 SRS 超时问题，而且没有牺牲压缩率和画质。

教训

误区	真相
问题复杂，需要更强的模型	方向错了，再强的模型也只是更快地走远
基于现有方案继续优化是安全的	如果现有方案本身没触及根因，继续优化就是浪费 Token
AI 会自己发现方向错了	大模型不会主动反思方向，它只会在你给的上下文里找最合理的下一步

核心原则：

当 AI 在一个方向上反复尝试却进展有限时，不要让它继续加细节，要停下来问自己：这个方向本身对吗？

这也是"文档先行"的真正意义——不是为了让 AI 写文档，而是为了在动手之前，先把思路摊开来检查方向。

案例三：问题被限定之后，AI 就跳不出框架

背景

同事做一个人脸检测相关的功能，底层用的是 DeepFace。他遇到一个性能问题：DeepFace 的搜索接口非常慢，单次查询要好几秒，完全达不到实时要求。

第一次提问

他去问 AI：

"DeepFace 的 search 接口很慢，怎么优化？"

AI 给了一堆方案：

预处理人脸对齐
降采样减少计算量
换更轻的模型（如 Facenet、OpenFace）
做向量化缓存
批量推理

他试了一天，效果都不理想。DeepFace 本身的架构决定了 search 接口就是这样，再怎么优化也只是缓解。

问题出在哪

我看完跟他说：

"你这个问题被限定在 DeepFace 里了。AI 会默认接受你的前提——'解决方案必须在 DeepFace 内部'。它不会主动跳出来说'你别用 DeepFace 了'。"

大模型的注意力机制就是这样：你给的上下文越具体，它越在这个范围内找答案。DeepFace 慢，它就在 DeepFace 里找优化点，不会主动推荐完全不同的技术栈。

换种问法

我让他开一个新会话，换一种问法：

"我在做人脸识别应用，有哪些可用的技术方案？每个方案的优缺点是什么？哪种方案在性能上最好？"

这次 AI 列出的方案包括：

方案	优点	缺点
DeepFace	接口简单，模型丰富	性能差，search 慢
dlib	准确率高	编译复杂，速度慢
ONNX Runtime + 人脸模型	性能极高，可 GPU 加速	需要自己封装接口
OpenCV DNN	轻量，无额外依赖	精度一般

同事很快选中了 ONNX Runtime 方案，用了一个现成的人脸识别 ONNX 模型，性能从几秒降到几十毫秒。

教训

误区	真相
AI 会质疑我的前提	AI 通常默认接受你的问题前提，很少主动挑战
在一个方向上问得越细越好	方向错了，细化只会让你更困在原地
同一个会话里改问法就行	旧会话里的上下文会持续影响 AI 的思路，关键问题要开新窗口

核心原则：

当你发现 AI 总是在一个狭小的范围内打转时，不是它不够聪明，是你把它的注意力锁死了。换一个更开放的问题、换一个新的会话，往往比继续追问更有效。

三个案例的共同主题

把三个案例放在一起看，它们讲的其实是同一件事：

驾驭 AI，不是让 AI 更聪明，而是把约束、方向、前提这些"边界条件"管理清楚。

案例	管理什么	怎么做
案例一：前端模块规范	约束条件	用 Skill / Rule / AGENTS.md 把规范写死
案例二：RTMP 首帧延迟	解题方向	怀疑现有方向，让 AI 从根因出发重新设计
案例三：人脸检测性能	问题前提	不被限定在技术栈内，主动拓宽选项

这三个维度，正好对应上一章讲的 Harness 思想：

约束条件 → Rule 和 AGENTS.md 画边界
解题方向 → 文档先行 + Plan checkpoint 防跑偏
问题前提 → 独立 SubAgent / 新会话跳出框架

给读者的实践建议

如果你现在用 AI 做项目，遇到以下情况，可以对照检查：

情况一：代码总是风格不一致、小错不断

不要换模型，先检查：

项目有没有统一的编码规范？
Skill / Rule 里是否写清楚了样式、命名、目录结构？
最强的模型在模糊约束下，未必比规范下的便宜模型更好用

情况二：AI 反复尝试但解决不了

不要继续给更多细节，先检查：

你给的方向本身对吗？
有没有可能是前提假设错了？
让 AI 先写一份问题分析和方案对比，不要直接让它改代码

情况三：AI 总是在一个技术范围内打转

不要继续在同一窗口追问，尝试：

开一个新会话，去掉具体技术限定
问"有哪些方案"而不是"这个方案怎么优化"
让 AI 先比较方案，再选择实现

本章小结

驾驭 AI 的最高境界，不是问出一个完美的问题，而是清楚自己给 AI 设定了什么边界，并且知道什么时候该打破这些边界。

该收紧时收紧——把规范写进 Skill 和 Rule
该放开时放开——怀疑方向、更换前提、重开会话
该审查时审查——让独立的 SubAgent 检查主 Agent 的输出

下一章是一个综合案例：如何为本书自动配图。我们会把前面讲过的跨工作区、MCP、复杂任务分解等方法，完整跑一遍。

驾驭 AI：三个让我印象深刻的实战教训 ​

案例一：规范没定好，再贵的模型也白搭 ​

背景 ​

现象 ​

转折 ​

教训 ​

案例二：方向错了，再大的模型也会死磕 ​

背景 ​

第一次方向 ​

方向错了 ​

新方向 ​

教训 ​

案例三：问题被限定之后，AI 就跳不出框架 ​

背景 ​

第一次提问 ​

问题出在哪 ​

换种问法 ​

教训 ​

三个案例的共同主题 ​

给读者的实践建议 ​

本章小结 ​

驾驭 AI：三个让我印象深刻的实战教训

案例一：规范没定好，再贵的模型也白搭

背景

现象

转折

教训

案例二：方向错了，再大的模型也会死磕

背景

第一次方向

方向错了

新方向

教训

案例三：问题被限定之后，AI 就跳不出框架

背景

第一次提问

问题出在哪

换种问法

教训

三个案例的共同主题

给读者的实践建议

本章小结