1. 主会场：12 个入口，背后其实是同一个问题#

主会场一开始，各个召集人把本期的多个分组房间依次介绍出来：AI+抑郁症康复、FDE 工程师能力、AI+灵感共创、FDE 团队共创、CancerDAO AI、Loop Engineering、可梦 AI OfferLab、OPC 智脑、AI 时代的阅读、AI 时代焦虑、和 AI 唠唠叨叨地协作、AI 进入协作关系后人的成长。

这些题目看起来很散：医疗、教育、求职、阅读、创业、企业落地、个人成长、工程方法。但当每个房间发起人快速介绍自己的话题时，一个共同的问题已经浮出来：

AI 不再只是一个工具入口，而是在进入人的决策、组织流程和协作关系。

FDE 房间关心的是企业到底需要什么样的人把 AI 带进去；CancerDAO AI 房间关心的是患者能不能用 AI 看懂报告、追踪病程、匹配临床试验；OPC 智脑房间关心的是一人公司从想法到付费用户之间到底少了哪一步；AI 阅读房间则把问题拉回个人：AI 能帮你总结，但它能不能替你形成理解？

主会场像一个目录，也像一次预告：第六期的主题并不是”AI 很厉害”，而是”AI 进入真实世界以后，哪些旧问题被放大了，哪些新角色正在出现”。

2. David、小星星和一群 FDE 从业者：AI 落地的新岗位，最难的不是写代码#

FDE 房间从一个很现实的问题开始：Forward Deployment Engineer 到底需要什么能力？

David 先把 FDE 的背景讲清楚。随着大模型公司和企业客户走得越来越近，AI 不只是卖 API 或卖模型，而是要进入客户的真实业务现场。FDE 这类角色因此变得更热：它既要理解客户需求，也要能把 AI 能力接到流程里，还要处理落地中的沟通、交付和迭代。

房间里也讨论了 Claude Certified Architect 这类认证。David 的重点不是把认证包装成万能通行证，而是把它当成一个学习抓手。

真正让房间变得具体的，是小星星的驻场经历。

他在一家做跨境业务的企业里待了三个月，看到的需求都不炫酷：销售每天花几个小时做 Excel 发票，财务要手工汇总大量单据；销售和海外客户沟通，要不断复制粘贴翻译；新人不熟业务，需要内部知识库快速回答问题。

于是他做了发票工具、WhatsApp 翻译插件、内部知识库和一些绩效统计脚本。

可他也很快发现，FDE 最难的并不是把工具写出来。

有的部门担心数据安全，有的人不愿改变原来的工作方式，有的老板对 AI 期望过高，有的同事把外部驻场人员当成”来替换自己的人”。一个工具能不能上线，往往取决于需求是不是被真正理解、关系是不是被处理好、流程里的人愿不愿意让它进入日常工作。

最后留下的判断很清晰：

FDE 不是”会用 AI 写代码的人”，而是能把业务语言、工程语言和组织现场翻译到一起的人。

3. Ray 和 Wang瑞：AI+灵感共创不是头脑风暴，而是把真实项目拆到下一步#

AI+灵感共创房间一开始，Ray 和 Wang瑞先聊了几个偏前沿的观察：科学基础模型如何把蛋白质、小分子、材料结构变成一种可被模型处理的”科学语言”；AI 原生团队里，瓶颈可能不再是单个人会不会用 AI，而是人与人之间的信息传递。

但这个房间最有价值的部分，不在概念，而在项目共创。

第一个项目来自一个面向信息学学习的产品。分享者原本想做一个帮助孩子学习编程的工具。Ray 的建议很直接：先观察真实学生怎么用它。不要在首页塞太多选择，也不要让界面被表情和装饰淹没。

第二个项目来自传统业务场景。参与者提出了几个非常具体的自动化需求：员工要在平台上找潜在客户，采购要在多个平台上询价，销售面对客户模糊需求时不知道该如何匹配产品和报价。

这个房间里反复出现的一个判断是：

不要从”AI 能做什么”出发，而要从业务场景和用户动作出发。

大家反而在追问：哪些步骤是规则明确的？哪些需要专家判断？哪些平台有反爬和成本问题？如果要自动报价，企业愿不愿意把产品库、历史报价、专家经验和客户访谈开放出来？

4. 袁军、沈林和 FDE 团队共创：企业 AI 化不是装一个模型，而是一次组织诊断#

另一个 FDE 相关房间更偏团队共创和企业落地。

袁军先把 FDE 能力拆成几层：懂行业和客户的战略顾问能力，能把客户语言翻译成工程语言的业务翻译能力，从 demo 到 POC 再到完整交付的技术实现能力，以及处理阻力、协作和变革的管理能力。

有参与者分享了一个典型案例：一位企业负责人希望把每个部门都变成 agent，让系统自学习、自动替代人，但只给了非常粗略的流程描述。问题并不是”模型够不够强”，而是企业对 AI 的理解、对自身流程的描述、对数据和责任边界的定义都还不够清楚。

