has father 就是——你只能有一个父亲、一个母亲。它既能扩充信息也能当约束：如果系统里同时有"Bob 是 Jim 的父亲"和"BB 是 Jim 的父亲"，推理机会得出Bob 和 BB 其实是同一个个体的两种写法（实体消歧就这么自动完成了）。→ 详细while True 循环。→ 详细resp（response）：指定模型 + prompt + 一个 tool，请 LLM 用这个 tool 解决问题。关键点：「LLM 什么也做不了。它唯一能做的就是以高概率给出下一个词。」 所以 LLM 只会把参数配好然后交还给你——他给 LLM 配了一句台词：「这就是你需要发起的那次 tool 调用，因为我做不到。我是 LLM，我被锁在这个盒子里。」→ 详细stop_reason（停止原因）：如果停止原因是 tool use，那就到点了——get_tool 接过那个已经组织好参数的 response，触发真正的动作。→ 详细tool runs（工具运行）之后。tool 返回信息 → 把信息整理成 validator（校验器） 能用的形式 → 这个 validator 是基于你领域的本体在运作的 → 由它判断 LLM 的回复到底合不合理。→ 详细x = 20，再写 x = hello，完全没问题，没有类型系统"——Pydantic 给它加上了类型。所以顺序是：先用 Pydantic 检查类型，再用 ontology 检查结果。→ 详细本场为 20 分钟单人演讲，没有 lightning round，也没有现场问答环节（结尾他说了句"非常感谢。20 分钟。"就下台，随后是掌声与音乐）。收尾内容：→ 详细
首尾呼应的座右铭（原话）：「我最后的结论是：没有什么是错误，没有输赢，没有成败，只有去做。」——即开场引用的 Sister Corita Kent / John Cage 那句 "Nothing is a mistake. There is no win. There's no fail. There's only make."。→ 详细
网站名的由来：他是铁杆爵士乐迷，John Coltrane 有一张专辑叫《A Love Supreme》，所以把自己的网站取名 Code Supreme，"上面有些音乐，都挺不错的"。→ 详细
邮箱：口播为 coyle@berkeley（现场语音听写，完整域名未拼全）；个人网站 codesupreme.ai（致敬 John Coltrane《A Love Supreme》）。→ 详细
身份：UC Berkeley 教师，计算机领域从业 30–35 年，早期在神经科学、八十年代做过专家系统。→ 详细
这场 20 分钟的演讲，相关度高得有点不讲道理——因为讲者随口举的本体例子（采购订单 / 客户 / 客户代表）字面就是一套 ERP 的实体表，而他提出的"本体当校验层"正好戳在你 PRD 工厂「跨线对齐缺地基」的坑上。按相关度从高到低：
他们怎么做的：讲者说建本体有两条路。自上而下是"把专家凑到一起，坐下来分析这个领域，把实体梳理出来——我们有采购订单，我们有客户，我们有客户代表，然后我们要把它们结构化，它们有属性，这些是它们之间的关系"→ 详细；自下而上是从真实数据（客户反馈）里发现新实体新关系，往图里加→ 详细。而本体的定义他用了 Gruber 1993 那句——"共享概念化的形式化规范"→ 详细。注意"shared"这个词：本体的价值不在于某个 agent 用得爽，而在于所有人和所有 agent 指的是同一个东西。
你可以怎么做：你的跨线对齐做不动，本质是一个病——6 条产品线、每条线的三驾马车，都在各说各的"订单""客户""退款"。别再把共同实体当"待补的文档"，把它当本体来建，而且两条路一起走：自上而下先从你最熟的产品线抽 15–30 个核心实体（订单、SKU、库存、退款单、客户、店铺、平台……）+ 它们的关系 + 每个字段的合法取值；自下而上从已有的 PRD 和线上工单里反向捞——凡是两份 PRD 对同一个词用了不同定义的，就是一条必须写进本体的条目。规模上不用怕：他反复说"它不复杂，你就把它想成一个图数据结构"→ 详细，不需要上 RDF/OWL 全家桶，一份带枚举约束的 YAML 就是最小可用本体。
更深一层（反着用）：他讲了一段警告——自上而下这套正是八十年代专家系统的路子，当年公司一家家冒出来、几百万美元砸进去、日本搞了"未来世界"项目，结果因为 scale 不了进了 AI 寒冬→ 详细。这条对你是红线：如果你拉一屋子人开三周会去穷举 ERP 全线实体，你复现的不是本体地基，是 1988 年。正确姿势是只为"已经出过问题的地方"建本体——哪条产品线跨线对齐吃过亏，就先建哪条线的十几个实体，让它立刻在碰撞和评审里被用到、被撞到、被修正。地基不是一次浇筑的，是被反复踩出来的。
所以呢：本周就干一件事——挑一条跨线联动最难受的产品线，写一份 30 行以内的实体+枚举清单当跨线共享地基，然后在评审环节加一条硬检查："本 PRD 出现的领域名词，是否全部能在本体里找到？找不到的要么加进去，要么改名。" 这一条就把没地基变成了有强制执行点的地基。
他们怎么做的：他展示的 OWL 错误清单全是用自然语言 prompt 很难可靠拦住、但用形式化约束一撞就报错的东西：同一笔订单第二次退款（functional property，"只能有一个"）；打款发给客服而不是买家（disjoint property，把 customer 和 support rep 定义成互不相交的实体）；状态值被编成"probably shipped"（枚举必须是 paid / shipped / refunded，别的都不行）。他原话：「ontology 能抓出来，用英文自然语言来做这件事就非常棘手」→ 详细、「当你身处纯文本的世界里时，这事就会变得很离谱，因为 LLM 本质上是概率性的」→ 详细。整套架构他浓缩成一句：「Pydantic at the door, ontology at the ledger」——入口校验类型，记账层校验语义→ 详细。
你可以怎么做：你的碰撞协议"纪律靠自觉、缺强制执行点"，症状八成是——规则写在 agent 定义的提示词里，靠 agent 自觉，遇上长上下文就漂了。照他的分层改：门口那层（独立初稿→碰撞、合成定稿→写 PRD 这些交接）用 Pydantic 式的结构校验——产出必须是带 schema 的结构化对象，字段缺了、枚举越界了直接 fail，不进入下一步；记账那层（PRD 定稿送真人评审前的终检）用本体校验器——检查"这份 PRD 里声明的状态流转，是否有本体里不存在的状态""同一个实体在不同章节是否被赋了互斥的属性"。这不需要真的跑 OWL reasoner，一个读 YAML 本体的 Python 校验脚本就是你的 reasoner。关键是他那条工程纪律：「你的 agent 应该尽量没有副作用……要先让它过一遍 ontology，确认没问题」→ 详细——即 agent 的产出先落到暂存区，过检才写进正式产物目录。
更深一层（镜子）：这场演讲其实在照你的一面镜子——你的 PRD 工厂目前是"用 LLM 检查 LLM"，三驾马车碰撞也是 agent 在读 agent。而讲者的整个立论是：概率的东西不能给概率的东西当护栏，必须有一层"确定性的、机器可判定的、跟 LLM 无关的"东西垫底→ 详细。你缺的那个"强制执行点"，本质上就是整条链路里第一个不需要模型也能判对错的地方。有它，agent 产出才谈得上可观测/可验证（"本次跑批被本体拦下 7 处枚举越界"是证据，"评审 agent 说质量不错"不是）。
所以呢：给 PRD 定稿送真人评审前加一个不调用任何模型的 validate_prd.py，输入 PRD 的结构化产物 + 本体 YAML，输出违规清单。它拦下的第一条错误，就是你"agent 产出可验证"的第一行证据。
他们怎么做的：他拆了 Claude agent 的 while True 循环：LLM 只能配参数不能执行（"我被锁在这个盒子里"）→ 看 stop_reason 是不是 tool use → 执行 tool → 标红的那一步：把 tool 返回的信息交给基于本体的 validator，判断合不合理 → 合理就往下，不合理就回退给 LLM 或引入 human in the loop→ 详细。他还点名了 agent 循环的三个具体风险：死循环、agent 互相对话导致的 drift（跑偏）、以及 token 数随循环飙升的成本→ 详细。
你可以怎么做：你的 7-Agent 造 App 链路已经有一个"强制契约"的成功经验——设计稿。把同样的招式复制到语义层：给每个 app 建一份极小的领域本体（这个 app 有哪些实体、哪些状态、状态之间允许怎么流转），让 Figma / Chrome / Notion 三条 MCP 链路的产出都对同一份本体做校验。设计稿约束的是"长什么样"，本体约束的是"说的是不是同一件事"——你现在缺的是后者。至于"把'该做什么'前移到 agent"这个痛点，本体正好是那个前移的载体：agent 读本体就知道这个 app 还缺哪些实体没实现，不用你每次口述。
更深一层（成本视角）：他把 token 成本明确列为循环的风险之一。你的 9+1 Agent 链路每多一轮"agent 之间互相纠错"，成本是实打实的。本体校验的经济学优势在于：它是零 token 的——一次确定性检查替掉一整轮"让另一个 agent 复读一遍看看对不对"。对一人公司来说，这不是工程洁癖，是杠杆：用一次性写好的规则，换掉每次都要付钱的推理。
所以呢：下一个 app 开工时，第一份产物不是原型也不是 PRD，是一页 domain.yaml；让 7 个 agent 都读它，并在链路末端跑一次零 token 的校验。
他们怎么做的：RDFS 的 domain/range 能从"Bob teaches Scooter"一句话自动推出"Bob 是 teacher、是 person，Scooter 是 student"→ 详细；OWL 的 transitive property 能从"Sue 是 Mary 的祖先、Mary 是 Ann 的祖先"推出"Sue 是 Ann 的祖先"→ 详细；functional property 能发现"Bob 和 BB 其实是同一个人"→ 详细。而且他强调这些规则不在图里，是搭在图旁边的——数据归数据，规则归规则→ 详细。
你可以怎么做：你的宪法里那些原则——"判断力 > 努力""问该不该做先于做多快""每周留一天思考""长远眼光 ≥ 短暂利益"——现在全是自然语言，只能靠软教练去"体会"，这正是你说的"软教练质量"和"跨域守门"上不去的原因。挑出能形式化的那几条：比如"每周留一天思考"是可判定的（本周日程里有没有一整块无会议时间，是/否）；"精力是元约束"可以变成 functional-property 式的硬约束（同一时间段只能有一个 active 主线项目，出现第二个就报冲突，就像"只能有一个父亲"）。剩下那些真的需要判断力的（比如"这是不是一个好的编码下注"）就老老实实交给对话，别硬编。分清哪些是 ledger（可判定的账），哪些是 judgment（需要人的判断）——这个划分本身就是这场演讲给你的礼物。
更深一层（冲突点）：讲者的立场和你的宪法有一处张力值得记下来。他说幻觉是 feature 不是 bug，"我们人类也一样，想象出并不存在的东西，然后把它们变成现实"→ 详细。而你的宪法整体偏"约束、守门、别乱来"。他的答案不是二选一，是分层：护栏放在执行与记账层，想象力放在生成层。所以你的 Chief of Staff 不该在你想点子的时候就跳出来引用原则——它应该在你准备把资源投下去的那一刻才拦。守门要守在账本前，不是守在脑子前。
所以呢：把宪法拆成两个文件——rules.yaml（机器可判定的硬约束，季度回望时自动出违规清单）和 principles.md（需要对话的软原则）。守门只查前者。
他们怎么做的：一位从业 30–35 年的 Berkeley 教师，站在 AI Engineer 大会上（现场 5,000 人）说了一个逆流的判断：「某种意义上，我们其实是在重访符号 AI 的早期成果。我认为我们正在回到专家系统的世界。」→ 详细 并给出可执行方案：Pydantic 把门 + ontology 记账 + agent 无副作用→ 详细。
你可以怎么做：这条天然是验证体选题，而且过得了你的弹药库闸门——因为可抄物、我的实测数据、我的判断三样都能凑齐。标题方向：「伯克利教了 30 年的老师说 agent 该配'本体'，我给自己公司的 9 个 AI 员工加了一层，拦下了 N 处胡说」。可抄物：那份 30 行的 domain.yaml 模板 + 零 token 校验脚本，读者直接拿走能用。我的实测：跑一轮 PRD 工厂或造 App 链路，记下"加本体前 vs 加本体后"的返工次数和 token 花费——这正好同时喂饱你的两个支柱：AI 员工管理成本账 + 大佬说 X 我试了。我的判断：删掉我的实测数字这篇还成不成立？不成立——因为核心结论"这层校验值不值得加"只有跑过的人才知道。闸门通过。
更深一层（Twitter 侧）：Twitter 那条管线吃的是过程。这个题目的过程感很强：本体建到第几个实体开始产生价值、第一条被拦下的错误长什么样、哪些约束写了之后反而添乱（这条最值钱，因为它是"翻车"素材，而翻车正是你这个号的人设承诺）。
所以呢：把它排进 Phase 0 存稿的验证体名额，先做实测再写稿——没有那组"加之前 / 加之后"的数字就别发，那是这篇唯一不可替代的东西。
他们怎么做的：他强调别重造轮子——schema.org（通用术语与关系）、FOAF（社交网络建模）、Dublin Core（描述论文与书籍的术语标准）已经做了 15–20 年，Wikipedia 底下就是 DBpedia 这个本体，你每次搜索其实是在查一个巨大的图数据库→ 详细。而图数据库之所以取代表格，是因为"往关系型数据库加东西要加新列，然后整个结构得重做；图数据库你直接挂一个新条目上去就行"→ 详细。
你可以怎么做：你的"主题骨架 → 原子笔记"结构本质就是一个手工本体，痛点"跨主题串联"其实就是关系没有被显式写下来——你有节点，没有带类型的边。最小改动：给笔记之间的链接加一个类型词（支持 / 反驳 / 是……的实例 / 属于……主题 / 来自……人物），这一步就把一堆散链接变成可推理的图。摄入 SOP 和信噪比的问题同理：给"这条内容值不值得进库"定一份枚举（相关项目 / 相关主题 / 无关但有趣 / 无关），别让判断每次都重新发明——这正是你 wiifm 档案里那条"红线：宁可空不要凑"的形式化版本，它已经是一条本体约束了，只是写成了自然语言。
更深一层：他那句"用上现成的本体对你更有利"，对第二大脑的含义是——别为你的九大主题从零发明分类体系。你已经有一份现成的、验证过的本体了，就是你 2021 年那三条产品价值观和那套操作系统。把它们当作顶层类目，新笔记往下挂，比再造一套标签体系强。
所以呢：下次整理时只做一件事——给链接加类型。节点你已经有了，缺的是边上的那个词。
他们怎么做的：本体 = 实体 + 关系 + 属性，配上"必须取某些特定值"的枚举约束，防止系统里出现"probably shipped"这种编造值→ 详细。
你可以怎么做：StockHelp 的 Phase 2/3 要做信号，最大的坑就是信号语义含糊。现在（Phase 1，只看数据的阶段）就把本体定死：实体（公司 / 行业 / watchlist / 估值快照）、属性（PE、5 年分位、基本面比率、target_pe、EPS、公允价）、以及枚举——估值状态只能是"显著低估 / 低估 / 合理 / 高估"，绝不允许出现自由文本。这样 Phase 2 接信号、Phase 3 接通知时，规则可以直接写在枚举上，而不是每次去解析一段描述。顺带解决"看板该显示什么信号"这个问题：信号 = 枚举值发生跃迁的那一刻（从"合理"跌进"低估"），不是数字本身在动。
更深一层（投资视角）：这场里藏着一段对价值投资者有用的技术史。八十年代符号 AI 融资狂热、几百万美元砸进去、日本举国搞"未来世界"项目，结局是 scale 不了 + AI 寒冬→ 详细；神经网络同样六十年代就有、同样 scale 不了，但它等来了 Nvidia 造 GPU 这个外生红利才翻身→ 详细。给你的启示是一条可以写进能力圈判断的问题：这家公司的瓶颈，是等得来外生红利的那种，还是等不来的那种？ 同样"暂时不 work"，一个变成了 Nvidia 的十年，一个变成了寒冬。这也顺手解释了为什么讲者能在 2025 年的会场说"我们正在回到专家系统的世界"——技术不死，只是等硬件。
所以呢：Phase 1 的收尾工作里加一条——把估值状态从计算结果里独立出来，定义成一个四值枚举字段。信号功能就有地方长了。