NOTES / FROM THE CORPUS

StandMeet 笔记

StandMeet 的公开设计笔记:产品动机、架构、关键设计与取舍。内容直接取自作者的 StandMeet 语料 wiki。

StandMeet 的核心,是一套面向受众做定制化自我介绍的基础设施:

对任何携带多面信息的人——或事物——而言,它都能为每一位需要了解它的受众,提供一份量身定制的介绍。

不只是人。一家公司对投资人、求职者、路人展示的是不同的面貌。一款产品对贡献者、维护者、用户、投资人展示的也是不同的面貌。结构每次都一样:一个实体,多个受众,每个受众需要的切片各不相同。

一个实体所承载的知识、所涉及的面向,远多于任何一位对话者所需要的。所以别人了解你的渠道不可能是一刀切的——它必须按受众定制,而这种定制需要居中的智能:要么你每次都亲自重新介绍自己一遍(不可扩展——见 dont-repeat-myself),要么你在中间放一个了解你全部语料的 agent,让它把相关的那一片提供给每一位提问者。

这就是名字的由来——StandMeet:一个代替你去见人的替身(stand-in)。见面、介绍、回答——全部由它按照桌子对面坐的是谁来定制完成——这样你就不必亲自到场、反复重复自己。

具体到一个人身上:这是一面能被 AI 读取、用你自己的声音与他人对话的镜像——一个可查询、按角色区分的个人真相层(personal truth layer),服务于这样一个世界:人们越来越多地是去问 AI 关于你的事,而不是直接来问你。招聘只是这套基础设施上当前的一项功能,不是产品本身。

本节内容

