半年，从复制粘贴到Agent管项目

2025年11月，我打开DeepSeek网页端，把我的模组代码一段段复制进去，问它“这段逻辑哪里有问题”，等它生成修改建议，再复制回来粘贴到IDE里。遇到报错就把错误日志再复制过去，来回往复。我觉得自己挺高效的。

2026年8月，我盯着屏幕上DeepSeek Harness的对话框发呆。基于Kimi K3的多个子agent同时在维护我的模组在多个游戏版本和不同加载器上的更新。我只需要在关键节点确认一下方向，剩下的全是agent自己干。

一、复制粘贴时代

回想2025年底的模组开发流程，最让我印象深刻的不是它有多慢，而是它有多浪费精力。

一个典型的开发日下午是这样的：上午看到社区发现了新bug或需求，下午开始做。打开IDE，另一个窗口开着DeepSeek网页端。把出错的代码块复制进去，告诉AI：“这段代码在游戏启动时抛出异常，请分析可能的原因……”等它输出，觉得有道理，再把代码复制回来。跑一遍测试，没解决，就把新的错误日志再复制回去。如此循环。

后来我发现Kimi对游戏模组开发理解更准确，于是又把所有问题搬到Kimi上去问。我像一个在不同AI网站之间来回跑腿的快递员，DeepSeek管Java语法，Kimi管游戏逻辑，遇到复杂问题还得两边问完对比答案。

整个下午，我的核心工作不是设计模组玩法，而是搬运代码和错误日志。

我的价值体现在“我能把需求准确地转述给AI”以及“我能判断AI输出的代码对不对”。前者是机械劳动，后者才是真正的开发能力，但后者只占了我不到20%的时间。

这就像工业革命前夕的手工作坊——你以为自己在使用工具，其实工具在使用你的时间。

二、当下载量开始增加

2026年初，玩家多了，反馈也多了，bug不断出现。不同的玩家用不同的游戏版本、不同的模组加载器，每一个环境组合都可能出现不同的问题，而开发者只有我一个。

那种压力下的无力感，我到现在还记得。按照原来那种复制粘贴的工作方式，我可能连bug都修不完，更别说开发新内容了。

好在那时候各家agent工具开始爆发式迭代。我先后试了Claude Code、Codex、Trae、Pi等各家agent，Opus、GPT、Deepseek、Kimi、MiniMax等模型。直到现在使用DeepSeek Harness+Kimi K3。

由K3构建的多端多版本同步更新：

从此，我不再是“用AI辅助写代码的人”，而变成了“管理agent开发模组的人”。

三、除了效率

以前我一次只能修一个版本的问题，一个新的bug往往需要在多个游戏版本（1.19.3、1.20.1、1.21.1）的多个加载器（fabric、forge、neoforge）中同步修复，切换版本又需要重新加载环境、重新定位代码、重新进入状态。现在我同时管理多个版本的模组更新，agent在维护一个版本时，我在审核另一个版本的改动，同时其他版本的更新agent在各自跑各自的流程。

我的精力从“写代码”转移到了“调度”和“决策”。

现在我的大部分精力花在“判断对不对”和“想清楚下一步做什么”——这个新功能的交互设计是否合理？agent提出的优化方案会不会引入新问题？下个版本应该优先做什么内容？

agent把大部分执行工作扛走了，我终于有空去处理玩家反馈里那些建议，去考虑模组的整体平衡性，去规划我一直想做的新内容。

我意外地找回了“做游戏”的乐趣。

四、发展速度

2025年，我在用DeepSeek网页端问Java语法问题，用代码补全工具做简单的补全，用AI笔记软件管理开发计划。那时候我已经觉得自己“全面拥抱AI开发”了。

但仅仅过了半年多，这些行为在今天的我看来，就像拿着算盘做微积分一样。

这也让我意识到我们对“未来工作方式”的想象，永远赶不上工具迭代的速度。

2025年我们讨论的是“AI能不能帮程序员写代码”，2026年我们讨论的是“一个人用agent能同时维护多少个版本”。问题本身已经变了，前一个问题的答案是“能，但需要人来判断”，后一个问题的答案是“取决于你搭agent的能力和判断力”。

而2027年，可能连“版本适配”这个概念都会被AI重新定义。

这个速度意味着任何基于“当前工具形态”制定的职业规划，都有可能在落地之前就已经过时。

最后

从2025年11月的第一行代码，到现在2026年9月，模组下载量接近五十万，多个版本的更新还在持续。也许几个月后，agent的形态又会发生翻天覆地的变化，也许某些我现在赖以生存的技能会再次过时。不论如何，我们无法阻止这一切，也无需阻止。