大多数人把 AI 当成 Google 来用，这就是它糟糕的原因。

Source: Dev.to

初始体验

在第一个月里，我把 Copilot 当作一个有抱负但没有约束的初级工程师来使用。它会写出我根本没要求的代码。函数进行到一半时，Copilot 会跳到前面——创建新方法、建议完整的类，像想要证明自己的初级工程师一样主动出击。

爆发点

在一次重构中，Copilot 输出的代码忽视了我们的风格指南，创建了名为 R 和 T 的变量，重复了我已经抽象的逻辑，并且把同一个模式重复了三次，而不是识别出抽象的可能性。测试全部失败，而它并不在乎——我并没有教它在乎。我花了两个小时清理本该只用二十分钟就能正确编写的烂摊子。

转变方法

我意识到自己在提示、得到过度扩展的输出，然后再裁剪——花在编辑 AI 输出的时间比自己写代码还多。问题不在于 AI，而在于我对答案的期待，而不是定义一个系统。

我停止尝试通过重新提示来摆脱糟糕的输出，转而更换 AI 所“抽取”的“大脑”。我创建了包含我们工程标准的 markdown 文件：我们如何编写需求、在范围界定前会问哪些问题、用户故事与任务的区别、我们如何权衡取舍、何时倾向于复制而不是抽象，以及在代码库中“干净”意味着什么。

编码标准

此后，当代理生成代码时，它不再即兴发挥；而是执行我们已经定义好的模式。我不再是在提示一个初级工程师——而是在指挥一位高级工程师。高级工程师写出更好的代码，因为他们能识别模式、知道何时抽象，并理解那些未写入文档的文化约束。你无法通过提示把这些灌输给 AI；只能把它们编码进去。

我们把这些标准做成了技能、规则、代理和钩子。我们为业务分析（BA）角色、解决方案架构师、代码审查流程和质量保证（QA）准备了 markdown 文件。当代理生成规格或编写代码时，它会引用这些文件——执行已定义的模式，而不是即兴创作。

通过系统思维实现规模化

过去的限制是人手：“我们人手不够”。现在的限制是算法质量——我们对判断的编码程度以及对“好”的定义。首席工程师和架构师采用 AI 的速度和深度都快于中级开发者。这并不是因为他们更技术，而是因为他们已经在以系统的方式思考。

• 中级工程师把 AI 当作配对编程工具：提示、审查、接受、循环。
• 架构师把 AI 当作基础设施：定义模式、编码约束，让系统自行执行。

采纳观察

• 首席工程师和架构师的 AI 使用量更高。
• 他们以系统思维为主，使得思考能够指数级扩展。
• 成本不在于失去手工艺，而在于学习一种新技能——编排，而不是单纯的编码或提示。

理解如何串联代理、在哪里插入人工判断、以及如何编码标准，使其既足够严格以防违规，又足够灵活以给你惊喜，这才是新的竞争力。

重新思考 AI 交互

当工程师在使用 AI 时遇到瓶颈，他们是重新提示还是重新架构？他们是尝试用更好的词汇引导 AI，还是改变 AI 所抽取的内容？第一种方法是线性扩展（一次提示、一次输出、一次编辑）。第二种方法是指数扩展（一次定义系统，永久执行）。

大多数人把 AI 当作 Google 使用，因为界面就是这么暗示的：输入、接受、继续。它看起来像进步，但进步不是检索速度，而是杠杆效应。Google 给你答案；高级工程师给你系统。你在跑哪条路？