Add Milky notes: 20 file(s)
This commit is contained in:
Zane
365
InBox/milky_BV1SZoXBkErT.md
Normal file
365
InBox/milky_BV1SZoXBkErT.md
Normal file
@@ -0,0 +1,365 @@
|
||||
---
|
||||
title: "[Milky] 为您整理《2026-04-25 Harness for AI coding 团队级 AI 编程驾驭工程》笔记 | BV1SZoXBkErT"
|
||||
source: "milky@4ueo.com"
|
||||
date: 2026-06-09 10:48
|
||||
tags: [milky, bilibili, notes]
|
||||
email_id: 2043
|
||||
---
|
||||
|
||||
Milky 为您整理了《2026-04-25 Harness for AI coding 团队级 AI 编程驾驭工程》 | BV1SZoXBkErT 笔记。
|
||||
|
||||
敏捷团队 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 个关键部分：
|
||||
|
||||
业务背景：为什么做这个需求
|
||||
字段清单：所有业务字段的类型、默认值、业务规则（避免只给原型图让 AI 去猜）
|
||||
原型链接：Figma 图等设计稿的链接（AI 可通过 MCP 读取 Figma）
|
||||
业务规则：按条拆分，例如：
|
||||
- 订单号生成规则
|
||||
- 发货规则
|
||||
- 状态转换规则
|
||||
|
||||
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 打样工程的作用
|
||||
|
||||
AI 生成代码风格一致：所有 AI 都基于同一个框架生成代码
|
||||
减少重复代码：AI 会复用框架中的组件而不是重复写
|
||||
降低认知负担：AI 不需要每次理解项目结构
|
||||
|
||||
4.3 如何创建打样工程
|
||||
|
||||
从旧项目中蒸馏出一个干净的新项目骨架
|
||||
定义每层职责：Controller → Service → Repository → Entity
|
||||
定义类命名规范和包结构
|
||||
放入 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 的工作方式）
|
||||
|
||||
让 AI 先写 API 测试/单元测试
|
||||
AI 运行测试 → 失败
|
||||
AI 再写实现代码
|
||||
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 方式
|
||||
|
||||
工具扫描：SonarQube 等静态分析工具 + AI 自动修复
|
||||
AI Review：用另一个 AI 模型做交叉 review（换模型做 review 是常用技巧）
|
||||
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 渐进式落地路线
|
||||
|
||||
单人验证阶段：选择一个简单项目，用 SuperPower + TDD 验证 AI 编程效率
|
||||
规范建立阶段：定义技术规格模板、代码规范、打样工程
|
||||
团队推广阶段：用 Skills 标准化工作方法，逐步让团队接受
|
||||
自动化阶段：打通从需求到部署的全流程，实现"代码即一切"
|
||||
|
||||
10.2 技术经理的核心职责
|
||||
|
||||
定义 AI 友好的需求规格模板 → 推动 BA/产品接受
|
||||
建立打样工程和代码规范 → 控制代码质量下限
|
||||
推动测试文化 → 这是专业和非专业软件公司的分界线
|
||||
构建团队共识 → 这是最难也是最重要的事
|
||||
|
||||
10.3 避坑指南
|
||||
|
||||
不要让 AI 直接写数据库：用 Flyway 脚本版本化管理
|
||||
不要拆分过于细小的需求：一个模块一个文档
|
||||
变更需求一定要标注变更类型：不要给完整状态
|
||||
不要让 AI 同时做设计和代码：分阶段，用不同角色
|
||||
不要完全依赖 AI Review：用规则约束、AI + 人工结合
|
||||
|
||||
十一、观众反馈与补充
|
||||
|
||||
华为 CodeArts Agent：带有规范驱动开发模式，可以参考
|
||||
Obsidian + Opal：适合做 Markdown 知识库管理，手机和电脑同步，适合在外也能用手机+终端工作
|
||||
看板式 AI 协同：所有需求、设计、任务全部看板化，共享给团队成员
|
||||
跨 Agent 通信：契约文件（如 OpenAPI JSON）放到共享目录，前后端各自读取 → 避免前端改完后端不知道的问题
|
||||
sonarlint 本地扫描 + AI 自动修复：在 pre-commit 阶段触发静态扫描，AI 自动修复代码风格问题，效果很好
|
||||
|
||||
──────────────────────────────
|
||||
Generated by MilkyAi@Bilibili: https://space.bilibili.com/3461574540921489
|
||||
Reference in New Issue
Block a user