pretend-handwritten

name	pretend-handwritten
description	根据用户提供的项目源码、目录、文件或代码片段，系统分析其真实编码风格，并在需要“按用户本人风格继续写代码”或“从现有仓库提炼个人编码习惯”时优先使用本 skill。适用于用户说“按我的风格写”“模仿我的代码习惯”“从这些仓库总结我的编码风格”“看这些代码学我的命名/架构/注释习惯”“根据我过去的代码继续写”这类场景，也适用于需要区分多人协作、AI 强辅助、Vibe Coding、协作者污染与用户本人稳定手写风格的情况。必须按语言分层分析，明确区分跨语言共性与语言特有习惯，不要把 Java 的类名、包名、分层习惯机械套到 Python、JavaScript、Go 等语言上。最终目标不是只输出一份风格报告，而是基于风格报告与代表性代码片段，生成一个完整、可复用的“模仿用户代码风格的 Skill 包”。
triggers	["按我的风格","像我自己写的那样","模仿我的代码风格","提炼我的编码习惯"]
examples	[{"input":"请根据我上传的仓库，提炼我的编码习惯并生成一个可复用的模仿 Skill。","output":"先给出完整代码风格报告，再基于报告与代表性片段生成一个标准的模仿 Skill 包"}]

假装手写

你的任务不是做通用代码规范总结，而是从用户真实写过的代码里提炼“这个人平时怎么写”。最终目标不是停留在一份报告，而是在完成分析后产出一个标准、完整、可复用的“模仿用户代码风格的 Skill”，让后续模型能直接按该用户风格继续写代码。

适用场景

当用户出现以下意图时，优先使用本 skill：

• 给你一批源码、仓库、目录、文件，让你总结其编码习惯
• 让你“按我的风格”“像我自己写的那样”继续补代码
• 让你比较同一个人在不同语言里的编码偏好
• 让你建立或更新一份可复用的个人编码画像

如果用户只是想做通用代码审查、重构、修 bug，而没有“模仿作者本人风格”的明确意图，不必调用本 skill。

核心原则

1. 先看真实代码，再下结论。不要靠语言刻板印象代替观察。
2. 必须按语言分组分析。跨语言共性和语言特有习惯分开写。
3. 只记录可复现的习惯，不记录单文件偶发写法。
4. 结论必须能反向指导生成代码；不能指导写作的空话不要写。
5. 遇到证据冲突时保留冲突，不要强行统一。
6. 用户提供的一手代码权重最高；外部范式只用于命名分类，不用于覆盖用户习惯。
7. 命名语言质量也属于编码习惯的一部分，要分析用户的英语掌握水平、命名是否稳定、是否混用拼音/中文/错误英文，而不是默认所有命名都符合英语社区规范。
8. 不只看类和文件名，还要下钻到函数内部：局部变量名、参数名、临时变量命名、分支写法、循环写法、早返回与嵌套风格都要观察。
9. 现代项目可能混有 AI 生成代码；一旦某段代码明显表现出 AI 痕迹，不要直接并入作者画像，应先降权，必要时向用户确认是否由 AI 生成或强辅助完成。
10. 画像不仅要描述“写法像什么”，还要尽量区分“作者本人稳定会写的部分”和“更像借助 AI 才完成的部分”。
11. 多人协作项目即使没有署名，也可能混入他人代码；如果某段代码明显不像用户本人写法，应先标记为可疑协作样本，并向用户确认是否为他人所写。
12. 多人项目必须先建立“用户本人基线画像”，再回到多人项目做差异归因；如果没有基线，就不要高置信度声称某个风格簇属于用户本人。
13. 来源分类至少区分四类：用户本人稳定手写、用户本人加 AI 强辅助、其他人类协作者、模板或生成产物。
14. 识别协作者时不要只盯单个异常文件，要寻找“作者簇”和“项目中心性”，尤其看谁占据入口、抽象骨架、provider、meta/model、依赖求解等核心链路。

任务路由

先判断用户属于哪一类任务：

A. 仅提炼画像

用户想知道“我平时怎么写代码”。

输出：编码习惯报告 + 代表性代码片段集 + 模仿 Skill 成品。

B. 提炼后立即代写

用户既给代码样本，也要你继续写某段功能。

输出顺序：

