用AI写代码三个月，感觉Prompt比代码本身还难调，正常吗？

正常，AI写代码本质是给需求做方言翻译，你俩得互相磨合语感。

我现在写Prompt都当写代码注释，把边界条件列清楚，比让它猜省心多了。

太正常了，我怀疑咱们用的是同一个Curson。你提到的那个“异常处理”问题我深有体会，它默认会把所有边界情况都当成潜在炸弹，结果生成一堆防御性代码，看着很专业但实际拖慢开发。后来我学乖了，直接在Prompt里写“只处理业务关键异常，其他抛给上层”，再给个具体例子，效果立竿见影。不过这确实暴露了一个核心矛盾——AI理解的是“语义模糊”的指令，而我们脑子里想的是“上下文精确”的意图。你花时间调Prompt，本质上是在帮它补足你脑子里但没写出来的隐性知识，这活儿本来就费劲。我的经验是，别追求一次性调对，把大任务拆成小步骤，每步只提一个明确要求，比如“先写接口签名，参数校验用注解实现”，比反复改一个大Prompt省心得多。另外，如果你发现某个描述反复改不好，直接换一种说法，比如把“简洁”换成“只用if-else处理空值”，它往往就懂了。说到底，这确实是新技能，但三个月还觉得累，可能说明工具的使用方式还没找到最适合你的节奏，不妨试试更结构化的指令模板。

太正常了，AI写代码就像个阅读理解满分的实习生，你得把需求说成人话它才懂。

我现在写复杂逻辑干脆直接手写，让AI干点重复劳动或者查文档反而更省心。

太正常了，AI写代码就像个过度热情的新人，你得把需求边界像画施工图一样给它标注清楚。

深有同感，关键不是让它写，而是让它“少写”，多写点“不要做什么”可能比“做什么”更省心。

太正常了，我前两天让Claude写个分页查询，它非要给我套上防SQL注入的过滤逻辑，我项目里根本用不上。后来我学乖了，直接在Prompt里写“只实现基础功能，别加额外防护”，不然它真能把代码给你写“完美”到没法看。

你现在这种感觉我特别懂，Prompt调教到后面其实是在跟模型的“过度理解”较劲。我的办法是给它限定具体函数名和参数类型，甚至直接贴一段现有代码风格让它模仿，这样反而比描述需求省事多了。

太正常了，我甚至觉得这是每个用AI写代码的人必经的坎。你描述的这个“处理异常”变“全家桶”的问题，本质上是模型对“简洁”和“健壮”的理解跟我们不一样，它默认你希望代码能应对所有极端情况，而咱们心里想的可能只是“别崩溃就行”。后来我干脆换个思路，不在Prompt里反复强调风格，而是直接贴一段我自己写的“标准代码”当例子，让它照着这个风格去补全其他接口，效果立竿见影。还有就是，把大任务拆成小步骤，比如先让它写核心逻辑，再单独下一步说“只加必要的错误处理，不要日志”，反而比一次性描述清楚省事得多。不过话说回来，这种来回拉扯的过程，某种程度上也是在逼我们把自己的需求想得更清楚，虽然累，但写完的代码确实比我自己瞎写要规整。你现在这个阶段，我猜可能只是还没找到跟它“对齐颗粒度”的窍门，多用几次就摸到脾气了。

太正常了，这根本不是你的问题。我用了半年多AI写代码，最大的感受就是它像个“过度热情的实习生”——你给它一个方向，它能给你发挥出十个方向，尤其是“处理异常”这种模糊指令，它恨不得把整个健壮性规范都塞进去。后来我学乖了，直接告诉它“只捕获特定异常，不写日志，不加注释”，或者干脆把代码结构限定死，反而效率高很多。其实这暴露了一个核心问题：Prompt的本质是在“翻译”你的隐性需求，而代码本身是显性逻辑，你脑子里那些“别过度设计”“别画蛇添足”的潜规则，它根本猜不到。所以我现在更倾向于用它写“一次性脚本”或者“样板代码”，真正有业务逻辑的部分，还是自己先搭好框架，让它只填空。另外，我发现把“不要做什么”写进Prompt比“要做什么”更管用，比如“不要新增函数”“不要改动现有接口签名”，这样能减少80%的来回拉扯。你那个“简洁一点”的反馈本身也太抽象了，建议换成具体约束，比如“删掉所有注释，参数校验只保留非空判断”，效果会立竿见影。说到底，AI是杠杆，但支点还得你自己找，别太纠结于“调Prompt”这件事，把它当成跟人沟通一样，越具体越省力。

