企业官网建设流程全解析

【虎鲸进化论 03】意图工程：当写代码变成写目标与验收

本文是「虎鲸进化论」系列第 4 篇（正文第 03 篇）。上一篇：三阶跃迁；下一篇预告：1 组长 + 2 开发 + 1 需求分析师 —— 当"会写代码"不再稀缺，分工被重写了。

前言

上一篇的结尾我留了一句话：人退到意图层之后，手里还剩什么手艺？旧手艺我丢了三遍，才攒出新的。

这一篇把"新的"摊开讲 —— 我给这套手艺起了个名字：意图工程。

不是"提示词工程"。提示词只是它最表面的形态。意图工程真正的内容是：把一件模糊的事，翻译成"可执行的目标 + 足够干活的上下文 + 可检验的验收标准"。你会发现，这三件事，软件工程教了二十年；而我们在 AI 时代，是把它们重新捡了一遍。

一、新三件基本功

基本功一：把模糊需求翻译成可执行目标。

“把报表优化一下” —— 这不是目标，这是愿望。Agent 拿到愿望，只会给你一版"看起来优化了"的东西。

翻译之后的目标长这样：“这张报表当前跑 40 分钟量级，目标：降到 10 分钟量级以内；约束：数字口径不允许变、调度依赖不允许变；验收：同一时间窗口的数字平移比对，误差为零。”

注意这里面装了什么：现状基线、目标、约束、验收。少一样，后面就要返工一轮。后来我们把它固化成了四段式模板（现状 / 目标 / 约束 / 验收），并且升格成组里的工单标准 —— 没有这四段的工单，不予受理。老一代工程师管这个叫"需求澄清"；现在它叫 goal 设定，而且变成了每一步动作的前置条件。（第 20 篇还会给它加第五段：停止条件—— 什么时候必须停下来问人。那是无人值守时代的保命条款。）

基本功二：上下文投喂。

同一个模型、同一个目标，喂不同的上下文，产出差距可以大到像两个系统。

• 给它相关表结构，它不会编字段；
• 给它历史同款实现（“照这个风格写”），它不会写出一版没人认得的怪东西；
• 给它踩过的坑清单，它能避开你上次刚踩过的雷。

这套动作的行业黑话叫"上下文工程"。它有个推荐顺序，我们叫"三件套"：表结构先行（防编字段）、同款实现参考（防跑风格）、坑清单兜底（防踩老雷）。说穿了也朴素：AI 的聪明程度，一半是模型给的，一半是你喂的。而"喂什么、不喂什么、喂多少"的取舍，取决于你对这份工作的理解 —— 理解越深，喂得越准。

还有一条物理定律要认：上下文不是越多越好—— 超出它"饭量"（几万 token 量级）的部分，会被挤掉或者稀释。所以长材料必须做"索引 + 按需检索"，不能整包硬塞。这条定律后来长成了一整篇（第 06/15 篇），现在先记个结论。

基本功三：验收标准前置。

这是三件里最重要、也最反人性的一件：在让它开工之前，先写"怎么算做对"。

为什么反人性？因为写验收标准，等于逼自己现在就把这事想清楚 —— 查什么、比什么、什么误差算过、什么边界必须覆盖。大多数人宁可先看到结果再发表意见（“跑起来了？那我看看……嗯，感觉不太对”），也不愿意提前写检查表。

但到了 Agent 阶段，这一步没法省：它跑得比你快、比你远。等结果回来再想验收，你审不动它。验收标准不前置，所谓的"人工审核"就只是心理安慰 —— 你会不由自主地只审那些"看起来最可疑"的地方，然后放行剩下八百个没看的地方。行业黑话管这个叫：抽查变抽奖。

三件基本功合起来，就是一句话：想清楚（目标）、喂明白（上下文）、验得出（标准）。而这三件事的共同点是 —— 它们全都发生在"动手"之前。

二、这不是新东西，是回归

我攒了几个月才慢慢反应过来：所谓"意图工程"，不是 AI 时代冒出来的新学科。它的每一条，都是需求工程的旧手艺。

只是过去二十年，行业里大量的岗位把这张网剪掉了一半：需求给到"大概齐"，方案跳过，直接写代码，写完跑一遍就上线 —— 因为写代码是最贵的一环，所有的纪律都得给"快点写"让路。

Agent 把这一环的边际成本干到了近乎零。于是纪律被重新加回来了：

你不写，它就乱做；你写歪，它做得比你想象的还歪。行业的纪律水平，被一台不会读心术的机器反向拉高了。

三、一个真实侧影：需求分析师开始自己修 bug 了

这套手艺真正让我吃惊的，不是我们这些写代码的人上手了 —— 是需求分析师上手了。

