草稿变专业

要解决的问题

工程师和求职者经常面对一种尴尬：脑子里有一堆零散的经历和想法，但要变成一份能直接发出去的简历、邮件或项目文档时，却不知如何组织。原始素材可能是随手记的几句话、一段微信消息，或者一个刚 push 上去还没写说明的仓库。这些草稿离「可交付」之间，往往差着结构规范、措辞打磨和格式统一这几道坎。

核心能力与工作流程

这个技能覆盖三种文档模式：简历、邮件/商务信函、README/技术文档。三者共享同一套工作流程，但各自只加载对应的参考模板，以保持上下文精简。

第一步是意图路由。在动手之前，技能会先将请求归入三种模式之一。判断依据包括关键词（如 简历 / CV / 邮件 / email / README）以及输入内容的类型。如果信息不足以确定模式，技能只会问一个澄清问题——「这是要做简历、邮件，还是技术文档？」——而不会跨模式猜测，因为混用模式会产出错误结果。

确定模式后，技能会遵循一组贯穿所有模式的质量门禁：

• 绝不编造事实。所有输出内容只能来自用户提供的素材。简历不会凭空捏造职位、日期或数据指标；邮件不会虚构承诺或截止日期；README 不会记录不存在的 API 或命令。
• 用占位符示范模式。当用户未提供某个字段的内容时，技能会写入一个明确标记的 [示例：…] 占位符，展示该位置应有的写法——比如简历中「强动词 + 可衡量结果」的句式，或者 README 某段落的合理骨架。这个标记是用户必须替换的提示，不会被悄悄删掉。
• 保持语义不变。重新组织措辞，但不改变用户意图、事实或承诺，尤其在邮件这类涉及承诺的语境中。
• 标准化结构。严格遵循 references/ 和 assets/ 中定义的章节顺序和模板，不每次另起炉灶。

三种模式各有侧重：简历模式遵循 ATS 规则，默认输出可被解析的 Markdown，也可通过 scripts/md2pdf.py 生成 PDF；邮件模式提供正式/中性/温和三档语气，并会保留用户的特殊约束（如「别把 deadline 定死」）；README 模式基于实际代码和笔记，先读仓库再动笔。

适用边界与注意事项

这个技能的核心原则是忠实于用户提供的素材。它能帮你把松散的草稿整理成专业文档，但不会替你补充缺失的经历或虚构项目细节。缺失的内容会以 [待补充] 或 [示例：…] 的形式标注，最终需要你手动填入真实信息。

当目标角色或行业可以从草稿中合理推断时（比如技能描述中提到的 React、Node 或期望城市），技能会直接说明假设并继续执行，不会做无谓的追问。但如果信息确实不足以推断，它会停下来确认，而不是瞎猜。