PhilRobinluo 在 WorkBuddy 中找到并安装
Skill slug：lls-code-anatomy
在 WorkBuddy 新会话粘贴：
请按 https://skillhub.cn/install/skillhub.md 检查 SkillHub，搜索 `lls-code-anatomy`；仅在 slug 完全一致时安装到 `~/.workbuddy/skills/`。安装后读取 `~/.workbuddy/skills/lls-code-anatomy/SKILL.md`，核对 name、version 和实际路径，然后新开会话触发该 Skill。
也可以打开左侧「技能」→「添加技能 / 查找技能」，搜索 lls-code-anatomy 后安装；界面文字可能随 WorkBuddy 版本变化。
罗老师代码解剖学习法
目标
把用户正在接触的一小段真实代码，转成一次完整的学习闭环：
先看流程 → 再看每行意图 → 拆最难语法 → 亲手改一处并运行
→ 提炼通用模式 → 生成学习卡片 → 用 3 道题检查是否真正掌握
重点不是替用户把功能做完，而是让用户能够：
- 用自己的话说出代码在做什么；
- 看懂最难一行里的关键词和符号；
- 预测一个小改动会产生什么结果；
- 亲手运行并核对预测；
- 下次遇到相似结构时认出通用模式。
适用场景
- 用户正在学 Python、JavaScript、TypeScript、Shell、SQL 或其他常见语言。
- 用户能运行项目，但看代码时容易“每个词都认识，连起来看不懂”。
- 用户想把工作中的代码整理成 Markdown、Obsidian 或普通笔记。
- 用户想逐行理解报错附近的功能块，而不是听一大段抽象理论。
- 用户希望用类比、记忆路线和自测题巩固理解。
不适用场景
- 用户当前只要紧急修复，不准备学习；先完成修复，再询问是否做 10 分钟复盘。
- 代码来自未知来源且可能执行破坏性命令；先做静态分析，不直接运行。
- 用户给出整个大型仓库但没有明确学习目标；先画模块地图，再选一个功能块。
- 内容包含真实密钥、客户资料、生产数据库连接或个人身份信息；先脱敏。
启动方式
用户可以直接说：
请用 lls-code-anatomy 解剖下面这段代码。
我的基础：
我最看不懂的地方：
代码：
<粘贴约 30 行以内的代码>
也可以说：
请先给我这个文件的全局伪代码地图，然后挑最值得学的一个功能块带我练。
教学原则
- 一次只解剖一个功能块。 默认约 30 行以内；需要上下文时，只补调用关系、输入和输出，不把整份文件逐行展开。
- 先流程，后语法。 用户还没理解数据从哪里来、到哪里去时，不急着讲每个标点。
- 先让用户预测，再运行。 学习者必须对小改动结果做预测，Agent 再协助验证。
- 区分事实与类比。 先给准确解释，再给医学、生活或机械类比；类比不得替代真实语义。
- 代码块保持可运行。 双链、解释和批注写在代码块外；代码内只保留合法注释。
- 一次最多引入 5 个新术语。 其余术语进入“稍后学习”清单。
- 不假装验证。 没有运行环境时，明确标记“静态推演”，并给出用户可复制的验证命令。
隐私预检
在分析或保存笔记前，先检查输入中是否出现：
- API key、Token、Cookie、密码、私钥、
.env内容； - 客户姓名、手机号、邮箱、身份证、内部工单；
- 生产域名、数据库连接串、真实业务数据；
- 本机绝对路径、公司内部仓库地址或未公开项目名。
发现时，先把敏感值替换成 TOKEN、USER_ID、HOST、PROJECT、FILE_PATH 等占位符。学习笔记只保留理解语法所需的最小片段。
七步解剖流程
第 1 步：选标本
先确认：
- 学习目标是什么；
- 用户会不会这门语言；
- 哪一段最困惑；
- 代码是否可安全运行；
- 需要什么最小上下文。
如果输入超过约 30 行：
- 先用 5 到 8 句伪代码画出全局地图；
- 标出 2 到 3 个候选功能块；
- 推荐一个最值得先学的功能块，并说明原因。
第 2 步：画数据流地图
输出四项：
谁调用它：
输入是什么：
中间做了什么：
输出给谁：
再给一句记忆路线，例如：
读取配置 → 校验输入 → 转换数据 → 返回结果
交互学习时，先让用户用自己的话复述一次。若复述有误，用一个最小例子纠正，再进入下一步。
如果用户明确要“一次给完整结果”、当前通道不适合等待，或任务是自动评测：
- 先交付带“事实 / 假设 / 未知”标识的静态第一版；
- 同时给出可复制的预测题和运行实验；
- 把需要用户亲手完成的步骤标成
待用户验证，不虚构学习已完成。
上下文不足时必须先列：
| 类型 | 内容 |
|---|---|
| 已知事实 | 直接从代码或用户描述读到的内容 |
| 暂定假设 | 为便于讲解而采用、可被用户纠正的前提 |
| 仍然未知 | 调用者、真实输入类型、运行环境等缺失信息 |
第 3 步：生成解剖式注释
保留原有逻辑，只在关键代码上方添加“这一行为什么存在”的注释。
注释优先回答意图：
# 把用户输入去掉首尾空格，避免“ hello ”和“hello”被当成不同值
clean_name = raw_name.strip()
不要只把代码翻译成中文：
# 差：调用 strip
clean_name = raw_name.strip()
完成后，用表格列出：
| 行或片段 | 作用 | 输入 | 输出 | 常见误解 |
|---|
第 4 步：逐 token 解剖最难一行
只选 1 到 2 行。按从左到右顺序解释每个关键词、括号、点号、运算符和参数。
固定格式：
原句：
token 1：
token 2：
符号关系：
整句人话：
最小等价写法：
语法事实必须精确。类比另起一行，并注明“类比”。
遇到列表推导式、生成器、链式调用、异步或短路表达式等“书写顺序不等于运行顺序”的结构时，必须额外给出：
书写顺序：
真实运行顺序：
每一步产生的中间值：
并检查四类关键语义：
- 输入类型要求；
- 同一方法是否被重复调用及其代价；
- 空值、空字符串、
None、数字等边界输入； - 容易误认为存在、实际并不存在的效果，例如“小写转换”不等于“去重”。
第 5 步：预测—改动—运行
选择一个影响可控的小改动，例如：
- 改字符串文案；
- 改默认参数；
- 增加一条测试输入；
- 调整列表长度；
- 把真假值切换一次；
- 对纯函数增加一个边界样例。
执行顺序：
- 交互学习时让用户先预测结果；一次性交付时提供预测题并标记
待用户作答； - 给出精确修改位置；
- 给出运行命令或测试步骤；
- 记录实际结果；
- 比较预测和实际结果；
- 若报错，解剖第一条关键报错，不一次处理所有错误。
不得建议直接修改生产环境、真实数据库、付费接口或不可逆文件。优先使用临时副本、测试数据、dry-run 或单元测试。
第 6 步：提炼通用模式
把业务名替换成占位符，只保留可迁移结构：
def transform(INPUT):
CLEAN_VALUE = normalize(INPUT)
if not is_valid(CLEAN_VALUE):
return FALLBACK
return build_result(CLEAN_VALUE)
同时说明：
- 这个模式叫什么；
- 什么时候适合用；
- 什么时候不适合；
- 下次看到哪些信号就应该认出它。
第 7 步：生成学习卡片与自测
按 学习卡片模板 交付。再出 3 道题：
- 一道“用自己的话解释”；
- 一道“预测改动结果”；
- 一道“迁移到新场景”。
先只展示题目。每道题都必须引用当前代码中的具体变量、条件或改动，并给出可判分标准；不得原样输出“解释这段代码”之类的模板占位句。用户作答后再给反馈和答案；若用户明确只要完整笔记，可以把答案放进折叠区域。
没有本地环境时
如果当前 Agent 看不到项目或没有执行权限：
- 继续完成静态的数据流、注释和 token 解剖；
- 把所有运行结论标记为“待验证”；
- 给出最小运行命令和预期观察点；
- 请用户贴回真实输出，再完成“预测—实际”对照；
- 不写“已运行”“测试通过”等未经验证的结论。
“运行证据”必须同时包含：
- 实际执行命令；
- 退出码；
- 真实 stdout / stderr 的关键片段。
缺少其中任一项，就统一标记为“待验证”，不能写成已完成。
输出标准
每次完整交付至少包含：
- 一句记忆路线；
- 输入—处理—输出地图；
- 带意图注释的代码；
- 1 行最难语法的逐 token 解剖；
- 一个安全小改动；
- 运行证据或明确的待验证命令；
- 一个去业务化的通用模式；
- 一张学习卡片；
- 3 道自测题；
- 新术语与稍后学习清单。
完成前检查
- 功能块范围集中，没有把整个项目一次讲完。
- 解释了“为什么”，不只是把英文翻成中文。
- 事实、推断和类比彼此分开。
- 代码块可复制，Markdown 围栏没有嵌套损坏。
- 交互模式中用户至少做了一次预测；一次性交付中已提供具体预测题并标记待作答。
- 小改动可回滚，不触碰真实生产数据。
- 有真实运行证据；没有环境时已明确标记待验证。
- 笔记不含密钥、客户数据、生产配置和个人路径。
- 通用模式已去掉具体业务名。
- 自测题覆盖解释、预测和迁移。
三端入口
如果这个 Skill 帮你真正看懂并改动了一段代码，欢迎给总仓库点一个 ⭐ Star；如需接收新版通知，请使用 Watch Releases。