我开始把 AI 当成一个真正的工作伙伴

这几天，我开始把 AI 当成一个真正的工作伙伴。

这个变化不是因为 AI 突然变得“什么都会了”，也不是因为我突然学会了写代码。

恰恰相反，是因为在一次次真实的问题里，我发现：面对一个自己暂时不会解决的问题时，我不一定需要先成为专家，也可以先和 AI 一起把问题拆开、测试、修正，然后继续往前走。

这让我重新理解了 AI 在企业工作中的价值。

从一个真实的网站项目开始

最近这段时间，我一直在做杰程中心的新网站。

从页面、组件，到文章系统，再到地图、部署和服务器运行，真正做起来以后，我发现一个网站并不是“把页面做出来”这么简单。

页面需要调整。

组件需要修改。

代码需要检查。

修改以后需要测试。

测试通过以后还要提交 Git。

代码推送到远程仓库以后，服务器还要 pull。

如果涉及依赖变化，还要重新安装。

然后 build。

最后重新启动网站。

任何一个环节出现问题，后面的事情都可能停下来。

以前遇到这样的事情，我很容易产生一种感觉：

这个问题是不是需要找一个专业的人来解决？

因为我知道自己想要什么，却不一定知道下一步应该怎么做。

而 AI 让我开始采用一种不同的工作方式。

我不需要等到自己完全理解一个技术问题以后才开始。

我可以先把问题告诉 AI。

然后一起看下一步是什么。

AI 并不总是第一次就对

这一点反而是我这段时间最重要的体会之一。

如果把 AI 想象成一个“什么都知道的人”，真正工作以后很容易失望。

因为它并不总是第一次就对。

有时候它会判断错。

有时候给出的代码第一次并不能达到预期效果。

有时候一个问题看起来应该来自 A，测试以后却发现并不是。

甚至有时候，代码已经修改完成，重新打开网站以后，结果仍然不对。

但这并没有让我觉得 AI 没有价值。

因为真正的工作，本来就不是每一次判断都正确。

以前做研发、技术支持或者问题排查的时候，本来就是这样的过程：

发现问题。

提出可能性。

测试。

看反馈。

排除一种可能。

重新判断。

修改。

再次测试。

直到真正找到问题。

这几天和 AI 一起工作，我重新体验到了这种非常熟悉的 Troubleshooting 状态。

六个小时，只为解决一个二维码问题

前几天，我们曾经花了将近六个小时解决一个二维码问题。

现在回头看，这个问题本身其实并不值得六个小时。

但那六个小时的过程，却让我对 AI 的理解发生了变化。

因为那根本不像传统意义上的“问答”。

我告诉 AI 我看到的现象。

AI 提出可能的问题。

我修改代码。

然后测试。

再把测试结果告诉 AI。

AI 根据新的结果重新判断。

我们不断排除错误方向，然后继续往下走。

最有意思的地方在于：

AI 并不是一开始就知道答案。

我们是在一起寻找答案。

这和“AI 给我一个答案”，其实是两件完全不同的事情。

前一种方式更像协作。

后一种方式更像查询。

而真实的企业工作里，大量问题其实属于前一种。

我们并不知道答案在哪里。

我们需要一起把答案找出来。

这让我重新想起 Troubleshooting

这种工作状态让我想起很多年前做技术支持和 R&D 协同解决问题的经历。

一个问题出现以后，没有人能够保证第一次判断就是正确的。

技术支持人员描述现象。

研发人员提出假设。

大家一起测试。

根据反馈继续判断。

如果方向不对，就换一个方向。

如果方向正确，就继续深入。

最终把问题解决。

现在，这个协作者变成了 AI。

它可以快速分析我提供的信息，也可以帮助我理解错误、检查代码、提出测试方法。

但它真正有价值的地方，并不是永远正确。

而是它可以一直参与这个过程。

一个地图上的小标签，也值得反复调整

网站做到后来，我们又遇到了一个很小的问题。

地图上的“杰程中心”位置不够准确。

于是我们开始调整高德地图。

先重新确定位置。

再调整 Marker。

位置不对，就重新调整。

然后发现默认的标签样式不够好看。

换一个。

颜色有点深。

再调整。

后来干脆把标签框去掉，改成透明的自定义 Marker。

然后又觉得字体颜色太浅。

继续调整。

最后才变成现在比较满意的样子。

如果单独看这件事情，可能会觉得：

不就是地图上的一个小标签吗？

确实只是一个小细节。

但真实的工作就是由大量这样的细节组成的。

AI 在这里真正帮到我的，并不是“替我设计了一张地图”。

而是我可以不断告诉它：

这个位置不对。

这个颜色有点深。

把框去掉。

透明一点。

字体再清楚一些。

然后继续修改。

这种反复沟通和调整，本身就是工作的一部分。

