【虎鲸进化论 03】意图工程当写代码变成写目标与验收本文是「虎鲸进化论」系列第 4 篇正文第 03 篇。上一篇三阶跃迁下一篇预告1 组长 2 开发 1 需求分析师 —— 当会写代码不再稀缺分工被重写了。前言上一篇的结尾我留了一句话人退到意图层之后手里还剩什么手艺旧手艺我丢了三遍才攒出新的。这一篇把新的摊开讲 —— 我给这套手艺起了个名字意图工程。不是提示词工程。提示词只是它最表面的形态。意图工程真正的内容是把一件模糊的事翻译成可执行的目标 足够干活的上下文 可检验的验收标准。你会发现这三件事软件工程教了二十年而我们在 AI 时代是把它们重新捡了一遍。一、新三件基本功基本功一把模糊需求翻译成可执行目标。“把报表优化一下” —— 这不是目标这是愿望。Agent 拿到愿望只会给你一版看起来优化了的东西。翻译之后的目标长这样“这张报表当前跑 40 分钟量级目标降到 10 分钟量级以内约束数字口径不允许变、调度依赖不允许变验收同一时间窗口的数字平移比对误差为零。”注意这里面装了什么现状基线、目标、约束、验收。少一样后面就要返工一轮。后来我们把它固化成了四段式模板现状 / 目标 / 约束 / 验收并且升格成组里的工单标准 —— 没有这四段的工单不予受理。老一代工程师管这个叫需求澄清现在它叫 goal 设定而且变成了每一步动作的前置条件。第 20 篇还会给它加第五段停止条件—— 什么时候必须停下来问人。那是无人值守时代的保命条款。基本功二上下文投喂。同一个模型、同一个目标喂不同的上下文产出差距可以大到像两个系统。给它相关表结构它不会编字段给它历史同款实现“照这个风格写”它不会写出一版没人认得的怪东西给它踩过的坑清单它能避开你上次刚踩过的雷。这套动作的行业黑话叫上下文工程。它有个推荐顺序我们叫三件套表结构先行防编字段、同款实现参考防跑风格、坑清单兜底防踩老雷。说穿了也朴素AI 的聪明程度一半是模型给的一半是你喂的。而喂什么、不喂什么、喂多少的取舍取决于你对这份工作的理解 —— 理解越深喂得越准。还有一条物理定律要认上下文不是越多越好—— 超出它饭量几万 token 量级的部分会被挤掉或者稀释。所以长材料必须做索引 按需检索不能整包硬塞。这条定律后来长成了一整篇第 06/15 篇现在先记个结论。基本功三验收标准前置。这是三件里最重要、也最反人性的一件在让它开工之前先写怎么算做对。为什么反人性因为写验收标准等于逼自己现在就把这事想清楚 —— 查什么、比什么、什么误差算过、什么边界必须覆盖。大多数人宁可先看到结果再发表意见“跑起来了那我看看……嗯感觉不太对”也不愿意提前写检查表。但到了 Agent 阶段这一步没法省它跑得比你快、比你远。等结果回来再想验收你审不动它。验收标准不前置所谓的人工审核就只是心理安慰 —— 你会不由自主地只审那些看起来最可疑的地方然后放行剩下八百个没看的地方。行业黑话管这个叫抽查变抽奖。三件基本功合起来就是一句话想清楚目标、喂明白上下文、验得出标准。而这三件事的共同点是 —— 它们全都发生在动手之前。二、这不是新东西是回归我攒了几个月才慢慢反应过来所谓意图工程不是 AI 时代冒出来的新学科。它的每一条都是需求工程的旧手艺。只是过去二十年行业里大量的岗位把这张网剪掉了一半需求给到大概齐方案跳过直接写代码写完跑一遍就上线 —— 因为写代码是最贵的一环所有的纪律都得给快点写让路。Agent 把这一环的边际成本干到了近乎零。于是纪律被重新加回来了过去手撸时代现在意图工程需求模糊 → 边写边猜需求模糊 → 它直接拒答 / 瞎猜你必须先想清方案在脑子里写的时候顺手改目标不写清它就跑偏方案感变成了显式输入测试是上线前补的验收标准是开工前写的文档最烦最后写上下文即文档不写它就没法开工你不写它就乱做你写歪它做得比你想象的还歪。行业的纪律水平被一台不会读心术的机器反向拉高了。三、一个真实侧影需求分析师开始自己修 bug 了这套手艺真正让我吃惊的不是我们这些写代码的人上手了 —— 是需求分析师上手了。按老分工她是提需求的人发现数据不对提个单子给开发等排期。而开发这边哪怕是个一行字的 bug也要走一遍自己的心理流程排期、插队、修完、回归。这中间的流转成本双方都清楚但谁也没有办法。后来有一天我问这个 bug 怎么样了她说已经修好了。她解释得很轻松把现象和单号发给 Agent让它查它定位到了代码行号和原因她把修复意图用一段话描述清楚让它出改动然后她自己按老习惯做了验收 —— 她本来就是全组最懂数字口径的人。这件事的分量比它表面看起来大实现的门槛真的归零了。挡住她的从来不是逻辑能力而是 Java/Scala 的语法和工程环境的认知负担那次修的还是智能运维平台那条线上的接口校验—— 这层壳被拆掉了角色边界溶解了。业务方和开发方之间那道墙本来就是工种分工捏出来的当实现不再是瓶颈墙就只剩心理作用全组最懂验收的人成了全组产能最高的人之一。这不是巧合 —— 她就是那个所有数字对错都逃不过眼睛的人。验收能力成了 AI 时代的第一生产力。顺带一句黑色幽默组里后来开玩笑说她是这轮风暴里最安全的人 —— 因为她最值钱的能力验收恰好长在 AI 够不着的那一侧。笑话归笑话这句话我们后来在卷Ⅳ 里认真算过一遍基本成立。四、实操同一件事的三种说法不给案例显得空给一个吧示意非真实数据 —— 我们组内部的对照等脱敏后有机会单独写一篇。需求给一张报表加同比。说法一愿望版给这张报表加个同比。结果它加了一列同比 —— 口径用跟上一期比而上游数据不是等间隔的。数字全错。你花的时间比自己做还长。比错更气人的是它错得彬彬有礼 —— 格式工整、注释齐全、提交信息规范一切都像对的。说法二目标版给这张报表加同比列。同比口径 本期 / 去年同期 - 1。结果口径对了但它没处理去年缺失的情况凭空造了个 0 当分母。边界翻车。说法三目标 约束 验收版给这张报表加同比列。口径本期 / 去年同期 - 1。约束去年不存在时置空不许用 0 顶替不许改动现有列。验收拿 [NN] 期数据跑一遍人工核对其中 [X] 个已知样本同比数一致去年同期缺失的行同比为空。结果一把过。而且它顺手把这个口径写进了自己的知识库 —— 下次同类需求不用重复说。三种说法的差距不在话术在你想清楚了没有。第一种你其实还没想第二种你想了一半第三种你全想了只是写下来的动作交给了你。它把想清楚这件事从可选项变成了必选项 —— 而想清楚本来就是这行最值钱的部分。五、为什么旧手艺要丢三遍最后说点真实的心理过程因为我知道这个坎每个人都会遇到第一遍舍不得丢。看到它写的东西手痒想自己写。写了两版又发现自己写的那版它还得接手改上下文总体更慢。第一次心态崩。第二遍想微操。接受不自己写了但每一步都要管这里改一行那里换个名字你成了一个人肉 diff 工具。产出上去了人更累了。第二次心态崩。第三遍学会只写目标与验收。想清楚、说清楚、写清楚标准然后把手从键盘上拿走。它做得不好先查自己的目标和标准 —— 大部分它不行复盘到最后是我没说清。第三遍之后才算真的退到意图层。退层不是自然的是摔出来的。结语回味点意图工程不是把话说漂亮而是把什么算做对提前写下来。这件事比写代码难也比写代码值钱 —— 更要命的是它正在变成任何人都绕不过去的第一道工序。这套新手艺放进一个真实的四人小组会长成什么工作流剧透一句两个代码水平非常一般的开发撑起了过去一个团队的产出 —— 而他们干的活你可能认不出来。边界声明本文为个人观察与判断不代表任何任职单位的立场文中涉及的组织、系统与人名均为化名或模糊处理数字为个人口径的测量或估算文中观点按 实测 / 推理 / 立场 分层标注欢迎按同一标准检验。下一篇计划聊1 组长 2 开发 1 需求分析师—— 一支不写代码的四人组是怎么运转的。转载请注明出处https://lizhiyong.blog.csdn.net/article/details/167922203