>前一段时间我在教AI做一件事——帮我整理项目周报。教着教着我发现一个挺有意思的现象：我以为我很清楚自己是怎么写周报的，真到要写提示词的时候，才发现很多步骤我自己从来没说清楚过。<
><>这件事让我对「教AI」有了新的理解：它不是单向的付出，而是在逼你把隐性经验显性化。<
><>我的第一版提示词写得很简单：「根据以下工作记录，生成项目周报」。<
><>结果出来一堆废话：进度正常、质量良好、安全可控。看着像周报，其实没有一个字有用。<
><>我回头想问题出在哪，发现根源是——我自己写周报的时候，脑子里有一套默认的判断：什么算重要、什么该突出、什么该压下去，但我从来没把这些说出口过。<
><>于是我开始逼自己写清楚，最后整理出这么几条规则：<
><>写完这几条我突然意识到：我平时写周报之所以快，靠的就是这套判断，只是它一直没被明确表述过。<
><><>第一个盲区：我以为标准很清楚，其实只有我自己清楚。<><
><>我在项目上待了十几年，很多判断已经变成直觉。但直觉没法传递。当我要把规则写出来给AI看的时候，才发现有些判断背后是有原则的，有些只是习惯，还有一些其实自己也没想明白。<
><><>第二个盲区：我以为步骤是线性的，其实是并行的。<><
><>我列流程的时候，以为自己是「先收集记录→再整理→再写」。真去复盘才发现，我其实是一边看记录一边就在做优先级判断，收集完初稿已经成型了。这种「收集和判断同时进行」的能力，恰恰是新手最难学的地方。<
><>把它写清楚之后，我反过来能给新来的技术员做培训了——因为我终于能说明白。<
><><>方法一：给正例和反例，不要只给规则。<> 光说「要突出重点」，AI不知道什么叫重点。给它一份写得好的和一份写得烂的做对比，效果立刻不同。这一点对带人也一样。<
><><>方法二：允许它犯错，但每次都要问「为什么错」。<> 我一开始看到AI输出不对就想改提示词，后来改成先问自己：它错的地方，是不是我没说清楚？十次里有八次是。<
><><>方法三：把成果固化成可复用的东西。<> 我现在不只是有一份写好的提示词，还整理了一份自己的周报检查清单——每次写完对照一遍。这份清单是从纠正AI错误的过程中攒出来的。<
><>教AI这件事对我的工作产生了几个意外的影响。<
><><>第一，我的文档质量提高了。<> 因为要写得让AI看得懂，也就是要写得让别人看得懂——以前很多「内部上下文」，现在都被我写进正式文件里了。<
><><>第二，我交接工作变容易了。<> 过去我的经验在脑子里，交接靠带着干；现在很多流程有了文字版，新手可以直接看。<
><><>第三，我对自己的判断更清楚了。<> 哪些是经验、哪些是原则、哪些只是习惯，区分开了之后，遇到新情况时判断反而更快了。<
><><><>体会：教AI的过程，本质上是逼自己把「知道怎么做」升级成「说得出为什么这么做」。前者是手艺，后者才是方法。<
><
>带过新人的都知道，教会别人比自己做一遍难得多。教AI也是同样的道理，而且它还没有「不懂装懂」的缓冲，你讲不清楚，它就直接给你一个错误的产出。<
><>所以我现在把这件事看得很重：让AI帮我干活是省时间，教AI怎么干是在补自己的方法论。前者是一次性的收益，后者是长期的。<
><>对工程人来说，这可能比自己埋头多干两年活更值。<
> <> <