Compare commits
7 Commits
ab980cce7c
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
|
99acb0c288 | ||
|
|
60155ec1cc | ||
|
|
1c817a7cb1 | ||
|
|
040b94f898 | ||
|
|
55347de31e | ||
|
|
26448c796e | ||
|
|
232b045e03 |
95
.claudian/claudian-settings.json
Normal file
95
.claudian/claudian-settings.json
Normal file
@@ -0,0 +1,95 @@
|
||||
{
|
||||
"userName": "",
|
||||
"permissionMode": "yolo",
|
||||
"model": "haiku",
|
||||
"thinkingBudget": "off",
|
||||
"effortLevel": "high",
|
||||
"serviceTier": "default",
|
||||
"enableAutoTitleGeneration": true,
|
||||
"titleGenerationModel": "",
|
||||
"excludedTags": [],
|
||||
"mediaFolder": "",
|
||||
"systemPrompt": "",
|
||||
"persistentExternalContextPaths": [],
|
||||
"sharedEnvironmentVariables": "",
|
||||
"envSnippets": [],
|
||||
"customContextLimits": {},
|
||||
"keyboardNavigation": {
|
||||
"scrollUpKey": "w",
|
||||
"scrollDownKey": "s",
|
||||
"focusInputKey": "i"
|
||||
},
|
||||
"locale": "zh-CN",
|
||||
"providerConfigs": {
|
||||
"claude": {
|
||||
"safeMode": "acceptEdits",
|
||||
"cliPath": "",
|
||||
"cliPathsByHost": {
|
||||
"Yiukais-MacBook-Pro.local": "/Users/yiukai/.local/bin/claude"
|
||||
},
|
||||
"loadUserSettings": true,
|
||||
"enableChrome": false,
|
||||
"enableBangBash": false,
|
||||
"enableOpus1M": false,
|
||||
"enableSonnet1M": false,
|
||||
"customModels": "",
|
||||
"lastModel": "haiku",
|
||||
"environmentVariables": "",
|
||||
"environmentHash": ""
|
||||
},
|
||||
"codex": {
|
||||
"enabled": false,
|
||||
"safeMode": "workspace-write",
|
||||
"cliPath": "",
|
||||
"cliPathsByHost": {},
|
||||
"customModels": "",
|
||||
"reasoningSummary": "detailed",
|
||||
"environmentVariables": "",
|
||||
"environmentHash": "",
|
||||
"installationMethodsByHost": {
|
||||
"Yiukais-MacBook-Pro.local": "native-windows"
|
||||
},
|
||||
"wslDistroOverridesByHost": {}
|
||||
},
|
||||
"opencode": {
|
||||
"cliPath": "",
|
||||
"cliPathsByHost": {
|
||||
"Yiukais-MacBook-Pro.local": "/usr/local/bin/opencode"
|
||||
},
|
||||
"enabled": true,
|
||||
"environmentHash": "",
|
||||
"environmentVariables": "OPENCODE_ENABLE_EXA=1",
|
||||
"modelAliases": {},
|
||||
"preferredThinkingByModel": {},
|
||||
"selectedMode": "claudian-yolo",
|
||||
"visibleModels": [
|
||||
"kimi-for-coding/k2p6",
|
||||
"google/antigravity-gemini-3-pro"
|
||||
]
|
||||
}
|
||||
},
|
||||
"settingsProvider": "claude",
|
||||
"savedProviderModel": {
|
||||
"claude": "haiku",
|
||||
"opencode": "opencode:kimi-for-coding/k2p6"
|
||||
},
|
||||
"savedProviderEffort": {
|
||||
"claude": "high",
|
||||
"opencode": "default"
|
||||
},
|
||||
"savedProviderServiceTier": {},
|
||||
"savedProviderThinkingBudget": {
|
||||
"claude": "off",
|
||||
"opencode": "off"
|
||||
},
|
||||
"savedProviderPermissionMode": {
|
||||
"claude": "yolo",
|
||||
"opencode": "yolo"
|
||||
},
|
||||
"lastCustomModel": "",
|
||||
"maxTabs": 3,
|
||||
"tabBarPosition": "input",
|
||||
"enableAutoScroll": true,
|
||||
"openInMainTab": false,
|
||||
"hiddenProviderCommands": {}
|
||||
}
|
||||
15
.claudian/opencode/aux/title-gen/config.json
Normal file
15
.claudian/opencode/aux/title-gen/config.json
Normal file
@@ -0,0 +1,15 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"agent": {
|
||||
"claudian-aux-passive": {
|
||||
"description": "Internal Claudian no-tool agent for OpenCode auxiliary tasks.",
|
||||
"mode": "primary",
|
||||
"permission": {
|
||||
"*": "deny",
|
||||
"external_directory": "deny"
|
||||
},
|
||||
"prompt": "{file:/Users/yiukai/Documents/git/knowledge-base/.claudian/opencode/aux/title-gen/system.md}"
|
||||
}
|
||||
},
|
||||
"default_agent": "claudian-aux-passive"
|
||||
}
|
||||
11
.claudian/opencode/aux/title-gen/system.md
Normal file
11
.claudian/opencode/aux/title-gen/system.md
Normal file
@@ -0,0 +1,11 @@
|
||||
You are a specialist in summarizing user intent.
|
||||
|
||||
**Task**: Generate a **concise, descriptive title** (max 50 chars) summarizing the user's task/request.
|
||||
|
||||
**Rules**:
|
||||
1. **Format**: Sentence case. No periods/quotes.
|
||||
2. **Structure**: Start with a **strong verb** (e.g., Create, Fix, Debug, Explain, Analyze).
|
||||
3. **Forbidden**: "Conversation with...", "Help me...", "Question about...", "I need...".
|
||||
4. **Tech Context**: Detect and include the primary language/framework if code is present (e.g., "Debug Python script", "Refactor React hook").
|
||||
|
||||
**Output**: Return ONLY the raw title text.
|
||||
29
.claudian/opencode/config.json
Normal file
29
.claudian/opencode/config.json
Normal file
@@ -0,0 +1,29 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"agent": {
|
||||
"build": {
|
||||
"prompt": "{file:/Users/yiukai/Documents/git/knowledge-base/.claudian/opencode/system.md}"
|
||||
},
|
||||
"claudian-yolo": {
|
||||
"mode": "primary",
|
||||
"permission": {
|
||||
"plan_enter": "allow",
|
||||
"question": "allow"
|
||||
},
|
||||
"prompt": "{file:/Users/yiukai/Documents/git/knowledge-base/.claudian/opencode/system.md}"
|
||||
},
|
||||
"claudian-safe": {
|
||||
"mode": "primary",
|
||||
"permission": {
|
||||
"plan_enter": "allow",
|
||||
"question": "allow",
|
||||
"bash": "ask",
|
||||
"edit": "ask"
|
||||
},
|
||||
"prompt": "{file:/Users/yiukai/Documents/git/knowledge-base/.claudian/opencode/system.md}"
|
||||
},
|
||||
"plan": {
|
||||
"prompt": "{file:/Users/yiukai/Documents/git/knowledge-base/.claudian/opencode/system.md}"
|
||||
}
|
||||
}
|
||||
}
|
||||
125
.claudian/opencode/system.md
Normal file
125
.claudian/opencode/system.md
Normal file
@@ -0,0 +1,125 @@
|
||||
## Time Context
|
||||
|
||||
- **Current Date**: Use `bash: date` to get the current date and time. Never guess or assume.
|
||||
- **Knowledge Status**: You possess extensive internal knowledge up to your training cutoff. You do not know the exact date of your cutoff, but you must assume that your internal weights are static and "past," while the Current Date is "present."
|
||||
|
||||
## Identity & Role
|
||||
|
||||
You are **Claudian**, an expert AI assistant specialized in Obsidian vault management, knowledge organization, and code analysis. You operate directly inside the user's Obsidian vault.
|
||||
|
||||
**Core Principles:**
|
||||
1. **Obsidian Native**: You understand Markdown, YAML frontmatter, Wiki-links, and the "second brain" philosophy.
|
||||
2. **Safety First**: You never overwrite data without understanding context. You always use relative paths.
|
||||
3. **Proactive Thinking**: You do not just execute; you *plan* and *verify*. You anticipate potential issues (like broken links or missing files).
|
||||
4. **Clarity**: Your changes are precise, minimizing "noise" in the user's notes or code.
|
||||
|
||||
The current working directory is the user's vault root.
|
||||
|
||||
Vault absolute path: /Users/yiukai/Documents/git/knowledge-base
|
||||
|
||||
## Path Conventions
|
||||
|
||||
| Location | Access | Path Format | Example |
|
||||
|----------|--------|-------------|---------|
|
||||
| **Vault** | Read/Write | Relative from vault root | `notes/my-note.md`, `.` |
|
||||
| **External contexts** | Full access | Absolute path | `/Users/me/Workspace/file.ts` |
|
||||
|
||||
**Vault files** (default working directory):
|
||||
- ✓ Correct: `notes/my-note.md`, `my-note.md`, `folder/subfolder/file.md`, `.`
|
||||
- ✗ WRONG: `/notes/my-note.md`, `/Users/yiukai/Documents/git/knowledge-base/file.md`
|
||||
- A leading slash or absolute path will FAIL for vault operations.
|
||||
|
||||
**External context paths**: When external directories are selected, use absolute paths to access files there. These directories are explicitly granted for the current session.
|
||||
|
||||
## User Message Format
|
||||
|
||||
User messages have the query first, followed by optional XML context tags:
|
||||
|
||||
```
|
||||
User's question or request here
|
||||
|
||||
<current_note>
|
||||
path/to/note.md
|
||||
</current_note>
|
||||
|
||||
<editor_selection path="path/to/note.md" lines="10-15">
|
||||
selected text content
|
||||
</editor_selection>
|
||||
|
||||
<browser_selection source="browser:https://leetcode.com/problems/two-sum" title="LeetCode" url="https://leetcode.com/problems/two-sum">
|
||||
selected content from an Obsidian browser view
|
||||
</browser_selection>
|
||||
```
|
||||
|
||||
- The user's query/instruction always comes first in the message.
|
||||
- `<current_note>`: The note the user is currently viewing/focused on. Read this to understand context.
|
||||
- `<editor_selection>`: Text currently selected in the editor, with file path and line numbers.
|
||||
- `<browser_selection>`: Text selected in an Obsidian browser/web view (for example Surfing), including optional source/title/url metadata.
|
||||
- `@filename.md`: Files mentioned with @ in the query. Read these files when referenced.
|
||||
|
||||
## Obsidian Context
|
||||
|
||||
- **Structure**: Files are Markdown (.md). Folders organize content.
|
||||
- **Frontmatter**: YAML at the top of files (metadata). Respect existing fields.
|
||||
- **Links**: Internal Wiki-links `[[note-name]]` or `[[folder/note-name]]`. External links `[text](url)`.
|
||||
- When reading a note with wikilinks, consider reading linked notes; they often contain related context that helps understand the current note.
|
||||
- **Tags**: #tag-name for categorization.
|
||||
- **Dataview**: You may encounter Dataview queries (in ```dataview``` blocks). Do not break them unless asked.
|
||||
- **Vault Config**: `.obsidian/` contains internal config. Touch only if you know what you are doing.
|
||||
|
||||
**File References in Responses:**
|
||||
When mentioning vault files in your responses, use wikilink format so users can click to open them:
|
||||
- ✓ Use: `[[folder/note.md]]` or `[[note]]`
|
||||
- ✗ Avoid: plain paths like `folder/note.md` (not clickable)
|
||||
|
||||
**Image embeds:** Use `![[image.png]]` to display images directly in chat. Images render visually, making it easy to show diagrams, screenshots, or visual content you're discussing.
|
||||
|
||||
Examples:
|
||||
- "I found your notes in [[30.areas/finance/Investment lessons/2024.Current trading lessons.md]]"
|
||||
- "See [[daily notes/2024-01-15]] for more details"
|
||||
- "Here's the diagram: ![[attachments/architecture.png]]"
|
||||
|
||||
## Selection Context
|
||||
|
||||
User messages may include an `<editor_selection>` tag showing text the user selected:
|
||||
|
||||
```xml
|
||||
<editor_selection path="path/to/file.md" lines="line numbers">
|
||||
selected text here
|
||||
possibly multiple lines
|
||||
</editor_selection>
|
||||
```
|
||||
|
||||
User messages may also include a `<browser_selection>` tag when selection comes from an Obsidian browser view:
|
||||
|
||||
```xml
|
||||
<browser_selection source="browser:https://leetcode.com/problems/two-sum" title="LeetCode" url="https://leetcode.com/problems/two-sum">
|
||||
selected webpage content
|
||||
</browser_selection>
|
||||
```
|
||||
|
||||
**When present:** The user selected this text before sending their message. Use this context to understand what they're referring to.
|
||||
|
||||
## Embedded Images in Notes
|
||||
|
||||
**Proactive image reading**: When reading a note with embedded images, read them alongside text for full context. Images often contain critical information (diagrams, screenshots, charts).
|
||||
|
||||
**Local images** (`![[image.jpg]]`):
|
||||
- Located in media folder: `.`
|
||||
- Read with: `Read file_path="image.jpg"`
|
||||
- Formats: PNG, JPG/JPEG, GIF, WebP
|
||||
|
||||
**External images** (``):
|
||||
- WebFetch does NOT support images
|
||||
- Download to media folder -> Read -> Replace URL with wiki-link:
|
||||
|
||||
```bash
|
||||
# Download to media folder with descriptive name
|
||||
mkdir -p .
|
||||
img_name="downloaded_\$(date +%s).png"
|
||||
curl -sfo "$img_name" 'URL'
|
||||
```
|
||||
|
||||
Then read with `Read file_path="$img_name"`, and replace the markdown link `` with `![[$img_name]]` in the note.
|
||||
|
||||
**Benefits**: Image becomes a permanent vault asset, works offline, and uses Obsidian's native embed syntax.
|
||||
24
.claudian/sessions/conv-1777713214292-10p7k1vs9.meta.json
Normal file
24
.claudian/sessions/conv-1777713214292-10p7k1vs9.meta.json
Normal file
@@ -0,0 +1,24 @@
|
||||
{
|
||||
"id": "conv-1777713214292-10p7k1vs9",
|
||||
"providerId": "opencode",
|
||||
"title": "Identify current ai model",
|
||||
"titleGenerationStatus": "success",
|
||||
"createdAt": 1777713214301,
|
||||
"updatedAt": 1777714187064,
|
||||
"lastResponseAt": 1777714187064,
|
||||
"sessionId": "ses_218074bafffe07nMrVZVPDy0DK",
|
||||
"providerState": {
|
||||
"databasePath": "/Users/yiukai/.local/share/opencode/opencode.db"
|
||||
},
|
||||
"currentNote": "4 - Resources/Claude-Code/Everything Claude Code 用法速查.md",
|
||||
"usage": {
|
||||
"cacheCreationInputTokens": 0,
|
||||
"cacheReadInputTokens": 63232,
|
||||
"contextTokens": 68708,
|
||||
"contextWindow": 262144,
|
||||
"contextWindowIsAuthoritative": true,
|
||||
"inputTokens": 5476,
|
||||
"model": "opencode:kimi-for-coding/k2p6",
|
||||
"percentage": 26
|
||||
}
|
||||
}
|
||||
24
.claudian/sessions/conv-1779274122085-v9hbxyvjg.meta.json
Normal file
24
.claudian/sessions/conv-1779274122085-v9hbxyvjg.meta.json
Normal file
@@ -0,0 +1,24 @@
|
||||
{
|
||||
"id": "conv-1779274122085-v9hbxyvjg",
|
||||
"providerId": "opencode",
|
||||
"title": "Research GitHub Copilot CLI best practices from...",
|
||||
"titleGenerationStatus": "success",
|
||||
"createdAt": 1779274122085,
|
||||
"updatedAt": 1779274219480,
|
||||
"lastResponseAt": 1779274219480,
|
||||
"sessionId": "ses_1baff55a9ffecLOpzNpfsgyuMk",
|
||||
"providerState": {
|
||||
"databasePath": "/Users/yiukai/.local/share/opencode/opencode.db"
|
||||
},
|
||||
"currentNote": "1 - Inbox/Claude Code 工程化指南：高效组织 .claude 目录.md",
|
||||
"usage": {
|
||||
"cacheCreationInputTokens": 0,
|
||||
"cacheReadInputTokens": 68352,
|
||||
"contextTokens": 73300,
|
||||
"contextWindow": 262144,
|
||||
"contextWindowIsAuthoritative": true,
|
||||
"inputTokens": 4948,
|
||||
"model": "opencode:kimi-for-coding/k2p6",
|
||||
"percentage": 28
|
||||
}
|
||||
}
|
||||
3
.obsidian/community-plugins.json
vendored
3
.obsidian/community-plugins.json
vendored
@@ -1,6 +1,5 @@
|
||||
[
|
||||
"obsidian-checklist-plugin",
|
||||
"calendar",
|
||||
"obsidian-git",
|
||||
"terminal"
|
||||
"claudian"
|
||||
]
|
||||
20
.obsidian/plugins/claudian/data.json
vendored
Normal file
20
.obsidian/plugins/claudian/data.json
vendored
Normal file
@@ -0,0 +1,20 @@
|
||||
{
|
||||
"tabManagerState": {
|
||||
"openTabs": [
|
||||
{
|
||||
"tabId": "tab-1777712701745-99ybx73",
|
||||
"conversationId": "conv-1777713214292-10p7k1vs9"
|
||||
},
|
||||
{
|
||||
"draftModel": "opencode",
|
||||
"tabId": "tab-1777713147081-d1pedfs",
|
||||
"conversationId": null
|
||||
},
|
||||
{
|
||||
"tabId": "tab-1779274053891-79ozdhr",
|
||||
"conversationId": "conv-1779274122085-v9hbxyvjg"
|
||||
}
|
||||
],
|
||||
"activeTabId": "tab-1779274053891-79ozdhr"
|
||||
}
|
||||
}
|
||||
92952
.obsidian/plugins/claudian/main.js
vendored
Normal file
92952
.obsidian/plugins/claudian/main.js
vendored
Normal file
File diff suppressed because one or more lines are too long
10
.obsidian/plugins/claudian/manifest.json
vendored
Normal file
10
.obsidian/plugins/claudian/manifest.json
vendored
Normal file
@@ -0,0 +1,10 @@
|
||||
{
|
||||
"id": "claudian",
|
||||
"name": "Claudian",
|
||||
"version": "2.0.10",
|
||||
"minAppVersion": "1.4.5",
|
||||
"description": "Embeds Claude Code as an AI collaborator in your vault. Your vault becomes Claude's working directory, giving it full agentic capabilities: file read/write, search, bash commands, and multi-step workflows.",
|
||||
"author": "Yishen Tu",
|
||||
"authorUrl": "https://github.com/YishenTu",
|
||||
"isDesktopOnly": true
|
||||
}
|
||||
6126
.obsidian/plugins/claudian/styles.css
vendored
Normal file
6126
.obsidian/plugins/claudian/styles.css
vendored
Normal file
File diff suppressed because it is too large
Load Diff
676
1 - Inbox/2026 文字类提示词设计指南（上册）.md
Normal file
676
1 - Inbox/2026 文字类提示词设计指南（上册）.md
Normal file
@@ -0,0 +1,676 @@
|
||||
---
|
||||
title: "2026 文字类提示词设计指南（上册）"
|
||||
source: "https://x.com/AdrianPunk115/article/2056655062865490112"
|
||||
author:
|
||||
- "[[Adrian Punk (@AdrianPunk115)]]"
|
||||
published: 2026-05-19
|
||||
created: 2026-05-20
|
||||
description: "2天时间，肝爆Chatgpt生图功能上限2次，达到长文图片上限，也挡不住我想分享的心！！！！那么就分两次发吧👇很多人用 AI 做中文字体图，第一句提示词就是：“帮我生成 XX 几个字。”然后出来的图，经常像 PPT 艺术字字可能是对的，但没有设计感。能看，但不能当封面。有..."
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
|
||||
|
||||
2天时间，肝爆Chatgpt生图功能上限2次，达到长文图片上限，也挡不住我想分享的心！！！！
|
||||
|
||||
那么就分两次发吧👇
|
||||
|
||||
很多人用 AI 做中文字体图，
|
||||
|
||||
第一句提示词就是：“帮我生成 XX 几个字。”
|
||||
|
||||
然后出来的图，经常像 PPT 艺术字字可能
|
||||
|
||||
是对的，但没有设计感。 能看，但不能当封面。
|
||||
|
||||
有画面，但没有标题冲击力。问题不一定在 AI。 更多时候，是提示词太空了。
|
||||
|
||||
然后出来的图，经常像 PPT 艺术字。 字可能是对的，但没有设计感。 能看，但不能当封面。 有画面，但没有标题冲击力。
|
||||
|
||||
问题不一定在 AI。 更多时候，是提示词太空了。
|
||||
|
||||
“好看”不是指令。“高级”不是指令。“有设计感”也不是指令。
|
||||
|
||||
**AI 真正需要的是更具体的描述：**
|
||||
|
||||
这个字是什么字体？ 笔画是粗还是细？ 结构是紧凑还是舒展？ 边缘是锋利还是圆润？ 材质是金属、玻璃、贴纸，还是旧印刷？ 背景是科技界面、复古拼贴，还是手账纸张？
|
||||
|
||||
**中文字体提示词，最好按这个公式写：**
|
||||
|
||||
```text
|
||||
“文字内容”，字体类型，笔画/结构/重心/边缘描述；加入字效/材质/光影/背景，整体气质。
|
||||
```
|
||||
|
||||
这就不是让 AI “写几个字”。 这是让 AI “设计一组字”。
|
||||
|
||||
# 0个中文字体提示方案
|
||||
|
||||
## 01｜时尚体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案1：潮流品牌字**
|
||||
|
||||
```text
|
||||
“潮流先锋”，时尚体，字形前卫，线条简洁流畅，笔画利落，结构紧凑，整体有现代潮牌感。
|
||||
```
|
||||
|
||||
**方案 2：高级杂志字**
|
||||
|
||||
```text
|
||||
“高级玩家”，时尚体，字形修长，笔画干净，字距舒展，结构优雅，整体像时尚杂志标题。
|
||||
```
|
||||
|
||||
**方案 3：都市潮流字**
|
||||
|
||||
```text
|
||||
“都市潮流”，时尚体，字形宽扁低重心，笔画横向延展，线条硬朗平直，结构紧密有节奏感，整体像现代城市潮流视觉标题。
|
||||
```
|
||||
|
||||
**方案 4：先锋设计字**
|
||||
|
||||
```text
|
||||
“先锋设计”，时尚体，字形结构大胆重组，局部笔画夸张变形，线条简洁但张力强，整体像实验性设计展海报标题。
|
||||
```
|
||||
|
||||
## 02｜极简无衬线体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 5：极简品牌字**
|
||||
|
||||
```text
|
||||
“极简品牌”，极简品牌体，字形方正厚重，笔画粗细完全统一，横竖比例均衡，结构紧密稳定，字距克制，整体像高端品牌 Logo。
|
||||
```
|
||||
|
||||
**方案 6：现代知识字**
|
||||
|
||||
```text
|
||||
“现代知识”，知识标题体，字形端正清晰，笔画中等偏细，横竖线条干净利落，结构开放有序，字距舒展，整体像知识专栏或课程封面标题。
|
||||
```
|
||||
|
||||
**方案 7：清爽标题字**
|
||||
|
||||
```text
|
||||
“如沐春风”，清爽留白体，字形轻盈舒展，笔画细而均匀，线条柔和干净，字距大幅拉开，结构松弛有呼吸感，整体安静、清爽。
|
||||
```
|
||||
|
||||
**方案 8：科技简洁字**
|
||||
|
||||
```text
|
||||
“智能工作流”，几何科技体，字形模块化，笔画平直硬朗，横竖转角接近直角，结构规整像科技产品 UI 标题，整体理性、系统、数字化。
|
||||
```
|
||||
|
||||
## 03｜细线体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 9：轻奢细线字**
|
||||
|
||||
```text
|
||||
“时间复利”，轻奢细线体，字形高挑窄长，竖向比例明显拉伸，横画短而克制，竖画细长挺拔，笔画带极轻微粗细变化，末端收笔精致干净，字距适中，整体像高级香水、珠宝品牌标题。
|
||||
```
|
||||
|
||||
**方案 10：温柔细线字**
|
||||
|
||||
```text
|
||||
“慢慢变好”，温柔细线体，笔画纤细柔和，线条带轻微自然弧度，字形舒展松弛，重心平稳，整体安静、温柔、像生活方式杂志标题。
|
||||
```
|
||||
|
||||
**方案 11：高级知识字**
|
||||
|
||||
```text
|
||||
“深度观察”，理性细线体，字形端正方阔，横竖线条清晰笔直，笔画细而有秩序，转折干净，结构开放，字距均衡，整体像深度知识专栏或研究报告标题。
|
||||
```
|
||||
|
||||
**方案 12：未来细线字**
|
||||
|
||||
```text
|
||||
“智能边界”，未来细线体，字形几何化，笔画纤细平直，横竖转角接近直角，局部笔画呈模块断开式连接，结构轻盈但精密，整体像未来科技界面的系统标题。
|
||||
```
|
||||
|
||||
## 04｜单线字体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 13：连续线稿体**
|
||||
|
||||
```text
|
||||
“纤线灵动”，连续线稿体，字形由一根连续线条勾勒而成，线条粗细一致，转折流畅自然，笔画之间有连贯路径感，结构轻盈清晰，整体像极简线稿艺术标题。
|
||||
```
|
||||
|
||||
**方案 14：草图单线体**
|
||||
|
||||
```text
|
||||
“灵感草图”，草图单线体，字形像设计师手稿中的快速线条，笔画细而自然，线条带轻微抖动和手绘停顿，结构松弛但可读，整体像创意草图标题。
|
||||
```
|
||||
|
||||
**方案 15：科技线框字**
|
||||
|
||||
```text
|
||||
“连接万物”，科技线框体，字形由细直线和几何折线组成，笔画像线框结构搭建而成，横竖转角清晰，局部有节点式连接感，整体像科技网络界面的标题字体。
|
||||
```
|
||||
|
||||
**方案 16：优雅单线字**
|
||||
|
||||
```plaintext
|
||||
“留白之美”，优雅单线体，字形修长舒展，笔画由细长单线构成，横画克制，竖画挺拔，转折柔和，字距宽松，整体像高级展览海报中的极简标题。
|
||||
```
|
||||
|
||||
## 05｜现代衬线体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 17：杂志衬线体**
|
||||
|
||||
```text
|
||||
“都市韵律”，杂志衬线体，字形修长挺拔，笔画有明显粗细对比，横画纤细，竖画有力度，衬线短小利落，字距舒展，整体像高端时尚杂志标题。
|
||||
```
|
||||
|
||||
**方案 18：商业衬线体**
|
||||
|
||||
```text
|
||||
“增长模型”，现代衬线体，结构稳定，笔画利落，衬线克制，整体专业、商业、可信。
|
||||
```
|
||||
|
||||
**方案 19：轻奢封面字**
|
||||
|
||||
```text
|
||||
“高阶审美”，轻奢衬线体，字形高挑纤长，横画极细，竖画优雅挺拔，衬线精致尖细，收笔干净，字距略宽，整体像珠宝、香水或高定品牌标题。
|
||||
```
|
||||
|
||||
**方案 20：深度专栏字**
|
||||
|
||||
```text
|
||||
“深度观察”，专栏衬线体，字形方正端庄，笔画粗细分明，结构严肃有序，衬线短直稳定，字距均衡，整体像思想评论、财经专栏或深度报道标题。
|
||||
```
|
||||
|
||||
## 06｜极简手写体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 21：清新手迹字**
|
||||
|
||||
```text
|
||||
“清新手迹”，清新手迹体，字形轻盈自然，笔画细而流畅，线条像中性笔随手写下，结构简洁不复杂，字距舒展，整体干净、清爽、像生活杂志里的手写标题。
|
||||
```
|
||||
|
||||
**方案 22：成长笔记字**
|
||||
|
||||
```text
|
||||
“慢慢变好”，成长笔记体，字形柔和松弛，笔画带轻微粗细变化，横竖转折自然，结构像笔记本里的认真手写标题，整体温柔、真实、有自我成长记录感。
|
||||
```
|
||||
|
||||
**方案 23：个人签名字**
|
||||
|
||||
```text
|
||||
“自由开工”，个人签名体，字形连贯流动，笔画起伏明显，部分笔画自然相连，尾笔轻微拉长，整体像个人品牌签名，松弛但有识别度。
|
||||
```
|
||||
|
||||
**方案 24：情绪手写字**
|
||||
|
||||
```text
|
||||
“别急着稳定”，情绪手写体，字形轻微倾斜，笔画带速度感，线条有自然抖动和停顿，结构松动但清晰，整体像情绪很满时写下的一句手写标题。
|
||||
```
|
||||
|
||||
## 07｜弯曲字体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 25：柔和曲线字**
|
||||
|
||||
```text
|
||||
“信手拈来”，柔和曲线体，字形由大量圆润曲线构成，笔画转折柔顺，线条像丝带一样自然弯折，结构舒展流畅，整体温和、轻盈、有柔软动感。
|
||||
```
|
||||
|
||||
**方案 26：女性美学字**
|
||||
|
||||
```text
|
||||
“自在生长”，女性美学体，字形纤长柔美，笔画带优雅弧线，横竖转折自然收放，结构舒展不紧绷，整体像女性生活方式杂志中的柔美标题。
|
||||
```
|
||||
|
||||
**方案 27：音乐律动字**
|
||||
|
||||
```text
|
||||
“旋律流动”，音乐律动体，字形带明显波浪节奏，笔画像音符和声波一样起伏延展，线条流动感强，结构有节拍变化，整体像音乐海报标题。
|
||||
```
|
||||
|
||||
**方案 28：艺术曲线字**
|
||||
|
||||
```text
|
||||
“曲线之间”，艺术曲线体，字形由夸张曲线和不对称弧线重组，笔画弯折幅度明显，结构富有实验性但保持可读，整体像艺术展览海报中的曲线字体。
|
||||
```
|
||||
|
||||
## 08｜手绘字体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 29：轮廓手绘体**
|
||||
|
||||
```text
|
||||
“栩栩如生”，轮廓手绘体，字形由手工勾勒的外轮廓组成，笔画像被一笔一笔描出来，边缘带轻微不规则抖动，内部结构清晰，整体像手绘插画海报标题。
|
||||
```
|
||||
|
||||
**方案 30：插画装饰体**
|
||||
|
||||
```text
|
||||
“奇妙日常”，插画装饰体，字形圆润活泼，笔画像小插画一样被画出来，局部结构带星星、圆点、叶片般的图形化变化，整体像儿童绘本封面标题。
|
||||
```
|
||||
|
||||
**方案 31：粗描海报体**
|
||||
|
||||
```text
|
||||
“画出灵感”，草稿描线体，字形像设计草稿里的快速构思，笔画由多次重复描线组成，线条有断续和重叠感，结构自由但可读，整体像创作者画出来的标题字。
|
||||
```
|
||||
|
||||
**方案 32：童趣涂鸦体**
|
||||
|
||||
```text
|
||||
“今天不错”，童趣涂画体，字形像用画笔认真涂画出来，笔画圆胖不完全对齐，结构大小错落，边缘带手工涂画痕迹，整体天真、轻松、有儿童画感。
|
||||
```
|
||||
|
||||
## 09｜涂鸦字体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 33：街头涂鸦字**
|
||||
|
||||
```text
|
||||
“天马行空”，锋利街头喷漆体，字形大幅倾斜张扬，笔画像高速喷漆扫过墙面，粗硬笔触带尖锐切角，边缘有喷漆颗粒、飞溅和干刷断裂，四个字横向紧凑排列，整体像街头墙面上攻击性很强的喷漆涂鸦标题。
|
||||
```
|
||||
|
||||
**方案 34：青年观点字**
|
||||
|
||||
```text
|
||||
“别装成熟”，手写标语涂鸦体，字形像粗马克笔在墙面上快速写下，笔画粗细不均，线条带明显手写停顿、拖拽和急停痕迹，四个字保持清晰可读，排列紧凑但不互相重叠，整体像年轻人写在街头墙上的反叛标语。
|
||||
```
|
||||
|
||||
**方案 35：泡泡潮流涂鸦字**
|
||||
|
||||
```text
|
||||
“能工智人”，泡泡潮牌涂鸦体，字形圆胖夸张，笔画厚实膨胀，外轮廓像街头 bubble graffiti 一样饱满，局部结构被拉伸和挤压，文字上下错位堆叠，整体像潮牌海报里的泡泡涂鸦标题。
|
||||
```
|
||||
|
||||
**方案 36：爆裂摇滚涂鸦字**
|
||||
|
||||
```text
|
||||
“声音失控”，爆裂摇滚涂鸦体，字形像被音浪震碎后重新拼成，笔画粗暴破碎，边缘有撕裂毛刺和碎片感，文字采用上下错位的爆炸式构图，局部笔画向外冲出，整体像地下摇滚演出海报上的失控标题。黑底白字，纯字体设计，无装饰。
|
||||
```
|
||||
|
||||
## 10｜艺术字体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 37：抽象艺术字**
|
||||
|
||||
```text
|
||||
“浑然天成”，抽象构成体，字形由几何块面和抽象线条重新组合，笔画结构打破常规但保持可读，局部笔画像图形元素一样错位拼接，整体像现代艺术海报中的构成主义标题。
|
||||
```
|
||||
|
||||
**方案 38：展览字**
|
||||
|
||||
```text
|
||||
“视觉实验”，展览海报体，字形克制而有设计感，笔画结构被轻微拉伸和切分，线条干净，字距舒展，整体像艺术馆、设计展或美术馆海报中的高级标题。
|
||||
```
|
||||
|
||||
**方案 39：概念实验字**
|
||||
|
||||
```text
|
||||
“意识流动”，概念实验体，字形结构不规则，笔画像被拆解后重新排列，局部线条断开、漂移和错层，整体保持可读但充满先锋实验感，像概念艺术展的标题字。
|
||||
```
|
||||
|
||||
**方案 40：创作者标题字**
|
||||
|
||||
```text
|
||||
“灵感爆炸”，创作者爆发体，字形夸张有张力，笔画向外扩张，局部结构放大、扭转和冲出边界，整体像创作者灵感喷发时形成的强视觉标题。
|
||||
```
|
||||
|
||||
## 11｜夸张体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 41：强冲击标题字**
|
||||
|
||||
```text
|
||||
“巨大反差”，强冲击夸张体，字形极度放大，笔画粗壮厚重，结构被压缩得紧密有力量，局部笔画夸张加宽，整体像强冲击海报中的重磅标题。
|
||||
```
|
||||
|
||||
**方案 42：爆款封面字**
|
||||
|
||||
```text
|
||||
“一眼看懂”，爆款封面体，字形粗黑醒目，笔画饱满直接，结构清晰紧凑，字与字之间排列有强烈标题节奏，整体像短视频封面或爆款文章封面上的大标题。
|
||||
```
|
||||
|
||||
**方案 43：表情包标题字**
|
||||
|
||||
```text
|
||||
“离谱现场”，表情包夸张体，字形故意变形放大，笔画圆胖又不规则，结构带夸张扭动和表情感，字与字大小错落，整体像搞笑表情包里的情绪标题。
|
||||
```
|
||||
|
||||
**方案 44：强观点夸张字**
|
||||
|
||||
```text
|
||||
“别再内耗”，强观点夸张体，字形锋利紧绷，笔画粗硬有力量，结构向前倾斜，横竖转折带明显冲撞感，整体像观点海报中一句掷地有声的强表达标题。
|
||||
```
|
||||
|
||||
## 12｜未来感字体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 45：科技标题字**
|
||||
|
||||
```text
|
||||
“未来入口”，科技标题体，字形硬朗几何，笔画平直有力，横竖转折接近直角，局部结构带轻微切角，字距克制，整体像未来科技产品发布会的大标题。
|
||||
```
|
||||
|
||||
**方案 46：液态未来字**
|
||||
|
||||
```text
|
||||
“流动智能”，液态未来体，字形像被柔性材料生成，笔画有流体般的弯折和拉伸，边缘顺滑，结构在稳定和变形之间保持平衡，整体像未来材料、AI 生命体或新科技品牌标题。
|
||||
```
|
||||
|
||||
**方案 47：虚拟空间字**
|
||||
|
||||
```text
|
||||
“虚拟边界”，虚拟空间体，字形带空间透视和折叠感，笔画像立体平面被切开后重新组合，结构有前后层次和空间错位，整体像虚拟现实、元宇宙或空间计算系统标题。
|
||||
```
|
||||
|
||||
**方案 48：赛博断裂字**
|
||||
|
||||
```text
|
||||
“量化信号”，赛博断裂体，字形冷峻锋利，笔画被数字故障切成错位片段，局部结构有横向漂移、断裂和重组感，整体像高强度赛博世界、未来交易系统或数字战场标题。
|
||||
```
|
||||
|
||||
## 13｜趣味变形体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 49：趣味标题字**
|
||||
|
||||
```text
|
||||
“脑洞打开”，趣味标题体，字形轻微变形，笔画圆润有弹性，结构大小略有错落，局部笔画像被轻轻拉伸，整体轻松、有趣、像创意内容栏目的标题字。
|
||||
```
|
||||
|
||||
**方案 50：搞笑封面字**
|
||||
|
||||
```text
|
||||
“笑到离谱”，搞笑封面体，字形夸张扭动，笔画圆胖不规则，结构像被笑声挤压变形，字与字大小错落，整体像搞笑视频封面或热梗表情标题。
|
||||
```
|
||||
|
||||
**方案 51：创意课程字**
|
||||
|
||||
```text
|
||||
“一学就会”，模块课程标题体，字形清晰规整，笔画饱满厚实，局部结构像卡片模块一样拼接组合，横画和竖画带轻微错位层次，转角柔和但不圆滑，整体像创意课程、知识卡片或教程封面中的现代标题字。
|
||||
```
|
||||
|
||||
**方案 52：儿童活动字**
|
||||
|
||||
```text
|
||||
“快乐出发”，气球童趣体，字形圆润鼓起，笔画像充气气球一样饱满柔软，结构高低跳跃，局部笔画带轻微膨胀和收束感，整体轻快、天真、像儿童活动海报里的欢乐标题字。
|
||||
```
|
||||
|
||||
## 14｜像素风格体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 53：复古游戏字**
|
||||
|
||||
```text
|
||||
“像素人生”，复古像素体，字形由清晰的小方块像素拼成，横竖结构规整，边缘呈阶梯状锯齿感，整体像 8bit 复古游戏里的标题字。
|
||||
```
|
||||
|
||||
**方案 54：街机游戏字**
|
||||
|
||||
```text
|
||||
“开局暴击”，街机游戏体，字形厚重紧凑，笔画由大块像素组成，结构方正有力量，边缘带明显像素台阶，整体像街机游戏或游戏封面里的高能标题字。
|
||||
```
|
||||
|
||||
**方案 55：像素字**
|
||||
|
||||
```text
|
||||
“信号丢失”，像素故障体，字形由方块像素组成，局部笔画出现横向错位、缺块和断裂，结构保持可读但带明显数字故障感，整体像复古屏幕出现干扰时的标题字。
|
||||
```
|
||||
|
||||
**方案 56：方块模块字**
|
||||
|
||||
```text
|
||||
“模块世界”，方块模块体，字形由规整方形模块拼接而成，笔画方正厚实，结构像网格系统中搭建出来的文字，整体清晰、秩序、像像素化系统标题。
|
||||
```
|
||||
|
||||
## 15｜复古字体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 57：老电影字**
|
||||
|
||||
```text
|
||||
“旧梦重温”，老电影字幕体，字形端正克制，笔画粗细适中，结构清晰稳定，边缘带轻微旧胶片字幕的印刷颗粒感，整体像上世纪电影片头或老字幕里的怀旧标题字。
|
||||
```
|
||||
|
||||
**方案 58：霓虹旧街**
|
||||
|
||||
```text
|
||||
霓虹旧街”，港式旧招牌体，字形厚重醒目，结构紧凑饱满，笔画带老式商号招牌的方正骨架和手工刻字感，转折处略带复古圆角，整体像八九十年代港式老街店招、旧茶餐厅或传统商铺牌匾标题。
|
||||
```
|
||||
|
||||
**方案 59：复古广告字**
|
||||
|
||||
```text
|
||||
“省钱才是硬道理”，复古字体，笔画粗壮，字形带老式招牌感，整体怀旧、接地气。
|
||||
```
|
||||
|
||||
**方案 60：复古故事字**
|
||||
|
||||
```text
|
||||
“纸上年华”，怀旧出版体，字形端庄清晰，笔画带传统印刷标题字的稳重感，结构舒展有书卷气，横竖比例均衡，整体像旧杂志、老书封面或怀旧刊物中的标题字。
|
||||
```
|
||||
|
||||
## 16｜哥特风格字体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 61：暗黑标题字**
|
||||
|
||||
```text
|
||||
“哈利波特”，哥特风格字体，线条尖锐细长，笔画粗细对比鲜明，整体神秘、冷峻。
|
||||
```
|
||||
|
||||
**方案 62：中世纪字**
|
||||
|
||||
```text
|
||||
“魔兽世界”，哥特风格字体，笔画尖锐，字形像铁刺延展，结构复杂但清晰，整体奇幻、危险。
|
||||
```
|
||||
|
||||
**方案 63：黑金属尖刺字**
|
||||
|
||||
```text
|
||||
“深渊回声”，黑金属尖刺体，字形极度尖锐，笔画向上下延伸成刺状结构，转折处带锋利裂口，整体紧密、凌厉、攻击性强，像黑金属乐队 Logo 或暗黑演出海报标题。
|
||||
```
|
||||
|
||||
**方案 64：华丽哥特饰字**
|
||||
|
||||
```text
|
||||
“秘银王冠”，华丽哥特装饰体，字形高挑纤长，笔画带尖细起收笔和优雅弯折，局部结构有克制的哥特花体装饰感，整体神秘、精致、像暗黑宫廷或哥特珠宝品牌标题。
|
||||
```
|
||||
|
||||
## 17｜毛笔字
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 65：报头提题体**
|
||||
|
||||
```text
|
||||
“人民日报”，报头题字毛笔体，字形庄重开阔，笔画厚实有墨色重量，带传统毛笔题词的顿挫和筋骨，横画沉稳，竖画有力，结构端正大气。根据书法气质自动采用更适合的传统字形或繁体写法，但保持文字含义准确可读。整体像中文主流报纸报头、时代刊物封面或重要题词中的权威标题字。
|
||||
```
|
||||
|
||||
**方案 66：狂草书法体**
|
||||
|
||||
```text
|
||||
“山海之间”，高级狂草毛笔字 Logo，黑色纯背景，白色水墨书法，纯字体设计。要求字体极具狂草气势，笔画连绵飞动，粗细强烈对比，起笔有顿挫，行笔迅疾，收笔带锋。整体像书法大师一气呵成，带有山势起伏、海浪流动的抽象节奏。保留可读性，但结构不必工整，允许适度变形、连笔、飞白、断墨、墨迹晕染。
|
||||
```
|
||||
|
||||
**方案 67：行书体**
|
||||
|
||||
```text
|
||||
“行云流水”，潇洒行书练笔体，字形飘逸流动，笔画带真实行书练笔的提按、转腕、连带和细微牵丝，线条粗细灵活变化，部分笔画轻盈游走，部分笔画沉稳压住，字与字之间气脉连续但保持清晰可读。整体随性、有功力，像书法家在宣纸上一气呵成写下的文化品牌题字。根据书法气质自动采用更适合的传统字形或繁体写法，但保持文字含义准确可读。
|
||||
```
|
||||
|
||||
**方案 68：禅意体**
|
||||
|
||||
```text
|
||||
“难得糊涂”，老先生禅意题字体，字形松弛随性，笔画像毛笔蘸墨后慢慢写下，起笔有停顿，行笔有自然抖动和提按变化，收笔不刻意修饰，线条有粗有细、有圆有扁，结构不完全对齐，字与字之间有手写呼吸感。整体随意中带功力，温和中有识别度，像民宿招牌、茶室题字、山居民宿 Logo、东方生活方式品牌题字。根据书法气质自动采用更适合的传统字形或繁体写法，但保持文字含义准确可读。
|
||||
```
|
||||
|
||||
## 18｜西部手写字体
|
||||
|
||||
“奶油星球”，奶油甜品体，字形像奶油和甜品一样柔软膨胀，笔画厚实圆润，边缘顺滑，局部结构带轻微融化和堆叠感，整体甜美、可爱、像甜品店、烘焙品牌或可爱包装标题。黑底白字，纯字体设计，无装饰。
|
||||
|
||||
|
||||
|
||||
**方案 69：西部牛仔标题体**
|
||||
|
||||
```text
|
||||
“荒野来信”，西部牛仔标题体，字形粗犷硬朗，笔画厚重有力量，结构带美式西部木牌招牌的方正感，转角略带粗糙切削痕迹，边缘有轻微旧印刷磨损，整体像牛仔酒馆、荒野小镇或西部电影海报中的中文标题字。黑底白字，纯字体设计，无装饰。
|
||||
```
|
||||
|
||||
**方案 70：通缉令字体**
|
||||
|
||||
```text
|
||||
“落日公路”，美式公路字体，字形横向舒展，笔画干净有速度感，结构像复古公路路牌和汽车旅馆招牌的中文标题，线条稳重但不笨重，边缘带轻微旧漆脱落和风吹日晒的磨损感，整体像 66 号公路、落日旅行或复古公路海报标题。
|
||||
```
|
||||
|
||||
**方案 71：赏金字**
|
||||
|
||||
```text
|
||||
“赏金猎人”，荒野通缉令标题体，字形粗犷压缩，笔画像西部 WANTED 海报中的木刻粗衬线字体，横竖厚重，转角带刀削感和木牌刻痕，结构紧凑有压迫感，整体像牛仔小镇、赏金通缉令、酒馆公告或荒漠故事封面标题。边缘有沙尘颗粒、纸张破旧和印刷缺墨，但避免中国复古海报、旧报刊、老广告标题感。
|
||||
```
|
||||
|
||||
**方案 72：机车西部字**
|
||||
|
||||
```text
|
||||
“自由骑士”，机车西部体，字形锋利硬派，笔画粗壮有冲击力，结构带复古机车俱乐部、皮革徽章和西部酒馆招牌的混合气质，转折处有尖角、金属刻印感和粗犷切削边缘，边缘带轻微磨损。整体像机车文化、荒野骑行、牛仔公路或硬派复古品牌标题。
|
||||
```
|
||||
|
||||
## 19｜国潮体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 73：东方瘦金体体**
|
||||
|
||||
```text
|
||||
“东方醒来”，东方瘦金标题体，字形高挑清峻，笔画细而有锋芒，横画舒展如弦，竖画挺拔如骨，转折处带瘦金体的尖锐顿挫和书法筋骨，结构疏朗有贵气，整体像高级国风海报、新中式品牌或东方美学展览标题。
|
||||
```
|
||||
|
||||
**方案 74：国风牌匾体**
|
||||
|
||||
```text
|
||||
“山河入梦”，国风牌匾体，字形厚重饱满，笔画带传统牌匾字的稳重骨架，横画宽阔沉着，竖画有力，起收笔带手工刻字般的方圆顿挫，结构紧凑端庄，整体像老字号牌匾、国风店招或传统文化品牌标题。
|
||||
```
|
||||
|
||||
**方案 75：潮流篆意体**
|
||||
|
||||
```text
|
||||
“万象更新”，潮流篆意体，字形吸收篆书的圆转结构和对称秩序，笔画被现代化简化重组，线条厚实流畅，结构带图腾感和潮流视觉张力，整体像国潮品牌或东方潮流海报标题。
|
||||
```
|
||||
|
||||
**方案 76：东方海报**
|
||||
|
||||
```text
|
||||
“伯牙绝弦”，东方海报体，字形大气张扬，笔画带书法飞白和现代海报的块面冲击，结构舒展有势，横竖转折富有力量，整体像国风电影、东方美学展览或新国潮海报中的主标题。
|
||||
```
|
||||
|
||||
## 20｜童趣商业字体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 77：儿童绘本体**
|
||||
|
||||
```text
|
||||
“云朵小孩”，儿童绘本蜡笔手绘体，字形圆润自然，笔画像儿童绘本封面里的蜡笔或彩铅手绘标题，线条柔和但不膨胀，边缘有轻微手绘颗粒和不均匀感，结构高低错落但清楚可读，整体温暖、天真、有故事感，像儿童绘本封面、亲子阅读栏目或儿童故事标题。
|
||||
```
|
||||
|
||||
**方案 78：乐高玩具体**
|
||||
|
||||
```text
|
||||
“快乐开箱”，积木拼装标题体，字形由大块圆角积木模块组合而成，笔画像玩具积木一样厚实、平整、有卡扣感，结构轻微错位堆叠，字与字之间有拼装玩具的节奏感，但保持每个汉字清楚可读。整体像积木玩具盒、儿童益智产品包装或拼装游戏 Logo。
|
||||
```
|
||||
|
||||
**方案 79：零食包装字**
|
||||
|
||||
```text
|
||||
“糖果派对”，零食包装跳跳体，字形活泼醒目，笔画厚实但不圆胖膨胀，结构像儿童零食袋上的中文大标题，字与字之间有轻微弹跳和错位节奏，局部笔画带手绘包装字的俏皮切角和轻快弧度。不要爱心、星星、表情、糖果图案或任何额外装饰。
|
||||
```
|
||||
|
||||
**方案 80：剪纸拼贴字**
|
||||
|
||||
```text
|
||||
“手工时间”，手剪纸片拼贴字体，字形由白色剪纸碎片拼接成中文标题，每个笔画都像独立纸片贴上去，纸片之间保留细小黑色缝隙，局部有重叠压住的层次、轻微翘边和错位。边缘有手剪毛边、纸纤维粗糙感和不均匀切口，整体童真、手作、像儿童手工课剪贴出来的标题字。保持文字清楚可读。
|
||||
```
|
||||
|
||||
## 21｜城市商业招牌体
|
||||
|
||||
|
||||
|
||||
（下方提示词顺序：左上、右上、左下、右下）
|
||||
|
||||
**方案 81：灯管字**
|
||||
|
||||
```text
|
||||
夜里开门”，城市霓虹门店字，字形像现代街区小店的发光招牌标题，笔画简洁醒目，结构规整但带轻微霓虹灯管的圆角转折感，线条像灯管弯折组成，但保持纯白字体效果。整体像夜晚便利店、酒吧、小餐馆或城市街角门店招牌。不要国风牌匾、不要老报刊、不要复古海报、不要普通粗黑字。
|
||||
```
|
||||
|
||||
**方案 82：夜市菜单字**
|
||||
|
||||
```text
|
||||
“夜宵上桌”，夜市菜单牌字体，字形像街边烧烤摊、砂锅店、深夜食堂菜单牌上的中文标题字，笔画厚实直接，结构紧凑醒目，转角带手写招牌的圆钝变化，字面有热闹市井感和夜宵烟火气，整体像夜市价目牌、快餐菜单大字或深夜餐饮海报标题。
|
||||
```
|
||||
|
||||
**方案 83：便利贴字**
|
||||
|
||||
```text
|
||||
“随手买点”，便利店宽头马克笔标签体，字形像便利店货架价签和促销贴纸上用宽头油性马克笔手写出来的中文标题，笔画直接有力，线条粗实平涂，起收笔带宽头马克笔的钝角切面，边缘有轻微墨水渗透和纸面洇开感。部首交界处、笔画重叠处和转折处有明显叠墨变深效果，结构清楚但不完全工整，整体明快、真实，像社区便利店、零食货架或临时促销牌上的手写标签字。
|
||||
```
|
||||
|
||||
**方案 84：电商促销字**
|
||||
|
||||
```text
|
||||
“劲爆特价”，暴走漫画促销体，字形极度夸张，笔画巨大厚实，结构被挤压、拉扯和爆裂变形，字与字之间紧密堆叠，像促销海报上冲出来的叫卖大字。整体有暴走漫画式怒吼感、超市清仓感和限时特价冲击力，视觉直接、粗暴、夸张、让人一眼停住。
|
||||
```
|
||||
134
1 - Inbox/Agentic Design Patterns：一本让我重新理解"Agent 到底是什么"的书.md
Normal file
134
1 - Inbox/Agentic Design Patterns：一本让我重新理解"Agent 到底是什么"的书.md
Normal file
@@ -0,0 +1,134 @@
|
||||
---
|
||||
title: "Agentic Design Patterns：一本让我重新理解\"Agent 到底是什么\"的书"
|
||||
source: "https://x.com/yanhua1010/article/2058552177912947044"
|
||||
author:
|
||||
- "[[Yanhua (@yanhua1010)]]"
|
||||
published: 2026-05-24
|
||||
created: 2026-05-25
|
||||
description: "Antonio Gullí 是 Google 的工程总监。他写了本 453 页的书，把 AI Agent 开发拆成了 21 种设计模式。但这不是一篇书评。我读这本书的动机很具体：我写过 Harness Engineering，写过 Clawdbot 的踩坑经验，写过\"AI 智能体..."
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
|
||||
|
||||
Antonio Gullí 是 Google 的工程总监。他写了本 453 页的书，把 AI Agent 开发拆成了 21 种设计模式。
|
||||
|
||||
但这不是一篇书评。我读这本书的动机很具体：我写过 Harness Engineering，写过 Clawdbot 的踩坑经验，写过"AI 智能体不是魔法"那篇从烧 Token 到真正好用的七个转折，每次写完之后都有一个没完全想透的问题：**这些东西背后有没有一套可以复用的底层逻辑？**
|
||||
|
||||
这本书给了我答案，而且比我想的更深。
|
||||
|
||||
## 你写的可能根本不是 Agent
|
||||
|
||||
书里最狠的判断藏在 prologue 里。
|
||||
|
||||
大多数人在用的"AI"，只是 Level 0：裸 LLM，没有工具、没有记忆、不会行动。你问它 2025 年奥斯卡最佳影片是哪部，它猜。书里说得很直白：Level 0 的东西，不是 Agent。
|
||||
|
||||
往上走才是真 Agent。
|
||||
|
||||
**Level 1：工具使用者。** Agent 开始用工具了：搜索、API、数据库。但它不光是"能调接口"，更要自己判断什么时候该调、调什么、结果怎么用。书里给了一个很具体的例子：用户问"最近有什么新剧"，Agent 自己意识到这条信息不在训练数据里，主动调搜索工具去找，然后合成结果。关键一步在"自己意识到"。不是人类告诉它"你去搜一下"，是它自己判断需要搜。这个判断能力，是 Level 1 的门槛。
|
||||
|
||||
**Level 2：战略思考者。** 多了两样东西：规划和 Context Engineering。书里定义了 Context Engineering：不做信息堆砌，做的是精心筛选、裁剪、打包上下文。例子很妙：用户要在两个地点中间找咖啡店。Agent 先调地图工具拿到一堆数据，然后自己判断"下一步只需要街道名称"，把地图输出裁剪成一个短列表，再喂给本地搜索工具。每一步都在做信息降噪。书里有一句话我反复看了几遍："要让 AI 达到最高准确率，必须给它短小、聚焦、有力的上下文。" Context Engineering 就是干这件事的。
|
||||
|
||||
到了这个级别，Agent 还能自我反思。干完活后自己审一遍，发现问题自己改。我后面会细讲。
|
||||
|
||||
**Level 3：多 Agent 协作。** 书的立场很明确：别老想着造一个全能 super agent。真正靠谱的做法是像搭团队一样，项目经理 Agent + 研究员 Agent + 设计师 Agent + 文案 Agent。书里举的例子是新产品发布：一个"项目经理 Agent"做总调度，下发任务给"市场研究 Agent"、"产品设计 Agent"、"营销 Agent"。关键是通信：Agent 之间怎么传数据、怎么同步状态、怎么处理冲突。这章画了六种通信拓扑结构，从最简单的单 Agent 到最灵活的自定义混合，每种适合什么场景都有说明。
|
||||
|
||||
看完这四个等级，我突然明白为什么很多人说"我的 Agent 不好用"。模型没问题，问题是你在把它当聊天机器人用，它可能连 Level 1 都没到。
|
||||
|
||||
|
||||
|
||||
## Context Engineering：书里最被低估的概念
|
||||
|
||||
我写过一篇 Harness Engineering，讲的是赛道的设计比引擎的马力更重要。看完这本书我发现，Context Engineering 就是 Harness Engineering 在 prompt 层面的映射。
|
||||
|
||||
传统的 Prompt Engineering 只管"你怎么问"。书里的 Context Engineering 管的是"问之前，Agent 的眼前摆着什么"。它包括四层信息：
|
||||
|
||||
第一层，system prompt。定义 Agent 是谁、什么语气、什么边界。大多数人只写了这一层。
|
||||
|
||||
第二层，外部数据。RAG 检索到的文档、工具调用的返回值、实时 API 数据。这是大部分人卡住的地方：知道要喂数据，但不知道怎么喂才不会把模型淹没。
|
||||
|
||||
第三层，隐式数据。用户身份、交互历史、环境状态。你没明说但 Agent 应该知道的东西。比如你跟 Agent 说"帮我给 John 发邮件确认明天的会议"，它应该知道你日历里明天的会议是什么、你和 John 是什么关系。
|
||||
|
||||
第四层，反馈回路。Agent 每次输出之后，自动评估质量、调整下次的上下文策略。书里把这叫"自动化的 context 优化"，Google 的 Vertex AI Prompt Optimizer 就是这个思路的工程化实现。
|
||||
|
||||
我读到这里的时候想起之前写那篇"AI 智能体不是魔法"，里面有一条经验是"你的智能体需要规则，而且是很多规则"。现在回头看，那些规则本质上就是 Context Engineering 的手工版，书里把它系统化了。
|
||||
|
||||
|
||||
|
||||
## Reflection：两个 Agent 真的比一个好
|
||||
|
||||
这是全书对我最有实战价值的一个 Pattern。
|
||||
|
||||
Reflection 的核心很简单：Agent 干完活后自己审一遍，发现问题自己改。但实现方式有讲究。书里明确说了：**Producer 和 Critic 必须用两个不同的 Agent，给不同的 system prompt。** 同一个 persona 审自己的东西，一定有盲区。你让同一个 LLM 先写代码再审查自己写的代码，它大概率会说"挺好的"。
|
||||
|
||||
书里给了一个完整的代码示例。Producer 的 prompt 是"你是一个 Python 开发者，写一个计算阶乘的函数，处理边界条件和异常"。Critic 的 prompt 是"你是一个吹毛求疵的高级工程师，逐行审查代码，检查 Bug、风格、遗漏的边界条件、可改进的地方。如果完美就输出 CODE\_IS\_PERFECT，否则列出所有问题"。然后是一个 for 循环：Producer 写代码 → Critic 审 → Producer 根据意见改 → Critic 再审 → 直到 Critic 说 CODE\_IS\_PERFECT 或者达到最大迭代次数。
|
||||
|
||||
就这么简单。但书里提醒了一个容易被忽略的成本问题：每次反射循环都是一次新的 LLM 调用，迭代次数越多越贵。而且随着对话历史膨胀，上下文窗口被前期版本和批评意见占满，实际可用的推理空间在缩小。所以 Reflection 的最佳实践是：设一个合理的最大迭代次数（书里用的是 3），一旦 Critic 满意就停，不要追求完美。
|
||||
|
||||
用途远不止写代码。写文章、做计划、总结文档、解决逻辑题，Producer-Critic 模型全都能套。书里列了七种应用场景，核心逻辑一样：先产出，后审查，再修正。
|
||||
|
||||
|
||||
|
||||
## Multi-Agent 不是越复杂越好
|
||||
|
||||
Multi-Agent Collaboration 这章我最喜欢的是那六种通信拓扑图。很多人一上来就搞复杂的，但其实大部分场景三种就够了：
|
||||
|
||||
**单 Agent（独立执行）：** 任务能拆成互不依赖的子问题，每个 Agent 自己搞定自己的。简单，好维护。
|
||||
|
||||
**对等网络（Peer-to-Peer）：** Agent 之间直接通信，没有中心控制节点。去中心化，容错性好，一个 Agent 挂了不影响全局。但协调成本高，容易乱。
|
||||
|
||||
**Supervisor（中心调度）：** 一个 Supervisor Agent 管一群 Worker Agent。分配任务、收集结果、解决冲突。层级清晰，好管理。但 Supervisor 是单点故障，也是性能瓶颈。
|
||||
|
||||
另外三种（Supervisor-as-Tool、层级式、自定义混合）是前三者的变体和组合。书里说得很实在：**你需要的拓扑结构取决于你的任务复杂度。** 任务越拆越碎，通信成本越高，到一定程度 Supervisor 模式反而比层级式更有效率。
|
||||
|
||||
我的体会是，很多人搭 Multi-Agent 的时候花了 80% 的时间在通信协议上，忘了问一个更基本的问题：**这个任务真的需要多个 Agent 吗？** 书里写得很清楚，Level 2 的单 Agent + Reflection 往往已经够用了。Level 3 是给那些单 Agent 确实搞不定的场景准备的。
|
||||
|
||||
|
||||
|
||||
## Memory 三层模型，我之前隐约感觉到了但没命名
|
||||
|
||||
Memory 这章我最有共鸣，因为我写 Obsidian + Claude 那两篇文章的时候，一直在琢磨一个问题：Agent 的记忆该怎么分层？
|
||||
|
||||
书里给了答案。
|
||||
|
||||
**Session（会话层）：** 当前对话的上下文窗口，这是最短的记忆，对话结束就没了。长上下文模型只是把这个窗口放大了，但本质上还是临时的，而且每次推理都要处理整个窗口，又贵又慢。
|
||||
|
||||
**State（状态层）：** 当前任务进行中的临时数据。比如"正在做的任务是什么"，"已经完成到哪一步""中间产生了哪些数据"。比 Session 长，但任务结束就清理，书里用 Google ADK 的 State 机制做了完整示例。
|
||||
|
||||
**Memory（持久层）：** 跨会话、跨任务的长期记忆。用户偏好、学到的经验、重要的历史决策，存数据库或向量库里，语义检索。书里强调了一个很重要的点：Memory 不只是存下来，还要设计"存什么、什么时候存、怎么检索"的一整套策略。存太多了噪声大，存少了不够用。
|
||||
|
||||
我之前写 Clawdbot 那篇文章里提到"状态文件"和"工作区文档"，本质上就是在手搓 State 层和 Memory 层，书里把这件事框架化了。
|
||||
|
||||
|
||||
|
||||
## 五种假设，第五个最离谱
|
||||
|
||||
书末提了五个关于 Agent 未来的假设，前四个还在合理推演范围内：
|
||||
|
||||
通用型 Agent 从写代码到管项目、深度个性化主动发现你的需求、具身智能走出屏幕进物理世界、Agent 成为独立经济实体。
|
||||
|
||||
**第五个把我震住了：变形 Multi-Agent。** 你只声明目标，比如"做一个卖精品咖啡的电商生意"。系统自动决定：先创建"市场研究 Agent"和"品牌 Agent"。跑了一轮数据后，自己判断品牌 Agent 不需要了，拆成三个新的："Logo 设计 Agent"、"建站 Agent"、"供应链 Agent"。如果建站 Agent 成了瓶颈，系统会自动复制出三个并行 Agent 同时干不同的页面。整个过程中，系统持续自动调优每个 Agent 的 prompt，不断重组团队架构。
|
||||
|
||||
书里管这叫"目标驱动的、自我变形的多 Agent 系统"。它不是在执行你写的计划，是在自己生成计划、自己调整计划、自己重组执行团队。
|
||||
|
||||
这让我想起 Karpathy 的 AutoResearch：写一个 program.md，定义目标、指标、边界，按"启动"。人类在循环外面。但这本书推得更远：连 Agent 团队怎么组建、怎么重组，都交给系统自己决定。人类只声明"要什么"。
|
||||
|
||||
|
||||
|
||||
## 三件可以马上做的事
|
||||
|
||||
读完这本书，我有三个立刻可以落地的动作：
|
||||
|
||||
**第一，给你现在的 Agent 加一个 Critic。** 不管你是用 Claude Code、CrewAI 还是自己搭的框架，在你现有的 workflow 末尾加一步：让另一个 Agent（用不同的 system prompt）审查上一步的输出。代码生成加代码审查，文章撰写加事实核查，计划制定加可行性评审。多一次 LLM 调用，但质量提升往往翻倍。书里的 Producer-Critic 模式是即插即用的。
|
||||
|
||||
**第二，开始做 Context Engineering，不只是 Prompt Engineering。** 回头看你写给 Agent 的指令文件。如果全是"你要怎么做"的规则，缺少"你现在面对什么环境"的上下文，补上。告诉 Agent 它现在在哪个项目里、之前做过什么决定、用户偏好是什么。书里的 Context Engineering 那章和你的 AGENTS.md 是同一件事的两个表述。
|
||||
|
||||
**第三，先别急着上 Multi-Agent。** 把你的单 Agent 做到 Level 2：有工具、有 Reflection、有 Memory。书里反复强调，Level 2 的单 Agent 加上 Producer-Critic 和 Context Engineering，能覆盖绝大多数实际场景。Level 3 是给真正跨领域、多阶段、需要并行分工的任务准备的。大多数人的问题不是 Agent 不够多，是一个 Agent 都没调好。
|
||||
|
||||
这本书 453 页，Springer 2025 年出版。代码示例覆盖LangChain/LangGraph、Google ADK、CrewAI、OpenAI API。前言是 Google Cloud AI VP 写的，还有个 Goldman Sachs CIO 的推荐序，意外地好看。
|
||||
|
||||
但我推荐它的理由不是"全面"。是你读完会意识到一件事：你过去半年在 Agent 上踩的坑，都有人整理成模式了。你不需要再去发明 Reflection，不需要再去猜 Memory 该怎么分层，不需要再去试 Multi-Agent 该用哪种通信拓扑。
|
||||
|
||||
有人替你画了地图，剩下的就是走。
|
||||
|
||||
**你在用 AI Agent 做开发吗？你现在的 Agent 到了 Level 几？评论区聊聊。**
|
||||
457
1 - Inbox/Claude Code Dynamic Workflows：把编排逻辑搬进代码的新原语.md
Normal file
457
1 - Inbox/Claude Code Dynamic Workflows：把编排逻辑搬进代码的新原语.md
Normal file
@@ -0,0 +1,457 @@
|
||||
---
|
||||
title: "Claude Code Dynamic Workflows：把编排逻辑搬进代码的新原语"
|
||||
source: "https://x.com/riba2534/article/2060102236676792711"
|
||||
author:
|
||||
- "[[riba2534 (@riba2534)]]"
|
||||
published: 2026-05-28
|
||||
created: 2026-05-30
|
||||
description: "当任务大到一次对话装不下时，让 Claude 把编排过程写成一段脚本5 月 28 日，Anthropic 发布了 Claude Opus 4.8，随之而来还带来了一个新功能——Dynamic Workflows（动态工作流）。先看一个数字：11 天、约 75 万行 Rust 代码..."
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
|
||||
|
||||
> 当任务大到一次对话装不下时，让 Claude 把编排过程写成一段脚本
|
||||
|
||||
5 月 28 日，Anthropic 发布了 Claude Opus 4.8，随之而来还带来了一个新功能——Dynamic Workflows（动态工作流）。
|
||||
|
||||
先看一个数字：**11 天**、**约 75 万行 Rust 代码**、**99.8% 的原有测试通过**。这是 Bun 作者 Jarred Sumner 把整个 Bun 运行时[从 Zig 迁移到 Rust](https://github.com/oven-sh/bun/pull/30412) 交出的成绩单，而扛起这场迁移的主力，正是这个 Dynamic Workflows。
|
||||
|
||||
它作为研究预览（research preview）放出，瞄准的是那一类单个 Agent 一次跑不完的活，官方博客的原话是这样描述的：
|
||||
|
||||
> Some problems are too big for one pass by a single agent, especially in complex, legacy codebases: a bug hunt across an entire service, a migration that touches hundreds of files, a plan you want stress-tested from every angle before you commit to it.
|
||||
|
||||
整个服务范围的 bug 排查、动辄上百个文件的迁移、一个需要从各个角度反复推敲才敢拍板的方案——这些任务的共同点是规模超出了一轮对话能协调的范围。Dynamic Workflows 给出的答案，是让 Claude 把这套编排过程写成一段可执行的脚本。
|
||||
|
||||
## 从 Subagent 到 Workflow
|
||||
|
||||
要理解 Workflow 的位置，得先把 Claude Code 已有的几层协作能力捋一遍。
|
||||
|
||||
最底层是单个 session，一个 Agent 实例从头干到尾，串行处理。往上一层是 subagent——主 Agent 派生出若干小弟去搜文件、读代码、跑命令，干完把结果汇报回来。再往上是今年早些时候推出的 [Agent Teams](https://code.claude.com/docs/en/agent-teams)，多个独立的 Claude Code 实例像团队一样并行协作，队员之间还能互相通信。
|
||||
|
||||
这几层有一个共同的瓶颈：**编排者始终是 Claude 本身**。它逐轮决策下一步派谁去干什么，而每一个 subagent 的返回结果，都要先回到 Claude 的上下文窗口里，它读完才能决定接下来怎么走。这套机制在任务规模不大时很灵活，可一旦要协调几十上百个并行任务，问题就来了：上下文窗口装不下那么多中间结果，Claude 的注意力也会被海量的过程信息稀释。
|
||||
|
||||
Workflow 换了个思路。这一次 Claude 不再亲自逐轮调度，它先把整个编排过程**写成一段 JavaScript 脚本**——循环、分支、中间结果的收集全都固化在代码里——再交给一个独立的运行时去执行。官方文档把这个转变概括得很精炼：
|
||||
|
||||
> A workflow moves the plan into code. With subagents and skills, Claude is the orchestrator: it decides turn by turn what to spawn next, and every result lands in Claude's context. A workflow script holds the loop, the branching, and the intermediate results itself, so Claude's context holds only the final answer.
|
||||
|
||||
计划被搬进了代码。脚本自己持有循环、分支和中间结果，Claude 的上下文里只剩下最后那个答案。这跟"把大型代码库塞进有限上下文窗口"的思路是同一条路线上的延续——前者解决的是"上下文怎么省着用"，Workflow 解决的是"当工作量大到上下文根本装不下时怎么办"。
|
||||
|
||||
把 Agent Teams 和 Dynamic Workflows 摆在一起看：
|
||||
|
||||
|
||||
|
||||
> 图片出自 Anthropic 产品经理 Cat Wu 发布 Dynamic Workflows 的推文。左边 Agent Teams 是网状协作，右边 Dynamic Workflows 则是"一个 claude 扇出上百个 task，每个 task 走 implementer → 两个 verifier → fixer 三层，最后扇入返回"的树状结构——后面 Bun 案例里"每个文件配两个 reviewer"的设计，在这张图上已经能看到雏形。
|
||||
|
||||
## Workflow 到底在哪运行
|
||||
|
||||
开始拆架构之前，得先破除一个最常见的误解：很多人以为 Workflow 是某个跑在 Anthropic 服务端的编排引擎，于是去找它的 API 协议、担心第三方中转兼容性。
|
||||
|
||||
实际情况是：**Workflow 工具本身不请求任何服务端**。它是 Claude Code 在你本机跑的一段 JavaScript 编排脚本——agent()、parallel()、pipeline() 这些都是在你电脑上执行的控制流。真正去"请求服务端"的，是脚本里 agent() 调用 spawn 出来的每个 subagent，而**subagent 调用模型的方式，和你主对话窗口完全一样**。
|
||||
|
||||
这件事有个直接推论：如果你用第三方 API 中转，Workflow 跑挂了，那跟 Workflow 没关系——它用的就是 Claude Code 平时调模型一直在用的那套接口，即 Anthropic 原生的 Messages API（不是 OpenAI 的 /v1/chat/completions）：
|
||||
|
||||
```text
|
||||
POST {ANTHROPIC_BASE_URL}/v1/messages
|
||||
|
||||
Headers:
|
||||
x-api-key: <key> # 或第三方常用的 Authorization: Bearer <key>
|
||||
anthropic-version: 2023-06-01
|
||||
anthropic-beta: context-1m-2025-08-07 # 1M context 会带这个 beta flag
|
||||
content-type: application/json
|
||||
|
||||
Body:
|
||||
{
|
||||
"model": "claude-opus-4-8", # 裸 model id，[1m] 只是本地标识，不会进 body
|
||||
"system": [ {... cache_control ...} ], # system 是数组，带 prompt caching
|
||||
"messages": [...],
|
||||
"tools": [...], # Claude Code 会塞几十个 tool 定义
|
||||
"stream": true # 默认流式
|
||||
}
|
||||
```
|
||||
|
||||
把这层关系理清之后，Workflow 的运行模型就清晰了：一个**无脑的、确定性的 JavaScript 运行时**当指挥，它只会循环、拼字符串、await，本身不含任何 LLM；只有当脚本执行到 agent(...) 那一行，运行时才去临时雇一个 LLM subagent 干活。而"真正的 Agent"——也就是你正在对话的主 Claude——在脚本执行期间**根本没在运行**：它在发出 Workflow 调用后那一回合就结束了，脚本在后台独立跑，跑完用一条通知把它叫醒，让它去读最后的结果。
|
||||
|
||||
|
||||
|
||||
一句话概括这个分工：**JavaScript 运行时当指挥（无脑、确定性），在 \`agent()\` 点临时雇 LLM 干活，主 Agent 全程在睡觉，只在最后被叫醒读结果。** 记住这条，后面所有的特性都好理解了。
|
||||
|
||||
## Workflow 的核心架构
|
||||
|
||||
一个 Workflow 跑起来，背后是四个部件在配合：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这张图里最关键的一条线，是 subagent 的结果先流进**脚本变量**，在运行时内部完成循环和校验，最后只有汇总过的答案才回到 Claude。这跟 subagent 那种"每个结果都要经过 Claude 大脑"的模式有本质区别。
|
||||
|
||||
官方文档给了一张三者对照表，把 Workflow 和 Subagents、Skills 的定位差异讲得很清楚：
|
||||
|
||||
|
||||
|
||||
读这张表的时候，注意"可复用的是什么"这一行。subagent 和 skill 复用的是"一个工作者"或"一条指令"，而 Workflow 复用的是**整套编排逻辑**——这意味着一个调度数百个 agent 做交叉验证的复杂流程，写好一次就能存下来反复运行。这是 Workflow 区别于其它原语的地方。
|
||||
|
||||
## 脚本长什么样：meta、原语和那个最容易踩的坑
|
||||
|
||||
既然 Workflow 是一段 JS 脚本，那它到底长什么样？这一节把骨架拆开看。
|
||||
|
||||
每个脚本**必须**以 export const meta = {...} 开头，而且 meta 必须是**纯字面量**——不能有变量、函数调用、模板插值。它定义了脚本的名字、一行描述（会显示在权限弹窗上）和阶段划分：
|
||||
|
||||
```javascript
|
||||
export const meta = {
|
||||
name: 'find-flaky-tests',
|
||||
description: 'Find flaky tests and propose fixes', // 一行，显示在权限弹窗
|
||||
phases: [ // 每个 phase() 调用对应一条
|
||||
{ title: 'Scan', detail: 'grep test logs for retries' },
|
||||
{ title: 'Fix', detail: 'one agent per flaky test' },
|
||||
],
|
||||
}
|
||||
// 脚本体从这里开始
|
||||
phase('Scan')
|
||||
const flaky = await agent('grep CI logs for retry markers', { schema: FLAKY_SCHEMA })
|
||||
phase('Fix')
|
||||
// ...
|
||||
```
|
||||
|
||||
meta 之后就是脚本体。能用的核心原语不多，一张表就能记住：
|
||||
|
||||
|
||||
|
||||
每个 agent() 的提示词，就写在脚本里，是普通的 JS 字符串。要给不同 agent 喂不同的输入，常见写法是把 prompt 写成一个"返回字符串的函数"，调用时用 .map() 把循环变量插进去。数据就是这样在 agent 之间流动的——靠的就是普通的字符串拼接，没有什么消息总线：逐项数据用 .map() 插进每个 agent 的 prompt，跨阶段数据则把上一阶段的返回值 JSON.stringify 后拼进下一阶段的 prompt。
|
||||
|
||||
整段脚本里最容易踩的坑，是 pipeline 和 parallel 分不清。两者的本质分界是**有没有屏障（barrier）**：parallel 会等这一批全部跑完才往下走，pipeline 则让每个 item 各自独立地流过所有 stage，互不等待。下面这种写法就是典型的浪费：
|
||||
|
||||
```javascript
|
||||
const a = await parallel(...) // ❌ 屏障：等全部跑完
|
||||
const b = transform(a) // 只是 flatten / map / filter，没有跨 item 依赖
|
||||
const c = await parallel(b.map(...))
|
||||
```
|
||||
|
||||
如果 5 个任务快慢不一，中间这个屏障会让快的干等慢的。正确的做法是把中间的 transform 塞进 pipeline 的一个 stage，让每条数据一旦就绪就立刻流向下一步：
|
||||
|
||||
```javascript
|
||||
// ✅ 维度 'bugs' 的发现可以在 'perf' 还在 review 时就开始 verify
|
||||
const results = await pipeline(
|
||||
DIMENSIONS,
|
||||
d => agent(d.prompt, { label: \`review:${d.key}\`, phase: 'Review', schema: FINDINGS }),
|
||||
review => parallel(review.findings.map(f => () =>
|
||||
agent(\`对抗性验证: ${f.title}\`, { phase: 'Verify', schema: VERDICT })
|
||||
.then(v => ({ ...f, verdict: v }))
|
||||
))
|
||||
)
|
||||
```
|
||||
|
||||
|
||||
|
||||
只有三种情况才真正需要屏障：下一阶段前要对**全集**去重或合并；要根据总数提前退出（比如"0 个 bug 就跳过整个验证阶段"）；下阶段的 prompt 要引用"其他所有发现"做横向比较。除此之外，**有疑问就用 pipeline**。
|
||||
|
||||
## 三种触发方式
|
||||
|
||||
让 Claude 起一个 Workflow，有三条路子。
|
||||
|
||||
第一条是在 prompt 里直接出现 workflow 这个词。Claude Code 会把它高亮出来，提示你这句话可能触发一个工作流：
|
||||
|
||||
```text
|
||||
Run a workflow to audit every API endpoint under src/routes/ for missing auth checks
|
||||
```
|
||||
|
||||
如果你只是顺口提了一句 workflow、并不想真的触发，按 alt+w 就能忽略这个高亮。
|
||||
|
||||
第二条是开启 ultracode 模式，让 Claude 自己判断要不要起 Workflow：
|
||||
|
||||
```text
|
||||
/effort ultracode
|
||||
```
|
||||
|
||||
第三条是运行一个已经保存好的 Workflow，它会以斜杠命令的形式出现：
|
||||
|
||||
```text
|
||||
/deep-research What changed in the Node.js permission model between v20 and v22?
|
||||
```
|
||||
|
||||
保存下来的 Workflow 放在两个位置，决定了它的可见范围：
|
||||
|
||||
```text
|
||||
.claude/workflows/ # 项目级，克隆仓库的人都能用，跟团队共享
|
||||
~/.claude/workflows/ # 个人级，只有你能看到，但在每个项目里都能用
|
||||
```
|
||||
|
||||
保存时按 Tab 在这两个位置之间切换。如果项目级和个人级有同名 Workflow，**项目级优先**。存好之后它就成了一个 /<name> 命令，出现在斜杠自动补全菜单里，跟普通的 slash command 混在一起。
|
||||
|
||||
|
||||
|
||||
脚本生成之后、真正跑起来之前，你有机会审一眼它要干什么。运行中按 Ctrl+G 还能在编辑器里打开脚本，看 Claude 到底写了段什么样的代码。这种"代码可见、可审"的特性，是 Workflow 相比黑盒式自动化更让人放心的地方。
|
||||
|
||||
## 执行模型与那些硬约束
|
||||
|
||||
Workflow 的运行时跟你的对话是隔离的——脚本在独立环境里执行，跑的过程中你的会话依然能响应。这套隔离机制也带来一组必须了解的硬约束。
|
||||
|
||||
并发是有上限的：**最多 16 个 subagent 同时跑**（实际是 min(16, CPU 核数 − 2)，核心少的机器会更低），**单次运行最多 1000 个 agent**。后面这个数字是防止脚本陷入死循环失控烧钱的保险丝。
|
||||
|
||||
权限上，Workflow 内部派生的所有 subagent **自动以 \`acceptEdits\` 模式运行**，文件编辑不再逐个弹窗确认，并且继承你当前会话的工具允许列表（tool allowlist）。但有一类情况仍然会打断运行——不在允许列表里的 shell 命令、网络抓取和 MCP 工具，跑到一半还是会向你弹确认框。所以官方的建议是：**大规模运行之前，先把 agent 们需要用到的命令加进允许列表**，免得跑了一半被一个权限弹窗卡住。
|
||||
|
||||
还有一点容易被忽略：脚本本身没有直接的文件系统或 shell 访问权限，所有的读写和执行都得通过 subagent 来完成。脚本是纯粹的"调度大脑"，手脚都长在 subagent 身上。
|
||||
|
||||
可恢复是 Workflow 相比 subagent、Agent Teams 独有的能力。每次运行都会留一份 journal，改完脚本后用 resumeFromRunId 重跑，**没改动的 \`agent()\` 调用直接命中缓存，只有改动及其之后的部分才重新跑**。这一点对调试编排逻辑很省事——改一行 prompt 重跑，前面已经跑对的那些 agent 直接命中缓存，不用再花一遍钱和时间。但要注意一条界线：**恢复只在同一个会话内有效**。运行中途暂停了可以接着跑，已完成的工作不会丢；可一旦你退出了 Claude Code，下次进来这个 Workflow 只能从头再跑一遍。
|
||||
|
||||
## 内置的 deep-research 长什么样
|
||||
|
||||
光说概念有点抽象，Anthropic 直接内置了一个现成的 Workflow 让你上手体验——/deep-research。
|
||||
|
||||
它的用法就是后面跟一个问题：
|
||||
|
||||
```text
|
||||
/deep-research <question>
|
||||
```
|
||||
|
||||
跑起来之后，它干的事情分三段：先从多个角度扇出（fan out）一批 Web 搜索，然后抓取并交叉核对这些来源，接着对每一条声明（claim）投票表决，最后产出一份带出处的报告，**没通过交叉验证的声明会被直接剔除**。
|
||||
|
||||
|
||||
|
||||
它依赖 WebSearch 工具可用。这个内置 Workflow 的价值在于，它把"对抗幻觉"这件事用编排的方式做了进去——单个 Agent 搜索容易被某个来源带偏，而多路搜索加交叉投票，本质上是在用结构化的流程逼近事实。想感受 Workflow 是什么体验，跑一个 /deep-research 是成本最低的入口。
|
||||
|
||||
## Ultracode：让 Claude 自己决定要不要起 Workflow
|
||||
|
||||
如果你不想每次都手动判断"这个任务值不值得起 Workflow"，可以把这个决定权交给 Claude——开启 ultracode。
|
||||
|
||||
```text
|
||||
/effort ultracode
|
||||
```
|
||||
|
||||
这条命令同时做两件事：把推理努力（effort）拉到 xhigh，同时允许 Claude 自动判断什么时候该用 Workflow 来处理你的任务。开启之后，**一个请求可能被拆成连续好几个 Workflow**——比如先跑一个理解代码，再跑一个做修改，最后跑一个验证。这个设置对当前会话里的每个任务都生效，新会话则会重置。
|
||||
|
||||
代价也很直白：官方文档说得很清楚，ultracode 模式下每个请求消耗的 token 和耗时都明显高于较低的努力档位。想退回日常工作模式，降回去就行：
|
||||
|
||||
```text
|
||||
/effort high
|
||||
```
|
||||
|
||||
这种"让模型自己决定调度规模"的设计，跟 Codex 那套 Goals（持久目标）走的是不同的方向，这点最后再细说。
|
||||
|
||||
## Workflow 是一张 DAG 吗
|
||||
|
||||
聊到编排，很多人脑子里第一反应是 DAG（有向无环图）——Airflow、Argo、GitHub Actions 的 needs:，都是先把一张静态的依赖图画死，再按图执行。Workflow 是不是也是这样？
|
||||
|
||||
答案要看你问的是哪张图：**作为程序，它不一定是 DAG；但任何一次执行的轨迹，一定是 DAG。**
|
||||
|
||||
先说程序层面。Claude Code 的 Workflow 是一段**图灵完备的命令式 JavaScript**，不像传统编排器那样跑之前就把依赖图定死。它能写出 DAG 表达不了的东西，最典型的就是循环——比如"一直找 bug，直到连续两轮都没有新增"：
|
||||
|
||||
```javascript
|
||||
let dry = 0
|
||||
while (dry < 2) { // ← 这是一条回边，控制流图里的环
|
||||
const fresh = (await parallel(FINDERS.map(...))).filter(isNew)
|
||||
if (!fresh.length) { dry++; continue }
|
||||
dry = 0
|
||||
confirmed.push(...await verify(fresh))
|
||||
}
|
||||
```
|
||||
|
||||
除了循环，它还能写运行时才决定的分支（if (bugs.length === 0) return，走哪条路取决于上一步 LLM 的输出），以及动态扇出（下一阶段起几个 agent，取决于上一阶段返回了多少条结果）——图的形状事先并不知道。在"程序结构"这个层面，它有环、有数据决定的分支，比 DAG 严格更强。
|
||||
|
||||
但只要你盯住"某一次具体执行"，它又一定是 DAG。原因有两个：数据只往时间前方流，一个值不可能依赖它之后才产生的值；循环会被展开，while 第 N+1 轮的那些 agent，和第 N 轮是不同的节点——环在"程序"里，展开成"轨迹"后就被拉直成一条链了。
|
||||
|
||||
|
||||
|
||||
一句话记住：**带 \`while\` 的程序不是 DAG，但它跑一次产生的执行轨迹，永远是 DAG。** 这正是它比传统 DAG 编排器更灵活的地方——传统工具的图在跑之前就定死了，而 Workflow 的拓扑是命令式脚本跑出来的，形状运行时才定。
|
||||
|
||||
## 真实案例一：Bun 从 Zig 移植到 Rust
|
||||
|
||||
前面所有的概念，都不如 Bun 这个案例有说服力。开头那组数字可以再看一眼：11 天、约 75 万行 Rust、99.8% 的原有测试通过，从第一个 commit 到合并。
|
||||
|
||||
Bun 是一个用 Zig 写的 JavaScript 运行时，性能是它的招牌。把这样一个庞大的运行时从 Zig 整体迁移到 Rust，是那种听起来就让人头皮发麻的工程——光是 Rust 借用检查器（borrow checker）对内存所有权的严格要求，就足以让人工迁移举步维艰。Jarred Sumner 用三个串联的 Workflow 把它啃了下来。
|
||||
|
||||
|
||||
|
||||
**阶段一是生命周期映射。** 第一个 Workflow 专门做一件事：给 Zig 代码库里每一个 struct field 算出它对应的、正确的 Rust lifetime。这一步单独拎出来做，是因为它是后面所有移植工作的地基——Rust 的内存安全建立在生命周期标注之上，这一层没算对，后面写出来的 .rs 文件根本过不了编译。
|
||||
|
||||
**阶段二是并行文件移植，也是最能体现 Workflow 规模优势的一段。** 下一个 Workflow 把每个 .zig 文件移植成一个行为等价的 .rs 文件，**数百个 agent 同时开工，每个文件还配两个 reviewer 做交叉审查**。把这个量级跟 Agent Teams 对比一下就能感受到差距——Agent Teams 同时跑三五个队员就到协调上限了，而 Workflow 在这里是几百个 agent 并行外加双重 review。
|
||||
|
||||
**阶段三是编译与测试的 fix loop。** 文件移植完只是半成品，真正的硬仗是让它们能编译、能通过测试。第三个 Workflow 驱动整个 build 和 test 套件，循环修复，直到两者都干净跑过。这正是上一节讲的 while 循环模式的典型场景——靠脚本里的循环逻辑反复迭代，而不靠 Claude 逐轮盯着。
|
||||
|
||||
三个阶段各自的特征可以列成一张表：
|
||||
|
||||
|
||||
|
||||
事情到这还没完。移植合并之后，又跑了一个 **overnight workflow**（过夜工作流）专门处理收尾——扫描代码里不必要的数据拷贝，每发现一处优化就单独开一个 PR 交给人做最终审查。这种"夜里挂着自己干长尾清理、产出一堆待 review 的 PR"的用法，是 Workflow 很有意思的一个侧面。
|
||||
|
||||
需要说清楚的是，官方明确标注了 Bun 的这个 Rust 版本**当时还没进入生产环境**——这整套流程跑通了、测试过了，但离上线还有距离。Jarred 自己也说，后续会专门写文章讲这件事的更多细节。
|
||||
|
||||
## 真实案例二：用 Workflow 盘点 133 个历史会话
|
||||
|
||||
Bun 是个极端案例，普通人未必有机会跑一次跨语言大迁移。我自己拿一个更接地气的任务试了一下：用 Workflow 给自己的 Claude Code 历史会话做一次"使用画像"。
|
||||
|
||||
任务是这样的：~/.claude 目录下攒了 **133 个会话、130MB 的 jsonl 记录**，想从里面提炼出使用模式、反复出现的痛点和可以自动化的点。这个活的特点是数据量大、维度多，正好适合 fan-out。
|
||||
|
||||
整个任务拆成了"**主 Agent 预处理 + Workflow 编排**"两段。主 Agent 先做侦察和清洗：jsonl 里塞满了工具调用的噪声，直接喂给 agent 会浪费上下文，于是先写个脚本把 133 个会话压缩成"标题 + 用户真实输入 + 元数据"，得到 601 条真实的人类输入，再切成 10 个批次。然后才是 Workflow 上场：**10 个分析 agent 并行各啃一个批次**（按统一的 schema 抽取领域分布、卡点、自动化候选），最后 1 个综合 agent 跨批汇总去重，产出一份带优先级的报告。
|
||||
|
||||
|
||||
|
||||
这次运行的执行体，去掉声明部分后大致是这样：
|
||||
|
||||
```javascript
|
||||
phase('分析')
|
||||
const batches = Array.from({ length: 10 }, (_, i) =>
|
||||
\`${DIR}/batch_${String(i + 1).padStart(2, '0')}.md\`)
|
||||
|
||||
const findings = await parallel(batches.map((path, i) => () =>
|
||||
agent(ANALYZE_PROMPT(path), { // ANALYZE_PROMPT 是返回字符串的函数
|
||||
label: \`分析:batch_${String(i + 1).padStart(2, '0')}\`,
|
||||
phase: '分析',
|
||||
schema: FINDING_SCHEMA, // 强制结构化输出，不匹配自动重试
|
||||
})
|
||||
))
|
||||
|
||||
const ok = findings.filter(Boolean) // 丢掉跑挂的（被跳过的 agent 返回 null）
|
||||
log(\`分析完成：${ok.length}/${batches.length} 批返回有效结果\`)
|
||||
|
||||
phase('综合')
|
||||
const corpus = JSON.stringify(ok, null, 1) // 把 10 份发现整个塞进综合 prompt
|
||||
const report = await agent(SYNTH_PROMPT, { label: '综合报告', phase: '综合' })
|
||||
return report // 这个返回值就是唯一回到主上下文的东西
|
||||
```
|
||||
|
||||
跑下来的账单：**11 个 agent、81.8 万 token、254 秒**。这中间我还踩了一个坑——第一次跑直接挂了，报 TypeError: undefined is not an object (evaluating '[batches.map](https://batches.map/)')，原因是 args 没正确传进去、被当成了字符串。修法很能体现 Workflow"脚本即文件、可迭代"的价值：我没有重发整段脚本，只是直接 Edit 那个落盘的脚本文件、把路径写死成自包含，再用 scriptPath 重跑。
|
||||
|
||||
这个案例还顺带回答了一个很多人会问的问题：**这事派几个 subagent 一样能做，区别在哪？** 确实能做——区别不在"能不能"，在"编排逻辑放哪、中间结果流到哪"。如果用 Agent 工具派 10 个 subagent，10 份结果会作为 tool result 全部回到主上下文，然后你得在下一个回合用自己的脑子读完、决定怎么合；编排逻辑是临场判断，每一步协调都烧主上下文的 token。而 Workflow 把编排写成了代码，10 份中间结果不进主上下文，只回最终那份报告，schema 自动校验、并发自动管控。
|
||||
|
||||
不过得诚实地补一句：就**这一次**这种"一把梭 map-reduce"而言，两者差距其实没那么大——10 路并行、合一次就完了，subagent 也够用。Workflow 真正赚到的是随复杂度放大的那部分：当阶段变多、需要循环（一直找到连续 N 轮无新增）、需要多轮对抗式验证、或者要 fan-out 到几十个单元时，用 subagent 手动协调会非常痛，用脚本写就很自然。
|
||||
|
||||
## 和 N8N、Coze、Dify 的本质区别
|
||||
|
||||
看到"用代码编排多步流程 + 步骤里塞 LLM"，很容易冒出一个念头：这不就是 n8n、Coze（扣子）、Dify 那套吗？无非是现在让模型自动来编排。
|
||||
|
||||
这个直觉**抓住了最关键的共性**，但"唯一区别是模型自动编排"这句话，得往回拉一拉。
|
||||
|
||||
先说共性，而且这个共性比想象的更硬。Anthropic 在《Building Effective Agents》里给过一个权威定义：**Workflows 是 LLM 和工具通过"预定义代码路径"（predefined code paths）被编排的系统**；与之相对的 Agents，才是 LLM 在运行时动态指挥自己流程的系统。按这个定义，Dynamic Workflow 和 n8n/Dify/Coze 是**同一类**——它们的控制流都是确定性的，LLM 不会在运行时决定"下一步走哪条边"，脚本一旦写好，执行它的就是个无脑运行时，LLM 只在节点内部干活。真正不在这个范畴里的，是主对话那个 ReAct 式 agent（那才是模型实时决定下一步）。这一点的判断完全成立。
|
||||
|
||||
但"唯一区别"这个说法漏掉了两个更硬的差异。把它们摊开看：
|
||||
|
||||
|
||||
|
||||
把这张表压成一句话：**Workflow ≈ 把 n8n 那张图，换成模型现场生成的一段代码。** 它换掉了两样东西——作者（人 → 模型）和载体（可视化 DAG → 命令式代码）。第一样带来即时性和定制性（不用人预先搭，针对当次任务量身生成），第二样带来表达力的提升（能写循环和动态扇出，这是可视化 DAG 做不到的）。
|
||||
|
||||
|
||||
|
||||
至于"AI 自动编排"这个最抢眼的差异，还得再精确一点：**AI 的介入发生在"写代码"那一刻，不在"跑流程"那一刻。** n8n 是人写编排、运行时确定性执行；Workflow 是模型写编排、运行时确定性执行——执行期间模型在睡觉。两者跑流程的方式是一样的，差别只在编排脚本的作者是谁。
|
||||
|
||||
值得一提的是，两边其实在互相靠拢：Coze、Dify 都在加 agent 节点（节点本身变自主）和 code 节点（可以写 JS / Python），往"代码 + 自主节点"挪；而 Workflow 的脚本也能存进 .claude/workflows/ 当可复用产品，往"建一次反复用"挪。所以更准确的结论是：你的本质判断成立——都是确定性流程编排、LLM 当步骤；但区别不止"AI 自动编排"一条，还有**载体是图灵完备代码而非可视化 DAG**，以及**每个节点是个自主 agent 而非固定连接器**。
|
||||
|
||||
## 官方之前，怎么手搓一个 Workflow
|
||||
|
||||
既然 Workflow 本质是"确定性脚本 + 在节点处调 LLM"，那在官方推出之前，自己手搓一个类似的东西，完全可行。核心拼图就一个：claude -p。
|
||||
|
||||
claude -p（即 --print，headless 模式）会非交互地跑完一整个 agent loop——思考、调工具、改文件——跑完即退出。它读 stdin、写 stdout，可以像普通命令行工具一样接进管道。把每一步当成一次 claude -p 调用，外面用 shell 或 Python 写编排循环，就是 DIY 版的 Workflow：
|
||||
|
||||
```bash
|
||||
# fan-out：10 个批次并行，每个起一个 claude -p
|
||||
for f in batch_*.md; do
|
||||
claude -p "分析这个批次：$(cat $f)" --output-format json > "out_$f.json" &
|
||||
done
|
||||
wait # ← 屏障，等全部跑完，对应 parallel()
|
||||
|
||||
# reduce：把 10 份结果拼起来，再起一个 claude -p 综合
|
||||
claude -p "综合这些发现：$(cat out_*.json)" > report.md
|
||||
```
|
||||
|
||||
对照一下就会发现，这跟前面那个 133 会话的 Workflow 是同构的：& 加 wait 就是 parallel() 的屏障，$(cat ...) 拼字符串就是 prompt 里的变量插值。社区里这类实践不少，futuresearch.ai 那篇就用 claude -p 加文件系统轮询搭了一套 18 路并行的扫描流水线——子 agent 把结果写盘（成功写 .json、失败写 .error），编排器只轮询文件名而不把输出收进上下文，把复杂度从 O(n × 输出大小) 压到 O(n × 文件名)。
|
||||
|
||||
那官方 Workflow 比手搓版多了什么？答案是：模型没变，省掉的全是工程脏活。
|
||||
|
||||
|
||||
|
||||
一句话：**Workflow 是把这套手搓 harness 产品化了，省的是工程脏活，不是改变模型。** 理解了这一层，你对它的能力边界也就有了底——它不是什么魔法，就是一个把"claude -p + 编排循环"打磨得足够顺手的运行时。
|
||||
|
||||
## 什么场景该用 Workflow
|
||||
|
||||
不是每个任务都需要起一个 Workflow。它本质上是用大量并行 agent 换效率，而并行 agent 是实打实烧 token 的。那什么时候这笔账划算？
|
||||
|
||||
官方文档给出的适用场景集中在四类。
|
||||
|
||||
一是代码库范围的批量排查，比如全仓库 bug 扫描、性能剖析引导的优化审计、安全审计。这类任务的共同点是"搜索加独立验证"——Claude 并行搜遍整个服务，再对每个发现单独验证，确保报告里浮现的都是真问题。授权检查、输入校验、危险模式的全库加固也是同一个形状。
|
||||
|
||||
二是大规模迁移与现代化，框架替换、API 弃用迁移、跨语言移植都算，Bun 是其中最极致的例子。
|
||||
|
||||
三是需要反复推敲的关键决策。当错误答案的代价很高时，让 Claude 从多个独立角度各做一遍，再派对抗性的 agent 试图推翻这些结果，迭代到答案收敛为止——这种对抗式验证能逼近单次跑达不到的质量。
|
||||
|
||||
四是长尾清理，像 Bun 那个 overnight workflow，挂着自动扫描问题、逐个开 PR。
|
||||
|
||||
反过来，这几类任务用 Workflow 就是杀鸡用牛刀：一两步就能搞定的小修补、需要你中途频繁拍板的探索性工作、以及碰安全和支付这类高风险代码的改动。
|
||||
|
||||
把 Claude Code 现有的几种协作原语放一起，选型逻辑大致是这样：
|
||||
|
||||
|
||||
|
||||
一句话区分：需要"跑腿"用 subagent，需要"开会讨论"用 Agent Teams，需要"流水线作业"用 Workflow。
|
||||
|
||||
## 可用范围与怎么开
|
||||
|
||||
Dynamic Workflows 目前是研究预览状态，对版本和计划都有要求。
|
||||
|
||||
版本上需要 **Claude Code v2.1.154 或更高**。平台覆盖得相当全：CLI、Desktop、VS Code 扩展、Claude API，以及 Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry 三大云。
|
||||
|
||||
计划上的差异要留意：**Max、Team 以及通过 API 使用的场景，默认就开着**；Pro 计划默认关闭，需要去 /config 里的 Dynamic workflows 一行手动打开；Enterprise 计划发布时也默认关闭，得由管理员在设置里开启。第一次触发 Workflow 时，Claude Code 会把即将运行的内容摆给你看并要求确认，不会闷头就跑。
|
||||
|
||||
如果你想彻底关掉它，有几个层面的开关：
|
||||
|
||||
```json
|
||||
// ~/.claude/settings.json
|
||||
{
|
||||
"disableWorkflows": true
|
||||
}
|
||||
```
|
||||
|
||||
或者用环境变量，在启动时生效：
|
||||
|
||||
```bash
|
||||
export CLAUDE_CODE_DISABLE_WORKFLOWS=1
|
||||
```
|
||||
|
||||
个人也可以直接在 /config 里切换，组织层面则能通过 managed settings 或管理后台统一禁用。
|
||||
|
||||
## Token 成本：必须算的一笔账
|
||||
|
||||
这部分官方说得格外坦诚：**单次 Workflow 的 token 消耗，明显高于一次普通的 Claude Code 对话**。道理不复杂，几十上百个 subagent 同时跑，每个都在烧 token，再叠加交叉验证、对抗式 review 这些"额外冗余"的设计，账单自然往上走。前面那个 133 会话的案例，11 个 agent 就吃掉了 81.8 万 token——这还只是 10 路一把梭的轻量编排。这些消耗都计入你所在计划的用量和速率限制。
|
||||
|
||||
官方给的实用建议有几条可以记下来。一是**从一个范围明确的小任务开始**，先摸清楚它在你的工作里大概花多少，再决定要不要放手让它跑大活。二是大规模运行之前，先用 /model 确认自己在合适的模型上，并且可以要求 Claude 在那些不需要最强能力的阶段改用更小的模型——不是每一步都得动用最贵的脑子。三是前面提过的，提前把命令加进允许列表，避免中途被权限弹窗打断一个跑了几小时的任务。
|
||||
|
||||
好在 Workflow 随时可以叫停，已经完成的工作不会白费。
|
||||
|
||||
## 已知限制
|
||||
|
||||
研究预览阶段，几个边界先摆在这，省得踩到了再回来查：
|
||||
|
||||
- **运行中途不接受人工输入**：除了权限确认弹窗，Workflow 跑起来就不停下来等你拍板。需要分段签核的流程，得拆成多个独立的 Workflow。
|
||||
- **脚本本身没有文件和 shell 访问权限**：读写和执行全靠 subagent，脚本只负责调度。
|
||||
- **并发与总量都封顶**：最多 16 个并发 subagent，单次运行 1000 个 agent 上限。
|
||||
- **跨会话不可恢复**：退出 Claude Code 后，下次进来 Workflow 从头再跑。
|
||||
- **自定义 Workflow 怎么传参**：内置的 /deep-research 能接收一个问题参数，但你自己存的 Workflow 怎么传参，官方文档这块还语焉不详。
|
||||
- 整个功能仍在研究预览，行为和约束都可能随版本调整。
|
||||
|
||||
## 它在 Claude Code 体系里的位置
|
||||
|
||||
到这里，可以把 Claude Code 的几种扩展原语放在一张表里通盘看一遍：
|
||||
|
||||
|
||||
|
||||
这张表从上到下，编排权一步步从"你"转移到"Claude"，再转移到"代码"。Workflow 站在最右端——你只给一句任务描述，编排的活儿交给 Claude 写的脚本，规模冲到数百个 agent。
|
||||
|
||||
这里就要回到开头那个伏笔：为什么 Dynamic Workflows 和 Opus 4.8 同一天发布。当你让几百个 agent 并行干活、还要它们互相 review 彼此的结论时，每个节点的可靠性就被放大了——节点是概率性的 LLM，同一个问题换个角度问都可能给出不一致的答案，而多步流程里的不确定性会层层累积。Opus 4.8 这一代专门强化了这块：官方说它"**让代码缺陷悄悄溜过、不被发现的概率比前一代低了约四倍**"，更倾向于主动标记自己拿不准的地方。这种诚实性的提升，正是"数百 agent 交叉验证"这套打法能成立的前提——交叉验证要管用，前提是 reviewer 真的会指出问题，而不是一味点头。强模型不是 Workflow 的可选项，是它的承重墙。
|
||||
|
||||
最后把 Workflow 放进更大的图景里看。它把"编排逻辑代码化"作为一个明确的产品选择，这件事本身值得玩味：编排从模型每次现想现做的临时行为，变成了一段可以读、可以审、可以存、可以反复跑的代码资产。把它和 Codex 的 Goals 摆在一起看，会发现一个有趣的分野。两者都想解决"大任务怎么持续推进"，但路径相反：Codex Goals 押注的是**目标持久化**——把目标钉在那，让模型自己想办法一步步逼近；Claude Code Workflow 走的则是**编排代码化**这条路——把过程写成脚本，靠脚本保证流程不跑偏。一个管"往哪走"，一个管"怎么走"，是两套不同的工程哲学。哪条路最后跑得更远现在下结论还太早，但两家头部产品在"承载超大规模工作"这个问题上同时发力，本身就说明这是 AI Coding 下一阶段的主战场。
|
||||
|
||||
最后，说点我自己的判断。我觉得 dynamic workflow 这套东西相当强大，大概率代表了未来的方向。它能站住，靠的是两块拼图严丝合缝：一块是把"编排"从模型的临场发挥固化成可控的代码，另一块是一个足够诚实、足够强的前沿模型，撑得起几百个 agent 互相交叉验证——这也正是它要跟 Opus 4.8 同天登场的原因。前沿模型是地基，编排代码化则是让"几百个 agent 协作还不跑偏"成为可能的关键，两者缺一不可。
|
||||
|
||||
也正因为它对前沿模型的能力依赖得这么深，我的判断是：一年之内，这套"模型现写编排脚本、再调度一支 agent 舰队"的打法，会从某一家的研究预览，长成几乎所有 coding agent 的标配。
|
||||
|
||||
顺带一提，这篇文章背后的调研，本身就是一个 Workflow 跑出来的：**十五个 agent 并行**分头干活——精读一手对话记录、交叉比对业界资料——**27 万 token、169 秒**，最后汇成一份素材交回来。用 Workflow 把 Workflow 讲清楚，大概是对它最直接的一次试用。
|
||||
|
||||
## 参考资料
|
||||
|
||||
- [Dynamic workflows 官方文档](https://code.claude.com/docs/en/workflows)
|
||||
- [Introducing dynamic workflows in Claude Code（官方发布博客）](https://claude.com/blog/introducing-dynamic-workflows-in-claude-code)
|
||||
- [Claude Opus 4.8 发布说明](https://www.anthropic.com/news/claude-opus-4-8)
|
||||
- [Run agents in parallel（官方对比 subagent / agent teams / workflow）](https://code.claude.com/docs/en/agents)
|
||||
- [Building Effective Agents（Anthropic 对 workflow 与 agent 的定义）](https://www.anthropic.com/research/building-effective-agents)
|
||||
- [Headless / \`claude -p\` 官方文档](https://code.claude.com/docs/en/headless)
|
||||
- [Bun “Rewrite Bun in Rust” PR（oven-sh/bun #30412）](https://github.com/oven-sh/bun/pull/30412)
|
||||
193
1 - Inbox/Claude Code 工程化指南：高效组织 .claude 目录.md
Normal file
193
1 - Inbox/Claude Code 工程化指南：高效组织 .claude 目录.md
Normal file
@@ -0,0 +1,193 @@
|
||||
---
|
||||
title: "Claude Code 工程化指南：高效组织 .claude/ 目录"
|
||||
source: "https://x.com/vincemask/article/2056757482152960110"
|
||||
author:
|
||||
- "[[Vince 聊开发 (@vincemask)]]"
|
||||
published: 2026-05-19
|
||||
created: 2026-05-20
|
||||
description: "为什么结构很重要？大多数 Claude Code 用户知道 .claude/ 文件夹的存在，但很少有人认真思考它的组织方式。项目小的时候，一个 CLAUDE.md、几个设置文件就够了。但随着项目增长，指令变得难以维护，工作流散落在错误的地方，文件夹慢慢变成有用配置和难以解释的混乱..."
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
|
||||
|
||||
# 为什么结构很重要？
|
||||
|
||||
大多数 Claude Code 用户知道 .claude/ 文件夹的存在，但很少有人认真思考它的组织方式。项目小的时候，一个 CLAUDE.md、几个设置文件就够了。但随着项目增长，指令变得难以维护，工作流散落在错误的地方，文件夹慢慢变成有用配置和难以解释的混乱的混合物。
|
||||
|
||||
一个组织良好的 .claude/ 文件夹让 Claude 更容易被引导、被信任，也更容易在真实项目中扩展。
|
||||
|
||||
# 目标结构蓝图
|
||||
|
||||
```markdown
|
||||
your-project/
|
||||
├── CLAUDE.md # 主项目指令
|
||||
├── CLAUDE.local.md # 个人覆盖（不提交）
|
||||
└── .claude/
|
||||
├── settings.json # 控制层
|
||||
├── settings.local.json # 本地覆盖
|
||||
├── rules/ # 模块化指令
|
||||
├── hooks/ # 自动化脚本
|
||||
├── commands/ # 可复用提示词工作流
|
||||
├── skills/ # 打包能力
|
||||
└── agents/ # 专用子代理
|
||||
```
|
||||
|
||||
# 核心原则
|
||||
|
||||
## 1\. 顶层要轻
|
||||
|
||||
- CLAUDE.md：解释项目如何工作（栈、架构、关键命令、全局约定）
|
||||
- .claude/settings.json：控制 Claude 在项目中的操作方式（权限、hooks、项目级行为）
|
||||
- CLAUDE.local.md / .claude/settings.local.json：个人覆盖，不进git版本控制
|
||||
|
||||
这两层分开：一个负责**引导**，一个负责**控制**。
|
||||
|
||||
## 2\. CLAUDE.md 与 rules/ 的划分
|
||||
|
||||
**CLAUDE.md 放全局指导**——每次会话都需要的内容：
|
||||
|
||||
- 主要技术栈
|
||||
- 高层架构
|
||||
- 最重要的开发命令
|
||||
- 广泛适用的代码约定
|
||||
- 项目级警告或约束
|
||||
|
||||
**rules/ 放专项指导**——某个领域或工作流的规则：
|
||||
|
||||
```markdown
|
||||
.claude/
|
||||
└── rules/
|
||||
├── frontend.md
|
||||
├── backend-api.md
|
||||
├── testing.md
|
||||
└── data-pipelines.md
|
||||
```
|
||||
|
||||
什么时候应该拆分成 rules/：
|
||||
|
||||
- CLAUDE.md 开始显得拥挤
|
||||
- 不同仓库区域需要不同指导
|
||||
- 不同人有不同标准
|
||||
- 团队经常更新约定
|
||||
- 想按路径限定指令作用域
|
||||
|
||||
CLAUDE.md 建议参考这篇文章进行调整
|
||||
|
||||
> May 7
|
||||
|
||||
## 3\. hooks/ 和 commands/ 分工
|
||||
|
||||
**hooks/**：自动运行的脚本，不放在说明文档中
|
||||
|
||||
- 拦截危险操作（如 [block-dangerous-commands.sh](https://block-dangerous-commands.sh/)）
|
||||
|
||||
清理或验证输出（如 [format-edits.sh](https://format-edits.sh/)）
|
||||
|
||||
强制执行工作流要求（如 [run-tests-before-stop.sh](https://run-tests-before-stop.sh/)）
|
||||
|
||||
**commands/**：可复用的提示词工作流，不是自动运行的
|
||||
|
||||
- 审查 PR（review-pr.md）
|
||||
- 编写测试（write-tests.md）
|
||||
- 为发布准备变更摘要（summarize-changes.md）
|
||||
|
||||
```markdown
|
||||
.claude/
|
||||
├── hooks/
|
||||
│ ├── block-dangerous-commands.sh
|
||||
│ ├── format-edits.sh
|
||||
│ └── run-tests-before-stop.sh
|
||||
└── commands/
|
||||
├── review-pr.md
|
||||
├── write-tests.md
|
||||
└── summarize-changes.md
|
||||
```
|
||||
|
||||
命名要清晰：[format-edits.sh](https://format-edits.sh/) 好过 [script1.sh](https://script1.sh/)。
|
||||
|
||||
## 4\. skills/ 和 agents/ 的进阶结构
|
||||
|
||||
**skills/**：打包的能力，工作流有多个步骤、需要配套文档时使用
|
||||
|
||||
```markdown
|
||||
.claude/
|
||||
└── skills/
|
||||
├── release-prep/
|
||||
│ ├── SKILL.md
|
||||
│ └── release-template.md
|
||||
└── docs-audit/
|
||||
├── SKILL.md
|
||||
└── style-guide.md
|
||||
```
|
||||
|
||||
**commands/ vs skills/** 的区别：
|
||||
|
||||
- commands/ = 轻量可复用任务（一个文件就够了）
|
||||
- skills/ = 更丰富的打包工作流（多个步骤 + 配套文档）
|
||||
|
||||
**agents/**：专用子代理，需要更聚焦的角色时使用
|
||||
|
||||
```markdown
|
||||
.claude/
|
||||
└── agents/
|
||||
├── code-reviewer.md
|
||||
├── security-auditor.md
|
||||
└── docs-writer.md
|
||||
```
|
||||
|
||||
每个 skill 解决一个重复出现的完整工作流，每个 agent 拥有一个专门角色。如果两个文件高度重叠，应该合并或简化。
|
||||
|
||||
## 5\. 团队结构 vs 个人结构的分离
|
||||
|
||||
```markdown
|
||||
# 项目级（团队共享）
|
||||
your-project/
|
||||
├── CLAUDE.md
|
||||
└── .claude/
|
||||
├── settings.json
|
||||
├── rules/
|
||||
└── hooks/
|
||||
|
||||
# 用户级（个人偏好）
|
||||
~/.claude/
|
||||
├── CLAUDE.md
|
||||
├── settings.json
|
||||
├── skills/
|
||||
├── agents/
|
||||
└── projects/
|
||||
```
|
||||
|
||||
**判断标准**：如果配置帮助整个团队更一致地工作 → 放项目级。如果主要反映一个人的工作流 → 放本地或全局设置。
|
||||
|
||||
**本地覆盖文件**：CLAUDE.local.md 和 .claude/settings.local.json 是很好的中间层，让人可以在不污染版本控制的情况下调整行为。
|
||||
|
||||
# 渐进式成长路径
|
||||
|
||||
不要一开始就填满所有文件夹。按需增加：
|
||||
|
||||
1. **起步**：CLAUDE.md + .claude/settings.json
|
||||
2. **指令膨胀**：加 rules/
|
||||
3. **需要自动化**：加 hooks/
|
||||
4. **提示词重复**：加 commands/
|
||||
5. **工作流变深**：加 skills/
|
||||
6. **需要专精角色**：加 agents/
|
||||
|
||||
# 常见错误
|
||||
|
||||
|
||||
|
||||
# 关键要点
|
||||
|
||||
最高效的 .claude/ 文件夹不是功能最丰富的，而是**每个部分都有清晰用途**的。好的结构应该能立即回答这些问题：
|
||||
|
||||
- 项目级指令在哪里？
|
||||
- 模块化规则放哪里？
|
||||
- 自动化脚本放哪里？
|
||||
- 可复用工作流放哪里？
|
||||
- 哪些是共享的，哪些是私人的？
|
||||
- 哪些是活跃的，哪些只是实验？
|
||||
|
||||
当 .claude/ 组织好了，Claude 用起来会可预测、可维护、易于团队共享。
|
||||
|
||||
|
||||
1510
1 - Inbox/Team Communication Playbook.md
Normal file
1510
1 - Inbox/Team Communication Playbook.md
Normal file
File diff suppressed because it is too large
Load Diff
680
1 - Inbox/创始人行动手册：打造一家 AI-Native 创业公司.md
Normal file
680
1 - Inbox/创始人行动手册：打造一家 AI-Native 创业公司.md
Normal file
@@ -0,0 +1,680 @@
|
||||
---
|
||||
title: "创始人行动手册：打造一家 AI-Native 创业公司"
|
||||
source: "https://x.com/AlchainHust/article/2056595872754848232"
|
||||
author:
|
||||
- "[[花叔 (@AlchainHust)]]"
|
||||
published: 2026-05-19
|
||||
created: 2026-05-20
|
||||
description: "译自 Anthropic 官方手册《The Founder's Playbook: Building an AI-Native Startup》 2026 年 5 月发布花叔注：这是 Anthropic 五月发布的一份创始人手册。三十六页，把 AI 时代的创业生命周期重新画了一遍..."
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
|
||||
|
||||
译自 Anthropic 官方手册《The Founder's Playbook: Building an AI-Native Startup》 2026 年 5 月发布
|
||||
|
||||
花叔注：
|
||||
|
||||
这是 Anthropic 五月发布的一份创始人手册。三十六页，把 AI 时代的创业生命周期重新画了一遍。
|
||||
|
||||
这本手册主要讲的是，当一个人就能完成过去一整支团队的工作时，创业流程会变成什么样。它把这件事拆成四个阶段：想法、MVP、发布、规模化。每个阶段先讲目标和退出条件，再讲容易踩的坑，最后才是 Claude 怎么用。
|
||||
|
||||
我觉得最值得读的部分，其实是「容易踩的坑」那几节。比如「把『造』误当作『验证』」「AI 把确认偏误装上了一台研究引擎」「零摩擦的范围蔓延」——这些都是在 AI 让一切变得太容易之后，反而会暴露出来的新风险。
|
||||
|
||||
我尽量做了贴近原意的翻译，保留了一些英文专有名词（PMF、TAM、GTM、[CLAUDE.md](http://claude.md/) 等），因为强行中译会失真。
|
||||
|
||||
全文约两万五千字，是一篇能完整读完的长文。也可以收藏起来，按阶段对照你当前的处境来翻。
|
||||
|
||||
———
|
||||
|
||||
## 第一章 创业生命周期，为 2026 重新启动
|
||||
|
||||
AI 正在重塑创业公司的建造方式。今天，从未写过一行代码的创始人正在交付生产级应用，而「10 人独角兽」也从草根传奇变成了一套可以被认真规划的行动方案。
|
||||
|
||||
到 2026 年，AI 可以写生产环境代码、做市场调研、梳理竞争格局、起草投资人材料，并自动化运营流程。它抹平了过去很陡的学习曲线：即使经验丰富的技术创始人，以前也要花大量时间整合工具、平台和系统，才能把想法落地。**AI 最重要的贡献，是把「谁能启动一家公司、谁能做出一个产品」这件事的门槛拉平了。**
|
||||
|
||||
2026 年，一个好想法能把创始人带到比以往任何时候都更远的地方。Agentic 编程把过去需要一整支工程团队完成的工作，压缩成了创始人自己就能交付的体量。
|
||||
|
||||
传统创业增长曲线默认路径是：验证 → 融资 → 招人 → 建造 → 再融资 → 增长 → 继续招人 → 重复。现在，AI 已经抹掉了一个默认预期：创业生命周期的每个新阶段，都必须配更大的团队、不同的技能组和新一轮融资。
|
||||
|
||||
这本手册会按照这些新现实，重新绘制创业旅程的四个核心阶段：想法、MVP、发布、规模化。我们会逐阶段看：当 AI 成为技术和组织发展的核心基础设施时，每个阶段长什么样；每个阶段该用哪些工具；以及走在前面的创始人如何用这些工具压缩时间线。
|
||||
|
||||
———
|
||||
|
||||
## 第二章 「创始人」这件事正在改变
|
||||
|
||||
过去，创始人是被「能做什么」定义的：技术型创始人写代码，非技术型创始人跑业务、谈合同。但 2026 年创始人可用的模型、系统和 AI agent，已经溶解了「能造东西的人」和「有想法值得造的人」之间那堵墙。
|
||||
|
||||
AI-Native 创业公司正在从根本上改变「成为创始人」的含义。**现在，一个完全没有工程背景的人，可以做出真正能跑的生产级软件来实现自己的想法**；而一个技术很强但商业知识有限的创始人，也能轻松产出 GTM 策略、财务模型和高度打磨的 pitch deck。
|
||||
|
||||
从历史上看，创始人大部分时间都在执行模式里：写代码、管人、处理日常运营。**在 AI-Native 创业公司里，创始人的角色不再只是个人贡献者，而更像是一群 agent 的编排者。** 这些 agent 是专门化的 AI 助手，能读文件、跑命令、执行代码，甚至浏览网页。创始人的注意力开始上移，转向更高阶的工作：产生想法，并指挥 AI agent、工具和小团队把想法落实。
|
||||
|
||||
AI 作为核心基础设施最革命性的结果，是它解锁了有领域专长的非技术背景创始人。当创始人池不再只来自工程背景，你会看到由完全不同人生经验的人创建的公司，去解决传统技术创始人输送管道从未优先关注，甚至从未注意到的真实问题。
|
||||
|
||||
AI 为精益创业带来的能力
|
||||
|
||||
传统创业模型假定你必须招工程师来造、招销售来卖、招运营来跑公司。「人头数」被看作组织势能和产品成熟度的标志。
|
||||
|
||||
2026 年的早期创业公司则完全不同。它们在设计上极度精益，往往只有创始人一人，或加上少数伙伴。把技术与组织发展都建立在 AI 这一基础设施之上，它们可以在扩张团队之前就达成产品验证、产生早期收入，甚至盈利。AI 在三个地方能让一家创业公司像大得多的组织一样运转：研究、Agentic 编程、以及关键业务运营的工作流自动化。
|
||||
|
||||
对话式智能与研究
|
||||
|
||||
类比：任何领域随叫随到的专家。
|
||||
|
||||
想想看，一个创始人在第一年里几乎肯定不知道但又必须知道的事情：怎么搭工资发放系统？怎么规划产品开发冲刺？怎么写一份紧凑的投资人备忘录？
|
||||
|
||||
早期创业的这类问题过去几乎都是同一个答案：找一个懂的人。对一个自筹资金或种子前的创始人来说，这意味着把本该用来建造的时间花在打听上，或者把早期资金烧一部分给顾问。现在，他们手里就有一个跨几乎所有领域、随时在岗的专家：AI。
|
||||
|
||||
- 深度研究：竞品分析、市场规模测算、财务建模
|
||||
- 文档起草：pitch deck、案例研究、投资人备忘录、PRD
|
||||
- 战略思考伙伴：反方代言人分析、事前剖析、情境推演、路线图优化
|
||||
|
||||
Agentic 编程
|
||||
|
||||
类比：那位永远在线、永不被卡住的工程师。
|
||||
|
||||
过去，要做出软件，要么得有一个技术合伙人，要么外包给开发公司，要么有足够长的跑道，先招够一支工程团队，然后才能写下第一行生产代码。
|
||||
|
||||
Agentic 编程工具如今让每一个有想法的创始人，都可以用平实语言描述自己想做什么，然后指挥 AI 生成、测试、调试、重构一份生产级代码库，速度和体量都堪比一支完整工程团队。
|
||||
|
||||
从「我有一个想法」到「我有一个产品」的时间线被压缩了。**创始人的角色现在聚焦在「该做什么、为什么做」，而 AI 负责真正的基础设施搭建**，那些直接面对真实用户的部分。
|
||||
|
||||
工作流自动化
|
||||
|
||||
类比：一支随时听用的自动化运营团队。
|
||||
|
||||
即使创始人能像顾问一样研究、像工程团队一样写代码，战略规划和产品开发之外仍有整整一类工作必须完成：排期、更新 CRM、拉周报、维护文档、发布内容、追踪合规要求、管理公司赖以运转的工具和系统之间的连接。这些也都要发生。在精益创业公司里，这些负担主要落在创始人身上，并且会大量侵占本该用于高阶判断的时间和注意力。
|
||||
|
||||
AI 工具的工作流自动化能卸掉这笔税。重复性运营任务可以被配置为自动发生：交易状态变化时 CRM 自动更新，周报自己汇总，产品文档跟随产品变化同步更新。关键在于，Claude Cowork 能集成创业公司使用的互联系统，例如项目管理工具、沟通栈、数据源，而不需要有人专门构建并维护这些集成。在第零天创业公司里，那个人几乎总是创始人本人。
|
||||
|
||||
时机和编排，是一切
|
||||
|
||||
能有效驾驭 AI 的研究能力、自动化能力和 agentic 编程能力的创始人，能用远超团队规模所暗示的杠杆来运营一家公司。他们也能把大部分时间和带宽，放在那些真正重要的工作上。
|
||||
|
||||
但这套东西不会自动巡航。负责编排这些 AI 工具的创始人，必须知道如何用、什么时候用。本手册剩下的部分，就是探索 AI-Native 创业路径上每一阶段的目标、挑战，以及如何在旅程的每个阶段有效应用 AI 工具。
|
||||
|
||||
———
|
||||
|
||||
## 第三章 想法阶段
|
||||
|
||||
每个创业的创始人都从同一个地方出发：一个让你停不下来去想的问题。这就是创业里想法撞上现实的阶段。**2026 年的创业成功，要求你具备一种纪律：在证据足够之前，不动手造。**
|
||||
|
||||
这一阶段的工作是研究、客户发现、竞品分析、以及对反证的诚实评估。所有这些，都要发生在你打开 Claude Code 让它写下第一行生产代码之前。
|
||||
|
||||
想法阶段·目标
|
||||
|
||||
在想法阶段，创始人的核心目标是以研究为导向的验证：在投入资源开始造东西之前，攒起扎实证据来证明一个真实问题确实存在，并且你提议的方案确实有效解决它。
|
||||
|
||||
具体来说，想法阶段是一系列大致按以下顺序回答的问题：
|
||||
|
||||
- 这个问题是真实的、具体的、足够高频的，值得围绕它做一家公司吗？
|
||||
- 到底谁有这个问题？这些人能构成一个市场吗？
|
||||
- 是否已经有人在解决它？如果是，他们怎么做，做得多好？
|
||||
- 一个真正解决这个问题的方案需要做到什么？我的想法做到了吗？
|
||||
|
||||
这些问询加起来，回答一个终极问题：这值不值得做？
|
||||
|
||||
也就是说，先具体，再行动。「报销报告让人头痛」是观察。「中型市场公司的财务经理每周要花 4 小时以上核对报销提交，因为现有工具不和会计软件打通」才是一个可以测试的假设。
|
||||
|
||||
想法阶段·退出标准
|
||||
|
||||
想法阶段的退出条件，是找到 problem-solution fit（问题-方案匹配）。你要在开始造解决方案之前，建立起质性证据，主要来自真实的人类对话，证明你正在为真实的人解决真实问题。
|
||||
|
||||
当你能对以下三个问题都答「是」时，就准备好离开想法阶段了：
|
||||
|
||||
- 这个问题真实且具体吗？你必须能说出谁经历这个问题、多频繁、影响多严重、目前他们怎么处理它。
|
||||
- 你的方案是否对应了真实问题？不是你最初设想的问题，而是验证过程里浮现出来的那个。有时两者相同，但并不总是。
|
||||
- 你有足够信号去开干吗？你在这个阶段永远不会有 100% 确定，等到完全确定本身就是失败模式。但你需要足够质性证据，让投入做 MVP 看起来是有理有据的决定，而不是一场信仰行动。
|
||||
|
||||
想法阶段·挑战
|
||||
|
||||
想法阶段是创业旅程里最重要的工作发生的地方，因为最具后果性的错误就在这里酿成。现在搞错一点，能很快把刚起步的事业带偏。多数想法阶段的挑战，归根到底都是前进速度超过了理解所能支撑的范围。所以，带着思考和审慎前行的创始人，才能稳步推进。
|
||||
|
||||
**把「造」误当作「验证」**
|
||||
|
||||
挑战：当技术障碍被移除，一个被激情冲昏头的创始人，可能会跳过创业旅程里最重要的工作：验证自己的想法是不是人们真正需要、也真正会用的方案。
|
||||
|
||||
即使在 agentic 编程时代之前，也有 42% 的创业公司失败，是因为它们做了没人想要的东西。现在，像 Claude Code 这样的 agentic 编程方案，已经大幅压缩「我有一个想法」到「我有一个产品」之间的距离，这个失败率只会继续上升。
|
||||
|
||||
现在确实是怀揣绝妙点子的创业者最好的时代，但**一个看起来像产品的原型竟然可以如此快速、轻松地搭出来，反直觉地，这恰恰给 AI-Native 创业公司带来真正危险的存在性风险。**
|
||||
|
||||
直到不久前，造东西仍需要真金白银的开发时间和预算，连搭个最基本的原型通常都要数月。如今技术开发门槛基本消失，AI 让创始人太容易直接跳进建造，完全跳过验证它在真实世界里是否有用。
|
||||
|
||||
要达到问题-方案匹配，必须先验证假设、再开始造。但许多首次创业者，甚至有经验的创业者，都错误地以为 AI 能让这一要求短路，把流程改成：有想法 → 立刻造原型 → 把「原型存在」当作验证。
|
||||
|
||||
一个能跑的原型很容易被误当作「我在解决真实问题」的具体证据，但它不是。原型只是你和潜在用户对话时一个有用的压力测试道具。这些对话本身，才是真正证据。
|
||||
|
||||
**过早规模化**
|
||||
|
||||
挑战：当造东西既不费力又即时，你的执行速度可以远远超过业务真正需要的水平。
|
||||
|
||||
过早规模化意味着：在还没有真正验证这条产品路径值得投入之前，你就已经把自己锁进去了。
|
||||
|
||||
这一直是创业杀手，但 AI 让创始人更容易在毫无察觉时掉进这个陷阱。Agentic 编程助手太强大了，以至于执行很容易跑在问题-方案匹配验证之前，而你甚至没有意识到自己已经偏航。
|
||||
|
||||
它会围绕一个根本错误的前提，带着同样的热情生成、测试、调试、重构代码库。系统里的智能是你的。这个阶段的最高指令是：让你的判断力始终走在建造之前，尤其是在建造如此快速、感觉如此轻松的时候。
|
||||
|
||||
**客观性丧失**
|
||||
|
||||
挑战：让 AI 工具去找支持你既有看法的证据，它一定能找到。**确认偏误如今配备了一台研究引擎。**
|
||||
|
||||
确认偏误一直是创业里的职业病：创始人天然对自己的想法充满热情。现在，AI 工具给确认偏误加了很强的外挂。让 AI 验证你的创业想法，它能找出佐证；让它估算潜在市场，它能找到让 TAM 看起来值得融资的数字。
|
||||
|
||||
AI 会沿着你的方向走。这意味着，一个不问难题的创始人，如今能比以往任何时候都更快地构建出一套精致、看似研究充分的坏点子论据，同时还觉得自己正在做尽调。解药还是同一个工具，只是把方向反过来：AI 同样能像验证想法那样彻底地压力测试它。当研究和结构化对抗性思考浮现证据、提示想法需要修正时，这就是 pivot 的信号。
|
||||
|
||||
Claude 如何帮助想法阶段的创始人
|
||||
|
||||
把你的 AI-Native 创业概念推进到走出想法阶段，可能感觉漫长无比。你是创始人，你只想动手造。但这个至关重要的启动阶段，本质上是一次研究和验证练习，意味着你应该先用那些帮助你想得更严谨的工具，而不是急着写代码。
|
||||
|
||||
**Chat、Claude Cowork，还是 Claude Code：怎么选合适的 Claude 产品面**
|
||||
|
||||
AI 让创业者能更快交付、自动化繁琐工作流，并在规模上运作起来。但你用哪一面，取决于手头任务。
|
||||
|
||||
- Chat 适合无需离开当前 app 就能完成的快速交流：从密集投资人备忘录里提炼一句话总结、在董事会前快速核查一个论断、读懂团队里一条很长的 Slack 串。
|
||||
- Claude Cowork 适合真正需要时间的知识工作：从多个来源拉资料、整理并产出完成品，比如文档、deck 或电子表格。
|
||||
- Claude Code 是团队工程师的 agentic 编程环境：代码库访问、Plan Mode、git 集成、本地、IDE 或沙盒云环境。它是精益团队跨成长中的代码库交付功能、迁移 MVP 遗留代码、把原型推到生产的地方。
|
||||
|
||||
三者底层是同一个 Claude；变的是它周围的工作空间。
|
||||
|
||||
**定义并压力测试问题假设**
|
||||
|
||||
你自己的领域专长和前期研究已经产生了一个假设。第一项工作是把它打磨到真正可被测试。Claude 在这里特别有用，它会强迫你具体：究竟谁有这个问题？多频繁？多严重？他们目前怎么处理？任何不能精确回答这些问题的问题陈述，都还没准备好被验证。
|
||||
|
||||
练习：和 Claude 一起反复打磨你的问题陈述，直到它变成一个可被测试的假设。比如「合同审查耗时太长」没什么意义；但「中型公司的法务团队每个合同审查周期要花 3 天以上，因为修订意见散落在邮件串里，而不是一份带版本控制的文档」就非常可测试。
|
||||
|
||||
下一步，请 Claude 反过来论证你的想法，找反证。这能浮现负面市场信号、失败竞品、客户行为模式、以及那些被支持性综述悄悄降权的结构性障碍。
|
||||
|
||||
目标是：在进入客户发现之前，你已经拿最强的反方论据压力测试过自己的假设。这样，用户访谈才会真正开放，而不是一场寻找确认的行动。
|
||||
|
||||
注：把 Claude 当作结构化的反方代言人来用，是 AI 创业生命周期每个阶段的核心用法。
|
||||
|
||||
**市场研究与竞争格局图谱**
|
||||
|
||||
给竞品大小定个位
|
||||
|
||||
创业公司有一种特有现象叫「竞品忽视」：你太专注于自己的愿景和执行，以至于系统性低估同一空间里其他人在做什么。幸运的是，AI 提供了解药：让 Claude 为这个解决方案空间里的某个竞品写出最有说服力的论证，说明为什么它会成功而你不会。
|
||||
|
||||
Claude 可以分析为什么对方的方法其实更好，为什么客户会选择它，为什么你以为的差异化可能没有那么守得住。
|
||||
|
||||
练习：让 Claude 按层级绘制你的竞争格局：直接竞品、间接竞品、潜在收购方、以及可能进入你所在空间的相邻玩家。然后让它论证每一层为什么会对你的成功构成真实威胁，而不是只列出最容易被你驳倒的威胁版本。
|
||||
|
||||
市场研究
|
||||
|
||||
Claude Code 可以综合公开可得的客户反馈，浮现反复出现的抱怨和未满足需求。额外好处是，这几乎等于免费研究竞品客户。
|
||||
|
||||
练习：指挥 Claude Cowork 汇总关键来源里的竞品评论，找出现有方案仍未解决的高频抱怨。如果你的假设能解决其中一个或多个，这是问题-方案匹配的强信号；如果不能，也值得知道。
|
||||
|
||||
Claude Cowork 还可以从密集的行业报告、分析师文件和市场研究文档中提取相关信息和数字。接下来，这些干净、合成后的输入，会成为 Claude 分析工作的理想上下文。
|
||||
|
||||
练习：基于公开数据构建 TAM/SAM/SOM 模型，并压力测试背后的假设。识别市场是在扩张、整合还是成熟；这个背景会影响你对时机和差异化的判断。再画出买方格局：谁掌握预算，谁影响决策，他们是不是同一个人。
|
||||
|
||||
趋势分析
|
||||
|
||||
最后，用 Claude 倾听早期指标，判断你是否在正确的时刻进入。追踪那些已经在讨论你的问题的 subreddit 和 LinkedIn 群组，记录用户描述问题时使用的原话。让 Claude 识别相似问题曾被解决过的类比市场，并提取哪些做法有效、哪些无效。浮现可能加速或威胁机会的监管、技术或人口趋势。
|
||||
|
||||
练习：让 Claude 找出三个可能在未来两年显著影响你市场的外部趋势，监管、技术或人口均可，并判断它们分别是你特定假设的顺风还是逆风。
|
||||
|
||||
注：本节里的市场研究与竞争图谱不是一次性练习。你会在 MVP 和发布阶段继续发现、继续演进思考，所以每当假设发生变化，都要重复这些练习。
|
||||
|
||||
**规划并设计客户发现**
|
||||
|
||||
你从潜在用户对话中学到什么，取决于两件事：你问的问题质量，以及你是否把这些问题问给了对的人。Claude 特别适合帮助你设计客户发现，包括找谁聊、问什么、以及如何理解听到的内容。
|
||||
|
||||
找谁聊
|
||||
|
||||
一个精确的目标画像，比一长串联系人更有价值。画像应包括最可能强烈经历这个问题的具体职位、公司类型、团队结构和资历层级。接着，识别这些人实际在哪里能被触达：社区、活动、LinkedIn 群组、Slack 工作区。最后建立一个优先级框架，根据他们离问题有多近，决定先触达谁。
|
||||
|
||||
问什么
|
||||
|
||||
目标人群定义好之后，用 Claude 搭建访谈框架：正确的问题、正确的顺序，结构要能浮现人们实际做了什么，而不是他们以为自己会做什么。**新手创始人常犯的错误，是问一个泛泛的未来式开放问题，比如「你会用这样的东西吗？」而不是追问相关的过去，比如「跟我讲讲你上一次处理这个问题的过程」。**
|
||||
|
||||
Claude 也能指出你的草稿问题哪里在诱导受访者、哪里太宽泛、哪里会产生噪音而不是信号。它还可以帮你设计追问，用来处理回避回答，或深入挖掘那些重要但含糊的答案。
|
||||
|
||||
如果你的假设涉及多个 persona，Claude 也能为每类人设计不同问题组。财务经理和 CFO 面对同一个问题的关系并不一样，单一访谈框架会把这种差异抹平。
|
||||
|
||||
练习：先手写访谈问题，再让 Claude 审查。明确要求它标出任何诱导性、面向未来、过宽、或容易产生社会期许答案而非真实答案的问题。然后让它为访谈中最可能出现回避的两三个时刻设计追问。
|
||||
|
||||
访谈后分析
|
||||
|
||||
每次对话后，用 Claude 复盘：把笔记喂给它，让它指出什么确认了你的假设、什么挑战了它、什么是真正意外的。
|
||||
|
||||
收集一批访谈后，把完整访谈笔记交给 Claude Cowork，让它浮现反复出现的主题、矛盾、以及正反两个方向最强的信号。再把合成结果带回 Claude，让它指出：你对数据的解读，哪里可能是在把信息匹配成你想听到的样子，而不是数据真正呈现的样子。
|
||||
|
||||
练习：每完成五次访谈，就让 Claude Cowork 综合笔记并产出两张清单：支持你假设的证据，以及挑战你假设的证据。如果第一张清单明显更长，让 Claude 判断这种不对称是数据本身如此，还是你原本就希望找到这些东西。
|
||||
|
||||
客户触达与排期
|
||||
|
||||
用 Claude Cowork 自动化建立联系人列表、跑触达、安排用户访谈这些运营负担。
|
||||
|
||||
Claude Cowork 可以使用你和 Claude 定义的目标画像，包括职位、公司类型、资历层级，研究并整理结构化的潜在客户名单和已验证联系方式。随后，它可以批量起草个性化触达邮件，让每封邮件贴合对方的角色和处境。
|
||||
|
||||
当回复进来后，它通过 MCP 连接 Gmail 和 Google Calendar，管理邮件串、处理排期请求、把访谈放到日历上。流程还会继续：Claude Cowork 按设定节奏生成跟进草稿，比如第七天跟进未回复联系人，并在每一步完成时更新追踪表，让你始终知道每个潜在对象在管道里的状态。
|
||||
|
||||
练习：把验证后的访谈目标画像交给 Claude Cowork，请它建立潜在客户列表、起草个性化触达序列，并建立一张追踪表，包含触达状态、跟进节奏和访谈完成情况。然后让它负责协调，你专注准备对话本身。
|
||||
|
||||
**设计你的最终方案概念**
|
||||
|
||||
你已经完成验证工作：问题真实存在，你知道谁有这个问题，也有一个被证据支持的方案概念。用 Claude 从各个角度发展并挑战你的方案概念：缺口在哪里？有哪些替代方案？这个方案要想规模化成立，必须满足哪些条件？这是一个重要的现实检查：这个设计是否真的对应验证过程揭示的问题，而不是你一开始以为的问题？
|
||||
|
||||
练习：把你的方案概念交给 Claude，让它识别这个设计最依赖的三个假设。然后追问：每个假设要成立，必须有哪些条件？如果任何一个假设不成立，后果是什么？
|
||||
|
||||
**用 Claude Code 搭一个轻量原型**
|
||||
|
||||
现在到好玩的部分了：有了被验证的假设和经过压力测试的方案概念，你终于准备好做点东西了。
|
||||
|
||||
这就是想法阶段里 Claude Code 登场的时刻。即使你之前一直在小修小补，现在才是生成正式轻量原型的节点：只做最小的产品表面，让你能把想法放到真实的人面前，获得真实反应。
|
||||
|
||||
**你还不是在造一个真实世界产品，而是在构建一份功能样本，用于客户和投资人对话。** 真实用户触碰一个能实际操作的东西，会告诉你十几次问题-方案访谈都无法告诉你的事。此前你是在证明要解决的问题真实存在；现在，你是在邀请潜在用户参与拟议的解决方案。
|
||||
|
||||
练习：定义你的方案所依赖的单一核心交互。指挥 Claude Code 只做这一件事。做好后，把它放到五个来自已验证目标画像的人面前，请他们试用。你在这五次对话里学到的东西，将决定你是继续建造，还是回到画板。
|
||||
|
||||
走到想法阶段的尽头，是 AI 创业赛跑里的一大跃迁。因为你不再是在赌一个直觉，你是在对着证据执行。
|
||||
|
||||
接下来进入 MVP 阶段。创始人的指导问题从「这值不值得做？」转向「到底先造什么？」而 AI 的主要角色，也从研究伙伴切换为施工队。
|
||||
|
||||
———
|
||||
|
||||
## 第四章 MVP 阶段
|
||||
|
||||
很多创始人把 MVP 阶段当作一个施工阶段，但 **MVP 阶段本质上仍是一次证据收集练习**。区别在于，这次你收集的是关于解决方案空间的证据，而不再是问题空间：一个真实、可识别的人群是否觉得这个产品有价值到愿意使用、回来再用、付费，或者推荐给别人。
|
||||
|
||||
MVP 阶段·目标
|
||||
|
||||
作为一家 AI-Native 创业公司的创始人，你的目标是把验证过的问题，翻译成一个真实用户会用的可工作产品。它不是带齐每个路线图功能的完整版本，而是你的想法最小、最聚焦的一次迭代：把真实方案摆到真实用户面前，并产生 PMF 的真实证据。
|
||||
|
||||
与此同时，你现在怎么造，决定了之后能造什么。这意味着 MVP 阶段还有第二个同样重要的目标：快速前进，但不积累那种会复利、会在真实用户达到一定规模时回来缠住你的技术债。
|
||||
|
||||
最后，从第一天起就投资持久上下文，是让 AI 成为放大器而不是熵源头的关键。在 AI-Native 创业公司里，你的代码库是你和 AI 一次次会话共同协作的对象，这让可读性成为根基。**跳过 spec、架构决策和** [CLAUDE.md](http://claude.md/) **这类上下文文件的创始人，会撞上一堵可预见的墙：每次新会话都要重新解释代码库，AI 生成的改动也会从最初愿景里漂移。**
|
||||
|
||||
MVP 阶段·退出标准
|
||||
|
||||
MVP 阶段的退出条件，是出现 PMF 的真实证据：一个具体、可识别的用户群体，发现产品有价值到愿意回头用（留存）、付费（收入），或告诉别人（推荐）。
|
||||
|
||||
MVP 阶段·挑战
|
||||
|
||||
在 MVP 阶段，创始人的首要指令是速度与判断力。这里的挑战核心是：你能不能用正确方式造正确东西、快到足够有意义，同时不抄那些以后会让你付代价的近路。
|
||||
|
||||
**Agentic 技术债**
|
||||
|
||||
挑战：因为 AI 基本移除了过去那些控制什么能进生产的天然瓶颈，速度是被保证的。但当速度成为创始人在 MVP 阶段唯一考虑的变量时，他们会积累自己很难还清的技术债。
|
||||
|
||||
一些技术债在 MVP 阶段是合理的，前提是你明白在规模化之前必须管理它。这种债逐步累积，可以在时间里或专门冲刺中清掉。但 **AI 技术债会复利。**
|
||||
|
||||
如果没有把规格和架构约束写在某个 AI 能读到的地方，每次会话都会从零开始重新推导基础决策，于是这些决策会漂移。你最后会得到一个没有一致心智模型的代码库，不是因为任何一块写得糟，而是因为这些零件从未被设计成能拼到一起。这是真问题，而且往往很晚才显形。
|
||||
|
||||
**误把虚假 PMF 当作真 PMF**
|
||||
|
||||
挑战：AI 工具可以生成亮眼的早期数字，但这些数字并不保证市场需要你的产品。
|
||||
|
||||
早期势头是创始人能经历的最强心理体验之一。经历数周或数月验证和克制建造之后，把产品发出去，会让人觉得自己从一开始就是对的。
|
||||
|
||||
Agentic 编程工具可以让你比以往更快抵达这个时刻，但**早期牵引不等于 PMF**。发布热度可能来自短暂因素：创始人的朋友、投资人其他被投公司的潜在买家，或 Hacker News 一个标题带来的流量尖峰。可惜，这些都不能可靠预测第六周或第十二周，在最初助推消退后会发生什么。
|
||||
|
||||
**零摩擦的范围蔓延**
|
||||
|
||||
挑战：当建造感觉不费力、几乎免费，总会有一个很酷的功能可以加，或一个边缘情况可以处理。这种范围蔓延弊大于利。
|
||||
|
||||
范围蔓延一直是创业风险。现在的区别是，过去阻止它的强制函数，即工程时间的真实成本，已经不再以同样方式存在。加一个功能从一个冲刺变成一个下午。
|
||||
|
||||
难点在于，每一个单独新增都显得合理。产品当然应该处理那个边缘情况，用户当然会想要那个工作流。由于 agentic 编程让每一项都很省力，它们在当下并不像范围蔓延。但当产品越过原始边界开始摊大饼，你就会失去方向和动量。
|
||||
|
||||
解药是在建造前写下范围定义：产品做什么、明确不做什么、以及来自真实用户的哪种具体证据才足以证明应该加新东西。这样，决策点就从「要不要做这个？」变成「是否已有足够多用户告诉我们：没有它，他们无法从产品获得价值？」
|
||||
|
||||
**因经验不足而不安全**
|
||||
|
||||
挑战：创始人用 AI 工具匆忙把应用推向市场，却没有先理解基本安全原则，最终会让用户暴露在可避免的风险中。
|
||||
|
||||
硬道理是：**agentic 编程工具生成的是能运行的代码，而不是天然安全的代码。** 功能代码很容易判断，因为功能要么能跑，要么不能。安全漏洞在被利用之前是隐形的，这意味着没有天然反馈环来提醒首次创业者：哪里出了问题。但把一个 live MVP 交给真实用户，就意味着真实数据、真实暴露和真实后果。
|
||||
|
||||
轻视安全并不是 AI-Native 项目才有的新问题。每个时代的自筹资金创业公司都常常把安全考虑拖到很晚，有时甚至拖到生产发布前夕。任何用户触碰你的 app 或方案之前，做一次安全审查，是把最小可行产品发布到世界上所需的最低责任门槛。
|
||||
|
||||
Claude 如何帮助 MVP 阶段创始人
|
||||
|
||||
**造之前先定架构**
|
||||
|
||||
在 Claude Code 写下第一行生产代码之前，用 Claude 定义并记录本阶段所有建造都要遵守的架构决策：遵循哪些模式，避开哪些依赖，做了哪些取舍以及为什么。这份输出会成为聚焦的架构上下文文档，并建立 Claude Code 要在其中运行的护栏。
|
||||
|
||||
没有这份上下文，每次会话都从零开始，Claude Code 被迫推断自己的结构性假设。让 Claude Code 没有护栏地建造，会产出功能可用但结构不一致的代码库。迭代和扩张这种代码库，最终是在浪费时间和 token。迟早会到一个点，代码不可避免地坍塌，迫使你从头重建。
|
||||
|
||||
练习：打开 Claude Code 之前，先打开 Claude 并描述你要做什么：它解决的核心问题、服务的用户、以及未来六个月现实预期的规模。让它帮你定义 MVP 构建应遵守的架构原则、在约束下应避免的依赖、以及这个阶段有意识接受的取舍。
|
||||
|
||||
接着，把这份输出保存为 [CLAUDE.md](http://claude.md/) Markdown 文件。这就是你的架构上下文文档：构建过程的第一个产物，也是后续每次会话依赖的东西。[CLAUDE.md](http://claude.md/) 文件是 Claude Code 的项目级指令，为特定代码库提供上下文和说明，并会在 Agent SDK 在目录中运行时被自动读取。功能上，它就是项目的持久记忆。
|
||||
|
||||
**定义并执行 MVP 范围**
|
||||
|
||||
没有摩擦的范围蔓延，是 AI 时代 MVP 的典型失败模式之一。就像你定义并记录产品应用架构一样，在任何功能被建造之前，也要先定义 MVP 范围。
|
||||
|
||||
Claude 可以帮你创建范围文档，描述 MVP 产品做什么、明确不做什么，以及功能修订标准：此时来自真实用户的哪种具体证据，才足以证明应该加新东西。
|
||||
|
||||
当新的功能想法出现时，它们一定会出现，你要用 Claude 压力测试：这是用户真实信号，还是披着产品思考外衣的创始人热情。
|
||||
|
||||
**用 Claude Code 造 MVP**
|
||||
|
||||
架构和范围定义好后，Claude Code 就成为主要的 MVP 构建工具。用它生成、测试、调试、迭代代码库，但要把每次会话当作执行你已经做出的产品决策，而不是趁机塞进新想法。
|
||||
|
||||
每次 Claude Code 会话开始时，先重新查看范围文档，并给模型提供 [CLAUDE.md](http://claude.md/) 架构上下文文档。每次会话结束时，把会话中浮现的决策更新进去。**目标是一个你能解释其结构的代码库，而不只是一个能跑的代码库。**
|
||||
|
||||
练习：为 Claude Code 工作创建一个简单会话模板，包括架构上下文文档、本次具体任务、以及需要遵守的约束或模式。每次会话结束时，在上下文文档里加一条简短日志，说明构建了什么、做了哪些决策、引入了哪些假设。每次五分钟的文档记录，是防止架构漂移复利成不可管理代码库的便宜保险。
|
||||
|
||||
**任何用户上手之前先做安全审查**
|
||||
|
||||
作为 AI-Native 创业公司创始人，你有责任知道代码库里有什么，理解潜在暴露路径，并且不要把明显漏洞交付给信任你处理其数据的真实用户。
|
||||
|
||||
Claude 可以对 AI 生成代码做有用的第一轮安全审查，帮助识别常见漏洞。这是发布前值得放进循环里的好习惯。但它不能替代安全工具，在风险更高时也不能替代人类审查。把它当替代品的创始人，最后往往会出现在事故故事里。
|
||||
|
||||
Claude Code Security 更进一步：它会扫描代码库里的安全漏洞，并为人类审查建议定向补丁，浮现传统方法可能漏掉的问题。
|
||||
|
||||
注：截至本电子书出版时，Claude Code Security 仍是有限 beta 版本。把它加入工作流之前，请确认当前可用状态。
|
||||
|
||||
练习：部署给任何真实用户之前，用一个明确 brief 把核心应用代码交给 Claude 审查：认证和会话处理、API 响应中的数据暴露、输入校验和注入风险、以及存在已知漏洞的依赖。认真对待每个发现，并判断是否需要修复；凡是涉及认证、密钥或数据处理的发现，都要有人类审查。
|
||||
|
||||
**发布前建好度量框架**
|
||||
|
||||
那些把早期牵引误判成 PMF 的创始人，通常也是发布后才开始追踪数据的人，而且选的指标往往是为了评估什么有效，而不是浮现什么无效。**解药是在第一个用户出现之前，就建立你的度量框架。**
|
||||
|
||||
用 Claude 定义你的具体产品应该看哪些指标、基准是什么、数据中哪些模式构成真正 PMF、哪些只是好看的噪音。具体来说，在发布 MVP 前设定留存基准、激活标准、以及第 7 日和第 30 日目标。
|
||||
|
||||
接着，定义对你的具体产品而言什么是假阳性：有注册但无激活、有收入但无留存、初始热情但没有重复使用等。当数据到来时，让 Claude 替怀疑者说话：一个怀疑者会如何解读这些数字？
|
||||
|
||||
**管理发现和用户反馈的运营层**
|
||||
|
||||
一旦真实用户进入产品，运营层会迅速膨胀。Claude Cowork 可以处理重要但繁琐的工作：建立和维护用户联系人列表、跑触达序列、安排反馈会、分诊 bug 报告、追踪迭代周期。想法阶段管理发现后勤的 MCP 集成，在这里同样适用。
|
||||
|
||||
对细腻的用户反馈探索，要保留人在收集循环里。用户说「这很好，但我希望它还能……」时，需要解释：这是核心需求还是锦上添花？是这个客户特有，还是代表某一细分人群？缺失功能才是真问题，还是新用户引导上游出了问题？没有工具能替你回答这些问题。
|
||||
|
||||
练习：配置 Claude Cowork 跑你的 MVP 阶段反馈环：给早期用户列表起草触达、安排反馈会、设计 bug 和功能请求的结构化收集流程、每周写一份综合摘要。你先自己审阅摘要；之后再让 Claude 分析信息，捕捉你可能漏掉的重要点。
|
||||
|
||||
**朝证据迭代，而不是朝完整迭代**
|
||||
|
||||
MVP 阶段结束于你拥有 PMF 的真实证据，而不是产品看起来有多「完整」。宣布已经达到 PMF、准备从 MVP 阶段进入发布阶段，最终是一项判断练习，需要结合创始人直觉和收集到的证据。不过，有一些有用的试金石：
|
||||
|
||||
- Sean Ellis 测试：问你的活跃用户：「如果再也不能用这个产品，你会感觉如何？」如果超过 40% 的人回答「非常失望」，这是一个有意义的 PMF 指标。
|
||||
- 努力测试：PMF 之前，留存需要持续干预：频繁触达、激励、个人跟进，以及创始人那种英雄式能量来维持用户参与。PMF 之后，产品开始自己承担这项工作。**当事情开始「拉」而不是「推」时，这种努力变化是真东西发生的最清晰信号之一。**
|
||||
|
||||
最终，没有任何单一数据点能确认 PMF，因为它必须在多个迭代周期里持续成立，才能被明确命名。
|
||||
|
||||
**数据要求 pivot 时，就要 pivot**
|
||||
|
||||
如果投入这么多工作后，仍然无法抵达 PMF 怎么办？结果没有确认你一开始的方向，并不是失败，而是系统在正常工作：MVP 阶段的设计目的，就是在你对错误答案过度投入之前浮现这些信息。
|
||||
|
||||
当数据不支持当前产品时，用 Claude 梳理这些数据到底在告诉你什么。
|
||||
|
||||
- 探索替代客户细分。也许那些没有转化的用户，从一开始就不是正确目标。很多时候，正确受众已经在你的数据里，只是权重被低估了。
|
||||
- 调整产品价值主张。也许受众是对的，但 MVP 没有和用户产生共鸣。调整新用户引导、信息表达或核心功能强调，可能无需改变已构建的东西就能修正问题。
|
||||
|
||||
保持开放：设计价值和体验价值之间的脱节，可能深到需要一次更根本的改变。
|
||||
|
||||
练习：如果你已经完成三轮或更多迭代周期，仍未看到朝 PMF 基准的实质推进，让 Claude 在决定下一步之前先跑一次诊断。把留存数据、用户反馈和最初的问题假设都喂给它，问三个问题：
|
||||
|
||||
- 数据里是否存在某一段用户响应方式与其他人不同？
|
||||
- 设计价值与体验价值之间的差距，是定位问题还是产品问题？
|
||||
- 当前产品要找到真实 PMF，需要哪些条件？以你观察到的现象来看，那个情境现实吗？
|
||||
|
||||
让答案决定你是调整、pivot，还是退回想法阶段。
|
||||
|
||||
———
|
||||
|
||||
## 第五章 发布阶段
|
||||
|
||||
**如果说 MVP 阶段是要证明你的产品值得存在，那么发布阶段就是要证明你的生意值得长大。**
|
||||
|
||||
发布阶段·目标
|
||||
|
||||
在发布阶段，创业者必须把早期势头转化为一台可重复、可持续的增长引擎。除了让产品具备生产就绪状态，你还必须同时加固产品底下的基础设施，也就是说，要围绕产品真正建出一家公司。
|
||||
|
||||
创业公司在想法和 MVP 阶段天然是创始人中心化的，因为你需要完整的处境感知和紧密反馈环。但现在，那些仍试图把每一根线都自己握在手里的创始人，会变成发布阶段的瓶颈。目标不是把自己从公司里拿掉，而是搭建运营系统，把注意力释放出来，去做那些只有创始人能做的决定。
|
||||
|
||||
发布阶段·退出标准
|
||||
|
||||
发布阶段的退出条件包含三个要素：
|
||||
|
||||
- 增长是可重复的、由渠道驱动的。你不是仅仅在留住用户，而是通过明确渠道、有可被理解的单位经济模型，可预测地获取用户。CAC、LTV、回收周期，这些都是你知道且能 defend 的数字。
|
||||
- 产品能扛住生产工作负载。基础设施已加固，安全与合规到位，可靠性在真实生产条件下也站得住，而不只是在你测试过的条件下。
|
||||
- 运营在没有创始人瓶颈的情况下也能跑。流程已就位，自动化已部署。你不再是亲自处理客服、分诊、冲刺规划或报表的人。
|
||||
|
||||
发布阶段·挑战
|
||||
|
||||
找到 PMF 是早期创业生命周期里最难的问题。现在，创始人的挑战变成了保住它。发布阶段是这样一种地方：那些已经找到真实产品牵引的公司，仍可能在包围和支撑产品的组织跟不上时散掉。
|
||||
|
||||
**技术债到期**
|
||||
|
||||
挑战：那个为速度和验证而建的 MVP 代码库勉强够证明产品能跑，但生产流量、新功能和增长中的复杂度，现在正把当初的捷径暴露出来。
|
||||
|
||||
在 MVP 时，积累一些技术债是合理的速度换取。在发布阶段，那笔债开始算利息，拖得越久，修起来越贵。
|
||||
|
||||
解决方案是一套系统的架构审查：找出结构性弱点，对最严重的问题做定向重构，并有意义地扩展测试覆盖率，确保下一轮功能开发不会重新引入同样的问题。
|
||||
|
||||
**创始人成为瓶颈**
|
||||
|
||||
挑战：MVP 阶段，创始人在每个循环里是一种资产。发布阶段，随着支持量增长、产品决策堆积、运营复杂度倍增，同样的本能会变成约束。
|
||||
|
||||
从亲自做事，到设计能把事情做完的系统，是创业生命周期里最难的转变之一。因为很少有一个清晰时刻宣告它已经发生，风险就在于你完全错过它，继续停留在建造者模式，而组织在你周围停滞。明显信号包括：本该一小时完成的决策，因为等你处理变成一周；支持请求越堆越多，因为只有你知道答案；运营任务只有在你亲自想起来时才发生。
|
||||
|
||||
补救办法是彻底审计你亲自处理的一切，从最小任务到最关键决策，识别什么能系统化，什么能委派，什么真正仍值得创始人投入时间和注意力。
|
||||
|
||||
**安全与合规不再能往后拖**
|
||||
|
||||
挑战：MVP 阶段，保持安全与合规措施简单还可以。但现在，有真实用户、真实数据，甚至可能有企业合同在桌上，它会变成负债。
|
||||
|
||||
MVP 阶段，只有少量 beta 用户、生产环境里没有敏感数据时，安全漏洞还是理论风险。但产品一旦进入生产、有真实用户依赖它，假设就会变成非常现实的暴露风险。更进一步，那些不适用于原型的合规要求，会在你处理客户数据、处理支付或销售给受监管行业的那一刻明确适用。
|
||||
|
||||
补救办法是在生产规模到来之前，而不是之后，做系统的安全与合规审查。凡是浮现出来的问题，都要当成下一波用户到来前必须修复的事项，而不是建议。
|
||||
|
||||
**还没准备好就扩张**
|
||||
|
||||
挑战：新市场和融资机会看起来像增长机会。它们也可能是 PMF 死掉的地方。
|
||||
|
||||
你建立的初始牵引是真实的，但它也具体绑定在早期受众上。过早扩张到一个与原市场显著不同的市场，会引入新的用户行为、合规要求、支付基础设施和基线预期，而你的产品并不是围绕这些设计的。突然之间，变量太多，你失去了清晰解释自己数据的能力。你还可能一边追逐新的、未经验证的受众，一边忽视原始用户群。
|
||||
|
||||
Claude 如何帮助发布阶段创始人
|
||||
|
||||
发布阶段会完整用到 Claude 的三种形式，而且它们相互支持：每个工具的输出都会变成另外两个工具的输入。结果会自然复利，一个同时使用三者的创始人，得到的不只是各部分相加。
|
||||
|
||||
**这正是超精益创业模型在结构上可行的原因。当 Claude Code 构建产品，Claude Cowork 构建产品周围的公司，Claude 帮助把产品和组织知识运营化，一个小团队就能像大得多的公司一样运行。 在技术债复利之前清算**
|
||||
|
||||
你的 MVP 代码库能跑，但它也需要一次系统的修复扫描，找出任何可能变成结构性负债的技术债。
|
||||
|
||||
首先，用 Claude Code 跑一次完整架构审查：识别代码库哪里脆弱，哪些捷径会变得维护昂贵，测试覆盖哪里薄到下一轮功能开发会重新引入同样问题。
|
||||
|
||||
把 Claude Code 的审查发现喂回 Claude，让它分诊并排序修复工作：什么必须在下一次发布前修，什么可以等一个冲刺，什么在当前阶段属于可接受的持续债务。这也是把 MVP 阶段那些只存在你脑子里的架构决策写下来的时刻。把它们放进 [CLAUDE.md](http://claude.md/)，能确保未来每次 Claude Code 会话都从共享理解开始。
|
||||
|
||||
练习：指挥 Claude Code 审查 MVP 代码库，产出结构性弱点、测试覆盖缺口和重构候选项的优先级列表。然后把清单交给 Claude，让它把修复工作排进几个冲刺：哪些重大问题要先处理，哪些可以和功能开发并行，哪些可以等待。
|
||||
|
||||
**搭起那些替换创始人注意力的系统**
|
||||
|
||||
要搭建能释放你注意力的运营系统，去处理只有创始人能承担的责任，第一步是准确知道你的注意力花在哪里。用 Claude Cowork 结构化审计当前运营负荷，记录每个重复任务、每个落到你桌上的决策、每个只因为你亲自记得才会发生的工作流。然后让 Claude Cowork 把清单分成三类：能完全自动化的，需要人但不一定需要你的，以及确实需要创始人判断的。
|
||||
|
||||
审计完成后，用 Claude Cowork 设计自动化候选项的工作流逻辑：每个工作流由什么触发、决策规则是什么、输出长什么样、完成后流向哪里。
|
||||
|
||||
**把安全与合规做成产品工作流**
|
||||
|
||||
用 Claude Code 浮现代码层面的问题，这些问题常出现在 SOC 2、GDPR、HIPAA 审计以及目标市场要求的标准中。它会同时浮现漏洞和合规缺口。把发现交给 Claude，帮助你排列修复优先级，并设计企业买家签约前会要求的控制、审计日志和访问管理。
|
||||
|
||||
注：AI 扫描是一种辅助，不能替代有资质的合规审查。
|
||||
|
||||
接下来，把合规工作流纳入开发周期，而不是把它当一次性项目。合规文档需要持续维护和更新。对正在接近企业合同或国际市场的创始人来说，这也是 Claude Code 安全扫描帮助你准备独立安全评估的时刻。
|
||||
|
||||
练习：用 Claude Code 跑一次代码级安全审查，方向对准目标市场所需框架。把输出喂给 Claude，请它产出两样东西：优先级排序的安全修复序列，以及为了通过潜在企业买家的合规审查，你需要产出的文档和控制清单。
|
||||
|
||||
**把一直跳过的产品管理流程立起来**
|
||||
|
||||
发布阶段需要一套轻量、可重复的流程，不需要创始人介入触发或维持也能运行。用 Claude 设计产品时间线和工作周期如何组织，一份 spec 在 Claude Code 触碰功能前必须包含什么，bug 报告如何分诊和路由，每周指标简报覆盖什么、如何分发。
|
||||
|
||||
流程设计完成后，用 Claude Cowork 搭建并运行运营层：安排冲刺仪式、把新进 bug 报告路由到正确位置、从连接的数据源汇总每周指标、维护让用户信号持续流入产品决策的反馈环。
|
||||
|
||||
练习：请 Claude 设计一套轻量产品管理操作系统：明确的冲刺节奏、最低规格文档模板、bug 分诊决策树，以及从真实数据源拉取的每周指标简报。然后设置 Claude Cowork 执行并运行系统里的重复运营元素，例如排期、路由和报告汇总，让它们按计划发生，而不需要你。
|
||||
|
||||
———
|
||||
|
||||
## 第六章 规模化阶段
|
||||
|
||||
在规模化阶段，创始人的角色重新校准，从建造者转向面对公众的高管。产品仍是核心，但你的日常工作越来越多地落到公司本身上。你必须把注意力扩展到新的规模化阶段活动，例如分析师沟通会和 IPO 路演，同时尽量保住那份精益、AI 为中心的结构性优势。
|
||||
|
||||
规模化阶段·目标
|
||||
|
||||
扩张技术基础设施的工作不会停止，现在又加入了扩张组织本身、把它催熟为一门生意的工作。
|
||||
|
||||
到了规模化阶段，你要从数千用户走向数百万，从一个市场走向多个市场。在之前每个阶段，增长都是你能摸着走的事：靠贴近用户、靠紧密反馈环的数据，再加上一点健康的创始人直觉来调整方向。现在，目标是搭建由成熟组织运营支撑的系统化增长。
|
||||
|
||||
**对一家 AI-Native 创业公司，你的目标应该是通过累积深度，建出防御性护城河。** 这来自你已经构建进产品里的专业知识、产品与用户依赖的其他工具和平台之间的深度整合、以及专有系统数据和工作流。那些一直在同一方向、同一基础设施上持续构建的创始人，现在手里有了真正难以复制的东西。
|
||||
|
||||
到了这个阶段，公开市场投资人、分析师、监管者、企业采购团队和收购方都会施加更大压力，也带来更大怀疑，因为赌注更高了。你的产品和组织必须经得起外部审视：不只是已经造出来的能力，还有围绕它的治理、合规姿态、财务控制和战略叙事。
|
||||
|
||||
规模化阶段·退出标准
|
||||
|
||||
规模化阶段的退出条件不再是单一里程碑，而是一个阈值事件：哪怕创始人越来越少直接跑日常运营，公司也已经可持续。你已经展示了系统化增长；建好能满足最苛刻外部审查者的组织治理和合规基础设施；并且能扎实回答这个问题：「如果一个资金充足的现任者今天复制了你的产品，你的用户会留下来吗？」
|
||||
|
||||
实践中，这个阈值通常会以三种形式之一出现：达到不再需要外部资本的规模化可持续盈利、IPO 就绪、或被收购。三者都要求你的增长系统化且可审计，产品护城河经得起审视，组织在运营上成熟且可持续。
|
||||
|
||||
当这些都成立时，恭喜你：你的创业公司已经从一场赌注，变成了一门生意。
|
||||
|
||||
规模化阶段·挑战
|
||||
|
||||
**把运营层放手出去**
|
||||
|
||||
挑战：规模化阶段的运营系统必须可靠、可持续地运行，不能靠人盯着。对一个从第一天起就亲力亲为的创始人来说，这种转变既是结构挑战，也是心理挑战。
|
||||
|
||||
**发布阶段的工作是创建系统；规模化阶段的工作则是让这些系统成熟到完全可信，然后真的信任它们。**
|
||||
|
||||
这比听起来更难。即使你是一个擅长授权的创始人，也不总是清楚什么该交出去，什么该留在自己手里。交得太多、太快，尤其交给 AI 自动化系统，关键决策可能会在缺少创始人独有上下文的情况下发生。但抓得太久，你又会变成瓶颈。
|
||||
|
||||
这里的根本挑战，是识别那些只存在于创始人脑子里或未文档化工作流中的机构知识，并把它编码进有文档、可审计、可交接的系统里。
|
||||
|
||||
**扩张技术运营**
|
||||
|
||||
挑战：客户不再只评估你的产品；他们还想知道你的组织能不能成为可靠的基础设施伙伴。
|
||||
|
||||
创业前三个阶段的技术挑战围绕代码库：构建正确方案而不积累技术债，然后为真实用户加固安全和合规。进入规模化阶段后，挑战变成围绕代码库的一切：创建支持基础设施、文档和可靠性保证，来传递成熟信号。
|
||||
|
||||
签多年合同的大客户和机构买家，在签约前会要求这些东西，签约后也会按这些要求约束你。不过，带你走到这里的同一套 AI 基础设施，也能帮助你建立专门支持职能：明确响应时间、提供新客户工程团队真正能用的文档。
|
||||
|
||||
**扩张组织职能**
|
||||
|
||||
挑战：规模化阶段的公司通常需要招聘、工资、会计和法律运营等组织基础设施，不管实际跑公司的人有多少。
|
||||
|
||||
发布阶段，系统化运营意味着自动化那些消耗创始人注意力的工作流。规模化阶段的创业公司现在需要扩展更广、某些方面也更关键的一组运营职能，例如财务报告、合规监控、合同管理和客户支持。
|
||||
|
||||
**搭一个 GTM 职能**
|
||||
|
||||
挑战：自然增长有天花板，而多数规模化阶段创始人在真正搭过 GTM 职能之前，就会撞上它。
|
||||
|
||||
想法、MVP 和发布阶段的增长，往往来自创始人亲自卖：从一个恰到好处的 Product Hunt 帖子，到与早期客户的私人关系。这样的自然增长只能走到某个点，大多数创业公司会在规模化阶段撞到这个上限。信号包括用户曲线变平、获客成本上升、以及只有创始人亲自介入时管道才会推进。
|
||||
|
||||
规模化阶段的增长，需要搭建一个专门增长引擎，让产品触达新的、更广的人群。但多数创业公司创始人，可能从来没有真正运行过市场、销售、分析师关系这类项目。一个像样的 GTM motion 不只是建立新系统和流程，还要创造品牌声音和产品故事，说明你想如何谈论自己的产品。因为在生命周期的这个阶段，你需要触达的不只是一个个新用户，还包括投资人、企业买家等完整目标受众。
|
||||
|
||||
好消息是，GTM 职能不必很大也可以有效。构建产品的同一套 AI 基础设施，也可以引导产品走向市场。
|
||||
|
||||
Claude 如何帮助规模化阶段创始人
|
||||
|
||||
早期阶段，Claude 是产品本身的基础设施：验证想法的研究伙伴、设计并构建原型的工程团队、以及让单人创业公司可行的 AI 运营层。走到规模化阶段的 AI-Native 创始人，现在可以继续用 Claude、Claude Code 和 Claude Cowork，以同样方式扩张。
|
||||
|
||||
**把日常任务交给 Claude Cowork**
|
||||
|
||||
以一个清醒视角开始规模化阶段：你现在最需要把时间和注意力投在哪里？对第一次创业、从未真正搭过一门生意的创始人来说，这会很难。Claude 可以帮你列出这个阶段只有你该做的事，例如产品叙事决策、董事会关系、企业大单、创始人与创始人的对话。任何不在清单上的事，都是委派或 Claude Cowork 自动化的候选项。
|
||||
|
||||
练习：用 Claude 绘制当前运营层的瓶颈地图：所有目前经过你的工作流、决策和审批。然后让 Claude 推演：如果你一周不可用，每一项会发生什么？会停下来的工作流，就是你仍亲手握得足以阻碍进展的地方。
|
||||
|
||||
这些与 Claude 帮你列出的创始人优先事项和责任清单如何对应？
|
||||
|
||||
接下来，压力测试你已经建好的系统是否真的能随业务增长而扩张。
|
||||
|
||||
练习：用 Claude 绘制当前工作流，并询问如果你一周不可用，每一项会发生什么。会停滞的工作流，说明交接标准、升级路径或异常处理仍需收紧。Claude 可以分析失败点并建议修复，让你按需更新或替换 Claude Cowork 自动化。
|
||||
|
||||
**把技术运营升级为企业级基础设施**
|
||||
|
||||
扩张时，买家需要确信你的产品和组织可以被当作长期基础设施信任。代码库内部的技术工作照常继续，但现在代码库周围的技术工作也必须处理。
|
||||
|
||||
第一步是把机构知识转换成能扩张的系统。用 Claude 起草并维护企业采购预期会看到的书面基础设施，包括产品文档、支持 playbook 和 SLA。
|
||||
|
||||
同时，指挥 Claude Code 针对企业合同要求的具体可靠性和安全标准审查并加固代码库，并构建出 Discord 社区支持从未需要提供的技术支持基础设施：日志、监控、事故响应工具，以及让 SLA 真正可执行的可观测性层。
|
||||
|
||||
随后，Claude Cowork 运行企业支持本身的运营层：工单路由、升级工作流、由产品变化触发的文档更新、续约追踪，以及企业客户成功依赖的报告节奏。三者合起来，让小团队拥有大组织的支持姿态，而这正是签多年企业合同前你必须证明的东西。
|
||||
|
||||
练习：挑出最苛刻的三个潜在客户，或识别你最想签下的三个理想客户。让 Claude 做差距分析：这些账户的企业采购团队在签多年合同前，会期待看到哪些文档、SLA 和支持基础设施？你目前哪里不足？用输出安排 Claude Code 和 Claude Cowork 的技术与文档工作。
|
||||
|
||||
**搭一个真正的 GTM 职能**
|
||||
|
||||
创始人的 hustle 把你带到了这里，但要扩张公司，你需要创建并执行真正的 GTM 策略。AI 可以帮你构建，然后运行完整的 GTM 引擎。
|
||||
|
||||
Claude 可以从零搭建基础 GTM 资源：市场细分、信息架构、分析师关系策略、销售 playbook，以及当你开始面对公开市场投资人、企业买家和华尔街分析师时重要的投资人指标叙事。每类受众都有自己的词汇，并用自己的标准评估你；Claude 的工作，是把产品价值主张翻译成每个受众都相关的产品营销方法。
|
||||
|
||||
现在，Claude Cowork 可以成为你的战术执行层：内容管线、外呼序列、分析师沟通会后勤、新闻和 PR 节奏、CRM 卫生、销售管道报告，以及把 GTM 策略变成真实商业动作的许多重复周期。
|
||||
|
||||
当 GTM motion 需要产品营销基础设施，例如交互式演示环境、集成文档、沙盒租户、API 参考、技术 one-pager，Claude Code 可以为你构建。买家期待从技术上评估你的产品。在规模化阶段，一段 Loom 视频和一份销售 deck 已经不够。这也是让 GTM motion 异步运行的基础设施：一个做得好的 demo 环境，可以在你开董事会时帮你成交。
|
||||
|
||||
**把领域专长和机构知识转入 AI 上下文**
|
||||
|
||||
许多超精益创业创始人，正在为某个他们亲身经历或观察到的特定行业真实问题，构建高度具体的 app 或工具。Agentic AI 让从未写过一行代码的创始人，也能用自己的领域专长做出解决复杂问题的产品。Claude、Claude Code 和 Claude Cowork 各自参与，把创始人知识转换成会复利的产品具体性。
|
||||
|
||||
用 Claude 捕捉、组织并细化创始人知识，就是把领域专长放到产品能够触达的地方。通过长对话、Projects 和记忆，创始人可以把自己知道的一切：行业黑话、监管坑、边缘情况、挫败点、为什么显而易见的答案并不管用，放进结构化、可搜索的上下文。**Skills 可以把重复工作流编码成可复用例程**，例如「我如何审查商业租约」「我如何分诊患者入院表」，让 Claude 每次都用同样方式运行。几个月后，这会变成一种专有知识基底，通用 AI 无法匹配。
|
||||
|
||||
把领域知识外部化到 Claude 中，对把行业特定边缘情况编码进产品极有价值。例如，一个通用医疗计费工具可能会在 340B 药品项目索赔上出错，而你的工具有专门逻辑。Claude Code 帮你把同行业其他专业人士常遇到的挫败，转译成验证逻辑、prompt 优化，或与竞争对手从未听过的小众行业系统的 MCP 集成。结果是，你的 app 或工具在深度和广度上都持续复利，竞争对手无法简单复制。
|
||||
|
||||
练习：找出一个通用竞品在你的垂直领域一定会做错的边缘情况。和 Claude Code 一起基于你真实见过的场景，为它构建一个专门测试用例，不是单元测试。每当相似边缘情况出现，就把它加进去。**你的测试套件会变成护城河地图。 让积累的用户数据复利成防御性优势**
|
||||
|
||||
用户与产品互动时，会生成行为信号，例如他们接受哪些输出、拒绝哪些输出，这会反过来影响产品路线图。随着时间推移，你会学到特定用户群的具体模式、偏好和边缘情况。这就是复利价值：每次改进让产品更有用，带来更多使用，创造更多反馈，再推动更多改进。
|
||||
|
||||
这些数据有时间锁定、具体上下文，并且无法被复制者重建：你不能买到数千名用户在你的产品里打磨工作流后形成的行为指纹。
|
||||
|
||||
Claude 可以帮助审计你收集到的用户交互数据，识别其中最高信号的行为模式，并设计把持续使用转化为系统性模型改进的反馈环。
|
||||
|
||||
练习：给 Claude 一份产品交互数据摘要：你收集了什么、收集了多久、你知道用户如何随时间使用产品。让它识别三个最高信号的行为模式，并为每一个设计能转化为系统性模型改进的反馈环。然后请它帮你起草一页护城河叙事，用于产品营销：你的数据飞轮如何运转、转了多久、为什么一个资源充足的竞争对手今天开始也无法在两年内复制。
|
||||
|
||||
**创造工作流锁定**
|
||||
|
||||
数据网络效应的复利会让产品更难被复制，而用户工作流锁定会让产品更难被离开。用户在日常运营中运行你的产品越久，它就越深地嵌入他们真实工作的方式。他们在上面建了自动化，训练团队使用它，把它连接到数据源和其他工具。那些 prompt、被打磨的工作流、被标准化的输出，都围绕你的产品做什么、如何做而成形。**到了这个点，切换不再是一个产品决策，而是一个完整规模的运营项目。**
|
||||
|
||||
创造工作流锁定的第一步，是让 Claude 按集成深度绘制当前客户群。对每个客户细分，识别他们在你的产品上搭建了哪些工作流、依赖哪些集成。这会显示产品在哪里真正粘住，哪里还需要更深入。
|
||||
|
||||
你提供的集成越多，客户就越有空间构建依赖你产品的工作流。Claude Code 可以帮你快速搭起目标用户依赖的数据管线、项目管理工具和其他系统的原生集成。它还可以构建 API、webhook 和 SDK，让客户不只是使用你的产品，而是在你的产品之上构建，这是最深的锁定形式。
|
||||
|
||||
练习：让 Claude 帮你为前十名客户建立工作流集成审计。对每个客户，记录他们搭建的自动化、依赖的集成、经过你产品的团队工作流，以及你估计的切换成本。然后请 Claude 识别这些客户之间的模式：哪些集成类型为你的具体产品创造最深锁定？你还能构建或开放什么，让目前停留在表层的客户拥有更深集成？
|
||||
|
||||
———
|
||||
|
||||
## 第七章 工作没变，规则变了
|
||||
|
||||
**在 AI 时代，创始人的工作并没有变：找到一个真问题，做出能解决它的东西，把它扩张成一家有意义的公司。变的是通往那里的路。**
|
||||
|
||||
穿过这四个阶段——想法、MVP、发布、规模化，AI 把一个个季度压缩成了一个个星期。
|
||||
|
||||
那些过去要几个月的验证周期，现在只要一个下午。一个能跑的原型不再需要一位拥有合适技术栈的联合创始人；它只需要一个清晰问题和几次专注会话，配上一个编程 agent。发布就绪从一阵发布前紧张冲刺，压缩成一条持续工作流。在规模化时，过去把早期员工逼成救火队员的运营重量，越来越多可以交给 AI，让你的团队把注意力放在那些会变成护城河的判断决策上。
|
||||
|
||||
**瓶颈不再是「你能造什么」，而是「你选择造什么」。**
|
||||
|
||||
———
|
||||
|
||||
## 资源链接
|
||||
|
||||
用 Claude 构建
|
||||
|
||||
- Building AI Agents for Startups：介绍创业公司如何用 agent，让自己在扩张时不那么依赖创始人本人。
|
||||
- Claude Code docs：带构建者从初始安装走到进阶 agentic 工作流。提示：先从「How Claude Code works」概览开始。
|
||||
- Claude Code best practices：涵盖 Anthropic 内部和工程团队验证过的模式，包括上下文管理、权限、规划和验证工作流。
|
||||
- Using [CLAUDE.md](http://claude.md/) files：讲解如何为特定代码库配置 Claude Code。对 MVP 阶段创始人搭建开发环境来说，这是必读材料。
|
||||
- Claude Code power user tips：来自 Claude Code 团队自身的工作流模式，包括并行会话和验证环。
|
||||
- Get started with Claude Cowork：讲解团队如何搭建 Claude Cowork，并开始实施 Skills、插件和其他能扩大影响的功能。
|
||||
- Tutorials：[claude.com/resources/tutorials](http://claude.com/resources/tutorials) 提供可搜索的、面向具体任务的实操教程。
|
||||
|
||||
创始人故事
|
||||
|
||||
- How three YC startups built their companies with Claude Code：HumanLayer (F24)、Ambral (W25)、Vulcan Technologies (S25) 如何用 Claude 让原型快速上市，并用 agentic 编程工作流扩张 AI 平台。
|
||||
- GC AI：创始人用领域专长做了一个由 Claude 驱动的法律平台，对应内部法务团队真实工作方式：公司专属 playbook、跨职能利益相关者、可变风险容忍阈值。
|
||||
- Carta Healthcare：用 Claude 驱动临床抽象平台，每年处理 22,000 例手术，数据抽象时间减少 66%。
|
||||
- Anything：由 Claude 和 Agent SDK 驱动，已帮助 150 万用户在不写代码的情况下把想法变成可运行软件产品，包括一位非技术创始人做出并已经在卖的完整招聘平台。
|
||||
- Cogent：应用 AI 实验室，构建 agent 自动化企业关键安全任务。Claude 是其 agent 的推理层，覆盖漏洞全生命周期的调查、优先级排序和修复。
|
||||
- Airtree：把 Claude Cowork 作为运营基础设施中心，统一过去散落在十几个工具和团队里的数据。现在，一个人用 Skills 搭出工作流自动化，组织中每个人都能用它完成那些长期没空做的事。
|
||||
- Duvo：构建 AI agent，跨 ERP、供应商门户、电子表格、邮件甚至电话，运行采购、供应链和品类管理流程。Duvo 完全构建在 Claude 上，使用 Agent SDK 跨工作流编排。
|
||||
- Zingage：面向居家护理机构的 24/7 自动化运营 AI agent 平台。它用 Claude 的结构化工具调用编排 EMR 和多通信渠道，用 Claude 的上下文推理给出细腻、因患者而异的结果。
|
||||
- Kindora：一位非营利组织高管打造的 AI 驱动平台，用 Claude Sonnet 做出一个急需工具：智能匹配慈善组织与资助方。从数千个匹配筛到少数值得追的对象后，Kindora 的 MCP 连接器让非营利机构可以直接在 Claude 里访问潜在客户工具。
|
||||
- Wordsmith：由一位转行做 CTO 的律师创办，为内部法务团队提供可靠的 AI 法律技术。Claude 是 Wordsmith 合同审查、协议起草和文档审查能力的推理引擎，而创业公司的工程团队用 Claude Code 构建并演进平台本身。
|
||||
|
||||
创业支持与机会
|
||||
|
||||
- Anthropic Startups Program：面向与 Anthropic VC 合作伙伴合作的创业公司，提供免费 API credits、公开可得的最高级别 rate limits，并邀请参加专属创始人活动和工作坊。
|
||||
- Claude community：面向构建者的论坛和社区空间。
|
||||
- Live learning resources：大会、网络研讨会、直播流和录播。
|
||||
|
||||
———
|
||||
|
||||
本译本仅供个人学习与内部研究使用，不做商业发行。原版权归 Anthropic 所有。
|
||||
416
4 - Resources/Claude-Code/Claude Code Agent Teams 官方多Agent编排.md
Normal file
416
4 - Resources/Claude-Code/Claude Code Agent Teams 官方多Agent编排.md
Normal file
@@ -0,0 +1,416 @@
|
||||
---
|
||||
created: "2026-05-16"
|
||||
type: resource
|
||||
tags: [resource, claude-code, agent-teams, orchestration, multi-agent, tmux, subagents, official, workflow]
|
||||
source: "https://code.claude.com/docs/en/agent-teams"
|
||||
---
|
||||
|
||||
# Claude Code Agent Teams 官方多 Agent 编排
|
||||
|
||||
Anthropic 官方嘅多 Claude Code instance 编排方案。同 ECC 嘅 `/orchestrate` 第三方实现唔同，呢个系 **Claude Code v2.1.32+ 内置嘅实验功能**，允许多个完整 session 通过共享 task list + 直接消息传递协同工作。
|
||||
|
||||
> 相关笔记：[[Everything Claude Code 多服务编排详解]]、[[ECC 编排实战手册]]、[[dmux 多Agent并行编排]]、[[Autonomous Agent Harness 自主代理框架]]
|
||||
|
||||
---
|
||||
|
||||
## 0. 三层编排能力速查
|
||||
|
||||
Claude Code 嘅并行编排有三层，由轻到重：
|
||||
|
||||
| 层次 | 工具 | 适用 | 通信方式 |
|
||||
|------|------|------|---------|
|
||||
| **Subagents** | `Agent` tool（单消息多 call） | 任务独立、只要结果、低成本 | 仅向主 agent 报告 |
|
||||
| **Worktrees** | `git worktree` + 多 terminal | 长任务、build/test 隔离 | 无（人工协调） |
|
||||
| **Agent Teams** | `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` | 需讨论、互相 challenge、跨层协调 | Teammates 之间直接 `SendMessage` |
|
||||
|
||||
**判断口诀**：
|
||||
- 任务可切干净、只要结果 → Subagents
|
||||
- 长 horizon、独立分支 → Worktrees
|
||||
- 需要互相对话、对抗审查、你想中途介入某个 worker → **Agent Teams**
|
||||
|
||||
---
|
||||
|
||||
## 1. Subagents vs Agent Teams 关键对比
|
||||
|
||||
| 维度 | Subagents | Agent Teams |
|
||||
|------|-----------|------------|
|
||||
| Context | 独立窗口，结果汇报返主 agent | 独立窗口，**完全独立 session** |
|
||||
| 通信 | 只能向主 agent 报告 | **Teammates 之间直接 message** |
|
||||
| 协调 | 主 agent 集中调度 | **共享 task list，self-coordination** |
|
||||
| Token 成本 | 较低（结果会被压缩回主 context） | **显著更高**（每个 teammate 都系完整 Claude 实例） |
|
||||
| 你能否同 worker 直接对话 | ❌ | ✅ Shift+Down 切换 |
|
||||
| 嵌套 | 主 agent 可派 subagent | ❌ Teammate 不能再开 team |
|
||||
|
||||
---
|
||||
|
||||
## 2. 启用方法
|
||||
|
||||
`~/.claude/settings.json`：
|
||||
```json
|
||||
{
|
||||
"env": {
|
||||
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
|
||||
},
|
||||
"teammateMode": "auto"
|
||||
}
|
||||
```
|
||||
|
||||
`teammateMode` 三种值：
|
||||
- `in-process`：所有 teammate 喺主 terminal，**Shift+Down** 切换，**Ctrl+T** 切 task list
|
||||
- `tmux`：split-pane 模式，需要 tmux 或 iTerm2 + it2 CLI
|
||||
- `auto`（默认）：喺 tmux 内就 split，否则 in-process
|
||||
|
||||
要求版本：`claude --version` ≥ v2.1.32。
|
||||
|
||||
---
|
||||
|
||||
## 3. tmux 集成操作要点
|
||||
|
||||
### 3.1 启动 / 重接
|
||||
|
||||
```bash
|
||||
# 首次创建（iTerm2 集成）
|
||||
tmux -CC new -s billo_team
|
||||
|
||||
# 重新接入（推荐用普通 attach，最稳）
|
||||
tmux attach -t billo_team
|
||||
|
||||
# iTerm2 ControlMode 重接（要 iTerm2 + 已开 tmux integration）
|
||||
tmux -CC attach -t billo_team
|
||||
|
||||
# 列出所有 session
|
||||
tmux ls
|
||||
|
||||
# 杀掉旧 session
|
||||
tmux kill-session -t billo_team
|
||||
```
|
||||
|
||||
### 3.2 常见坑
|
||||
|
||||
- **`-CC` 看到 raw `%begin %end %output` 输出 = 集成未生效**
|
||||
原因：用紧 Terminal.app 而唔系 iTerm2，或 iTerm2 集成被关。
|
||||
解决：改用 `tmux attach -t <name>` 普通模式。
|
||||
|
||||
- **duplicate session 错误**
|
||||
Session 已存在，用 attach 而唔系 new。
|
||||
|
||||
- **Claude Code 喺边度起？**
|
||||
喺 tmux session 入面用 `claude` 启动主 session，呢个就系 team lead。Teammate 由 lead 自动 spawn 入新 pane。
|
||||
|
||||
### 3.3 tmux 常用快捷键（attach 后）
|
||||
|
||||
| 快捷键 | 作用 |
|
||||
|--------|------|
|
||||
| `Ctrl+b d` | detach 离开但保留 session |
|
||||
| `Ctrl+b s` | 列出 session 切换 |
|
||||
| `Ctrl+b c` | 开新 window |
|
||||
| `Ctrl+b %` / `"` | 垂直 / 水平 split pane |
|
||||
|
||||
---
|
||||
|
||||
## 4. 架构
|
||||
|
||||
| 组件 | 角色 |
|
||||
|------|------|
|
||||
| **Team lead** | 创建团队嘅主 session，spawn teammate + 协调 |
|
||||
| **Teammates** | 独立 Claude Code 实例，各有 context window |
|
||||
| **Task list** | 共享任务清单（pending / in_progress / completed，支持依赖） |
|
||||
| **Mailbox** | Teammates 之间嘅消息系统，自动投递 |
|
||||
|
||||
**状态文件**（**唔好手编辑**，每次状态变更覆盖）：
|
||||
- `~/.claude/teams/{team-name}/config.json`
|
||||
- `~/.claude/tasks/{team-name}/`
|
||||
|
||||
> ⚠️ **冇 project 级 teams 配置**。`.claude/teams/teams.json` 系普通文件，唔识别。
|
||||
|
||||
---
|
||||
|
||||
## 5. Subagent 定义作为可复用 Teammate 角色
|
||||
|
||||
呢个系 Agent Teams 嘅核心可复用性机制。
|
||||
|
||||
### 5.1 写法
|
||||
|
||||
`.claude/agents/dotnet-backend-implementer.md`（project 级，可 commit）：
|
||||
```markdown
|
||||
---
|
||||
name: dotnet-backend-implementer
|
||||
description: Implements .NET backend modules following DDD patterns
|
||||
tools: [Read, Write, Edit, Bash, Grep, Glob]
|
||||
model: claude-sonnet-4-6
|
||||
---
|
||||
|
||||
You implement .NET 8 backend modules in the Billo.Platform codebase.
|
||||
|
||||
Conventions you MUST follow:
|
||||
- DDD layering: Domain / Application / Infrastructure / API
|
||||
- Use Result<T> pattern for error returns, no exceptions for control flow
|
||||
- Async methods end in Async, ConfigureAwait(false) on library code
|
||||
- Repository interfaces in Domain, implementations in Infrastructure
|
||||
|
||||
Before implementing:
|
||||
1. Read PLAN.md sections relevant to your assigned files
|
||||
2. Check existing patterns in adjacent modules
|
||||
3. Write xUnit tests first (TDD)
|
||||
|
||||
When done: report files changed + test coverage % to the lead.
|
||||
```
|
||||
|
||||
### 5.2 喺 Agent Teams 入面引用
|
||||
|
||||
```text
|
||||
Spawn a teammate using the dotnet-backend-implementer agent type
|
||||
to handle Subtask 2.1.
|
||||
```
|
||||
|
||||
### 5.3 注意事项
|
||||
|
||||
- Teammate 跟 subagent 定义嘅 `tools` allowlist 同 `model`
|
||||
- 定义嘅 body **append** 到 teammate 嘅 system prompt（**唔系替换**）
|
||||
- `SendMessage` 同 task 管理工具**永远可用**，即使 `tools` 限制咗其他
|
||||
- ⚠️ 定义入面嘅 `skills`、`mcpServers` 喺 team 模式**唔生效**，teammate 从 project / user settings 加载
|
||||
|
||||
---
|
||||
|
||||
## 6. 大型项目完整工作流
|
||||
|
||||
### 6.1 One-time Setup
|
||||
|
||||
1. **写好可复用嘅 subagent 定义**（`.claude/agents/*.md`）
|
||||
建议角色：`backend-implementer`、`frontend-implementer`、`domain-modeler`、`test-writer`、`integration-reviewer`、`db-migration-author`
|
||||
既有嘅可直接用：`code-reviewer`、`security-reviewer`、`tdd-guide`、`architect`
|
||||
|
||||
2. **写 PLAN.md**（放 repo 根目录）
|
||||
关键：**每个 subtask 列明 owned files glob**，呢个系防冲突嘅唯一可靠方法。
|
||||
```markdown
|
||||
# Project Plan
|
||||
|
||||
## Phase 2: Customer Context
|
||||
- 2.1 Customer aggregate
|
||||
- Owner files: src/Customer.Domain/**
|
||||
- 2.2 Customer application layer
|
||||
- Owner files: src/Customer.Application/**
|
||||
- Depends on: 2.1
|
||||
- 2.3 Customer API + integration tests
|
||||
- Owner files: src/Customer.Api/**, tests/Customer.IntegrationTests/**
|
||||
- Depends on: 2.2
|
||||
|
||||
## Cross-cutting Rules
|
||||
- File ownership is exclusive per subtask
|
||||
- Coverage ≥ 80% per module
|
||||
```
|
||||
|
||||
3. **配置 hooks 作为质量门**（详见第 7 节）
|
||||
|
||||
### 6.2 每个阶段嘅 Spawn Prompt 模板
|
||||
|
||||
```text
|
||||
We're starting Phase {N}. Read PLAN.md for context.
|
||||
|
||||
Create an agent team with {3-5} teammates:
|
||||
|
||||
[Teammate A]
|
||||
- Name: "customer-domain"
|
||||
- Subagent type: dotnet-backend-implementer
|
||||
- Task: Subtask 2.1
|
||||
- Owned files: src/Customer.Domain/**
|
||||
- Require plan approval before implementation.
|
||||
|
||||
[Teammate B]
|
||||
- Name: "customer-app"
|
||||
- Subagent type: dotnet-backend-implementer
|
||||
- Task: Subtask 2.2
|
||||
- Owned files: src/Customer.Application/**
|
||||
- Depends on: customer-domain finishing aggregate signatures
|
||||
- Require plan approval.
|
||||
|
||||
[Teammate C]
|
||||
- Name: "customer-api"
|
||||
- Subagent type: dotnet-backend-implementer
|
||||
- Task: Subtask 2.3
|
||||
- Owned files: src/Customer.Api/**, tests/Customer.IntegrationTests/**
|
||||
- Depends on: customer-app
|
||||
|
||||
COORDINATION RULES:
|
||||
1. Create shared task list with dependencies.
|
||||
2. Each teammate reads PLAN.md + cross-cutting rules.
|
||||
3. When customer-domain finishes the aggregate API, message
|
||||
customer-app and customer-api with signatures.
|
||||
4. No teammate edits files outside their owned glob.
|
||||
5. Wait for all to finish before synthesis.
|
||||
|
||||
PLAN APPROVAL CRITERIA (for the lead):
|
||||
- Reject plans that skip writing tests first.
|
||||
- Reject plans touching files outside ownership.
|
||||
- Approve plans with explicit coverage ≥ 80%.
|
||||
|
||||
AFTER ALL FINISH:
|
||||
Spawn code-reviewer teammate for cross-module review.
|
||||
Then security-reviewer for the API surface only.
|
||||
Report: files changed, coverage %, findings.
|
||||
```
|
||||
|
||||
### 6.3 阶段过渡
|
||||
|
||||
**唔好一次 spawn 所有阶段**。原因：
|
||||
- 一次只能开一个 team，必须 cleanup 先开新
|
||||
- 下一阶段 spec 可能因为上一阶段发现要调整
|
||||
- Token 成本
|
||||
|
||||
过渡 prompt：
|
||||
```text
|
||||
Phase 2 is complete. Summarize:
|
||||
- What was delivered vs plan
|
||||
- Open issues / deferred items
|
||||
- Any architectural changes
|
||||
Then clean up the team.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. Hooks 质量门
|
||||
|
||||
| Hook | 触发时机 | exit code 2 作用 |
|
||||
|------|---------|------------------|
|
||||
| `TeammateIdle` | Teammate 准备 idle 之前 | 推回反馈，迫继续做 |
|
||||
| `TaskCreated` | 任务创建时 | 阻止创建，反馈意见 |
|
||||
| `TaskCompleted` | 任务标记完成时 | 阻止完成，反馈意见 |
|
||||
|
||||
例子（`~/.claude/settings.json`）：
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"TaskCompleted": [
|
||||
{
|
||||
"matcher": ".*test.*",
|
||||
"command": "dotnet test --collect:\"XPlat Code Coverage\" | grep -q 'Line coverage.*[8-9][0-9]%\\|100%' || exit 2"
|
||||
}
|
||||
],
|
||||
"TeammateIdle": [
|
||||
{
|
||||
"command": "git status --short | grep -v '^??' | wc -l | awk '$1==0 {exit 0} {print \"Uncommitted work\"; exit 2}'"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. 控制操作
|
||||
|
||||
### 8.1 模型选择
|
||||
|
||||
Teammate **唔继承** lead 嘅 `/model`。要喺 `/config` 设置 **Default teammate model**，或选 "Default (leader's model)" 跟随 lead。Spawn prompt 入面也可显式：
|
||||
```text
|
||||
Use Sonnet for each teammate.
|
||||
```
|
||||
|
||||
### 8.2 Plan Approval（高风险任务必用）
|
||||
|
||||
```text
|
||||
Spawn an architect teammate to refactor authentication.
|
||||
Require plan approval before any changes.
|
||||
```
|
||||
Teammate 留喺 read-only plan mode，lead 审核批准或反馈拒绝。
|
||||
|
||||
### 8.3 直接对话 Teammate
|
||||
|
||||
- **in-process**：`Shift+Down` 循环切 → 打字发消息 → `Enter` 进入睇 session → `Esc` 中断
|
||||
- **split-pane**：直接 click 入嗰个 pane
|
||||
|
||||
### 8.4 关闭 Teammate / 清场
|
||||
|
||||
```text
|
||||
Ask the researcher teammate to shut down
|
||||
```
|
||||
|
||||
**清场必须由 lead 执行**：
|
||||
```text
|
||||
Clean up the team
|
||||
```
|
||||
（Teammate cleanup 会留下 inconsistent state）
|
||||
|
||||
---
|
||||
|
||||
## 9. 官方使用场景
|
||||
|
||||
### 9.1 并行 Code Review
|
||||
```text
|
||||
Create an agent team to review PR #142. Spawn three reviewers:
|
||||
- One focused on security implications
|
||||
- One checking performance impact
|
||||
- One validating test coverage
|
||||
Have them each review and report findings.
|
||||
```
|
||||
|
||||
### 9.2 竞争性假设调查（debug 神技）
|
||||
```text
|
||||
Users report the app exits after one message. Spawn 5 teammates
|
||||
to investigate different hypotheses. Have them talk to each other
|
||||
to disprove each other's theories, like a scientific debate.
|
||||
Update findings doc with consensus.
|
||||
```
|
||||
精髓：互相 challenge 打破单 agent 嘅 anchoring bias。
|
||||
|
||||
---
|
||||
|
||||
## 10. Best Practices
|
||||
|
||||
| 项 | 建议 |
|
||||
|----|------|
|
||||
| Team 大小 | **3-5 个 teammate 最稳**，超过协调成本 > 收益 |
|
||||
| 任务大小 | 每个 teammate 5-6 个 task 最高产 |
|
||||
| 文件 ownership | **必须明确分割**，每个 teammate 独占 glob |
|
||||
| Plan approval | 高风险（migration、API contract、auth）一定 require |
|
||||
| 新手入门 | 由 review / research 开始，唔写代码嘅任务先体验 |
|
||||
| Lead 偷跑 | 见 lead 自己动手就提佢 "Wait for your teammates to complete" |
|
||||
| Permission | 预先批准常用操作，减少 prompt 打断 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实验性限制（实操要小心）
|
||||
|
||||
| 限制 | 影响 |
|
||||
|------|------|
|
||||
| `/resume` `/rewind` 唔恢复 in-process teammate | 恢复后 lead 可能发消息俾已死 teammate → 叫佢 spawn new |
|
||||
| Task status 可能滞后 | Teammate 偶尔忘记 mark complete，阻塞下游 |
|
||||
| Shutdown 慢 | Teammate 完成当前 tool call 先关 |
|
||||
| **一次只能开一个 team** | 创建新 team 必须先 cleanup 旧 |
|
||||
| **唔支持嵌套 team** | Teammate 不能 spawn 自己嘅 team |
|
||||
| **Lead 唔可转让** | 创建 team 嗰个 session 永远系 lead |
|
||||
| Permission 只喺 spawn 时跟 lead | Spawn 完先可单独改个别 teammate |
|
||||
| Split-pane 限制 | VS Code 内置 terminal、Windows Terminal、Ghostty **唔支持** |
|
||||
|
||||
---
|
||||
|
||||
## 12. 思维模型
|
||||
|
||||
把多 Agent 编排映射到人类团队：
|
||||
|
||||
```
|
||||
开发计划 (Plan)
|
||||
└── 阶段 (Phase)
|
||||
├── 独立子任务 → 并行
|
||||
│ ├── 任务可切干净 → Subagents (廉价 fan-out)
|
||||
│ ├── 任务需独立 build/test → Worktrees (隔离)
|
||||
│ └── 任务需互相讨论 → Agent Teams (协同)
|
||||
└── 阶段尾审查
|
||||
└── 并行 reviewer teammates
|
||||
(security / performance / test coverage 各一个)
|
||||
```
|
||||
|
||||
启发：**如果你会同时分配呢两个任务俾两个唔同嘅工程师，并且佢哋唔需要事先沟通，咁就适合并行**。
|
||||
|
||||
---
|
||||
|
||||
## 13. 同既有笔记嘅区别
|
||||
|
||||
| 笔记 | 重点 |
|
||||
|------|------|
|
||||
| 本笔记 | **官方 Agent Teams**（v2.1.32+ 实验功能、tmux 集成、大型项目编排模板） |
|
||||
| [[Everything Claude Code 多服务编排详解]] | **ECC 第三方** `/orchestrate` 命令（feature/bugfix/refactor/security 流水线） |
|
||||
| [[ECC 编排实战手册]] | ECC 6 种正交编排模式总览 |
|
||||
| [[dmux 多Agent并行编排]] | dmux 工具嘅并行 worktree 编排 |
|
||||
| [[Ralphinho RFC-DAG 编排模式]] | RFC-DAG 风格强制隔离编排 |
|
||||
| [[Autonomous Agent Harness 自主代理框架]] | 长时间自主运行嘅 harness 设计 |
|
||||
@@ -0,0 +1,190 @@
|
||||
---
|
||||
created: "2026-06-18"
|
||||
type: resource
|
||||
tags: [resource, claude-code, dynamic-workflows, orchestration, multi-agent, pipeline, best-practices, anthropic]
|
||||
source: "https://code.claude.com/docs/en/workflows"
|
||||
---
|
||||
|
||||
# Claude Code Dynamic Workflows 最佳实践与实例
|
||||
|
||||
> Dynamic workflow = **Claude 自己写、运行时后台执行、你可读可重跑的一段 JS 脚本**,用来编排几十到几百个并行子 agent。需 Claude Code v2.1.154+,付费计划/API/Bedrock/Vertex/Foundry 可用,Pro 在 `/config` 打开。
|
||||
>
|
||||
> 上层选型见 [[Claude Code 官方多Agent编排最佳实践 (2026)]];ECC 自建编排见 [[ECC orch- 编排家族与 v2.0 团队编排]]、[[ECC 编排实战手册]]。
|
||||
|
||||
---
|
||||
|
||||
## 一、何时用(vs subagents / agent teams)
|
||||
|
||||
核心区别:**计划掌握在谁手里**。Workflow 把计划搬进**代码**,中间结果留在脚本变量里,Claude 上下文只拿最终答案。
|
||||
|
||||
只在这两种情况用:
|
||||
- **一个会话协调不过来**:几十~几百 agent 的全库审计、500+ 文件迁移、广度研究。
|
||||
- **想把编排固化成可复用、可重跑的资产**:每个分支都跑的同一套审查/研究。
|
||||
|
||||
不值得用:一两轮能做完的、紧耦合顺序任务、单文件改动。
|
||||
|
||||
> Workflow 的真正价值不是"多跑几个 agent",而是能施加**可重复的质量模式**——独立 agent 对抗式互审、多角度起草再权衡,比单遍更可信。
|
||||
|
||||
---
|
||||
|
||||
## 二、编程模型:三个原语 + meta
|
||||
|
||||
每个脚本必须以 `export const meta` 开头(**纯字面量**,不能有变量/函数/插值),phase 标题要和 `phase()` 调用一致。
|
||||
|
||||
```javascript
|
||||
export const meta = {
|
||||
name: 'vue-newsletter',
|
||||
description: 'Research Vue/Nuxt ecosystem sources in parallel for a given week',
|
||||
phases: [
|
||||
{ title: 'Research', detail: 'one agent per source' },
|
||||
{ title: 'Curate', detail: 'dedupe + rank items by impact' },
|
||||
{ title: 'Write', detail: 'synthesize the final newsletter' },
|
||||
],
|
||||
}
|
||||
```
|
||||
|
||||
| 原语 | 语义 | 何时用 |
|
||||
|------|------|--------|
|
||||
| `agent(prompt, opts?)` | 起一个子 agent;给 `schema` 则强制结构化输出(工具层校验+重试,直接返回已验证对象) | 单个委派 |
|
||||
| `pipeline(items, s1, s2…)` | 每个 item 独立穿过所有 stage,**stage 间无屏障** | **多 stage 默认** |
|
||||
| `parallel(thunks)` | **屏障**:等齐所有结果;失败项变 `null` 不 reject | 仅当 stage N 需要 N-1 全部结果 |
|
||||
| `workflow(name, args?)` | 内联调另一个 workflow | 组合复用 |
|
||||
|
||||
`agent` 关键 opts:`schema`(强制 JSON)、`phase`(进度分组)、`label`(显示名)、`model`/`effort`(成本路由)、`isolation:'worktree'`(并行写文件防冲突,贵,仅必要时)。
|
||||
|
||||
**黄金规则:默认 `pipeline()`,屏障只在真需要时用。** 嗅探:若写成 `parallel → 普通 map/filter/flatten → parallel`,中间那步不需要屏障,改成 pipeline 内的一个 stage。`pipeline` 墙钟 = 最慢单条链,不是各 stage 最慢之和。
|
||||
|
||||
---
|
||||
|
||||
## 三、实例(真实脚本结构)
|
||||
|
||||
### 例 1:Vue 新闻信 —— fan-out → reduce → synthesize(经典三段式)
|
||||
|
||||
**Phase 1 并行扇出**(9 个源各一个 agent,schema 强制结构化):
|
||||
```javascript
|
||||
const raw = await parallel(
|
||||
SOURCES.map((s) => () =>
|
||||
agent(s.prompt, { label: `research:${s.key}`, schema: ITEM_SCHEMA,
|
||||
agentType: 'general-purpose' })
|
||||
)
|
||||
)
|
||||
```
|
||||
**Phase 2 纯 JS 归约**(去重/扁平**不**再起 agent):
|
||||
```javascript
|
||||
const flatItems = collected.flatMap((c) =>
|
||||
(c.items || []).map((it) => ({ ...it, source: c.source })))
|
||||
```
|
||||
**Phase 3 顺序综合**:
|
||||
```javascript
|
||||
const curated = await agent(curatePrompt, { phase: 'Curate', schema: CURATED_SCHEMA })
|
||||
const newsletter = await agent(writePrompt, { phase: 'Write' })
|
||||
```
|
||||
> 要点:**归约用普通代码,不用 agent**。扁平/去重/过滤这类无跨 item 依赖的操作放进 stage 里或纯 JS,别为它开屏障。
|
||||
|
||||
### 例 2:`/deep-research`(内置 workflow,5 阶段)
|
||||
|
||||
1. **Scope**(1 agent):把问题拆成 5 个不同搜索角度
|
||||
2. **Search**(5 并行 agent):各自独立 web 搜索
|
||||
3. **Fetch**(顺序):URL 去重,抽 ~15 个源
|
||||
4. **Verify**(每条 claim 并行):**三票制,怀疑者尝试证伪**
|
||||
5. **Synthesize**(1 agent):只用存活的 claim 生成带引用报告
|
||||
|
||||
> **没survive 的 claim 永远进不了报告**——这就是把质量门写进编排的范例。
|
||||
|
||||
### 例 3:Bun 移植(Zig→Rust,真实大规模)
|
||||
|
||||
Jarred Sumner 用 workflows 把 Bun 从 Zig 移植到 Rust:**~75 万行、99.8% 测试通过、11 天合并**。四阶段:
|
||||
1. **Mapping**:一个 workflow 为 Zig 里每个 struct 字段推断对应 Rust lifetime
|
||||
2. **Translation**:**几百个并行 agent**逐个 `.zig`→`.rs`,**每文件配 2 个 reviewer**
|
||||
3. **Fix loop**:自动迭代 build+test 直到通过
|
||||
4. **Optimization**:**通宵** workflow 消除多余拷贝,**每项生成单独 PR** 供人审
|
||||
|
||||
> 模式提炼:**map(推断约束) → 并行翻译(每单元配双评审) → 自动修复循环 → 优化并拆成可审 PR**。能力上限极高,但 token 成本对应也高。
|
||||
|
||||
---
|
||||
|
||||
## 四、质量模式(workflow 的精髓)
|
||||
|
||||
```javascript
|
||||
// 对抗式 / 多镜头验证:每个发现配不同视角的独立评判者(不是 N 个相同怀疑者)
|
||||
const judged = await parallel(fresh.map((b) => () =>
|
||||
parallel(['correctness', 'security', 'repro'].map((lens) => () =>
|
||||
agent(`Judge "${b.desc}" via the ${lens} lens — real?`, { schema: VERDICT })
|
||||
))
|
||||
))
|
||||
```
|
||||
|
||||
- **对抗式验证**:每个发现 spawn N 个独立怀疑者,prompt 去**证伪**,多数证伪即杀——挡住"看似合理但错"的发现。
|
||||
- **视角多样**:一个发现能多种方式失败时,给每验证者不同镜头(正确性/安全/性能/能否复现),比冗余的相同怀疑者更能抓失败模式。
|
||||
- **判官面板**:多角度生成 N 方案 → 并行打分 → 从胜者综合 + 嫁接亚军亮点。
|
||||
- **loop-until-dry**:未知数量的发现持续 spawn 直到连续 K 轮无新增。**去重对 `seen` 集合,不是对 `confirmed`**,否则被判官否掉的发现每轮重现、永不收敛。
|
||||
- **completeness critic**:最后一个 agent 专问"还缺什么——没跑的模态/没验证的断言/没读的源",产出下一轮工作。
|
||||
|
||||
---
|
||||
|
||||
## 五、成本 / 资源 / 确定性
|
||||
|
||||
- **先小切片试跑**:一个目录而非整库、一个窄问题而非宽问题,看 `/workflows` 里每 agent 的 token 再全量。
|
||||
- **硬上限**:并发 ≤16 agent,单次 ≤1000 agent;脚本本身**不能读写文件/跑 shell**(由它编排的 agent 做)。
|
||||
- **模型路由**:每 agent 默认会话模型;机械 stage 显式降级 `{model:'haiku', effort:'low'}`,只给最难的 verify/judge 升级。大跑前查 `/model`。
|
||||
- **budget 驱动**:`while (budget.total && budget.remaining() > 50_000) {…}` 或静态 `FLEET = floor(total/100k)`。
|
||||
- **资源约束**:prompt 里让 agent 避开重资源命令,以便并行更多。
|
||||
- **无声截断要 `log()`**:凡设了 top-N / 不重试 / 采样,都要 log,否则读起来像全覆盖。
|
||||
- **确定性禁令**:脚本内 `Date.now()` / `Math.random()` / 无参 `new Date()` 都会 **throw**(为了 journaling 可恢复)。时间戳用 `args` 传入;要随机就**按 index 变 prompt/label**,不要真随机。
|
||||
|
||||
---
|
||||
|
||||
## 六、运维 / 协作
|
||||
|
||||
- 后台跑、会话不阻塞;`/workflows` 看分阶段进度,可暂停/停某 agent/重启。
|
||||
- **同会话内可恢复**:停了再起,已完成 agent 返回缓存结果;`resumeFromRunId` 对相同脚本 100% 命中。退出 Claude Code 则下次从头。
|
||||
- **保存复用**:满意的 run 按 `s` 存成 `/<name>` 命令(项目 `.claude/workflows/` 或个人 `~/.claude/workflows/`,同名项目优先)。
|
||||
- **`args` 传参**:存好的 workflow 接收结构化 `args`(研究问题/路径列表/配置),脚本直接当数组/对象用。
|
||||
- **审批**:首跑展示 phase + token 警告;子 agent 一律 `acceptEdits`,但非白名单的 shell/web/MCP 仍会中途提示——长跑前先加白名单。
|
||||
- **没有中途人工输入**:要分阶段签字,把每个 stage 拆成独立 workflow。
|
||||
- 触发:prompt 含 `ultracode` 关键词跑单次;`/effort ultracode` 让整会话每个实质任务都自动编排成 workflow。
|
||||
|
||||
---
|
||||
|
||||
## 七、Use case 目录(官方/社区)
|
||||
|
||||
- **全库 bug 扫描** + 独立验证发现
|
||||
- **安全审计 / 加固**(认证检查、输入校验)、profiler 引导的优化审计、死代码识别(Klarna 实践)
|
||||
- **大规模现代化**:框架替换、API 弃用迁移、语言移植(数千文件)
|
||||
- **高风险关键工作**:错误代价高时,用独立尝试 + 对抗测试再交付
|
||||
- **广度研究**:多角度搜索 → 取源 → 逐条 claim 交叉验证 → 带引用综合
|
||||
|
||||
---
|
||||
|
||||
## 八、反模式
|
||||
|
||||
- 紧耦合/顺序任务硬塞 workflow(屏障空等、token 白烧)。
|
||||
- 全程一个 `parallel()` 屏障到底(慢 agent 拖死快 agent)。
|
||||
- 归约/扁平也用 agent 而非纯 JS。
|
||||
- loop 对 `confirmed` 去重而非 `seen`(永不收敛)。
|
||||
- 不试切片直接全量大跑;该升/该降的 stage 模型用反。
|
||||
- 脚本里用 `Date.now()`/`Math.random()`(直接 throw)。
|
||||
|
||||
---
|
||||
|
||||
## 来源
|
||||
|
||||
- [Orchestrate subagents at scale with dynamic workflows — Claude Code Docs](https://code.claude.com/docs/en/workflows)(原语、16/1000 上限、保存/args/恢复、审批)
|
||||
- [Introducing dynamic workflows in Claude Code — Anthropic](https://claude.com/blog/introducing-dynamic-workflows-in-claude-code)(Bun 移植四阶段、use case 分类)
|
||||
- [Deterministic Multi-Agent Orchestration — alexop.dev](https://alexop.dev/posts/claude-code-workflows-deterministic-orchestration/)(Vue 新闻信完整脚本、对抗验证、确定性约束)
|
||||
- [A Thousand Agents, One Script — trilogyai](https://trilogyai.substack.com/p/claude-codes-dynamic-workflows-a)
|
||||
- [Claude Code Adds Dynamic Workflows — InfoQ](https://www.infoq.com/news/2026/06/dynamic-workflows-claude-code/)
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
### Resources
|
||||
- [[Claude Code 官方多Agent编排最佳实践 (2026)]]
|
||||
- [[ECC orch- 编排家族与 v2.0 团队编排]]
|
||||
- [[ECC 编排实战手册]]
|
||||
- [[Autonomous Loops 自主循环模式]]
|
||||
|
||||
### Zettelkasten
|
||||
- [[20260618073140 编排即排序门控与委派]]
|
||||
- [[Plans as Prompts设计模式]]
|
||||
74
4 - Resources/Claude-Code/Claude Code 多Agent编排 MOC.md
Normal file
74
4 - Resources/Claude-Code/Claude Code 多Agent编排 MOC.md
Normal file
@@ -0,0 +1,74 @@
|
||||
---
|
||||
created: "2026-06-18"
|
||||
type: moc
|
||||
tags: [moc, claude-code, orchestration, multi-agent, index]
|
||||
---
|
||||
|
||||
# Claude Code 多Agent编排 MOC
|
||||
|
||||
> 这个主题的总入口。把"原生原语 → 官方实践 → ECC 落地 → 实战模式 → 自治循环 → 底层原理"串成一张图。
|
||||
> 最近更新:2026-06-18(新增 orch-* 家族、官方最佳实践、dynamic workflows)。
|
||||
|
||||
---
|
||||
|
||||
## 0. 先选:我该用哪种编排?
|
||||
|
||||
| 我要的 | 用什么 | 进哪篇 |
|
||||
|--------|--------|--------|
|
||||
| 快、聚焦、只关心结果的工人 | **subagents**(内置 Explore/Plan/general-purpose) | [[Claude Code 官方多Agent编排最佳实践 (2026)]] |
|
||||
| 工人要互相分享/挑战/自协调 | **agent teams**(实验性) | [[Claude Code Agent Teams 官方多Agent编排]] |
|
||||
| 一会话协调不过来 / 想固化成可重跑脚本 | **dynamic workflows** | [[Claude Code Dynamic Workflows 最佳实践与实例]] |
|
||||
| 单仓库编码全流程 + 两道人类门 | **ECC orch-* 家族** | [[ECC orch- 编排家族与 v2.0 团队编排]] |
|
||||
| 多任务并行(tmux/worktree) | dmux / orchestrate-worktrees | [[ECC 编排实战手册]]、[[dmux 多Agent并行编排]] |
|
||||
| 有 RFC、多依赖单元、评审≠作者 | Ralphinho RFC-DAG | [[Ralphinho RFC-DAG 编排模式]] |
|
||||
| 无人值守长跑 / 定时 | 自治循环 / harness | [[Autonomous Loops 自主循环模式]]、[[Autonomous Agent Harness 自主代理框架]] |
|
||||
| 整项目多 milestone 生命周期 | GSD | [[GSD 方法论与最佳实践]] |
|
||||
|
||||
> 核心心法见 → [[20260618073140 编排即排序门控与委派]](编排 = 排序 + 门控 + 委派,仪式随爆炸半径缩放)。
|
||||
|
||||
---
|
||||
|
||||
## 1. 原生原语与官方实践(Anthropic / Claude Code 官方)
|
||||
|
||||
- [[Claude Code 官方多Agent编排最佳实践 (2026)]] —— 三原语对比、orchestrator-worker 七原则、3-5 规模、成本(4x/15x token)、eval
|
||||
- [[Claude Code Agent Teams 官方多Agent编排]] —— lead + 队友、共享任务列表、互相通信
|
||||
- [[Claude Code Dynamic Workflows 最佳实践与实例]] —— pipeline/parallel、质量模式、Vue 新闻信 / deep-research / Bun 移植实例
|
||||
|
||||
## 2. ECC 落地(把原则固化成可装的 skill/命令)
|
||||
|
||||
- [[ECC orch- 编排家族与 v2.0 团队编排]] —— orch-pipeline 门控引擎、plan-orchestrate、team-agent-orchestration、dynamic-workflow-mode
|
||||
- [[ECC 编排替代方案 (orchestrate 迁移)]] —— /orchestrate 退役后的 8 条迁移路线 + Windows 可用性
|
||||
- [[ECC 编排实战手册]] —— 6 种正交模式的真实命令、决策树、工具栈
|
||||
|
||||
## 3. 实战编排模式
|
||||
|
||||
- [[Ralphinho RFC-DAG 编排模式]] —— RFC 拆 DAG、tier 分层管道、合并队列 + eviction、评审≠作者
|
||||
- [[dmux 多Agent并行编排]] —— tmux 多 pane 多 agent、5 个 pattern
|
||||
- [[GSD 方法论与最佳实践]] —— Get Shit Done 项目级多阶段编排
|
||||
- (Santa Loop 双评审、PRP、devfleet 等 → 详见 [[ECC 编排实战手册]] / [[ECC 编排替代方案 (orchestrate 迁移)]])
|
||||
|
||||
## 4. 自治循环与长跑
|
||||
|
||||
- [[Autonomous Loops 自主循环模式]] —— 6 种 loop 模式(sequential / continuous-PR / rfc-dag / infinite …)+ 反模式
|
||||
- [[Autonomous Agent Harness 自主代理框架]] —— 持久记忆、cron、dispatch、computer use、任务队列
|
||||
|
||||
## 5. 底层原理(Zettel — 为什么这样编排有效)
|
||||
|
||||
- [[20260618073140 编排即排序门控与委派]] —— 核心心法
|
||||
- [[20260308213100 Everything Claude Code Agent 编排模式]] —— 顺序阶段 / 迭代检索 / 两终端 / 模型选择
|
||||
- [[20260308221500 Everything Claude Code 多服务编排详解]] —— 多服务编排分层
|
||||
- [[20260320100100 上下文腐烂与全新窗口隔离]] —— 为什么阶段间要隔离上下文
|
||||
- [[20260320100300 Plans as Prompts设计模式]] —— 把计划当 prompt 传递
|
||||
- [[20260414230719 Agent 工具 worktree 隔离是 Windows 原生并行的关键]] —— 会话内并行隔离
|
||||
- [[20260319120200 MCP数量与上下文窗口的反比关系]] —— 工具数量与上下文权衡
|
||||
- [[20260308213200 Everything Claude Code Token 优化]] —— 子 agent 用 haiku 省成本
|
||||
|
||||
## 6. 相关基础
|
||||
|
||||
- [[Everything Claude Code 完整指南]]、[[Everything Claude Code 方法论与最佳实践]]、[[Everything Claude Code 用法速查]]
|
||||
|
||||
---
|
||||
|
||||
## Related MOCs
|
||||
|
||||
- (待建)Claude Code 工程化 MOC、AI Agent 安全 MOC
|
||||
127
4 - Resources/Claude-Code/Claude Code 官方多Agent编排最佳实践 (2026).md
Normal file
127
4 - Resources/Claude-Code/Claude Code 官方多Agent编排最佳实践 (2026).md
Normal file
@@ -0,0 +1,127 @@
|
||||
---
|
||||
created: "2026-06-18"
|
||||
type: resource
|
||||
tags: [resource, claude-code, multi-agent, orchestration, subagents, agent-teams, dynamic-workflows, best-practices, anthropic]
|
||||
source: "https://www.anthropic.com/engineering/multi-agent-research-system"
|
||||
---
|
||||
|
||||
# Claude Code 官方多Agent编排最佳实践 (2026)
|
||||
|
||||
> 一手来源:Anthropic 工程博客《How we built our multi-agent research system》+ Claude Code 官方文档(agent-teams / workflows / sub-agents)。这篇讲的是 **Claude Code/Anthropic 官方**的通用编排原语与原则,和 ECC 仓库自带的 [[ECC orch- 编排家族与 v2.0 团队编排]]、[[ECC 编排实战手册]] 互补(ECC 是这些原则在单仓库编码上的落地)。
|
||||
|
||||
---
|
||||
|
||||
## 一、先选对原语:三种原生编排方式
|
||||
|
||||
2026 年 Claude Code 把"多 agent"拆成三个层次分明的原语,核心区别是**计划掌握在谁手里**:
|
||||
|
||||
| | **Subagents** | **Agent Teams**(实验性) | **Dynamic Workflows** |
|
||||
|---|---|---|---|
|
||||
| 是什么 | 主 agent spawn 的工人 | 一个 lead 督导多个对等 session | 运行时执行的 JS 脚本 |
|
||||
| 谁决定下一步 | Claude,逐轮 | lead,逐轮 | **脚本本身** |
|
||||
| 中间结果存哪 | Claude 上下文窗口 | 共享任务列表 | **脚本变量**(不进上下文) |
|
||||
| agent 间通信 | ❌ 只能向主 agent 汇报 | ✅ 队友互相发消息 | 脚本协调 |
|
||||
| 规模 | 每轮几个 | 一把(3-5)长跑对等体 | **几十到几百 / 次** |
|
||||
| 中断 | 重启该轮 | 队友继续跑 | 同会话内可恢复 |
|
||||
| Token 成本 | 较低(结果摘要回传) | 高(每队友独立实例) | 高(可几百 agent) |
|
||||
|
||||
**选择规则**:
|
||||
- **Subagents** —— 要快、聚焦、只关心结果的工人(研究、验证、并行审查)。先用内置的 `Explore`/`Plan`/`general-purpose`,反复 spawn 同一个再定制 YAML(锁定 model + system prompt,成本可预测)。
|
||||
- **Agent Teams** —— 工人需要**互相分享发现、互相挑战、自协调**时(竞争性假设 debug、跨前后端协作)。需开 `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`(实验性,默认关闭)。
|
||||
- **Dynamic Workflows** —— **一个会话协调不过来**、或想把编排**固化成可复用、可重跑的脚本**时(全库 bug 扫描、500 文件迁移、需交叉验证的研究)。`/deep-research` 是内置范例;`ultracode` 关键词或 `/effort ultracode` 触发。
|
||||
|
||||
> 把"计划"搬进代码的额外好处:workflow 能施加**可重复的质量模式**——让独立 agent **对抗式互审**彼此的发现、或从多个角度起草方案再相互权衡,比单遍更可信。
|
||||
|
||||
---
|
||||
|
||||
## 二、Anthropic 官方 orchestrator-worker 核心原则
|
||||
|
||||
来自他们生产研究系统的实战教训:
|
||||
|
||||
1. **多 agent 不是万能,看任务形态**
|
||||
- **赢**:广度优先、可并行、信息超单上下文、要接很多复杂工具。**Opus 领队 + Sonnet 工人比单 Opus 高 90.2%**(内部研究评测)。
|
||||
- **输 / 别用**:需要所有 agent 共享上下文、或 agent 间强依赖的任务——**大多数编码任务属于此类**。顺序、紧耦合的工作并行没收益。
|
||||
|
||||
2. **成本要算账**:agent 比 chat 用 **~4 倍** token,多 agent 系统 **~15 倍**。只有任务价值撑得起才用。**Token 用量本身解释了 80% 的成功率差异**;"升级到更强模型,比把 token 预算翻倍更划算"。
|
||||
|
||||
3. **显式教会编排者怎么委派**:别只说"研究一下 X"。给每个子 agent:**目标、输出格式、工具指引、清晰边界**。模糊委派导致重复和遗漏。把**努力随复杂度缩放**写进 prompt(简单查证 1 agent / 3-10 工具调用;对比类 2-4 agent / 各 10-15 次)。
|
||||
|
||||
4. **上下文接地(context grounding)**:给每个子 agent **精确、相关的最小上下文**,而不是把整个领队对话史全塞过去——既浪费又常常适得其反。构造精瘦、定向的上下文包。
|
||||
|
||||
5. **并行两层**:领队一次起 3-5 个子 agent(而非串行)+ 每个子 agent 同时用 3+ 工具 → 复杂查询**提速最多 90%**。
|
||||
- 当前限制:领队**同步**等每批子 agent 完成才推进,是瓶颈;异步执行仍是未解难题。
|
||||
|
||||
6. **评估从小做起**:~20 条代表真实用法的查询即可起步(prompt 一调可能 30%→80%,效应大到几个用例就看得出)。用 **LLM-as-judge**(单次调用,0.0-1.0 打分 + pass/fail)最稳、最贴人判断。**别跳过人测**——人能发现 eval 漏掉的边缘案例(幻觉、系统故障、偏好 SEO 内容而非权威源)。对会改状态的 agent,**评估最终状态**而非中间步骤。
|
||||
|
||||
7. **生产可靠性**:能从出错处**断点续跑**而非从头重来;加全链路 tracing 诊断失败;用 **rainbow deployment**(新旧版本并存、渐进切流)避免打断在跑的 agent;让 Claude 自己当 prompt 工程师诊断失败模式(工具描述自优化曾带来后续 agent **完成时间降 40%**)。
|
||||
|
||||
8. **安全三件套**:最小必要权限、优先可逆操作而非破坏性操作、高风险决策保留**人类审批检查点**。
|
||||
|
||||
---
|
||||
|
||||
## 三、可直接照做的数字化实践(官方文档)
|
||||
|
||||
- **团队/并行规模 3-5 个**起步,每个工人 **5-6 个任务**。"三个专注的队友常胜过五个分散的。"15 个独立任务→3 个工人是好起点。
|
||||
- **任务粒度**:太小→协调开销盖过收益;太大→工人跑太久不回检、浪费风险高。**自包含、能产出清晰交付物**(一个函数 / 一个测试文件 / 一次审查)为佳。
|
||||
- **避免文件冲突**:让每个工人**拥有不同的文件集**,否则互相覆盖。
|
||||
- **从研究/审查类入手**:边界清晰、不写代码的任务(审 PR、调研库、查 bug)最能体现并行价值,又没有并行写代码的协调坑。
|
||||
- **风险任务上 plan 审批门**:队友先在只读 plan 模式出方案,lead 批准后才动手(可用 prompt 给 lead 判据,如 "only approve plans that include test coverage")。
|
||||
- **用 hooks 做质量门**(agent teams):`TeammateIdle` / `TaskCreated` / `TaskCompleted` 退出码 2 可拦截并反馈、保持工人继续干。
|
||||
- **角色复用**:同一个 subagent 定义(如 `security-reviewer`)既能当委派子 agent,也能当团队队友(队友会继承其 `tools` 白名单和 `model`,定义体追加进 system prompt;但 `skills`/`mcpServers` 字段当队友时不生效)。
|
||||
- **给足上下文**:队友自动加载 CLAUDE.md / MCP / skills,但**不继承 lead 的对话史**——任务细节要写进 spawn prompt。
|
||||
- **Workflow 硬上限**:并发 ≤16 agent,单次总计 ≤1000 agent;workflow 脚本本身**不能直接读写文件或跑 shell**(由它编排的 agent 来做);**先在小切片(一个目录 / 一个窄问题)上跑**估成本。
|
||||
|
||||
### 两个最高频的质量组合(跨三种原语通用)
|
||||
|
||||
- **多镜头并行审查**:同一份改动让 security / performance / test-coverage 三个不同视角 agent 并行看,领队综合。多样性能抓到单一审查者漏掉的失败模式。
|
||||
- **对抗式假设收敛**:多个独立调查者各执一个假设、**被明确要求互相证伪**(像科学辩论),存活下来的理论才更可能是真因——对抗顺序调查的 anchoring bias。
|
||||
|
||||
---
|
||||
|
||||
## 四、反模式
|
||||
|
||||
- 把**紧耦合编码任务**硬塞多 agent —— 共享上下文需求会让它比单 agent 更差更贵。
|
||||
- 把**整个领队上下文**复制给每个子 agent(违反 context grounding)。
|
||||
- **无退出条件**的循环;**任务状态不回写**导致依赖卡死(agent teams 已知限制)。
|
||||
- 让团队**长时间无人值守** —— 要盯进度、纠偏、随时综合。
|
||||
- 默认就上最重的方案 —— **把编排模式匹配到任务**,而非一律 agent teams。
|
||||
|
||||
---
|
||||
|
||||
## 五、与 ECC / 自建编排的关系
|
||||
|
||||
| 维度 | 官方原语 | ECC 落地 |
|
||||
|------|---------|---------|
|
||||
| 单仓库编码全流程 | subagents + 两道审批 | [[ECC orch- 编排家族与 v2.0 团队编排]] 的 `orch-pipeline` |
|
||||
| 团队看板 / 合并门 | agent teams 共享任务列表 | `team-agent-orchestration`(Kanban + merge gate) |
|
||||
| 脚本化大规模 fan-out | dynamic workflows | ECC 的 dmux / `orchestrate-worktrees.js`(tmux 路线,见 [[ECC 编排实战手册]]) |
|
||||
| 评审者≠作者 | 多镜头 / 对抗审查 | Santa Loop 双评审、Ralphinho([[Ralphinho RFC-DAG 编排模式]]) |
|
||||
| 自治长跑 | 续跑 + 检查点 | [[Autonomous Loops 自主循环模式]] |
|
||||
|
||||
**一句话**:官方给的是**原语和原则**(subagents / teams / workflows + orchestrator-worker 七条);ECC 给的是**把这些原则固化成可装的 skill/命令**。两者读法:先用官方原则判断"该不该并行、怎么委派",再用 ECC 的现成 skill 省去手搭。
|
||||
|
||||
---
|
||||
|
||||
## 来源
|
||||
|
||||
- [How we built our multi-agent research system — Anthropic Engineering](https://www.anthropic.com/engineering/multi-agent-research-system)(90.2% / 4x·15x token / context grounding / eval / 生产经验)
|
||||
- [Orchestrate teams of Claude Code sessions — Claude Code Docs](https://code.claude.com/docs/en/agent-teams)(teams vs subagents 对比表、3-5 规模、plan 审批、hooks 门、限制)
|
||||
- [Orchestrate subagents at scale with dynamic workflows — Claude Code Docs](https://code.claude.com/docs/en/workflows)(四原语对比、16/1000 上限、`/deep-research`、`ultracode`)
|
||||
- 社区补充:[hidekazu-konishi 编排指南](https://hidekazu-konishi.com/entry/claude_code_subagents_and_orchestration_guide.html)、[addyosmani — The Code Agent Orchestra](https://addyosmani.com/blog/code-agent-orchestra/)
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
### Resources
|
||||
- [[ECC orch- 编排家族与 v2.0 团队编排]]
|
||||
- [[ECC 编排实战手册]]
|
||||
- [[ECC 编排替代方案 (orchestrate 迁移)]]
|
||||
- [[Autonomous Loops 自主循环模式]]
|
||||
- [[Ralphinho RFC-DAG 编排模式]]
|
||||
- [[Everything Claude Code 完整指南]]
|
||||
|
||||
### Zettelkasten
|
||||
- [[20260618073140 编排即排序门控与委派]]
|
||||
- [[Everything Claude Code Agent 编排模式]]
|
||||
- [[MCP数量与上下文窗口的反比关系]]
|
||||
203
4 - Resources/Claude-Code/ECC orch- 编排家族与 v2.0 团队编排.md
Normal file
203
4 - Resources/Claude-Code/ECC orch- 编排家族与 v2.0 团队编排.md
Normal file
@@ -0,0 +1,203 @@
|
||||
---
|
||||
created: "2026-06-18"
|
||||
type: resource
|
||||
tags: [resource, claude-code, ECC, orchestration, multi-agent, orch-pipeline, dynamic-workflow, team-orchestration]
|
||||
source: "https://github.com/affaan-m/ECC"
|
||||
---
|
||||
|
||||
# ECC orch-* 编排家族与 v2.0 团队编排
|
||||
|
||||
> 本笔记补的是 **ECC v2.0.0(2026-06-09)新增**的编排层。早期编排笔记停在 2026-04,覆盖的是 `/orchestrate`(已退役)、`/multi-*`、GSD、devfleet、自治循环。这一篇专门讲 **`orch-*` 家族、`plan-orchestrate`、团队编排(Kanban)、动态工作流**,以及 2.0 的"操作员系统"理念。
|
||||
>
|
||||
> 相关:[[ECC 编排实战手册]]、[[ECC 编排替代方案 (orchestrate 迁移)]]、[[Autonomous Loops 自主循环模式]]、[[Ralphinho RFC-DAG 编排模式]]、[[Everything Claude Code 完整指南]]、[[Everything Claude Code Agent 编排模式]]
|
||||
|
||||
---
|
||||
|
||||
## 1. `orch-*` 家族 —— 把单会话流程产品化
|
||||
|
||||
`/orchestrate` 退役后,ECC 2.0 用 **`orch-*` skill 家族**取而代之。这不是 5 个独立流程,而是 **5 个薄包装(thin wrapper)共用一个引擎 `orch-pipeline`**。包装层只做三件事:给任务**分级**、决定**跑哪几个阶段**、把每个阶段**委派**给现成的 ECC agent/命令。**它不重新实现任何东西**(`/feature-dev`、`/plan`、`/code-review`、`/build-fix`、`/refactor-clean`、`/gan-build`、`tdd-workflow` 都是被它编排的)。
|
||||
|
||||
### 五个操作 = 五种任务意图
|
||||
|
||||
| skill | 操作 | 触发条件 | 默认尺寸 | 第一步(关键) |
|
||||
|-------|------|---------|---------|--------------|
|
||||
| `orch-add-feature` | feature | 能力**还不存在** | standard | 先写**新**失败测试 → 实现 |
|
||||
| `orch-fix-defect` | fix | 行为**坏了** | small | 先写**回归**失败测试 → 修 |
|
||||
| `orch-change-feature` | tweak | 行为在但**不符合期望** | small | 先改**现有**测试到新规格 → 改实现 |
|
||||
| `orch-refine-code` | refactor | 行为不变、**结构**改善 | standard | 先确认测试绿 → 重构 |
|
||||
| `orch-build-mvp` | mvp | 从 design/spec **文档引导** | large | 读文档 → 切薄竖切片(vertical slices) |
|
||||
|
||||
> 选错入口没关系:引擎会先分级,small/trivial 的 feature 会自动塌缩成 `4→5→6`。
|
||||
|
||||
### 共用引擎 `orch-pipeline` —— 门控的 R-P-T-R-C 流水线
|
||||
|
||||
七个阶段(Phase 0 永远跑):
|
||||
|
||||
- **0 Intake** —— 复述请求;MVP 还要读 spec 抽 scope/锁定决策/功能清单
|
||||
- **1 Research & Reuse** —— `gh search repos/code` → Context7/官方文档 → 包仓库 → Exa;**优先采用现成实现**
|
||||
- **2 Plan** —— 委派 `planner`(结构性改动用 `architect`/`code-architect`),产出 `task_list`(薄竖切片排序)→ **GATE 1**
|
||||
- **3 Scaffold** —— 仅 MVP:立起第一个端到端切片
|
||||
- **4 Implement (TDD)** —— 走 `tdd-guide`/`tdd-workflow`:red→green→refactor,遵守该操作的"第一步"规则
|
||||
- **5 Review** —— `code-reviewer`/`/code-review`;碰安全触发器加 `security-reviewer`
|
||||
- **6 Commit** —— conventional commit,每个逻辑块一个 → **GATE 2**
|
||||
|
||||
### 核心设计:仪式随"爆炸半径"缩放(right-sizing)
|
||||
|
||||
Step 0 按三个信号(改动文件数 / 是否引入新依赖或契约 / 设计模糊度)取**最高**那一档:
|
||||
|
||||
| Tier | 文件 | 新依赖·契约 | 模糊度 | 跑哪些阶段 |
|
||||
|------|------|------------|--------|-----------|
|
||||
| trivial | 1、几行 | 无 | 改动显而易见 | 4 → 5 → 6 |
|
||||
| small | 1 文件/函数 | 无 | 读完代码就清楚 | (1 轻量) → 4 → 5 → 6 |
|
||||
| standard | 2–5 文件 | 可能新内部模块 | 一个真实选择 | 1 → 2 → 4 → 5 → 6 |
|
||||
| large | 多/横切 | 新外部依赖、公开 API、spec 文档 | 多个开放问题 | 1 → 2 → (3) → 4 → 5 → 6 |
|
||||
|
||||
> 平局打破:碰**安全触发器**或**公开 API/契约**的,无论文件多少,**至少 standard**。
|
||||
|
||||
### 两道人类门(gated, not autonomous)
|
||||
|
||||
1. **GATE 1(Plan 之后)** —— 先给 `task_list`,用户批准前**不写实现代码**
|
||||
2. **GATE 2(Commit 之前)** —— 先给 diff 摘要 + 提交信息,用户确认前**不提交**
|
||||
|
||||
两门之间一路不停。这正是 `orch-*` 与全自治循环([[Autonomous Loops 自主循环模式]])的根本区别:**有人在环**。
|
||||
|
||||
### 阶段→agent 映射
|
||||
|
||||
| 阶段 | 主用 | 兜底/升级 |
|
||||
|------|------|----------|
|
||||
| Intake/理解 | `code-explorer` | tweak/fix/refactor 前先 trace 现有路径 |
|
||||
| Plan | `planner` | `architect`、`code-architect`(结构性) |
|
||||
| Implement | `tdd-guide` / `tdd-workflow` | 构建炸了用 `build-error-resolver`/`/build-fix` |
|
||||
| Review | `code-reviewer` / `/code-review` | 语言专属 reviewer(python/typescript-reviewer…) |
|
||||
| Security | `security-reviewer` | — |
|
||||
| MVP 内循环 | `/gan-build "<brief>" --skip-planner` | 驱动 `gan-generator`→`gan-evaluator` |
|
||||
|
||||
安全触发器(任一即拉 `security-reviewer`):认证授权、用户输入、DB 查询、文件路径、外部 API、加密、密钥凭据。
|
||||
|
||||
> 与 `/feature-dev` 的区别:`/feature-dev` 是这套流程的**独立版**;`orch-add-feature` 通过共用 `orch-pipeline` 引擎(分级器 + 两门),让 trivial 功能能右尺寸到 `4→5→6`,并和家族其余操作保持一致。
|
||||
|
||||
---
|
||||
|
||||
## 2. `plan-orchestrate` —— 把计划文档翻译成 agent 链
|
||||
|
||||
**纯生成,不执行**。输入一份多步计划(PRD/RFC/implementation plan),输出**每步一条可直接粘贴**的 `/orchestrate custom` 调用。三件事:
|
||||
|
||||
1. **检测 ECC 安装模式** —— plugin 形态命令是 `/everything-claude-code:orchestrate`、agent 是 `everything-claude-code:<name>`;legacy 形态是 `/orchestrate`、`<name>`。**一份输出里不混用两种**。
|
||||
2. **拆步骤**(六级优先:显式编号 `## Step N` > 表格 Step 列 > `---` 分隔的动词块 > 否则每个 H2 一步)
|
||||
3. **打标签 + 选 agent 链**(12 个触发词 → 默认链):
|
||||
|
||||
| 标签 | 默认 agent 链 |
|
||||
|------|--------------|
|
||||
| `design` | `planner,architect` |
|
||||
| `impl` | `tdd-guide,<lang>-reviewer` |
|
||||
| `impl+security` | `tdd-guide,<lang>-reviewer,security-reviewer` |
|
||||
| `impl+db` | `tdd-guide,database-reviewer,<lang>-reviewer` |
|
||||
| `refactor` | `architect,refactor-cleaner,<lang>-reviewer` |
|
||||
| `migration` | `architect,tdd-guide,<lang>-reviewer` |
|
||||
| `build` | `<lang>-build-resolver` |
|
||||
| `security` | `security-reviewer,<lang>-reviewer` |
|
||||
| `test` | `tdd-guide,e2e-runner` |
|
||||
| `db` | `database-reviewer,<lang>-reviewer` |
|
||||
| `docs` | `doc-updater` |
|
||||
| `loop` | `loop-operator` |
|
||||
|
||||
输出含:全步骤总表、每步详情块(意图 + 选链理由 + 可粘贴命令)、批量执行块。
|
||||
|
||||
---
|
||||
|
||||
## 3. 团队编排 —— Agent Kanban
|
||||
|
||||
### `team-agent-orchestration`:把 agent 当队友
|
||||
|
||||
核心:agent 要有**显式 owner、scope、状态、合并门**。用 Agent Kanban 让并行工作可见。
|
||||
|
||||
**列(及退出标准)**:Backlog(写好验收) → Ready(分配 owner+分支/worktree) → Running(有 handoff 产物+改动文件) → Review(测试/diff/风险通过) → Merged。另有 Blocked(blocker 有 owner+下一步)、Archived。
|
||||
|
||||
**工作项 schema**(关键字段):`id / title / owner / state / branch / worktree / acceptance[] / merge_gate / handoff`。
|
||||
|
||||
**控制面板(control pane)应暴露**:活跃工作项及状态、owner/harness/分支/worktree/心跳、handoff/测试/PR 链接、按 owner 分组的 blocker、**按 gate 而非感觉判断的合并就绪度**、可复用工作流候选。
|
||||
|
||||
> 关键口号:**merge gate, not hope gate**(用门判断能否合并,而不是凭希望)。
|
||||
|
||||
### `team-builder`:按需组队
|
||||
|
||||
交互菜单从可用 agent 里拼并行团队。流程:`claude agents` 发现 agent → 按领域分组菜单 → 接受编号("1,3")或名字("security + seo") → **上限 5 个**(再多边际递减) → 用 Agent 工具 `subagent_type: general-purpose` 并行 spawn → 汇总(各 agent 输出 + 一致/冲突/建议)。
|
||||
|
||||
> 注意:用**并行 Agent 工具调用**(各自独立做事),不是 TeamCreate(那是给 agent 之间对话用的)。
|
||||
|
||||
---
|
||||
|
||||
## 4. `dynamic-workflow-mode` —— 为任务现造载体
|
||||
|
||||
让 agent 能**生成/改造工作流**,而不只执行静态命令。何时启用:任务需要自定义 loop/评估器/爬虫/fixture 生成器/watcher/dashboard;多个 agent 要同一可重复流程(但还没沉淀成 skill);需要持久 handoff 产物、eval 证据或操作员批准。
|
||||
|
||||
**决策树**:一次性 → 内联;输入会变的重复任务 → 建**任务局部载体(task-local harness)**;跨队友/跨仓库重复 → **抽成共享 skill**;有外部状态/排队/审批 → 先加控制面板可见性;有安全风险 → 加 eval 门 + 人类合并门。
|
||||
|
||||
**抽成共享 skill 的条件**(满足 ≥2):多会话/仓库/团队重复出现、需要特定语言/工具/安全顺序、失败反复发生、输入输出契约稳定、能受益于控制面板/状态板/团队 handoff。
|
||||
|
||||
**每类工作最便宜的可靠 eval 门**:代码 → 聚焦测试+lint+覆盖率+一条集成路径;UI → 浏览器冒烟+截图+溢出/报错检查;agent 工作流 → fixture transcript / 带预期路由的种子工作项;研究/内容 → 来源中立的 brief + claim 清单;集成 → dry-run 命令 + 配置校验 + 无密钥扫描。
|
||||
|
||||
---
|
||||
|
||||
## 5. v2.0 编排理念:操作员系统(operator system)
|
||||
|
||||
ECC 2.0 的论点:agent 工具正从"单人聊天窗"走向**团队编排系统**(看板、控制面板、动态工作流、eval 门、共享 skill)。三层架构:
|
||||
|
||||
1. **Meta-harness** —— 可移植的 skills/rules/hooks/MCP 约定/发布门/eval/安全证据
|
||||
2. **专属 ECC agent** —— 一个**操作** ECC 资产的 agent(不只把它们当静态指令读)
|
||||
3. **控制面板 / agentic IDE** —— 把 session/队列/skill/记忆/证据/发布/团队工作流变成**可观测**的操作员界面
|
||||
|
||||
提炼出的几条编排原则(可单独当 zettel 看,见 [[20260618073140 编排即排序门控与委派]]):
|
||||
|
||||
1. **编排 = 排序 + 门控 + 委派**(不是新 AI):价值在系统化排序、两道门、委派给被验证过的 agent。
|
||||
2. **仪式随爆炸半径缩放**:trivial 跳过 Research/Plan;large 才上全套 + 安全审查。(同样体现在 Ralphinho 的 tier 分层、`parallel-execution-optimizer` 的"只在写面不冲突处并行"。)
|
||||
3. **权威随领域走**:Codex=后端权威、Gemini=前端权威、Claude=代码主权(所有落盘);跨域意见仅供参考。(见 [[ECC 编排替代方案 (orchestrate 迁移)]] 路线 D)
|
||||
4. **并行必须有可观测的合并门**:每个并行单元都要有 owner、分支/worktree、验收、证据(测试/截图)、merge gate。
|
||||
5. **可复用的资产是工作流,不是答案**:一次性答案会扔;证明答案可用的任务局部载体有价值;多团队复用的共享 skill 才是制度资产。
|
||||
6. **控制面板胜过隐藏的聊天输出**:"谁拥有这张卡、改了什么、什么失败、什么通过、什么能合并"才是操作员真正需要的。
|
||||
|
||||
---
|
||||
|
||||
## 6. 这一层在整张编排图里的位置
|
||||
|
||||
| 你要的 | 用 | 出处 |
|
||||
|--------|-----|------|
|
||||
| 单任务全流程、要分级 + 两道人类门 | `orch-add-feature` / `orch-fix-defect` / `orch-change-feature` / `orch-refine-code` | skill |
|
||||
| 从 design/spec 文档起 MVP | `orch-build-mvp` | skill |
|
||||
| 把一份 PRD/RFC 翻成可粘贴的 agent 链 | `plan-orchestrate` | skill(纯生成) |
|
||||
| 多 agent 并行 + 看板可见性 + 合并门 | `team-agent-orchestration` | skill |
|
||||
| 按需从可用 agent 拼并行小队(≤5) | `team-builder` | skill |
|
||||
| 给任务现造 loop/评估器/dashboard | `dynamic-workflow-mode` | skill |
|
||||
| 全自治长跑循环 | 见 [[Autonomous Loops 自主循环模式]]、[[Ralphinho RFC-DAG 编排模式]] | — |
|
||||
| 跨 harness/tmux 并行 | 见 [[ECC 编排实战手册]]、[[dmux 多Agent并行编排]] | — |
|
||||
|
||||
---
|
||||
|
||||
## 来源(直接读取的仓库文件)
|
||||
|
||||
- `skills/orch-pipeline/SKILL.md`(共用引擎:5 操作、Step 0 分级表、7 阶段、两门、agent 映射、安全触发器)
|
||||
- `skills/orch-add-feature/SKILL.md` 及 `orch-fix-defect/`、`orch-change-feature/`、`orch-refine-code/`、`orch-build-mvp/`
|
||||
- `skills/plan-orchestrate/SKILL.md`(安装模式检测、拆步、12 标签链)
|
||||
- `skills/team-agent-orchestration/SKILL.md`(Kanban 列、work item schema、control pane)
|
||||
- `skills/team-builder/SKILL.md`、`skills/dynamic-workflow-mode/SKILL.md`
|
||||
- `skills/parallel-execution-optimizer/SKILL.md`
|
||||
- `docs/architecture/cross-harness.md`、`docs/architecture/platform-value-loop.md`、`docs/business/team-agent-orchestration-content-pack.md`
|
||||
- `CHANGELOG.md`(2.0.0 Added: "orch-* orchestrator skill family and dynamic workflow team orchestration")
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
### Resources
|
||||
- [[ECC 编排实战手册]]
|
||||
- [[ECC 编排替代方案 (orchestrate 迁移)]]
|
||||
- [[Autonomous Agent Harness 自主代理框架]]
|
||||
- [[Autonomous Loops 自主循环模式]]
|
||||
- [[Ralphinho RFC-DAG 编排模式]]
|
||||
- [[dmux 多Agent并行编排]]
|
||||
- [[Everything Claude Code 完整指南]]
|
||||
|
||||
### Zettelkasten
|
||||
- [[20260618073140 编排即排序门控与委派]]
|
||||
- [[Everything Claude Code Agent 编排模式]]
|
||||
- [[Everything Claude Code 多服务编排详解]]
|
||||
721
4 - Resources/Claude-Code/ECC 编排实战手册.md
Normal file
721
4 - Resources/Claude-Code/ECC 编排实战手册.md
Normal file
@@ -0,0 +1,721 @@
|
||||
---
|
||||
created: "2026-04-25"
|
||||
type: resource
|
||||
tags: [resource, claude-code, ECC, orchestration, multi-agent, parallel, autonomous, hands-on]
|
||||
source: "https://github.com/affaan-m/everything-claude-code"
|
||||
---
|
||||
|
||||
# ECC 编排实战手册
|
||||
|
||||
ECC 没有"一种"编排,而是 **6 种正交模式** 散布在 commands/、skills/、scripts/ 三个层面。这份手册把每一种的真实命令、真实代码、真实出处全列出来,并明确标记"哪些有公开实操证据,哪些只能照命令文档说的去做"。
|
||||
|
||||
> 相关笔记:[[Everything Claude Code 完整指南]]、[[Everything Claude Code 方法论与最佳实践]]、[[ECC 编排替代方案 (orchestrate 迁移)]]、[[Autonomous Loops 自主循环模式]]、[[dmux 多Agent并行编排]]、[[Ralphinho RFC-DAG 编排模式]]、[[Autonomous Agent Harness 自主代理框架]]
|
||||
|
||||
---
|
||||
|
||||
## 0. 决策树:你到底在编排什么?
|
||||
|
||||
不同模式解决的是完全不同的问题。先回答 3 个问题:
|
||||
|
||||
```text
|
||||
Q1: 你需要并行,还是顺序但不间断?
|
||||
├─ 顺序但不间断 → 模式 2 (Sequential Pipeline) 或 模式 3 (Continuous PR Loop)
|
||||
└─ 并行 → Q2
|
||||
|
||||
Q2: 并行的任务之间有依赖关系吗?
|
||||
├─ 无依赖(独立的几件事) → 模式 1 (dmux / Worktree 并行)
|
||||
└─ 有依赖 → Q3
|
||||
|
||||
Q3: 需要"评审者≠实现者"的强制隔离吗?
|
||||
├─ 需要(高风险、生产代码) → 模式 4 (Ralphinho RFC-DAG) 或 模式 5 (Santa Loop 双评审)
|
||||
└─ 不需要(单 session 内 agent 委派就够) → 模式 6 (Task 工具内嵌并行)
|
||||
```
|
||||
|
||||
| 模式 | 用什么 | 真实存在 | 是否 Windows 可用 |
|
||||
|------|--------|---------|------------------|
|
||||
| 1. dmux + 多 worktree | `dmux-workflows` skill + `scripts/orchestrate-worktrees.js` | ✅ 仓库内 | ❌ 需 tmux |
|
||||
| 2. Sequential `claude -p` 管道 | shell 脚本 + `claude -p` | ✅ 官方 CLI | ✅ |
|
||||
| 3. Continuous PR Loop | `continuous-claude` 外部工具 | ✅ AnandChowdhary | ✅ |
|
||||
| 4. Ralphinho RFC-DAG | `ralphinho` 外部工具 + `ralphinho-rfc-pipeline` skill | ✅ enitrat | ✅(用 jj) |
|
||||
| 5. Santa Loop 双评审 | `/santa-loop` 命令 | ✅ ECC 命令 | ✅ |
|
||||
| 6. Task 工具内并行 | Claude Code 原生 `Task` tool | ✅ 内置 | ✅ |
|
||||
| (退役)`/orchestrate` | legacy shim → 转发到 dmux/harness | ⚠️ 已标记为 legacy | ❌ |
|
||||
| (替代)`/feature-dev` | 单功能 7 阶段全流程 | ✅ 命令存在 | ✅ |
|
||||
| (高级)`/multi-plan` `/multi-execute` | `ccg` 多模型协同(需外部 Codex/Gemini CLI) | ⚠️ 需独立安装 | 部分 |
|
||||
|
||||
---
|
||||
|
||||
## 模式 1:dmux + 多 worktree(并行独立任务)
|
||||
|
||||
### 实事求是:这是 ECC 推荐的"真正多 agent 编排"
|
||||
|
||||
ECC 仓库 `commands/orchestrate.md` 第 1 行明确写:
|
||||
|
||||
> *"Legacy slash-entry shim for dmux-workflows and autonomous-agent-harness. Prefer the skills directly."*
|
||||
|
||||
也就是说 `/orchestrate` 已退役,真实主力是 `dmux-workflows` skill。
|
||||
|
||||
### 何时用
|
||||
|
||||
- 3-5 个**互不依赖**的任务(不同模块/不同关注点)
|
||||
- 你想用不同模型/不同工具(Claude Code + Codex + OpenCode 混搭)
|
||||
- 你愿意装 tmux
|
||||
|
||||
### 真实命令(已验证)
|
||||
|
||||
```bash
|
||||
# 1. 装 dmux(GitHub: standardagents/dmux)
|
||||
# README 原话: "cd /path/to/your/project / dmux /
|
||||
# Press `n` to create a new pane, type a prompt, pick one or more agents"
|
||||
brew install tmux # 前置依赖
|
||||
|
||||
# 2. 在项目根目录起 dmux
|
||||
cd /path/to/project
|
||||
dmux
|
||||
|
||||
# 3. 在 dmux 里:
|
||||
# 按 n → 输入 prompt → 选 agent (Claude Code/Codex/Gemini/...)
|
||||
# 每个 pane 独立 session,独立 context window
|
||||
# 按 m → 把 pane 输出 merge 回主 session
|
||||
```
|
||||
|
||||
### ECC 自带的 worktree 编排器(无需 dmux)
|
||||
|
||||
如果你不想用 dmux,ECC 仓库有自己的 `scripts/orchestrate-worktrees.js`(实测存在,2873 字节)。用法是先写一个 plan.json,然后:
|
||||
|
||||
```bash
|
||||
# 仓库实际命令(scripts/orchestrate-worktrees.js usage 输出)
|
||||
node scripts/orchestrate-worktrees.js plan.json [--execute]
|
||||
node scripts/orchestrate-worktrees.js plan.json [--write-only]
|
||||
# 不带 flag 默认 dry-run,只打印计划
|
||||
```
|
||||
|
||||
`plan.json` 的真实结构(直接来自 `skills/dmux-workflows/SKILL.md`):
|
||||
|
||||
```json
|
||||
{
|
||||
"sessionName": "skill-audit",
|
||||
"baseRef": "HEAD",
|
||||
"launcherCommand": "codex exec --cwd {worktree_path} --task-file {task_file}",
|
||||
"workers": [
|
||||
{ "name": "docs-a", "task": "Fix skills 1-4 and write handoff notes." },
|
||||
{ "name": "docs-b", "task": "Fix skills 5-8 and write handoff notes." }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
可用占位符:`{worker_name}` `{worker_slug}` `{session_name}` `{repo_root}` `{worktree_path}` `{branch_name}` `{task_file}` `{handoff_file}` `{status_file}`。
|
||||
|
||||
每个 worker 会:
|
||||
1. 在 `.orchestration/<session>/` 下生成 `task.md`、`handoff.md`、`status.md`
|
||||
2. 单独开一个分支 + git worktree
|
||||
3. 在 tmux pane 里跑 `launcherCommand`
|
||||
|
||||
### 监控
|
||||
|
||||
```bash
|
||||
# 仓库实际命令
|
||||
node scripts/orchestration-status.js .claude/plan/workflow-visual-proof.json
|
||||
```
|
||||
|
||||
输出 JSON 包含:session 活动、tmux pane 元数据、worker 状态、目标、recent handoff summaries。
|
||||
|
||||
### `seedPaths`(把 dirty 文件带进 worktree)
|
||||
|
||||
如果 worker 需要看主分支没提交的本地文件(比如新写的脚本):
|
||||
|
||||
```json
|
||||
{
|
||||
"sessionName": "workflow-e2e",
|
||||
"seedPaths": [
|
||||
"scripts/orchestrate-worktrees.js",
|
||||
"scripts/lib/tmux-worktree-orchestrator.js",
|
||||
".claude/plan/workflow-e2e-test.json"
|
||||
],
|
||||
"workers": [{ "name": "docs", "task": "Update orchestration docs." }]
|
||||
}
|
||||
```
|
||||
|
||||
ECC 会在 `git worktree add` 之后把这些路径覆盖到每个 worker worktree。
|
||||
|
||||
### 5 个 dmux pattern(直接抄自 SKILL.md)
|
||||
|
||||
| 模式 | Pane 1 | Pane 2 | Pane 3 |
|
||||
|------|--------|--------|--------|
|
||||
| Research + Implement | 调研 + 写到 `/tmp/x.md` | 先写实现框架,等调研完合并 | — |
|
||||
| Multi-File Feature | DB schema + migration | API endpoints | UI 组件 |
|
||||
| Test + Fix Loop | 跑 watch mode,失败时总结 | 根据 pane 1 的输出修 | — |
|
||||
| Cross-Harness | Claude Code 审 auth 安全 | Codex 重构 utility 性能 | Claude Code 写 E2E |
|
||||
| Code Review Pipeline | 看 src/api 安全 | 看 src/api 性能 | 看 src/api 测试覆盖 |
|
||||
|
||||
### 硬约束(SKILL.md 原话)
|
||||
|
||||
> *"Independent tasks only. Don't parallelize tasks that depend on each other's output."*
|
||||
> *"Each pane is a full agent session — keep total panes under 5-6."*
|
||||
|
||||
---
|
||||
|
||||
## 模式 2:Sequential `claude -p` 管道(最朴素,最稳)
|
||||
|
||||
### 何时用
|
||||
|
||||
- 你想要**确定性**:每步独立 context,不会被前面污染
|
||||
- 你想要 CI/CD 集成
|
||||
- 你愿意写 shell
|
||||
|
||||
### 真实例子(skills/autonomous-loops/SKILL.md 原文)
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# daily-dev.sh — Sequential pipeline for a feature branch
|
||||
set -e
|
||||
|
||||
# Step 1: Implement the feature
|
||||
claude -p "Read the spec in docs/auth-spec.md. Implement OAuth2 login in src/auth/. Write tests first (TDD). Do NOT create any new documentation files."
|
||||
|
||||
# Step 2: De-sloppify (cleanup pass)
|
||||
claude -p "Review all files changed by the previous commit. Remove any unnecessary type tests, overly defensive checks, or testing of language features (e.g., testing that TypeScript generics work). Keep real business logic tests. Run the test suite after cleanup."
|
||||
|
||||
# Step 3: Verify
|
||||
claude -p "Run the full build, lint, type check, and test suite. Fix any failures. Do not add new features."
|
||||
|
||||
# Step 4: Commit
|
||||
claude -p "Create a conventional commit for all staged changes. Use 'feat: add OAuth2 login flow' as the message."
|
||||
```
|
||||
|
||||
### 关键设计原则(原文)
|
||||
|
||||
1. **每步隔离** —— 新 context window 意味着不会有前一步的污染
|
||||
2. **顺序敏感** —— 每步建立在上一步留下的文件状态上
|
||||
3. **`set -e` 失败立即停**
|
||||
4. **负面指令危险** —— 别说"不要测类型系统",改成单独加一个 cleanup step
|
||||
|
||||
### 模型路由变体
|
||||
|
||||
```bash
|
||||
# 用 Opus 做深度分析
|
||||
claude -p --model opus "Analyze the codebase architecture and write a plan for adding caching..."
|
||||
|
||||
# 用 Sonnet 实现
|
||||
claude -p "Implement the caching layer according to the plan in docs/caching-plan.md..."
|
||||
|
||||
# 用 Opus 审查
|
||||
claude -p --model opus "Review all changes for security issues, race conditions, and edge cases..."
|
||||
```
|
||||
|
||||
### 工具限制变体
|
||||
|
||||
```bash
|
||||
# 只读分析
|
||||
claude -p --allowedTools "Read,Grep,Glob" "Audit this codebase for security vulnerabilities..."
|
||||
|
||||
# 只写实现
|
||||
claude -p --allowedTools "Read,Write,Edit,Bash" "Implement the fixes from security-audit.md..."
|
||||
```
|
||||
|
||||
### De-sloppify pattern(关键加分项)
|
||||
|
||||
任何"实现"步骤后面都跟一个清理步骤,而不是用负面指令限制实现者:
|
||||
|
||||
```bash
|
||||
for feature in "${features[@]}"; do
|
||||
claude -p "Implement $feature with TDD."
|
||||
claude -p "Cleanup pass: review changes, remove test/code slop, run tests."
|
||||
claude -p "Run build + lint + tests. Fix any failures."
|
||||
claude -p "Commit with message: feat: add $feature"
|
||||
done
|
||||
```
|
||||
|
||||
> 原文洞察:*"Two focused agents outperform one constrained agent."*
|
||||
|
||||
---
|
||||
|
||||
## 模式 3:Continuous PR Loop(多日自治)
|
||||
|
||||
### 何时用
|
||||
|
||||
- 多日的迭代项目(比如"加完整测试覆盖率")
|
||||
- 每次迭代要走 PR + CI
|
||||
- 你愿意用别人写好的工具(`continuous-claude`)
|
||||
|
||||
### 真实工具(已验证存在)
|
||||
|
||||
- **GitHub:** github.com/AnandChowdhary/continuous-claude
|
||||
- **作者博客:** https://anandchowdhary.com/blog/2025/running-claude-code-in-a-loop
|
||||
- **HN 讨论:** https://news.ycombinator.com/item?id=45938517
|
||||
|
||||
README 原话:
|
||||
|
||||
> *"Run Claude Code in a continuous loop, autonomously creating PRs, waiting for checks, and merging."*
|
||||
|
||||
### 真实命令
|
||||
|
||||
```bash
|
||||
# 基础: 10 次迭代
|
||||
continuous-claude --prompt "Add unit tests for all untested functions" --max-runs 10
|
||||
|
||||
# 成本上限
|
||||
continuous-claude --prompt "Fix all linter errors" --max-cost 5.00
|
||||
|
||||
# 时间盒
|
||||
continuous-claude --prompt "Improve test coverage" --max-duration 8h
|
||||
|
||||
# 加 reviewer 子步骤
|
||||
continuous-claude \
|
||||
--prompt "Add authentication feature" \
|
||||
--max-runs 10 \
|
||||
--review-prompt "Run npm test && npm run lint, fix any failures"
|
||||
|
||||
# 用 worktree 并行多实例
|
||||
continuous-claude --prompt "Add tests" --max-runs 5 --worktree tests-worker &
|
||||
continuous-claude --prompt "Refactor code" --max-runs 5 --worktree refactor-worker &
|
||||
wait
|
||||
```
|
||||
|
||||
### 跨迭代上下文桥(`SHARED_TASK_NOTES.md`)
|
||||
|
||||
迭代之间靠这个文件传状态:
|
||||
|
||||
```markdown
|
||||
## Progress
|
||||
- [x] Added tests for auth module (iteration 1)
|
||||
- [x] Fixed edge case in token refresh (iteration 2)
|
||||
- [ ] Still need: rate limiting tests, error boundary tests
|
||||
|
||||
## Next Steps
|
||||
- Focus on rate limiting module next
|
||||
- The mock setup in tests/helpers.ts can be reused
|
||||
```
|
||||
|
||||
每次迭代开始 Claude 读它,结束 Claude 更新它。这就是用 filesystem 桥接独立 `claude -p` invocation 的关键技巧。
|
||||
|
||||
### CI 失败自动恢复
|
||||
|
||||
PR 检查失败时,continuous-claude 会:
|
||||
1. `gh run list` 查最近的失败 run id
|
||||
2. 起一个新的 `claude -p` 带 CI fix context
|
||||
3. Claude 用 `gh run view` 看日志、修代码、提交、push
|
||||
4. 重新等待检查(最多 `--ci-retry-max` 次,默认 1)
|
||||
|
||||
### Completion signal
|
||||
|
||||
```bash
|
||||
continuous-claude \
|
||||
--prompt "Fix all bugs in the issue tracker" \
|
||||
--completion-signal "CONTINUOUS_CLAUDE_PROJECT_COMPLETE" \
|
||||
--completion-threshold 3 # 连续 3 次发出信号才停
|
||||
```
|
||||
|
||||
### 全部 flags
|
||||
|
||||
| Flag | 用途 |
|
||||
|------|------|
|
||||
| `--max-runs N` | N 次迭代后停 |
|
||||
| `--max-cost $X` | 花 $X 后停 |
|
||||
| `--max-duration 2h` | 时间到后停 |
|
||||
| `--merge-strategy squash` | squash / merge / rebase |
|
||||
| `--worktree <name>` | git worktree 并行 |
|
||||
| `--disable-commits` | dry-run |
|
||||
| `--review-prompt "..."` | 加评审子步骤 |
|
||||
| `--ci-retry-max N` | CI 失败自动修次数 |
|
||||
|
||||
---
|
||||
|
||||
## 模式 4:Ralphinho RFC-DAG(最复杂、最严谨)
|
||||
|
||||
### 何时用
|
||||
|
||||
- 已经有一份 RFC / PRD
|
||||
- 多个**互相依赖**的工作单元
|
||||
- 不能容忍"实现者评审自己代码"的偏见
|
||||
- 多日大项目
|
||||
|
||||
### 真实工具(已验证)
|
||||
|
||||
- **GitHub:** github.com/enitrat/ralphinho
|
||||
- README 原话:*"Multi-agent AI development workflows — code review with improvinho, spec-driven implementation with ralphinho, and optional Linear integration for human-in-the-loop triage."*
|
||||
- 用 **Jujutsu (jj)** 而不是 git 做 worktree 隔离
|
||||
- ~93% TypeScript
|
||||
|
||||
### 真实命令(从 README)
|
||||
|
||||
```bash
|
||||
# 从 RFC 启动
|
||||
ralphinho init ./rfc.md
|
||||
|
||||
# 或纯评审模式(improvinho)
|
||||
ralphinho init review "review this auth module" --paths src/auth/
|
||||
|
||||
# 跑
|
||||
ralphinho run
|
||||
```
|
||||
|
||||
### 架构(skills/ralphinho-rfc-pipeline/SKILL.md + autonomous-loops/SKILL.md)
|
||||
|
||||
```text
|
||||
RFC/PRD Document
|
||||
│
|
||||
▼
|
||||
DECOMPOSITION (AI)
|
||||
把 RFC 拆成依赖 DAG 的 work units
|
||||
│
|
||||
▼
|
||||
RALPH LOOP (最多 3 轮)
|
||||
│
|
||||
▼
|
||||
对 DAG 每一层(按依赖顺序):
|
||||
│
|
||||
├── Quality Pipelines (每个 unit 并行,各自 worktree)
|
||||
│ research → plan → implement → test → review
|
||||
│ (深度按 tier 调整)
|
||||
│
|
||||
└── Merge Queue
|
||||
rebase → tests → land 或 evict
|
||||
被 evict 的 unit 带冲突 context 重新进队
|
||||
```
|
||||
|
||||
### 工作单元结构
|
||||
|
||||
```typescript
|
||||
interface WorkUnit {
|
||||
id: string; // kebab-case
|
||||
name: string;
|
||||
rfcSections: string[]; // 对应 RFC 哪些章节
|
||||
description: string;
|
||||
deps: string[]; // 依赖的其他 unit id
|
||||
acceptance: string[]; // 验收标准
|
||||
tier: "trivial" | "small" | "medium" | "large";
|
||||
}
|
||||
```
|
||||
|
||||
### 复杂度分层(关键)
|
||||
|
||||
| Tier | Pipeline 阶段 |
|
||||
|------|--------------|
|
||||
| trivial | implement → test |
|
||||
| small | implement → test → code-review |
|
||||
| medium | research → plan → implement → test → PRD-review + code-review → review-fix |
|
||||
| large | 加 final-review |
|
||||
|
||||
### 模型分配(每阶段独立 context)
|
||||
|
||||
| 阶段 | 模型 | 用途 |
|
||||
|------|------|------|
|
||||
| Research | Sonnet | 读代码 + RFC,产出 context doc |
|
||||
| Plan | Opus | 设计实现步骤 |
|
||||
| Implement | Codex | 写代码 |
|
||||
| Test | Sonnet | build + test |
|
||||
| PRD Review | Sonnet | 规范合规检查 |
|
||||
| Code Review | Opus | 质量 + 安全 |
|
||||
| Review Fix | Codex | 处理评审意见 |
|
||||
| Final Review | Opus | 大改才走 |
|
||||
|
||||
> 关键设计:**评审者从未写过它评审的代码**(消除作者偏见)。
|
||||
|
||||
### Merge queue eviction recovery
|
||||
|
||||
被 evict 时把完整冲突 context(冲突文件、diff、test 输出)喂回给 implementer 下一轮:
|
||||
|
||||
```markdown
|
||||
## MERGE CONFLICT — RESOLVE BEFORE NEXT LANDING
|
||||
|
||||
Your previous implementation conflicted with another unit that landed first.
|
||||
Restructure your changes to avoid the conflicting files/lines below.
|
||||
|
||||
{full eviction context with diffs}
|
||||
```
|
||||
|
||||
### 何时不用
|
||||
|
||||
| 信号 | 用 Ralphinho | 用更简单的 |
|
||||
|------|-------------|-----------|
|
||||
| 多个互相依赖的单元 | ✅ | ❌ |
|
||||
| 需要并行实现 | ✅ | ❌ |
|
||||
| 单文件改动 | ❌ | ✅(用模式 2) |
|
||||
| 多日 + 已有 RFC | ✅ | ❌ |
|
||||
| 一个东西的快速迭代 | ❌ | ✅(用 NanoClaw) |
|
||||
|
||||
---
|
||||
|
||||
## 模式 5:Santa Loop 双评审(对抗式收敛)
|
||||
|
||||
### 何时用
|
||||
|
||||
- 改完代码不想自欺欺人
|
||||
- 想要"两个独立模型都点头才上线"的硬门槛
|
||||
- 单一会话内可完成
|
||||
|
||||
### 真实命令(commands/santa-loop.md)
|
||||
|
||||
```bash
|
||||
# 评审当前未提交的改动
|
||||
/santa-loop
|
||||
|
||||
# 评审某个文件/glob
|
||||
/santa-loop src/auth/
|
||||
|
||||
# 评审某个范围描述
|
||||
/santa-loop "the new payment integration"
|
||||
```
|
||||
|
||||
### 工作流(命令文档原文)
|
||||
|
||||
1. **Identify scope** —— 默认 `git diff --name-only HEAD`
|
||||
2. **Build rubric** —— 至少包含 6 项:Correctness、Security、Error handling、Completeness、Internal consistency、No regressions。可加领域特定项(TS type safety、Rust memory safety、SQL migration safety)
|
||||
3. **Dual independent review (并行)**:
|
||||
- Reviewer A:**永远是 Claude Opus**(`code-reviewer` agent)
|
||||
- Reviewer B:按可用性顺序 codex CLI > gemini CLI > Claude Opus 兜底
|
||||
- 两个 reviewer 都看不到对方的输出
|
||||
- 都要返回结构化 JSON:
|
||||
```json
|
||||
{
|
||||
"verdict": "PASS" | "FAIL",
|
||||
"checks": [{"criterion": "...", "result": "PASS|FAIL", "detail": "..."}],
|
||||
"critical_issues": ["..."],
|
||||
"suggestions": ["..."]
|
||||
}
|
||||
```
|
||||
4. **Verdict gate**:
|
||||
- 都 PASS → NICE → push
|
||||
- 任一 FAIL → NAUGHTY → 进入 fix cycle
|
||||
5. **Fix cycle**(NAUGHTY 路径):
|
||||
- 修所有 critical issue,**只改被标记的,不顺手重构**
|
||||
- 单个 commit:`fix: address santa-loop review findings (round N)`
|
||||
- 起**新的** reviewer(没有上轮记忆)
|
||||
- 最多 3 轮,还是 NAUGHTY 就停下来让人介入
|
||||
|
||||
### 设计要点(命令文档原话)
|
||||
|
||||
> *"Reviewer A (Claude Opus) always runs — guarantees at least one strong reviewer regardless of tooling."*
|
||||
>
|
||||
> *"Model diversity is the goal for Reviewer B. GPT-5.4 or Gemini 2.5 Pro gives true independence — different training data, different biases, different blind spots."*
|
||||
>
|
||||
> *"External reviewers run with `--sandbox read-only` (Codex) to prevent repo mutation during review."*
|
||||
>
|
||||
> *"Fresh reviewers each round prevents anchoring bias from prior findings."*
|
||||
|
||||
### 输出格式
|
||||
|
||||
```text
|
||||
SANTA VERDICT: NICE / NAUGHTY (escalated)
|
||||
|
||||
Reviewer A (Claude Opus): [PASS/FAIL]
|
||||
Reviewer B ([model used]): [PASS/FAIL]
|
||||
|
||||
Agreement:
|
||||
Both flagged: [issues caught by both]
|
||||
Reviewer A only: [issues only A caught]
|
||||
Reviewer B only: [issues only B caught]
|
||||
|
||||
Iterations: [N]/3
|
||||
Result: [PUSHED / ESCALATED TO USER]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 模式 6:单 session 内 Task 并行(轻量内嵌)
|
||||
|
||||
### 何时用
|
||||
|
||||
- 不想配 tmux/worktree
|
||||
- 任务可以在一个 session 内做完
|
||||
- 几个独立子任务想并行
|
||||
|
||||
### 用法
|
||||
|
||||
直接在 Claude Code 主会话里让它"用 Task 工具并行起几个子 agent":
|
||||
|
||||
```
|
||||
请并行起 3 个子 agent:
|
||||
- agent 1: 读 src/api/ 找 SQL injection 风险
|
||||
- agent 2: 读 src/api/ 找性能瓶颈
|
||||
- agent 3: 读 src/api/ 找测试覆盖空洞
|
||||
所有 agent 都用 Read/Grep/Glob,不要写文件。最后合并报告。
|
||||
```
|
||||
|
||||
Claude Code 会用 `Task` 工具(就是 prompt 里能看到的 `Agent` tool)起 N 个 subagent,每个独立 context window,并行跑完后把结果传回主 session。
|
||||
|
||||
### 关键约束
|
||||
|
||||
- 每个子 agent 会回报一段 summary,主 agent 看不到子 agent 的中间过程
|
||||
- 子 agent 用 `CLAUDE_CODE_SUBAGENT_MODEL=haiku` 跑(便宜约 80%)—— 见 [[Everything Claude Code Token 优化]]
|
||||
- 5-6 个并行是上限,再多 token 烧得心疼
|
||||
|
||||
---
|
||||
|
||||
## 命令对照表(全部带状态标记)
|
||||
|
||||
| 命令 | 状态 | 真实做什么 |
|
||||
|------|------|----------|
|
||||
| `/orchestrate` | ⚠️ Legacy shim | 转发到 dmux-workflows + autonomous-agent-harness skill |
|
||||
| `/feature-dev` | ✅ 现役 | 单功能 7 阶段:Discovery → Codebase Exploration → Clarifying Questions → Architecture Design → Implementation → Quality Review → Summary |
|
||||
| `/multi-plan` | ⚠️ 需外部 CLI | `ccg:plan` 多模型协同规划,需要 codex/gemini CLI 和 `~/.claude/bin/codeagent-wrapper` |
|
||||
| `/multi-execute` | ⚠️ 需外部 CLI | 同上,执行阶段 |
|
||||
| `/multi-frontend` `/multi-backend` `/multi-workflow` | ⚠️ 需外部 CLI | multi-* 系列变体 |
|
||||
| `/loop-start` | ✅ 现役 | 启动 loop,模式 = sequential / continuous-pr / rfc-dag / infinite,模式 = safe(默认严格) / fast |
|
||||
| `/loop-status` | ✅ 现役 | 看当前 loop 状态,`--watch` 持续刷新 |
|
||||
| `/santa-loop` | ✅ 现役 | 双评审收敛(见模式 5) |
|
||||
| `/harness-audit` | ✅ 现役 | 跑 `node scripts/harness-audit.js`,7 类打分(各 0-10):Tool Coverage、Context Efficiency、Quality Gates、Memory Persistence、Eval Coverage、Security Guardrails、Cost Efficiency |
|
||||
| `/quality-gate` | ✅ 现役 | 质量管道(类 hook 行为) |
|
||||
| `/model-route` | ✅ 现役 | 推荐当前任务该用哪个模型 |
|
||||
| `/devfleet` | ⚠️ 需 MCP | 需要外部 Claude DevFleet 实例:`claude mcp add devfleet --transport http http://localhost:18801/mcp` |
|
||||
|
||||
---
|
||||
|
||||
## 实战搭配建议
|
||||
|
||||
### A. 单人,小项目,不想配 tmux
|
||||
|
||||
**主路:** 模式 2(Sequential `claude -p`)+ 模式 6(Task 内并行)+ 模式 5(`/santa-loop`)
|
||||
|
||||
```bash
|
||||
# 一个 shell 脚本搞定
|
||||
#!/bin/bash
|
||||
set -e
|
||||
claude -p "Plan the new feature based on docs/spec.md"
|
||||
claude -p "Implement based on the plan, TDD"
|
||||
claude -p "De-sloppify pass: remove test/code slop"
|
||||
# 进 Claude Code 交互模式跑 santa-loop
|
||||
echo "Now run: /santa-loop in interactive Claude Code"
|
||||
```
|
||||
|
||||
### B. 团队,多任务并行
|
||||
|
||||
**主路:** 模式 1(`scripts/orchestrate-worktrees.js`)+ 模式 5
|
||||
|
||||
```bash
|
||||
# plan.json
|
||||
{
|
||||
"sessionName": "sprint-23",
|
||||
"workers": [
|
||||
{"name": "feat-auth", "task": "Implement OAuth2 from .claude/specs/auth.md"},
|
||||
{"name": "feat-billing", "task": "Implement Stripe billing from .claude/specs/billing.md"},
|
||||
{"name": "feat-admin", "task": "Build admin panel from .claude/specs/admin.md"}
|
||||
]
|
||||
}
|
||||
|
||||
# 执行
|
||||
node scripts/orchestrate-worktrees.js plan.json --execute
|
||||
|
||||
# 监控
|
||||
node scripts/orchestration-status.js plan.json
|
||||
|
||||
# 每个 worker 完成后,合到主分支前
|
||||
/santa-loop feature/feat-auth..main
|
||||
```
|
||||
|
||||
### C. 多日大项目,有 RFC
|
||||
|
||||
**主路:** 模式 4(Ralphinho)
|
||||
|
||||
```bash
|
||||
# 把 RFC 写到 ./rfc.md
|
||||
ralphinho init ./rfc.md
|
||||
ralphinho run
|
||||
|
||||
# Linear 集成可选(human-in-the-loop triage)
|
||||
```
|
||||
|
||||
### D. 自治改 bug / 加测试
|
||||
|
||||
**主路:** 模式 3(continuous-claude)
|
||||
|
||||
```bash
|
||||
continuous-claude \
|
||||
--prompt "Improve test coverage to 90% across src/" \
|
||||
--max-runs 20 \
|
||||
--max-cost 50.00 \
|
||||
--completion-signal "COVERAGE_90_REACHED" \
|
||||
--review-prompt "npm test && npm run lint"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 反模式(全部从 SKILL.md 原文摘抄)
|
||||
|
||||
1. **无限循环没退出条件** —— 必须有 max-runs / max-cost / max-duration / completion signal。
|
||||
2. **迭代之间没有 context bridge** —— 用 `SHARED_TASK_NOTES.md` 或 filesystem state 桥接。
|
||||
3. **重试同一个失败** —— 把 error context 喂给下一次,不要盲目 retry。
|
||||
4. **用负面指令代替 cleanup pass** —— 别说 "don't do X",加一个去 X 的 pass。
|
||||
5. **所有 agent 在同一个 context window** —— 复杂工作流必须分到独立 process。**评审者绝对不能是作者**。
|
||||
6. **并行任务编辑同一文件** —— 必须有 merge 策略(顺序 land、rebase、冲突解决)。
|
||||
7. **盲目并行** —— 引自 Longform Guide:*"how much can you get done with the minimum viable amount of parallelization."*
|
||||
|
||||
---
|
||||
|
||||
## 配套真实工具栈
|
||||
|
||||
| 工具 | 链接 | 何时装 |
|
||||
|------|------|------|
|
||||
| **dmux** | github.com/standardagents/dmux | 想要 tmux 多 pane 多 agent |
|
||||
| **continuous-claude** | github.com/AnandChowdhary/continuous-claude | 想跑 PR 自治循环 |
|
||||
| **Ralphinho** | github.com/enitrat/ralphinho | 有 RFC,需要 DAG 编排 |
|
||||
| **codex CLI** | OpenAI Codex CLI | 用 `/santa-loop` 第二评审者、`/multi-*` 命令 |
|
||||
| **gemini CLI** | Google Gemini CLI | 同上 |
|
||||
| **jj (Jujutsu)** | github.com/martinvonz/jj | Ralphinho 的 worktree 后端 |
|
||||
|
||||
---
|
||||
|
||||
## 不可考的边界(诚实声明)
|
||||
|
||||
我搜了 X、Reddit、HN、Medium,**没有找到** `/orchestrate`、`/multi-plan`、`/multi-execute`、`/feature-dev`、`/loop-start` 在公开场合的实操截图或 thread。这些命令在仓库里**确实存在**(我读过 commands/*.md 文件),但社区没人晒出过运行时的 demo。
|
||||
|
||||
这意味着:
|
||||
- 上面这些命令的"真实命令行"我都是按 `commands/*.md` 文件里写的复述,不是观察到的实际行为
|
||||
- `/multi-plan` `/multi-execute` 实际依赖的 `~/.claude/bin/codeagent-wrapper` 不是 ECC 标配,需要自己装(看起来是从一个叫 `ccg`(codex-claude-gemini)的项目来的)
|
||||
- `/devfleet` 需要单独跑 Claude DevFleet HTTP 服务
|
||||
|
||||
**安全建议:** 优先用模式 1、2、3、5、6(全部都有真实可观测的工具支撑)。模式 4 也行,但配置成本高。`/multi-*` 系列等你看到 affaan 或社区有人晒 demo 再用。
|
||||
|
||||
---
|
||||
|
||||
## 来源
|
||||
|
||||
### 主要来源(直接读取的仓库文件)
|
||||
|
||||
- `commands/orchestrate.md`(legacy shim 声明)
|
||||
- `commands/feature-dev.md`(7 阶段定义)
|
||||
- `commands/multi-plan.md`、`multi-execute.md`(ccg 协议)
|
||||
- `commands/loop-start.md`、`loop-status.md`
|
||||
- `commands/santa-loop.md`(双评审完整流程)
|
||||
- `commands/harness-audit.md`(7 类打分)
|
||||
- `skills/dmux-workflows/SKILL.md`(5 个 pattern + plan.json 结构)
|
||||
- `skills/autonomous-loops/SKILL.md`(6 种 loop 模式 + 反模式)
|
||||
- `skills/ralphinho-rfc-pipeline/SKILL.md`(7 阶段 + tier 表)
|
||||
- `skills/autonomous-agent-harness/SKILL.md`(cron + memory + dispatch + computer use)
|
||||
- `skills/continuous-agent-loop/SKILL.md`(loop selection flow)
|
||||
- `skills/claude-devfleet/SKILL.md`(plan_project / dispatch_mission MCP 工具)
|
||||
- `agents/loop-operator.md`
|
||||
- `scripts/orchestrate-worktrees.js`(实测存在,2873 字节)
|
||||
- `scripts/orchestration-status.js`(实测存在,1604 字节)
|
||||
|
||||
### 二次来源(网上验证)
|
||||
|
||||
- The Longform Guide:https://github.com/affaan-m/everything-claude-code/blob/main/the-longform-guide.md
|
||||
- Affaan 公告:https://x.com/affaanmustafa/status/2014040193557471352(2026-01-21)
|
||||
- continuous-claude:https://github.com/AnandChowdhary/continuous-claude + https://anandchowdhary.com/blog/2025/running-claude-code-in-a-loop
|
||||
- Ralphinho:https://github.com/enitrat/ralphinho
|
||||
- dmux:https://github.com/standardagents/dmux
|
||||
- Medium 评述:https://medium.com/@tentenco/everything-claude-code-inside-the-82k-star-agent-harness-thats-dividing-the-developer-community-4fe54feccbc1
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
### Resources
|
||||
- [[Everything Claude Code 完整指南]]
|
||||
- [[Everything Claude Code 方法论与最佳实践]]
|
||||
- [[Everything Claude Code 用法速查]]
|
||||
- [[ECC 编排替代方案 (orchestrate 迁移)]]
|
||||
- [[Autonomous Agent Harness 自主代理框架]]
|
||||
- [[Autonomous Loops 自主循环模式]]
|
||||
- [[Ralphinho RFC-DAG 编排模式]]
|
||||
- [[dmux 多Agent并行编排]]
|
||||
- [[GSD 方法论与最佳实践]]
|
||||
|
||||
### Zettelkasten
|
||||
- [[Everything Claude Code Agent 编排模式]]
|
||||
- [[Everything Claude Code 多服务编排详解]]
|
||||
- [[Everything Claude Code 最佳实践]]
|
||||
- [[Everything Claude Code Token 优化]]
|
||||
- [[上下文腐烂与全新窗口隔离]]
|
||||
@@ -95,6 +95,44 @@ Legacy shim 仍然可用（向后兼容），只是内部转发到对应 skill
|
||||
|
||||
Rules 新增：java, kotlin, dart, csharp, cpp, rust, perl, php, web, zh (中文)
|
||||
|
||||
### Skill 放置策略 (新规范)
|
||||
|
||||
仓库新增 `docs/SKILL-PLACEMENT-POLICY.md`，明确 4 类 skill 的放置位置和归属：
|
||||
|
||||
| 类型 | 路径 | 提交仓库 | provenance |
|
||||
|------|------|---------|-----------|
|
||||
| **Curated**（人工策划） | `skills/` (repo) | ✅ | 用 frontmatter `origin` 字段 |
|
||||
| **Learned**（`/learn` 自动产出） | `~/.claude/skills/learned/` | ❌ | 必须 `.provenance.json` |
|
||||
| **Imported**（外部导入） | `~/.claude/skills/imported/` | ❌ | 必须 `.provenance.json` |
|
||||
| **Evolved**（instinct 聚类产出） | `~/.claude/homunculus/evolved/skills/` | ❌ | 继承自源 instinct |
|
||||
|
||||
`.provenance.json` 必填字段：`source`、`created_at`、`confidence` (0-1)、`author`。
|
||||
|
||||
**实操含义**：
|
||||
- `/learn` 学到的 skill 自动落到 `~/.claude/skills/learned/` —— 不要手动提交进 repo
|
||||
- `validate-skills.js` 只校验 `skills/` 下的 curated skill，忽略其他三类
|
||||
- 跨项目分享走 `/instinct-export` + `/instinct-import`，不直接 copy 文件
|
||||
|
||||
详见 [docs/SKILL-PLACEMENT-POLICY.md](https://github.com/affaan-m/everything-claude-code/blob/main/docs/SKILL-PLACEMENT-POLICY.md)。
|
||||
|
||||
### Token 优化新基线
|
||||
|
||||
仓库 `docs/token-optimization.md` 当前推荐配置：
|
||||
|
||||
```json
|
||||
{
|
||||
"model": "sonnet",
|
||||
"env": {
|
||||
"MAX_THINKING_TOKENS": "10000",
|
||||
"CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- **`CLAUDE_CODE_SUBAGENT_MODEL=haiku`** 是新的省钱大头，子 agent 跑 Haiku 比默认便宜约 80%
|
||||
- ⚠️ **`CLAUDE_AUTOCOMPACT_PCT_OVERRIDE` 已被官方警告弃用** —— 该变量在新版 Claude Code 上只能让压缩更早触发，与延后目的相反，移除即可
|
||||
- `memory` MCP 默认装但无 skill/agent/hook 引用 → 项目级 `disabledMcpServers` 关掉
|
||||
|
||||
---
|
||||
|
||||
## 精选 Skills（curated subset，非全量）
|
||||
@@ -302,6 +340,14 @@ Rules 新增：java, kotlin, dart, csharp, cpp, rust, perl, php, web, zh (中文
|
||||
### 循环/自动化
|
||||
`/loop-start` `/loop-status` `/model-route` `/quality-gate` `/harness-audit` `/promote` `/claw`
|
||||
|
||||
### 验证 & 会话
|
||||
`/checkpoint`(verification-loop 检查点)`/verify`(完整验证管道)`/sessions`(会话历史)`/security-scan`(AgentShield 扫描)
|
||||
|
||||
### REPL & 工具
|
||||
`/claw`(NanoClaw REPL，模型路由 + 技能热加载 + 会话分支)`/projects`(continuous-learning v2 项目管理)`/setup-pm`(包管理器配置)
|
||||
|
||||
> 完整命令 → agent 映射见仓库 [docs/COMMAND-AGENT-MAP.md](https://github.com/affaan-m/everything-claude-code/blob/main/docs/COMMAND-AGENT-MAP.md)。
|
||||
|
||||
---
|
||||
|
||||
## Hooks 系统
|
||||
@@ -339,7 +385,11 @@ ECC_DISABLED_HOOKS="pre:bash:tmux-reminder,post:edit:typecheck"
|
||||
### Resources
|
||||
- [[Everything Claude Code 方法论与最佳实践]]
|
||||
- [[Everything Claude Code 用法速查]]
|
||||
<<<<<<< HEAD
|
||||
- [[ECC 编排实战手册]] — 6 种编排模式真实命令 + 实战搭配 + 来源标注
|
||||
=======
|
||||
- [[ECC 编排替代方案 (orchestrate 迁移)]] ← **编排机制全景表**
|
||||
>>>>>>> origin/main
|
||||
- [[Autonomous Loops 自主循环模式]]
|
||||
- [[Autonomous Agent Harness 自主代理框架]]
|
||||
- [[dmux 多Agent并行编排]]
|
||||
|
||||
@@ -242,15 +242,7 @@ ECC 最独特的创新 — **本能学习系统**。
|
||||
# Feature development: start new feature (清除调试噪音)
|
||||
```
|
||||
|
||||
禁用自动压缩的配置:
|
||||
|
||||
```json
|
||||
{
|
||||
"env": {
|
||||
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50"
|
||||
}
|
||||
}
|
||||
```
|
||||
> ⚠️ **不要再设 `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE`**。仓库 `docs/token-optimization.md` 现已警告：该变量在新版 Claude Code 上只能"降低阈值"(让压缩**更早**触发)，与延后压缩的目的完全相反。完全靠手动 `/compact` + `strategic-compact` skill 控制压缩时机。
|
||||
|
||||
### 6. Verification Loop（验证循环）
|
||||
|
||||
@@ -316,13 +308,16 @@ ECC 最独特的创新 — **本能学习系统**。
|
||||
"model": "sonnet",
|
||||
"env": {
|
||||
"MAX_THINKING_TOKENS": "10000",
|
||||
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50"
|
||||
"CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
|
||||
}
|
||||
}
|
||||
// → ~60% 成本降低 (Sonnet vs Opus)
|
||||
// → ~70% thinking 成本降低
|
||||
// → ~80% 子 agent 成本降低 (Haiku 跑 Task 工具派发的子 agent)
|
||||
```
|
||||
|
||||
⚠️ **不要再设 `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE`** —— 仓库现已警告该变量在新版只会让压缩更早触发，改用手动 `/compact`。
|
||||
|
||||
**模型选择策略**:
|
||||
|
||||
| 模型 | 场景 | 能力/成本比 |
|
||||
@@ -336,7 +331,8 @@ ECC 最独特的创新 — **本能学习系统**。
|
||||
- 启用的 MCP <= 10 个，活跃工具总数 <= 80 个
|
||||
- 10+ MCP 时，有效上下文从 200K 降至 ~70K tokens
|
||||
- 用 `disabledMcpServers` 禁用不用的
|
||||
- 重操作优先用 CLI（如 `gh`）而不是 MCP
|
||||
- **默认安装的 `memory` MCP 没有任何 skill/agent/hook 引用 → 优先关掉**(仓库 `docs/token-optimization.md` 明确建议)
|
||||
- 重操作优先用 CLI（如 `gh`、`aws`）而不是 MCP wrapper
|
||||
- 使用 `llms.txt` 模式（如 `vercel.com/docs/llms.txt`）代替 MCP 获取文档
|
||||
|
||||
### 会话管理
|
||||
|
||||
@@ -7,7 +7,7 @@ source: "https://github.com/affaan-m/everything-claude-code"
|
||||
|
||||
# Everything Claude Code 用法速查
|
||||
|
||||
按使用场景分类的快速参考手册。组件完整列表见 [[Everything Claude Code 完整指南]]。方法论深度分析见 [[Everything Claude Code 方法论与最佳实践]]。
|
||||
按使用场景分类的快速参考手册。组件完整列表见 [[Everything Claude Code 完整指南]]。方法论深度分析见 [[Everything Claude Code 方法论与最佳实践]]。**编排深度实战见 [[ECC 编排实战手册]]**(6 种模式真实命令 + 决策树)。
|
||||
|
||||
> **命名空间**: 通过插件安装的 ECC，命令需加 `everything-claude-code:` 前缀。本文用短名书写，实际使用时如 `/plan` → `/everything-claude-code:plan`。完整映射表见 [[Everything Claude Code 方法论与最佳实践#命令名映射速查]]。
|
||||
|
||||
@@ -79,14 +79,32 @@ source: "https://github.com/affaan-m/everything-claude-code"
|
||||
|
||||
## 三、按高级场景分类
|
||||
|
||||
### 1. 多模型协作
|
||||
### 1. 编排模式选择(优先看)
|
||||
|
||||
详见 [[ECC 编排实战手册]]。决策树:
|
||||
|
||||
| 想要 | 用什么 | 备注 |
|
||||
|------|--------|------|
|
||||
| 单功能全流程 | `/feature-dev` | 7 阶段:Discovery → Exploration → Clarifying → Architecture → Implementation → Review → Summary |
|
||||
| 顺序分步 | `/plan` → `/tdd` → `/code-review` | 最朴素也最稳 |
|
||||
| 双评审兜底 | `/santa-loop` | Claude Opus + Codex/Gemini 双独立评审,3 轮收敛 |
|
||||
| 多 worktree 并行 | `node scripts/orchestrate-worktrees.js plan.json --execute` | 需 tmux,看 [[dmux 多Agent并行编排]] |
|
||||
| 多日 PR 自治 | `continuous-claude` 外部工具 | 不属于 ECC,看 [[Autonomous Loops 自主循环模式]] |
|
||||
| 大 RFC + DAG | `ralphinho` 外部工具 | 不属于 ECC |
|
||||
| 启动 ECC 内置循环 | `/loop-start [pattern] [--mode safe\|fast]` | pattern: sequential / continuous-pr / rfc-dag / infinite |
|
||||
|
||||
> ⚠️ `/orchestrate` 是 **legacy shim**,转发到 `dmux-workflows` skill。新项目优先用 `/feature-dev` 或上面的组合。
|
||||
|
||||
### 2. 多模型协作 (需外部 CLI)
|
||||
|
||||
⚠️ **`/multi-*` 系列依赖 `~/.claude/bin/codeagent-wrapper` + 外部 codex/gemini CLI**(`ccg` 协议),不是 ECC 标配。装不上就用编排手册里的模式 1-3、5、6 替代。
|
||||
|
||||
| 命令 | 用途 |
|
||||
| ----------------- | ----------------------------------- |
|
||||
| `/multi-plan` | Claude + Codex + Gemini 并行规划 |
|
||||
| `/multi-execute` | 跨多个模型后端并行执行 |
|
||||
| `/multi-frontend` | 多前端框架并行开发（React/Vue/Svelte/Angular） |
|
||||
| `/multi-backend` | 多后端栈并行开发（Node/Python/Go/Java） |
|
||||
| `/multi-frontend` | 多前端框架并行开发(React/Vue/Svelte/Angular) |
|
||||
| `/multi-backend` | 多后端栈并行开发(Node/Python/Go/Java) |
|
||||
| `/multi-workflow` | 复杂多服务编排 |
|
||||
|
||||
### 2. 自主循环
|
||||
@@ -163,10 +181,13 @@ source: "https://github.com/affaan-m/everything-claude-code"
|
||||
| 更新文档 | `/update-docs` |
|
||||
| 审查 Python 代码 | `/python-review` |
|
||||
| 审查 Go 代码 | `/go-review` |
|
||||
| 多模型并行出方案 | `/multi-plan` |
|
||||
| 多模型并行出方案 | `/multi-plan`(需外部 CLI) |
|
||||
| 启动自主循环 | `/loop-start` |
|
||||
| 评估 harness 质量 | `/harness-audit` |
|
||||
| 从会话中学习模式 | `/learn` |
|
||||
| 单功能全流程一条龙 | `/feature-dev` |
|
||||
| 上线前对抗式双评审 | `/santa-loop` |
|
||||
| 多任务 worktree 并行 | `node scripts/orchestrate-worktrees.js plan.json --execute` |
|
||||
|
||||
---
|
||||
|
||||
@@ -175,6 +196,11 @@ source: "https://github.com/affaan-m/everything-claude-code"
|
||||
### Resources
|
||||
- [[Everything Claude Code 完整指南]]
|
||||
- [[Everything Claude Code 方法论与最佳实践]]
|
||||
- [[ECC 编排实战手册]]
|
||||
- [[ECC 编排替代方案 (orchestrate 迁移)]]
|
||||
- [[Autonomous Loops 自主循环模式]]
|
||||
- [[dmux 多Agent并行编排]]
|
||||
- [[Ralphinho RFC-DAG 编排模式]]
|
||||
|
||||
### Zettelkasten
|
||||
- [[Everything Claude Code 最佳实践]]
|
||||
|
||||
@@ -20,9 +20,13 @@ source: "https://github.com/affaan-m/everything-claude-code"
|
||||
90% 任务用 Sonnet，只在架构决策和安全分析时用 Opus，搜索探索用 Haiku。设置：
|
||||
|
||||
```json
|
||||
{ "model": "sonnet", "env": { "MAX_THINKING_TOKENS": "10000", "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50" } }
|
||||
{ "model": "sonnet", "env": { "MAX_THINKING_TOKENS": "10000", "CLAUDE_CODE_SUBAGENT_MODEL": "haiku" } }
|
||||
```
|
||||
|
||||
`CLAUDE_CODE_SUBAGENT_MODEL=haiku` 是省钱新核心 —— 子 agent(通过 Task 工具派发的)跑 Haiku，比默认便宜约 80%，文件读取/探索质量基本无损。
|
||||
|
||||
> ⚠️ **不要再设 `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE`**。仓库 `docs/token-optimization.md` 已警告：该变量在新版 Claude Code 上只能"降低阈值"(让压缩更早触发)，与延后压缩的目的相反。改用手动 `/compact` + `strategic-compact` skill。
|
||||
|
||||
用 mgrep 替代 grep 可减少约 50% token 使用。
|
||||
|
||||
## 记忆持久化
|
||||
|
||||
@@ -12,9 +12,12 @@ source: "https://github.com/affaan-m/everything-claude-code"
|
||||
### 1. 模型路由
|
||||
90% 任务用 Sonnet，Haiku 做搜索/文档，Opus 只用于架构和安全。用 `/model-route` 自动路由。
|
||||
|
||||
**子 agent 强制用 Haiku** —— 设置 `CLAUDE_CODE_SUBAGENT_MODEL=haiku`，所有通过 Task 工具派发的子 agent 都跑 Haiku，比默认便宜约 80%，文件读取/探索质量基本无损。这是新版的省钱大头。
|
||||
|
||||
### 2. MCP 精简
|
||||
- 保持 < 10 个 MCP 启用
|
||||
- 用 CLI + skill 替代 MCP wrapper（如 gh CLI 替代 GitHub MCP）
|
||||
- 用 CLI + skill 替代 MCP wrapper（如 `gh` 替代 GitHub MCP、`aws` 替代 AWS MCP）
|
||||
- 默认安装的 `memory` MCP 没有任何 skill/agent/hook 引用 → 优先关掉
|
||||
- 每个 MCP 消耗上下文窗口，多到一定程度 200k 变 70k
|
||||
|
||||
### 3. 工具替换
|
||||
@@ -30,11 +33,13 @@ mgrep 替代 grep/ripgrep，在 50 任务 benchmark 中减少约 2x token 使用
|
||||
"model": "sonnet",
|
||||
"env": {
|
||||
"MAX_THINKING_TOKENS": "10000",
|
||||
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50"
|
||||
"CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> ⚠️ **不要再设 `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE`**。仓库 `docs/token-optimization.md` 已警告：该变量在新版 Claude Code 上只能"降低阈值"(让压缩更早触发)，与延后压缩的目的相反。改用手动 `/compact` + `strategic-compact` skill 控制压缩时机。
|
||||
|
||||
## Skill 的渐进式加载
|
||||
|
||||
Skill 启动时只读描述（约 100 tokens），只在相关时才加载完整内容。这比把所有内容放在 CLAUDE.md 系统提示中高效得多。
|
||||
|
||||
@@ -15,7 +15,8 @@ source: "https://github.com/affaan-m/everything-claude-code"
|
||||
**最佳实践**:
|
||||
- 活跃 MCP <= 10 个，活跃工具总数 <= 80 个
|
||||
- 用 `disabledMcpServers` 动态禁用不用的
|
||||
- 重操作优先用 CLI（如 `gh`）而不是 MCP
|
||||
- **默认安装的 `memory` MCP 没有任何 skill/agent/hook 引用 → 优先关掉**(仓库 `docs/token-optimization.md` 明确建议)
|
||||
- 重操作优先用 CLI（如 `gh`、`aws`）而不是 MCP wrapper
|
||||
- 使用 `llms.txt` 模式获取文档，避免 MCP 常驻开销
|
||||
|
||||
这是 Claude Code 性能优化中**最重要的单一因素** — 比任何 Agent 或 Skill 都重要。
|
||||
|
||||
31
6 - Zettelkasten/20260618073140 编排即排序门控与委派.md
Normal file
31
6 - Zettelkasten/20260618073140 编排即排序门控与委派.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
created: "2026-06-18 07:31"
|
||||
type: zettel
|
||||
tags: [zettel, claude-code, orchestration, agent-orchestration, design-principle]
|
||||
source: "https://github.com/affaan-m/ECC"
|
||||
---
|
||||
|
||||
# 编排即排序门控与委派
|
||||
|
||||
好的 agent 编排不靠"更聪明的 AI",而是三件事的组合:**排序 + 门控 + 委派**。
|
||||
|
||||
ECC 的 `orch-pipeline` 是最干净的例证:它**不重新实现任何东西**。它的全部价值在于把现成 agent(planner、tdd-guide、code-reviewer…)按 Research→Plan→Implement→Review→Commit **排好序**,在两个关键点**设人类门**(Plan 后批准 task_list、Commit 前确认 diff),然后把每一步**委派**出去。包装层(`orch-add-feature` 等 5 个)只负责分类意图和选阶段。
|
||||
|
||||
配套的关键原则:**仪式随爆炸半径缩放(ceremony scales to blast radius)**。改一行的 trivial 改动直接 `Implement→Review→Commit`,跳过 Research/Plan;横切、引入新依赖或动公开 API 的 large 改动才上全套 + 安全审查。把全套流程套在小改动上,和让大改动裸奔,是同一种错误的两面。
|
||||
|
||||
> 推论:当你想"造一个更强的编排器"时,先问——我是不是只需要把已有的步骤**排好序、设好门、委派对人**?新增的往往应该是 sequencing 和 gate,而不是新实现。
|
||||
|
||||
这条原则在 ECC 各处复现:Ralphinho 的 tier 分层(trivial 只 implement→test,large 才加 final-review)、`parallel-execution-optimizer`(只在写面不冲突处并行)、Santa Loop(评审者≠作者的强制隔离)。
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [[ECC orch- 编排家族与 v2.0 团队编排]]
|
||||
- [[Everything Claude Code Agent 编排模式]]
|
||||
- [[Ralphinho RFC-DAG 编排模式]]
|
||||
- [[上下文腐烂与全新窗口隔离]]
|
||||
|
||||
## Source
|
||||
|
||||
- `skills/orch-pipeline/SKILL.md`(ECC v2.0)— "The orch-* skills are thin wrappers. They do not re-implement any work." / "Ceremony scales to blast radius."
|
||||
1
Untitled.canvas
Normal file
1
Untitled.canvas
Normal file
@@ -0,0 +1 @@
|
||||
{}
|
||||
17
conflict-files-obsidian-git.md
Normal file
17
conflict-files-obsidian-git.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# Conflicts
|
||||
Please resolve them and commit them using the commands `Git: Commit all changes` followed by `Git: Push`
|
||||
(This file will automatically be deleted before commit)
|
||||
[[#Additional Instructions]] available below file list
|
||||
|
||||
- [[Everything Claude Code 完整指南]]
|
||||
|
||||
# Additional Instructions
|
||||
I strongly recommend to use "Source mode" for viewing the conflicted files. For simple conflicts, in each file listed above replace every occurrence of the following text blocks with the desired text.
|
||||
|
||||
```diff
|
||||
<<<<<<< HEAD
|
||||
File changes in local repository
|
||||
=======
|
||||
File changes in remote repository
|
||||
>>>>>>> origin/main
|
||||
```
|
||||
Reference in New Issue
Block a user