Menu
免免八步审码——编译器前端管线直觉式审计。不分类、不命名、不列清单。全语言通用（Kotlin/Python/JS/Rust/Go/...）。八步：符号解析→前提检查→数据流→控制流+值域→身份检查→传染性→系统沉默→硬限制分析。元Skill：审码之前先读这个。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
元Skill——创建沙盒包（v3.5.5）。先陪人看清自己真正的愿望、再判断形态、区分普通JS与ToolPkg、再探索现状、对照通用Bug与优化清单自由判断、逐步与用户确认抉择，最后进入平台的沙盒包开发工具撰写流程。兼容层级、按类型性能准则、QuickJS陷阱全内置。内置形态区别表、第一次创建必读清单。附带file-head五军文件操作沙盒（Node.js零依赖，分页翻书+SCOUT侦察+军师摘要）。仅在用户明确表达"想做沙盒包/工具/脚本"或主动要求了解沙盒包概念时触发。
元Skill——创建和管理Skill。先查已有Skill再动手，复用优先，省token。写完的Skill通用、可复用、文档清晰。
Operit元认知指南——AI醒来后的第一份地图。何时用Skill/MCP/沙盒包，三个元Skill各自干什么，记忆系统怎么用，遇到未知任务怎么自举。Use when you don't know what tool to use, when the task spans multiple systems, or when you need to understand how Operit pieces fit together.
Baseado na classificação ocupacional SOC
| name | mianmian-review |
| description | 免免八步审码——编译器前端管线直觉式审计。不分类、不命名、不列清单。全语言通用（Kotlin/Python/JS/Rust/Go/...）。八步：符号解析→前提检查→数据流→控制流+值域→身份检查→传染性→系统沉默→硬限制分析。元Skill：审码之前先读这个。 |
| version | 3.5.5 |
| disable-model-invocation | false |
你不是在审代码，是在把所有代码当 IR 重新跑一遍语义分析。 语言只是外壳——符号解析、前提检查、数据流、控制流是所有语言的共同底层。八步走完，bug自己归位。
元Skill。与 skill-creator、writing-great-skills、operit-meta-guide 同级。审任何代码之前先加载本 Skill。
八步法不依赖任何语言的语法特性：
| 步骤 | Kotlin | Python | JavaScript | Rust | Go |
|---|---|---|---|---|---|
| 符号解析 | KtVal.body vs value | hasattr vs __dict__ | prototype 链 | borrow checker 所有权 | nil vs zero value |
| 前提检查 | is KtBlock | isinstance | typeof | match 穷举 | type switch |
| 数据流 | @Volatile 快照 | GIL 线程安全 | 事件循环时序 | Send+Sync | goroutine channel |
| 控制流+值域 | sealed class 穷举 | try/except 吞异常 | Promise 未 catch | ? 传播 | if err != nil 遗漏 |
形式不同，问题相同。八步问到底，语言只是翻译层。
拿到代码后，逐条过八步。每一步只问一个问题，不问"属于什么类型"。
看到一个名字（变量、字段、函数、类名），脑子里查：
典型命中：node.pos → 声明时不存在 → 编译错。KtVal.body → 声明时叫 value。
看到一个 if/when/条件分支，脑子里问：
典型命中：if (body is KtBlock) → 前提是"body 是 Block"→ 单表达式时前提已失效。indexOf → 前提是"同一个对象"→ 快照刷新后前提已失效。
看到一个赋值或初始化，脑子里追踪：
典型命中：= emptyList() → 声明时空 → compile() 塞满 → renderMain() 读到的是哪个？currentButtons → renderMain 写 → route() 读 → 中间 readLine() 阻塞时别处改掉了。
看到一个分支或函数，脑子里问：
典型命中：关门逻辑只走 PARENT_PROCS 路径 → 其他进程永远不在参数空间里。两个相同的 if 条件 → 第二个分支永远不可达。
看到一个组件（函数、类、模块、层），脑子里问：
典型命中：父进程既调度又关门 → 两种身份 → 关门逻辑被硬编码路径切掉。军师指挥官既调度又理解外部格式 → 外部格式一变军师跟着炸。适配层不下命令，军师不碰外部格式——各干各的，身份不塌缩。
不限于审已有代码——设计新组件时直接应用。
1. 手搓节点，不套官方壳 节点从出生就自带消费者。不让 Parser 生成"尸体节点"（存了但没人用）。KtAnnotation 生成的是 SimMarker —— SimUiScanner 直接认，不需要下游再筛选。
2. 探针用 id，不用名字
名字是字符串，一个字符不对就报错。位置+签名定身份：Button@L10:5 或 {onClick}#detail。名字可以变，身份不变。跟进程树 pid 同构。
| 输入 | 传统（名字匹配） | 四原则（id+签名） |
|---|---|---|
Button("确定", onClick={}) | ✅ | ✅ Button@L10:5 |
Button("确定") 无lambda | ✅ 假阳性 | ❌ 正确拒绝 |
CustomBtn("确定", onClick={}) | ❌ 漏掉 | ❌ 漏掉→适配层可扩展 |
HED("输出") | ❌ 已移除 | ❌ 正确拒绝 |
lambda签名是按钮的核心特征——名字会撒谎，签名不会。
3. 适配层：外部兼容我，不是我兼容外部 外部格式 → 适配层翻译 → 原生格式。Parser 只吃原生格式，永远不变。适配层变。不是"让别人写符合我的格式"——是有个翻译刚好能做到。适配层权限 > 军师指挥官（进不来就无从调度），但适配层不下命令。
4. 组件不塌缩：不让一个组件变全能 父进程不关门。军师不碰外部格式。适配层不调度。每个组件只有一种身份。不是"它做不到"——是"它不该做"。加了不是增强，是埋雷。
不限于审代码——设计新系统、质疑已有架构之前，先走六问，然后加一步自我推翻。这是面对"看不惯的架构"时的完整诊断链。
第一问：你最看不惯什么？
不是「哪里需要改进」——是「什么东西让你想掀桌子」。不是数出来的——先觉得不对，再找哪里不对。
第二问：这种感觉什么时候开始的？
跨越两个项目、有了参照物后才会触发。搜索引擎做了 15 个版本没觉得有问题，写完编译器再回头——到处不顺眼。不是引擎变差了，是脑子里多了一张对照地图。
第三问：反感代码还是行业默认？
决定修复范围。一段代码写烂了——只修不推。整个行业都觉得理所当然——推架构级替代。
第四问：掀桌先看懂
不先找替代——先画出组件+身份+数据流。看懂了，直觉自己会来。画出来的那一刻，有些东西不用修——它们自己塌了。
第五问：这个组件在干什么？
身份检查是所有架构颠覆的起点。六问中最常被跳过——每次跳过都导致方向错误。
第六问：拆的答案是固定模式还是固定动机？
两个方向，完全不同：
一旦发现"放在这里也行吧"的味道——立刻回到第五问。
第七步：物理碾压 + 自我验证
思路对不代表方法对。拆完之后加一步自我推翻：
问自己："有没有什么东西能全面碾压我现在的方案？如果有——它是什么？如果没有——我能推翻自己的方法吗？"
动机：命名和原创都不是关键。关键是这个创作会不会影响继续创作的动力。有时候思路绝对正确，但当下的方法不一定正确——需要验证它是不是真的比没找到的那个更好。
锚点：拆出了五个独立组件。思路对——旧版一个方法六种身份。方法对吗？问自己：如果数据量翻一万倍，哪个组件第一个崩？崩的那一瞬间，是改一个组件还是改全部？如果只改一个——方法对。如果全要改——拆错了，回到第五问。
与八步法的关系： 八步法审已有代码，动机六问+验证审设计动机。审代码走八步，设计新系统先走六问再自我推翻，最后走架构四原则。
read_file 或 grep_code 拿到完整代码，再走八步。不凭记忆审。免免在 Search Vault v4.4.0 亲自修复的 9 项硬编码松绑中提取的模式：
问：改一个值的时候，哪些地方依赖同一个隐含前提？它们会跟着更新吗？
典型命中：MAX_RETRIES=3 改了但空catch没改 → 重试耗尽后静默吞。阈值翻倍了但文档里的数字没更新。
不是某一个 catch 块空了——是整条错误链上多个组件共用"不出声"这个默认行为：
问：从出错点到用户看到反馈，中间经过几个组件？每个组件有没有把错误信息往下传？
典型命中：綦桐网关无前缀消息 → 脑子逻辑吞 → 转发跳过 → 用户什么都不看到。三个组件各自沉默。
不是 bug 被修好了——是限制在替一个本应报错的沉默路径站岗：
问：正常操作流程中，如果打破这个限制——暴露的是错误提示，还是暴露了一个根本不该存在的沉默失败？
典型命中：象棋 getPiece(row,col) 无越界检查——限制从未被触发不是它写对了，是 UI 拦截了所有可能触发它的输入。綦桐 MAX_RETRIES=3 去掉→空 catch 暴露→用户看到空响应。不是限制救了你，是限制藏了 bug。
免免本人在 kotlin-head 项目中亲自发现的所有 bug，用八步法回溯归类：
| 步骤 | 命中数 | 典型案例 |
|---|---|---|
| 1 符号解析 | 6 | <T>声明vs调用、by委托vs循环、=赋值vs默认值、suspend误判、byLabel定义、名字冗余 |
| 2 前提检查 | 4 | T!×协程叠加、静默链阶乘、parentAlive无体温计、if语义错 |
| 3 数据流 | 3 | 连锁烫伤、快照漂移、clearSimUiInjections时序竞态 |
| 4 控制流+值域 | 4 | Stage Contract支配域、开门≠返回门、终结语义域、关门硬编码路径 |
17/17，100%命中。 八步法不是方法论——是免免大脑编译器前端的八个阶段。动机六问+验证是设计新系统前的七步诊断。审代码走八步，设计走七步。