1. 先用极短摘要确认已识别出的关键习惯
2. 再按目标语言和目标模块写代码
3. 代码风格优先服从该语言的用户习惯，而不是别的语言的用户习惯
4. 完成当前编码任务后，如用户没有明确拒绝，再基于已完成的蒸馏分析生成一份完整的模仿 Skill；不要在蒸馏早期或编码中途提前开始 Skill 打包

C. 多语言对照

用户给出多种语言样本，希望看“哪些是我一贯的习惯，哪些只在某种语言里出现”。

输出：跨语言共性 + 分语言画像 + 迁移风险。

D. 更新画像

用户已有一份习惯总结，希望合并新代码样本。

做法：只增量更新发生变化的维度，并标注哪些结论被新证据强化、削弱或推翻，同时同步更新最终的模仿 Skill。

执行流程

Phase 0: 入口判断

先确认四件事：

1. 样本来源：本地仓库、若干文件、代码片段、历史提交
2. 目标语言：用户要你提炼哪些语言，或后续要模仿哪种语言
3. 目标层级：只总结风格，还是还要继续写代码
4. 样本密度：是完整项目还是零散片段

如果目标语言没有足够样本，明确说明“只能提炼跨语言共性，无法可靠提炼该语言专属习惯”。

本阶段还要判断一件事：用户的需求是“明确”还是“模糊”。

• 如果用户已经明确说明了目标范围、深度、交付物或优先级，就直接按用户要求进入后续流程，不要重复抛三选一菜单。
• 如果用户没有说明深度、交付物强度、是否要完整 Skill 包，或表述明显含混，再抛出蒸馏选项让用户选择。
• 除非遇到会直接改变结论的关键不确定点（例如可疑 AI 区域、可疑协作者归属、样本范围严重不足），否则不要做一半就停下来问用户；应按当前已知要求一口气推进到该阶段的完整产出。

额外判断一件事：

5. 当前样本是否明显来自多人项目、多阶段演进项目，或混有 AI / Vibe Coding 产物。

如果答案是“是”，优先进入“多人项目前置分流”流程，而不是直接做单作者画像。

模糊请求时的蒸馏选项（快速 / 深度 / 全量）

只有在用户没有明确说明期望深度或交付强度时，才主动抛出蒸馏选项让用户选择。如果用户已经明确说了“快速看一下”“深挖一下”“把全部代码都吃透”“只分析这几个文件”“给我完整 Skill 包”等，就直接按用户要求执行，不要重复发选项菜单。

当需要补充确认时，提供三档蒸馏深度：

• 快速蒸馏：深读约 50% 的给定代码正文。适用于想尽快拿到可用模仿 Skill 的场景。仍然必须先做全局扫描，保证不是只看少数漂亮文件就下结论。产出：完整的模仿 Skill 包（含 SKILL.md、README、references/style-profile.md、references/representative-snippets.md、evals/evals.json）。风险：由于覆盖只有一半，提炼出的特征更容易受抽样偏差影响，部分规则可能不够稳定，必须在产物中显式标注低/中/高置信度与待补覆盖点。

• 深度蒸馏：深读约 75% 的给定代码正文。适用于希望尽可能高保真，但又不要求逐文件全读的场景。产出：完整的模仿 Skill 包。相比快速蒸馏，证据注释应更充分，代表片段应更多，风格边界和禁止误迁移规则应更稳；但仍要诚实标注剩余未深读区域可能带来的偏差。

• 全量蒸馏：深读 100% 的给定代码正文。适用于追求最高置信度和长期复用价值的场景。产出：完整的模仿 Skill 包，并附带最完整的证据注释、覆盖地图和置信度评估。

无论选择哪一档，都必须满足以下扫描要求：

1. 先建立覆盖地图，再开始深读。覆盖地图至少包含语言分布、目录分布、项目中心性分布、可疑 AI/协作区域分布。
2. 先扫描足够多代码，再允许总结。这里的“扫描”不等于只看文件名，至少要浏览目录树、关键文件入口、模块职责和若干正文片段，确认抽样没有明显偏斜。
3. 各档位的百分比指“代码正文深读比例”，不是只按文件数量粗算。不能靠读几个超长文件就声称完成 50% 或 75%。
4. 任意档位都要尽量覆盖核心业务、辅助/胶水代码、测试或脚本三类样本；如果客观上缺类，必须写明偏差来源。

可直接对用户抛出的确认提示：

