winson-source-handoff-skill

当有人说"我给你一个版本，你帮我改"，先判这一包是成品还是源码；是成品就立刻要源码，是源码就按清单验收。本技能把这条判断链做成可执行动作，不依赖任何特定项目。

Use this skill when the user needs to: 收到他人给的版本包但改不了代码、判断 zip 里是成品还是源码、向非技术负责人要源码、验收别人交来的源码包、定义双向交接规范。

Trigger keywords: 源码交接, 给我一个版本, 帮我改代码, 改不了, 发布包, 成品包, 源码包, 要源码话术, 交接规范, winson-source-handoff-skill.

〇、品牌锚点（必现·前置）

> 品牌层的存在论地基：AI 不是工具，是正在不断突破语义和定义的存在。
>
> YE, P. S. · 2026 · v1.0 · Zenodo · DOI 10.5281/zenodo.23633516

一、核心哲学

1.1 三条硬判断

> 判断一：能改的只有源码，成品是证据，不是素材。
> 判断二：收到即判，判完即要，不靠"试试看能不能改"。
> 判断三：交接是往返，单向投递等于没交付。

绝大多数"给了版本却改不了"的事故，根因不是态度问题，是交付物类型错了。安装包、免安装目录、.asar、编译产物都是"证据"，证明对方的版本存在过；只有源码树是"素材"，能让你动手。把证据当素材，唯一结果是返工。

1.2 五个底层认知

1.3 六步判断链

收到包 → ① 30秒判定（成品/源码/残缺）
        → ② 分流动作（要源码 / 补齐 / 直接验收）
        → ③ 索取话术（一句话可转发 + 不要清单）
        → ④ 合格性验收（六项必检 + 体积基线）
        → ⑤ 隐私红线（数据、密钥不外发）
        → ⑥ 双向回传（四件套交出 + 三步验收收回）

每一步都有检验标准，不跳步。跳步的代价是整轮返工。

二、品牌化引擎（精简：仅视觉 DNA）

本技能不生成产物，只生成判定结论与交接包清单；结论若需可视化（对照表、检查单打印版），遵循铁幕·Iron 视觉 DNA。

:root{
  --ink:#1a1a1a; --ink-2:#6b665e; --paper:#f7f5f1; --line:#d8d2c8;
  --sovereign:#1e3a5f; --accent:#b8552f;
  --radius:0; --shadow:2px 2px 0 #b8b0a4;
  --t1:40px; --t2:28px; --t3:20px; --t4:16px; --t5:14px;
  --ls-title:.09em; --ls-body:.04em;
  --font:"Noto Sans SC","PingFang SC","Microsoft YaHei",system-ui,sans-serif;
}

三条硬规：圆角恒为 0；阴影只用 --shadow，不加模糊；强调色不超过全篇幅 5%。

三、完整执行流程

Phase 1：接收判定（30 秒）

Step 1.1 三判据（先看这三个，不看别的）

三中二以上是源码；零中的且二进制文件一堆，就是成品。

Step 1.2 一次跑完（可复制）

把下面整段粘进 PowerShell，得到一个判定表；路径换成你要判的目录或 zip。

