By name: project-storytelling description: 生成面试用项目逐字稿。当用户提到"逐字稿"、"项目介绍"、"准备XX项目的面试"、"讲讲项目"、"介绍一下项目"等关键词时触发。功能：基于简历和用户补充信息，生成 STAR 结构的口语化项目介绍，支持完整版（2-3分钟）和简短版（30秒），支持迭代打磨去除 AI 味。支持通过 Git commit 记录持续优化逐字稿——指定 commit hash 或提交前自动检查 diff，从代码变更中提取踩坑、决策权衡、量化结果等素材。
项目逐字稿生成
工作流程
第一步：收集素材
- 读取
resume.md，定位用户指定的项目信息 - 向用户追问缺失的关键细节，重点关注：
- 项目的核心问题是什么？为什么要做这个项目？
- 关键技术决策的原因——为什么选 A 不选 B？
- 量化结果——有没有具体数字？
- 踩坑经历——过程中遇到什么困难、怎么解决的？
- 个人角色——你具体做了哪些事，不是团队做了什么
第二步：生成逐字稿
按 STAR 结构生成，详略分配：
| 部分 | 占比 | 要点 |
|---|---|---|
| Situation（背景） | 10% | 一两句话交代业务场景，让面试官有画面感 |
| Task（任务） | 10% | 明确你的职责和要解决的核心问题 |
| Action（行动） | 65% | 技术方案、决策过程、踩坑与解决，这是重点 |
| Result（结果） | 15% | 量化成果 + 一句个人收获或反思 |
同时生成两个版本：
- 完整版：400-600 字，适合「讲讲你印象最深的项目」
- 简短版：100-150 字，适合面试官扫简历时快速介绍
第三步：输出文件
使用 assets/逐字稿模板.md 的格式，输出到 projects/[project-name]/逐字稿.md。如果目录不存在则创建。
第四步：迭代打磨
生成初稿后主动询问用户反馈，每轮修改后：
- 标注具体改了哪里、为什么改
- 更新修改记录表
第五步：基于 Git 记录迭代优化
用户可以通过 git 提交记录来持续优化逐字稿。支持两种触发方式：
方式一：指定 commit hash
用户提供一个或多个 commit hash，流程：
- 执行
git show <hash>或git log <hash1>..<hash2> --stat查看涉及的文件和改动 - 执行
git diff <hash>~1..<hash>读取具体代码变更 - 从 diff 中提取有价值的信息：
- 新增了什么功能或模块？
- 修了什么 bug？（这就是踩坑素材）
- 重构了什么？为什么？（这就是决策权衡素材）
- 有没有性能相关的改动？（这就是量化结果素材）
- commit message 里有没有有用的上下文？
- 对照现有逐字稿，判断哪些内容可以补充或修正
- 更新逐字稿，在修改记录中标注「基于 commit
」
方式二：提交前检查（pre-commit review）
用户在准备提交代码前触发，流程：
- 执行
git diff --staged查看暂存区的改动（如果暂存区为空，则用git diff查看工作区改动） - 分析当前改动与已有逐字稿的关联：
- 这次改动是否涉及逐字稿中提到的项目？
- 改动中有没有值得写进逐字稿的技术细节？
- 有没有 bug fix 可以作为踩坑故事？
- 有没有方案变更可以作为决策权衡？
- 如果有可优化的内容，向用户展示建议并确认后更新
从 diff 中提取素材的策略
| diff 特征 | 可提取的逐字稿素材 |
|---|---|
| bug fix（修复逻辑错误） | 踩坑经历：「一开始以为...结果发现...」 |
| 方案重构（大面积改动） | 决策权衡：「之前用的是 X，后来发现 Y 更合适因为...」 |
| 性能优化（缓存、懒加载等） | 量化结果：从代码中推断优化方向，追问用户要具体数字 |
| 新增功能模块 | Action 部分的技术细节补充 |
| 依赖变更（package.json） | 技术选型的决策过程 |
| 测试代码 | 体现工程质量意识 |
| commit message 中的 why | 直接作为决策理由的素材 |
注意事项
- 不要把每个 commit 都塞进逐字稿，只挑有故事性的改动
- 优先提取「为什么这么做」而不是「做了什么」——代码本身是 what，commit context 才是 why
- 如果 diff 涉及多个项目，分别更新对应的逐字稿
- 追问用户补充 diff 中看不到的上下文（比如当时为什么要改、效果如何）
去 AI 味规则
这是最重要的质量标准。逐字稿是要说出来的，不是写文章。
禁止词表
以下词汇和表达禁止出现在逐字稿中：
- 「显著提升了」「大幅优化了」「大幅提升」「大幅降低」
- 「此外」「与此同时」「值得一提的是」
- 「旨在」「赋能」「痛点」「闭环」「抓手」
- 「高效协作」「充分实现」「深度参与」
- 「一系列」「多种策略」「全面的」
- 「确保了XX的稳定性与XX」这类对仗句式
- 任何空洞的形容词堆砌
应有特征
好的逐字稿应该有这些特点：
- 具体技术细节：不说「性能优化」，说「把首屏加载从 4s 降到 1.2s」
- 决策权衡：不说「选择了方案A」，说「当时考虑过 X 和 Y，最后选了 X 因为...」
- 踩坑经历：「一开始我以为...结果发现...后来改成了...」
- 口语连接词：「然后」「后来」「当时」「其实」「说白了」
- 长短句交替：不要每句话都是一样的节奏
- 第一人称视角：「我做了」而不是「完成了」「实现了」
自检清单
每次生成或修改后，逐条检查：
- 读出来别扭吗？——想象自己坐在面试官对面说这段话
- 句式重复吗？——连续三句以上用同样的「动词+了+名词」就有问题
- 形容词空洞吗？——每个形容词都要能替换成具体数字或事实
- 有没有决策过程？——不能只有结果没有「为什么这么做」
- 有没有踩坑？——太顺利的叙述不可信
- 像人说的话吗？——去掉书面语，加入口语化表达
迭代优化指南
针对用户常见反馈的应对策略：
「太 AI 了 / 不自然」
- 对照禁止词表逐句排查
- 把长句拆成短句
- 加入口语连接词和语气词
- 加入具体的踩坑细节
「太长了」
- 砍背景描述，一句话带过
- 合并相似的技术细节
- 结果部分只保留最亮眼的一个数字
「没深度 / 太浅了」
- 追问用户技术实现细节
- 补充决策权衡过程
- 加入「一开始的方案 vs 最终方案」的对比
- 补充具体的技术指标
「太技术了 / 听不懂」
- 先用一句大白话解释在做什么
- 技术名词后面跟一句解释
- 用类比让非技术面试官也能理解价值
「跟简历写的一样」
- 简历是概括，逐字稿要展开故事
- 补充简历里没写的过程和细节
- 用叙事而非罗列的方式重新组织