自动化开发痛点与会议开场
会议说明了为什么要讨论 Harness：工具已经跨过能交付的门槛，但多人、多项目、多 Agent 并发时，真正暴露的是管理、验收和资源协调问题。
Timeline
2 小时 10 分钟，被拆成 18 个工程问题
时间线保留飞书妙记跳转，方便回到原始语境。公开正文则做二次提炼，避免把逐字稿当成总结。
Chapters
章节复盘
点击时间戳可打开飞书妙记对应位置。
从副驾到管理者
林诚强调把 Agent 当作团队新人：给规范、架构、背景和最佳实践。并发上不去，往往不是模型不够强，而是驱动者还在用副驾心态盯每一行代码。
Review 与经验沉淀
代码 Review 不只是挑错，而是把重复问题沉淀成 Skills、检查点和自动验证。Agent 无状态，项目知识必须落到纸面和流程里。
模型选择与前端质量
领先模型的 Token 成本低于人力成本；前端生成不稳时，应优先使用成熟组件库和自有业务组件，让 Agent 更专注业务逻辑。
复杂系统如何保持控制
当 AI 给出的架构超出理解范围，建议砍掉复杂冗余，选择自己能解释、能验收、能长期维护的方案。
Harness 实践与多 Agent 协同
团队开始踩通从自动化开发到自动化测试验收的链路，但 Agent 间缺乏协调、测试闭环不足和缺少收口人，是并发开发的典型痛点。
多端测试与认知债务
多端开发需要观测工具和自动化测试闭环。术语不准、变量歧义、任务边界不清都会形成认知债务，放大 Agent 理解偏差。
个人生产力与 Token 并发
高并发开发像种菜收菜：并发度从手动推进，到多 Agent 协作，再到睡眠开发逐步抬升。Markdown 可作为 Agent 生命周期和交接的协调层。
Spec 设计与量化指标
Spec 不追求 100% 预言未来，85%-90% 完整度更实际。新增变化应控制在约 15% 内，增删比可用来观察是否发生不健康重构。
Worktree 分歧
Worktree 能解决并行文件冲突，也会带来合并、端口、上下文污染和 Token 成本。结论不是一刀切，而是把选择权交给项目复杂度。
ToB/ToC Spec 与分层
ToB 更重视组件抽象、子系统复用和表结构/API 分层；ToC 更容易被体验细节拉扯。Spec 应先讨论业务，再落表结构，避免相互污染。
前端检查点与设计稿
可用 Kimi 等工具基于 Markdown Spec 生成设计稿，再设置硬约束检查点，把前后端雏形串起来。测试可交给 AI 一部分，但细节仍要人验收。
资源感知
资源感知包括端口、CPU、GPU、线上线下性能差异。用 Markdown 维护资源列表，可以避免多个项目并发时抢端口、抢算力、抢上下文。
模型能力与领域知识
模型效果受领域知识沉淀影响。公开数据充分、流程标准的领域更适合模型接管；创新领域仍需要专家判断和频繁校验。
页面设计工具
早期验证不必把 Figma 当唯一入口。可以用 GPT 图像、Stitch、Dribbble/Behance 参考稿和站点 CSS 总结来形成风格约束。
后端分层与脚手架
后端可按数据层、算法层、业务逻辑层拆分。成熟脚手架和现有框架源码能帮助 AI 更快理解关键流程节点。
产品经理交付方式
产品经理不只交 PRD 和原型，而应尽量产出 MVP，由开发和 Agent 反向评审、生成说明文档并做工程化收口。
收尾与后续分享
会议确认会整理录音稿，并保持小范围高密度交流。模型能力变化很快，定期同步比一次性结论更可靠。