最近看了一篇关于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当团队。
而我,正在努力从前者变成后者。
随时随地看视频