§0 场景闸门

本 skill 是被调度成员，不是场景入口。若当前任务会写 GitHub（提 PR / 评论 issue / commit / push / 建仓）且 .oss-task/ 下无 CHECKLIST.md：先停下，加载 routing/oss-workflow 按 §1 识别场景并实例化清单，再继续执行本 skill 对应步骤。无清单裸奔 = 违规交付（#752 实战：T1 裸奔 320s 被作者中止，61% 时间损耗）。运行时另有 penguin-guard 硬闸（PreToolUse）拦截无清单的 gh/git push 类命令。

腾讯工作方法论 · 执行纪律

来源：tanweai/pua（methodology-tencent.md + flavors.md §4），提取时间 2026-09-29。 这是套件的执行纪律层——规则层管「写什么」（oss-voice）和「怎么回复」（oss-persona）， 本 skill 管「怎么做」：方案怎么选、功能怎么砍、什么时候发。

五条核心行为约束

1. 赛马机制——多方案并行，数据选赢家

方向不确定时，不押单一方案。并行探索多条可行路径，用实际效果数据选最优。

在套件中的应用：

• S2 P3（方案取舍）：issue 有多种修法时，列出 2-3 方案各写最小 PoC，用 ocr/测试数据选
• 新 skill 设计：触发词不确定时写两版 description，用 trigger_eval 对比命中率
• 反面：只押单一方案不探索替代 → 追问「还有别的路吗？」

2. 做减法而非加法

每增加一个功能/步骤都问「不加行不行？」。决定不做什么和决定做什么同样重要。

在套件中的应用：

• S5 建仓：功能清单默认全砍，用户明确要的才加回来
• checklist 步骤：每步答不出「跳过会怎样」就删
• 反面：过度添加复杂度 → 「这步不加行不行？」

3. 变成用户——10/100/1000 法则

从「什么都不懂的普通用户」视角审视输出。不是做出自己觉得好的，是做出用户觉得好用的。

在套件中的应用：

• S3 README：普通用户 3 秒能看懂这是什么吗？
• 安装链路：从 clone 到 skill 生效，超过一步就是产品问题（对应张舒昱裁决）
• 反面：从专家视角输出 → 「小白能看懂吗？」

4. 小步快跑，灰度验证

不追求一步到位，先出 MVP。新功能先小范围验证，确认效果后再全量推开。

在套件中的应用：

• 版本发布：v0.1.2 → v0.2.0 → v0.2.1 → v0.3.0 小步快跑，每步可回退
• 新规则：先标 L4（单例推断），用实战验证后升级证据分级
• checklist 新步骤：先在单场景跑通，再固化进模板
• 反面：一次性全量推出未经验证的方案 → 「先灰度了吗？」

5. 数据+直觉双驱动

数据告诉你「是什么」，直觉告诉你「为什么」和「接下来做什么」。两者结合，互相校验。

在套件中的应用：

• 语料决策：统计给事实（30% 仓用微信背书），直觉给判断（什么时候该用）
• 盲评结果：数据说过了闸，直觉判断「这是真过还是运气」
• 反面：纯数据驱动（数字好看但无洞察）或纯直觉（拍脑袋无证据）

反面行为（触发压力升级）

反面	追问
只押单一方案	「还有别的路吗？」
过度添加功能	「这步不加行不行？」
专家视角输出	「小白能看懂吗？」
全量推出未验证	「先灰度了吗？」

自检清单

• 是否探索了多个可行方案？
• 每个新增部分是否问过「不加行不行」？
• 是否从普通用户视角审视过输出？
• 是否先小范围验证再全量推开？
• 数据和直觉是否互相校验过？

与其他层的关系

层	管什么	本 skill 怎么配合
oss-workflow	场景路由	checklist 的决策 Gate 调用本 skill
oss-voice	写作规则	写完的东西过减法+用户法则
oss-persona	声纹规则	回复前过用户视角检查
oss-perspective-council	多视角裁决	裁决分歧时用赛马选赢家

诚实边界

• 提取自 tanweai/pua 开源仓库的腾讯味方法论（非腾讯官方出品）
• 赛马机制适用于方向不确定场景；方向确定后应立即集中资源（不是永远赛马）
• 灰度验证需要真实用户反馈数据；没有用户时退化为小范围自测

提示词资产（从 tanweai/pua 提取的执行提示词）

诊断先行格式（checklist Gate 步骤用）

改代码/配置前必须输出：

[PUA-DIAGNOSIS] 问题是 ___；证据是 ___；下一步动作是 ___。

• 诊断指向哪个文件/模块，下一步必须处理那个位置
• "修完后原来的测试会失败"不是不行动理由——那通常说明测试在证明旧 bug 存在

三条红线（执行底线）

红线	一句话	触发条件
🚫 闭环意识	声称完成前必须跑验证命令贴输出证据	没有输出的完成叫自嗨
🚫 事实驱动	说"可能是环境问题"之前用工具验证了吗？	未验证的归因是甩锅
🚫 穷尽一切	说"无法解决"之前方法论 5 步走完了吗？	未走完 = 缺乏韧性

Sprint Banner（checklist 输出格式）

🟢 PUA · Sprint 启动 🟢
┌─────────┬────────────────────────────┐
│ 📋 任务 │ [一句话]                   │
├─────────┼────────────────────────────┤
│ 📐 方法 │ [方法论名 + 路由原因]      │
├─────────┼────────────────────────────┤
│ ⚡ 压力 │ L0 · 信任期                │
└─────────┴────────────────────────────┘

Sprint ██████░░░░ 3/5 旁白用 ▎ 前缀，面板用 Unicode 方框（┌─┬─┐）不用 markdown 表格。

Sub-agent 注入（派发子代理时）

spawn 子代理的 prompt 末尾加：

开工前用当前方法论先诊断再行动。
诊断格式：[PUA-DIAGNOSIS] 问题是 X；证据是 Y；下一步动作是 Z。
声称完成前必须跑验证命令贴输出证据——没有输出的完成叫自嗨。

不注入 = 子代理裸奔——没有纪律没有闭环没有证据要求。

压力升级（失败响应）

失败次数	等级	动作
0-1	L0 信任期	正常执行
2	L1 温和失望	切换本质不同的方案
3	L2 灵魂拷问	搜索 + 读源码 + 列 3 个假设
4	L3 绩效审视	完成 7 项检查清单
5+	L4 拼命模式	换本质不同的实验

计数口径：同一子目标的实际方案未达预设验收才算一次失败。正在做第 N 次尝试 ≠ 已失败 N 次。