Claude Code 正在让我成为更好的 dev（而且我有数据） 🧠⚙️
Source: Dev.to
这并不是“停止编程”：而是工艺的另一个阶段 🧬
软件开发一直是一连串抽象的过程：每一次飞跃都在减少敲击键盘的次数，而不是责任。代理似乎是下一次飞跃——更少的输入，更多的决策和维护。
我的设置 🧩
| 工具 | 我的使用方式 |
|---|---|
| Claude Code (Sonnet 4.5) in the terminal | 完整实现，多文件工作，带反馈的迭代细化 |
| JetBrains AI (with Sonnet 4.5) | 在 IDE 中的聚焦提问，PR 评审，特定提示 |
我不喜欢某些人所谓的 vibe coding：使用 AI 超快构建并迭代直至可用 而不一定深入探究每个决定背后的技术“原因”。我倾向于 受控的 AI‑assisted development：代理加速执行，但由我掌控。所有合并的代码都会经过我的逐行审查。如果出现问题，我负责。
数字：/insights 对我真实使用情况的说明 📊
我在 Claude Code 中运行了 /insights，得到了一份仅覆盖过去两周终端活动的报告。注意： 我已经使用该工具数月——此报告只捕捉了这段时间。
- 445 条消息，12 天（≈ 37.1 条/天）
- +5,867 / −3,088 行，涉及 61 个文件
- 主导模式：迭代细化，共 13 场会话
我请求的前两大类别并列：
- 功能实现（17）
- Bug 修复（17）
其后是 UI 精细化（8）、PR 评论分类（7）以及 代码审查回复草拟（7）。
我使用它并不仅仅是“生成代码”。我用它完成整个闭环——从最初的实现到处理审查反馈。
当流程中断（这正是好的一面） 🧯
报告中最有价值的部分并不是我做得好的地方，而是这段：
- Buggy Code (13)： 早期尝试出现类型不匹配、属性错误、逻辑失误。
- Wrong Approach (9)： 在代码库已经有合适模式可循时仍从头构建。
- 其他：过于激进的改动、细微不准确。
是的——首次尝试往往会出错。但关键的学习点很明确：我与代理人的问题并不是通过少用它来解决，而是通过提供更好的上下文来解决。
- 当上下文模糊时，代理人会猜测。
- 当上下文包含正确的类型和现有代码库的模式时，收敛速度会很快。
比我更能描述我的工作流程的模式 🪞
/insights 捕捉到了我的主要工作流：我委派雄心勃勃的多文件实现，然后通过迭代积极引导，直至完成。出现错误的初稿并不是阻碍；它们是快速前进的预期代价——只要我在指引方向。
这也是我对一位有才华的初级开发者采用的相同方法：要求一个雄心勃勃的初稿，明知需要进一步打磨，然后通过上下文和仓库规则进行指导。
我想强化的内容（根据报告） ✅
Three patterns I want to keep:
- 代码审查与判断 – 我把真实的 bug 与不可操作的评论区分开，并在需要时以有依据的理由进行反驳。代理帮助组织和起草，但接受或拒绝的决定权在我。
- 端到端一次性迭代 – 实现 → 反馈 → 修复 → 测试。我喜欢的细节：86 次使用
TodoWrite。使用代理时，规划是工作的一部分。 - 基于模式的决策 – 我更倾向于保持代码库的一致性，而不是增加维护成本的“新想法”。当提案偏离惯例时，我会重新使用现有模式作为参考。
我将制度化的要点 (📌)
从摩擦中，报告建议将规则写入 CLAUDE.md。以下是两个示例：
- 模式优先 – 在实现功能之前，先在代码库中寻找已有的模式并以其为参考。
- 类型优先 – 在提出 TypeScript 修复之前，先阅读相关的类型和接口。不要“猜测形状”。
报告还建议创建 技能（可复用的命令，用于重复的流程）。例如，一个用于代码审查回复的技能可以：
- 列出评论。
- 对其进行分类。
- 提出最小化的修复方案。
- 起草回复。
- 验证构建。
责任：你无法委托的部分 (🧱)
使用代理和让大脑关闭之间是有区别的。
我的一个朋友——一名管理员，而不是开发者——使用 AI 工具以惊人的速度构建应用。这很令人印象深刻，他的目标是让这些应用能够运行。
我的目标是让它们同样可维护且可辩护：能够理解它们、调试它们，并在出现故障时保持运行。
- 工具可能会宕机（即使是像 AWS 这样的大型服务）。
- 如果工具宕机，我仍然需要打开代码仓库，了解发生了什么，并进行修复——尤其是我在 PR 中提交的更改。
- 任何工具都可以生成代码，但它们无法做出判断，决定哪些代码应该存在、哪些不应该。
- AI 可以写代码；所有权却不能。
如果你想尝试而不产生依赖 (🧪)
如果你正处于相同的转型阶段，我唯一能给出的通用建议是：
- 把 AI 当作队友，而不是自动驾驶仪。
它能加速执行，但方向由你决定。 - 投入上下文。
正确的类型和仓库模式比华丽的提示更重要。 - 在 2–4 周后（且如果你使用 Claude Code），运行
/insights。
不是为了“自我验证”，而是为了发现重复的摩擦点（并纠正习惯）。 - 如果你刚刚起步， 一个结构化的起点对我帮助很大：免费 Nebius × JetBrains 联合推出的 AI 辅助编程 课程（链接见下）。
接下来 (🧭)
我不认为代理会“扼杀”开发。我认为它们改变了有价值工作的所在：更少的敲键，更需要判断、更多审查、以及更具防御性的技术决策。
我的下一步是衡量这些变化（尤其是 pattern‑first 和 types‑first）是否在下一个 /insights 周期中降低了 buggy code 和 wrong approaches。
- 如果数据有所改善，我会分享结果。
- 如果没有改善，我也会把结果分享出来。
对我而言，拥有基于数据的工作流反馈就是金子般的价值。
致谢 (🙌)
- 让我踏入此领域的课程： AI‑Assisted Programming by Nebius × JetBrains
- 终端工具： Claude Code
- 在我的 IDE（WebStorm）中使用的： JetBrains AI
- 照片作者 Daniil Komov，来源于 Unsplash