导读：为防止人工智能编码助手失控，开发者们需要学会编写完善的规范，并培养产品管理等技能。

没有哪个严谨的开发者会指望人工智能神奇地替他们完成工作。

我们已达成一种更为务实（尽管仍略感不适）的共识：人工智能可成为出色的实习生，但无法取代资深开发者。然而，若此观点成立，那么其推论也成立：若人工智能是实习生，那你便是它的经理。

遗憾的是，多数开发者并不都是擅长管理的人。

我们每天都能在与 GitHub Copilot、Cursor 或 ChatGPT 等工具的交互中看到这种现象。我们随意下达一些模糊、不成熟的指令，比如“将按钮变为蓝色”或“修复数据库连接”，然后当 AI 凭空造出一个 2019 年就已不存在的库，或者把一个关键的身份验证流程重构成一个公开的安全漏洞时，我们却表现得十分惊讶。我们责怪大模型，称其不够智能。

但问题通常不在于模型的智能程度，而在于我们缺乏清晰的认知。要充分发挥这些工具的价值，我们所需的并非更高级的工程技巧，而是更完善的规范。我们应将人工智能交互视为一个正式的委托流程，而非一种魔法咒语。

换言之，我们需要成为更优秀的管理者。

缺失的技能：规范

谷歌工程经理艾迪·奥斯曼尼近期发表了一篇关于此主题的经典文章，标题为《如何为人工智能代理编写完善的规范》。这是我见过的最实用的人工智能管理工作指南之一，也是对我近期提出的一些核心原则的有益拓展。

奥斯曼尼并非试图向你兜售自主编码的科幻未来。他只是想防止你的智能体迷失方向、遗忘信息或淹没在上下文中。他的核心观点简单却深刻：将庞大而单一的规范一股脑地抛给智能体往往会失败，因为上下文窗口和模型的注意力预算会成为阻碍。

他所说的“智能规范”便是解决方案。这些规范对代理有用，能在不同会话中保持稳定，且结构清晰，以便模型能关注最重要的事项。

这正是大多数“人工智能将使开发者效率提升十倍”的论述中所缺失的关键技能。真正的优势并非源于模型本身，而是源于能够将意图转化为约束条件，并将输出转化为可运行软件的人。生成式人工智能提升了资深工程师的价值，而非降低。

从提示到产品管理

若你曾指导过初级开发人员，必定清楚该怎么做。你不能只是简单地说“构建身份验证”，而要详细说明所有细节：“使用 OAuth，支持 Google 和 GitHub，在服务器端维护会话状态，不涉及支付，编写集成测试，并记录接口。” 你要提供示例，指出潜在的陷阱，并坚持要求提交一个小型 pull request，以便你检查他们的工作。

奥斯曼尼正将同样的管理原则应用于代理工作流程。他建议先从一个高层次的愿景入手，让模型将其扩展成更完整的规范，然后不断修改该规范，直至它成为共享的真理来源。

这种“规范优先”的方法正迅速成为主流，从博客文章发展到各种工具。GitHub 的 AI 团队一直倡导规范驱动开发，并发布了 Spec Kit，将智能体的工作限制在规范、计划和任务之后。JetBrains 也提出了同样的观点，建议在智能体开始修改代码之前设置审查检查点。

翻译：若你的组织在与人沟通需求方面已然困难重重，那么客服人员也无济于事。他们只会加剧混乱，只不过收费更高罢了。

一个真正有效的规范模板

一份优秀的 AI 规范并非征求意见稿（RFC），而是一种能够降低偏差成本、降低正确性成本的工具。

奥斯曼尼建议先从简洁的产品简介入手，让代理人起草一份更详细的规范，然后将其修正为一份可在不同阶段重复使用的动态参考文档。这固然不错，但真正的价值在于规范中包含的具体组件。基于奥斯曼尼的研究以及我对成功团队的观察，一份功能完善的 AI 规范需要包含一些不可或缺的要素。

首先，你需要明确目标和非目标。仅仅描述目标是不够的，你必须列出哪些内容明确超出范围。非目标可防止意外重写和“好心办坏事”的范围蔓延，比如人工智能在修复一个拼写错误时，突然决定重构你的整个 CSS 框架。

