支付团队新人的第一天：用 Claude Code 走读退款链路

周一加入支付团队，周三要修复一条退款提示。新人打开仓库，看到几十个目录，却不知道请求从哪里进入、退款状态由谁更新。此时最需要的不是逐个阅读文件，而是一条能走通的路线。

Claude Code 可以协助完成这种代码库导览：你提出一个具体问题，它查看相关文件，解释调用关系，再根据追问继续深入。把它当作陪你读代码的向导，而不是了解所有历史背景的老同事，通常更容易用好。

先把导览范围缩到一笔退款

第一次不要问“解释整个项目”。范围越大，回答越容易变成目录摘要。选择一个新人即将接触的动作，例如用户申请退款，让导览围绕这个动作展开。

可以在仓库目录中启动 Claude Code，然后输入：“我刚加入团队，请带我理解用户申请退款的流程。先找出请求入口、核心业务逻辑、外部支付调用和相关测试。暂时不要修改文件，也不要执行命令；每项结论都给出文件路径和相关函数名。不确定的地方请明确标注。”

这段提示同时规定了任务、边界和证据。文件路径让新人能够自己打开源码，函数名则方便向导师提问，不必只说“人工智能说退款在这里处理”。

给仓库访问划出安全边界

开始前，先确认公司允许将哪些代码交给外部模型处理，以及账户、模型服务和中转服务是否符合团队要求。不要把生产密钥、客户资料或真实支付记录放进对话；排查问题时优先使用脱敏样例。

仓库里的 CLAUDE.md 可以记录项目约定，但应先人工检查内容。文件中的说明不等于安全授权，“不要修改文件”这样的提示也不是强制隔离机制。应配合权限设置逐项审核工具请求；需要更严格的只读保证时，使用隔离副本或只读环境。

沿着请求入口走到测试

拿到初步地图后，不要立即要求更多文件。按实际执行顺序，一段一段追问：

• 入口：哪个路由或处理器接收退款请求？身份验证和参数检查在哪里？
• 业务：谁判断订单能否退款？重复提交时，哪段逻辑负责避免重复处理？
• 依赖：调用支付服务失败后，错误怎样返回？后续是否依赖回调或后台任务？
• 测试：哪条测试覆盖正常退款？哪条覆盖失败、重复请求或状态冲突？

每轮只聚焦一个问题，并要求区分“代码直接显示的行为”和“根据命名作出的推测”。如果涉及异步任务，应继续追踪任务消费者，而不是在任务提交处结束导览。

用源码核对三项关键结论

回答流畅不代表理解正确。挑出三项会影响修改的结论，例如退款权限、状态更新时机和失败处理方式，逐一打开对应文件核对。特别注意同名函数、旧版本目录和只供测试使用的实现。

可以继续要求：“请列出支持上述三项结论的代码位置，并指出哪些行为还需要查看配置或询问维护者。”如果工具提供了行号，也要确认它对应当前版本；代码变动后，行号可能已经失效。

运行测试前，先阅读项目说明和测试配置，确认命令不会连接生产数据库、发送消息或调用真实支付接口。获得许可后，再运行与这条链路最相关的小范围测试，不必一开始就执行整套测试。

把导览变成新人自己的代码地图

结束时，请 Claude Code 整理一页笔记：请求入口、主要调用顺序、关键文件、相关测试和待确认问题。不要把整段聊天直接当成交接文档；由新人删掉重复内容，再请导师确认业务规则与设计背景。

最后做一次反向复述：“如果要修改退款失败时的提示，我准备先查看这些文件，补充这类测试，但不改变退款状态转换。”能说清修改范围和不应触碰的边界，比记住目录结构更能说明导览有效。

为团队统一准备模型访问

如果团队需要按实际用量安排模型访问，可以考虑 RelayVano：它提供按量付费的模型中转服务，并可与 Claude Code 配合使用。先确认组织的数据处理要求，再按其当前接入文档完成配置；有需要时可注册账户，用一次小范围代码导览验证连接与费用是否符合预期。

真正值得保留的成果，不是一份听起来完整的仓库介绍，而是新人能够亲自验证的路线：从哪里进入、经过哪些判断、在哪里产生副作用，以及用什么测试确认修改没有越界。