写代码时用Prompt工程到底值不值？感觉越调越玄学

说实话，你那个二分查找变体的经历我太有共鸣了。我一开始也迷信那种“仔细考虑边界情况”的咒语，后来发现模型根本分不清“仔细”和“过度设计”的界限，你越强调防御性，它越给你堆if-else和抽象层，最后代码比手写还难维护。日常业务代码里我基本不花超过半分钟去调prompt，需求描述清楚、给个输入输出示例就差不多了，跑不通就直接改代码或者再问一次，比反复打磨措辞快得多。所谓prompt工程在复杂推理任务上可能有用，但写CRUD或者常规算法，真没必要把简单问题搞成玄学。有个比较实用的中场技巧是限定它别加多余东西，比如加一句“只改我指出的bug，不要重构，不要加类型注解”，反而比正面描述更管用。另外多轮对话里直接甩报错信息让它修，比一次性写完美prompt效率高多了。那些大佬强调结构可能是为了做评测或者批量任务，咱普通写业务代码，实用主义优先，别被方法论绑架了。

说实话我也踩过这个坑，一开始还以为是自己prompt写得不够“专业”，后来发现根本不是那么回事。你那个二分查找的例子特别典型，加了一堆“仔细考虑边界”反而让模型开始自我加戏，因为它会把这些词理解成“用户想要更复杂的方案”。我现在基本不信什么万能模板了，业务代码里我更倾向于先把需求拆小，一次只让它干一件事，比如“只写函数体，不要类型注解，不要异常处理”。如果结果不对，我宁愿重新表述需求或者换个角度问，而不是在原prompt上叠buff。那种“防御式编程”之类的词，对模型来说更像风格暗示，不是逻辑约束，很容易跑偏。所以我觉得prompt工程在写业务代码时性价比真不高，除非你在做特别复杂的系统设计或者需要严格控制输出格式。日常场景下，快速迭代、小步验证比打磨措辞有用得多。

我平时写业务代码基本不折腾prompt，最多就是把需求写清楚点，比如输入输出格式、用哪个库、有没有性能要求，剩下的让模型自己去发挥。你那个二分查找变体加一堆“防御式编程”反而翻车，太真实了，模型很容易把“仔细考虑边界”理解成“给我堆防御代码”，最后写出一坨你根本不想维护的东西。我觉得prompt工程在业务代码里收益挺边际的，除非你是在做那种需要反复调用的自动化流程，比如批量生成测试用例或者固定格式的代码转换，那才值得把模板打磨一下。日常写功能的话，我一般就是先让它出一版，跑不通或者逻辑不对，直接把报错或者反例贴回去让它改，来回两三轮比憋一个完美prompt快多了。所谓的中场技巧，我感觉就是别把它当人，把它当一个需要具体约束的代码生成器，给例子比给形容词管用，比如“参考这个函数的风格”或者“边界条件按这个测试用例来”，比“仔细考虑”这种话强十倍。

我也有同感，那些“防御式编程”的提示词真不一定好使，反而容易让AI加戏。日常写业务代码我基本就丢个函数签名和输入输出示例，错了再针对性补一句“边界情况再检查下”。与其花十分钟雕prompt，不如直接让它跑测试用例，看哪挂了再调。偶尔卡壳时加个“先想清楚再写”倒是有点用，但大部分时候就是试错法最省心。

感觉你踩的坑我基本都踩过。现在我的做法是prompt只写清楚输入输出和约束条件，比如“不用类型检查，保持函数在20行内”，反而比堆一堆“防御式编程”之类的词管用。写业务代码时我更倾向先让AI出个能跑的版本，再针对具体bug追问，比一开始就雕花prompt省事多了。那些强调复杂结构的大佬可能是在做通用工具或评测，日常搬砖真没必要那么玄学。

我基本不调prompt，直接描述需求，不行就换个说法重试，很多时候是模型状态问题不是措辞问题。那种堆一堆“仔细考虑边界”的反而容易触发它过度发挥，业务代码要的是简单直接。我的习惯是先把需求拆小，一次只让它写一个函数，边界case自己补测试。真要说技巧，给个具体输入输出示例比写一堆形容词管用多了。