Git、服务器，以及那些以前容易让我停下来的事情

这段时间还有一些变化，是我自己感受特别明显的。

以前看到 Git、服务器、环境变量和部署这些东西，我很容易产生距离感。

例如：

git status
git diff
git commit
git push
git pull
npm run build
systemctl restart

对于熟悉这些工具的人来说，它们非常普通。 但对于不熟悉的人来说，一个命令就可能让工作停下来。 现在，我可以把终端里发生的事情直接告诉 AI。 它告诉我下一步做什么。 我执行。 再把结果发回来。 然后继续。 于是整个过程变成了： 我操作，AI 判断；我反馈，AI 再判断。 AI 并没有替我工作。 但它降低了我继续工作的门槛。 我认为这可能是一个非常重要的区别。

真正的变化，不是“我会写代码了”

我并没有因为这段时间的工作突然变成程序员。 我也没有因为 AI 就掌握了所有技术。 这些都不是事实。 真正发生变化的是： 以前遇到一些自己不会的问题，我可能会停下来。 现在，我更愿意继续往前走。 不知道下一步怎么做，可以先把问题描述出来。 不知道错误是什么意思，可以把错误贴出来。 不知道代码哪里有问题，可以把代码发过去。 修改以后不知道对不对，可以把结果再拿回来验证。 于是，“我不会”不再一定意味着“我不能继续”。 它可能只是意味着： 那我们看看下一步是什么。

这对工作方式来说，是一个很大的变化。

AI 更像一个不会嫌你问题多的同事

这可能是我最近最深的一种感受。 真实工作中，一个人很难一直陪在另一个人旁边。 尤其是一些很小的问题。 你可能不好意思一直问别人： “这个是什么意思？” “我这里为什么不对？” “这个命令下一步怎么输入？” “我改完了，你帮我再看一下？” “这个颜色是不是有点深？” “这个位置是不是还可以再调整一点？” 但 AI 不太一样。 你可以不断问。 可以重复。 可以推翻刚才的方案。 可以说： 不对，我们换一个办法。

然后继续。 它不会因为问题太小而觉得不值得解决。 也不会因为你已经测试了很多次而不耐烦。 这让我重新理解了“工作伙伴”这四个字。 工作伙伴不一定意味着一个人替你完成工作。 很多时候，它只是意味着： 当你卡住的时候，有人愿意和你一起看一眼。

AI 真正改变的，可能是解决问题的方式

过去我们谈 AI，经常会谈效率。 一个小时的工作变成十分钟。 一个人完成原来需要几个人完成的事情。 这些当然重要。 但我现在越来越觉得，还有另外一种变化可能更加重要。 AI 改变的是一个人面对问题时的心理状态。 以前遇到一个自己不会的问题，第一反应可能是： 这个我不会。

然后开始寻找别人。 现在可能会变成： 这个我暂时不会，但我们可以先看看。

这两个念头之间，其实差别非常大。 前者容易让人停下来。 后者会让人继续往前走。

企业真正使用 AI，也许应该从真实问题开始

我现在越来越觉得，企业使用 AI 不一定要从一个宏大的 AI 战略开始。 也不一定要先建立一个非常复杂的系统。 很多时候，可以从一个真实的问题开始。 一个客户问题。 一个内部流程。 一个数据整理任务。 一个网站。 一次排查。 一个原本需要专业人员才能继续推进的问题。 先让 AI 参与进去。 让它帮助理解问题。 帮助提出可能性。 帮助测试。 帮助检查。 然后把一次成功的协作经验留下来。 再解决下一个问题。 再下一个。 慢慢地，一个人的工作方式会改变。 一个团队的工作方式也会改变。 最后，企业的工作方式可能也会改变。 这可能比讨论“AI 到底有多厉害”更值得关注。

我开始把 AI 当成一个真正的工作伙伴

现在回头看这段时间发生的事情： 一个二维码。 一个网站。 一张地图。 一个 Marker。 一行环境变量。 一次 Git commit。 一次服务器部署。 很多看起来很小的事情。 它们没有哪一件是惊天动地的。 但它们让我第一次非常具体地感受到： AI 正在从“一个我偶尔使用的工具”，变成“一个我每天可以一起工作的伙伴”。 我开始愿意把一些以前觉得“太技术”的事情继续往前做。 不是因为我突然什么都会了。 而是因为我知道： 我可以和 AI 一起做。 它可以帮我理解。 帮我判断。 帮我排查。 帮我检查。 有时候也会判断错。 那就重新来。 这其实和过去的研发工作没有那么大的区别。 真正重要的，从来不是谁一开始就知道答案。 真正重要的是： 我们能不能一起把问题解决掉。 所以，我开始把 AI 当成一个真正的工作伙伴。 而这，可能只是一个开始。