Common workflows 常见干活套路

这页不是讲大道理，而是讲“这活平时到底咋派”。 官方把几种开发里最常见的活路，拆成一套套顺手流程，免得你每次都现想。

像庄稼人不会每回收麦子都从头发明流程，都是先看成熟没、再开机器、再装袋、再收尾。 Claude Code 这页讲的也是这种固定套路。

官方第一套就是“理解新代码库”。

做法很朴素：先进项目目录，启动 Claude，然后先问整体概况，再往下追问架构、数据模型、认证流程这些关键脉络。

这套适合刚接手新项目时用。先问大路，再问岔路，别上来就盯某一行代码，不然容易只见树木不见林子。

官方第二套是“找跟某个功能相关的文件”。

先让它找出负责某件事的文件，再让它解释这些文件怎么配合，最后再追执行流程从哪儿到哪儿。

比如你要查登录，就让它先找认证相关文件，再顺着“前端到数据库”一路捋。

这比你自己拿着手电筒一间屋一间屋找快得多。

官方的修 bug 流程也很实在：先把报错和复现办法给它，再问修法，最后才让它落地改。

如果你只说“有问题”，它就像只知道屋里漏水，但不知道是屋顶裂了还是水管爆了。 你把触发命令、报错栈、复现步骤一起给，它查得快得多。

所以修 bug 最关键不是“命令多高级”，而是让它看见准症状。

官方专门放了 refactor 流程：先找旧写法，再问改造方案，最后安全落地。

如果改动比较大，最好先用 Plan Mode，只看不改，先把方案捋直。 等你确认要动哪些文件、可能影响哪几块，再让它正式开工。

这套特别适合老项目，省得一拆就是连环塌。

官方有一整块在讲 tests。

核心意思是：别只让它改代码，还要让它顺手把检查也补上，或者直接跑完测试再修失败项。

这样它不是“写完就走”，而是“写完还会自己拿尺子量一遍”。

官方这页把 subagents、plan mode、git worktrees、并行会话都放进来了。 意思很明确：复杂活别硬塞一个窗口里闷头搞。

调查可以分给专门的小工，平行方案可以放到不同 worktree 里，各自干各自的。 主会话只看摘要和结果，脑子更清爽。

官方还提醒，Claude Code 不只是交互聊天窗口。

你可以 pipe 数据给它、让它做一次性分析、放进验证流程、控制输出格式，像其他命令行工具一样接进流水线。

这点很像村里常用的小机械：有时候单独开，有时候接在整条流水上，关键看你怎么配。