{
  "schema_version": "3.0",
  "updated": "2026-09-01",
  "scope": "Public research dossiers and materials only. Dossiers expose questions, current views and evidence gaps; material records expose use, scope and limits. Articles and project software retain separate canonical locations. Private source inventories are never included.",
  "types": [{"id":"report","label":"研究报告","description":"行业研究、白皮书与阶段报告"},{"id":"data","label":"数据与表格","description":"数据汇总、比较表与在线图谱"},{"id":"note","label":"研究笔记","description":"阶段分析、方法与研究记录"},{"id":"reference","label":"来源索引","description":"公开来源与阅读说明"}],
  "collections": [{"id":"embodied-industry","title":"具身智能产业","summary":"从任务和交付阶段出发，再分别理解本体、技术、公司与产品。","coverage":"已有：2026 夏季版入门地图的 12 页试读，产业、灵巧操作与世界模型三份研究笔记。","notes":["robot-industry","manipulation-data","world-models"],"materials":["embodied-field-guide"],"articles":["/notes/agent-left-embodied-right/","/notes/waic-from-models-to-systems/"],"section":"research","status":"持续更新","updated_at":"2026-08-31","question":"怎样把机器人演示、技术路线和真实交付放进同一张产业地图？","current_answer":"演示、试点和持续交付是三种不同证据。产业判断应先说明机器人替谁完成什么任务，再比较形态、技术路线和公司位置。","gap":"待补：完整版公开范围、公司状态复核，以及技术路线与真实部署案例的持续更新。","findings":["同一项技术在研究原型、试点设备和规模交付中承担的证明责任不同。","自由度、模型规模和数据量不能越过任务成功率与交付条件，直接证明产品价值。"],"lead_material":"embodied-field-guide"},{"id":"home-robots","title":"家庭机器人","summary":"把任务价值、现有替代方案和失败恢复放在一起判断。","coverage":"已有：一份任务与失败恢复笔记，以及 208,755 条开放场景记录的结构汇总。原始反馈未公开。","notes":["household-robots"],"materials":["home-robots-corpus"],"articles":["/notes/home-robots-recovery-burden/","/notes/home-robots-harder-richer/","/notes/robots-give-people-new-bodies/"],"section":"research","status":"资料复核中","updated_at":"2026-08-31","question":"家庭机器人在什么任务上值得进入日常生活，失败后又由谁接管？","current_answer":"家庭任务是否成立，取决于节省的劳动是否大于部署、维护和救援成本。平台讨论能暴露任务线索，不能直接证明购买需求。","gap":"待补：按家庭角色和具体任务进行人工复核，并补充长期使用、接管频率和愿意付出成本的证据。","findings":["同一个家庭任务要同时记录执行者、受益者、接管者和维护者。","记录数不是人数，也不是独立需求；来源集中度必须与结论一起披露。"],"lead_material":"home-robots-corpus"},{"id":"ai-glasses","title":"AI 眼镜与空间交互","summary":"从使用时刻、身体负担和对象连续性判断新终端的必要性。","coverage":"已有：穿戴与空间交互两份笔记，以及 209,862 条开放场景记录的结构汇总。","notes":["wearables","spatial-computing"],"materials":["ai-glasses-corpus"],"articles":["/notes/ai-wearable-modalities-body-comfort/","/notes/spatial-computing-touch-moment/","/notes/scene-user-demand-evidence-research/"],"section":"research","status":"资料复核中","updated_at":"2026-08-31","question":"哪些时刻值得让 AI 离开手机，进入身体和空间中的新设备？","current_answer":"新设备需要同时满足高频任务、身体可接受和现有设备不便完成三个条件。组合语料可以发现场景线索，不能代替真实行为与采用证据。","gap":"待补：按设备、角色和场景复核样本，并补充持续佩戴、实际行为和付费选择的证据。","findings":["功能清单不能替代可用时刻；输入输出条件与身体阻力决定设备能否长期存在。","历史文章的产品反馈子集与组合快照不是同一分母，数字不能直接互换。"],"lead_material":"ai-glasses-corpus"},{"id":"local-ai","title":"本地 AI 与个人算力","summary":"先明确任务、隐私和持续运行条件，再计算整套使用成本。","coverage":"已有：本地 AI 与 Agent 上下文两份笔记，以及 211,088 条相关记录的结构汇总。","notes":["local-ai","agent-context"],"materials":["local-ai-corpus"],"articles":["/notes/local-ai-box-task-economics/","/notes/agent-context-recommendation-after-rag/"],"section":"research","status":"资料复核中","updated_at":"2026-08-31","question":"什么任务真的需要在本地运行，又该选择现有电脑、共享设备还是专用硬件？","current_answer":"先证明任务必须在本地持续发生，再比较性能、权限、维护和人工介入。现有电脑是默认替代方案，专用设备要证明完整工作流的增量价值。","gap":"待补：按实际工作负载比较设备，并补充非技术用户的安装、维护、失败恢复和长期使用证据。","findings":["离线运行模型不等于整个 Agent 工作流都不离开设备。","公开语料约九成来自 Reddit，适合发现问题，不代表总体市场分布。"],"lead_material":"local-ai-corpus"},{"id":"ai-video","title":"AI 视频与创作工具","summary":"把首轮生成与后续编辑分开，观察项目文件、局部修改和资产管理。","coverage":"已有：视频生产和可交互内容两份工作笔记。行业报告原稿尚未公开。","notes":["video-production","playable-content"],"materials":[],"articles":["/notes/ai-video-second-edit/","/notes/ai-native-basic-unit/","/notes/ai-apps-unbundled-before-agent-filled/"],"section":"exploration","status":"主报告整理中","updated_at":"2026-08-31","question":"生成模型怎样进入可修改、可协作、可交付的专业视频工作流？","current_answer":"首轮生成解决的是素材起点，专业交付还需要稳定的局部修改、时间线控制、版本资产和协作接口。","gap":"待补：核对本地与飞书版本，完成产品和工作流事实检查，再确定主报告公开范围。","findings":["编辑者需要保留已确认的部分，只重做其余内容。","能生成连续画面不等于形成可持续交互的世界。"],"lead_material":"video-production"},{"id":"agent-systems","title":"Agent 系统与能力计量","summary":"拆开发现、选择、执行、结果消费与价值，建立可核对的计量层级。","coverage":"已有：AgentMeasure 白皮书全文，以及上下文、软件能力、计量和研究工作流四份笔记。","notes":["agent-context","software-capabilities","agent-measurement","research-workflows"],"materials":["agent-measurement-paper"],"articles":["/notes/agentmeasure-from-spec-to-evidence/","/notes/when-the-software-consumer-becomes-an-agent/","/notes/every-agent-usage-number-is-self-reported-zh/"],"section":"research","status":"规范迭代中","updated_at":"2026-08-31","question":"Agent 真正使用软件时，应该记录哪些动作、结果和价值？","current_answer":"一次调用、一次任务、一次结果被使用和一次业务收益属于不同分母。运行时还要同时记录上下文、状态与权限，才能解释任务为什么成功或失败。","gap":"待补：真实任务基准、跨产品事件对照，以及规范字段与当前实现版本的持续校准。","findings":["工具调用成功只能证明动作发生，不能自动证明结果被采用或产生价值。","能力发现与执行权限必须分开记录，避免把可见能力误当作可用能力。"],"lead_material":"agent-measurement-paper"},{"id":"product-research","title":"产品研究与组织方法","summary":"把证据能支持的决定、责任主体和修订条件写清楚。","coverage":"已有：需求、替代方案、证据维护、硬件创新和组织责任五份方法笔记，以及公开来源索引。","notes":["demand-evidence","alternatives-entry","evidence-maintenance","hardware-innovation","organization-responsibility"],"materials":["public-reading-sources"],"articles":["/notes/scene-user-demand-evidence-research/","/notes/competitive-analysis-software-hardware/","/notes/hardware-innovation-organization-management/","/notes/appointed-manager-organizational-legitimacy/"],"section":"method","status":"方法持续修订","updated_at":"2026-08-31","question":"怎样让需求、竞品、组织和版本证据真正支持下一步决定？","current_answer":"每条证据都应写清它支持什么决定、由谁负责，以及出现什么变化时需要重新核对。","gap":"待补：更多经过授权的真实案例，以及方法在不同项目中的使用记录和失败复盘。","findings":["一条反馈只能支持与其场景、角色和行为相匹配的决定。","版本、分母和公开边界必须成为研究产物的一部分。"],"lead_material":"public-reading-sources"},{"id":"digital-making","title":"桌面数字制造","summary":"把生成设计、制造过程和质检反馈连接成一条可复核链路。","coverage":"已有：一份桌面制造工作笔记。公司与设备比较表尚未完整归档。","notes":["desktop-manufacturing"],"materials":[],"articles":["/notes/competitive-analysis-software-hardware/"],"section":"exploration","status":"材料归并中","updated_at":"2026-08-31","question":"数字设计怎样穿过材料、工艺和设备状态，变成可重复交付的实物？","current_answer":"设计文件只是输入。合格交付还要记录材料批次、工艺参数、设备状态和质检结果，并能追溯各环节。","gap":"待补：修复多维表归档缺口，核对报告版本，再决定是否发布设备与工艺比较表。","findings":["可制造性需要在设计阶段进入约束，而不是在成品失败后补救。","设备参数无法替代材料、过程和质量记录。"],"lead_material":"desktop-manufacturing"},{"id":"dji-alumni","title":"大疆系创业与产业扩散","summary":"把创业名单、共同履历和产业结果分开，逐项回到公司与产品证据。","coverage":"已有：一份公开公司图谱和一份人才与产业扩散笔记。","notes":["talent-and-industry"],"materials":["dji-company-map"],"articles":["/notes/dji-talent-whale-fall/"],"section":"research","status":"图谱复核中","updated_at":"2026-08-31","question":"人才从一家硬件公司流向新团队时，哪些能力真的发生了迁移？","current_answer":"共同履历只能说明关联，不能单独证明能力迁移、股权关系或创业成功率。研究需要继续追踪产品、供应链和组织经验如何进入新团队。","gap":"待补：逐项核对公司状态、产品变化与公开来源，并处理样本选择带来的偏差。","findings":["履历标签是查证入口，不是因果结论。","公司与产品状态会变化，图谱必须保留时间和来源。"],"lead_material":"dji-company-map"}],
  "records": [
  
    {
      "id": "report-agent-measurement-paper",
      "kind": "report",
      "slug": "agent-measurement-paper",
      "title": "如何度量 AI Agent 对软件的使用",
      "summary": "AgentMeasure 计量白皮书，解释发现、选择、使用、结果与价值的区分，以及计量口径的设计假设。",
      "url": "/knowledge/materials/agent-measurement-paper/",
      "lang": "zh-CN",
      "collections": ["agent-systems"],
      "updated": "2026-08-16",
      "version": "Whitepaper v0.2",
      "access": "全文公开",
      "source_label": "本站已公开白皮书",
      "use_for": "判断 Agent 使用软件时，哪些事件能分别证明发现、执行、结果与价值。",
      "public_scope": "白皮书全文入口；Whitepaper v0.2 / Standard Draft 0.4。",
      "boundary": "方法与规范提案，不代表行业采用或业务收益已经验证。",
      "review_status": "版本、原文入口与公开范围已核对",
      "source_page": "/notes/agent-usage-measurement-standard/",
      "study_id": null,
      "downloads": [{"label":"阅读白皮书全文","url":"/notes/agent-usage-measurement-standard/","format":"网页 · 保留原地址"}],
      "source_ids": null,
      "text": "判断 Agent 使用软件时，哪些事件能分别证明发现、执行、结果与价值。 白皮书全文入口；Whitepaper v0.2 / Standard Draft 0.4。 方法与规范提案，不代表行业采用或业务收益已经验证。 <h2 id=\"这份资料是什么\">这份资料是什么</h2> 这份白皮书讨论 Agent 使用软件时，如何分别记录能力发现、方案选择、执行操作、结果消费与业务价值。它适合用来理解计量对象和统计分母，避免把一次调用、一次任务与一次业务结果混为一谈。 全文保留在原有地址。知识库增加资料说明和专题关联，没有复制一份需要独立维护的报告正文。 怎样使用 先阅读原文中的论点、假设和术语，再根据具体任务判断需要哪一级证据。若要实现计量，应进一步核对公开项目中的当前规范，避免把历史白皮书的版本当作最新实现契约。 版本与边界 原文发表于 2026-08-16，标注 Whitepaper v0.2 / Standard Draft 0.4。研究主张与规范设计属于作者的提案，不代表行业已经采纳、实验已经验证或产品收益已经成立。 引用时保留版本号及原文地址；需要当前代码与规范时，请回到 AgentMeasure 公开仓库。 Whitepaper v0.2 · AgentMeasure Standard Draft 0.4 作者：Roy Tong（仝夏瑞） 参考实现：AgentMeasure 仓库（GitHub）。 摘要 AI Agent 越来越多地代表用户与组织选择、调用并与软件交易。当 Skill、MCP server、 API、CLI 这些接口越来越容易创建与分发时，经济价值日益向它们背后的稀缺能力集中： 专有数据、算力、执行、权限、交易与真实世界的履约。 这在产生支付问题之前，先产生了计量问题。一个能力要能被可靠地定价、比较、计费与 优化，生态必须先就”什么算选择、什么算一次操作、什么算成功交付、什么算结果被消费、 什么算结果、什么算计费单位”达成共识。 AgentMeasure 为这个正在形成的 Capability Economy 提出一套开放计量标准：Reach → Choice → Use → Utility → Value 的共同数据语言，加上未来 Metering、Marketplace 与 支付轨道可以构建其上的测量语义。目标不是仪表盘，而是让 Capability as a Service （CaaS，本文用法）成为可能的计量基础。 一、从 SaaS 到 Capability Economy 软件分发曾有一条可读的链路：下载、安装、使用。每个时代有自己的经济单元。下面描述 的转变是增量，不是替代：与 seat-based SaaS、request-based API 并存的， callable capabilities 正在成为 Agent 中介的软件消费的一种新经济单元。 SaaS 人 → 应用 → 席位 / 月 API Economy 软件 → API → 请求 / Token Capability Economy Agent → Capability → 操作 / 结果 三股力量推动向第三行迁移： 接口被 Agent 吸收。 UI 与工作流越来越多地由 Agent 执行，而不是呈现给人。软件 剩下的是一件可调用的外衣——skill 文件、MCP tool、CLI、endpoint。 分发制品正在商品化。 开放的 Skill、开放的 MCP adapter、开放的 CLI，任何人都能 在几小时内创作并发布。接口可能变得廉价易造；能力依然是稀缺的交付物。 稀缺性下移。 稀缺层不再是应用外壳，而是可调用外衣所控制的访问权： 数据 · 算力 · 动作 · 权限 · 信任 · 真实世界履约 搜索能力因索引而稀缺；预订能力因能确认预订而稀缺；支付能力因能移动金钱而稀缺。 当商业价值集中在能力上，自然的经济单元就变成操作、数量、效应、结果——或其中任何 一项的收入分成。 如果 Capability 成为经济单元，Capability 计量就变成基础设施。 这是本文的论点。 论点与假设（Thesis and assumptions） AgentMeasure 建立在三个尚未完全证实的趋势判断上： Agent 将中介越来越多的软件选择与执行。 更多软件能力将脱离其人类 UI 被独立暴露。 基于使用、效应与结果的商业模型将与 seat-based 定价并存。 即使这些趋势发展不均衡，测量标准依然有用：对象、质量规则与声称纪律本身成立为 一套 Agent 软件测量标准。 二、先计量，后变现（Measurement Before Monetization） CaaS 要能定价、计费与建立声誉，先要有共同的测量语义。四个问题说明这一点： 一个用户任务 → 1 个 Operation → 3 次重试 收 1 次钱还是 3 次？ 工具成功返回 → Agent 忽略了结果 价值交付了吗？ 预订 API 执行了 → 预订从未被确认 能力履约了吗？ 任务成功 → 没有这个能力也能成功吗？ Provider 能主张价值吗？ 这些问题都无法由原始调用次数回答，也无法由支付轨道回答。它们需要关于 operation / attempt / delivery / consumption / effect / outcome 的一致定义，以及 把观察转化为这些对象的一致规则。这个共识就是切入点：先计量，后变现。 现实证据：商业先于计量到来 这并非假设——Agent 中介商业的支付与发现基础设施已经存在： Cloudflare Agents SDK 允许 MCP Tool 按单次调用定价并经 x402 收费 （Charge for MCP tools）。 Coinbase x402 Bazaar 是发现层：Agent 搜索带价格与 schema 的服务，并经 MCP 完成付费调用（x402 Bazaar）。 OpenAI 与 Stripe 的 Agentic Commerce Protocol（ACP） 已在真实 agentic commerce 流程中使用（报道）。 这证明本节的论点：支付与发现基础设施先于共同的 capability 测量语义到来—— 这正是 AgentMeasure 要填补的空缺。 三、测量对象 Observation 是证据单位，不是业务测量单位。 AgentMeasure 先定义业务单位： Provider ↓ Software Entity ↓ Capability ↓ Interaction Surface Capability 是主要的功能与测量对象。Offering 是一个或多个 Capability 的商业包装 ——定义于 Commercial Extension（实验性），绝不插入 Core 测量谱系。 对象 定义 层 Software Entity 被度量的软件：Tool、Skill、API、Data Source、Agent、Application、Runtime Capability Market Capability 实体的具名功能——主要的功能与测量对象 Market Interaction Surface 能力的可观察调用界面（mcp_tool、cli_command、http_endpoint…） Market Decision Opportunity 一次工具选择决策 Behavior Candidate Set 该次决策真正提供的候选集合 Behavior Presentation 某 selectable 出现在候选集 Behavior Selection Agent 选择某 selectable Behavior Operation 为某任务对某 Capability 的一次逻辑使用 Behavior Attempt Operation 的一次实际执行（重试 = 多个 Attempt） Behavior Result / Effect 能力返回了什么 / 世界改变了什么 Behavior Task Operation 所服务的任务单位 Behavior Client 独立 Agent runtime / installation Market Project package/MCP/skill 归属的软件项目 Market Category 可比较的能力类别（搜索、预订…） Market Observation 测量事实的证据记录（认证与签名可选，由 verification profiles 定义） Evidence 观察发生在 Interaction Surface 层；归属到 Software Entity 经机器可读 registry 解析——观察时绝不猜测。 定价不是核心模型的对象。 Offering——引用一个或多个 Capability 的商业包装， 含允许的 surface、定价政策、服务级别目标与商业约束——定义在 Commercial Extension （实验性、非规范性）中，使测量语义的演进不被任何支付设计绑架。 分布事件（Distribution events） 商业归因进入范围后，discovery 重新获得商业意义——但不成为选择分母： Published → Listed → Retrieved / Discovered → Presented Presented 仍是选择指标的分母；Discovered 是分布归因事件，回答 哪个 Skill / Registry / Marketplace 带来了 Capability 使用。 四、Agent–Capability 交互模型 Reach → Value 是测量视角，不是普适执行状态机。 不同类别的能力有不同的有意义链路： Information 操作 → 结果 → 消费 Action 操作 → 效应 → 确认 Transaction 操作 → 授权 → 提交 / 结算 Interaction Class（information / action / transaction / computation / communication / control / storage / sensing）决定适用哪条链路、哪些 Utility 信号 有意义。搜索结果被消费；预订被确认；支付被结算。把所有能力塞进一条流水线， 产出的数字会失去含义。 五、测量框架 AgentMeasure 定义 Metric Families，不定义全局北极星。 M1 Distribution — Reach。 能力进入 Agent 世界了吗？ Available Clients · Eligible Opportunities · Presentations · Presentation Rate · Distribution Coverage M2 Choice — 最 Agent-native。 Agent 有机会时会选它吗？ 选择数 · Observed Selection Rate（Observed Selected ÷ Presented）· Conditional Choice Share · 首选率 M3 Execution — Use。 选了以后好用吗？Draft 0.4 分开计数 Operation 与 Attempt—— 这正是未来 Metering 需要的区分： Operations · Attempts · Attempts per Operation Operation 完成率 · Operation 成功率 Attempt 失败率 · 重试率 · 延迟 M4 Utility — 有效使用。 能力交付了可用信息，还是引发了预期效应？ Result Utility 已交付 · 已消费 · 已接受 Effect Utility 已应用 · 已确认 · 已回退 / 失败 M5 Outcome — Value。 改善任务了吗？ 任务成功关联 · 增量提升 · 节省时间 · 节省成本 关系测量（从独立章节降级为小节）：Trial → Active → Repeated → Preferred → Dependent。最不可替代的 Dependent 依然是长期资产信号。 六、测量质量与声称纪律 证据质量不是覆盖质量，两者都不是限定质量，也都不是方法论。一组 100% 真实但只覆盖 2% Agent 的事件，不是市场数据。 Measurement Quality ├── Provenance / Evidence Strength 观察来自哪里？其来源被支持得多强？ ├── Coverage 我们看到了多少世界？ ├── Qualification 这算不算真实生产使用？ ├── Sampling 采样了吗？不确定性多少？ ├── Identity 标识归一得怎么样？ └── Method/version 用什么统计、哪个规范版本？ 限定使用。 每条观察携带两条轴——Usage Context（流量来源）与 Validity（观察是否 真实）。Strict Qualified Usage = production + validity=normal：公共指标的 默认口径。unknown 的 context/validity 单独披露，绝不静默计入——没有”报 unknown → 进排行榜”的激励。重试是同一 Operation 的另一次 Attempt，作为可靠性信号保留，不算 多次逻辑使用。 声称纪律。 每个公开指标携带 Measurement Label：分子、分母、可观测人群、合格 人群、runtime 覆盖、grain、choice mode、decision authority、selection constraint。 观测到的选择绝不说成偏好；关联绝不说成因果；不可观测绝不说成负面。 七、测量与计量（Measurement and Metering） 从测量标准通向 CaaS 的桥是语义的：测量单位 ≠ 计费单位，且三个计量概念必须 绝对分开——Event 是为什么计费，Unit 是按什么单位计，Quantity 是多少单位： 能力 billable_event billable_unit billable_quantity 搜索 operation_succeeded operation 1 数据 result_delivered record 1,382 算力 compute_completed gpu_second 47.2 动作 effect_confirmed operation 1 预订 effect_confirmed booking 1 线索 outcome_qualified qualified_lead 5 电商 transaction_settled transaction 0.03（收入分成） 因此，计量语义按 Offering 定义： Billable Event 哪个测量事实触发计费 Billable Unit 计量单位（操作、记录、GPU-秒、效应…） Billable Quantity 单位如何计数（按策略：attempts、确认…） Pricing Model 按操作 · 按数量 · 按效应 · 按结果 · 收入分成 Pricing Policy 版本化的价格规则（flat、阶梯、企业协议、surge…） Quote 单次调用实际适用的条款（quote_id、policy 版本、单价） Metering Policy 测量事实 → 计费事实的映射（规则、排除），版本化 Metering Ledger 可重放、可纠错的计量事实账本（revision / supersedes / reversal） Commercial Attribution 哪些参与方贡献了发现 / 选择 / 收入 支付不在范围内。 AgentMeasure 不定义支付轨道、钱包、结算货币、商户记录关系或 金融托管。它产出支付系统消费的事实——合格操作、已确认效应、合格结果、计费数量、 商业归因。 AgentMeasure 标准化经济事实，不移动金钱。 八、归因与增量 能力参与了成功任务，不等于它导致了成功。 归因测量（observational）：哪些能力参与了任务链——只能支持”关联”与”参与执行链”的结论。 增量测量（counterfactual）：能力的存在创造了多少额外价值——随机对照是最强 证据，但许多能力无法随机关闭。因此因果声称遵循 Value Evidence Ladder： V0 Association 任务成功时参与过 V1 Matched / Observational 控制已知混淆变量比较 V2 Offline Ablation 重放任务、移除能力 V3 Quasi-experiment switchback / 自然变异 V4 Randomized Holdout 最强因果证据 只允许用实际产出的证据等级支持对应的因果声称强度——与测量质量的纪律一致。 商业归因扩展观察侧到分发链： GitHub Skill → Registry → Agent 推荐 → Capability → 支付 谁贡献了发现、选择与收入？这是未来 Agent affiliate 与收入分成模型的基础——且绝不 与因果增量混为一谈。 九、能力信任与可比性（Capability Trust and Comparability） 能力消费者的选择受多种因素塑造。Agent 与 Marketplace 可以在品牌、政策、价格、 用户偏好与平台约束之外越来越多地比较机器可读的性能信号——这正是 AgentMeasure 的 Decision Authority / Selection Constraint 模型描述的轴： Capability Signals 可靠性 · 延迟 · 价格 · 新鲜度 · 消费 · 效应成功 · 结果 · 安全 · 测量覆盖 AgentMeasure 不计算通用 AgentMeasure Score。Agent A 在乎价格，Agent B 在乎延迟， Agent C 在乎隐私。排名是 Agent 与 Marketplace 的产品决策；标准只定义可比较的信号 与让它们可比较的 Label。Measurement Label 是这种可比性的基础。 十、观察与部署架构（Observation & Deployment Architecture） 不同测量 surface 能看到的东西不同；单边接入就有价值，但声称必须匹配 surface： 分发侧 → Agent Runtime 侧 → Provider 侧 → 效应 / 结果侧 Surface 能看什么 Registry 发现 / 可用性 Agent runtime 呈现 / 选择 / 消费 Capability provider 操作 / attempts / 结果 目标系统 效应 / 交易 实验层 增量 双侧观察（Agent runtime + provider）构成佐证（E2）；仅 Provider 侧也足以支持 provider-scoped 的使用指标。标准不在请求关键路径上：观察异步产出、仅元数据、 落盘前伪匿名。 十一、互操作 标准是 transport-neutral、vendor-neutral 的。现有基础设施作为实现例子而非前提： MCP 承载生命周期事件与 trace context；OpenTelemetry 承载工具 span；Codex/Claude Code/DeepSeek Harness 暴露带能力声明的观察点；registry 提供实体身份。未来的支付 轨道消费标准的事实，而不是扩展标准的核心。 十二、不做什么与治理 AgentMeasure 不是支付协议、Marketplace、钱包或通用声誉系统。标准不： 移动金钱或托管资金； 给能力排名或给 Provider 打分； 定义什么是”好”能力； 要求任何中心服务器、Agent 侧安装或开源 Provider。 标准本身由社区治理（AUP 流程，proposals/）；建立在它之上的商业产品不得控制 标准的定义。 十三、开放问题 任务边界：什么算一个”任务”，由谁定义？ 效应验证：不深度集成每个目标系统，如何确认效应（预订确认、支付结算）？ 规模化增量：如何在不干扰生产的情况下跨生态运行反事实实验？ 候选集可观测性：Presented 是关键分母，多数 runtime 尚未暴露 routing 层信号。 跨 Agent 身份：同一 client 跨 Codex/Claude/DSH——何时可知？ 计费单位共识：Provider 与支付轨道最终会就哪些测量事实达成一致，误计量的代价多大？ 隐私：伪匿名下关联与留存能走多远？ 十四、结论 软件消费者正在从人变成 Agent，经济单元正在从席位转向可调用的能力。在能力被定价、 计费与比较之前，生态需要一套共享的测量语言——什么算选择、什么算操作、什么算交付、 消费、效应与结果，以及哪些数字能支持哪些结论。 AgentMeasure 就是那个提案：测量语义作为基础设施，商业语义作为未来扩展，支付交给 别人的轨道。今天：让开发者知道 Agent 如何真实使用自己的能力。下一步：让 Capability 可以跨 Agent 被统一度量、比较和计量。长期：成为 CaaS 与 Agent Capability Economy 的统一计量基础。 参考文献 RFC 2119 / BCP 14 — Key words for use in RFCs to Indicate Requirement Levels。 OpenTelemetry GenAI semantic conventions — gen_ai.* 工具调用遥测字段。 Model Context Protocol (MCP) 规范 — 工具发现与调用 surface。 MCP Registry — 实体解析的 server 身份入口。 EDPB — 伪匿名化指引（伪匿名数据仍可能属于 personal data）。 Cloudflare — Charge for MCP tools（x402 / Agentic Payments）。 Coinbase — x402 Bazaar：Discover & pay over MCP。 OpenAI / Stripe — Agentic Commerce Protocol（ACP），2025 年 9 月发布；见 Digital Transactions 报道。 AgentMeasure 规范 — Core / Metrics / Data / Entity / Quality / Correlation （standard/）；Commercial Extension（extensions/COMMERCIAL.md，实验性）； 机器可读 registry（schemas/、registry/）；参考实现与 conformance vectors 同仓发布。 规范全文（测量对象、生命周期、指标家族、质量、报告）与参考实现（AgentMeasure）均已开源。AgentMeasure 1.0 毕业标准：2 个独立实现、3 个 runtime profiles、2 个 tool-side 实现、公开 conformance + canonical test vectors、5-10 个真实项目、已发布的 discrepancy report、安全与隐私审查。"
    },
  
    {
      "id": "data-ai-glasses-corpus",
      "kind": "data",
      "slug": "ai-glasses-corpus",
      "title": "AI 眼镜与开放场景 · 语料汇总",
      "summary": "AI 眼镜与开放场景研究的语料范围、平台分布及历史候选标签统计。适合核对样本口径，不用于推断总体市场需求。",
      "url": "/knowledge/materials/ai-glasses-corpus/",
      "lang": "zh-CN",
      "collections": ["ai-glasses"],
      "updated": "2026-08-31",
      "version": "2026-08-31 汇总快照",
      "access": "仅汇总数据",
      "source_label": "本站已公开数据汇总",
      "use_for": "核对 AI 眼镜与开放场景语料的规模、来源偏差和历史候选标签口径。",
      "public_scope": "209,862 条记录的聚合统计；20 类来源；JSON 与 CSV 汇总。",
      "boundary": "不含原始文本；组合快照不能替代产品反馈子集或真实采用证据。",
      "review_status": "汇总算术、来源合计与公开字段已复核",
      "source_page": null,
      "study_id": "ai-glasses-2023",
      "downloads": [{"label":"下载本组汇总","url":"/knowledge/data/ai-glasses-summary.json","format":"JSON · 本组"},{"label":"下载三组对照总览","url":"/knowledge/data/corpus-summary-2026-08-31.csv","format":"CSV · 三组"}],
      "source_ids": null,
      "text": "核对 AI 眼镜与开放场景语料的规模、来源偏差和历史候选标签口径。 209,862 条记录的聚合统计；20 类来源；JSON 与 CSV 汇总。 不含原始文本；组合快照不能替代产品反馈子集或真实采用证据。 <h2 id=\"这份快照与旧文章不是同一分母\">这份快照与旧文章不是同一分母</h2> 这份组合快照覆盖 2023-01 至 2026-07 的开放场景记录，用于检查来源偏差和历史候选标签。此前文章使用的是更窄的产品反馈筛选集；两者的纳入条件不同，不能用 209,862 替换旧文样本数。 20 类来源并不均衡：Reddit 占 83.29%，YouTube 占 10.14%，VITURE 公开评论占 2.26%。这些比例描述采集结果，不代表设备用户或潜在购买者的分布。 机器标签能支持什么 E0–E5 是历史处理产生的候选标签。本轮只复核各标签计数能否加总到总记录数，没有逐条确认发言中的产品、角色、行为和上下文。因此 E3 或 E5 不能直接解释为购买、留存或需求已经成立。 两条记录缺少原有文本哈希字段；“其余哈希未重复”也不是语义去重证明。按规范化后的完全相同文本检查，本组与本地 AI 组共享 104 条，与家庭机器人组共享 72 条。 复核到哪里 公开文件允许复算来源、标签与结构质量的汇总关系，不包含正文、平台账户、用户标识和原帖地址集合。记录月份来自字段，不表示各月连续、均匀覆盖；完整边界见数据方法。 {“id”:”ai-glasses-2023”,”title”:”AI 眼镜与开放场景”,”record_count”:209862,”first_month”:”2023-01”,”last_month”:”2026-07”,”largest_source”:”reddit”,”largest_source_records”:174791,”largest_source_share_pct”:83.2885,”platform_counts”:{“app_store”:155,”bilibili”:2993,”github”:429,”google_play”:283,”hacker_news”:2520,”halliday_judgeme”:4,”inmo_loox”:60,”lucyd_okendo”:622,”public_forum”:26,”reddit”:174791,”rokid_judgeme”:307,”solos_judgeme”:25,”taobao”:2,”tmall”:3,”viture_okendo”:4734,”weibo”:63,”x”:274,”xiaohongshu”:679,”youtube”:21279,”zhihu”:613},”machine_evidence_label_counts”:{“E0”:168476,”E1”:29266,”E2”:3630,”E3”:1843,”E4+”:120,”E4-“:943,”E5”:5584},”duplicate_record_ids”:0,”missing_record_ids”:0,”duplicate_stored_text_hashes”:0,”missing_stored_text_hashes”:2,”nonempty_text_records”:209862,”invalid_json_lines”:0,”input_sha256”:”a6fabcdbf8a50329c9520efe763b4f460c68838c19cf9409830269c9abe75b89”,”semantic_label_validation”:”not-performed-in-this-recount”,”unit”:”feedback record, not person or validated demand”}"
    },
  
    {
      "id": "data-dji-company-map",
      "kind": "data",
      "slug": "dji-company-map",
      "title": "大疆系创业公司图谱",
      "summary": "已公开的公司与产品图谱，作为产业研究的查阅入口。保留字段与观察语境，不把履历关联当作成功率或因果证明。",
      "url": "/knowledge/materials/dji-company-map/",
      "lang": "zh-CN",
      "collections": ["dji-alumni"],
      "updated": "2026-08-31",
      "version": "2026-08-31 公开版本",
      "access": "在线图谱",
      "source_label": "本站已公开图谱",
      "use_for": "查找大疆相关人才创业的公司与产品线索，并回到具体公开来源继续核验。",
      "public_scope": "一份公开在线图谱；展示公司、产品及关联线索，不包含私有研究表。",
      "boundary": "共同履历不证明股权、能力迁移、因果关系或创业成功率。",
      "review_status": "公开入口和字段边界已核对；对象事实需持续复核",
      "source_page": null,
      "study_id": null,
      "downloads": [{"label":"打开在线图谱","url":"/dji-map.html","format":"网页 · 宽表"}],
      "source_ids": null,
      "text": "查找大疆相关人才创业的公司与产品线索，并回到具体公开来源继续核验。 一份公开在线图谱；展示公司、产品及关联线索，不包含私有研究表。 共同履历不证明股权、能力迁移、因果关系或创业成功率。 <h2 id=\"这份资料是什么\">这份资料是什么</h2> 这份在线图谱按公司与产品整理大疆相关人才创业的公开研究线索。它提供对象清单，方便回到具体公司和公开来源继续查证。 原图谱与文章保留原地址；知识库只是给这份表格建立稳定的资料说明和专题归属，没有额外发布本地研究目录里的其他文件。 怎样使用 先查看对象和字段，再根据自己的问题核对产品、时间与关联性质。如果需要将某项资料用于对外分析，请继续查阅相应的一手来源，不把目录收录视为已完成事实核验。 适用边界 有共同履历不等于公司间存在股权关系，也不能据少数被收录的案例估计创业成功率。人才流动、组织经验与产业结果需要分别论证。 图谱保留的是公开版本。本地的其他履历信息、内部文件或公司策略不因此获得公开许可。引用时请附图谱地址和版本日期，并说明自己的筛选条件。"
    },
  
    {
      "id": "report-embodied-field-guide",
      "kind": "report",
      "slug": "embodied-field-guide",
      "title": "具身智能入门地图 · 2026 夏季版",
      "summary": "从产业、公司、产品到技术的入门研究地图。提供内容介绍和前 12 页 PDF 试读，帮助建立后续研究的坐标。",
      "url": "/knowledge/materials/embodied-field-guide/",
      "lang": "zh-CN",
      "collections": ["embodied-industry"],
      "updated": "2026-07-20",
      "version": "2026 夏季版",
      "access": "公开试读",
      "source_label": "本站已公开研究",
      "use_for": "建立具身智能产业、公司、产品和技术路线的第一层阅读坐标。",
      "public_scope": "内容说明与前 12 页 PDF 试读；不包含全书正文。",
      "boundary": "阶段性入门地图，不能替代公司状态、技术进展和真实部署的实时核验。",
      "review_status": "试读范围、文件与原说明页已核对",
      "source_page": "/notes/embodied-intelligence-beginners-guide/",
      "study_id": null,
      "downloads": [{"label":"阅读 PDF 试读","url":"/assets/downloads/embodied-intelligence-preview-2026-summer.pdf","format":"PDF · 前 12 页"},{"label":"查看内容与版本介绍","url":"/notes/embodied-intelligence-beginners-guide/","format":"网页"}],
      "source_ids": null,
      "text": "建立具身智能产业、公司、产品和技术路线的第一层阅读坐标。 内容说明与前 12 页 PDF 试读；不包含全书正文。 阶段性入门地图，不能替代公司状态、技术进展和真实部署的实时核验。 <h2 id=\"这份资料是什么\">这份资料是什么</h2> 这份入门地图来自对具身智能产业、公司、产品和技术的阶段性整理。它用任务和交付阶段区分不同机器人，再连接产业链、技术路径与职业学习问题。 可以先借它建立阅读坐标：一项技术处在哪一层，一家公司提供什么产品，演示、试点和持续交付分别说明什么。随后再回到论文、开发文档和具体公司来源核对。 目前能获得什么 这里提供已公开的前 12 页 PDF 试读及内容介绍，不是全书免费下载。完整版本的范围和获取方式保留在原说明页。没有将未公开的本地白皮书版本替换进这份资料。 使用边界 版本为 2026 夏季版，内容介绍发表于 2026-07-20。公司状态与技术判断具有时效性；这份入门整理不替代实时核验、专业教材或真机实验。 引用请写明作者、标题、版本和所用页码。试读文件不授予整本材料或其中第三方内容的再分发权。 过去几个月，我一直在系统学习具身智能。 开始深入这个领域后，我很快遇到一个问题：资料很多，却缺少阅读顺序。 今天看到人形机器人，明天看到四足机器人；刚理解 VLA，又遇到世界模型、强化学习、遥操作和合成数据。产品发布、融资新闻、演示视频、论文与产业报告每天都在增加，但它们讨论的往往不是同一层问题。 产品形态、应用场景、产业链、技术路线、公司竞争力和商业进展经常混在一起。看得越多，越容易记住零散名词，却仍然说不清这个行业的结构。 我此前长期做软件和 AI 产品，机器人对我也是一个需要从零理解的新领域。为了建立一张相对完整的地图，我花了三个多月整理公司资料、行业报告、论文、视频、播客和公众号文章，并尝试用同一套问题比较它们。 这些笔记后来变成了《具身智能入门：产业、公司、产品、技术与职业地图》。 先建立坐标，再判断公司和技术 我把具身智能看成一座还在建设中的城市。 刚进入这个领域时，很容易马上追问哪家公司最强、哪条技术路线会赢。但如果没有基本坐标，这些判断往往只是把融资、演示效果和技术名词放在一起比较。 我先回答几组基础问题： 产业链由哪些环节构成，每个环节解决什么问题？ 人形、四足、轮式双臂和固定机械臂分别适合哪些任务？ 一家公司是在做演示、试点、交付，还是已经形成复购？ 本体、感知、控制、模型、数据与部署怎样协同？ 一个非机器人背景的人，应该怎样进入这个行业？ 这些问题构成了全书的基本框架。 第一部分：产业与场景 这一部分先讨论具身智能的边界、八层产业链和主要产品形态。 我没有把所有机器人放进同一个排名，而是从任务出发：客户需要搬运、巡检、操作工具、照护、陪伴，还是家庭安防？任务不同，对本体、自由度、安全、成本和部署方式的要求也不同。 同一种机器人在发布会上和在真实场景里，也可能是两个完全不同的产品。演示一次动作，和长时间稳定完成任务之间，还隔着可靠性、维护、人员配置、系统集成与成本。 第二部分：公司研究 我整理了 80 余家国内外公司，并选择 39 家建立首轮跟踪矩阵。 这里不做公司总榜。我把不同品类、任务和商业阶段的公司分开，再从业务、产品、技术、经营、资本和组织几个角度观察，同时标记证据来源和可信度。 公司研究中我反复使用一个问题： 一个机器人产品，怎样从能演示，走到能试点、能交付、能复购？ 融资额、估值和演示视频都能提供信息，但它们不能代替客户、部署与收入证据。更值得追问的是：谁在使用、完整任务是什么、进入了哪个阶段、部署需要多少人力，以及客户为什么愿意继续使用。 第三部分：产品与技术 技术部分从产品任务倒推系统，没有按论文名词逐条解释。 如果机器人要在真实环境里完成任务，本体、感知、运动控制、VLA、世界模型、数据、仿真、灵巧手、触觉、安全与部署之间是什么关系？哪些能力决定“能不能做”，哪些能力决定“能不能稳定做”，又有哪些问题最终会落到成本和维护上？ 我希望这部分能帮助非算法背景的读者建立系统关系，也帮助只熟悉某个局部技术的人理解它在完整产品中的位置。 第四部分：职业与学习 进入一个快速变化的行业，职业选择不能只看公司名和岗位标题。 这一部分整理了岗位族、招聘信息、薪酬口径、员工体验与离职代理信号，也提供了一套公司研究工作表。这份材料不保证转行结果；它用来帮助读者判断自己的经验可以迁移到哪里、目标岗位负责什么，以及应该补哪些知识和实践。 这份地图适合怎样使用 这不是机器人算法教材，也不能代替论文、开发文档、真机实验和持续研究。 下面几类读者可以把它作为入门参考： 想系统了解具身智能，但还没有机器人专业背景； 需要研究行业、公司、产品或商业机会； 正在评估具身智能公司与岗位； 已经熟悉局部技术，希望补齐产业、产品和商业视角。 使用这份地图时，可以把不同公司和产品放回各自的任务与阶段中，避免只通过融资金额、演示效果和热门概念判断行业。 关于版本与更新 目前整理完成的是 2026 夏季版，共 120 页。 这份材料记录的是 2026 夏季的阶段性判断。具身智能变化很快，很多判断还要由产品、客户和时间继续检验。后续版本会记录哪些公司进入了新阶段、哪些技术判断发生了变化，以及哪些原本看好的场景没有按预期发展。 网站提供前 12 页试读版，可以先了解内容框架和写作方式。 版本说明与获取方式见说明页。 《具身智能入门：产业、公司、产品、技术与职业地图》 Roy.Tong 2026 夏季版"
    },
  
    {
      "id": "data-home-robots-corpus",
      "kind": "data",
      "slug": "home-robots-corpus",
      "title": "家庭机器人与开放场景 · 语料汇总",
      "summary": "家庭机器人研究的语料规模、来源构成与历史候选标签分布，配合任务与失败恢复笔记阅读。原始平台内容不再分发。",
      "url": "/knowledge/materials/home-robots-corpus/",
      "lang": "zh-CN",
      "collections": ["home-robots"],
      "updated": "2026-08-31",
      "version": "2026-08-31 汇总快照",
      "access": "仅汇总数据",
      "source_label": "本站已公开数据汇总",
      "use_for": "核对家庭机器人研究语料的规模、时间范围、来源集中度和结构问题。",
      "public_scope": "208,755 条记录的聚合统计；6 类来源；JSON 与 CSV 汇总。",
      "boundary": "不含原始文本；机器候选标签不等于人工确认的任务或需求。",
      "review_status": "汇总算术、来源合计与公开字段已复核",
      "source_page": null,
      "study_id": "home-robots-2023",
      "downloads": [{"label":"下载本组汇总","url":"/knowledge/data/home-robots-summary.json","format":"JSON · 本组"},{"label":"下载三组对照总览","url":"/knowledge/data/corpus-summary-2026-08-31.csv","format":"CSV · 三组"}],
      "source_ids": null,
      "text": "核对家庭机器人研究语料的规模、时间范围、来源集中度和结构问题。 208,755 条记录的聚合统计；6 类来源；JSON 与 CSV 汇总。 不含原始文本；机器候选标签不等于人工确认的任务或需求。 <h2 id=\"这份快照怎样进入任务研究\">这份快照怎样进入任务研究</h2> 快照覆盖 2023-01 至 2026-08 的开放场景记录。它的作用是帮助发现家庭任务、失败情形和替代方案的线索，再回到具体场景做人工判断；它本身不能回答家庭是否愿意长期采用或付费。 六类来源中，Reddit 占 88.15%，Hacker News 占 9.11%。平台讨论的出现频率不能外推为家庭用户分布，也不能替代接管次数、维护负担和长期使用行为。 标签与旧报告如何处理 E0–E5 是历史机器处理产生的候选结果。本轮核对了标签合计，没有逐条确认发言所指的产品、角色、上下文及实际行为，因此不沿用旧报告中未经复核的“需求已闭合”结论。 有一条记录缺少原有文本哈希。按规范化后的完全相同文本检查，本组与本地 AI 组共享 133 条文本，与 AI 眼镜组共享 72 条；这不是人物去重或语义去重。 复核到哪里 公开层只提供结构汇总、月份范围和输入摘要。原始反馈、个人标识、内部产品方案以及未经授权的第三方内容保持私有。完整方法和可复算层级见研究数据说明。 {“id”:”home-robots-2023”,”title”:”家庭机器人与开放场景”,”record_count”:208755,”first_month”:”2023-01”,”last_month”:”2026-08”,”largest_source”:”reddit”,”largest_source_records”:184008,”largest_source_share_pct”:88.1454,”platform_counts”:{“bilibili”:941,”github”:905,”hacker_news”:19023,”reddit”:184008,”stackexchange”:297,”youtube”:3581},”machine_evidence_label_counts”:{“E0”:161090,”E1”:32030,”E2”:7105,”E3”:668,”E4+”:2707,”E4-“:2434,”E5”:2721},”duplicate_record_ids”:0,”missing_record_ids”:0,”duplicate_stored_text_hashes”:0,”missing_stored_text_hashes”:1,”nonempty_text_records”:208755,”invalid_json_lines”:0,”input_sha256”:”5fcb6627471cbf583932a8e7085193a365cce1301e75d84c65feeae11c426cbe”,”semantic_label_validation”:”not-performed-in-this-recount”,”unit”:”feedback record, not person or validated demand”}"
    },
  
    {
      "id": "data-local-ai-corpus",
      "kind": "data",
      "slug": "local-ai-corpus",
      "title": "本地 AI 与个人算力 · 语料汇总",
      "summary": "本地 AI 与个人算力研究所用语料的结构统计，包含记录范围、来源分布和质量检查。仅公开汇总，不含原始用户文本。",
      "url": "/knowledge/materials/local-ai-corpus/",
      "lang": "zh-CN",
      "collections": ["local-ai"],
      "updated": "2026-08-31",
      "version": "2026-08-31 汇总快照",
      "access": "仅汇总数据",
      "source_label": "本站已公开数据汇总",
      "use_for": "核对本地 AI 研究语料的规模、时间范围、来源构成与结构质量。",
      "public_scope": "211,088 条记录的聚合统计；7 类来源；JSON 与 CSV 汇总。",
      "boundary": "不含原始文本；记录数不是人数、市场份额或已验证购买需求。",
      "review_status": "汇总算术、来源合计与公开字段已复核",
      "source_page": null,
      "study_id": "local-ai-2024",
      "downloads": [{"label":"下载本组汇总","url":"/knowledge/data/local-ai-summary.json","format":"JSON · 本组"},{"label":"下载三组对照总览","url":"/knowledge/data/corpus-summary-2026-08-31.csv","format":"CSV · 三组"}],
      "source_ids": null,
      "text": "核对本地 AI 研究语料的规模、时间范围、来源构成与结构质量。 211,088 条记录的聚合统计；7 类来源；JSON 与 CSV 汇总。 不含原始文本；记录数不是人数、市场份额或已验证购买需求。 <h2 id=\"这份快照固定了什么\">这份快照固定了什么</h2> 快照把本地 AI 与私有算力研究使用的一批记录固定在 2024-01 至 2026-07。公开层保留总量、七类来源的计数、时间字段、结构检查和输入快照摘要；原始帖子、账户、用户标识及逐条文本均未发布。 来源高度集中：Reddit 占 90.21%，Hacker News 占 5.90%。因此它适合发现部署、配置、隐私和持续运行中的问题，不适合估计不同人群的市场比例。 分母与跨组重复 211,088 指反馈记录，不是独立用户。主快照没有 E0–E5 编码字段，下游文件中的机器标签不能倒填成原始数据事实。 按 Unicode NFKC、空白折叠和首尾清理后的完全相同文本检查，本组与 AI 眼镜组共享 104 条文本，与家庭机器人组共享 133 条。这个检查不包含模糊匹配或人物关联，所以三组记录既不能直接相加，也不能据此宣布完成语义去重。 复核到哪里 公开 JSON 与 CSV 可以复算来源合计、比例和结构质量字段；输入摘要通过 SHA-256 绑定到本轮私有快照。本次没有重新爬取，也没有逐条进行语义审核。完整重算仍需要获得原始快照的合法访问权限。 {“id”:”local-ai-2024”,”title”:”本地 AI 与私有算力”,”record_count”:211088,”first_month”:”2024-01”,”last_month”:”2026-07”,”largest_source”:”reddit”,”largest_source_records”:190425,”largest_source_share_pct”:90.2112,”platform_counts”:{“github”:2092,”hacker_news”:12456,”public_ecommerce_reviews”:368,”public_forum”:2810,”public_review_comments”:1801,”reddit”:190425,”stackexchange”:1136},”machine_evidence_label_counts”:{“not-coded”:211088},”duplicate_record_ids”:0,”missing_record_ids”:0,”duplicate_stored_text_hashes”:0,”missing_stored_text_hashes”:0,”nonempty_text_records”:211088,”invalid_json_lines”:0,”input_sha256”:”ae7dbd0cef04bc0013f66484207e0c95328250a88b350cb01ac692947ddb863f”,”semantic_label_validation”:”not-performed-in-this-recount”,”unit”:”feedback record, not person or validated demand”}"
    },
  
    {
      "id": "reference-public-reading-sources",
      "kind": "reference",
      "slug": "public-reading-sources",
      "title": "公开研究来源索引",
      "summary": "研究笔记引用的论文、项目规范与官方文档，逐项说明来源角色和适用范围，方便回到原文核对。",
      "url": "/knowledge/materials/public-reading-sources/",
      "lang": "zh-CN",
      "collections": ["product-research"],
      "updated": "2026-08-31",
      "version": "随引用维护",
      "access": "来源链接",
      "source_label": "本站已公开引用",
      "use_for": "从研究判断回到论文、公开规范和官方文档，核对来源实际支持的范围。",
      "public_scope": "跨专题的公开链接与阅读说明；不转载第三方全文。",
      "boundary": "收录只表示用于查证，不代表为来源中的全部观点背书。",
      "review_status": "链接角色和公开边界已整理；时效性随引用更新",
      "source_page": null,
      "study_id": null,
      "downloads": [{"label":"查看公开来源","url":"/knowledge/sources/","format":"网页 · 原文链接"}],
      "source_ids": null,
      "text": "从研究判断回到论文、公开规范和官方文档，核对来源实际支持的范围。 跨专题的公开链接与阅读说明；不转载第三方全文。 收录只表示用于查证，不代表为来源中的全部观点背书。 <h2 id=\"这份清单有什么用\">这份清单有什么用</h2> 从研究笔记中遇到一个技术或方法判断时，可以沿清单回到论文、公开规范或官方文档，确认它究竟支持什么。每项来源带有角色和范围说明，避免把厂商介绍、实验结果和作者分析混为一谈。 这份索引跨专题使用。一项来源可以被多份资料引用，不为每个专题复制一份内容，也不把每次引用计为新增研究产物。 收录不表示背书 来源中的事实只覆盖其声明的范围。厂商功能介绍不证明普遍的生产效果，研究论文的实验也不能自动外推到其他任务。使用时仍需查看原文的日期、输入条件和限制。 权利与更新 这里提供链接和阅读说明，不转载完整第三方报告或视频逐字稿。原文权利属于相应作者；网站对自身材料的许可不扩大到第三方内容。链接变更、来源撤回或证据范围发生变化时，相关研究资料需要一起修订。"
    },
  
    {
      "id": "note-agent-context",
      "kind": "note",
      "slug": "agent-context",
      "title": "Agent 运行时：上下文、状态与权限",
      "summary": "把 Context Recommendation 收敛为可实现的职责：这一步需要什么信息、能做什么，以及如何恢复。",
      "url": "/knowledge/agent-context/",
      "lang": "zh-CN",
      "collections": ["local-ai","agent-systems"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "把 Context Recommendation 收敛为可实现的职责：这一步需要什么信息、能做什么，以及如何恢复。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["agentmeasure-core","iread"],
      "text": "一个 Agent 可以在每轮调用同一个模型，却需要不同的工作环境。研究阶段需要来源，编辑阶段需要当前文件，发布阶段还需要目标、授权和失败处理。把全部资料塞进长上下文，解决不了这些差别。 我把这项职责称为 Context Recommendation：依据当前任务，为下一步组合信息、能力、状态与约束。这是我的产品架构提案，不是已有统一标准，也不要求必须训练一个推荐模型。 先分清六类上下文 对象 需要保留的内容 常见失败 指令 目标、交付物、禁止事项 把来源文章中的指令当成用户要求 记忆 已确认偏好、历史决定、有效期 临时意见变成永久规则 知识 原始来源、观察日期、反证 旧报告压过新事实 能力 工具输入输出、前置条件 工具可见却无法真正执行 状态 文件版本、任务进度、待处理结果 重复操作或覆盖新修改 权限 数据范围、动作范围、审批条件 模型“认为获准”就执行 权限需要执行层检查。写进提示词的规则可以帮助模型规划，不能替代文件隔离、接口授权和网络策略。 一个能逐步实现的运行回路 在模型调用前，先读取最新任务状态，检索候选材料；过滤无权限、过期和与当前步骤无关的内容；再决定哪些原文、摘要、工具和规则进入这一轮。执行后记录事实、输出和状态变化。 先用确定性规则处理权限、版本和预算，检索处理文档候选，再考虑排序模型。复杂度应由真实失败驱动，不必先搭一套庞大的“认知架构”。 任务状态与聊天历史应分开。对话中说“已经发布”不是发布凭证；应该保存目标版本、执行结果和可回查的地址。摘要可以帮助继续工作，关键事实仍须能回到原始事件。 用失败类型指导评测 同一个错误答案，原因可能是没有召回资料、召回了过期版本、模型误读，或工具执行失败。只看最终分数，无法判断该改检索、模型还是运行时。 评测时至少保留任务版本、可见资料、允许的工具、输出和验收结果。对长任务增加中断恢复、用户改需求、来源互相矛盾这几类测试。它们比“连续跑了多少轮”更接近产品可靠性。 什么会推翻这套投入 对于输入固定、步骤短、没有外部动作的任务，普通检索与清晰模板可能已经足够。运行时工程增加的延迟、维护和调试成本必须算进去。 下一步验证应比较同一组任务的完成质量、人工修正时间和越权拦截效果。不能因为接入了更多上下文，就宣称任务价值提高。 本页把原文章中较宽的概念收敛为实现职责；完整论证仍保留在原文。"
    },
  
    {
      "id": "note-agent-measurement",
      "kind": "note",
      "slug": "agent-measurement",
      "title": "Agent 计量：执行事实、任务结果与价值",
      "summary": "明确分母和证据边界，避免把重试、调用成功、被使用和业务收益混成一个数字。",
      "url": "/knowledge/agent-measurement/",
      "lang": "zh-CN",
      "collections": ["agent-systems"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "明确分母和证据边界，避免把重试、调用成功、被使用和业务收益混成一个数字。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["agentmeasure-core","agentmeasure-evidence","agentmeasure-lab"],
      "text": "AgentMeasure 研究的问题很具体：软件被 Agent 调用以后，怎样描述发生了什么，并让别人检查数字的含义。它仍是开放草案与实现项目，不是已经被全行业采纳的计量标准。 同一件事，不能混用分母 一个演示例子：用户要求生成一次报告，服务端第一次尝试失败，第二次成功。若两次尝试确实属于同一个逻辑操作，应记录： 指标 结果 分母 attempts 2 实际执行尝试 operations 1 去重后的逻辑操作 attempt success 50% 成功尝试 / 全部尝试 operation success 100% 成功操作 / 全部操作 这只是解释语义的例子，不是生产测量结果。若日志缺少操作标识，无法可靠关联重试，就必须披露归组规则和未知部分，不能强行凑出一个精确操作数。 一条测量链有多处断点 “可用 → 被展示 → 被选择 → 执行 → 有用 → 增量价值”中，每个箭头都需要证据。服务端日志擅长描述执行，未必知道 Agent 看到了哪些备选项；客户端选择记录也未必知道最终用户是否接受结果。 测量报告应该先写可观察范围，再给指标。没有展示分母，就不报告选择率；没有用户验收，就不把 HTTP 成功等同于任务成功；没有可比较的对照，就不把前后增长写成因果收益。 怎样读当前项目的证据 公开 trace 案例用于检查适配、字段和计数边界。它来自演示数据，不能替代真实客户生产流量。 Lab提供预注册、实验组织和报告工具。随附合成实验用于验证引擎能否恢复已知效应，也能报告没有效应的结果；不说明真实 Agent 已获得同样提升。 这种限制应出现在结果附近，不能藏在文末。 计费还需要另一份契约 业务可以按尝试、成功操作、时间或结果收费，但需要预先定义失败、重试、取消、超时和人工接管如何处理。计量准确不等于价格合理；收到付款也不等于创造了增量价值。 我会把下一阶段验证放在真实日志中无法归组的操作、没有回传的最终结果，以及不同工具之间不可比的成功口径。一个让原有数字变得不那么漂亮、却更容易检查的测量系统，仍然有价值。"
    },
  
    {
      "id": "note-alternatives-entry",
      "kind": "note",
      "slug": "alternatives-entry",
      "title": "替代方案与市场进入：让下一站回答最重要的未知",
      "summary": "把竞争分析从同类产品参数表扩展到真实替代行为，并用证据职责选择进入顺序。",
      "url": "/knowledge/alternatives-entry/",
      "lang": "zh-CN",
      "collections": ["product-research"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "把竞争分析从同类产品参数表扩展到真实替代行为，并用证据职责选择进入顺序。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["sure"],
      "text": "竞争对手可以是另一家公司，也可以是用户已有的工具、人工服务，或者暂时不做。只比较同形态产品，很容易把一整个不需要该形态的人群漏掉。 本地 AI 的替代方案包含现有电脑，桌面制造的替代方案包含代加工，家庭机器人的替代方案包含家务习惯与专用家电。共同点是：用户购买结果，我们却容易按自己的产品分类寻找对手。 用同一个任务比较完整代价 一张有效的比较表，至少要固定任务、质量门槛和使用条件，再记录开始使用、完成任务、处理失败与持续维护的成本。省下执行时间，却增加更多准备和核验，不一定构成改善。 软件与硬件的差别在于代价如何发生。软件可能有迁移、集成和权限成本；硬件还增加空间、耗材、物流与维修。不能用“免费软件”或“一次买断”抹去完整使用成本。 市场承担不同的证据职责 我在原文章中将 Geek、Professional、领域 B 端和大众消费者理解为不同证据环境，而非必须依次通过的升级路线。 愿意折腾的人擅长暴露能力边界，却可能替产品承担配置工作；专业用户能评价工作流，却可能要求小众控制；组织客户能检验部署与服务，却可能用定制收入掩盖不可复制；大众市场能检验低门槛，却可能让曝光遮住留存不足。 进入顺序应取决于最重要的未知。如果现在最不确定的是完整部署成本，再多个人用户试用也未必能回答。 事先决定什么结果会改变路线 试点前写下：这次验证哪个假设，什么行为支持它，什么结果构成反证，何时停止或转向。标准需要时间与场景边界，不用统一的漂亮数字。 例如，一个专用创作工具可以先验证反复修改是否明显减少人工重做，再考虑扩大获客。这里是实验顺序建议，不是预设一定要收费多少或找到多少用户。 保留三种常被忽略的结果 用户觉得问题不重要；现有方案已经足够；新方案有价值，但不值得承担切换成本。这三种结果都应该进入结论，且会导致不同决定。 这使竞争研究与需求研究接到了一起：前者解释用户为什么会留下，后者解释用户为什么值得改变。两者都不该服务于证明自己已经选好的外形一定正确。"
    },
  
    {
      "id": "note-demand-evidence",
      "kind": "note",
      "slug": "demand-evidence",
      "title": "需求证据：一条反馈究竟能支持什么决定",
      "summary": "保留场景、替代方案、接受条件与行为之间的联系，不让语料规模冒充需求验证。",
      "url": "/knowledge/demand-evidence/",
      "lang": "zh-CN",
      "collections": ["product-research"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "保留场景、替代方案、接受条件与行为之间的联系，不让语料规模冒充需求验证。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["sure"],
      "text": "资料越多，越容易把“找到很多相关讨论”误写成“需求已经验证”。研究的关键动作，是让每条材料只承担它实际支持的判断。 SURE 是我用于整理这件事的方法与工具。它区分场景、问题、替代行为、方案接受和商业行为，要求证据能回到来源。软件负责检查结构，研究者负责解释语义与作出决定。项目与协议 证据等级不是市场成熟度阶梯 等级 记录的内容 不能直接推出 E0 活动、角色、场景背景 存在未满足需求 E1 明确任务、困难或目标 愿意换一种解决办法 E2 当前做法、绕行、失败或切换成本 接受研究中的新方案 E3 对该方案在给定条件下的接受或偏好 已经购买或持续使用 E4+ / E4− 商业意图 / 拒绝、取消、退货等反证 所有人具有同样意愿 E5 付费持有、部署、复用等已发生行为 这些行为由产品某项功能导致 同一角色、场景和任务中的问题链、方案链与行为链，才能连接起来判断。把甲的抱怨、乙的付费和丙的长期使用拼在一起，会制造一位根本不存在的“完整用户”。 先比较用户现在怎样解决 “想要一个机器人帮忙”可能只是表达结果愿望。用户如何处理这件事、频率多高、付出什么、为什么旧方案不够，才让新产品有比较对象。 满意替代方案应保留。它可能说明这个市场已有足够好的答案，也可能指出新方案需要跨过多高的门槛。只收抱怨会把研究变成论证既定方案的材料库。 自动编码只能产生待复核候选 一次公开讨论中的 “return” 可能指退货，也可能指程序返回；“买给父母的扫地机”不能直接变成购买通用照护机器人的证据。出现价格还可能是其他产品、服务或无关支出。 本轮三组语料重计验证了记录数、字段和来源分布，没有逐条确认机器标签。统计见数据页。CLI 检查通过与研究结论通过，是两次不同的验收。 让研究决定下一项行动 对一个拟进入开发的场景，我希望研究交付四样东西：目前最强的支持证据、最强的反证、仍未跨过的判断门槛，以及能改变投入决定的下一次验证。 如果缺的是方案接受，就设计可理解的原型；缺的是交付成本，就做带完整支持记录的试点。继续扩大背景语料，通常无法弥补这两类缺口。 本页把原研究长文收敛为阅读和行动入口。具体数据契约及命令用法仍以项目仓库为准，避免在知识库维护第二套容易过期的工具说明。"
    },
  
    {
      "id": "note-desktop-manufacturing",
      "kind": "note",
      "slug": "desktop-manufacturing",
      "title": "桌面制造：从生成设计到做出合格实物",
      "summary": "研究材料、工艺、设备状态与质检如何把数字创意变成可重复交付。",
      "url": "/knowledge/desktop-manufacturing/",
      "lang": "zh-CN",
      "collections": ["digital-making"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "研究材料、工艺、设备状态与质检如何把数字创意变成可重复交付。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["prusa-settings"],
      "text": "生成一张漂亮的设计图，与做出一件尺寸正确、强度足够、能按时交付的实物，中间还有许多决定。桌面制造的 AI 机会，应沿着这些决定寻找。 我把原研究中的设备和公司材料重新组织为一条工作链：需求与设计、可制造性判断、材料与工艺、设备执行、质检与返工、交付。公司目录留在来源侧，不能替代这条任务链。 工艺建议需要知道现场条件 同一个造型，换材料、喷嘴、支撑方式或用途，可能需要不同设置。PrusaSlicer 的打印设置文档展示了这类参数空间；它提供具体技术依据，不支持“某个模型能一键解决全部工艺”的结论。打印设置 一个有用的工艺助手，应知道当前设备、材料与目标，也应说明建议适用条件。拿不到条件时，先提出需要确认的问题，比输出一套看似完整的参数更可靠。 失败是数据，但不是自动变成知识 失败照片可以帮助识别外观异常，仍需联系当时的配置、材料状态、环境和设备记录。否则，相似外观可能来自不同原因；下一次照搬调整也未必有效。 应将建议、执行参数与结果连起来，并保留人工修正。评估时看同类任务的首次合格率、材料浪费、处理时间和返工负担。这里给出的是指标建议，尚未提供真实实验提升数字。 多设备平台先解决差异 打印、雕刻与切割共享部分设计和订单流程，但执行约束、材料风险与验收条件不同。统一入口可以降低切换成本，统一到抹去工艺差别则会增加错误。 跨设备软件更适合先统一任务描述、文件版本、设备能力和结果记录。高风险执行应由设备侧限制和人工确认承担，不能仅依赖生成内容中的提醒。 商业判断从持续使用开始 设备销量不能直接推出软件订阅或耗材收入。还需知道买家是否持续开机、做什么、失败后是否继续，以及现有切片软件、代加工服务和成熟工艺能解决多少问题。 消费兴趣、创作者工作室与小批量生产的要求可能不同。下一轮应按任务与交付责任抽样，而不是把所有桌面设备都放进一个市场故事。"
    },
  
    {
      "id": "note-evidence-maintenance",
      "kind": "note",
      "slug": "evidence-maintenance",
      "title": "研究维护：数字、版本与公开边界",
      "summary": "让报告能被持续修正：固定分母、保存来源版本、区分机器标签与人工判断。",
      "url": "/knowledge/evidence-maintenance/",
      "lang": "zh-CN",
      "collections": ["product-research"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "让报告能被持续修正：固定分母、保存来源版本、区分机器标签与人工判断。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["sure","agentmeasure-core"],
      "text": "研究报告过期，不一定是行业发生了变化。也可能是数据文件已经更新，正文还保留旧数字；或者同一个名称，先后指代原始记录、筛选子集与编码结果。 这次整理把报告的“内容版本”和“数据版本”分开保存。公开页面标注复核日期，数据发布保留输入快照摘要、统计方法和不支持的推论。 一组数字至少带四个条件 统计单位是什么，纳入了谁，覆盖哪个时间，如何从输入计算。条目、评论、项目、用户和需求不可以互换。不同来源中的同文转载，也不能充当多份独立支持。 本次核对的三组语料合计包含 629,705 次记录，但跨组存在规范化后的完全相同文本。这个总和不表示独立用户或已经验证的需求。即使完全去重，同一人的多次发言仍可能存在。 公开汇总保留每组分母、来源集中度和交叉重复口径，也说明原始平台内容没有再分发。 机器可以查结构，语义需要另外验收 字段齐全、JSON 可解析、记录 ID 不重复，是必要检查。判断一句话是否真的接受方案，是否真的付费，以及付款对象是什么，需要回到上下文。 机器标签统计应明确称为候选标签分布。抽检可以估计错误与发现系统偏差，但必须说明抽样方法和范围；不能把一个小样本的通过率套到全部来源。 用修订记录处理冲突 若旧正文与当前表格冲突，先固定两个版本，再核对过滤条件。确认是错误时更正，并说明影响了哪个结论；如果口径不同，保留两个分母及用途。不要悄悄替换数字后继续沿用旧论证。 一个值得维护的知识单元，应该能单独更新某个判断，而不必每次重写整份行业报告。文章保留当时的完整论证，知识页承接后续修订，两者互相指向。 公开不等于原始材料全部上传 作者自己的分析、处理方法和经过审查的汇总可以公开。第三方原文、平台账号标识、企业内部计划和个人资料，需要另外的权限与使用边界。脱掉名字不一定完成匿名化，小样本背景仍可能识别人或组织。 这个知识库采用公开白名单：只有经过内容检查的派生文件进入站点仓库。原始资料留在独立的本地工作区，不能仅用页面隐藏或草稿标记隔离。 对自己的方法也保留反证 如果维护成本高到无法持续，应减少字段、缩小发布范围，优先保住来源、日期、分母和关键反证。资料系统的价值在于提高下一次判断质量，不在于积累越来越多却没人复核的字段。"
    },
  
    {
      "id": "note-hardware-innovation",
      "kind": "note",
      "slug": "hardware-innovation",
      "title": "硬件创新：按不可逆投入组织决策",
      "summary": "让价值验证、系统集成、供应链与经营承诺接得上，避免将样机成功当成产品完成。",
      "url": "/knowledge/hardware-innovation/",
      "lang": "zh-CN",
      "collections": ["product-research"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "让价值验证、系统集成、供应链与经营承诺接得上，避免将样机成功当成产品完成。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": [],
      "text": "智能硬件同时承担两类变更：软件仍可更新，器件、结构、模具和库存却可能已经锁定。组织机制需要围绕这些不同的变更成本建立。 原长文按创始人类型、团队阶段与管理原型展开。这里保留更通用的主线：每一次扩大不可逆投入之前，应该补上哪一类证据。 阶段门应决定投入，而不只是检查进度 技术样机证明关键能力做得出来，用户原型帮助判断结果是否重要，工程验证检查设计是否可实现，试制与量产验证交付条件。不同产品会采用不同阶段安排，但证据职责不能混在一起。 演示成功之后，还要追问它依赖了哪些条件：是谁准备环境，失败时谁介入，零件来自哪里，更换与制造成本如何。被演示隐藏的工作，往往会在交付时重新出现。 三种责任必须有人承担 产品负责人解释用户和当前版本的价值边界；系统负责人把目标转成可以同时满足的指标与接口；项目负责人处理跨专业依赖、集成计划与风险升级。 这些是责任，不是规定所有小团队必须立刻招齐三个专职岗位。兼任可以，但关键取舍要有人明确作出，不能在多个部门之间悬空。 原文给出的团队规模适合作为特定复杂度的规划示例，不应当作行业通用人数标准。本页不沿用一套固定编制。 冻结范围，同时保留改变的路径 冻结不是禁止学习，而是说明这轮交付以什么为基线。新增需求应展示对成本、周期、质量和已确认体验的影响，再决定本轮纳入、下轮处理或放弃。 软件更新也不是免费的补救。它可能影响能耗、性能、安全和售后；若原硬件能力不足，更新不能凭空补出器件或散热空间。 从一款产品走向多款产品 复用平台值得投入的前提，是不同项目反复需要同一项能力，并能接受共同的边界。过早统一会限制探索，过晚统一会造成重复建设。 经营责任也需覆盖上市后的服务、返修、库存和生命周期。只在发布会完成时庆祝，会让团队低估交付给用户之后仍要承担的工作。 我会用一个问题检查组织是否真正成熟：关键负责人离开某次会议后，团队还能否按照共同基线处理变化、暴露风险并完成取舍？如果不能，组织可能仍靠个人协调维持。"
    },
  
    {
      "id": "note-household-robots",
      "kind": "note",
      "slug": "household-robots",
      "title": "家庭机器人：任务承诺与失败恢复",
      "summary": "先确定替谁完成什么，再比较身体；把救援、维护、噪音和多成员权限计入使用成本。",
      "url": "/knowledge/household-robots/",
      "lang": "zh-CN",
      "collections": ["home-robots"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "先确定替谁完成什么，再比较身体；把救援、维护、噪音和多成员权限计入使用成本。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["irobot-care"],
      "text": "家庭机器人增加的不只是动作能力，还会改变家庭成员之间的责任分配。谁设置它、谁收到告警、谁在卡住以后赶回家处理，可能与购买者和受益者并不是同一个人。 因此我会把产品承诺写成“在什么条件下，替谁完成哪件事”，再讨论四足、人形、轮式或固定设备。 从任务与现有替代方案比较 任务 常见替代 新机器需要证明的增量 清洁 人工、保洁、既有扫地机 净节省劳动，且维护可承担 远程看一眼 固定摄像头、可转动镜头、家人 移动带来的信息增量足以覆盖成本 取送物品 固定收纳、家人、简单辅助设施 完整任务的可靠性与恢复成本 情感互动 宠物、玩具、远程交流 新鲜感过去后仍有关系价值 这是一张产品分析表，不是市场需求排名。开放场景中有人表达孤独、照护压力或行动困难，不能直接推出他接受机器人，更不能推出接受某种身体。 成功之外，还要设计五个状态 任务可以完成、自动重试、换一种安全方法、请求接管，或者停止并说明未完成部分。每种状态都要让用户知道发生了什么。 请求接管应该给出地点、失败原因、已尝试动作和最小必要帮助。让用户从头排查，实质上把系统工程工作转嫁给家庭。自动重试也需要边界，反复尝试可能扩大物理损失。 维护同样是产品任务。iRobot 的特定系列维护说明列出滤网、刷子、传感器和充电触点的护理要求。这能证明自动清洁仍包含人的维护劳动，不能用来推断其他品牌的故障率。 已有研究能支持多强的结论 本地家庭机器人语料重计为 208,755 条记录，来源明显集中，自动标签还存在形态和词义误判。最新结构复核公开的是计数与限制，不把规则编码的“链条闭合”当作经过人工验证的购买需求。 一个尤其需要纠正的推断是：扫地机的使用或“为父母购买”材料，可以帮助理解家庭购买链；它不能直接验证人形照护、机器狗安防或医疗安全效果。 下一轮应怎样测试 用同一项任务比较机器人与现有替代方案，记录合格完成、人工救援次数、每次救援时间、日常维护和被放弃的任务。购买者、使用者和实际维护者分别访谈。 早期不必承诺包办家庭事务。把一个窄承诺做得可信，并保留清晰的求助和退出机制，更容易得到有意义的长期使用证据。"
    },
  
    {
      "id": "note-local-ai",
      "kind": "note",
      "slug": "local-ai",
      "title": "本地 AI：任务成立之后，设备才有购买理由",
      "summary": "把离线、隐私和算力拆成任务条件，再比较已有电脑、共享设备与专用硬件的完整成本。",
      "url": "/knowledge/local-ai/",
      "lang": "zh-CN",
      "collections": ["local-ai"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "把离线、隐私和算力拆成任务条件，再比较已有电脑、共享设备与专用硬件的完整成本。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["lmstudio-offline","ollama-context","jetson-lifecycle"],
      "text": "本地 AI 有明确用途，但“愿意在本地运行”与“愿意新增一台设备”是两次不同的选择。用户可能已经拥有足够好的电脑，也可能愿意接受云端服务。设备需要解释自己的增量价值。 将口号还原成约束 常见理由 需要进一步确认 离线 哪些步骤必须断网？模型、检索、授权和外部工具是否都能工作？ 隐私 哪些数据不能离开哪条边界？谁能查看文件、日志和结果？ 低延迟 比较的是首次响应，还是完整任务和排队时间？ 低成本 是否计入设备折旧、安装、模型维护、耗电与失败处理？ 长期运行 任务是否高频到值得占用一台持续在线的设备？ 这些条件可能支持专用硬件，也可能支持给现有设备安装软件。判断不应提前绑定形态。 已有设备是必须比较的替代方案 LM Studio 的文档说明，已下载的模型及部分本地工作流可以离线使用。这至少构成一个基线：先在现有电脑上完成任务，再寻找必须购买新设备的原因。外部工具是否联网仍需单独检查。官方说明 模型文件装得下，不代表任务运行得好。上下文、并发和其他进程也占用资源。Ollama 的文档明确提醒，更长上下文需要更多内存；仅比较参数量或算力峰值，会漏掉实际工作负载。上下文文档 什么任务值得进一步验证专用设备 持续监听本地事件、为多人提供服务、连接现场设备，或需要将研究者的个人电脑与执行环境分开，都可能增加专用设备的价值。这里列的是待检验条件，不是已经证实的市场规模。 用同一组任务，比较现有电脑、本地专用设备和允许范围内的云端方案。记录质量、耗时、人工介入、断网表现与维护负担。只有增加的持续使用价值超过新增负担，才有购买理由。 硬件还带来供货、替换和系统维护责任。NVIDIA 对模组与开发套件的生命周期作了不同说明，这提醒我们不要把开发验证条件直接当成产品交付承诺。生命周期说明 本轮资料允许说到哪里 所核对的本地 AI 主语料有 211,088 条记录，Reddit 占约 90.21%。这是特定采集范围的讨论材料，不是购买意愿调查；该快照没有 E0–E5 编码字段。完整口径见数据说明。它能帮助找任务与失败线索，不能证明一类新硬件已经拥有需求。"
    },
  
    {
      "id": "note-manipulation-data",
      "kind": "note",
      "slug": "manipulation-data",
      "title": "灵巧操作：手、触觉与数据如何互相约束",
      "summary": "以目标任务和可观测的接触过程评价灵巧手，避免自由度、数据小时数与平台价值之间的跳跃。",
      "url": "/knowledge/manipulation-data/",
      "lang": "zh-CN",
      "collections": ["embodied-industry"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "以目标任务和可观测的接触过程评价灵巧手，避免自由度、数据小时数与平台价值之间的跳跃。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["openvla","droid"],
      "text": "灵巧操作同时面对物体形状、接触、摩擦、形变和控制误差。一只手能摆出很多姿态，不等于它能稳定操作目标物体；一批视频看起来丰富，也不等于提供了训练所需的动作信息。 我的研究重点是硬件、感知、数据与任务之间的适配。特定公司的非公开路线和参数不进入这个公共框架。 先定义任务空间，再讨论自由度 抓取刚性盒子、插拔线束、拧盖子和整理织物，要求不同。评估时先写出物体变化、成功条件、允许耗时和失败后果，再比较夹爪、欠驱动手与高自由度手。 增加自由度可能扩大可达动作，也增加驱动、控制、故障点与学习空间。它的收益应该表现为目标任务覆盖或可靠性提升，不应只靠外观接近人手来证明。 数据需要记录什么 数据来源 能提供什么 不能直接补齐什么 普通视频 语义、物体和动作线索 执行器状态、接触力、可执行动作 人类第一视角 实际工作情境与行为变化 人手到机器人动作的对应关系 真机遥操作 观察、机器人状态、动作与结果 采集成本、覆盖偏差、示范质量 仿真 可控条件与大量试错 未建模的材料、接触和真实差异 实际部署 目标任务、失败与人工介入 自动形成高质量训练集 DROID把跨环境操作数据和采集体系一起公开；OpenVLA提供视觉语言动作模型的研究路径。两者说明数据与模型可以被具体检查，但不能单凭数据集规模判断某款手或某项家庭任务已经可用。 触觉的价值要落在接触问题上 视觉主要帮助定位与识别，力觉和触觉可以补充接触后的信息。但不同传感器能测什么、噪声有多大、如何标定、能用多久，并不一致。 有触觉传感器，不代表策略有效利用了触觉。验证时应比较同任务的视觉基线与加入触觉后的表现，保留滑移、遮挡、材料变化和传感器退化条件。额外维护与系统成本也要计入。 数据基础设施何时可能成为平台 如果某种硬件拥有稳定接口、可批量供给和维护能力，算法与数据有机会围绕它积累。这个平台假设还需要跨客户复用、独立开发者采用和持续任务效果来验证。 卖出许多只手，与形成通用技能生态之间隔着数据协议、标注、评测和权利边界。下一步值得跟踪的，是一项技能换手、换物体、换场地后的效果，而不仅是新增多少数据小时。"
    },
  
    {
      "id": "note-organization-responsibility",
      "kind": "note",
      "slug": "organization-responsibility",
      "title": "组织责任：先修接口，再判断谁不合适",
      "summary": "把组织合法性落到决策记录、跨团队承诺与坏消息出现的时间，不把信任简化成满意度。",
      "url": "/knowledge/organization-responsibility/",
      "lang": "zh-CN",
      "collections": ["product-research"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "把组织合法性落到决策记录、跨团队承诺与坏消息出现的时间，不把信任简化成满意度。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": [],
      "text": "组织图回答谁向谁汇报，未必回答一个跨团队结果由谁负责。产品承诺、系统限制、研发排期和客户期待如果互不相认，每个部门都可能按自己的目标完成工作，整体却持续失约。 处理这种问题，先要找到责任断点，再判断结构或人员需要怎样改变。 任命之外，还需要共同工作的记录 我在原文章中用“职位合法性”与“组织合法性”区分任命带来的权力，以及团队在共同工作中形成的判断信任。这是管理实践框架，不是新的学术定义。 判断信任并不要求所有人同意结果。它需要团队知道决定依据、明确取舍、纠错路径和复盘条件，也需要见过承诺被兑现。 新负责人不必在观察与行动之间二选一 正在扩大的明确风险应立即控制。可逆、低风险的流程改进也可以尽早做。对重组、关键人事和战略转向，则应提高证据门槛。 “先了解三个月”或“上任马上换人”都不能独立构成方法。时间安排要服务于风险和证据，而不是表演某种管理风格。原文的 90 天安排在这里作为示例保留，不设为普遍期限。 四个接口比新组织图更先影响结果 目标是否描述同一个结果；决定由谁最终作出；评审是否允许暴露尚未解决的问题；跨团队承诺是否包括质量、时间和变更方式。 若项目经理只有催促权，没有升级风险的路径，增加会议也无法解决问题。若产品范围持续变化却无人承担代价，换一个研发负责人也可能继续延期。 当然，接口清楚也不能掩盖真实的能力、诚信或意愿问题。系统分析帮助做出更公平的判断，不意味着无限推迟必要的人事决定。 用行为信号检查改变 我会观察坏消息是否出现得更早，反对意见是否带着证据进入正式讨论，普通分歧是否不再全部升级到最高负责人，以及团队能否在负责人不在场时继续使用同一套标准。 这些信号本身仍需结合业务结果理解。更少升级可能意味着授权有效，也可能意味着问题被压住。需要同时查看风险暴露和交付质量，避免把一种管理口号换成另一种局部指标。 本页只整理公开管理文章中的方法，不包含具体组织的人事信息、内部评价或未公开决策。"
    },
  
    {
      "id": "note-playable-content",
      "kind": "note",
      "slug": "playable-content",
      "title": "可交互内容：用户的动作，必须对世界留下影响",
      "summary": "把连续生成的画面与可持续交互的世界分开，研究状态、规则、反馈和恢复。",
      "url": "/knowledge/playable-content/",
      "lang": "zh-CN",
      "collections": ["ai-video"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "把连续生成的画面与可持续交互的世界分开，研究状态、规则、反馈和恢复。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["world-model-taxonomy"],
      "text": "一段内容会回应用户，不意味着它已经是一个可玩的世界。如果用户拿走的物体下一轮重新出现，已经做过的选择无法继续，画面再流畅也难以形成可信的行动体验。 我的判断是：可交互内容的核心资产之一，是动作之后仍被承认的状态。画面负责表达状态，规则决定状态怎样变化，两者不能只靠下一轮语言描述碰巧保持一致。 需要决定哪些事不会凭空改变 角色身份、物品归属、空间关系、任务进度以及关键选择，都可能需要持久保存。并非所有细节都要模拟到物理精度，但哪些允许即兴、哪些必须稳定，应由体验目标决定。 例如，一个以探索为主的短篇体验可以允许场景细节变化，却仍需记住玩家已经打开了哪扇门。这里是设计示例，不是已经上线项目的使用数据。 区分三种责任 生成系统可以负责呈现新场景，规则系统负责判断动作是否允许，状态系统负责保存动作的后果。它们可以共享模型，也可以由模型和确定性代码组合实现。 越重要、越不可逆的状态，越不适合仅依赖模型“记住”。需要记录输入、变更、结果和版本，允许检查矛盾并恢复。做出一次响应与保证长期一致，是不同的成本。 世界模型的功能分类能帮助识别这些责任，但不能证明模型天然具备了完整游戏引擎。分类提案 传播效果与产品留存分开测 惊喜片段适合展示，却无法单独回答用户是否愿意继续。评测应包含重复进入、沿旧选择继续、尝试边缘动作，以及恢复中断任务。记录用户是在探索可能性，还是反复绕开系统失忆。 商业上还要区分创作者制作成本、单次运行成本与付费动机。模型每轮能生成新东西，并不意味着用户每轮都获得新价值。 本页是从创作与 Agent 系统研究中整理出的设计假设。没有把内部项目计划、融资叙事或尚未完成的产品能力当成公开成果。"
    },
  
    {
      "id": "note-research-workflows",
      "kind": "note",
      "slug": "research-workflows",
      "title": "把研究工作流接到可检查的产物上",
      "summary": "用 iRead 发现变化，用 SURE 组织证据，用知识页维护判断；工具与研究结论各自负责。",
      "url": "/knowledge/research-workflows/",
      "lang": "zh-CN",
      "collections": ["agent-systems"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "用 iRead 发现变化，用 SURE 组织证据，用知识页维护判断；工具与研究结论各自负责。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["iread","sure","transcript","agentmeasure-lab"],
      "text": "研究任务最容易停在“读了很多资料，写了一份报告”。下一次问题出现时，报告中的来源过期、数字无从重算，新的 Agent 也不知道哪些判断已经被否定。 我更希望把研究留下来的东西组织为来源记录、证据表、当前判断和验证产物。工具可以不同，这几类对象需要能够互相定位。 现有项目分别负责什么 项目 输入与产物 不负责证明什么 iRead 领域与经审核信源；事件和报告 出现很多报道不证明趋势成立 SURE 决策问题与反馈证据；研究契约、编码和审计 CLI 通过不证明市场需求真实 视频转录工具 获准处理的媒体；可核对的逐字稿 转录不等于原作者事实核验，也不授予再发布权 AgentMeasure / Lab 操作日志或实验设计；口径与结果 流水线成功不证明真实业务收益 公开知识库 经过整理的分析、引用和数据说明 不承担私有原件的全量备份 这些项目现在各有独立入口。这里描述的是一种协作方法，不声称它们已经形成自动运行、无需审阅的完整平台。 一次更新应该改变明确对象 新信息进入时，先判断它是旧事件的另一篇报道、新事实、相反证据，还是需要进一步检查的说法。只有改变研究问题的材料，才值得更新主题正文。 更新一项判断时记录：旧结论是什么，新增证据改变了哪个前提，哪些部分仍有效。原文保持可回查，当前知识页给出维护后的版本。这样可以承认过去的判断有局限，而不抹掉当时的依据。 自动化的边界 文件和来源中可能夹带指令，不能因为它们出现在研究材料里就授权工具行动。发布、发信、删除、付费与设备控制需要由任务本身授予权限。 资料去重、格式校验、指标重计适合自动化。来源是否独立、评论究竟在支持哪个产品、某项概念是否有商业意义，需要语义复核；研究工具应该把这些问题暴露出来。 如何验收这套工作流 挑一个已经有旧结论的主题，用一条新增反证走完整个流程：能否找到受影响的知识页，更新数据口径，保留原文链接，并让关联文章提示读者查看最新判断。 如果增加的只是文件数和摘要数，没有减少下一次判断所需的检索与复核成本，研究工作流还没有完成它的任务。"
    },
  
    {
      "id": "note-robot-industry",
      "kind": "note",
      "slug": "robot-industry",
      "title": "具身智能产业地图：任务、技术与商业成熟度",
      "summary": "把本体形态、技术路线、公司位置和交付证据分开，避免用同一张榜单回答不同问题。",
      "url": "/knowledge/robot-industry/",
      "lang": "zh-CN",
      "collections": ["embodied-industry"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "把本体形态、技术路线、公司位置和交付证据分开，避免用同一张榜单回答不同问题。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["openvla","droid"],
      "text": "“人形”“VLA”“灵巧手”“家庭服务”和“融资”经常被放在同一张产业图上，但它们分别是身体形态、模型方法、部件、场景和资本事件。研究时先区分层级，才能判断一条新闻究竟改变了什么。 这份地图重组了此前白皮书中的定义和框架。它服务于产品与商业判断，不给公司做未经统一口径验证的排名。 一张产业图需要两种视角 制造视角沿零部件、本体、集成与服务展开，适合研究成本、供货和责任。学习系统视角则追踪经验如何转成能力： 环节 关键对象 应检查的事实 经验 遥操作、第一视角、仿真、部署记录 有无动作、结果、失败与使用权限 模型 感知、VLA、世界模型、策略 训练和测试条件是否匹配目标任务 执行 规划、控制、手与传感器 接触、实时性与异常停止 产品 本体、交互、维护方案 能否长期承担约定任务 部署 现场流程、交付、售后 新客户能否复用已有能力 两种图互补。模型性能提高不代表整机交付改善，出货增加也不保证新增数据能进入训练。 身体是一项任务决策 平整场地内的移动操作，轮式平台值得与双足一起比较；复杂地面巡检，需要审查四足的通过性；固定工位操作，要先比较固定机械臂与专用装置。 这些是工程取舍，不能写成“某种身体永远更优”。楼梯、作用范围、负载、能耗、维护和人员共处条件变化后，选择会变化。人形的工具兼容潜力也需要由具体任务兑现。 商业成熟度需要可观察的进展 沿“受控演示—客户试点—重复交付—持续运营—复购扩张”追踪，比把论文、订单和营收混在一起更有解释力。每一步都问有没有独立客户、多少人工支持、是否达到验收条件。 平台化不再被我放在这条成熟度阶梯的最高一级。一个没有开发者生态的窄任务设备，也可能拥有成熟利润；一个开放 SDK 的研究平台，也可能尚无重复客户。平台结构与商业成熟度是两个维度。 把自主程度写进经济账 单位有效任务成本应覆盖折旧、部署、人工接管、维护、耗材与软件，分母采用客户认可的合格任务。统计口径必须说明运行时间、任务难度和失败处理。 “自主有效工作小时”适合观察趋势，但不是所有任务通用的价值指标。慢速完成与高速完成的一小时不能直接相比；对某些任务，合格件数或异常处置效果更重要。 下一步研究重点是同任务、同环境下的长期工作证据，以及新客户交付是否越来越省力。缺少这些证据时，保留技术进展判断，暂缓商业规模结论。"
    },
  
    {
      "id": "note-software-capabilities",
      "kind": "note",
      "slug": "software-capabilities",
      "title": "软件重构与能力经济",
      "summary": "界面、可调用能力、交付资产和经济价值是四个不同对象；分别判断谁掌握了什么。",
      "url": "/knowledge/software-capabilities/",
      "lang": "zh-CN",
      "collections": ["agent-systems"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "界面、可调用能力、交付资产和经济价值是四个不同对象；分别判断谁掌握了什么。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["agentmeasure-core","sure"],
      "text": "当用户把任务交给 Agent，软件的界面可能不再是每次使用都必须经过的入口。但界面使用减少，不能直接推出软件没有价值。数据库、渲染、支付执行、专有数据和现场服务，都可以通过不同入口被使用。 我的长期判断是：部分软件会围绕可调用能力重新分工。判断一家公司时，要同时看能力如何被发现，以及它最终交付的东西是否稀缺。 把四个对象拆开 对象 例子 应回答的问题 入口 App、网页、对话、CLI 谁接收用户的目标？ 接口 API、MCP、SDK、Skill 外部系统怎样调用？ 交付资产 数据、执行系统、权限、客户流程 换一个接口能否复制？ 经济结果 付费使用、可归因收益、履约成本 谁付款，为什么续费？ Skill 可以描述操作方法，MCP 可以暴露工具，CLI 可以方便确定性执行。它们不自动产生独占数据、客户信任或持续收益。反过来，接口很简单的服务也可能掌握难以替代的交付能力。 产品的基本状态要能被读取和修改 在 AI 创作工具里，只有一个导出的文件通常不够。需要持续保存人物、素材、版本、授权与修改关系。在企业流程里，需要保留订单、审批状态、参与者和不可逆动作。 这使“语义对象及其历史”成为重要产品资产。人通过界面理解和修订，Agent 通过接口操作，两者应面对同一份状态。不能给 Agent 另做一套没有权限约束、与人类界面不同步的后台捷径。 分发、使用与价值分别验证 被安装说明进入了某个环境；被展示说明进入选择范围；被选中说明一次决策发生；被调用说明执行开始。任务完成后，还要判断结果是否被接受，以及它是否比替代方案更划算。 因此，能力目录负责发现，能力经济专题维护论证，AgentMeasure研究测量。目录收录不能充当使用量，更不构成投资或采购推荐。 需要保留的反例 高频交互、精确控制、多人协作、强品牌关系的产品，可能继续拥有重要的人类入口。也有企业宁愿让 Agent 在既有软件内工作，不愿把目标交给另一个平台。 所以，“所有 App 都会消失”过于激进。“所有软件加上聊天框就能适应变化”同样缺少解释。应该逐条研究具体工作流：哪些操作可以让渡，哪些状态和责任仍需要专业系统承接。 观察周期应围绕真实客户任务。若调用增长却没有更多被接受的结果，或收入上升完全来自更高的重试成本，都不能据此确认能力经济的价值假设。"
    },
  
    {
      "id": "note-spatial-computing",
      "kind": "note",
      "slug": "spatial-computing",
      "title": "空间交互：被指向的对象，需要能被持续操作",
      "summary": "从“看、指、捏、说”延伸到对象身份、执行确认和跨步骤状态，不把空间展示等同于完整交互。",
      "url": "/knowledge/spatial-computing/",
      "lang": "zh-CN",
      "collections": ["ai-glasses"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "从“看、指、捏、说”延伸到对象身份、执行确认和跨步骤状态，不把空间展示等同于完整交互。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": [],
      "text": "在原文章里，我用“看、指、捏、说”描述一种可能的空间交互语法。这是产品判断，不是对现有平台标准的转述。它最有价值的部分，是让人直接指向环境中的对象，再表达要做什么。 但选中一个对象只是开始。如果下一步无法延续它的身份、版本和权限，空间交互仍然只是一场短暂展示。 先让对象在任务里存活 同一个对象可能同时有可见形态、文件、业务记录与操作权限。看向屏幕中的家具，不等于授权购买它；指向同事的文档，不等于拥有编辑权。 可持续操作需要回答：指向的是哪一个对象，当前状态是什么，允许哪些动作，执行结果如何回到用户面前。对于高后果动作，确认界面必须明确展示范围，不能把注视当成同意。 快交互与长任务要接得上 移动、缩放、选中之类动作需要直接反馈；跨应用整理、比较与制作可能由 Agent 承担。两种节奏可以共存。把一切改成长对话会拖慢直接操作；让所有长任务依赖手势，又会增加记忆与体力负担。 我倾向于让直接操作承担“指定对象和局部调整”，让 Agent 承担“理解目标和组织多步任务”。中间要有可见的计划、进度、暂停和恢复，尤其要显示发生了哪些状态变化。 空间研究不能被头显品类限制 本地空间世界研究中，讨论涉及建模、格式、协作、引擎、设备连接等不同领域。它们帮助发现工作阻力，却不能一并称为头显需求。一个文件在工具之间打不开，首先是交付链路问题；是否需要空间显示，需要额外论证。 这里将原报告中的线索收敛为三个研究对象：跨工具保持的对象、可解释的操作状态、能完成任务的输入输出组合。不采用未经人工回查的需求等级或意愿比例。 验证可以从普通屏幕开始 选择一个真实工作流，例如审阅并修改一个三维方案。先在普通界面记录定位对象、理解差别、表达修改和核验结果的成本，再比较空间交互改善了哪一环。 如果收益只来自更大的显示面积，就不应归因于新的智能交互。反过来，如果同一套对象与操作协议在手机、桌面和头显上都有效，价值可能主要在系统层，而不属于某一种外形。"
    },
  
    {
      "id": "note-talent-and-industry",
      "kind": "note",
      "slug": "talent-and-industry",
      "title": "人才与产业扩散：履历标签之后，还要看能力怎样迁移",
      "summary": "把创业名单、组织经验和产业结果分开，避免由少数成功公司反推人才流动的原因与成功率。",
      "url": "/knowledge/talent-and-industry/",
      "lang": "zh-CN",
      "collections": ["dji-alumni"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "把创业名单、组织经验和产业结果分开，避免由少数成功公司反推人才流动的原因与成功率。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": [],
      "text": "给创业公司加上某个大厂的“系”，便于传播，也容易把复杂经历压成一个标签。同样来自一家企业，正式任职、实习、顾问、合作与分拆并不是同一种关系；创始人和普通团队成员也不是同一种统计对象。 这轮本地名单复核最有价值的改进，是先分开这些关系，再讨论能力可能如何扩散。这里提炼方法，不把未逐一核验的履历与经营数据重新发布成事实榜单。 先确定自己在数什么 公司、品牌、创业项目和创始人可能在同一份表里出现。一个人多次创业会产生多个项目，一家公司可能运营多个品牌。同一条关系图上的节点数不能直接改写为“多少位离职者”。 成立年份也不等于离职年份。融资阶段、累计融资、估值、众筹与收入各自回答不同问题，不能为了一个传播性强的总数直接相加。 履历只是研究起点 我更关心迁移的是哪一种能力：系统集成、供应链组织、质量判断、产品定义、渠道经营，还是团队协作方式。它们需要通过实际产品和交付记录判断，不能仅凭前雇主名字确认。 离开原组织以后，新团队可能吸收其他公司、学术机构和合作伙伴的经验。把结果全部归因于一家前雇主，会漏掉这部分积累。 成功案例无法给出成功率 媒体更容易报道融资、出货与增长，沉默、停止和转向的项目更难进入名单。只收集可见案例，就没有计算失败率、离职率或创业成功率的分母。 即使名单中很多项目在相近时间出现，也需要检查采集是否重点搜索了近期新闻。研究者的检索窗口，可能制造出一段看似明显的创业浪潮。 从产业研究回到组织设计 如果一种能力可以被反复带到不同任务里，它值得作为组织建设对象。下一步应研究这种能力怎样训练、由哪些角色共同承担、依赖什么供应链与制度，以及脱离原组织后哪些部分会失效。 这个问题比复制一家明星企业的组织图更有用。它也连接本知识库的硬件方法：可迁移的能力最终需要表现为判断质量与重复交付，而不是人才名单的长度。 后续文章可以沿“工程能力如何跨品类迁移”展开。公开前仍需逐项核验引用案例，不能让方法上的谨慎被标题中的确定性抵消。"
    },
  
    {
      "id": "note-video-production",
      "kind": "note",
      "slug": "video-production",
      "title": "AI 视频生产：保留已确认的东西，再修改其余部分",
      "summary": "将首轮生成与专业交付分开，以可编辑项目、局部修改和版本资产理解创作软件价值。",
      "url": "/knowledge/video-production/",
      "lang": "zh-CN",
      "collections": ["ai-video"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "将首轮生成与专业交付分开，以可编辑项目、局部修改和版本资产理解创作软件价值。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["otio","runway-references","c2pa"],
      "text": "第一次生成回答“能不能做出这个效果”，后续修改回答“能不能按照要求完成这份作品”。专业创作软件需要长期处理第二个问题。 一个已经确认人物、台词和节奏的片段，可能只需更换背景。如果工具要求整段重做，新的画面还需要重新检查其他部分。看似只改了一处，实际重开了整份验收。 项目需要留下可以操作的结构 要保留的东西 下一次修改如何使用 对象与素材身份 找到同一个人、商品、声音和授权来源 时间与依赖关系 调整局部时知道哪些镜头和音轨受到影响 已确认的约束 保住不能改变的内容，明确尚未锁定的部分 版本与修改记录 比较结果、退回原状态、继续协作 交付条件 检查格式、字幕、画幅与渠道要求 不一定每项都由生成模型内部完成。确定性编辑、素材管理、渲染和人工判断，可以与模型共同构成生产系统。 能力示例与边界 Runway 的参考图工作流说明了图像中的身份与场景一致性已经成为具体产品能力。它可用于准备视频素材，不能直接证明任意视频编辑任务的稳定性。参考图文档 OpenTimelineIO 提供剪辑信息的交换结构，包括片段、轨道、时间、标记与元数据，但不内嵌音视频。这类工程结构提醒我们，作品不是一个孤立的视频文件；也不能误把一个交换格式当成完整生产系统。项目文档 内容来源记录有助于追溯。C2PA 提供来源凭证相关机制，并不自动判断内容为真或授予素材版权，商业使用仍须逐项确认。说明 怎样评估“更好改” 给出同样的初稿和修改单，记录修改完成时间、额外改变了多少已确认内容、多少步骤需要人工回退，以及最后是否达到要求。应包含模型直接生成、传统编辑和混合工作流的对照。 “第二次修改”是我的产品观察切口，不是声称某类软件必然取得商业优势。一次性娱乐与简单素材生成可能不需要完整项目系统。工作越依赖连续协作和反复确认，这个切口越值得验证。 原研究中关于行业规模和企业经营数据的未核验表述未纳入本页；这里保留可独立检验的产品判断。"
    },
  
    {
      "id": "note-wearables",
      "kind": "note",
      "slug": "wearables",
      "title": "AI 穿戴：可用时刻比功能清单更重要",
      "summary": "按身体位置、输入输出条件与日常使用阻力研究眼镜、耳机和其他穿戴设备。",
      "url": "/knowledge/wearables/",
      "lang": "zh-CN",
      "collections": ["ai-glasses"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "按身体位置、输入输出条件与日常使用阻力研究眼镜、耳机和其他穿戴设备。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["sure"],
      "text": "穿戴设备的能力只有在用户愿意戴着、方便触发、允许记录时才存在。拍摄、听觉与显示各自有价值，但把它们相加，得不到日常使用价值。 我更愿意从“可用时刻”理解这类产品：某项任务发生时，设备是否在身上，电量是否足够，环境是否允许输入，输出是否能被接收。 身体位置决定任务，也决定代价 眼镜靠近视线，耳机接近听觉，手表容易查看与触碰。这个位置同时带来遮挡、重量、发热、佩戴与社交条件。比较时应保持任务一致：同样是获取一句提示，听到、看到和主动拿出手机，分别打断了什么？ “模态更多”不必然更好。会议里适合的语音交互，在公共场所可能难以使用；持续视觉输入也涉及被拍摄者的同意和数据管理。产品必须提供明确的开始、停止和状态提示，而不是把记录变成难以察觉的默认动作。 把一天拆成可观察的场景 我会记录任务发生、设备可用、实际触发、输出可接受、任务结束五个节点。漏掉任何一层，都可能将功能演示误判为使用机会。 例如，用户说想记住路上见到的信息，可以先确认他现在如何记录、多久发生一次、遗忘造成什么后果。然后再比较手机拍照、语音备忘与穿戴采集。一次新奇体验只能说明愿意尝试。 这也是原文章中“身体舒适度”观点的进一步收敛：舒适度并非单独一张参数表，而是影响设备在需要时是否可用的条件。 语料要保留产品与场景的区别 本次核对的眼镜组合语料有 209,862 条记录，其中既有产品反馈，也有开放场景讨论，Reddit 占约 83.29%。不能把全部记录叫作“AI 眼镜用户评价”，也不能将机器识别的付费、复用标签直接视为购买与留存证据。 此前文章中的产品反馈子集与本轮组合快照不是同一分母，见数据口径。后续验证应从具体任务抽样，回看上下文、替代方案与实际行为；不能靠扩大关键词采集量来替代这一步。 一个值得继续研究的问题 穿戴设备是否能在少打断用户的同时，明确表达自己的状态与权限？如果用户无法知道什么时候正在记录、结果去了哪里、如何撤回，再多“无感”也可能变成负担。"
    },
  
    {
      "id": "note-world-models",
      "kind": "note",
      "slug": "world-models",
      "title": "世界模型：画面、状态与行动各自证明什么",
      "summary": "用输出契约区分视频生成、可计算仿真与行动规划，避免把视觉效果当成物理能力。",
      "url": "/knowledge/world-models/",
      "lang": "zh-CN",
      "collections": ["embodied-industry"],
      "updated": "2026-08-31",
      "version": "持续修订的研究笔记",
      "access": "全文公开",
      "source_label": "本站已公开研究笔记",
      "use_for": "用输出契约区分视频生成、可计算仿真与行动规划，避免把视觉效果当成物理能力。",
      "public_scope": "研究笔记全文",
      "boundary": "阶段分析；具体事实、来源与修订范围以正文为准。",
      "review_status": "公开正文已收录，持续修订",
      "source_page": null,
      "study_id": null,
      "downloads": null,
      "source_ids": ["world-model-taxonomy","openvla","droid"],
      "text": "“世界模型”适合描述研究方向，却不足以定义一份产品验收单。同样是一段杯子被推动的视频，一个系统可能只生成画面，另一个保存可计算的物体状态，第三个据此选择机器人的动作。三者的错误会造成不同后果。 先问下游拿到什么 World Labs 在 2026 年 6 月提出按功能区分 renderer、simulator 和 planner。我借用这个分类帮助分析产品；它是一个研究团队的提案，不是统一标准。原文 下游得到的东西 我的验收问题 画面与声音 镜头是否连续，指定对象是否保持一致，修改是否可控？ 可计算的场景状态 尺度、碰撞、材质和状态变化能否支持目标计算？ 行动或行动序列 在给定观测与限制下，任务能否安全完成，失败能否识别？ 这张表不是模型排行榜。一套系统可以同时承担几项职责，也可以把职责交给不同模块。 可看与可用之间，需要一个明确的转换 视频给出了一个可能的未来，但机器人还需要动作的坐标、时间、力度以及执行后的新观测。三维场景可以支持漫游，也未必包含适合接触任务的材料参数。把结果接入下游时，应写清楚保留了什么，估计了什么，哪些量根本不存在。 例如，将生成场景用于机器人训练，至少要检查比例、碰撞几何、动作接口和任务结果定义。这里的重点是检查项目自身的训练契约，不是要求每种娱乐内容都具有工程仿真的精度。 数据价值来自补上哪一种缺口 真实视频可以丰富外观与事件知识；带动作和结果的机器人轨迹，才让特定执行条件进入数据。DROID 和 OpenVLA 展示了真机数据、任务适配与策略学习的具体路径，不能据此跳到“看完互联网视频就会做家务”。DROID、OpenVLA 评估新增数据时，我会比较同一组任务上的失败类型：是对象没认对、接触时滑落、没有察觉失败，还是下一步计划错误。数据规模只有落到这些差别上，才有产品意义。 目前保留的判断 生成、仿真与规划可能相互提供训练信号，但“可能融合”不能当作已经具备通用行动能力的证据。白皮书中的产业讨论在这里拆成三个可单独验证的问题：结果是否可控、状态是否可信、行动是否可靠。它们也分别连接创作软件、空间工具和机器人。"
    }
  
  ]
}