全部笔记

  1. 架构每根支柱都是 key-designs 下的一个节点,承载着它的组件、代码路径、状态和设计页面:
  2. 易混术语——形似而实异的术语本系统中容易混淆的词汇冲突,逐一精确拆分。文档里出现这些词却没加限定时,来这里对照。
  3. 部署——自托管、单租户StandMeet 以自托管、单租户、单机的形态部署。这是产品本身要求的形态,不是留待日后修补的局限——代码里没有水平扩展能力,恰恰是架构正确的证据,而不是技术债。
  4. 关键设计这些是非显而易见的、承重级的设计决策,组织成七个支柱节点(每个都是一个文件夹,设计页面作为其子页面)。贯穿全局的主线:StandMeet 正在成为一个可插拔平台——一个精简的内核(底座)加上插件——这是 harness-is-the-os-of-the-intent-stack 的操作系统式框架(内核 = 构成性的、…
  5. 第六支柱 · 访问控制(阀门)谁能看到什么、能做什么——这是测试最重的一根支柱(acl-* 端到端测试矩阵)。入口通过访问码(access code,即邀请码、二维码);访问码针对某个角色签发,该角色的 RoleSnapshot 在签发时冻结(会话内规则不再漂移)。授权由三层的纯 AND 收窄组合而成——global(实时)∧ role(冻结)∧…
  6. 访问控制 — 图表覆盖度该支柱的类图分散在各自所属的设计页面上;本页是覆盖率关卡。
  7. ACL 与配额粒度符号约定:
  8. BYOAI 浏览器端密钥库访问者自己的密钥在浏览器端具备抗 XSS 能力:一个不可导出的 AES-GCM CryptoKey 存放在 IndexedDB 中(JS 可以调用加密/解密,但永远读不到其原始字节),而该密钥的密文信封存放在 localStorage 中。必须同时攻破这两个存储才能窃取密钥——单独转储其中任何一个都毫无用处(app/…
  9. BYOAI 密钥信封访客自己的模型密钥(BYOAI)从不接触服务端存储或 Redis。浏览器持有该密钥,并在每次请求中通过 X-Byoai-Key 头把它封装起来:AES-256-GCM,对称密钥由 HKDF-SHA256(session_token) 派生——因此唯一的共享秘密就是 session token,不引入任何新的服务端秘密…
  10. 带码落地 /c/<slug> 与轮换 code 字符串触发问题。 简历 PDF(resume-composer-one-renderer)在二维码里印的是 <public_url>/?code=<code>。这是 URL 里的凭据:它会进浏览器历史、进每个跨源子资源的 Referer、进截图。而且 code 是整体泄露的——招聘者会转发 PDF。2026-09-06 之…
  11. 所有者密钥对认证(Ed25519 Sigv1)owner MCP handle(/mcp/*)对每一个 HTTP 请求都要求有效的 Sigv1 签名——旧的 Bearer PAT 在密钥对认证取代 PAT 时被移除(routes/mcphandle/server.go)。
  12. Owner 会话与滥用控制:没人写文档的小阀门大阀门都有自己的页——三层 ACL(access-control list,acl-and-quota-granularity)、Sigv1(owner-keypair-auth)、embed JWT(JSON Web Token,embed-credential-never-carries-the-code)。这一…
  13. RoleSnapshot 在会话签发时冻结会话签发时,整个角色状态(corpus URI、prompt 正文、skill prompts、允许的工具、拒绝的 capability、拒绝的语料 glob、waypoints、按 capability 的配置、角色 id/name)会被快照进 Redis 里的 session_data;此后该会话再也不会读取角色…
  14. 通过工具调用 _meta 传递可信身份会话的可信身份——OwnerID、Subject{Kind, ID}(一张 access code 或一把出站 key;2026-08-20 之前叫 CodeID,162f09833 改名,让 key 路径的会话也有 subject、配额才有东西可计)、RoleID,以及冻结的语料 ACL 作用域(CorpusSco…
  15. 支柱五·Agent 核心(主循环)解读引擎——产品论题(同一语料库,按受众分层呈现)在这里执行。inference(backend/internal/conversation/inference/)包裹了 CloudWego 的 eino ADK 循环(Anthropic → 原生 Messages API;Gemini → 自己的适配器;其余所有供…
  16. Agent 作为可注入的 DriverAgent core = 借助 Bridge/Driver 模式实现的、可独立启动的模块。
  17. Agent 核心:图表覆盖情况该模块的类图分别放在各自归属的设计页面上;这一页是覆盖度关卡——记录哪些部分已经画过图、哪些还没有。
  18. Turn 与客户端解耦,完成时才持久化agent turn 运行在 context.WithoutCancel 之上——客户端断开连接(刷新页面/关闭页面)不会取消它;流会跑完并落库(只有 WithTimeout 才会给它设上限)。事件流被 tee 到一个展示端(display sink)和一个累积器(accumulator)两处,持久化钩子在 done…
  19. 入口无关的 Agent(内向/外向对称)agent 对入口是无关的:各个入口只是消费者,它们负责填充一个中立的会话上下文,然后调用 agent。
  20. Eval-harness 复用生产环路Eval-harness 只导入公开的 agentcore facade(从不导入 internal/),并运行与生产环境逐字节相同的 agent 循环——这样在 eval 中发现的 bug 就是真实存在的 bug,而不是重新实现造成的假象。Fixture 作为合法的替代数据源注入,而不是 mock(它们满足的是与 …
  21. 在终止性错误时强制给出最终答案如果 agent 循环以错误告终,且没有产生任何 assistant 文本(比如达到最大迭代次数、幻觉出不存在的工具名等),系统不会把错误直接抛给访客,而是再多发起一次不带工具的 LLM 调用,让模型基于已有的信息给出回答——保持人设,而不是一句罐头式的兜底话(backend/internal/conversatio…
  22. 幽灵引导——一条建议消息,弯转对话方向Owner 希望访客对话向按角色设定的目的地收敛(查看某个项目、理解差异化、预约一次通话)——但议程是访客自己的,不存在硬控制。唯一可用的工具是一条建议通道:幽灵消息(ghost message)。这是 steering-without-control 的一个实例:一个场,而不是一道围栏。
  23. 系统提示词哈希回归检测组装好的系统提示词会做 SHA-256 哈希;一个不变量检查会把它构建 3 次,并断言哈希值完全一致(backend/internal/capabilities/capreg/system_prompt.go——Registry.SystemPromptHash,经 routes/sys/diag_session.g…
  24. 无缓冲 SSE 直通/api/v1/agent/turn 这个 Next 路由不走 next.config 的 rewrites——因为 rewrites 会把上游的 SSE 整个缓冲住,浏览器只会在最后一次性收到全部帧,实时的转圈提示("searching → reading X")也就永远渲染不出来。所以这个路由改为把上游的 Rea…
  25. 支柱二 · 能力(它们说 MCP)agent 的双手,以插件的形式组织在 MCP 标准之上(原样照搬——没有私有协议)。capreg 是注册表:确定性的装配顺序(system-prompt 的哈希依赖于它)、EnableGate,以及暴露公式 exists ∧ owner_enabled ∧ connector_deps_met ∧ role_acl…
  26. 能力(Capabilities)——图表覆盖(组装侧 vs 消费侧)与 connector-diagram-coverage 采用同样的双侧切法:组装侧(能力如何按会话注册并暴露出来)与消费侧(loop 实际持有什么)。插件加载相关的类型放在 mcp-capability-plugins;skills runner 的类型放在 skills-progressive-disclosur…
  27. 能力自己声明配额、配置和存储mcp-capability-plugins 讲的是:一个内建能力 = 一份 manifest + 一个跑在沙箱里的 MCP 进程。这一页讲的是宿主过去为每个能力手写的那部分:一张邀请码能用它几次、owner 能调哪些设置、它的行存在哪、它能向宿主要什么。现在这些都是能力自己 manifest.yaml 里的声明,由…
  28. capsocket——一个能力一条窄 socket沙箱化的内置插件(summarize / retrieval / booker / mail-sender;ask-visitor 同样在沙箱里,但没有声明任何 host op,所以根本没有 socket)在网络隔离(--unshare-net)下运行,通过每个能力一条 unix socket(/run/standm…
  29. 功能底线约束外部化迁移的契约——把某个 capability 从核心中迁出时,不得丢失以下任何一项横切行为。底线项目(每一项都有既有 spec 支撑):
  30. MCP 能力插件本页是能力平面——StandMeet 作为 MCP 宿主(参见 confusables)。指 agent 的外部工具/技能(retrieval、booker、summarize、ask_visitor,加上所有者注册的 ext-mcp)。已经是插件形态——两条插件轴线之一(另一条是 connector-plugins…
  31. Skills:三层渐进式披露一个 skill 不是每个脚本配一个工具的做法(那样会让工具列表爆炸,把系统提示词撑得臃肿)——skill 也不是一种 capability:它是骑在 capability 之上的一个被创作出来的产物(confusables)。取而代之的是三个层级:
  32. ui:// MCP-Apps 卡片聊天里每个工具的交互卡片,以 MCP-Apps 的 ui:// 资源形式下发,渲染在一个通过 postMessage 与宿主通信的沙箱 iframe 里。所有单工具卡片都已迁移完毕——ask_visitor、corpus_search/list、summarize、日历相关工具,甚至 calendar_book(通过…
  33. 支柱三 · Connector(带凭证的边缘)每一次带凭证的对外接触都要经过同一层:connector.Hub + 分类插槽(category slots)。消费方(agent 能力、平台功能、IM 桥;job-loop 至今仍不是消费方)看到的是固定的分类契约(CalendarProxy、MailProxy —— backend/internal/connec…
  34. 连接器依赖——Requires,fail-closed 解析这是 capabilities 支柱与 connector 支柱之间的正式接口——设计上就是 fail-closed 且不关心消费者身份的。插件清单声明 Requires: ["calendar", "smtp"]——这些是应用内依赖提供方的名字,每一个都由某个连接器类别背书。capreg/depresolver.g…
  35. 连接器 — 图示覆盖(注册侧 vs 调用侧)连接器模块是共享一个包的两套设计:注册侧(连接器如何被安装、授予凭据、激活)和调用侧(消费者如何在完全看不到提供方或凭据的情况下调用一个类别动词)。用一张图恰好会模糊掉这个模块存在的意义所系的那条边界——所以,画两张。
  36. 连接器出口防护(SSRF 防御)一旦 owner 可以上传任意的 OpenAPI connector,目标 URL 就变成了攻击者可控的——这是典型的 SSRF 攻击面(把它指向 169.254.169.254 或某个内部服务)。防御分两层:
  37. Connector 插件——可安装、消费方无关Connector 不是 MCP——它讲的是分类契约(category contract),而不是 MCP 的线协议;这两条插件轴仅在 connector-deps(confusables,含 action 与 sync 模式的区分)处相交。
  38. 幂等预订,只写重试Calendar 的 events.insert 并非幂等:如果连接在 Google 已经创建好事件、但响应还没送达之前断开,盲目重试就会造成重复预订。因此幂等键在任何重试循环开始之前只生成一次,并在 401 刷新 + 重试的整个周期内复用;写入重试策略只重试发送前的传输错误,绝不重试 5xx(5xx 可能服务端已经…
  39. 支柱一·语料库(资产)这是主理人的知识库——护城河所在。一张表 corpus_notes,带一列 genre(raw / wiki / output / subjectivity / writing)——三层仍然是 raw→wiki→output(与 Obsidian vault 的 raw→wiki→output 同构),但原来分开的 …
  40. 反向链接即重建的边表[[X]] 原样存在正文里(存储时从不改写)。每次保存时,代码会提取全部 [[X]],把它们解析成 id,然后先删掉全部出边、再插入新的一整套(note_refs / writing_refs——note_refs 在 2026-07-06 之前叫 wiki_refs,4fc769d61;两张表现在都指向 corpu…
  41. 语料库 — 图表覆盖情况这个支柱的类图分散在各自所属的设计页面上;本页是覆盖率关卡。
  42. 语料检索——走图,而不只是走树现状(已落地): corpus_search / corpus_read / corpus_list / corpus_links / corpus_grep / corpus_map / corpus_peek / corpus_resolve —— 八个工具,跑在 Meilisearch 词法索引之上(Postg…
  43. 派生路径——"corpus 即文件系统"corpus_notes(所有体裁——wiki / output / subjectivity,自 d925d9081(2026-07-09)起 raw 也在内)有一棵基于 parent_id 自引用的树,但没有 path 这一列。地址是运行时现算出来的:沿父链一路把标题 slug 拼接起来(usecase.Wiki…
  44. 全局素材池——一个存储,引用记账触发问题。 2026-09-05 之前,素材属于它的 holder——storage_key = <holder_id>/<asset_id>,"删 holder → 同事务删它的素材"(那段旧注释还留在表上方,backend/db/schema.sql:560-578)。这个形状让复用不可能(第二条想用同一张图的条…
  45. Obsidian 同步机制StandMeet 与 Obsidian vault 之间的双向同步。形态类似 Quartz / obsidian-importer:两个按钮,各自对应一个批处理任务,由所有者手动触发——没有文件监听,没有实时同步。
  46. 协议——frontmatter 字段来源契约对每一个字段,都问两个问题:它的值到底从哪里来,以及谁会读它——Obsidian、StandMeet、两者都读,还是都不读。凡是来源比"你手动敲进去"更可信的字段(文件名、系统时间、正文本身、导入器),就不该出现在模板里。已逐字段对照 buildSaveInputFromVault(import.go:286)核实过…
  47. 同步笔记的渲染与可扩展性StandMeet 如何支撑它所同步的笔记的呈现 / 可扩展层(定理式 callout、数学公式、图表、动态组件)——这是已经定型的设计。
  48. Vault 导入:单一 vault 与忽略规则StandMeet 的账户以单一 Obsidian vault作为其实时数据源——方案 A。另外两个方案先搁置:
  49. 渲染引擎StandMeet 的 markdown 管道在聊天回答、wiki/output 页面和 writings 中渲染富内容(app/src/components/page/markdown.tsx):remark-gfm + remark-math + rehype-katex + 一个 MermaidBlock 代码…
  50. KaTeX(数学公式)数学公式渲染。StandMeet 侧:remark-math → rehype-katex(katex ^0.16)。Obsidian 侧:MathJax。
  51. Mermaid(图表)基于文本的图表。Obsidian:内置支持。StandMeet:一个 code 组件的重写逻辑检测到 mermaid(isMermaidCode / mermaidSource,app/src/components/page/markdown-helpers.ts:5),交给一个懒加载的 MermaidBlock 渲…
  52. TikZ(精确数学图形)— 已上线补上 mermaid 补不了的缺口:精确的数学图形——几何作图、交换图、带坐标/标签的方框、函数曲线。一个 ```tikz 代码块渲成 SVG,reader 上已经在跑。
  53. 三层语料库:晋升制raw → wiki → output:草稿 → 精选 → 打磨。条目是被晋升的,不是被复制的——自从三层折进一张 corpus_notes 表(d925d9081,2026-07-09),来源关系归成一列 source_ids(上游 id:wiki←raw、output←wiki——原来的 source_raw_i…
  54. Writings 与 vault:Obsidian 导入导出子系统目前(已落地): 手动的、由所有者触发的批量架构。GET /api/admin/obsidian/export 流式输出一个 standmeet-vault.zip(不落临时文件);POST /api/admin/obsidian/import 接受整个 vault 的 multipart 上传(浏览器端 webki…
  55. StandMeet × 八种控制方法若把 StandMeet 看作一部控制论机器,它就是一套控制装置:消灭一个随机 LLM 的多样性,并将其收敛到唯一目标 G = "像 owner 本人那样作答——有依据、安全、保持其语气。" 对照八种控制方法(control-methods):
  56. Embed 凭据永不携带 code触发问题。 <standmeet-chat> widget 跑在一个 StandMeet 管不到的站上,而它的会话必须落到一张 access code 上——code 才是承载 role → 语料 ACL + 能力的东西(今天由 embed-widget-carries-code-capabilities.spec.…
  57. Microsite:owner 自己写、实例负责构建与托管的页面实例根路径是保留 slug home(HomepageSlug,owner/usecase/microsite.go:34;2026-09-04 的 a5e1cada9,模板 77aee7dc6)。应用中间件探测 GET /api/v1/homepage,有 live 的 home 构建时把 / 重写过去(app/s…
  58. 支柱四·监控(最薄的支柱)对运行中系统的调用时遥测(telemetry):这是宿主的第二个横切控制器,与 ACL 在时机上不同——ACL 作用于会话建立阶段(通过"未被发现"、capreg 里的 ErrHidden);监控则作用于调用时。在调用路径上内联生效的只有监控和 secret-scan(设计文档点名的 secret-scan 截至 2…
  59. 产品自主升级——实例原地重建自己触发问题。 镜像式的栈里 backend 刻意不挂 docker.sock(deployment)——它拉不动镜像,也重建不了自己的容器。2026-09-04 之前,按钮向 owner 自己给的一个不透明 URL 发请求(STANDMEET_REDEPLOY_HOOK),把部署知识推进了产品、也推给了 owner 的…
  60. 简历 composer:一个渲染器画画布也画 PDF触发问题。 简历是 chain-hiring 的出站那一半:PDF 上印着一个 QR(quick-response)码,它的 URL 让招聘者凭 access code 进门(access-control)。招聘者评判的是 PDF,从来不是编辑器。Typst 画 PDF、React 画画布的时候,每条排版规则都存在两…
  61. service handle(StandMeet 作为 MCP 服务器)不是支柱——是对外的一面。 这个节点特意与 capabilities 分开,因为这两者是系统里最容易混淆的一对概念(confusables):capabilities 是capability plane(能力平面)——我们的 agent 以 MCP host(宿主)身份消费工具;这个节点是service handle…
  62. as-MCP 门面本页讲的是 service handle——StandMeet 作为 MCP 服务端(对外的一面),而不是我们自己的 agent 以 host 身份消费插件的那个 capability 平面——参见 confusables。
  63. UI—MCP 对等:UI 能做的,handle 都能做每一个能通过管理 UI 触达的 owner 操作,也必须能通过 service handle(StandMeet-as-MCP-server)触达——这样 owner 的 AI 会话就永远不会沦为浏览器的二等公民。例外必须是显式的,绝不能是意外产生的。
  64. 支柱七·结构与纪律(地基)其余六根支柱立足的地面。代码形态:Go 按领域打包(internal/<domain>/{entity,usecase,repo,db,ops,facade} —— 按层切的 domain → usecases → routes 上帝包已于 2026-07-27 拆解,见 backend-domain-modules…
  65. 红不了的闸门不是闸门infra/scripts/ 下五十五个 check-* 条目(2026-09-07 数的)里有十个只干一件事:攻击另外四十五个。它们共同的开头就是那条学说 —— 一个从没红过的闸门不是闸门。
  66. 后端领域模块——按领域组织后端曾经(到 2026-07-27 为止)是按层打包的,而不是按领域打包的。这是一整类纠缠问题背后的根本技术债(比如 connector 为了自己的概念去导入 capabilities 的上帝包;一个 kernel 本不该持有的带类型 category 表面)。本节点定下的目标是:按领域打包——每个领域拥有自己完整的…
  67. 构建器:一个独立的、认领任务的服务Microsite(改名前叫"自定义页面",e7fe80e91,2026-09-05)的构建跑在一个独立的构建器服务里,而不是主应用中——这样 API 进程就永远不需要 docker.sock 或 vite。构建器(builder/runner.mjs)对 /internal/builds/claim 长轮询,用 S…
  68. 两个收口——出站与入站后端最深的那个结构性想法,而它一直没有笔记。一个能力能做什么、以及它能反过来向宿主要什么,各自只从一个地方过——而且两者都由闸门守着,不靠评审。
  69. 展示错误:统一信封,日志与客户端分离抵达用户的错误都被包进同一种信封结构;错误的根因单独记录在日志里审计,绝不暴露给客户端。
  70. 每个领域:内部 DDD 分层 + 一层薄的对外 facadeinternal/<domain>/ 下的各个领域没有对外暴露的门面层。要使用一个领域,你得把整个目录读一遍才能找到它的方法——没有一个单一的地方能说清楚"这个领域提供了什么"。领域内部的文件也没有按 DDD 角色分类(entity / usecase / service / repo / infra 混在一起)。
  71. 短暂与仅追加优先于有状态存储代码库中反复出现的一种品味:能派生或追加的可变状态,就不要保留。
  72. 外置就要彻底外置一个被外置的能力,必须连它自己的存储一起带走。 如果内核还攥着那张表,那这个能力只是换了个地址,不是被外置了 —— 而"更整洁的地址"能通过每一道闸门,同时什么都没改变。
  73. 门面的方向——两个信任平面facade-parity 让每一个门面都成为唯一那份注册表的投影。但那个模型没有方向这根轴 —— 它的基础 reach 只有 OwnerRead() / OwnerAction(),接的也就两个门面,两个都朝向 owner。这一篇补上缺的那根轴;而"为什么必须在任何对外门面碰这套机制之前补",值得说白:
  74. 门面对等一份注册表;每一个门面要么由它生成、要么对着它校验。 绝不允许同一个能力有第二份手写的描述。
  75. 判断力审查——超越 lint 的纪律分工: lint / 类型检查 / 测试守的是机械正确性(mechanical-guardrails);审查指南守的是判断质量——"机械正确 ≠ 架构干净"。这是一份自我演化的文档;第一轮审查产出了发现 1–9 并触发了一次重构。
  76. 机械护栏把"用机械约束取代社会性争论"做成实体。它已经从几个 linter 长成了 infra/scripts/ 下的 55 个 check-* 条目 —— 45 道守卫加 10 道自检(2026-09-07 数的),全部挂在同一个 make lint 后面(最快的检查排在最前)。make lint 由 CI 和 pre-p…
  77. 每个界面原语只有一个源头十二道闸门,一条学说:每一个视觉原语只有一份定义,再由一道构建期闸门让第二份不可能存在。 这个产品的视觉一致性真正来自这里 —— 不来自风格指南,也不来自评审。
  78. 落地顺序:被依赖的先走一条落地顺序的规则,同时也是一条关于谁来定这个顺序的规则。
  79. Owner MCP facade = 在两个容器上做通用的发现与调用owner 的 agent(owner 自己的 MCP 客户端 / Claude Code)必须以和访客 agent 完全相同的通用方式 去触达各种能力:从容器里发现,按名字调用。不允许为每个能力单独写 host 代码。
  80. Owner 脚本沙箱加固Owner 编写的 skill 脚本(skill_run_script,见 skills-progressive-disclosure)是不可信的,因此运行在强隔离的沙箱中:--network=none(无法外传数据)、--read-only 根文件系统(无法持久化)、--tmpfs /tmp 限量的临时空间(64 …
  81. 结构 — 图表覆盖度这个支柱的类图分别放在各自所属的设计页面上;本页是覆盖率检查页。
  82. Subjectivity 记录笔记:一个 ACL 粒度问题(原名为 "Subjectivity owner-visibility (gate-one tightening)"——现改名,因为"owner"从一开始就是错误的框架。owner 的可见性没有任何变化:整个语料库本来就是属主的。真正会变化的是访客能否读到某条记录笔记,而这就是普通的 ACL 问题。)
  83. 产品它是为了什么、它是什么,以及它的边界划在哪里。
  84. 边界——它不是什么StandMeet 不是一个求职工具。 招聘显然是它的一种应用场景(招聘者先预读,再问出更好的追问),但创始人自己的使用排在第一位——外部大脑、起草、表达、综合、筛选。(founder-product-fit)
  85. 设计原则(哲学一致性)每一个设计选择都能追溯到一个明确表达的立场——内部一致性是硬性要求,不是装饰。
  86. 差异化相对于输入类工具(Notion / Glasp / Readwise)。 它们解决的是输入问题——高亮标注、做笔记、写日记。它们并不解决由他人以你的声音进行检索这件事。Notion 页面是访客必须逐字阅读的一段文字;StandMeet 的检索是对话式的——访客提出一个具体问题,得到一个具体答案。
  87. 产品简介StandMeet 把压缩过程反过来做。你先建好一个知识库,记录你是谁、你真正做过什么;然后你自己——或者来访者——对它发起查询,AI 会用你的口吻作答,答案扎根于你自己说过的话,并带有引用出处。这是第一个可查询、网络原生的自我呈现系统——你的个人真相层,当有人问"这个人值不值得信、合不合适"时,AI 咨询的就是它。
  88. 动机StandMeet 为什么必须存在——问题所在、最初的那个洞察、时机,以及契合度。
  89. AI 对话是思考的基底这个种子洞察来自切身经验:与 LLM 的对话,如今才是真正发生实质性思考的地方。 向 Claude 解释一个复杂的观点时,你表达得比发一条推文清楚得多——AI 会追问细节,语境允许你深入展开,对话这种形式本身就是辩证的。那份产出已经存在了——只是除你之外没有人能取用它。
  90. 别让我重复自己这是最尖锐、最具体的痛点——也是证明这个产品确实成立的最有力证据。一个善于表达的思考者,如果一遍又一遍被问同一件事,要付出很高的代价:
  91. 创始人与产品的契合Sijie 就是这款产品的目标用户——这不是一句营销说辞,而是一种架构上的优势。多年积累的 AI 对话内容就这样流失;LinkedIn 上的呈现远不能代表他;朋友想把他介绍给别人时也很难说清楚。在这个阶段,创始人与产品的契合就是这场赌注本身。
  92. 解读经济过去 25 年,互联网靠的是注意力经济——喊得响就有眼球,在 LinkedIn 上表演。现在它正在转向解读经济:整个网络被 AI 对你的判断过滤了一遍。越来越多时候,别人想知道能不能信任你,不是直接问你,而是去问一个 AI,由一个 agent 代为阅读。
  93. 有损自我呈现这个问题对网状思考者打击最重——他们的想法活在一张稠密的图里,而每一条捕获与传递的信息通道却顽固地是线性的。三重损耗叠加在一起:
  94. 生硬的提问,柔性的采集面试式的问题——"说说你曾经……的一次经历"——是生硬的:它们检索的是经历片段,而经历片段无法临时突击。冷不丁地被问,即便故事储备丰富的人也答得不好(记忆有损+表达有损,见 lossy-self-presentation);若提前一晚准备好答案,那答案就成了编造——恰恰是这款产品所反对的简历注水。
  95. 交易需要差异招聘——以及大多数高风险的初次接触——从根本上说是一场交易,而交易需要差异:一个选你而不是别人的理由。简历做的恰恰相反。它是为了让 HR 能解析而做的有损压缩——把人塞进由头衔、日期、条目组成的固定模板,正好抹掉了那些本该让人选择你的差异。你出场时,已经被预先拍平成"这个类别里的又一个候选人"。
  96. 为什么是现在三个推动因素正在同时汇聚:
  97. 论点这个循环是:user 以 agent 的方式,从一段 AI 对话里自主挑选出好的部分 → 通过 MCP 把它们推送到 StandMeet → 语料逐步积累 → 语料再服务于多种用途。
  98. 需求 → 设计(这座桥)product 与 architecture 之间缺失的中间层——产品表面如何拆解为七根支柱,双向可溯:每条承诺追到它的工程实现,每根支柱也能追回它据以成立的那条承诺。同时记录 2026 年 6 月转向之后,哪些产品文档仍然具有权威性。
  99. Chain · 显式推送——AI 对话变为一份经过策展的语料库除了主理人刻意策展并推送的内容之外,没有任何东西能进入语料库;私有的基质只有经过刻意的动作,才会变成一层持久的、面向公众的层。
  100. Chain · 招聘 —— 首个应用,而非产品本身boundaries —— 招聘是建立在基础设施之上的一个应用,明确地不是产品本身。transaction-needs-difference —— 一笔交易需要差异性;简历是把信息有损压缩成一种HR可解析的格式;StandMeet的工作是把这份差异性放回去。dont-repeat-myself —— 同一个工作故事,…
  101. Chain·解读——访客提问,语料库以你的声音作答任何人都可以提出一个具体问题,并得到一个用主人的口吻表达、有依据、带引用、并按其角色调整过框架的具体答案——一份语料库,按提问者、按每个问题分别做线性化。
  102. 链路·机器可读——当提问者是一个 agent 时interpretation-economy ——网络正从注意力经济转向解释经济(interpretation economy):"不是别人来问你,而是问一个 AI";agent 不会善意地替你补全空白,它需要的是结构化证据,否则你就会被拉平成品类均值。why-now ——MCP 是这一切得以成立的基础设施。
  103. 链条 · 所有者优先——先做外部大脑,再谈观众introduction ——"第一个用户是你自己——它是你自己思考的外部大脑;别人来查询只是第二层界面"。boundaries ——"不是一个求职工具;所有者自己的使用排在第一位"。founder-product-fit ——创始人本身就是目标用户;他自己用起来的真实摩擦,暴露的是任何人都装不出来的东西:摄入的顺手…
  104. Chain · 选择性访问 —— 谁能看到什么,在签发时冻结状态: 最深的一条链路 —— 设计已定稿,测试最重。
  105. Chain · 主权——你的基础设施,你的密钥,你的信任边界introduction ——语料库由你来整理、由你来推送,绝不抓取;附加它这个动作本身就是信任边界。design-principles ——一个架构层面的预判:个体 + AI subagent 作为所有权的基本单位。deployment ——自托管单租户是这个产品必然要求的形态。