三个月前，一个后端工程师在Reddit发帖：「我花了4小时让Claude写了个支付模块，上周要加退款功能，看了20分钟没看懂自己写的代码——哦不对，是Claude写的。」
这条帖子24小时收获3400赞。评论区像互助会现场，全是「我也是」「上周刚发生」「现在看见AI生成的代码就PTSD」。
问题不在Claude。Anthropic的模型能力没问题，问题出在人的工作流设计——或者说，根本没有设计。
为什么代码越跑越陌生
开发者对AI编程有个致命误解：把每次对话当成独立任务，而非持续工程的环节。
Claude在单轮对话里表现极佳。你描述需求，它输出代码，测试通过，部署上线。这个闭环流畅得让人上瘾。
但三周后你需要扩展功能，打开代码库的瞬间会陷入考古现场。变量命名逻辑、模块拆分理由、某处异常处理的取舍——这些决策只存在于Claude的输出里，不在任何你控制的系统中。
原文作者有个精准比喻：你不是在调试代码，是在考古发掘。
具体崩坏场景通常三类：
架构漂移：Claude为当前任务优化的局部方案，与系统整体设计逐渐脱节
隐式依赖：某处实现依赖了Claude在对话早期生成的辅助函数，但这段关系没有任何文档
上下文截断：长对话后期，Claude开始压缩或遗忘早期决策，导致输出与初衷偏离
这些不是Claude的bug。它按你要求的顺序执行了你要求的任务。问题是你从未告诉它各模块在系统层面的关联——而单轮对话的上下文长度，根本不足以让它自行推断。
可持续AI编程的3个前置问题
能长期用Claude写出可维护代码的开发者，有个共同习惯：把每次对话当作「交接班」。
开始新对话前，他们会先回答三个问题：
第一，当前代码库的结构和约束是什么？不是让Claude猜，是明确告知：「用户模块用Repository模式，支付模块依赖Stripe SDK，不要引入新ORM。」
第二，这次改动与现有系统的交互点在哪？具体到函数名、接口定义、数据流向。
第三，完成后的验证标准是什么？不只是「能跑」，而是「符合现有代码风格」「不增加认知负担」「测试覆盖新增分支」。
听起来像常识？但多数人直接跳进任务描述，假设Claude和自己有相同的全局视图，然后不假思索地接受输出。
最普遍的失败模式：把「能运行」等同于「正确」。
AI生成的代码通过编译、跑通基础测试，不代表它属于这个系统。真正的验收标准是：下次修改时，这段代码让工作变容易还是变困难？
这需要额外5分钟审查：命名是否符合项目惯例？是否重复实现了已有工具函数？异常处理是否与其他模块一致？是否引入了不必要的抽象层？
5分钟换几小时，这笔账不难算。
对话长度是隐形杀手
另一个值得养成的习惯：控制单轮对话长度。
长对话会累积漂移。提示词上下文逐渐填满，Claude开始主动压缩或总结早期内容，精度随之流失。你可能在对话后半段发现，它给出的方案与最初架构设想已经南辕北辙。
短对话、窄范围——「给这个模块添加X功能，这是模块当前职责和接口」——输出更紧凑，验证也更简单。
对话结束时，给自己留一份交接笔记：做了什么、为什么这么做、什么变了。下次对话的开头，把这份笔记喂给Claude。
这套方法不需要新工具或复杂系统。它是工作流设计，而大多数人跳过这一步，因为Claude让「开始」变得太容易了。
原文作者正在整理一套免费入门资料「Ship With Claude」，核心是可维护AI辅助开发的模式，包括5个提示词框架。他说自己系统性地思考这个问题，正是因为看到了太多「三周后懵圈」的案例。
热门跟贴