最近招了几个实习生做开发。这批毕业生是真正的 AI Native，用 Cursor、Claude Code 写代码的速度惊人，一天能交付过去一周的工作量。但几周下来，一个规律越来越明显：写得快的人，不一定走得远。
有经验的工程师拿到 AI 生成的代码，第一反应是审视：这个模块的边界在哪？它和现有系统怎么衔接？出了问题怎么排查？而刚毕业的实习生，很多时候的反应是：能跑就行，赶紧下一个。
代码量在涨，但项目在几轮迭代后开始走向混沌。新功能不断叠加，没人提炼共性，没人思考架构，最后代码变成一团无法维护的意大利面。写代码很快，但维护代码，或者说决定要写什么，这些才是真正难的部分。
这让我重新思考一个问题：和 AI 协作，到底需要什么能力？
我之前写过，Vibe Coding 时代有六种更稀缺的能力，其中"与 AI 协作的能力"只用了一句话带过。现在回看，这一条值得展开，因为它不是一种单一能力，而是一组复合的元能力：
和 AI 协作需要的是一种全新的能力：你得像一个系统架构师一样去定义 AI 的工作边界，像一个 QA 一样去校验它的输出质量，像一个产品经理一样去明确它"该做什么、不该做什么"。
像架构师一样定义边界
AI 的问题从来不是"做不好"，而是"不知道该做到哪里"。
给它一个模糊的指令，它会尽可能地填满空间。让它实现一个功能，它可能顺便改了三个不相关的模块。让它重构一段代码，它可能把整个文件重写了。不是因为它乱来，而是因为你没告诉它边界在哪。
中科院最近的 Vibe Coding 综述把这件事说得很清楚：人类在这种新范式中的角色是"意图阐述者、上下文管理者、质量仲裁者"。翻译成大白话，你得像一个系统架构师一样思考三个层面的边界。
输入边界：给 AI 什么上下文。不是越多越好，而是"恰好足够"。一个有经验的人知道哪些信息是关键约束，哪些是噪音。这和做系统设计时定义 API 的入参一样，精确的输入才能得到可控的输出。
输出边界：期望 AI 交付什么。格式、范围、粒度，都需要提前想清楚。"帮我写一个用户管理模块"和"帮我写一个用户注册接口，输入手机号和验证码，输出 JWT token，错误码参考现有规范"，得到的结果天差地别。
行为边界：允许 AI 自主到什么程度。哪些决策它可以自己做，哪些必须先问你。这和管理团队中的授权机制一模一样。
我在带实习生的过程中发现，有经验的工程师在给 AI 下指令前，脑子里已经有一张系统的"地图"。他们知道当前任务在整个系统中的位置，知道改动会影响哪些下游，知道哪些地方不能动。而缺乏经验的人，连地图都没有，自然也划不出边界。
这不是 Prompt Engineering 的问题。Prompt 只是表达边界的手段，真正的能力是你脑子里有没有那张地图。
像 QA 一样校验质量
AI 有一个被严重低估的问题：自洽性。
阿里内部的实践数据很说明问题：让 AI 同时写代码和单元测试，测试通过率 100%，但逻辑是错的。学生自己出题自己改卷，当然不会挂科。
这意味着"能跑"不等于"对了"，"测试通过"不等于"符合预期"。你不能把验收的权力也交给 AI，否则就陷入了一个封闭的自我论证循环。
和 AI 协作时，你得像一个 QA 一样建立独立的验收视角：
功能层面：它做的事，是不是你要的事？不是看代码写得漂不漂亮，而是看它有没有解决真正的问题。很多时候 AI 的输出"看起来很专业"，但仔细看会发现它在解决一个你没问的问题。
边界层面：它漏了什么？AI 倾向于处理 happy path，对边界条件、异常处理、并发场景的覆盖天然不足。一个有经验的 QA 的直觉就是：正常的都没问题，出问题的一定在边界。
一致性层面：它和已有系统的契合度如何？AI 不了解你的系统历史，不知道某个看似冗余的逻辑其实是为了兼容老数据，不知道某个命名规范是团队约定。每一次新增代码，都需要有人从系统整体的视角去判断它是否和谐。
我观察到的规律是：缺乏经验的人对 AI 的输出往往缺乏质疑意识。不是他们不想验证，而是他们缺乏"知道该质疑什么"的经验。这是一种需要时间积累的模式识别能力，AI 帮不了你。
像产品经理一样明确取舍
AI 的默认行为是"你问什么我就做什么，而且尽可能做多"。
对于简单的个人项目或爱好项目，这不是问题，因为维护成本低，试错代价小。但对于严谨的商业项目，尤其是需要落地、需要有人承担责任的项目，做多了比没做更危险。每一行代码都是负债，每一个功能都需要长期维护，每一次扩展都要考虑和现有系统的兼容。
好的协作者不只是给 AI 派任务，更重要的是帮它做取舍。这本质上是产品经理的核心能力：
明确优先级：十件事里，哪三件是现在必须做的？AI 不会帮你排序，它只会按顺序一件件做。如果你不排优先级，它会把精力均匀分配在所有事情上，结果什么都做了一半。
拒绝 scope creep：AI 在执行过程中经常"好心办坏事"，自行扩展范围。让它改一个 bug，它顺便重构了周边代码。让它加一个字段，它顺便改了数据库 schema。你需要有一个清晰的"不做什么"清单，这比"做什么"更重要。
定义"足够好"的标准：什么程度算完成？追求完美是 AI 的本能（它会不断优化直到你叫停），但在现实中，80% 的方案今天上线，比 100% 的方案下周上线更有价值。
在不断叠加功能的过程中，能否提炼出共性，能否看到抽象的机会，能否决定"这个功能虽然用户在要但现在不该做"，这些判断需要对业务的深刻理解。这是经验，不是工具能替代的。
一个人可以是一个团队，但门槛更高了
这三重角色的背后，是一个更大的趋势：AI 的加入，让原本必须一个团队才能完成的事情，现在一个人就能解决。
一个人可以同时写前端、后端、部署、测试。听起来是解放，但反过来想，这对个人的要求变得极高。你不再是流水线上的一个工位，而是需要理解整条线的人。
过去，架构有专人做，QA 有专人做，产品取舍有 PM 做。大家各司其职，哪怕你只精通一个环节，也能在团队中发挥价值。现在不一样了。AI 补齐了执行层的短板，反过来要求每个人具备更复合的能力。岗位在融合，上下游在渗透，你需要理解的不再只是自己那一块，而是整个系统。
这不是"全栈"那个概念。全栈说的是技术层面的广度。我说的是思维层面的升维：你得同时具备定义问题的能力（架构师）、验证答案的能力（QA）、和做出取舍的能力（PM）。
对于严谨的商业项目，你必须从高维度去理解整个系统是怎么架构的。出现问题的时候，你要清楚可能是哪个环节出了问题，并且能观测到每个过程的细节。这些能力，AI 不会教你，只有踩过坑、维护过真实项目的人才知道。
我的思考
这套元能力（定义边界、校验质量、明确取舍）不是 AI 时代才有的新发明。它们一直存在于优秀的工程师、产品经理、创业者的工作习惯中。只是过去，这些能力分散在团队的不同角色里，每个人只需要精通自己的那一块。
AI 做的事情，是把这些原本分散的能力要求，压缩到了每一个个体身上。它对人原本非常细化的能力提出了更高的要求，要求每个人具备更多元、更复合的思维方式。
会用 AI 工具不等于能驾驭 AI。就像会开车不等于能当赛车手，差距不在于踩油门的动作，而在于对弯道、对路况、对车辆极限的判断。
AI 越强，管理它的能力越值钱。这句话今天听着像一个观点，用不了多久就会变成一个常识。