最近在尝试用 Claude Code 和 DeepSeek 辅助一个网游客户端的开发结果被 AI 气笑了好几次。不是那种“哇AI 真厉害”的笑而是那种“你认真的吗这也能错”的苦笑。这让我意识到把 AI 当“代码生成器”用和把它当“开发伙伴”用完全是两回事。前者你只关心它吐出来的代码能不能跑后者你得学会和它沟通、协作甚至“吵架”。很多人觉得AI 辅助编程就是复制需求、粘贴代码、运行成功。但真实情况是你可能会遇到AI 写了一段看似完美的逻辑结果漏掉了关键的状态判断AI 生成了一个复杂的 UI 组件但交互逻辑和你的游戏框架完全不兼容AI 帮你重构了代码结果性能反而下降了。问题不在于 AI 不够强而在于我们默认它“应该懂”却忘了告诉它“上下文”和“边界”。所以与其抱怨 AI 不靠谱不如聊聊怎么让它变得靠谱。这篇文章不是要教你用哪个 AI 写代码最快而是想分享一套从“被气笑”到“能协作”的工作流。核心就一句话把 AI 当成一个需要明确需求、清晰上下文和持续反馈的初级开发伙伴而不是一个全知全能的代码许愿机。1. 为什么 Claude Code 和 DeepSeek 会把你“气笑”先别急着怪模型。很多时候问题出在我们给它的“任务包”上。AI 没有项目经验没有对代码库的长期记忆更没有对“游戏开发”这个领域的常识性理解。它只能基于你给的提示词和它训练数据中的模式来生成代码。1.1 典型“气笑”场景还原假设你在开发一个网游的背包系统需要实现一个物品拖拽交换位置的功能。你给的提示词可能是“用 Unity C# 写一个背包格子物品拖拽交换的脚本。”AI 可能会给你一个这样的“教科书”实现public class InventorySlot : MonoBehaviour, IDragHandler, IBeginDragHandler, IEndDragHandler { public Image itemIcon; private GameObject draggingIcon; private Vector3 startPosition; public void OnBeginDrag(PointerEventData eventData) { draggingIcon Instantiate(itemIcon.gameObject, transform); draggingIcon.transform.SetParent(transform.root); // ... 省略 } public void OnDrag(PointerEventData eventData) { draggingIcon.transform.position eventData.position; } public void OnEndDrag(PointerEventData eventData) { // 简单销毁 Destroy(draggingIcon); // 这里缺少关键的交换逻辑判断 } }然后你就笑了。为什么因为这个脚本只实现了“拖拽视觉反馈”但最核心的交换逻辑判断判断拖拽到了哪个格子、两个格子物品是否可交换、交换后的数据同步、网络通信等完全没写。AI 把“拖拽交换”理解成了一个纯粹的 UI 交互动画。更深层的问题在于缺少上下文AI 不知道你的背包数据是ListItem还是字典不知道物品有唯一 ID不知道有“绑定物品不可交易”的规则。缺少边界条件AI 没考虑拖拽到背包外、拖拽到无效区域、快速连续点击、网络延迟下的状态同步。缺少架构约束AI 不知道你的项目用了 MVC、ECS 还是别的模式这个脚本应该放在 View 层还是 Controller 层1.2 AI 的“思维”局限与我们的应对策略AI 本质上是“模式匹配”和“概率生成”。它擅长根据海量代码学到的“套路”来组合代码片段但它不理解业务它不知道“网游背包”和“电商购物车”在数据一致性、网络同步上的根本区别。没有长期记忆它不会记住你 10 分钟前告诉它的项目架构。倾向于生成“平均”解它会给出最常见、最通用的实现而不是最适合你特定场景的“最优”解。所以被“气笑”是常态。但我们可以通过改进交互方式大幅降低被气的频率提升协作效率。2. 从“模糊需求”到“精确指令”如何给 AI 写提示词别再问“怎么写一个 XX 系统”了。那等于让一个新人开发直接去造火箭。我们要做的是拆解任务提供上下文明确约束。2.1 结构化提示词模板一个高效的提示词应该包含以下几个部分角色与目标告诉 AI 它现在是谁要达成什么最终目标。上下文信息提供必要的背景比如项目类型、框架、关键类。具体任务清晰、无歧义地描述要它做什么。输入与输出明确输入数据的格式和期望输出的代码格式、函数签名等。约束与要求性能、规范、禁止事项、必须使用的模式等。示例可选给一个类似的小例子让它理解你的风格。2.2 实战案例重写背包拖拽交换让我们用上面的模板重新给 AI比如 Claude Code下指令角色与目标你是一个经验丰富的 Unity 网游客户端开发工程师。目标是编写一个稳健的背包物品拖拽交换功能。上下文信息项目使用 C# 和 Unity UI (UGUI)。背包数据由InventoryManager单例管理它有一个Dictionaryint, ItemData存储所有格子数据Key 是格子索引 (0-35)。ItemData类包含itemId,count,isBound等属性。UI 层面每个背包格子是一个InventorySlotUI预制体。具体任务请实现InventorySlotUI脚本中的拖拽逻辑。需要完整处理拖拽开始、拖拽中、拖拽结束三个事件。核心是在OnEndDrag时判断拖拽释放位置下的 UI 元素是否是另一个InventorySlotUI如果是则向InventoryManager请求交换这两个格子的数据。输入与输出输入用户的拖拽操作事件。 输出一个完整的 C# 脚本包含必要的命名空间引用、类定义、事件接口实现以及调用InventoryManager.Instance.SwapSlots(int fromIndex, int toIndex)方法的逻辑。约束与要求遵循 Unity 的IDragHandler等事件接口规范。拖拽开始时需要创建一个临时图标跟随鼠标但不要直接操作原物品图标。必须检查目标格子是否有效存在、非空、物品可交换。考虑性能使用对象池管理临时拖拽图标。代码需包含简要注释。禁止在 UI 脚本中直接修改InventoryManager的底层数据字典所有数据操作必须通过管理器的方法。示例如果风格重要可以参考项目中ShopItemUI的点击购买逻辑它也是通过ShopManager.Instance.Purchase(itemId)来操作的。这样一套提示词下去AI 生成的代码质量会天差地别。它知道了数据在哪、怎么访问、有什么规则、要注意什么。虽然可能还需要微调但至少基础框架和关键逻辑点都覆盖到了。3. 进阶协作让 AI 参与设计、调试与重构一旦掌握了基础指令就可以让 AI 承担更复杂的角色。3.1 设计评审与方案咨询不要直接让 AI 写代码先让它出方案。比如“我需要在 Unity 里实现一个带冷却时间的技能按钮。要求1. 点击触发技能。2. 进入冷却时按钮不可交互并有环形填充或数字倒计时。3. 冷却时间可从配置表读取。4. 需要考虑多个技能同时冷却的管理。请给我 2-3 种不同的实现方案并分析每种方案的优缺点如性能、可维护性、扩展性。”AI 可能会给出基于Coroutine的方案、基于Update计时器的方案、使用DOTween插件的方案等。你可以基于它的分析结合项目实际情况做选择然后再让它实现你选中的方案。3.2 化身“调试助手”遇到诡异 Bug 时把错误信息、相关代码片段、你的排查思路喂给 AI。“这段技能伤害计算代码在服务器和客户端结果不一致。服务器用int计算客户端用float。这是代码片段。我怀疑是浮点数精度问题或者计算顺序不同。请帮我分析可能的原因并给出修复建议确保两端确定性计算。”AI 可以快速指出float运算的不确定性建议改用decimal或固定精度数学库或者统一计算顺序。3.3 代码重构与优化让 AI 审查代码并提出优化建议。“以下是我的敌人 AI 状态机部分代码。我感觉Update里分支太多性能可能有问题而且新增状态很麻烦。请分析当前代码的问题并建议一种更好的模式比如状态模式、行为树并简要说明重构思路。”AI 可能会指出大量if-else导致的可维护性问题并给出状态模式的基本结构图甚至帮你把现有逻辑映射到新框架的伪代码。4. 避坑指南与 AI 协作时必须守住的底线AI 很强大但不能无脑信任。以下几个原则能帮你避免重大失误。4.1 核心业务逻辑必须亲手掌控AI 可以写工具类、写 UI 绑定、写数据解析但像战斗公式、经济系统、关键任务流程这些核心业务逻辑一定要自己写或者至少极度仔细地审查 AI 生成的每一行代码。AI 不理解“平衡性”和“游戏性”。4.2 永远进行“冒烟测试”AI 生成的代码无论看起来多完美永远不要直接提交到主分支。必须创建一个临时分支运行最基本的测试编译通过吗能正常启动/初始化吗执行核心功能不报错吗用极端值空值、超大值、负值测试一下会崩溃吗4.3 警惕“依赖幻觉”和“版本陷阱”AI 可能会使用一些它“认为”存在的方法或类。比如它生成的代码里调用了YourGame.Manager.Instance.SwapItems()但你的项目里可能叫GameInventory.Swap。AI 是在“编造”你的项目结构。务必手动检查所有外部引用。 同样AI 推荐的 NuGet 包、Unity 插件版本可能过时或与你的项目不兼容。所有依赖变更必须人工核实。4.4 代码风格与规范需要持续对齐如果你不加以约束AI 生成的代码风格可能是混杂的。你需要在提示词中明确要求“使用 C# 的var关键字。方法名使用 PascalCase局部变量使用 camelCase。大括号换行使用 Allman 风格。异步方法使用async/await模式。”或者更好的方法是让 AI 去学习你项目中已有的代码风格。你可以粘贴一段你的标准代码然后说“请按照与此代码相同的风格和规范进行编写。”5. 构建你的“AI 辅助开发”可持续工作流单次使用 AI 是手工作业把它融入日常流程才能形成生产力。5.1 分层使用策略根据任务复杂度决定 AI 的参与深度任务类型AI 参与度你的角色样板代码(DTO简单UI绑定)高 (90%)提供数据结构检查输出通用算法/工具函数(排序查找日期处理)高 (80%)定义输入输出测试边界模块实现(背包商城邮件)中 (60%)提供详细设计编写核心业务让AI填充分支逻辑系统架构/核心机制(网络同步状态机)低 (20%)主导设计让AI提供备选方案或评审调试与优化中 (50%)提供错误上下文让AI分析可能原因自己验证5.2 建立“上下文缓存”和 AI 对话的一大成本是反复交代背景。你可以这样做为每个功能模块创建一个独立的对话Claude 有对话线程DeepSeek 可以开启新对话。在对话开头一次性粘贴或上传相关的核心类定义、接口、配置文件结构。后续所有关于这个模块的讨论都基于这个对话进行。AI 会更好地保持上下文一致性。5.3 迭代与反馈循环不要期望一次成功。把和 AI 的协作看成“迭代开发”第一轮给出详细提示词获得初版代码。第二轮运行测试发现 Bug 或不符合预期的地方。将错误信息、你的分析和修改要求反馈给 AI。第三轮AI 修正。你进行集成测试看是否与其他模块冲突。第四轮可能需要性能优化或代码风格调整。这个过程本身就是一种高效的代码审查和逻辑梳理。被 AI“气笑”不是终点而是一个信号提醒我们换一种方式与它对话。从“模糊的许愿”转向“精确的工程指令”从“被动的代码接收者”转向“主动的架构师与审查者”。当你开始习惯为 AI 描述上下文、划定边界、设计验收标准时你会发现它不再是那个偶尔犯傻的“实习生”而逐渐变成了一个不知疲倦、知识渊博、随叫随到的“高级助手”。那个气笑你的瞬间最终会变成你会心一笑的默契。