按老分工，她是"提需求的人"：发现数据不对，提个单子给开发，等排期。而开发这边，哪怕是个一行字的 bug，也要走一遍自己的心理流程：排期、插队、修完、回归。这中间的流转成本，双方都清楚，但谁也没有办法。

后来有一天，我问这个 bug 怎么样了，她说：已经修好了。

她解释得很轻松：把现象和单号发给 Agent，让它查；它定位到了代码行号和原因；她把修复意图用一段话描述清楚，让它出改动；然后她自己按老习惯做了验收 —— 她本来就是全组最懂数字口径的人。

这件事的分量，比它表面看起来大：

1. 实现的门槛真的归零了。挡住她的从来不是逻辑能力，而是 Java/Scala 的语法和工程环境的认知负担（那次修的还是智能运维平台那条线上的接口校验）—— 这层壳被拆掉了；
2. 角色边界溶解了。"业务方"和"开发方"之间那道墙，本来就是工种分工捏出来的；当实现不再是瓶颈，墙就只剩心理作用；
3. 全组最懂验收的人，成了全组产能最高的人之一。这不是巧合 —— 她就是那个所有数字对错都逃不过眼睛的人。验收能力，成了 AI 时代的第一生产力。

顺带一句黑色幽默：组里后来开玩笑说，她是这轮风暴里"最安全"的人 —— 因为她最值钱的能力（验收），恰好长在 AI 够不着的那一侧。笑话归笑话，这句话我们后来在卷Ⅳ 里认真算过一遍，基本成立。

四、实操：同一件事的三种说法

不给案例显得空，给一个吧（示意，非真实数据 —— 我们组内部的对照，等脱敏后有机会单独写一篇）。

需求：给一张报表加"同比"。

说法一（愿望版）：

给这张报表加个同比。

结果：它加了一列同比 —— 口径用"跟上一期比"，而上游数据不是等间隔的。数字全错。你花的时间比自己做还长。（比"错"更气人的是：它错得彬彬有礼 —— 格式工整、注释齐全、提交信息规范，一切都像对的。）

说法二（目标版）：

给这张报表加同比列。同比口径 = 本期 / 去年同期 - 1。

结果：口径对了，但它没处理去年缺失的情况，凭空造了个 0 当分母。边界翻车。

说法三（目标 + 约束 + 验收版）：

给这张报表加同比列。口径：本期 / 去年同期 - 1。约束：去年不存在时置空，不许用 0 顶替；不许改动现有列。验收：拿 [NN] 期数据跑一遍，人工核对其中 [X] 个已知样本，同比数一致；去年同期缺失的行，同比为空。

结果：一把过。而且它顺手把这个口径写进了自己的知识库 —— 下次同类需求，不用重复说。

三种说法的差距，不在"话术"，在你想清楚了没有。第一种你其实还没想；第二种你想了一半；第三种你全想了，只是"写下来"的动作交给了你。它把"想清楚"这件事，从可选项变成了必选项 —— 而想清楚本来就是这行最值钱的部分。

五、为什么旧手艺要"丢三遍"

最后说点真实的心理过程，因为我知道这个坎每个人都会遇到：

第一遍：舍不得丢。看到它写的东西，手痒，想自己写。写了两版又发现，自己写的那版它还得接手改上下文，总体更慢。第一次心态崩。

第二遍：想微操。接受不自己写了，但每一步都要管：这里改一行，那里换个名字，你成了一个人肉 diff 工具。产出上去了，人更累了。第二次心态崩。

第三遍：学会只写目标与验收。想清楚、说清楚、写清楚标准，然后把手从键盘上拿走。它做得不好，先查自己的目标和标准 —— 大部分"它不行"，复盘到最后是"我没说清"。

第三遍之后，才算真的退到意图层。退层不是自然的，是摔出来的。

结语（回味点）

意图工程不是把话"说漂亮"，而是把"什么算做对"提前写下来。

这件事比写代码难，也比写代码值钱 —— 更要命的是，它正在变成任何人都绕不过去的第一道工序。

这套新手艺放进一个真实的四人小组，会长成什么工作流？剧透一句：两个代码水平非常一般的开发，撑起了过去一个团队的产出 —— 而他们干的活，你可能认不出来。

边界声明

• 本文为个人观察与判断，不代表任何任职单位的立场；
• 文中涉及的组织、系统与人名均为化名或模糊处理，数字为个人口径的测量或估算；
• 文中观点按 实测 / 推理 / 立场 分层标注，欢迎按同一标准检验。

下一篇计划聊：1 组长 + 2 开发 + 1 需求分析师—— 一支"不写代码"的四人组，是怎么运转的。

转载请注明出处：
https://lizhiyong.blog.csdn.net/article/details/167922203