由于工作原因，我突然接手了一个比较大的项目。

背景文档缺失严重，交接时拿到的主要就是一份代码。项目做什么、各个模块怎么配合、本地如何启动，都需要自己摸索。也没有可以随时请教的人。

虽然有开发经验，但面对陌生业务和一整个代码库，我还是有些焦虑。打开目录，每个文件似乎都能看懂一点，却很难把它们连起来。

于是，我开始尝试让 AI 帮我接手这个项目。

回头看，这个过程可以整理成五个阶段：

建立系统地图 → 跑通核心链路 → 验证自己的理解 → 建立交付保障 → 完成真实需求。

下面按我的五天经历展开。

第一天：先建立系统地图

刚开始，我最想解决的问题是：这个项目到底在做什么？

于是，我先让 AI 梳理五件事：

1. 项目的功能和业务边界。
2. 整体架构与主要运行服务。
3. 技术栈，以及各项技术的用途。
4. 数据流向。
5. 每个目录的职责。

这里，“业务边界”尤其值得问。页面上出现某个功能，并不代表它已经完整实现。接手时需要分清：哪些流程已经能运行，哪些只有部分代码，哪些只是产品设想。

我的提示词类似这样：

请在不修改代码的情况下，帮我建立一份项目地图。

说明项目用途、主要用户、现有功能、技术栈、运行服务、目录职责和数据流向。

每个结论都给出对应的文件依据。区分已经实现的功能与尚未完成的功能；不确定的地方单独列出。

要求 AI 给出依据，是这一阶段很重要的一步。

如果它说系统使用了任务队列，我就可以继续问：任务在哪里创建？由哪个进程消费？失败后怎样处理？这样才能把架构图上的方框与实际代码联系起来。

接着，是搭建本地开发环境。

这个项目包含 Go 后端、Next.js 前端和 PostgreSQL 等组件。仅仅安装依赖还不够，环境变量、认证配置和数据库初始化都会影响启动。

我就遇到了这样的错误：

invalid admin authentication configuration

其实，拿到一串启动命令，不代表已经知道怎样运行项目。

后来，我要求 AI 按下面的方式指导：

请一步一步带我搭建本地开发环境。

每一步说明三个内容：为什么要做、如何操作、怎样确认成功。

如果失败，告诉我应该检查什么。先跑通必要服务，再接入外部依赖。

第一天结束时，我希望得到的是一张能继续使用的地图：知道系统由哪些部分组成，也知道本地启动需要哪些条件。

第二天：让自己快速接手

有了项目地图，接下来仍然有一个问题：今天应该先做什么？

可以学的东西太多了。前端、后端、数据库、任务队列、数据源，每一项都值得深入。但如果目标只是“熟悉整个项目”，到了晚上也很难判断自己到底完成了多少。

这时，我用了 grill-me 这个 skill。

它的作用是通过连续追问，把模糊的计划拆成明确的选择。我当时问的是：

为了快速接手这个项目，你建议我今天应该做些什么？请先追问我的目标、可用时间和当前条件，再帮我制定计划。

这轮沟通中，有一个变化很有代表性。

AI 最初建议用四小时跑通完整的数据处理流程。我告诉它，我只有两小时。

随后检查又发现，本地的外部采集器没有启用。于是，我们把范围缩小到：手工录入一条测试数据，完成审核、发布和前端展示。

这个目标具体多了，也更容易验证。

完成标准包括：我能找到每一步对应的页面、API、后端模块和数据库表，并解释数据为什么会出现在那里。

第三天：用一个小 MVP 验证理解

这里的 MVP 是一个帮助理解系统的小模型。业务范围和数据量都缩小，只保留需要学习的关键机制。

这样做之后，我可以更清楚地观察：

• 输入怎样进入系统。
• 模块之间怎样传递数据。
• 哪些数据需要持久化。
• 中间状态如何变化。
• 结果怎样返回给用户。

原项目的复杂度很容易遮住这些基础关系。小模型则让我有机会亲手把它们连接起来，再回头对照原项目。

这一阶段也可以让 AI 帮忙：

请根据现有架构，设计一个用于学习的小型 MVP。

只保留理解核心机制所必需的组件。说明每个组件对应原项目的哪一部分，以及哪些能力被省略了。

“省略了什么”同样重要。例如，小 MVP 可能没有处理并发、重试和权限，这些仍然需要回到原项目继续学习。

我用来判断自己是否理解的标准也变了：能解释各部分存在的原因，能预测一次输入会得到什么结果，也能说出小模型的局限。

第四天：把交付流程也纳入接手范围

代码可以在本地运行之后，我开始梳理 GitHub 上的 CI/CD 流程。

这个项目部署在 AWS Lightsail 上，通过 Docker 运行。但知道服务器在哪里，还不足以掌握项目的交付方式。

我还需要弄清楚：

• 提交代码后，哪些检查会自动运行？
• Docker 镜像在哪里构建和保存？
• 服务器如何获取新版本？
• 数据库变更在什么时候执行？
• 部署后怎样确认服务正常？
• 出现问题时，如何恢复？

整个流程可以先理解为：

提交代码
  ↓
自动检查
  ↓
构建并发布镜像
  ↓
服务器部署
  ↓
运行验证

这一阶段，AI 帮我解释了 GitHub Actions、SSH、GitHub Secrets、镜像仓库和部署脚本之间的关系。

我发现，一个很有效的问题是：

请说明这一步在哪台机器上执行、读取什么配置、产生什么结果，以及失败后应该查看哪里。

因为本地电脑、GitHub Actions 的运行环境和 Lightsail 服务器是三个不同的执行位置。分清楚之后，原本难懂的配置就容易理解了。

接手项目也需要接手它的交付方式。只有知道修改如何经过检查、如何进入运行环境，后续开发才更有把握。

第五天：通过真实需求，检验接手能力

开始处理新需求之后，我发现另一个难点：产品描述往往很粗。

例如，“加一个用户验证弹窗，填写邮箱后才能访问”，听起来像一个界面需求，实际却留下了很多问题：

这是收集用户信息，还是建立登录系统？要保护整个网站，还是只保护部分功能？信息存在哪里？用户的数据是否需要相互隔离？

后来，需求又变成了社交账号登录，还要继续明确：不同登录渠道的身份是否合并，历史匿名数据如何处理，没有配置的渠道是否展示。

这些问题不先回答，代码很容易做到一半再改方向。

所以，我再次使用 grill-me，让 AI 帮我把需求细化成规则和验收标准。

可以这样提问：

请先检查现有流程，再追问这项需求中的歧义。

优先明确用户场景、访问范围、数据归属、异常处理和验收标准。需求明确后，再制定实现计划。

总结

经过这次实践，我发现，AI 已经能根据一个比较模糊的需求，快速生成代码并编写测试。但要让这些代码可靠地进入生产环境，还需要建立一套明确的质量保障流程。

这次接手项目，我总结了三层检查：

1. 自动化检查：在本地和 CI 中运行静态检查、类型检查及相关测试，尽早发现基础问题。
2. AI 审查与端到端验证：让 AI Review 代码，检查需求是否遗漏、边界条件和错误处理是否完整；再通过 E2E 测试，验证关键业务流程能否正常运行。
3. 人工验收：结合业务目标检查实际效果，确认改动符合预期，再决定是否发布。

此外，还可以每天使用 retro skill，让 AI 回顾当天的改动，找出重复逻辑、不必要的复杂度，以及可以精简或合并的代码。如果发现了问题，就把经验补充到项目规则或测试中，减少同类问题再次发生的机会。