taptapmaker项目重构记录

1 小时前12 浏览综合

前言

我是专业程序员出身，在跟塔拉拉合作重构项目这么久以来，就一个感受：

塔拉拉懂的很多，啥都会（写） [心动小镇_点赞]

塔拉拉水平堪忧，啥都不会（用） [心动小镇_汗]

一句话概括，塔拉拉就是个学历顶尖但极缺项目经验的博士外包实习生

总结一下我现在工作模式和原则：

新模块新系统写好提示词给塔拉拉

等待塔拉拉执行任务时，拉取塔拉拉上传的项目代码进行review（审查）

出现bug先让塔修，超过3分钟仍在分析而没有具体方案，则立即中断，并要求上传代码，展示相关逻辑所在脚本行数，拉取代码后自己分析原因

如果bug出现原因难以单纯从代码判断，则自己添加调试语句，让塔拉拉pull并build

如果bug背后是让人恶心的屎山架构（最经典的就是每帧重建UI），那么新开对话，要求给出相关系统的完整调用链，然后三步走：问清现有逻辑，给出重构方案让塔分析可行性，撰写任务明确且修改闭环的重构提示词

塔拉拉的回复中关于“bug已修复”，“所有路径均检查”，“找到了根因”这种话，在我看来置信度只有50%，一切以游戏运行情况和代码实现细节为准.

项目文档中不再记录物品配置表，物品配置表通过项目代码中直接引用的Config.lua回顾与修改，游戏实现细节自己记着就行，实在忘了就开游戏试一下，除非有向上汇报人或者在其他人面前炫耀，独立开发中的游戏策划文档完全没有存在的意义，塔拉拉记不住，自己又没空维护

在撰写提示词时尽可能减少额外理解成本和规则，不要指望能告诉塔拉拉一些规则来简化自己以后的需求表达，浪费token还不一定奏效。举个例子，我经常让塔拉拉pull和build，有时候我会想能不能定义一个/pb的命令来指代整个操作，但这种看似提效但写不进塔拉拉的系统提示词的规则，完全就是废纸合同，不如每次都把意思完整表达清楚

开发系统和功能或者UI时，有意识的去为每个模块或控件指定命名且之后在修改相关内容的时候严格按照命名去写提示词。例如开发左上角的信息状态面板，那么以后如果要改这个面板的内容时严格使用“信息状态面板“这个命名代指，撰写提示词时不会再出现”血条面板“，”左上角展示部分“这种需要额外理解的关键词

（能想到的细节就这么多）

重构记录碎片

下面记录一下做项目时候遇到的一些经典问题和交流提示词（列举会比较随意，翻到哪记录到哪，顺序不分先后）

温馨提示：专业术语和主观表达可能会比较多，如果没有涉猎相关领域，建议凭感觉观看，不要过度分析

对话背景：塔拉拉的代码里对于每个窗口的打开和关闭均往全局控制器里塞showXXX状态变量，什么showBackpack，showItemDetail，然后在每帧更新的时候全部判断一遍，而且每个窗口均十分离散，耦合混乱，缺乏统一管理。

对话背景：我的项目对于“基地”和“关卡”两个场景有明确的边界，在关卡中是不存档的，只有当玩家完成关卡回到基地时才会应用玩家数据的变化。但塔拉拉对此没有做分离，在基地和在关卡操作和取用同一份存档数据，如果玩家在关卡中掉线，存档的变化会十分不可控。

对话背景：review代码的时候发现代码在基地访问了进入关卡才会构建的数据模型，为了快速理解这段代码所牵扯到的其他逻辑，这里选择直接问塔拉拉。

对话背景：最让我感到恶心的写法，我完全无法理解UI这种东西为什么要每帧构建和检测数据变化，通常都是MVC或者MVVM以数据驱动或者以事件驱动，塔拉拉这么写会导致游戏主循环和UI的更新之间有很高耦合，且要开发新的UI需求需要在本不该访问的脚本中加一大堆状态变量。又费性能又难维护又没有可读性又容易出bug

对话背景：我是真不知道塔拉拉是聪明还是偷懒，由于基地数据和关卡数据的分离，我的思路是单独管理一份存档的备份，在关卡阶段只操作这个备份。但是塔拉拉的操作是在进入关卡时通过setmetatable拦截的方式偷偷把存档的独写逻辑改为备份的独写，然后退出关卡的时候再偷偷撤回这个拦截，在外界看来就是在直接独写同一份存档。setmetatable这种改元表的写法是解释性语言的特殊技能，他很方便用来偷偷修改调用链，但是后面要是出了bug，找原因的时候会被这玩意整疯，因为setmetatable干的事极其难以追踪。

