使用 AI 进行开发四个最常用的活儿：探索代码库、修 bug、重构、写测试
文章来源：
https://coding.stormzhang.ai/claude-code/16-common-workflows.html
0. 先认住：四种活儿，四把工具
核心的区别在一个维度上：这活儿动不动你的代码？
看出来没？探索是零风险的（它只读不写），所以可以放心大胆问；修 bug 和重构是动刀的，得让它先讲清楚再动手；写测试介于两者之间，它新建文件不碰你原有代码，但你得盯它有没有偷懒只测「正常情况」。
记住这张表的判断逻辑，下面四节就是把每一把工具拆开教你怎么握。
💡 一句话总结：四类活儿先按「动不动代码」分清性格——探索零风险随便问，动刀的活儿先让它讲再让它改。
1. 探索陌生代码库：从大到小，三层问下去
我刚接手这个项目，帮我快速上手。分三步：
1. 给我整体架构概览，说清主要模块和它们的职责
2. 负责 [你关心的功能，如「订单支付」] 的代码在哪些文件里
3. 追踪 [某条核心流程，如「一笔订单的创建到支付」] 的完整执行路径
用新手能懂的方式讲，先别改任何代码。💡 一句话总结：探索就一个节奏——从大架构到具体文件再到执行链路，从大到小三层问下去，前两层在 Plan Mode 里问最稳。
2. 修 bug：贴报错 → 找根因 → 改 → 加回归测试
我遇到一个 bug。
报错信息：[完整粘贴报错和堆栈]
复现步骤：[我做了什么才触发，是偶发还是必现]
请你：
1. 先定位根本原因，解释为什么会出错，先别改代码
2. 给我修复方案，解决根因，不要只是把报错盖住
3. 改完补一个能复现这个 bug 的回归测试，跑一遍确认通过💡 一句话总结：修 bug 四步走——贴报错和复现步骤、先找根因、再改、最后补回归测试；少了回归测试这把锁，同一个 bug 迟早复活。
3. 重构：先讲现状 → 定目标 → 小步改 → 改前改后都测
我想重构 [文件 / 函数名]。
重构目标：[具体说，如「拆成更小的函数」「换成现代写法」「消除重复」]
要求：
1. 先解释这段代码现在的行为，包括容易忽略的边界情况
2. 如果它还没有测试，先补上覆盖现有行为的测试
3. 小步重构，保持对外行为完全不变
4. 重构前后都跑一遍测试，确认结果一致💡 一句话总结：重构的命根子是「行为不能变」——先讲现状、再定目标、小步改，用改前改后都过的测试把行为锁死；没测试就先补测试再动手。
4. 写测试：重点是逼它覆盖边界情况
给 @[文件路径] 里的 [函数名] 写测试。
要求：
1. 沿用项目现有的测试框架和断言风格
2. 重点覆盖边界情况：[列出你能想到的，如「空输入、零、负数、超大值、类型不对」]
3. 也帮我想想还有哪些我没列到的边界情况，一并测上
4. 写完跑一遍，有失败的修到通过💡 一句话总结：写测试别只说「写测试」——显式逼它覆盖边界情况（空值、零、负数、类型错误），再让它帮你补你没想到的边界，正常路径反而最不重要。
5. 小结
把日常 80% 的活儿拆成了四类，每一类给了一套固定打法和一个能抄的模板：
现在应该能： 拿到任何一类高频任务，不再对着光标发懵——直接调出对应模板填空，知道每一步该让 AI 先干什么、自己该盯什么。这四个模板，是之后绝大多数工作的脚手架；熟了之后会发现，再复杂的任务也无非是这四类的组合与串联。
评论区