今天晚上，我让 AI 从多个本地小图出发，把它们按照一定规则拼接成一张大图。整个过程倒没有戏剧化的转折，我只用了五分钟就帮助 AI 完成了任务。但是，在这个过程中，我发现自己有意识地用了几种管理 AI 的技巧，而这些技巧往往是新手最欠缺的。所以，我把具体用的技巧分享出来，看会不会对大家有启发。

## 破解"知识诅咒"：从技术控到AI管理者的角色蜕变

最开始的结果是这样的：我让 AI 生成一个拼接好的大图，但得到的结果是一个带着明显拼接痕迹的合成图，一眼就知道不对。但是又很难说上来具体是哪里错了。作为一个写了八百年代码的老码农，我的手已经放在键盘上了，打算立刻开始查坐标原点、尺寸归一化和缩放细节。

但是，就在我准备接管代码的瞬间，我突然意识到这是一个 AI 时代的典型陷阱。这个陷阱来自于“知识的诅咒”（Curse of Knowledge）。越是技术力高的人，越会想要第一时间亲自下场帮 AI debug。这是因为我们太熟悉这些编程细节了，往往能够迅速猜到问题可能的几种原因。而且编程确实又是一个有快感的东西，所以手痒想立刻上手。而且，这很多时候确实可以提升速度，毕竟现阶段的 AI 在我们熟悉的领域 debug 的功底还是没有我们深厚。

但我为什么控制住了自己的冲动呢？因为我意识到了两件事情：

1. 第一是，这会让 AI 错失一次自我升级的机会。虽然我们可以很快用我们的技术能力去解决问题，但就好像在人类开发组里，老板和手下抢活是大忌一样，我们应该尽可能地给组员更多的机会去成长，而不是事必躬亲。否则看起来好像问题解决得很快，但是组员因为一直在抄答案，水平却得不到有效的提升。
2. 第二是，这也是新手 Manager 常常掉进去的一个陷阱。虽然从一次两次的角度来说，自己上手干活可能比下属慢慢修要来得快，但是当你有多个下属的时候，从“我会写代码，所以我就自己修”到“我来做 Manager，让组员学会怎么修”的这个思维转变，往往可以带来数倍的效率提升和更高的scalability。

## 拒绝摸黑调试：提供可视化上下文

从这两个原因出发，我按住了直接上手的冲动，而决定看看如果我不跳进一线帮忙，而是从更宏观的角度辅助 AI 来做 debug，会发生什么事。

我首先问自己，下面我怎么去跟 AI 描述这个问题出在哪？不论是人或者 AI，直接把生成好的错误图像扔给它，看来是一个最直观的方法。但其实换位思考，如果是我拿到这个生成的有明显拼接痕迹的图本身，我也很难一步就定位出到底是什么原因。还是需要仔细观察出现瑕疵的精确位置，然后以此结合代码反推出具体的 bug 是什么。最好还得结合这个图像打点log。

换言之，如果我们就直接跟 AI 说“你做错了”然后把生成的图贴给它，一定程度上这是 set for failure。这是因为AI没有足够的 context 和精确的信息来迅速定位 bug。所以我完全可以想象到，如果我真的这么做了，看到的情况无非就是 AI 鬼打墙，每次随机地做一些更改，然后问我出来的结果对不对。得知不对以后再去拍脑袋想另外的原因，再问我结果对不对，不断地道歉和循环。所以不论是对人类还是对 AI 的工作场景里，我都会尽量避免这种类似白板编程式的只能盯着 code 去猜原因的 debug。不会扔给下属一个仅凭肉眼无法判断的问题，然后指望对方闷头去搞定。

从这个角度出发，一个自然的思考就是，要让 AI 成功地完成修复，就得给它更完善的资料。比如说，每个小图在最终大图中出现的位置、大小、排列关系，最好把这个过程给可视化出来。这样一方面它自己能够直观地看到图片的排布是否合理，另外一方面，这也让我对它的输出的正确性的检查变得更加直观简单。所以我就用这种逆向思考的 manager的思维来告诉 AI：你的结果错了，但是为了让你理解错哪了，你先来份可视化，把每一个小图在大图中的位置给可视化出来，让我看见小图都拼在哪里了。

AI很快就生成了一张可视化的图像。很明显，最上面的一行和下面的图像比例失调，这个是为什么我们在最终的版本里看到拼接痕迹的原因。其实在这里，我已经看出来问题所在了。但因为同样的原因，我还是把这个图像贴给 AI，问它“你自己看看问题出在哪里”，并让它修正，并且把学到的教训放在 cursor rules 里面。

在这之后，AI 就自己去查看了这张可视化的图，很快地理解了问题出在哪里，并且实际修正了代码，生成了正确的图像。这整个过程，我其实并没有直接把答案告诉 AI，而是像一个人类的 manager 经常做的那样，把 best practice 带进来。通过 mechanism 和 procedure 让它自己去发现问题，也让它自己提出解决方案。

## 认知脚手架：培养AI的问题解决能力

在这个故事里面，我想分享的启发主要有两点：

第一点是，很多人因为各种原因迟迟不愿意去用 AI，比如 AI 会 hallucinate，会非常有欺骗性地给你一个错误的答案。比如 AI 太弱了，它写代码的效率远远没有我高。但我想指出的是，这些问题其实不是 AI 特有的问题。同样的问题也经常出现在人类组织的管理里。

