简历写解决方案不写执行动作

更新于 2026-10-10

**简历要写的是「业务层的问题 + 技术层的解决方案」，不是「我调用了什么接口」。** 判定一句话：

写的是动作（配置了、接入了、设计了）→ 执行层；写的是判断（为什么必须解决、错误产生在哪、为什么这样选、怎么验证）→ 解决方案层。

	写法	读者得到什么
执行	接入搜题接口、配置调用规则、设计图片映射	你会操作这套系统
方案	针对相似题条件差异导致答案误用的问题，区分原题匹配与相似题参考，校验题干关键条件与选项一致性，按匹配情况采取不同答疑策略，并用专项评测验证误用风险	你识别了问题、选了机制、能证明有效

产品化不是把动词换大（「配置」改「设计」）。是把为什么做、错在哪、怎么判断有效补上；实现细节留到面试被追问时再展开。

一个本身很简单的局部需求（例如「把已有的搜题能力接到对话入口」）被当成项目主线后，整段经历会退化成「我做了个工具」。判断依据是它有没有判断价值：需求简单、动作单一，就应当降级为某个优化点里的一个动作，而不是撑起整个项目。（详见答疑是功能层搜题只是手段层）

想让一段经历「讲得深」，靠的不是往里塞 RAG / 向量库 / 知识图谱这类词，而是沿这条链回答清楚：

业务上为什么这个问题不可接受
  → 错误具体产生在哪一层
  → 选择什么机制解决、放弃了什么
  → 用什么口径验证它真的有效

术语只用来解释取舍，不用来充深度。 没做过的层不要写成做过 —— 贡献只需要覆盖你真正能影响的那一层，但你要能解释整条链的边界。

想讲深，往往要「补课」（理解当时没参与的层）。这时必须区分：

后补的内容标为「复盘实验 / 独立实践」，不能倒写成实习期间已上线的成果。