袁军和其他共创者给出的建议是：先对齐认知，再做诊断。 不要急着承诺一个大而全的系统，也不要一上来就做复杂 demo。更稳妥的路径是找到一个足够小、足够明确、能被业务方验证的痛点，先做出一个能建立信任的小结果。

房间后半段讨论了 API、私有化、本地部署和混合部署。

这个房间最后留下的判断是：

FDE 的价值不只是会选模型，而是能帮企业判断：哪些流程值得 AI 化，哪些数据不能出边界，哪些组织阻力必须先被处理。

5. Fernanda 和 YoSean：患者最缺的不是一句答案，而是一条能走下去的病程路径#

CancerDAO AI 房间是这一期最沉重，也最具体的房间之一。

Fernanda 和 YoSean 介绍 CancerDAO AI 时，没有把它讲成一个普通问答机器人。它更像是围绕癌症患者全病程管理的一套工具和社区设想：患者上传检查报告、病历、基因检测结果后，系统帮助整理病例、解释报告、做问答、匹配临床试验，也尝试围绕患者数据授权、技能市场和患者社区建立更长期的支持网络。

房间里一个核心问题是：患者和家属真正缺什么？

很多时候不是缺一个泛泛的医学解释，而是缺一条可以继续走下去的路径：现在处在哪个治疗阶段？标准治疗失败后还有没有临床试验？基因检测结果意味着什么？副作用要不要继续扛？什么时候必须换医院、找专科、抢时间窗口？

DeepSleep 分享了自己作为家属陪伴母亲长期抗癌的经历。她提到，治疗不是单点决策，而像一个复杂工程：诊断、检查、专科选择、治疗窗口、临床试验、用药副作用、照护轮换，每一步都可能影响后面的结果。

这个房间没有把 AI 说成”替代医生”。它更像在讨论另一件事：

当患者已经开始用 AI 读报告、查方案、问下一步时，我们能不能给他们一个更可靠、更可追踪、更尊重数据边界的辅助系统。

6. 阿昭、Nature 和一群项目人：Loop Engineering 不是新词竞赛，而是把目标、上下文和反馈闭起来#

Loop Engineering 房间从一个工程概念切入，但最后讨论的其实是人如何控制一个复杂的 AI 系统。

Nature 先把 prompt、context、harness、loop 的关系讲得很清楚：这些概念本质上都在回答同一个问题：模型什么时候应该看到什么，应该保留什么，应该忘掉什么，输出之后又如何被检查、修复和继续推进。

这背后的难点不是”多放几个 agent”，而是：当系统越来越复杂，人如何知道它在做什么、错在哪里、该由谁来纠偏。

房间里也有人问：如果新名词迭代太快，普通人应该怎么学？阿昭给出的建议很朴素：从自己的项目开始做，不要只看二手解读。Nature 也补了一句更锋利的判断：如果你没有一个具体到让自己痛的项目，也许你暂时并不需要学 Loop Engineering。

后半段，讨论进入传统行业和真实项目。电子制造报价的案例尤其具体：客户给来的报价资料可能有多份文档，一个团队要花很久拆参数、算成本、核风险。报价错了，可能直接亏损或丢单。

这个房间最后把问题从 loop 拉回 goal：

闭环不是为了让系统自己转起来，而是为了让人能持续把目标、上下文、评审和反馈压进同一个工作流。

7. Katerina 和赵迪：求职不只是写简历，而是把信息差拆成一条可练习的流程#

可梦 AI OfferLab 房间围绕求职展开。

Katerina 和赵迪展示的产品目标很明确：用户上传简历和目标 JD，系统分析岗位关键词、匹配度和表达差距，再帮助改写简历，生成中英文版本。

房间里很快有人提出更进一步的问题：如果学生本身不知道自己的经历该怎么表达怎么办？ 如果简历里没有项目经历，AI 是不是应该先通过访谈把校园经历、兼职经历、课程项目、竞赛经历挖出来，再转化成岗位能理解的语言？

于是，求职这个话题背后的核心判断变成了：

简历只是表层。真正要补的是一个人识别机会、表达价值、验证能力和持续迭代的系统。

8. 李屹镒和 OPC 智脑：一人创业不是先把产品做完，而是先验证谁愿意付钱#

OPC 智脑房间像一个密集的创业诊断台。

李屹镒介绍的 OPC 智脑不是绑定某个模型的产品，而是一套可以放进不同 AI 工具里的 Skills。它围绕一人公司常见阶段做诊断：想法验证、产品设计、合规问题、冷启动、找到第一个付费用户、从 1 到 100 放大。

房间里连续出现了几个真实项目：

• 淼淼想做面向 2 到 6 岁孩子的情绪陪伴产品。李屹镒没有直接鼓励她去开模、做硬件，而是先把合规、儿童产品、供应链、质量、安全认证、算法备案这些问题摆出来。然后他把问题收窄：先验证父母是否真的愿意为这个需求付钱。
• 黄赟提出公司注册和专利检索相关的想法。讨论没有停在”能不能做一个 AI 专利搜索”，而是继续追问：谁已经有数据库？客户为什么不用现有代理机构？
• 韩春涛是安全开发背景，想转向 AI 安全。李屹镒建议他把方向从宽泛的”AI 安全”缩到更具体的 LLM 红队、提示注入、越狱、数据泄露、输入安全测试等领域。
• Timo 的 CNC 加工报价项目。他已经有试用工厂，有人愿意付费，但他担心产品不够成熟。李屹镒给出的建议非常直接：如果有人愿意付费，就先收第一笔钱。