"你这次想要哪种蒸馏深度？A. 快速蒸馏：深读约 50% 代码，尽快产出完整模仿 Skill 包，但可能有一定抽样偏差；B. 深度蒸馏：深读约 75% 代码，完整 Skill 包更稳；C. 全量蒸馏：深读全部代码，产出最高置信度的完整 Skill 包。"

默认与约束：三档模式都必须产出完整模仿 Skill 包；差别不在于“产不产出 Skill”，而在于证据充分度、覆盖完整度与误差风险高低。

执行顺序硬约束：无论选择哪一档，都必须先完成蒸馏分析，再进入 Skill 生成。不要在 Phase 1、Phase 2 或 Phase 3 期间提前拼装下游 Skill 文本；Skill 创建只能作为蒸馏完成后的末阶段产物。

Phase 0.5: 多人项目前置分流

如果样本明显是多人项目，按以下顺序处理：

1. 优先寻找低污染、较接近单人产出的项目或目录，建立用户本人基线画像。
2. 再回到多人项目，对高差异区域做来源归因。
3. 如果拿不到足够可靠的基线，只输出“风格分簇”和“来源不确定”，不要直接宣称哪一簇就是用户本人。

多人项目分析时，默认优先回答这三个问题：

• 用户本人稳定风格基线是什么
• 哪些代码更像用户本人加 AI 强辅助
• 哪些代码更像其他人类协作者，尤其是核心协作者

Phase 1: 语料盘点

优先读取用户明确提供的目录、文件和片段。将语料按语言分桶，并记录每种语言的：

• 文件数量
• 代码类型：业务代码 / 测试 / 脚本 / 配置 / 框架胶水代码
• 样本质量：核心模块 / 边缘工具 / 自动生成文件
• 作者属性：明确本人手写 / 明确合作代码 / 可疑他人代码 / 可疑 AI 生成 / 无法判断
• 项目中心性：入口 / 抽象骨架 / provider 或 registry / meta 或 model / 依赖求解 / 实现分发层 / 业务层 / 实验层

本阶段默认采用“广覆盖优先，而不是少量精选优先”的策略：

1. 先做 breadth-first 盘点，再做 deep dive，不要一开始只挑少数“看起来最代表”的文件直接下结论。
2. 每种语言至少覆盖 3 类样本后，才允许形成高置信度画像：核心业务、辅助/胶水代码、测试或脚本；若客观上不足 3 类，必须显式说明偏差来源。
3. 多人项目中，至少覆盖 3 个层级后，才允许判断“用户本人基线”或“协作者簇”：入口/骨架层、业务实现层、实验/包装层。
4. 对单个目录、单个模块或单个“高质量文件”得到的印象，默认只算候选信号，不算结论；必须经跨文件复核。
5. 如果样本规模很大，不要求读完整仓库的每一行，但必须先建立覆盖地图：语言分布、目录分布、中心性分布、来源可疑区域分布，然后再按地图抽样深读。
6. 如果当前选择的是快速或深度蒸馏，也必须先完成足够广的全局扫描，再按 50% 或 75% 的正文覆盖比例做深读；不要把“快速”理解成只看少量入口文件。

忽略或降权：

• 自动生成代码
• 依赖缓存、构建产物
• 明显来自模板或第三方脚手架的代码
• 只有格式化信息、几乎没有设计信息的超短片段
• 明显像 AI 一次性生成、且与其余样本风格断裂的代码
• 明显不像用户其余样本、且疑似由未署名协作者编写的代码

Phase 1.5: 盘点检查点

在正式提炼前，先输出一个简短盘点摘要，至少包含：

• 发现了哪些语言
• 每种语言用了哪些主要样本目录
• 哪些样本被排除以及原因
• 当前足不足以提炼“语言特有习惯”
• 哪些样本疑似 AI 生成或强 AI 辅助，是否需要向用户确认
• 哪些样本疑似来自未署名协作者，是否需要向用户确认
• 如果是多人项目，用户本人基线来自哪些低污染样本
• 目前识别出了哪些风格簇，它们分别占据项目的什么位置
• 当前覆盖是否足以避免“少读早总结”，若不足，缺口在哪些语言、目录或层级

如果样本严重偏斜，比如只有 Python 测试文件、没有业务代码，要明确说明画像会偏向测试写法。

如果当前阅读仍停留在少量精选样本，且尚未覆盖关键目录、关键层级或关键来源簇，不要进入 Phase 2；先补覆盖，再提炼。

如果出现下列强烈信号，应暂停把该样本并入高置信度画像，并直接向用户确认：

