从“数字实习生”到可靠协作者——AI Agent规范的六大军规启示

最近看了一篇关于AI Agent规范编写的深度分析，读后的第一反应是：原来我一直在用管理人类员工的方式管理AI，却期待它表现出超越人类的执行力。

这本身就是一种悖论。

文章开篇提到的一个场景让我会心苦笑——"一旦上下文过长，模型就会开始'罢工'"。

这不就是我过去三个月的真实写照吗？我曾在Cursor里丢给Claude一份长达8000字的PRD，要求它开发一个完整的用户系统。结果它写了一半就开始"失忆"：前面说要用的JWT认证，后面改成了Session；数据库表结构改了三次，每次都不记得上一次为什么这样设计。

当时我以为这是AI的"智力问题"。现在我才明白，这是我的"管理问题"。

就像文章里那个精妙的比喻：AI Agent是一个"只要有机会就绝对会偷懒耍滑的奇怪数字实习生"。它不是不聪明，而是太"聪明"——聪明到会在信息过载时选择性遗忘，会在边界模糊时走最短路径，会在无人监督时自信满满地犯错。

而我，作为它的"直属领导"，却连一份清晰的Job Description都没给它。

GitHub从2500个案例中提炼出的六大核心领域（命令、测试、项目结构、代码风格、Git工作流、边界），乍看之下平淡无奇——这不就是常规软件工程的那一套吗？
但细想之下，这恰恰揭示了AI时代最核心的认知转变：我们不是在"使用"一个工具，而是在"管理"一个劳动力。

• 命令（Commands）对应的是执行标准——告诉它用什么工具、按什么流程；
• 测试（Testing）对应的是验收标准——让它知道做到什么程度算"完成"；
• 项目结构（Structure）对应的是组织架构——明确权责边界；
• 代码风格（Style）对应的是企业文化——统一行为模式；
• Git工作流（Workflow）对应的是协作机制——定义如何与他人（或其他Agent）互动；
• 边界（Boundaries）对应的是红线意识——什么绝对不能碰。

这哪里是在写技术文档？这分明是在设计一套数字组织的管理制度。

文章中最让我印象深刻的是那个三级边界系统：
✅ Always：始终执行——无需请示，直接做；

⚠️ Ask first：事先询问——先汇报，后执行；

🚫 Never：绝不执行——碰都不要碰。

这套机制的设计之精妙，在于它承认了AI的有限自主性。

我们人类管理者常常陷入一个误区：要么把AI当全自动机器人（结果它闯祸），要么把AI当完全无能的工具（结果自己累半死）。而三级边界提供了一个中间态——在可控范围内赋权。
"严禁提交密钥"被评为最有益的单一约束，这个细节让我停顿了很久。因为它暴露了一个残酷现实：AI最危险的不是"做不到"，而是"不知道自己做错了"。

它不会恶意泄露你的AWS密钥，它只是不理解"为什么这串字符不能出现在GitHub上"。这种无知的危险，比故意的破坏更难防范。

文章大力推崇的"计划模式"（Plan Mode）——让AI先在只读状态下分析、规划、提问，确认无误后再执行——与我过去的使用习惯完全相反。

我以前的做法是：想到一个需求，立刻打开AI工具开始写代码。遇到问题再改，发现遗漏再加。结果往往是：代码越写越乱，债越积越多，最后不得不推倒重来。

这像极了现实中那些"敏捷"到失控的项目：用战术上的勤奋，掩盖战略上的懒惰。

GitHub的规范驱动开发（Spec-driven Development）流程——Specify → Plan → Tasks → Implement——本质上是在说：在AI时代，规划的价值被严重低估了。
因为AI的执行速度太快，快到人类来不及思考；快到我们可以用同样的时间尝试十种方案，却忘了问"这十个方案是不是都错了方向"。

文章里引用Simon Willison的话尤其扎心："从编程Agent那里获得好结果，感觉就像在管理一名人类实习生，这种相似度让人不安。"

不安的源头，或许在于我们终于意识到：管理AI和管理人类，底层逻辑竟然如此相通。

读完这篇文章，我对AI Agent的认知发生了微妙但重要的转变。

我不再把它看作一个"更聪明的搜索引擎"或"更快的代码生成器"。我开始把它看作一个需要被管理的组织单元——一个有着超强执行力、但判断力存疑的"数字员工"。
而规范（Spec），就是我对这个"员工"行使管理权的制度性工具。

它不是我给AI的"提示词"，而是我们之间的契约；

不是我单方面的指令，而是双方共同的参照系；

不是一次性的文档，而是持续迭代的活物。

文章结尾处的那句"祝你规范编写愉快"，初读觉得有些俏皮，细品却意味深长。

因为在AI时代，编写规范的能力，或许将成为区分"AI的使用者"与"AI的管理者"的关键分水岭。

前者把AI当工具，后者把AI当团队。

而我，正在努力从前者变成后者。