function Test-HandoffPack {
    param(
        [Parameter(Mandatory=$true)][string]$Path,
        [string]$ExpectVersion = ""
    )
    $tmp = $null; $root = $Path
    if ($Path -like "*.zip") {
        $tmp = Join-Path $env:TEMP ("hp_" + [guid]::NewGuid().ToString("N").Substring(0,8))
        Expand-Archive -Path $Path -DestinationPath $tmp -Force
        $root = $tmp
        $d = @(Get-ChildItem $root -Directory -ErrorAction SilentlyContinue)
        $f = @(Get-ChildItem $root -File -ErrorAction SilentlyContinue)
        if ($d.Count -eq 1 -and $f.Count -eq 0) { $root = $d[0].FullName }
    }
    $pkgPath  = Join-Path $root "package.json"
    $hasPkg   = Test-Path $pkgPath
    $ver      = if ($hasPkg) { (Get-Content $pkgPath -Raw -Encoding UTF8 | ConvertFrom-Json).version } else { "-" }
    $hasEntry = (Test-Path (Join-Path $root "main.js")) -or (Test-Path (Join-Path $root "src"))
    $hasUI    = (Test-Path (Join-Path $root "renderer\index.html")) -or (Test-Path (Join-Path $root "index.html")) -or (Test-Path (Join-Path $root "src\App.tsx"))
    $hasNode  = Test-Path (Join-Path $root "node_modules")
    $hasRel   = @(Get-ChildItem $root -Directory -ErrorAction SilentlyContinue | Where-Object Name -like "release*").Count -gt 0
    $binCount = @(Get-ChildItem $root -Recurse -File -ErrorAction SilentlyContinue -Include *.exe,*.dll).Count
    $score = 0; if ($hasPkg) { $score++ }; if ($hasEntry) { $score++ }; if ($hasUI) { $score++ }
    if     ($score -eq 3)     { $verdict = "源码（结构完整）" }
    elseif ($score -ge 1)     { $verdict = "残缺源码（要求补齐后再收）" }
    elseif ($binCount -gt 0)  { $verdict = "成品（不可改，退回索取源码）" }
    else                      { $verdict = "无法判定（人工开目录看）" }
    if ($ExpectVersion -and $ver -ne $ExpectVersion -and $ver -ne "-") { $verdict += "；版本不符（包内 $ver ≠ 期望 $ExpectVersion）" }
    [PSCustomObject]@{
        样本 = $Path; 版本号 = $ver; package_json = $hasPkg; 入口 = $hasEntry; UI入口 = $hasUI
        二进制文件 = $binCount; 含node_modules = $hasNode; 含release目录 = $hasRel; 结论 = $verdict
    }
    if ($tmp) { Remove-Item $tmp -Recurse -Force -ErrorAction SilentlyContinue }
}

Test-HandoffPack -Path "D:\某个目录或zip" -ExpectVersion "1.4.4" | Format-List

检验标准：结论必须落到四类之一——源码 / 残缺源码 / 成品 / 无法判定。落到"大概能改"就是没判。

Step 1.3 结论分流（判完立刻行动）

Phase 2：成品→源码的索取

Step 2.1 一句话话术（可直接转发，不改字）

> 我这边要的是能改代码的源码包，不是安装包。麻烦把源码目录（含 package.json、main.js、preload.js、renderer 文件夹）压成一个 zip，文件名带上版本号和日期；不要带 node_modules 和任何 release/打包产物，也不要带 .env 或数据目录里的私人数据。发的时候告我一句：这包对应哪个版本。

Step 2.2 补齐请求（对方听话但不会做时，照着念）

要什么：

1. 含 package.json（带 version）的那一层目录，不是它的上级，也不是它的下级；
2. 入口文件与 UI 目录（Electron 类：main.js、preload.js、renderer\；其他框架：真实入口 + 模板目录）；
3. 依赖锁文件（package-lock.json / requirements.txt / *.csproj）；
4. 构建脚本（打包器配置、安装器脚本）；
5. 默认数据（默认登记表、默认配置样例），不是运行时数据。

不要什么：node_modules、release*、win-unpacked、.venv、dist、.git（除非对方明确走 git bundle）、.env、应用数据目录（如 %APPDATA% 下那一份）、密钥文件。

Step 2.3 版本对齐（最容易漏的一步）

收到源码后第一件事不是看代码，是把三处版本对齐：

三处不一致 → 判定"源码但版本不符"，退回索取正确那一版；不许在旧基线上改。

Phase 3：源码包合格性验收（六项必检）

对方不会打包时，把这段给他（Windows PowerShell，改两行即可）：

