矛盾与视角差异
这批资料里的硬性事实冲突依然不多，但 5 月新增源把几组“方法论上的张力”放得更明显了。
Codex 接入 Claude Code
矛盾：Codex 插件被一些文章解读为 OpenAI “偷 Claude 用户”的平台争夺动作，而另一些文章更强调它是分工明确的协作插件。来自 [[raw/2026-04-02/九皋山人/OpenAI 的阳谋：把 Codex 装进 Claude Code 的主工作流.md|来源: OpenAI 的阳谋：把 Codex 装进 Claude Code 的主工作流.md]] vs [[raw/2026-04-02/AI兴观点/打不过就加入：OpenAI 官方出手，把 Codex 插件装进 Claude Code.md|来源: 打不过就加入：OpenAI 官方出手，把 Codex 插件装进 Claude Code.md]]
Claude Code 内部机制
矛盾：逆向/泄露向文章倾向于把 Claude Code 描述成含有大量隐藏机制与“宠物”彩蛋的复杂系统，而工具设计解读更强调渐进暴露、最小工具集和工程演进。来自 [[raw/2026-04-02/秋芝2046/51万行源码泄露！Claude Code 里面到底藏了什么？.md|来源: 51万行源码泄露！Claude Code 里面到底藏了什么？.md]] [[raw/2026-04-02/花叔/祝贺Claude Code成功越狱，获得永生.md|来源: 祝贺Claude Code成功越狱，获得永生.md]] vs [[raw/2026-04-24/方圆yo/Anthropic 给 Claude Code 设计工具的最佳实践.md|来源: Anthropic 给 Claude Code 设计工具的最佳实践.md]]
模型强弱 vs 任务形状
矛盾：有些发布/评测叙事仍倾向把 GPT-5.5 与 Opus4.7 理解成谁在单榜单上更强，但经验文更强调真正分界线是任务形状、工作流治理和 Harness，而不是单一模型分数。来自 [[raw/2026-04-24/AI兴观点/GPT-5.5 炸场发布：碾压Opus4.7，OpenAI夺回王座，AI 编程进入「少 token 干大活」时代.md|来源: GPT-5.5 炸场发布：碾压Opus4.7，OpenAI夺回王座，AI 编程进入「少 token 干大活」时代.md]] vs [[raw/2026-04-27/金先森是朝鲜族阿/别问谁更强，GPT-5.5和Opus4.7综合对比.md|来源: 别问谁更强，GPT-5.5和Opus4.7综合对比.md]] [[raw/2026-04-29/李泽宇的AI实验室/如何让Codex自主编码10小时，秘籍开源.md|来源: 如何让Codex自主编码10小时，秘籍开源.md]]
更自动化 vs 不打断人
矛盾：一类实践希望让 AI 一晚上自动评测和优化系统，另一类文章则强调工作流最重要的不是更自动化，而是不打断人。来自 [[raw/2026-04-29/凤聆/Harness Engineering实践，做了一个平台让AI一晚上自动评测和优化你的系统.md|来源: Harness Engineering实践，做了一个平台让AI一晚上自动评测和优化你的系统.md]] vs [[raw/2026-04-30/问答/AI 工作流最重要的不是更自动化，而是不打断人.md|来源: AI 工作流最重要的不是更自动化，而是不打断人.md]]
反向链接
- [[wiki/entities/Claude Code]]
- [[wiki/entities/Codex 与 Claude Code 集成]]
- [[wiki/concepts/上下文管理与 Harness Engineering]]
- [[wiki/entities/Workspace Agents 与企业工作流]]
- [[wiki/concepts/AI Agent 编程治理分水岭]]
- [[wiki/concepts/Skills、Agents 与工具设计]]
- [[wiki/syntheses/AI 创业与 OPC]]
- [[wiki/concepts/Obsidian、LLM Wiki 与个人知识管理]]
2026-05 新增矛盾
Bash vs MCP 路线之争
矛盾：来新璐明确卸载了 GitHub MCP，因为 CLI 调用成功率更高——Linux 命令在预训练中出现几十亿条，MCP 预训练占比不到 0.1%。但李伟山认为 MCP 是”AI 世界的 USB 接口”，是快速扩展工具生态的关键。本质：训练语料覆盖度 vs 标准化生态扩展。来自 [[raw/2026-05-13/十字路口/探秘 Claude Code，搞懂 Agent Harness｜对谈来新璐.md|来源: 对谈来新璐]] vs [[raw/2026-05-13/李伟山/从零设计生产级 Multi-Agent Harness：架构、评估、记忆、成本与 MCP 工具接入全拆解.md|来源: 生产级 Multi-Agent]]
单 Agent vs 多 Agent
矛盾：Anthropic 官方建议”先充分挖掘单智能体的潜力，多智能体会带来额外开销和信息损耗”。来新璐认为下一步必然是”Agent 蜂群的集群化作业”。可能是阶段差异——Anthropic 讲工程务实，来新璐讲演进方向。来自 [[raw/2026-05-12/Akshay/深度拆解：AI 智能体 Harness 的构造【译】.md|来源: Harness 12组件]] vs [[raw/2026-05-13/十字路口/探秘 Claude Code，搞懂 Agent Harness｜对谈来新璐.md|来源: 对谈来新璐]]
Prompt Flow vs Agent Native 范式之争
矛盾：来新璐认为 LangChain/LangGraph 的 Prompt Node 流转方法论”在未来的 Agent 开发中会越来越不适用”。但李伟山在落地路线中仍推荐小团队使用 LangGraph 作为轻量状态机方案。核心理念差异：控制流由代码确定性管理 vs 由模型自主编排。来自 [[raw/2026-05-13/十字路口/探秘 Claude Code，搞懂 Agent Harness｜对谈来新璐.md|来源: 对谈来新璐]] vs [[raw/2026-05-13/李伟山/从零设计生产级 Multi-Agent Harness：架构、评估、记忆、成本与 MCP 工具接入全拆解.md|来源: 生产级 Multi-Agent]]
厚 Harness vs 薄 Harness（增强）
矛盾升级：Anthropic/Cursor 主张”脚手架隐喻”——Harness 是临时建筑，模型变强后应逐步拆除。但王云鹤明确反对这个方向，提出 Harness 的本质是”组合优化问题”——给定任务和可选模型集合，每步选最优模型并调整 harness 参数，优化 任务价值×成功率×Token性价比。他的判断更激进：Harness 不仅不会消失，还会因为多模型协同而变得更复杂。来自 [[raw/2026-05-12/Akshay/深度拆解：AI 智能体 Harness 的构造【译】.md|来源: Harness 12组件]] vs [[raw/2026-05-18/机器之心/王云鹤眼中的Harness：复杂优化问题，AGI灵魂争夺之战.md|来源: 王云鹤 Harness]]
延伸：王云鹤进一步提出”AI 灵魂之争”——如果 Harness 可以控制甚至选择模型，AI 的灵魂到底在 Base Model 还是 Harness？若基于 Harness 数据反哺模型训练（Model-Harness 联合优化），灵魂归属更模糊。这道哲学题背后是商业利益：谁控制了 Harness，谁就控制了 Agent 生态的入口。
Token 效率：现在讨论太早 vs 生存线
矛盾：来新璐认为 Agent 模型还处于婴儿期，不必过快讨论 Token efficiency。但李伟山把它作为生产级 Agent 的生命线（Token Budget 四级降级 + 7 项监控指标）。研究视角 vs 生产运维视角的典型张力。来自 [[raw/2026-05-13/十字路口/探秘 Claude Code，搞懂 Agent Harness｜对谈来新璐.md|来源: 对谈来新璐]] vs [[raw/2026-05-13/李伟山/从零设计生产级 Multi-Agent Harness：架构、评估、记忆、成本与 MCP 工具接入全拆解.md|来源: 生产级 Multi-Agent]]
Computer Use 路线：截图+坐标 vs DevTools Protocol
矛盾：Anthropic 走截图路线，强调”所见即所得”，但存在坐标错位、上下文爆炸等问题。Kimi WebBridge 走 CDP 路线，直接操作 DOM 元素，速度快、精准、保留登录会话。前者通用性更强，后者效率更高但依赖浏览器扩展。来自 [[raw/2026-05-14/Anthropic/Anthropic 发布 Computer Use 最佳实践.md|来源: CU 最佳实践]] vs [[raw/2026-05-15/AI兴观点/你还傻乎乎给 Computer Use 传截图？Kimi 发布的浏览器扩展Kimi WebBridge，Agent 直接操控你浏览器.md|来源: Kimi WebBridge]]
全职 Agent 生成 vs 人机协作
矛盾：Fiona Fung（Anthropic）强调”代码就是唯一事实来源”、“所有 PR 都有 Claude 参与”——AI 深度嵌入全流程。但金先森强调 AI 越强对人的要求越高，判断力不能外包。gnash 也强调 PRD 必须人写清楚验收标准。在”AI 应该替代多少人类判断”维度上立场不同。来自 [[raw/2026-05-13/宝玉/AI 时代到底该怎么管一个工程团队.md|来源: 工程团队管理]] vs [[raw/2026-05-12/金先森是朝鲜族阿/Claude和GPT全买了，AI用起来为啥还是不好用？老金来告你！.md|来源: AI 悖论]]
AI 让开发者失业 vs AI 无法背锅
矛盾：Tuhin Nair 认为 AI 至今做不到承担责任（背锅），这是资深开发者仍在坚守的核心价值。与”程序员已死”叙事形成直接矛盾。来自 [[raw/2026-05-14/Tuhin Nair/为什么资深开发者讲不清自己的专业能力.md|来源: 资深开发者价值]]
GPT-5.5 vs Opus 4.7 提示词方向相反
矛盾：GPT-5.5 官方指南要求删掉”必须""永远""只能”，用结果定义任务不用步骤；Anthropic 迁移指南说 Opus 4.7 “更字面、更不自动扩展”，需要更明确的范围声明。两个顶级模型对提示词的要求走向了两个相反方向。来自 [[raw/2026-05-02/发现明日产品的/这11个小技巧，GPT-5.5和Claude 4.7的Token 烧得更值 - 附官方指南.md|来源: Token 小技巧]]
代码审查：Fireable Offense vs 铁律环节
矛盾：Sam Schillace 极端主张”代码审查是 Fireable Offense”——审查阻碍了 AI 驱动团队的交付速度。但 Superpowers 的 requesting-code-review 是铁律环节。来自 [[raw/2026-04-30/AI兴观点/你的AI编程搭档，有了-超能力-——Superpowers Skills技能库完全指南.md|来源: Superpowers 指南]]
记忆深层建模 vs 记忆过时破坏性
矛盾：张碧泉介绍 Hermes 五层记忆”黑格尔辩证式用户建模”追求深度，但洁癖.skill 作者认为”一件过期的记忆比没有记忆更糟糕——没有记忆时 AI 至少知道自己不知道，读到过期信息会基于错误前提做事”。来自 [[raw/2026-04-29/张碧泉/深入浅出Harness Engineerring之核心模式与理念.md|来源: Hermes 记忆架构]] vs [[raw/2026-04-29/数字生命卡兹克/开源「洁癖.skill」，让你的Agent越用越聪明。.md|来源: 洁癖.skill]]
纯 Markdown vs 向量数据库知识库
矛盾：LLM Wiki 坚持纯 Markdown（零数据库、Git 可控），但飞樰指出数百到低千页面后 index.md 驱动检索显著下降。GBrain 引入向量数据库解决规模化，但与 LLM Wiki 的核心理念存在路径分歧。来自 [[raw/2026-05-16/朗朗晴空/LLM Wiki 不是 RAG：知识系统的范式转换.md|来源: LLM Wiki 不是 RAG]] vs [[raw/2026-05-13/飞樰/深度解析LLM Wiki - Obsidian-Wiki - GBrain：Agent时代知识的”自组织”与”自进化”.md|来源: GBrain]]
2026-05-19 新增矛盾
用户手动编排 vs Agent 自动触发
矛盾：Matt Pocock 的 Skills 体系主张用户手动调用每个技能（/grill-with-docs → /prototype → /to-prd 等），强调人保持控制权。但 Superpowers 主张 Agent 自动判断时机并触发相应技能，追求”全自动”。对控制权归属的根本分歧——手动编排更可靠但更慢，自动触发更流畅但可能错判。来自 [[raw/2026-05-18/AgentBuff/VibeCoding工程化实践之Matt Pocock Skills，软件工程经验的技能结晶.md|来源: Matt Pocock Skills]] vs [[raw/2026-04-30/AI兴观点/你的AI编程搭档，有了-超能力-——Superpowers Skills技能库完全指南.md|来源: Superpowers 指南]]
Markdown vs HTML 作为 Spec 载体
矛盾：社区主流（OpenSpec、SDD、CLAUDE.md）走纯文本 Markdown 路线，强调版本控制友好、Git diff 可读、模型训练语料覆盖广。但 Anthropic CC 团队工程师 Thariq Shihipar 把 PRD/技术 spec/设计系统全转成 HTML，理由是 Markdown 计划太长后人类不再逐行阅读，HTML 的卡片/表格/颜色/交互按钮让人重新愿意参与审查。版本控制友好性 vs 人类可审查性。来自 [[raw/2026-05-18/Capihom/Claude Code 工程师：为什么使用HTML文件作为AI规范丨How I AI.md|来源: HTML-as-Spec]]
SDD 彻底替代 Vibe Coding vs Vibe Coding 改良
矛盾：jilolo 认为 Vibe Coding 只能做 demo、SDD 才是生产级——“Spec 才是新的代码”。但 gnash 认为 Vibe Coding 的真正瓶颈不是没有 Spec，而是 PRD 没写到测试能直接接手的程度——在好的 PRD 下 Vibe Coding 依然高效。本质不是替代关系，而是”多前投入换少后返工”的经济学分歧：花 2-3 倍 token 写 spec 值不值得？来自 [[raw/2026-05-16/jilolo/Vibe Coding已经是过去式了：Spec Driven Development（SDD） 指南.md|来源: SDD指南]] vs [[raw/2026-05-16/gnash/PRD怎么写，vibe coding能够减少50%以上的测试时间？.md|来源: PRD写法]]
AI Native 创业：非技术创始人能成功 vs 技术是硬门槛
矛盾：Anthropic 官方创始人手册明确说非技术创始人也能交付生产级应用——AI 三种界面(Chat/Cowork/Code)覆盖了从快问快答到深度编码的全线。但 Sam（一年 CC 深度用户）认为”真正用好 Claude Code 的人是本来就懂技术的人”——生产事故风险（如多租户数据暴露、幻觉 API）是非技术创始人的隐性天花板。本质是”能做出来”vs”能做得靠谱”的分歧。来自 [[raw/2026-05-17/Anthropic/Anthropic 官方发布：《创始人手册：打造 AI 原生初创公司》.md|来源: 创始人手册]] vs [[raw/2026-05-17/Sam/用了 Claude Code 一年多，我想说几句扎心的实话.md|来源: CC一年实话]]
单智能体深度自治 vs 三智能体架构 vs 上下文管理优先
矛盾：OpenAI 坚持单智能体深度自治（100 万行代码零人工编写），Anthropic 走 Planner-Generator-Evaluator 三智能体分离（类似 GAN 架构），Cursor 聚焦单智能体的动态上下文管理（把 harness 当产品运营迭代）。三家的路线差异反映了对”Agent 可靠性从哪来”的不同回答：环境工程 vs 角色分离 vs 上下文策略。来自 [[raw/2026-05-18/邵猛/Agent Harness Engineering 三重前沿实践：Codex、Claude Code、Cursor 如何让人类从编码者升为架构师.md|来源: 三重前沿]]
2026-05-22 新增矛盾
”代码是负债” vs “/goal 放手生产”
矛盾：阿里云 CIO 明确提出”代码一旦生产出来，首先是负债”——代码的维护成本、技术债、理解成本远超编写成本。但 Codex 的 /goal 模式鼓励 AI 大量自主生产代码，Anthropic 的 Agent View 也在推动”放手让 Agent 干”。两种立场如何调和？可能的分界线：负债论针对的是”无规范约束的代码生产”，/goal 模式的前提是”有 Harness 和 Spec 约束的代码生产”。但两者对”代码生产的态度”确实构成根本张力。来自 [[raw/2026-05-22/阿里云开发者/代码一旦生产出来，首先是负债 —— 一个CIO 的AI效能实践复盘.md|来源: 阿里云CIO-代码负债]]
薄 Harness（衰变定律）vs 厚 Harness（多模型组合优化）——李伟山入场
矛盾升级：在上文 [[#厚 Harness vs 薄 Harness（增强）|已有矛盾]] 的基础上，李伟山明确提出”衰变定律”——Harness 应随模型能力提升做减法，当模型原生能力覆盖某个 harness 功能时，应立即精简。这与王云鹤”多模型组合的永久基础设施”构成更正式的张力。三方立场：Anthropic/Cursor（脚手架隐喻，随模型变强拆除）vs 李伟山（衰变定律，主动做减法）vs 王云鹤（组合优化，越做越复杂）。来自 [[raw/2026-05-13/李伟山/从零设计生产级 Multi-Agent Harness：架构、评估、记忆、成本与 MCP 工具接入全拆解.md|来源: 李伟山-Harness衰变]] vs [[raw/2026-05-18/机器之心/王云鹤眼中的Harness：复杂优化问题，AGI灵魂争夺之战.md|来源: 王云鹤 Harness]]
Karpathy 极简通用规则 vs 项目特定重型配置
矛盾：Karpathy 的 CLAUDE.md 仅 65 行四条规则（“不要写临时代码”等级），追求跨项目通用行为约束。但 QQ 音乐、Spotify 等团队的 Harness 体系包含大量项目特定的目录约定、模块边界、命名规则和工具限制。通用行为约束和项目特定工程约束的分界线在哪？可能的答案：Karpathy 管”怎么做事”，项目 CLAUDE.md 管”在这个项目里怎么做”。但实际工程中两条线经常交叉。来自 [[raw/2026-05-12/Karpathy/Vibe Coding 2.0：Karpathy 的极简 AI 编程实践.md|来源: Karpathy-Vibe2.0]]
Vibe Coding 遭受的正式批评
矛盾：ChallengeHub 的 SDD 指南明确将 Vibe Coding 列为反面教材——“代码复杂度持续走高”是 Vibe Coding 的固有缺陷，因为缺少前期结构约束。这比上文 [[#SDD 彻底替代 Vibe Coding vs Vibe Coding 改良|已有的 SDD vs Vibe Coding 矛盾]] 更进一步：不是”改良够不够”，而是”Vibe Coding 本身有结构性缺陷”。Vibe Coding 倡导者（如 Karpathy）尚未对此做出直接回应。来自 [[raw/2026-05-22/ChallengeHub/Spec-Driven Development完整指南：6要素+3模式+多智能体，一篇讲透SDD怎么用.md|来源: ChallengeHub-SDD完整指南]]
2026-05-31 新增矛盾
Harness 追求 AI 最大嵌入 vs 个体行动力维持
矛盾：现有 wiki 的 Harness Engineering 主线（“Agent = Model + Harness”）默认 AI 使用越多越好、越工程化越好。但 jerry 从认知心理学角度发出警告：AI 的真正副作用不是”变笨”，而是行动力削减——棘轮效应（只进不退）、多巴胺陷阱（摩擦抹除）、身份内化（“需要 AI 才能运转的人”）。“AI 无法替你成为一个能够行动的人。“这是与整个 Harness 推进叙事的深层张力——不是反对用 AI，而是警告”过度依赖”有真实的认知代价。来自 [[raw/2026-05-26/AI退化的不是脑子，是行动力.md|来源: AI退化行动力]] vs [[wiki/concepts/上下文管理与 Harness Engineering]] 全页主线 调和可能性：这不是二选一，而是提醒 Harness 设计时应纳入”人在回路”的认知保护机制——不能把 Harness 做成”人完全不需要思考”的系统。
学术综述支撑厚 Harness vs Anthropic 薄 Harness 衰变定律升级
矛盾升级：CMU/Yale/JHU 的 71 页综述《Agent Harness Engineering: A Survey》系统论证了 Harness 不是过渡工具而是核心基础设施——同一个模型换 harness 提升数倍性能、需要 trace-native 评估、需要完整的七层框架。这直接冲击了上文 [[#薄 Harness（衰变定律）vs 厚 Harness（多模型组合优化）——李伟山入场|薄 vs 厚 Harness 矛盾]] 中 Anthropic/李伟山的”衰变/减法”立场。现在”厚 Harness”方有了第一篇来自 CMU+Yale+JHU+Amazon 联合的顶级学术背书。来自 [[raw/2026-05-28/刚刚，一篇最全Agent Harness综述来了！.md|来源: CMU综述]]
延伸：腾讯程序员提出的”判断工程不可能三角”（Spec 完备性 vs Goodhart 抗性 vs Tacit 保全）为厚 Harness 路线增加了”过度显形的代价”这一新维度——Harness 越厚、规则越多、指标越精确，可能反而越容易触发 Goodhart 定律和隐性知识流失。详见 [[上下文管理与 Harness Engineering#“判断工程的不可能三角”：Harness 的隐藏代价（2026-05 新增）|Harness 隐藏代价]]。
Dynamic Workflows 确定性 vs Agent Teams 涌现式路线张力
矛盾：Claude Code 内部出现两条并行路线：Dynamic Workflows 用代码写死流程（确定性、可审计、可回放），Agent Teams 让模型自己协调（涌现式、灵活、适应性）。这不是”哪个更好”的问题，而是一个新的技术路线选择——Workflows 适合”有明确 oracle 的机械性任务”（如 Bun 重写 Rust），Agent Teams 适合”需要跨视角碰撞的创造性任务”。但两者在一个产品内共存，可能在未来演化为路线之争。来自 [[raw/2026-05-27/Claude Code 隐藏新功能 -workflows：确定性多 Agent 编排引擎深度拆解.md|来源: Workflows深度拆解]] vs [[raw/2026-05-26/Claude Code + Agent Teams，并行任务的最佳实践.md|来源: Agent Teams实战]]
“AI 全自主不可靠” vs Dynamic Workflows 75 万行成功案例
矛盾：腾讯 Agentic Engineering 文章（公理化推导）主张”AI 全自主不可靠”——概率性+记忆有限=错误指数累积。但同期的 Dynamic Workflows 成功实现 Bun 从 Zig 到 Rust 的 75-96 万行代码自主生成（11 天、99.8% 测试通过）。调和点：关键变量不在”全自主与否”而在”有没有完善的测试套件作为 oracle”——有确定性验证标准时全自主可行，缺乏时不可靠。来自 [[raw/2026-05-29/腾讯云开发者/Agentic Engineering六条最佳实践.md|来源: 六条最佳实践]] vs [[raw/2026-05-29/为dynamic workflows，Claude 发布 Opus4.8.md|来源: Dynamic Workflows]]
MCP/CLI/Skills 三层分工消解 Bash vs MCP 张力
潜在消解：独行者 木子李提出 MCP（能力层）/CLI（调用层）/Skills（任务层）三层分工框架——不是替代是三层协作。MCP 暴露服务能力、CLI 高效调用、Skills 编排流程。CLI 更模型友好的原因是”语料红利”而非”形式优势”。“调用层缺失”才是真问题。该框架不否定 [[wiki/concepts/上下文管理与 Harness Engineering]] 中记录的”Bash vs MCP”张力，但提供了一个更优雅的非二选一解法。来自 [[raw/2026-05-27/MCP、CLI 与 SKILLS：它们不是替代关系，而是 AI 工具调用体系的三层分工.md|来源: 三层分工]]
Skill 优化：AI 自动训练 vs 人类手工编写
新张力：微软 SkillOpt 研究将 Skill 文档视为神经网络权重、通过 rollout→reflection→edit 循环自动优化，跨模型迁移已验证（GPT-5.4→CC +59.7 分）。这与 wiki 中所有 Skill 编写方法论（Skill Creator、Skill Factory、手工编写最佳实践）构成新范式对比——Skill 文档的”作者”可能不再是人类而是 AI。但复旦/微软实验同时警告 25% 负迁移率——自动优化的质量高度依赖 eval 质量。来自 [[raw/2026-05-27/别再手写 Skill 了！微软最新研究：像神经网络一样训练 Skill.md|来源: SkillOpt]] vs [[wiki/concepts/Skills、Agents 与工具设计]] 的”手工编写”全章
Opus 4.8 的 reach test 与 benchmark 之争（2026-06 新增）
矛盾升级：Every 团队的 reach test（Sr. Engineer Benchmark 63 分 vs GPT 5.5 的 62 分）提供了一种比 benchmark 更贴近工作选择的评价框架。但 reach test 本身也有缺陷——样本太小（3 人）、任务权重依赖团队业务特征。核心矛盾不在分数本身，而在”以什么标准判断模型好”：benchmark 追求可复现的客观度量，reach test 追求”我用不用它”的实践判断。一个模型 benchmark 领先但没人伸手去用，比 benchmark 落后更致命。来自 [[raw/2026-06-01/Capihom/为什么我从 Codex 又回到了 Claude？丨Every.md|来源: Capihom Reach Test]]
Dynamic Workflows 的清晰度升级 vs Agent Teams 涌现张力（2026-06 新增）
j5land 用”装修房子比喻”（普通对话=∠一个师傅、Skill=施工手册、Subagent=多叫几个师傅、Agent Teams=施工队、Workflow=施工流程图）把四个概念的定位说清楚了。但这反而让路线选择更明显：Workflows 适合”有明确 oracle 的机械性任务”，Agent Teams 适合”需要跨视角碰撞的创造性任务”。两者在同一产品内共存不是问题，但团队的技能投资需要二选一——学 Workflows 的 JavaScript 编排还是学 Teams 的角色设计。来自 [[raw/2026-06-01/j5land/Claude Code 本次发布的 Workflow 是什么？有哪些场景值得用？.md|来源: j5land Workflows vs Teams]]
Log 分析：传统工程 vs AI 工程（2026-06 新增）
Fox 爱分享的两篇面试题文章（Redis、Kafka）展示了一个与 AI 主线不同的工程风格——传统后端架构师的核心技能在”极端恶劣环境下的兜底方案设计”（Redis 全崩时断臂求生、Kafka Topic 多时性能雪崩），这与 AI 工程”用 Harness 兜住模型不确定性”形成风格对照。两者没有矛盾，但说明了一个事实：AI 工程化不能取代底层工程素养——Redis 挂了的时候，AI agent 也救不了你。来自 [[raw/2026-06-01/Fox爱分享/听说你觉得旁路缓存很Low？蚂蚁金服一面：高并发下的 Redis 顶级连环炮.md|来源: Fox Redis]] [[raw/2026-06-02/Fox爱分享/蚂蚁一面：为什么选Kafka？别的MQ不行吗？.md|来源: Fox Kafka]]
人为中心+AI 辅助 vs AI 为中心（2026-06 新增）
王鹏程提出了一组更彻底的判断：Copilot 模式不是”过渡方案”而是”弯路”——它没有消除不确定性，而是在循环放大。反馈回路被切断。AI 为中性模式下反馈才能闭合。从工程史角度看，每一场范式跃迁都经历了先用新工具替代旧工具再重构流程的过渡形态——Copilot 正是”用电动机直接替换蒸汽机”的过渡形态。这个判断比之前 [[#更自动化 vs 不打断人]] 中所记录的张力更根本——不是”自动化的度”的问题，而是”谁是中心”的问题。来自 [[raw/2026-06-02/王鹏程/AI软件工程范式革命的思考.md|来源: 王鹏程 Copilot 弯路]]
2026-06-21 新增矛盾
Loop Engineering 是第四次跃迁 vs “新瓶装旧酒”
矛盾：梦朝思夕和 AllenTang 将 Loop Engineering 定位为 Harness 之后 Agentic Engineering 的第三次/第四次跃迁——从写 Prompt 到写 Loop 的范式转移，且提炼了五要素模型和六组件解剖。但 Guide 作者在面试场景中明确质疑”这不是改了个词？就是把 Prompt Engineering 之前做的事用一个新词包装了一下”。两种立场代表了对 Agent 编程演进是否构成真正范式转移的根本分歧。来自 [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: 梦朝思夕 Loop Engineering]] vs [[raw/2026-06-17/Guide/面试官：你说你懂 Loop Engineering，那 Claude Code 的 -loop 和 -goal 区别是什么？我：这是啥？.md|来源: Guide 面试官]]
提示词说服 vs 确定性执行——CLAUDE.md 与 Hooks 的分工本质
矛盾：CLAUDE.md、Rules、Skills 等一切”指令式”机制本质上依赖模型对自然语言的理解——是一种”提示词说服”（Prompt Persuasion）。但 Hooks、Permissions、Command 走的是代码执行路径，具备 100% 确定性。多位作者分别独立触及这个区分：吴师兄指出”只写 AI 猜不到的事”（把已知规律从 CLAUDE.md 移出）、技术自由圈强调”程序性记忆 vs 一次性指令”、脸谱君提出”AI 不是我肚子里蛔虫”。核心分歧在于：CLAUDE.md 内容到底该有多少条？14 条/200 行的纪律本质上是对”说服 vs 执行”比例的工程判断——规则越多，越接近编程但越受压缩限制。来自各组源文件独立交叉验证——吴师兄、金色传说、邵猛、技术自由圈、扶苏、Unknown 等多来源共识。
全自动 Harness 管控 vs 人类保持控制权（尼恩 vs Matt Pocock 路线升级）
矛盾升级：在上文 [[#用户手动编排 vs Agent 自动触发|已有矛盾]] 的基础上，新增源将这条路线张力推得更深。尼恩（技术自由圈）的工业级 Skill 体系设计的核心是”Source-as-Root”——决策源头在技能框架而非人类，中心 Skill 自动编排自动触达目标。Matt Pocock 的 Skill 设计哲学则是”人类决定下一步哪个 Skill”——用户输入即入口，Skill 不自动级联。两条路线在”触发点”（模型自动 vs 用户手动）、“编排者”（系统 vs 人）、“可撤销性”（困难 vs 自然）三个维度上全面对立。来自 [[raw/2026-06-20/技术自由圈/阿里面试官：如何设计工业级 Skills 进化体系？ 一个工业级 技能 Infra 底座如何设计？.md|来源: 技术自由圈-Skill Infra]] vs [[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: Matt Pocock Skill 工作流]]
OpenAI Sites (PaaS) vs Anthropic Artifacts (无状态画布)——平台战略分化
矛盾：OpenAI 发布 Sites，本质是 AI 原生全栈 PaaS——模型生成完整可部署前端 + 后端 + 数据持久化，用户直接获得”一键上线的全栈应用”。Claude Code Artifacts 则走无状态灵感画布路线——终端输出实时可视化，随会话刷新，强调临时性和高安全性（无持久化）。两者在”输出存在形式”、“安全模型”、“可迭代性”和”用户场景”上全面对立：Sites 解决”让应用上线”的问题，Artifacts 解决”让工作流直观化”的问题。不构成替代关系，但同为”AI 输出可视化”方向的不同答案。来自 [[raw/2026-06-20/AI兴观点/Claude Code 推出新功能 Artifacts：AI 编程会话输出可以变成生动的交互页面，并能实时共享给团队.md|来源: CC Artifacts]] [[raw/2026-06-19/发现明日产品的/Claude Code 发了个「王炸」功能，打工人狂喜.md|来源: CC 王炸功能]] 等
三种多 Agent 架构哲学分歧——单 Agent+能力 vs 层级 CRD vs Hooks+子代理
矛盾升级：新增源揭示了三种根本不同的多 Agent 架构哲学：Hermes（得物）走”单 Agent + 能力模块”路线，通过规则资产化和三层门控（事实来源/演练/责任）在一个 Agent 内扩展能力边界；AgentTeams 走”层级 CRD”路线，用 Kubernetes 风格的 Custom Resource Definitions 管理 Agent 间的依赖、资源和权限；扶苏走”单 Agent + Hooks + 特化子代理”路线，通过 Hooks 拦截生命周期事件调用子代理处理特化任务。三套方案的共同点是把 Agent 当作可管理的资源而非独立个体，但对”管理粒度”和”组织模型”有根本分歧。来自 [[raw/2026-06-17/小试、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: Hermes 得物]] [[raw/2026-06-17/承吉/工作闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md|来源: AgentTeams 承吉]] [[raw/2026-06-19/扶苏/Claude Code 深度实战：半年单兵重构 30 万行代码的硬核工程化指南.md|来源: 扶苏 30 万行代码]]
Spec-first SDD vs Execution-first Harness——OpenSpec vs 扶苏实践
矛盾：Jameszyh 的 OpenSpec 从”规约驱动”出发，主张在代码编写之前生成完整的 Delta Spec（类似数据库的 WAL 预写日志），所有实现决策必须与 Spec 可追溯——Brownfield-friendly，严格规约优先。扶苏的 30 万行代码重构实践则走”Execution-first”路线——核心工程决策在 Hooks 拦截和 Pipeline 重试策略中隐含，CLAUDE.md 和 Skills 用来规约行为但不预先写 Spec。两种路线回答了同一个根本问题——“质量保证的锚点在哪”——的不同答案：在规约中 vs 在运行时管控中。来自 [[raw/2026-06-20/Jameszyh/OpenSpec 深度剖析：规约驱动开发的终极形态.md|来源: OpenSpec]] vs [[raw/2026-06-19/扶苏/Claude Code 深度实战：半年单兵重构 30 万行代码的硬核工程化指南.md|来源: 扶苏 30 万行]]
“人负责判断、AI 负责执行”共识下的判断定义分化
矛盾：叶小钗（管理者判断+AI 结构化）、吕昭波（同一模式的企业管理版本）、云舒（AI 缺乏经验无法替代判断）、YC（创始人必须能运营客户生意）四条线索共同构成了”人负责判断、AI 负责执行”的共识。但”判断”本身的定义完全不同——叶小钗说的是项目管理判断（优先级/风险/资源分配），吕昭波说的是战略分析判断（商业模型/SWOT/假设查证），云舒说的是经验判断（编程架构/边界失误场景），YC 说的是创业判断（客户需求/产品市场匹配）。核心张力不是”判断有无价值”，而是”判断有多个不可化简的维度”，不能用”AI 替代判断”这种单一陈述涵盖。来自 [[raw/2026-06-18/叶小钗/FDE、AI 产品经理、AI 工程师：普通人吃到 AI 红利的三种路径.md|来源: 叶小钗 FDE]] [[raw/2026-06-20/吕昭波/AI Coding赋能管理人员，用商业画布、SWOT 等分析工具，把战略思考变成可执行产出.md|来源: 吕昭波-商业画布]] [[raw/2026-06-20/云舒的AI实践笔记/AI用的越多，越觉得人的判断重要.md|来源: 云舒判断]] [[raw/2026-06-20/Capihom/YC 合伙人：你寻找创业点子的方式不对丨Y Combinator.md|来源: YC 合伙人]]
AI 验证能力缺失——假通过 vs 静默缺陷
矛盾：吴师兄”一个月烧 1.5 万美金”的惨痛教训中核心问题是”AI 说通过了，但真的黑屏了”——他估算约 20 个 Skill 里有 7 个假通（35% 虚报）。AI 沃茨的 PPT Skill 同样经历了”0 fail 全绿但页码排版不对”的静默渲染缺陷。技术自由圈的工业级 Skill 架构专门设计了 Deviation Detection 和偏离检测作为核心组件——把”验证不可信”视为架构问题而不是测试问题。两条线索深度互证：AI 的自我验证能力极其不可靠，必须外挂独立验证手段。来自 [[raw/2026-06-20/吴师兄/一个月给 Claude Code 烧了 1.5 万美金，我才搞懂 skill 到底该怎么写.md|来源: 吴师兄 1.5万美金]] [[raw/2026-06-19/AI沃茨/开源一个为演讲而生的PPT Skill，再不用跟观众大眼瞪小眼了.md|来源: AI沃茨 PPT Skill]] [[raw/2026-06-20/技术自由圈/阿里面试官：如何设计工业级 Skills 进化体系？ 一个工业级 技能 Infra 底座如何设计？.md|来源: 技术自由圈 GEPA]]
辩论对抗的失效边界——“双重确认偏误”
矛盾：多 Agent 辩论对抗（Debate）被视为提高 Agent 输出可靠性的有效手段。但 Jameszyh 在 LangGraph 底层原理中指明了一个关键失效模式：多个 Agent 共享同一个模型底座，在辩论证成过程中会互相强化确认偏误——不是消除错误而是协商出错。这与 OpenClaw 已有的”辩论退化陷阱”（[[wiki/entities/OpenClaw 与多 Agent 编排#辩论对抗的失效模式|辩论退化]]）构成独立印证：多 Agent ≠ 更可靠，共享基座的辩论可能比单 Agent 更危险。来自 [[raw/2026-06-19/Jameszyh/LangGraph 底层原理：它是怎么把 LLM 变成一台状态机的.md|来源: Jameszyh LangGraph]]
2026-07 新增矛盾
Agent Loop vs Loop Engineering
矛盾：一类资料把 Loop Engineering 等同于 Agent 内部的感知-推理-行动-观察循环；另一类资料强调 Agent Loop 只是执行原语，Loop Engineering 是围绕任务发现、预算、验证、状态持久化和交接的系统工程。前者容易把”会循环”误判为”可治理”，后者强调运行时治理。来自 [[raw/2026-07-01/论文跟踪/Agent Loop 与 Loop Engineering 区别.md|来源: Agent Loop 与 Loop Engineering 区别]] vs 多篇 Loop 入门教程。
长上下文 vs 记忆治理
矛盾：1M 上下文叙事容易让人以为”把资料全塞进去”即可解决记忆问题；但工作记忆/长期记忆/压缩治理资料指出，长上下文会在 10 万 token 后出现性能退化，且无法替代事实晋升、过期、冲突标记和摘要结构。来自 [[raw/2026-06-30/Unknown/虽然许多模型都支持了 1M 上下文，但实际上到了 10 万时就会变得很蠢，超过 20 万时就会更蠢，越长越蠢…….md|来源: 长上下文退化]] vs [[raw/2026-06-30/45岁老架构师尼恩/阿里面试：为什么 长期记忆分成 静态长期记忆 和 动态长期记忆 ？长期记忆爆炸了，怎么解决？.md|来源: 长期记忆分层]]
OpenClaw 通用数字员工 vs ADE/Worktree First
矛盾：OpenClaw 路线强调通用 GUI/网页操作，适合展示”接入万物”；Orca/ADE 路线强调给 Agent 一个专用开发环境、worktree 和远程执行能力。前者覆盖面广但状态和成本难控，后者更窄但更贴近 AI Coding 生产闭环。来自 [[raw/2026-06-24/叶小钗/OpenClaw、WorkBuddy、Loop 工程：谁在火，谁有用，谁还在 Demo.md|来源: OpenClaw/WorkBuddy/Loop]] vs [[raw/2026-07-01/爱海贼的无处不在/AI编程实践第15节：Orca 的多代理协同开发，专门为AI Coding 打造的 IDE.md|来源: Orca ADE]]
Skill 自动召回 vs Skill 供应链安全
矛盾：工业级 Skill 系统希望自动召回、自动注入、自动演化，减少人工选择成本；SkillScan 资料提醒 Skill 是可执行工作流包，自动召回扩大了供应链攻击、权限滥用和依赖漂移风险。越自动，越需要 manifest、安全扫描、权限边界和版本治理。来自 [[raw/2026-07-01/会员技术/AI Agent 的 Skill 系统设计.md|来源: Skill 系统设计]] vs [[raw/2026-07-01/火山引擎 AI 安全/一文了解｜SkillScan 智能体技能安全扫描最佳实践.md|来源: SkillScan]]