Zane/obsidian-notes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

同步最新文档

Browse Source
This commit is contained in:
Zane
2026-06-01 20:58:30 +08:00
parent 383b678599
commit 6c6929615a
6 changed files with 529 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files

352
3Resources/AI/2026-04-25 Harness for AI coding 团队级 AI 编程驾驭工程_BV1SZoXBkErT_笔记.md Normal file
View File

@@ -0,0 +1,352 @@
# 敏捷团队 AI 编程驾驭工程体系
## 一、背景与核心问题
### 1.1 为什么需要团队级 AI 编程体系
当前 AI 编程工具（如 SuperPowe、Claude Code、Cursor 等）已经非常强大，但**在团队级、项目级场景下落地困难**。核心原因是：
- **需求衔接问题**：产品经理/BA 给的需求格式不统一，颗粒度不一致，导致 AI 无法有效理解
- **开发实践问题**：多人协作时，AI 生成的代码风格不统一、难以形成一致的整体
- **工具生态混乱**：Claude Code、Cursor、windsurf、SuperPower 等工具差异大，没有统一标准
- **流程与制度问题**：团队工作习惯难以改变，这是最大的阻力来源
### 1.2 当前团队使用 AI 编程的认知分级
根据开发者能力分层：
| 级别 | 描述 | 典型行为 |
|------|------|----------|
| 初级开发者 | 照猫画虎，不知道系统如何工作 | 抄代码、写业务逻辑，被 AI 替代 |
| 专家型开发者 | 做技术公关，复杂组件开发 | 仍需要，但 AI 可辅助 |
| 架构型开发者 | 设计服务、做权衡决策 | AI 辅助设计，但要人工把关 |
| 技术经理/CTO | 处理复杂混乱的问题 | 构建团队 AI 工作体系 |
> **关键洞察**："这个玩具不是玩 AI，是玩人"——真正的挑战不在于 AI 能力，而在于如何让团队按照统一的方式工作。
### 1.3 AI 辅助软件工程全流程图
```
需求分析 → 技术方案设计 → 代码编写 → Code Review → 测试 → 部署 → 生产 Bug 修复
↓ ↓ ↓ ↓ ↓ ↓ ↓
录音转文档 打样工程 API/单元测试 交叉模型 E2E测试 K8S部署 MCP自动
访谈纪要 代码模板 TDD 循环 Review Playwright 触发合并 发通知
需求文档 技术规范
原型链接
```
## 二、需求阶段：如何让需求 AI 友好
### 2.1 需求规格模板必须包含的内容
BA 或产品经理给的需求文档必须包含以下 4 个关键部分：
1. **业务背景**：为什么做这个需求
2. **字段清单**：所有业务字段的类型、默认值、业务规则（避免只给原型图让 AI 去猜）
3. **原型链接**：Figma 图等设计稿的链接（AI 可通过 MCP 读取 Figma）
4. **业务规则**：按条拆分，例如：
- 订单号生成规则
- 发货规则
- 状态转换规则
### 2.2 需求颗粒度的判断标准
**不要用 Story 拆分需求**（一个人增产改查拆成 4 个 story 对 AI 来说信息量不够）。
正确做法：**一个模块一个文档**，判断颗粒度的标准是：
- 是否有独立的表结构
- 是否可以单独上线
### 2.3 新建需求 vs 变更需求
**新建需求**：告诉 AI 有多少表、多少页面、多少功能操作 → AI 生成完整模块
**变更需求**（重要）：
- 必须用标签标注变更类型：`[+字段]` `[-字段]` `[修改字段]`
- 不要把最终完整状态给 AI，因为 AI 需要对比现有代码 → 浪费大量 Token 且效果差
- 示例：
```markdown
# 订单模块变更需求
## 新增内容 [+]
- 新增字段：order_type（订单类型，枚举值：NORMAL, VIP, B2B）
## 修改内容 [~]
- 修改字段：shipping_address 最大长度从 200 改为 500
## 删除内容 [-]
- 删除字段：legacy_flag（已废弃）
```
### 2.4 用 Obsidian 搭建知识库给 AI 做上下文
将所有需求规格、技术规格都放到知识库中，用 Obsidian + Markdown 管理：
- 用浏览器插件一键将网页转成 Markdown 并保存图片本地
- 用 backlink 功能做上下文关联
- AI 通过读取这个知识库获得长期记忆 → "Single source of truth"
## 三、技术规格阶段：技术方案设计
### 3.1 技术规格必须包含的内容
技术规格是开发的核心输入，必须包含以下 5 个部分：
| 内容 | 工具/格式 | 说明 |
|------|----------|------|
| 领域模型 | PlantUML / Mermaid | 代码化表达，便于 AI 理解 |
| 数据库设计 | DBML / Flyway 脚本 | 不要让 AI 直接操作数据库，用版本化的 Flyway 脚本 |
| API 定义 | OpenAPI / Markdown | 后端写完 API 后输出 API 文档给前端 |
| 时序图 | Mermaid | 复杂流程需要时序图 |
| 专项设计 | Markdown | 权限、事务、缓存等专项内容 |
> **重要教训**：不要给 AI 写数据库的写权限，曾经因为 AI 动不动修改数据库导致多人操作冲突。把写权限关掉，让 AI 生成 Flyway 脚本，本地测试时让 Flyway 跑。
### 3.2 DSL 驱动的技术规格
用领域特定语言（DSL）来驱动技术规格：
- 领域模型用 PlantUML
- 数据库用 DBML
- API 用 OpenAPI
- 这些 DSL 都可以通过代码生成 → 保证前后端一致性
> 这实际上就是模型驱动架构（Model-Driven Architecture），当团队从零开始全新的 AI 项目时，这种严格的检查和约束更容易建立。
## 四、打样工程：AI 友好的代码框架
### 4.1 什么是打样工程
打样工程（Seed Project）是一个预先定义好的代码框架模板，包含：
- 每层的类名和职责定义
- 代码规范和最佳实践
- 依赖配置和目录结构
### 4.2 打样工程的作用
1. **AI 生成代码风格一致**：所有 AI 都基于同一个框架生成代码
2. **减少重复代码**：AI 会复用框架中的组件而不是重复写
3. **降低认知负担**：AI 不需要每次理解项目结构
### 4.3 如何创建打样工程
1. 从旧项目中蒸馏出一个干净的新项目骨架
2. 定义每层职责：`Controller → Service → Repository → Entity`
3. 定义类命名规范和包结构
4. 放入 Git 仓库供团队共享
## 五、开发阶段：让 AI 听话写出统一风格的代码
### 5.1 用 RAG（检索增强生成）提供上下文
将技术规格、代码规范、历史决策等信息放到代码仓库的 `/docs` 或 `/book` 目录下，AI 通过检索这些文档获得上下文：
```markdown
/my-project
/book
/requirements # 需求规格
/specifications # 技术规格
/api-docs # API 文档
/src
/skills
/mcp
```
### 5.2 多任务同步开发：Worktree 的使用
Git Worktree 可以把分支映射成目录，实现多任务并行：
```bash
# 创建多个工作目录
git worktree add ../feature-order feature/order
git worktree add ../feature-user feature/user
# 在不同目录下同时工作，做完后合并
```
**但要注意**：
- 多人同时操作多人工作时，版本管理会比较痛苦
- 建议提前把规格设计好，让 AI 慢慢跑，而不是同时开太多任务
### 5.3 不要让 AI 边写代码边做设计
用 `rapper5` 的思路：**Discovery/Design 和 Coding 分两个阶段**。
- 先做探索性设计，让不同 AI 模型（GPT、Claude、Gemini）各自给出方案
- 选定方案后，再激活 Coding 角色专职写代码
- 切换角色时重置上下文，避免 AI 注意力分散
## 六、测试阶段：AI 写代码形成闭环的核心
### 6.1 为什么测试是 AI 编程的命脉
> "没有 API 测试和单元测试，无法形成 AI 写代码的闭环。"
AI 生成代码后必须能**自我验证**，否则：
- 人工验证效率极低
- AI 无法发现自己的问题
- 团队无法真正提效
### 6.2 测试策略（3 层）
| 测试类型 | 工具 | 驱动方式 |
|----------|------|----------|
| 单元测试 | JUnit / pytest | TDD：先写测试让 AI 失败，再写实现 |
| API 测试 | REST Assured / Newman | 自动化回归，可直接卡 90%+ 覆盖率 |
| E2E 测试 | Playwright（推荐，替代了 Selenium） | 上线前 80% 的 case 回归覆盖 |
### 6.3 TDD 循环（SuperPower 的工作方式）
1. 让 AI 先写 API 测试/单元测试
2. AI 运行测试 → 失败
3. AI 再写实现代码
4. AI 自动运行测试验证 → 通过
> **效果**：单元测试可达 100% 覆盖率，API 测试可达 90%+ 覆盖率。
### 6.4 AI 写测试解决假阳性问题
有时候 AI 为了让测试通过，会伪造测试逻辑。解决方案：
- **TDD 先写测试**：先让测试失败，再让 AI 写实现
- **交叉验证**：用不同的 AI 模型互相 review 代码和测试
### 6.5 测试用例的管理
测试用例直接放到代码仓库中：
- 单元测试：跟随代码模块
- API 测试：放在 `/test/api` 目录
- E2E 测试：用 TypeScript + Playwright，放在代码仓库根目录（或与前端项目同仓库）
## 七、Review 阶段：AI 辅助 Code Review
### 7.1 多种 Review 方式
1. **工具扫描**：SonarQube 等静态分析工具 + AI 自动修复
2. **AI Review**：用另一个 AI 模型做交叉 review（换模型做 review 是常用技巧）
3. **Agent 自动触发**：在 PR 阶段自动触发 Review Agent
### 7.2 AI Review 的问题与解决方案
**问题**：AI Review 总是会提改进建议，哪怕没有明显问题（因为你的 prompt 让它提问题）。
**解决方案**：
- 设置阈值：达到一定级别才提问题，否则不输出
- 让 AI 只关注 bug 和逻辑错误，不过度关注风格问题
- 用团队的架构规约来约束 Review 标准
### 7.3 不同场景的 Review 策略
- **全新项目（AI 100% 生成）**：可以用最严格的规则，AI 写完直接修
- **混合项目（人 + AI）**：可能存在历史遗留问题，Review 结果噪音多，建议从新模块开始逐步规范
- **跨系统场景**：AI 容易犯错（尤其涉及 3-5 个系统的交互），建议收敛到单个仓库处理
> **经验**：跨系统时 AI 犯错误概率高达 70-80%，核心原因是缺少完整的系统间关系和业务规则上下文。
## 八、工具链：AI 编程工具全景
### 8.1 三类 AI 编程工具
| 类型 | 代表工具 | 特点 |
|------|----------|------|
| 命令行 CLI | Claude Code, OpenAI Codex | 适合快速操作、脚本化 |
| IDE 集成 | Cursor, Windsurf, VS Code AI | 适合日常开发，界面友好 |
| 辅助插件 | SuperPower（推荐个人）, Copilot | 按需使用 |
### 8.2 常用 MCP（Model Context Protocol）
| MCP | 用途 |
|-----|------|
| 数据库 MCP | 操作数据库（注意：只读，写权限建议关闭） |
| Figma MCP | 读取设计稿 |
| Jira MCP | 管理工单 |
| Git MCP | 代码提交、PR 操作 |
### 8.3 Skills 体系
Skills = 一段提示词 + 模板 + 脚本，用于描述工作方法。
- 把打样工程的初始化做成 Skill
- 把团队规范做成 Skills
- Skills 放到代码仓库中共享
**重要观点**：
> "现在 AI 理解力已经很强大，不需要把规范落实为非常固定的格式，只要表达清楚信息、强调重点即可。"
**主流 Skill 框架**：
- SuperPower：内置大量 Skills，开箱即用，适合个人
- Claude Agent（hermes）：自动基于对话生成和优化 Skills
- MCP：工具调用协议
### 8.4 为什么不推荐 SDD 框架
SDD（Scenario-Driven Development）框架本身很好，但**落地难度在于团队共识**：
- 需要团队所有人按照相同流程工作
- 现实团队中阻力很大（不是不愿意用，是习惯改不了）
- SuperPower 对个人很好用，但团队级很难推广
> **结论**：与其强推 SDD 框架，不如团队自己定义一套 Roos + Skills + MCP 的组合。
## 九、架构型思考：未来趋势
### 9.1 Agent Code 的趋势
未来必然会出现 "Agent Code" 的概念——把整个团队的所有产物（需求、规格、规范、测试）全部代码化，放到代码仓库中统一管理：
```markdown
/.agent
/skills # 工作方法
/mcp # 工具配置
/templates # 模板
/rules # 规范
/docs # 文档
```
所有 AI 工具（SuperPower、Claude Code 等）安装时都从代码库读取配置，实现极致高效。
### 9.2 多 Agent 协调的挑战
当前多 Agent 框架（如 CrewAI、AutoGen）还处于早期阶段：
- 缺少程序级别的精确校验（不能完全依赖 AI 判断）
- Agent 与代码之间的交互需要程序驱动而非纯 AI 驱动
- 可能需要自己写 workflow 调度器
### 9.3 共识是第一要务
> "工具是玩人的，为了获得团队的共识。"
大公司之所以比小公司/创业公司更难推进 AI 编程变革，是因为：
- 习惯难以改变
- 团队文化难以调整
- 需要从上到下的强力推动
## 十、团队实践建议
### 10.1 渐进式落地路线
1. **单人验证阶段**：选择一个简单项目，用 SuperPower + TDD 验证 AI 编程效率
2. **规范建立阶段**：定义技术规格模板、代码规范、打样工程
3. **团队推广阶段**：用 Skills 标准化工作方法，逐步让团队接受
4. **自动化阶段**：打通从需求到部署的全流程，实现"代码即一切"
### 10.2 技术经理的核心职责
- 定义 AI 友好的需求规格模板 → 推动 BA/产品接受
- 建立打样工程和代码规范 → 控制代码质量下限
- 推动测试文化 → 这是专业和非专业软件公司的分界线
- 构建团队共识 → 这是最难也是最重要的事
### 10.3 避坑指南
1. **不要让 AI 直接写数据库**：用 Flyway 脚本版本化管理
2. **不要拆分过于细小的需求**：一个模块一个文档
3. **变更需求一定要标注变更类型**：不要给完整状态
4. **不要让 AI 同时做设计和代码**：分阶段，用不同角色
5. **不要完全依赖 AI Review**：用规则约束、AI + 人工结合
## 十一、观众反馈与补充
- **华为 CodeArts Agent**：带有规范驱动开发模式，可以参考
- **Obsidian + Opal**：适合做 Markdown 知识库管理，手机和电脑同步，适合在外也能用手机+终端工作
- **看板式 AI 协同**：所有需求、设计、任务全部看板化，共享给团队成员
- **跨 Agent 通信**：契约文件（如 OpenAPI JSON）放到共享目录，前后端各自读取 → 避免前端改完后端不知道的问题
- **sonarlint 本地扫描 + AI 自动修复**：在 pre-commit 阶段触发静态扫描，AI 自动修复代码风格问题，效果很好