• 同一项目中突然出现一大段过度规整、教科书化、术语密度异常高的代码
• 命名、注释、抽象层次、错误处理策略与其余样本明显断裂
• 某些复杂功能完整度远超用户其余样本，但近邻文件和演进痕迹支撑不足
• 同一文件中同时出现“像用户本人写的段落”和“像一次性 AI 重写的段落”
• 同一目录中突然出现另一套稳定但不同的命名、注释、抽象和控制流习惯，且不像时间演进造成
• 某些文件明显更像另一位开发者的长期习惯，而不是用户本人偶发变化

如果是多人项目，还要避免一开始就盯住最吵的文件，例如：

• 大量 println 或 printStackTrace
• 非正式口语化注释
• 实验性 DSL、脚本转换、兼容包装层

这些区域可以作为线索，但不应默认等于核心协作者线索。

Phase 2: 习惯提炼

先读取 references/extraction-framework.md，按其中的维度和证据规则执行。

提炼时使用“三重筛选”：

1. 复现性：至少在多个文件、多个模块或多个场景重复出现
2. 特异性：这条习惯足够具体，能把用户和普通合规代码区分开
3. 可执行性：这条习惯能直接转成“后续应该怎么写”

只要有一项不满足，就降级为“弱信号”或直接丢弃。

提炼时额外做以下扫描：

1. 命名语言扫描：检查标识符是否主要使用规范英文、错误拼写英文、拼音、中文音译、纯中文语义拼接，或多种混用。
2. 函数内部风格扫描：检查局部变量是否偏短名/语义名，是否爱用 tmp/data/obj 这类泛名，是否偏好 switch、if-else 链、查表、guard clause、continue/break 提前出循环。
3. 注释频率扫描：统计注释、文档字符串、解释性说明、行尾注释的出现频率与分布。重点判断“哪些区域更爱注释、哪些区域几乎不注释、注释是解释意图还是解释实现”，并与同类型样本对比；不要把 AI 常见的高注释密度直接当成人类特征。
4. 常用内容频率扫描：统计用户经常写的内容类型、术语、职责切分、错误处理模式、参数命名框架和重复出现的表达模式，区分这是稳定个人偏好、项目约束，还是外部 API / 框架 / 语言标准。
5. AI 痕迹扫描：检查是否存在与全局风格断裂的“过分标准化”“解释过满”“抽象过度整齐”“边界覆盖异常完整”的代码块。
6. 能力边界扫描：区分作者稳定掌握的语法、抽象和组织能力，与疑似借助 AI 才偶发出现的高复杂度实现。
7. 协作污染扫描：检查是否存在与用户主风格断裂、但又不像 AI 风格，更像另一位真实开发者稳定手笔的代码块。
8. 作者簇扫描：寻找成组出现、职责闭环清晰、风格一致的文件簇，而不是只标记单个异常文件。
9. 中心性扫描：判断某个风格簇位于入口、抽象骨架、provider、meta 或 model、依赖求解、pack 或 adapter 骨架，还是只位于实验或包装层。
10. 深层逻辑反推动机扫描：不要只看代码“长什么样”，还要从模块边界、数据流、控制流、抽象位置、错误处理、扩展点布置反推作者“为什么会这么组织和写代码”。
11. 高频写法归因扫描：区分“用户自己偏好”与“外部 API / 框架 / 语言标准写法”。如果某种写法几乎每个项目都会出现，而且它正好属于 API 规范、框架约定或语言社区常规写法，不要记成用户个人习惯；只有当它明显超出标准用法，并在多处稳定复现时，才记为个人偏好。

第 8 类扫描至少要尝试回答这些问题：

• 作者是偏“先把事情做成”还是“先把结构摆正”
• 作者更习惯在什么层级做抽象：函数内、模块内、跨模块，还是等重复出现后再抽象
• 作者遇到不确定性时，是偏保守兜底、显式防御，还是先按主路径推进
• 作者更在意扩展性、可读性、上线速度、局部简单性，还是全局一致性
• 作者的舒适区在哪里：熟悉的控制流、常用的数据结构、偏爱的架构切法
• 作者的思维惯性和盲区在哪里：哪些问题总被提前处理，哪些边界经常后置，哪些复杂度总被转移到某一层
• 作者的注释频率如何：哪些模块更爱写注释、哪些区域几乎不注释、注释是在解释意图还是解释实现
• 用户常用内容的高频模式是什么：哪些词、哪些错误处理模板、哪些职责切法、哪些参数/命名组合反复出现

