mirror of
https://github.com/tradecatlabs/vibe-coding-cn.git
synced 2026-08-02 21:57:44 +00:00
tukuaiai
193 lines
9.2 KiB
Markdown
193 lines
9.2 KiB
Markdown
<a id="目录定位"></a>
|
||
|
||
# 研究
|
||
|
||
## 字多不看
|
||
|
||
- 本目录是“观察与判断区”。
|
||
- 新技术、新技术栈、优秀 repo 和工程范式，先放这里研究。
|
||
- 内容稳定后，再沉淀到 `concepts/` 或 `references/`。
|
||
- 每篇研究笔记先回答：是什么、解决什么问题、是否值得采用、风险在哪里。
|
||
|
||
## 快速导航
|
||
|
||
1. [Harness 工程解析](#research-harness-engineering) - 工程控制、评估器、反馈闭环与 AI 生成系统可靠性。
|
||
2. [tmux 蜂群协作](#research-tmux-ai-swarm) - 用 tmux 让多个 AI 终端可感知、可调度、可救援的实验性协作范式。
|
||
|
||
<details>
|
||
<summary><strong>完整细粒度目录（点击展开/收起）</strong></summary>
|
||
|
||
### 细粒度目录
|
||
|
||
- [1. Harness 工程解析](#research-harness-engineering)
|
||
- [2. tmux 蜂群协作](#research-tmux-ai-swarm)
|
||
|
||
</details>
|
||
|
||
## 使用方式
|
||
|
||
- 用这里记录还在观察期的新技术、repo、工具趋势和工程范式。
|
||
- 如果内容已经成为稳定概念，迁入 `concepts/`。
|
||
- 如果内容已经变成可执行清单、模板或选型依据，迁入 `references/`。
|
||
|
||
## 正文
|
||
|
||
---
|
||
|
||
<details>
|
||
<summary><strong>1. Harness 工程解析</strong> - 工程控制、评估器、反馈闭环与 AI 生成系统可靠性。（点击展开/收起）</summary>
|
||
|
||
<a id="research-harness-engineering"></a>
|
||
|
||
## 1. Harness 工程解析
|
||
|
||
> 工程控制、评估器、反馈闭环与 AI 生成系统可靠性。
|
||
|
||
1. Harness Engineering 的本质是用确定性的工程控制系统，把大模型的非确定性输出压缩进可预测的轨道里，让“概率生成”变成“可验收的产出”
|
||
|
||
2. 大模型在系统里只承担两件事：理解意图、把意图翻译成文本（代码/配置/文档），它更像算力与语言编译器，而不是可靠性来源
|
||
|
||
3. 可靠性不来自“更聪明的模型”，而来自外部机制对输出的四类动作：拦截意图、校验结果、拒绝不合格、注入必要上下文
|
||
|
||
4. 最小可运行 Harness 的关键不是生成代码，而是闭环：生成→编译/运行→抓取错误→反馈重写→直到通过，这把一次性聊天改造成可迭代的生产流程
|
||
|
||
5. 第一类硬问题是上下文与遗忘：任务一复杂就会撑爆上下文、目标漂移、前后端混写，本质是模型没有稳定的工作记忆与任务边界
|
||
|
||
6. 对应解法是动态上下文注入与记忆管理：把规则与知识拆成可插拔技能包，按“当前意图”精准装载与卸载，让上下文保持短、准、相关
|
||
|
||
7. 记忆的工程化含义不是“多存点东西”，而是把踩坑与验证过的结论自动提炼成规则沉淀下来，使系统具备跨任务的抗重复犯错能力
|
||
|
||
8. 第二类硬问题是自评幻觉：让模型自己审查等于既当运动员又当裁判，它会用讨好与自洽掩盖逻辑错误，漂亮但不可用
|
||
|
||
9. 对应解法是评估驱动与机械测试：引入独立的、可执行的第三方判定（编译器、单测、端到端 UI 测试、独立 QA Agent），用硬指标决定通过与否
|
||
|
||
10. 质量下限从“模型聪明程度”迁移到“验收机制完备性”，系统真正的生产力来自可重复运行的判定器，而不是一次灵感式输出
|
||
|
||
11. 第三类硬问题是时间维度的熵增：长期运行后模型会为了更快过测试而走捷径，架构漂移、耦合蔓延，最终形成不可维护的腐化代码库
|
||
|
||
12. 对应解法是架构强约束与持续清理：用静态规则提前阻断跨层依赖等结构性违规，再用专职清理机制持续重构、更新文档、回收技术债，对抗代码腐化
|
||
|
||
13. 当系统拥有规划者、执行者、评估者、硬约束钩子、清理机制时，Harness 才从脚本升级为“Agent 操作系统”，长期稳定性来自分工与制衡
|
||
|
||
14. 那些看似“AI 自己写出百万行代码”的魔法，核心不在模型，而在工具与 Harness 组合出来的现实校验、反馈重试、规则约束与持续治理
|
||
|
||
15. Harness 不是回到古法逐行写代码，而是把工程重心从实现细节迁移到边界、接口、约束、断言与验收标准，编码对象从业务逻辑变成生产流水线
|
||
|
||
16. Harness 的门槛高于写业务代码的根因在于：它要求你先把“什么算对、什么算好、什么必须禁止”形式化成可执行规则，否则系统会高速产出结构化垃圾
|
||
|
||
17. Harness 的维护成本来自业务变化：当目标函数变了，你必须同步重写评估器与测试桩，否则闭环会失真并进入死锁或错误优化
|
||
|
||
18. 最大误解之一是指望模型升级解决跑偏，现实规律是无论马多强，没有缰绳都会把车拉进沟里，可靠性必须由外部约束提供
|
||
|
||
19. 最大误解之二是工具越多越好，工具过载会导致选择震荡与时间浪费，工具集应该为评估与执行最小充分，而非堆权限展示强大
|
||
|
||
20. 最大误解之三是把无约束的氛围式开发当工业未来，它只能在无历史负担的小项目里成立，一旦进入长周期协作与演进，没有硬边界就必然灾难
|
||
|
||
21. Harness 的上限由评估器决定：如果你无法把“好结果”编码为可检验的规则与测试，系统就无法稳定优化，模型也无法替你完成这层战略定义
|
||
|
||
22. 未来工程师的分化本质是控制权分配：一类在代码生成速度上竞争，另一类在规则、评估、架构与闭环设计上竞争，后者决定系统长期生产力与可维护性
|
||
|
||
</details>
|
||
|
||
---
|
||
|
||
<details>
|
||
<summary><strong>2. tmux 蜂群协作</strong> - 用 tmux 让多个 AI 终端可感知、可调度、可救援的实验性协作范式。（点击展开/收起）</summary>
|
||
|
||
<a id="research-tmux-ai-swarm"></a>
|
||
|
||
## 2. tmux 蜂群协作
|
||
|
||
> 用 tmux 让多个 AI 终端可感知、可调度、可救援的实验性协作范式。
|
||
|
||
### 是什么
|
||
|
||
tmux 蜂群协作是把多个 AI CLI 会话放进同一个 tmux 工作台，通过 `capture-pane` 读取输出、`send-keys` 发送按键、共享状态文件同步进度，再用脚本封装形成 commander + worker 的多终端协作系统。
|
||
|
||
在当前仓库中，它不再以旧的 `playbooks/` 目录存在，而是收敛到 `skills/auto-tmux/`：
|
||
|
||
- 可执行入口：[auto-tmux skill](../../skills/auto-tmux/SKILL.md)
|
||
- 脚本入口：[auto-tmux.sh](../../skills/auto-tmux/scripts/auto-tmux.sh)
|
||
- 完整文档：[AI 蜂群协作](../../skills/auto-tmux/references/ai-swarm-collaboration.md)
|
||
|
||
### 解决什么问题
|
||
|
||
1. 多个 AI 会话互相不可见，导致重复工作、信息断裂和人工来回搬运。
|
||
2. AI CLI 卡在确认、报错或长任务等待时，需要人工不断盯屏。
|
||
3. 多任务并行时缺少统一巡检、分工、日志和验收证据。
|
||
4. 多终端协作缺少安全边界，容易误发命令或控制错误窗口。
|
||
|
||
### 当前判断
|
||
|
||
这是一种值得保留的实验性方法，但必须脚本化、目标化和门禁化。
|
||
|
||
推荐路线不是让 AI 直接随意执行 `tmux send-keys`，而是先使用 `skills/auto-tmux/scripts/auto-tmux.sh` 封装：
|
||
|
||
```bash
|
||
skills/auto-tmux/scripts/auto-tmux.sh hub --session ai-hub --workers 3 --cmd "codex"
|
||
skills/auto-tmux/scripts/auto-tmux.sh topology --session ai-hub
|
||
skills/auto-tmux/scripts/auto-tmux.sh scan --session ai-hub -n 80
|
||
```
|
||
|
||
这个封装层能做到：
|
||
|
||
- 先确认 target 存在。
|
||
- 默认对输出脱敏。
|
||
- 发送前打印目标上下文。
|
||
- 危险命令默认拒绝。
|
||
- 巡检、救援和录制都可重复执行。
|
||
|
||
### 适用场景
|
||
|
||
- 多个 AI CLI 并行处理互不冲突的子任务。
|
||
- commander 统一分配任务、巡检 worker、收集证据。
|
||
- 需要观察长时间运行的安装、测试、构建或调试任务。
|
||
- 需要把卡住的低风险确认交给脚本化救援。
|
||
- 需要保留 pane 日志，用于复盘、审计和验收。
|
||
|
||
### 不适用场景
|
||
|
||
- 涉及生产数据库、云资源删除、密钥输入和敏感凭证展示。
|
||
- 需要图形界面、复杂交互或强实时反馈的操作。
|
||
- 无法接受误输入、误中断或误控制的任务。
|
||
- 没有明确任务边界、锁、日志和验收标准的多 Agent 并发。
|
||
|
||
### 采用建议
|
||
|
||
最小可用结构：
|
||
|
||
```text
|
||
ai-hub
|
||
├── commander
|
||
├── worker1
|
||
├── worker2
|
||
└── worker3
|
||
```
|
||
|
||
推荐协议：
|
||
|
||
1. commander 负责拆任务、巡检、救援和最终验收。
|
||
2. worker 一次只处理一个明确子任务。
|
||
3. 所有发送动作必须使用完整 `<session>:<window>.<pane>` target。
|
||
4. 救援先 dry-run，再真实执行。
|
||
5. 长任务必须 record，完成后汇报命令、diff、测试和风险。
|
||
|
||
### 风险
|
||
|
||
| 风险 | 说明 | 约束 |
|
||
|:---|:---|:---|
|
||
| 误控 pane | target 错误会向错误窗口发命令 | 先 `topology`，再 `capture` |
|
||
| 死循环 | 多个 AI 互相救援或互相触发 | 设置 commander 单点调度 |
|
||
| 文件冲突 | 多 worker 改同一文件 | 子任务分工和锁机制 |
|
||
| 信息泄露 | capture 读到 token 或密码 | 默认脱敏，隔离敏感会话 |
|
||
| 幻觉放大 | 多 AI 同时错误执行 | 以测试、diff、日志和人工验收兜底 |
|
||
|
||
### 后续观察点
|
||
|
||
- 是否需要把 `/tmp/ai_swarm/tasks.json` 标准化为 schema。
|
||
- 是否需要增加 worker 状态机和锁文件脚本。
|
||
- 是否需要接入 GitHub Actions、Prometheus 或本地 Web 面板。
|
||
- 是否需要把 commander / worker prompt 模板独立成可复用 prompt。
|
||
|
||
</details>
|