177
3Resources/AI/2026-05-30 SDD 规格驱动落地_文档管理策略_BV1mZV76eEPC_笔记.md Normal file
View File

@@ -0,0 +1,177 @@
# SDD 规格驱动落地：文档管理策略
## 研讨会背景与目的
本次分享是 AI 编程相关话题的延续，主要聚焦 **SDD（Spec-Driven Development，规格驱动开发）** 的文档管理策略。
### 研讨会机制
- **目的**：让参会者能够参与达成社区共识，分享各公司在 AI 编程实践中的经验
- **形式**：咨询师分享观察到的公司实现方案、架构设计、系统设计等内容
- **价值**：对个人和团队帮助都非常大，通过集体讨论形成共识
> 特别感谢卡尼克老哥在研讨会期间贡献了大量分享思想，受益颇多。
---
## AI 编程发展历程回顾
### 时间线概览
| 时间 | 分享内容 | 核心概念 |
|------|----------|----------|
| 2025年6月 | 早期 AI 编程实践 | DPER5 方法论 |
| 后续 | MCP 等工具整合 | MCP、Scales |
| 5月9日 | Plan 和 Build 模式 | 新因子（吸引子）概念 |
| 本次 | SDD 文档管理策略 | 规格驱动落地 |
---
## DPER5 方法论
### 核心思想
DPER5 将软件工程中使用 AI 进行开发的过程分为 **5 个弱阶段（Weak Stages）**：
```
Discover → Plan → Execute → Review → Refine
↓ ↓ ↓ ↓ ↓
发现 规划 执行 评审 优化
```
### 阶段特性
- 不同阶段 AI 会按照不同的模式运行
- 例如在 **Design** 模式或 **Discover** 模式下，AI **不会修改代码**
- 这种分阶段约束是驯服 AI 的简单有效方法
### 实践应用
- 在早期阶段（2025年），演讲者已经在公司内部领先应用
- 采用 `Design → Plan → Execute` 的流程驱动开发
- 该方法使用了较长时间，有效规范了 AI 辅助开发流程
---
## MCP（Model Context Protocol）工具生态
### 工具整合
后续随着 MCP 以及相关工具套件的出现，形成了完整的 AI 编程工具生态：
- **MCP（Model Context Protocol）**：模型上下文协议
- **Scales**：扩展工具
- **SDD**：规格驱动开发方法论
这些工具被整合到一份 PPT 手册中，作为团队 AI 编程的指南或手册参考。
---
## SDD（规格驱动开发）
### SDD 的核心模式
SDD 提供了多种工作模式，适用于不同的开发场景：
| 模式 | 适用场景 | AI 行为特征 |
|------|----------|-------------|
| **Design** | 需求分析、架构设计 | 不修改代码，仅提供设计建议 |
| **Discover** | 探索发现、方案调研 | 不修改代码，专注于信息收集 |
| **Plan** | 规划分解、任务拆解 | 生成实现计划 |
| **Build** | 代码实现、具体开发 | 执行代码编写和修改 |
### 新因子（吸引子）概念
由 countic 大佬在 5月9日的分享中引入：
**物理学的概念解释**：
- 在混沌系统中，存在两种震荡反馈的系统
- 这种系统最终会收敛到一个稳定状态
- 这个收敛点被称为 **吸引子（Attractor）**
**在 AI 编程中的应用**：
- 通过引入新因子，可以引导 AI 的输出趋向于预期的稳定状态
- 帮助控制 AI 在复杂任务中的发散性
- 实现更可控的 AI 驱动开发流程
---
## SDD 文档管理策略
> 本次分享的核心主题，聚焦于规格驱动开发的文档管理方法
### 文档在 SDD 中的作用
1. **规格定义**：明确需求和设计规范，作为开发的基准
2. **上下文传递**：在不同阶段之间传递上下文信息
3. **版本控制**：记录规格的变更历史
4. **团队协作**：统一团队对需求的理解和实现方式
### 文档管理最佳实践
（基于 SDD 方法论，文档管理应遵循以下原则）
- **规格优先**：在开发前先完成规格文档的编写
- **增量迭代**：规格文档随项目进展逐步完善
- **双向追溯**：规格与实现之间保持可追溯性
- **工具集成**：将文档管理与 AI 编程工具链整合
---
## 工具链整合方案
### 推荐的 AI 编程工具栈
```
┌─────────────────────────────────────────────────────┐
│ 规格层 (Spec) │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Design │ │ Discover │ │ Plan │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
├─────────────────────────────────────────────────────┤
│ 工具层 (Tools) │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ MCP │ │ Scales │ │ SDD │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
├─────────────────────────────────────────────────────┤
│ 执行层 (Execution) │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ Build │ │ Review │ │
│ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────┘
```
### MCP 的核心功能
- 提供标准化的上下文协议
- 实现 AI 与外部工具的无缝集成
- 支持多工具协同工作
---
## 社区贡献者致谢
| 贡献者 | 贡献内容 |
|--------|----------|
| 卡尼克 | 大量分享思想，研讨会核心参与者 |
| countic | 引入新因子（吸引子）概念，分享 Plan/Build 模式 |
| 少个分号 | SDD 方法论整理，工具链整合，文档管理策略分享 |
---
## 后续话题预告
本次分享的议程安排：
1. **SDD 文档管理策略**（当前内容）
2. **AIGC 模板相关话题**（由卡尼克老哥分享）
---
## 参考资源
- 本次分享的 PPT 资料（可作为团队 AI 编程手册/指南）
- 搜索关键词：`AI编程`、`MCP`、`SDD`、`DPER5`、`规格驱动开发`
- 相关标签：`人工智能`、`规格驱动开发`、`AI编程`

