小陈亲测推荐

小陈亲测推荐

已发布 40 篇文章

WorkBuddy 使用技巧 Day30:接手老项目:先让它读,再让它改

WorkBuddy 使用技巧 Day30:接手老项目:先让它读,再让它改

这是《WorkBuddy 30 天技巧》系列第 30 篇(共 30 篇),分类:安全与进阶。每天一个可立刻上手的小技巧。

接手老项目:先让它读,再让它改
WorkBuddy 技巧 Day30:接手老项目:先让它读,再让它改

一句话结论:陌生代码库别急着提需求,先花五分钟让它读懂。

你刚被丢进一个陌生的代码仓库,老板说「加个登录功能」。你还没读明白架构就下指令,结果它改的地方和你预期的完全不是一回事,还顺手动了三个不相干的文件。Day30 要讲的,就是接手老项目的原则:先花几分钟让它把代码库读明白,你确认理解对了,再提需求、指定范围,改完逐文件核对。

为什么需要这个技巧

为什么「先读后改」这么重要?因为陌生代码库最忌讳盲目动手。AI 不了解你的项目结构时,会按它自己的猜测去改,可能把逻辑写进错误的模块、漏掉既有的约定、甚至破坏已有的数据流。等你跑起来才发现,问题已经扩散到好几个文件。反过来,先让它通读并输出架构说明,等于逼它先建立对项目的正确认知;你再核对它说的「某某功能在哪个文件」,就能判断它是真懂还是胡猜。确认理解到位后再提需求、并明确指定要改的范围,改动就可控、可预期。这条规则不只适用于代码——接手一批陌生文档、表格时同理:先读懂结构再动手,返工率直线下降。

怎么做:分 4 步走

1. 先让它通读并输出架构

第一步只下阅读指令:「通读这个代码库,输出架构说明:模块划分、核心数据流、入口文件、依赖的技术栈。」强调不要修改任何文件。这一步让它建立项目全景,你拿到的是一张「地图」,而不是一堆改动。读得对不对,后面再验,但现在至少它开始按你的项目思考,而不是按通用模板乱猜。

2. 核对它是否真理解

拿到架构说明后,别直接信,出几道验证题:让它将某个具体功能(比如「用户登录校验」)定位到具体文件。如果它能准确指出实现位置,说明读进去了;如果答得含糊或张冠李戴,说明还没读懂,这时候提需求必翻车。核对过关,再进入下一步,等于给后续改动买了保险。

3. 提需求并指定改动范围

确认理解后,再提具体需求,并且明确指定要改哪些文件、改到什么程度。比如「在 service 层加一个校验函数,入口文件只做调用,不要动数据库层」。范围写得越具体,它越不会手痒去改无关地方。涉及多文件的改动,让它先列计划你确认,再执行,和 Day24 的批量整理一个思路。

4. 改完看变更逐文件核对

改动完成后,点开结果区的「变更」视图,逐个文件看它到底改了哪几行、为什么改。发现改错了或改多了,直接在对话里说「撤回某某文件的修改」。不要等跑起来才发现问题——变更视图就是你的验收台,逐文件过一遍,确认没问题再拿去用。

可直接复制的指令

适用场景:接手陌生代码库

通读当前项目代码,输出一份架构说明(模块划分、核心数据流、入口文件、依赖的技术栈),并指出「用户登录校验」逻辑分别在哪些文件实现。不要修改任何文件。

适用场景:加功能前先确认范围

刚才架构说明里支付模块在 service/pay.py。请只在该文件内增加退款校验函数,入口层只做调用,不要改动数据库层和订单模块,先列改动计划我确认。

适用场景:接手陌生文档集

通读这个文档目录,输出结构说明:哪些是第一手数据、哪些是汇总稿、它们之间引用关系,并指出「Q3 结论」最早出现在哪个文件。不要改动任何文件。

实战案例

背景:你新接手一个三年前的内部系统,要对「导出报表」功能加个字段,但完全不认识代码结构。你没直接说「加字段」,而是先下:通读项目,输出架构说明,模块划分、数据流、入口文件、技术栈,并指出「导出报表」逻辑在哪实现,不要改文件。它回了一份说明,你追问「导出逻辑具体在哪个文件」,它准确指向 export/service.py。你确认它读懂了,才下第二步:只在 export/service.py 里加一个字段映射,入口和模板层照旧,先列计划。它列出三行改动你确认,执行后你点开「变更」视图,确实只动了那一个文件、加了那一行映射。整个过程没破坏既有逻辑,你也没靠自己硬读几千行代码。

常见误区

上来就提改需求

陌生项目直接说「加个功能」,它按通用模板猜着改,常改错模块还动无关文件。先读后改,理解到位再动手,返工率最低。

不核对就信架构说明

它输出的架构说明可能含猜测。出验证题让它定位具体功能到文件,答得含糊说明没读懂,这时候提需求必翻车,先打回重读。

改完不看变更视图

改完直接拿去跑,等出问题才发现它多动了文件。养成习惯点开「变更」逐文件核对,这是最后一道闸,别跳过。

进阶玩法

进阶上,「先读后改」能和 Day14 的专家配合:接手的是财务系统就选财务专家、是前端项目就走相关语境,读出来的架构说明更贴领域。也能和「工作空间」联动——把老项目固定在一个空间,读和改都在那进行,历史对话和变更都归在一起,下次接手的人(或未来的你)能直接翻。周期性的维护类任务还能接自动化,比如每周让它通读变更日志、输出风险点摘要。记住这条原则不只限代码:接手陌生文档、表格时同样先读懂结构再动手,一样省返工。

小结

接手老项目别急着改。先让它通读输出架构、你出验证题确认真懂、再指定范围提需求、改完逐文件看变更。先读后改,陌生代码库也能安全上手。

← Day29 不止文字:图片、视频、3D 也能产

本系列 30 篇已全部上线,系列完整目录见:WorkBuddy 30 天技巧 · 总目录