对话背景：分析调用链，分析耦合/相关逻辑这两个是我比较常用的两种提问方式，前者分析逻辑深度，后者分析逻辑广度，当出现bug需要修改时候，以造成bug的代码为中心进行相关搜索和提问，能快速确定哪些能改，哪些不能改，改了会对哪些有影响，对哪些没有影响。在有大重构需求之前基本都会问清楚这些情况。

对话背景：由于窗口UI进行了规范化和重构，但是有部分UI即便表面接入了UI管理器，但实际用法并非寻常的调用逻辑。出现bug后让塔拉拉自己修，他说修好了，但实际上bug依旧，这边是我自己根据代码针对性的对这几个窗口制定重构方案，直接让塔拉拉执行。

对话背景：同样是代码review过程中闻到了”臭代码“的味道，一般做数据动效的时候UI展示数据才有硬性要求要用缓存，其他情况只是更新的话都是直接从游戏的最权威的数据中心读取最新数据，所以这里问了为什么要用缓存，而且他这个缓存还是整个数据中心的全量缓存。塔拉拉的回答看起来似乎没有问题，缓存确实能减少每帧读model的开销。但问题不在这，问题在于为什么要每帧读model，这本身就引出了上面几条记录所述的每帧构建UI的框架性问题，如果对项目的整体技术架构没有把控，这种隐患完全无法察觉

暂时就先记录这么多，这项目重构至少也有两星期了，如果按照”只实现用户提的功能要求就完事“的原则去开发新功能和打补丁，项目根本支撑不起后面天马行空的想法和更新，这也就是大多数开发者感到无力的原因，出了bug，塔拉拉也修不好，自己也无从下手。

代码实现本来就只能满足一时的需求，要扩展项目规模离不开重构，但是重构这个事如果开发者不提，塔拉拉是不会做的，而且塔拉拉也没有思路去做，他只会根据当前这个充满补丁的架构继续实现开发者的需求。然而开发者的想法本身是不可能有所谓的框架的（不然哪来的创新），塔拉拉做不了重构，为了实现需求只能继续堆屎，项目只有两种结局，要么赶紧闭环上架，要么直接停摆。

感受与建议

AI的认知负债来自哪里？

塔拉拉做游戏很快，这点毋庸置疑，如果相同的游戏我自己开发，可能要花费三四倍的时间。但同时我又在想，本来要花费一天才能实现的系统和功能，凭啥靠塔拉拉一小时就搞定了？

如果是我自己作为程序去做这个事情，大概是：30%的架构+30%的编码+20%的为粗心买单+20%的纠结，其中20%的纠结是为了避免屎山的出现。而对于AI而言，要做这个系统功能大概是：40%意图分析和需求整理+40%的编码+15%的系统提示词约束+5%的输出格式化。而也许我在纠结那20%的代码怎么写的时候，塔拉拉已经跑完了这100%。

但是如果是开发一个玩法明确，机制清晰，各种细节全部有参考且敲定的项目，我的开发速度大概还能跟开发创新项目的塔拉拉有的一拼。

总结下来，塔拉拉快是因为人类的两样东西他没有：注意力机制，责任心

AI究竟是何种角色？

大家对taptap制造的热情感觉最近冷却了不少，一方面是因为“随手做好玩游戏”的幻灭，一方面是作品堆积导致官方政策缩紧知难而退，一方面也是tap制造暴露的优缺点筛除了大部分抱着侥幸和不切实际的幻想而来的开发者。我在使用tapmaker的时候也屡次气的想砸桌子（尤其是他自己写的代码自己还能误解的时候），但我只能说，这大概就是AI的脾性，毕竟AI是不吃压力和pua这一套的，他也因此无法背负任何责任，他顶多算个没有灵魂的npc，出了任何问题都只能从开发者自身去解决。

市面上AI产品千千万万，市场也趋于成熟，但是感觉人们对于AI的认知并不完善，AI能做什么，做不了什么，哪些事情需要人介入，哪些事情就不该抱有期待，大家还是无法描摹出一张清晰的图谱。但就我认识而言，真正能决定AI怎么做的是他底层大模型的运行规则，其次是AI产品包装时注入的系统提示词，“以后面板都按照这个样式”，“每次更新功能都要修改xx文档”，“每次实现需求时都先制定计划并向我询问，在我同意前禁止执行”这些话，全部都只是只有局部效应的参数而已，无法修改AI的执行准则本身。AI的思维模式和思考惯性我们作为AI产品的用户无法决定，只能适应。AI听不懂只能尝试另一种更清晰的表达，而不是强调和解释他该如何理解这句话。