回答的核心
如果 AI 方案已经超出驱动者理解，很可能是过度设计或失控信号。不要追求“AI 做我完全做不了的复杂物”，而要选择自己能解释、能验收、能维护的方案。
Q&A
问答真正暴露的是边界：什么能交给 AI，什么必须由人收口
会议后半段的价值在于具体问题：复杂系统看不懂怎么办、前端总改坏怎么办、产品经理如何交付、Worktree 到底值不值得用。这些问题比工具清单更接近真实工程。
Complexity
AI 设计出看不懂的系统怎么办
问题来自复杂 AgentOS / A2A 类系统的管理困惑。
操作建议
让 AI 给多个方案，挑自己理解范围内的最优方案；砍掉冗余抽象；把系统拆成可测试、可观测、可替换的小模块。
Frontend
前端生成效果差、改动易破坏旧逻辑怎么办
这个问题反复出现在 AI 编程实践中。
不要让 AI 从零发明基础 UI
用成熟组件库和设计系统兜底，基础控件越稳定，AI 越能把精力放在业务逻辑和页面状态。
沉淀自有业务组件
业务里反复出现的列表、表单、状态面板、工作流步骤要组件化。这样下一次不是重新生成，而是复用。
保留视觉验收
截图、移动端、长文本、交互状态和回归路径要人工检查。前端测试不能只看代码是否编译。
PM
产品经理在 AI 时代交付什么
会议里的回答非常明确：只交 PRD 不够了。
从文档到 MVP
产品经理应尽量把 idea 做成能跑的 MVP，自己完成基础测试，再交给开发评审和工程化。
反向生成说明文档
让 AI 基于 MVP 代码生成说明文档，前后端开发再用自己的 Agent 评审、重构和部署。
节省迭代时间
这种方式可以减少传统 UI 评审、终审、开发、测试之间的等待，把讨论建立在可运行产品上。
Disagreements
值得保留的分歧
好的会议不是消灭分歧，而是把分歧变成判断框架。
| 议题 | 立场 A | 立场 B | 整理后的判断 |
|---|---|---|---|
| Worktree | 并行开发必须隔离工作树。 | 上下文污染和合并成本可能很高。 | 按项目复杂度和任务独立性选择，不默认。 |
| Spec 完整度 | 越全越能减少返工。 | 写太久会拖慢启动。 | 85%-90% 更实际，保留 15% 变化空间。 |
| 设计工具 | Figma/Sketch 可控性强。 | 早期验证可用 AI 图像和参考稿。 | 验证功能优先时不必追求像素级设计。 |
| 脚手架 | 脚手架是古法编程残留。 | 脚手架能降低重复和认知成本。 | 标准流程可脚手架化，创新部分保留灵活度。 |