一个简历网站 Skill，是如何完成内容优化的？

用户上传一份简历，希望生成个人网站。一个常见做法是：读取简历、润色几段文字，然后立刻开始写页面。

但真正执行时，很快会遇到几个问题：简历中的“负责”究竟意味着参与、独立完成还是主导？“显著提升性能”有没有数据支撑？目标岗位要求的技术没有出现在简历中，是遗漏了，还是用户确实没有相关经验？网站首屏应该突出技术能力、项目成果，还是职业方向？

如果这些问题没有先解决，生成出来的网站可能很漂亮，却无法准确代表用户。

因此，这个简历网站 Skill 并不会拿到材料后立即生成 React 页面。它会先完成一轮内容优化：读取材料、整理事实、向用户澄清、分析岗位 JD、确定内容策略、制定修改计划，最后让用户批准优化后的文案。只有内容准备完成，网站设计流程才会启动。

本文沿着一次真实的使用顺序，介绍这套内容优化流程是如何工作的。

第一步：判断简历内容是否已经准备好

Skill 启动后，首先进行内容预检。

它会检查当前工作区是否已经存在一套完整、有效且经过用户批准的内容材料。预检可能得到三种结果：

为什么需要这一步？

因为“修改网站”和“修改简历内容”并不是同一类任务。如果用户只想调整配色、动效或响应式布局，就可以继续使用上次确认的内容，不需要重新询问全部经历。反过来，只要出现了新简历、新 JD、新项目或事实修正，原来的内容基线就可能失效，必须重新检查。

内容预检相当于一道分流门：它决定当前任务是继续设计网站，还是先把内容准备好。

第二步：读取简历，但暂时不急着润色

内容优化开始后，Skill 会先读取用户提供的材料，包括：

• PDF 或 DOCX 简历；
• Markdown、TXT 或用户直接粘贴的内容；
• 项目说明、作品材料和链接；
• 可选的目标岗位 JD；
• 用户补充的经历或事实修正。

这一步的目标不是生成更好听的句子，而是回答一个更基础的问题：材料里到底写了什么？

例如，简历里可能有这样一句话：

负责智能问答系统开发，完成知识库和检索模块建设。

Skill 此时不会马上改成“主导企业级智能问答平台架构设计”。它只会提取材料明确支持的信息，例如：

• 用户参与了智能问答系统开发；
• 工作包含知识库建设；
• 工作包含检索模块建设；
• 当前材料没有说明团队规模；
• 当前材料没有说明用户是否主导；
• 当前材料没有提供性能或业务指标。

也就是说，读取阶段优先建立内容边界，而不是追求表达强度。

如果 PDF 是扫描件，或者当前环境无法可靠提取 DOCX 内容，Skill 会请求用户提供可读文本或转录。它不会因为解析失败就猜测文件内容，也不会把某个外部解析服务作为必须条件。

第三步：把原始材料整理成事实和证据

读取完成后，Skill 会把内容拆成两个相互关联的部分：事实和证据。

事实描述当前可以确认的信息。例如：

{
  "fact_id": "fact-project-qa-system",
  "value": "参与智能问答系统开发",
  "source_ids": ["source-resume"],
  "confidence": "high",
  "confirmation_status": "unreviewed"
}

证据记录这项事实来自哪里：

{
  "evidence_id": "evidence-project-qa-system",
  "source_id": "source-resume",
  "quote": "负责智能问答系统开发，完成知识库和检索模块建设",
  "location": "项目经历第 1 项"
}

为事实和证据分配稳定 ID，看起来比直接保存一段文字更麻烦，但它解决了三个实际问题。

第一，后续每次改写都能说明依据。系统可以指出某段文案使用了哪些事实，而不是只说“根据你的简历优化”。

第二，材料之间出现冲突时，可以准确定位来源。例如，旧简历和新简历中的项目日期不一致，Skill 可以保留两个证据片段，等待用户判断，而不是擅自选一个。

第三，JD 匹配可以引用事实，不需要把岗位关键词直接写进简历。

此时，事实、证据和最终文案仍然是三种不同的数据：

原始材料：用户最初提供了什么
事实记录：当前能够确认什么
批准文案：最终允许在网站上公开什么

润色只会改变第三层，不会反向篡改前两层。

第四步：一次只向用户确认一个关键问题

简历材料通常不会一次性提供所有信息。常见缺口包括：

• 工作或教育日期相互矛盾；
• 项目中个人贡献不明确；
• 只写了技术，没有说明解决的问题；
• 使用了“效果显著”，但没有结果依据；
• 联系方式、链接或作品是否允许公开不明确；
• 没有说明目标岗位和希望呈现的职业方向。

Skill 不会一次性抛出一长串问卷，而是每轮只询问一个当前影响最大的问题。大致顺序是：

1. 公开姓名和身份信息；
2. 目标岗位或专业方向；
3. 工作、教育时间冲突；
4. 项目范围和个人贡献；
5. 项目结果与指标来源；
6. 联系方式、链接和媒体权限；
7. 语言与表达语气。

