接手项目，一直是很难的事。
不管怎么说，这种事情只能让 程序员 来干。
在 AI 时代，ai 是可以给你写一大堆的东西。但是很不同的是，AI 写的东西，就像一个整体，一个黑箱。它可能有文档，但是这文档也只能看一半信一半。
古法编程手搓的代码，里面往往是还有作者的一些精妙的非传统的设计。不论好坏，反正在作者眼里，它的可塑造性是 AI 写的东西不能直接超越的。
什么意思呢？就是你 AI 给了你 3mb 的源代码，确实能跑通，但是你想修改的话，因为你从来没见过里面的构造，你心里也明白，让它精准的更改是一件几乎无法能表达精准的事。
而那些你自己从 0 开始，看着长大的项目，则是有种很踏实的感觉。
这个就涉及到接管别人的项目的技巧了。
这个很重要，无论你要接管的项目，是不是 AI 的项目，都一样是个技术活。
我在网上最近看到了一篇文章对这个讲的很不错。作者是博客园的【楚国的小隐士】，下面是我的笔记：
在 AI 时代，很多「文科生」做出的东西，其实只有一个前端界面，而且继续做，项目复杂度就会上来，就没办法继续了。
在实际环境中，招聘程序员的情况，大部分不是去从 0 开发一个系统，而是找程序员接手维护居多。就是所谓的【运维开发工程师】。这个是普遍的大部分的程序员岗位。
实际上未来，经济下滑，加上 AI 带来大量的垃圾项目，未来新业务可能很难更多，所以新项目的开发估计更少，而接手维护老项目的场景需求会更常见。
现实世界是虚拟世界的基础。
因此，第一步是搞清业务逻辑，而承载业务的地方，是数据库！
（数据库，看上去就和Excel表格差不多。）
数据库怎么设计，背后的商业业务就是什么样子，软件就是什么样子。数据库泄露了这个都明白，是很大的事故。但是，在软件开发领域，数据表结构，通常也是大机密！因为这个真的会把整个公司的商业模式泄露，就几个表结构，也蕴藏着大信息量。SQL语句是一个项目隐私。在和 AI 对话时千万不要把 SQL 语句发出去。
如果是小白，可以先不学编程，而是先学一下 SQL 语句。这个几个小时就基本学够了，然后受益终身。
搞清楚表结构的任何细节，比如那个是主键，每个字段的含义，以及为什么这个字段设计成递增、递减，各种外键、约束、表关系。
之后你的整个项目，都将基于这些信息为骨架，不断完善。
如果你的项目很重要，千万不要让 AI 介入理解数据库的过程。这个是很隐私的内容，相比而言，代码可能都没有数据库结构隐私。
（PS: 开发者可以借助Navicat等工具生成数据库模型图，把表关系可视化）
如果已经有文档了，那就省去 AI 阅读了。
这一步也很关键，除了让自己完善数据库骨架上的神经末梢，也就是对项目有更深的理解。
同时也是让 AI 后续在干活时，直接看 API 文档，而不是再次读代码，整理业务关系（换言之，API 文档就是给 AI 提供的优质上下文）。
数据库结构是从 0 开发一个软件的首要重任。而 API 设计是次要的重任。下面是提示词的例子：
请帮我分析这段 NextJS 接口代码（Route Handler / API Routes）：
1. 按照业务模块对接口进行分组
2. 使用 Markdown 表格输出，包含字段：请求路径、HTTP方法、业务功能描述
3. 基于接口逻辑、参数和返回值，推断每个接口对应的真实业务操作与业务场景
4. 只做技术与业务逻辑分析，不执行、不复现、不生成可直接运行的业务代码各种 API 都要有，不仅包括 HTTP 方面的。
这个简单了。
我们学一个项目的时候，也喜欢去配置那边，研究揣摩一番。
一般是以 config、pom、application 为字眼的，大都是 JSON 格式，也有 yaml 格式的等等。一般在根目录或其他显眼的地方。
这个能告诉我们，它连接了哪些外部系统、使用了哪些中间件、依赖了哪些框架和版本。
不过.... 商业大项目，配置文件里，一般动辄几百上千行，最好也要搭配 AI 去消化理解。
走完上面三步，我们基本就对项目的运转有点印象了。对于专业程序员，这个难不到他们，他们的职业生涯，一半都是在读陌生的代码里度过的。况且现在都 AI 时代，更难不到了。
但，如果你是偏小白，那就使用【追变量名】大法！
各位程序员肯定对这种方法有回忆。都是这样过来的。
看准一个你能理解的部分（任意部分就行），然后找到一个变量名，之后以它为「线头」，追到函数，明白函数的作用，再追到方法、类、模块等等等，一个文件跳到另一个文件。之后一直到追不动的时候，你就大概明白运行逻辑了。
之后再来两三轮，就基本 OK 了。会略耗费点时间。
让 AI 生成《软件需求规格说明书》《模块设计报告》《模块流程图》也是一个技巧。
不过也别太迷信自己明白了项目运行。我们很难能像作者一样明白代码的运行逻辑，但这个方法确实好用。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。