比如，很多人类小伙伴在工作的时候也会犯各种各样的错误，有些思路会跑偏，会做一些错误的假设和臆测。那对于这样的同事提交的代码，你会不做任何检查直接给你的老板看吗？当然不会。我们会首先通过 code review 或者各种交叉验证，来确保这个代码和报告的质量，只有在我们把关确认它的质量达标以后，才会进一步提交。

从另一个方面来说，AI 现在写代码会鬼打墙，效率不高，也很类似大家在人类组里看到的一些不熟练的员工。作为人类 manager，我们往往会先想办法让对方从根本上成长，学会工作方法，积累工作经验，通过这样的方法让自己变得更加 scalable，从而实现比自己单打独斗远远更高的生产力。这是人类新手 manager 尤其需要注意的一点。只是现在，人人都可以用上 AI，但大家没有意识到，我们其实角色也在悄悄发生了变化，变成了 AI Manager 而已。

而这恰恰是我想分享的第二点。要想有效地利用 AI，最大的关键其实不是你要成为一个 LLM 的专家，知道 transformer、fine-tuning 的各种技术细节。恰恰相反，要想最有效地使用 AI，需要完成从 IC 到 Manager 的思维蜕变。再回头看看我们在这个简单的例子里做的三个决策：

1. 不和 AI 抢键盘。下属遇到问题，我们的责任不是直接上手帮他修好，这样又不 scalable，又让他丧失了成长的机会。
2. 不让 AI 摸黑干活。就好比一个实习生是个刚接手祖传屎山的新人，你让他立刻开始产出，这是 set for failure 一样。AI 遇到这种情况，就只能原地打转，debug 不出来，或者干脆开始 hallucination。这不是 AI 的问题，而是 Manager 没有给它足够的信息。
3. 授之以渔，而不是授之以鱼。我们指导 AI 工作的关键不是帮它做好 debug，然后把答案直接给它。而是从方法论的角度教它怎么自己摸索出 bug 在哪里。这样我们的角色才是一个 enabler 和 multiplier，才能实现生产力的真正倍数增长。

所以最关键的思维转变是，不要老想着让自己变强，而要学会站在管理者的位置，让AI变强。和人类经理一样，我们不需要比AI更懂技术，但要更懂得如何为它创造成功条件。下一次当AI搞砸任务时，不妨先问自己这三个问题：

1. 我给的信息足够让人类同事听懂任务吗？
2. 如果我是新人，接到这个任务会想要哪些资料？
3. 有没有不涉及技术细节的通用方法能引导思考？

毕竟，未来最稀缺的不是会写代码的AI，而是可以让AI真正deliver的AI manager。

## 后记

在Deepseek时代，AI的中文文案能力得到了突飞猛进的提升。这个文章的写作也大量探索了使用r1来辅助写作。最终我定下来的写作流程是：

1. 语音输入基本素材
2. o1 pro整理和深化观点和结构（这一步为什么不用r1是因为r1写文章营销味/韭味太重了，比如这个是r1对这篇文章建议的草稿：
```
开篇钩子：
"当我的AI程序员交出一张破碎的拼图时，我意识到：未来最稀缺的能力不是会调参，而是会「管AI」——这是用ChatGPT重构200张卫星图时得到的顿悟"
核心认知差：
程序员用AI写代码 VS 管理者用AI造系统：真正拉开差距的，是管理数字员工的「元能力」

心智模型升级三部曲：
心智跨越1：从「技术专家」到「问题架构师」
* 经典误区：把自己当人肉Debugger（"这里坐标计算有问题，应该调整..."）
* 破局关键：建立「指令工程学」思维（"我需要怎样的输入输出关系？如何设计验证环节？")
* 实操案例：通过要求生成「拼图位置热力图」，把图像问题转化为数据结构可视化问题
心智跨越2：从「过程监管」到「验证设计」
* 反常识洞察：AI的幻觉不是技术问题，而是管理者的问题（当错误率>70%，说明需求描述存在结构性缺失）
* 执行框架：
    1. 可信度测试：如果人类需要多少信息才能解决？
    2. 验证锚点：设计可量化的检查节点（如拼图缝隙占比<2%）
    3. 抗幻机制：要求用两种不同算法交叉验证
心智跨越3：从「解决方案提供者」到「认知脚手架搭建者」
* 高阶心法：用领域知识构建「思维约束框架」
    * 初级：直接给代码建议（X）
    * 进阶：注入行业范式（"航拍图拼接应考虑地球曲率校正"）（√）
    * 终极：建立决策树（"若缝隙出现在经度方向，优先检查投影坐标系转换"）（√√）
```
3. r1进行试写，寻找一些精彩片段（这一步为什么不直接用r1一个是因为营销味，一个是因为它instruction following能力比较弱，老要自己加戏）
4. 结合o1的提纲和r1的片段人肉口述
5. 最终人肉润色（这一步为什么不用r1是因为它instruction following能力太弱，没办法忠于原文，叫它润色老要自己加戏改写）

所以其实最终写作的过程也还是完全是人写的。

<script async data-uid="49b08a3e73" src="https://yage-ai.kit.com/49b08a3e73/index.js"></script>