AI协作开发实战：Claude 3.5 Sonnet中医游戏项目翻车启示录

1. 项目缘起当Claude遇上中医游戏最近我一直在琢磨怎么把AI工具真正用起来而不是停留在“调戏ChatGPT”的层面。正好Anthropic新推出的Claude 3.5 Sonnet模型特别是那个“Claude Teammate”协作模式号称能像一个真正的队友一样和你一起规划、编码、调试完成一个完整的项目。这听起来太诱人了我决定用它来搞点有意思的——开发一个中医主题的互动小游戏。我的想法很简单但很有挑战性做一个基于Web的“中医体质辨识与养生建议”游戏。用户通过回答一系列关于生活习惯、身体感受的问题游戏会判断其属于九种基本体质如平和质、气虚质、阳虚质等中的哪一种并给出个性化的、有趣的养生小贴士和虚拟互动。这玩意儿既有文化传播价值又有一定的实用性和趣味性。然而理想很丰满现实却让我翻了车。这次和Claude Teammate的深度合作与其说是一次顺畅的开发之旅不如说是一场关于AI协作边界、知识准确性和项目管理的生动实验。整个过程充满了惊喜、困惑和哭笑不得的瞬间也让我对“AI作为队友”这件事有了更深刻、更接地气的认识。2. 项目蓝图与Claude Teammate的“雄心壮志”2.1 初始构想与技术栈规划我的核心需求是快速验证想法因此技术栈选择了最经典、最易上手的组合前端用Vue 3 ViteUI库用Element Plus后端逻辑为了简化直接打算用Node.js写个简单的本地服务或者甚至前期用纯前端JSON数据模拟。数据库都先不考虑体质判定规则和养生知识库打算硬编码在代码里。我把这个想法丢给了Claude Teammate。它的反应非常积极立刻生成了一份详尽的“项目计划书”项目阶段划分需求分析 - 技术选型 - 数据库设计 - 前后端开发 - 测试部署。详细功能模块用户问卷模块、体质判定算法模块、知识库模块、结果展示与互动模块。甚至给出了“甘特图”式的开发排期精确到了天。看着这份计划我第一感觉是专业这AI队友也太靠谱了考虑得比我还周全。它甚至主动建议“为了确保中医知识的准确性我们应该建立一个结构化的知识图谱将体质、症状、药材、穴位关联起来。” 这个建议听起来非常高级让我对项目前景充满了不切实际的幻想。注意这是与AI协作的第一个“甜蜜陷阱”。AI倾向于生成结构完美、看似专业的计划但这往往基于其训练数据中的通用项目模板可能严重脱离当前项目的实际复杂度、资源尤其是你的时间精力和核心目标快速原型验证。2.2 第一个分歧知识库的“深度”与“可行性”Claude开始兴致勃勃地设计“中医知识图谱”的数据库Schema。它给出了一个包含七八个表的ER图雏形Constitution体质表Symptom症状表Herb中药材表Acupoint穴位表Recipe药膳方表以及它们之间多对多的关系表。它解释道“这样我们可以实现灵活的查询比如‘气虚质伴有失眠症状推荐什么药膳和穴位按摩’”我立刻叫停了。我提醒它“哥们我们这是个小游戏第一个版本的目标是‘跑通流程界面好看判定基本靠谱’。你这个知识图谱工程量太大了而且最关键的是——我们哪里去搞这么多准确、结构化、无版权争议的中医数据难道要你和我一本本《黄帝内经》去翻吗”Claude Teammate沉默思考了几秒回复道“您说得对。我们可以采用简化方案。我建议先聚焦九种体质每种体质预定义一组典型症状5-8条、养生原则3条和推荐食药材3-5种。这些数据我们可以从公开、权威的中医科普资料中摘要整理并以JSON格式存储。”这里学到了第一课必须给AI设定明确、具体、可执行的边界。要不断把它从“宏伟蓝图”拉回“最小可行产品”的现实中。它的优势是提供选择和思路但决策权必须牢牢掌握在人类手中尤其是关于项目范围和资源投入的决策。3. 核心开发AI编码的“神操作”与“鬼打墙”3.1 前端问卷模块高效与僵化并存进入编码阶段Claude在生成基础框架和样板代码方面展现了惊人的效率。我让它“创建一个Vue 3组件展示一个中医体质问卷问题列表从JSON中读取使用Element Plus的Radio组件作为单选”。它几乎在瞬间就给出了一个非常漂亮的Questionnaire.vue组件代码结构清晰样式也搭配得不错。它甚至主动添加了进度条、上一题/下一题按钮和简单的表单验证。template div classquestionnaire-container el-steps :activecurrentStep finish-statussuccess simple el-step v-for(q, index) in questions :keyq.id :titleQ${index 1} / /el-steps div v-ifcurrentQuestion classquestion-card h3{{ currentQuestion.text }}/h3 el-radio-group v-modelanswers[currentQuestion.id] changehandleAnswerChange el-radio v-foroption in currentQuestion.options :keyoption.value :labeloption.value border {{ option.text }} /el-radio /el-radio-group /div div classaction-buttons el-button :disabledcurrentStep 0 clickprevQuestion上一题/el-button el-button typeprimary :disabled!answers[currentQuestion.id] clicknextQuestion {{ currentStep questions.length - 1 ? 提交问卷 : 下一题 }} /el-button /div /div /template script setup import { ref, computed } from vue; import questionsData from /data/questions.json; // 假设的问卷数据 const questions ref(questionsData); const currentStep ref(0); const answers ref({}); const currentQuestion computed(() questions.value[currentStep.value]); const handleAnswerChange (val) { console.log(问题 ${currentQuestion.value.id} 答案:, val); }; const prevQuestion () { if (currentStep.value 0) currentStep.value--; }; const nextQuestion () { if (currentStep.value questions.value.length - 1) { currentStep.value; } else { submitQuestionnaire(); } }; const submitQuestionnaire () { console.log(提交答案:, answers.value); // 这里触发体质判定逻辑 }; /script这部分合作非常愉快。但问题很快出现当我想修改交互细节时比如“希望选项不是垂直排列而是水平排列并且选中后有更明显的视觉反馈”Claude给出的修改建议有时会“用力过猛”。它可能会建议引入一个新的UI组件库或者写一段复杂的CSS Grid布局而实际上可能只需要给el-radio组件加一个style属性或修改一个已有的CSS类。实操心得在让AI生成代码后对于具体的样式和微交互调整往往自己直接动手改更快。AI擅长从0到1搭建框架但在从1到1.5的精细调整上沟通成本可能高于手动成本。你需要明确告诉它“在现有代码基础上只修改XX部分目标是达到YY效果请给出最简洁的修改方案。”3.2 体质判定算法逻辑的“严谨”与知识的“幻觉”这是本次翻车的重灾区。我要求Claude实现判定算法根据用户对20个问题的答案每个答案对应某种体质的倾向分计算九种体质的得分取最高分者为主要体质并可以给出兼夹体质的判断。Claude很快写出了算法函数逻辑看起来严丝合缝。但当我开始审查它预定义的“问题-体质”得分映射表时问题来了。我发现在questions.json里有一个问题是“您容易失眠吗” 选项有“从不”、“偶尔”、“经常”。Claude给“经常”这个选项的得分映射是{ 阴虚质: 3, 气虚质: 2, 痰湿质: 1 }。我觉得有点不对劲。凭我有限的中医知识失眠确实与阴虚火旺阴虚质关系密切但“气虚质”和“痰湿质”也会导致失眠吗我让Claude提供这个得分映射的出处或依据。Claude的回答开始变得模糊“根据一般性中医理论气虚可能导致心神失养痰湿可能阻滞气机影响心神从而引发失眠。这是一个简化的模型旨在体现体质的复杂性。”我继续追问“请提供具体的经典中医文献或公认的现代教材中明确指出‘气虚质’和‘痰湿质’是失眠主要证型的依据。”这时Claude表现出了AI在专业领域尤其是像中医这样充满辩证、非标准化知识的领域的典型弱点——自信地生成看似合理但缺乏坚实依据的内容。它可能会混合一些正确的知识阴虚致失眠然后用推理和概率生成来填补空白气虚、痰湿也可能有关联并将结果以确定性的口吻呈现出来。致命陷阱AI在专业领域极易产生“知识幻觉”。它生成的“知识”可能是基于语言模式拼凑的而非经过验证的事实。对于中医、法律、医疗等严肃领域AI只能作为灵感来源或初稿生成器其输出必须由领域专家严格审核。我不得不暂停开发亲自去查阅《中医体质分类与判定》标准以及一些权威的中医诊断学教材。结果证实了我的怀疑在该标准中失眠确实是阴虚质的主要判定条目之一但与气虚质、痰湿质的典型症状关联很弱。Claude的“简化模型”在专业上是站不住脚的如果按此上线会误导用户。翻车点总结我们花了大量时间在“纠正AI生成的知识性错误”上而不是在推进开发。我不得不亲自扮演“领域专家”和“事实核查员”的角色重新梳理所有20个问题、54个选项20*3假设每个问题3个选项与9种体质的对应关系。这是一个极其枯燥且容易出错的过程。3.3 后端逻辑与“过度设计”在搞定或者说绕过复杂的知识准确性验证后我们进入简单的后端逻辑。我说“写一个Node.js的Express服务提供一个POST接口/api/evaluate接收答案JSON调用我们刚才写的判定函数返回体质结果和养生建议。”Claude的“队友”属性又开始发挥作用。它建议“为了更好的可维护性和未来扩展我们应该将判定算法、知识库数据访问封装成独立的服务层。同时接口应该加入请求验证、错误处理中间件并使用环境变量管理配置。考虑到未来用户量我们可以先集成一个轻量级缓存比如node-cache。”听着又很有道理对吧但我们的用户量预期是我以及可能分享给几个朋友看看。这个“未来扩展”在可预见的半年内都不存在。我再次拒绝了这套“企业级”方案坚持只写一个最简单的、直通式的路由处理函数。Claude虽然照做了但生成的代码里依然残留着一些“过度设计”的痕迹比如尝试用joi库做复杂的请求体验证而我只需要检查answers对象是否存在。经验之谈AI基于海量开源项目训练其“最佳实践”往往是面向有一定规模、长期维护的项目。对于个人快速原型、一次性脚本或内部小工具这些“最佳实践”可能变成“过度工程”。开发者必须清晰判断当前项目所处的阶段敢于对AI说“不我们这次就用最简单粗暴的方式”。4. 翻车总结与“人机协作”模式反思项目最终并没有以我理想中的完整游戏形态上线。它停留在一个能跑通问卷、给出一个基于我手动校正过的、相对靠谱的体质判定结果的半成品。主要的“翻车”并不在技术实现而在以下几个方面4.1 翻车点深度剖析知识准确性鸿沟这是最大的坑。AI包括Claude 3.5在需要深度、专业、非标准化领域知识如中医的场景下是极不可靠的“专家”。它会创造知识而不是检索知识。任何涉及专业判断的内容必须由人类专家把关。沟通与上下文损耗尽管Claude Teammate有长上下文但在复杂的、多轮的项目讨论中它仍然会“忘记”或“混淆”之前设定的约束条件比如“我们不做知识图谱”或者在新的对话分支中回到默认的“宏大叙事”模式。需要不断重复强调核心约束。效率悖论在某些环节如生成样板代码、编写工具函数效率提升巨大但在另一些环节如纠正知识错误、讨论具体交互细节效率反而降低因为你需要花时间理解AI的提议、判断其合理性、并给出更精确的指令。创造性瓶颈AI能基于已有模式组合创新但难以实现真正的“游戏性”突破。当我让它为“阳虚质”的结果页面设计一个有趣的互动小动画或游戏时它的建议无非是“一个慢慢变温暖的太阳图标”、“一个进度条显示阳气提升”缺乏让人眼前一亮的设计。4.2 如何更有效地与AI Teammate协作经过这次翻车我总结出一些更务实的人机协作模式明确角色定位AI是“超级实习生”或“初级工程师”不是“架构师”或“领域专家”。让它负责执行明确、具体的任务而不是做高层次决策。任务拆解要极致粒度化不要给“开发一个中医游戏”这种指令。要拆解成“根据这个JSON结构生成一个Vue 3的问卷组件要求有进度条和单选按钮。”“这里有一个体质判定算法的JavaScript函数框架请根据这份映射表我提供补全计分逻辑。”“为‘平和质’的结果页面写一段鼓励性的、轻松幽默的文案。”自己掌握核心逻辑与数据像体质判定规则、养生建议文案、游戏核心玩法逻辑这些体现项目独特价值和专业性的部分必须自己亲手编写或严格审核。AI只负责将其转化为代码语法。建立“审核-修正”循环对AI生成的任何代码、文案、设计都要带着批判性思维审查。特别是涉及业务逻辑、专业知识和用户体验的部分。发现问题后不是自己重写而是给AI清晰的修正指令“这个函数有BUG当输入为null时会崩溃请加入空值检查并返回默认值。”善用其“搜索引擎”和“灵感激发”功能当你卡在某个技术实现细节时可以问“用Canvas实现一个粒子逐渐汇聚成中医太极图的效果有哪些常见的实现思路” 它能快速给你几个方向你再选择其中一个深入。4.3 给想用AI协作开发者的真心话Claude Teammate以及类似的AI编程助手是强大的“力量倍增器”但它不会取代开发者而是会改变开发的工作流。它把开发者从大量的重复性、模式化编码中解放出来但也对开发者提出了更高的要求要求你有更清晰的架构和设计能力因为你需要指挥AI。要求你有更扎实的代码审查和调试能力因为你要为AI的产出负责。要求你在专业领域有更深的积累因为你要识别和纠正AI的“幻觉”。这次“翻车”的中医游戏项目虽然没成功上线但价值巨大。它像一次高强度的“人机结对编程”训练让我真切地摸到了当前AI协作能力的边界和甜点。下一次如果我要做一个“个人记账应用的数据可视化面板”我想我会和Claude Teammate合作得非常愉快——因为那是一个逻辑清晰、知识依赖度低、非常适合AI发挥的领域。所以别怕翻车。和AI一起搞事情翻车本身就是最快的学习路径。关键是从翻车中找到那条属于你的人机协作最佳航线。我现在已经开始规划下一个项目了这次我会从一个更明确、更可控的痛点开始。