用 Claude 技能链串起缺陷修复流程

dev.to · AI#Claude#缺陷修复#工作流

Editor brief · 编辑速览

作者分享用 Claude 技能链提取工单上下文、复现缺陷、模拟外部服务，并在确认方案后执行修复、浏览器检查与自查的工作方式。工程师的投入逐步转向输入质量与方案把关。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

一位在 Deskpro 工作的工程师发现，自己已经约四个月没打开 VS Code，于是把它删了。他仍然修 bug、参与评审、决定技术方案，只是把更多精力放在给 Claude 提供上下文、选择方案和检查结果上。

作者的主张很直接：工程师应该更关心输入和输出，减少对亲手写代码、逐行读代码的依赖。这套做法有参考价值，但能否成立，取决于你有没有足够的业务判断力，以及团队有没有可靠的验证流程。

作者过去修 bug，要读工单、尝试复现、查找原因、修改、测试，再开 PR。真正耗时的往往不是修改代码，而是前面的调查。遇到依赖第三方服务、又无法在本地运行的问题，光复现就可能吃掉大半天。

现在，他用 Claude 配合一串 skills 完成这条链路：从工单提取上下文，复现问题，为本地缺失的服务构造模拟实现，再与作者讨论方案。方案确认后，Claude 执行修改；如果涉及 UI，就在浏览器中检查；随后自查变更、质疑可疑之处、做安全检查，最后附上证据创建 PR。

作者说，复现现在经常只需几分钟。但原文没有交代样本数量、问题难度和成功率，因此只能视为个人工作记录，不能据此推算团队整体能提速多少。

人仍然要做选择。作者追求的是影响范围最小、取舍最少、不容易波及其他页面的修复，而不是看到一个能运行的方案就接受。Claude 负责执行，作者负责判断这次究竟应该改到哪里。

作者在一月还写过，自己每次都会在变更合入前读完所有修改。如今他的观点变了：亲手写过、逐行读过，都不能保证代码正确。

他依赖的是单元测试、端到端测试、CI、人工 QA，以及新增的一条要求：每个 PR 都必须附上证据，证明它实现了声称的行为。

读过代码不能替代验证，但验证是否充分，同样需要判断。

这套思路对前端尤其容易理解：一个按钮的处理函数看起来没问题，不代表浏览器里的操作结果就正确。作者要求 UI 修复经过浏览器检查，是把验收落到了实际行为上。不过，原文没有说明证据的具体格式，也没交代如何检查相关功能是否受到影响，不能把「附了证据」直接等同于「覆盖了风险」。

评审也随之变化。Claude 先对 PR 分类，把机械、明显的文件标记为已查看，留下真正改变行为的文件供作者判断。他仍然会看这些文件，理解改了什么、为什么改，再决定是否接受。

至于循环怎么写、文件怎么排、命名是否合自己口味，他不再留下这类细枝末节的意见。风格交给 Prettier 和 PHP CS Fixer，评审集中在正确性、安全性，以及是否满足工单要求。

作者有约二十年的 Web 开发经验，在 Deskpro 工作了近四年。Claude 给出三个选项时，他熟悉代码库、产品和客户，能快速判断哪个合适，也能发现三个都不合适。

这正是标题里「输入」的分量。输入不只是把需求写长一点，还包括明确边界、提供业务背景、说明约束，并在方案偏离时及时纠正。

作者也承认，探索性工作没有那么顺畅。尤其是新功能，大家还不知道答案应该长什么样，需要更多来回讨论。他选择延长对话，而不是回到编辑器里尝试。

这说明他的流程更容易在目标明确、能够复现和验收的 bug 修复上发挥作用。对于尚未明确需求的新功能，AI 不会自动消除决策成本，只是让决策更多发生在对话里。

作者没有建议新人照搬「不读代码」。相反，他强调，缺少领域知识和取舍能力时，批准一个自己无法判断的方案，会更危险。

我认同作者把注意力从代码风格转向行为、风险和证据。已经能交给格式化工具的事情，确实没必要占用大量人工评审时间。

但从「逐行阅读不是充分保障」推到「可以大幅减少阅读」，中间有前提：测试和 QA 足够可靠，验收证据可信，负责人也能识别方案中的遗漏。原文没有提供缺陷率、返工率或评审成本的对照数据，所以这仍然是一套个人经验，不能替所有团队证明效果。

作者说「机器现在读代码」，也说得偏满。团队成员仍可能通过代码排障、理解系统和接手维护。Prettier 能统一格式，却不能替人判断复杂逻辑是否容易理解。

相比全量逐行评审，我更倾向于按风险分配阅读精力：让工具处理机械检查，人重点看行为变化、关键假设和验证盲区。至于能少读多少，应该由项目的实际反馈决定，而不是由对 AI 的信任程度决定。