例如，面对“性能得到显著提升”，Skill 可能这样询问：

材料中提到性能得到显著提升。你是否有可验证的响应时间、吞吐量或错误率数据？如果没有，我们可以使用不含具体数字的定性表达。

这里同时给出了一个回退路径。用户不知道具体数字并不会阻塞整个流程，也不意味着系统可以编造一个数字。最终可以改成：

优化核心请求链路与缓存策略，改善高并发场景下的响应稳定性。

当然，这个版本仍需要相应事实或用户确认支持。

对于网站并非必需的次要信息，用户可以选择暂不回答。Skill 会把它记录为未决项，而不是为了填满页面自动补写。

第五步：检查项目描述是否真正讲清楚了价值

事实基本明确后，Skill 会检查每段经历是否回答了几个关键问题：

• 项目解决了什么问题？
• 用户实际承担了什么任务？
• 用户采取了什么行动？
• 最终产生了什么结果？

这与 STAR 思路相近，但 STAR 在这里是内部检查工具，不是固定写作模板。最终网站不会机械地显示“Situation、Task、Action、Result”四段文字。

对于技术项目，结果也不只有百分比和收入。下面这些都可能是有效结果：

• 完成可运行功能或系统集成；
• 建立自动化测试、恢复或发布流程；
• 改善延迟、吞吐量、覆盖率或错误率；
• 形成可复现的评估方法；
• 获得奖项、排名或外部认可；
• 被真实用户、评审或团队采用。

如果结果缺失，Skill 会询问；如果用户也没有更多信息，就使用真实的定性结果或省略，而不是制造量化指标。

这一阶段的目的不是让每段项目看起来都“战绩惊人”，而是让读者能够理解用户做了什么，以及这项工作为什么值得展示。

第六步：如果有 JD，逐条分析岗位匹配

当用户提供目标岗位 JD 时，Skill 会额外生成一份岗位匹配报告。

它不会直接统计关键词出现次数，而是先拆解每一条岗位要求：

• hard_requirement：学历、地点、工作权限、年限或明确要求的技术；
• core_capability：岗位持续使用的核心能力和主要职责；
• bonus_signal：领域背景、工具或加分经验。

接着，Skill 将每条要求与已有事实和证据逐一比较，并给出四种状态：

• strong_match：已有事实和证据充分支持；
• partial_match：只支持要求中的一部分；
• transferable：不是直接经验，但存在可迁移能力；
• unmatched：当前材料中没有支持证据。

例如：

对于 unmatched，Skill 只会询问用户是否有尚未写入简历的真实经历。如果没有，就保持未匹配，不会把这项能力自动加进简历。

JD 匹配的作用主要有三点：

1. 将匹配度高的项目和能力放到更显眼的位置；
2. 在含义准确时，采用岗位使用的标准术语；
3. 识别需要进一步澄清、但目前不能写入的内容。

岗位定制只改变排序和表达，不改变事实主版本。针对不同 JD，可以生成不同的文案层，但底层事实仍然是同一份。

第七步：先选择“怎么讲”，再决定“具体怎么写”

即使事实完全相同，也可以采用不同的内容策略。

例如，一名同时做过算法、后端和产品原型的用户，可以有三种呈现方向：

技术深度型

突出工程难点、系统设计、技术选择和实现边界。适合技术岗位，但可能弱化产品背景和协作过程。

结果导向型

突出交付、使用场景和结果。更容易被非技术读者理解，但需要足够的结果证据。

综合能力型

强调从问题分析到实现交付的完整能力。覆盖面更广，但如果信息组织不好，容易显得缺少鲜明重点。

Skill 会根据用户的目标岗位、项目材料和 JD 匹配，给出两到三种实质不同的策略，说明各自的适配性与取舍，并推荐其中一种。

用户必须明确选择内容策略。这个批准解决的是：

网站应该用什么叙事方式介绍我？

它还没有解决：

每一句具体文案是否可以公开？

因此，内容策略批准和最终文案批准是两个独立步骤。用户选择了“技术深度型”，不代表 Skill 可以自行决定所有技术描述。

第八步：明确策略后，先生成内容 TODO

策略确认后，Skill 不会立即改写全文，而是先生成内容实施计划。

计划会说明：

• 哪些项目或经历需要改写；
• 每项任务使用哪些事实和证据；
• 输出到哪个内容块；
• 哪些说法因为证据不足仍然不能使用；
• 最后如何验证内容包。

一个简化的任务可以写成：

任务：优化智能问答项目描述
依据：fact-project-qa-role、evidence-project-qa-01
输出：approved-copy.json 中的 project-qa-summary
重点：工程问题、个人行动、已确认结果
禁止：不得加入未经确认的用户数量和性能百分比
验证：内容包校验 + 用户文案批准

为什么内容优化也需要 TODO？

因为计划可以在生成前暴露问题。如果某个任务没有事实、没有证据，也没有明确记录为受阻，它就不应该进入文案生成阶段。用户也可以在正式改写前确认优化范围，避免 Skill 花时间改写本来不需要展示的内容。

第九步：按证据改写，而不是自由发挥