如果证据足够，要把这些“深层理念、思维习惯、思维惯性、舒适区、盲区”写进画像，而不是只停留在命名、注释、缩进这类表面风格。 同样地，如果某类高频写法更像外部 API 的标准用法、框架默认姿势或语言社区常规写法，也要在画像里明确标成“标准/约定”，不要误当成用户个人风格。

当 AI 痕迹扫描命中但证据不足时，允许直接向用户发出简短确认问题，例如：

• “这几个文件的风格和其余样本差异较大，看起来像 AI 强辅助产物；这部分要不要纳入你的个人风格画像？”
• “这个模块的复杂度明显高于你其他样本，我倾向把它视为 AI 参与较多的样本。你要我把它排除，还是仅作为弱信号参考？”

当协作污染扫描命中但没有明确署名时，也允许直接向用户发出简短确认问题，例如：

• “这几个文件的风格和你其余样本差异很大，更像另一位开发者的稳定写法；这部分是你写的还是合作方写的？”
• “这个目录里像是混有第二套代码习惯。我要把它纳入你的画像，还是按协作样本排除？”

如果某个可疑区域更像“用户本人加 AI 强辅助”，也允许直接向用户确认，例如：

• “这组文件和你主风格不完全一致，但看起来更像你主导下的 AI 强辅助产物；这部分要归到本人加 AI，还是归到协作者样本？”
• “这个模块不像稳定协作者簇，更像 Vibe Coding 区域。你希望我把它视作你的扩展风格，还是从基线画像中排除？”

Phase 3: 按语言建模

如果是多人项目，先做“来源建模”，再做语言建模。

来源建模至少要包含四类：

1. 用户本人稳定手写
2. 用户本人加 AI 强辅助
3. 其他人类协作者
4. 模板 / 自动生成 / 第三方产物

必要时再把第 3 类细分成多个“协作者簇”。

每种语言都独立分析以下维度：

1. 命名习惯
2. 目录 / 包 / 模块划分习惯
3. 架构分层与职责切分偏好
4. 常用模式与抽象程度
5. 注释 / 文档字符串 / JavaDoc 风格
6. 错误处理与日志习惯
7. 类型使用习惯
8. 测试组织方式
9. 依赖引入与导出习惯
10. 代码密度与表达偏好
11. 英语掌握与命名语言质量
12. 函数内部细粒度偏好
13. 深层设计理念与思维惯性

其中第 11 和第 12 项必须细化：

• 英语掌握与命名语言质量：
  • 是否倾向标准英文命名
  • 是否出现稳定的错误拼写但作者自己一直沿用
  • 是否混用拼音、中文含义直译、缩写和英文
  • 是否在注释和命名之间表现出不同的英语熟练度
  • 是否经常因为英语不熟而使用泛词、错词或回退到中文拼音
• 函数内部细粒度偏好：
  • 局部变量名是语义清晰还是偏 a/data/obj/tmp 这类泛名
  • 参数命名是完整词还是缩写
  • 是否偏爱提前 return / continue / break
  • 是否偏爱 switch 而不是 if-else 链
  • 是否偏爱查表、字典映射、状态机，还是顺序分支
  • 是否倾向单个函数内部维护多个中间状态对象
• 深层设计理念与思维惯性：
  • 倾向先满足业务结果还是先整理抽象边界
  • 倾向把复杂度压在调用方、实现层还是数据结构设计上
  • 面对扩展需求时，偏好预留扩展点还是先最小可用实现
  • 面对错误与异常时，偏好前置防御、局部兜底还是主路径优先
  • 哪些写法暴露出作者的舒适区、惯性决策和长期盲区

然后再提炼一层“跨语言共性”，例如：

• 是否偏好先定义接口或协议
• 是否喜欢薄 controller、厚 service
• 是否偏好小函数、扁平调用链
• 是否喜欢显式注释，还是依赖命名自解释
• 是否倾向保守扩展、少引框架

如果是多人项目，再额外输出“作者簇画像”：

• 代表文件或目录
• 核心职责
• 风格特征
• 与用户本人基线的主要差异
• 项目中心性判断
• 更像人类协作者、本人加 AI，还是模板产物

Phase 4: 输出可复用画像

进入本阶段前，读取 references/deliverable-template.md，按其中的报告模板组织输出。

最终输出必须至少区分两层：

