亮点提炼：当面试官问"这东西给业务省了什么"
这是我"Java 转 AI 工程"系列的第 13 篇。前十二篇一直在往工程里加东西，这一篇什么都不加。它处理的是我把整套链路做完之后才撞上的问题：我做得出来，但讲不出来。
一、我被一句话问住了
那是一场很常规的技术面。前面聊得顺，我顺着自己的稿子往下走：Graph 的节点和键策略、ReplaceStrategy 配错会让下游读到 List 而不是 String、Graph 中断和 threadId 的会话隔离、检查点落到 Redis、同步接口改 Kafka、Nacos 热更阈值、Milvus 的集合名不接受中划线、评估节点用 PASS/FAIL 驱动条件边。讲到大概第十分钟，面试官抬手打断了我。
"这些我都听得懂。"他说，"我想问的是------这套东西上线之后，业务那边少了什么、多了什么？"
我停了两秒，答出来的是："减少了人工测算的工作量。"
他紧接着问："那这个系统当初立项，是业务方提的，还是你们技术自己找的活？"
第二问更糟。我发现我得现编。整个项目从头到尾没人问过我"立项理由"，因为它是我给自己派的活：把一门课的工程在企业场景里复刻出来。我对每个节点的实现细节都有把握，对"为什么值得做这件事"却只剩下两句口号。
事后我把这次失败归到一句话上：我准备了一份实现说明书，却被要求做一次项目汇报。 这两件事用的不是同一种语言，而我一直默认技术讲得越细，分就越高。那天技术部分他一点没否，只是从我整段描述里拿不到"这个人参与过决策"的信号。
我后来复盘这段对话，发现问题不在"我答不上来"，而在我根本没被要求想过。而我真正改的地方是顺序。同一周另一场面试，我把链路里的技术名词全部后置，开场只说了一句：
这个系统做的事，是把计划员"凭经验挑几个重点 SKU 算一下"这件事，变成每个 SKU 只要被卖动就重新算一遍；算完不直接生效，中间卡一道人工审核，卡完了才落成调拨单。
说完这句，面试官接的是"审核人是谁""为什么不让它自动生效"------这两个问题我全都有准备，也有真实的坑可讲。而上一场那句"你们业务少了什么"，我之所以答不上，是因为我前面的十分钟里一句业务都没说，他只能从头问起。讲法的前后位置，决定了面试官拿到的第一个问题是"决策类"还是"考核类"。
二、技术亮点和业务价值，是两件事
我用来判断自己有没有分清这两者的一个土办法：技术版说法换个项目还能接着用，业务版说法必须带着这个项目的名词。 如果一段描述把公司名、系统名、角色名全遮掉还成立，那它多半只是在报菜名。
同样是描述一件事，两种说法长这样：
| 同一件事 | 技术版说法 | 业务版说法 |
|---|---|---|
| 给客服页的查询接口加缓存 | Redis 做二级缓存，热点 key 加随机过期时间防击穿 | 客服点开工单不用等转圈，"系统卡"这类投诉从月度榜上掉下去了 |
| 调拨链路里加人工审核节点 | Graph 中断 + 条件边，审核结果写进状态里的一个 key | AI 的建议不直接进业务库，只有人被问过一遍、点过采纳的才进；出了错能追到是谁批的 |
| 工作流状态搬进 Redis | 每个 super-step 存一次快照，按会话 ID 隔离 | 发布、重启不再是事故，跑到一半等审批的那张单子不会凭空消失 |
三条并排看，规律挺清楚：
- 技术版的关键词是怎么做到的：组件、机制、配置项。
- 业务版的关键词是谁的哪件事变了：角色、动作、后果。
- 业务版几乎不出现技术名词，但它的可信度又必须靠技术版兜住，否则就变成 PPT 话术。
所以这两者不是高下关系，而是论点与论据的关系：业务价值是论点，技术实现是论据。 只给论据的人听起来像执行者；只给论点的人听起来像没写过代码的人。我那天犯的错是前者，而我见过不少人矫枉过正成了后者。
三、包装的三层：做了什么 / 解决了什么痛点 / 换来什么
我后来给自己定了一个死板的检查表，任何一个亮点都要能填满三层才算讲完。
第一层，做了什么：把系统边界说死。 谁调用它、输入是什么、产出是什么、写进哪张表。这层的作用不是炫技，是不给面试官留"靠猜"的空间。边界一模糊，后面所有的追问都会变成审问。
第二层，解决了什么痛点：必须有具体的人。 不是"效率低"，而是"计划员算一个 SKU 要十几分钟，而 SKU 有几百个，所以他只能挑自认为重要的算，于是积压和断货同时存在"。有没有人名词（计划员、客服、业务方），决定了这一层是场景还是口号。
第三层，换来什么收益：口径 + 数字。 这一层是绝大多数学习项目断掉的地方，而我认为断在这里不是表达能力问题，是诚实问题------没上线就是没有对比数据。缺数字的时候能做的，是把口径说完整，数字用假设句：
| 如果你们能拿到 | 就能说这个对比 |
|---|---|
| 上线前后同类 SKU 的呆滞库存金额 | 建议被采纳的比例 × 呆滞金额下降，能折算成资金占用减少多少 |
| 计划员的工时台账 | 单 SKU 人工测算耗时，能折成人天 |
| 审批节点的平均等待时长 | 人机协同究竟加了多少流程成本------这个数往小处说，比报收益更有说服力 |
| 调拨单错发、退回的记录 | AI 建议的真实质量，比"准确率提升 X%"诚实得多 |
最后一行是我今年才想通的：愿意主动讲"我准备怎么衡量成本"的人，比只报收益的人可信。
还有一条我认为最有价值的策略，来自讲义：把 AI 落在非核心业务线上 ------并发几十 QPS、日订单量不到一千这个量级的子系统（这是示例口径，不是我实测的量级），而不是核心交易链路。理由不是"简单"，而是风险边界：
- 核心链路会把话题引向性能影响和故障责任，而这些恰恰是学习项目最没法证明的东西。
- 非核心系统允许慢、允许失败、允许人工兜底，正好对上 Agent 现在的成熟度。
- 契合点要自己讲出来：商品管理、库存优化、报表自动化，共同特征是数据密集但决策不致命。
注意这跟"不重要所以随便做"是两码事。反过来，主动讲清楚"我为什么没往核心系统放"，本身就是一层业务判断。整条叙事线也就顺了：技术验证 → 小规模试点 → 业务融合。
最后一层的边界还牵着一个我一开始处理不好的问题：这套东西该叫几个项目。 我手里其实是两条链路，一条给仓库出调拨建议，一条让业务方用自然语言问报表。我最早当两个项目并列讲，听感就成了"他做了两个 demo"。后来改成一层套一层：底下是企业原有的库存与销售系统，上面挂两个 Agent------一个管决策 （该不该调、调多少），一个管复盘（调完之后卖成什么样、钱花在哪）。这两块拼起来才是业务能听懂的一件事：事前有建议、事后能验证。名字也就顺势换成"智能库存调拨优化系统"，把范围讲清而不是把数量堆多。
同样的道理适用于换行业。这套链路的骨架（多维数据 → 模型建议 → 人工闸门 → 落库 → 可回溯）跟"库存"没什么血缘关系，把它移植到别的业务场景里，改的是喂进去的表和提示词里的名词，不变的是那三层决策结构。这也是为什么我在描述它时尽量不用"库存"当主语，而用"任何一个需要人做取舍、又做不到全覆盖的决策场景"当主语------听众能不能对上自己公司的场景，全靠这一句。
四、把库存调拨这个项目拆开：六条亮点，两种说法
前面几章我一共往里加了大概十来个东西，但能当亮点讲的其实就六条。同一件事，我给每个都配了一句技术说法和一句业务说法：
| 亮点 | 技术说法 | 业务说法 |
|---|---|---|
| 全局状态机与键策略 | 七个 key 的数据契约，语义全是"当前值"所以统一覆盖策略 | 一条链路上每个节点、每个人看的是同一份数，不会因为两处口径不一致吵起来 |
| 人机协同审核 | 图中断 + 邮件确认 + 条件边分流，AI 生成的单子状态只能是待审核 | 决定权还在人手里，AI 只负责把材料准备好；每张单子有明确的批准人 |
| 检查点持久化 | 快照落 Redis、按会话隔离，进程恢复后从断点接着跑 | 流程可以在"等人"那一步停几天，回来还能接上，服务重启不算事故 |
| 消息驱动削峰 | 同步接口改 Kafka，触发阈值在 Nacos 在线调（讲义示例是把阈值从 20 压到 5），消费端用唯一键幂等 | 卖得再猛也不会把系统按下去，模型不会被同一件事反复叫醒；不想让 AI 动的时候，配置点一下就能收住 |
| RAG 表结构知识库 | 按标题切分、向量化入 Milvus、查询改写后召回再注入上下文 | 业务方问的是自家口径，不用先学会写 SQL，也不用等数据同学排期 |
| 评估闸门 + 循环重试 | 生成与评估共享同一套检索上下文、但提示词目标相反，判决驱动条件边 | 出去的东西被人挑过毛病；报表出错被发现的时间点，从"周会上"提前到了"发出去之前" |
六条不要一次全讲。我现在的打法是挑两条主线，因为它们正好对应业务侧最关心的两个问题：
- 会不会出错：人机协同 + 评估闸门。一个拦在写库前，一个拦在发出前。
- 会不会宕：消息驱动 + 检查点。一个管进来太多，一个管跑到一半没电。
私有化部署（第 12 章）不在这六条里，它的落点完全不同：讲的是数据出不出内网、算力怎么租、成本怎么算，而不是效果。这类"基础设施型"亮点，一说效果就露馅。
这六条落到纸面（简历上那三五行）时，我的排版是固定的：一行项目定位 + 三行"机制---后果"。
- 项目定位那行只说边界，不说技术：在原有库存与销售系统之上，落两个 Agent，一个出调拨建议，一个做自然语言问数。
- 三行各挑一条亮点，按"我做了什么机制 → 因此系统能做到什么"的句式写，动词开头，不出现形容词。
- 技术栈单独一行放最后，当索引用而不是当卖点。它的唯一作用是让面试官知道从哪一句开始往下挖。
我最早那版简历是把这六条全列上去、每条前面挂三个组件名，结果是被问了一整场技术细节，一次都没讲到业务。少写不是遗漏，是控制对方从哪儿开始问。
五、面试官真正会追问的几刀
亮点讲完不是结束，是开始。我被砍过、也看别人被砍过的，主要是这几刀。每刀我准备的不是话术，是答法骨架。
"你为什么不直接用 Dify / Coze？重复造轮子。" 这刀问的不是选型，是判断力。骨架：先承认低代码平台在它擅长的场景里确实快；再给三条分界------要不要接企业自己的库和表结构、出问题能不能在代码里定位、流程里插一道人工闸门平台给不给位置；最后落到结论，"我这张图不是替代低代码，是把同一张图画在能被工程约束的那一层"。补一句反转会更可信：如果需求是三天换一个模型的探索性验证，我反而会选低代码。
"模型胡说八道怎么办？污染了库怎么办？" 骨架：幻觉不能靠提示词消除，只能把它挡在写库之前；顺序是收敛输出格式 → 生成与评估两段提示词 → 人工审核 → 只有采纳过的才落库、并留审批痕迹；收尾给责任："出了事我能查到是哪张单、谁批的。"
"性能瓶颈在哪？" 骨架：先分层定位，再谈优化。编排层是节点串行，模型层是推理耗时，数据层是查库和外部调用。然后说清哪层是我能动的（阈值、并发、缓存、削峰），哪层取决于模型服务本身。最忌讳的是把三层的优化混成一句"我做了高并发改造"。
"并发能扛多少？" 这刀问的是量级感，不是数字。骨架：给边界条件（哪条业务线、什么量级）、给压测方法（同一 SKU 重复触发验幂等、看分区数与积压、量消费端单条耗时）、给没做的部分并明说。我现在的原则是宁可说"这个量级我没测过，但我知道怎么测出来"，也不给一个能被追问三层的数字。
"为什么放在这个系统做，而不是别的？" 最容易被忽略的一刀，因为它问决策。骨架：数据密集 / 决策不致命 / 有人能兜底，三个条件同时满足才选它。
"为什么不用现成的云端大模型，要自己部署？" 这刀问的是选型依据和成本意识。骨架分三段：先讲数据（表结构、字段口径、业务文档这些不该长期留在第三方语料里），再讲成本（自建要租卡、按什么计费、闲时烧不烧钱），最后讲折衷------开源模型和商用大模型之间是有质量差距的，值得换的前提是"数据不出内网"这个约束压过了效果损失。别把它讲成"为了技术先进性"，一说这个词就露底。
"这块是你一个人做的，还是团队？" 对复刻型项目，这刀比前面所有刀都更致命，因为它问的是你和这个项目的真实关系 。我的骨架是三段切分：整套链路是我按企业场景独立搭起来的；其中一部分能力（Graph 的用法、RAG 的工程结构）我照着资料复现，复现完做了自己的改造（比如把状态存储从默认的内存实现换成外置的，是因为我撞上了审批邮件丢失这个具体场景）；还有一部分我压根没做（多轮对话、模型微调、全量压测）。"这一部分我是抄来的"敢当场说出口，才是这段回答唯一立得住的地方------这里一含糊，后面每一刀的诚实度都要被重新定价。
"这项目你觉得最大的问题是什么？" 送命题，但我靠它把气氛扳回来过。骨架是给一个真实存在、我还没解决的问题，比如评估节点对空结果直接判放行这个短路分支------它省了一次模型调用，但把"没生成"和"生成得对"混成了同一个出口。敢说出这种层次的问题，比多背两个组件有用。
六、什么不能吹
讲义给的 STAR 模板长这样：S 挑一个日订单量不到一千的子系统，T 是库存预测不准，A 用某个算法，R 填"准确率提升 15%"，话术里还有一句"经过三个月灰度运行"。
这些数字我全部划掉了。不是因为它们是错的数字，而是因为它们不是我的。
数字一出口，追问路径是固定的四层：怎么测的、基线是多少、样本量多大、口径谁认的。四层里任何一层答不上，前面所有技术细节都会被重新评估成"他大概只是看过"。虚构的代价也很少是当场被拆穿------更常见的代价是你为了自圆其说，入职之后要花很大力气维护一个不存在的前提，而这个前提会反过来决定你被分到哪条线、被要求做什么。写进简历这件事，本质是把风险从"面试三十分钟"转移到"试用期三个月 + 背调 + 前同事"，后者贵得多。
所以我明确反对三类写法：把课程项目写成"某公司生产系统"；把 demo 量级写成生产量级；把"我复刻了一个"说成"我主导了一个"。
反过来，这三样可以说，而且我说过：
- "这是我自己按企业场景复刻的工程，没上生产，所以没有生产数据。" 这句话换来的不是扣分，是问题从"你的数字怎么来的"变成"你打算怎么验证"------后者我准备好了。
- 真实的坑比亮点值钱。 那条走完全流程的幻觉调拨单、那个把外层 api-key 删掉导致启动失败的下午、那个键名写成
message结果整条链路静默断裂的半天。这些编不出来，也不需要编。 - 能力边界。 "我知道怎么压测，还没做全量"是一句完全站得住的话。
还有一类更隐蔽的膨胀，是时态。模板里"压测"和"灰度"这两张牌我保留了，但把完成时改成了将来时。讲义原话是"强调进行了充分的压力测试和灰度发布"，问题是这个"进行了"我担不起------灰度要先有发布体系和监控基线，那是单人本地工程拿不出来的证据。我现在的说法是："这个量级可以先不做全量压测，但上线前我会按重复触发、积压、单条耗时这三个场景压；灰度按仓库维度切，先只放一个仓。"同一句话，时态一改，就从吹牛变成了计划。
七、这一章真正改变的东西
写完这篇我确认了一件事：亮点提炼不是话术训练，它是在逼我把每个工程决策重新问一遍"这是为了谁"。有几个决策我答不上来------比如某个中间 key 为什么存在、某段提示词为什么那么写。答不上来的那部分，说明我确实只是复刻，没做设计。这么一想，把技术说辞翻译成业务价值，做的其实只是把断掉的决策链补齐，顺带把项目本身也照出了几个没做扎实的地方。
技术深度决定你经不经得起追问，业务表达决定别人愿不愿意追问你。这两件事我以为是一个，今年才知道是两个。
下一篇回到工程：当流程多到不能靠 Java 代码一张张画出来，需要把节点抽成可复用的组件、用一种表达式去编排它们。第 14 章开始讲 LiteFlow 的组件化编排------组件、上下文、EL 表达式，以及我会拿它来解决前几章留下的哪个麻烦。
本篇依据课程第 13 章两份讲义笔记（亮点提炼、智能库存调拨优化系统面试攻略）整理，是我对自己表达方式的复盘。文中出现的收益类数字均为模板示例或待验证的取数口径，不是实测结果；涉及的工程细节以本系列前几篇为准。