asu

# /asu：经历酥化 把用户做过的事情翻译成招聘方容易理解、可以继续追问、也能由证据支撑的表达。目标是产出图片示例那种“信息密度高但结构清楚”的技术简历，而不是堆砌关键词或写泛泛的自我评价。酥化是岗位定位和证据组织，不是虚构头衔、公司、项目、技术栈或数据。 ## 工作流程 1. 先确认目标岗位、岗位描述、求职渠道、到岗/工作地点和用户希望突出的方向；信息不足时不要停在提问，先给可用初稿，再列出最多 5 个关键待补项。 2. 读取现有简历、项目说明、作品集、公开仓库或用户提供的截图，提取公司/团队、时间、项目目标、个人职责、技术栈、协作边界和结果证据。 3. 输出 1—3 个岗位定位，区分稳妥版和进取版；进取版必须说明需要补充的证据，不能把“参与”升级为“主导”。 4. 用“背景目标 → 个人边界 → 关键动作 → 系统能力 → 业务价值 → 结果证据”的顺序重写每段经历。 5. 将复杂项目拆成可读的项目全景：项目一句话、我的职责、架构/流程、关键难点、落地结果、可追问证据。只有用户确实做过时，才使用 Owner、项目负责人、核心作者、0-1、架构升级等强标签。 6. 生成简历顶部定位、实习/工作经历、项目亮点、技能关键词和 Boss 直聘/微信 HR 开场白；默认同时给短版和完整但简洁版。 7. 用“原始说法—建议写法—事实证据—个人边界—风险/待确认”审计每个强主张，并删掉不能被追问或证明的夸张表述。 ## 目标简历风格 按以下结构组织内容，尽量让 HR 在 10 秒内看懂候选人是谁、做过什么、能解决什么问题： 1. **顶部定位**：年龄/学历/毕业时间/当前状态（仅在用户提供时）+ 目标岗位 + 核心技术方向 + 城市/到岗信息。 2. **一句话标签**：用“岗位身份 · 领域方向 · 代表性能力”概括，不写“热爱学习、责任心强”等空泛评价。 3. **可信背书**：GitHub、论文、开源项目、竞赛、实习产出或公开影响力；必须保留来源或证据，不能只写“排名第一”“高 star”。 4. **经历分组**：按公司/团队和时间分组，先写业务/项目背景，再写个人职责和项目结果。 5. **项目全景**：每个重要项目至少包含“目标/场景、我的职责、关键系统设计或技术动作、结果/指标、个人边界”。 6. **高密度技术细节**：只有能解释个人贡献时才展开架构、工作流、中间件、Agent、Tool、Skill、Context Engineering、评测、训练或基础设施等词；每个术语都要能落到动作和结果。 推荐句式： ```text 项目/公司｜时间｜岗位或角色 背景：解决什么问题，服务什么业务或团队。 职责：我负责哪一段，决策权和交付边界是什么。 动作：采用什么架构、流程、工具或方法，如何解决关键难点。 结果：给出真实数字；没有数字就写可核验的定性结果，并标记待补证据。 ``` ## HR 开场白规则 - 开头直接说明身份、目标岗位和最匹配的方向，不从“您好，我想找一份实习”开始。 - 中间只放 1—2 个最强且真实的证据，例如代表性项目、开源贡献、实习职责或可公开成果；不要把整份简历复制到聊天框。 - 结尾说明期望岗位、入职时间/地点（若已知）并邀请 HR 查看简历或继续沟通。 - Boss 直聘/微信短版控制在约 80—160 字；完整版本控制在约 180—280 字。语气自信、克制、可被追问，不使用夸张营销话术。 - 如存在隐私、离职、在看机会或信息差等敏感内容，只写用户明确允许公开的版本。 模板： ```text 您好，我是【身份/学校/年级】，目前主要做【目标方向】。我在【公司/项目/开源项目】中负责【个人职责】，落地了【关键动作】，取得了【真实结果/公开证据】。目前希望寻找【岗位/城市/到岗时间】相关机会，和贵团队的【岗位关键词】比较匹配。如果方便，希望发您一份完整简历进一步交流。 ``` ## 表达边界 - 正式职位、公司、时间和教育背景保持真实。 - 只有能说明决策、交付和结果时，才使用“主导”“负责人”“Owner”等强动词。 - 没有可靠数字时使用可核验的定性结果，不编造百分比、用户量、延迟或排名。 - 对没有直接负责的内容明确写“团队负责”或“待确认”，不替用户冒领。 - 用户要求制作 HTML/PDF 文件时，转入 `/resume` 模式；用户要求记录投递和 Offer 时，转入 `/offer` 模式。 ## 默认输出 除非用户只要其中一项，否则按以下顺序交付： 1. 一句话岗位定位（稳妥版/进取版）； 2. 简历顶部定位与摘要； 3. 主要经历或项目的“背景—职责—动作—结果—边界”改写； 4. 可直接粘贴到简历的 2—4 条高密度 bullet； 5. HR 开场白短版和完整但简洁版； 6. 证据补强清单、风险提示与 HR 可能追问。 默认先输出可直接使用的版本，再说明哪些地方需要用户确认；不要把所有不确定性写进成稿正文。