我用了大概半年的 cursor，我发现以目前的 AI 技术，还不能指望 AI 能神奇地替自己干活。
也就是说，现在还不能做到，我告诉他成品的效果，然后我出门玩儿，让他干活儿，回家就奇迹般的完成的整个产品的创作。
开发者们逐渐达成了一种更务实的共识：AI 更像是个实习生，而不是资深开发者的替代品。但既然如此，其推论也同样成立：如果你把 AI 当作实习生，那你就是它的经理。
可惜的是，大多数开发者并不擅长当经理。
这也就是我题目的观点，一个好的开发可能用不好 AI。
这一点在日常使用 Cluade、Cursor 或 ChatGPT 等工具时随处可见。
我们常常抛出模糊、草率的指令，比如“把按钮改成蓝色”或“修一下数据库连接”，然后又对 AI 的胡编乱造感到惊讶——它可能凭空引用一个 2019 年就已废弃的库，或者把关键的身份验证流程重构成了一个公开的安全漏洞。
我们责怪模型，说它还不够聪明。
但问题通常不在于模型的智能程度，而在于我们缺乏清晰的表达。
要想从这些工具中获得价值，我们不需要更多花哨的提示工程技巧，而是需要更好的需求规格说明（specification）。
我们必须把与 AI 的交互看作一种正式的委派过程，而不是念咒施法。
换句话说，我们需要成为更好的经理。
被忽视的关键技能：写好规格说明
Google 工程经理 Addy Osmani 最近发表了一篇题为《如何为 AI 智能体写出一份好规格说明》（How to write a good spec for AI agents）的教程，堪称这一主题的典范。这是我见过的关于“如何当好 AI 经理”最实用的操作指南，也很好地延伸了我最近提出的一些核心原则。
Osmani 并不是在兜售“全自动编码”的科幻愿景。他关注的是如何防止 AI 智能体迷失方向、遗忘上下文，或被信息淹没。
他的核心观点简单却深刻：向智能体丢出一个庞大、单体式的规格文档往往行不通，因为上下文窗口限制和模型的注意力预算会成为障碍。
他的解决方案是所谓“智能规格”（smart specs）——这些规格要对智能体真正有用、能在多个会话中持久有效，并且结构清晰，让模型能迅速抓住重点。
这正是当前“AI 将使开发者效率提升 10 倍”这类讨论中普遍缺失的一环。杠杆效应并非来自模型本身，而是来自那个能把意图转化为约束、再把输出转化为可运行软件的人。生成式 AI 实际上提高了对“资深工程师”的要求，而非降低，因为它需要资深工程师掌握另一项技能，了解你的项目，并说出来。
从提示词到产品管理
如果你带过初级开发者或者实习生，你一定早就明白这个道理。你肯定不会只说一句“做个登录功能”，而是会明确细节：“创建一个新的登录页面，两个输入框，居中对齐，然后最下面一个发送验证码，一个登录按钮，使用服务端提供的 API 触发登录。”
或者是：“用 OAuth，支持 Google 和 GitHub 登录，会话状态必须保存在服务端，不要碰支付模块，写好集成测试，并为接口写文档。”
诸如此类...
你会提供示例，指出雷区，还会要求提交小的 PR，以便及时检查工作。
Osmani 正是将这种管理纪律迁移到了 AI 智能体的工作流中。他建议先给出高层愿景，让模型扩展成更详细的规格，再由你反复修改，直到这份规格成为双方共享的“唯一真相源”。
这种“先写规格（spec-first）”的方法正迅速成为主流，从博客文章走向实际工具。
GitHub 的 AI 团队大力倡导规格驱动开发，并推出了 Spec Kit，要求智能体在执行任务前必须有明确的规格、计划和任务分解。
JetBrains 也持相同观点，建议在智能体开始修改代码前设置审查检查点。
Thoughtworks 的 Birgitta Böckeler 甚至提出了一个许多团队悄悄回避的尖锐问题：她指出，规格驱动的演示往往默认开发者会完成大量需求分析工作——即使问题本身模糊不清，或规模大到本应由产品经理和利益相关方主导。
换句话说：如果你连给人类讲清楚需求都困难，AI 不会救你，只会以更高的 token 消耗放大混乱。
换更多的钱，办更小的事儿！
一份真正有效的 AI 规格模板
一份好的 AI 规格不是 RFC（征求意见稿），而是一种让偏离成本高昂、正确实现成本低廉的工具。
Osmani 建议从简洁的产品简报开始，让 AI 起草详细规格，再由你修正为可在多个会话中复用的“活文档”。这很好，但真正的价值在于你包含的具体内容。
基于 Osmani 的工作和我对高效团队的观察，一份可用的 AI 规格必须包含几个不可或缺的要素：
- 目标与非目标（Objectives and Non-goals）
仅用一段话描述目标远远不够。你必须明确列出哪些内容不在范围内。“非目标”能防止 AI 在修复一个拼写错误时，自作主张地重写整个 CSS 框架。 - 模型无法自行推断的上下文
包括架构约束、领域规则、安全要求和集成点。只要影响业务逻辑，你就得写清楚。AI 无法猜出你的合规边界。 - 明确的边界（Boundaries）——这是最关键的
你需要一份“禁止触碰”清单。这些护栏能防止“实习生”误删生产数据库配置、提交密钥，或修改那些维系系统运转的老旧供应商目录。 - 验收标准（Acceptance Criteria）
“完成”到底意味着什么？这应该体现为具体的检查项：测试用例、不变量，以及几个常被忽略的边界情况。如果你觉得这听起来像“良好的工程实践”（甚至“良好的管理”），那是因为它本来就是。我们只是借新工具之名，重新拾起了曾被忽视的基本功。
发现了吗？如果用 AI 开发产品，开发者必须要了解产品，了解业务，了解目标，去成为 Product Owner！
上下文是一种产品，不是一条提示
开发者对 AI 智能体感到沮丧的一个原因是：我们总把提示当作一次性操作，但它其实不是。它更像是搭建一个工作环境。
Osmani 指出，长提示失败不仅因为上下文长度限制，更因为模型在同时接收太多指令时表现会变差。
Anthropic 将这种能力称为“上下文工程”（context engineering）——你必须将背景信息、指令、约束、工具和期望输出结构化组织，让模型能可靠地聚焦于最重要的部分。
这实际上改变了开发者的角色定位——从“API 调用专家”转变为“上下文架构师”。
你的价值不再是你记得某个 API 的语法（AI 比你更熟），而在于你知道哪个 API 与当前业务问题相关，并确保 AI 也清楚这一点。
Ethan Mollick 在《给你的 AI 实习生办理入职》（On-boarding your AI intern）一文中说得更直白：你必须搞清楚实习生在哪方面有用、在哪方面烦人、在哪方面根本不该委派（因为出错代价太高）。这说白了就是判断力——而判断力的本质，就是专业经验。
代码所有权的陷阱
当然，这里也存在风险。如果我们把实现完全交给 AI，只专注于写规格，就可能脱离软件的真实世界。
Honeycomb 的 CTO Charity Majors 一直在警告这一特定风险。她区分了“代码创作”（authorship）和“代码所有权”（ownership）：AI 让创作变得近乎零成本，但所有权（即在生产环境中调试、维护和理解代码的能力）却变得更昂贵。
Majors 认为：“当你过度依赖 AI 工具，只做监督而不亲自动手时，你自己的专业能力会迅速退化。”这给“开发者即经理”的模式带来了悖论：要写出 Osmani 所倡导的好规格，你需要深厚的技术理解；但如果你整天只写规格、让 AI 写代码，你可能会慢慢失去这种理解。
你要明白，你是雇佣 AI 来帮你完成工作，而不是让 AI 成为代码的主人
解决方案很可能是混合模式。
开发者 Sankalp Shubham 将其称为“低档位驾驶”（driving in lower gears）。他用手动挡汽车打比方：对于简单、样板化的任务，你可以挂高档，让 AI 快速推进（高自动化，低控制）；但对于复杂、新颖的问题，你必须降档——你可能自己写伪代码，或亲手实现核心算法，只让 AI 生成测试用例。
你始终是驾驶员。AI 是引擎，不是司机。
未来属于规格驱动
颇具讽刺意味的是，许多开发者当初选择编程，正是因为想避开管理职责。他们喜欢代码，因为它是确定性的——计算机（大部分时候）会照你说的做。而人类（以及实习生）则混乱、模糊，需要指导。
如今，开发者最核心的工具本身变得混乱而模糊。
这也是为什么我说，“一个好的开发可能用不好 AI” 的原因。
要在这种新环境中成功，开发者必须培养那些看似“软”实则极难的技能：清晰表达愿景的能力，将复杂问题拆解为 AI 可处理的、上下文隔离的模块化任务的能力。
在这个时代脱颖而出的开发者，未必是打字最快或背诵标准库最多的人，而是那些能把业务需求转化为技术约束、清晰到连一只“随机鹦鹉”都无法搞砸的人。
AI 时代，说明白你的需求比写明白你的需求更重要！
