先说结论。简历上每一个名词，都是你亲手发给面试官的提问许可证。
名词越炫，他下钻的落点越深。而落差一旦暴露，被问倒这一条还算轻的。真正贵的是连你真做过的那部分，也一起被打折。
我最近帮人改简历改得比较多，尤其是 AI 项目那一段。这一段是眼下最容易翻车的地方，因为词儿都太新太好听了，写的人自己都容易被自己写的词唬住。
先划一条线，哪儿能往上，哪儿必须往实
开头得先把一件事分开说，不然这篇文章会被读成「老实人劝你自我阉割」。
定位可以往上站。 你投什么职位、以什么角色自我描述、希望被哪把尺子衡量，这一层要敢往高处站。同样一个人，按「后端开发」这把尺子量，四十岁是劣势；按「架构师」那把尺子量，年龄就是资历。这一步叫选战场。
技术事实必须往实写。 每个名词都得经得起三层追问，兜不住的一律降到兜得住的那一档。
这两件事一点都不矛盾。恰恰是事实写得扎实，高定位才立得住——架构师那把尺子，量的是你对边界和代价的判断。用过多少高级方案，它不太在乎。而判断只能从实话里长出来。
下面五个案例，全是真的，我做了匿名。
案例一 · 「熟练混合 RRF 召回」
实际做的 向量 + 关键词两路召回，结果用 RRF 融合。
坑在哪 RRF 本质就是一个公式，按排名倒数加权求和，实现出来只有几行代码。而「熟练」这两个字暗示的是你做过融合策略的对比，调过参。于是面试官三连问，为什么选 RRF 不用加权分数融合？k 值取多少、怎么定的？两路分数分布差异大的时候怎么处理？
答不上来。
「熟练」就从加分项变成减分项。
怎么写不翻车 「实现向量 + BM25 双路召回，用 RRF 融合结果」。想加分就补一句选型理由：RRF 只看排名不看分数，省掉了两路分数尺度对齐和权重调参。这句话讲得清楚，比「熟练」值钱得多——它证明你知道自己为什么这么选，而「熟练」只证明你会用形容词。
案例二 · 「意图双引擎路由」
实际做的 规则优先、大模型兜底的意图识别。
坑在哪 「双引擎」听起来像两个引擎并行推理、投票仲裁。实际是级联兜底。规则命中就走规则，没命中才落到大模型。面试官顺着「双引擎」往下问：两个引擎结论冲突怎么仲裁？路由准确率怎么评估的？一问就露出真相——根本没有「仲裁」这回事。
怎么写不翻车 「规则优先、LLM 兜底的意图识别：高频意图走规则，保证低延迟零成本；长尾意图由 LLM 接住」。
这个分层本身就是很漂亮的工程决策，如实写反而是亮点。造词造成「双引擎」，是把一个真优点换成了一个假破口。
案例三 · 「私有化 RAG 知识底座」
坑在哪 「私有化」三个字，面试官必问部署边界。embedding 模型本地跑还是调云端 API？生成用的大模型在哪？数据出不出内网？
如果知识库在内网、但 embedding 或生成走的是公有云接口，严格说这就不叫全链路私有化。而这个追问基本躲不过，因为真做过私有化的人，第一反应就是问这个。
怎么写不翻车 照实写边界。「知识库与检索服务部署于内网，embedding 用 XX（本地部署/云 API），生成走 XX」。
边界写得越清楚，越显得你真懂私有化部署里的数据合规问题；含糊才显得心虚。
案例四 · 「业务 Skill 工具化编排、可办业务」
实际做的 N 个只读的业务查询工具，供 agent 调用。
坑在哪 这一句里两个词都超了。「可办业务」暗示有写操作——办理、提交、状态变更，面试官立刻问，幂等怎么做？失败怎么回滚？权限怎么控？「编排」暗示多工具组合调度、依赖管理、执行计划。而实际是只读查询、单工具直调，这两个方向的追问，一个都接不住。
怎么写不翻车 「将 N 个业务查询封装为标准化工具供 agent 调用，当前限定只读」。
只读一点都不丢人，它是一个明确的安全设计决策，不让 agent 有机会误改业务数据。主动讲出来是加分项，被面试官戳穿才是减分项。同一个事实，你先说和他先问，价值差着一个身位。
案例五 · 「具备从 RAG 到自主智能体的架构演进设计能力」
坑在哪 这句话不是事实陈述，是能力形容词。面试官一句「那你演进到哪一步了？自主智能体上线了吗」就破功——「设计能力」没有落地物，就等于自我评价。
而简历上写自我评价，等于把定价权交给对方来砍。
怎么写不翻车 简历只写事实，能力让面试官自己推断。做到哪步写哪步，「已落地 RAG + 工具调用」。
演进路线是好素材，但它属于面试现场——被问到「下一步怎么规划」时讲出来，是洞察；印在简历上，是靶子。
一个极端版：名词能反过来证明简历是倒推的
前面五个是「名词超出事实」，还有一种更狠的，是名词推翻事实。
我见过一份简历，某段任职是 2017 年 5 月到 2020 年 9 月，写着自己搭建的技术底座里有 Sentinel、Nacos、Seata、Spring Cloud Alibaba。
对这几个组件熟的人已经笑了。Sentinel 2018 年中才开源，Nacos 2018 年下半年，Seata 2019 年 1 月才放出来（当时还叫 Fescar），Spring Cloud Alibaba 2018 年 10 月才进孵化。她 2017 年进去搭的底座里，不可能有这几样。
年份记错是小事，麻烦的是它暴露了生产方式。先列一份技能清单，再倒推着塞进项目里。同一份简历上还有个佐证——两个相隔三年、业务完全不同的项目，技术栈一字不差。
这一条比任何数字问题都伤，因为它动的是整份材料的性质。一旦被判定「技术栈是倒推填的」，你所有「主导落地」的默认解释，都从「做过」降级成「听说过」。
讽刺的是，真话更好听。
2017 年那会儿写 Spring Cloud Netflix、Dubbo、Zookeeper 才是真实且体面的，后来真升级过就写「2019 年起逐步迁到 Nacos + Sentinel」。「我经历过一次注册中心迁移」，比「我一开始就有 Nacos」值钱十倍，而且它是真的。
正面版：主动说「我没做」，比声称做了更像架构师
反过来的例子也有，这是我最想讲的一条。
另一份简历写着做过异地多活。但按那家的业务体量算，可用性从年停机 52 分钟压到 5 分钟，省下来的钱大约九万，异地多活的年增量成本是百万级。ROI 差两个数量级。 更别说八个人的团队排不出 7×24 的值班表。
所以正确的写法是反着来，主动说：
「我们评估过异地多活，按当时的业务体量 ROI 不成立，最后做的是同城双机房加异地备份。」
这一句说完，面试官对你的判断会当场变向，从「这人在报菜名」变成「这人会算账」。声称做过异地多活，你在证明自己是执行者；说清为什么不做，你在证明自己是决策者。 后者贵得多——而这，正是「定位往上站」真正靠什么立住。
三条自检
一，每个名词问自己：「追问三轮，我兜得住吗？」 兜不住就降到兜得住的那一档。降级不吃亏。少一个形容词的损失，比一次击穿小得多。
二，把简历当代码，跑一遍一致性检查。 数字、职级、时间线、公司名，全文交叉比对。这活儿现在成本极低——把简历丢给 AI，让它专挑自相矛盾的地方，比你自己读三遍都准。
但要提防反过来用。让 AI 帮你「把表述写得更漂亮」，它会热情地把你的一万 QPS 润色成五万，然后在面试现场把你卖了。 AI 是很好的挑错工具，是很危险的美化工具——这条规律不只适用于简历。
三，把形容词换成三样东西——数字、边界、决策理由。 「熟练」换成「为什么这么选」，「私有化」换成「部署边界在哪」，「可办业务」换成「当前限定只读」。这三样东西有个共同的好处：它们天然自洽，因为你没在维护一个需要记住的版本。
最后
面试这件事的残酷之处在于：它不筛选真实水平，它筛选可被验证的真实水平。
一份诚实的简历，最坏结果是被判「经验还不够」，你还有机会用回答翻盘。一份名词超载的简历，最坏结果是被归类为「不可信」——从那一刻起，你说的每句话都在被打折，包括那些完全真实的部分。
所以定位往高处站，事实往实处写。别费劲把自己写成别人，把自己写清楚——这件事本身就已经很难，也已经足够。