太正常了，AI写代码就像跟甲方对需求，你越抽象它越自由发挥，直接给具体例子和边界条件反而省事。

调prompt的功夫本质上是在替它补上下文，等哪天它自己学会追问需求，咱才算真解放了。

太正常了，我现在写代码前先花十分钟把需求拆成伪代码塞给AI，反而比直接描述功能省心。你那个“简洁一点”的反馈太模糊，它根本分不清你要删的是日志还是校验，不如直接说“只保留参数非空判断，去掉所有日志输出”。另外可以试试给它一个你手写的精简版当参照物，让它照着风格改，能少吵好几轮。

太正常了，我这周调一个分页查询的prompt，改了七八版它才没给我整出那种“智能”的过度设计。后来我学乖了，直接告诉它“只写实现逻辑，不要任何防御性代码”，反而一次过。感觉AI写代码的默认风格就是“过度工程”，你得花心思把它的“默认值”调成你想要的，这不就是在跟一个固执的同事磨合嘛。

太正常了，这几乎是每个用AI写代码的人都会撞上的墙。我自己的感觉是，AI对“简洁”和“健壮”的理解完全取决于你给它的上下文颗粒度，你光说“处理异常”，它默认就是防御式编程全家桶，恨不得把每个变量都包一层。后来我学乖了，直接给它贴一段业务代码，然后说“只对数据库连接部分加try-catch，其他别动”，效果立竿见影。其实这本质上是需求拆解的问题，你花在调Prompt上的时间，恰恰是在理清自己到底要什么边界，这跟以前写代码时画流程图、写注释的思考成本是一样的。另外，我强烈建议你试试把“负面例子”写进Prompt里，比如“不要加日志，不要打印堆栈，保持函数体不超过20行”，这比单纯说“简洁”管用十倍。等哪天你发现调Prompt的时间开始少于手写代码的时间了，说明你已经建立了一套自己的指令语法，那时候才算是真正上手了。

这太正常了，我刚开始用AI写代码那会儿也是这个状态，甚至怀疑自己是不是跟Prompt八字不合。后来我发现，问题出在把AI当成了“能理解业务上下文”的同事，它其实只是个超强的模式匹配器。你说的“处理一下异常”这种描述，对AI来说就是个开放题，它只能按训练数据里的“标准答案”来，自然就是try-catch全家桶。我现在习惯把约束条件直接写进代码注释里，比如在函数上方标注“仅捕获特定异常，不打印日志”，这样它的输出会精准很多。另外，我觉得你来回改Prompt，其实是在帮AI“缩小搜索空间”，这本质上跟调试代码很像，只是调试对象从机器逻辑变成了语言模型。等你摸清它的“脾气”，比如它对哪些词敏感、对哪些指令会过度反应，后面效率会翻倍的。还有个邪招，你可以让它先写一版“最啰嗦但逻辑完整”的，再单独发一条“只保留核心逻辑，删掉所有非必要代码”的指令，分两步走比一步到位省心得多。

太正常了，我现在写业务代码基本也是这个状态。感觉Prompt调优已经变成一门玄学，你给它“处理异常”它就理解成“堆满防御性代码”，你改口说“简洁”它又矫枉过正到连校验都砍掉，这中间那个平衡点全靠你拿话术去试。而且最坑的是，同一个Prompt在不同模型版本里表现还不一样，我上周刚调好的描述，这周更新完Claude又得从头磨。后来我学乖了，干脆把代码规范直接写进系统Prompt里，比如“只捕获自定义异常，不处理第三方库的RuntimeException”，但这样写下来，那段约束比我要写的接口逻辑还长。所以你说累不累，其实是在跟模型做一种“模糊需求翻译”的博弈，它永远理解不到你脑子里那个“刚好”的度。我现在是能拆小任务就拆小任务，让它一次只改一个点，反而比给个完整需求让它自由发挥靠谱得多。

太正常了，现在写Prompt跟调参似的，AI的“简洁”理解跟咱们不在一个频道上。