进入文案优化后，每个内容块都使用可对照的格式：

Original:
负责智能问答系统开发和相关功能实现。

Proposed:
设计并实现智能问答系统的知识库与检索模块，完成核心问答链路的功能交付。

Evidence:
fact-project-qa-role, evidence-project-qa-01

Why:
用具体模块和交付范围替换含糊的“负责”表达。

优化重点包括：

• 使用具体行动替代“负责”“参与”等模糊表达，但不升级责任归属；
• 说明产品、系统、用户、团队或约束范围；
• 有可靠结果时，把结果放在更突出的位置；
• 技术项目优先说明工程问题、设计选择和实现边界；
• 删除没有事实支撑的空泛形容词；
• 保持技术名称和个人贡献准确；
• 有可靠数字才量化，没有数字就使用真实的定性表达；
• 保持用户选择的语言和语气。

这里有一条非常重要的边界：优化只能增强表达，不能扩张事实。

例如：

如果更强的表达需要新事实，Skill 会返回澄清阶段，而不是悄悄补上。

第十步：让用户单独批准最终文案

候选文案生成后，Skill 会展示修改结果和依据，并等待用户确认。

只有用户明确接受的内容块，才会标记为：

{
  "approval_status": "user_approved"
}

以下行为都不能代替文案批准：

• 用户只说“继续”；
• 用户之前批准了内容策略；
• 用户批准了 TODO；
• 用户打开了预览页面；
• Agent 认为文案已经足够好。

这项约束让用户始终拥有最终公开内容的决定权。Skill 可以提出更好的表达，但不能替用户决定哪些说法代表本人。

第十一步：把内容整理成网站可以消费的包

文案批准后，Skill 会生成一套版本化内容包：

.resume-site-work/
├── input/
│   ├── source-manifest.json
│   ├── normalized-resume.json
│   └── approved-copy.json
└── reports/
    ├── content-provenance.json
    ├── content-design-spec.json
    ├── content-implementation-plan.json
    └── jd-match.json

这些文件分别承担不同职责：

内容包通过校验后，预检状态才会变成 CONTENT_READY。如果后续修改事实或文案，则需要增加内容版本，不能静默覆盖已经确认的结果。

第十二步：网站生成器只使用已确认的内容

完成内容交接后，Skill 才进入网站设计阶段，继续询问整体结构、字体、配色、媒体、主动效和副动效。

网站生成器会根据页面结构重新安排内容，也可以为了阅读节奏适当缩短或省略某些块，但它只能使用：

• 已核验的事实；
• 用户批准的文案。

它不能在设计阶段重新引入未确认内容，也不能为了填满页面编造新项目、指标或图片。

这种分工让内容优化和视觉设计各自解决自己的问题：

内容阶段：这个网站应该真实地说什么？
设计阶段：这些内容应该如何被看见和理解？

两者不是相互替代，而是顺序衔接。只有内容边界稳定之后，结构和视觉设计才有可靠依据。

完整流程回顾

把前面的步骤串起来，一次完整的内容优化过程如下：

这条流程中，真正发生“文案改写”的只是后半段。前半段的大部分工作都在确定内容边界：哪些是真的、哪些存在冲突、哪些与岗位有关、哪些还不能写。

这套流程解决了什么

与一次性润色相比，这套内容优化机制带来了四个直接变化。

内容更可信

数字、日期、职位、技术和责任归属都有来源或用户确认。缺少依据时，系统会提问、降级表达或省略。

优化更有方向

Skill 不是逐句替换近义词，而是先选择内容策略，再决定项目顺序、表达重点和页面层级。

JD 定制不会污染事实

岗位要求保存在独立匹配报告中。它可以影响排序和用词，但不能自动变成用户能力。

网站内容可以持续迭代

事实、证据、策略、文案和版本分别保存。以后更换 JD、补充项目或重新设计网站时，不需要从头理解全部材料。

仍然需要承认的边界

这套流程可以减少内容漂移，但不能自动证明用户提供的信息在现实中绝对真实。Schema 和校验器只能检查字段、引用和状态是否一致，最终事实仍依赖原始材料和用户确认。

另外，严格的审批门会让第一次生成比“一键润色”更慢。它更适合需要长期公开、反复使用和针对岗位定制的个人网站，而不是只想快速获得一段临时文案的场景。

这是一种明确的取舍：用更多前期确认，换取后续生成的可靠性、可追溯性和可复用性。

结语

一个简历网站 Skill 的内容优化，不只是把句子写得更专业。

它需要先理解材料，区分事实与推测，找到真正值得展示的项目价值；有目标岗位时，还要判断哪些要求已经匹配、哪些只能迁移、哪些目前没有证据。之后再由用户选择叙事方向，批准实施计划和最终文案，最后把稳定的内容交给网站生成器。

整套流程可以概括为：

先确定“能够说什么”，再决定“应该怎么说”，最后设计“如何让人看见”。

这也是内容优化被放在网站生成之前的原因：一个真正个性化的网站，不应只拥有独特的颜色和动效，还应该准确地讲述它所代表的那个人。