第六章：验：运行命令与诊断（测试/lint/typecheck）

6.1 很多失败不是代码错，而是“验证没跑对”

常见问题：

• 没跑测试就交付
• 跑错命令（项目根本不是 npm test）
• 命令依赖环境变量/配置但没说明
• 命令进入交互式输入导致卡死

你要做的是把验收变成“固定清单”，让每次交付都有相同的验证路径。

6.2 先发现正确命令，再按顺序执行

如果你不确定项目命令，先让 Trae 在仓库里找：

请先从 package.json / pom.xml / build.gradle / pyproject.toml 找到正确的：
1) 测试命令
2) lint/typecheck 命令
3) 构建命令
然后按顺序执行，并汇总结果。

推荐顺序：

1. tests（先证明行为正确）
2. lint/typecheck（再保证风格与类型）
3. build（最后确保能编译/打包）

6.3 禁止交互式命令，避免卡死

建议你写一个硬约束：

不要运行任何需要交互输入的命令；如果必须交互，请先说明原因并给出非交互替代方案。

6.4 用诊断结果做“最后门禁”

除了命令输出，还要关注编辑器诊断（编译错误、类型错误、语法错误）。
你的目标是让交付时诊断为 0。

你可以要求：

修复完成后，请确保：
1) tests/lint/typecheck/build 通过
2) 诊断为 0（无编译/类型/语法错误）
3) 输出变更摘要与回滚方式

6.5 本章小结

你已经把“验收”变成可复现流程：

• 先找对命令，再按顺序跑
• 禁止交互式命令，避免卡死
• 以诊断为最后门禁，确保能编译运行

下一章把规则体系化：目录边界、依赖策略、验收门禁，如何让 Trae 的默认行为更像团队资深工程师。