我的习惯是先 diff 看改动面，再决定跑不跑。
TRAE 改完我会先扫一眼它动了哪几个文件、每处改动的意图对不对，尤其是它“顺手”新建的文件和改的依赖——这两类最容易埋雷。确认改动面符合预期，我才去跑。
只有一种情况我直接跑：改动特别小、且只在测试里，比如加一个单测函数。这种错了成本极低。
但我吃过亏：有一次它“顺手”把数据库迁移也改了，我没看就跑，环境直接脏了。从那以后凡是涉及 schema、配置、删除类，一律先看 diff。
你们大概是什么比例？是一股脑跑，还是也先 review？
标签：#互动交流
先跑，确认能跑通、功能实现准确无误先，然后看情况是否需要跑通单元测试和UI自动化测试，最后review和细节调整。一般不会让ai直接执行schema，配置也是，涉及数据库、配置方面还是会先检查确认
你这个顺序挺有意思——先把"能跑通"当第一道闸，再补单测/UI 自动化，最后才 review。我刚好反过来，diff 当第一道闸。好奇一个点：你遇到过"跑通了但其实埋了雷"的情况吗？比如逻辑对、边界错，单测也没覆盖到的那种。
遇到过，所以后面的review就需要多花一些心思，还可能需要返工。我感觉我可能说错了，使用ai后，我更多的使用的是SDD规范驱动开发，先出规范、原型，这其中就包含schema和配置，然后按照确认后规范进行开发，在执行开发时要求它写单元测试和UI自动化测试，并要求跑通测试，它会在测试的同时修复发现的问题，最终测试与功能都通过后，我才会验证功能结果和review。有时它完成没有达到我想要的效果、代码不规范超出边界，就会让它再返工 
我这边更多是算法工程，所以我一般都是先plan，然后看plan后再跑。
然后对开发项目会维护两个skill，一个是plan+run之后记录功能的更新，另一个是run完测试发现了bug，然后改完bug会额外记录一下bug_fix的记录。