同步笔记
This commit is contained in:
Build Bot
0
97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】.md
Normal file
0
97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】.md
Normal file
@@ -1,13 +0,0 @@
|
||||
# Structured Output for Beginners (Part 3)
|
||||
|
||||
**URL:** https://pocketflow.substack.com/p/structured-output-for-beginners-3
|
||||
**Source:** PocketFlow Substack newsletter
|
||||
**Saved:** 2026-05-12
|
||||
|
||||
> ⚠️ 笔记无法直接抓取正文内容（Substack 从当前环境不可访问）
|
||||
|
||||
## 关于该文章
|
||||
|
||||
这是 PocketFlow 的 "Structured Output for Beginners" 系列的第三部分。PocketFlow 是一个轻量级 AI 工作流框架，该系列文章主要讲解如何利用结构化输出（如 JSON Schema、Pydantic 模型等）来约束 LLM 输出格式，实现更可靠的 AI 应用。
|
||||
|
||||
请手动查看原文获取完整内容。
|
||||
1743
InBox/640.svg
Normal file
1743
InBox/640.svg
Normal file
File diff suppressed because it is too large
Load Diff
|
After Width: | Height: | Size: 121 KiB |
@@ -1,215 +0,0 @@
|
||||
# AutoHarness 深度解读
|
||||
|
||||
> 来源：https://zhuanlan.zhihu.com/p/2016839356833341880
|
||||
> 收藏时间：2026-03-25
|
||||
|
||||
## 一句话总结
|
||||
|
||||
用小模型（Gemini-2.5-Flash）自动写一段"规则检查代码"包裹在 LLM 外面，让它不再犯"非法操作"的低级错误，结果小模型+代码 > 大模型裸跑。
|
||||
|
||||
---
|
||||
|
||||
## 这篇论文到底在解决什么问题？
|
||||
|
||||
### LLM 做 Agent 时的尴尬现实
|
||||
|
||||
你可能已经知道，现在很多人在用 LLM 做 agent——让模型去完成一些需要"行动"的任务，而不是简单地回答问题。比如让 LLM 下棋、玩游戏、操控机器人等。
|
||||
|
||||
**问题来了：LLM 经常做出"非法操作"。**
|
||||
|
||||
论文举了一个非常生动的例子：在 Kaggle GameArena 的国际象棋比赛中，Gemini-2.5-Flash 78% 的失败不是因为下棋策略差，而是因为走了不符合规则的棋。比如让马走直线、让兵倒着走之类的。
|
||||
|
||||
这就好比你请了一个非常聪明的人来帮你下棋，他对棋局分析得头头是道，但就是经常把棋子摆到不合法的位置上。
|
||||
|
||||
### 为什么会这样？
|
||||
|
||||
LLM 本质上是一个文本生成模型。它"知道"国际象棋的规则（因为训练数据里有大量棋谱），但它没有一个硬编码的规则引擎来确保输出的每一步都合法。它的"知道"是概率性的、模糊的，不是精确的。
|
||||
|
||||
### 现有解决方案及其问题
|
||||
|
||||
| 方案 | 怎么做 | 问题 |
|
||||
|------|--------|------|
|
||||
| Fine-tuning | 用大量合法游戏轨迹去微调模型 | 成本极高；可能降低模型在其他任务上的能力 |
|
||||
| 手写 Harness | 人工为每个游戏写一个规则检查器 | 费时费力，每换一个游戏就要重写 |
|
||||
|
||||
**这篇论文的创新点是：让 LLM 自己写这个规则检查器。**
|
||||
|
||||
---
|
||||
|
||||
## 核心概念：什么是 "Harness"？
|
||||
|
||||
### Harness 的直觉理解
|
||||
|
||||
"Harness" 这个词在英文里是"挽具/马具"的意思，用来控制和约束马的行为方向。在这篇论文里，Harness 就是包裹在 LLM 外面的一层"安全壳"，确保 LLM 输出的动作是合法的。
|
||||
|
||||
用工程的话说，这就是一个 wrapper / middleware / interceptor：
|
||||
|
||||
```
|
||||
传统做法：
|
||||
用户请求 → LLM → 输出动作（可能非法）→ 环境报错
|
||||
|
||||
加了 Harness 之后：
|
||||
用户请求 → LLM → Harness检查 → 合法? → 执行
|
||||
↓ 不合法
|
||||
告诉LLM"这步不行" → LLM重新生成 → 再检查...
|
||||
```
|
||||
|
||||
### 三种 Harness 变体
|
||||
|
||||
论文提出了三种不同"约束力度"的 harness：
|
||||
|
||||
#### ① Harness-as-Action-Verifier（动作验证器）— 论文主要聚焦的方案
|
||||
|
||||
```python
|
||||
while True:
|
||||
action = LLM.generate(observation) # LLM 提出一个动作
|
||||
if code_harness.is_legal_action(obs, action): # 代码检查是否合法
|
||||
break # 合法就执行
|
||||
else:
|
||||
# 不合法，告诉 LLM 这步不行，让它重新想
|
||||
observation += f"\n警告：{action} 是非法操作，请重新选择"
|
||||
return action
|
||||
```
|
||||
|
||||
类比：就像你写代码时 IDE 的实时语法检查——你写了不合法的代码，红线提示你改。
|
||||
|
||||
#### ② Harness-as-Action-Filter（动作过滤器）
|
||||
|
||||
```python
|
||||
legal_actions = code_harness.propose_action(obs) # 代码先列出所有合法动作
|
||||
best_action = LLM.rank(legal_actions) # LLM 从中选最好的
|
||||
return best_action
|
||||
```
|
||||
|
||||
类比：就像下拉菜单——用户只能从合法选项中选，不可能输入非法值。
|
||||
|
||||
#### ③ Harness-as-Policy（代码即策略）— 最激进的方案
|
||||
|
||||
```python
|
||||
action = code_harness.propose_action(obs) # 完全由代码决定动作
|
||||
return action # 根本不需要 LLM
|
||||
```
|
||||
|
||||
类比：你直接写了一个规则引擎/算法来玩游戏，LLM 只在"开发阶段"用来写这个算法。运行时零 LLM 调用，零成本。
|
||||
|
||||
---
|
||||
|
||||
## 核心方法：怎么让 LLM 自动写出 Harness？
|
||||
|
||||
这是论文最核心的技术贡献。如果你熟悉 GRPO，你可以把这个过程理解为：用环境反馈来优化代码，而不是优化模型权重。
|
||||
|
||||
### 整体流程
|
||||
|
||||
```
|
||||
1. 初始化：LLM 写一版 harness 代码（propose_action + is_legal_action）
|
||||
2. 测试：用这个代码在游戏环境里跑 rollout
|
||||
3. 评估：记录哪些动作被判为非法，收集错误信息
|
||||
4. 反馈：把错误信息喂给 LLM（Critic 模块整理错误）
|
||||
5. 优化：LLM 基于错误反馈生成改进版代码（Refiner 模块）
|
||||
6. 重复 2-5，直到合法率达到 100% 或超时
|
||||
```
|
||||
|
||||
### 和 GRPO 的对比
|
||||
|
||||
| 维度 | GRPO | AutoHarness |
|
||||
|------|------|-------------|
|
||||
| 优化的对象 | 模型权重 θ | 代码文本（程序） |
|
||||
| 搜索空间 | 参数空间（连续） | 程序空间（离散） |
|
||||
| 反馈信号 | reward（标量） | 执行反馈（错误日志+reward） |
|
||||
| 优化方法 | 梯度下降 | LLM 当"突变算子"改代码 |
|
||||
| 探索策略 | 采样多个 response 对比 | Thompson sampling 做 tree search |
|
||||
| 类比 | 调参让模型更好 | 让 AI 写更好的代码 |
|
||||
|
||||
**关键区别**：GRPO 改的是模型内部的权重，AutoHarness 改的是模型外部的代码。一个改"大脑"，一个改"工具"。
|
||||
|
||||
### Tree Search + Thompson Sampling
|
||||
|
||||
#### 为什么要用 Tree Search？
|
||||
|
||||
简单的迭代优化（写代码 → 测试 → 改代码 → 测试…）有个问题：容易陷入局部最优。比如 LLM 沿着一个思路改了 5 版代码，发现这个方向走不通了，但已经回不去了。
|
||||
|
||||
Tree search 的思路是：同时维护多个版本的代码，像一棵树一样分叉发展。
|
||||
|
||||
```
|
||||
初始代码 v0
|
||||
/ \
|
||||
v1a v1b ← 两个不同的改进方向
|
||||
/ \ |
|
||||
v2a v2b v2c ← 继续分叉
|
||||
|
|
||||
v3a ← 这个方向成功了！合法率100%
|
||||
```
|
||||
|
||||
#### Thompson Sampling 是什么？
|
||||
|
||||
你面对这棵树上的多个节点，每次迭代应该选哪个节点来继续优化？这就是经典的 exploration-exploitation（探索-利用）问题：
|
||||
|
||||
- **利用（Exploitation）**：选当前表现最好的代码版本继续改进
|
||||
- **探索（Exploration）**：试试那些还没被充分优化的代码版本，也许潜力更大
|
||||
|
||||
Thompson sampling 是一种概率性的选择策略：
|
||||
|
||||
```
|
||||
对每个节点：
|
||||
1. 根据它历史的"合法率"数据，建一个概率分布（Beta 分布）
|
||||
2. 从这个分布中随机采样一个值
|
||||
3. 选采样值最高的节点来优化
|
||||
|
||||
效果：表现好的节点被选中的概率更高（利用），
|
||||
但表现差的节点也有机会被选中（探索）
|
||||
```
|
||||
|
||||
工程类比：这和你做 A/B testing 时的 Multi-Armed Bandit 问题几乎一模一样。Thompson sampling 就是一种 bandit 算法。
|
||||
|
||||
### Critic 和 Refiner 的分工
|
||||
|
||||
**Critic（批评者）**：
|
||||
- 输入：rollout 中失败的步骤（最多 5 个）
|
||||
- 工作：整理和归纳各种错误类型
|
||||
- 输出：结构化的错误摘要
|
||||
- 类比：Code Review 时给你提 bug 的同事
|
||||
|
||||
**Refiner（优化者）**：
|
||||
- 输入：当前代码 + Critic 的错误摘要
|
||||
- 工作：基于反馈生成改进版代码
|
||||
- 输出：新版本的 harness 代码
|
||||
- 类比：你根据 code review 意见改代码
|
||||
|
||||
一个关键细节：如果 `is_legal_action()` 返回 True 但环境说动作非法（漏判），则两个函数都要改；如果 `is_legal_action()` 返回 False 且动作确实非法（检查器工作正常，只是 `propose_action` 提出了错误动作），则只改 `propose_action()`。这个区分很重要，避免了"改了不该改的代码"。
|
||||
|
||||
---
|
||||
|
||||
## 实验结果解读
|
||||
|
||||
### 训练效率：多快能学会？
|
||||
|
||||
- 平均 **14.5 次迭代**就能学会（即 LLM 改代码 14.5 次）
|
||||
- **19/32 个游戏**不到 10 次就搞定了
|
||||
- 最难学的游戏：GermanWhist（43次）、Chess（64次）、Othello（62次）
|
||||
|
||||
直觉理解：简单游戏（如猜数字、骰子）规则简单，几次就能写对检查器；复杂游戏（如国际象棋）规则多样（王车易位、吃过路兵等），需要更多轮迭代。
|
||||
|
||||
最终结果：**全部 145 个游戏都达到了 100% 合法动作率。**
|
||||
|
||||
### 双人游戏：小模型+Harness vs 大模型
|
||||
|
||||
| 对阵 | 我们的方法胜率 | 对手胜率 |
|
||||
|------|--------------|----------|
|
||||
| Flash+Harness vs Gemini-2.5-Pro | **56.3%** | 38.2% |
|
||||
| Flash+Harness vs Flash（原始） | **64.8%** | — |
|
||||
|
||||
这意味着什么？**一个小模型（Flash）配上自动生成的规则检查代码，可以打败一个大几倍的模型（Pro）。**
|
||||
|
||||
---
|
||||
|
||||
## 核心启示
|
||||
|
||||
1. **"代码即策略"可能是 LLM Agent 的终局形态** — 让 LLM 写代码，然后运行时零 LLM 调用
|
||||
2. **小模型+好代码 > 大模型裸跑** — 这打破了"模型越大越好"的迷信
|
||||
3. **Program Synthesis + RL 的结合** — 这可能是下一代 AI 系统的核心范式
|
||||
|
||||
---
|
||||
|
||||
## 标签
|
||||
|
||||
#论文解读 #AutoHarness #LLM #Agent #ProgramSynthesis #GRPO #强化学习
|
||||
@@ -1,91 +0,0 @@
|
||||
# CLI-Switch：Agent 调用 Claude Code / Codex 的正确姿势
|
||||
|
||||
**来源：** [微信公众号 - WilleAi笔记](https://mp.weixin.qq.com/s/_lFBObJClMx74DuJVegAaw)
|
||||
**作者：** 上心12138
|
||||
**日期：** 2026年5月13日 02:05
|
||||
**标签：** #cli-switch #ClaudeCode #Codex #Agent #AI #开发工具
|
||||
|
||||
---
|
||||
|
||||
## 从工具箱到手术刀
|
||||
|
||||
三个月前作者发过一篇文章介绍 cli-switch，定位是"Agent 的 CLI 工具箱"——支持多个编码 Agent，能调很多模型。跑了一段时间后发现：做得太多，反而没有一个做得够好。
|
||||
|
||||
Claude Code 和 Codex 在编码场景的领先优势越来越明显，其他工具逐渐边缘化。所以整个项目重构了。
|
||||
|
||||
**v1.0.0** 换成了 TypeScript / Node.js，npm 安装，聚焦只做一件事：
|
||||
> **让 Agent 正确调用 Claude Code 和 Codex，并知道选对应的什么模型。**
|
||||
|
||||
### 重构带来的关键变化
|
||||
|
||||
- **更干净**：砍掉了不必要的 Agent 支持，专注 Claude Code + Codex
|
||||
- **环境隔离**：每次调用起独立子进程，不碰全局配置
|
||||
- **策略引擎**：4 种执行策略——single（单步）、write_review（写完审查）、write_test_fix（写完跑测试、不过就修）、high_quality（全程 premium 模型）
|
||||
- **Skill 系统**：给 Agent 操作手册，自动识别 8 种能力（写代码、代码审查、重构、修 bug、分析、写测试、跑测试、解释代码）
|
||||
|
||||
---
|
||||
|
||||
## 两个人的电脑（核心痛点）
|
||||
|
||||
Claude Code 只有一份全局配置。Agent 没法单独指定模型，只能用全局配的那个。就像两个人共用一台电脑，谁改了设置另一个都受影响。
|
||||
|
||||
Codex 也一样。每次调 Codex 要手动设 `OPENAI_API_KEY` 和 `OPENAI_BASE_URL`，用完还得改回来。
|
||||
|
||||
---
|
||||
|
||||
## 一行安装，一个 Key 搞定
|
||||
|
||||
```bash
|
||||
npm install -g cli-switch
|
||||
```
|
||||
|
||||
配一个环境变量：
|
||||
|
||||
```bash
|
||||
export SWITCH_API_KEY=your-gateway-key
|
||||
export SWITCH_BASE_URL=https://your-relay.example.com/v1
|
||||
```
|
||||
|
||||
Agent 调 Claude Code 时自动注入为 `ANTHROPIC_API_KEY`，调 Codex 时注入为 `OPENAI_API_KEY`。**不碰全局配置**，通过子进程临时环境变量注入，用完即焚。
|
||||
|
||||
---
|
||||
|
||||
## 使用示例
|
||||
|
||||
**调 Claude Code：**
|
||||
```bash
|
||||
cli-switch run "给 src/auth.ts 补单元测试" --agent claude-code
|
||||
```
|
||||
|
||||
**调 Codex：**
|
||||
```bash
|
||||
cli-switch run "重构 utils 模块" --agent codex
|
||||
```
|
||||
|
||||
**写完自动跑测试，不过就修（最多循环 5 次）：**
|
||||
```bash
|
||||
cli-switch run "实现登录功能" --strategy write_test_fix
|
||||
```
|
||||
|
||||
**路由预览，不花 Token：**
|
||||
```bash
|
||||
cli-switch run "重构 auth 模块" --dry-run
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 对比表
|
||||
|
||||
| | 之前 | 之后 |
|
||||
|---|---|---|
|
||||
| 调 Claude Code | 手动设环境变量，担心改全局配置 | 一条命令，自动注入 |
|
||||
| 调 Codex | 又得手动设一套 OpenAI 的变量 | 同一条命令，换 `--agent codex` |
|
||||
| Key 管理 | 中转站 Key 要手动塞给每个工具 | 配一次，两个工具都能用 |
|
||||
| 模型切换 | 改全局配置，影响自己正在用的 | Agent 用自己的，互不影响 |
|
||||
| 执行隔离 | 直接在项目里改，改坏了就麻烦 | worktree 或临时副本，随便折腾 |
|
||||
|
||||
---
|
||||
|
||||
## 与 Hermes Agent 的关联
|
||||
|
||||
这个工具直接解决了 Hermes Agent（以及类似 AI Agent）在调用 Claude Code / Codex 时的**环境变量冲突**和**配置隔离**问题。Hermes 的 `delegate_task` 工具配合 `acp_command` 参数可以调用 Claude Code 和 Codex，而 cli-switch 进一步简化了 Key 注入和模型选择。
|
||||
@@ -1,29 +0,0 @@
|
||||
# CLIProxyAPI
|
||||
|
||||
**GitHub**: https://github.com/router-for-me/CLIProxyAPI
|
||||
**添加时间**: 2026-03-24
|
||||
**提醒时间**: 2026-03-25 10:00
|
||||
**标签**: #代理 #CLI #工具
|
||||
|
||||
---
|
||||
|
||||
## 项目简介
|
||||
|
||||
(待补充 - 明天落实时填写)
|
||||
|
||||
## 主要功能
|
||||
|
||||
(待补充)
|
||||
|
||||
## 安装使用
|
||||
|
||||
(待补充)
|
||||
|
||||
## 备注
|
||||
|
||||
- 用户要求：无风险的情况下落实
|
||||
- 提醒已设置：明天（3月25日）10:00
|
||||
|
||||
---
|
||||
|
||||
**原始链接**: https://github.com/router-for-me/CLIProxyAPI
|
||||
@@ -1,53 +0,0 @@
|
||||
# Claude Code 2.1.141 重磅发布！61项更新，细节体验再次升级
|
||||
|
||||
> 来源：[微信公众平台](https://mp.weixin.qq.com/s/73PuGdfvSt7j2l-tTigd_g)
|
||||
> 作者：晓明兄
|
||||
> 日期：2026年5月15日 08:04
|
||||
|
||||
## 本次更新三大亮点
|
||||
|
||||
### 1. Hook 通知能力大幅提升（最实用！）
|
||||
- 新增 `terminalSequence` 字段到 Hook JSON 输出
|
||||
- 即使没有控制终端（non-TTY），Hook 也能直接发出：
|
||||
- 桌面通知
|
||||
- 窗口标题变更
|
||||
- 终端铃声
|
||||
- 长任务跑完、重要事件发生时，Claude 终于能"主动叫你"
|
||||
- 社区用户直呼这是 "sleeper hit"（潜伏杀手级改动），让 Agent 感觉更像真实同事
|
||||
|
||||
### 2. Rewind 菜单新增 "Summarize up to here"
|
||||
- 长会话上下文爆炸时，不用手动重启丢失历史
|
||||
- 选中位置后一键压缩早期上下文，保留最近对话
|
||||
- 完美解决 token 限制痛点，同时不丢失"为什么之前方案失败"的重要信息
|
||||
|
||||
### 3. Agent View 与后台任务更稳定
|
||||
- `claude agents --cwd <path>`：支持按目录过滤会话列表
|
||||
- 后台 Agent 完成工作但仍有 shell 时，自动移到 Completed 状态
|
||||
- 空闲后台会话 5 分钟后自动清理
|
||||
- 权限模式、模型切换等并发问题得到大量修复
|
||||
|
||||
## 其他重要新增与改进
|
||||
|
||||
**新增功能：**
|
||||
- `CLAUDE_CODE_PLUGIN_PREFER_HTTPS`：无 SSH Key 环境也能轻松安装 GitHub Plugin
|
||||
- `ANTHROPIC_WORKSPACE_ID`：支持 Workload Identity Federation，精确作用域
|
||||
- `CLAUDE_CODE_VOICE_FORWARD_INTERIMS_TYPED` 等语音相关环境变量
|
||||
|
||||
**体验与修复亮点：**
|
||||
- 长思考 Spinner 10 秒后变 amber 色，提醒你 Claude 还在努力
|
||||
- 大量 Windows、插件、MCP、权限对话框、markdown 表格等修复
|
||||
- Auto Mode 权限提示更清晰，说明是由哪个 rule 触发
|
||||
- Prompt tokens 优化：tools 占比从 43.5% 提升至 47.3%
|
||||
|
||||
## 开发者真实声音
|
||||
- "一个小改动，却让长跑 Agent 真正能‘喊’人。"
|
||||
- "Rewind 压缩功能直接解决上下文爆炸问题，不用再手动重启丢失历史。"
|
||||
|
||||
结合之前的 Agent View + /goal，Claude Code 正在成为一套真正可管、可控、可长时间运行的 AI 工程体系。
|
||||
|
||||
## 写在最后
|
||||
Claude Code 的迭代节奏越来越快。从 Agent View 的全局视野，到 /goal 的目标驱动，再到这次的 Hook 通知和上下文压缩，它正在一步步把"把任务扔给 AI"从理想变成稳定可靠的生产力工具。
|
||||
|
||||
---
|
||||
|
||||
#ClaudeCode #AI编程 #开发者工具 #AgenticAI
|
||||
@@ -1,108 +0,0 @@
|
||||
# Cursor 开源团队工作流 Team-kit
|
||||
|
||||
> 来源：[微信公众平台](https://mp.weixin.qq.com/s/YT-yD6LcYJhUm5aTQtCsKQ)
|
||||
> 作者：VibeCoder · Vibe编码
|
||||
> 时间：2026年5月7日 07:56
|
||||
|
||||
---
|
||||
|
||||
Cursor 官方插件仓库发布了 `cursor-team-kit`（v1.1.0），将 Cursor 团队内部的 CI、Code Review、PR、测试、验证、代码清理、周报等工作流打包成可直接安装的插件。
|
||||
|
||||
**安装：** `/add-plugin cursor-team-kit`
|
||||
|
||||
**内容构成：** 17 Skills + 1 Sub Agent + 2 Rules
|
||||
|
||||
特点：不依赖 Linear、Jira、Slack、Notion 等第三方服务，靠 Git、GitHub CLI、本地测试、浏览器自动化、终端 harness 等基础能力工作。
|
||||
|
||||
---
|
||||
|
||||
## 它是什么
|
||||
|
||||
manifest 里写得直白：*Internal workflows used by Cursor developers*。
|
||||
|
||||
官方强调：**plug and play without requiring third-party service integrations**。价值不是把 SaaS 接进 IDE，而是把团队怎么收尾、验证、review 写成 agent 能读懂的操作手册。
|
||||
|
||||
---
|
||||
|
||||
## 技术原理
|
||||
|
||||
目录结构：
|
||||
```
|
||||
cursor-team-kit/
|
||||
├── .cursor-plugin/plugin.json
|
||||
├── agents/ci-watcher.md
|
||||
├── rules/
|
||||
│ ├── no-inline-imports.mdc
|
||||
│ └── typescript-exhaustive-switch.mdc
|
||||
└── skills/
|
||||
├── loop-on-ci/
|
||||
├── verify-this/
|
||||
├── control-cli/
|
||||
├── control-ui/
|
||||
├── pr-review-canvas/
|
||||
└── ...
|
||||
```
|
||||
|
||||
设计哲学：Skills 很多，Sub Agent 很少。只有一个后台 agent `ci-watcher`（盯 PR checks）。其他复杂动作都拆成独立 skill，按需触发更像 checklist。
|
||||
|
||||
---
|
||||
|
||||
## verify-this（最有价值的 skill）
|
||||
|
||||
硬性要求：
|
||||
1. 把用户 claim 改写为**可证伪命题**
|
||||
2. 采集 baseline 和 treatment 两组 artifact
|
||||
3. 相同命令、相同数据、相同环境比较
|
||||
4. 只允许三种结论：**VERIFIED** | **NOT VERIFIED** | **INCONCLUSIVE**
|
||||
|
||||
直击 agent 写代码最大的毛病——太容易凭感觉宣布完成。这个 skill 可迁移到 Claude Code、Codex、OpenCode 等任何本地 coding agent。
|
||||
|
||||
---
|
||||
|
||||
## control-cli & control-ui（执行层）
|
||||
|
||||
- **control-cli**：给交互式 CLI/TUI 搭可重复 harness，用 tmux、PTY、Expect、Node inspector 驱动输入、捕获屏幕、记录 transcript
|
||||
- **control-ui**：面向 Web/IDE/Electron，用 Playwright/CDP 连接真实页面，截图、读 accessibility tree、抓 console/network、做性能和内存分析
|
||||
|
||||
说明 Cursor 内部对 agent 的要求已不止读代码和写代码——代码写完后 agent 要真的去操作它。
|
||||
|
||||
---
|
||||
|
||||
## PR 被当成阅读体验来设计
|
||||
|
||||
PR 生命周期工具：
|
||||
- `new-branch-and-pr`
|
||||
- `review-and-ship`
|
||||
- `make-pr-easy-to-review` — 整理 noisy history、改 PR 描述、补风险说明
|
||||
- `get-pr-comments`
|
||||
- `pr-review-canvas` — 将 diff 渲染为交互式 HTML 走读页面，加伪代码、流程图、review checklist
|
||||
|
||||
AI 让代码产出速度变快后，review 压力上升，审查代码也要做信息设计。
|
||||
|
||||
---
|
||||
|
||||
## 两条 Rules 暴露代码品味
|
||||
|
||||
只有两条 always-on rules：
|
||||
1. **typescript-exhaustive-switch** — TypeScript union/enum switch 做穷尽处理（`never` 兜底）
|
||||
2. **no-inline-imports** — import 放文件顶部
|
||||
|
||||
共同指向：代码要容易被静态分析，也要容易被人扫读。
|
||||
|
||||
---
|
||||
|
||||
## workflow-from-chats（元技能）
|
||||
|
||||
从最近对话里提取团队偏好：触发条件、工作步骤、质量标准、停止条件、证据和置信度。判断该写成 skill、rule、workflow doc 还是不落地。
|
||||
|
||||
解决长期问题：人会不断纠正 agent 的行为习惯，但这些纠正如果不显式沉淀成 artifact，就不会累积为能力。
|
||||
|
||||
---
|
||||
|
||||
## 总结
|
||||
|
||||
- **verify-this** 解决了 agent 自证的问题
|
||||
- **control-cli/ui** 把 agent 从代码生成推进到操作验证
|
||||
- **pr-review-canvas** 承认审查代码需要信息设计
|
||||
- **两条 rules** 是品位种子
|
||||
- **workflow-from-chats** 解决团队知识沉淀
|
||||
@@ -1,72 +0,0 @@
|
||||
# Cursor: 持续改进我们的智能体框架 (Continually Improving Agent Harness)
|
||||
|
||||
> 原文: [cursor.com/cn/blog/continually-improving-agent-harness](https://cursor.com/cn/blog/continually-improving-agent-harness)
|
||||
> 作者: Stefan Heule & Jediah Katz · 2026-04-30
|
||||
|
||||
## 核心思想
|
||||
|
||||
改进智能体框架 = 愿景驱动 → 提出假设 → 实验验证 → 定量/定性信号迭代。大多数改进不是跃迁式突破，而是执着地叠加一个个小优化。
|
||||
|
||||
---
|
||||
|
||||
## 1. 上下文窗口的演进
|
||||
|
||||
- **早期 (2024末):** 模型自行选择上下文能力弱 → 大量护栏：lint/类型错误反馈、改写文件读取请求、限制单轮工具调用数量、预填大量静态上下文（文件夹布局、语义匹配代码片段、用户附件压缩版）
|
||||
- **现在:** 上述做法大多淡出。保留少量实用静态上下文（OS、git 状态、当前/最近查看文件）。转向**动态上下文**——模型在工作过程中按需拉取（过往对话、活跃终端会话、相关工具等）
|
||||
|
||||
## 2. 评估框架变更
|
||||
|
||||
| 方式 | 说明 |
|
||||
|------|------|
|
||||
| **离线评估** | 自有评估套件 + 公开基准 [CursorBench](https://cursorbench.com)；快速、标准化、可跨时间对比 |
|
||||
| **在线 A/B 测试** | 同时部署两个+框架变体，在生产环境真实用户中测试 |
|
||||
|
||||
**质量衡量指标:**
|
||||
- **直接指标:** 延迟、token 效率、工具调用次数、缓存命中率
|
||||
- **保持率 (Keep Rate):** 智能体生成的代码变更在固定时间后仍保留在代码库中的比例
|
||||
- **语义满意度分析:** 用 LLM 读取用户对智能体输出的回应——用户进入下个功能=成功信号，用户粘贴堆栈追踪=失败信号
|
||||
|
||||
➤ 案例: 尝试用更贵模型做上下文摘要，改善微乎其微，不值得成本。
|
||||
|
||||
## 3. 跟踪并修复性能退化
|
||||
|
||||
**工具调用错误分类:**
|
||||
- `InvalidArguments` / `UnexpectedEnvironment` — 模型出错、上下文矛盾
|
||||
- `ProviderError` — 外部工具服务中断（GenerateImage、WebSearch 等）
|
||||
- `UserAborted` / `Timeout` — 用户中止或超时
|
||||
|
||||
**告警策略:**
|
||||
- 未知错误＝缺陷 → 超阈值即告警
|
||||
- 预期错误 → 异常检测告警（每个工具×每个模型分别计算基线），显著偏离基线时触发
|
||||
- 自动化工单: 每周运行一个特化智能体，搜索日志找出新增/激增问题，在 Linear 创建或更新工单
|
||||
|
||||
➤ 成果: 一次集中冲刺将意外工具调用错误降低一个数量级，所有工具可靠性达 99%+（很多 99.9%）。
|
||||
|
||||
## 4. 为不同模型定制框架
|
||||
|
||||
- 所有框架抽象不依赖具体模型，但可深度定制
|
||||
- **工具格式差异:** OpenAI 训练使用 patch 格式编辑文件；Anthropic 习惯字符串替换。用错格式会消耗更多 reasoning token 并产生错误
|
||||
- **提示定制:** OpenAI 遵循指令更字面/精确；Claude 更偏直觉，对不精确指令容忍度高
|
||||
- **Early Access 调优:** 从最接近的现有框架入手 → 离线评估找出易错点 → 团队成员实际使用反馈 → 迭代直到可发布
|
||||
- **"上下文焦虑"（context anxiety）:** 一个模型在上下文窗口渐满时拒绝执行任务，通过调整提示缓解
|
||||
|
||||
## 5. 支持聊天中途切换模型
|
||||
|
||||
- 切换时自动切换到对应模型的框架（不同提示、不同工具接口）
|
||||
- 添加自定义指令告诉模型它是"中途接手"对话
|
||||
- 缓存是 provider/model 特定的，切换导致缓存未命中 → 尝试用对话摘要缓解
|
||||
- 替代方案: 使用**子智能体**（从全新上下文窗口开始），最近支持用户指定模型运行子智能体
|
||||
|
||||
## 6. 框架与软件开发的未来
|
||||
|
||||
- **多智能体模式**是方向: 一个负责规划、一个负责快速编辑、一个负责调试，各司其职
|
||||
- **框架是关键:** 知道调度哪个智能体、如何描述任务、如何整合结果——这些编排能力体现在框架中，而非单个智能体身上
|
||||
|
||||
---
|
||||
|
||||
## 启发
|
||||
|
||||
> 与 Hermes Agent 的开发哲学高度一致——持续关注动态上下文、工具可靠性、评估方法论、以及为不同模型优化框架。
|
||||
---
|
||||
|
||||
原文链接: [https://cursor.com/cn/blog/continually-improving-agent-harness](https://cursor.com/cn/blog/continually-improving-agent-harness)
|
||||
@@ -1,227 +0,0 @@
|
||||
---
|
||||
source: 微信公众号
|
||||
url: https://mp.weixin.qq.com/s/Rao9okjfY7gzsHldjRKdDw
|
||||
title: Hermes Agent 架构分析
|
||||
tags: [hermes-agent, architecture, AI-agent]
|
||||
---
|
||||
|
||||
# Hermes Agent 架构分析
|
||||
|
||||
## 系统全景
|
||||
Hermes Agent 是一个**多平台、可扩展的 AI Agent 框架**，核心组件包括：
|
||||
- **核心 Agent 引擎** — AIAgent 类（run_agent.py）
|
||||
- **工具系统与注册中心** — registry 架构
|
||||
- **网关与多平台适配** — 20+ 平台适配器
|
||||
- **配置与状态管理** — 双轨配置 + SQLite 会话存储
|
||||
- **安全模型** — 多层审批 + 纵深防御
|
||||
|
||||
---
|
||||
|
||||
## 核心 Agent 引擎
|
||||
|
||||
### AIAgent 类设计
|
||||
采用**大类单文件设计**（run_agent.py），所有核心逻辑汇聚于一个文件中。
|
||||
|
||||
**60+ 构造器参数**按语义分区：
|
||||
- 模型配置
|
||||
- 工具控制（enabled/disabled_toolsets）
|
||||
- 行为控制（quiet_mode, save_trajectories）
|
||||
- 上下文标识（platform, session_id）
|
||||
- 回调注入（clarify, approval, sudo, progress callbacks）
|
||||
|
||||
这是一种**配置注入（Configuration Injection）**模式。
|
||||
|
||||
### 双接口设计
|
||||
```python
|
||||
def chat(self, message: str) -> str:
|
||||
"""简单接口 — 返回最终响应字符串"""
|
||||
|
||||
def run_conversation(self, ...) -> dict:
|
||||
"""完整接口 — 返回字典"""
|
||||
```
|
||||
Facade + Full API 双层设计。
|
||||
|
||||
### 核心循环
|
||||
```
|
||||
while api_call_count < max_iterations and budget.remaining > 0:
|
||||
# 1. 预飞检查 — 上下文压缩
|
||||
# 2. API 调用
|
||||
# 3. 工具调用分支（支持并行执行）
|
||||
# 4. 终止条件
|
||||
```
|
||||
|
||||
**关键设计决策：**
|
||||
| 权衡 | 选择 | 理由 |
|
||||
|------|------|------|
|
||||
| 同步 vs 异步 | 同步循环 | 可预测性、调试简单 |
|
||||
| 迭代控制 | 双重限制 | 线程安全预算管理 |
|
||||
| 上下文压缩 | 触发式 | 仅在 token 上限时启动 |
|
||||
|
||||
### IterationBudget — 线程安全预算管理
|
||||
使用 threading.Lock 实现，解决子代理委派场景下的预算共享问题。
|
||||
|
||||
### 上下文压缩（5 阶段管线）
|
||||
1. **工具输出裁剪** — 截断超长返回值
|
||||
2. **头部保护** — 锁定系统提示 + 前 N 轮
|
||||
3. **Token 预算尾部定位** — 从尾部向前累积
|
||||
4. **结构化摘要** — LLM 摘要被截断的中间部分
|
||||
5. **工具对消毒** — 确保 tool_use/tool_result 成对出现
|
||||
|
||||
**防抖机制**：检测连续多次压缩则触发紧急降级。
|
||||
|
||||
### Prompt 缓存策略
|
||||
Anthropic system_and_3 策略：系统提示 + 最后 3 条消息设置 cache_control 断点。
|
||||
|
||||
### 多 API 模式适配
|
||||
支持 4 种 LLM API 协议：OpenAI、Anthropic、Google、OpenRouter，内部统一格式后在 API 调用前动态转换。
|
||||
|
||||
---
|
||||
|
||||
## 工具系统与注册中心
|
||||
|
||||
### Registry 架构（tools/registry.py）
|
||||
```python
|
||||
class ToolEntry:
|
||||
__slots__ = ('name', 'toolset', 'schema', 'handler', 'check_fn',
|
||||
'requires_env', 'platform_filter', 'is_mcp')
|
||||
```
|
||||
|
||||
**设计亮点：**
|
||||
- **AST 自动发现** — 扫描 tools/ 目录的 registry.register() 调用，无需手动维护导入列表
|
||||
- **MCP 影子保护** — MCP 工具同名时优先内置版本
|
||||
- **__slots__ 优化** — 减少内存开销
|
||||
|
||||
### 工具分层（6 层）
|
||||
从底层执行环境到顶层 Agent 循环，每一层单向依赖。
|
||||
|
||||
### 工具集定义
|
||||
_HERMES_CORE_TOOLS 列表，用户通过 enabled/disabled_toolsets 精确控制。
|
||||
|
||||
### 工具调用生命周期（8 步流程）
|
||||
LLM → tool_calls → model_tools.handle_function_call() → registry.dispatch() → 审批检查 → handler → JSON result → tool_result message
|
||||
|
||||
---
|
||||
|
||||
## 网关与多平台适配
|
||||
|
||||
### Gateway 架构
|
||||
异步事件循环，20+ 平台适配器并发运行，统一路由到 AIAgent。
|
||||
|
||||
### 平台适配器模式（Template Method + Strategy）
|
||||
```python
|
||||
class BasePlatformAdapter(ABC):
|
||||
# 4 个必须实现的抽象方法
|
||||
async def send_text(self, chat_id, text): ...
|
||||
async def send_typing(self, chat_id): ...
|
||||
async def get_display_name(self, user_id): ...
|
||||
async def start(self): ...
|
||||
# 10+ 可选覆盖方法
|
||||
```
|
||||
|
||||
支持 20+ 适配器：Telegram、Discord、Slack、WhatsApp、QQ、Signal、HomeAssistant、WeChat（元宝）等。
|
||||
|
||||
### 会话管理
|
||||
- 双写持久化：SQLite（主）+ JSONL（向后兼容）
|
||||
- 重置策略：idle（空闲超时）/ daily（每日定时）
|
||||
|
||||
### Agent 缓存（LRU）
|
||||
最大 128 个 Agent 实例的资源感知缓存。
|
||||
|
||||
---
|
||||
|
||||
## 数据流转
|
||||
|
||||
### 主流程（键盘 → 屏幕）
|
||||
CLI 入口 → Agent 循环 → LLM API → 工具执行 → 流式渲染 → 会话持久化
|
||||
|
||||
### 工具调用流细节
|
||||
- **Agent 级拦截**：todo_tool、memory_tool 直接处理不进 registry
|
||||
- **审批流程**：环境豁免 → YOLO 模式 → LLM 智能评估 → 人工审批
|
||||
|
||||
---
|
||||
|
||||
## 配置与状态管理
|
||||
|
||||
### 双轨配置系统
|
||||
```
|
||||
~/.hermes/
|
||||
├── config.yaml # 结构化配置 (YAML)
|
||||
├── .env # 环境变量 (API keys)
|
||||
├── skins/ # 自定义皮肤
|
||||
├── skills/ # 已安装技能
|
||||
└── sessions/ # 会话数据 (SQLite + FTS5)
|
||||
```
|
||||
|
||||
### 三套配置加载器
|
||||
- load_cli_config() — CLI 交互模式
|
||||
- load_config() — 子命令
|
||||
- 直接 YAML 加载 — Gateway
|
||||
|
||||
### SessionDB
|
||||
SQLite + FTS5 全文搜索，WAL 模式读写并发，自动迁移，Jitter 写重试。
|
||||
|
||||
---
|
||||
|
||||
## 安全模型
|
||||
|
||||
### 多层审批体系
|
||||
1. 环境检测豁免 → 2. YOLO 模式 → 3. LLM 智能评估 → 4. 人工审批回调
|
||||
|
||||
### 危险模式检测（30+ 模式）
|
||||
```python
|
||||
DANGEROUS_PATTERNS = [
|
||||
r"rm\s+(-[rf]+\s+)?/", # 文件系统破坏
|
||||
r"curl.*\|\s*(bash|sh)", # 网络风险
|
||||
r"sudo\s+", # 权限提升
|
||||
# ...
|
||||
]
|
||||
```
|
||||
Unicode 规范化防绕过（NFKC + 零宽字符移除）。
|
||||
|
||||
### 凭证保护
|
||||
- 环境变量黑名单（工具执行时自动过滤）
|
||||
- 敏感路径保护（~/.ssh/, ~/.gnupg/ 等）
|
||||
|
||||
### SSRF 防护
|
||||
在平台适配器基类中验证 URL，阻止内网/回环地址访问。
|
||||
|
||||
### 安全设计哲学
|
||||
纵深防御（Defense in Depth）：最小特权、分层检查、反绕过、环境隔离、凭证隔离。
|
||||
|
||||
---
|
||||
|
||||
## 可扩展性体系
|
||||
|
||||
### 工具扩展（最核心的扩展机制）
|
||||
添加新工具仅需 2 个文件 + AST 自动发现。零配置。
|
||||
|
||||
### 技能系统（Skills）
|
||||
纯文本能力增强（~/.hermes/skills/），通过自然语言描述注入系统提示。
|
||||
|
||||
### MCP 生态
|
||||
Hermes 同时作为 MCP Server 和 MCP Client。
|
||||
|
||||
### 皮肤系统
|
||||
纯数据扩展（YAML），运行时通过 /skin 命令即时切换。
|
||||
|
||||
---
|
||||
|
||||
## 设计哲学
|
||||
|
||||
### 核心原则
|
||||
- **实用主义胜于教条主义** — 大文件不如过度拆分
|
||||
- **回调注入实现界面无关** — 4 个入口共享同一个 AIAgent
|
||||
- **分层而非分片** — 6 层清晰分层
|
||||
- **安全作为一等公民** — 深度嵌入架构
|
||||
- **约定优于配置** — 自动发现、自动加载、自动集成
|
||||
|
||||
### 主要权衡
|
||||
| 权衡 | 选择 | 收益 |
|
||||
|------|------|------|
|
||||
| 大文件 vs 小模块 | 大文件 | 核心逻辑内聚 |
|
||||
| 同步 vs 异步 | 同步 | 可预测性 |
|
||||
| 单进程 vs 微服务 | 单进程 | 部署简单 |
|
||||
| AST 发现 vs 显式注册 | 动态发现 | 零配置 |
|
||||
|
||||
### 一句话总结
|
||||
> Hermes 是一个以实用主义为导向、以可扩展性为骨架、以安全性为底线的工业级 AI Agent 框架。
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
title: Hermes 编排 Agent + Web 可观测性方案
|
||||
date: 2026-04-29
|
||||
tags: [Hermes, Agent编排, ttyd, tmux, 可观测性]
|
||||
---
|
||||
|
||||
# Hermes 编排 Agent + Web 可观测性方案
|
||||
|
||||
## 背景
|
||||
|
||||
Hermes 作为母 Agent 编排不同的子 Agent（Codex、Claude Code 等），但全部在后台运行，无法直观看到每个 Agent 的实时输出和进度。需要将后台 tmux session 暴露到 Web 前端观察。
|
||||
|
||||
## 方案：ttyd + tmux
|
||||
|
||||
**ttyd**（GitHub 31k+ stars）可以把任意终端程序变成 Web 页面，通过 WebSocket 实时推流。
|
||||
|
||||
### 架构
|
||||
|
||||
```
|
||||
Hermes (编排大脑)
|
||||
│
|
||||
├─ tmux session codex1 ─── ttyd :8080 ──► http://localhost:8080
|
||||
├─ tmux session claude1 ─── ttyd :8081 ──► http://localhost:8081
|
||||
└─ tmux session codex2 ─── ttyd :8082 ──► http://localhost:8082
|
||||
```
|
||||
|
||||
### 使用方式
|
||||
|
||||
```bash
|
||||
# 启动 Agent 的 tmux session
|
||||
tmux new-session -d -s codex1 -x 140 -y 40
|
||||
tmux new-session -d -s claude1 -x 140 -y 40
|
||||
|
||||
# ttyd 暴露每个 session 到 web
|
||||
ttyd -p 8080 tmux attach -t codex1 &
|
||||
ttyd -p 8081 tmux attach -t claude1 &
|
||||
|
||||
# 浏览器打开
|
||||
open http://localhost:8080 # 看 Codex
|
||||
open http://localhost:8081 # 看 Claude Code
|
||||
```
|
||||
|
||||
### 类似方案
|
||||
- **Wetty / Gotty** — 与 ttyd 类似
|
||||
- **LangFuse / AgentOps** — 专业 Agent trace 平台，但偏事后日志分析，非实时终端画面
|
||||
|
||||
### 文件握手通信
|
||||
|
||||
Agent 之间通过文件交换上下文：
|
||||
|
||||
```
|
||||
/tmp/handoff.json # Codex 输出 → Claude Code 读取
|
||||
/tmp/instruction.md # Claude Code 重注入指令 → 拉起新 Codex
|
||||
/tmp/next_prompt.txt # 下一步指令
|
||||
```
|
||||
|
||||
## 关键结论
|
||||
|
||||
1. **不要** 让 Agent 之间直接互相调用（失控）
|
||||
2. **要** 用 Hermes 作为中央编排大脑
|
||||
3. **用文件作为 Agent 间通信协议**
|
||||
4. **ttyd 解决实时观察问题**，浏览器多标签同时查看所有 Agent
|
||||
|
||||
---
|
||||
|
||||
*来源：Hermes Agent 对话 (2026-04-29)*
|
||||
@@ -1,84 +0,0 @@
|
||||
# OpenSpec + Superpowers workflow orchestrator（OpenFlow）：连接需求与工程的工作流编排器
|
||||
|
||||
**来源：** [微信公众号 - 幽人](https://mp.weixin.qq.com/s/8PT7nlj-Jcu8Xa6lwyApYQ)
|
||||
**作者：** 幽人
|
||||
**日期：** 2026年5月15日 11:12
|
||||
**标签：** #OpenFlow #OpenSpec #Superpowers #工作流编排 #AI编码
|
||||
|
||||
---
|
||||
|
||||
## 核心定位
|
||||
|
||||
> OpenSpec + Superpowers workflow orchestrator — bridging requirements specs and engineering execution, eliminating the format gap.
|
||||
|
||||
**OpenFlow 是连接需求规格与工程执行的工作流编排器**，消除两者之间的格式鸿沟。它是一个 npm 全局包（`@lininn/openflow`），纯粹作为一个独立的**编排层**，不嵌入 OpenSpec 或 Superpowers 的代码。
|
||||
|
||||
GitHub: [lininn/openflow](https://github.com/lininn/openflow)
|
||||
|
||||
### 解决的问题
|
||||
- **需求模糊**：用户说"做一个贪吃蛇游戏"，AI 需要自行猜测技术栈、复杂度、边界条件
|
||||
- **规格缺失**：没有结构化的设计文档，代码写到一半发现需求变了
|
||||
- **进度不明**：做到哪里了？哪些功能已完成？哪些待验证？
|
||||
- **验收困难**：如何确认代码实现了设计？设计变更是否同步到代码？
|
||||
|
||||
---
|
||||
|
||||
## 核心架构
|
||||
|
||||
- **技术栈**：TypeScript（98.6%），npm 全局包
|
||||
- **核心依赖**：OpenSpec（结构化规格生成）+ Superpowers（实现规划与执行）
|
||||
- **目录结构**：CLI 优先 + 模板驱动 + 平台兼容（.claude/ 技能 + .omc/ 会话存储）
|
||||
|
||||
### 双层依赖检测机制
|
||||
**优雅降级策略** — 不强制依赖 OpenSpec 或 Superpowers：
|
||||
- Init 时检测：检测缺失 → 引导安装，但技能文件仍然生成
|
||||
- 运行时检测：Build 阶段发现缺失时自动降级为手动步骤执行
|
||||
|
||||
核心理念：**让工具先能用，再逐步完善。**
|
||||
|
||||
---
|
||||
|
||||
## 五阶段工作流
|
||||
|
||||
| 命令 | 阶段 | 描述 |
|
||||
|------|------|------|
|
||||
| `/openflow proposal` | proposal | 轻量需求捕获 — 3-5 个问题快速收敛需求 |
|
||||
| `/openflow brainstorming` | brainstorming | 深度设计 — 多轮权衡探索 |
|
||||
| `/openflow spec` | spec | 生成规格 + 自动翻译为 plan-ready.md |
|
||||
| `/openflow build` | build | 执行实现（调用 Superpowers） |
|
||||
| `/openflow close` | close | 验证一致性 + 归档 |
|
||||
|
||||
### Proposal 阶段：需求的起点
|
||||
用最少的提问（3-5 个），把用户脑子里的需求变成可执行的变更描述：
|
||||
1. **做什么** — 想实现什么功能/变更？
|
||||
2. **为什么** — 解决什么问题？给谁用的？
|
||||
3. **成功标准** — 怎样算做完了？验收条件？
|
||||
4. **边界** — 什么不在范围内？
|
||||
5. **现有约束** — 技术栈、兼容性、时间上的限制？
|
||||
|
||||
输出格式：proposal.md
|
||||
|
||||
### Spec 阶段：从 proposal 到可执行规格
|
||||
将 proposal 升级为完整的规格文档，包含详细的功能描述、数据结构、API 设计、组件树等。最终产出包括：
|
||||
- `design.md` — 完整设计文档
|
||||
- `specs/` 目录 — 规格细节（包含详细的 spec 和 `plan-ready.md`）
|
||||
- `tasks.md` — 任务清单（含依赖关系和验收标准）
|
||||
|
||||
### Build 阶段：自动执行实现
|
||||
关键概念是**任务沙箱**（task sandbox）：
|
||||
1. 每个 task 从 tasks.md 中被抽取到一个独立的 `.snapshot/` 沙箱
|
||||
2. 沙箱内包含：任务描述、相关规格、类/方法骨架、依赖说明
|
||||
3. 为每个 task 生成独立的 context（LLM 上下文隔离，避免信息过载）
|
||||
|
||||
### Close 阶段：验证与归档
|
||||
- `verify` 子命令：对照 tasks.md 验证每个任务的实现状态和格式一致性
|
||||
- `close` 归档：将 changes 目录中的内容归档到当前项目的 `changes/`
|
||||
|
||||
---
|
||||
|
||||
## 编排 vs 工具绑定
|
||||
|
||||
OpenFlow 与其他方案的区别：
|
||||
- **不是**将 Cursor/Claude Code/Codex 等工具与工作流深度绑定
|
||||
- **而是**在每个阶段生成描述性的 prompt 和产出，让各阶段的 AI Agent 可以看懂指令并产出对接产物
|
||||
- 靠**文件格式**（统一的 markdown 规范）打通各阶段，而不是靠 API 集成
|
||||
@@ -1,96 +0,0 @@
|
||||
# AI编程新范式：规格驱动编程 OpenSpec 的落地实战
|
||||
|
||||
**来源：** [微信公众号 - AI软件产品经理](https://mp.weixin.qq.com/s/5CSEUj1R7q3KhaRBkJE-ZA)
|
||||
**作者：** melong
|
||||
**日期：** 2026年4月7日 07:00
|
||||
**标签：** #OpenSpec #规格驱动编程 #AI编程 #Cursor #落地实战
|
||||
|
||||
---
|
||||
|
||||
## OpenSpec 简介
|
||||
|
||||
> OpenSpec 是一个命令行工具，帮助我们和 AI 助手之间建立规范驱动（spec-driven）的开发流程，强调变更隔离、人类与 AI 的共识和审查闭环，本质上是在构建一种新的"人机协作语言"。
|
||||
|
||||
GitHub: [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec)
|
||||
|
||||
### 核心思想
|
||||
将开发流程拆解为两个清晰的阶段：
|
||||
1. **明确"要什么"** — 在 `openspec/specs/` 文件夹中定义当前系统的完整规范
|
||||
2. **管理"怎么改"** — 在 `openspec/changes/` 文件夹中存放所有变更提案
|
||||
|
||||
从"边写边改"到"规范先行"，非常适合 **1→n 的项目迭代**。
|
||||
|
||||
### 亮点
|
||||
- 变更从提案到落地、全流程规范、闭环管理，每一步可溯源、复查与协同
|
||||
- 规范落地后，后续团队成员查阅 specs 文档即可快速了解业务历史和变更细节
|
||||
|
||||
---
|
||||
|
||||
## 初始化工作
|
||||
|
||||
### 1. 安装 OpenSpec
|
||||
```bash
|
||||
npm install -g @fission-ai/openspec@latest
|
||||
# 需要 Node >= 20.19.0
|
||||
```
|
||||
|
||||
### 2. 项目初始化
|
||||
```bash
|
||||
cd your_project
|
||||
openspec init
|
||||
```
|
||||
选择使用的工具（Cursor、Claude Code、Codex 等），会在项目根目录下生成对应的 skill 文件夹。
|
||||
|
||||
### 3. 填充项目上下文信息
|
||||
在 Cursor 对话框中输入：
|
||||
```
|
||||
Please read openspec/project.md and help me fill it out with details about my project, tech stack, and conventions
|
||||
```
|
||||
|
||||
`project.md` 结构包括：Purpose、Tech Stack、Project Conventions（Code Style / Architecture / Testing / Git Workflow）、Domain Context、Important Constraints、External Dependencies。
|
||||
|
||||
### 4. 生成变更提案
|
||||
在 Cursor 中使用 `/openspec-propose` 命令：
|
||||
```
|
||||
/openspec-propose 需求文档地址为https://mi.feishu.cn/wiki/xxx
|
||||
```
|
||||
|
||||
每次提案生成一个 Change ID，在 `changes/` 下创建目录，包含：
|
||||
- **proposal.md** — 提案（Why / What Changes / Impact）
|
||||
- **design.md** — 技术方案和架构决策
|
||||
- **tasks.md** — 任务清单（多阶段 checkbox 任务）
|
||||
- **specs/xxx/spec.md** — 可测试的需求规格
|
||||
|
||||
### 5. 审查与验证
|
||||
- **重新提案**：不满意时可反复迭代，直到符合预期
|
||||
- **反复迭代**：直接在 tasks.md 上修改，而不是新建提案
|
||||
|
||||
---
|
||||
|
||||
## 执行落地
|
||||
|
||||
### 拆分任务为可用交付（walkthrough）
|
||||
- 将 tasks.md 的每个阶段按最细粒度拆分
|
||||
- 让 AI 搞清楚当前阶段全部任务细节
|
||||
- 确认前后端各自的任务边界
|
||||
|
||||
### 增量编码模式
|
||||
- 每完成一个 phase，`/review` → `/fix` → `/test`
|
||||
- 用自然语言描述期望，比问"有没有bug"更有效
|
||||
- tips：频繁 `/clear` 清空上下文，避免 token 老化
|
||||
|
||||
---
|
||||
|
||||
## 常见报错与解决
|
||||
|
||||
| 报错 | 原因 | 解决 |
|
||||
|------|------|------|
|
||||
| `openspec: command not found` | Node 版本不够或全局安装路径问题 | 用 `npx @fission-ai/openspec` 替代，或升级 Node |
|
||||
| 图片/head 标签被截断 | Cursor 的响应长度限制 | 分阶段执行，或要求 AI 仅输出关键修改部分 |
|
||||
| 上下文过长导致幻觉 | 长时间未 `/clear` | 每个 phase 完成后 `/clear`，重新加载上下文 |
|
||||
|
||||
---
|
||||
|
||||
## 总结
|
||||
|
||||
> **OpenSpec 的核心价值不在于工具本身，而在于它强制执行的"先想清楚再动手"的工程纪律。** 在 AI 编码能力越来越强的今天，真正的瓶颈已经不是"写不出代码"，而是"写不对代码"。OpenSpec 通过规范驱动的方式，把人的判断力放在设计阶段，把 AI 的执行力放在编码阶段，各取所长。
|
||||
3763
InBox/tmp_tmall_ai_article.txt
Normal file
3763
InBox/tmp_tmall_ai_article.txt
Normal file
File diff suppressed because it is too large
Load Diff
739
InBox/tmp_tmall_ai_article_clean.txt
Normal file
739
InBox/tmp_tmall_ai_article_clean.txt
Normal file
@@ -0,0 +1,739 @@
|
||||
æ¬â½æ¯å
|
||||
³äº AI è¾
|
||||
å©ç¼ç çå
|
||||
¨â¾¯å®ææåï¼åºäºå¤©ç«æ°åå¢éçå®è·µç»éªï¼ä»é®é¢æ¬è´¨å°è§£å³â½
|
||||
æ¡ï¼ä»ç论æ¡æ¶å°å®ææ¡ä¾ï¼ç³»ç»æ§å°ä»ç»å¦ä½è®© AI æ´å¥½å°å®æ⼤é¨åéæ±ã
|
||||
æ¬æåä¸ä¸ä¸¤ç¯ï¼ä¸ç¯å
|
||||
å«ï¼
|
||||
1. ç°ç¶ä¸é®é¢è¯æ - æ·±â¼åæ AI â½£ç çå⼤çç¹ï¼åä¸å¯¹ãåä¸å¥½ãåä¸äºãæ¹ä¸å¨ï¼ï¼å¹¶ä»é¡¹â½¬ç¥è¯ã⽤æ·è¾â¼ãä»»å¡å¤æ度ãâ¾æ£æºå¶ã模åè½â¼çäºä¸ªç»´åº¦æä¾é对æ§è§£æ³ã
|
||||
2. â½
|
||||
æ³è®ºä¸ä¼åæè·¯ - æåº"æ⼤åå¤â½¤ãâ¾ç¶è¯â¾ç¬¬â¼ãâ¼â¼å®å¾"ä¸â¼¤æ ¸â¼¼ææ³ï¼å¹¶æ²¿ç"åç½®åå¤âå¼ååâå¼åä¸âå®æå"çå
|
||||
¨æµç¨ï¼ç»åºæ¯ä¸ªèç¹çå¯è½å°ä¼å⼿段ã
|
||||
3. ååºæ¯å®ææ¡ä¾ - æ ¹æ®éªæ¶æ åå代ç è´¨éè¦æ±ï¼å°éæ±å为"éæ±é©±å¨å"å"⼯ç¨ä¸»å¯¼å"两类ï¼éè¿â¼©â¼ç«¯å表â»åC端å¤æä¸å¡çå®æ´æ¡ä¾ï¼å±ç¤ºä¸ååºæ¯ä¸çæä½³å®è·µã
|
||||
ä¸ç¯å
|
||||
å«ï¼
|
||||
4. å¢é建设ç»éª - å享æ°åå¢éå¨â¼©â¼ç«¯ï¼å端å
|
||||
¨æ åï¼åC端ï¼è§å¾å离ãç¥è¯åºå»ºè®¾ã⼯ä½æµæ²æ·ï¼ä¸¤ä¸ªâ½
|
||||
åçæ¢ç´¢ï¼å
|
||||
æ¬â¼¯å
|
||||
·å»ºè®¾ãâ½æ¡£æ²æ·ãç¥è¯åºâ½
|
||||
æ¡çå
|
||||
·ä½è½å°å
|
||||
容ã
|
||||
5. å®â½¤æå·§éé¦ - 涵ç UI éæãå¤æ Prompt æ建ãæ°æ®è½¬æ¢ãå¤â½
|
||||
æ¡éä¼ãâ½æ¡£â½£æç常â»
|
||||
åºâ½¤åºæ¯ï¼ä»¥å严åè¯â½ãåçè´¨ççæåå确度çæå·§ã
|
||||
AIâ½£ç ç°ç¶
|
||||
â å½åAIâ½£ç ç主è¦é®é¢
|
||||
åä¸å¯¹ï¼
|
||||
AI没æå®å
|
||||
¨æç
|
||||
§â½¤æ·æå¾å®æåè½ï¼è½»ååå¨ç¼ºé·ï¼éåâ½æ³è¿â¾
|
||||
åä¸å¥½ï¼
|
||||
AI产åºç代ç ä¸ç¬¦åè¦æ±ï¼å
|
||||
æ¬ä½ä¸éäºä»£ç è´¨é/代ç é£æ ¼/å®ç°æ¹æ¡
|
||||
åä¸äº
|
||||
项ç®éå«é»è¾å¤ªå¤ï¼æ件ç»æå¤æï¼è¦å度é«ï¼AIå®å
|
||||
¨æ æ³æé¢æå®æä»»å¡
|
||||
ï¼å¦ä¸äºå
|
||||
é¨SDKå·¥å
|
||||
·åºï¼ä½¿ç¨è¯´æé½å¨å¤é¨ææ¡£ï¼AI æ æ³ç´æ¥éè¿ä»£ç ç解å¦ä½ä½¿ç¨ï¼èªç¶æ æ³ååºå¯¹åºç使ç¨ä»£ç ï¼
|
||||
æ¹ä¸å¨
|
||||
å¨æäºè¿ä»£åºæ¯ä¸ï¼AIä¸ç´æ æ³è¾åºæ£ç¡®ç»æï¼å¨é误ä¸ä¸æ循ç¯ï¼çè³è¿å¯è½æ¹åå
|
||||
¶ä»é¨åï¼æ¤æ¶åªè½äººå·¥ä»å
|
||||
¥
|
||||
èä»å
|
||||
¥åï¼æ³è¦å®æä¿®æ¹åéè¦é¢å¯¹AIçæ¶é´å
|
||||
çæç大é代ç ï¼åè导è´æçä¸éï¼ä½¿ç¨è
|
||||
å®å
|
||||
¨ä¸§å¤±äºå¯¹é¡¹ç®çææ§
|
||||
â 导è´é®é¢ç主è¦å ç´ ä¸è§£æ³
|
||||
1. 项⽬/éæ± éå«ä¿¡æ¯è¿å¤ï¼AIä¸ç¥éï¼
|
||||
ç±äºâ¼¤å®¶é½æ¯æ·å
|
||||
ç§æ项⽬ï¼ä»£ç ä¸ä¸ä»
|
||||
å
|
||||
å«äºä¸å±çä¸å¡é»è¾ï¼è¿ææ¥â¾å⾯â¼â½
|
||||
çSDK⼯å
|
||||
·åºä»£ç ï¼â¾¯å¯¹â½å¤è·åç项⽬ç¥è¯ï¼å³ä½¿æ¯Cluade40æ¥äºä¹â½æµäºäºã
|
||||
解æ³ï¼
|
||||
使⽤ææ确声æçNPMå
|
||||
ï¼æè
|
||||
ç»å
|
||||
¶æ¥â¼Artifact7 çè¾
|
||||
å©â½æ¡£â½£æ⼯å
|
||||
·ï¼
|
||||
æä¾å¯è®¿é®çå¤é¨ç¥è¯åºï¼å
|
||||
æ¬ä½ä¸éäº MCP⼯å
|
||||
· / 项⽬ç¥è¯åº / éæ±â½æ¡£ã
|
||||
2. ⽤æ·è¾â¼ä¸ç²¾åï¼å¿
|
||||
è¦ä¿¡æ¯ä¸â¾ï¼æ²¡ç»AI说ï¼
|
||||
代ç å¼åå°±æ¯ä»æ¨¡ç³çéæ±è½¬åâ½æ§ä¹ç代ç ï¼æ¨¡ç³é¨åå¨å®ç°ä¸å¿
|
||||
ç¶ä¼è¢«è¡¥å
|
||||
|
||||
ï¼å®ç°ä¸åé¢æçâ¼â¼¤åå å°±æ¯æ¨¡ç³é¨å没ææ确说æã
|
||||
解æ³ï¼
|
||||
⽤æ·ä¸»å¨å¢å è¾â¼å
|
||||
容 / è¾
|
||||
å©â¼¯å
|
||||
·æåè¾â¼è´¨é
|
||||
对â¼äºå¸¸â»
|
||||
çæ
|
||||
åµæä¾ prompt 模çï¼ä½¿â½¤æ¶æ ¹æ®å®é
|
||||
éæ±ä½é¨åä¿®æ¹ï¼
|
||||
å⽤⼯å
|
||||
·è¿â¾â½¤æ·è¾â¼æ©åï¼ä»¥å对å¿
|
||||
è¦ç模ç³é¨åè¿â¾æ è®°ä¸éæï¼
|
||||
å¼â¼ Spec Coding â½
|
||||
æ¡ï¼ä»¥è¯¦ç»çâ½æ¡£ä½ä¸ºAIè¾â¼ï¼
|
||||
对⾼é¢åºæ¯ååºçº¦å®ï¼éè¿çº¦å®æ¥è¦ç模ç³ï¼å¦ç»´æ¤â¼ä»½æç»æ´æ°çAGENT.mdï¼ã
|
||||
æå¾è¯å«ï¼åºäºé¡¹â½¬ä¸ä¸â½â¾å¨æ¨æµæ¨¡ç³é¨å
|
||||
æ¥â¼MCP⼯å
|
||||
·ï¼æ©â¼¤ AI æç¥â¼ï¼ä½¿AIè½æ´å¥½å°ç解⽤æ·æå¾ï¼
|
||||
éè¿ ä»£ç ç´¢å¼ / 项⽬â½æ¡£ / CodeWiki çè¾
|
||||
å©â¼¿æ®µï¼ä½¿ AI å¯ä»¥åºäºé¡¹â½¬ä»£ç å¿«é仿åä¸æ¨æµã
|
||||
è¿â¾¥åå¨â¼ä¸ªå
|
||||
³äºâ½æ¡£è¯¦ç»ç¨åº¦çæè¡¡ç¹ï¼å°åºæ¯ä½¿â½¤â¼¤â½½å
|
||||
¨çâ½æ¡£ï¼è¿æ¯â¼©â½½ç²¾ã
|
||||
ç»è¿å®è·µï¼æéåçâ½
|
||||
æ¡åºè¯¥æ¯å
|
||||
ç»åºâ¼ä¸ªå¯ä»¥åºæ¬æè¿°æ¸
|
||||
æ¥éæ±ç⼩â½æ¡£ï¼åæ ¹æ®AIå®é
|
||||
产åºçå离æ
|
||||
åµæ¥è¿â¾é®é¢è¡¥å
|
||||
|
||||
ï¼å 为⼤é¨åé½æ¯â¼ä¸ªéå¤åºç°ç常â»
|
||||
é®é¢ï¼åææ¯ä¿æ⼯å
|
||||
·å模åå°½å¯è½ä¸åï¼ï¼è¿â¾â¼æ¬¡è¡¥å
|
||||
|
||||
以åå°±å¯ä»¥å®æâ¼ä»½ç²¾å好⽤çè¾â¼â½æ¡£ã
|
||||
3. ä»»å¡å¤æ度⾼
|
||||
AI â½£ç çæåçä¼éçä»»å¡å¤æ度çæåâ½½å¨æ个èç¹å¼å§éª¤éï¼æ¤æ¶åéè¦éè¿åéç⼿段éä½ä»»å¡çé¾åº¦ï¼æ⼤å AI çâ½£ç æåçï¼â½½éä½å¤æ度主è¦æ以ä¸ä¸¤ä¸ªâ»åº¦ã
|
||||
éä½ä»»å¡å¤æ度
|
||||
è¯å«éå¤ç⼯ä½æµä¸ä»£ç ï¼è¿â¾é对æ§ä¼åä¸å°è£
|
||||
å¤â½¤ï¼ä»â½½åå°â½£ç ç代ç éä¸ä¸ç¡®å®æ§ï¼
|
||||
å¤æä»»å¡æåï¼å°å个ä¸ææµè¯ç⼤åä»»å¡ï¼ææå¤ä¸ªå¯éªæ¶ç⼩åâ¿çï¼
|
||||
åºå®å®ç°æè·¯/ç»èï¼ç»â¼æ维模åï¼éè¿çº¦å®æ¥åå° æç»´/éå è´æ
|
||||
ã
|
||||
éä½â¼¯ç¨å¤æ度ï¼â½ä»¶éãè¦å度ï¼
|
||||
åå©ä¼ç§ç⼯ç¨ç»æ设计ï¼å®ç° 代ç / 模å / â½ä»¶ ç天ç¶è§£è¦ï¼å¾å¤â½£ç é®é¢å
|
||||
¶å®å½ç±»å°åºé½ä¼â¾å°åºç¡ç代ç ⼯ç¨åé®é¢ï¼å
|
||||
·æä¼ç§â¼¯ç¨ç»æçä»åºå¤©ç¶å°±æè¾â¾¼çAIâ½£ææåçï¼ï¼
|
||||
éè¿ä»£ç ç´¢å¼/项⽬â½æ¡£/CodeWiki çè¾
|
||||
å©â¼¿æ®µï¼æâ¾¼AIæ£ç´¢æçï¼åå°å æ£ç´¢å°é¾â½½æ°å¢çâ½â½¤ä¸ä¸â½ã
|
||||
4. 缺å°â¾æ£ç¯è
|
||||
ç°å¨ç常è§â½£ç æµç¨ï¼åªä¼è¿â¾åºç¡ç代ç è§èä¸è¯æ³æ£æµï¼å¹¶æ²¡æå®æ´çReview & Test çæµç¨ãæ¤æ¶çAIåªæ¯å®æäºä»£ç â½£æï¼å¹¶ä¸â¼å®å®æäºä»»å¡ï¼ä¹ä¸â¼å®æ»¡â¾å®é
|
||||
ç代ç è´¨éè¦æ±ã
|
||||
代ç è´¨éâ¾æ£
|
||||
å¨æ¬å°å¼â¼â¾æ£æµç¨ï¼åæ¶å®æ代ç è´¨é确认ï¼
|
||||
使⽤ Code å¹³å°çAI CRå©â¼¿è¿â¾åå¸åé¢æ£ï¼å¯ä»¥â¾å®ä¹ CR è§åã
|
||||
åè½â¾æ£
|
||||
å端å¯ä»¥éè¿æ¥â¼MCPçâ½
|
||||
å¼è®©AIå¯ä»¥æç¥å端â»â¾¯ï¼ä»â½½è¿â¾é¨ååè½æµè¯ï¼
|
||||
å端å¯ä»¥éè¿åæµç´æ¥æ¥çåè½æ£ç¡®æ§ï¼
|
||||
对äºâ½æ³æµè¯ç⼤åä»»å¡ï¼å¯ä»¥æåå°å¤ä¸ªæäºéªæ¶çâ¿çï¼å¦å端è¿â¾è§å¾å离ï¼å¯¹é»è¾hooksé¨åè¿â¾åå
|
||||
æµè¯ï¼ã
|
||||
5. 模å / Agent çå·®å¼ä¸è½â¼éå¶
|
||||
模åçä¸å / ç¼ç ⼯å
|
||||
·çä¸åï¼é½ä¼å½±åâ½£æç»æï¼å³ä½¿æ¯åâ¼ä¸ªæ¨¡åï¼ä¹ä¼å 为模åçéæºæ§â½½äº§â½£ä¸åçç»æãè¦å° AI â½£ç è¿â½¤å¨â¼¯ç¨ä¸ï¼ä¸ä»
|
||||
éè¦â¾¯å¯¹æ¨¡åççæ¿ï¼è¿éè¦å¯¹æ模åçéæºæ§ã
|
||||
ä¸ä¸â½çªâ¼æé
|
||||
çåè¿ç¨â½æ¡£ï¼å®ç°ä¸ä¸â½å¤â½¤ï¼è·³è¿æ¶éç¯è
|
||||
代ç ä¸ä¸â½ï¼ä»åºä¿¡æ¯ãæ¥â¼ä¿¡æ¯
|
||||
项⽬ä¸ä¸â½ï¼PRDãåè½â½æ¡£
|
||||
æä¾æ´ç²¾åçä¸ä¸â½ï¼å°½éä¸è®© AI é â½ä»¶çæµ
|
||||
éè¿â¼äºâ½¤æ· Rule çæ§æ³¨æâ¼ç¶æï¼â½å¦ï¼è®© AI æ¯æ¬¡å¯¹è¯ç»æé½è¦â½¤è°¢è°¢ç»å°¾ï¼å¦æ没æå说æä¸ä¸â½çªâ¼å·²ç»çäºï¼
|
||||
éæºæ§ / 模åå·®å¼ å¯¼è´â½£æå
|
||||
容çè´¨éä¸ç¨³å®
|
||||
æä¾æ´ä¸¥æ ¼ç约æâ½æ¡£ / Spec Codingâ½
|
||||
æ¡
|
||||
è¡¥å
|
||||
|
||||
â¾æ£ç¯è
|
||||
ä¿®æ¹åé®é¢é误çâ¾¼
|
||||
ä¿®æ¹åé®é¢ç¸å½äºä¸ä¸â½æ´å¤ï¼æ£ç¡®çè¦æ±æ´â¾¼çâ½£ç ä»»å¡ï¼â½½AIç解â¼å¼±ï¼æ以修æ¹åä»»å¡åç¡®çæ´ä½ï¼è¿å°±æ¯â¼¤å®¶æ常æå°çæ¹ä¸å¨çé®é¢ã对äºè¿ä¸ªé®é¢ï¼ä¸»è¦ç解æ³å°±æ¯â½¤åâ½æå°çåæ³å»éä½ä»»å¡å¤æ度ï¼åå° AIç解代ç çé¾åº¦ æè
|
||||
éä½â½£ç ä»»å¡ä½é
|
||||
天⽣对æäºé®é¢è½â¼å¼±ï¼å®¹æå¡å¨æ»å¾ªç¯â¾¥
|
||||
è¯å«å¸¸â»
|
||||
é误åºæ¯ï¼By Case åæ积累ç»éªï¼æ²æ·å¯¹åºç解æ³
|
||||
æ ¸â¼¼â½
|
||||
æ³è®ºä¸å
|
||||
¨æµç¨ä¼åæå
|
||||
è¿é¨å主è¦ä»ç»æâ¾¼AIâ½£ç ææçâ¼äºæ ¸â¼¼æè·¯ï¼å¹¶åºäºâ½£ç æµç¨ä¸çå个èç¹ç»åºâ¼äºå¯ä»¥å®æ½çä¼å⼿段ã
|
||||
â æ ¸â¼¼ææ³
|
||||
æ⼤åå¤â½¤
|
||||
â½è®ºæ¯â¼â¼¯ç¼ç è¿æ¯AIç¼ç ï¼æææççææâ½
|
||||
æ¡å°±æ¯æ⾼代ç çå¤â½¤åº¦ã å¨AIç¼ç çèæ¯ä¸ï¼éè¿å¤â½¤è¿å¯ä»¥æ⾼⽣ç ä»»å¡çç¡®å®æ§ï¼æ⼤éä½ä»»å¡å¤æ度ï¼æ⾼对代ç çææ§åº¦ï¼ä¿è¯â½£æç»æçè´¨éã
|
||||
模åä¼å
|
||||
|
||||
å°æ¯â¼é¨åçå¼åé½è§ä¸ºâ¼ä¸ªæç¡®è¾â¼è¾åºçæ åå¯å¤â½¤æ¨¡åï¼å¯ä¿¡ä»»çâ¿çï¼ï¼ä¸ææç¸å
|
||||
³å£°æå¯ä»¥éè¿æç¡®çè·¯å¾è®¿é®è·åï¼æ¯ä¸ªåè½é½æ¯å
|
||||
·ææ¸
|
||||
æ°è¾¹ççåºï¼AIå¯ä»¥å¾â¾ç¶å°ä»ä»£ç ä¸è·åæéç¥è¯ã
|
||||
ï¼ç°å¨çAI⼯å
|
||||
·å·²ç»å
|
||||
·å¤äºå¾å¼ºçä¿¡æ¯è·ååè½ä¸æ¨çè½â¼ï¼
|
||||
è¶â½ç¼ç¨
|
||||
ä¼å
|
||||
使⽤已æ模åï¼ä¸è¦â¾â¼°é 轮⼦ï¼éè¿æ⼩éçâè¶â½ä»£ç âå°å®ä»¬ç»åæå®æ´ç³»ç»ï¼ä½ ç代ç åªè´è´£ï¼ç»åãè°â½¤ãå°è£
|
||||
ãéé
|
||||
ãä»â½½å¨ä½¿â½¤AIå®æ⼤é¨å代ç çåæ¶ï¼ä»ç¶ä¿ç项⽬ææ§åº¦ã
|
||||
⼯ä½æµå¤â½¤
|
||||
对äºâ¼äºå¯æ åå/éå¤æ§å¼º/å¤æ度⾼ç⼯ä½æµç¨ï¼å¯ä»¥åæ¶æ²æ·å°æ åçAI⼯ä½æµï¼å
|
||||
æ¬ä½ä¸éäº â½æ¡£ãMCPãSkillï¼ï¼è¿â¼æ¥æ©â¼¤â¼¯ä½ä¸çå¯å¤â½¤èå´ã
|
||||
â½æ¡£å
|
||||
â¾
|
||||
â½æ¡£æ¯AI Codingç第â¼è¦ç´ ï¼PRDå³åæµï¼â½æ¡£å³ä»£ç ï¼ä¼å
|
||||
ä¿®æ¹â½æ¡£â½½ä¸æ¯ä»£ç ï¼è¿é¨åâ½æ¡£å¹¶ä¸è¦æ±â¼¤â½½å
|
||||
¨ï¼éç¹æ¯å¯¹â¼¤è´â½
|
||||
åçæè¿°ï¼ä¸é¨åææ··æ·é¨åç详ç»è¯´æã
|
||||
åºäº Spec-kit ç模åï¼çæ³ç¶æä¸æ¯æâ¼ä»½å¯ä»¥å代ç 100%äºç¸è½¬æ¢çâ½æ¡£ï¼ä½æ¯ç°å¨å®æµä¸æ¥å¾é¾è¾¾å°è¿ç§çæ³ç¶æï¼æ²¡æå¯ä»¥å®ç¾æ述项⽬çâ½æ¡£ï¼â½æ¡£ä¹æ²¡æ³æ°å¥½è½¬æ¢å°ä»£ç ï¼ï¼æ好ççç¥è¿æ¯å¤â½¤å°±â¾ã
|
||||
â¼â¼å®å¾
|
||||
认æ¸
|
||||
AIç28 å®å¾ï¼20% æ¶é´å¯ä»¥å®æ80%çä»»å¡ï¼ä½æ¯å©ä¸ç 20% è¦ 80% çæ¶é´ï¼
|
||||
0% â 80%ï¼èâ½æï¼ï¼ä»é¶å¼å§â½£ææ°åè½â¾®å¸¸å¿«ï¼AI 对å
|
||||
¨æ°çãç¬â½´çé»è¾å¤çå¾æå
|
||||
¶å®ç¾ï¼
|
||||
80% â 100%ï¼æ·±â½åºï¼ï¼å½åè½éè¦æ¶å°¾ï¼æ¶åå°å¤æçä¸ä¸â½ãè¾¹ç¼ Case ä¿®å¤ã以åä¸æ§é»è¾çè¦åæ¶ï¼AI ç表ç°ä¼æå´å¼ä¸è·ï¼å¸¸å¸¸éè¦â¼â¼¯ä»â¼ï¼
|
||||
æâ¾¼AIâ½£ææççéç¹ï¼1æ¯æâ¾¼å80%çè´¨éï¼2æ¯æâ¾¼å20%çæçã
|
||||
â å
|
||||
¨æµç¨èç¹
|
||||
â¼æ¬¡ AI Coding çæ§â¾æµç¨â¼¤æ¦å¯ä»¥æ¦æ¬ä¸ºï¼ç解⽤æ·æå¾ > æ¥æ¾ä¸ä¸â½> 设计æ§â¾â½
|
||||
æ¡>代ç â½£æ > ç®åæ ¡éªãç±äº LLM çéæºæ§ï¼æ¯â¼ä¸ªæ§â¾ç¯èé½å
|
||||
å«çâ½éçå¯è½ï¼â½½ææ§AIâ½£ç ï¼å°±æ¯å¨æ¯ä¸ªç¯èé½è¿â¾æ确声æä¸ä»â¼ï¼ä»â½½ä¿éAIæç
|
||||
§â¾â¼°çé¢æè¿â¾äº§åºã
|
||||
以ä¸æ¯ä»æ¯ä¸ªèç¹è¿â¾æåï¼å
|
||||
³äºAIç¼ç¨æµçæ¯ä¸ªé¨åï¼æ们æä»ä¹â¼¿æ®µå¯ä»¥è¿â¾ä¼åã
|
||||
è¿é¨å主è¦æ¯åºäºæ¯ä¸ªèç¹è¿è¡ä¼åæ¹æ¡è®²è§£ï¼å¹¶ä¸ä»£è¡¨å®é
|
||||
éè¦ä¸¥æ ¼æç
|
||||
§è¿ä¸ªæ¥éª¤è¿è¡æµç¨æåï¼æééç¨å³å¯ï¼å
|
||||
·ä½å®è·µä¸çåèåéåå¨åé¢çå®ææ¡ä¾ä¸ä¼è¯¦ç»è¯´æã
|
||||
åç½®åå¤
|
||||
åå¤é¡¹â½¬/å¢éç¥è¯åºï¼æä¾å
|
||||
Œ
|
||||
±ç»ä»¶APIï¼ä¸å¡ç¥è¯ï¼å
|
||||
æ¬ä½ä¸éäº mcp / ç¥è¯åº / â½æ¡£
|
||||
ç¡®å®åºç¡ç代ç å®ç°è§èï¼çº¦æ代ç â»æ ¼ï¼é常å½å README.md / AGENTS.md æ¾å¨æ ¹â½¬å½ï¼å¦æAI没æ读ååææï¼éè¿rulesæè
|
||||
⼿å¨æ·»å ä¸ä¸â½ï¼
|
||||
以尽å¯è½æç¡®ã解è¦çå½¢å¼ï¼è®¾è®¡ä»åºç⽬å½ç»æä¸å®ç°â½
|
||||
æ¡
|
||||
对äºâ½ä»¶å¼â½¤å±çº§å¤çæ
|
||||
åµï¼AIåºç çæ£ç¡®çæ¾èä¸éï¼â¼é¨åæ¯å 为å端å±äºå¼±ç±»åè¯â¾ï¼
|
||||
对äºæ´å å¤æç项⽬ï¼å¯ä»¥å°è¯ä½¿â½¤â¼äºæ´è¿â¼æ¥çè§å¾å离ä¸ç¶æ管ççâ½
|
||||
æ¡è¿â¾æå解è¦ã
|
||||
å¼åå
|
||||
æç¡®éæ±å
|
||||
容ï¼ä»£ç â½å
|
||||
³ï¼
|
||||
产åå¼åå°±æ¯ä»æ¨¡ç³çâ½æ¡£è½¬å代ç ï¼â½½ä»£ç æ¯â½æ§ä¹çï¼æ¨¡ç³é¨åå¨å®ç°ä¸å¿
|
||||
ç¶ä¼è¢«è¡¥å
|
||||
|
||||
ï¼å®ç°ä¸åé¢æçâ¼â¼¤åå å°±æ¯æ¨¡ç³é¨å没ææ确说æã
|
||||
对äºä¸æç¡®çæ
|
||||
åµï¼å¯ä»¥ä½¿â½¤â¼äºè¾
|
||||
å©â¼¯å
|
||||
·æè
|
||||
åºç¡æ¨¡çè¿â¾æ åå prd ç产åºï¼å¹¶æ ¹æ®éæ±è¿â¾ä¿®æ¹ï¼
|
||||
éæ±æç¡®é¨åï¼ä¸å»ºè®®æ¶åå
|
||||
·ä½å®ç°ï¼â½¬åçAIç¼ç è½â¼å·²ç»â¾å¤å¼ºâ¼¤ï¼éç¹è¯´æåè½éæ±å³å¯ï¼æç¡®çåè½â½æ¡£â¾ä»¥è®© AI 设计åºåéçâ½
|
||||
æ¡ï¼æåæ¶åå®ç°ä¸ä»
|
||||
å½±åéæ±è¯´æï¼ä¹ä¼éå¶ AI çåæ¥ï¼
|
||||
å¦æéè¦è¿â¼æ¥æç¡®åé¨ååè½ç¹ï¼å¯ä»¥éè¿ spec ⼯å
|
||||
·è½¬æ¢æè¿ä¼¼åå
|
||||
æµè¯çåè½â½æ¡£ï¼å¿
|
||||
è¦æ¶å°å
|
||||
¶è½¬åæå®é
|
||||
åå
|
||||
æµè¯ã
|
||||
ä»»å¡è®¾è®¡ä¸æå
|
||||
å¦æå次å®ç°è¿äºå¤æï¼ä¼ä¸¢å¤±å¯¹ä»£ç çææ§åº¦ï¼â½½å¦æå次任å¡ä½é太⼤ï¼AI 容æå¨æ§â¾è¿ç¨ä¸ä¸¢å¤±ä¸ä¸â½ä¸æ³¨æâ¼ã
|
||||
ç»ä»¶æåï¼å°â¼ä¸ªå¤æãéªæ¶å¡â¼ä¸¥æ ¼ä½â½æ³ç´æ¥æµè¯ãæ¶å模åå¤ãè¿ä»£é¢çâ¾¼ç⼤è§æ¨¡ä»»å¡ï¼æåå°å¤ä¸ªç®åãè¿ä»£é¢çä½ãå¯æµè¯çâ¿çï¼å¹¶è¿â¾ç»è£
|
||||
ã
|
||||
æµç¨æåï¼å°å¤æä»»å¡è¿â¾åæ¥æ解ï¼å¹¶éè¿æ¸
|
||||
åâ½æ¡£è®°å½å®ææ
|
||||
åµã
|
||||
å¼åä¸ï¼æ°å»ºåéæ±ï¼
|
||||
å建并æç»è¿ä»£è¿ç¨â½æ¡£ï¼å¦â»â¾¯READMEï¼ç»ä»¶è¯´æï¼ä»â½½ä¿éæ¯æ¬¡å¯¹è¯æ¶AIå¯ä»¥å¿«éè·åä¿¡æ¯ï¼é¿å
|
||||
AI读åè¿å¤â½ä»¶ã
|
||||
ï¼AIæ¯æ¬¡æ°å¯¹è¯é½éè¦è±è´¹â¼¤étokenå¨è¯»åä¸éæ±â½å
|
||||
³çåç½®ä¸ä¸â½ï¼
|
||||
åæ¶ç®¡çä¸ä¸â½çªâ¼ï¼ç¡®ä¿AI没æ失å»ä¸æ³¨åº¦ï¼â½å¦è®©AIæ¯æ¬¡æ§â¾å®éè¿°åºç¡ååï¼
|
||||
å°½å¯è½ä½¿â½¤ä¸¥æ ¼è§£è¦çæ¶æ设计ï¼é²â½çä¸ææ¯åº
|
||||
å¼â¼â¾æ£æºå¶ï¼ä¿éåè½ä¸è´¨é
|
||||
让AIâ¾â¾æ·»å è°è¯ç¹ä½ï¼éè¿è°è¯ä¿¡æ¯ä¿®æ¹é®é¢
|
||||
对â¿ç ç»ä»¶/åè½ å建åå
|
||||
æµè¯
|
||||
éè¿MCP⼯å
|
||||
·è¿â¾â»â¾¯æµè¯
|
||||
使⽤AIåç¬è¿â¾ä»£ç è´¨éReviewç¯è
|
||||
对äºé¨åæç»å¤±è´¥çåºæ¯
|
||||
å°è¯ä¿®æ¹â½¤æ·è¾â¼ï¼æä¾æ´ç²¾ç¡®çä¸ä¸â½ï¼æè
|
||||
åAIæä¾â½
|
||||
åæå¼
|
||||
让AIå¨ä¿®æ¹ä»£ç åå
|
||||
è¾åºâ½
|
||||
æ¡å¹¶å®¡é
|
||||
|
||||
æ¶éå°æ¡ä¾ä¸è¿â¾By Caseåæ
|
||||
常è§é·é±ï¼å¨ä¸æ¬¡ä¼è¯ä¸è¿è¡å¤§éä»»å¡ï¼è¿ä¼å¯¼è´ä¸ä¸æ太é¿å¤ªå®½æ³ï¼æ¨¡å注æå丢失ã
|
||||
对äºç¬ç«çä»»å¡ï¼åºè¯¥åæ¶æ°å»ºå¯¹è¯
|
||||
对äºå¤§åä»»å¡ï¼åºè¯¥åæ¶çæåç±»è¿ç¨ææ¡£ï¼å½æ¨¡åæåçæ¾èéä½æ¶åæ¢å¯¹è¯å¹¶ä¼ å
|
||||
¥è¿ç¨ææ¡£æ¢å¤ä¸ä¸æ
|
||||
å¼åä¸ï¼è¿ä»£åéæ±ï¼
|
||||
常â»
|
||||
é®é¢ï¼
|
||||
åºæ¯
|
||||
åâ½£äºä»ä¹
|
||||
åæ
|
||||
æ¹â¼ä¸ªåè½ï¼åäºå¦â¼ä¸ª
|
||||
æ·»å å é¤åè½æ¶ï¼ä¸â¼©â¼¼å½±åäºæ·»å åè½
|
||||
è±æ¶é´ææ¥ï¼å¯è½è¶æ¹è¶ä¹±
|
||||
æ³åå°"æ¨å¤©é£ä¸ªçæ¬"
|
||||
æ¨å¤©ç代ç è½â½¤ï¼ä»å¤©æ¹äºâ¼å ï¼å
|
||||
¨åäº
|
||||
æ¾ä¸å°æ¨å¤©ççæ¬
|
||||
è¯äºä¸ç§â½
|
||||
æ¡ï¼æ³åå°ç¬¬â¼ç§
|
||||
第â¼ç§â½
|
||||
æ¡å
|
||||
¶å®æ好ï¼ä½å·²ç»è¢«è¦çäº
|
||||
è¦ä¹éåï¼è¦ä¹å°å°±
|
||||
AI æ¹äºä¸è¯¥æ¹çå°â½
|
||||
|
||||
让 AI æ¹â¼ä¸ªâ½ä»¶ï¼å®é¡ºâ¼¿æ¹äºå
|
||||
¶ä»â½ä»¶
|
||||
ä¸ç¥éåªäºè¢«æ¹äº
|
||||
ç¸è¾äºæ°å»ºåä»»å¡ï¼è¿ä»£æ¶æåçæ´ä½çåå 主è¦æ¯ï¼AI天çé模仿èå¼±ç解ï¼æ°å»ºåä»»å¡ä¾§éäºæ¨¡å对代ç ç仿åè½åï¼èè¿ä»£åä»»å¡è¦æ±AIç解代ç ä¸ç²¾åä¿®æ¹ï¼æ以æåçæ´ä½ã
|
||||
注æåæ¶çº¦æï¼é²â½AI⽬æ æ¼ç§»
|
||||
Bad Case â
|
||||
"帮æä¼åè¿ä¸ªå½æ°"ï¼ç»æ AI éæäºæ´ä¸ªç±»ï¼
|
||||
Good Case â
|
||||
|
||||
åªä¼åå½æ° calculateTotalï¼ä¸åä»»ä½å
|
||||
¶ä»çåæ´ï¼éä¸äºæ¤å½æ°ä¸ç¹
|
||||
å°½éä¼ â¼ç²¾åçä¸ä¸â½ï¼åå°AIæç´¢èå´
|
||||
Bad Case â
|
||||
帮æä¿®æ¹ç°å¨çå¼¹çªæ ·å¼ï¼åå
|
||||
¶ä»é¡µé¢çç»ä¸
|
||||
Good Case â
|
||||
|
||||
帮æä¿®æ¹pages/GoodsManagement/drawer.tsx ä¸çå¼¹çªæ ·å¼ï¼åèpages/Warehouse/GoodsDetAIl/drawer.tsx
|
||||
ç®å主æµå·¥å
|
||||
·é½å¯ä»¥æ·»å ä¸ä¸æï¼ä¸ç¨èªå·±åpath
|
||||
对äºå¤æè¿ä»£ï¼æ好åæ¶éè¿gitè¿â¾çæ¬ç®¡çï¼å 为符åéæ±ç代ç å¯è½å¨åâ¼ä¸ªâ¼©æ¶ï¼çâ¾åâ¼å¤©çæ个çæ¬ï¼å¤â½
|
||||
æ¡å¯¹â½â½¤åâ½ / çæ¬ç®¡ç⽤commitï¼
|
||||
è¿â¼æ¥çè¿ä»£æåçï¼ä¸»è¦ä¾èµäºä»åºæ¶æç解è¦ç¨åº¦ï¼æ¹ä¸å¨æ¶å°±è¦ä¾é æè´æ§ç解è¦
|
||||
â¼â¼¯å¿
|
||||
é¡»ä»â¼æ¶ï¼å¯ä»¥é⽤â¼â¼¯æä¾â½
|
||||
æ¡ï¼AIæ§â¾æ¹å¨çåâ¾å¨â½
|
||||
æ¡èçæ¶é´ï¼å¦ï¼æè¦ç§»é¤è¿ä¸ªå½æ°ä¸ç¡¬ç¼ç çä¸å¡é»è¾ï¼å°å
|
||||
¶æ¹æå¤é¨ä¼ åï¼å¹¶å¨æ¹å¥½ååæ¥ä¿®æ¹ææè°â½¤äºè¿ä¸ªå½æ°ç代ç ï¼
|
||||
å®å¨â½æ³ç»§ç»è¿ä»£æ¶ï¼åå©å·²æçåè½â½æ¡£è¿â¾æ´ä½ä»£ç éæï¼å¦æ没æï¼å¯ä»¥å°è¯è®©AIæ ¹æ®â½¬åè¿â¾æ»ç»ï¼ä½æ¯æ¤æ¶æ好ä»æ¨¡ååä¸éæï¼
|
||||
å
|
||||
¶ä½é¨ååæ°å»ºåéæ±
|
||||
å®æå
|
||||
åºäºéæ±å®ææ
|
||||
åµåæ¶è¿â¾é®é¢ç¹åæä¸èµäº§æ²æ·ï¼çæ³æ
|
||||
åµçâ¾å¯ä»¥èè让 AI åºäºå·²æç»éªè¿â¾â¾æè¿ä»£ï¼ä»â½½éæ¥æ©â¼¤è½â¼è¾¹çï¼è¸©è¿çåå°±ä¸è¦å踩ï¼åè¿ç代ç å°±ä¸è¦å第â¼éã
|
||||
åºäºâ½£ç è¿ç¨ä¸ç常â»
|
||||
é®é¢ï¼åæ¶è¿ä»£åºç¡è§èâ½æ¡£
|
||||
ï¼â¼©â¼ç«¯å¼åä¸æ²æ·çå
|
||||
³é®æ³¨æç¹ï¼å°¤å
|
||||
¶æ¯éè¦æ²»çAIå欢乱⽤hooksçâ½ç
|
||||
ï¼
|
||||
è¯å«å
|
||||
³é®æµç¨ï¼æ²æ·å°Skillï¼èµäº§åçAISOPï¼å
|
||||
å«æè¿°ãæ令ãèæ¬ã模ççå
|
||||
容ï¼
|
||||
è¯å«å
|
||||
³é®æ¨¡å¼ï¼æ²æ·å°æ åå ç»ä»¶ / 模ç
|
||||
åºç åç¡®ç
|
||||
â¼â¼¯ä»â¼ææ¬
|
||||
AIâ¾ç±åæ¥
|
||||
70%
|
||||
â¾¼
|
||||
æè¯æçä¸â½
|
||||
å
|
||||
|
||||
80%
|
||||
ä½
|
||||
ç§æå
|
||||
+è°â½¤è§è
|
||||
95%
|
||||
ä½
|
||||
çå®ä»¥ä¸çå
|
||||
容ï¼æ人ä¼è¯´ï¼æåªæ³ä½¿ç¨åºç¡çChatè¿è¡ä»£ç çæï¼ä¸æ³è¯å®¡AIçæçæ¹æ¡ï¼ä¹ä¸æ³è·³è½¬åºå»ä½¿ç¨é¢å¤çå·¥å
|
||||
·ï¼æä¹è®©æçChatçç æææ´å¥½ï¼ä»¥ä¸æ¯å 个快æ·å¯ç¨çè°ä¼æ段ï¼
|
||||
é
|
||||
ç½®åºç¡ç项ç®è§åï¼å¹¶æ ¹æ®å®é
|
||||
çé®é¢å¯¹å
|
||||
¶è¿è¡ä¸äºè°ä¼ï¼
|
||||
æå设计è¾ä¸ºè§£è¦ç项ç®ç»æï¼æé« AI è¿ä»£çæåçï¼
|
||||
æ¥å
|
||||
¥ä¸äºè¾
|
||||
å©çMCPå·¥å
|
||||
·åå·²éªè¯è¿çSkillsè¿è¡è½åè¾
|
||||
å©ï¼
|
||||
使ç¨ä¸äºåºç¡çæ示è¯æµç¨æ模çï¼å°½å¯è½æè¿°æ¸
|
||||
æ¥éæ±ï¼
|
||||
å½çº¯å¯¹è¯æ¹å¼å®å
|
||||
¨é·å
|
||||
¥ç¶é¢æ¶ï¼å¯ä»¥åè以ä¸ä¸¤ç§å®ææ¡ä¾è¿è¡ä¼åã
|
||||
两类å®ææ¡ä¾
|
||||
AIç¼ç è¿ç¨ä¸ï¼æ个â½è¾éè¦çå
|
||||
³æ³¨ç¹å°±æ¯ï¼å¨ä¿è¯è¿ä»£æåççåæ¶ï¼è¿è¦çåºâ¼å®çâ¼ä¸ºå¯ä»â¼ç©ºé´ï¼ä»¥åä¿æ对代ç çææ§åº¦ï¼å¯¹äºéªæ¶è¦æ±è¶â¾¼ç项⽬ï¼ææ§çåâ¼â¼¯å¯ä»â¼ç©ºé´çè¦æ±å°±è¶â¾¼ï¼â½½æ ¹æ®éªæ¶è¦æ±ä»¥åå®é
|
||||
æ
|
||||
åµï¼å¯ä»¥å°å®é
|
||||
éæ±å为以ä¸ä¸¤ç±»ã
|
||||
éæ±é©±å¨å
|
||||
⼯ç¨ä¸»å¯¼å
|
||||
ç¹ç¹
|
||||
强è°"è¦ä»ä¹åè½"
|
||||
AI â¾ä¸»å³çææ¯å®ç°
|
||||
â¼â¼¯ä»â¼å°ï¼å
|
||||
³æ³¨ç»æ
|
||||
强è°"æä¹å®ç°"
|
||||
â¼â¼¯æ·±åº¦åä¸å®ç°â½
|
||||
æ¡å³ç
|
||||
â¼â¼¯ä»â¼å¤ï¼å
|
||||
³æ³¨ä»£ç è´¨é
|
||||
代ç è§è度è¦æ±
|
||||
ä½
|
||||
â¾¼
|
||||
éªæ¶æ å
|
||||
ä½
|
||||
â¾¼
|
||||
éå«ç¥è¯é
|
||||
ä½
|
||||
â¾¼
|
||||
项⽬å¤æ度
|
||||
ä½
|
||||
â¾¼
|
||||
AIæ®æ¼çâ»â¾
|
||||
åè½å¼åè
|
||||
|
||||
ç¼ç è¾
|
||||
å©å
|
||||
æ¡ä¾
|
||||
⼩â¼åå°â»â¾¯ / ç åâ¾â½¤â¼¯å
|
||||
·
|
||||
线ä¸C端â»â¾¯ / å家端â»â¾¯
|
||||
â éæ±é©±å¨åï¼DO WHATï¼
|
||||
è¿â¼åºæ¯ç主è¦å
|
||||
³æ³¨ç¹å¨äºï¼
|
||||
æ³åæ³å®å
|
||||
¨éæéæ±ç¹ï¼é²â½ AI èé æå离ï¼
|
||||
è¦æâ¼å®çè¾
|
||||
å©â¼¿æ®µæ¥ä¿è¯ä»£ç è´¨éï¼ä»â½½æâ¾¼è¿ä»£æåçï¼
|
||||
çåºâ¼å®çâ¼â¼¯ä»â¼ç©ºé´ï¼ä¸è¦äº§åºâ¼å é¾ä»¥ä»â¼ç代ç ï¼
|
||||
æ¥ä¸æ¥å°ä»¥â¼ä¸ªâ¼©â¼ç«¯çéæ±ï¼ä»æ°å»ºâ»â¾¯å°â¼æ¬¡è¿ä»£åè½ï¼éæ¥å¯¹â½ä¸åâ½
|
||||
æ¡äº§åºçâ½£ç ç»æã
|
||||
æ°å»ºâ¼ä¸ªâ¼©â¼ç«¯å表â»
|
||||
éæ±èæ¯ï¼
|
||||
â¼ä¸ªå¸¸è§çå表â»ï¼æå段å±ç¤ºè´§åç¸å
|
||||
³ä¿¡æ¯ï¼å¹¶ä¸â½ææå段è¿æ»¤ã
|
||||
对äºç®åçâ»â¾¯â½£æï¼æä¾â¾å¤ä¿¡æ¯çâ½æ¡£ï¼AIå³å¯å®æ对åºçéæ±ï¼â½½æ ¹æ®å®é
|
||||
éæ±çéªæ¶å¡â¼ä¸â½¤æ·éæ±ï¼è¿å¯ä»¥å为å¦ä¸ä¸ç§å®ç°â»æ ¼ã
|
||||
è½â½¤å°±â¾å
|
||||
è¾æè¦æ±å
|
||||
ä¸¥æ ¼å
|
||||
ï¼å·²ç»æâ¼ä»½å
|
||||
³äºå¸¸è§å表æ¥è¯¢â»çå®ç°æ¨¡çï¼
|
||||
å®ç°è·¯å¾
|
||||
ç´æ¥è¾â¼æ¥â¼ææ¡£ï¼å
|
||||
¶ä»å®å
|
||||
¨ç±AIè¿è¡å®åã
|
||||
æä¾å°éå®ç°éå®ï¼ä½¿â½¤tao- designï¼ï¼æè
|
||||
ç±AIâ¾â¾è¯»åä»åºä»£ç è¿â¾å¤æ
|
||||
æä¾åºç¡ç代ç å®ç°è§èä¸â½ä»¶æ¨¡ç
|
||||
æè¦æ±æä¾prdï¼å¹¶è¿â¾â¼å®çç»æåä¼å
|
||||
æä¾åºç¡ç代ç å®ç°è§èä¸â½ä»¶æ¨¡ç
|
||||
æè¦æ±æä¾prdï¼å¹¶è¿â¾â¼å®çç»æåä¼å
|
||||
æä¾æ´ä¸¥æ ¼çå
|
||||
·ä½å®ç°ç»å®ï¼éè¿ä¸¥æ ¼ç代ç 模çéå®äº§ç©æ ¼å¼
|
||||
ææ
|
||||
æ ·å¼
|
||||
ç»ä»¶åºå
|
||||
åºåºæ¬é£æ ¼
|
||||
ç»ä»¶åºå
|
||||
åºåºæ¬é£æ ¼
|
||||
åè½ç¬¦åç¨æ·è¦æ±
|
||||
符åè§è§ç¨¿ / å¹³å°è§èè¦æ±
|
||||
åè½ç¬¦åç¨æ·è¦æ±
|
||||
å¯è¿ä»£æ§
|
||||
éå¤ææ
|
||||
åµï¼AIä¹å¯ä»¥åè¿è¡ä¸å®ç¨åº¦çè¿ä»£
|
||||
AIå¯ä»¥è¿è¡ä¸å®ç¨åº¦çè¿ä»£
|
||||
AIå¯ä»¥è¿è¡é¿æå¤æ¬¡çè¿ä»£
|
||||
代ç è´¨é
|
||||
代ç ç»ç»æ ¼å¼éæºï¼è¿å¯è½äº§åºå个巨åæ件ï¼ï¼äººå·¥ä»å
|
||||
¥ææ¬é«
|
||||
代ç ç»ç»æ ¼å¼è¾è§èï¼ä»£ç 轻度解è¦ï¼äººå·¥ä»å
|
||||
¥ææ¬ä¸ï¼ä»ç¶æé¨åé»è¾ä»£ç å
|
||||
å«å¨ä¸»æ件
|
||||
代ç å®å
|
||||
¨æç
|
||||
§ç»ä¸æè·¯ / ç»ä»¶ å®æï¼åè½å®ç°åæ£å¨å个åç»ä»¶ï¼ä»£ç ä¸¥æ ¼è§£èï¼äººå·¥ä»å
|
||||
¥ææ¬ä½
|
||||
对äºè¿ç§ä¸¥æ ¼ç解è¦æ¨¡å¼ï¼äººå·¥ç¼åæ¶å¯è½ææ¬è¿é«ï¼ä½æ¯äº¤ç»AIç¼ååæ¯éå¾å
|
||||
¶æ
|
||||
é®é¢è°è¯
|
||||
åâ½æ§å¶
|
||||
å¨å¾®è°é¶æ®µï¼åæ¶éè¿Commitä¿åçæ¬ï¼å 为AIâ½£ç æ¯è¦çå¼ï¼æ²¡æåæ¶åæ¡£ä¼å 为æäºé误修æ¹å¯¼è´ä»£ç æ··ä¹±ï¼ååå°½å¼ï¼â½¬åçâ½£ç ⼯å
|
||||
·é½æâ¼å®çåéåè½ï¼ä½æ¯ä¸è½è¿äºä¿¡ä»»ï¼ã
|
||||
æ¥éè°è¯
|
||||
常è§æ¥éç´æ¥å°æ¥éé¨åå¤å¶ç»Agentâ¾â¾è°è¯å³å¯ï¼å¯è§£å³ç80%ï¼è§£å³ä¸æçé¨å主è¦æ¥â¾ä¸â½
|
||||
åºå
|
||||
é¨çæ¥éï¼éè¦ç¹å¤ï¼ã
|
||||
é¨åéé»æåæ¥éï¼å
|
||||
³æå¼¹çªå³å¯ï¼é¨åé误弹çªåªæ¯ä¾¿äºæ¬å°è°è¯ï¼çº¿ä¸å¹¶ä¸ä¼æ¾ç¤ºã
|
||||
æ°æ®è°è¯
|
||||
æ°æ®é®é¢ä¸ä¼ææ¥éæ示ï¼å¯ä»¥è®©AIâ¾â¾â½£æâ¼äºè¾åºâ½å¿è¾
|
||||
å©ææ¥ã
|
||||
xxxxæ¾ç¤ºä¸ºç©ºï¼å¸®æå¨å
|
||||
³é®èç¹æ°å¢consoleâ½å¿ï¼ä»¥ä¾¿æå¤å¶ç»ä½ ææ¥é®é¢ã
|
||||
以ä¸é¡µé¢è°è¯ä¹å¯ä»¥éè¿MCPå·¥å
|
||||
·ï¼æè
|
||||
ç´æ¥éè¿cursorçbrowser tabè¿è¡ï¼ç¯å¹
|
||||
é®é¢ä¸åå±å¼ã
|
||||
è¿â¾â¼æ¬¡æ¶åå¤ä¸ªé¨åçä¸åè¿ä»£
|
||||
éæ±èæ¯ï¼åå§éæ±ï¼ï¼
|
||||
å¨è´§å管ç页é¢ä¸ï¼è´§åé¤äºåºç¡ä¿¡æ¯å¤ï¼è¿å
|
||||
å«å¨æå±æ§ä¿¡æ¯ãè¿äºå±æ§ç±å±æ§å®ä¹ç³»ç»ç®¡çï¼æ¯æå¤ç§æ°æ®ç±»åï¼å符串ãæ°åãå¸å°å¼ãæ¶é´æ³çï¼ï¼ä¸åè´§åå¯è½æ¥æä¸åçå±æ§ã
|
||||
为äºæåè´§å管ççæçåç¨æ·ä½éªï¼éè¦æä¾ä»¥ä¸åè½ï¼
|
||||
å±æ§å±ç¤ºï¼å¨å表ä¸ç´è§å±ç¤ºè´§åå±æ§ï¼æ¯æç¨æ·èªå®ä¹æ¾ç¤ºåªäºå±æ§
|
||||
å±æ§çéï¼æ¯ææå±æ§è¿è¡çéæ¥è¯¢ï¼å¿«éå®ä½ç®æ è´§å
|
||||
å±æ§ç¼è¾ï¼æ¯ææ¥çåç¼è¾å个货åçå±æ§ä¿¡æ¯ã
|
||||
æç¡®éæ±
|
||||
å
|
||||
åºäºæ¥â¼â½æ¡£åéæ±ï¼äº¤ç»AIå建产åâ½æ¡£ï¼æ ¸å¯¹å®æåè¿â¼ä¸â¼æ¥ï¼å¸¸è§æ¹å¨å¯ä»¥è®©AIç´æ¥â½£æï¼ä½å¦ææ¶åå°å¤æç交äºï¼æ好å
|
||||
ççAIåå¤æä¹å®ç°ï¼,以ä¸æ¯è®©AIæ©ååç产åéæ±â½æ¡£ã
|
||||
# è´§åå±æ§åè½éæ±ææ¡£
|
||||
## éæ±èæ¯
|
||||
å¨è´§å管ç页é¢ä¸ï¼è´§åé¤äºåºç¡ä¿¡æ¯å¤ï¼è¿å
|
||||
å«å¨æå±æ§ä¿¡æ¯ãè¿äºå±æ§ç±å±æ§å®ä¹ç³»ç»ç®¡çï¼æ¯æå¤ç§æ°æ®ç±»åï¼å符串ãæ°åãå¸å°å¼ãæ¶é´æ³çï¼ï¼ä¸åè´§åå¯è½æ¥æä¸åçå±æ§ã
|
||||
为äºæåè´§å管ççæçåç¨æ·ä½éªï¼éè¦æä¾ä»¥ä¸åè½ï¼1. **å±æ§å±ç¤º**ï¼å¨å表ä¸ç´è§å±ç¤ºè´§åå±æ§ï¼æ¯æç¨æ·èªå®ä¹æ¾ç¤ºåªäºå±æ§2. **å±æ§çé**ï¼æ¯ææå±æ§è¿è¡çéæ¥è¯¢ï¼å¿«éå®ä½ç®æ è´§å3. **å±æ§ç¼è¾**ï¼æ¯ææ¥çåç¼è¾å个货åçå±æ§ä¿¡æ¯
|
||||
---
|
||||
## ä¸ãåè½éæ±
|
||||
### 1.1 å±æ§åå±ç¤º
|
||||
**åè½ï¼** å¨è´§åå表ä¸æ·»å "å±æ§"åï¼å±ç¤ºè´§åå±æ§ä¿¡æ¯ã
|
||||
**交äºï¼**- é»è®¤æ¾ç¤ºææå±æ§ï¼æ¯ä¸ªå±æ§ä»¥"æ ç¾+å¼"å±ç¤º- æä½åºæä¾"é
|
||||
ç½®å±æ§å"æé®ï¼å¯é
|
||||
ç½®æ¾ç¤ºåªäºå±æ§- æ¶é´æ³ç±»åæ¾ç¤ºä¸ºæ¥ææ¶é´æ ¼å¼ï¼ææ¬ç±»åæ¯ææ¢è¡- æ å±æ§æ¶æ¾ç¤º"ææ å±æ§"
|
||||
---
|
||||
### 1.2 å±æ§çé
|
||||
**åè½ï¼** å¨çéåºæ¯ææå±æ§è¿è¡çéæ¥è¯¢ã
|
||||
**交äºï¼**- çéåºæ¾ç¤º"æå±æ§çé"åºåï¼å·²æ·»å ççéæ¡ä»¶ä»¥ Tag å±ç¤º- ç¹å»"æ·»å å±æ§çé"æå¼å¼¹çª- å¼¹çªä¸éæ©å±æ§ï¼ç³»ç»æ ¹æ®å±æ§ç±»åèªå¨å¤æçéæ¹å¼ï¼ - å符串/ææ¬ï¼ææ举å¼âæ举å¤éï¼æ æ举å¼âææ¬å¹é
|
||||
- æ°åï¼æ°å¼èå´ - å¸å°ï¼å¸å°å¼éæ© - æ¶é´æ³ï¼æ¶é´èå´ - æ¶é´æ³èå´ï¼æ¶é´ç¹- è¾å
|
||||
¥çéå¼åç¡®å®ï¼çéæ¡ä»¶çæ并触åæ¥è¯¢
|
||||
---
|
||||
### 1.3 å±æ§ç¼è¾
|
||||
**åè½ï¼** å¨æä½åæä¾"å±æ§"æé®ï¼å¯æ¥çåç¼è¾è´§åå±æ§ã
|
||||
**交äºï¼**- ç¹å»"å±æ§"æé®æå¼å³ä¾§æ½å±- æ½å±ä¸ä»¥è¡¨æ ¼å±ç¤ºå±æ§ä¿¡æ¯ï¼å±æ§é®ãå±æ§é®å称ãå±æ§ç±»åãå±æ§å¼ï¼- æ ¹æ®å±æ§ç±»åæ¾ç¤ºå¯¹åºç¼è¾æ§ä»¶ï¼ - æ°åâæ°åè¾å
|
||||
¥æ¡ - å¸å°âå¼å
|
||||
³ç»ä»¶ - æ¶é´æ³âæ¥ææ¶é´éæ©å¨ - æ¶é´æ³èå´âæ¥ææ¶é´èå´éæ©å¨ - å符串ï¼ææ举å¼ï¼âä¸æå¤é - å符串ï¼æ æ举å¼ï¼âææ¬è¾å
|
||||
¥æ¡ - ææ¬âå¤è¡ææ¬è¾å
|
||||
¥æ¡- ä¿®æ¹åç¹å»"ä¿åå±æ§"ï¼ä¿åæååå·æ°å表并å
|
||||
³éæ½å±
|
||||
---
|
||||
## äºãæ°æ®ç±»å说æ
|
||||
| å±æ§ç±»å | çéæ¹å¼ | ç¼è¾æ§ä»¶ ||---------|---------|---------|| STRING | ææ¬å¹é
|
||||
æ æ举å¤é | ææ¬è¾å
|
||||
¥æ¡ æ ä¸æå¤é || TEXT | ææ¬å¹é
|
||||
| å¤è¡ææ¬è¾å
|
||||
¥æ¡ || NUMBER | æ°å¼èå´ | æ°åè¾å
|
||||
¥æ¡ || BOOLEAN | å¸å°å¼ | å¼å
|
||||
³ç»ä»¶ || TIMESTAMP | æ¶é´èå´ | æ¥ææ¶é´éæ©å¨ || TIMESTAMP_RANGE | æ¶é´ç¹ | æ¥ææ¶é´èå´éæ©å¨ |
|
||||
---
|
||||
è¿ä»£ææ对æ¯
|
||||
ç±äºä¸æ¯ææ页é¢é½è½æ¾å°å¯ä»¥æ°å¥½æ½è±¡æè¿°åºæ¥ç页é¢æ¨¡çï¼æ以è¿ééç¨ è½ç¨å°±è¡ç å è¾æè¦æ±ç è¿è¡è¿ä»£ææ对æ¯ã
|
||||
è½â½¤å°±â¾åç +
|
||||
ä»
|
||||
è¾â¼åå§éæ±
|
||||
è¾æè¦æ±ååç +
|
||||
ä»
|
||||
è¾â¼åå§éæ±
|
||||
è¾æè¦æ±ååç +
|
||||
æâ¼â¼¯éæåç详ç»åè½â½æ¡£
|
||||
æç»ææ
|
||||
åºæ¬ç¬¦åè¦æ±
|
||||
åè½ååºæ¥äºï¼ä½æ¯ä¸å¤ªåé¢æ
|
||||
åºæ¬ç¬¦åè¦æ±
|
||||
代ç è´¨é
|
||||
⼤éä¿®æ¹ä¸»â½ä»¶ï¼å¤æ¬¡è¿ä»£åæåçå¿
|
||||
ç¶â¼¤å¹
|
||||
ä¸é
|
||||
è¿ä»£å主â½ä»¶â¾æ°è¾¾å°600â¾ï¼åºæ¬ä¸§å¤±â¼â¼¯ä»â¼å¯è½æ§
|
||||
ä»
|
||||
轻微修æ¹ä¸»ä»£ç åç»ä»¶ååæ¸
|
||||
æ°ï¼äººå·¥ä»å
|
||||
¥ææ¬ä½
|
||||
主æ件é»è¾æ¸
|
||||
æ°ï¼è¿ä»£æªä¿®æ¹ä¸»æ件
|
||||
åªä¿®æ¹äºæ¶åç¸å
|
||||
³çåç»ä»¶ï¼åç»ä»¶å
|
||||
¶å®ä¹å¯ä»¥æ´å
|
||||
èï¼è¿é¨åå¯ä»¥è®©AIåè¿è¡äºæ¬¡ä¼åï¼
|
||||
ç±ä¸å¯â»
|
||||
|
||||
æ¸
|
||||
æ°ç prd ä¿è¯åè½ç¬¦åé¢æï¼å¦æ没æé¢å
|
||||
对 AI æ³è¦äº§åºçå
|
||||
容è¿â¾å®¡æ ¸ï¼å¾å®¹æåâ½£å离导è´ç»æä¸åé¢æï¼
|
||||
ä¼è´¨ç代ç æâ¾¼è¿ä»£æçï¼åå§ç代ç 对åç»è¿ä»£çæåçæè¾â¼¤å½±åï¼å¦ææºä»£ç å·²ç»å¨å ç 代ç ï¼åç»è¿ä»£æ¶AIä¹ä¼å»¶ç»è¿ä¸ªâ»æ ¼ï¼å¯¼è´è¿ä»£æåçæ¥éä¸éï¼ä¸ä¸§å¤±â¼â¼¯ä»â¼ä¿®æ¹ä»£ç ç空é´ã
|
||||
â ⼯ç¨ä¸»å¯¼åï¼HOW TO DOï¼
|
||||
è¿â¼åºæ¯ç主è¦å
|
||||
³æ³¨ç¹å¨äºï¼
|
||||
代ç éè¦ä¸¥æ ¼ç¬¦å⼯ç¨è´¨éï¼
|
||||
ç¼åè
|
||||
è¦ä¿ç对代ç ⼤é¨åçææ§åº¦ï¼ä¸äº§åºå
|
||||
容â¼â¼¯å¯ä»â¼åº¦â¾¼ï¼
|
||||
对äºè¿ç±»å¤æ度⾼ / éå«ç¥è¯å¤ç项⽬ï¼æä¹è®© AI å¯ä»¥å / ç¥éåã
|
||||
éæ±èæ¯ä¸å®ç°æ解
|
||||
éæ±å
|
||||
容ï¼
|
||||
éè¦å¨â»â¾¯Feedsä¸æ°å¢â¼çº§ç±»â½¬é
|
||||
ç½®ï¼ä¸ååå¡â½ç¹å»è·³è½¬åæ¢å°è·³è½¬â¾æä¸é´â»ï¼åæ¥æ¯ç´æ¥è·³è½¬åå详æ
|
||||
â»ï¼ï¼å®æè§è§æ´æ°ã
|
||||
å®ç°æ解
|
||||
æå¡ç«¯
|
||||
å端
|
||||
éè¦æ°å¢â¼ä¸ª ald solutionï¼ä¸â½æâ¼çº§ç±»â½¬å¬åâ½æï¼beå¬åæ¶å¢å åæ°ï¼
|
||||
æ°å¢â¼çº§ç±»â½¬é
|
||||
置项并æ´æ¹æ¥â¼åæ°
|
||||
éåfeedsç»ä»¶ï¼åææ§ç»ä»¶ä¸â½æå¤çº§ tabï¼ï¼ä¿®æ¹å¡â½ä¸ tab æ ·å¼
|
||||
ä¿®æ¹å¡â½è·³è½¬é»è¾
|
||||
åç½®ç¥è¯åå¤
|
||||
对äºè¿ç±»ä¸å¡ä»åºï¼éå«ç¥è¯åå
|
||||
¶å¤ï¼è¿äºéå«ç¥è¯æäºæ¥â¾ä¸å¡è¯ä¹ï¼æäºæ¥â¾å
|
||||
é¨å¹³å°çå¼å模å¼ï¼ä¹æâ¼äºæ¥â¾åâ¾å¢éçå®ç°è§èãå¦æ没æåç½®è¾â¼ï¼AI å®å
|
||||
¨â½ä»ä¸â¼¿ï¼æ¤æ¶éè¦æåè¯å«ä¸å¡è¯ä¹ä¸çéå«ç¥è¯ä¸â¼äºå®ç°è§è / â½
|
||||
æ¡ï¼å¹¶å°å
|
||||
¶æ²æ·å°â½æ¡£ï¼è®© AI æ迹å¯å¾ªã
|
||||
⾸å
|
||||
ï¼æ¢³çåºå½åéæ±éè¦å£°æçéå«ç¥è¯
|
||||
ä»ä¹æ¯â¾å»ºçä¸é´â»ï¼ä»ä¹æ¯åå详æ
|
||||
â»ï¼æä¹è¿â¾è·³è½¬ï¼
|
||||
å端ä»åºå
|
||||
æä¹æ°å»ºâ¼ä¸ªsolutionï¼æ没æä»ä¹ç¸å
|
||||
³ç代ç è§èï¼
|
||||
å端ä»åºè¦ä½¿â½¤ä»ä¹â¼¯å
|
||||
·åºï¼â¼äºåºç¡åè½å¦ä½å®ç°ï¼
|
||||
Feedsç»ä»¶åºå¦ä½ä½¿â½¤ï¼é
|
||||
置项æ¯ä»ä¹ï¼æä¹æ´æ¹ï¼
|
||||
以ä¸æ¯æ¢³çåºæ¥çåç½®â½æ¡£ï¼â½æ¡£è¿é¨å建议 AI â½£æé
|
||||
åâ¼â¼¯ä¿®æ¹ï¼å°½éé⽤æ¸è¿å¼æ«é²çååï¼â¼â¼â½æ¡£ä¿¡æ¯å
|
||||
¨â½½ç²¾ï¼å¯¹äºéè¦è¯¦ç»ä»ç»çé¨åï¼å¯ä»¥å¦å¤å建â½æ¡£è¿â¾è¡¥å
|
||||
|
||||
ï¼æ好æ¯æâ¼ä¸ªå©äºç»â¼è¯»åçå°â½
|
||||
è¿â¾åæ¾ï¼åæå·å¯å¨çæ¶åç¼ååç½®â½æ¡£ä¼è±è¾å¤çæ¶é´ï¼ä½æ¯è¿æ¯å¼å¾ï¼ä¸æªæ¥å¿
|
||||
é¡»è¦å®æçäºæ
|
||||
ï¼åæå¤â½¤å°çæ¶åå°±ä¼åç°æé¢å¶â½æ¡£æå¤ç½ï¼ã
|
||||
æå¡ç«¯ç¸å
|
||||
³â½æ¡£
|
||||
å端ç¸å
|
||||
³â½æ¡£
|
||||
ææ¯â½
|
||||
æ¡äº§åº
|
||||
åå¤å¥½ä»¥åå°±å¯ä»¥åºäºç¥è¯é®çå代ç 产åºææ¯â½
|
||||
æ¡ï¼è¿é¨å注æè¿æ¯è¦æä¾å
|
||||
³é®ä¿¡æ¯ï¼å¯¹äº AI éè¦ä»ç¥è¯åºè·åç¥è¯çæ
|
||||
åµï¼æ好æ¯è®©AIååºå
|
||||
¶åèçå
|
||||
·ä½â½æ¡£ï¼é²â½åºç°å离ãç±äºæ¯é代ç è´¨éç项⽬ï¼éè¦â¼â¼¯å®æ对ææ¯â½
|
||||
æ¡çå®æ´å®¡æ¥ä¸ä¿®æ¹ï¼ä¹æ¯å¯¹ä»£ç ææ§åº¦çä¿è¯ï¼æ¯ç«çº¿ä¸ bug ä¸è½è®© AI èé
|
||||
ï¼ã
|
||||
以ä¸æ¯é⽤çææ¯â½
|
||||
æ¡æ¨¡çä¸å®é
|
||||
产åºâ½
|
||||
æ¡ï¼è½ç¶ææ¯â½æ¡£çèµ·æ¥â¾æ°å¾å¤ï¼ä½æ¯å
|
||||
¶å®â¼¤é¨åé½æ¯ä»£ç èéé¨åï¼éå®æ ¼å¼åçææ¯â½æ¡£å
|
||||
¶å®ä¸ä¼å ⽤太å¤ç审æ¥æ¶é´ã
|
||||
å®ç°åé¦å
|
||||
æç
|
||||
§å¦ä¸æ¨¡çè¿è¡ææ¯æ¹æ¡ç¼åï¼ææ¡£çæå°ä»åºdocsç®å½ä¸ï¼æ确认ååè¿è¡å®ç°
|
||||
ææ¯æ¹æ¡æ¨¡çå¼ç¨ææ¡£ - 声æå¼ç¨çç¥è¯åºææ¡£ï¼å¹¶åå
|
||||
¥ä»ç¥è¯åºæ ¹ç®å½çindex.mdè·åçæ¬å·```## å¼ç¨ææ¡£- **ç¥è¯åºçæ¬**ï¼v1.2.3 (ä» index.md è·å)- **ç¸å
|
||||
³ææ¡£**ï¼ - [æ ¸å¿ä¸å¡æµç¨ææ¡£](é¾æ¥) - ç¨äºç解ä¸å¡é»è¾ - [ææ¯æ¶æææ¡£](é¾æ¥) - ç¨äºç¡®å®ææ¯éå - [API è§èææ¡£](é¾æ¥) - ç¨äºæ¥å£è®¾è®¡åè```
|
||||
ç¸å
|
||||
³æ¥å£ - å¦æ åçç¥åè½ç¹æ解 - 讲ç¨æ·çéæ±å解æå
|
||||
·ä½çåè½ç¹å
|
||||
·ä½å®ç°æ¹æ¡ - 大è´å£°æå®ç°æ¹æ¡ï¼å¹¶å¨å
|
||||
³é®é¨ä½é
|
||||
ä¸æ ¸å¿ä»£ç ï¼æè
|
||||
mermAIdæµç¨å¾é®é¢é¢è¦ - åææ´ä½æµç¨ä¸å¯è½ä¼åºç°é®é¢çå°æ¹ï¼å¹¶æä¾åºå¯¹æªæ½ç¸å
|
||||
³åç¹ - å¦æ åçç¥å
|
||||
容补å
|
||||
|
||||
- å¯ä»¥æ ¹æ®éæ±å
|
||||
容èªç±åæ¥ï¼æ é¢å
|
||||
容èªæï¼åä¸äºå
|
||||
容补å
|
||||
|
||||
ï¼ä½æ¯ä»
|
||||
éä¸å°é¨å
|
||||
å¯ä»¥çå°ï¼è¢«åç½®ææ¡£å饱åï¼AIå¾å®æ´å°äºè§£äºèªå·±è¯¥å¹²ä»ä¹ï¼ä¸å®æ´å°ææ¡äºæ·å
|
||||
C端ä¸å¡ä»åºä¸çå¼åæ¹å¼ã
|
||||
å
|
||||
·ä½æ§è¡é¶æ®µ - 解è¦å®ç°
|
||||
å
|
||||
³äºæ§è¡é¨åï¼é»è¾å
|
||||
容åå端å®ç°èµ·æ¥é½å¤§å·®ä¸å·®ï¼è¿é¨åå
|
||||
容æ¹æ¡ç¡®å®ä»¥åAI产åºç代ç åºæ¬é½è½æ»¡è¶³éæ±ï¼è¿åéç¹è®²ä¸C端å端æå
|
||||
³é®çè§è§é¨åã
|
||||
C端 AI ç¼ç ä¸å¥½ç¨çä¸ä¸ªä¸»è¦åå å°±æ¯C端é»è¾ä¸è§è§è¦å度太é«ï¼è AI å天ç缺ä¹å¯¹è§è§å
|
||||
容çæç¥åï¼æ¤æ¶å¦æä¸æ¬¡æ§è®©AIæç»ä»¶çé»è¾ä»£ç åè§è§é½åå®å®¹æ顾æ¤å¤±å½¼ï¼å¯¼è´é®é¢ç´æ¥ä¸åäºä¸ä¸ªå¤æ度ã
|
||||
æ¤æ¶æçæ³ç解æ³ï¼è¿æ¯å°½å¯è½çå°è§è§ä»£ç ä¸é»è¾ä»£ç å离ï¼å
|
||||
让 AI å®æé»è¾ä»£ç é¨åï¼ååç¬éè¿å
|
||||
¶ä»æ¹æ¡å®æè§è§ç»ä»¶çç¼åï¼åä½¿ç¨ AI å°é»è¾ä¸è§è§ç»ä»¶è¿è¡ç»å®ãåºç¡çè§å¾å离æ¯è¾ç®åï¼å°±æ¯é¦å
|
||||
åå®ä¸ä¸ªæ½è±¡ç»ä»¶ï¼å
|
||||
å«äºå±æ§ä¸äºä»¶ï¼ååä¸ä¸ªåªè´è´£ç»å®äºä»¶ä¸å±æ§ç纯è§è§ç»ä»¶ç»åå³å¯ã
|
||||
Bad Case â
|
||||
è§å¾åé»è¾è¦å严éï¼æ¯æ¬¡å¯¹è§å¾çä¿®æ¹é½è¦åæ¶å½±åå°é»è¾å®ç°
|
||||
Good Case â
|
||||
|
||||
è§å¾åé»è¾å®å
|
||||
¨è§£è¦ï¼è§å¾ä¿®æ¹ä¸åå½±åé»è¾ï¼ä¸å¡å±åè§å¾å±åå¯ä»¥å¿«éè¿ç§»å¤ç¨
|
||||
ï¼ä¸ºäºå±ç¤ºæ¸
|
||||
æ°æ以éç¨ä¸¤ä¸ªæ件çå½¢å¼ï¼å®è·µä¸å¯ä»¥å并å°ä¸ä¸ªç»ä»¶ï¼åªè¦ä¿çè¿ä¸ªè§å¾å离ç设计æç»´å³å¯ï¼
|
||||
è§å¾å离è¿æ个好å¤å°±æ¯æ大å°åå°äºå端ç CR ååï¼æ¯å¦ä¸ä¸ªè§å¾å离åçè´ç©è½¦ç»ä»¶ï¼CR æ¶åªéè¦éç¹æ¥ç主é»è¾ index.tsx ç代ç åæ´ï¼å®¡æ¥ååç¬é´å°æ大åã
|
||||
éæè¿ç¨ä¸ï¼ä¹ç»å¸¸ä¼éå°è§å¾åé»è¾ç»å®è¿æ·±ï¼æ æ³å¤ç¨ è§è§/é»è¾ 代ç çæ
|
||||
åµï¼è¿æ¶åä¹å¯ä»¥ç´æ¥è®© AI è¿è¡ä»£ç æ解ï¼äº§åºæ´å 纯粹ç é»è¾/è§è§ç»ä»¶ãæ¯å¦è¿ä¸ªéæ±ä¸çåå¡å
|
||||
å«å¤§éé»è¾ï¼ææ³å®ç°æ°çå¡çæ ·å¼è¿å¾ä»åæ¥ 400 è¡çè§è§ç»ä»¶éæåºæ¥ææé»è¾ä»£ç ï¼ç®ç´æ²¡æ天çãä½æ¯è®©AIå°ç»ä»¶æ¹é æè§å¾å离çç»æåï¼åéè¿D2C产åºæ°çå¡çç»ä»¶ï¼å¨è¿è¡ç¶æä¸äºä»¶çç»å®å³å¯ï¼åç»è¿ä»£ä¹ä¼æ´å æ¸
|
||||
æ°ã
|
||||
åºäºä»¥ä¸æè·¯ï¼è¿å¯ä»¥è¿ä¸æ¥è®¾è®¡è§å¾å离çç»ä»¶åºï¼é¢è®¾ç»ä»¶çäºä»¶ï¼ç±è°ç¨æ¹è¿è¡è§è§ç»ä»¶çå®ç°ï¼å®æäºä»¶çç»å®ï¼åå°æ大åçé»è¾å¤ç¨ãæ¯å¦ï¼æ们ä¸å¡æéè¦å¨ä¸ååºæ¯ä¸å¤ç¨çfeeds模åï¼ä¸ºäºä¿è¯æ大åçé»è¾å¤ç¨ï¼æä»¬å° tab 渲æçé¨å交ç»è°ç¨æ¹ï¼è°ç¨æ¹èªå·±è¿è¡ tab é¨åçè§è§å®ç°ï¼åªè¦ç»å¯¹åºçå
|
||||
ç´ å好äºä»¶ç»å®å³å¯ã
|
||||
åææ²æ·
|
||||
å®æéæ±åï¼å¯ä»¥éæ°æ¢³çæ´ä¸ªæµç¨ä¸çé®é¢ä¸å¯ä»¥å¤ç¨çå
|
||||
容ï¼è¿ä¸æ¥å®æèµäº§æ²æ·ï¼è¿é¨åå
|
||||
容åæççæåè°æ´é½ä¼æ¯è¾è´¹å²ï¼ä½æ¯åºæ¬å 个ä¸åéæ±è®¤çè·ä¸æ¥çæ²æ·ï¼å°±å¯ä»¥è¦çå¾å¤æ¥å¸¸å¼åçå
|
||||
容äºï¼ç¶åå°±å¯ä»¥éæ¥è¿å
|
||||
¥å享å
|
||||
¶æçé¶æ®µãå½æ¥å¸¸å¼ååºæ¯æ举å°80%以åï¼AI ä¼è¶æ¥è¶åæ们延伸åºçåæï¼ä¸æ¯è¡ç¼ä¹±é ï¼èæ¯ææ们èæµ·ä¸ç代ç æ¬è¿å°å®ä»¬åºè¯¥åå¨çå°æ¹ã
|
||||
ç»ä»¶æ²æ·
|
||||
åºäºå·²æçè§å¾å离ç»æï¼ä¸å¡é»è¾ç»ä»¶çå¯å¤ç¨åº¦å·²ç»ä¸ååéäºè§è§ç¨¿ï¼èå¥ç¦»äºä¸å¡é»è¾çè§è§ç´ æï¼ä¹å¯ä»¥å¿«éçåºç¨å°å个项ç®ã
|
||||
ç¥è¯ææ¡£è¿ä»£
|
||||
è½ç¶å¨åç½®åå¤æå·²ç»æåè¿è¡äºç¥è¯ææ¡£ççæï¼ä½æ¯ AI 大æ¦çè¿æ¯ä¼æç解å离çæ
|
||||
åµï¼è¿æ¶åå°±è¦å¯¹å·²æçææ¡£è¿è¡è¡¥å
|
||||
|
||||
说æãæ¯å¦ï¼ææä¾äºå¦ä½å建è¿ä»£çææ¡£åï¼åç° AI è¿æ¯ä¼èªç±åæ¥ï¼å¯¼è´æµç¨æ§è¡é误ãäºæ¯æé对å 类常è§é®é¢è¡¥å
|
||||
|
||||
äºä¸¥æ ¼çº¦æï¼éè¿è¿è¡æ¶çåæ¶ä¿®æ£æ¥ä¿è¯ææ¡£çæææ§ã
|
||||
å·¥ä½æµæ²æ·
|
||||
å®æä¸æ¬¡éæ±ä»¥åï¼æéè¦çå°±æ¯reviewæ´ä¸ªå®ç°æµç¨ï¼è¯å«æ没æ å¯æ åå/éå¤æ§å¼º/æ¶åæä»¶å¤ çå¯æ²æ·æµç¨ï¼æ¯å¦è¿ä¸ªéæ±å°±æå¤ä¸ªå¯ä»¥è½æç®å Skill çå·¥ä½é¡¹ï¼æ åå·¥ä½æµçæ²æ·å¯ä»¥è®© AI è¶æ¥è¶å¯æ§ã
|
||||
å端 ald solution å建ï¼åæ¥ä¿®æ¹ç¸åºæ件ï¼
|
||||
å¨åé¢çåºç¡ä¸ï¼è¿è¡åå端æµç¨ä¸²èï¼å¦ï¼solution -> æ¥å£ææ¡£ -> å端è°ç¨å½æ°çæï¼
|
||||
å端天马é
|
||||
置项çæ°å¢ä¸ç¸åºç读å代ç çæï¼
|
||||
é»è¾ä»£ç çæ -> è°ç¨D2Cå·¥å
|
||||
·çæè§è§ç»ä»¶ -> è¿è¡é»è¾ä¸è§å¾çç»å®ã
|
||||
å¢éä»ç»
|
||||
æ¬æä½è
|
||||
å屿ï¼æ¥èªæ·å¤©éå¢-天ç«æ°åè¥éææ¯å¢éãæ们è´åéè¿å¤§æ°æ®ã人工æºè½æé é¢å
|
||||
çæ°ååæ°åè¥éå¹³å°ï¼æå¡äºå¤©ç«æ°åå
|
||||
¨é¾è·¯å¢é¿ï¼é¢ååçå家æ建ä»æ°åç åãæ°ååµåå°æ°åä¸æ°çâ¼ä½å解å³æ¹æ¡ï¼è´è´£ã天ç«å°é»çã/ã天ç«Uå
|
||||
ã/ãTMICãï¼å¤©ç«æ°ååæ°ä¸å¿ï¼/ãæ·ç³»æ°åè¿è¥å¹³å°ãçæ·ç³»æ ¸å¿çæ°åä¸æ°å®¢ä¸å¡ï¼å¸®å©å家è¿æ¥æ·ç³»ç«å
|
||||
å¤æµéãè¥éèµæºä¸æ°æ®ï¼åè§æ¨¡åæ°åç»è¥ä¸ç¡®å®æ§å¢é¿ã
|
||||
¤ æå±é
|
||||
读 ¤
|
||||
3DXRææ¯ | ç»ç«¯ææ¯ | é³è§é¢ææ¯
|
||||
æå¡ç«¯ææ¯ | ææ¯è´¨é | æ°æ®ç®æ³
|
||||
@@ -1,42 +0,0 @@
|
||||
# 从需求到交付：一套基于 AI 辅助的高质量代码生产实践
|
||||
|
||||
**来源：** [微信公众号 - OLDLIE](https://mp.weixin.qq.com/s/V8AR1ooSgrafZgH6KgEEOw)
|
||||
**作者：** oldlie
|
||||
**日期：** 2026年4月11日 19:32
|
||||
**标签：** #AI编码 #代码质量 #交付流程 #OpenSpec #Superpowers
|
||||
|
||||
---
|
||||
|
||||
## 核心流程
|
||||
|
||||
### 1. 需求分析与关键点识别
|
||||
使用 `openspec explore` 指令向 AI 提出概要需求。核心目的是借助 AI 的信息处理能力，快速识别需求中的关键点、潜在风险和边界条件。
|
||||
|
||||
### 2. 制定分阶段实现路线图
|
||||
利用 `superpower` 技能，要求 AI 将需求转化为清晰、可执行的路线图（Roadmap），将整个项目拆解为多个可管理的阶段。
|
||||
|
||||
### 3. 前置条件确认与详细设计
|
||||
进入每个新阶段前，让 AI 确认所有前置条件是否满足。确认后协作进行详细设计，要求 AI 输出包含后台代码详细设计和关键过程时序图的设计文档，并严格参考既定的代码规范。
|
||||
|
||||
### 4. 设计审查与规范对齐
|
||||
设计文档完成后进行严格审查，确保实现方案完全符合代码规范。**"先设计，后编码"** 的模式让问题在早期被发现和解决，效率远高于在代码写完后再去分散阅读源文件。
|
||||
|
||||
### 5. 代码实现与自动化审查
|
||||
AI 完成代码编写后立即执行 `/review` 指令。`/review` 模式关注的维度（安全性、健壮性）与默认编码模式不同，要求更高，能发现单元测试难以覆盖的逻辑问题。
|
||||
|
||||
此外，AI 有时倾向于使用最简单而非最高效的方式实现功能，或在处理长上下文时出现"偷懒"现象——人工触发的全面审查必不可少。
|
||||
|
||||
### 6. 查漏补缺与迭代循环
|
||||
`/review` 之后让 AI 根据路线图再次检查当前阶段是否存在遗漏，确认无遗漏且满足进入下一阶段的条件后，再开启新一轮循环。
|
||||
|
||||
---
|
||||
|
||||
## 流程设计的深层思考
|
||||
|
||||
| 设计要素 | 价值 |
|
||||
|---------|------|
|
||||
| **路线图** | 将宏大目标拆解为具体步骤，减少单次交互的上下文信息量，确保整体目标不偏离 |
|
||||
| **详细设计文档** | 集中审核设计逻辑比分散阅读代码更高效，更容易发现深层次问题 |
|
||||
| **分步设计** | 管理上下文窗口长度，确保 AI 在每个环节保持高效和精准 |
|
||||
|
||||
**核心理念：** 通过精心设计的步骤、指令和审查机制，引导 AI 成为"结对编程"伙伴，共同交付高质量的代码。
|
||||
@@ -1,80 +0,0 @@
|
||||
---
|
||||
title: 基于 Harness + SDD + 多仓管理模式的 AI 全栈开发实践
|
||||
source: https://mp.weixin.qq.com/s/ygQGSH5c7GHYDvkqWoQTXQ
|
||||
author: 盖伦 / 得物技术
|
||||
date: 2026-05-06
|
||||
tags: [AI开发, 全栈, SDD, Harness, Cursor, Claude Code]
|
||||
---
|
||||
|
||||
# 基于 Harness + SDD + 多仓管理模式的 AI 全栈开发实践｜得物技术
|
||||
|
||||
## 一、核心理念：Harness 思维 — 让 AI 模仿，而不是凭空创造
|
||||
|
||||
### 全栈AI开发最容易踩的坑
|
||||
让AI从零开始写代码产生"外星代码"：风格不一致、复用率低、采纳率低。AI生成了代码，但Review成本和返工成本反而更高了。
|
||||
|
||||
### Harness 思维的核心：给 AI 一个"模仿对象"
|
||||
给AI一个已有的实现作为参照，让它照着复刻一份，而不是凭空创造。
|
||||
|
||||
**四条原则：**
|
||||
|
||||
| 原则 | 说明 | 举例 |
|
||||
|------|------|------|
|
||||
| 找相似实现 | 在代码库中找到功能最相似的已有实现作为参照 | "结束语"参照"场景化欢迎语" |
|
||||
| 复用优先 | 能复用的组件、接口封装、数据结构直接复用 | 复用greetingExtendInfo数据结构 |
|
||||
| 模仿着复制 | "抄一份改一改"比用新方式好 | Controller/Service/Repository按已有模仿 |
|
||||
| 约束生成范围 | 提示词中明确指定参考文件/参考接口 | 前端修改入口@FeatureTable/index.tsx:53-58 |
|
||||
|
||||
### 提示词体现 Harness
|
||||
- ❌ 不推荐：`请实现一个结束语管理的 CRUD 接口`
|
||||
- ✅ 推荐：明确指定参考文件、数据结构和接口路径，如"参照场景欢迎语功能（后端/api/v1/feature/list，前端FeatureTable/index.tsx:53-58）实现"
|
||||
|
||||
## 二、全栈工作区搭建与 Codebase Indexing
|
||||
|
||||
将前后端代码放在同一个工作区下的三个核心价值：
|
||||
1. **Codebase Indexing**：Cursor对工作区内所有代码进行向量化嵌入建立语义索引，AI能跨仓库理解代码关系
|
||||
2. **上下文完整**：AI同时能看到前后端代码，接口字段、命名风格自然对齐
|
||||
3. **SDD文档集中管理**：前后端SDD文档在同一工作区，便于接口契约对齐
|
||||
|
||||
### Cursor vs Claude Code 实测对比
|
||||
|
||||
| 功能维度 | Cursor | Claude Code |
|
||||
|---------|--------|-------------|
|
||||
| 代码库语义索引 | 支持grep+语义检索，速度快 | 仅支持grep，依赖模型能力 |
|
||||
| 代码生成速度 | 极速，平均1-3分钟 | 中速，平均3-30分钟 |
|
||||
| 代码采纳率 | 两者相当 | 两者相当 |
|
||||
| 文件/代码段引用 | 快捷键、拖拽即可引用 | 需手动@文件路径，无法引用代码段 |
|
||||
| 多Agent | 默认开启（多Tab并行） | 需手动注册子Agent |
|
||||
| 费率模型 | 失败任务不收费 | 失败任务耗时长，容易浪费Token |
|
||||
| 历史会话恢复 | 仅能查看当前项目会话记录 | 可查看全局会话记录 |
|
||||
| 综合评价 | 快速迭代首选，推荐Composer2模式 | 长链路复杂任务可用 |
|
||||
|
||||
## 三、SDD 驱动的全栈代码生成流程
|
||||
|
||||
- 全栈SDD需同时覆盖前后端
|
||||
- 提示词编写范式：明确需求、参考实现、数据结构、接口契约
|
||||
- 前后端需求点清单分工示例
|
||||
- SDD文档产出与指令使用说明
|
||||
|
||||
## 四、多 Agent 协作：前后端并行开发
|
||||
|
||||
- Cursor中使用多Tab并行（默认开启）
|
||||
- Claude Code中使用Subagent能力（需手动注册）
|
||||
- 建议：前端Agent专注UI/交互，后端Agent专注API/数据
|
||||
|
||||
## 五、前后端联调：Mock 数据与分阶段验证
|
||||
|
||||
- 三阶段验证策略
|
||||
- Mock数据编写要点
|
||||
- 后端独立构建验证
|
||||
- 前后端联调步骤
|
||||
|
||||
## 六、警惕 SDD 陷阱：测试如何介入全栈研发
|
||||
|
||||
- SDD不等于需求文档
|
||||
- 关注隐性功能（异常处理、边界情况、性能要求）
|
||||
- 测试应尽早介入
|
||||
|
||||
## 七、综合效益与总结
|
||||
|
||||
核心公式：**Harness（约束） + SDD（规格） + 多仓（上下文） = 高质量AI全栈代码**
|
||||
182
InBox/天猫AI编码实践四文对照整理.md
Normal file
182
InBox/天猫AI编码实践四文对照整理.md
Normal file
@@ -0,0 +1,182 @@
|
||||
# 天猫 AI 编码实践四文对照整理
|
||||
|
||||
## 原笔记引用
|
||||
|
||||
- [[天猫新品营销技术团队AI编码实战指南（上）]]
|
||||
- [[天猫新品团队AI编码实战指南（下）]]
|
||||
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]]
|
||||
- [[AI-First产研团队的交付路径]]
|
||||
|
||||
---
|
||||
|
||||
## 一句话结论
|
||||
|
||||
这四篇文章虽然切入点不同，但核心结论高度一致：**AI 编码的上限，不主要取决于模型本身，而取决于团队能否把需求、规范、代码模式、领域知识、任务拆解和验证闭环，组织成 AI 可消费、可复用、可持续更新的工程资产。**
|
||||
|
||||
---
|
||||
|
||||
## 共同点
|
||||
|
||||
### 1. 都在反复强调：问题核心不是 prompt，而是上下文工程
|
||||
|
||||
- [[天猫新品营销技术团队AI编码实战指南（上）]] 强调，AI 写不对、写不好、写不了、改不动，根因大多来自隐性知识、需求模糊、任务复杂、缺少验证和工程结构问题。
|
||||
- [[AI-First产研团队的交付路径]] 进一步把这件事抽象为“初稿准确率”问题，指出模型差异不是主要矛盾，上下文质量才是。
|
||||
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 则把上下文具体化成四层物料：开发规范、代码模式、领域知识、任务规格。
|
||||
|
||||
共同认识是：**AI 不是因为不会写代码才失效，而是因为拿到的上下文不完整、不准确、不可执行。**
|
||||
|
||||
### 2. 都主张“最大化复用”，而不是追求从零生成
|
||||
|
||||
- [[天猫新品营销技术团队AI编码实战指南（上）]] 把“最大化复用”列为核心方法论。
|
||||
- [[天猫新品团队AI编码实战指南（下）]] 从代码复用、知识复用、工作流复用、工具复用、人机分工五个层级展开。
|
||||
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 进一步提出“能抄不写，能连不造，能复用不原创”，本质是让 AI 做胶水而不是原创主体。
|
||||
|
||||
共识非常明确：**团队真正要建设的不是“更强提示词”，而是可复用的物料体系。**
|
||||
|
||||
### 3. 都认为自然语言文档和结构化规格是核心输入接口
|
||||
|
||||
- [[天猫新品营销技术团队AI编码实战指南（上）]] 直接提出“自然语言第一”。
|
||||
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 用 `Task Spec` 承载当前需求意图。
|
||||
- [[AI-First产研团队的交付路径]] 则把 PRD、技术方案、任务拆解都 Skill 化，形成逐级收敛的上下文链路。
|
||||
- [[天猫新品团队AI编码实战指南（下）]] 还提出“视图分离”，把同一份 PRD 分成人读版和 AI 执行版。
|
||||
|
||||
这说明：**文档不是代码的附属物，而是 AI 时代的软件输入层。**
|
||||
|
||||
### 4. 都强调必须有验证闭环，不能把 AI 当黑盒执行器
|
||||
|
||||
- [[天猫新品营销技术团队AI编码实战指南（上）]] 明确要求补上 review、测试、前后端验证。
|
||||
- [[AI-First产研团队的交付路径]] 把 Daily Coding Agent 定义成“编码→单测→CR→修复”的循环。
|
||||
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 的目标不是生成代码，而是提升生产可采纳率。
|
||||
|
||||
共同点是：**衡量标准不是“写出来了”，而是“能否稳定进入交付流程”。**
|
||||
|
||||
### 5. 都在把团队经验沉淀成可版本化资产
|
||||
|
||||
- `AGENTS.md`
|
||||
- `spec.md`
|
||||
- 样板代码
|
||||
- 团队知识库
|
||||
- Skill / 工作流脚本
|
||||
- 上下文回写机制
|
||||
|
||||
四篇文章都在做同一件事：**把本来只存在于熟手脑子里的隐性经验，外化为 AI 能稳定读取的长期资产。**
|
||||
|
||||
---
|
||||
|
||||
## 关键差异
|
||||
|
||||
### 1. 关注层级不同
|
||||
|
||||
- [[天猫新品营销技术团队AI编码实战指南（上）]] 更偏总论，解释为什么 AI 编码会失败，以及团队应如何补足工程基础设施。
|
||||
- [[天猫新品团队AI编码实战指南（下）]] 更偏场景化落地，讨论不同业务严苛度下的人机分工与复用策略。
|
||||
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 更聚焦中后台“胶水需求”的高采纳率打法。
|
||||
- [[AI-First产研团队的交付路径]] 更像组织级方法论，强调交付链路、Skill-as-Code 和上下文持续回写。
|
||||
|
||||
### 2. 对“AI 最适合做什么”的判断重心不同
|
||||
|
||||
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 最鲜明，认为 AI 最适合做“90%抄 + 10%写”的胶水型工作。
|
||||
- [[天猫新品营销技术团队AI编码实战指南（上）]] 认为 AI 适合高复用、低歧义、边界清晰的 80% 工作。
|
||||
- [[天猫新品团队AI编码实战指南（下）]] 则进一步按 C 端、B 端、小二端、工具端区分 AI 的适用边界。
|
||||
- [[AI-First产研团队的交付路径]] 关注点不在某类代码，而在整个交付链是否能把任务收敛到 AI 可执行粒度。
|
||||
|
||||
### 3. 物料结构的表达方式不同
|
||||
|
||||
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 是“四层物料体系”。
|
||||
- [[AI-First产研团队的交付路径]] 是“L0/L1/L2 三层加载 + 六段式交付闭环”。
|
||||
- [[天猫新品团队AI编码实战指南（下）]] 是“代码/知识/工作流/工具/人机分工”五级复用。
|
||||
- [[天猫新品营销技术团队AI编码实战指南（上）]] 则是更通用的工程治理视角。
|
||||
|
||||
虽然结构不同，但都在回答同一个问题：**该给 AI 什么信息、以什么时机给、给到什么粒度。**
|
||||
|
||||
### 4. 适用对象和目标不同
|
||||
|
||||
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 更像“如何提高业务出码采纳率”。
|
||||
- [[AI-First产研团队的交付路径]] 更像“如何让整个产研团队围绕 AI 重组交付方式”。
|
||||
- [[天猫新品团队AI编码实战指南（下）]] 更像“不同业务场景应该怎么设计 AI 工作流”。
|
||||
- [[天猫新品营销技术团队AI编码实战指南（上）]] 更像“AI 编码问题诊断与总策略”。
|
||||
|
||||
---
|
||||
|
||||
## 可以合并出的统一框架
|
||||
|
||||
如果把四篇文章压缩成一套统一模型，大致可以整理成下面这条链路：
|
||||
|
||||
1. **先显式化需求**
|
||||
把模糊业务目标转成结构化需求、边界、验收标准。
|
||||
|
||||
2. **再补齐静态底座**
|
||||
提前准备 `AGENTS.md`、代码规范、样板代码、领域术语表、知识库索引。
|
||||
|
||||
3. **按任务粒度动态加载上下文**
|
||||
不全量塞资料，而是按项目级、文件级、任务级逐层注入。
|
||||
|
||||
4. **优先让 AI 做复用型工作**
|
||||
组件拼装、页面搭建、CRUD、接口对接、样板代码延展、文档生成。
|
||||
|
||||
5. **复杂任务拆黑盒**
|
||||
把大任务拆成边界清晰、可独立验证的小任务，降低“改不动”的概率。
|
||||
|
||||
6. **以验证闭环替代一次生成幻想**
|
||||
编码、单测、CR、修复、回写知识，形成迭代闭环。
|
||||
|
||||
7. **把过程沉淀为下一轮资产**
|
||||
当前需求完成后，不只交代码，还更新 spec、知识库、样板和工作流。
|
||||
|
||||
这条链路本质上就是：**显式化 -> 结构化 -> 复用化 -> 校验化 -> 资产化。**
|
||||
|
||||
---
|
||||
|
||||
## 最值得吸收的几个强观点
|
||||
|
||||
### 1. AI 编码的 ROI 关键指标不是速度，而是“初稿准确率 / 采纳率”
|
||||
|
||||
- [[AI-First产研团队的交付路径]] 强调初稿准确率。
|
||||
- [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 直接用采纳率来证明方法有效。
|
||||
|
||||
这比“生成了多少代码”更接近真实业务价值。
|
||||
|
||||
### 2. 关键规则必须静态在场，不能赌 AI 主动查文档
|
||||
|
||||
这个观点在 [[97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】]] 里特别尖锐：如果规范只放在可检索文档中，AI 可能根本不会主动去看；关键约束应该放进 `AGENTS.md` 或类似的强注入入口。
|
||||
|
||||
### 3. 好的 AI 协作不是减少文档，而是提高文档的执行性
|
||||
|
||||
四篇文章都在证明，AI 时代不是“不写文档”，而是要写**更能驱动执行的文档**：
|
||||
|
||||
- 人看得懂
|
||||
- AI 也能直接消费
|
||||
- 能版本管理
|
||||
- 能逐轮更新
|
||||
|
||||
### 4. AI 更像高效但不稳定的执行者，不是自动化替代品
|
||||
|
||||
这也是四篇文章最一致的现实主义立场：**不要神化模型，要工程化地驯化模型。**
|
||||
|
||||
---
|
||||
|
||||
## 对我自己的可落地启发
|
||||
|
||||
### 适合立即做的事
|
||||
|
||||
- 给常做任务建立固定 spec 模板。
|
||||
- 把仓库中的关键规范上提到 `AGENTS.md` 或固定入口。
|
||||
- 为高频页面/模块准备“样板代码”而不是只写原则。
|
||||
- 把易踩坑知识整理成可检索知识库，而不是散落在聊天记录里。
|
||||
- 每次做完需求后，回写实现经验，让下一次不是从零开始。
|
||||
|
||||
### 需要避免的误区
|
||||
|
||||
- 只优化 prompt，不治理仓库结构。
|
||||
- 把复杂需求整包扔给 AI，不做任务拆分。
|
||||
- 以“生成速度”代替“可采纳质量”。
|
||||
- 希望 AI 从零原创一切，而不是基于现有资产复用。
|
||||
- 做完代码后不回写知识，导致上下文长期失真。
|
||||
|
||||
---
|
||||
|
||||
## 适合作为总纲的理解
|
||||
|
||||
如果只保留一句总纲，可以是：
|
||||
|
||||
> **AI 编码不是“让模型替你开发”，而是“把团队的需求表达、代码模式、知识经验和验证流程，重构成模型可稳定执行的交付系统”。**
|
||||
|
||||
30
InBox/天猫新品营销技术团队AI编码实战指南（上）.md
Normal file
30
InBox/天猫新品营销技术团队AI编码实战指南（上）.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# 《天猫新品营销技术团队AI编码实战指南（上）》
|
||||
|
||||
**来源：** [微信公众号文章](https://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650543356&idx=1&sn=c460ef2f9e36ffbdc1083dd36c2595b6)
|
||||
**本地存档：** `C:\Users\Zane\Desktop\我的\天猫新品营销技术团队AI编码实战指南（上）.html`
|
||||
**作者：** 天猫新品营销技术
|
||||
**标签：** #微信文章 #AI编码 #工程实践 #团队方法论
|
||||
|
||||
## 重新总结
|
||||
|
||||
这篇上篇文章的核心判断是：AI 编码已经能显著提效，但真正的问题不在“模型会不会写代码”，而在“团队能不能把需求、上下文、工程结构和校验流程组织成 AI 可稳定执行的形态”。作者基于天猫新品团队实践，把 AI 编码常见失败归纳为四类：写不对、写不好、写不了、改不动；再把根因拆到项目知识缺失、用户输入模糊、任务复杂度过高、缺少自检闭环、模型和 Agent 能力边界这五个维度。
|
||||
|
||||
文章给出的主线不是追求一次性完美生成，而是通过工程化手段提升“前 80% 的成功率”和“后 20% 的收敛效率”。对应的方法论有三条：最大化复用、自然语言第一、接受二八定律。最大化复用强调把系统拆成可理解、可调用、可组合的模块和工作流，尽量让 AI 做胶水代码而不是重造轮子；自然语言第一强调文档、规范、需求说明和过程记录要先于代码，文档质量直接决定 AI 产出质量；二八定律则提醒团队接受 AI 在 0% 到 80% 阶段很快，但在复杂收尾、边界修复、旧逻辑耦合阶段会明显失速，因此需要人为介入和流程补强。
|
||||
|
||||
在执行层面，文章按完整流程给出优化建议：开发前先准备知识库、AGENTS/README、代码规范、目录边界和可检索上下文；需求阶段把模糊 PRD 转成更明确的功能描述，必要时引入 spec 化文档；任务设计上降低复杂度，把大任务拆成可验收的小黑盒；开发中持续维护过程文档和上下文，避免 AI 因窗口限制失焦；完成后补上 code review、测试、前后端验证等自检环节。作者尤其强调，很多 AI 编码问题本质上不是“提示词技巧”问题，而是仓库结构差、耦合重、文档缺、验证弱导致的工程问题。
|
||||
|
||||
文章最后通过场景分类说明实践差异：一类是“需求驱动型”，重点在让 AI 准确理解业务目标和验收标准；另一类是“工程主导型”，重点在模块边界、复用能力、视图分离、知识沉淀和工作流建设。整体结论很务实：不要把 AI 当成能脱离工程体系独立完成软件开发的黑盒，而应把它纳入团队的文档、规范、测试、知识库和流程体系中，作为一个高效但不稳定的执行者来管理。
|
||||
|
||||
## 核心要点
|
||||
|
||||
- 四大痛点：写不对、写不好、写不了、改不动。
|
||||
- 五类根因：项目隐性知识太多、需求输入不清晰、任务复杂度过高、缺少 review/test 闭环、模型与 Agent 有天然边界。
|
||||
- 三条方法论：最大化复用、自然语言第一、接受二八定律。
|
||||
- 真正的提效点不是“多写 prompt”，而是把需求、文档、知识库、模块边界和测试流程变成 AI 可消费的上下文。
|
||||
- 复杂项目里，AI 更适合完成高复用、低歧义、边界清晰的 80% 工作；剩余 20% 仍需要工程治理和人工兜底。
|
||||
|
||||
## 对我的启发
|
||||
|
||||
- AI 编码的上限，更多取决于仓库可读性、知识显式化程度和验证手段，而不是单次对话技巧。
|
||||
- `AGENTS.md`、README、Spec、CodeWiki 这类文档不是附属物，而是 AI 开发链路里的输入接口。
|
||||
- 如果一个需求总是“改不动”，优先怀疑任务拆分、模块耦合和上下文组织方式，而不是只怪模型笨。
|
||||
@@ -1,13 +0,0 @@
|
||||
# 微信文章（未抓取到内容 - 触发验证码）
|
||||
|
||||
**来源：** [微信公众号文章 (未知公众号)](https://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650543356&idx=1&sn=c460ef2f9e36ffbdc1083dd36c2595b6)
|
||||
**日期：** 2026年（未知具体日期）
|
||||
**标签：** #微信文章
|
||||
|
||||
---
|
||||
|
||||
> ⚠️ 该文章在抓取时触发了微信的 CAPTCHA 验证码保护，未能获取到内容和标题。
|
||||
>
|
||||
> 原始 URL 参数：__biz=MzAxNDEwNjk5OQ==, mid=2650543356, idx=1, sn=c460ef2f9e36ffbdc1083dd36c2595b6
|
||||
>
|
||||
> 建议在微信客户端内手动打开，或使用 WeChat 官方 API 获取。
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
title: 测试笔记 - 共享目录转移
|
||||
date: 2026-03-20
|
||||
tags: [测试, 共享目录]
|
||||
---
|
||||
|
||||
# 测试笔记
|
||||
|
||||
这是一篇测试笔记，用于验证共享目录转移流程。
|
||||
|
||||
## 创建信息
|
||||
- 创建时间: 2026-03-20 03:01
|
||||
- 来源: Mac mini 共享目录
|
||||
- 目标: zanepc Obsidian InBox
|
||||
|
||||
## 测试内容
|
||||
如果这篇笔记能成功转移到 zanepc 的 Obsidian 中，说明流程配置正确。
|
||||
|
||||
---
|
||||
*自动创建用于测试共享目录转移*
|
||||
@@ -1,86 +0,0 @@
|
||||
# 淘天营销中后台生码工作流最佳实践
|
||||
|
||||
**来源：** [微信公众号 - 大淘宝技术](https://mp.weixin.qq.com/s/VjTyHFr17l_bObG6x8-Mmw)
|
||||
**作者：** 营销前台技术团队（大淘宝技术）
|
||||
**日期：** 2026年4月27日 16:16
|
||||
**标签：** #淘天 #营销中后台 #AI生码 #云端托管 #工作流 #大淘宝技术
|
||||
|
||||
---
|
||||
|
||||
## 升级路径总览
|
||||
|
||||
核心决策：从"本地+云端双路径" → **统一收敛至云端托管生码**（基于 AoneSuper）
|
||||
|
||||
**三个核心工程：**
|
||||
1. 跨仓库工作区（git submodule + turborepo）
|
||||
2. 可编排场景化工作流
|
||||
3. 知识自动沉淀（功能树 + 领域 Skill）
|
||||
|
||||
**核心方法论：**
|
||||
- 给恰好够用的精确知识
|
||||
- 确定性逻辑交工程
|
||||
- 知识建正向循环
|
||||
|
||||
---
|
||||
|
||||
## 为什么弃用本地研发
|
||||
|
||||
| 问题 | 具体表现 |
|
||||
|------|---------|
|
||||
| 环境配置难统一 | 系统版本、Node 版本、网络代理差异巨大，排查困难 |
|
||||
| AK 管理困难 | 生态用工需明文存储 AK 在个人设备，分发/轮换/回收无管控 |
|
||||
| 执行易中断 | 电脑息屏/网络断开导致长任务中断，需手动续跑 |
|
||||
|
||||
## 为什么选 AoneSuper 而非自建
|
||||
|
||||
S1 自建了基于 LangGraph 的多 Agent 架构，但发现：
|
||||
- 基建维护成本高
|
||||
- CodeAgent CLI 社区生态（Skills、MCP、SubAgent）迅速成熟
|
||||
- 自建 LangGraph 方案边际收益递减
|
||||
|
||||
**结论：** 接入 AoneSuper，投入重心从基建打磨转向业务效果优化。
|
||||
|
||||
---
|
||||
|
||||
## 跨仓库工作区
|
||||
|
||||
### 设计思路
|
||||
|
||||
1. **聚合需求仓库**：创建"需求工作区"文件夹，聚合所有相关仓库
|
||||
2. **引入 git submodule**：外层文件夹作为独立 git 空间，用于存放 Agent 配置（Skills、MCP、SubAgent）和中间产物（需求理解、方案设计、任务列表等）
|
||||
3. **消除副作用**：通过脚本自动化 submodule 操作，降低同学理解成本
|
||||
|
||||
### 研发调试优化
|
||||
|
||||
利用 **turborepo** 的 monorepo 构建能力，实现：
|
||||
- 一键启动所有需求子仓库服务
|
||||
- 自动配置子仓库间的依赖 link
|
||||
- 解决多层依赖（基础组件 → 业务组件 → 前端业务）的调试问题
|
||||
|
||||
---
|
||||
|
||||
## 可编排场景化工作流
|
||||
|
||||
### 两种场景的差异化策略
|
||||
|
||||
**场景一：迁移/重构（高确定性）**
|
||||
- 已有明确的"A 迁移到 B"的确定性逻辑
|
||||
- 架构说明文档 + 领域 Skill 固化规则
|
||||
- 将迁移/重构的逻辑转化为可复用的领域能力
|
||||
|
||||
**场景二：日常迭代（低确定性）**
|
||||
- 需求边界模糊，需要大量上下文
|
||||
- 引入**功能树**实现精准查表式知识供给
|
||||
- 辅助 D2C（Design-to-Code）/ API 还原优化
|
||||
|
||||
### 功能树
|
||||
|
||||
核心思想：将一个项目的结构化知识（路由、组件、数据流、API）提取为树形索引，Agent 在接到需求时可以快速"查表"定位到代码位置，而不是大海捞针。
|
||||
|
||||
### 知识自动沉淀
|
||||
|
||||
通过持续积累，形成**提效飞轮**：
|
||||
1. 生码过程中发现知识盲区
|
||||
2. 补充功能树 / 领域 Skill
|
||||
3. 下次生码质量提升
|
||||
4. 释放人力持续补充更多知识
|
||||
@@ -5,20 +5,471 @@
|
||||
> 原文：https://mp.weixin.qq.com/s/EdVjZuBVcXjd30TpxyLsXQ
|
||||
> 完整报告下载：关注公众号 **GIS极客**，后台回复 **"清华HarnessEngineering"** 获取下载链接
|
||||
|
||||
---
|
||||
|
||||
## 核心观点
|
||||
|
||||
驾驭工程 (Harness Engineering) 的核心是**围绕高自治、长时程 AI 构建可治理的操作系统层**，将提示词、上下文、智能体等能力制度化为机械可验证的契约、状态恢复与审计体系，从而从 **"让AI听懂"** 升级为 **"让AI系统可信、可控、可持续运行"**。
|
||||
Visual: [[清华大学 驾驭工程 Harness Engineering 研究报告.visual]]
|
||||
|
||||
---
|
||||
|
||||
## 报告概述
|
||||
## 提取说明
|
||||
|
||||
本文为清华大学发布的研究报告，主要内容以图片形式呈现（报告正文截图）。需要阅读完整版请按上述方式获取 PDF。
|
||||
这次按“每张图 = 一个模块”重组。
|
||||
|
||||
报告关注的关键问题：
|
||||
- 高自治 AI 系统的治理与可控性
|
||||
- 长时程 AI 运行的操作系统层设计
|
||||
- 提示词、上下文、智能体的制度化
|
||||
- 机械可验证的契约、状态恢复与审计体系
|
||||
- 图片已下载到 `清华大学 驾驭工程 Harness Engineering 研究报告.hires/`
|
||||
- 每个小节对应一张原图
|
||||
- 小节标题优先按图片主标题人工整理
|
||||
- 正文尽量保留 OCR 全文，只做了轻度空格清洗
|
||||
|
||||
风险：
|
||||
|
||||
- OCR 对英文、链接、少数专有名词和局部排版仍有误识别
|
||||
- 个别页图像里有示意图、图标或多栏布局，转写会比纯段落页更差
|
||||
- 如需完全准确版本，仍应以对应原图为准
|
||||
|
||||
---
|
||||
|
||||
### 驾驭工程（Harness Engineering）研究报告
|
||||
|
||||
页码：`page-01.jpg`
|
||||
|
||||
驾驭工程 (Harness Engineering) 研究报告一下 0 乁《电脑日志面板 Agent 核心判断：驾驭工程是操作系统层提示词工程是语言层智能体工程是工作流层；驾驭工程是操作系统层。对象：高自治、长时程、可治理的 A 係统丨 26 年 26
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-01.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 清新研究团队简介
|
||||
|
||||
页码：`page-02.jpg`
|
||||
|
||||
· 领导学术研究团队近 30 人。指导大数据、 AI 、人形机器人等多个产业团队。冫目视频号： @清新研究；公众号： @清新研究九 | 司月沈阳：清华大学新闻学院 / 人工智能学院双聘教授、博导 · 团队坚持：整体主义、实证主义、社会建构、进步主义。 " 六大研究方向： 。 ？ 1 ． A 吠模型理论与哲学 4 · 新媒体与网络舆论网邮箱： 124739259@q q ℃ om 圈 oo 囗囹 00 囗 2 · AI 文艺回。 ． 回回 ． 回回彗 3 ． A | 应用 6 ． × R 应用丨微博： @ 清新研究 | 公众号： @ 清新研究
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-02.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 全文结构目录
|
||||
|
||||
页码：`page-03.jpg`
|
||||
|
||||
全文结构目录术语状态 ． 从术语状态 ． “ ． ，按“定义一证据一结构一落地”展开。结构 · 四层链条到 ． “ · 它和提示词 / 上下刘智能体工程的边界是什么证据。第一部分回答“ · 。这个词现在是什么落地 · 中国落地路线 ． “ · 按“定义一证据一结构一落地”展开。 @ 清新研究团队 | 2026 年 3 月 2
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-03.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 一句话结论
|
||||
|
||||
页码：`page-04.jpg`
|
||||
|
||||
一句话结论总判断驾驭工程不是把提示词再写长一点，而是把模型周围整个制度化执行环境设计出来 0 怎么让型动起来怎么说清 0 一模型提示词工程 - 智能体工程程制杂“提示词工程解决“怎么说清楚” 0 。智能体工程解决“怎么让模型动起来” 0 @ 淆究团队《 2026 年 3 月 26 日
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-04.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 四层链条：从语言到操作系统
|
||||
|
||||
页码：`page-05.jpg`
|
||||
|
||||
四层链条：从语言到操作系统驾驭工程核心观点提示词工程、上下文工程、智能体工程、骘驭工訴一互斥关系，而曰层上语言层关注指令表达，上下文层关注状态供给 > 上下文层语言层智能体工程关注状态供给关注指令表达 @ 清新研究团队 | 2026 年 3 月 26 日
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-05.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 第一部分：术语状态
|
||||
|
||||
页码：`page-06.jpg`
|
||||
|
||||
第一部分 | 术语状态葳至 2026 ． 03 一 26 、 、 、 、 \ 术语状态冫当前术语体系基本稳定，关键定义待进一步明确。 @ 清新研团队 | 2026 年 3 月 26 日
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-06.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 它不是教科书术语，但已被前沿团队反复使用
|
||||
|
||||
页码：`page-07.jpg`
|
||||
|
||||
它不是教科书术语，但已被前沿团队反复使用术语状态 H4R § S 卪 48 q ： 2026 ． 02m OpenAl 在 2026 ． 02 · 11 明确使用 harness en.. 这说明它已进入一线工程实践话语。早些时候近期、 、 、 、 、 、 、乛工程博客时间轴但它仍在形成中，边界尚未像“数抿库”或“擞。服务”那样冻结。 0 边界仍在探索和定义中。数据库徼服务歡櫷源： https濯0些na靴om／刑e对ha賺翰e哣谳丽g/ ； httpsflwww.anthtopic.com/engineering/effective-harnesses-for-lcng-running-agents ； https//www.arthropic.wm!engineering/harness-design-lcng-running•apps
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-07.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### OpenAI 为什么叫它 Harness Engineering
|
||||
|
||||
页码：`page-08.jpg`
|
||||
|
||||
OpenAI 为什么叫它 Harness Engineering OpenAI 证据五个月后仓库达到约百万行 0 仃人工代码启动 OpenAI Codex 实验场景 HARNESS 估算开发时间 0 ENGINEERING 约为手写的 1 / 10 ． 丿 OpenAI 的核心变化是：工程师的主业不再是手写代码代码库
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-08.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### Anthropic 为什么持续谈 Harness
|
||||
|
||||
页码：`page-09.jpg`
|
||||
|
||||
Anthropic 为什么持续谈 Harness Anthropic 证据一亠一亠 Anthropic 的实践把 harness 从抽象口号压成 2025 · 11 的文章聚焦长时程会话，@@鄱 2026 · 03 的文章把 harness design 推到长时程“祀一数据源： https://mvw anthropic.com/engineering/effective-harnesses-for- long-running-agents ： https://www anthropic.com/engineering/harness-design-long-running-apps
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-09.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 为什么“现在”突然重要
|
||||
|
||||
页码：`page-10.jpg`
|
||||
|
||||
7 回答问丿聊天气泡因为模型已跨过“回答问题”的门槛为什么“现在”突然重要 · OpenAI 己把 agents 定义为能完成从简单目标到开放式完成开放式任务 ． 工作台 · Anthropic 区分 workfl ow 一 agent ． 数据来源： https:!/developers.openai.com/api/docs/guides/agents ； https://www.anthropic.com/engineering/building-effective-agents
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-10.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 瓶颈已经从“生成更多”转向“让人只在高杠杆节点出手”
|
||||
|
||||
页码：`page-11.jpg`
|
||||
|
||||
瓶颈已经从“生成更多”转向“让人只在高杠杆节点出手”瓶颈变化 1 优先级判断节点出手代码吞吐 (Code Throughput) OpenAI 公开写道，随着代码吞吐上升，瓶颈变成了 human QA• 这意味着系统设计的目标不再是“让多做点” 2 · 3 0 LOW SCARCE 人类注意力 (Human Attention) EXECUTIVE SUMMARY HUMAN QA BOTTLENECK 关踺高杠杆节点
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-11.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 中国落地窗口已经形成
|
||||
|
||||
页码：`page-12.jpg`
|
||||
|
||||
中国落地窗口已经形成 10 ％ 介 1408 亿元数字经济体量与增长 2024 年数字经济核心产业增加 11 。 08 亿人川 24 年我国同民換 / ／ ' | 人工智能 + 未来驱动引擎互联网昔及率、网络规模与普及率。中国政策、网络规模与数字经济体量力数源智龍应用础彘施体生膚 0 过 · 2024 年数字经济核心产业增加值 140891 亿元。 2024 年我国网民规模 11 ． 08 亿人，互联网普及率 78 ． 6 ％ 蟲樾睾：卜 ttpc / 艹虱“ / 。伍 2St2n 却 25 旧 0 ． 四 62m htA ；卜 t 丿 / “ “ “ 《 “伍。 ti ' 丿闸。叫 /VS 馴 34 117 四 ． 恒靼刀 - “ ， m “彐“ ' n ／ 於 ． “ 6 / - 加“ ． 3 / 20 理 ms3103 仆。 。 。 / 心 03 02 312 ． n8 ht
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-12.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 第二部分：四层链条
|
||||
|
||||
页码：`page-13.jpg`
|
||||
|
||||
02 第二部分丨四层链条先厘清层级边界，才能避免把所有能力混叫成噁严《四、自主 (Autonomy) 、协作 b “薹础词 @ 清新研究团队丨 2026 年 3 月 26 日
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-13.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 提示词工程：语言层
|
||||
|
||||
页码：`page-14.jpg`
|
||||
|
||||
0 提示词工程：语言层提示词工程定义 · OpenAl 仍把 prompt engineering 定义为 ． 它解决的是“怎么说清楚” · 重点包括角色设定、输出格式、上法、示例组织一臼令优先级指令纸（ SYSTEM PROMPT) 、系统提示 (SYSTEM PROMPT) 色设定 ． 你是一个专业的 A 勵手 ． · 上下给法：基于以下信息“格式约束 (FORMAT CONSTRAINTS) 出格。请使用 Markdowm 指先级：请优先执行， ． 示例组织 EXAM PLES ）示 1 ：用户输入“ ， A | 输出“示例 2 ：丿 0 数据来源： https://developers.openai.com/api/dcxs/guides/prompt-engineering ； https://developers.openai.com/api/docs/guides/prompt-engineering
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-14.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 提示词工程的能力边界
|
||||
|
||||
页码：`page-15.jpg`
|
||||
|
||||
提示词工程的能力边界提示词工程边界（单轮任务） g 单轮生成 0 结构化输出 0 风格一致性和清晰遵循验收（刀当任务是短时、闭环、单步可验收时，提示词工程往往已经够用。很多团队在这里就能拿到很高 ROI ，不需要急着上 Agent0 数扼来源： https://developersopenai.com/api/docs/guides/prompt-engineering ， https://wwwnnthropic.com/engineering/building-effective-agents 复杂长时程任务（挑战与限制）严 2 @ 多步推理与起忆 × ？外部工具交互 × × @ 动态环境适应外部数据错反馈面临长时程、多目标、需持续交互的任务时，单纯提示词工程能力不足，需要引入 Agent 等更复杂系统。
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-15.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### GPT-5.4 之后，提示词重点被推向“契约化”
|
||||
|
||||
页码：`page-16.jpg`
|
||||
|
||||
GPT-5.4 之后，提示词重点被推向“契约化”提示工升 ． OpenAl 最新指导把高杠杆提示尹词变化概括为 output cont•• ． 这说明提示词工程并没有消失，而是在向可执行契约演化。 。提示词不再只是“写得像人”而是开始承担流程控制语义 0 數抿耒源： https://developers.openai.com/api/docs/guides/prompt-guidance/ 0 目标状态孑终止信号 S\JCCESS \ 具体的准确度数完成条件凵逻辑约刺 (Completion Conditions) nput/output protocol, 工具期待 (TOOI Expectations) database and interfaces JSON 」 5 4 function calls with ／ 咿 predefined parameters 输出契约 (Output Contracts) Fixed output format Fixed output format
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-16.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 规划、前导语与过程可见性
|
||||
|
||||
页码：`page-17.jpg`
|
||||
|
||||
PLAN 0 0 计划 MILESTONE 确定目标与步驟规划、前导语与过程可见性工具前导语工具系统区分指息 0 前导语 PREAMBL OpenAl 针对 agentic tasks 强调：对长时或重工具流程 ． preamble 让模型在调用工具前说清意图。工具调用 TOOL CALLS 0 执行操作，与外部系统交互阶段更新 PHASE UPDATES phase 则帮助系统区分中间 commentary 与 fina. 完成 COMPLETE 达到预期鲒果数塘源： https://dwelopers.openaicom/api/docs/guides/prompt-guidance/ ；
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-17.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 隐藏中间层：上下文工程
|
||||
|
||||
页码：`page-18.jpg`
|
||||
|
||||
03 隐藏中间层《上下文工程如果提示词工程管“说什么” ，上下文工程就管“喂什么”管“说什么”提示词工程 @ 清澌研究团队丨 2026 年 3 月 26 日 Context Engineering 管“喂什么” 0 0 、 0 上下文工程
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-18.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 上下文工程：隐形内核
|
||||
|
||||
页码：`page-19.jpg`
|
||||
|
||||
上下文工程：隐形内核上下文工程定义睾 Anthropic 明确把 context engineering 视核心问题不再只是 system p rom pt · 它包括系统指令、工具、外部数据、消息历史、 MCP 、长期状态等。外部数据消息历史上下文状态球体 0 提示 MCP 长期状态数据来源： https://www.anthropic.com/enqineerinq/effective—context—enqineerinq—for-ai-aqents
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-19.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 上下文是关键但有限的资源
|
||||
|
||||
页码：`page-20.jpg`
|
||||
|
||||
上下文是关键但有限的资源上下文有限搋挤 0 0 上下文物理边界上下文窗囗不是抽象参数，而是 Agent 能否保持一致行为的物理边界。 02k / 128k USED 上下文预算占用情况任务本身关键约束 ． ，上下文一旦拥挤，任务本身、关键约束和新证据就会互相争枪注龜力。 。 ` Anthropic: 、 。 。长时代理策略 Anthropic 直接指出：长时代理需要不断展与压上下文。不断策展信息筛选压缩上下文立净内存数据来源： https://www、*
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-20.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 上下文状态由什么组成
|
||||
|
||||
页码：`page-21.jpg`
|
||||
|
||||
上下文状态由什么组成上下文状态组成系统指令定义高优先级规则。孑历史回@ 完整的交互记录。 0 工具决定模型看见哪些动作可能性。摘要精炼的关键信息。 ？乙 ． 外部数据提供世界知识。长期状态持久记忆与个性化。 O 蚴模型入 ． 0 一动作 ／ 响应在多轮代理里，真正进入模型判断的不只是聊天记录。数来源： https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-21.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 为什么上下文会“腐烂”
|
||||
|
||||
页码：`page-22.jpg`
|
||||
|
||||
为什么上下文会“腐烂”么卧上下文腐烂一， vs 、 ． 一上下文腐烂是今明确目新鮮。越长的会话越容易出现辶状态漂移、通漏、过时规则残留和局部模式俣旧指令可能遮蔽新目标。冗长历史会让穫型把局部线索误当全局事实。 。越长的会话越容易出现状态漂移、違、过时规则残留和局聾式课。旧指令可能遮蔽新目标。 。冗长历史会让樓型把局部线索误当全局事实。随着时间推移，上下文质量下降 @ 数握来源： htfps ： //wwwnnthr叩ic.com/engineering/effective-context-engineering-for-ai-agents 乜时“腐对上下
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-22.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 上下文工程是内核，驾驭工程是外壳
|
||||
|
||||
页码：`page-23.jpg`
|
||||
|
||||
上下文工程是内核驾驭工程是外壳飞上下文与 Harness 区别 · 我的判断是： context engineering 管“喂给模型什么” · 前者解决状态供绐。 · 后者解决状态之外的契约、权限、回滚、审计和熵控内核与操作系统外壳的分层图外郜交互与訾控外壳驾驭工契约与奴限外部交互与管筏回与版本控制、数与状态流向模型 ／ 管蛤摟型什么”解决状共蛤《 0 》审计与监 \ 崆制与隐足性内核 (Core) ：上下文工程 (Context Engineering) 知 2026 年 3 月 26 日
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-23.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 第三部分：智能体工程过渡
|
||||
|
||||
页码：`page-24.jpg`
|
||||
|
||||
第三部分刂智倻工智能体工程过渡当模型开始带工具、多轮行动并动态选择路径，问题就从“ " 变成“工作流 " 任分稱 0 划，皿、丿司动态选径工作流 @ 清新研究团队丨 2026 年 3 月 26 日
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-24.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 智能体工程：工作流
|
||||
|
||||
页码：`page-25.jpg`
|
||||
|
||||
智能体工程 0 工作流智能体工程定义工作流画布一， Guardrails 安全护栏记忆 / 知识。 OpenAI 把 agents 定义为能从简单目标走到复杂开放式工作流“ · 智能体工程的关注点是让模型动起来。其核心对象包括模型、工具、记忆 / 知识、 guardrails 、控制流“控制流数据源： https://developers.openai.com/api!docs/guides/agents
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-25.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### Anthropic：Workflow 与 Agent 不是一回事
|
||||
|
||||
页码：`page-26.jpg`
|
||||
|
||||
Anthropic: Workflow 与 Agent 不是一回事 workflow vs agent Workflow （预定义代码路径） Anthropic 的区分非常关键： workflow 走预定义代码路径 ' 前者更可预测。定性流程图 (Deterministic Flowchart) Sturt Step 1 0 1 ） dition Step 2 2 ） No Step 3 （步 0 3 ） End （ ）数据来源： Agent （动态决策路径）后者更灵活，也更难验证和治理。 Decision? Environment 惭境）动态决路径 (Dynamic Decision path) https://www anthropic.com/enginæring/building-effective-agents
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-26.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### OpenAI Agent 架构的六个要件
|
||||
|
||||
页码：`page-27.jpg`
|
||||
|
||||
OpenAI Agent 架构的六个要件 Agent 架构 Agent 不是只有模型这说明 agent eng i neering 已经是一套系统工程。单个模型再强，也需要被放进工作流与保护层。模型 LLM/Core APIs/Functions 0 ） guardrails Safet /Poli 知识 Memo /Retrieval 逻辑 Reasonin Plcnni 评测 Evaluation/Testing 数据来源： https://developers.openai.com/api/docs/guides/agents
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-27.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 工具不是 API 包装，而是给 Agent 的动作契约
|
||||
|
||||
页码：`page-28.jpg`
|
||||
|
||||
》 ／ 侄具不是 API 包装，而是给 Agent 的动作契约工具设计工具面板 / ' · Anthropic 反复强调 ． 动作契约 0 ， 0 ' ； 00@夢 0 工具需要被当成“给非确 0 - AgenV (Action Contract) 0 丰富信返回上下文理纭采 (Return Context) Token 效率优化输入输出，节省成本工具描述准确指引，明确能力定性代理看的软件契纟勺 " 来设计。 · 名字空间、返回上下文、 token 效率与工具描述都会影响表现。亻囫 0 数源 ． https://www.anthropicxom/engineering/writing-tools-for-agents@
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-28.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 为什么工具层开始从“直接调用”转向“写代码调用”
|
||||
|
||||
页码：`page-29.jpg`
|
||||
|
||||
为什么工具层开始从“直接调用”转向“写代码调用” MCP 与代码执行 0 ． Anthropic 在 MCP 文章中指出，直接工具调用会消耗上下文； 。 Agent 可以通过代码把复杂任务分解为更经济的执行路径。 0 工具定义 0 更强代理代码执行 MCP (Model Context ProtocoI) 核心价值艹厂囗囗囗复杂任务分解精确检索与执行数扌居 ． 源： https ： //www anthropic.com/engineering/code-execution-with-mcp
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-29.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 没有 eval 的 Agent，只是会行动的黑箱
|
||||
|
||||
页码：`page-30.jpg`
|
||||
|
||||
没有 eval 的 Agent, 只是会行动的黑箱评测回路 | 身 Anthropic 在 eval 文章中强调匚 / 单轮。 “吧不足以覆盖长时代囗囗理 grader 生产监控、自动评测、 B 、人工审阅要形成多层防线。任务一反馈。代理 0 数来： https:hwww.anthropic.com/engineering/demystifying-evals-for-a卜agents 、一二《 《 《 《一一
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-30.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 第四部分：制度层
|
||||
|
||||
页码：`page-31.jpg`
|
||||
|
||||
4 制度层当提示、上下文、工作流都不够解释问题时，剩下的就是制度层。 @ 清新研究团队丨 2026 年 3 月 26 日
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-31.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 驾驭工程的严格定义
|
||||
|
||||
页码：`page-32.jpg`
|
||||
|
||||
驾驭工程的严格定义契约工具验证严格定义标契约高自治 AI 模犁记忆安全舒围绕高自治 AI 构建整套可持续执行环境一目标契约了@ ， ， ． 一一， 。目标不是让模型“会做事” 。它是系统级环境设计，而不是单点技巧集合。 x 、一一，一一 ． 一一一一二一一一一一一 ． 一 @清新研究团队 | 2026 年 3 月 26 日
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-32.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 为什么我把它定义为“操作系统层”
|
||||
|
||||
页码：`page-33.jpg`
|
||||
|
||||
为什么我把它定义为“操作系统层” 0 为什么是 OS 层 Agenth 统架构户愉入只是输入接囗操作系统分层图： Agent 世界对照因为它不只决定一次输出，而是决定任务如何被启动语言层只是输人接口。工作流层只是动作编排。工作流排作盈引操作系统层（ OS 层）核心：决宸任芳如何被启动只是动作苤悱因为它不只决定一次輸出任务划权督理状记亿存实时监窪 A nt 执行与环境传操作系 OS 用户应用层 Shell/APlä 核 (OSE) 文件系統 / 调度件夤膊层 Agent 世界 OS 用户指令 / 应用 - 语盲 / 工作流口 OS 层 (Agent OS) 任身观划与拽行能力与衩记亿与状态訾理行力监与安全执环境与工具 @ 新研壳团队 | 2026 年 3 月 26 日
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-33.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 它不是替代提示词工程，而是对它的上卷
|
||||
|
||||
页码：`page-34.jpg`
|
||||
|
||||
它不是替代提示词工程，而是对它的上卷，不是替代关和而是对它的上卷驾驭工程 Age nt Prompt ． ResuIt 〕 Context Prompt · 因此 "prom 死”这种说法并不成立。 ． 真正的变化曰 rompt 不再是全部，驾驭工程把 prompt 、 context 、 agent 而刂度层中的一个部亻。全部吸纳进去清新研究团队丨 2026 年 3 月 26 日
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-34.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 六个负重部件总览
|
||||
|
||||
页码：`page-35.jpg`
|
||||
|
||||
六个负重部件六大负重部件总览本报告把驾驭工程拆成六个必须被工程化的负重部件。 1 ． 机器可验证的完成契约 CONTRACT g-O · 机器可验证的完成契约。 4 ． [Component 4 Name] · [Brief description Of component 4 ] 2 ． DurabIe KnowIedge 的 System of Record 0 REC · durable knowledge 的 system Of rec•• 5 ． CComponent 5 Name] · [Brief description Of component 5 〕 @ 清新研究团队丨 2026 年 3 月 26 日 3 、 [Component 3 Name] 0 · [Brief description Of component 3 ] 6 ． [Component 6 Name] · [Brief description Of component 6 〕
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-35.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 部件一：完成定义必须可机器验证
|
||||
|
||||
页码：`page-36.jpg`
|
||||
|
||||
部件一：完成定义必须可机器验证 0 完陇契约清单 .Com letion Contract Checklist) 团队原创定义 0@ 1 ． 输出格 (Output Format) 一预定数据结掏与相式范 2 ． 工具使用仃 00 | Usage) 一指定工具调用与交互流程 3 ． 停止条件 (Stopping Conditions) 一明确终止触发与边界倩况 4 ． 验收方法 (Acceptance Methods) 一自动化测试与正准则 〕 SON ERROR 。 OpenAl 的提示指导和 Codex 实践都把 "what done 灬不是漂亮回答，而是可验证完成。 -p ，拳一孑 ． Done ” 0 。契约里应包含输出格式、工具使用、停止条件和验收方法。数据来溽： https://develogærs.openai.com/api/docs/guides/prompt-guidance/ ； https://openai.com/index/harness-engineering/
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-36.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 部件二：知识必须成为 system of record
|
||||
|
||||
页码：`page-37.jpg`
|
||||
|
||||
部件二一个巨大的 AGENTS.md 团队原创定义知识必须成为 s stem of record 仓库 GoogIe DOCS 对 Agent 来说，不在仓库里的 Google Docs 部件二知识必须可发现知识必须可验证知识必须可维护数源： https：//openai.com/index/harness-engineering/； https://www.anthropic.com/engineering/effective-context-engineerirg-for-ai-agents
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-37.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 部件三：必须给 Agent 真正的感官和手脚
|
||||
|
||||
页码：`page-38.jpg`
|
||||
|
||||
团队原创定义部件三：必须给 Agent 真正的感官和手脚 0 t 亠 00 囗 UI （浏览器）指标 (Metrics & Traces) Agent 日志 (Log) 终端 (Terminal & 测试） · 0penAI 给 Codex 接了 UI 、日志、指标和 traces ； · 只有能读 UI 、看日志、跑测试，代理才有资格自证完成。 · 仅靠读代码和口头声明，很难发现真实 bugo X @？ https://www.anthropic.com/engineering/harness-design-long-running•apps
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-38.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 部件四：必须解决长时程失忆
|
||||
|
||||
页码：`page-39.jpg`
|
||||
|
||||
部件 ． 四！ ；必须解决长时程失忆《部件可长时任务不能只靠大上下文硬扛。 0 0 @进葭文件 git feature 团队原创定义关键是让状态可恢复、可交接、可继续。 Anthropic 的 [ 0n9 一 running harness 用长时任务不能只靠 0 大上下文硬扛。 0-0 0 关键是让状态可恢复、可交接、可继续。数提来源： https：//www.anthropic.com/engineering/effective-harnesses-for-long-running-cgents ； https://wwwnnthropic.com/engineering/harness-design-long-nmning-apps 一 ． 一一 ． ． 一一一一一一 = 二二一
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-39.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 部件五：验证必须外置成回路
|
||||
|
||||
页码：`page-40.jpg`
|
||||
|
||||
Generator 、部件五：验证必须外置成回路部件五外部 evaluator 0 负责不相信主 agento 丶夕团以原创定义 valuator 'Playwrigh@P ． 加黿怙@ 冶同式 d 数据来源 ． p § ； ／ 凹山四些国在四！些 gg / 《 ；匹， https://www.anthropic.com/engineering/demystifying-evals-for-ai-aqents
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-40.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 部件六：边界、沙箱与熵控制必须机械化
|
||||
|
||||
页码：`page-41.jpg`
|
||||
|
||||
部件六：边界、沙箱与熵控制必须机械化部件八 lnput C0de & Data 0 沙箱 lint 彡风格 (Style) 风格、架构和安全不能只存在于人腌审美里。要把 taste 、 risk 和架构 governance 写进 lin••• (Architecture) 一安全 (Security) 〔 taste - risk governance Approved 团队原创定义 90 / 100 质量分 OpenAI 用 lint 回收站数来源： https://openai.com/index/harness-engineering/; https://www.anthropic.com/engineering(claud&éödé-sandboxing
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-41.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 驾驭工程最深一层是注意力工程
|
||||
|
||||
页码：`page-42.jpg`
|
||||
|
||||
驾驭工程最深一层是注意力工程 0 0 0 HUMAN TIME & ATTENTION 訓亠 0 正稀缺资 ' 0 HIGH AI CAPABILITY 匡 00 驾驭工程的真正目标不是把 AI 变得更像人。低价值环节可井行妊务自动纠针刈 M 姓 0 VALUE CREATION 目标 0 0 0 一 0 OpenAl 明确说，真正稀缺趵是 human time and at 人类注意力漏斗 0 而是把人从低价值、可并行、可自动纠错环节中抽离》始意力创造性工作； ' 战略决策核心价值创造自动化过滤 & AI 辅助鼓据来源： ht:ps://openücom/index/harness engineering/
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-42.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 人的角色发生了什么变化
|
||||
|
||||
页码：`page-43.jpg`
|
||||
|
||||
人的角色发生了什么变化角色变化 BEFORE: 表达者 ()x resser) " “ 0 、 〔@》乸》 。在提示词工程里， e 四 ee 疗四人主要是表达者；提示词工程。人的工作抽象层上模糊目标伊 Goal) Focus cra 厑 9 ／ 叩 u 区 specific outputs. 又@ 清新研究团队 AFTER: 设计者 & 抽象层上移。要把模糊目标翻译成 acceptance criteria; · 人的工作重点转向系统设计与评估。 = ． acceptance criteria （验收标准） Focus 虎 9 system behavior and 諂毹 e 忉 e 忉 ． 2026 年 3 月 26 日
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-43.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### 驾驭工程真正要求的是组织能力，不只是模型能力
|
||||
|
||||
页码：`page-44.jpg`
|
||||
|
||||
驾驭工程真正要求的是组织能力，不只是模型能力组织能力真正稀缺的，不再是会不会写 prompt ，而是能不能把人类判断制度化产品（ Product) · 需求 & 定义蚴。价值发现实台理 (Governance) 0 。合规 & 风险组织能力协同引擎工程 (Engineering) 蛉。构建 & 实施。技术卓越 0 运营 (Operations) | ． · 维护 & 优化 · 持续改进 t · 标准制定。组织需要产品、工程、治理、运营协同。 · 单点高手可以做 demo ，系统化团队才能做长期稳定生产。 @ 清新研究团队 ] 2026 年 3 月 26 日
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-44.jpg]]
|
||||
|
||||
---
|
||||
|
||||
### GIS 极客尾图
|
||||
|
||||
页码：`page-45.png`
|
||||
|
||||
GIS
|
||||
|
||||
![[清华大学 驾驭工程 Harness Engineering 研究报告.hires/page-45.png]]
|
||||
|
||||
48197
InBox/清华大学：驾驭工程 (Harness Engineering) 研究报告（附完整报告下载） 1.html
Normal file
48197
InBox/清华大学：驾驭工程 (Harness Engineering) 研究报告（附完整报告下载） 1.html
Normal file
File diff suppressed because one or more lines are too long
@@ -1,12 +0,0 @@
|
||||
---
|
||||
source: 知乎专栏
|
||||
url: https://zhuanlan.zhihu.com/p/2033520572144030920
|
||||
date_saved: 2026-05-02
|
||||
tags: [zhihu, inbox]
|
||||
---
|
||||
|
||||
# 知乎专栏文章：p/2033520572144030920
|
||||
|
||||
**链接：** [https://zhuanlan.zhihu.com/p/2033520572144030920](https://zhuanlan.zhihu.com/p/2033520572144030920?utm_psn=2033977981434114693)
|
||||
|
||||
> 待阅读。文章内容因知乎反爬保护未能自动抓取，请手动打开链接查看。
|
||||
Reference in New Issue
Block a user