0
InBox/glue-coding-tmall-ai-practice-2026-03-27.md → 3Resources/AI/97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】.md
View File

0
97.9%采纳率，胶水编程：业务需求出码最佳实践【天猫AI Coding实践系列】.md
View File

36
InBox/v2ex_1196441_大模型变笨讨论.md
View File

@@ -1,36 +0,0 @@
# 大家有没有感觉最近大模型变笨了
**来源**: https://www.v2ex.com/t/1196441#reply25
**保存时间**: 2026-03-24
**标签**: #AI #大模型 #讨论
---
## 帖子摘要
楼主提问：大家有没有感觉最近大模型变笨了？
主要讨论点：
- 用户感觉 GPT-4、Claude 等大模型最近回复质量下降
- 有人认为是心理作用或期望值提高
- 也有人提到可能是模型更新导致的风格变化
- 讨论涉及多个主流大模型：GPT-4、Claude、Gemini 等
---
## 关键回复观点
1. **心理作用论**: 用多了之后对模型能力边界更清楚，所以感觉"变笨"
2. **模型更新论**: OpenAI 等厂商确实会调整模型，可能影响某些任务的表现
3. **任务复杂度**: 随着使用深入，提出的问题更难，模型显得力不从心
4. **对比效应**: 新模型出来后，旧模型相对显得弱了
---
## 个人思考
(待补充)
---
**原始链接**: https://www.v2ex.com/t/1196441#reply25

17
InBox/zhihu_article_2028819446546932894.md
View File

@@ -1,17 +0,0 @@
---
title: 知乎文章 - 2028819446546932894
source: https://zhuanlan.zhihu.com/p/2028819446546932894
created: 2026-05-09 15:02
tags: [zhihu, article, saved]
---
# 知乎文章
**URL:** https://zhuanlan.zhihu.com/p/2028819446546932894
**说明:** 此 URL 由 Hermes 保存，文章内容因知乎反爬虫机制（zse_ck）暂无法自动抓取。
> 请手动访问该链接查看完整文章内容，然后将正文粘贴到此处。
---