上次提到《当我20天的账单超过4000美元 | 长琴[1]》应该只是众多使用 AI Coding 场景中的一个缩影，本文还是以我自己为例，继续聊聊 AI Coding 以及 AI。
恐怖渗透
上次我们已经提到，token 已成燎原之势，现实更加恐怖，工作、学习、研究，每一项都有 AI 重度参与，不过这个“参与度”我想人与人之间差别应该很大。我没有做过太多调研，只能以自己为例来说明了。
首先，工作上基本是 AI 写代码了，偶尔 AI 不能用的时候人工来写，目前还没有感觉到写不出来，但速度确实慢了很多。算法工作，数据处理是大头戏，而数据处理的细节非常多，遇到过几次“坑”后，现在乖乖 review，尤其是核心逻辑，确保自己掌握。不过对于一些事后统计相关的，就看的比较粗糙了。为了便于 review，我还专门把服务器改造了一下，vim、yazi、tmux、git delta 等等一系列工具都给挪到了服务器上（俺的 dotfiles[2]），比较大的改动就还是拉到本地用 IDE 看了。总的来说，工作上已经合作的比较顺畅：代码部分，他写我 review；方案部分，我提出他补充并文档；文案部分，我给需求他直接写；其他操作类的（比如 ab、上线等）也由他完成，我只给指令。总的来说，这部分的合作已经基本没啥问题了，分工明确，基本不再有问题。
其次，学习上 AI 扮演了强力的“指导者”角色，大的方向还是由我来确定，他帮我补充细节，然后我去阅读并理解，有疑惑的地方（有时候是我没理解，有时候是他搞错了）继续沟通，直到彻底理解整个过程。这方面从一开始就很顺畅，原因也很简单——这部分始终以我为中心，或者说以我搞懂为中心，所以他的输出我会仔细阅读并斟酌，“坑”不到。其实也包括写 blog，这个之前已经提过好几次了，写 blog 的核心是梳理自己的思路，而不是为了输出而输出。
最后，说说研究，这个也是我第一次在这个方向上遭遇“坑”。其实之前不是没有搞研究，而是没有这么重度依赖 AI 的搞研究。这次的 case 就是我完全把一个任务丢给他，当时的想法是，数据处理有很多细节和有时候没说清楚或不好说清楚的地方，但算法研究应该还好，于是——掉坑里去了。这中间最主要的原因还在自己，因为我并没有把想法描述的非常非常清楚——其实我也做不到，很多时候，理解是个逐步深入的过程，我很难在一开始就全部说的很清楚，很多细节是代码实现的时候才意识到的。所以，AI 自己发挥，我还完全没有 review，直到我用另一个 AI review 时才发现问题所在。结果就是——大量实验结论不完全可信，浪费了不少时间和资源。更恶心的是，我还得重新阅读代码，仔细确认 bug，然后启动实验对比之前的结果——你看，消耗的时间反而更多了。
本质缺陷
那1%的错误不是偶然的，而是结构性的。不知道大家用 AI 的时候有没有遇到过这个问题，就是很多原则其实在全局配置文件、memory 等多个地方一再强调，他依然不按这些原则来。举个最简单的例子，我明确很多次“写代码优先复用已有逻辑，不要新写”，但很多时候还是需要重新给他强调这一点。这里之所以不新写，是因为大部分已有逻辑我都 review 过，复用这些代码能够让我更加快速 review，而且代码不容易堆成屎山。我其实是想让他在构建系统的过程中不断重构和优化（这点也专门写到规则了）。
另外，如果观察模型中间过程，我们就会发现其实他很多时候很蠢，一个不久前统计过的信息，过几轮再问，他会再重新跑脚本统计一次；而且他用的脚本并不存下来，相当于就是每次都重写脚本。所以对一些常用任务我只好强行让他固化成固定脚本，写好注释，再次执行时直接用已有的代码。
总的来说，用 AI 用的越多，会越感觉这东西和真正的“智能”有距离，他的套路和章法都是有迹可循的。他没办法帮你构建新的 idea，大部分时候还需要人提出方向；他也没办法保证输出 100% 正确，也许 99% 都是对的，但那 1% 可能在某个时间爆掉，让你之前的付出全部打水漂。也就是说，如果你没有真正理解他的逻辑，他未来一定会做出你不理解的行为——这也是种瓜得瓜，种豆得豆。
这些问题简单来说是大模型的幻觉——这个菜市场买菜大妈可能都知道的名词。记得有篇论文研究提到，幻觉是始终伴随着性能提升而存在的，甚至可以说，幻觉可能本身就是“智能”的一部分——但你很菜的时候，不知道就是不知道；当你很聪明的时候，不知道会想办法自己推理。其实 AI 本质上还是“概率匹配”，而非“逻辑理解”，所以 1% 的错误不是偶然的，而是结构性的——往往就发生在边界条件、反常识的创新点等地方。而且，简单的提示词约束其实根本解决不了，反而可能会成为噪声。毕竟，同样一句话在不同情况下可能有不同的意思和理解，提示有时候反而增加困惑。
对抗策略
所以，我个人其实并不喜欢“调教 AI”，“调教” 这个词感觉可能本身就是伪命题。我们早在 23 年提示词最火的时候就明确提出，提示词这个方向一定会消失或称为常态，后面也不会再有“提示词工程师”这种职位。所以，23 年 1 月发表《ChatGPT Prompt工程：设计、实践与思考 | 长琴[3]》后就基本没再写过这个方向的文章（这可能是中文圈第一篇系统性的 prompt 文章，当时有不少人专门找过来）。总而言之，提示词解决不了问题，都只能治标不治本，这只是形式上的约束，没办法解决 LLM 本质的“不理解”。不过，我们也不能完全说它没用，只能说有时候“看起来有用”罢了。
额外多说几句，除了 prompt，去年开始火的 skill 也是类似的，其实就是模块化的 prompt，实在是不知道这东西为啥那么火（不理解，也不太有兴趣去了解）。再就是之前的 MCP，一个数据格式也是莫名其妙的火。这两个本站是完全没碰过了，不过我自己在工作中倒是实现过两个 training-free 的 prompt 优化算法，就是我们在《Training-Free RL：当“训练”不再更新参数，而是更新上下文 | 长琴[4]》中介绍过的 TF-GRPO 和 TRT，前者擅长召回，后者擅长精度，在我们自己的任务上能有 10-20 个点的提升。
回到我开头提到的研究时那个坑，当时是怎么发现问题的呢？我用另一个 AI 模型（codex sol）去 review 了 AI（cc fable5、opus4.8）生成的代码，发现了 bug，然后把 bug 再发送给 cc，他自己也承认了 bug。这就好办了——用另一个非同系列/同厂商的 AI 去 review 其他 AI 生成的代码和方案，让他们之间互相对抗，看起来好像很不错。后来和同事交流，发现大家也都是这样干的，毛病是没啥毛病，就是稍微有点费钱。
其实还有很多策略我们在此前的一些文章（如《以 AI Coding 之管窥探世界之变 | 长琴[5]》、《为了让AI干活儿，我竭尽所能——我的 Vibe Coding 认知升级之路 | 长琴[6]》、《从 OpenClaw 再谈 AI Coding：我们还剩下什么 | 长琴[7]》等）中多多少少都提到过，比如写测试用例、review、smoke、模块化、文档化、多方法验证等等。这里不重复谈这些，只是额外补充一点——理论分析，尤其是算法设计相关工作。其实在深度学习流行之前的机器学习年代，理论分析和公式推导还是比较流行的；不过深度学习流行之后，实验性的论文越来越多。我非常清晰地记得 18 年左右那会儿看论文的感受，就感觉论文越来越像实验报告了，以前比较多的数学公式和推导在论文中出现的次数越来越少了。但其实理论分析依然非常重要，它能指导你的实验设计，也能让你更好地了解自己的训练，包括目标、数据、动力、算法设计等方面。所以，理论分析应该贯穿全过程，便于提前发现明显异常的结果，它可能比实验本身更重要。
人为中心
经历了“试图调教 AI”，到“承认 AI 不可调教”，我终于清晰认识到——必须以自己为中心——你现在敷衍一次，未来 AI 也一定会在某些地方敷衍你一次。这是一种心态上的变化，行为上倒并不一定有很大变化，只是采用不同策略时心理预期会跟着调整。比如，重点工作相关代码，必须亲自 review；探索性的，就让两个 AI 互搏，重点关注互相反馈，有效果时再人工介入。刚刚提到的 review、smoke、assert 这些都是基本操作啦，文档化更是对抗记忆压缩效果下降的最 naive 方法（26 年年初还专门写过《为了让AI干活儿，我竭尽所能——我的 Vibe Coding 认知升级之路 | 长琴[6]》，以及对应的项目 create-vibe-app[8]）。
其实，“以人为中心”还有个有意思的理由，大家应该也发现了，AI 很多时候都比较啰嗦，这里的啰嗦不仅仅是内容上（巴不得什么都给你搞上去），很多时候也是设计上的，就是做很多“不该”或“当下不该”做的设计，尤其是 research 的时候，很容易偏离主线，把事情搞得过于全面和复杂。这其实不是缺陷，但“人工干预收敛”确实也是必要的。而且，AI 写的文档真的看不下去，太长了，内容太多了。我经常开玩笑地说：“AI 写的文档也只能 AI 看，不是给人看的”。有时候 AI 互搏，看他们两个每一轮洋洋洒洒一大堆，很多地方我都看的云里雾里，只能抓主线了，偶尔也会感觉怪怪的（手动狗头）。
不过，也不需要想的太复杂，简单来说就是“掌控感”，这里既指对正在发生的事情了如指掌，也指对项目和系统保持“注意力”，后者更可怕。AI 越来越聪明，人的注意力其实在不知不觉中“脱敏”——狼来了的故事。AI 那种看似合理其实边界偏移的结果不会马上让系统崩溃，这种“无声的污染”可能导致致命的错误。所以，可以预见的是，长尾和黑天鹅迟早会到来，而且会比以往更加频繁和剧烈。这不是危言耸听，历史上每一次重大工程灾难，在发生前都极少有人看到裂缝，现在我们就正处在那条裂缝的边缘。总而言之一句话，要“驾驭 AI”，守住理论直觉，守住核心代码，守住亲自“把控”的权利。“糊弄自己”，而且还是不知不觉中进行的，这可能是当下最值得警惕的“新常态”。
说个题外话，写 blog 也是，如果你有过写作经验，就知道 “写” 和 “读”、甚至 “说” 都是非常不一样的。这个场景下，AI 最适合的是辅助理解（比如某个公式和概念）、资料搜集、整体检查和优化建议。“写” 这个动作应该永远由人来完成，“写”其实不是在“写”，而是在整理思路，在思考，在做不一样的深度理解。虽然我不懂脑科学，但自己的感觉是这个过程会在大脑中有不一样的“印刻”，感觉就是“读一百篇不如写一篇”，所以本站会一直坚守这点，AI 永远会是配角。
再就是，我自己的感觉是，AI 再怎么学习我的写作风格，总还是差点感觉。而且最主要的是，自己少了那种与读者对话的感觉，其实归根结底受损失的自己。这不禁让我想起那个关于守护地球的观点——其实地球压根不在乎环境有多恶劣……
Reference
[1] 当我20天的账单超过4000美元 | 长琴: https://yam.gift/2026/06/06/AI/2026-06-06-Think-AI/
[2] dotfiles: https://github.com/hscspring/dotfiles
[3] ChatGPT Prompt工程：设计、实践与思考 | 长琴: https://yam.gift/2023/01/25/NLP/2023-01-25-ChatGPT-Prompt-Engineering/
[4] Training-Free RL：当“训练”不再更新参数，而是更新上下文 | 长琴: https://yam.gift/2026/03/24/NLP/LLM-Training/2026-03-24-RL-New-Paradigm-Traning-Free/
[5] 以 AI Coding 之管窥探世界之变 | 长琴: https://yam.gift/2026/01/01/AI/2026-01-01-From-AI-Coding-Watch-World-Future/
[6] 为了让AI干活儿，我竭尽所能——我的 Vibe Coding 认知升级之路 | 长琴: https://yam.gift/2026/01/18/AI/2026-01-18-Upgrade-VibeCoding/
[7] 从 OpenClaw 再谈 AI Coding：我们还剩下什么 | 长琴: https://yam.gift/2026/03/13/AI/2026-03-13-From-OpencClaw-to-AI-Coding/
[8] create-vibe-app: https://github.com/hscspring/create-vibe-app