文章归档

很多线上问题不是“看不出来”，而是证据太散：日志、进程状态、配置、时间线分布在不同位置，临时命令又只服务于当下这一次判断。结果是问题排完了，下次仍要重新拼一遍流程。

比较稳妥的做法，是把一次有效排查中真正有价值的动作沉淀成固定顺序的诊断流程。它不追求覆盖所有场景，只要求在常见故障上能快速收集同一组证据，减少遗漏和返工。

本文讨论的是本地或远程环境中的通用诊断方法，不依赖特定框架。核心目标很简单：把“临时猜测”变成“可重复验证”。

很多团队都会写临时脚本：批量改文件名、导出数据、生成配置、清理日志、检查构建产物。脚本第一次出现时通常只为解决一个具体问题，写得快、跑得通就够了，但它一旦被第二次使用，就已经进入了工程资产的范围。

本文讨论的不是把脚本做成完整平台，而是如何在成本可控的前提下，让一个临时脚本具备可重复执行、可定位问题、可交接维护的基本能力。结论很简单：先固定输入输出边界，再补齐失败处理和运行说明，最后才考虑抽象和扩展。

适用场景包括本地开发辅助脚本、CI 中的小型检查任务、一次性迁移后仍可能复用的数据处理脚本。对于只运行一次且已经归档的脚本，不必过度整理；对于会被多人、定期或自动化环境调用的脚本，则应该尽早收敛成稳定工具。

很多团队都会积累一批临时脚本：导数据、补配置、批量改文件、清理缓存、生成报表。它们通常从一次问题处理开始，能跑通，但没有边界、没有检查、没有回滚提示。问题不在于脚本短，而在于它已经承担了生产操作，却仍按临时命令的方式维护。

本文讨论的不是如何把所有脚本改造成复杂平台，而是如何把一个已经有价值的脚本整理成可复跑、可审查、可交接的工程步骤。结论是：先明确输入输出和影响范围，再补齐预检查、幂等处理、日志记录和失败退出，让脚本从“某个人会用”变成“按说明就能稳定执行”。

让 AI 修改代码时，真正危险的往往不是它不会写，而是它一次写得太多：顺手整理目录、统一命名、升级依赖，再补上一层“更合理”的抽象。最终 diff 看起来很完整，验证成本却超过了人工重写。

解决办法不是把提示词写得更长，而是给每轮修改设定一个明确的“变更预算”。预算限制本轮可以触碰的文件、行为和验证范围，使 AI 的产出保持在人工能够快速审查、机器能够及时验证的尺度内。