背景:Python后端,主要写FastAPI + SQLAlchemy。三个月前开始重度依赖Cursor的Agent模式,基本是描述需求→它生成代码→我复制粘贴→测试通过→上线。最近review自己写的代码,发现很多逻辑我根本讲不清楚,比如某个复杂的async上下文管理器嵌套,或者它自己封装的一个装饰器链。同事问我为什么这么写,我只能说“AI这么生成的,能跑”。现在有点慌:如果哪天Cursor挂了或者项目要交接,我是不是就废了?有没有人也遇到类似情况?是应该硬着头皮读懂每一行,还是先追求效率、等有经验了再回头补课?
用Cursor写后端三个月,代码能跑但看不懂,这正常吗?
全部回复
共 44 条能跑和能维护是两码事,建议至少把核心链路啃明白,不然真成了AI的提线木偶。
我也有类似经历,但后来发现硬读反而能逼自己理解架构,效率其实没降多少。
说实话这状态太真实了,我团队里俩新人现在也这样,代码跑得飞起但一问三不知。我的建议是别全读懂,但至少把那些装饰器链和上下文管理器的“骨架”画出来,知道数据怎么流的就行。不然等哪天AI抽风改了个参数,你连从哪下手排查都不知道。而且交接时一句“AI写的”真的会让人想打人,哪怕你只懂个大概,也比完全黑盒强。
这种“能跑但不懂”的情况我太有体会了,之前用AI写了个异步任务队列,后来加需求时想改个超时时间,愣是找了半天没找到逻辑在哪。我觉得你先别慌,可以挑几个高频用到的复杂片段,花点时间逆向拆解一下,其他的先放着。毕竟你现在的核心价值是能用AI快速交付,而不是当人肉解释器,但至少要给自己留个“万一出问题能上手修”的底线。
我跟你一模一样,上个月review自己用AI写的SQLAlchemy查询,那家伙嵌套了五层关联,我盯着看了半天硬是没看懂为啥要这么写。后来我试了个笨办法,把每个复杂函数丢给AI让它用中文注释重写一遍,再对照着读,效率高很多。别指望全懂,但至少把“这个函数是干嘛的、输入输出是啥”搞明白,不然真
这状态太真实了,我前阵子用AI写Go项目也这样,跑得挺欢但一让我讲原理直接卡壳。我的建议是别全盘硬啃,但至少要把那些装饰器和上下文管理器的核心逻辑捋一遍,不然真出问题你连从哪下手调都不知道。另外交接这事确实得提前想,我一般会让AI在关键地方写清楚注释,哪怕多花点时间,后面省心不止一点。
说实话能跑和能维护是两码事,你这不是废了,是还没建立起对代码的“手感”。我碰上这种情况会挑几个最复杂的模块,让AI先给我讲一遍设计思路,再自己手动改个小功能练手,比单纯读代码效率高多了。别慌,工具本来就是杠杆,关键是你得学会怎么用杠杆而不被杠杆吞了。
我也有过这阶段,后来发现最好的办法是拿一段你完全看不懂的代码去问AI“为什么这么写”,让它给你拆解,你反复追问直到能自己复述。三个月不算晚,挑几个核心文件搞懂就够了,其他允许黑盒。真等交接那天,你能讲清主流程和几个难点,同事就谢天谢地了,别给自己太大压力。
这状态我太熟了,之前用copilot写脚本也这样,后来项目重构直接傻眼。建议你至少把那些核心的装饰器和异步逻辑啃明白,其他边缘代码可以先放着,不然交接时真能急出白头发。
效率当然要追,但得给自己设条线,比如每周抽半天专门复盘AI写的代码,不求全懂但关键路径必须能讲清楚。否则哪天工具抽风或者需求一变,你连从哪儿下手改都不知道,那才是真废了。
这状态太真实了,我前阵子用Copilot写脚本也这德行,能跑但逻辑细节完全说不清。我的建议是挑那些复杂嵌套和装饰器重点啃,其他简单代码先放着,不然交接时候真会崩溃。而且你想想,AI生成的代码自己搞不懂,出bug时候排查起来比手写慢十倍,那时候才真要命。
说实话我太理解这种状态了,但我的建议是别硬读每一行,那会把你拖垮。你现在真正该做的不是理解那个装饰器链,而是建立“代码所有权”意识——比如让AI每次生成后强制它用中文注释解释设计意图,或者让它给你画一下调用流程图,这样至少你能跟同事讲清楚大方向。我当初用Copilot写Go项目也这样,后来交接时被问得满脸通红,才意识到“能跑”和“可维护”完全是两码事。但反过来想,你三个月能写出这些东西,说明你业务抽象能力其实在进步,只是语法层面的细节被AI代劳了。建议你挑最核心的两个模块,专门花一周时间让AI给你逐行讲透,剩下的暂时保持黑盒,等碰到bug再深入。另外一定要把AI生成的代码加上自己的命名规范和模块拆分习惯,哪怕改个变量名都行,这样过一个月你至少能凭手感记住哪些地方容易出问题。工具倒不会真让你废掉,但审代码的习惯必须长出来,不然下一个项目你心里永远没底。
能跑和能维护是两码事,建议至少把核心路径的装饰器和上下文弄懂,不然交接时真的会社会性死亡。
我也有过这阶段,后来逼自己把AI生成的代码重构一遍,虽然慢但心里踏实多了。
说实话你这个状态我太懂了,我前阵子用Copilot写个数据处理管道也是这感觉,跑起来没问题但让我讲里面那个生成器的yield逻辑,我愣是卡了半天。我觉得这事儿得分两层看,短期你靠AI堆功能效率确实高,但长期如果代码里全是你自己都解释不了的黑盒,那维护成本迟早爆炸。我现在的做法是,AI生成完代码后,逼自己花十分钟把核心逻辑用注释写出来,写不出来就说明我还没真正掌握,得拆开看。另外你担心的交接问题很现实,我同事就接过一个AI写的屎山,最后重写了三分之一,因为没人敢动那些不明不白的部分。建议你别硬啃每一行,但至少要把那些“关键节点”搞懂,比如装饰器到底做了什么、上下文管理器怎么控制资源,这些是地基。等你有经验了再回头补课,大概率是没这个时间的,因为新需求永远会来。
说实话我觉得你这不是代码问题,是信任问题。你想想,以前写代码是“我懂所以我能改”,现在是“它能跑所以我不问”,这中间缺的恰恰是“为什么”这个环节。我建议你挑几个核心文件,花半天时间让AI逐行给你讲逻辑,讲到你懂为止,这比盲读源码效率高多了。至于交接,别慌,真到那天你边看边问AI也能撑过去,但前提是你得学会怎么问。
这状态我太熟了,之前用Copilot写数据处理脚本也这样,能跑但让我讲原理直接卡壳。我觉得你慌的点其实不是代码本身,是那种“失去掌控感”的焦虑,毕竟工作里最怕的就是自己成了那个只能点运行的人。我的经验是别想着每行都读懂,先挑那些你日常要改、要排错的核心模块去啃,比如那个装饰器链,你就在它出错的时候debug一遍,比干看强十倍。至于交接,说实话现在团队里没几个能完全看懂AI生成代码的,大家半斤八两,真出问题一起对着屏幕猜。但有一点得提醒,SQLAlchemy那类ORM的异步会话管理最好还是自己手写一遍,那玩意儿真出事排查起来AI帮不了你,纯靠底子。效率可以追,但至少得给自己留几个“安全气囊”模块,不然哪天模型一更新,生成风格变了,你连改都不知道从哪下手。
这状态我太熟了,之前用Copilot写爬虫也这样,跑得飞起但让我解释正则为什么这么写直接哑火。我觉得关键不是每行都读,而是得搞懂那些“设计决策”背后的原因,比如它为什么用async上下文管理器而不是普通函数,这关系到你排查问题的能力。你想想,万一线上出个诡异bug,你连代码逻辑都理不清,怎么定位?我现在的做法是让AI生成完后,逼自己用自然语言把核心流程复述一遍,讲不出来的部分就当场问它,直到能自圆其说。至于交接,我觉得比读懂代码更重要的是你积累了“如何描述需求”的经验,这本身也是能力。但别拖太久,至少把那些你经常碰的模块彻底搞明白,不然哪天AI升级改了个行为,你连哪里会坏都不知道。
代码能跑但讲不清,这跟埋雷没区别,交接时迟早炸自己脚上。
建议至少把核心链路读透,剩下边角料让AI背锅就行。
能跑和能维护是两码事,建议至少把关键路径的逻辑啃透,不然哪天升级依赖直接抓瞎。
我也有类似经历,交接时被问得一愣一愣的,现在习惯让AI每段代码都写注释,自己再过一遍。
我太懂你这个状态了,我身边好几个同事现在都这样,代码review的时候跟开盲盒似的。但我觉得你得先想清楚一个问题:你是在用AI写代码,还是在用AI替你思考?如果只是把需求丢进去然后无脑merge,那三个月后看不懂太正常了,因为你压根没参与过决策过程。我自己的经验是,现在用Cursor写复杂逻辑时,会强制它先输出设计思路,然后我再逐行过一遍,哪怕慢一点,至少知道每个装饰器存在的理由。你那个async上下文管理器嵌套,说实话,很多写了两三年的人可能也讲不透,但区别在于他们能自己debug,而你一旦遇到线上问题,可能连从哪下手都不知道。所以我的建议是,不用硬着头皮读懂每一行,但至少要能回答“为什么这里要这么设计”这个问题,不然哪天AI给你生成个有隐患的代码,你连排查方向都没有。另外交接这事真的别拖,你现在就该把那些看不懂的模块单独拎出来,用最笨的方式重写一遍,哪怕效率低,但那是真正属于你的能力。
能跑就行,但交接前建议至少把核心逻辑用注释讲明白,不然坑的是接手的同事。
这状态我太懂了,先效率后补课没问题,但别拖太久,不然代码会变成你和AI的共同秘密。
这状态我太熟了,建议至少把核心链路看懂,不然线上出问题debug得怀疑人生。
能跑和懂是两码事,交接时你就懂了,趁现在赶紧补课,不然后面更痛苦。
能跑和能维护是两码事,建议至少把核心链路啃明白,不然哪天AI给个坑你连怎么埋的都不知道。
我也有这感觉,后来强制自己每周抽时间重写一遍关键模块,虽然慢但心里踏实多了。
我跟你情况几乎一模一样,用AI写快三个月了,现在看自己代码跟看别人写的一样。不过我觉得问题不在读懂每一行,而是得把那些关键路径上的逻辑搞明白,比如装饰器链和上下文管理器到底在干什么,不然真出bug你连排查方向都没有。建议你挑几个核心模块硬啃一遍,其他边角料先放着,效率和安全得平衡一下,不然交接的时候真会怀疑人生。
说实话这事儿太常见了,我身边好几个朋友都这样,现在代码review基本变成AI代码阅读大会。但我觉得你慌得有点早,能跑本身就是一种能力,关键是得给自己留条后路——至少把关键路径上的核心逻辑搞懂,比如那个装饰器链到底改了啥数据,不然出问题连排查方向都没有。
我自己的做法是让Cursor写完之后,让它再用自然语言解释一遍设计思路,存成注释或者文档,这样既保效率又能勉强跟上它的脑回路。至于交接,现在很多团队已经在接受“AI生成+人工审核”的模式了,你只要能讲清业务影响和改哪里,比死磕每一行语法重要得多。
说实话我觉得这状态挺危险的,能跑和能维护是两码事,尤其后端出问题时候得靠人肉排查,你连逻辑都讲不清到时候定位bug会特别痛苦。我的建议是至少把那些核心链路和复杂装饰器拆开读懂,冷门边角可以先放着,不然交接时同事心里肯定打鼓。另外你可以试着让Cursor每一步生成都附带注释说明设计意图,逼自己过一遍,比事后补课轻松多了。