其次，你需要提供模型无法推断的上下文信息。这包括架构约束、领域规则、安全要求和集成点。若这些信息对业务逻辑至关重要，你必须明确说明。人工智能无法猜测你的合规性边界。

第三，或许也是最重要的一点，你需要设定界限。你需要明确的“禁止触碰”列表。这些列表就像护栏，可防止实习生删除生产数据库配置、提交机密信息或修改支撑系统运行的旧版供应商目录。

最后，你需要验收标准。“完成”意味着什么？这应该通过检查来体现：测试、不变式，以及一些容易被忽略的边界情况。若你觉得这听起来像是优秀的工程实践（甚至是优秀的管理），那就对了。的确如此。我们正在重拾我们曾经忽视的这门学科，只不过披上了新工具的外衣。

语境是一种产品，而非提示

开发者对智能体感到沮丧的一个原因是，我们把提示当作一次性活动，但事实并非如此。它更像是搭建一个工作环境。奥斯曼尼指出，大型提示失败的原因不仅在于上下文本身的限制，还在于大模型在一次性堆砌过多指令时性能会下降。

Anthropic 将这种做法称为“上下文工程”。你必须构建好背景、指令、约束、工具和所需输出，才能让模型可靠地遵循最重要的信息。

这使得开发人员的职责描述转变为类似“上下文架构师”的角色。开发人员的价值不在于了解特定 API 调用的语法（人工智能比我们更了解这一点），而在于知道哪个 API 调用与业务问题相关，并确保人工智能也知道这一点。

Ethan Mollick 指出，你必须了解实习生在哪些方面有用，在哪些方面会令人烦恼，以及在哪些方面不应该委派，因为出错的代价太高。说白了，你需要判断力。而判断力，说白了，就是需要专业知识。

代码所有权的陷阱

当然，这里也存在着风险。若我们把实现工作交给人工智能，而只关注规范，我们就有可能脱离软件的实际运行情况。

Honeycomb 的首席技术官 Charity Majors 就此风险发出警告。她将其区分出“代码作者”和“代码所有权”。人工智能使得代码作者的成本极低——几乎为零。但所有权（即在生产环境中调试、维护和理解代码的能力）的成本却越来越高。

Majors 这样说道：“当你过度依赖人工智能工具，当你只是监督而非亲力亲为时，你自身的专业知识会迅速衰退。” 

这就给“开发者即管理者”的模式带来了悖论。正如 Osmani 所建议的，要编写一份优秀的规范，你需要深厚的技术领悟力。若你把所有时间都花在编写规范上，而让 AI 来编写代码，你可能会逐渐丧失这种深厚的技术理解。而解决方案很可能是采用混合方法。

开发者 Sankalp Shubham 将此称为“低档位驾驶”。他用手动挡汽车作比喻。对于简单的样板任务，你可以挂上高档位，让 AI 快速行驶（高度自动化，低控制）。但对于复杂新颖的问题，你需要降档。你可以自己编写伪代码。你可以手动编写复杂的算法，而只让 AI 编写测试用例。

我们仍然是驾驶员——人工智能是发动引擎，但绝不是司机。

未来由管理驱动

讽刺的是，许多开发者选择这个职业正是为了避免成为管理者。

他们喜欢编码，因为代码具有确定性。计算机（大多数情况下）会按照指令行事。而人类（包括实习生）则不然，他们行事鲁莽，思维混乱、模棱两可，需要人们指导。

如今，开发者的主要工具正变得混乱且含糊不清。

要想在这个新环境中取得成功，开发者需要培养一些实际上相当难得的软技能。你需要学会如何清晰地阐述愿景，你需要学会如何将复杂的问题分解成独立的、模块化的任务，以便人工智能能够在不丢失上下文的情况下处理这些问题。

在这个时代脱颖而出的开发者，未必是打字速度最快的人，或是熟记最多标准库的人——他们是能够将业务需求清晰地转化为技术约束的人，这样即使是鹦鹉，也不会出错。

作者：场长