Appearance
DeepSeek-V4-Pro 发布，我的 AI 员工该涨薪了
8 月 13 号 DeepSeek-V4-Pro 发布，朋友圈当天刷屏。跑分截图、代码对比，一轮接一轮。
别人在看模型有多强，我在想另一件事：我的员工，大脑要升级了。
我有一个员工，入职一年多。不占工位，不请假，不要工资，凌晨三点叫它干活也不会有情绪。这一年它从"发出来的代码我不敢看"，变成现在我敢把十万行的老工程直接丢给它。V4-Pro 发布，对它来说就是免费换了个更聪明的大脑。
带过人的人都懂一个道理：一个员工好不好用，三分看能力，七分看怎么带。AI 也一样--它只是工具，文章写得好不好，代码改得对不对，最后还是要看用它的人。
严格说它连员工都不算。员工还有主观能动性，它没有：没人派活，它一个字也不会写；没人教，它连你的项目用什么框架都不知道。它更像一支笔--同一支笔，文学家手里写出四大名著，数学家手里算出万有引力，艺术家手里画出心里的世界。心中有丘壑，下笔才有神。工具还是那个工具，差别从来在拿工具的人。
这一年我带的其实不是它，是我带它的方式。过程不算光彩，走了整整一年弯路：先把它带成复读机，再把它放养到闯祸，最后才找到那个度。
一、口头培训的时代：同一句话，我讲了四遍
它刚入职那阵，我培训它的方式跟带新人一样：靠嘴。
"我们用这个框架。""参数别用 Map。""先看 service 层。"每次开工前交代一遍。问题是它记不住--不是它笨，是它压根没有记忆：会话一关，培训内容全部清零，第二天从头再来。同一个"参数别用 Map"，我一个礼拜讲了四遍，讲到后面开始怀疑，到底是它的问题还是我的问题。
后来我发现，所有用 AI 干活的人都在经历同一件事：你教它的话，全是一次性的。团队里更乱，每个人口头培训出来的 AI 都不一样，同事踩过的坑，换个人接着踩；收藏夹里存了一堆提示词，真干活的时候，还是从需求背景开始重新描述。
解决办法不新鲜：把培训内容写成文件，放进项目里，让它每次开工自动读。写一次，用无数次。这类文件分两种，职责不一样。一种相当于员工手册，管约束，写的是"什么必须做、什么不能做"，比如"参数用 DTO 不用 Map"，每次干活都生效。一种相当于岗位方法论，写的是"某类事怎么做"，比如一篇文章怎么写、一个项目怎么部署，它碰到对应任务才去翻。在 AI 工具里，前者叫规则，后者叫技能。
沉淀的位置也不神秘：就是项目里普普通通的 Markdown 文件。规则一般放在项目根目录的说明文件里，各家工具叫法不同，CLAUDE.md、AGENTS.md 指的都是它，AI 每次开工先读这一份。技能放在固定的技能目录下，一份技能一个文件夹：一份说明写"这类事怎么做"，再配几篇查得到的参考材料。相当于给新员工配了一本员工手册，外加一柜子岗位操作手册。本质上全是人话写成的文档，谁能看，谁能改。
把话写成文件，只是第一步。怎么写，才决定这份文件带出来的员工什么样。我第一版就写砸了。
二、三十页员工手册：把它带成了复读机
第一版文档，我是照着公司编码规范抄的。三十多条，命名、注释、异常处理、日志格式，事无巨细。当时想得很简单：规矩越全，出来的活越稳。
头几天确实稳。让它写个设备接入模块，代码拿出来规范挑不出毛病，review 速度比看新同事的快一倍。我还挺得意，觉得带出来了。
第二周露馅了。让它写告警推送，打开一看，和上周的设备接入像双胞胎--分层套路一样，注释腔调一样，连类注释都是同一个句式："该类用于处理相关业务逻辑"。处理什么业务？它不知道，反正句式对了。再让它写篇接入文档，通篇四平八稳，一句错的没有，一句能记住的也没有。
我以前带过一个实习生，规矩教得太细，他给谁发邮件都带"尊敬的领导"，包括给我发"哥，中午吃啥"。手册没有错，错在我把所有地方都当成该讲手册的地方。
三、完全放养：它开始自由发挥
手册失败后，我走到另一个极端：整份文档删得只剩一句话--"你是资深工程师，按行业最佳实践来。"
三天，我就见识了"最佳实践"这四个字有多大的解释空间。
让它改个分页查询，它顺手重命名了三个方法，理由是原来的"不符合领域驱动设计"。让它修个空指针，bug 修好了，附赠一份架构演进建议书，认真建议我引入 CQRS。印象最深的一次，它嫌我用了三年的工具类"职责不单一"，拆成了五个文件。拆得确实漂亮，第二天我自己找工具方法找了十分钟。
每件事单拎出来看，都挺"专业"。合在一起四个字：不是我要的。就像请装修师傅来刷个墙，他把你的沙发也换了--换的还是他喜欢的款。你还不太好生气，因为它确实在"为你好"。
管得太死是复读机，完全放手是自由发挥。带人的分寸感，一下子具体了。
四、原则定死，方法放手：分寸看任务的性质
摸索一年，我的标准就一条：这个任务的正确答案，是唯一的还是开放的。
1. 唯一答案：手册一条条写具体
写代码是最典型的。编译要么过要么不过，规范要么符合要么不符合，字段要么判空要么等着半夜被告警叫醒--对错标准唯一，没有"发挥空间"这种东西。
所以我的代码类规则，每一条都写得很具体：
- 接口参数用 DTO，禁止 Map 接参
- 更新接口先判空再赋值，避免空值覆盖旧数据
- 实体类一律用 Lombok，不手写 getter
这些条款不跟它商量，也没必要商量。有意思的是，这种定死的规则它执行得比人稳--新员工记十条规矩会忘三条，它一条不忘，凌晨三点写出来的代码和下午三点的一个水准。
在这种任务里，不需要它有想法。它的聪明劲儿应该全部花在"怎么改对"，一点都不要花在"要不要换个更优雅的写法"上。前者是干活，后者是装修师傅换沙发。
写代码这样管用，写文章照搬就要出事。
2. 开放答案：只给方向，不给模板
去年让它帮我写公众号文章，我列了十几条规范：标题不超过二十字、开头三行内进主题、结尾要引导关注。它每条都照做了。
结果那批文章像从一个模子出来的。结构一样，节奏一样，连转折都出现在同样的位置。有读者留言问"你们是不是套了模板"，我没法回，因为确实像，虽然每篇都是现写的。
后来我删掉大部分规范，只告诉它三件事：这篇写给谁、要解决什么问题、大概分几段。标题、开头、句子，让它自己组织。改完的第一篇就不一样了--开头直接进场景，没有"随着XX的发展"。我读了两遍，能看得下去。这就够了。
带过编辑团队的人对这个应该不陌生：给成熟作者定条条框框，写出来的全是命题作文；只定方向和红线，人才能冒出来。AI 一样。
3. 混合任务：步骤定死，处理方式留给它
部署是第三种情况，两种都占。
步骤必须固定：先构建哪个模块、后重启哪个服务，顺序不能变。这种地方它自由发挥一次，出一次生产事故，我可能要赔进去一整个晚上。但出错之后怎么排查，我写得就很松："遇到编译失败，先看模块依赖有没有改动，再看 JDK 版本"，写到提示为止，不写具体命令。
为什么排查不写全？因为写不全。错误是长尾的，今天列二十种，明天出第二十一种。判断这种事，它比我反应快，见过的报错也比我多。步骤固定是保证它不乱来，排查放开是让它派得上用场。
同一个员工，原则定死、方法放手--这句管理者挂在嘴边的老话，放在 AI 身上严丝合缝。
五、V4-Pro 发布：换了个更聪明的大脑，考核标准没变
回到 8 月 13 号。V4-Pro 对我的员工来说，就是免费换了个更聪明的大脑。
这次拿它当考卷：照着技能写一篇公众号文章，再改十万行老工程里的需求。文章读得下去，工程编译一遍过，引用没断，测试没挂，几乎没返工。去年这时候，同样的事我改了三轮。
要说变化，模型确实强了一档。但"能力上限"和"发挥出几成"是两回事--上限是大脑的，发挥是带法的。带法不对，越聪明的大脑跑偏得越离谱：它有更多力气做你不要的事，还做得特别认真。这也是为什么同一个 V4-Pro，有人拿它当搜索引擎，有人能拿它改十万行的老工程。
而且松紧这个度，模型帮不了你定。它不知道你的工程哪些地方错不起，不知道你的读者是谁、这篇文章要解决什么问题--这些答案都在用的人手里。
下一代模型发布时，我大概还会这么考一回。跑分年年有人晒，带员工的分寸只能自己拿--因为答案不在模型里，在带它的人手里。