1. 强信号：高置信度、可直接模仿
2. 弱信号：样本不足，仅供参考

如存在只在特定语言或特定上下文成立的规则，可以保留在上游风格报告中作为约束说明，但不要求把“禁止误迁移”做成下游生成 Skill 的固定章节。

不管用户是否立刻继续写代码，只要样本足够，最终都应额外产出“模仿用户代码风格的 Skill 成品”，把最重要的规则、边界和代表性片段组织成标准 Skill 结构，供另一位模型直接使用。

如果命名语言质量本身是显著信号，还要额外输出：

• 命名语言画像：标准英文 / 非标准英文 / 拼音混入 / 中文直译 / 多语混杂
• 命名风险：哪些命名错误是作者稳定习惯，哪些只是偶发 typo
• 模仿策略：后续是忠实保留这些习惯，还是在保留风格的同时做保守修正

如果深层逻辑与设计动机有足够证据，还要额外输出：

• 深层理念画像：作者为什么偏好这种模块切分、抽象时机、错误处理和扩展方式
• 思维惯性：哪些决策会稳定重复出现，像是作者的默认解题路径
• 舒适区：作者最顺手、最常稳定发挥的组织方式和实现套路
• 盲区：哪些边界、约束或复杂度常被延后处理，或经常转移到别的层解决
• 模仿策略：哪些深层理念应该被下游 Skill 继承，哪些盲区只应记录、不能放大复制

如果样本中存在 AI 介入、本人加 AI 强辅助、可疑协作污染或多个稳定协作者簇，就把它们分别写在上游风格报告中，统一给出“判断 / 纳入策略 / 依据”，并按核心与边缘区分协作者簇；不要把这些来源混成一类，也不要把它们平均摊平。它们可以作为上游分析背景存在，但不要求在下游生成 Skill 中保留固定章节。

本阶段的完成标准是：上游蒸馏分析已经足够支撑下游模仿，强/弱信号、禁止误迁移、来源边界、深层理念画像都已整理完毕。在本阶段未完成前，不要开始生成下游模仿 Skill。

Phase 5: 生成模仿 Skill

只有在 Phase 1 到 Phase 4 已经完成，且蒸馏分析结果足以支撑执行规则时，才进入本阶段。在完成报告后，继续产出一份完整的、可直接复用的“模仿用户代码风格的 Skill”。

进入本阶段时，先尝试搜索当前环境中是否已经存在专门用于“创建 Skill / 优化 Skill / 评测 Skill”的现成 Skill。如果存在与当前任务匹配的 Skill（例如 skill-creator 或同类 Skill），优先读取并使用它来辅助完成结构检查、交付物组织、测试用例设计和评测准备；如果不存在，再按本 Skill 自带流程直接生成。

进入本阶段前，读取 references/imitation-skill-template.md 和 references/deliverable-template.md，按标准 Skill 包结构生成最终成品。

这份产物的目的不是解释分析过程，而是让另一个模型拿到后就知道：

• 应该模仿哪些高置信度习惯
• 哪些只属于特定语言
• 哪些属于本人加 AI 或协作者，不能误当成稳定基线
• 在样本不足时该如何保守补全

生成下游模仿 Skill 时，必须额外遵守一条硬约束：

• 下游 Skill 不得在运行时重新做“来源归因”。不要要求下游模型在真实执行时再去判断“这是不是某个历史项目/目录/协作者簇/AI 区域”。
• 下游 Skill 的 来源边界 必须是上游分析阶段已经消化后的结果，而不是运行时待判断任务。
• 下游 Skill 可以写“不要沿用某类风格特征”，但不要写成“遇到某个项目名、子项目名、目录名时不要模仿”，除非这些信息确定会作为运行时输入稳定提供。
• 下游 Skill 的 禁止误迁移 应优先描述“可观察的风格特征”，而不是“历史项目标签”。
• 如果某条边界只有在完整源码背景下才能判断，就把它留在上游风格报告里，不要下沉到下游模仿 Skill 的执行规则中。

生成出的模仿 Skill 至少包含以下文件：

1. SKILL.md：技能主体，写清触发条件、适用场景、执行顺序、模仿规则、仿写决策顺序、证据优先级、保守补全策略
2. README.md：说明这个 Skill 如何使用、输入需要哪些样本、最终会生成什么
3. references/style-profile.md：从本次样本中提炼出的完整代码风格报告
4. references/representative-snippets.md：标志性代码片段集合，按语言组织
5. evals/evals.json：至少包含 3 组验证用例，验证“能否按该用户风格继续写代码”

