那该怎么平衡低瑕疵和高技术力，如果要取舍该怎么选

回复 群友 4814 直接给结论：不需要平衡，必须果断倒向“高技术力”。如果非要取舍，宁可做一份“局部有棱角但单点极深”的简历，也绝对不要做“完美但平庸”的六边形水桶简历。 原因很简单：HR 看的“低瑕疵”（排版工整、没有错别字、时间线清晰、关键词命中）是一次性工程，你现在既然能过 HR 关，说明这 80 分的及格线你已经拿到了，继续往 95 分抠细节是零收益。而业务面官看简历是“一俊遮百丑”——只要你有一个地方打穿了他的技术痛点，哪怕你其他模块写得糙一点、或者有某项次要技能没点亮，他也会立刻约你聊。 具体实操时，用“二八分仓”的策略来做取舍： 1. 保住 HR 的底线（只花 20% 篇幅和精力，不再多改） 保持你现在的教育背景、技能清单、一页纸排版和关键词密度不变。这些就是给 HR 和 ATS 机器看的通行证，动都不用动。 2. 把 1 个核心项目写成“技术深水区”（砸入 80% 篇幅，宁深勿全） 很多人的“低瑕疵”思维是：生怕别人觉得自己某方面不会，于是在项目里把前端、后端、数据库、部署、Prompt 调优全写一遍，看起来面面俱到。业务最烦这种写法，因为每样都写等于每样都很浅。 正确的取舍是：直接砍掉项目里 70% 的常规开发描述（比如怎么搭框架、怎么写接口），只留 1 到 2 个最硬核的技术攻坚点，把它拆到极致。 比如做 Agent 项目，别写“实现了多工具调用和记忆模块”，直接写：当时在某场景下长上下文工具调用准确率只有 60%，排查发现是历史死循环污染上下文 + Schema 歧义；你设计了什么上下文裁剪策略、怎么改了 Hook 拦截校验、怎么用收集的 badcases 跑回归，最后准确率拉到 92%、Token 降了 40%。 3. 敢于暴露边界，用“真实的工程取舍”代替“完美的套话” 业务眼里最高级的“高技术力”，恰恰不是你的方案完美无瑕，而是你知道每种方案的缺陷并做了权衡（Trade-off）。 在简历里大大方方写出“放弃了方案 A（因为延迟高/维护重），选择了有某某局限性的方案 B，并用某某机制兜底”。在不懂行的 HR 看来这叫“暴露瑕疵”，但在业务 Tech Lead 眼里，这叫“真正干过活、踩过坑的工程师”。 总结一句话：用固定的版式和关键词糊弄过 HR，然后把核心项目里所有像“说明书”一样的平庸描述全删了，只留你解决过的最难的那一两个技术问题。