用多了就会发现，关键得把边界条件写死，不然它自由发挥起来比你自己写还费劲。

太正常了，我用了半年多AI写代码，现在最耗时的就是调prompt，尤其是那种“看似简单但隐含需求”的描述。你举的这个例子我太有同感了，“处理一下异常”在AI眼里就是“全副武装”，恨不得把每个函数都包上三层防御，但有时候我们就是想要个轻量级的错误透传而已。后来我学乖了，直接把约束写进prompt里，比如“只捕获特定异常类型，不要加日志，不要改变原有返回结构”，虽然描述很长，但反而比来回试错省时间。还有一个坑是AI对“简洁”的理解跟咱们不一样，它可能觉得删参数校验是优化，但实际业务里那是最基本的底线。我现在都先把业务规则拆成清单，一条条喂给它，宁可啰嗦也不让它自由发挥。另外，我怀疑这种问题跟模型对“模糊指令”的默认偏好有关，它倾向于生成最“安全”的代码，而不是最“合适”的代码。所以与其说是在调prompt，不如说是在帮AI建立业务上下文，想通了这点，心态就平和多了。

太正常了，我现在写业务代码基本是“伪代码+中文注释”直接扔给Claude，让它按我的思路补全，而不是给它一个模糊的“处理一下异常”这种需求。你遇到的这个问题本质上是——AI对“简洁”和“健壮”的理解取决于训练数据里的平均偏好，而不是你这个项目的具体上下文。我试过最有效的方法是给它一个反例，比如明确告诉它“不要加日志，不要捕获所有异常，只在数据库连接处try-catch”，这样它反而能理解边界。另外，我怀疑你花在调Prompt上的时间，其实是在心里重构需求逻辑，这本身就是写代码的一部分，只不过从“敲键盘”变成了“组织语言”。我现在会把Prompt当成接口文档来写，输入输出、边界条件、禁止项全列清楚，虽然前期写得久，但改代码的次数明显少了。不过说实话，遇到那种“改了三轮Prompt还不如自己写十行”的情况，我就直接手写了，没必要跟它死磕。

太正常了，我上周调一个分页查询的prompt，改了七八版才让它别自作主张加排序逻辑。后来学乖了，直接在开头写死“只改我指定的部分，其他代码一字不动”，效率反而上来了。你可以试试把需求拆成极小步骤，一次只让它改一个点，别指望一句话搞定所有事。另外真不如自己写核心逻辑，让AI补测试用例和边界检查，分工明确点会省心很多。

太正常了，我现在写代码前花十分钟构思prompt，写完还得花半小时微调，最后干脆把AI生成的代码当参考，自己重写一遍。你说的这个“简洁”和“完整”的平衡点确实难把握，我试过在prompt里加“只处理核心逻辑，不要额外防御”，结果它连基本的空指针都不管了。后来我干脆把异常处理和参数校验单独分成两个prompt去生成，再手动合并，感觉比一次性生成靠谱点。

太正常了，我刚开始用Copilot那会儿也这样，后来发现核心问题在于咱们总拿写代码的思维去提需求，但模型理解的是自然语言的模糊指令。你那个“处理一下异常”其实是个典型的坑，它默认要覆盖所有可能路径，结果就是过度工程化。我现在的做法是直接在Prompt里给具体边界，比如“只捕获网络超时和数据库连接失败，其他异常向上抛”，甚至直接贴出接口的返回结构，这样它就知道该在哪儿加日志、哪儿能省。还有个特别有用的技巧是让它先列出改动点再动代码，相当于先对齐方案，不然你永远在跟它玩“你说东它写西”的拉锯战。调Prompt确实比写代码费脑，因为你要同时理解业务逻辑和模型的“脾气”，但摸清规律后效率能翻倍，比如把常用的约束条件存成模板，每次只改核心需求。另外，别太指望一次性到位，我一般会先让它产出第一版，然后针对diff逐条提修改意见，比反复改全局描述精准得多。

太正常了，我刚开始用Copilot那会儿也这样，后来发现写Prompt的核心是给它限定边界，比如直接说“只处理XX异常，其他抛出去，不加日志”，效果能好很多。你越让它“自己看着办”，它就越放飞自我。另外可以试试把代码风格示例直接贴给它，比用形容词管用多了。