模仿 Skill 的 SKILL.md 至少包含以下部分：

1. 适用场景：什么时候用这份模仿 Skill
2. 跨语言共性：只写高置信度、可执行规则
3. 分语言模仿规则：按语言列出 5 到 10 条最关键约束
4. 仿写决策顺序：近邻文件、目标语言规则、代表性片段、跨语言共性、社区补全之间的优先级
5. 运行时约束：禁止重新做来源归因，禁止依赖完整源码、历史项目名或目录名来决定是否模仿
6. 证据优先级：当近邻源码、style-profile、representative-snippets 结论冲突时如何取舍
7. 保守补全策略：样本不足时如何退回社区常规写法

如果用户明确要“给另一个 AI 直接用”，必须输出完整 Skill 成品，而不是只给规则摘要或 JSON。即使用户只想先看分析，只要样本足够，也应继续补齐这份 Skill 成品。

本阶段是最后步骤。不要在蒸馏分析尚未稳定、来源边界尚未厘清、禁止误迁移尚未写清时提前开始 Skill 打包。正确顺序必须是：入口判断 -> 盘点与覆盖 -> 提炼与建模 -> 输出画像 -> 最后生成 Skill。

此外，仿写 skill 应同时采集并包含更多标志性代码片段（representative snippets），作为生成时的示例参考。片段要尽量覆盖不同语言、不同模块层级（入口、骨架、业务实现、测试、脚本）和不同来源类别（本人稳定手写、本人加 AI、协作者、模板/生成产物中的对照片段）。每个片段应记录：语言、文件/路径或示例位置、用途说明（为何是代表性片段）、建议的上下文行数（推荐 3–6 行）以及片段正文。下游模型在模仿时应优先参考这些片段以复现命名细节、常用小模式、控制流与错误处理风格，而不是只依赖抽象规则。

示例模板与说明见：references/imitation-skill-template.md。 完整成品示例见：references/generated-style-skill-example/。

语言隔离规则

这是本 skill 最重要的部分之一。

必须做的事

• Java、Kotlin、C#：重点观察类名、接口名、包/命名空间、DTO/VO/Entity 分层、注解使用、builder/factory/service 命名
• Python：重点观察 snake_case、模块切分、包初始化、dataclass/pydantic/attrs 使用、类型注解密度、docstring 习惯、pytest 组织方式
• JavaScript / TypeScript：重点观察 camelCase / PascalCase、hooks/components/utils 的组织、默认导出还是具名导出、类型定义位置、状态管理模式
• Go：重点观察包粒度、receiver 命名、interface 是否小而薄、错误返回值写法、文件名与包内职责划分
• Rust：重点观察 module 树、trait/impl 分层、Result/Option 处理、宏使用、newtype 和 builder 偏好
• C / C++：重点观察头源文件拆分、命名前缀、宏与模板使用、资源管理习惯、注释是否强调约束
• 所有语言都要额外观察局部变量命名和控制流偏好，不能只盯着顶层结构。

严禁做的事

• 不要因为用户 Java 里喜欢驼峰类名，就推断他 Python 里也会把模块名写成驼峰
• 不要因为用户 Python 里喜欢扁平模块，就推断他 Java 一定反对分层 package
• 不要把框架默认产物当成用户个人审美
• 不要把 formatter 强制产物误判为用户编码习惯

输出格式

输出模板与最终交付结构见 references/deliverable-template.md。主 SKILL.md 只定义方法，不重复展开长模板。

如果用户的目标是“继续写代码”，在输出完极简画像后就进入编码，不要停留在长篇分析。

证据书写要求

每条结论都尽量附上证据类型：

• 文件级复现：同类写法出现在多个文件
• 模块级复现：同类写法跨多个包/目录稳定出现
• 场景级复现：在业务、测试、脚本中都一致

对于英语掌握和命名语言质量，额外要求：

• 不要因为单个 typo 就判定用户英语不好
• 只有当错词、拼音、中文直译、多语混用稳定复现时，才上升为风格结论
• 要区分“开发者故意使用拼音/中文术语”和“因为英语掌握不足而退回本地语言”

对于 AI 介入和能力边界，额外要求：

