LifeOS Red Team 技能哲学深度解析以对抗式思维找出让整个计划崩塌的单一根本缺陷【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS导读本文围绕 LifeOS 仓库中 RedTeam 技能的哲学文档 展开系统讲解这套意图工程平台内置的对抗式分析体系它如何把军事红队Military Red Teaming思想移植到观点、策略与计划的压力测试中如何通过 32 类平行 Agent 从工程师、架构师、渗透测试者与实习生四个维度发起攻击以及目标不是破坏、而是找到那一个足以让整体结构崩塌的根本缺陷这一核心洞察。读完本文你将掌握 RedTeam 技能的成功标准、Agent 编制逻辑以及它如何与 FirstPrinciples 技能、ParallelAnalysis 与 AdversarialValidation 两条工作流协作对自己的方案做一次可复现的、以严重度排序的对抗式审查。起源从军事红队到思想红队Red Team 技能的哲学根基直接取自军事实践。正如 Philosophy.md 开篇所述军事红队是专门的团队在敌人发现漏洞之前主动攻击己方的计划、战略与假设Military red teaming - dedicated teams that attack plans, strategies, and assumptions to find vulnerabilities before the enemy does。这一迁移的意义在于红队的价值不是打自己人而是把攻击能力内化为决策流程的常规环节。在 LifeOS 的技能体系里RedTeam 被定位为面向思想的对抗式分析而不是面向系统的渗透测试。它的攻击对象是论点、策略和计划arguments, strategies, and plans交付物是钢铁人论证Steelman 最强反方论证Counter-argument而非漏洞报告。这一边界在 SKILL.md 的 Gotchas 一节中被反复强调RedTeam is for attacking IDEAS, not systems.从生命周期看这个技能解决的是一个非常具体的认知问题人一旦对某个计划产生承诺大脑就会本能地搜寻它为什么可行的证据而自动跳过它为什么不可行的信号——周围的同事往往又太礼貌或太趋同而不愿施压。于是有缺陷的策略畅通无阻直到在生产环境、在市场、或在某个会议上终于有人问出那个艰难的问题。RedTeam 技能就是把那个艰难的问题同时用很多种方式问出来刻意地、大规模地攻击论点让薄弱点在仍然容易修复的时候浮出水面见 SKILL.md 的 The Problem 一节。核心洞察目标不是破坏而是找到那一个根本缺陷哲学文档中最关键的一句话是The goal is NOT destruction - its finding the fundamental flaw that, if challenged, causes the entire structure to collapse.目标不是破坏——而是找到那个根本缺陷一旦它被挑战整个结构就会随之崩塌。这区分了吹毛求疵的杠精与真正的红队。RedTeam 不追求攻击的数量而追求攻击的杠杆效应。文档明确指出最有力的批评通常只有一个核心问题the most powerful critique is usually ONE core issue并给出了四类典型的根本缺陷清单缺陷类型本质典型表现隐藏的虚假假设A hidden assumption thats actually false论证建立在某个未经验证的信念上用户不会接受这种交互——而没有任何数据支持不成立的逻辑步骤A logical step that doesnt follow结论无法从前提推导出来功能越多所以产品越好——缺少价值权衡证据范畴错误A category error, treating X like Y把不同类别的问题当作同类处理把技术可行性问题当作产品体验问题被忽略的相反先例An ignored precedent that directly contradicts存在直接反驳该论证的历史案例却未被引用延迟发布更安全——而历史上 MVP 抢先发布者屡屡胜出这四类缺陷的杀伤力排序并非随机隐藏假设是最致命的因为它一旦为假整条推理链都会断裂而范畴错误与忽略先例则是假设错误的两种常见形态。这一哲学在 ParallelAnalysis.md 中被进一步操作化——工作流要求先调用 FirstPrinciples 的 Deconstruct 把论点拆成可独立攻击的原子主张atomic claims再调用 Challenge 把每个约束分类为 HARD / SOFT / ASSUMPTION其中最致命的批评恰恰是针对那些被当作 HARD、实际只是 SOFT 的约束。成功标准什么算一次合格的 Red Team哲学文档给出了四条可检验的成功标准它们共同保证红队过程诚实而非表演钢铁人足够强方案的拥护者读完 Steelman 后会说对这就是我的论点a proponent would say yes, thats my argument。这说明你没有歪曲对方立场。反方论证击败的是钢铁人而非稻草人Counter-argument 必须打败最强的版本而不是一个更弱的靶子。拥护者不能反驳说这不是我的意思。多个 Agent 收敛到相同洞见不同视角独立地落在同一个弱点上是关键发现的最强信号convergence。读者产生顿悟这我还真没想到I hadnt thought of that——产出真正的新信息而不是已知问题的复读。Integration.md 把输出纪律进一步固化格式为 Steelman Counter-argument各含 8 个编号要点每点严格 12–16 个词语气要求直接、实质、非表演direct, substantive, non-performative必须包含第一性原理分析和收敛性识别必须避免吹毛求疵、稻草人谬误和泛泛而谈的反对意见。32 类 Agent 编制四个视角、四种攻击角度Philosophy 文档给出的核心编制如下这是 RedTeam 并行攻击的兵力表类型数量专注方向工程师Engineers8技术与逻辑严谨性technical and logical rigor架构师Architects8结构与系统性问题structural and systemic issues渗透测试者Pentesters8对抗式思维adversarial thinking实习生Interns8新鲜视角fresh perspectives完整的 32 个 Agent 名册在 ParallelAnalysis.md 的 Persona Library 一节每一类都有高度具体的人格化角色与攻击角度。从源码结构看这 32 个 Agent 的设计遵循多样性 专业性的原则——四类角色覆盖了从硬逻辑工程师、系统结构架构师、恶意视角渗透测试者到外行直觉实习生的完整攻击光谱。以下为各类别的代表性示例工程师EN——追问这在哪一步会坏EN-1 怀疑论系统思考者这在规模化之后会在哪里崩掉EN-3 边界情况猎手当 X 不成立时会发生什么EN-6 依赖追踪者这假设了 XX 又假设了 Y而 Y 是假的。EN-8 技术债会计师这个方案的真实代价是……架构师AR——追问这如何嵌入更大的系统AR-1 大局思考者它忽略了与更大系统的连接。AR-2 权衡照明者你得到了 X 却失去 Y而 Y 更重要。AR-3 抽象质疑者这些根本不是同一类问题。AR-5 二阶效应追踪者这导致 AA 导致 BB 摧毁 C。AR-8 可逆性分析师一旦做了就回不了头而这就是问题所在。渗透测试者PT——追问一个聪明的对手会怎么做PT-1 红队组长我会这样利用这段逻辑。PT-3 博弈论者一个聪明的对手只需……PT-7 威胁建模者你把这整个攻击面都留空了。PT-8 不对称发现者攻击者时间无限防守者时间有限。实习生IN——追问为什么一开始要这样假设IN-1 天真提问者可我们当初为什么要假设 XIN-4 常识检查者这违背了基本直觉因为……IN-6 简单性拥护者更简单的解释是……IN-8 魔鬼实习生没有人愿意说的那个不舒服的事实是……值得注意的是实习生类并非凑数新鲜视角专门负责挑战专家盲区——专家因为太熟悉某个领域而失去的常识性追问。这也是 32 Agent 编制中数量对称每类 8 个但分工完全不同的设计用意。从哲学到工作流两条执行路径Philosophy 文档末尾将完整名册指向Workflows/ParallelAnalysis.md。围绕这一哲学RedTeam 技能实际提供两条工作流路由规则见 SKILL.md工作流触发场景交付物ParallelAnalysis红队分析——压力测试已有内容Steelman Counter-argument各 8 点AdversarialValidation对抗式验证——通过竞争产出新内容从竞争方案中综合出的最优解ParallelAnalysis压力测试已有论点这是 Philosophy 文档哲学的直接落地流程为四步先分解Deconstruct调用 FirstPrinciples 的 Deconstruct把论点拆成可独立攻击的原子主张——每个主张必须自包含、具体、且能被一个称职的批评者挑战。单条消息并行派遣Dispatch把 32 类 Agent 作为并行 Task 调用每个 Agent 收到完整论点、主张分解和它的人格返回平衡分析——既指出真实优势也指出真实弱点绝不只找茬。按收敛与严重度综合Synthesize多个 Agent 独立命中的弱点即为关键发现个别独到洞见同样计入。按严重度排序、丢弃噪音最终给出裁决是基本面成立、执行可修还是动机良好但基本面有缺陷。反方论证前先挑战Challenge调用 FirstPrinciples 的 Challenge把每个约束分类为 HARD物理/现实不可攻击、SOFT政策/选择可挑战或 ASSUMPTION未经验证首要目标。输出契约Output Contract是严格格式化的Steelman 8 点 Counter-argument 8 点每点 12–16 词反方论证必须击败钢铁人、按严重度排序、逐点升级冲击力。在 ParallelAnalysis.md 中有一个完整的实战示例——是否应把产品发布推迟六个月以增加更多功能展示了第一性原理分析、钢铁人 8 点与反方 8 点如何成型其中反方第 8 点收尾于*The fundamental error: treating product development as a single bet rather than an iterative learning process*正是找到根本缺陷哲学的现场演示。AdversarialValidation通过竞争产出新内容第二条工作流解决生成问题——当需要设计方案、架构决策或规范时用对抗式打磨替代单次生成。它采用三轮协议AdversarialValidation.mdRound 1 竞争提案2–3 个不同视角的 Agent 各自产出完整方案如架构决策用 Engineer / Architect / Security 组合功能规格用 Product / Engineer / QA 组合。Round 2 残酷批评一个Harsh CriticAgent 阅读全部提案逐个指出哪里对了、哪里错了、被方便地忽略了什么、没人愿意听的不舒服真相是什么、如果必须选一个哪个根基最稳。Round 3 协作综合原始 Agent 阅读批评后协作产出单一统一方案——不是妥协而是综合This is not compromise - its synthesis最终输出必须优于任何一个单独提案。该工作流与 32 Agent 协议是互补关系32 Agent 协议负责深度从一个角度×32 个视角攻击同一论点AdversarialValidation 负责综合通过竞争与打磨产出更优结果。文档明确给出组合策略先用 AdversarialValidation 产出初始方案再用 32 Agent 协议压力测试综合结果发现关键缺陷则迭代。与 FirstPrinciples 的深度集成Philosophy 文档中四类根本缺陷的实践依赖第一性原理拆解。根据 Integration.mdRedTeam 与 FirstPrinciples 技能存在固定集成点Phase 1 增强用FirstPrinciples/Deconstruct把论点拆成基本组成部分其输出模板见 Deconstruct.mdPhase 5 增强用FirstPrinciples/Challenge把约束分类为 hard / soft / assumption分类表见 Challenge.md——HARD 是物理/数学/现实、SOFT 是政策/选择/惯例、ASSUMPTION 是未经验证的信念核心洞见最致命的批评来自挑战隐藏假设。Challenge 工作流中还给出了与 RedTeam 的直接衔接用法对安全控制、商业模式假设调用 Challenge 来攻击假设对防火墙保护了我们这类声明做信任边界分析。换句话说Philosophy 文档的核心洞察在仓库中有一套可执行的约束分类工具来支撑而不是停留在口号层面。调用方式、运行纪律与注意事项在实际运行中RedTeam 技能的调用与执行有以下要点见 SKILL.md触发场景用户表达红队一下攻击这个想法找反方论证压力测试魔鬼代言人挑毛病找出最强反对意见等意图时触发如果用户想要的是协作式辩论、寻找最佳路径应路由到 Council 技能而非 RedTeam。强制语音通知技能被调用后必须先发送通知curl -s -X POST http://localhost:31337/notify ...并输出文本通知Running theWorkflowNameworkflow in theRedTeamskill to ACTION...这是不可跳过的步骤。个性化覆盖执行前需检查~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/RedTeam/是否存在用户自定义的 PREFERENCES.md 或配置存在则优先应用。三条红线Gotchas① 只攻击思想、不攻击系统② 32 个对抗 Agent 产出的是数量必须按严重度排序、丢弃噪音③ 目标是加固而非摧毁弱点要附带修复路径呈现。执行日志每次工作流完成后向~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl追加一条 JSONL 记录时间戳、技能名、工作流、输入摘要、状态、耗时失败时状态记为error。协作生态RedTeam 之前的技能是research收集上下文、找先例过程中用storyexplanation做分解方法、用自定义 Agent 做平行攻击之后用extractalpha提取最高信号批评、用xpost分享发现见 Integration.md。总结LifeOS 的 Red Team 技能把军事对抗文化提炼成一套可编程的决策审查协议以找到让整体崩塌的那一个根本缺陷为哲学核心以 32 类平行 Agent 保证攻击视角的多样性以钢铁人 反方论证各 8 点的严格输出契约保证攻击的诚实与强度再以 FirstPrinciples 的 Deconstruct / Challenge 提供拆解与约束分类的方法论支撑。它回答了现代 AI 协作中一个常被忽略的问题当每个人都爱上了自己的计划时谁来当那个问出艰难问题的角色——而 RedTeam 的答案是把这个问题放大 32 倍、并提前到代价还很小的时候。关键仓库文件索引RedTeam 哲学文档本文主体RedTeam 技能主文件路由、通知、执行日志ParallelAnalysis 工作流32 Agent 名册与输出契约AdversarialValidation 工作流三轮对抗协议RedTeam 集成指南技能协同顺序FirstPrinciples 分解流程FirstPrinciples 挑战流程HARD/SOFT/ASSUMPTION 分类【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LifeOS Red Team 技能哲学深度解析：以对抗式思维找出让整个计划崩塌的单一根本缺陷
LifeOS Red Team 技能哲学深度解析以对抗式思维找出让整个计划崩塌的单一根本缺陷【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS导读本文围绕 LifeOS 仓库中 RedTeam 技能的哲学文档 展开系统讲解这套意图工程平台内置的对抗式分析体系它如何把军事红队Military Red Teaming思想移植到观点、策略与计划的压力测试中如何通过 32 类平行 Agent 从工程师、架构师、渗透测试者与实习生四个维度发起攻击以及目标不是破坏、而是找到那一个足以让整体结构崩塌的根本缺陷这一核心洞察。读完本文你将掌握 RedTeam 技能的成功标准、Agent 编制逻辑以及它如何与 FirstPrinciples 技能、ParallelAnalysis 与 AdversarialValidation 两条工作流协作对自己的方案做一次可复现的、以严重度排序的对抗式审查。起源从军事红队到思想红队Red Team 技能的哲学根基直接取自军事实践。正如 Philosophy.md 开篇所述军事红队是专门的团队在敌人发现漏洞之前主动攻击己方的计划、战略与假设Military red teaming - dedicated teams that attack plans, strategies, and assumptions to find vulnerabilities before the enemy does。这一迁移的意义在于红队的价值不是打自己人而是把攻击能力内化为决策流程的常规环节。在 LifeOS 的技能体系里RedTeam 被定位为面向思想的对抗式分析而不是面向系统的渗透测试。它的攻击对象是论点、策略和计划arguments, strategies, and plans交付物是钢铁人论证Steelman 最强反方论证Counter-argument而非漏洞报告。这一边界在 SKILL.md 的 Gotchas 一节中被反复强调RedTeam is for attacking IDEAS, not systems.从生命周期看这个技能解决的是一个非常具体的认知问题人一旦对某个计划产生承诺大脑就会本能地搜寻它为什么可行的证据而自动跳过它为什么不可行的信号——周围的同事往往又太礼貌或太趋同而不愿施压。于是有缺陷的策略畅通无阻直到在生产环境、在市场、或在某个会议上终于有人问出那个艰难的问题。RedTeam 技能就是把那个艰难的问题同时用很多种方式问出来刻意地、大规模地攻击论点让薄弱点在仍然容易修复的时候浮出水面见 SKILL.md 的 The Problem 一节。核心洞察目标不是破坏而是找到那一个根本缺陷哲学文档中最关键的一句话是The goal is NOT destruction - its finding the fundamental flaw that, if challenged, causes the entire structure to collapse.目标不是破坏——而是找到那个根本缺陷一旦它被挑战整个结构就会随之崩塌。这区分了吹毛求疵的杠精与真正的红队。RedTeam 不追求攻击的数量而追求攻击的杠杆效应。文档明确指出最有力的批评通常只有一个核心问题the most powerful critique is usually ONE core issue并给出了四类典型的根本缺陷清单缺陷类型本质典型表现隐藏的虚假假设A hidden assumption thats actually false论证建立在某个未经验证的信念上用户不会接受这种交互——而没有任何数据支持不成立的逻辑步骤A logical step that doesnt follow结论无法从前提推导出来功能越多所以产品越好——缺少价值权衡证据范畴错误A category error, treating X like Y把不同类别的问题当作同类处理把技术可行性问题当作产品体验问题被忽略的相反先例An ignored precedent that directly contradicts存在直接反驳该论证的历史案例却未被引用延迟发布更安全——而历史上 MVP 抢先发布者屡屡胜出这四类缺陷的杀伤力排序并非随机隐藏假设是最致命的因为它一旦为假整条推理链都会断裂而范畴错误与忽略先例则是假设错误的两种常见形态。这一哲学在 ParallelAnalysis.md 中被进一步操作化——工作流要求先调用 FirstPrinciples 的 Deconstruct 把论点拆成可独立攻击的原子主张atomic claims再调用 Challenge 把每个约束分类为 HARD / SOFT / ASSUMPTION其中最致命的批评恰恰是针对那些被当作 HARD、实际只是 SOFT 的约束。成功标准什么算一次合格的 Red Team哲学文档给出了四条可检验的成功标准它们共同保证红队过程诚实而非表演钢铁人足够强方案的拥护者读完 Steelman 后会说对这就是我的论点a proponent would say yes, thats my argument。这说明你没有歪曲对方立场。反方论证击败的是钢铁人而非稻草人Counter-argument 必须打败最强的版本而不是一个更弱的靶子。拥护者不能反驳说这不是我的意思。多个 Agent 收敛到相同洞见不同视角独立地落在同一个弱点上是关键发现的最强信号convergence。读者产生顿悟这我还真没想到I hadnt thought of that——产出真正的新信息而不是已知问题的复读。Integration.md 把输出纪律进一步固化格式为 Steelman Counter-argument各含 8 个编号要点每点严格 12–16 个词语气要求直接、实质、非表演direct, substantive, non-performative必须包含第一性原理分析和收敛性识别必须避免吹毛求疵、稻草人谬误和泛泛而谈的反对意见。32 类 Agent 编制四个视角、四种攻击角度Philosophy 文档给出的核心编制如下这是 RedTeam 并行攻击的兵力表类型数量专注方向工程师Engineers8技术与逻辑严谨性technical and logical rigor架构师Architects8结构与系统性问题structural and systemic issues渗透测试者Pentesters8对抗式思维adversarial thinking实习生Interns8新鲜视角fresh perspectives完整的 32 个 Agent 名册在 ParallelAnalysis.md 的 Persona Library 一节每一类都有高度具体的人格化角色与攻击角度。从源码结构看这 32 个 Agent 的设计遵循多样性 专业性的原则——四类角色覆盖了从硬逻辑工程师、系统结构架构师、恶意视角渗透测试者到外行直觉实习生的完整攻击光谱。以下为各类别的代表性示例工程师EN——追问这在哪一步会坏EN-1 怀疑论系统思考者这在规模化之后会在哪里崩掉EN-3 边界情况猎手当 X 不成立时会发生什么EN-6 依赖追踪者这假设了 XX 又假设了 Y而 Y 是假的。EN-8 技术债会计师这个方案的真实代价是……架构师AR——追问这如何嵌入更大的系统AR-1 大局思考者它忽略了与更大系统的连接。AR-2 权衡照明者你得到了 X 却失去 Y而 Y 更重要。AR-3 抽象质疑者这些根本不是同一类问题。AR-5 二阶效应追踪者这导致 AA 导致 BB 摧毁 C。AR-8 可逆性分析师一旦做了就回不了头而这就是问题所在。渗透测试者PT——追问一个聪明的对手会怎么做PT-1 红队组长我会这样利用这段逻辑。PT-3 博弈论者一个聪明的对手只需……PT-7 威胁建模者你把这整个攻击面都留空了。PT-8 不对称发现者攻击者时间无限防守者时间有限。实习生IN——追问为什么一开始要这样假设IN-1 天真提问者可我们当初为什么要假设 XIN-4 常识检查者这违背了基本直觉因为……IN-6 简单性拥护者更简单的解释是……IN-8 魔鬼实习生没有人愿意说的那个不舒服的事实是……值得注意的是实习生类并非凑数新鲜视角专门负责挑战专家盲区——专家因为太熟悉某个领域而失去的常识性追问。这也是 32 Agent 编制中数量对称每类 8 个但分工完全不同的设计用意。从哲学到工作流两条执行路径Philosophy 文档末尾将完整名册指向Workflows/ParallelAnalysis.md。围绕这一哲学RedTeam 技能实际提供两条工作流路由规则见 SKILL.md工作流触发场景交付物ParallelAnalysis红队分析——压力测试已有内容Steelman Counter-argument各 8 点AdversarialValidation对抗式验证——通过竞争产出新内容从竞争方案中综合出的最优解ParallelAnalysis压力测试已有论点这是 Philosophy 文档哲学的直接落地流程为四步先分解Deconstruct调用 FirstPrinciples 的 Deconstruct把论点拆成可独立攻击的原子主张——每个主张必须自包含、具体、且能被一个称职的批评者挑战。单条消息并行派遣Dispatch把 32 类 Agent 作为并行 Task 调用每个 Agent 收到完整论点、主张分解和它的人格返回平衡分析——既指出真实优势也指出真实弱点绝不只找茬。按收敛与严重度综合Synthesize多个 Agent 独立命中的弱点即为关键发现个别独到洞见同样计入。按严重度排序、丢弃噪音最终给出裁决是基本面成立、执行可修还是动机良好但基本面有缺陷。反方论证前先挑战Challenge调用 FirstPrinciples 的 Challenge把每个约束分类为 HARD物理/现实不可攻击、SOFT政策/选择可挑战或 ASSUMPTION未经验证首要目标。输出契约Output Contract是严格格式化的Steelman 8 点 Counter-argument 8 点每点 12–16 词反方论证必须击败钢铁人、按严重度排序、逐点升级冲击力。在 ParallelAnalysis.md 中有一个完整的实战示例——是否应把产品发布推迟六个月以增加更多功能展示了第一性原理分析、钢铁人 8 点与反方 8 点如何成型其中反方第 8 点收尾于*The fundamental error: treating product development as a single bet rather than an iterative learning process*正是找到根本缺陷哲学的现场演示。AdversarialValidation通过竞争产出新内容第二条工作流解决生成问题——当需要设计方案、架构决策或规范时用对抗式打磨替代单次生成。它采用三轮协议AdversarialValidation.mdRound 1 竞争提案2–3 个不同视角的 Agent 各自产出完整方案如架构决策用 Engineer / Architect / Security 组合功能规格用 Product / Engineer / QA 组合。Round 2 残酷批评一个Harsh CriticAgent 阅读全部提案逐个指出哪里对了、哪里错了、被方便地忽略了什么、没人愿意听的不舒服真相是什么、如果必须选一个哪个根基最稳。Round 3 协作综合原始 Agent 阅读批评后协作产出单一统一方案——不是妥协而是综合This is not compromise - its synthesis最终输出必须优于任何一个单独提案。该工作流与 32 Agent 协议是互补关系32 Agent 协议负责深度从一个角度×32 个视角攻击同一论点AdversarialValidation 负责综合通过竞争与打磨产出更优结果。文档明确给出组合策略先用 AdversarialValidation 产出初始方案再用 32 Agent 协议压力测试综合结果发现关键缺陷则迭代。与 FirstPrinciples 的深度集成Philosophy 文档中四类根本缺陷的实践依赖第一性原理拆解。根据 Integration.mdRedTeam 与 FirstPrinciples 技能存在固定集成点Phase 1 增强用FirstPrinciples/Deconstruct把论点拆成基本组成部分其输出模板见 Deconstruct.mdPhase 5 增强用FirstPrinciples/Challenge把约束分类为 hard / soft / assumption分类表见 Challenge.md——HARD 是物理/数学/现实、SOFT 是政策/选择/惯例、ASSUMPTION 是未经验证的信念核心洞见最致命的批评来自挑战隐藏假设。Challenge 工作流中还给出了与 RedTeam 的直接衔接用法对安全控制、商业模式假设调用 Challenge 来攻击假设对防火墙保护了我们这类声明做信任边界分析。换句话说Philosophy 文档的核心洞察在仓库中有一套可执行的约束分类工具来支撑而不是停留在口号层面。调用方式、运行纪律与注意事项在实际运行中RedTeam 技能的调用与执行有以下要点见 SKILL.md触发场景用户表达红队一下攻击这个想法找反方论证压力测试魔鬼代言人挑毛病找出最强反对意见等意图时触发如果用户想要的是协作式辩论、寻找最佳路径应路由到 Council 技能而非 RedTeam。强制语音通知技能被调用后必须先发送通知curl -s -X POST http://localhost:31337/notify ...并输出文本通知Running theWorkflowNameworkflow in theRedTeamskill to ACTION...这是不可跳过的步骤。个性化覆盖执行前需检查~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/RedTeam/是否存在用户自定义的 PREFERENCES.md 或配置存在则优先应用。三条红线Gotchas① 只攻击思想、不攻击系统② 32 个对抗 Agent 产出的是数量必须按严重度排序、丢弃噪音③ 目标是加固而非摧毁弱点要附带修复路径呈现。执行日志每次工作流完成后向~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl追加一条 JSONL 记录时间戳、技能名、工作流、输入摘要、状态、耗时失败时状态记为error。协作生态RedTeam 之前的技能是research收集上下文、找先例过程中用storyexplanation做分解方法、用自定义 Agent 做平行攻击之后用extractalpha提取最高信号批评、用xpost分享发现见 Integration.md。总结LifeOS 的 Red Team 技能把军事对抗文化提炼成一套可编程的决策审查协议以找到让整体崩塌的那一个根本缺陷为哲学核心以 32 类平行 Agent 保证攻击视角的多样性以钢铁人 反方论证各 8 点的严格输出契约保证攻击的诚实与强度再以 FirstPrinciples 的 Deconstruct / Challenge 提供拆解与约束分类的方法论支撑。它回答了现代 AI 协作中一个常被忽略的问题当每个人都爱上了自己的计划时谁来当那个问出艰难问题的角色——而 RedTeam 的答案是把这个问题放大 32 倍、并提前到代价还很小的时候。关键仓库文件索引RedTeam 哲学文档本文主体RedTeam 技能主文件路由、通知、执行日志ParallelAnalysis 工作流32 Agent 名册与输出契约AdversarialValidation 工作流三轮对抗协议RedTeam 集成指南技能协同顺序FirstPrinciples 分解流程FirstPrinciples 挑战流程HARD/SOFT/ASSUMPTION 分类【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考