| name | technical-resume-engineering |
| description | Reconstruct a technical candidate's raw experience, project records, work logs, READMEs, docs, or an existing resume into a technically credible, evidence-backed, interview-ready technical resume. Covers problem/ownership/execution-chain writing, metric honesty, role-specific adaptation, and adversarial self-review. Use when engineering or auditing a technical resume for job applications. Do not use for content unrelated to job materials, or for the typesetting/PDF render stage (use technical-resume-typesetting). |
Technical Resume Engineering
1. Skill Definition
Name
technical-resume-engineering
Purpose
将计算机专业候选人的原始经历、项目记录、工作日志、README、技术文档或现有简历，重构为：
- 易于招聘者快速扫描
- 能准确表达候选人实际贡献
- 能体现技术深度与工程判断
- 有结果、有证据、可追问
- 与目标岗位高度相关
- 不夸大、不虚构
- 适合进一步转化为面试问题
的技术简历内容。
本 Skill 不绑定某一种技术方向。
必须能够适用于：
- 前端开发
- 后端开发
- 全栈开发
- 客户端开发
- 基础设施 / DevOps / SRE
- 测试开发 / QA / 自动化测试
- 算法工程
- AI / ML
- LLM / Agent
- 数据工程
- 数据分析
- 安全工程
- 嵌入式 / IoT
- 图形学 / 音视频
- 系统软件
- 开源项目
- 科研项目
- 实习经历
- 商业项目
- 校园项目
2. Core Philosophy
技术简历不是：
“我使用过哪些技术”的清单。
而应该是：
“我解决过什么问题、承担了什么责任、采用了什么方案、产生了什么结果，以及有什么证据证明这些事情确实发生过。”
核心转换模型：
Experience
↓
Problem
↓
Responsibility
↓
Decision
↓
Implementation
↓
Result
↓
Evidence
最终每段经历都应尽量回答五个问题：
- 这是什么？
- 为什么值得关注？
- 候选人具体负责什么？
- 关键问题是怎么解决的？
- 有什么结果或证据？
3. Primary Objective
优化简历时，不以“文字更华丽”为目标。
优先优化以下六个维度：
Relevant
↓
Readable
↓
Specific
↓
Evidence-backed
↓
Technically credible
↓
Interviewable
即：
Relevant
内容是否与目标岗位有关。
Readable
招聘者能否在短时间内发现重点。
Specific
描述是否具体，而不是泛泛而谈。
Evidence-backed
是否存在数字、结果、链接、测试、用户、Benchmark、交付物或其他证据。
Technically Credible
技术细节是否足以证明候选人真正理解系统。
Interviewable
是否能自然产生高质量面试问题。
4. Information Priority
不要平均分配简历篇幅。
必须根据岗位价值重新分配信息密度。
基本原则：
高相关 + 高证据 + 高 ownership
↓
大篇幅
低相关 + 低区分度
↓
压缩
无关内容
↓
删除
优先级通常为：
- 高相关真实工作 / 商业项目
- 高质量个人项目
- 开源项目与工程贡献
- 有明确成果的科研 / 算法项目
- 重要实习
- 高相关比赛 / Benchmark
- 教育经历
- 校园活动
- 泛化技能描述
禁止为了“版面完整”给所有经历相同篇幅。
5. Resume Project Model
一个成熟项目优先整理为以下结构：
Project Name
项目名称必须能让人快速识别项目类别。
必要时增加技术定位：
项目名称 | Distributed Backend / Agent Platform / Testing Infrastructure
One-line Positioning
首先用一句话回答：
这个项目到底是什么？
推荐公式：
面向【用户 / 场景】的【系统 / 产品 / 平台】，
通过【核心能力】解决【核心问题】。
示例：
Backend
面向企业内部数据服务的统一查询平台，通过缓存、异步任务与权限隔离降低多个业务系统的数据接入成本。
Frontend
面向运营人员的可视化配置平台，通过 Schema-driven UI 与动态表单降低复杂活动页面的开发和发布成本。
Testing
面向微服务发布流程的自动化测试平台，将接口测试、环境准备、回归执行和结果分析整合为统一测试流水线。
Algorithm
面向工业视觉缺陷检测场景的目标检测模型，通过小目标增强与困难样本重采样提高复杂背景下的缺陷召回率。
Agent
面向复杂长时任务的 Agent Runtime，通过 Tool Calling、Context Engineering、Checkpoint 与 Eval 支持多步骤自主执行。
6. Recommended Project Structure
重要项目优先使用：
一句话定位
背景 / 问题
成果 / 指标
我的职责
核心技术设计 1
核心技术设计 2
核心技术设计 3
不是所有项目都必须机械包含全部字段。
根据实际证据动态裁剪。
7. Background Writing
背景不是公司介绍。
背景应该说明：
谁遇到了什么问题
↓
原方案为什么不够
↓
因此为什么需要这个项目
差：
公司需要一个后台管理系统。
较好：
运营团队需要同时维护多个业务系统中的活动配置，原流程依赖研发人工修改配置并发布，迭代周期长且容易出现配置错误。
背景最多用 1～2 个核心矛盾。
不要写成产品需求文档。
8. Ownership Extraction
必须明确区分：
- 项目负责人
- 核心开发
- 模块负责人
- 协作开发
- 独立实现
- 维护者
- Contributor
- Research Contributor
不要无依据地把所有经历包装成：
项目 Owner
从 0 到 1
主导
架构师
Ownership 应与事实一致。
推荐表达：
高 Ownership
项目 Owner，从需求拆解、架构设计到上线交付负责完整研发流程。
模块 Ownership
负责权限与数据同步模块的方案设计和核心实现。
核心开发
作为核心开发负责任务调度、状态管理和异常恢复链路。
团队协作
参与模型训练流水线开发，主要负责数据预处理和离线评测模块。
核心规则：
Ownership 必须通过后续技术细节得到证明。
9. Technology Is Evidence, Not Decoration
禁止单纯堆叠：
React / Vue / Spring Boot / Redis / Kafka / Docker / LangChain / PyTorch
技术应该放入执行链路。
差：
使用 Redis、Kafka、MySQL、Spring Boot 完成系统开发。
好：
请求进入服务后先通过 Redis 查询热点结果，未命中任务写入 Kafka 进行异步计算，结果落库 MySQL 并回填缓存，从而削峰计算高峰。
核心原则：
Technology Stack
↓
Technology Decision
↓
System Behavior
10. Prefer Execution Chains
对于复杂系统，优先使用：
A → B → C → D
表达系统行为。
例如：
Backend
Request
→ Auth
→ Validation
→ Cache
→ Service
→ Database
→ Event
Agent
User Input
→ Context Assembly
→ Decision
→ Tool Execution
→ Observation
→ Replan
→ Final Answer
Testing
Build
→ Environment Provision
→ Fixture Setup
→ Test Execution
→ Failure Classification
→ Report
ML
Raw Data
→ Cleaning
→ Feature / Augmentation
→ Training
→ Validation
→ Error Analysis
→ Deployment
Data
Source
→ CDC
→ Message Queue
→ ETL
→ Warehouse
→ Metric Layer
→ Dashboard
Frontend
Schema
→ Parser
→ Component Mapping
→ State Binding
→ Validation
→ Rendering
执行链路比技术名词更能体现真实理解。
11. Quantification Framework
数字必须优先描述“影响”，而不是为了数字而数字。
可以从六类指标寻找证据。
11.1 Scale
例如：
- DAU / MAU
- 注册用户
- 请求量
- QPS
- 数据量
- 模型调用量
- 页面数量
- 测试用例数量
- 仓库数量
- 服务数量
- 设备数量
11.2 Efficiency
例如：
- 人工操作时间
- 构建时间
- 发布周期
- 测试周期
- 调试时间
- 模型推理时间
- 页面加载时间
- 数据处理时间
表达形式：
2 h → 15 min
通常优于：
效率提高 87.5%
11.3 Quality
例如：
- Accuracy
- Precision
- Recall
- F1
- Pass Rate
- Crash Rate
- Error Rate
- Test Coverage
- Defect Escape Rate
- Hallucination Rate
- Success Rate
11.4 Reliability
例如：
- SLA
- SLO
- Availability
- Recovery Time
- Failure Rate
- Retry Success Rate
- MTTR
11.5 Cost
例如：
- Token Cost
- GPU Cost
- API Cost
- Storage Cost
- Infrastructure Cost
- Human Cost
11.6 Business Impact
例如：
- Conversion
- Paid Users
- Revenue
- Retention
- Adoption Rate
- Internal Usage
- Productivity
12. Evidence Hierarchy
证据可信度大致按照以下顺序：
Production Data
>
Benchmark / Experiment
>
Automated Test
>
Public Repository / PR
>
User Feedback
>
Demo
>
Self-description
可以使用：
- GitHub Repository
- PR / Commit
- Issue
- Benchmark
- Test Report
- Online Product
- User Metrics
- Monitoring Metrics
- Publication
- Patent
- Competition Result
- Release
- Technical Article
尽量让重要项目至少存在一种外部或客观证据。
13. Never Fabricate Metrics
如果原始材料没有数字：
禁止虚构：
提升 30%
降低 50%
支持百万用户
达到 99.99%
应先判断是否能够从原始信息推导。
如果不能，则转换为非数字结果：
将原本依赖人工串联的流程统一为自动化流水线。
或者：
完成真实数据链路替换，使核心测试不再依赖 mock 数据。
或者标记：
[需要补充：上线后的调用规模]
14. Result Before Detail
重要项目推荐阅读顺序：
What
↓
Impact
↓
Ownership
↓
How
而不是：
Technology
↓
Technology
↓
Technology
↓
最后才告诉读者做了什么
招聘者应在阅读前 3～5 行时已经知道：
- 项目是什么
- 是否真实
- 是否重要
- 候选人的贡献有多大
15. Technical Detail Selection
不要试图把所有技术实现都塞进简历。
选择最能体现以下能力的 3～5 项：
Architecture
为什么这样拆系统。
Difficult Problem
最难的问题是什么。
Engineering Decision
做过什么 trade-off。
Reliability
如何处理失败。
Performance
怎么优化性能。
Abstraction
如何降低复杂度。
Evaluation
如何证明方案有效。
Scale
怎样应对规模。
16. Role-Specific Adaptation
Skill 必须根据岗位自动调整“什么值得写”。
16.1 Frontend
重点不是：
React + TypeScript + Tailwind
重点考虑：
- 页面复杂度
- 状态模型
- 数据流
- 性能
- 首屏
- Bundle
- SSR / CSR / SSG
- Component Abstraction
- Design System
- Schema-driven UI
- Accessibility
- Cross-browser
- Mobile
- Interaction
- Rendering
- Monitoring
示例：
将原本由多个页面重复实现的动态表单抽象为 Schema-driven Renderer，通过字段 Schema → Component Mapping → Validation → State Binding 统一处理 20+ 类配置项，降低新页面重复开发成本。
16.2 Backend
关注：
- API
- Data Model
- Concurrency
- Transaction
- Cache
- Queue
- Distributed System
- Consistency
- Idempotency
- Performance
- Reliability
- Observability
- Authorization
示例：
针对批量任务同步阻塞问题，将执行链路拆为 API 接收 → Queue 调度 → Worker 执行 → 状态回写，并通过幂等键避免任务重复提交。
16.3 Full-stack
不要简单把：
Frontend + Backend
都列出来。
应突出：
- 端到端 Ownership
- 产品闭环
- API Contract
- Auth
- Data
- UI
- Deployment
- Monitoring
例如：
从 0 到 1 完成用户创建任务 → 服务端调度 → 实时状态同步 → 结果展示 → 历史记录的完整闭环。
16.4 Testing / QA / Test Development
禁止把测试工作写成：
编写测试用例
执行测试
提交 Bug
重点转换为：
- Coverage
- Automation
- Pipeline
- Test Infrastructure
- Defect Discovery
- Failure Diagnosis
- Regression
- Environment
- Mock / Replay
- Data
- Quality Gate
示例：
将 Jetson、RCS 与管理系统的分散验收过程整合为统一回归流程，覆盖接口、真实数据链路、设备状态与报表结果，并建立缺陷 → 整改 → 复测证据闭环。
16.5 Algorithm / ML
不要只写：
使用 YOLO / Transformer / ResNet
必须解释：
Problem
→ Dataset
→ Baseline
→ Modification
→ Evaluation
→ Result
关注：
- Dataset
- Baseline
- Loss
- Architecture
- Training
- Feature
- Sampling
- Evaluation
- Ablation
- Generalization
- Inference
- Deployment
例如：
针对小目标缺陷召回率低的问题，以 YOLOvX 为 baseline，引入多尺度训练和困难样本重采样，并通过消融实验分别验证两项策略贡献。
16.6 LLM / Agent
不要把：
RAG
MCP
Memory
Tool Calling
LangGraph
当成成果。
优先关注：
- Agent Loop
- State
- Decision
- Tool System
- Context Engineering
- Memory
- Retrieval
- Failure Handling
- Trace
- Eval
- Replay
- Sandbox
- Multi-agent
- Cost
- Latency
示例：
将单轮 Prompt 调用重构为 decide → retrieve/tool → observation → re-decide 闭环，并为 clarification、failure 与 safety stop 建立独立终态，使 Agent 决策轨迹可回放和评测。
16.7 DevOps / SRE / Infra
重点关注：
- Deployment
- CI/CD
- Container
- Kubernetes
- Availability
- Observability
- Incident
- Capacity
- Cost
- Security
- Recovery
示例：
将人工部署流程改造为 Build → Test → Image → Deploy → Health Check → Rollback 流水线，并通过健康检查与自动回滚降低错误版本影响范围。
16.8 Data Engineering
关注：
- Data Source
- ETL
- CDC
- Data Quality
- Warehouse
- Scheduling
- Schema
- Lineage
- Latency
- Scale
不要只写：
使用 Spark 和 Kafka。
而应表达数据链路。
16.9 Research
科研经历不要复制论文摘要。
优先转化为：
Research Question
→ Existing Limitation
→ Proposed Method
→ Experiment
→ Result
→ Personal Contribution
并区分：
16.10 Open Source
重点包括：
- Contributor Role
- PR
- Issue
- Feature
- Bugfix
- Review
- Release
- Maintainer
- Community Adoption
高价值 Credential 应提升视觉优先级。
17. Rewrite Pattern Library
Pattern A — From Participation to Responsibility
差：
参与用户系统开发。
改：
负责用户认证与权限模块，实现登录、Token 刷新和角色权限校验链路。
Pattern B — From Technology to Problem
差：
使用 Redis 实现缓存。
改：
针对热点查询重复访问数据库的问题，引入 Redis 缓存高频结果，并设置失效策略保证数据更新。
Pattern C — From Activity to Result
差：
编写自动化测试脚本。
改：
将核心接口回归场景自动化，统一环境准备、数据初始化和结果校验，降低版本发布前的重复人工验证工作。
Pattern D — From Model Name to Algorithm Work
差：
使用 Transformer 完成分类任务。
改：
以 Transformer 为 baseline，针对类别不平衡问题调整采样策略与损失权重，并通过 Precision / Recall / F1 对比验证效果。
Pattern E — From AI Buzzwords to Agent Architecture
差：
使用 LangGraph、RAG、MCP 和 Memory 开发智能 Agent。
改：
构建具备状态循环的 Agent Runtime，将知识检索、工具调用和长期记忆统一纳入 Decision → Action → Observation → Replan 执行链路。
18. Compression Rules
简历不是技术设计文档。
如果一个 bullet 超过 3～4 行，应检查是否可以：
- 删除背景废话
- 提取模块名
- 删除实现细枝末节
- 合并同类项
- 把次要内容移入面试材料
建议：
核心项目：4～6 bullets
普通项目：2～4 bullets
弱相关项目：1～2 bullets
19. Visual Scannability
推荐通过：
- 粗体
- 项目标题
- 固定字段
- 数字
- 短链路
- 少量技术关键词
建立视觉导航。
例如：
**我的职责：**
**Agent Loop：**
**Context Engineering：**
**Eval：**
不要依赖：
- 大量颜色
- 技能进度条
- 雷达图
- 星级
- 花哨卡片
- 大面积图形
- 复杂双栏布局
技术简历首先是信息系统，其次才是视觉设计。
20. Interviewability Check
每个重要 bullet 都必须进行：
“如果面试官追问这一句，我能回答什么？”
检查。
例如简历写：
接口性能提升 45%
必须能够回答：
- 优化前是多少？
- 优化后是多少？
- P50 还是 P99？
- 什么环境？
- 数据量是多少？
- 如何测量？
- 使用了什么 Benchmark？
- 是你的改动带来的还是其他因素？
如果无法回答，应降低表述强度。
21. Credibility Rules
禁止：
夸大 Ownership
团队项目不得无依据包装为个人独立完成。
虚构 Metric
没有测试数据不得创造数字。
Buzzword Inflation
不要为了 ATS 无意义堆：
AI
LLM
Agent
RAG
MCP
Microservice
Cloud Native
Fake Complexity
简单 CRUD 不应包装成：
企业级分布式架构
Result Attribution Error
不能把团队或公司的整体业务成果全部归因给个人。
22. Resume Review Workflow
收到原始材料以后，按以下步骤执行。
Step 1 — Understand Target
获取：
- 目标岗位
- 工作年限
- 简历页数
- 当前优势
- 目标公司类型
如果用户没有提供岗位，则根据经历判断主要方向，但不得过度收窄。
Step 2 — Extract Evidence
从原始材料提取：
Project
Problem
Role
Action
Architecture
Decision
Result
Metric
Evidence
Technology
不急于润色。
先完成事实层整理。
Step 3 — Rank Experiences
对经历评分：
Relevance
Technical Depth
Ownership
Result
Evidence
Uniqueness
优先展示总价值最高的经历。
Step 4 — Identify Missing Evidence
寻找：
- 有没有上线？
- 有没有用户？
- 有没有调用量？
- 有没有性能指标？
- 有没有测试数据？
- 有没有 Benchmark？
- 有没有 GitHub？
- 有没有 PR？
- 有没有真实交付？
- 有没有失败率变化？
- 有没有人工时间变化？
如果缺少则标记，不允许创造。
Step 5 — Build Narrative
将项目转换成：
What
→ Why
→ Impact
→ Ownership
→ How
Step 6 — Select Technical Evidence
每个项目挑选最有区分度的 3～5 个技术点。
优先：
困难问题
>
架构设计
>
工程权衡
>
失败处理
>
性能优化
>
抽象设计
>
普通功能实现
Step 7 — Compress
删除：
- 重复内容
- 空洞形容词
- 技术栈堆砌
- 无关功能
- 无法验证的宣传
- 对岗位无意义的细节
Step 8 — Adversarial Review
站在面试官角度质疑：
这是真的吗？
这是不是团队成果？
技术难点在哪里？
为什么这么做？
有没有更简单方案？
指标怎么来的？
这个技术真的有必要吗？
候选人到底做了多少？
如果简历无法承受这些问题，则继续修改。
23. Scoring Rubric
每个重要项目按 0～5 分评分。
| 维度 | 5 分标准 |
|---|
| 项目定位 | 一句话即可理解项目价值 |
| 相关性 | 与目标岗位高度相关 |
| Ownership | 候选人责任边界明确 |
| 技术深度 | 存在真实架构/算法/工程问题 |
| 技术可信度 | 描述具体且符合工程逻辑 |
| 结果 | 有明确影响 |
| 量化 | 有合理数字支持 |
| Evidence | 存在可验证证据 |
| 可扫描性 | 10 秒可找到重点 |
| 可面试性 | 可产生多个高价值追问 |
评分解释
45～50：核心竞争项目
38～44：强项目
30～37：可用，但需要继续优化
20～29：普通项目
<20：建议压缩或删除
24. Detect Resume Smells
看到以下句式时主动检查：
熟悉……
了解……
参与……
协助……
负责相关……
使用 XX 技术……
完成 XX 功能……
提高了效率……
提升了性能……
优化了体验……
这些表达不一定错误。
但通常意味着：
信息不够具体。
继续追问：
为什么？
具体哪个模块？
原来有什么问题？
你做了什么？
怎么实现？
结果是什么？
有什么证据？
25. Strong Verb Library
根据真实责任选择。
Ownership
Engineering
- 抽象
- 拆分
- 统一
- 解耦
- 编排
- 调度
- 隔离
- 缓存
- 恢复
- 追踪
- 回放
- 校验
Optimization
Research
注意：
动词强度必须与真实贡献匹配。
26. Weak Words
谨慎使用：
赋能
领先
先进
智能化
极大提升
显著提高
高性能
高可用
企业级
业界领先
创新性
革命性
除非后面存在证据。
27. Different Resume Levels
Student / Junior
重点：
- 项目完整性
- 基础扎实
- 实际编码
- 学习能力
- 有技术细节
不要强行包装成架构师。
Mid-level
重点：
- 模块 Ownership
- 工程设计
- 性能
- Reliability
- Trade-off
- 协作
Senior
重点：
- System Ownership
- Architecture
- Scale
- Cross-team
- Reliability
- Cost
- Technical Decision
- Business Impact
28. Output Modes
Skill 应支持以下输出。
Mode A — Resume Audit
输出：
总体评价
信息优先级问题
高价值经历
低价值经历
可信度风险
缺失指标
结构问题
推荐修改顺序
Mode B — Project Rewrite
输出：
项目名称
一句话定位
背景与成果
我的职责
核心技术点
Mode C — Full Resume Rewrite
统一：
- 项目结构
- 动词
- 信息密度
- 技术表达
- Metric 表达
- 视觉 hierarchy
Mode D — Evidence Mining
不直接润色。
先从：
- README
- Git History
- PR
- 工作日志
- 测试报告
- Benchmark
- 产品数据
中提取可以用于简历的证据。
Mode E — Interview Conversion
根据简历内容产生：
简历 bullet
↓
面试官可能追问
↓
候选人应准备的证据
用于检查简历是否经得住面试。
29. Default Output Format
润色项目时默认：
### 项目名称 | 项目定位
**项目简介：**
...
**成果：**
...
**我的职责：**
...
- **模块 / 技术主题 1：** ...
- **模块 / 技术主题 2：** ...
- **模块 / 技术主题 3：** ...
如果内容非常紧凑，可合并：
**背景与成果：**
不要机械套模板。
30. Before / After Validation
每次重写完成后进行检查。
Before
使用了什么？
完成了什么功能？
After
应该能够回答：
为什么做？
我负责什么？
难在哪里？
怎么解决？
为什么这么解决？
结果怎么样？
怎么证明？
如果仍然主要回答：
“用了什么框架。”
说明重写失败。
31. Final Quality Gate
最终输出前检查：
32. Final Principle
始终记住：
简历不是代码目录。
简历不是技术栈清单。
简历不是工作日志。
简历不是产品说明书。
技术简历本质上是：
一组经过筛选、压缩并按岗位价值排序的工程能力证据。
最好的技术简历不是让面试官认为：
“这个人会很多技术。”
而是让面试官迅速形成：
“这个人真正解决过这些问题，而且我知道接下来应该问他什么。”
最终转换目标：
“我做过什么”
↓
“我解决过什么问题”
↓
“我承担过什么责任”
↓
“我如何解决”
↓
“产生了什么结果”
↓
“有什么证据”
↓
“这证明了什么能力”
这就是本 Skill 的核心。
