diff --git a/InBox/2026-05-30_SDD_规格驱动落地_文档管理策略_BV1mZV76eEPC_笔记.md b/InBox/2026-05-30_SDD_规格驱动落地_文档管理策略_BV1mZV76eEPC_笔记.md deleted file mode 100644 index f8ea206..0000000 --- a/InBox/2026-05-30_SDD_规格驱动落地_文档管理策略_BV1mZV76eEPC_笔记.md +++ /dev/null @@ -1,177 +0,0 @@ -# SDD 规格驱动落地：文档管理策略 - -## 研讨会背景与目的 - -本次分享是 AI 编程相关话题的延续，主要聚焦 **SDD（Spec-Driven Development，规格驱动开发）** 的文档管理策略。 - -### 研讨会机制 - -- **目的**：让参会者能够参与达成社区共识，分享各公司在 AI 编程实践中的经验 -- **形式**：咨询师分享观察到的公司实现方案、架构设计、系统设计等内容 -- **价值**：对个人和团队帮助都非常大，通过集体讨论形成共识 - -> 特别感谢卡尼克老哥在研讨会期间贡献了大量分享思想，受益颇多。 - ---- - -## AI 编程发展历程回顾 - -### 时间线概览 - -| 时间 | 分享内容 | 核心概念 | -|------|----------|----------| -| 2025年6月 | 早期 AI 编程实践 | DPER5 方法论 | -| 后续 | MCP 等工具整合 | MCP、Scales | -| 5月9日 | Plan 和 Build 模式 | 新因子（吸引子）概念 | -| 本次 | SDD 文档管理策略 | 规格驱动落地 | - ---- - -## DPER5 方法论 - -### 核心思想 - -DPER5 将软件工程中使用 AI 进行开发的过程分为 **5 个弱阶段（Weak Stages）**： - -``` -Discover → Plan → Execute → Review → Refine - ↓ ↓ ↓ ↓ ↓ - 发现 规划 执行 评审 优化 -``` - -### 阶段特性 - -- 不同阶段 AI 会按照不同的模式运行 -- 例如在 **Design** 模式或 **Discover** 模式下，AI **不会修改代码** -- 这种分阶段约束是驯服 AI 的简单有效方法 - -### 实践应用 - -- 在早期阶段（2025年），演讲者已经在公司内部领先应用 -- 采用 `Design → Plan → Execute` 的流程驱动开发 -- 该方法使用了较长时间，有效规范了 AI 辅助开发流程 - ---- - -## MCP（Model Context Protocol）工具生态 - -### 工具整合 - -后续随着 MCP 以及相关工具套件的出现，形成了完整的 AI 编程工具生态： - -- **MCP（Model Context Protocol）**：模型上下文协议 -- **Scales**：扩展工具 -- **SDD**：规格驱动开发方法论 - -这些工具被整合到一份 PPT 手册中，作为团队 AI 编程的指南或手册参考。 - ---- - -## SDD（规格驱动开发） - -### SDD 的核心模式 - -SDD 提供了多种工作模式，适用于不同的开发场景： - -| 模式 | 适用场景 | AI 行为特征 | -|------|----------|-------------| -| **Design** | 需求分析、架构设计 | 不修改代码，仅提供设计建议 | -| **Discover** | 探索发现、方案调研 | 不修改代码，专注于信息收集 | -| **Plan** | 规划分解、任务拆解 | 生成实现计划 | -| **Build** | 代码实现、具体开发 | 执行代码编写和修改 | - -### 新因子（吸引子）概念 - -由 countic 大佬在 5月9日的分享中引入： - -**物理学的概念解释**： - -- 在混沌系统中，存在两种震荡反馈的系统 -- 这种系统最终会收敛到一个稳定状态 -- 这个收敛点被称为 **吸引子（Attractor）** - -**在 AI 编程中的应用**： - -- 通过引入新因子，可以引导 AI 的输出趋向于预期的稳定状态 -- 帮助控制 AI 在复杂任务中的发散性 -- 实现更可控的 AI 驱动开发流程 - ---- - -## SDD 文档管理策略 - -> 本次分享的核心主题，聚焦于规格驱动开发的文档管理方法 - -### 文档在 SDD 中的作用 - -1. **规格定义**：明确需求和设计规范，作为开发的基准 -2. **上下文传递**：在不同阶段之间传递上下文信息 -3. **版本控制**：记录规格的变更历史 -4. **团队协作**：统一团队对需求的理解和实现方式 - -### 文档管理最佳实践 - -（基于 SDD 方法论，文档管理应遵循以下原则） - -- **规格优先**：在开发前先完成规格文档的编写 -- **增量迭代**：规格文档随项目进展逐步完善 -- **双向追溯**：规格与实现之间保持可追溯性 -- **工具集成**：将文档管理与 AI 编程工具链整合 - ---- - -## 工具链整合方案 - -### 推荐的 AI 编程工具栈 - -``` -┌─────────────────────────────────────────────────────┐ -│ 规格层 (Spec) │ -│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ -│ │ Design │ │ Discover │ │ Plan │ │ -│ └─────────────┘ └─────────────┘ └─────────────┘ │ -├─────────────────────────────────────────────────────┤ -│ 工具层 (Tools) │ -│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ -│ │ MCP │ │ Scales │ │ SDD │ │ -│ └─────────────┘ └─────────────┘ └─────────────┘ │ -├─────────────────────────────────────────────────────┤ -│ 执行层 (Execution) │ -│ ┌─────────────┐ ┌─────────────┐ │ -│ │ Build │ │ Review │ │ -│ └─────────────┘ └─────────────┘ │ -└─────────────────────────────────────────────────────┘ -``` - -### MCP 的核心功能 - -- 提供标准化的上下文协议 -- 实现 AI 与外部工具的无缝集成 -- 支持多工具协同工作 - ---- - -## 社区贡献者致谢 - -| 贡献者 | 贡献内容 | -|--------|----------| -| 卡尼克 | 大量分享思想，研讨会核心参与者 | -| countic | 引入新因子（吸引子）概念，分享 Plan/Build 模式 | -| 少个分号 | SDD 方法论整理，工具链整合，文档管理策略分享 | - ---- - -## 后续话题预告 - -本次分享的议程安排： - -1. **SDD 文档管理策略**（当前内容） -2. **AIGC 模板相关话题**（由卡尼克老哥分享） - ---- - -## 参考资源 - -- 本次分享的 PPT 资料（可作为团队 AI 编程手册/指南） -- 搜索关键词：`AI编程`、`MCP`、`SDD`、`DPER5`、`规格驱动开发` -- 相关标签：`人工智能`、`规格驱动开发`、`AI编程` \ No newline at end of file diff --git a/InBox/Harness_Engineering最佳实践_深度解析AgentHamness的底层原理_核心组件和实战应用_学不会我_BV1Hn9UBrEsH_P1_笔记.md b/InBox/Harness_Engineering最佳实践_深度解析AgentHamness的底层原理_核心组件和实战应用_学不会我_BV1Hn9UBrEsH_P1_笔记.md deleted file mode 100644 index 1211b26..0000000 --- a/InBox/Harness_Engineering最佳实践_深度解析AgentHamness的底层原理_核心组件和实战应用_学不会我_BV1Hn9UBrEsH_P1_笔记.md +++ /dev/null @@ -1,320 +0,0 @@ -# Harness Engineering 最佳实践：Agent Harness 底层原理、核心组件与实战应用 - -## 目录 - -1. [AI 工程师的岗位分层体系](#1-ai-工程师的岗位分层体系) -2. [大模型应用的三层进化范式](#2-大模型应用的三层进化范式) -3. [Prompt Engineering：让模型"会说"](#3-prompt-engineering让模型会说) -4. [Context Engineering：解决上下文膨胀问题](#4-context-engineering解决上下文膨胀问题) -5. [Agent Harness 核心架构](#5-agent-harness-核心架构) -6. [Harness Engineering 的工程实践](#6-harness-engineering-的工程实践) - ---- - -## 1. AI 工程师的岗位分层体系 - -### 1.1 三层架构概述 - -在 2026 年，AI 工程师可分为三个层级，每个层级有明确的技术侧重点： - -| 层级 | 定位 | 核心职责 | 技术侧重 | -|------|------|----------|----------| -| **AI 产品化** | AI 产品经理、AI 解决方案架构师 | 发现 AI 价值场景，重塑业务流程 | 业务分析、产品设计 | -| **AI 应用层** | AI 应用工程师、大模型应用开发 | 业务方案落地，AI 赋能场景 | Prompt Engineering、Context Engineering、RAG | -| **AI 大模型算法层** | 模型研发工程师 | 提升模型垂直能力 | SFT 微调、RLHF 对齐、安全护栏 | - -### 1.2 各层级的核心差异 - -**AI 产品化层**： -- 聚焦于找到 AI 的价值场景 -- 重新定义业务产品线 -- 属于业务与产品方向 - -**AI 应用层**（Harness Engineering 的落地层）： -- 偏业务 + 方案落地 -- 利用开源模型构建垂直应用 -- 2026 年最稀缺、最具机会的方向 - -**AI 大模型算法层**： -- 不做基座模型（GPT-4、Qwen3.6 等基座由大厂完成） -- 聚焦于模型的**垂直能力提升** -- 包括： - - **SFT 微调**（Supervised Fine-Tuning） - - **RLHF**（Reinforcement Learning from Human Feedback） - - **对齐训练**（Alignment） - - **安全护栏**（Safety Guardrails） - -### 1.3 职业选择建议 - -``` -技术背景 → AI 应用层（最佳入场点） -产品背景 → AI 产品化层 → 可延伸至应用层 -算法背景 → AI 大模型算法层 -``` - -> **核心观点**：2026 年是**大模型应用落地**的关键年份，大多数人的机会在于 AI 应用层。 - ---- - -## 2. 大模型应用的三层进化范式 - -从时间维度看，AI 应用开发经历了三个阶段的范式转变： - -``` -2022-2024：Prompt Engineering 时代 - ↓ -2025：Context Engineering 时代 - ↓ -2026：Agent Harness / Harness Engineering 时代 -``` - ---- - -## 3. Prompt Engineering：让模型"会说" - -### 3.1 时间窗口 - -2022 年 11 月 ChatGPT 发布后成为焦点 - -### 3.2 核心问题 - -**解决"如何说"的问题**——如何更好地与模型沟通，让模型生成更高质量的回答。 - -### 3.3 技术特征 - -- 单对单对话模式 -- 用户输入一句话，模型返回一句话 -- 关注点：如何编写有效的 Prompt - -### 3.4 典型场景 - -``` -用户 → Prompt → LLM → Response -``` - ---- - -## 4. Context Engineering：解决上下文膨胀问题 - -### 4.1 时间窗口 - -2025 年 - -### 4.2 核心问题 - -随着 Agent 开发引入工具调用（如 MCP 协议），上下文窗口中的内容越来越多，导致模型能力反而下降、**幻觉（Hallucination）** 问题加剧。 - -### 4.3 核心目标 - -**解决"有什么"的问题**——让模型清楚地知道当前拥有哪些信息。 - -### 4.4 关键概念 - -**Context Window（上下文窗口）**： -- 多轮对话的执行过程中，所有历史信息都存储在上下文窗口中 -- 当内容越来越多时，模型会出现"迷失"现象 - -**迷失问题（Lost in Context）**： -- 模型在大量上下文中无法准确识别关键信息 -- 导致： - - 响应质量下降 - - 幻觉增加 - - 任务执行失败 - -### 4.5 Context Engineering 的职责 - -| 问题 | 解决方案 | -|------|----------| -| 上下文过长 | 上下文压缩、摘要 | -| 信息混乱 | 结构化组织、分类管理 | -| 关键信息被淹没 | 关键信息突出、检索增强 | - ---- - -## 5. Agent Harness 核心架构 - -### 5.1 官方来源 - -本文档基于 **LangChain 团队**发布的关于 Agent Harness 的官方博客，是全球最懂 Agent 的团队发布的系统性技术文档。 - -### 5.2 Agent Harness 的定位 - -**Harness** 的本意是"驾驭、利用"，Agent Harness 即对 Agent 的工程化驾驭框架。 - -### 5.3 核心架构体系 - -``` -┌─────────────────────────────────────────┐ -│ Agent Harness │ -├─────────────────────────────────────────┤ -│ ┌─────────────┐ ┌─────────────────┐ │ -│ │ 规划层 │ │ 执行层 │ │ -│ │ Planning │ │ Execution │ │ -│ └─────────────┘ └─────────────────┘ │ -│ ┌─────────────┐ ┌─────────────────┐ │ -│ │ 工具层 │ │ 记忆层 │ │ -│ │ Tools │ │ Memory │ │ -│ └─────────────┘ └─────────────────┘ │ -│ ┌─────────────┐ ┌─────────────────┐ │ -│ │ 感知层 │ │ 评估层 │ │ -│ │ Perception │ │ Evaluation │ │ -│ └─────────────┘ └─────────────────┘ │ -└─────────────────────────────────────────┘ -``` - -### 5.4 各层核心组件详解 - -#### 5.4.1 规划层（Planning） - -**职责**：将复杂任务分解为可执行的子任务 - -**关键技术**： -- **任务分解**（Task Decomposition） -- **思维链**（Chain of Thought, CoT） -- **子任务规划** - -#### 5.4.2 执行层（Execution） - -**职责**：执行规划层生成的子任务 - -**关键技术**： -- **工具调用**（Tool Calling） -- **动作执行**（Action Execution） -- **结果反馈** - -#### 5.4.3 工具层（Tools） - -**职责**：为 Agent 提供外部能力 - -**典型工具类型**： -- **MCP 工具**（Model Context Protocol） -- API 调用 -- 搜索引擎 -- 数据库查询 -- 文件系统操作 - -#### 5.4.4 记忆层（Memory） - -**职责**：存储和管理 Agent 的历史状态与上下文 - -**记忆类型**： -| 类型 | 说明 | 用途 | -|------|------|------| -| 短期记忆 | 当前对话上下文 | 处理即时任务 | -| 长期记忆 | 持久化存储 | 跨会话经验积累 | -| 工作记忆 | 工作过程中的临时状态 | 任务执行中间态 | - -#### 5.4.5 感知层（Perception） - -**职责**：接收和处理外部输入 - -**感知内容**： -- 用户指令 -- 文档输入 -- 多模态信息（图像、音频等） -- 环境状态 - -#### 5.4.6 评估层（Evaluation） - -**职责**：评估 Agent 执行结果的质量 - -**评估维度**： -- 输出正确性 -- 任务完成度 -- 安全性检查 -- 效率评估 - ---- - -## 6. Harness Engineering 的工程实践 - -### 6.1 定义 - -**Harness Engineering** 是系统性地构建、测试、优化 Agent 行为能力的工程学科。 - -### 6.2 与传统软件工程的区别 - -| 维度 | 传统软件工程 | Harness Engineering | -|------|-------------|---------------------| -| 不确定性 | 低（确定性逻辑） | 高（概率性输出） | -| 测试难度 | 可精确断言 | 需概率评估 | -| 调试方法 | 日志追踪 | 行为轨迹分析 | -| 质量保障 | 单元测试 + 集成测试 | 评估驱动开发 | - -### 6.3 核心工程实践 - -#### 6.3.1 评估驱动开发（Evaluation-Driven Development） - -``` -设计评估指标 → 开发 Agent → 持续评估 → 迭代优化 -``` - -#### 6.3.2 行为可复现性 - -- 通过种子（seed）控制随机性 -- 构建可测试的 Agent 行为 -- 建立回归测试机制 - -#### 6.3.3 多维度评测 - -- **任务完成率**：Agent 是否完成目标 -- **效率指标**：消耗的 Token 数量、执行时间 -- **质量评分**：输出的人力评估 -- **安全性检查**：有害内容过滤 - -### 6.4 LangChain Agent Harness 的工具链 - -``` -┌──────────────────────────────────────────┐ -│ LangChain 生态 │ -├──────────────────────────────────────────┤ -│ LangChain │ Agent 开发框架 │ -│ LangSmith │ 追踪与评估平台 │ -│ LangServe │ Agent 部署服务 │ -│ LangGraph │ Agent 工作流编排 │ -└──────────────────────────────────────────┘ -``` - ---- - -## 7. 补充：观众反馈中的有价值观点 - -> 本节整理自视频弹幕中观众的补充与讨论 - -### 7.1 关于 Context Engineering 的延伸 - -- Context Engineering 不仅解决"上下文膨胀"，还需要考虑**信息密度**问题 -- 有效上下文 = 去除噪音后的核心信息 -- 常用的压缩策略：LLM 摘要、关键信息提取、信息去重 - -### 7.2 关于 Agent 幻觉的处理 - -- 幻觉问题在单轮对话中已存在 -- 在多轮 Agent 执行中，幻觉会被**级联放大** -- 建议在每个关键步骤增加**自我校验**机制 - -### 7.3 关于实际落地的建议 - -- 不要过度追求 Agent 的自主性，**人机协同**往往更可靠 -- 初期应聚焦垂直场景，积累领域知识后再扩展 - ---- - -## 附录：关键术语表 - -| 英文术语 | 中文解释 | -|----------|----------| -| **Harness Engineering** | 驾驭工程，Agent 的系统工程化方法 | -| **Agent Harness** | Agent 框架的核心组件集合 | -| **Prompt Engineering** | 提示词工程，优化人机交互质量 | -| **Context Engineering** | 上下文工程，管理信息输入质量 | -| **Hallucination** | 幻觉，LLM 生成虚假或不准确内容 | -| **Chain of Thought (CoT)** | 思维链，引导模型展示推理过程 | -| **SFT** | Supervised Fine-Tuning，有监督微调 | -| **RLHF** | Reinforcement Learning from Human Feedback，基于人类反馈的强化学习 | -| **MCP** | Model Context Protocol，模型上下文协议 | -| **Agent** | 智能体，能够自主执行任务的 AI 系统 | - ---- - -> **笔记说明**：本笔记基于 LangChain 团队发布的官方博客整理，聚焦于 Agent Harness 的技术架构与工程实践。视频原版对三层架构有详细展开，读者可根据需要结合原视频深入理解各层级的技术细节。 \ No newline at end of file diff --git a/InBox/OpenAI_Skill的自动评分器怎么搭_BV1HWd6BsEmG_笔记.md b/InBox/OpenAI_Skill的自动评分器怎么搭_BV1HWd6BsEmG_笔记.md deleted file mode 100644 index a45374e..0000000 --- a/InBox/OpenAI_Skill的自动评分器怎么搭_BV1HWd6BsEmG_笔记.md +++ /dev/null @@ -1,316 +0,0 @@ -# OpenAI Skill 自动评分器构建指南 - -## 一、为什么需要评分器 - -当更新一个 Skill 并执行完成后，**表面结果正常不代表真的变好了**。核心问题是： - -- Skill 是否真的完成了预期任务？ -- 修改是否引入了新的问题（回归）？ -- 如何在不同版本之间进行性能比较？ - -评分器的职责就是回答这些问题，让 Skill 的质量变化可衡量、可追踪。 - ---- - -## 二、运行轨迹记录 - -### 2.1 什么是运行轨迹 - -评分的前提是有东西可以打分。OpenAI 的做法是使用 **CodeExec JSON** 记录 Skill 的完整执行过程。 - -### 2.2 配置方式 - -```json -{ - "code_exec": true // 启用后输出结构化执行记录 -} -``` - -### 2.3 记录内容 - -启用后，Skill 每执行一步都会输出结构化记录，包括： - -- 跑了什么命令 -- 创建了什么文件 -- 执行顺序 -- 时间戳 - -### 2.4 关键特性 - -| 特性 | 说明 | -|------|------| -| **完整性** | 记录完整执行流程，而非日志摘要 | -| **可解析性** | 结构化数据，可被程序直接读取 | -| **可调试性** | 失败时可精确定位到具体哪一步出错 | - -> 没有运行轨迹，评分器只能看最终产物，无法分析执行过程。 - ---- - -## 三、评分器类型 - -### 3.1 确定性检查（Deterministic Checks） - -#### 3.1.1 原理 - -纯代码规则驱动的检查，**不用大模型**，写死判断逻辑，程序直接对着运行轨迹核对。 - -#### 3.1.2 典型检查项 - -``` -- 有没有执行 npm install -- 有没有创建 package.json -- 命令执行顺序是否符合预期 -- 是否在指定目录执行操作 -``` - -#### 3.1.3 核心特性 - -| 特性 | 说明 | -|------|------| -| **确定性** | 同样行为每次判断结果一致，没有模糊地带 | -| **可调试** | 一旦失败，打开记录文件即可看到从哪一步开始偏离 | - -#### 3.1.4 局限性 - -确定性检查能回答"**基础动作做了没有**"，但无法回答"**做出来的东西是不是你想要的样子**"。 - ---- - -### 3.2 评分细则检查（Rubric-based Checks） - -#### 3.2.1 原理 - -使用 **LLM 作为裁判**，读取仓库内容，按预定义的评分细则输出结构化打分结果。 - -#### 3.2.2 适用场景 - -很多 Skill 的验收标准本来就是软性规则，例如： - -- 代码结构是否干净 -- 组件组织是否符合团队约定 -- 样式配置是否按既定风格落地 -- 命名规范是否遵循 - -#### 3.2.3 评分细则的拆解方法 - -把模糊的质量标准拆成若干个**可独立判断的维度**： - -| 模糊标准 | 拆解后的维度 | -|----------|--------------| -| 代码质量好 | 组件是否按功能分目录 | -| | 是否有未使用的引用 | -| | 样式类名是否遵循命名约定 | -| | 配置项是否集中管理 | - -#### 3.2.4 关键要求：锁定输出格式 - -**必须提前定义输出模板**，规定模型必须输出哪些字段： - -```json -{ - "passed": true/false, - "total_score": 85, - "dimensions": [ - { - "name": "component_organization", - "score": 90, - "reason": "组件按功能正确分目录" - }, - { - "name": "unused_imports", - "score": 70, - "reason": "发现3处未使用的import" - } - ] -} -``` - -#### 3.2.5 为什么必须锁死格式 - -| 自由输出 | 锁死格式 | -|----------|----------| -| 每次措辞不同 | 格式统一 | -| 无法跨版本比较 | 结果可量化 | -| 无法进自动化流程 | 可直接集成 CI/CD | -| 输出是"审稿意见" | 输出是"评估数据" | - ---- - -## 四、评分器组合策略 - -### 4.1 分工明确 - -``` -确定性检查 ──→ 抓底线（基础动作有没有发生） -评分细则检查 ──→ 抓质量（做出来的东西像不像你要的） -输出格式锁定 ──→ 防飘移（每次评分结果一致） -``` - -### 4.2 集成到流水线 - -这套组合设计之初就面向 **持续集成（CI）**： - -- 不再依赖工程师手动触发测试 -- 成为持续运行的回归守门员 -- Skill 每次更新都会自动验证 - ---- - -## 五、6 类扩展检查 - -在基础评分器之上，可按需叠加以下检查： - -### 5.1 命令数与循环检测 - -``` -检查运行记录里执行了多少条命令 -``` - -**目的**：检测行为退化 - -> 案例：如果一个 Skill 以前 6 步能完成，现在要 18 步，表面上任务还是完成了，但系统正在变差。 - -### 5.2 消耗量追踪 - -``` -记录每次运行消耗的 token 数量 -``` - -**目的**：防止 Skill 越来越臃肿 - -- 每次执行越来越贵 -- 每次执行越来越慢 - -### 5.3 构建检查 - -```bash -# skill 完成后直接执行构建命令 -npm run build -``` - -**目的**：端到端验证 - -- 很多项目表面完成，构建就露馅 -- 成本低，应该**默认开启** - -### 5.4 运行时冒烟检查 - -```bash -# 启动开发服务器 -npm run dev -# 发送测试请求 -curl http://localhost:3000/api/health -``` - -**目的**：验证服务是否真正可用 - -> 注意：这类检查更慢，按风险等级决定是否每次都执行。 - -### 5.5 仓库清洁度检查 - -``` -检查任务完成后是否出现不该有的文件 -``` - -**目的**：确保系统没有被"弄脏" - -### 5.6 权限回归检查 - -``` -验证 skill 是否还能在最小权限下正常工作 -``` - -**目的**：防止权限漂移 - -- 某次改动后悄悄开始依赖更高权限 -- 权限漂移在自动化后会变成结构性风险 - -### 5.7 扩展策略 - -``` -原文建议：先加快速检查，再按风险叠加慢检查 - 不是一次全上，是按需扩展 -``` - -| 检查类型 | 速度 | 建议频率 | -|----------|------|----------| -| 命令数检测 | 快 | 每次 | -| 消耗量追踪 | 快 | 每次 | -| 仓库清洁度 | 快 | 每次 | -| 构建检查 | 中 | 每次 | -| 运行时冒烟 | 慢 | 按风险 | -| 权限回归 | 慢 | 定期 | - ---- - -## 六、5 条核心原则 - -### 原则一：量真正重要的东西 - -> Don't measure for the sake of measuring. First, think about what you'd actually care about if it got worse. - -**不要为了有指标而有指标**，先想清楚什么变差了，你会真的在意。 - -### 原则二：先写清晰可检查的定义 - -> If the success criteria are fuzzy, the evaluation will be too. - -验收标准模糊，评估就没有意义。**先把"什么叫做对"写成可执行的判断**。 - -### 原则三：把评估扎在真实行为上 - -> Record the full execution trace and write deterministic checks around the actual actions taken. - -记录 Skill 的完整运行轨迹，围绕实际执行的动作写确定性检查。 - -### 原则四：规则不够时，再让模型补上 - -> Use rubric-based evals to handle quality judgments that rules can't cover, not as a replacement. - -用评分细则处理规则覆盖不了的质量判断，**顺序不能反**。确定性检查在前，LLM 评分在后。 - -### 原则五：让真实失败去驱动样本增长 - -> Every time you manually fix something, turn it into a test case. - -每次手动修复都是一个信号，**把它变成测试用例**，让 Skill 持续把这件事做对。 - ---- - -## 七、整体流程图 - -``` -┌─────────────────────────────────────────────────────────┐ -│ Skill 执行 │ -└─────────────────┬───────────────────────────────────────┘ - ▼ -┌─────────────────────────────────────────────────────────┐ -│ CodeExec JSON 记录运行轨迹 │ -└─────────────────┬───────────────────────────────────────┘ - ▼ - ┌───────┴───────┐ - ▼ ▼ -┌───────────────┐ ┌─────────────────┐ -│ 确定性检查 │ │ 评分细则检查 │ -│ (规则驱动) │ │ (LLM 裁判) │ -└───────┬───────┘ └────────┬────────┘ - ▼ ▼ - └────────┬─────────┘ - ▼ -┌─────────────────────────────────────────────────────────┐ -│ 结构化评估结果（跨版本可比较） │ -└─────────────────┬───────────────────────────────────────┘ - ▼ -┌─────────────────────────────────────────────────────────┐ -│ 进入 CI/CD 流水线 │ -└─────────────────────────────────────────────────────────┘ -``` - ---- - -## 八、参考资料 - -- 原文标题：Testing Agent Skills Systematically with Evals -- 原文链接：https://developers.openai.com/blog/eval-skills -- 视频来源：慢学AI（BV1HWd6BsEmG） \ No newline at end of file diff --git a/InBox/Shopify_内部_Agent__为什么不准员工私聊___AI_native组织要的不是个人提效_是组织自进化_BV1i77X6pE1C_笔记.md b/InBox/Shopify_内部_Agent__为什么不准员工私聊___AI_native组织要的不是个人提效_是组织自进化_BV1i77X6pE1C_笔记.md deleted file mode 100644 index 6f70fde..0000000 --- a/InBox/Shopify_内部_Agent__为什么不准员工私聊___AI_native组织要的不是个人提效_是组织自进化_BV1i77X6pE1C_笔记.md +++ /dev/null @@ -1,187 +0,0 @@ -# Shopify 内部 Agent River：为什么不准员工私聊？ - -## 核心观点 - -**AI-native 组织的门槛不是个人更快，而是组织能从经验中学习、能自进化。** - -单纯给员工配备私人 AI Agent，可能让每个人变快，但组织本身没有进化。 - ---- - -## 问题背景：企业对 AI 的常见误区 - -### 误区做法 - -给每个员工开 AI 账号，配一个自己的 Agent，让他跑在： - -- 本地终端 -- 编辑器私人对话框 -- 私聊窗口里 - -### 效果 - -- 查问题更快 -- 改代码更快 -- 跑测试更快 - -### 真正的门槛 - -> 更硬的问题是：**组织能不能从这些 AI 工作里学习？** - -能否把一次排查、一次修复、一次好判断，变成后面所有人和所有 Agent 都能继承的经验？ - ---- - -## 核心对比：私人 Agent 的天花板 - -| 维度 | 私人 Agent | 公开 Agent（River） | -|------|-----------|---------------------| -| 服务范围 | 键盘前那个人 | 整个团队 | -| 上下文来源 | 单人输入 | 多人补充 | -| 经验沉淀 | 个人日志 | 组织语料 | -| 复现性 | 低（过程不可见） | 高（可搜索、复用） | -| 学习能力 | Agent 之间互相学不到 | 团队协作促进 Agent 进化 | - -### 私人 Agent 的局限性 - -以一次排查偶发失败测试为例： - -1. 你昨天怎么定位问题？ -2. 中间错了哪些方向？ -3. 最后是哪条线索把问题收住？ - -这些问题**即使留在日志里，也只是事后材料**： - -- 不会天然变成多人协作现场 -- 别的工程师不会在过程中看到 -- 不会有人顺手补一个约束 -- 下一次类似情况，不会自动从这条路径开始 - ---- - -## River 的设计选择 - -### 基本工作方式 - -River 是 Shopify 内部 Slack 里的 AI Agent： - -- 员工**不在私聊窗口找他**，要到内部公开频道里 @ 他 -- River 会执行：读代码、跑测试、开 PR、查数据仓库、看生产链路记录 -- 必要时，River 还会**反驳他认为不好的计划** - -### 硬性产品约束 - -``` -只支持公开频道工作，不支持一对一私聊 -``` - -每一次和 River 的对话，都会变成一条 Slack 线程记录，**默认对 Shopify 内部员工可见**。 - -> 注：这里的"公开"指 Shopify 内部 Slack 范围内可见，不是互联网公开。 - ---- - -## 公开线程的工作机制 - -### 典型场景 - -``` -1. 工程师 A 在频道提问 - ↓ -2. River 开始工作：读文件、跑查询、贴出部分发现 - ↓ -3. 工程师 B 看到（通过频道链接或被人拉进来） - ↓ -4. B 补一句关键约束： - - "这个表不能这样查" - - "这个服务刚迁移过" - - "这个测试以前失败过，原因可能不在这里" - - "这个方案会影响另一个团队" - ↓ -5. River 吸收新上下文，继续往下查 -``` - -### 公开 vs 私人的关键差别 - -- **私人对话**：AI 多数只继承一个人的上下文 -- **公开线程**：AI 进入的是一个**多人协作现场** - ---- - -## 组织学习机制：语料挖掘与回写 - -公开线程记录会形成一套**可挖掘的组织语料**，Shopify 会： - -1. **挖掘反复出现的模式** -2. 把这些模式回写到 River 的： - - 技能（Skills） - - 提示词（Prompts） - - 默认动作（Default Actions） - -### 具体沉淀内容 - -| 沉淀内容 | 说明 | -|---------|------| -| 排查路径 | 哪些排查路径有效 | -| 工程约束 | 哪些工程约束应该默认带上 | -| 提示词/技能 | 哪些提示词和技能动作可以沉淀下来 | - -### 核心机制 - -``` -一个人硬啃出来的修复办法 → 下一个人的起点 -一个线程里反复出现的约束 → River 以后更容易带上的上下文 -``` - -> **一次好的排查，不再只是某个人和某个 Agent 的私有经历，而是开始教会后面的线程。** - ---- - -## 边界与限制 - -### 不等于禁止所有私聊 - -企业**不是不能有任何 AI 私聊**，而是 River 这个 Agent 坚持不做私聊入口。 - -### 需要边界控制的场景 - -以下敏感问题仍然要有边界： - -- 权限相关 -- 安全相关 -- 人事相关 -- 法务相关 - -### River 的定位 - -River 处理的是**那些值得被组织记住的工作**，而不是所有对话。 - ---- - -## 核心启示 - -### 对老板和技术负责人的问题清单 - -部署 AI Agent 时，不仅要问： - -- ❌ 员工有没有 Agent？ -- ❌ 对话日志能不能回收？ -- ❌ 个人效率有没有提升？ - -更要问： - -- ✅ 这些 Agent 对话**会不会教会后面的线程**？ -- ✅ 员工用 AI 解决问题的过程，是一份**后台日志**，还是一个**团队能参与、能接力、能复用的工作现场**？ - -### 结论 - -| 类型 | 结果 | -|------|------| -| 如果只是后台日志 | 一堆分散的个人提效，每个人都快了一点，但组织没有变聪明 | -| 如果是可协作的工作现场 | 组织从每次 AI 工作中学习，实现**自进化** | - -### 金句 - -> **私人 Agent 的天花板是键盘前那个人。** -> -> **公开 Agent 的价值是让后面的线程不从零开始。** \ No newline at end of file diff --git a/InBox/milky_BV17y7U6EER5.md b/InBox/milky_BV17y7U6EER5.md deleted file mode 100644 index 172cdd4..0000000 --- a/InBox/milky_BV17y7U6EER5.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -title: "[Milky] 为您整理《北大Agent新范式：不改模型权重，效果翻倍北大搞出Agent新范式：不改模型权重，效果接近翻倍》笔记 | BV17y7U6EER5" -source: "milky@4ueo.com" -date: 2026-06-09 21:17 -tags: [milky, bilibili, notes] -email_id: 2068 ---- - -Milky 为您整理了《北大Agent新范式：不改模型权重，效果翻倍北大搞出Agent新范式：不改模型权重，效果接近翻倍》 | BV17y7U6EER5 笔记。 - -Life Harnessness：北大Agent优化新范式 - -核心发现 - -传统Agent优化的核心假设被推翻：Agent的效果并非完全由模型能力决定。北京大学这篇论文证明，在很多情况下，Agent的失败不是因为模型"笨"，而是因为模型与环境之间的接口不匹配。 - - -Agent的本质再定义 - -传统观点认为：Agent ≈ LLM，能力强则Agent强 - -论文新观点：Agent是一个完整的交互循环系统，包含以下组件： - -` -环境 → 观测 → 运行时系统 → 工具定义 → 动作模型 → 输出动作 - ↑ ↓ - ←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←← -` - -| 组件 | 说明 | -|------|------| -| 运行环境 | 环境给观测，定义工具和动作 | -| 动作执行器 | 模型输出动作，执行器执行 | -| 反馈循环 | 执行结果反馈回来更新下一步决策 | - -关键洞察：模型输出相同，结果可能完全不同。整个行为是模型和运行时环境共同决定的。 - - -问题根源：接口层不匹配 - -传统Agent常见的失败场景： - -模型不知道API的调用格式 -不知道什么动作是合法的 -不知道反馈信号是什么意思 -不知道什么时候该停止 - -传统解决方案：通过SFT（监督微调）把这些知识灌进模型权重 - -新方案思路：为什么把环境特定的知识硬编码到模型里？这些东西应该在接口层处理。 - - -Life Harnessness 框架 - -核心思路 - -不改模型权重，只改运行时接口 - -从训练轨迹中学习，把反复出现的交互失败转换成可复用的干预。 - -四个维度的可复用干预 - -| 维度 | 功能 | 说明 | -|------|------|------| -| 环境契约 (Environment Contract) | 告诉模型环境规则 | 明确这个环境中什么能做、什么不能做 | -| 程序技能 (Program Skill) | 任务分解标准化 | 把复杂任务拆解成标准流程 | -| 动作实现 (Action Implementation) | 格式转换 | 把模型的高层意图转换成环境能理解的精确格式 | -| 轨迹调控 (Trajectory Regulation) | 流程控制 | 决定什么时候该回溯、什么时候该停止、什么时候该重试 | - -核心特征 - -训练后固定：Harness一旦训练好就固定下来，评估时不再改变 -非动态调整：不是推理时还在动态调整的东西 -标准化接口适配层：类似于给Agent配了一个"经验丰富的项目经理" - - -实验结果 - -评估规模 - -7个确定性环境 -18个模型骨干（从最小到最大全覆盖） -126个模型-环境组合 - -效果数据 - -| 指标 | 数值 | -|------|------| -| 有提升的组合数 | 116 / 126 | -| 平均相对提升 | 88.5% | - -88.5%是接近翻倍的提升，不是小数点后一位的微弱改进。 - -迁移能力验证 - -使用 Qwen-34B 的训练轨迹进化出来的Harness -能直接迁移到其他 17个模型 上 -从最小到最大的模型全部适用 - -关键发现：这说明Harness抓到的不是某个模型的特性行为，而是环境本身的结构。 - - -范式转变 - -| 维度 | 旧范式（模型中心） | 新范式（接口中心） | -|------|-------------------|-------------------| -| 优化方向 | 调模型：SFT、蒸馏、更大参数 | 调接口：优化运行时适配层 | -| 适用场景 | Agent不行就调模型 | Agent不行，先看接口是否有问题 | -| 关系定位 | 互补，非替代 | 互补，非替代 | - - -局限性 - -最适合确定性、规则型的环境：需要大量创造性、开放性的任务可能效果不明显 -依赖训练轨迹：需要有足够多的失败案例才能总结干预规则 -干预维度固定：目前是4个维度，能否扩展到更多类型环境还需验证 - - -未来发展方向 - -自动发现与进化 -不用人工定义4个维度，让系统自己发现需要什么样的接口适配 - -跨环境迁移 -在一个环境上学到的接口适配，能否用到另一个类似环境 - -协同进化（最具潜力） -Harness和模型的协同进化，接口层与模型共同进化 - - -对普通人的意义 - -短期 -企业级Agent体验大幅提升 -"你得用精确话术跟AI说话"的情况越来越少 -接口层帮你把意图转换成系统能理解的格式 - -中期 -Agent开发门槛大幅降低 -不需要海量数据去SFT大模型 -只要把接口适配做好，中等模型就能有很好的效果 - -长期 -可能改变整个AI产业的分工： - - 大模型厂商：负责通用推理能力 - - 垂直领域厂商：负责接口适配层 -比现在每个公司都训练自己的模型更高效 -Harness可解释、可审计，解决监管问题 - - -核心启示 - -不要一遇到问题就想着堆算力、堆参数。有时候真正的突破来自于对问题本身的重新定义。 -不是模型不行，可能是我们的接口不行。 -换个角度看问题，整个世界都不一样了。 - -────────────────────────────── -Generated by MilkyAi@Bilibili: https://space.bilibili.com/3461574540921489 \ No newline at end of file diff --git a/InBox/milky_BV1ArVU62Eac.md b/InBox/milky_BV1ArVU62Eac.md deleted file mode 100644 index 932c6bd..0000000 --- a/InBox/milky_BV1ArVU62Eac.md +++ /dev/null @@ -1,435 +0,0 @@ ---- -title: "[Milky] 为您整理《面向架构编程范式，超越OOP和MVC》笔记 | BV1ArVU62Eac" -source: "milky@4ueo.com" -date: 2026-06-09 21:17 -tags: [milky, bilibili, notes] -email_id: 2062 ---- - -Milky 为您整理了《面向架构编程范式，超越OOP和MVC》 | BV1ArVU62Eac 笔记。 - -面向架构编程范式：超越 OOP 和 MVC - -一、编程范式的本质 - -1.1 什么是编程范式 - -编程范式（Programming Paradigm）是指程序的表达方式，它不决定程序能实现什么功能，只决定能否方便、易懂地表达功能。 - -` -过程式表达： -f1(); f2(); f3(); - -面向对象表达： -obj.f1(); obj.f2(); obj.f3(); -` - -两段代码功能完全相同，都是先执行 F1，再执行 F2、F3。表达方式不同，但实现的功能是一样的。 - -关键结论： -面向对象能写的程序，过程式也能写 -反过来也一样 -无论用哪种范式，你的程序都能实现买东西这个功能 - -1.2 编程范式的真正目的 - -编程范式的根本目的是为了大规模代码和大规模团队分工合作。 - -当代码量膨胀到： -成千上万行 -几十万行 -上百万行 - -当团队有上百号程序员时，需要将整个项目拆分成多个模块，每个组负责一个模块。程序员需要调用其他人开发的模块，这就引出了模块封装隔离的概念。 - -1.3 模块封装隔离的概念 - -把模块的运行原理封装在模块内，只暴露接口。模块的调用者只需要会操作接口，不需要理解模块内部的运行原理，就能使用这个模块。 - -如果做不好封装隔离： -调用其他模块时，需要充分理解那个模块的内部原理 -整个项目可能有成百上千个模块 -需要懂上百个模块的内部原理，才能写自己的程序 -这在实际项目中是不现实的 - -二、面向对象与模块封装 - -2.1 面向对象的封装优势 - -面向对象提供 class 语法，程序员可以很方便地把程序拆分成多个部分： - -`python -class A: - def interface1(self): ... - def interface2(self): ... - -class B: - def interface1(self): ... - def interface3(self): ... - -class C: - def interface2(self): ... - def interface3(self): ... -` - -每个类是一个模块，每个模块下有若干接口（可外部调用的函数）。实际项目中，每个类可能有几百上千行代码，好几十个函数接口，分别由不同程序员开发。 - -2.2 不只是面向对象在做模块封装 - -`python -过程式模块封装 -module_a.py -def f1(): ... -def f2(): ... - -module_b.py -def f3(): ... - -main.py -import module_a -import module_b -module_a.f1() -module_b.f3() -` - -效果和 class 一样。但这种方案太笨重了，比用类要复杂。 - -2.3 工程成本原则："太麻烦，没人用" - -工程问题和数学问题不同： -数学算法不需要考虑成本 -工程问题最看重的就是成本 - -如果一个东西的使用成本大于收益，那根本就不会有人去用它。即使这是个好东西。 - -这会导致： -只有那些最重要的功能才能采用该方案 -一些边边角角的小功能则完全没法用 -用它反而会让程序更复杂 - -结论：面向对象比过程式高级，因为面向对象提供了一种方便的用于封装接口的语法。 - -2.4 class 的本质澄清 - -class 的本质是借口（Interface）。 - -一个 class 定义得好不好，取决于： -有没有做好功能的封装 -有没有暴露出正确的接口 - -至于汽车有几个轮子、像不像鸭子，根本无关紧要。 - -正确的类比：手机开机按钮就是一个接口。按下开机键后，手机进行一系列复杂的初始化过程，而用户不需要懂这个过程，只要会按开机键就可以了。 - -三、面向对象的设计缺陷 - -3.1 继承的问题：代码无法复用 - -使用继承进行代码复用的问题： - -` - A - / \ - B C -` - -假设 F1、F2、F3 的代码写在 A 类中。用户只需要 F1 和 F3，无法复用这段代码——因为继承会把 F2 也带进来。 - -3.2 组合优于继承 - -组合思想： -` - Main - / | \ - A B C -` - -子模块拆分成 A 类、B 类、C 类。写 Main 类的程序员需要 F1、F2、F3 中的哪个就组哪个，不需要的就不组。既简单又灵活，完胜继承链条。 - -组合是一种思想，并不局限于某种特定语法。 - -3.3 多重继承的致命问题：重名冲突 - -这是一个记账器例子，子模块 A 和子模块 C 有一个重名的函数 F1，这会造成冲突。 - -有人会说：把其中一个函数重命名为其他名字不就得了？ - -现实项目里没这么简单： -A 模块和 C 模块可能分别是两家公司开发的开源库 -每个库可能有几万行代码 -F1 函数的调用链可能非常复杂 -如果要改名，就要改动整条调用链 -项目还可能存在其他库依赖这两个库的命名 -要改的话就要连同其他库一起改 - -真正要命的是：原库可能已经在业界运行过多年，安全性和稳定性有保证。改了源代码就要承担出 bug 的风险。 - -3.4 这种改动要求是不合理的 - -对比其他领域的例子： -显卡上有一个电容 -主板上的电容可能和显卡上的电容重名或型号相同 -不会产生命名冲突 - -工业产品的拆分逻辑都是组合。子模块中存在重名零件，根本不影响任何东西。这才是正确的封装逻辑。 - -全天底下各行各业，就面向对象搞特殊。 - -四、MVC 方案的局限 - -4.1 MVC 就是组合 - -MVC 把功能拆分成最细的 Model（数据）和 View（函数），再通过 Controller 组合起来： - -`python -class MainController: - def init(self): - self.modelA = ModelA() - self.modelB = ModelB() - self.viewC = ViewC() -` - -用哪个 model 或 view 函数就组哪个，不用的就不组。 - -虽然 A 和 B 存在重名函数，但是并不会产生冲突。 - -4.2 MVC 的问题：抽象泄露 - -在 Main 模块中初始化 A 和 B，并交换两者的指针时，存在一个问题： - -A 和 B 的初始化逻辑泄露到 Main 这一层了。 - -在实际项目中： -A 和 B 可能是别的程序员写的底层库 -Main 模块由业务层程序员写 -底层库的逻辑本不应该泄露到业务层 - -正确的封装：每一层程序员将本层的逻辑封装在本层。不应该要求使用者理解本层逻辑，只要使用者会用即可。 - -4.3 初始化逻辑的复杂性 - -实际项目中初始化可能存在非常复杂的交互关系： - -` -A 先初始化几步 -把中间结果传给 B 初始化 -再把中间结果传回给 A，继续初始化 -` - -另外，实际项目中子模块可能不止两个，很可能存在多个子模块初始化过程相互交织的情况。这要求 Main 程序员必须非常理解 A 和 B 等子模块的内部实现，才能写出 Main 层。 - -4.4 抽象泄露导致的问题 - -问题 1：模块无法替换 - -库存程序员无法写出一个模块 C 去替换模块 B，因为 Main 层耦合了模块 B 的初始化逻辑。模块 C 只要初始化逻辑稍有不同，就无法替换 B。 - -问题 2：中间层方案要么灵活性差，要么代码极为复杂 - -一种方案是加一个中间层（Middle Layer），中间层由 A 或 B 这一层的程序员编写。Main 层程序员无需理解中间层的内部实现。 - -但存在两种情况： -中间层代码最为简单，但灵活性差：Main 程序员无法选择组合哪几个子模块或者组合其他同接口的子模块。比如 Main 实现不了组合 A、C、D 三个模块，因为中间层只实现了 A、B 组合 -让中间层适配，由 Main 层程序员自由选择组合哪些子模块：中间层的代码变得极为复杂 - -记住"太麻烦，没人用"原则。 - -4.5 依赖注入和微服务 - -依赖注入或微服务确实解决了抽象泄露问题。这两个方案都能进行模块替换。 - -衡量封装得好不好，可以看此模块能不能替换成同类模块。 - -唯一的问题是：这俩方案太重型了。使用成本太高。 - -五、时间悖论问题 - -5.1 时间悖论的根源 - -回到第一种方案，分析根本原因： - -` -A 模块 ←→ B 模块 - ↓ - Main 模块 -` - -这里存在一个时间悖论： -A 模块和 B 模块是先写出来的 -Main 模块是在之后的某个时间点写出来的 - -如果想避免抽象泄露到 Main 层，程序员需要在 Main 类出现前表达交换 A 和 B 的指针这件事。然而，这做不到，因为 Main 只有在 A 和 B 存在后才出现。 - -5.2 语法限制导致的困境 - -但这是因为语法限制。假设编译器支持使用抽象名称作为指针名，其实是不存在时间悖论的。 - -六、新语法设计方案 - -6.1 核心语法设计 - -语法基本沿袭继承，但在调用函数或成员变量时，使用该成员的整个名称链： - -| 符号 | 含义 | -|------|------| -| ..（两个点） | 向上级寻找 | -| ...（三个点） | 向平级寻找 | -| .（一个点） | 向下级寻找 | - -也可以使用上斜杠、横杠和下斜杠表示。符号不重要，重要的是原理。 - -6.2 use 关键字 - -当名称列太长时，可以使用 use 关键字进行缩写： - -`python -use module_a.b.c as abc -` - -实际上，这个 use 关键字本质上和传统语言里包管理里的 include 或 import 是相同的东西。 - -6.3 super 关键字 - -代码中有个 super 关键字。ABCD 模块可能是先写出来的，Main 模块是未来的某个时间点写出来的。 - -所以写 ABCD 的时候，程序员是不知道未来那个上级模块叫什么名字。这时可以用 super 关键字表示任意名称的上级模块： - -`python -class A: - def method(self): - super..call_something() # 向上级寻找 -` - -在这种写法下： -底层模块的逻辑封装在底层 -每一层程序员无需理解底层模块，只要会组合就行了 -可以任意替换同类模块 - -6.4 from 和 to 关键字 - -`python -from ModuleC import xxx as xxx_renamed -to ModuleX use some_function -` - -from 和 to 关键字比看上去更重要，类似于主板设计师在 PCB 板上连同导线。这个动作是本编程范式下的基石。 - -6.5 模块重命名 - -有时子模块可能需要同类。那么可以像下面这样重命名： - -`python -class MainB: - from ModuleA as mod_a - from ModuleB as mod_b - # 两个模块都有相同的接口，但名称不同时进行重命名 -` - -6.6 新语法的优势 - -在抽象泄露的情况下，是无法做到自由替换子模块的，因为上级模块耦合了下层实现。每个下层实现的逻辑不同，替换时要连带替换，泄露到内层的逻辑代码。 - -使用新语法后： -每层程序员可以任意组合 B 或 C -两者名称不同时，使用 from 关键字重命名即可 -模块可以自由替换 - -七、核心原理：工业流水线思想 - -7.1 职能隔离的比喻 - -本语法的核心思想是仿照工业流水生产线生产工业品： - -不同工段的工人是职能隔离的 -不同工段的工人无需理解前一个工段 -只需要会组装上一个工段传输过来的零件即可 -同时，本工段的工人也应该将封装好的零件提供给后一个工段的工人，让其无需理解本工段逻辑 - -7.2 空间位置关系 - -拿主板和显卡的例子来做说明： -主板上的一个电容和显卡上的一个电容重名或型号相同时，不会产生名称冲突 -原因在于，主板和显卡是通过三维空间位置寻找子零件 - -本语法中的全路径巡境表达的是对象成员的空间位置关系，相当于主板设计师在 PCB 板上按空间位置连同导线。 - -7.3 编译期依赖注入 - -本语法相当于在面向对象的继承语法的基础上，在编译期实现依赖注入。 - -本语法是对面向对象的语法的发展或改进，而非否定。 - -八、API 关键字与调用链耦合 - -8.1 基本语法存在的问题 - -但刚刚的基本语法存在一个问题：调用链耦合了其他模块的名称链。 - -看回例子： -模块 A 再调用模块 B 时，调用链耦合了 B 到 D 这个名称链 -在实际项目中，模块 B 可能是其他公司开发的开源库 -它写的名称链可能是 B → E → D -模块 A 的程序员是不可能要求 B 程序员按 A 的要求改名的 - -所以这种基本语法仅适用于模块内部，程序员可以完全控制代码的情况下。 - -8.2 API 关键字解决方案 - -当模块间进行交互时，需要另外一种封装机制：API 关键字。 - -`python -class ModuleA: - @API # 标记为公开接口 - def public_interface(self): ... - - def privatemethod(self): ... # 内部方法 -` - -本语法中不存在其他面向对象语言中的 public 和 private 关键字，而是使用 API 关键字控制可见性。 - -8.3 API 关键字的作用 - -当模块 M 的未标记为 API 时： -该 M 的成员变量和成员函数全是 public 公有 -可被外部任意访问 - -使用 API 关键字可以： -精确控制哪些接口对外暴露 -将调用链耦合封装在模块内部 -允许外部替换同接口的模块而不影响内部实现 - -九、总结 - -9.1 编程范式演进路径 - -| 阶段 | 特点 | 问题 | -|------|------|------| -| 过程式 | 简单直接 | 代码膨胀后难以维护 | -| 面向对象 | class 语法便于封装 | 继承导致代码无法复用、重名冲突 | -| MVC | 组合思想 | 抽象泄露、初始化逻辑耦合 | -| 依赖注入/微服务 | 解决抽象泄露 | 太重型、成本高 | - -9.2 新范式的核心要点 - -全路径巡境：通过名称链完整表达模块间的空间位置关系 -编译期依赖注入：在编译阶段完成依赖关系的绑定 -职能隔离：仿照工业流水线，每层程序员无需理解底层 -模块可替换：衡量封装好不好的标准是能否自由替换同类模块 -API 关键字：控制模块间交互的接口暴露 - -9.3 对面向对象的态度 - -本语法是对面向对象的语法的发展或改进，而非否定。它解决了： -继承的代码复用问题 -多重继承的重名冲突问题 -MVC 的抽象泄露问题 -时间悖论导致的初始化耦合问题 - - -相关讨论补充（来自弹幕）： -边界条件处理和输入检查在任何范式下都需要考虑 -用函数做 API 和用类做 API 区别挺大——类可以维护状态，函数式更纯粹 -有些成员变量要维护的话，面向对象还是最合适的 - -────────────────────────────── -Generated by MilkyAi@Bilibili: https://space.bilibili.com/3461574540921489 \ No newline at end of file diff --git a/InBox/milky_BV1BpEh6YEDU.md b/InBox/milky_BV1BpEh6YEDU.md deleted file mode 100644 index bc5aa90..0000000 --- a/InBox/milky_BV1BpEh6YEDU.md +++ /dev/null @@ -1,444 +0,0 @@ ---- -title: "[Milky] 为您整理《Claude Code创始人:教你正确写出AI提示词，还有搭建自己的Agent智能体》笔记 | BV1BpEh6YEDU" -source: "milky@4ueo.com" -date: 2026-06-10 01:11 -tags: [milky, bilibili, notes] -email_id: 2633 ---- - -Milky 为您整理了《Claude Code创始人:教你正确写出AI提示词，还有搭建自己的Agent智能体》 | BV1BpEh6YEDU 笔记。 - -Claude Code 官方教程：提示词编写与 Agent 智能体搭建 - -演讲者：Boris Cherny，Anthropic 工程师，Claude Code 创建者 - -Claude Code 简介 - -Claude Code 是一种新型的 AI 编程助手，与传统的代码补全工具（如 GitHub Copilot）不同，它是一个全功能的 Agent（智能体），可以： - -构建完整的功能（features） -编写整个函数和文件 -修复整个 bug -自动串联使用各种工具 - -核心特性 - -| 特性 | 说明 | -|------|------| -| 跨 IDE 支持 | 支持 VS Code、Xcode、JetBrains 等所有主流 IDE | -| 跨环境支持 | 可在本地、远程 SSH、Container 等环境中运行 | -| 通用性 | 不需要改变现有工作流程 | -| 无需索引 | 代码留在本地，不上传到远程服务器 | -| 不训练模型 | 不使用用户代码进行训练 | - - -入门设置 - -基础配置 - -安装 Claude Code 后，官方推荐以下设置： - -`bash -设置终端（获得 Shift+Enter 换行功能） -/terminal setup - -切换主题 -/slash themes # 可选择 light/dark/zen 主题 - -安装 GitHub App（可选） -在任意 GitHub issue 或 PR 中 @Claude） -/install github-app -` - -工具权限自定义 - -`bash -自定义允许使用的工具集，避免每次都弹出确认 -这样设置后不需要每次都手动批准工具调用 -` - -语音输入（Mac 用户） - -进入系统设置 → Accessibility → Dictation -启用听写功能 -双击听写键即可语音输入提示词 - -这对于编写详细的提示词非常有帮助，可以像与另一个工程师对话一样自然地描述需求。 - - -第一步：Codebase Q&A（强烈推荐入门方式） - -为什么从 Q&A 开始 - -这是 Anthropic 新员工入职培训的第一课： - -降低学习门槛：不需要了解任何复杂功能，只需要提问 -了解 AI 边界：帮助理解 Claude Code 能做什么、不能做什么 -无需设置：无需索引、无需配置，直接开始使用 - -效率提升数据 - -| 场景 | 传统方式 | 使用 Claude Code Q&A | -|------|---------|---------------------| -| 技术入职培训 | 2-3 周 | 2-3 天 | - -可以问的问题类型 - -`text -代码使用问题 -"How is this particular piece of code used?" -"How do I instantiate this thing?" - -Git 历史问题 -"Look through Git history to explain why this function has 15 arguments" -Claude Code 会自动： -查找这些参数是如何引入的 -谁引入了这些更改 -当时的背景情况 -相关的 commit 和 issue - -GitHub Issues 问题 -"Fetch issues related to this feature" -可以获取 issue 的上下文信息 - -工作进度查询 -"What did I ship this week?" -Claude Code 会查看 git log，自动总结本周的工作 -` - -重要提示：Claude Code 理解这些请求不是通过 System Prompt 指定的，而是模型本身能力强的体现。 - - -代码编辑功能 - -Agent 工作原理 - -Claude Code 拥有一个小型工具集，它会自动串联使用这些工具： - -Edit files - 编辑文件 -Run bash commands - 运行命令 -Search files - 搜索文件 - -推荐的代码编辑工作流 - -` -让 Claude 先思考和规划 -让它向你展示计划 -征得你同意后再写代码 -` - -推荐提示词模板： - -`text -"Before you write code, make a plan. Answer with the plan and ask for my approval before writing code." -` - -这种方式可以避免"一次性实现3000行功能但完全不是想要的结果"的情况。 - -常见任务提示词 - -`text -自动创建分支、提交代码并推送到远程 -"Think for this one. This commit push here." - -Claude Code 会： -自动创建新分支 -分析 git history 和 git log 确定提交格式 -创建符合项目规范的 commit -推送到远程 -创建 Pull Request -` - - -工具集成 - -Batch 命令工具 - -定义自定义 CLI： - -`bash -告诉 Claude Code 关于你的 CLI 工具 -Claude 会使用 --help 来了解工具用法 - -如果频繁使用，可以添加到 quilMD 中（持久化保存） -` - -MCP（Model Context Protocol）工具 - -Claude Code 支持 MCP 工具，可以集成团队已有的各种工具： - -告诉 Claude 关于工具的描述 -添加 MCP 服务器配置 -Claude 会自动学习和使用这些工具 - -常见工作流 - -| 工作流 | 适用场景 | 说明 | -|--------|---------|------| -| 探索 → 规划 → 确认 → 写代码 | 复杂功能实现 | 适合需要仔细设计的功能 | -| 写代码 → 运行测试 → 迭代 | UI 开发 | Claude 可以看到测试结果并自我改进 | -| 截图/截图验证 | Web/iOS 开发 | Claude 可以用 Puppeteer 截图并迭代 | - -关键技巧：给 Claude 一个反馈工具（如单元测试、截图验证），它可以自主迭代 2-3 次，通常能得到近乎完美的结果。 - - -上下文管理（核心功能） - -quilMD 文件 - -quilMD 是 Claude Code 的特殊配置文件，可以放在多个位置： - -| 位置 | 说明 | 是否提交到 Git | -|------|------|---------------| -| 项目根目录 | 所有会话自动读取 | ✅ 应该提交 | -| 本地 .claude/ 目录 | 仅本地使用 | ❌ 不提交 | -| 嵌套子目录 | 仅在子目录工作时读取 | ✅ 应该提交 | -| 企业根目录 | 企业级配置，所有项目共享 | ✅ 企业管理 | - -quilMD 内容建议 - -` -推荐包含的内容 -常用的 batch 命令 -MCP 工具配置 -架构决策 -重要的文件路径 -代码风格指南 - -示例内容（Anthropic 实际使用的） -common bash commands: [...] -style guide: [...] -core files: [...] -` - -保持简短：quilMD 太长会消耗大量上下文窗口，通常不太有用。 - -企业级配置 - -`yaml -企业配置文件可以包含： -全局 s 命令 -批量权限配置 -URL 黑名单（禁止访问的 URL） -MCP 服务器配置 -权限策略 -` - -权限管理示例： - -`yaml -允许所有员工使用某个测试命令（自动批准） -allowed_commands: - - test - -禁止访问的 URL -blocked_urls: - - https://internal.company.com/confidential -` - -其他上下文引入方式 - -| 方式 | 语法 | 说明 | -|------|------|------| -| @文件路径 | @path/to/file | 引入特定文件到上下文 | -| s 命令 | /command-name | 可在主目录或项目中定义 | -| 嵌套 quilMD | - | 在子目录中自动引入 | -| # 记住 | #remember something | 让 Claude 记住某些偏好 | - - -快捷键与实用技巧 - -核心快捷键 - -| 快捷键 | 功能 | -|--------|------| -| Shift+Tab | 切换到自动接受编辑模式（建议用于运行测试、迭代时） | -| Escape | 停止 Claude 当前操作（安全操作，不会破坏会话） | -| Escape + Escape | 返回历史记录 | -| ↑ + F | 查看完整输出（Claude 上下文窗口中的所有内容） | -| ! | 进入 batch 模式，输入命令并进入上下文 | -| # | 让 Claude 记住某些偏好（会自动更新 quilMD） | - -常用技巧 - -自动接受编辑模式 -`bash -适合场景： -知道 Claude 在做正确的事 -运行单元测试并迭代 -不需要每次都手动批准 -` - -让 Claude 记住偏好 -`text -如果 Claude 没有正确使用某个工具 -输入： -remember always use --verbose flag when running this tool - -Claude 会自动更新 quilMD -` - -批量命令进入上下文 -`bash -输入 ! 后跟命令 -!docker build -t myapp . -命令和输出都会进入 Claude 的上下文窗口 -适合： -长时间运行的命令 -需要 Claude 分析命令输出 -` - -会话恢复 -`bash -会话结束后，使用 resume 恢复 -/claude resume -` - - -Claude Code SDK - -基础使用 - -`bash -使用 -p 参数调用 CLI SDK -claude -p "你的提示词" - -可选参数： ---allowed-tools: 指定允许使用的工具 ---format: 输出格式（JSON/streaming JSON） -` - -使用场景 - -| 场景 | 示例 | -|------|------| -| CI 集成 | 在持续集成流程中使用 | -| 事件响应 | 处理生产环境问题 | -| 管道处理 | 集成到各种自动化流程 | -| 日志分析 | 读取 GCP bucket 中的日志，Claude 找出有趣的信息 | -| CLI 集成 | 结合 jq 等工具进行数据处理 | - -管道示例 - -`bash -读取日志文件并分析 -cat large-log-file.log | claude -p "找出异常模式和错误" - -结合 Git 命令 -git status | claude -p "帮我生成提交信息" - -结合 jq 处理数据 -some-api-call | jq '.data' | claude -p "分析这个数据" -` - -Claude Code SDK 本质上是一个智能化的 Unix 工具，给一个提示，返回一个 JSON/文本结果。 - - -并行工作技巧（高级用户） - -普通用户 vs 高级用户 - -| 普通用户 | 高级用户 | -|---------|---------| -| 同时运行 1 个 Claude session | 运行多个 SSH 隧道连接的 Claude session | -| 单个仓库工作 | 多个仓库 checkout 同时运行 | -| 顺序完成任务 | 使用 Git worktrees 实现隔离并行 | - -并行化方法 - -`bash -方法1：多个 terminal tabs -打开多个终端，每个运行不同的 Claude session - -方法2：Git worktrees -git worktree add feature-branch -在不同的工作树中并行运行 Claude - -方法3：SSH 隧道 -连接到远程机器运行 Claude -` - -建议 - -尽量不要同时在一个仓库中运行多个 Claude，这可能会导致冲突。使用 Git worktrees 实现真正的隔离并行。 - - -Q&A 精选 - -Q: 为什么构建 CLI 工具而不是 IDE 插件？ - -A: 两个原因 - -通用性：Anthropic 员工使用各种 IDE（VS Code、Neovim、Xcode、JetBrains 等），终端是共同的分母 -未来趋势：AI 模型发展迅速，年底可能人们不再使用传统 IDE，CLI 避免在 UI 层过度投资 - -Q: Claude Code 支持多模态吗？ - -A: 完全支持，从一开始就支持 - -使用方法： -拖拽图片到终端 -提供文件路径 -复制粘贴图片 - -典型使用场景：提供一个 UI mock 图片，告诉 Claude "实现这个界面"，然后用 Puppeteer 迭代验证。 - -Q: Anthropic 内部如何使用 Claude Code？ - -80% 的技术员工每天使用 Claude Code -包括工程师和研究员 -研究人员使用 notebook 工具编辑和运行 Jupyter notebooks - -Q: Bash 命令安全性如何处理？ - -A: 复杂的三层权限系统 - -Claude Code 通过以下方式平衡安全性和效率： - -只读命令识别：识别哪些命令是只读的 -静态分析：分析哪些命令可以安全组合 -分层权限： - - 企业级：统一配置权限 - - 项目级：特定项目配置 - - 用户级：个人偏好设置 -黑名单：可以阻止危险命令或 URL - - -总结：最佳实践路线图 - -` -┌─────────────────────────────────────────────────────────┐ -│ 入门阶段 │ -│ 1. 安装 Claude Code │ -│ 2. 运行 /terminal setup │ -│ 3. 开始 Codebase Q&A（提问、提问、提问） │ -│ 4. 理解 Claude 的能力和边界 │ -└─────────────────────────────────────────────────────────┘ - ↓ -┌─────────────────────────────────────────────────────────┐ -│ 进阶阶段 │ -│ 1. 学习代码编辑：先规划 → 确认 → 写代码 │ -│ 2. 使用 #remember 教 Claude 你的偏好 │ -│ 3. 集成团队工具（MCP、自定义 CLI） │ -│ 4. 编写项目 quilMD（共享给团队） │ -└─────────────────────────────────────────────────────────┘ - ↓ -┌─────────────────────────────────────────────────────────┐ -│ 高级阶段 │ -│ 1. 配置企业级策略和权限 │ -│ 2. 使用 SDK 集成到 CI/CD 流程 │ -│ 3. 使用并行工作流（多个 session、worktrees） │ -│ 4. 构建自定义 Agent 解决方案 │ -└─────────────────────────────────────────────────────────┘ -` - -核心原则： - -从 Q&A 开始，不要急于使用复杂功能 -给予足够的上下文（quilMD、MCP、工具） -让 Claude 先思考和规划 -给予反馈工具让它迭代改进 -投入时间配置，回报是巨大的 - -────────────────────────────── -Generated by MilkyAi@Bilibili: https://space.bilibili.com/3461574540921489 \ No newline at end of file diff --git a/InBox/milky_BV1HWd6BsEmG.md b/InBox/milky_BV1HWd6BsEmG.md deleted file mode 100644 index a034258..0000000 --- a/InBox/milky_BV1HWd6BsEmG.md +++ /dev/null @@ -1,321 +0,0 @@ ---- -title: "[Milky] 为您整理《OpenAI：Skill的自动评分器怎么搭》笔记 | BV1HWd6BsEmG" -source: "milky@4ueo.com" -date: 2026-06-09 21:17 -tags: [milky, bilibili, notes] -email_id: 1995 ---- - -Milky 为您整理了《OpenAI：Skill的自动评分器怎么搭》| BV1HWd6BsEmG 笔记。 - -OpenAI Skill 自动评分器构建指南 - -一、为什么需要评分器 - -当更新一个 Skill 并执行完成后，表面结果正常不代表真的变好了。核心问题是： - -Skill 是否真的完成了预期任务？ -修改是否引入了新的问题（回归）？ -如何在不同版本之间进行性能比较？ - -评分器的职责就是回答这些问题，让 Skill 的质量变化可衡量、可追踪。 - - -二、运行轨迹记录 - -2.1 什么是运行轨迹 - -评分的前提是有东西可以打分。OpenAI 的做法是使用 CodeExec JSON 记录 Skill 的完整执行过程。 - -2.2 配置方式 - -`json -{ - "code_exec": true // 启用后输出结构化执行记录 -} -` - -2.3 记录内容 - -启用后，Skill 每执行一步都会输出结构化记录，包括： - -跑了什么命令 -创建了什么文件 -执行顺序 -时间戳 - -2.4 关键特性 - -| 特性 | 说明 | -|------|------| -| 完整性 | 记录完整执行流程，而非日志摘要 | -| 可解析性 | 结构化数据，可被程序直接读取 | -| 可调试性 | 失败时可精确定位到具体哪一步出错 | - -没有运行轨迹，评分器只能看最终产物，无法分析执行过程。 - - -三、评分器类型 - -3.1 确定性检查（Deterministic Checks） - -3.1.1 原理 - -纯代码规则驱动的检查，不用大模型，写死判断逻辑，程序直接对着运行轨迹核对。 - -3.1.2 典型检查项 - -` -有没有执行 npm install -有没有创建 package.json -命令执行顺序是否符合预期 -是否在指定目录执行操作 -` - -3.1.3 核心特性 - -| 特性 | 说明 | -|------|------| -| 确定性 | 同样行为每次判断结果一致，没有模糊地带 | -| 可调试 | 一旦失败，打开记录文件即可看到从哪一步开始偏离 | - -3.1.4 局限性 - -确定性检查能回答"基础动作做了没有"，但无法回答"做出来的东西是不是你想要的样子"。 - - -3.2 评分细则检查（Rubric-based Checks） - -3.2.1 原理 - -使用 LLM 作为裁判，读取仓库内容，按预定义的评分细则输出结构化打分结果。 - -3.2.2 适用场景 - -很多 Skill 的验收标准本来就是软性规则，例如： - -代码结构是否干净 -组件组织是否符合团队约定 -样式配置是否按既定风格落地 -命名规范是否遵循 - -3.2.3 评分细则的拆解方法 - -把模糊的质量标准拆成若干个可独立判断的维度： - -| 模糊标准 | 拆解后的维度 | -|----------|--------------| -| 代码质量好 | 组件是否按功能分目录 | -| | 是否有未使用的引用 | -| | 样式类名是否遵循命名约定 | -| | 配置项是否集中管理 | - -3.2.4 关键要求：锁定输出格式 - -必须提前定义输出模板，规定模型必须输出哪些字段： - -`json -{ - "passed": true/false, - "total_score": 85, - "dimensions": [ - { - "name": "component_organization", - "score": 90, - "reason": "组件按功能正确分目录" - }, - { - "name": "unused_imports", - "score": 70, - "reason": "发现3处未使用的import" - } - ] -} -` - -3.2.5 为什么必须锁死格式 - -| 自由输出 | 锁死格式 | -|----------|----------| -| 每次措辞不同 | 格式统一 | -| 无法跨版本比较 | 结果可量化 | -| 无法进自动化流程 | 可直接集成 CI/CD | -| 输出是"审稿意见" | 输出是"评估数据" | - - -四、评分器组合策略 - -4.1 分工明确 - -` -确定性检查 ──→ 抓底线（基础动作有没有发生） -评分细则检查 ──→ 抓质量（做出来的东西像不像你要的） -输出格式锁定 ──→ 防飘移（每次评分结果一致） -` - -4.2 集成到流水线 - -这套组合设计之初就面向 持续集成（CI）： - -不再依赖工程师手动触发测试 -成为持续运行的回归守门员 -Skill 每次更新都会自动验证 - - -五、6 类扩展检查 - -在基础评分器之上，可按需叠加以下检查： - -5.1 命令数与循环检测 - -` -检查运行记录里执行了多少条命令 -` - -目的：检测行为退化 - -案例：如果一个 Skill 以前 6 步能完成，现在要 18 步，表面上任务还是完成了，但系统正在变差。 - -5.2 消耗量追踪 - -` -记录每次运行消耗的 token 数量 -` - -目的：防止 Skill 越来越臃肿 - -每次执行越来越贵 -每次执行越来越慢 - -5.3 构建检查 - -`bash -skill 完成后直接执行构建命令 -npm run build -` - -目的：端到端验证 - -很多项目表面完成，构建就露馅 -成本低，应该默认开启 - -5.4 运行时冒烟检查 - -`bash -启动开发服务器 -npm run dev -发送测试请求 -curl http://localhost:3000/api/health -` - -目的：验证服务是否真正可用 - -注意：这类检查更慢，按风险等级决定是否每次都执行。 - -5.5 仓库清洁度检查 - -` -检查任务完成后是否出现不该有的文件 -` - -目的：确保系统没有被"弄脏" - -5.6 权限回归检查 - -` -验证 skill 是否还能在最小权限下正常工作 -` - -目的：防止权限漂移 - -某次改动后悄悄开始依赖更高权限 -权限漂移在自动化后会变成结构性风险 - -5.7 扩展策略 - -` -原文建议：先加快速检查，再按风险叠加慢检查 - 不是一次全上，是按需扩展 -` - -| 检查类型 | 速度 | 建议频率 | -|----------|------|----------| -| 命令数检测 | 快 | 每次 | -| 消耗量追踪 | 快 | 每次 | -| 仓库清洁度 | 快 | 每次 | -| 构建检查 | 中 | 每次 | -| 运行时冒烟 | 慢 | 按风险 | -| 权限回归 | 慢 | 定期 | - - -六、5 条核心原则 - -原则一：量真正重要的东西 - -Don't measure for the sake of measuring. First, think about what you'd actually care about if it got worse. - -不要为了有指标而有指标，先想清楚什么变差了，你会真的在意。 - -原则二：先写清晰可检查的定义 - -If the success criteria are fuzzy, the evaluation will be too. - -验收标准模糊，评估就没有意义。先把"什么叫做对"写成可执行的判断。 - -原则三：把评估扎在真实行为上 - -Record the full execution trace and write deterministic checks around the actual actions taken. - -记录 Skill 的完整运行轨迹，围绕实际执行的动作写确定性检查。 - -原则四：规则不够时，再让模型补上 - -Use rubric-based evals to handle quality judgments that rules can't cover, not as a replacement. - -用评分细则处理规则覆盖不了的质量判断，顺序不能反。确定性检查在前，LLM 评分在后。 - -原则五：让真实失败去驱动样本增长 - -Every time you manually fix something, turn it into a test case. - -每次手动修复都是一个信号，把它变成测试用例，让 Skill 持续把这件事做对。 - - -七、整体流程图 - -` -┌─────────────────────────────────────────────────────────┐ -│ Skill 执行 │ -└─────────────────┬───────────────────────────────────────┘ - ▼ -┌─────────────────────────────────────────────────────────┐ -│ CodeExec JSON 记录运行轨迹 │ -└─────────────────┬───────────────────────────────────────┘ - ▼ - ┌───────┴───────┐ - ▼ ▼ -┌───────────────┐ ┌─────────────────┐ -│ 确定性检查 │ │ 评分细则检查 │ -│ (规则驱动) │ │ (LLM 裁判) │ -└───────┬───────┘ └────────┬────────┘ - ▼ ▼ - └────────┬─────────┘ - ▼ -┌─────────────────────────────────────────────────────────┐ -│ 结构化评估结果（跨版本可比较） │ -└─────────────────┬───────────────────────────────────────┘ - ▼ -┌─────────────────────────────────────────────────────────┐ -│ 进入 CI/CD 流水线 │ -└─────────────────────────────────────────────────────────┘ -` - - -八、参考资料 - -原文标题：Testing Agent Skills Systematically with Evals -原文链接：https://developers.openai.com/blog/eval-skills -视频来源：慢学AI（BV1HWd6BsEmG） - -────────────────────────────── -— Milky 视频总结助手 \ No newline at end of file diff --git a/InBox/milky_BV1Hn9UBrEsH.md b/InBox/milky_BV1Hn9UBrEsH.md deleted file mode 100644 index 9fd6093..0000000 --- a/InBox/milky_BV1Hn9UBrEsH.md +++ /dev/null @@ -1,324 +0,0 @@ ---- -title: "[Milky] 为您整理《Harness Engineering最佳实践：深度解析AgentHamness的底层原理、核心组件和实战应用 学不会我退出AI圈！》 P1笔记 | BV1Hn9UBrEsH" -source: "milky@4ueo.com" -date: 2026-06-09 21:17 -tags: [milky, bilibili, notes] -email_id: 2013 ---- - -Milky 为您整理了《Harness Engineering最佳实践：深度解析AgentHamness的底层原理、核心组件和实战应用 学不会我退出AI圈！》 P1 | BV1Hn9UBrEsH 笔记。 - -Harness Engineering 最佳实践：Agent Harness 底层原理、核心组件与实战应用 - -目录 - -AI 工程师的岗位分层体系 -大模型应用的三层进化范式 -Prompt Engineering：让模型"会说" -Context Engineering：解决上下文膨胀问题 -Agent Harness 核心架构 -Harness Engineering 的工程实践 - - -AI 工程师的岗位分层体系 - -1.1 三层架构概述 - -在 2026 年，AI 工程师可分为三个层级，每个层级有明确的技术侧重点： - -| 层级 | 定位 | 核心职责 | 技术侧重 | -|------|------|----------|----------| -| AI 产品化 | AI 产品经理、AI 解决方案架构师 | 发现 AI 价值场景，重塑业务流程 | 业务分析、产品设计 | -| AI 应用层 | AI 应用工程师、大模型应用开发 | 业务方案落地，AI 赋能场景 | Prompt Engineering、Context Engineering、RAG | -| AI 大模型算法层 | 模型研发工程师 | 提升模型垂直能力 | SFT 微调、RLHF 对齐、安全护栏 | - -1.2 各层级的核心差异 - -AI 产品化层： -聚焦于找到 AI 的价值场景 -重新定义业务产品线 -属于业务与产品方向 - -AI 应用层（Harness Engineering 的落地层）： -偏业务 + 方案落地 -利用开源模型构建垂直应用 -2026 年最稀缺、最具机会的方向 - -AI 大模型算法层： -不做基座模型（GPT-4、Qwen3.6 等基座由大厂完成） -聚焦于模型的垂直能力提升 -包括： - - SFT 微调（Supervised Fine-Tuning） - - RLHF（Reinforcement Learning from Human Feedback） - - 对齐训练（Alignment） - - 安全护栏（Safety Guardrails） - -1.3 职业选择建议 - -` -技术背景 → AI 应用层（最佳入场点） -产品背景 → AI 产品化层 → 可延伸至应用层 -算法背景 → AI 大模型算法层 -` - -核心观点：2026 年是大模型应用落地的关键年份，大多数人的机会在于 AI 应用层。 - - -大模型应用的三层进化范式 - -从时间维度看，AI 应用开发经历了三个阶段的范式转变： - -` -2022-2024：Prompt Engineering 时代 - ↓ -2025：Context Engineering 时代 - ↓ -2026：Agent Harness / Harness Engineering 时代 -` - - -Prompt Engineering：让模型"会说" - -3.1 时间窗口 - -2022 年 11 月 ChatGPT 发布后成为焦点 - -3.2 核心问题 - -解决"如何说"的问题——如何更好地与模型沟通，让模型生成更高质量的回答。 - -3.3 技术特征 - -单对单对话模式 -用户输入一句话，模型返回一句话 -关注点：如何编写有效的 Prompt - -3.4 典型场景 - -` -用户 → Prompt → LLM → Response -` - - -Context Engineering：解决上下文膨胀问题 - -4.1 时间窗口 - -2025 年 - -4.2 核心问题 - -随着 Agent 开发引入工具调用（如 MCP 协议），上下文窗口中的内容越来越多，导致模型能力反而下降、幻觉（Hallucination） 问题加剧。 - -4.3 核心目标 - -解决"有什么"的问题——让模型清楚地知道当前拥有哪些信息。 - -4.4 关键概念 - -Context Window（上下文窗口）： -多轮对话的执行过程中，所有历史信息都存储在上下文窗口中 -当内容越来越多时，模型会出现"迷失"现象 - -迷失问题（Lost in Context）： -模型在大量上下文中无法准确识别关键信息 -导致： - - 响应质量下降 - - 幻觉增加 - - 任务执行失败 - -4.5 Context Engineering 的职责 - -| 问题 | 解决方案 | -|------|----------| -| 上下文过长 | 上下文压缩、摘要 | -| 信息混乱 | 结构化组织、分类管理 | -| 关键信息被淹没 | 关键信息突出、检索增强 | - - -Agent Harness 核心架构 - -5.1 官方来源 - -本文档基于 LangChain 团队发布的关于 Agent Harness 的官方博客，是全球最懂 Agent 的团队发布的系统性技术文档。 - -5.2 Agent Harness 的定位 - -Harness 的本意是"驾驭、利用"，Agent Harness 即对 Agent 的工程化驾驭框架。 - -5.3 核心架构体系 - -` -┌─────────────────────────────────────────┐ -│ Agent Harness │ -├─────────────────────────────────────────┤ -│ ┌─────────────┐ ┌─────────────────┐ │ -│ │ 规划层 │ │ 执行层 │ │ -│ │ Planning │ │ Execution │ │ -│ └─────────────┘ └─────────────────┘ │ -│ ┌─────────────┐ ┌─────────────────┐ │ -│ │ 工具层 │ │ 记忆层 │ │ -│ │ Tools │ │ Memory │ │ -│ └─────────────┘ └─────────────────┘ │ -│ ┌─────────────┐ ┌─────────────────┐ │ -│ │ 感知层 │ │ 评估层 │ │ -│ │ Perception │ │ Evaluation │ │ -│ └─────────────┘ └─────────────────┘ │ -└─────────────────────────────────────────┘ -` - -5.4 各层核心组件详解 - -5.4.1 规划层（Planning） - -职责：将复杂任务分解为可执行的子任务 - -关键技术： -任务分解（Task Decomposition） -思维链（Chain of Thought, CoT） -子任务规划 - -5.4.2 执行层（Execution） - -职责：执行规划层生成的子任务 - -关键技术： -工具调用（Tool Calling） -动作执行（Action Execution） -结果反馈 - -5.4.3 工具层（Tools） - -职责：为 Agent 提供外部能力 - -典型工具类型： -MCP 工具（Model Context Protocol） -API 调用 -搜索引擎 -数据库查询 -文件系统操作 - -5.4.4 记忆层（Memory） - -职责：存储和管理 Agent 的历史状态与上下文 - -记忆类型： -| 类型 | 说明 | 用途 | -|------|------|------| -| 短期记忆 | 当前对话上下文 | 处理即时任务 | -| 长期记忆 | 持久化存储 | 跨会话经验积累 | -| 工作记忆 | 工作过程中的临时状态 | 任务执行中间态 | - -5.4.5 感知层（Perception） - -职责：接收和处理外部输入 - -感知内容： -用户指令 -文档输入 -多模态信息（图像、音频等） -环境状态 - -5.4.6 评估层（Evaluation） - -职责：评估 Agent 执行结果的质量 - -评估维度： -输出正确性 -任务完成度 -安全性检查 -效率评估 - - -Harness Engineering 的工程实践 - -6.1 定义 - -Harness Engineering 是系统性地构建、测试、优化 Agent 行为能力的工程学科。 - -6.2 与传统软件工程的区别 - -| 维度 | 传统软件工程 | Harness Engineering | -|------|-------------|---------------------| -| 不确定性 | 低（确定性逻辑） | 高（概率性输出） | -| 测试难度 | 可精确断言 | 需概率评估 | -| 调试方法 | 日志追踪 | 行为轨迹分析 | -| 质量保障 | 单元测试 + 集成测试 | 评估驱动开发 | - -6.3 核心工程实践 - -6.3.1 评估驱动开发（Evaluation-Driven Development） - -` -设计评估指标 → 开发 Agent → 持续评估 → 迭代优化 -` - -6.3.2 行为可复现性 - -通过种子（seed）控制随机性 -构建可测试的 Agent 行为 -建立回归测试机制 - -6.3.3 多维度评测 - -任务完成率：Agent 是否完成目标 -效率指标：消耗的 Token 数量、执行时间 -质量评分：输出的人力评估 -安全性检查：有害内容过滤 - -6.4 LangChain Agent Harness 的工具链 - -` -┌──────────────────────────────────────────┐ -│ LangChain 生态 │ -├──────────────────────────────────────────┤ -│ LangChain │ Agent 开发框架 │ -│ LangSmith │ 追踪与评估平台 │ -│ LangServe │ Agent 部署服务 │ -│ LangGraph │ Agent 工作流编排 │ -└──────────────────────────────────────────┘ -` - - -补充：观众反馈中的有价值观点 - -本节整理自视频弹幕中观众的补充与讨论 - -7.1 关于 Context Engineering 的延伸 - -Context Engineering 不仅解决"上下文膨胀"，还需要考虑信息密度问题 -有效上下文 = 去除噪音后的核心信息 -常用的压缩策略：LLM 摘要、关键信息提取、信息去重 - -7.2 关于 Agent 幻觉的处理 - -幻觉问题在单轮对话中已存在 -在多轮 Agent 执行中，幻觉会被级联放大 -建议在每个关键步骤增加自我校验机制 - -7.3 关于实际落地的建议 - -不要过度追求 Agent 的自主性，人机协同往往更可靠 -初期应聚焦垂直场景，积累领域知识后再扩展 - - -附录：关键术语表 - -| 英文术语 | 中文解释 | -|----------|----------| -| Harness Engineering | 驾驭工程，Agent 的系统工程化方法 | -| Agent Harness | Agent 框架的核心组件集合 | -| Prompt Engineering | 提示词工程，优化人机交互质量 | -| Context Engineering | 上下文工程，管理信息输入质量 | -| Hallucination | 幻觉，LLM 生成虚假或不准确内容 | -| Chain of Thought (CoT) | 思维链，引导模型展示推理过程 | -| SFT | Supervised Fine-Tuning，有监督微调 | -| RLHF | Reinforcement Learning from Human Feedback，基于人类反馈的强化学习 | -| MCP | Model Context Protocol，模型上下文协议 | -| Agent | 智能体，能够自主执行任务的 AI 系统 | - - -笔记说明：本笔记基于 LangChain 团队发布的官方博客整理，聚焦于 Agent Harness 的技术架构与工程实践。视频原版对三层架构有详细展开，读者可根据需要结合原视频深入理解各层级的技术细节。 - -────────────────────────────── -— MilkyAi \ No newline at end of file diff --git a/InBox/milky_BV1LjdzB3EAu.md b/InBox/milky_BV1LjdzB3EAu.md deleted file mode 100644 index f85babc..0000000 --- a/InBox/milky_BV1LjdzB3EAu.md +++ /dev/null @@ -1,186 +0,0 @@ ---- -title: "[Milky] 为您整理《[播客] Agent技术周报2，harness工程能力更新，开源agent生态分化》笔记 | BV1LjdzB3EAu" -source: "milky@4ueo.com" -date: 2026-06-09 21:17 -tags: [milky, bilibili, notes] -email_id: 1989 ---- - -Milky 为您整理了《[播客] Agent技术周报2，harness工程能力更新，开源agent生态分化》| BV1LjdzB3EAu 笔记。 - -Agent技术周报#2：Harness工程能力更新与开源Agent生态分化 - -本周核心主题 - -Agent开发正从单纯的模型能力竞赛转向更复杂的系统能力构建，Harness Engineering（脚手架工程）成为Agent开发的核心差异化竞争点。 - -业界共识：有用的Agent不是 "just best models"，而是以下系统能力的组合： - -文件系统访问 -BSH（Shell）上下文压缩 -记忆管理 -权限控制 -重试机制 -评估机制 -子Agent协作 - - -趋势预测 - -预计到 2025年下半年，竞争焦点将从模型精度转向整个Agent系统的鲁棒性和可观测性。 - -用户核心关注点： - -| 旧关注点 | 新关注点 | -|---------|---------| -| 单次推理精度 | 能否持续运行数小时甚至数天 | -| 模型是否最聪明 | 任务中途出错能否自动恢复 | -| 上下文理解能力 | 长对话中是否丢失上下文 | - - -Harness工程的技术实践路径 - -解耦与标准化 - -代表方案：OpenAI Ediness SDK - -将Harness逻辑与实际计算存储环境分离 -Harness本身开源可定制 -具体代码执行委托给第三方沙箱环境（如 Modal、CodeFlare） -形成 无状态编排 + 有状态隔离工作区 的模式 -优势：既安全又灵活 - -强化控制与护栏 - -代表方案：Lachain DeepAgent - -将Agent降级为结构化的工具调用 -通过中间件和严格的文件系统权限设置护栏 -防止Agent行为失控 - -技能持久化与演化（关键创新） - -代表方案：HermesAgent - -核心思想：把Agent成功完成的工作流自动保存为可复用的技能 - -` -工作流程：执行 → 成功 → 保存技能 → 可复用 → 持续积累 -` - -Agent不再是"干完就忘" -能积累经验，越用越强 -形成 学习 → 固化 → 复用 的闭环 - - -实际影响 - -企业层面 - -部署门槛变化：从"选GPT-4还是Claude"转向"如何设计稳定安全的Harness系统" -云服务商迅速反应：Cloudflare、Modal等推出专门的Agent沙箱服务，试图在生态层绑定用户 -开源Harness项目正在快速追赶闭源系统的能力 - -用户层面 - -更关注Agent的持续运行能力、自动恢复、上下文保持 -衍生新现象：Wing Fatigue（持续的审查、修正AI输出带来的精神疲劳） -反向推动系统本身需要更可靠、更自动化 - - -开源Agent生态分化 - -本周焦点：开源Agent框架早期百花齐放，现在开始像操作系统一样出现清晰的定位分化。 - -主要框架对比 - -| 框架 | 定位 | 特点 | 目标用户 | -|------|------|------|----------| -| HermesAgent | 可编程专业Agent | 高度可定制、技能持久化、工具箱 | 开发者和高级用户 | -| Open Interpreter / Open Cloud | 即时运行个人助理 | 记忆导入、Memory Palace、聊天UI优化、视频生成插件 | 普通用户 | - -HermesAgent（本周更新 V0.9 / V0.10） - -核心功能： - -专业的本地Web管理仪表盘 -强大的技能持久化功能 -丰富的集成能力 - -典型应用场景： -用户用它自动修复开源模型的底层代码bug → 跑测试 → 生成报告 → 上传到模型社区，全程高度自制。 - -杀手锏：不是会用工具，而是能固化技能——让Agent从临时工变成有经验的老员工。 - -Open Cloud - -核心功能： - -记忆导入 -Memory Palace -聊天UI优化 -视频生成插件集成 - -定位：更偏向即时运行个人助理，用户体验更友好。 - -新入局者 - -| 框架 | 特点 | -|------|------| -| OpenAG | 开源云编码Agent站 | -| DeepAgent | 底层运行1，支持可插拔模型、提供商、沙箱、中间件、追踪等 | - - -行业格局影响 - -2025年可能迎来Agent框架的 Linux vs Windows 时刻。 - -用户根据可编程性需求（Hermes方向）还是应用性需求（Open Cloud方向）做选择 -开源Agent在可复现性和可审计性上的优势凸显 -开始吸引对透明度和可控性有要求的企业用户 -闭源方案（GitHub Copilot、Claude Code等）仍有先发和集成优势，但开源追赶速度非常快 - - -其他值得关注的技术趋势 - -安全与合规转型 - -新的架构正在推动审查重点从代码安全转向AI行为安全 - -结合Git版本管理的存储方案 -为Agent所有操作提供审计追踪和回滚能力 - -垂直化与平台化并行 - -平台化：通用Agent平台扩展为Agent工作区 -垂直化：面向生命科学、网络安全等高价值领域的垂直专业Agent兴起，针对特定领域知识深度优化 - -本地部署加速 - -将Qwen 3.6模型通过量化技术 -可在消费级显卡甚至大内存普通电脑上运行 - -典型场景： -用户用本地部署的模型分析长达数十万字的个人日记，数据完全不用离开本地，隐私优势无可替代 - - -总结 - -Agent战场已全面升级：从单点模型比拼扩展到整体系统比拼。 - -决定性竞争优势来源 - -| 能力 | 说明 | -|------|------| -| 容错性 | 系统容许组件失败 | -| 可恢复性 | 出错后能自动恢复 | -| 可审计性 | 所有操作可追溯 | -| 可演化性 | 经验积累能力 | - -Harness工程是构建这些能力的核心学科。 - -开源生态会继续分化，提供不同层级的解决方案 -企业及个人用户的选择标准需从"模型智能"转向"模型可靠性"等系统能力 - -────────────────────────────── -— Milky 视频总结助手 \ No newline at end of file diff --git a/InBox/milky_BV1SZoXBkErT.md b/InBox/milky_BV1SZoXBkErT.md deleted file mode 100644 index 5e1b7eb..0000000 --- a/InBox/milky_BV1SZoXBkErT.md +++ /dev/null @@ -1,365 +0,0 @@ ---- -title: "[Milky] 为您整理《2026-04-25 Harness for AI coding 团队级 AI 编程驾驭工程》笔记 | BV1SZoXBkErT" -source: "milky@4ueo.com" -date: 2026-06-09 21:17 -tags: [milky, bilibili, notes] -email_id: 2043 ---- - -Milky 为您整理了《2026-04-25 Harness for AI coding 团队级 AI 编程驾驭工程》 | BV1SZoXBkErT 笔记。 - -敏捷团队 AI 编程驾驭工程体系 - -一、背景与核心问题 - -1.1 为什么需要团队级 AI 编程体系 - -当前 AI 编程工具（如 SuperPowe、Claude Code、Cursor 等）已经非常强大，但在团队级、项目级场景下落地困难。核心原因是： - -需求衔接问题：产品经理/BA 给的需求格式不统一，颗粒度不一致，导致 AI 无法有效理解 -开发实践问题：多人协作时，AI 生成的代码风格不统一、难以形成一致的整体 -工具生态混乱：Claude Code、Cursor、windsurf、SuperPower 等工具差异大，没有统一标准 -流程与制度问题：团队工作习惯难以改变，这是最大的阻力来源 - -1.2 当前团队使用 AI 编程的认知分级 - -根据开发者能力分层： - -| 级别 | 描述 | 典型行为 | -|------|------|----------| -| 初级开发者 | 照猫画虎，不知道系统如何工作 | 抄代码、写业务逻辑，被 AI 替代 | -| 专家型开发者 | 做技术公关，复杂组件开发 | 仍需要，但 AI 可辅助 | -| 架构型开发者 | 设计服务、做权衡决策 | AI 辅助设计，但要人工把关 | -| 技术经理/CTO | 处理复杂混乱的问题 | 构建团队 AI 工作体系 | - -关键洞察："这个玩具不是玩 AI，是玩人"——真正的挑战不在于 AI 能力，而在于如何让团队按照统一的方式工作。 - -1.3 AI 辅助软件工程全流程图 - -` -需求分析 → 技术方案设计 → 代码编写 → Code Review → 测试 → 部署 → 生产 Bug 修复 - ↓ ↓ ↓ ↓ ↓ ↓ ↓ - 录音转文档 打样工程 API/单元测试 交叉模型 E2E测试 K8S部署 MCP自动 - 访谈纪要 代码模板 TDD 循环 Review Playwright 触发合并 发通知 - 需求文档 技术规范 - 原型链接 -` - -二、需求阶段：如何让需求 AI 友好 - -2.1 需求规格模板必须包含的内容 - -BA 或产品经理给的需求文档必须包含以下 4 个关键部分： - -业务背景：为什么做这个需求 -字段清单：所有业务字段的类型、默认值、业务规则（避免只给原型图让 AI 去猜） -原型链接：Figma 图等设计稿的链接（AI 可通过 MCP 读取 Figma） -业务规则：按条拆分，例如： - - 订单号生成规则 - - 发货规则 - - 状态转换规则 - -2.2 需求颗粒度的判断标准 - -不要用 Story 拆分需求（一个人增产改查拆成 4 个 story 对 AI 来说信息量不够）。 - -正确做法：一个模块一个文档，判断颗粒度的标准是： -是否有独立的表结构 -是否可以单独上线 - -2.3 新建需求 vs 变更需求 - -新建需求：告诉 AI 有多少表、多少页面、多少功能操作 → AI 生成完整模块 - -变更需求（重要）： -必须用标签标注变更类型：[+字段] [-字段] [修改字段] -不要把最终完整状态给 AI，因为 AI 需要对比现有代码 → 浪费大量 Token 且效果差 -示例： - -`markdown -订单模块变更需求 - -新增内容 [+] -新增字段：order_type（订单类型，枚举值：NORMAL, VIP, B2B） - -修改内容 [~] -修改字段：shipping_address 最大长度从 200 改为 500 - -删除内容 [-] -删除字段：legacy_flag（已废弃） -` - -2.4 用 Obsidian 搭建知识库给 AI 做上下文 - -将所有需求规格、技术规格都放到知识库中，用 Obsidian + Markdown 管理： - -用浏览器插件一键将网页转成 Markdown 并保存图片本地 -用 backlink 功能做上下文关联 -AI 通过读取这个知识库获得长期记忆 → "Single source of truth" - -三、技术规格阶段：技术方案设计 - -3.1 技术规格必须包含的内容 - -技术规格是开发的核心输入，必须包含以下 5 个部分： - -| 内容 | 工具/格式 | 说明 | -|------|----------|------| -| 领域模型 | PlantUML / Mermaid | 代码化表达，便于 AI 理解 | -| 数据库设计 | DBML / Flyway 脚本 | 不要让 AI 直接操作数据库，用版本化的 Flyway 脚本 | -| API 定义 | OpenAPI / Markdown | 后端写完 API 后输出 API 文档给前端 | -| 时序图 | Mermaid | 复杂流程需要时序图 | -| 专项设计 | Markdown | 权限、事务、缓存等专项内容 | - -重要教训：不要给 AI 写数据库的写权限，曾经因为 AI 动不动修改数据库导致多人操作冲突。把写权限关掉，让 AI 生成 Flyway 脚本，本地测试时让 Flyway 跑。 - -3.2 DSL 驱动的技术规格 - -用领域特定语言（DSL）来驱动技术规格： -领域模型用 PlantUML -数据库用 DBML -API 用 OpenAPI -这些 DSL 都可以通过代码生成 → 保证前后端一致性 - -这实际上就是模型驱动架构（Model-Driven Architecture），当团队从零开始全新的 AI 项目时，这种严格的检查和约束更容易建立。 - -四、打样工程：AI 友好的代码框架 - -4.1 什么是打样工程 - -打样工程（Seed Project）是一个预先定义好的代码框架模板，包含： -每层的类名和职责定义 -代码规范和最佳实践 -依赖配置和目录结构 - -4.2 打样工程的作用 - -AI 生成代码风格一致：所有 AI 都基于同一个框架生成代码 -减少重复代码：AI 会复用框架中的组件而不是重复写 -降低认知负担：AI 不需要每次理解项目结构 - -4.3 如何创建打样工程 - -从旧项目中蒸馏出一个干净的新项目骨架 -定义每层职责：Controller → Service → Repository → Entity -定义类命名规范和包结构 -放入 Git 仓库供团队共享 - -五、开发阶段：让 AI 听话写出统一风格的代码 - -5.1 用 RAG（检索增强生成）提供上下文 - -将技术规格、代码规范、历史决策等信息放到代码仓库的 /docs 或 /book 目录下，AI 通过检索这些文档获得上下文： - -`markdown -/my-project - /book - /requirements # 需求规格 - /specifications # 技术规格 - /api-docs # API 文档 - /src - /skills - /mcp -` - -5.2 多任务同步开发：Worktree 的使用 - -Git Worktree 可以把分支映射成目录，实现多任务并行： - -`bash -创建多个工作目录 -git worktree add ../feature-order feature/order -git worktree add ../feature-user feature/user - -在不同目录下同时工作，做完后合并 -` - -但要注意： -多人同时操作多人工作时，版本管理会比较痛苦 -建议提前把规格设计好，让 AI 慢慢跑，而不是同时开太多任务 - -5.3 不要让 AI 边写代码边做设计 - -用 rapper5 的思路：Discovery/Design 和 Coding 分两个阶段。 -先做探索性设计，让不同 AI 模型（GPT、Claude、Gemini）各自给出方案 -选定方案后，再激活 Coding 角色专职写代码 -切换角色时重置上下文，避免 AI 注意力分散 - -六、测试阶段：AI 写代码形成闭环的核心 - -6.1 为什么测试是 AI 编程的命脉 - -"没有 API 测试和单元测试，无法形成 AI 写代码的闭环。" - -AI 生成代码后必须能自我验证，否则： -人工验证效率极低 -AI 无法发现自己的问题 -团队无法真正提效 - -6.2 测试策略（3 层） - -| 测试类型 | 工具 | 驱动方式 | -|----------|------|----------| -| 单元测试 | JUnit / pytest | TDD：先写测试让 AI 失败，再写实现 | -| API 测试 | REST Assured / Newman | 自动化回归，可直接卡 90%+ 覆盖率 | -| E2E 测试 | Playwright（推荐，替代了 Selenium） | 上线前 80% 的 case 回归覆盖 | - -6.3 TDD 循环（SuperPower 的工作方式） - -让 AI 先写 API 测试/单元测试 -AI 运行测试 → 失败 -AI 再写实现代码 -AI 自动运行测试验证 → 通过 - -效果：单元测试可达 100% 覆盖率，API 测试可达 90%+ 覆盖率。 - -6.4 AI 写测试解决假阳性问题 - -有时候 AI 为了让测试通过，会伪造测试逻辑。解决方案： -TDD 先写测试：先让测试失败，再让 AI 写实现 -交叉验证：用不同的 AI 模型互相 review 代码和测试 - -6.5 测试用例的管理 - -测试用例直接放到代码仓库中： -单元测试：跟随代码模块 -API 测试：放在 /test/api 目录 -E2E 测试：用 TypeScript + Playwright，放在代码仓库根目录（或与前端项目同仓库） - -七、Review 阶段：AI 辅助 Code Review - -7.1 多种 Review 方式 - -工具扫描：SonarQube 等静态分析工具 + AI 自动修复 -AI Review：用另一个 AI 模型做交叉 review（换模型做 review 是常用技巧） -Agent 自动触发：在 PR 阶段自动触发 Review Agent - -7.2 AI Review 的问题与解决方案 - -问题：AI Review 总是会提改进建议，哪怕没有明显问题（因为你的 prompt 让它提问题）。 - -解决方案： -设置阈值：达到一定级别才提问题，否则不输出 -让 AI 只关注 bug 和逻辑错误，不过度关注风格问题 -用团队的架构规约来约束 Review 标准 - -7.3 不同场景的 Review 策略 - -全新项目（AI 100% 生成）：可以用最严格的规则，AI 写完直接修 -混合项目（人 + AI）：可能存在历史遗留问题，Review 结果噪音多，建议从新模块开始逐步规范 -跨系统场景：AI 容易犯错（尤其涉及 3-5 个系统的交互），建议收敛到单个仓库处理 - -经验：跨系统时 AI 犯错误概率高达 70-80%，核心原因是缺少完整的系统间关系和业务规则上下文。 - -八、工具链：AI 编程工具全景 - -8.1 三类 AI 编程工具 - -| 类型 | 代表工具 | 特点 | -|------|----------|------| -| 命令行 CLI | Claude Code, OpenAI Codex | 适合快速操作、脚本化 | -| IDE 集成 | Cursor, Windsurf, VS Code AI | 适合日常开发，界面友好 | -| 辅助插件 | SuperPower（推荐个人）, Copilot | 按需使用 | - -8.2 常用 MCP（Model Context Protocol） - -| MCP | 用途 | -|-----|------| -| 数据库 MCP | 操作数据库（注意：只读，写权限建议关闭） | -| Figma MCP | 读取设计稿 | -| Jira MCP | 管理工单 | -| Git MCP | 代码提交、PR 操作 | - -8.3 Skills 体系 - -Skills = 一段提示词 + 模板 + 脚本，用于描述工作方法。 - -把打样工程的初始化做成 Skill -把团队规范做成 Skills -Skills 放到代码仓库中共享 - -重要观点： -"现在 AI 理解力已经很强大，不需要把规范落实为非常固定的格式，只要表达清楚信息、强调重点即可。" - -主流 Skill 框架： -SuperPower：内置大量 Skills，开箱即用，适合个人 -Claude Agent（hermes）：自动基于对话生成和优化 Skills -MCP：工具调用协议 - -8.4 为什么不推荐 SDD 框架 - -SDD（Scenario-Driven Development）框架本身很好，但落地难度在于团队共识： - -需要团队所有人按照相同流程工作 -现实团队中阻力很大（不是不愿意用，是习惯改不了） -SuperPower 对个人很好用，但团队级很难推广 - -结论：与其强推 SDD 框架，不如团队自己定义一套 Roos + Skills + MCP 的组合。 - -九、架构型思考：未来趋势 - -9.1 Agent Code 的趋势 - -未来必然会出现 "Agent Code" 的概念——把整个团队的所有产物（需求、规格、规范、测试）全部代码化，放到代码仓库中统一管理： - -`markdown -/.agent - /skills # 工作方法 - /mcp # 工具配置 - /templates # 模板 - /rules # 规范 - /docs # 文档 -` - -所有 AI 工具（SuperPower、Claude Code 等）安装时都从代码库读取配置，实现极致高效。 - -9.2 多 Agent 协调的挑战 - -当前多 Agent 框架（如 CrewAI、AutoGen）还处于早期阶段： -缺少程序级别的精确校验（不能完全依赖 AI 判断） -Agent 与代码之间的交互需要程序驱动而非纯 AI 驱动 -可能需要自己写 workflow 调度器 - -9.3 共识是第一要务 - -"工具是玩人的，为了获得团队的共识。" - -大公司之所以比小公司/创业公司更难推进 AI 编程变革，是因为： -习惯难以改变 -团队文化难以调整 -需要从上到下的强力推动 - -十、团队实践建议 - -10.1 渐进式落地路线 - -单人验证阶段：选择一个简单项目，用 SuperPower + TDD 验证 AI 编程效率 -规范建立阶段：定义技术规格模板、代码规范、打样工程 -团队推广阶段：用 Skills 标准化工作方法，逐步让团队接受 -自动化阶段：打通从需求到部署的全流程，实现"代码即一切" - -10.2 技术经理的核心职责 - -定义 AI 友好的需求规格模板 → 推动 BA/产品接受 -建立打样工程和代码规范 → 控制代码质量下限 -推动测试文化 → 这是专业和非专业软件公司的分界线 -构建团队共识 → 这是最难也是最重要的事 - -10.3 避坑指南 - -不要让 AI 直接写数据库：用 Flyway 脚本版本化管理 -不要拆分过于细小的需求：一个模块一个文档 -变更需求一定要标注变更类型：不要给完整状态 -不要让 AI 同时做设计和代码：分阶段，用不同角色 -不要完全依赖 AI Review：用规则约束、AI + 人工结合 - -十一、观众反馈与补充 - -华为 CodeArts Agent：带有规范驱动开发模式，可以参考 -Obsidian + Opal：适合做 Markdown 知识库管理，手机和电脑同步，适合在外也能用手机+终端工作 -看板式 AI 协同：所有需求、设计、任务全部看板化，共享给团队成员 -跨 Agent 通信：契约文件（如 OpenAPI JSON）放到共享目录，前后端各自读取 → 避免前端改完后端不知道的问题 -sonarlint 本地扫描 + AI 自动修复：在 pre-commit 阶段触发静态扫描，AI 自动修复代码风格问题，效果很好 - -────────────────────────────── -Generated by MilkyAi@Bilibili: https://space.bilibili.com/3461574540921489 \ No newline at end of file diff --git a/InBox/milky_BV1Z5EL6XE2m.md b/InBox/milky_BV1Z5EL6XE2m.md deleted file mode 100644 index 5265d0d..0000000 --- a/InBox/milky_BV1Z5EL6XE2m.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: "[Milky] 为您整理《提示词工程：变量系统与条件渲染》笔记 | BV1Z5EL6XE2m" -source: "milky@4ueo.com" -date: 2026-06-09 23:03 -tags: [milky, bilibili, notes] -email_id: 2630 ---- - -Milky 为您整理了《提示词工程：变量系统与条件渲染》 | BV1Z5EL6XE2m 笔记。 - -提示词工程：变量系统与条件渲染 - -背景：为什么需要变量系统？ - -在之前的视频中，我们讨论了提示词的基本写法——角色、标签、结构等。但从现在开始，讲解的核心转向：如何一次写好、多次复用。 - -现实问题 - -当你只有一个项目时，直接编写提示词没有问题。但当场景变成这样： - -你写了一个代码审查提示词，效果很好 -老板要求把这个提示词应用到项目 B、C、D、E、F - -如果提示词中写死了： -项目路径 -审查重点 -配置规则 - -你只能： -复制 5 份提示词 -逐个修改路径和审查重点 - -结果是：6 个项目 = 6 份提示词，改一个地方需要改 6 次 - -解决方案：模板化 - -将提示词做成模板，把可变部分替换为变量，运行时注入具体值： - -` -一份模板 → 适配所有项目 -改一个地方 → 全部项目生效 -` - -变量系统的本质 - -可以把提示词模板理解为填空题： - -` -今天天气真，我打算去，带上我的_。 -` - -填入不同内容： - -| 填空1 | 填空2 | 填空3 | -|-------|-------|-------| -| 热 | 海边 | 冲浪板 | -| 凉快 | 公园 | 摄像机 | - -提示词变量本质上是这种机制，只不过填空的内容变成： -项目路径 -漏洞类型 -配置规则 -审查重点 -其他基础参数 - -Shannon 生产环境案例 - -在 Shannon 的生产环境中： -存在几十个提示词文件 -每个提示词会被用于上百个不同的项目 - -如果不做模板化，维护成本是灾难性的。 - -变量系统的进阶能力 - -变量系统的能力不止于此，还能实现更强大的功能：让整个段落、整个章节出现或消失。 - -就像一份智能问卷： -根据你前面的回答 -自动显示或隐藏后续的问题 - -预告：后续视频内容 - -本系列将依次讲解： - -简单的替换 -最直观的填空方式，变量值决定替换成什么内容 - -条件渲染 -变量的值不仅决定换成什么，还决定要不要显示。例如： -变量 X = "启用" → 显示某个章节 -变量 X = "关闭" → 该章节完全不出现 - -前缀感值 -一个变量同时控制标点和内容，例如根据变量值自动添加合适的语气词或连接词 - -提示词中的 import 语句 -类似代码中的 import，实现提示词的模块化和复用 - -总结 - -在讲解变量系统与条件渲染的过程中，会越来越发现：提示词工程和写代码非常相似。 - -提示词本质上是 AI 时代的人类编程语言——通过模板化、变量、条件控制等机制，实现提示词的高效复用和灵活配置。 - -────────────────────────────── -Generated by MilkyAi@Bilibili: https://space.bilibili.com/3461574540921489 \ No newline at end of file diff --git a/InBox/milky_BV1i77X6pE1C.md b/InBox/milky_BV1i77X6pE1C.md deleted file mode 100644 index fdfd16e..0000000 --- a/InBox/milky_BV1i77X6pE1C.md +++ /dev/null @@ -1,192 +0,0 @@ ---- -title: "[Milky] 为您整理《Shopify：内部 Agent， 为什么不准员工私聊？——AI native组织要的不是个人提效，是组织自进化》笔记 | BV1i77X6pE1C" -source: "milky@4ueo.com" -date: 2026-06-09 21:17 -tags: [milky, bilibili, notes] -email_id: 2054 ---- - -Milky 为您整理了《Shopify：内部 Agent， 为什么不准员工私聊？——AI native组织要的不是个人提效，是组织自进化》 | BV1i77X6pE1C 笔记。 - -Shopify 内部 Agent River：为什么不准员工私聊？ - -核心观点 - -AI-native 组织的门槛不是个人更快，而是组织能从经验中学习、能自进化。 - -单纯给员工配备私人 AI Agent，可能让每个人变快，但组织本身没有进化。 - - -问题背景：企业对 AI 的常见误区 - -误区做法 - -给每个员工开 AI 账号，配一个自己的 Agent，让他跑在： - -本地终端 -编辑器私人对话框 -私聊窗口里 - -效果 - -查问题更快 -改代码更快 -跑测试更快 - -真正的门槛 - -更硬的问题是：组织能不能从这些 AI 工作里学习？ - -能否把一次排查、一次修复、一次好判断，变成后面所有人和所有 Agent 都能继承的经验？ - - -核心对比：私人 Agent 的天花板 - -| 维度 | 私人 Agent | 公开 Agent（River） | -|------|-----------|---------------------| -| 服务范围 | 键盘前那个人 | 整个团队 | -| 上下文来源 | 单人输入 | 多人补充 | -| 经验沉淀 | 个人日志 | 组织语料 | -| 复现性 | 低（过程不可见） | 高（可搜索、复用） | -| 学习能力 | Agent 之间互相学不到 | 团队协作促进 Agent 进化 | - -私人 Agent 的局限性 - -以一次排查偶发失败测试为例： - -你昨天怎么定位问题？ -中间错了哪些方向？ -最后是哪条线索把问题收住？ - -这些问题即使留在日志里，也只是事后材料： - -不会天然变成多人协作现场 -别的工程师不会在过程中看到 -不会有人顺手补一个约束 -下一次类似情况，不会自动从这条路径开始 - - -River 的设计选择 - -基本工作方式 - -River 是 Shopify 内部 Slack 里的 AI Agent： - -员工不在私聊窗口找他，要到内部公开频道里 @ 他 -River 会执行：读代码、跑测试、开 PR、查数据仓库、看生产链路记录 -必要时，River 还会反驳他认为不好的计划 - -硬性产品约束 - -` -只支持公开频道工作，不支持一对一私聊 -` - -每一次和 River 的对话，都会变成一条 Slack 线程记录，默认对 Shopify 内部员工可见。 - -注：这里的"公开"指 Shopify 内部 Slack 范围内可见，不是互联网公开。 - - -公开线程的工作机制 - -典型场景 - -` -工程师 A 在频道提问 - ↓ -River 开始工作：读文件、跑查询、贴出部分发现 - ↓ -工程师 B 看到（通过频道链接或被人拉进来） - ↓ -B 补一句关键约束： - - "这个表不能这样查" - - "这个服务刚迁移过" - - "这个测试以前失败过，原因可能不在这里" - - "这个方案会影响另一个团队" - ↓ -River 吸收新上下文，继续往下查 -` - -公开 vs 私人的关键差别 - -私人对话：AI 多数只继承一个人的上下文 -公开线程：AI 进入的是一个多人协作现场 - - -组织学习机制：语料挖掘与回写 - -公开线程记录会形成一套可挖掘的组织语料，Shopify 会： - -挖掘反复出现的模式 -把这些模式回写到 River 的： - - 技能（Skills） - - 提示词（Prompts） - - 默认动作（Default Actions） - -具体沉淀内容 - -| 沉淀内容 | 说明 | -|---------|------| -| 排查路径 | 哪些排查路径有效 | -| 工程约束 | 哪些工程约束应该默认带上 | -| 提示词/技能 | 哪些提示词和技能动作可以沉淀下来 | - -核心机制 - -` -一个人硬啃出来的修复办法 → 下一个人的起点 -一个线程里反复出现的约束 → River 以后更容易带上的上下文 -` - -一次好的排查，不再只是某个人和某个 Agent 的私有经历，而是开始教会后面的线程。 - - -边界与限制 - -不等于禁止所有私聊 - -企业不是不能有任何 AI 私聊，而是 River 这个 Agent 坚持不做私聊入口。 - -需要边界控制的场景 - -以下敏感问题仍然要有边界： - -权限相关 -安全相关 -人事相关 -法务相关 - -River 的定位 - -River 处理的是那些值得被组织记住的工作，而不是所有对话。 - - -核心启示 - -对老板和技术负责人的问题清单 - -部署 AI Agent 时，不仅要问： - -❌ 员工有没有 Agent？ -❌ 对话日志能不能回收？ -❌ 个人效率有没有提升？ - -更要问： - -✅ 这些 Agent 对话会不会教会后面的线程？ -✅ 员工用 AI 解决问题的过程，是一份后台日志，还是一个团队能参与、能接力、能复用的工作现场？ - -结论 - -| 类型 | 结果 | -|------|------| -| 如果只是后台日志 | 一堆分散的个人提效，每个人都快了一点，但组织没有变聪明 | -| 如果是可协作的工作现场 | 组织从每次 AI 工作中学习，实现自进化 | - -金句 - -私人 Agent 的天花板是键盘前那个人。 -公开 Agent 的价值是让后面的线程不从零开始。 - -────────────────────────────── -Generated by MilkyAi@Bilibili: https://space.bilibili.com/3461574540921489 \ No newline at end of file diff --git a/InBox/milky_BV1mZV76eEPC.md b/InBox/milky_BV1mZV76eEPC.md deleted file mode 100644 index 69bd25b..0000000 --- a/InBox/milky_BV1mZV76eEPC.md +++ /dev/null @@ -1,181 +0,0 @@ ---- -title: "[Milky] 为您整理《2026-05-30 SDD 规格驱动落地，文档管理策略》笔记 | BV1mZV76eEPC" -source: "milky@4ueo.com" -date: 2026-06-09 21:17 -tags: [milky, bilibili, notes] -email_id: 2044 ---- - -Milky 为您整理了《2026-05-30 SDD 规格驱动落地，文档管理策略》 | BV1mZV76eEPC 笔记。 - -SDD 规格驱动落地：文档管理策略 - -研讨会背景与目的 - -本次分享是 AI 编程相关话题的延续，主要聚焦 SDD（Spec-Driven Development，规格驱动开发） 的文档管理策略。 - -研讨会机制 - -目的：让参会者能够参与达成社区共识，分享各公司在 AI 编程实践中的经验 -形式：咨询师分享观察到的公司实现方案、架构设计、系统设计等内容 -价值：对个人和团队帮助都非常大，通过集体讨论形成共识 - -特别感谢卡尼克老哥在研讨会期间贡献了大量分享思想，受益颇多。 - - -AI 编程发展历程回顾 - -时间线概览 - -| 时间 | 分享内容 | 核心概念 | -|------|----------|----------| -| 2025年6月 | 早期 AI 编程实践 | DPER5 方法论 | -| 后续 | MCP 等工具整合 | MCP、Scales | -| 5月9日 | Plan 和 Build 模式 | 新因子（吸引子）概念 | -| 本次 | SDD 文档管理策略 | 规格驱动落地 | - - -DPER5 方法论 - -核心思想 - -DPER5 将软件工程中使用 AI 进行开发的过程分为 5 个弱阶段（Weak Stages）： - -` -Discover → Plan → Execute → Review → Refine - ↓ ↓ ↓ ↓ ↓ - 发现 规划 执行 评审 优化 -` - -阶段特性 - -不同阶段 AI 会按照不同的模式运行 -例如在 Design 模式或 Discover 模式下，AI 不会修改代码 -这种分阶段约束是驯服 AI 的简单有效方法 - -实践应用 - -在早期阶段（2025年），演讲者已经在公司内部领先应用 -采用 Design → Plan → Execute 的流程驱动开发 -该方法使用了较长时间，有效规范了 AI 辅助开发流程 - - -MCP（Model Context Protocol）工具生态 - -工具整合 - -后续随着 MCP 以及相关工具套件的出现，形成了完整的 AI 编程工具生态： - -MCP（Model Context Protocol）：模型上下文协议 -Scales：扩展工具 -SDD：规格驱动开发方法论 - -这些工具被整合到一份 PPT 手册中，作为团队 AI 编程的指南或手册参考。 - - -SDD（规格驱动开发） - -SDD 的核心模式 - -SDD 提供了多种工作模式，适用于不同的开发场景： - -| 模式 | 适用场景 | AI 行为特征 | -|------|----------|-------------| -| Design | 需求分析、架构设计 | 不修改代码，仅提供设计建议 | -| Discover | 探索发现、方案调研 | 不修改代码，专注于信息收集 | -| Plan | 规划分解、任务拆解 | 生成实现计划 | -| Build | 代码实现、具体开发 | 执行代码编写和修改 | - -新因子（吸引子）概念 - -由 countic 大佬在 5月9日的分享中引入： - -物理学的概念解释： - -在混沌系统中，存在两种震荡反馈的系统 -这种系统最终会收敛到一个稳定状态 -这个收敛点被称为 吸引子（Attractor） - -在 AI 编程中的应用： - -通过引入新因子，可以引导 AI 的输出趋向于预期的稳定状态 -帮助控制 AI 在复杂任务中的发散性 -实现更可控的 AI 驱动开发流程 - - -SDD 文档管理策略 - -本次分享的核心主题，聚焦于规格驱动开发的文档管理方法 - -文档在 SDD 中的作用 - -规格定义：明确需求和设计规范，作为开发的基准 -上下文传递：在不同阶段之间传递上下文信息 -版本控制：记录规格的变更历史 -团队协作：统一团队对需求的理解和实现方式 - -文档管理最佳实践 - -（基于 SDD 方法论，文档管理应遵循以下原则） - -规格优先：在开发前先完成规格文档的编写 -增量迭代：规格文档随项目进展逐步完善 -双向追溯：规格与实现之间保持可追溯性 -工具集成：将文档管理与 AI 编程工具链整合 - - -工具链整合方案 - -推荐的 AI 编程工具栈 - -` -┌─────────────────────────────────────────────────────┐ -│ 规格层 (Spec) │ -│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ -│ │ Design │ │ Discover │ │ Plan │ │ -│ └─────────────┘ └─────────────┘ └─────────────┘ │ -├─────────────────────────────────────────────────────┤ -│ 工具层 (Tools) │ -│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ -│ │ MCP │ │ Scales │ │ SDD │ │ -│ └─────────────┘ └─────────────┘ └─────────────┘ │ -├─────────────────────────────────────────────────────┤ -│ 执行层 (Execution) │ -│ ┌─────────────┐ ┌─────────────┐ │ -│ │ Build │ │ Review │ │ -│ └─────────────┘ └─────────────┘ │ -└─────────────────────────────────────────────────────┘ -` - -MCP 的核心功能 - -提供标准化的上下文协议 -实现 AI 与外部工具的无缝集成 -支持多工具协同工作 - - -社区贡献者致谢 - -| 贡献者 | 贡献内容 | -|--------|----------| -| 卡尼克 | 大量分享思想，研讨会核心参与者 | -| countic | 引入新因子（吸引子）概念，分享 Plan/Build 模式 | -| 少个分号 | SDD 方法论整理，工具链整合，文档管理策略分享 | - - -后续话题预告 - -本次分享的议程安排： - -SDD 文档管理策略（当前内容） -AIGC 模板相关话题（由卡尼克老哥分享） - - -参考资源 - -本次分享的 PPT 资料（可作为团队 AI 编程手册/指南） -搜索关键词：AI编程、MCP、SDD、DPER5、规格驱动开发 -相关标签：人工智能、规格驱动开发、AI编程 - -────────────────────────────── -Generated by MilkyAi@Bilibili: https://space.bilibili.com/3461574540921489 \ No newline at end of file diff --git a/InBox/milky_BV1p9QnBtEMq.md b/InBox/milky_BV1p9QnBtEMq.md deleted file mode 100644 index 91b5b31..0000000 --- a/InBox/milky_BV1p9QnBtEMq.md +++ /dev/null @@ -1,273 +0,0 @@ ---- -title: "[Milky] 为您整理《让AI真正读懂证据间的因果：深度验证框架解决逻辑断层，实现92.0%平衡准确率》笔记 | BV1p9QnBtEMq" -source: "milky@4ueo.com" -date: 2026-06-09 21:17 -tags: [milky, bilibili, notes] -email_id: 1987 ---- - -Milky 为您整理了《让AI真正读懂证据间的因果：深度验证框架解决逻辑断层，实现92.0%平衡准确率》| BV1p9QnBtEMq 笔记。 - -病例驱动证据验证框架：从表面匹配到可验证推理 - -研究背景与问题 - -当前 AI 证据引用的核心缺陷 - -现有 AI 模型在引用外部证据时存在严重的逻辑断层问题： - -| 缺陷类型 | 具体表现 | -|---------|---------| -| 表面匹配依赖 | 过度依赖文本相似度，用文字重合度"走捷径" | -| 逻辑断层 | 未真正理解证据与主张之间的因果关系 | -| 虚假支撑 | 生成看起来合理但缺乏逻辑支撑的回答 | -| 高风险隐患 | 在医疗、法律等领域可能导致致命错误 | - -问题本质 - -模型并未真正"看懂"证据，而是利用文本重合度生成看似合理的回答。这种虚假的逻辑支撑在专业领域非常危险。 - - -解决方案：三位一体验证框架 - -框架架构 - -研究团队提出病例驱动验证框架（Case-Driven Evidence Verification），核心是三位一体结构： - -` -┌─────────────────────────────────────────────────────┐ -│ 验证任务 │ -│ （转化为严苛的判断题） │ -├─────────────────────────────────────────────────────┤ -│ │ -│ ┌─────────┐ ┌──────────────┐ ┌───────────┐ │ -│ │ 具体情境 │ + │ 外部证据 │ + │ 结构化主张 │ │ -│ │ CASE │ │ EVIDENCE │ │ CLAIM │ │ -│ └─────────┘ └──────────────┘ └───────────┘ │ -│ │ -│ ↓ │ -│ 模型输出裁定结果 VERDICT │ -│ （支持 / 不支持） │ -└─────────────────────────────────────────────────────┘ -` - -工作机制 - -输入三元组：同时输入具体情境（Case）、外部证据（Evidence）和结构化主张（Claim） -判断题模式：将任务转化为判断题，强制模型输出明确裁定 -逻辑验证：验证证据在当前情境下是否真实支撑主张 - - -自动化数据生成方法 - -核心创新 - -零人工标注成本的自动化数据生成流水线，整合两大数据源： - -| 数据源 | 用途 | -|-------|------| -| MIMIC-CXR（真实影像报告） | 提取病例状态（Case） | -| Radiopaedia（医学知识库） | 抽取数万条证据（Evidence） | - -通过 Refire Core 逻辑规则智能重组，自动映射成数十万条正负样本。 - -四类训练样本 - -| 样本类型 | 特征 | 作用 | -|---------|------|------| -| 正样本 | 明确支持主张 | 学习正确关联模式 | -| 错误状态陷阱 | 高度相关但结论相反 | 封堵关键词匹配捷径 | -| 困难负样本 | 因果关系复杂 | 强化深层理解 | -| 简单负样本 | 明显不支持 | 基线学习 | - -反事实负样本（核心突破） - -语义特征：与主张极度接近，包含所有核心关键词 -逻辑特征：由于病例特征差异，推导方向与主张完全相反 -占比：25% 的数据集专门用于封堵关键词匹配捷径 - -目的：逼迫模型放弃表面关联，深入理解文字背后的逻辑因果。 - - -实验设计与结果 - -关键对比实验 - -病例深度关联的效果 - -| 配置 | AUPRC | 平衡准确率 | -|-----|-------|-----------| -| 纯证据验证 | 35.1% | — | -| 深度关联验证 | 87.8% | 92.0% | - -结论：单纯堆砌资料不能让 AI 变聪明，结合具体情境才能实现性能跨越。 - -关键词陷阱测试 - -场景：病例明确显示无胸腔积液，面对包含相同术语的干扰证据 - -| 模型 | 支持率 | -|-----|-------| -| 普通 AI | 99.1% | -| 深度验证模型 | 0.000% | - -结论：框架能有效识破伪装，不再盲目信任语义相近但逻辑无关的信息。 - -物理干预测试（检验推理真实性） - -三种极端条件： - -| 测试条件 | 描述 | AUPRC | F1 分数 | -|---------|------|-------|---------| -| 正常关联证据 | 基线测试 | 87.8% | 高 | -| 清空证据 | 切断所有参考资料 | 大幅下降 | 大幅下降 | -| 交换证据 | 张冠李戴的专业文本 | 21.7% | 显著缩水 | - -结论：性能急剧崩溃证明模型高度依赖正确的外部证据，而非死记答案。 - -证据数量与性能关系 - -| 证据数量 | AUROC | -|---------|-------| -| 1 句 | 较低 | -| 2 句 | 97.4%（巅峰） | -| 10 句 | 基本持平 | - -关键发现：模型不需要翻阅数百页文档，只需抓准最关键的两句信息就能实现满血性能。过度堆砌资料反而引入背景干扰。 - -全维度性能对比 - -| 方法 | AUROC | AUPRC | BRI Score | -|-----|-------|-------|-----------| -| 纯情境推断 | 59.90% | — | 高 | -| 纯证据验证 | — | 35.11% | 高 | -| 三位一体深度关联 | 97.43% | 87.8% | 0.060 | - - -泛化能力验证 - -陌生知识测试（Held-out Content） - -使用从未参与训练的全新医学百科文章： - -| 指标 | 结果 | -|-----|------| -| AUROC | 97.2% | -| F1 分数 | 77.9% | - -结论：模型学习到的是通用验证逻辑，而非对特定教材句式的死记硬背。 - -跨数据集迁移 - -将基于 MIMIC-CXR 训练的模型直接空降到 CheXpert Plus 数据集（6万+患者）： - -| 指标 | 结果 | -|-----|------| -| AUROC | 93.46% | -| 平衡准确率 | 87.45% | - -结论：即便面对截然不同的书写风格和病例分布，模型验证能力依然在线，展现极强落地适应性。 - -底层模型对比 - -| 模型 | 参数量 | AUPRC | 特点 | -|-----|-------|-------|------| -| DeBERTa-v3-large | 3.95亿 | 87.8% | 综合最强，面对未知证据最稳 | -| FlanT5-large | — | 次之 | 经典大模型 | -| RoBERTa-large | — | — | 经典 baseline | - -结论：更现代的特征提取器能更敏锐地锁定微小的语义偏差。 - - -应用场景 - -临床问答护城河 - -` -检索器 → 生成器 → 【验证框架】 → 医生 - ↓ - 输出置信度分数 - 拦截 99% 幻觉主张 -` - -作为最后一道交叉质证 -有效拦截无依据方案 -辅助医生做出更稳健的决策 - -自动化医疗报告审核 - -自动提取结构化结论 -与原始影像发现及医学标准逐一核对 -实时标注逻辑冲突，提示人工复核 -减轻高年资医生审核负担 -杜绝因疲劳引发的关键性疏漏 - -跨领域泛化 - -| 领域 | 应用 | -|-----|------| -| 法律合规 | 核实法条是否真实适用于案件事实 | -| 科研验证 | 自动检查实验引用是否存在张冠李戴 | -| 企业知识库 | 核对工单与操作手册，拒绝随意发挥 | - - -范式跃迁：从 RAG 到 VAG - -| 范式 | 特征 | 核心区别 | -|-----|------|---------| -| RAG（检索增强生成） | 只要检索文本看起来相似，就强行作为答案参考 | 区分相关性与支撑性 | -| VAG（验证增强生成） | 只有存在明确逻辑因果的文本才被认定为有效证据 | 追求确凿性 | - -本质转变：AI 从松散的文本拼接机器 → 严谨的逻辑推演中枢 - - -当前局限与未来路线 - -技术边界 - -| 局限类型 | 具体问题 | -|---------|---------| -| 泛化损耗 | 面对截然不同的新证据时，AUPRC 指标仍会产生客观衰减 | -| 多状态扩展 | 目前主要验证二元主张，未来需向复杂多元连续图谱扩展 | -| 端到端噪声 | 引入全网实时检索后，对模型抗干扰能力提出更高要求 | - -演进路线 - -` -第一阶段（已完成） 第二阶段（进行中） 第三阶段（愿景） - ↓ ↓ ↓ -三位一体验证框架 → 端到端动态检索 → 人类专家深度对齐 - + + - 非结构化长文本 证据链自我修剪 - 高噪声环境 自主思考 Agents -` - - -核心结论 - -| 指标 | 结果 | 意义 | -|-----|------|------| -| AUPRC | 87.8%（提升 52.6%） | 跨越性性能提升 | -| 平衡准确率 | 92.0% | 高可靠性 | -| BRI Score | 0.060 | 极低预测误差 | - -核心启示：真正的智能不仅在于调取知识，更在于懂得如何对证据负责。 - - -术语表 - -| 术语 | 全称 | 解释 | -|-----|------|------| -| AUPRC | Area Under Precision-Recall Curve | 精确率-召回率曲线下面积，衡量不平衡数据集性能 | -| AUROC | Area Under Receiver Operating Characteristic Curve | ROC 曲线下面积，衡量分类器区分能力 | -| BRI Score | Brier Score | 预测误差的均方误差，越低越准确 | -| RAG | Retrieval-Augmented Generation | 检索增强生成 | -| VAG | Verification-Augmented Generation | 验证增强生成 | -| DeBERTa | Decoding-enhanced BERT with disentangled attention | 更现代的预训练语言模型架构 | -| MIMIC-CXR | Medical Information Mart for Chest X-ray | 公开胸部 X 光影像数据集 | -| 反事实负样本 | Counterfactual Negative Samples | 语义相似但逻辑结论相反的样本，用于测试模型是否真正理解因果关系 | -| CheXpert Plus | — | 斯坦福大学胸部 X 光数据集 | -| Refire Core | — | 逻辑规则引擎，用于自动构建训练样本 | - -────────────────────────────── -— Milky 视频总结助手 \ No newline at end of file diff --git a/InBox/milky_BV1tJwKzDE8x.md b/InBox/milky_BV1tJwKzDE8x.md deleted file mode 100644 index b48737a..0000000 --- a/InBox/milky_BV1tJwKzDE8x.md +++ /dev/null @@ -1,320 +0,0 @@ ---- -title: "[Milky] 为您整理《【AI翻译】别再自己钻研Claude技巧了，Autoresearch帮你搞定》笔记 | BV1tJwKzDE8x" -source: "milky@4ueo.com" -date: 2026-06-09 21:17 -tags: [milky, bilibili, notes] -email_id: 1983 ---- - -Milky 为您整理了《【AI翻译】别再自己钻研Claude技巧了，Autoresearch帮你搞定》| BV1tJwKzDE8x 笔记。 - -AutoResearch 自动优化 Claude Code Skills 完整指南 - -目录 - -核心概念 -为什么需要自动研究 -AutoResearch 仓库解析 -自动研究的三个要素 -评估设计原则 -实战演示流程 -演示结果 -最佳实践与注意事项 - - -核心概念 - -Claude Code Skills 现状 - -Claude Code Skills（云代码技能）是用于扩展 Claude Code 能力的提示词文件，但存在稳定性问题： - -| 指标 | 比例 | -|------|------| -| 运行技能得到预期输出 | ~70% | -| 运行技能输出垃圾结果 | ~30% | - -什么是 AutoResearch - -AutoResearch 是由 Andre Karpathy（OpenAI 创始成员、前特斯拉 AI 负责人）发布的一个 GitHub 仓库，核心功能是让一组 AI 智能体能够自主优化某个流程。 - -原仓库地址： -` -https://github.com/karpathy/auto-research -` - - -AutoResearch 仓库解析 - -该仓库刻意设计得非常精简，只有三个重要文件： - -文件结构 - -` -auto-research/ -├── prepare.py # 机器学习专用（训练分词器等），与技能优化无关 -├── train.py # 核心文件，相当于你的 skill.md -└── program.py # 核心文件，相当于你的智能体 -` - -工作原理类比 - -| AutoResearch 组件 | 对应内容 | -|-------------------|----------| -| train.py | 你的 skill.md（要优化的技能提示词） | -| program.py | 你的智能体（负责改进技能） | - -优化流程 - -` -给智能体（program.py）一个高级指令 -智能体运行技能（train.py），根据评估标准评分 -智能体判断"这次是否比上次好" -自动迭代，提示词越来越严密 -每 N 分钟自动运行一次（如每 5 分钟） -` - - -自动研究的三个要素 - -要让自动研究工作，你需要准备好： - -客观指标（Objective Metric） - -一个可量化测量的数字，而不是模糊的感觉描述。 - -示例： - -| 应用场景 | 客观指标 | -|----------|----------| -| 网站加载速度 | 毫秒（ms） | -| 冷邮件活动 | 回复率（%） | -| Claude Code Skill | 通过率 / 评估分数 | - -测量工具（Measurement Tool） - -理想情况下应该自动化、可靠，无需人工介入。 - -示例： - -| 应用场景 | 测量工具 | -|----------|----------| -| 网站性能 | Google Lighthouse | -| 冷邮件 | 即时 API 分析 | -| Skills | 测试套件（智能体编写的自动化测试） | - -可改变的东西（Variable to Change） - -整个优化的对象： - -| 应用场景 | 改变的内容 | -|----------|------------| -| 网站优化 | 代码改动 | -| 冷邮件优化 | 邮件文案 | -| Skills 优化 | 提示词内容（skill.md 文件） | - - -评估设计原则 - -为什么需要多次运行评估 - -AI 输出本质上是数据分布，存在随机性： - -` -运行 20 次技能（生成 20 张图片） - ↓ -每次输出都有细微差别 - ↓ -有些图片相似，有些不同 - ↓ -必须运行多次，用统计方法评估 -` - -评估的三个统计指标 - -| 指标 | 含义 | 作用 | -|------|------|------| -| 众数（Mode） | 出现频率最高的值 | 判断"最常见的结果是什么" | -| 中位数（Median） | 排序后的中间值 | 判断"大致平均水平" | -| 平均值（Mean） | 所有分数之和除以次数 | 判断"总体表现" | - -二元问题原则（核心要点） - -评估应该使用二元的是/否、真/假问题，尽量避免多值评分。 - -原因： 复合概率导致变异性放大 - -` -二元评分：只有 Pass/Fail → 变异性可控 -多值评分（如 1-7 分）→ 每个环节的变异会累积放大 - ↓ -想象一个漏斗：开始很窄，变异累积后可能差很多 -最终结果可能从 39/40 变成 2/40 -` - -多值评分的风险示例： -如果给模型太多评估点 -模型可能学会"复述每个评估点"来通过测试 -就像不理解材料但能考 100 分的学生 - -不要过于具体/狭窄 - -反面示例（过于严格）： -` -"确保输出在 X 字以内" -"确保包含关系符号" -"确保不包含某些字符" -` - -这会导致模型过度优化评估指标而不是真正提升质量。 - - -实战演示流程 - -演示案例：图表生成器技能优化 - -步骤一：设置 Claude Code 环境 - -在 VSCode 或任意编辑器中安装 Claude Code 扩展，设置好开发环境。 - -步骤二：获取 AutoResearch 仓库 - -`bash -将仓库链接提供给智能体 -"Read this: https://github.com/karpathy/auto-research" -` - -步骤三：创建评估标准 - -将评估标准定义为4 个二元问题： - -| # | 评估标准 | 具体要求 | -|---|----------|----------| -| 1 | 文字清晰度 | 所有文字是否清晰且语法正确 | -| 2 | 配色方案 | 是否符合粉彩色、柔和色调（避免霓虹色） | -| 3 | 布局条理 | 是否从左到右/从上到下有条理（无乱糟糟的气泡和装饰） | -| 4 | 无数字编号 | 是否没有 "1, 2, 3, 4" 这样的编号 | - -步骤四：提供高级指令给智能体 - -使用自然语言描述任务： - -` -"我想让你用 AutoResearch 库来改进图表生成器技能。 - - 该技能的功能是生成约 200 字的脚本。 - - 请用上面的仓库中的自动研究方法帮我建立一套改进系统。 - - 每次测试请生成 10 个图表。 - - 我希望你按回车继续。" -` - -步骤五：明确评分机制 - -` -生成 10 张图片 -每个图片用 4 个标准评估 -最高分 = 40 分（10 × 4） - -流程： -生成 10 张图 -用 4 个标准评估所有 10 张 -计算 40 分中的得分 -修改提示词 -再试一次 -选择表现更好的版本 -` - - -演示结果 - -网站优化案例 - -| 指标 | 优化前 | 优化后 | 改进 | -|------|--------|--------|------| -| 加载时间 | 1100ms | 67ms | 81.3% | - -图表生成器技能案例 - -| 指标 | 第一次测试 | 后续迭代 | -|------|------------|----------| -| 评估分数 | 32/40 | 37/40 | -| 迭代趋势 | 基准 | 持续提升 | - -视频效果： 智能体不断让提示词越来越符合预设的粉彩色、可爱图标等规格。 - - -最佳实践与注意事项 - -✅ 推荐做法 - -使用二元问题评估 - - 是/否、真/假 - - 避免 1-10 分等多值评分 - -保持评估标准简洁 - - 每个技能 3-5 个核心标准 - - 太多标准会导致"假通过" - -让评估自动化 - - 编写测试套件 - - 设置定时循环运行 - -记录所有变更 - - 模型尝试的所有改动清单 - - 可传承给未来的更强模型（GPT-6、Claude 4.0 等） - -❌ 避免做法 - -不要过于具体 - ` - ✗ "确保输出在 100 字以内" - ✗ "确保包含关系符号" - ` - -不要多值复合评分 - ` - ✗ "X 方面打 1-7 分" - ✓ "X 方面是否达标：是/否" - ` - -不要只运行一次 - - 必须多次运行取统计结果 - - 用众数、中位数判断质量 - - -可应用场景扩展 - -AutoResearch 不仅限于 Skills 优化，可应用领域： - -| 领域 | 优化目标 | -|------|----------| -| 网站 | 加载速度、SEO | -| 落地页 | 转化率 | -| A/B 测试 | 标题、缩略图 | -| 邮件营销 | 邮件文案、回复率 | -| 代码 | 性能、架构 | -| 提示词 | 任何技能或流程 | - - -资源链接 - -原视频： https://www.youtube.com/watch?v=qKU-e0x2EmE -AutoResearch 仓库： https://github.com/karpathy/auto-research -完整 Claude Code 课程： 见 UP 主频道 - - -总结 - -AutoResearch 提供了一种让 AI 自主优化 AI 的方法论。通过： - -定义客观指标 → 知道要优化什么 -建立测量工具 → 知道如何量化改进 -提供可变量 → 提示词、代码或文案 -多次运行 + 统计评估 → 确保结果可靠 - -即使你不是机器学习专家，也可以利用这个框架显著提升 Claude Code Skills 的可靠性和准确性，实现技能的自我进化。 - -────────────────────────────── -— Milky 视频总结助手 \ No newline at end of file