AI 让老手慢了 19%，他们却觉得快了 20%

AI 让熟练开发者慢了 19%，他们事后却觉得快了 20%。这个数字来自 METR 2025 年的随机试验：16 名有经验的开发者，246 个真实任务，使用 AI 工具后完成速度下降 19%，但他们估计 AI 让自己快了 20%。

DORA 2025 报告发现，90% 的团队已经采用 AI，但 AI 采用仍与更高的交付不稳定性相关。Stack Overflow 2025 的数据则是：84% 的开发者使用 AI，46% 不信任其准确性。这些数字放在一起，指向一个麻烦：用得多，不代表用得准；感觉快，也不代表真的快。

发帖人在银行做 OpenShift 平台。OpenShift 是 Kubernetes 的企业发行版，生产环境里到处是版本、权限和回滚约束。他把自己的工作分成适合和不适合交给模型的两类。

适合交给模型的事

读日志、事件和堆栈，整理成按可能性排序的原因假设；解释接手来的 Helm chart、Jenkinsfile 或 Terraform 模块；起草 jq、PromQL、正则和 Bash；给一份 diff 做第二双眼睛；把聊天记录整理成复盘。

不适合交给模型的事

精确的 flag、CRD 字段和 API 版本。模型会生成形状正确的东西：来自更新版本的字段，或者别的子命令里的 oc 参数。看起来像真的，拿去跑就出事。

他用的提示词分成 7 段：

1. 角色和读者：资深工程师，跳过基础。
2. 环境要带版本。这是单个影响最大的杠杆。
3. 任务写成结果：排出 3 个最可能原因，不要说看看这个。
4. 证据放进标签，比如 <events>、<logs>。长输入把数据放前面，问题放后面。Anthropic 文档说，在复杂多文档输入上，这样做最多能提升 30% 的质量。
5. 约束要带理由：银行生产环境，只读，任何变更先 dry-run 并准备回滚。
6. 输出形状：每条原因带支持它的日志行，加一条只读确认命令。
7. 如果不确定某个 flag 或 field 在这个版本存在，直接说不确定，别猜。

接下来让集群自己检查：

oc explain deployment.spec.strategy.rollingUpdate
oc apply -f generated.yaml --dry-run=server
oc diff -f generated.yaml
helm template ./chart | kubeconform -strict
shellcheck generated.sh

生成的 YAML 先做 server dry-run，再 diff；Helm 模板过 kubeconform；shell 脚本过 shellcheck。模型给的是草稿，集群给的是答案。

对 Agent 工具，比如 Claude Code、Codex CLI、MCP，他的做法是：给只读 kubeconfig；任何会改东西的操作都要批准；常驻规则写进 CLAUDE.md 或 AGENTS.md；日志和工单当不可信输入；别把生产凭据放笔记本。

监管数据这块，消费级和企业级条款在训练数据上不一样。发帖人提到，Anthropic 自 2025 年 8 月起的消费者条款允许用 Free、Pro、Max 对话训练，除非用户选择退出；商业条款排除训练。OpenAI 表示不用企业数据训练。粘贴前脱敏，但把脱敏当安全带，别当保证。

原帖最后问：有没有人真的量过自己用 AI 和不用 AI 的速度，不只靠感觉？

原帖：https://www.reddit.com/r/PromptEngineering/comments/1xslvg4/ai_made_experienced_devs_19_slower_while_they/
长版和三个可复用提示词：https://aib-devops.com/en/blog/ai-for-devops-engineers/ 发帖人的博客，无广告和注册。