这个房间反复出现的一句话可以概括成：

OPC 的第一性问题不是”我能做什么产品”，而是”谁有痛感，谁愿意付钱，下一周我能拿什么去验证”。

9. 袁继伟：AI 可以帮你读，但不能替你形成理解#

AI 时代还要不要自己阅读？这个房间的答案并不是简单的”要”或”不要”。

袁继伟展示的是一个偏阅读工作台的工具：可以保存网页和 PDF，做合集管理、翻译、笔记、问答、引用跳转，也可以围绕文档配置不同的 AI 辅助方式。但他的重点不是让 AI 替人读完，而是让人更好地回到原文。

讨论里，一位做教育内容的参与者提出了一个很具体的痛点：他们在 K12 场景里把电子书拆章节、生成报告和可读内容，但 AI 生成的内容经常太平、太逻辑化，缺少故事性、共情和思考空间。

袁继伟的开发实践也很有意思：他不是一开始就做出完整产品，而是不断找参考项目、拆设计、让 AI 帮助实现，再频繁删除功能、重写、迭代。

这个房间留下的判断很克制：

AI 可以帮你翻译、总结、提问、检索、生成卡片，但理解这件事仍然要由人完成。

10. KQY 和共创参与者：真正该焦虑的，不是 AI 写代码，而是你有没有可迁移的底层能力#

AI 时代焦虑房间，表面上是在聊”会不会被取代”，实际上聊的是人在技术变化中还能抓住什么。

KQY 先从自己观察到的变化讲起：AI coding 明显提升了个人产出，一些公司内部也开始重新评估岗位和团队结构。但房间里很快把”AI 替代人”拆得更细：个人写代码变快，不等于组织交付一定变快。真实工作里，大量时间消耗在需求理解、跨团队沟通、文档、测试、发布、责任划分和后续维护上。

另一个重要讨论是全栈化。AI 让一个人更容易跨前端、后端、脚本、数据和自动化工具，但人的认知带宽仍然有限。尤其在金融、医疗、工业等高风险场景里，“一个人全包”并不总是好事。

大家给出的答案并不花哨：底层原理、阅读能力、检索与判断、跨团队沟通、情绪管理、健康、睡眠、运动，以及在变化中保持持续学习的能力。

其中一个很有价值的区分是：检索不等于阅读，看到答案不等于理解。

所以这个房间的结论不是”别焦虑”，而是更具体：

恐惧本身会消耗人。比起反复问 AI 会不会取代我，更有用的是问：我有哪些能力可以跨工具、跨岗位、跨周期迁移。

11. 你想猫：唠叨不是废话，是把经验沉淀进下一轮工作流#

“AI 需要一个唠唠叨叨的你”这个题目，听起来很轻松，但房间里的内容其实很工程化。

你想猫的核心观点是：很多人用 AI 失败，不是因为问得不够高级，而是因为给的信息太少，反馈太少，错误没有被记录，也没有进入下一次流程。 所谓”唠叨”，不是对 AI 发牢骚，而是持续告诉它：哪里不对、为什么不对、下一次应该怎么改。

随后你想猫展示了自己做过的工作流：检测、修复、迭代、评分、分支对比，让系统自己不断收敛。他也展示了”漫剧系统”和视频广告工作流：先反向拆解热门短剧或优秀视频的镜头、构图、光线、情绪曲线和节奏，再把这些观察变成提示词、流程和下一轮生成的约束。

这里最关键的不是”生成一次视频”，而是把每次失败写回系统。

这个房间留下的判断很适合所有正在用 AI 做创作的人：

不要只把 AI 当成一个回答器。把你的偏好、纠错、案例和判断持续喂回流程，AI 才会从”会生成”走向”会配合”。

12. 毅成：AI 越像协作者，人越需要一面镜子#

“当 AI 进入协作关系，人如何成长？“房间的发起人毅成，带来的是一个 AI 协作能力测评 demo。

这个 demo 会通过一系列问题，生成一份关于个人 AI 协作能力的报告。它关心的不只是”你会不会用某个工具”，而是你是否能定义问题、提出好问题、拆任务、委派给 AI、使用上下文和工具链、在 AI 输出后做判断和迭代。

毅成把它称作一种”AI 刻度”。

房间里，生财王者带来了另一个问题：他做过一个用药提醒小程序，但担心推广和变现不值得投入。毅成没有直接建议他继续做小程序，而是建议他回到真实需求：不要只复制热门项目，要去身边的人和公司里找 AI 落地机会。

这个房间的核心判断是：

当 AI 越来越像协作者，人越需要看见自己的协作方式。测评不是为了贴标签，而是为了找到下一步可以练习的地方。