已阅读
This commit is contained in:
Zane
@@ -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编程`
|
||||
@@ -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 的技术架构与工程实践。视频原版对三层架构有详细展开，读者可根据需要结合原视频深入理解各层级的技术细节。
|
||||
@@ -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）
|
||||
@@ -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 的价值是让后面的线程不从零开始。**
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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 视频总结助手
|
||||
@@ -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
|
||||
@@ -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 视频总结助手
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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 视频总结助手
|
||||
@@ -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 视频总结助手
|
||||
Reference in New Issue
Block a user