我用 AI 做了一个小工具,但代码不是关键

昨天，有个朋友在微信上找我。

她在编辑一份 Word 文档，里面有一张很长的表格。其中一列放着不同企业的 Logo，因为图片大小不一样，表格的行高也跟着参差不齐。

她只能一张张调整，所以想知道，有没有办法一次把这一列的图片统一成相同的宽度。

我先试了一下 Word 自带的图片设置，发现这些嵌入表格的图片没办法一起选中调整。

然后我就想直接把文档交给 AI 处理。

但我又担心这种方式不够稳定，而且朋友以后再遇到同样的问题，可能还要重新上传、处理和下载，其中一些文件处理能力也可能需要付费。

想了想，我最后决定用一个相对传统的方式：在 Word 里通过宏来批量处理。

宏可以理解成一段直接运行在 Word 里的批处理代码。

我把需求告诉 ChatGPT，它很快生成了第一版代码。代码可以运行，但只能处理固定的一列。如果下一份表格里的 Logo 换了位置，代码就不能直接用了。

于是我又把它改成了可以配置的方式：由用户自己选择要处理哪一列，设置图片宽度，同时保持 Logo 原来的长宽比例。

工具做好以后，我又想到，朋友没有接触过代码。如果只把宏发给她，她可能不知道第一次该怎么配置，以后又该从哪里运行。

所以我把前面的处理过程和使用要求交给 ChatGPT，让它整理出一份操作手册，把第一次配置和日常使用分别写清楚。

最后，我把代码和操作手册一起发给了她。

从收到需求，到完成代码、测试和操作手册，整个过程大概只用了半个小时。

代码能写出来，不等于这件事已经交付好了

现在很多 AI，生成代码的能力确实已经很强了。只要把需求说清楚，很快就能得到一版可以运行的代码。

但回头看这个案例，代码并不是最关键的部分。

如果我只是让 AI 处理当前这份文档，那么下一次遇到同样的问题，朋友还是要重新处理。

如果我直接把第一版宏交给她，这段代码只能处理固定的一列，换一张表就可能不能用了。

即使代码已经改成可配置的方式，如果没有操作手册，一个平时不接触代码的人也未必知道怎么使用。

所以，真正让这个工具可以交付的，是后面的几次判断：

选择哪种处理方式，哪些内容不能写死，以及怎样让使用者以后能够独立操作。

这些事情，AI 可以帮我实现，但决定还是要我自己做。

AI 降低了实现成本，但判断仍然来自人

我过去 10 多年一直在做企业信息化和项目管理。

这段经历让我形成了一个习惯，收到一个需求以后，我不会只看眼前能不能解决，还会继续往后想。

这件事以后会不会重复发生？现在选择的工具是否合适？使用者有没有能力自己操作？最后交出去的东西到底能不能真的用起来，产生价值？

这些判断不一定很显眼，但它们会直接影响最后的结果。

过去，即使想到了这些问题，可能也会因为写代码和整理文档的成本太高，最后只能停在想法上。

现在有了 AI，实现这些想法的成本已经低了很多。

从这次实践来看，我更倾向于这样理解：

AI 可以把代码写得越来越快，但一个方案应该怎么设计、做到什么程度，以及怎样交到使用者手里，仍然依赖人的真实判断。

代码只是实现方案的一部分。

真正的交付，是让这个方案进入使用场景以后，对方可以稳定地把它用起来。