# 为什么需要 ys-team

## AI 写代码的问题变了

现在的 coding agent 已经会自己循环：读代码、计划、修改、跑命令、再修。

真正的问题不是“怎么让它动起来”，而是“它什么时候该停”。如果退出条件不保真，agent 只会更快地把错误代码迭代到看起来很自信。

常见失败：

- UI 交互坏了，但单测和编译都绿
- API 行为变了，但只测了纯函数
- 发布链路漏一步，代码本身却没报错
- 文档模板改了，两个 baseline 副本不同步

## ys-team v1 的解法

把工程重量放到 verifier，而不是流程仪式。

5 个概念：

1. **规则**：AI 的行为边界
2. **约束地图**：项目硬约束和风险
3. **术语表**：避免领域语言漂移
4. **错题本**：跨任务复用的失败模式
5. **verifier 卡**：复杂改动的执行与验收合约

v1 不再排他，不靠强制尾标判断工作是否有效。真正的判断是：

- 入口有没有合格 verifier 卡
- 出口 verifier 有没有真绿
- 用户能不能看见当前结果状态

## 反模式案例

### 案例 1：假绿

**用户请求**：修复任务列表粘贴 Markdown 后不能保存的问题。

**没有 verifier 时**：agent 跑了单测和 build，全绿。用户真实粘贴 `- [ ] 任务` 后仍然失败。

**ys-team v1 行为**：UI/交互类低于 L2 默认不通过。verifier 卡要求真实粘贴或行为测试，并断言刷新后仍存在。

### 案例 2：范围膨胀

**用户请求**：优化首页加载速度。

**没有边界时**：agent 从图片懒加载改到缓存层，又引入 Redis 和数据库索引。

**ys-team v1 行为**：Write-Scope 是入口闸的一部分。发现要改 scope 外文件时停止，回到讨论或请求确认。

### 案例 3：用户被迫选流程

**用户请求**：把登录流程做得更可靠。

**旧式流程负担**：agent 反问要不要开某个流程、要不要 TDD、要不要审阅。

**ys-team v1 行为**：用户只描述目标。agent 内部判断不可逆性和不确定性，需要时 grill 并起 verifier 卡。

### 案例 4：人工抽检被包装成自动通过

**用户请求**：调整一个复杂视觉状态。

**不诚实时**：agent 说测试通过，但其实只是看了一眼截图。

**ys-team v1 行为**：诚实标 L0，写清人工抽检步骤、剩余风险和为什么不能自动化。

## 两个真决策点

1. **签 verifier 卡**：验收标准是否足够像真人会做的检查？
2. **抽检证据**：验证是否真绿？如果不是 L3/L2，剩余人工项是否清楚？

减少人的复查成本，不是让人完全不看，而是让人只看真正影响质量的两个点。

## 适合谁

- 个人开发者用 AI coding agent 写代码
- 小团队希望 AI 改动有边界、有证据
- 希望把项目本地 SOP 低成本沉淀到仓库里的团队

对已有成熟工程治理的大团队，ys-team 更适合作为 AI 协作层补充。