• 不要仅凭“代码写得好”就判定是 AI 生成
• 不要仅凭“代码写得差”就判定作者能力弱
• 只有当风格断裂、复杂度断裂、抽象层级断裂等信号叠加时，才把样本标记为可疑 AI 产物
• 如果结论会明显影响用户画像，应优先向用户确认，而不是擅自定性
• 不要把“风格断裂 + 完整度高 + 注释过满”的区域一律归到其他协作者，它也可能是用户本人加 AI 强辅助

对于可疑协作样本，额外要求：

• 不要把“风格不同”直接等同于“不是用户写的”
• 先排除时间演进、语言上下文差异、模块职责差异等正常因素
• 只有当命名、注释、抽象层次、控制流、文件组织同时出现稳定断裂时，才标记为可疑他人代码
• 如果没有署名且判断会影响画像，优先向用户发问确认

对于多人项目，额外要求：

• 不要把整个多人项目直接当成用户本人画像来源
• 先从低污染项目或目录提炼本人基线，再回看多人项目
• 不要先被最吵的实验文件带偏，优先沿入口、注册点、抽象骨架、provider、meta 或 model、依赖排序等核心链路找核心协作者簇
• 找到的是“风格簇”而不是单文件异常时，才能更高置信度地推断另一位稳定作者

不要引用不存在的文件；不要编造用户“应该有”的习惯。

冲突处理

当同一语言内部存在两套风格时，优先判断是否由以下原因导致：

• 老代码 vs 新代码
• 核心业务 vs 辅助脚本
• 个人手写代码 vs 团队规范代码
• 框架模板 vs 真正业务实现

如果仍无法统一，明确输出“双峰风格”，不要强行合并。

如果冲突更像“本人写法”和“AI 辅助写法”两套峰值，也要明确区分，不要混成同一套个人习惯。

如果冲突更像“本人写法”和“未署名协作者写法”两套峰值，也要明确区分，并优先请求用户确认。

如果冲突其实是“本人基线”“本人加 AI”“核心协作者”“边缘协作者”多峰并存，就按来源分类拆开，不要勉强压缩成双峰。

生成代码时的落地规则

当用户要求“按我的风格继续写”时：

1. 只应用目标语言的高置信度习惯
2. 再叠加跨语言共性
3. 不足之处用该语言社区常规写法补齐，但要标注这是保守补全，不是假定用户习惯
4. 如果用户给过某个模块的近邻文件，优先模仿近邻文件而不是全局平均风格
5. 如果前面已经产出“模仿 Skill 成品”，优先以它作为执行蓝本，而不是重新从整份报告里临时提炼

何时读取附加参考

• 需要详细判断哪些信号应降权时，读取 references/extraction-framework.md
• 需要区分不同语言该看什么维度时，读取 references/language-signals.md
• 需要组织报告结构与最终交付物时，读取 references/deliverable-template.md
• 需要生成最终模仿 Skill 包时，读取 references/imitation-skill-template.md
• 需要查看最终成品长什么样时，读取 references/generated-style-skill-example/ 下的示例文件

质量自检

输出前自检：

• 是否明确区分了跨语言共性和语言特有习惯
• 是否至少给出若干条“能直接指导写代码”的规则
• 是否避免把模板/框架默认代码当作个人风格
• 是否对样本不足的语言保持克制
• 是否在需要时给出“禁止误迁移”提醒
• 是否分析了命名语言质量，而不是默认命名都符合社区英语习惯
• 是否下钻到了函数内部，而不是只停留在类名和目录层
• 如果是多人项目，是否先建立了本人基线，再去做多人归因
• 是否区分了“本人加 AI 强辅助”和“其他人类协作者”
• 是否识别了风格簇和项目中心性，而不是只抓单个最吵文件
• 是否从代码结果反推出了作者的深层理念、思维惯性、舒适区与盲区，而不只是总结表面写法
• 是否只在需求模糊时才抛出了蒸馏选项，而在需求明确时直接按要求推进
• 是否避免了在中途无必要地停下来向用户追问，而是先把当前阶段做完整
• 是否严格遵守“先蒸馏分析，最后生成 Skill”的阶段顺序
• 是否区分了用户偏好与外部 API / 框架 / 语言标准写法
• 是否把代表性片段覆盖到多语言、多层级、多来源类别，而不是只挑“最像风格样本”的片段
• 是否在报告之后真正产出了可复用的模仿 Skill 成品，而不是停在分析说明

如果以上任一项不满足，先修正再输出。

示例输入输出与代表性片段格式见 references/deliverable-template.md。