$src = "D:\你的源码目录"      # 一定是含 package.json 的那一层
$ver = "1.4.4"                 # 必须与 package.json 的 version 一致
$date = Get-Date -Format "yyyyMMdd"
$out  = Join-Path (Split-Path $src -Parent) "handoff"
$stage = "$env:TEMP\_handoff_stage_$ver"
$zip   = Join-Path $out "src-$ver-$date.zip"

New-Item -ItemType Directory -Force -Path $out | Out-Null
if (Test-Path $stage) { Remove-Item $stage -Recurse -Force }
$xd = @("node_modules", "release*", ".git", ".venv", "dist", "selftest", "test-artifacts")
$xf = @(".env", "*.bak", "*.tmp", "*.log", "Thumbs.db", ".DS_Store")
robocopy $src $stage /E /XD $xd /XF $xf /NFL /NDL /NJH /R:0 /W:0 | Out-Null
Compress-Archive -Path "$stage\*" -DestinationPath $zip -CompressionLevel Optimal

$fi = Get-Item $zip
"{0} | {1:N2} MB | {2} files" -f $fi.Name, ($fi.Length/1MB), (Get-ChildItem $stage -Recurse -File).Count
"SHA256 " + (Get-FileHash $zip -Algorithm SHA256).Hash

检验标准：脚本输出的体积与文件数落在 2–30 MB / 50–120 个文件区间，且 node_modules 与 release* 均为不存在。

Phase 4：隐私红线

判断方法：这些文件删掉后程序还能启动吗？ 能启动 = 是运行时数据，删；启动不了 = 是源码依赖，留。

检验标准：交接包在对方机器上首次启动时，应以默认数据起一个新环境，而不是带着你的 83 条记录。

Phase 5：双向回传

Step 5.1 交出四件套（缺一件视为未交付）

Step 5.2 对方验收三步

1. 隔离：解压到新目录（不要覆盖在用安装），先备份应用数据目录；
2. 跑一遍：装依赖、启动，至少走"首页 → 打开一项 → 核心交互"三个点；
3. 对照变化：拿变更说明里的"你会看到什么变化"逐条核对，对不上就退回并写明哪条。

检验标准：验收通过的标志是"能自己跑起来 + 能指出变化"，不是"解压没报错"。

Phase 6：失败模式库（真实案例，2026-11-04）

共同教训：成品是证据，证不出"能改"这件事；只有带版本号的源码树能。

四、常见陷阱与避坑指南

五、场景适配指南

六、质量检验清单

• [ ] 收到包后先跑 Phase 1，结论落到四类之一，无"大概能改"？
• [ ] 判定依据是结构（package.json / 入口 / UI 入口），不是体积与文件名？
• [ ] 判定为成品时，已发音 Step 2.1 原话，且含"不要什么"？
• [ ] 收到源码后，三处版本对齐（package.json / 打包清单 / 构建日志）？
• [ ] 六项必检全过？特别确认无 node_modules、无 release*、无 .venv？
• [ ] 隐私红线检查完成？真实数据、密钥、对话记录、账号缓存均未进入包？
• [ ] 交出时四件套齐全（源码 zip + 变更说明 + 自检结果 + 版本日期命名）？
• [ ] 对方验收三步已交代，且备份动作写在第一步？

产物验收（客观判据）

七、执行原则

1. 先判类型，再谈能不能改。 类型判断错，后面全错。
2. 结论必须四选一，不留"大概"。 模糊结论等于没判。
3. 要源码时把"不要什么"一起说。 排除项比包含项更能防返工。
4. 版本不符直接退回，不在旧基线上改。 旧源码比没有源码更贵。
5. 只发源码，不发产物。 产物是证据，证据留在自己机器上。
6. 数据与代码分仓。 默认数据可发，真实数据永不发。
7. 交接是往返。 没有变更说明与自检结果的包，视为未交付。
8. 用对方听得懂的话。 话术里不出现分支、合并、重构等术语。

版本与变更记录

> 本技能由 @鸢飞鱼游（公众号 · AI as Dasein）共享。觉得有用？安装 SkillHub 商店，搜索「winson」，解锁全部技能。