导读：为防止人工智能编码助手失控，开发者们需要学会编写完善的规范，并培养产品管理等技能。
没有一个严谨的开发者会奢望人工智能能奇迹般地替他们完成所有工作。一个更务实（尽管仍有些不适）的共识正在形成：人工智能可以成为出色的实习生，但它无法替代资深开发者。然而，如果这个观点成立，那么其逆否命题同样成立：如果人工智能是实习生，那么你就是它的经理。
遗憾的是，大多数开发者并非天生的管理者。
在与 GitHub Copilot、Cursor 或 ChatGPT 等工具的日常互动中，这种现象屡见不鲜。我们常常给出模糊且不成熟的指令，比如“把按钮变成蓝色”或“修复数据库连接”。然后，当 AI 凭空捏造出一个 2019 年就已不存在的库，或是把一个关键的身份验证流程改造成一个公开的安全漏洞时，我们又表现得十分惊讶，转而指责大模型不够智能。
但问题通常不在于模型的智能程度，而在于我们缺乏清晰的表达和规划。要充分发挥这些工具的价值，我们需要的可能不是更高级的编程技巧，而是更完善的规范。我们应该将人机交互视为一个正式的委派流程，而非许下魔法般的咒语。换言之，在这个时代，我们需要成为更优秀的管理者。
缺失的技能：规范
谷歌工程经理 Addy Osmani 近期发表了一篇题为《如何为人工智能代理编写完善的规范》的文章。这无疑是我见过的最实用的人工智能管理工作指南之一，它对我近期思考的一些核心原则进行了有益的拓展。
Osmani 并非在兜售一个自主编码的科幻未来。他只是想防止你的 AI 助手迷失方向、遗忘关键信息或被海量上下文淹没。他的核心观点简单而深刻：将庞大而单一的规范一股脑地丢给 AI 往往会失败，因为上下文窗口和模型的注意力预算是有限的。
他提出的“智能规范”正是解决方案。这些规范对 AI 代理有用，能够在不同会话间保持稳定，并且结构清晰，以便模型能聚焦于最重要的事项。这正是许多关于“AI 将使开发者效率提升十倍”的论述中所缺失的关键能力。真正的优势并非源于模型本身，而是源于那些能够将业务意图转化为技术约束、并将输出转化为可运行软件的人。生成式人工智能实际上提升了资深工程师的价值，而非削弱。
从提示到产品管理
如果你指导过初级开发者，你一定知道该怎么做。你不能只是简单地说“做个登录功能”，而是要详细说明所有细节：“使用 OAuth，支持 Google 和 GitHub，在服务器端维护会话状态，不要涉及支付，编写集成测试，并记录接口。”你需要提供示例，指出潜在的陷阱，并要求提交小型的 Pull Request 以便复查。
Osmani 将同样的管理原则应用到了 AI 代理的工作流中。他建议从一个高层次的愿景开始，让模型将其扩展为更完整的规范，然后不断迭代修正，直到它成为双方共享的“真理来源”。这种“规范优先”的方法正迅速成为主流，从博文思想演变为各种工具实践。GitHub 的 AI 团队一直在倡导规范驱动开发，并发布了 Spec Kit，将 AI 助手的工作限制在制定规范、计划和任务之后。JetBrains 也提出了类似的观点，建议在 AI 开始修改代码前设置审查检查点。
简单翻译一下：如果你的组织连向人类讲清楚需求都困难重重，那么 AI 客服也帮不上忙，它们只会加剧混乱，并且收费更高。
一个真正有效的规范模板
一份优秀的 AI 规范不是征求意见稿，而是一种能够降低偏离成本、提升正确率的工具。Osmani 建议从一个简洁的产品简介开始，让 AI 代理起草更详细的规范，然后将其打磨成一份可在不同阶段重复使用的动态参考文档。
这固然不错，但真正的价值在于规范中包含的具体要素。基于 Osmani 的研究以及对成功团队的观察，一份功能完善的 AI 规范必须包含以下几个不可或缺的部分：
- 目标与非目标：仅仅描述要做什么（目标）是不够的，还必须明确说明不做什么（非目标）。非目标可以防止意外的重写和“好心办坏事”的范围蔓延，比如 AI 在修复一个拼写错误时，突然决定重构你的整个 CSS 框架。
- 关键上下文：提供模型无法自行推断的上下文信息，包括架构约束、领域规则、安全要求和集成点。如果这些信息对业务逻辑至关重要，就必须明文说明，AI 无法猜测你的合规边界在哪里。
- 明确界限：你需要一个清晰的“禁止触碰”列表。这些列表就像护栏，可以防止实习生删除生产数据库配置、提交敏感信息，或是修改支撑系统运行的遗留供应商代码。
- 验收标准：“完成”意味着什么？这必须通过可检查的条目来体现：测试用例、必须保持不变的条件，以及一些容易被忽略的边界情况。
如果你觉得这听起来很像优秀的软件工程实践（甚至是优秀的管理学），那就对了。确实如此。我们正在重新拾起我们曾经有些忽视的这门学科，只不过现在它穿上了一件由新工具编织的外衣。
语境是一种产品，而非一次性提示
开发者对 AI 助手感到沮丧的一个常见原因是，我们把“写提示”当作了一次性活动，但事实并非如此。它更像是搭建一个稳定的工作环境。Osmani 指出，大型提示失败的原因不仅在于上下文长度的限制，还在于当一次性塞入过多指令时，大模型本身的性能会下降。
Anthropic 将这种做法称为“上下文工程”。你必须精心构建背景、指令、约束、工具和期望的输出格式，模型才能可靠地遵循其中最重要的信息。这使得开发者的职责描述逐渐向“上下文架构师”的角色转变。开发者的价值不再仅仅在于知道某个特定 API 调用的语法（AI 比我们更清楚这一点），而在于知道哪个 API 调用与当前业务问题相关，并确保 AI 也知道这一点。
正如 Ethan Mollick 指出的，你必须了解你的“实习生”在哪些方面有用，在哪些方面会添乱，以及在哪些方面根本不应该委派给它，因为出错的代价太高。说到底，你需要判断力。而判断力，说到底，就是深厚的专业知识。
代码所有权的陷阱
当然，这种模式也存在风险。如果我们把实现工作全部交给 AI，自己只专注于编写规范，我们就有可能与软件的实际运行细节脱节。Honeycomb 的 CTO Charity Majors 就曾对此发出警告。她区分了“代码作者”和“代码所有者”。AI 使得成为“代码作者”的成本变得极低——几乎为零。但“所有权”（即在生产环境中调试、维护和理解代码的能力）的成本却越来越高。
Majors 这样说道：“当你过度依赖 AI 工具，当你只是监督而非亲自动手时，你自身的专业知识会迅速衰退。”这就为“开发者即管理者”的模式带来了一个悖论：正如 Osmani 所建议的，要写出一份优秀的规范，你需要深厚的技术领悟力。但如果你把所有时间都花在写规范上，而让 AI 去写代码，你可能会逐渐丧失这种深刻的技术理解。
解决方案可能是一种混合方法。开发者 Sankalp Shubham 将此称为“低档位驾驶”。他以手动挡汽车作比喻：对于简单的样板任务，你可以挂上高档位，让 AI 快速行驶（高度自动化，低控制）。但对于复杂、新颖的问题，你需要降档。你可以自己编写伪代码，可以手动构建复杂的算法，而只让 AI 来生成测试用例。我们仍然是驾驶员——AI 是强大的引擎，但绝不是司机。
未来由管理驱动
颇具讽刺意味的是，许多开发者选择这个职业，恰恰是为了避免成为管理者。他们热爱编码，因为代码具有确定性。计算机（在大多数情况下）会严格按指令执行。而人类（包括实习生）则不然，他们行为难以预测，思维模糊、充满歧义，需要被引导。
如今，开发者的主要工具正变得和他们曾想避开的人类一样，充满了不确定性和模糊性。要想在这个新环境中取得成功，开发者需要培养一些实际上相当难得的“软技能”。你需要学会如何清晰地阐述愿景，需要学会如何将复杂问题分解为独立的、模块化的任务，以便 AI 能够在有限的上下文内有效处理。
在这个时代，脱颖而出的开发者可能不是打字最快的人，也不是能背出最多标准库的人。他们将是这样的人：能够清晰地将业务需求转化为技术约束，使得即使是一只“鹦鹉”（指 AI）也不会偏离轨道。欲了解更多关于技术趋势与开发者成长的杂谈，欢迎访问 开发者广场。同时，深入探讨 人工智能 领域的技术细节与最佳实践，也是提升这项关键技能的重要途径。这一切的交流与学习，都可以在 云栈社区 这样的技术社区中发生。
发表于 10 小时前
|
查看: 0|
回复: 0
