「我没有提示词，只有工作流。」这是资深工程师对AI编程工具的真实使用总结。不是炫技，是每天省下的10-30分钟，堆成了主业之外的持续产出。

「先搜索，再动手」—— 15秒换3小时的教训

当任务涉及单个文件之外的改动——重命名、模式替换、重构——我会先下达一条指令：

动手改之前，先用grep找出所有出现X的地方，列出来给我看，我再告诉你哪些要改。

这句话阻止的糟糕修改，比任何测试套件都多。它强制AI在行动前列举影响范围，也给我一个自然的"停，这改动太大了"的刹车点。

成本15秒，收益是3小时后不会发现它把迁移脚本里的名字也改了。

「先写测试，让它挂，再修复」

不是因为我是TDD原教旨主义者。而是AI有个怪毛病：写起代码来信心十足，却常常是错的。测试是发现这个问题最便宜的方式。

我的实际话术：

针对我刚才描述的bug，先写一个失败的测试。运行它，确认失败的原因是对的。然后写修复，再跑一遍。

"运行它，确认失败的原因是对的"是关键。意外通过的测试比没测试还糟——它们制造虚假的安全感。强制AI观察自己从红到绿的过程，能抓住那些"测试错了，代码其实有问题"的微妙情况。

「先解释，再出diff」

学习新东西时——库API、框架模式、语言特性——我不会让Claude直接写代码。

写代码之前，先用大白话解释你要做什么。谁调谁，状态机长什么样。然后再出diff。

没有这一步，我会拿到一堆能跑但看不懂的代码，理解债务不断累积，直到第二或第三次迭代时爆雷。

「每次只改一个文件，除非我明确说可以」

Claude Code的默认行为是看到关联就顺手改了，这在复杂代码库里很危险。我的约束：

一次只改一个文件。改完给我diff，我确认后再进行下一步。除非我明确说"一起改了"，否则不要跨文件。

这防止了"顺手优化"导致的级联错误，也让审查变得可控。

「提交前，用git diff --stat给我总结」

会话结束前：

用git diff --stat给我看看改了哪些文件，每处改动一句话说明。

这是最后的防线。AI会忘记自己改过什么，这个命令强迫它（和我）正视变更范围，防止意外提交debug代码或临时文件。

这些工作流的核心不是控制AI，是控制我自己——防止在"它看起来懂了"的幻觉里，一步步把代码库推向不可维护的深渊。