AI编程助手写出的代码越来越难维护，是我的用法有问题吗？

说实话我也踩过一样的坑，后来发现根源不在prompt，而是这类工具天生就没法理解你项目的上下文边界。我的做法是先把接口定义和核心类型写好，让AI只填函数体，再强制它按我给的模板输出，结构就不会跑偏太多。

另外别指望它一步到位，我每次生成完都会立刻重构一遍，把工具函数抽出去，相当于让它帮你写草稿，但框架必须自己定。你试试把大任务拆成小步骤，每步给它明确输入输出，比写一堆抽象原则管用多了。

这问题我也踩过坑，后来发现关键不是让AI“懂原则”，而是把大任务拆成一个个小函数让它单独写，每段控制在二三十行内，再自己拼装。另外给它看一段你手写的代码风格样例，比写一百句“要清晰”都管用。至于变量命名，我都是让AI先出逻辑，再全局搜索批量替换，别指望它一次到位。

这问题我太有同感了，AI生成代码的“结构性懒惰”确实存在，尤其是项目一大，它就会默认把所有逻辑塞进最近的函数里。我的经验是别指望靠prompt约束它，不如把大文件拆成若干个小模块，每个模块用空文件+详细注释先定义好职责，再让AI填空，效果会好很多。另外变量命名这关真得自己过一遍，我后来基本把AI写的函数当“初稿”，重构的时间反而比从零写省不了太多，但它胜在能快速铺开骨架，替代那些重复的模板代码。

说实话我也有同感，AI写代码更像“快速堆功能”而不是“长期维护”，你那些问题我觉得根源在于它没有全局上下文，你拆文件它根本感知不到。我自己的办法是先把项目结构和关键接口定死，让它只填充函数体，而不是让它自由发挥整个模块。另外与其写“遵循SOLID”，不如直接给它一个你手写的例子做few-shot，它模仿得会靠谱很多。你试过把代码库喂给它做参考吗？感觉这比prompt里喊口号有用多了。

这问题太真实了，我后来干脆把AI当高级补全用，大结构还是自己搭。

同感，建议直接把项目里的代码片段喂给它当few-shot例子，比写一万字prompt管用。

问题不在prompt，是你把架构设计的活儿外包给工具了，它只会缝合不会设计。

试试先自己把接口和边界定死，再让AI填肉，你会发现它乖多了。

这问题太真实了，我最近也踩过类似的坑。后来发现别指望prompt能一次性约束住它，不如把大任务拆成小函数让AI逐个生成，再自己拼装，结构就清楚多了。另外那种“AI写完我重构”的心态可能更实际，把它当个快速生成草稿的实习生，别当高级工程师用。你试试让它先输出接口定义再填实现，感觉比直接写整段逻辑可控一些。

你试试把大任务拆成小函数让AI逐个写，再自己拼装，别让它一口气生成整个文件，效果好很多。

说到底AI不懂你项目的上下文，得把它当结对编程的初级搭档，关键架构和边界还是得自己把控。

把需求拆成小任务喂给它，再自己搭好骨架让它填肉，别指望一次生成整个文件。

说实话这问题我太有同感了，项目跑两周才暴露结构问题已经算运气好了。我自己的经验是，这类工具对“局部重构”特别擅长，但对“全局一致性”基本没概念，你指望它记住前面写的风格，还不如指望它别把变量名从camelCase突然换成snake_case。你提到prompt强调SOLID只在前几行有效，我觉得是因为它压根没有“整个文件”的长期记忆，上下文窗口一满，后面就完全是概率生成的新逻辑了。我现在的工作流是让AI写纯函数或者独立的小工具，比如解析、格式化这种边界清晰的，但涉及多个模块交互的业务流程，我会先自己搭好骨架和接口，再让它往空函数体里填实现。还有个偏门技巧，把你手写的几个典型函数贴进prompt里当“风格锚点”，比写一百字抽象要求管用得多，最好带点你常用的命名习惯和错误处理模式。另外强烈建议开它的“编辑模式”而不是“生成模式”，让它在你现有代码基础上改，而不是每次推倒重来，至少能少点职责混杂的巨型函数。不过说真的，对这种内部管理系统，我最后还是会定期花半小时手动梳理它生成的烂摊子，这工具更像是雇了个特别快但粗心的实习生，代码审查和结构把控那步省不掉。

这问题我太有同感了，用了一阵子也发现它特别爱把工具函数和业务逻辑缝在一起，变量名起得跟闹着玩似的。后来我琢磨出一个笨办法，就是让它按“输入-处理-输出”的结构写小函数，每次只干一件事，并且明确告诉它不要自己加料。另外感觉它确实更适合写点独立的工具代码或者填充样板，复杂业务还是得自己搭好框架再让它填肉，不然重构的功夫比手写还累。

这问题我太有同感了，你提到的变量命名和代码堆叠完全是AI的“舒适区病”。后来我发现光在prompt里喊原则没用，得给它当“验收员”，比如明确要求“每个函数不超过15行，且只能有一个业务意图”。另外建议你把项目里的代码风格片段直接粘进prompt做few-shot示例，比抽象描述管用十倍，甚至能让它模仿你写过的某个具体模块。不过说真的，对于复杂业务流，我更愿意让它生成纯工具函数或单步逻辑，主体架构还是自己搭，这样能省掉好多重构的暗坑。

跟我想的一样，AI适合写函数，不适合设计结构，拆代码这活儿还是得自己来。

我试过让它先写测试再补实现，结构会稳不少，你可以试试。

与其改prompt，不如把大文件拆成小任务喂给它，一次只写一个函数，效果立竿见影。

说实话你遇到的这个情况太典型了，我项目里也踩过一样的坑。后来发现别把AI当独立开发者，当个需要你随时拽着绳子的实习生会好很多——每让它写一个函数前，我先自己把接口、边界条件、甚至变量名都定好，它只负责填空。另外强烈建议你试试让AI先写一个“设计草案”文档，不直接出代码，等结构聊清楚了再动手，比反复强调原则管用多了。

说实话你遇到的情况我太有同感了，尤其是那个“只在前几行有效”的描述，简直精准到可怕。我后来慢慢发现，这类工具本质上是个“超级擅长接话的实习生”，你给它一个清晰的小目标，它能干得漂亮，但你要它自己把握整个项目的架构和职责边界，它就会开始自由发挥了。我现在的做法是先自己把文件骨架、函数签名和关键接口写死，甚至把TODO注释都标好，然后让AI只负责填充具体逻辑，这样它就没有空间去“堆砌”了。另外关于变量命名，我会在项目里维护一个术语表，把比如“订单状态”这种词直接贴进prompt，而不是抽象地说“命名要清晰”。还有就是，别指望一次生成就完事，我通常会让它先出个初版，然后我手动改一轮，把改完的代码当例子再喂回去，几次之后它就能模仿出你的一部分风格了。最后想问下，你试过给它指定“只能修改我划线的函数，不得新增函数”这种硬性限制吗？我觉得这招比强调SOLID管用多了。

我习惯让它先写接口和测试用例，再填实现，结构会好很多，你试试？

我也有同感，AI写小函数还行，一让它搞模块化就容易失控。后来我改成先自己搭好目录结构，每个文件只给它一个明确任务，比如“只写这个service类，不要加任何工具函数”，效果好了不少。另外可以试试让它先输出设计思路再写代码，不然它默认就是一路往下写。