{ "schema_version": "1.0", "updated": "2026-08-31", "scope": "Public content only; knowledge notes are evolving author analysis. Existing essays retain their publication context. English translations are separate pages, not independent evidence.", "topics": [{"id":"agent-systems","title":"Agent 与软件系统","summary":"让软件接住长期任务：上下文、执行状态、能力分发与计量。","question":"一个 Agent 怎样从一次回答，变成可以持续交付的系统？","start":"agent-context","related":["ai-devices","product-research"]},{"id":"robotics","title":"具身智能与机器人","summary":"用任务、可靠性和交付成本理解身体、模型、数据与商业化。","question":"机器人完成的工作，是否足以覆盖它给人增加的工作？","start":"robot-industry","related":["ai-devices","organization"]},{"id":"ai-devices","title":"AI 终端与新交互","summary":"从日常使用条件理解眼镜、空间交互、AI PC、NAS 与本地 Agent。","question":"新的终端形态，为哪项任务创造了已有设备没有的价值？","start":"local-ai","related":["agent-systems","creative-tools"]},{"id":"creative-tools","title":"创作工具与数字制造","summary":"把生成结果变成可以修改、复用和交付的作品与实物。","question":"生成越来越便宜之后，谁负责把结果做对、改好并交付？","start":"video-production","related":["agent-systems","product-research"]},{"id":"product-research","title":"产品研究与商业判断","summary":"从场景与替代方案找需求，用证据决定下一笔投入。","question":"手里的资料究竟允许我们做出哪一级判断？","start":"demand-evidence","related":["robotics","organization"]},{"id":"organization","title":"组织建设与产业落地","summary":"把技术、产品、制造与经营放在同一套决策和责任体系里。","question":"团队怎样将一次成功演示，变成重复交付与持续经营？","start":"hardware-innovation","related":["product-research","robotics"]}], "records": [ { "id": "knowledge-agent-context", "kind": "knowledge", "lang": "zh-CN", "title": "Agent 运行时：上下文、状态与权限", "topic": "agent-systems", "url": "/knowledge/agent-context/", "summary": "把 Context Recommendation 收敛为可实现的职责：这一步需要什么信息、能做什么，以及如何恢复。", "updated": "2026-08-31", "related": ["software-capabilities","research-workflows","local-ai"], "related_articles": ["/notes/agent-context-recommendation-after-rag/"], "source_ids": ["agentmeasure-core","iread"], "text": "一个 Agent 可以在每轮调用同一个模型，却需要不同的工作环境。研究阶段需要来源，编辑阶段需要当前文件，发布阶段还需要目标、授权和失败处理。把全部资料塞进长上下文，解决不了这些差别。 我把这项职责称为 Context Recommendation：依据当前任务，为下一步组合信息、能力、状态与约束。这是我的产品架构提案，不是已有统一标准，也不要求必须训练一个推荐模型。 先分清六类上下文 对象 需要保留的内容 常见失败 指令 目标、交付物、禁止事项 把来源文章中的指令当成用户要求 记忆 已确认偏好、历史决定、有效期 临时意见变成永久规则 知识 原始来源、观察日期、反证 旧报告压过新事实 能力 工具输入输出、前置条件 工具可见却无法真正执行 状态 文件版本、任务进度、待处理结果 重复操作或覆盖新修改 权限 数据范围、动作范围、审批条件 模型“认为获准”就执行 权限需要执行层检查。写进提示词的规则可以帮助模型规划，不能替代文件隔离、接口授权和网络策略。 一个能逐步实现的运行回路 在模型调用前，先读取最新任务状态，检索候选材料；过滤无权限、过期和与当前步骤无关的内容；再决定哪些原文、摘要、工具和规则进入这一轮。执行后记录事实、输出和状态变化。 先用确定性规则处理权限、版本和预算，检索处理文档候选，再考虑排序模型。复杂度应由真实失败驱动，不必先搭一套庞大的“认知架构”。 任务状态与聊天历史应分开。对话中说“已经发布”不是发布凭证；应该保存目标版本、执行结果和可回查的地址。摘要可以帮助继续工作，关键事实仍须能回到原始事件。 用失败类型指导评测 同一个错误答案，原因可能是没有召回资料、召回了过期版本、模型误读，或工具执行失败。只看最终分数，无法判断该改检索、模型还是运行时。 评测时至少保留任务版本、可见资料、允许的工具、输出和验收结果。对长任务增加中断恢复、用户改需求、来源互相矛盾这几类测试。它们比“连续跑了多少轮”更接近产品可靠性。 什么会推翻这套投入 对于输入固定、步骤短、没有外部动作的任务，普通检索与清晰模板可能已经足够。运行时工程增加的延迟、维护和调试成本必须算进去。 下一步验证应比较同一组任务的完成质量、人工修正时间和越权拦截效果。不能因为接入了更多上下文，就宣称任务价值提高。 本页把原文章中较宽的概念收敛为实现职责；完整论证仍保留在原文。" },{ "id": "knowledge-agent-measurement", "kind": "knowledge", "lang": "zh-CN", "title": "Agent 计量：执行事实、任务结果与价值", "topic": "agent-systems", "url": "/knowledge/agent-measurement/", "summary": "明确分母和证据边界，避免把重试、调用成功、被使用和业务收益混成一个数字。", "updated": "2026-08-31", "related": ["software-capabilities","demand-evidence","evidence-maintenance"], "related_articles": ["/notes/agent-usage-measurement-standard/","/notes/agentmeasure-from-spec-to-evidence/","/notes/every-agent-usage-number-is-self-reported-zh/"], "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": "knowledge-alternatives-entry", "kind": "knowledge", "lang": "zh-CN", "title": "替代方案与市场进入：让下一站回答最重要的未知", "topic": "product-research", "url": "/knowledge/alternatives-entry/", "summary": "把竞争分析从同类产品参数表扩展到真实替代行为，并用证据职责选择进入顺序。", "updated": "2026-08-31", "related": ["demand-evidence","local-ai","desktop-manufacturing"], "related_articles": ["/notes/competitive-analysis-software-hardware/","/notes/market-roles-remove-uncertainty/"], "source_ids": ["sure"], "text": "竞争对手可以是另一家公司，也可以是用户已有的工具、人工服务，或者暂时不做。只比较同形态产品，很容易把一整个不需要该形态的人群漏掉。 本地 AI 的替代方案包含现有电脑，桌面制造的替代方案包含代加工，家庭机器人的替代方案包含家务习惯与专用家电。共同点是：用户购买结果，我们却容易按自己的产品分类寻找对手。 用同一个任务比较完整代价 一张有效的比较表，至少要固定任务、质量门槛和使用条件，再记录开始使用、完成任务、处理失败与持续维护的成本。省下执行时间，却增加更多准备和核验，不一定构成改善。 软件与硬件的差别在于代价如何发生。软件可能有迁移、集成和权限成本；硬件还增加空间、耗材、物流与维修。不能用“免费软件”或“一次买断”抹去完整使用成本。 市场承担不同的证据职责 我在原文章中将 Geek、Professional、领域 B 端和大众消费者理解为不同证据环境，而非必须依次通过的升级路线。 愿意折腾的人擅长暴露能力边界，却可能替产品承担配置工作；专业用户能评价工作流，却可能要求小众控制；组织客户能检验部署与服务，却可能用定制收入掩盖不可复制；大众市场能检验低门槛，却可能让曝光遮住留存不足。 进入顺序应取决于最重要的未知。如果现在最不确定的是完整部署成本，再多个人用户试用也未必能回答。 事先决定什么结果会改变路线 试点前写下：这次验证哪个假设，什么行为支持它，什么结果构成反证，何时停止或转向。标准需要时间与场景边界，不用统一的漂亮数字。 例如，一个专用创作工具可以先验证反复修改是否明显减少人工重做，再考虑扩大获客。这里是实验顺序建议，不是预设一定要收费多少或找到多少用户。 保留三种常被忽略的结果 用户觉得问题不重要；现有方案已经足够；新方案有价值，但不值得承担切换成本。这三种结果都应该进入结论，且会导致不同决定。 这使竞争研究与需求研究接到了一起：前者解释用户为什么会留下，后者解释用户为什么值得改变。两者都不该服务于证明自己已经选好的外形一定正确。" },{ "id": "knowledge-demand-evidence", "kind": "knowledge", "lang": "zh-CN", "title": "需求证据：一条反馈究竟能支持什么决定", "topic": "product-research", "url": "/knowledge/demand-evidence/", "summary": "保留场景、替代方案、接受条件与行为之间的联系，不让语料规模冒充需求验证。", "updated": "2026-08-31", "related": ["alternatives-entry","evidence-maintenance","agent-measurement"], "related_articles": ["/notes/scene-user-demand-evidence-research/"], "source_ids": ["sure"], "text": "资料越多，越容易把“找到很多相关讨论”误写成“需求已经验证”。研究的关键动作，是让每条材料只承担它实际支持的判断。 SURE 是我用于整理这件事的方法与工具。它区分场景、问题、替代行为、方案接受和商业行为，要求证据能回到来源。软件负责检查结构，研究者负责解释语义与作出决定。项目与协议 证据等级不是市场成熟度阶梯 等级 记录的内容 不能直接推出 E0 活动、角色、场景背景 存在未满足需求 E1 明确任务、困难或目标 愿意换一种解决办法 E2 当前做法、绕行、失败或切换成本 接受研究中的新方案 E3 对该方案在给定条件下的接受或偏好 已经购买或持续使用 E4+ / E4− 商业意图 / 拒绝、取消、退货等反证 所有人具有同样意愿 E5 付费持有、部署、复用等已发生行为 这些行为由产品某项功能导致 同一角色、场景和任务中的问题链、方案链与行为链，才能连接起来判断。把甲的抱怨、乙的付费和丙的长期使用拼在一起，会制造一位根本不存在的“完整用户”。 先比较用户现在怎样解决 “想要一个机器人帮忙”可能只是表达结果愿望。用户如何处理这件事、频率多高、付出什么、为什么旧方案不够，才让新产品有比较对象。 满意替代方案应保留。它可能说明这个市场已有足够好的答案，也可能指出新方案需要跨过多高的门槛。只收抱怨会把研究变成论证既定方案的材料库。 自动编码只能产生待复核候选 一次公开讨论中的 “return” 可能指退货，也可能指程序返回；“买给父母的扫地机”不能直接变成购买通用照护机器人的证据。出现价格还可能是其他产品、服务或无关支出。 本轮三组语料重计验证了记录数、字段和来源分布，没有逐条确认机器标签。统计见数据页。CLI 检查通过与研究结论通过，是两次不同的验收。 让研究决定下一项行动 对一个拟进入开发的场景，我希望研究交付四样东西：目前最强的支持证据、最强的反证、仍未跨过的判断门槛，以及能改变投入决定的下一次验证。 如果缺的是方案接受，就设计可理解的原型；缺的是交付成本，就做带完整支持记录的试点。继续扩大背景语料，通常无法弥补这两类缺口。 本页把原研究长文收敛为阅读和行动入口。具体数据契约及命令用法仍以项目仓库为准，避免在知识库维护第二套容易过期的工具说明。" },{ "id": "knowledge-desktop-manufacturing", "kind": "knowledge", "lang": "zh-CN", "title": "桌面制造：从生成设计到做出合格实物", "topic": "creative-tools", "url": "/knowledge/desktop-manufacturing/", "summary": "研究材料、工艺、设备状态与质检如何把数字创意变成可重复交付。", "updated": "2026-08-31", "related": ["video-production","hardware-innovation","alternatives-entry"], "related_articles": [], "source_ids": ["prusa-settings"], "text": "生成一张漂亮的设计图，与做出一件尺寸正确、强度足够、能按时交付的实物，中间还有许多决定。桌面制造的 AI 机会，应沿着这些决定寻找。 我把原研究中的设备和公司材料重新组织为一条工作链：需求与设计、可制造性判断、材料与工艺、设备执行、质检与返工、交付。公司目录留在来源侧，不能替代这条任务链。 工艺建议需要知道现场条件 同一个造型，换材料、喷嘴、支撑方式或用途，可能需要不同设置。PrusaSlicer 的打印设置文档展示了这类参数空间；它提供具体技术依据，不支持“某个模型能一键解决全部工艺”的结论。打印设置 一个有用的工艺助手，应知道当前设备、材料与目标，也应说明建议适用条件。拿不到条件时，先提出需要确认的问题，比输出一套看似完整的参数更可靠。 失败是数据，但不是自动变成知识 失败照片可以帮助识别外观异常，仍需联系当时的配置、材料状态、环境和设备记录。否则，相似外观可能来自不同原因；下一次照搬调整也未必有效。 应将建议、执行参数与结果连起来，并保留人工修正。评估时看同类任务的首次合格率、材料浪费、处理时间和返工负担。这里给出的是指标建议，尚未提供真实实验提升数字。 多设备平台先解决差异 打印、雕刻与切割共享部分设计和订单流程，但执行约束、材料风险与验收条件不同。统一入口可以降低切换成本，统一到抹去工艺差别则会增加错误。 跨设备软件更适合先统一任务描述、文件版本、设备能力和结果记录。高风险执行应由设备侧限制和人工确认承担，不能仅依赖生成内容中的提醒。 商业判断从持续使用开始 设备销量不能直接推出软件订阅或耗材收入。还需知道买家是否持续开机、做什么、失败后是否继续，以及现有切片软件、代加工服务和成熟工艺能解决多少问题。 消费兴趣、创作者工作室与小批量生产的要求可能不同。下一轮应按任务与交付责任抽样，而不是把所有桌面设备都放进一个市场故事。" },{ "id": "knowledge-evidence-maintenance", "kind": "knowledge", "lang": "zh-CN", "title": "研究维护：数字、版本与公开边界", "topic": "product-research", "url": "/knowledge/evidence-maintenance/", "summary": "让报告能被持续修正：固定分母、保存来源版本、区分机器标签与人工判断。", "updated": "2026-08-31", "related": ["demand-evidence","research-workflows","agent-measurement"], "related_articles": ["/notes/scene-user-demand-evidence-research/","/notes/agentmeasure-from-spec-to-evidence/"], "source_ids": ["sure","agentmeasure-core"], "text": "研究报告过期，不一定是行业发生了变化。也可能是数据文件已经更新，正文还保留旧数字；或者同一个名称，先后指代原始记录、筛选子集与编码结果。 这次整理把报告的“内容版本”和“数据版本”分开保存。公开页面标注复核日期，数据发布保留输入快照摘要、统计方法和不支持的推论。 一组数字至少带四个条件 统计单位是什么，纳入了谁，覆盖哪个时间，如何从输入计算。条目、评论、项目、用户和需求不可以互换。不同来源中的同文转载，也不能充当多份独立支持。 本次核对的三组语料合计包含 629,705 次记录，但跨组存在规范化后的完全相同文本。这个总和不表示独立用户或已经验证的需求。即使完全去重，同一人的多次发言仍可能存在。 公开汇总保留每组分母、来源集中度和交叉重复口径，也说明原始平台内容没有再分发。 机器可以查结构，语义需要另外验收 字段齐全、JSON 可解析、记录 ID 不重复，是必要检查。判断一句话是否真的接受方案，是否真的付费，以及付款对象是什么，需要回到上下文。 机器标签统计应明确称为候选标签分布。抽检可以估计错误与发现系统偏差，但必须说明抽样方法和范围；不能把一个小样本的通过率套到全部来源。 用修订记录处理冲突 若旧正文与当前表格冲突，先固定两个版本，再核对过滤条件。确认是错误时更正，并说明影响了哪个结论；如果口径不同，保留两个分母及用途。不要悄悄替换数字后继续沿用旧论证。 一个值得维护的知识单元，应该能单独更新某个判断，而不必每次重写整份行业报告。文章保留当时的完整论证，知识页承接后续修订，两者互相指向。 公开不等于原始材料全部上传 作者自己的分析、处理方法和经过审查的汇总可以公开。第三方原文、平台账号标识、企业内部计划和个人资料，需要另外的权限与使用边界。脱掉名字不一定完成匿名化，小样本背景仍可能识别人或组织。 这个知识库采用公开白名单：只有经过内容检查的派生文件进入站点仓库。原始资料留在独立的本地工作区，不能仅用页面隐藏或草稿标记隔离。 对自己的方法也保留反证 如果维护成本高到无法持续，应减少字段、缩小发布范围，优先保住来源、日期、分母和关键反证。资料系统的价值在于提高下一次判断质量，不在于积累越来越多却没人复核的字段。" },{ "id": "knowledge-hardware-innovation", "kind": "knowledge", "lang": "zh-CN", "title": "硬件创新：按不可逆投入组织决策", "topic": "organization", "url": "/knowledge/hardware-innovation/", "summary": "让价值验证、系统集成、供应链与经营承诺接得上，避免将样机成功当成产品完成。", "updated": "2026-08-31", "related": ["organization-responsibility","robot-industry","desktop-manufacturing"], "related_articles": ["/notes/hardware-innovation-organization-management/","/notes/from-ai-software-to-physical-world/"], "source_ids": [], "text": "智能硬件同时承担两类变更：软件仍可更新，器件、结构、模具和库存却可能已经锁定。组织机制需要围绕这些不同的变更成本建立。 原长文按创始人类型、团队阶段与管理原型展开。这里保留更通用的主线：每一次扩大不可逆投入之前，应该补上哪一类证据。 阶段门应决定投入，而不只是检查进度 技术样机证明关键能力做得出来，用户原型帮助判断结果是否重要，工程验证检查设计是否可实现，试制与量产验证交付条件。不同产品会采用不同阶段安排，但证据职责不能混在一起。 演示成功之后，还要追问它依赖了哪些条件：是谁准备环境，失败时谁介入，零件来自哪里，更换与制造成本如何。被演示隐藏的工作，往往会在交付时重新出现。 三种责任必须有人承担 产品负责人解释用户和当前版本的价值边界；系统负责人把目标转成可以同时满足的指标与接口；项目负责人处理跨专业依赖、集成计划与风险升级。 这些是责任，不是规定所有小团队必须立刻招齐三个专职岗位。兼任可以，但关键取舍要有人明确作出，不能在多个部门之间悬空。 原文给出的团队规模适合作为特定复杂度的规划示例，不应当作行业通用人数标准。本页不沿用一套固定编制。 冻结范围，同时保留改变的路径 冻结不是禁止学习，而是说明这轮交付以什么为基线。新增需求应展示对成本、周期、质量和已确认体验的影响，再决定本轮纳入、下轮处理或放弃。 软件更新也不是免费的补救。它可能影响能耗、性能、安全和售后；若原硬件能力不足，更新不能凭空补出器件或散热空间。 从一款产品走向多款产品 复用平台值得投入的前提，是不同项目反复需要同一项能力，并能接受共同的边界。过早统一会限制探索，过晚统一会造成重复建设。 经营责任也需覆盖上市后的服务、返修、库存和生命周期。只在发布会完成时庆祝，会让团队低估交付给用户之后仍要承担的工作。 我会用一个问题检查组织是否真正成熟：关键负责人离开某次会议后，团队还能否按照共同基线处理变化、暴露风险并完成取舍？如果不能，组织可能仍靠个人协调维持。" },{ "id": "knowledge-household-robots", "kind": "knowledge", "lang": "zh-CN", "title": "家庭机器人：任务承诺与失败恢复", "topic": "robotics", "url": "/knowledge/household-robots/", "summary": "先确定替谁完成什么，再比较身体；把救援、维护、噪音和多成员权限计入使用成本。", "updated": "2026-08-31", "related": ["robot-industry","wearables","demand-evidence"], "related_articles": ["/notes/home-robots-harder-richer/","/notes/robots-give-people-new-bodies/","/notes/home-robots-recovery-burden/"], "source_ids": ["irobot-care"], "text": "家庭机器人增加的不只是动作能力，还会改变家庭成员之间的责任分配。谁设置它、谁收到告警、谁在卡住以后赶回家处理，可能与购买者和受益者并不是同一个人。 因此我会把产品承诺写成“在什么条件下，替谁完成哪件事”，再讨论四足、人形、轮式或固定设备。 从任务与现有替代方案比较 任务 常见替代 新机器需要证明的增量 清洁 人工、保洁、既有扫地机 净节省劳动，且维护可承担 远程看一眼 固定摄像头、可转动镜头、家人 移动带来的信息增量足以覆盖成本 取送物品 固定收纳、家人、简单辅助设施 完整任务的可靠性与恢复成本 情感互动 宠物、玩具、远程交流 新鲜感过去后仍有关系价值 这是一张产品分析表，不是市场需求排名。开放场景中有人表达孤独、照护压力或行动困难，不能直接推出他接受机器人，更不能推出接受某种身体。 成功之外，还要设计五个状态 任务可以完成、自动重试、换一种安全方法、请求接管，或者停止并说明未完成部分。每种状态都要让用户知道发生了什么。 请求接管应该给出地点、失败原因、已尝试动作和最小必要帮助。让用户从头排查，实质上把系统工程工作转嫁给家庭。自动重试也需要边界，反复尝试可能扩大物理损失。 维护同样是产品任务。iRobot 的特定系列维护说明列出滤网、刷子、传感器和充电触点的护理要求。这能证明自动清洁仍包含人的维护劳动，不能用来推断其他品牌的故障率。 已有研究能支持多强的结论 本地家庭机器人语料重计为 208,755 条记录，来源明显集中，自动标签还存在形态和词义误判。最新结构复核公开的是计数与限制，不把规则编码的“链条闭合”当作经过人工验证的购买需求。 一个尤其需要纠正的推断是：扫地机的使用或“为父母购买”材料，可以帮助理解家庭购买链；它不能直接验证人形照护、机器狗安防或医疗安全效果。 下一轮应怎样测试 用同一项任务比较机器人与现有替代方案，记录合格完成、人工救援次数、每次救援时间、日常维护和被放弃的任务。购买者、使用者和实际维护者分别访谈。 早期不必承诺包办家庭事务。把一个窄承诺做得可信，并保留清晰的求助和退出机制，更容易得到有意义的长期使用证据。" },{ "id": "knowledge-local-ai", "kind": "knowledge", "lang": "zh-CN", "title": "本地 AI：任务成立之后，设备才有购买理由", "topic": "ai-devices", "url": "/knowledge/local-ai/", "summary": "把离线、隐私和算力拆成任务条件，再比较已有电脑、共享设备与专用硬件的完整成本。", "updated": "2026-08-31", "related": ["agent-context","software-capabilities","alternatives-entry"], "related_articles": ["/notes/local-ai-box-task-economics/","/notes/agent-left-embodied-right/"], "source_ids": ["lmstudio-offline","ollama-context","jetson-lifecycle"], "text": "本地 AI 有明确用途，但“愿意在本地运行”与“愿意新增一台设备”是两次不同的选择。用户可能已经拥有足够好的电脑，也可能愿意接受云端服务。设备需要解释自己的增量价值。 将口号还原成约束 常见理由 需要进一步确认 离线 哪些步骤必须断网？模型、检索、授权和外部工具是否都能工作？ 隐私 哪些数据不能离开哪条边界？谁能查看文件、日志和结果？ 低延迟 比较的是首次响应，还是完整任务和排队时间？ 低成本 是否计入设备折旧、安装、模型维护、耗电与失败处理？ 长期运行 任务是否高频到值得占用一台持续在线的设备？ 这些条件可能支持专用硬件，也可能支持给现有设备安装软件。判断不应提前绑定形态。 已有设备是必须比较的替代方案 LM Studio 的文档说明，已下载的模型及部分本地工作流可以离线使用。这至少构成一个基线：先在现有电脑上完成任务，再寻找必须购买新设备的原因。外部工具是否联网仍需单独检查。官方说明 模型文件装得下，不代表任务运行得好。上下文、并发和其他进程也占用资源。Ollama 的文档明确提醒，更长上下文需要更多内存；仅比较参数量或算力峰值，会漏掉实际工作负载。上下文文档 什么任务值得进一步验证专用设备 持续监听本地事件、为多人提供服务、连接现场设备，或需要将研究者的个人电脑与执行环境分开，都可能增加专用设备的价值。这里列的是待检验条件，不是已经证实的市场规模。 用同一组任务，比较现有电脑、本地专用设备和允许范围内的云端方案。记录质量、耗时、人工介入、断网表现与维护负担。只有增加的持续使用价值超过新增负担，才有购买理由。 硬件还带来供货、替换和系统维护责任。NVIDIA 对模组与开发套件的生命周期作了不同说明，这提醒我们不要把开发验证条件直接当成产品交付承诺。生命周期说明 本轮资料允许说到哪里 所核对的本地 AI 主语料有 211,088 条记录，Reddit 占约 90.21%。这是特定采集范围的讨论材料，不是购买意愿调查；该快照没有 E0–E5 编码字段。完整口径见数据说明。它能帮助找任务与失败线索，不能证明一类新硬件已经拥有需求。" },{ "id": "knowledge-manipulation-data", "kind": "knowledge", "lang": "zh-CN", "title": "灵巧操作：手、触觉与数据如何互相约束", "topic": "robotics", "url": "/knowledge/manipulation-data/", "summary": "以目标任务和可观测的接触过程评价灵巧手，避免自由度、数据小时数与平台价值之间的跳跃。", "updated": "2026-08-31", "related": ["robot-industry","world-models","desktop-manufacturing"], "related_articles": ["/notes/embodied-intelligence-beginners-guide/"], "source_ids": ["openvla","droid"], "text": "灵巧操作同时面对物体形状、接触、摩擦、形变和控制误差。一只手能摆出很多姿态，不等于它能稳定操作目标物体；一批视频看起来丰富，也不等于提供了训练所需的动作信息。 我的研究重点是硬件、感知、数据与任务之间的适配。特定公司的非公开路线和参数不进入这个公共框架。 先定义任务空间，再讨论自由度 抓取刚性盒子、插拔线束、拧盖子和整理织物，要求不同。评估时先写出物体变化、成功条件、允许耗时和失败后果，再比较夹爪、欠驱动手与高自由度手。 增加自由度可能扩大可达动作，也增加驱动、控制、故障点与学习空间。它的收益应该表现为目标任务覆盖或可靠性提升，不应只靠外观接近人手来证明。 数据需要记录什么 数据来源 能提供什么 不能直接补齐什么 普通视频 语义、物体和动作线索 执行器状态、接触力、可执行动作 人类第一视角 实际工作情境与行为变化 人手到机器人动作的对应关系 真机遥操作 观察、机器人状态、动作与结果 采集成本、覆盖偏差、示范质量 仿真 可控条件与大量试错 未建模的材料、接触和真实差异 实际部署 目标任务、失败与人工介入 自动形成高质量训练集 DROID把跨环境操作数据和采集体系一起公开；OpenVLA提供视觉语言动作模型的研究路径。两者说明数据与模型可以被具体检查，但不能单凭数据集规模判断某款手或某项家庭任务已经可用。 触觉的价值要落在接触问题上 视觉主要帮助定位与识别，力觉和触觉可以补充接触后的信息。但不同传感器能测什么、噪声有多大、如何标定、能用多久，并不一致。 有触觉传感器，不代表策略有效利用了触觉。验证时应比较同任务的视觉基线与加入触觉后的表现，保留滑移、遮挡、材料变化和传感器退化条件。额外维护与系统成本也要计入。 数据基础设施何时可能成为平台 如果某种硬件拥有稳定接口、可批量供给和维护能力，算法与数据有机会围绕它积累。这个平台假设还需要跨客户复用、独立开发者采用和持续任务效果来验证。 卖出许多只手，与形成通用技能生态之间隔着数据协议、标注、评测和权利边界。下一步值得跟踪的，是一项技能换手、换物体、换场地后的效果，而不仅是新增多少数据小时。" },{ "id": "knowledge-organization-responsibility", "kind": "knowledge", "lang": "zh-CN", "title": "组织责任：先修接口，再判断谁不合适", "topic": "organization", "url": "/knowledge/organization-responsibility/", "summary": "把组织合法性落到决策记录、跨团队承诺与坏消息出现的时间，不把信任简化成满意度。", "updated": "2026-08-31", "related": ["hardware-innovation","talent-and-industry","evidence-maintenance"], "related_articles": ["/notes/appointed-manager-organizational-legitimacy/","/notes/hardware-innovation-organization-management/"], "source_ids": [], "text": "组织图回答谁向谁汇报，未必回答一个跨团队结果由谁负责。产品承诺、系统限制、研发排期和客户期待如果互不相认，每个部门都可能按自己的目标完成工作，整体却持续失约。 处理这种问题，先要找到责任断点，再判断结构或人员需要怎样改变。 任命之外，还需要共同工作的记录 我在原文章中用“职位合法性”与“组织合法性”区分任命带来的权力，以及团队在共同工作中形成的判断信任。这是管理实践框架，不是新的学术定义。 判断信任并不要求所有人同意结果。它需要团队知道决定依据、明确取舍、纠错路径和复盘条件，也需要见过承诺被兑现。 新负责人不必在观察与行动之间二选一 正在扩大的明确风险应立即控制。可逆、低风险的流程改进也可以尽早做。对重组、关键人事和战略转向，则应提高证据门槛。 “先了解三个月”或“上任马上换人”都不能独立构成方法。时间安排要服务于风险和证据，而不是表演某种管理风格。原文的 90 天安排在这里作为示例保留，不设为普遍期限。 四个接口比新组织图更先影响结果 目标是否描述同一个结果；决定由谁最终作出；评审是否允许暴露尚未解决的问题；跨团队承诺是否包括质量、时间和变更方式。 若项目经理只有催促权，没有升级风险的路径，增加会议也无法解决问题。若产品范围持续变化却无人承担代价，换一个研发负责人也可能继续延期。 当然，接口清楚也不能掩盖真实的能力、诚信或意愿问题。系统分析帮助做出更公平的判断，不意味着无限推迟必要的人事决定。 用行为信号检查改变 我会观察坏消息是否出现得更早，反对意见是否带着证据进入正式讨论，普通分歧是否不再全部升级到最高负责人，以及团队能否在负责人不在场时继续使用同一套标准。 这些信号本身仍需结合业务结果理解。更少升级可能意味着授权有效，也可能意味着问题被压住。需要同时查看风险暴露和交付质量，避免把一种管理口号换成另一种局部指标。 本页只整理公开管理文章中的方法，不包含具体组织的人事信息、内部评价或未公开决策。" },{ "id": "knowledge-playable-content", "kind": "knowledge", "lang": "zh-CN", "title": "可交互内容：用户的动作，必须对世界留下影响", "topic": "creative-tools", "url": "/knowledge/playable-content/", "summary": "把连续生成的画面与可持续交互的世界分开，研究状态、规则、反馈和恢复。", "updated": "2026-08-31", "related": ["world-models","video-production","agent-context"], "related_articles": ["/notes/ai-native-basic-unit/"], "source_ids": ["world-model-taxonomy"], "text": "一段内容会回应用户，不意味着它已经是一个可玩的世界。如果用户拿走的物体下一轮重新出现，已经做过的选择无法继续，画面再流畅也难以形成可信的行动体验。 我的判断是：可交互内容的核心资产之一，是动作之后仍被承认的状态。画面负责表达状态，规则决定状态怎样变化，两者不能只靠下一轮语言描述碰巧保持一致。 需要决定哪些事不会凭空改变 角色身份、物品归属、空间关系、任务进度以及关键选择，都可能需要持久保存。并非所有细节都要模拟到物理精度，但哪些允许即兴、哪些必须稳定，应由体验目标决定。 例如，一个以探索为主的短篇体验可以允许场景细节变化，却仍需记住玩家已经打开了哪扇门。这里是设计示例，不是已经上线项目的使用数据。 区分三种责任 生成系统可以负责呈现新场景，规则系统负责判断动作是否允许，状态系统负责保存动作的后果。它们可以共享模型，也可以由模型和确定性代码组合实现。 越重要、越不可逆的状态，越不适合仅依赖模型“记住”。需要记录输入、变更、结果和版本，允许检查矛盾并恢复。做出一次响应与保证长期一致，是不同的成本。 世界模型的功能分类能帮助识别这些责任，但不能证明模型天然具备了完整游戏引擎。分类提案 传播效果与产品留存分开测 惊喜片段适合展示，却无法单独回答用户是否愿意继续。评测应包含重复进入、沿旧选择继续、尝试边缘动作，以及恢复中断任务。记录用户是在探索可能性，还是反复绕开系统失忆。 商业上还要区分创作者制作成本、单次运行成本与付费动机。模型每轮能生成新东西，并不意味着用户每轮都获得新价值。 本页是从创作与 Agent 系统研究中整理出的设计假设。没有把内部项目计划、融资叙事或尚未完成的产品能力当成公开成果。" },{ "id": "knowledge-research-workflows", "kind": "knowledge", "lang": "zh-CN", "title": "把研究工作流接到可检查的产物上", "topic": "agent-systems", "url": "/knowledge/research-workflows/", "summary": "用 iRead 发现变化，用 SURE 组织证据，用知识页维护判断；工具与研究结论各自负责。", "updated": "2026-08-31", "related": ["agent-context","demand-evidence","evidence-maintenance"], "related_articles": ["/notes/scene-user-demand-evidence-research/","/notes/agentmeasure-from-spec-to-evidence/"], "source_ids": ["iread","sure","transcript","agentmeasure-lab"], "text": "研究任务最容易停在“读了很多资料，写了一份报告”。下一次问题出现时，报告中的来源过期、数字无从重算，新的 Agent 也不知道哪些判断已经被否定。 我更希望把研究留下来的东西组织为来源记录、证据表、当前判断和验证产物。工具可以不同，这几类对象需要能够互相定位。 现有项目分别负责什么 项目 输入与产物 不负责证明什么 iRead 领域与经审核信源；事件和报告 出现很多报道不证明趋势成立 SURE 决策问题与反馈证据；研究契约、编码和审计 CLI 通过不证明市场需求真实 视频转录工具 获准处理的媒体；可核对的逐字稿 转录不等于原作者事实核验，也不授予再发布权 AgentMeasure / Lab 操作日志或实验设计；口径与结果 流水线成功不证明真实业务收益 公开知识库 经过整理的分析、引用和数据说明 不承担私有原件的全量备份 这些项目现在各有独立入口。这里描述的是一种协作方法，不声称它们已经形成自动运行、无需审阅的完整平台。 一次更新应该改变明确对象 新信息进入时，先判断它是旧事件的另一篇报道、新事实、相反证据，还是需要进一步检查的说法。只有改变研究问题的材料，才值得更新主题正文。 更新一项判断时记录：旧结论是什么，新增证据改变了哪个前提，哪些部分仍有效。原文保持可回查，当前知识页给出维护后的版本。这样可以承认过去的判断有局限，而不抹掉当时的依据。 自动化的边界 文件和来源中可能夹带指令，不能因为它们出现在研究材料里就授权工具行动。发布、发信、删除、付费与设备控制需要由任务本身授予权限。 资料去重、格式校验、指标重计适合自动化。来源是否独立、评论究竟在支持哪个产品、某项概念是否有商业意义，需要语义复核；研究工具应该把这些问题暴露出来。 如何验收这套工作流 挑一个已经有旧结论的主题，用一条新增反证走完整个流程：能否找到受影响的知识页，更新数据口径，保留原文链接，并让关联文章提示读者查看最新判断。 如果增加的只是文件数和摘要数，没有减少下一次判断所需的检索与复核成本，研究工作流还没有完成它的任务。" },{ "id": "knowledge-robot-industry", "kind": "knowledge", "lang": "zh-CN", "title": "具身智能产业地图：任务、技术与商业成熟度", "topic": "robotics", "url": "/knowledge/robot-industry/", "summary": "把本体形态、技术路线、公司位置和交付证据分开，避免用同一张榜单回答不同问题。", "updated": "2026-08-31", "related": ["household-robots","manipulation-data","world-models","hardware-innovation"], "related_articles": ["/notes/embodied-intelligence-beginners-guide/","/notes/agent-left-embodied-right/"], "source_ids": ["openvla","droid"], "text": "“人形”“VLA”“灵巧手”“家庭服务”和“融资”经常被放在同一张产业图上，但它们分别是身体形态、模型方法、部件、场景和资本事件。研究时先区分层级，才能判断一条新闻究竟改变了什么。 这份地图重组了此前白皮书中的定义和框架。它服务于产品与商业判断，不给公司做未经统一口径验证的排名。 一张产业图需要两种视角 制造视角沿零部件、本体、集成与服务展开，适合研究成本、供货和责任。学习系统视角则追踪经验如何转成能力： 环节 关键对象 应检查的事实 经验 遥操作、第一视角、仿真、部署记录 有无动作、结果、失败与使用权限 模型 感知、VLA、世界模型、策略 训练和测试条件是否匹配目标任务 执行 规划、控制、手与传感器 接触、实时性与异常停止 产品 本体、交互、维护方案 能否长期承担约定任务 部署 现场流程、交付、售后 新客户能否复用已有能力 两种图互补。模型性能提高不代表整机交付改善，出货增加也不保证新增数据能进入训练。 身体是一项任务决策 平整场地内的移动操作，轮式平台值得与双足一起比较；复杂地面巡检，需要审查四足的通过性；固定工位操作，要先比较固定机械臂与专用装置。 这些是工程取舍，不能写成“某种身体永远更优”。楼梯、作用范围、负载、能耗、维护和人员共处条件变化后，选择会变化。人形的工具兼容潜力也需要由具体任务兑现。 商业成熟度需要可观察的进展 沿“受控演示—客户试点—重复交付—持续运营—复购扩张”追踪，比把论文、订单和营收混在一起更有解释力。每一步都问有没有独立客户、多少人工支持、是否达到验收条件。 平台化不再被我放在这条成熟度阶梯的最高一级。一个没有开发者生态的窄任务设备，也可能拥有成熟利润；一个开放 SDK 的研究平台，也可能尚无重复客户。平台结构与商业成熟度是两个维度。 把自主程度写进经济账 单位有效任务成本应覆盖折旧、部署、人工接管、维护、耗材与软件，分母采用客户认可的合格任务。统计口径必须说明运行时间、任务难度和失败处理。 “自主有效工作小时”适合观察趋势，但不是所有任务通用的价值指标。慢速完成与高速完成的一小时不能直接相比；对某些任务，合格件数或异常处置效果更重要。 下一步研究重点是同任务、同环境下的长期工作证据，以及新客户交付是否越来越省力。缺少这些证据时，保留技术进展判断，暂缓商业规模结论。" },{ "id": "knowledge-software-capabilities", "kind": "knowledge", "lang": "zh-CN", "title": "软件重构与能力经济", "topic": "agent-systems", "url": "/knowledge/software-capabilities/", "summary": "界面、可调用能力、交付资产和经济价值是四个不同对象；分别判断谁掌握了什么。", "updated": "2026-08-31", "related": ["agent-measurement","video-production","local-ai"], "related_articles": ["/notes/ai-native-basic-unit/","/notes/when-the-software-consumer-becomes-an-agent/","/notes/ai-apps-unbundled-before-agent-filled/"], "source_ids": ["agentmeasure-core","sure"], "text": "当用户把任务交给 Agent，软件的界面可能不再是每次使用都必须经过的入口。但界面使用减少，不能直接推出软件没有价值。数据库、渲染、支付执行、专有数据和现场服务，都可以通过不同入口被使用。 我的长期判断是：部分软件会围绕可调用能力重新分工。判断一家公司时，要同时看能力如何被发现，以及它最终交付的东西是否稀缺。 把四个对象拆开 对象 例子 应回答的问题 入口 App、网页、对话、CLI 谁接收用户的目标？ 接口 API、MCP、SDK、Skill 外部系统怎样调用？ 交付资产 数据、执行系统、权限、客户流程 换一个接口能否复制？ 经济结果 付费使用、可归因收益、履约成本 谁付款，为什么续费？ Skill 可以描述操作方法，MCP 可以暴露工具，CLI 可以方便确定性执行。它们不自动产生独占数据、客户信任或持续收益。反过来，接口很简单的服务也可能掌握难以替代的交付能力。 产品的基本状态要能被读取和修改 在 AI 创作工具里，只有一个导出的文件通常不够。需要持续保存人物、素材、版本、授权与修改关系。在企业流程里，需要保留订单、审批状态、参与者和不可逆动作。 这使“语义对象及其历史”成为重要产品资产。人通过界面理解和修订，Agent 通过接口操作，两者应面对同一份状态。不能给 Agent 另做一套没有权限约束、与人类界面不同步的后台捷径。 分发、使用与价值分别验证 被安装说明进入了某个环境；被展示说明进入选择范围；被选中说明一次决策发生；被调用说明执行开始。任务完成后，还要判断结果是否被接受，以及它是否比替代方案更划算。 因此，能力目录负责发现，能力经济专题维护论证，AgentMeasure研究测量。目录收录不能充当使用量，更不构成投资或采购推荐。 需要保留的反例 高频交互、精确控制、多人协作、强品牌关系的产品，可能继续拥有重要的人类入口。也有企业宁愿让 Agent 在既有软件内工作，不愿把目标交给另一个平台。 所以，“所有 App 都会消失”过于激进。“所有软件加上聊天框就能适应变化”同样缺少解释。应该逐条研究具体工作流：哪些操作可以让渡，哪些状态和责任仍需要专业系统承接。 观察周期应围绕真实客户任务。若调用增长却没有更多被接受的结果，或收入上升完全来自更高的重试成本，都不能据此确认能力经济的价值假设。" },{ "id": "knowledge-spatial-computing", "kind": "knowledge", "lang": "zh-CN", "title": "空间交互：被指向的对象，需要能被持续操作", "topic": "ai-devices", "url": "/knowledge/spatial-computing/", "summary": "从“看、指、捏、说”延伸到对象身份、执行确认和跨步骤状态，不把空间展示等同于完整交互。", "updated": "2026-08-31", "related": ["wearables","world-models","agent-context"], "related_articles": ["/notes/spatial-computing-touch-moment/"], "source_ids": [], "text": "在原文章里，我用“看、指、捏、说”描述一种可能的空间交互语法。这是产品判断，不是对现有平台标准的转述。它最有价值的部分，是让人直接指向环境中的对象，再表达要做什么。 但选中一个对象只是开始。如果下一步无法延续它的身份、版本和权限，空间交互仍然只是一场短暂展示。 先让对象在任务里存活 同一个对象可能同时有可见形态、文件、业务记录与操作权限。看向屏幕中的家具，不等于授权购买它；指向同事的文档，不等于拥有编辑权。 可持续操作需要回答：指向的是哪一个对象，当前状态是什么，允许哪些动作，执行结果如何回到用户面前。对于高后果动作，确认界面必须明确展示范围，不能把注视当成同意。 快交互与长任务要接得上 移动、缩放、选中之类动作需要直接反馈；跨应用整理、比较与制作可能由 Agent 承担。两种节奏可以共存。把一切改成长对话会拖慢直接操作；让所有长任务依赖手势，又会增加记忆与体力负担。 我倾向于让直接操作承担“指定对象和局部调整”，让 Agent 承担“理解目标和组织多步任务”。中间要有可见的计划、进度、暂停和恢复，尤其要显示发生了哪些状态变化。 空间研究不能被头显品类限制 本地空间世界研究中，讨论涉及建模、格式、协作、引擎、设备连接等不同领域。它们帮助发现工作阻力，却不能一并称为头显需求。一个文件在工具之间打不开，首先是交付链路问题；是否需要空间显示，需要额外论证。 这里将原报告中的线索收敛为三个研究对象：跨工具保持的对象、可解释的操作状态、能完成任务的输入输出组合。不采用未经人工回查的需求等级或意愿比例。 验证可以从普通屏幕开始 选择一个真实工作流，例如审阅并修改一个三维方案。先在普通界面记录定位对象、理解差别、表达修改和核验结果的成本，再比较空间交互改善了哪一环。 如果收益只来自更大的显示面积，就不应归因于新的智能交互。反过来，如果同一套对象与操作协议在手机、桌面和头显上都有效，价值可能主要在系统层，而不属于某一种外形。" },{ "id": "knowledge-talent-and-industry", "kind": "knowledge", "lang": "zh-CN", "title": "人才与产业扩散：履历标签之后，还要看能力怎样迁移", "topic": "organization", "url": "/knowledge/talent-and-industry/", "summary": "把创业名单、组织经验和产业结果分开，避免由少数成功公司反推人才流动的原因与成功率。", "updated": "2026-08-31", "related": ["hardware-innovation","robot-industry","evidence-maintenance"], "related_articles": ["/notes/hardware-innovation-organization-management/"], "source_ids": [], "text": "给创业公司加上某个大厂的“系”，便于传播，也容易把复杂经历压成一个标签。同样来自一家企业，正式任职、实习、顾问、合作与分拆并不是同一种关系；创始人和普通团队成员也不是同一种统计对象。 这轮本地名单复核最有价值的改进，是先分开这些关系，再讨论能力可能如何扩散。这里提炼方法，不把未逐一核验的履历与经营数据重新发布成事实榜单。 先确定自己在数什么 公司、品牌、创业项目和创始人可能在同一份表里出现。一个人多次创业会产生多个项目，一家公司可能运营多个品牌。同一条关系图上的节点数不能直接改写为“多少位离职者”。 成立年份也不等于离职年份。融资阶段、累计融资、估值、众筹与收入各自回答不同问题，不能为了一个传播性强的总数直接相加。 履历只是研究起点 我更关心迁移的是哪一种能力：系统集成、供应链组织、质量判断、产品定义、渠道经营，还是团队协作方式。它们需要通过实际产品和交付记录判断，不能仅凭前雇主名字确认。 离开原组织以后，新团队可能吸收其他公司、学术机构和合作伙伴的经验。把结果全部归因于一家前雇主，会漏掉这部分积累。 成功案例无法给出成功率 媒体更容易报道融资、出货与增长，沉默、停止和转向的项目更难进入名单。只收集可见案例，就没有计算失败率、离职率或创业成功率的分母。 即使名单中很多项目在相近时间出现，也需要检查采集是否重点搜索了近期新闻。研究者的检索窗口，可能制造出一段看似明显的创业浪潮。 从产业研究回到组织设计 如果一种能力可以被反复带到不同任务里，它值得作为组织建设对象。下一步应研究这种能力怎样训练、由哪些角色共同承担、依赖什么供应链与制度，以及脱离原组织后哪些部分会失效。 这个问题比复制一家明星企业的组织图更有用。它也连接本知识库的硬件方法：可迁移的能力最终需要表现为判断质量与重复交付，而不是人才名单的长度。 后续文章可以沿“工程能力如何跨品类迁移”展开。公开前仍需逐项核验引用案例，不能让方法上的谨慎被标题中的确定性抵消。" },{ "id": "knowledge-video-production", "kind": "knowledge", "lang": "zh-CN", "title": "AI 视频生产：保留已确认的东西，再修改其余部分", "topic": "creative-tools", "url": "/knowledge/video-production/", "summary": "将首轮生成与专业交付分开，以可编辑项目、局部修改和版本资产理解创作软件价值。", "updated": "2026-08-31", "related": ["software-capabilities","playable-content","desktop-manufacturing"], "related_articles": ["/notes/ai-video-second-edit/","/notes/ai-native-basic-unit/"], "source_ids": ["otio","runway-references","c2pa"], "text": "第一次生成回答“能不能做出这个效果”，后续修改回答“能不能按照要求完成这份作品”。专业创作软件需要长期处理第二个问题。 一个已经确认人物、台词和节奏的片段，可能只需更换背景。如果工具要求整段重做，新的画面还需要重新检查其他部分。看似只改了一处，实际重开了整份验收。 项目需要留下可以操作的结构 要保留的东西 下一次修改如何使用 对象与素材身份 找到同一个人、商品、声音和授权来源 时间与依赖关系 调整局部时知道哪些镜头和音轨受到影响 已确认的约束 保住不能改变的内容，明确尚未锁定的部分 版本与修改记录 比较结果、退回原状态、继续协作 交付条件 检查格式、字幕、画幅与渠道要求 不一定每项都由生成模型内部完成。确定性编辑、素材管理、渲染和人工判断，可以与模型共同构成生产系统。 能力示例与边界 Runway 的参考图工作流说明了图像中的身份与场景一致性已经成为具体产品能力。它可用于准备视频素材，不能直接证明任意视频编辑任务的稳定性。参考图文档 OpenTimelineIO 提供剪辑信息的交换结构，包括片段、轨道、时间、标记与元数据，但不内嵌音视频。这类工程结构提醒我们，作品不是一个孤立的视频文件；也不能误把一个交换格式当成完整生产系统。项目文档 内容来源记录有助于追溯。C2PA 提供来源凭证相关机制，并不自动判断内容为真或授予素材版权，商业使用仍须逐项确认。说明 怎样评估“更好改” 给出同样的初稿和修改单，记录修改完成时间、额外改变了多少已确认内容、多少步骤需要人工回退，以及最后是否达到要求。应包含模型直接生成、传统编辑和混合工作流的对照。 “第二次修改”是我的产品观察切口，不是声称某类软件必然取得商业优势。一次性娱乐与简单素材生成可能不需要完整项目系统。工作越依赖连续协作和反复确认，这个切口越值得验证。 原研究中关于行业规模和企业经营数据的未核验表述未纳入本页；这里保留可独立检验的产品判断。" },{ "id": "knowledge-wearables", "kind": "knowledge", "lang": "zh-CN", "title": "AI 穿戴：可用时刻比功能清单更重要", "topic": "ai-devices", "url": "/knowledge/wearables/", "summary": "按身体位置、输入输出条件与日常使用阻力研究眼镜、耳机和其他穿戴设备。", "updated": "2026-08-31", "related": ["spatial-computing","household-robots","demand-evidence"], "related_articles": ["/notes/ai-wearable-modalities-body-comfort/","/notes/robots-give-people-new-bodies/"], "source_ids": ["sure"], "text": "穿戴设备的能力只有在用户愿意戴着、方便触发、允许记录时才存在。拍摄、听觉与显示各自有价值，但把它们相加，得不到日常使用价值。 我更愿意从“可用时刻”理解这类产品：某项任务发生时，设备是否在身上，电量是否足够，环境是否允许输入，输出是否能被接收。 身体位置决定任务，也决定代价 眼镜靠近视线，耳机接近听觉，手表容易查看与触碰。这个位置同时带来遮挡、重量、发热、佩戴与社交条件。比较时应保持任务一致：同样是获取一句提示，听到、看到和主动拿出手机，分别打断了什么？ “模态更多”不必然更好。会议里适合的语音交互，在公共场所可能难以使用；持续视觉输入也涉及被拍摄者的同意和数据管理。产品必须提供明确的开始、停止和状态提示，而不是把记录变成难以察觉的默认动作。 把一天拆成可观察的场景 我会记录任务发生、设备可用、实际触发、输出可接受、任务结束五个节点。漏掉任何一层，都可能将功能演示误判为使用机会。 例如，用户说想记住路上见到的信息，可以先确认他现在如何记录、多久发生一次、遗忘造成什么后果。然后再比较手机拍照、语音备忘与穿戴采集。一次新奇体验只能说明愿意尝试。 这也是原文章中“身体舒适度”观点的进一步收敛：舒适度并非单独一张参数表，而是影响设备在需要时是否可用的条件。 语料要保留产品与场景的区别 本次核对的眼镜组合语料有 209,862 条记录，其中既有产品反馈，也有开放场景讨论，Reddit 占约 83.29%。不能把全部记录叫作“AI 眼镜用户评价”，也不能将机器识别的付费、复用标签直接视为购买与留存证据。 此前文章中的产品反馈子集与本轮组合快照不是同一分母，见数据口径。后续验证应从具体任务抽样，回看上下文、替代方案与实际行为；不能靠扩大关键词采集量来替代这一步。 一个值得继续研究的问题 穿戴设备是否能在少打断用户的同时，明确表达自己的状态与权限？如果用户无法知道什么时候正在记录、结果去了哪里、如何撤回，再多“无感”也可能变成负担。" },{ "id": "knowledge-world-models", "kind": "knowledge", "lang": "zh-CN", "title": "世界模型：画面、状态与行动各自证明什么", "topic": "robotics", "url": "/knowledge/world-models/", "summary": "用输出契约区分视频生成、可计算仿真与行动规划，避免把视觉效果当成物理能力。", "updated": "2026-08-31", "related": ["manipulation-data","spatial-computing","playable-content"], "related_articles": ["/notes/embodied-intelligence-beginners-guide/"], "source_ids": ["world-model-taxonomy","openvla","droid"], "text": "“世界模型”适合描述研究方向，却不足以定义一份产品验收单。同样是一段杯子被推动的视频，一个系统可能只生成画面，另一个保存可计算的物体状态，第三个据此选择机器人的动作。三者的错误会造成不同后果。 先问下游拿到什么 World Labs 在 2026 年 6 月提出按功能区分 renderer、simulator 和 planner。我借用这个分类帮助分析产品；它是一个研究团队的提案，不是统一标准。原文 下游得到的东西 我的验收问题 画面与声音 镜头是否连续，指定对象是否保持一致，修改是否可控？ 可计算的场景状态 尺度、碰撞、材质和状态变化能否支持目标计算？ 行动或行动序列 在给定观测与限制下，任务能否安全完成，失败能否识别？ 这张表不是模型排行榜。一套系统可以同时承担几项职责，也可以把职责交给不同模块。 可看与可用之间，需要一个明确的转换 视频给出了一个可能的未来，但机器人还需要动作的坐标、时间、力度以及执行后的新观测。三维场景可以支持漫游，也未必包含适合接触任务的材料参数。把结果接入下游时，应写清楚保留了什么，估计了什么，哪些量根本不存在。 例如，将生成场景用于机器人训练，至少要检查比例、碰撞几何、动作接口和任务结果定义。这里的重点是检查项目自身的训练契约，不是要求每种娱乐内容都具有工程仿真的精度。 数据价值来自补上哪一种缺口 真实视频可以丰富外观与事件知识；带动作和结果的机器人轨迹，才让特定执行条件进入数据。DROID 和 OpenVLA 展示了真机数据、任务适配与策略学习的具体路径，不能据此跳到“看完互联网视频就会做家务”。DROID、OpenVLA 评估新增数据时，我会比较同一组任务上的失败类型：是对象没认对、接触时滑落、没有察觉失败，还是下一步计划错误。数据规模只有落到这些差别上，才有产品意义。 目前保留的判断 生成、仿真与规划可能相互提供训练信号，但“可能融合”不能当作已经具备通用行动能力的证据。白皮书中的产业讨论在这里拆成三个可单独验证的问题：结果是否可控、状态是否可信、行动是否可靠。它们也分别连接创作软件、空间工具和机器人。" }, { "id": "article-/notes/local-ai-box-task-economics/", "kind": "article", "lang": "zh-CN", "title": "本地 AI 盒子，得先证明自己值得多占一个插座", "topic": "ai-devices", "url": "/notes/local-ai-box-task-economics/", "summary": "将隐私、离线和持续运行变成可测试条件，再与现有电脑、NAS 和允许范围内的云端方案比较：专用设备的价值，要覆盖它增加的安装与维护负担。", "published": "2026-08-31", "translation_of": null, "related": ["local-ai","alternatives-entry"], "text": "一台新设备进入家庭或办公室，要占空间、接电、配置网络，有时还要有人记得更新它。 对于本地 AI，这些负担很容易被模型参数和算力数字盖过去。演示里只要能跑起来，产品就显得顺理成章：数据留在本地，没有持续的云端推理账单，还能一直在线。 但用户面前还有一个更便宜的起点：先用已经拥有的电脑。 我对本地 AI 硬件的判断因此比较苛刻。它要证明的增量价值，应当包括从安装到持续使用的整笔账。 本地运行已经是一个替代方案，不必先成为新品类 LM Studio 的官方文档说明，模型下载完成后，本地聊天、文档处理以及本地服务等工作流可以离线运行。下载模型、发现模型和获取更新仍需要网络，外部工具的联网行为也必须另行检查。离线说明 这不代表现有电脑适合所有任务，却意味着“能离线运行模型”本身不足以支持新增硬件。 产品需要继续回答：现有电脑在哪项任务上不够用？问题出在性能、持续在线、多人共享、设备连接，还是使用者不愿承担配置？新设备究竟解决了哪一项，又增加了多少新工作？ 如果只是把安装过程封装好了，它可能是一款有价值的易用型产品。只是这份价值需要通过上手、维护和服务验证，不应被包装成天然成立的算力需求。 隐私要画边界，离线要跑全程 “私有”是一个模糊的词。 它可能表示数据不发到外部服务，也可能表示同事之间不能互相看到文件；可能关注模型输入，也可能关注日志、备份和远程维护。模型在本地执行，只解决了其中一部分。 一个 Agent 在本地读取合同，再调用外部工具处理内容，数据仍可能离开设备。把模型从云端搬下来，不会自动约束其他工具的权限。 因此，隐私需求应被写成可检查的边界：什么资料允许被谁读取，什么结果能发到哪里，什么动作必须确认，以及日志保存到什么程度。设备默认配置要承担这些责任，不能全交给一段提示词。 离线也一样。演示一次断网问答，无法证明完整工作流可以离线。任务可能在检索、授权、外部数据或更新环节停住。测试应从任务开始跑到交付，记录无法完成的步骤。 能装下模型，还不等于能接住工作 设备宣传很容易围绕“能运行多大的模型”展开。用户实际要完成的任务，还会占用上下文、并发、检索和其他工具资源。 Ollama 的上下文文档明确提醒，更大的上下文需要更多内存。模型权重能装下，只能证明一个条件，不代表长文档、多任务和持续运行都达到预期。上下文说明 我会先拿真实任务比较设备，把硬件选择放到比较之后。 例如，整理一批允许在本地处理的研究文件，从读取、提取证据到形成带来源的报告。要观察的除了速度，还有漏读、错误引用、任务中断后的恢复，以及人最终花了多久检查结果。 设备若只是更早给出一个需要大量返工的初稿，不能直接认定它提高了效率。 专用设备可能在哪些地方成立 我更愿意关注持续运行的职责。 个人电脑会休眠、出门、被其他任务占用。一套共享工作流可能需要稳定的文件权限、固定工具环境和可恢复的任务队列。现场设备也可能需要低延迟连接，或在网络不稳定时继续处理事情。 这些条件可能支持独立设备，但仍需具体核验。持续在线本身并不会产生价值；它必须对应持续发生的任务。 另一种价值来自明确的交付责任。用户买到的不只是硬件，还包括可理解的权限、稳定更新、故障恢复和有人负责的服务。配置能力较弱的用户，可能愿意为此付费。不过，服务成本也要进入商业模型，不能只在购买理由里出现。 硬件的时间尺度尤其重要。NVIDIA 的生命周期说明对模组与开发套件作了区分，提醒产品团队不要将开发验证条件直接等同于长期供货和维护承诺。生命周期说明 二十万条讨论，仍然不能替盒子下订单 这次知识整理重新计算了一组本地 AI 主语料：211,088 条记录，Reddit 占约 90.21%。它覆盖特定时间与采集范围，没有代表全部潜在用户；这份主快照也没有可以直接当作需求结论的 E0–E5 编码。数据与边界 这些讨论能帮助找到任务和配置问题。它们不能证明发言的人愿意购买某台设备，也不能证明安静的大多数具有相同需求。 尤其要当心极客的容忍度。愿意下载模型、改配置和调试驱动的人，可以帮助发现能力边界，却可能替产品承担了未来用户无法接受的劳动。极客把设备跑通，是技术证据；大众用户能长期独立使用，还需要另一组证据。 把盒子与替代方案放在同一张验收单上 我会先约定任务、质量门槛、数据边界和使用频率，再比较现有电脑、专用本地设备，以及条件允许的其他方案。 除了采购或服务费用，要记录安装、等待、人工介入、失败恢复、维护与升级。设备折旧和持续运营成本也在其中。暂时无法估算的项，标成未知，不用乐观数字填平。 这项比较可能得到几种不同结论：现有电脑已经足够；软件封装和支持服务更有价值；或者独立设备确实显著降低了完整任务的负担。 三种答案都值得接受。产品选择应当跟着证据走。 对专用设备，我最终想看到的是：任务确实持续发生，用户不必重新配置和解释，设备稳定完成工作，出现问题时也没有把全部责任退还给购买者。 当它开始在每天的工作里变得不可或缺，那个插座才算占得值得。" },{ "id": "article-/notes/home-robots-recovery-burden/", "kind": "article", "lang": "zh-CN", "title": "机器人进家庭，要先过“谁来收拾残局”这一关", "topic": "robotics", "url": "/notes/home-robots-recovery-burden/", "summary": "家庭机器人的体验可能由失败后的劳动决定。购买者、使用者与维护者未必是同一个人，机器人替一个人省事，也可能让另一个人长期补位。", "published": "2026-08-31", "translation_of": null, "related": ["household-robots","robot-industry"], "text": "设想一个家庭机器人，能把桌上的杯子放回柜子。 只要演示成功，画面就很完整：识别杯子，抓取，移动，放下。可是在家里，事情还有前后两段。它开始前，是否要有人清空桌面、打开柜门？杯子没放稳时，谁来处理？下一次使用前，又是谁检查和维护？ 这是一个假设情境，不代表某款产品的测试结果。它提醒我，家庭机器人省下的劳动，必须和它新增的劳动放在一起计算。 我把后者称为“善后负担”。 成功率的分母之外，还有没被记录的工作 我们需要记录成功率，也需要明确任务从哪里开始、在哪里结束。 如果每次开始前都由人整理环境，测试衡量的是整理后场景里的表现。如果机器人失败以后需要人把它送回起点，却只统计最终完成，也会漏掉接管成本。 家庭尤其容易发生这种偏移，因为总会有人帮忙。设备够不到时，递一下；卡住时，挪一下；指令听不懂时，换个说法。每次都是小动作，加在一起可能成为一个长期岗位。 因此，评价机器人不能只问它替人做了多少，也要问谁被迫配合它做了什么。 一次成功演示可以证明能力。要证明日常价值，还需要把这些配合劳动带回来。 买单的人，未必负责善后 家庭不像一张只有一个用户的需求卡。 有人提议购买，有人每天使用，有人负责充电、联网、清理和联系客服。买给父母的设备，设置问题可能由子女远程处理；一个人喜欢的新设备，也可能由另一个人承担日常维护。 这会带来一种产品层面的错觉：购买者很满意，产品也有销量，家里的总负担却未必减少。 家庭产品需要识别谁在每个环节投入时间，以及这种分工是否被接受。省下 A 的十分钟，新增 B 的十五分钟，即使机器人看起来更先进，也不能据此说家庭获得了净收益。这里的分钟数只是算例，不是调研统计。 家庭的价值不都能折算成时间。有人愿意为便利、独立性或陪伴付出维护劳动。这些付出应在产品研究中被看见，并确认家庭愿意接受。 专用家电也有维护，问题是比例和可预期性 维护不是机器人独有的缺陷。 iRobot 为 Roomba s 系列提供的维护表，列出了滤网、刷子、传感器等部件的护理事项。这只证明某类产品确实需要维护，不能用来推算所有机器人的故障率。官方维护说明 成熟的任务型设备可以有维护要求，同时仍然很有价值。用户可能愿意定期清理，因为它持续完成了足够多的工作，维护时间也可预期。 难点在于不可预期的打断。设备总在用户离开后需要接管，或者每次失败都要重新判断发生了什么，就会消耗额外注意力。 一个产品每周一次可以安排的维护，与每天随机出现的求助，在生活里不是同一种负担。只累计分钟数，也可能漏掉这种差别。 失败后怎么做，应该进入产品定义 机器人遇到困难时，可以重试，可以换一种方式，可以请人帮助，也可以停止。 这些动作需要有边界。无休止重试会浪费时间，错误重试还可能增加损失；过早求助则把本可完成的工作退回给人。停止也必须让家庭理解：任务停在哪里，现场是否安全，下一步需要做什么。 我更希望看到一份完整的任务记录：准备条件、自动完成、重试、人工介入、失败结果、恢复方式，以及维护。每次接管都写清楚是谁、做了什么、花了多久。 这比只展示一次任务末尾的成功状态更接近交付责任。 尤其在多人家庭里，求助不能默认发给最近的人。产品需要让家庭知道谁负责哪类问题，也允许明确不接受某些任务。便利建立在可承受的分工上。 大量家庭讨论，不等于通用机器人的需求证明 本轮整理核对了 208,755 条家庭机器人与开放场景记录，其中 Reddit 占约 88.15%。机器标签和记录结构可以统计，但本次重计没有逐条确认每条发言究竟在接受什么方案。语料说明 用户抱怨做家务，可以说明一个问题。用户购买扫地机，可以说明某个方案获得了行为支持。把两者拼接成“用户愿意购买通用家庭机器人”，中间仍缺证据。 甚至同一个词也可能误导分析。提到“机器人”“取东西”或“退回”，并不必然对应我们正在研究的产品与任务。语境、对象和现有替代方案，都需要人工回查。 所以，我会先挑具体任务，再研究机器人需要满足的条件，而不会从一张想象中的通用能力清单出发。 怎样设计一场更有用的家庭测试 先记录家庭原来的做法：谁完成任务，多久发生一次，时间和注意力用在哪里，哪些地方已经足够好。 再引入机器人，保留任务准备、自动执行和善后的完整过程。除正常成功外，主动安排允许范围内的中断和边缘情境，观察设备如何停下、解释与恢复。不要为了保持漂亮数据，把难处理的失败剔出统计。 测试要持续到初期新奇感之外，时间长短取决于任务频率。期间既要问购买者，也要问实际使用和维护的人。如果某个成员长期替设备补位，这就是需要解释的产品成本。 最终可能发现，一个功能更少但善后更轻的方案，比一个能力更广却频繁求助的方案更受欢迎。也可能发现，用户愿意为了某项高价值能力承担额外维护。两种结果都需要真实任务支持。 家庭机器人需要更强的动作能力。它进入生活的那一天，产品责任也会延伸到动作失败之后。 我希望下一次演示在杯子放歪时不要剪掉。让我们继续看：机器人接着做了什么，人又需要做什么。" },{ "id": "article-/notes/ai-video-second-edit/", "kind": "article", "lang": "zh-CN", "title": "AI 视频软件的护城河，藏在第二次修改里", "topic": "creative-tools", "url": "/notes/ai-video-second-edit/", "summary": "把人物、台词和节奏保住，只改客户要求的一处：这件事比多接几个视频模型，更接近专业创作软件的长期价值。", "published": "2026-08-31", "translation_of": null, "related": ["video-production","software-capabilities"], "text": "给一个视频工具布置这样的修改任务： 初稿已经确认。人物不变，台词不变，镜头时长不变，只把背景换掉。 这是一个用于讨论的工作情境，不是我引用的客户案例。它足够普通，却能把两类产品区分开：一类擅长再生成一段看起来不错的视频；另一类知道哪些内容已经通过验收，并能在保住它们的前提下继续工作。 我更愿意用后一个任务判断 AI 视频软件的价值。 第一次生成很适合展示能力。第二次修改，开始检验软件是否理解“项目”。 “只改这里”，才是困难的要求 人在创作过程中会不断缩小不确定性。 最初可能连方向都没有。几轮讨论后，人物确定了，品牌语气确定了，镜头节奏也确定了。后来的每次修改，都建立在此前的决定之上。 如果工具每轮都把整段内容重新交给模型，它可能改善了背景，却同时改变表情、动作和商品细节。创作者不得不把已经通过的部分再检查一遍。生成本身花的时间很短，重新核对与协调花的时间却不一定短。 这里产生了一种容易被忽略的成本：每次修改都重新打开多少已经关闭的问题。 所以，“支持局部修改”不应只理解为界面上能圈一块区域。它还包括时间上的局部、对象上的局部，以及责任上的局部——谁确认了什么，哪些结果此刻不能动。 模型的进步，会改变边界，不会取消项目 参考图、一致性控制和编辑能力都在发展。Runway 的 Gen-4 Image References 文档把人物与场景参考的工作流讲得很具体。它处理的是图像，可用于准备视频素材，不能直接证明整段视频也能稳定保持相同约束。厂商教程还需要具体任务测试来检验。Runway 文档 如果模型将来可以精准保住所有指定条件，今天某些繁琐的补救步骤就可以消失。软件不应靠模型暂时做不好的事情维持复杂度。 但项目仍需记住条件来自哪里。 这次确定的人物，下次能不能用于另一条片子？客户否决过的版本，为什么不能再次出现？同事改了字幕之后，谁能看到哪些镜头需要重新检查？换一个模型生成，哪些素材与决定还能继续使用？ 模型擅长执行某次修改，与软件承担这些长期责任，可以同时成立。 一个 MP4 装不下完整的创作过程 最终视频是交付物，却不是全部生产资产。 素材身份、镜头依赖、时间线、字幕、音轨、版本、修改要求和批准记录，决定了团队下一次还能怎样处理它。如果这些东西只散落在聊天里，换个人、换个会话，工作就容易从解释背景重新开始。 OpenTimelineIO 提供了一个很具体的工程参照：它描述片段、轨道、时间、标记和元数据等剪辑信息，音视频本身仍通过外部引用关联。它没有包办整个生产系统，却说明“保存一个视频文件”与“保存一份可继续工作的项目”存在实际差别。OpenTimelineIO 文档 AI 创作软件可以有自己的项目结构，也可以与已有格式衔接。重要的是，创作者先前作出的决定能够留下来，下一步的工具可以使用它们。 这还影响 Agent 的角色。 Agent 能根据要求组织制作步骤、选择工具、检查输出，但如果工具只返回一段视频，没有可继续操作的结构，下一轮依然可能回到“把要求再说一遍”。一个好的工具接口应该让 Agent 指定对象、读取状态、提交修改并检查差异，而不只是接收一段提示词。 价值积累在批准过的东西里 创作软件里有一类资产很难从单次生成量看出来：已经被确认可用的东西。 可能是一套商品素材、一位角色的形象约束、一种被接受的字幕风格，也可能是客户确认过的节奏和修改习惯。 它们的价值来自减少下一次的不确定性。换工具时，如果需要重新确认全部条件，即使新工具生成得更便宜，迁移也未必值得。 我认为，这比“接入了多少模型”更接近专业软件可能形成的壁垒。不过，积累必须让用户可迁移、可检查。把素材锁住制造退出成本，与真正减少重复劳动，是两种完全不同的产品选择。 来源与使用条件也应进入项目。C2PA 提供内容来源凭证相关机制，但凭证不会自动判断作品为真，更不会自动授予素材版权。软件仍需保留实际授权和适用范围，不能用一个“可信”图标代替判断。C2PA 说明 把连续修改做成评测 我会给产品设计一组连续修改任务。 先得到同等质量的初稿，再依次修改背景、台词、画幅和节奏。每轮都明确哪些内容允许变化，哪些必须保持，最后交给不知道工具路线的评审检查结果。 记录的重点包括：完成修改花了多久，破坏了多少已经通过的条件，需要多少人工回退，以及最终交付是否达标。对照可以包括直接重新生成、传统编辑和二者组合。 这样才有机会区分：工具只是更快吐出结果，还是确实减少了完整项目的工作量。 还应该观察第二个项目。第一次保存的人物与品牌资产，在下一次是否真正省下工作？如果每次仍需从头解释，所谓“项目记忆”可能只是历史记录的另一个名字。 哪些用户未必需要这一套 一次性娱乐内容、探索创意或简单素材生成，可能只需要足够便宜、足够快、足够惊喜。给这些用户强加复杂项目管理，会增加负担。 专业工作也不是功能越多越好。确定性编辑能解决的事情，就不必每次调用生成模型。能自动保住的条件，也不应该让用户不断手动锁定。 我的判断适用在另一类任务里：作品要被反复确认、多人协作，并按明确要求交付。在这些任务中，下一次修改越重要，项目结构越有价值。 看下一款 AI 视频软件时，我会少看一轮炫目的首稿，多给它一句修改要求： 其他都保留，只改这一处。" },{ "id": "article-/en/notes/agentmeasure-from-spec-to-evidence/", "kind": "article", "lang": "en", "title": "AgentMeasure Weekly: The Spec Is Growing Evidence", "topic": "agent-systems", "url": "/en/notes/agentmeasure-from-spec-to-evidence/", "summary": "Engineering and evidence progress from Aug 22–25: AgentMeasure Lab v0.4 (open experiment engine), the first preregistered controlled A/B on a real agent harness, v0.2.2 conformance hardening with the first community-contributed fixture (Urusilla-001), the first public evidence case (langfuse demo traces: 12 attempts, 0% safe operation coverage), and the spec's move from a ladder to two states plus ranked evidence.", "published": "2026-08-25", "translation_of": "/notes/agentmeasure-from-spec-to-evidence/", "related": ["agent-measurement","research-workflows"], "text": "The first AgentMeasure progress report. Project: github.com/roy-tong/AgentMeasure, website: roy-tong.github.io/AgentMeasure. Every number below comes from reproducible run output — no hand-transcribed figures. What shipped this week The project moved from “specification documents” to an “evidence flywheel.” Four release nodes, one through-line: every claim must be recomputable. v0.2.0 (Aug 22) — Whitepaper v0.3 (EN + zh-CN) + AgentMeasure Lab v0.4, an open experiment engine: enforced preregistration, balanced blocked assignment, budget circuit breakers, honest statistics (Wilson intervals, two-proportion tests, honest nulls), and a bilingual decision-maker one-pager in every report. 78 tests. v0.2.1 (Aug 22) — The first preregistered controlled A/B on a real agent (codex CLI against a real MCP tool server): 4 tasks × 2 variants, full-funnel capture, real token metering (188K–215K tokens per operation). The result is an honest null: +25pp observed but p=0.29, next round needs ≈31 per arm. The engine did not flatter it — that is the point of the engine. v0.2.2 (Aug 24) — Conformance hardening. The first external conformance pass (from langfuse discussion #16383) exposed two real bugs: the validator skipped root-level required fields after an oneOf branch matched (#8), and the aggregator trusted declared operation summaries without reconciling the underlying attempt rows (#9). Both fixed — and, per the commitment made then, the first community-contributed fixture (Urusilla-001) was accepted into the conformance suite. CI now runs external-fixture guards plus the full lab suite on every relevant change. Aug 25 — The first public evidence case (conformance/evidence/langfuse-demo-traces/): Langfuse’s published demo seed data (three real framework-instrumented traces, commit-pinned, source not redistributed) run through the canonical pipeline via a disclosed one-off adapter. The result is a 0%: 12 attempts, operation grouping evidence 100% missing; safe operation coverage 0% — in both fail-closed and structural-experimental modes; token usage absent from the export entirely (0/26). This is not a “our bar is high, everyone else fails” flex. It pins the claim boundary: these numbers describe these three traces only. The reproducible scripts (fetch_source.py + run_case.py, stdlib only) ship with the case — anyone can recompute it. The spec revision: from a ladder to two states The same week, two independent external reviewers (direct replies, anonymous pending consent) read the spec and independently converged on the same critique: in my original four-level consumption ladder, referenced is not a semantic state — it is a weak estimator for influence with two named failure modes: cite-without-use and use-without-cite. The spec is now revised as DR-005, “two states + ranked evidence”: availability (a context fact): whether a capability entered the agent’s context; influence (a behavioral fact): whether it changed the agent’s behavior — answered at the experiment layer. A third reviewer added the provider-side inference boundary: client-side telemetry certifies serialized-as-sent, one step short of reached-inference. That boundary is now in the definitions. Also shipped: M3 execution-grain vectors operationalizing DR-006 — a runtime retry chain (429 → timeout → success under one operation_id) resolves to 1 operation in the spec, with M3.3 attempt success 0.333 and attempts_per_operation = 3 forced as disclosure — not three counts of “usage.” Two experts converging independently is behavioral validation of the spec’s direction. Writing it in beats any marketing copy. Product and growth reality The concurrently released PRD v0.5 records the dual-hypothesis test now in flight: A (conformance toolkit — real external pull already) vs B (usage integrity audit — closer to revenue, unvalidated), with a preregistered four-branch gate review on Sep 3. One channel, falsified: cold email. 616 delivered → 1 meaningful reply → 0 integrations. Closed. One loop, validated: structured upstream participation. One issue in langfuse → the first external conformance pass → two real bugs (#8/#9) → fixed and released as v0.2.2 → the first community-contributed fixture. That participate → evidence → fix → contribute loop is the single most valuable outcome of the week. The website’s trial entry (roy-tong.github.io/AgentMeasure) is now dual-path: email-first, GitHub issue as the fallback — the audit’s audience is CEOs and CFOs, and they should not be forced to open a GitHub account. What’s next Sep 3: dual-hypothesis gate review (four-branch decision criteria preregistered); Lab M2 open-source release and conformance vector completion (execution / reporting layers); Replicate the upstream-participation loop on the next batch of observability / gateway / runtime projects; Show HN: three of four gates passed; one 2-minute demo short. One sentence for the week: the standard is no longer just a document — it is producing its own evidence." },{ "id": "article-/notes/agentmeasure-from-spec-to-evidence/", "kind": "article", "lang": "zh-CN", "title": "AgentMeasure 一周进展：规范开始长出证据", "topic": "agent-systems", "url": "/notes/agentmeasure-from-spec-to-evidence/", "summary": "AgentMeasure 近一周（8/22–8/25）的工程与证据进展：Lab v0.4 开源实验引擎、codex 真实 Agent 上的首个预注册 A/B、v0.2.2 一致性加固（首个外部 fixture Urusilla-001）、首个公开证据案例（langfuse demo traces：12 次尝试、安全操作覆盖率 0%），以及规范从「阶梯」到「两状态 + 分级证据」的修订。", "published": "2026-08-25", "translation_of": null, "related": ["agent-measurement","research-workflows"], "text": "这是 AgentMeasure 的第一篇进展周报。项目主页：github.com/roy-tong/AgentMeasure，官网：roy-tong.github.io/AgentMeasure。以下所有数字都来自可复现的运行输出，不含手抄转写。 一周做了什么 过去一周，项目从「规范文档」推进到「证据飞轮」。四个版本节点，一条主线：每一条声明都要能被复算。 v0.2.0（8/22）——白皮书 v0.3（中英双语）+ AgentMeasure Lab v0.4 开源实验引擎：预注册（preregistration）锁、均衡分组、预算熔断、诚实统计（Wilson 区间、双比例检验、诚实零结果），以及面向决策者的双语一页纸报告。78 个测试。 v0.2.1（8/22）——在真实 Agent 上跑通了第一个预注册对照实验（codex CLI + 真实 MCP 工具服务器）：4 任务 × 2 变体，全漏斗采集，真实 token 计量（每个操作 188K–215K tokens）。结果是一个诚实的零结论：观测到 +25pp 但 p=0.29，下一轮需要约 31/臂。引擎没有美化它，这正是引擎存在的意义。 v0.2.2（8/24）——一致性加固。第一轮外部一致性测试（来自 langfuse 讨论 #16383）暴露了两个真 bug：校验器在 oneOf 匹配后跳过根级必填字段（#8）；聚合器信任声明的操作摘要而不核对底层的尝试行（#9）。两者都已修复，并且——按当时的承诺——第一个外部贡献的 fixture（Urusilla-001）被接受进一致性套件。CI 现在每次都跑外部 fixture 门禁 + Lab 全套测试。 8/25——第一个公开证据案例发布（conformance/evidence/langfuse-demo-traces/）：把 Langfuse 公开的 demo 种子数据（三条真实框架遥测 trace，commit 锁定、源不分发）通过一次性适配器跑过规范管线。结论是一个 0%： 12 次 attempts，操作分组证据 100% 缺失； 安全操作覆盖率 0%（fail-closed 与 structural-experimental 两种模式下都是）； token 用量在导出中整体缺席（0/26）。 这不是「我们的标准很高所以别人不合格」的炫耀，而是把 claim boundary 钉死：这些数字只描述这三条 trace。可复现脚本（fetch_source.py + run_case.py，纯标准库）随案例发布，任何人可以复算。 规范的修订：从阶梯到两状态 同一周，两位独立的外部评审人（经私信交流，匿名待授权）在阅读规范后独立收敛到了同一个批评：我原来设计的四级消费阶梯里，referenced（被引用）不是一个语义状态，而只是一个对 influence 的弱估计器，它有两种具名失败模式——引用了但没用（cite-without-use）和用了但没引用（use-without-cite）。 规范因此修订为 DR-005「两状态 + 分级证据」： availability（上下文事实）：能力是否进入了 Agent 的上下文； influence（行为事实）：能力是否改变了 Agent 的行为——由实验层回答。 另一位评审人补上了 provider 侧的推理边界：客户端遥测能证明的是 serialized-as-sent（已序列化发出），离 reached-inference（到达推理）还差一步。这个边界现在写进了定义。 同时发布的还有 DR-006 落地的 M3 执行粒度向量：一条运行时重试链（429 → timeout → success，同一个 operation_id）在规范里归为 1 次操作，M3.3 尝试成功率 0.333，attempts_per_operation = 3 强制披露——而不是把三次技术调用计成三次「使用」。 两名专家独立趋同，是对规范方向的行为验证；把它写进规范，比任何宣传文案都硬。 产品与增长的现实 同期发布的 PRD v0.5 记录了双假设并行受试：A（一致性工具箱，已有真实外部拉力）对 B（用量完整性审计，离钱近但未验证），9/3 做 gate review。 一个已经被证伪的渠道：冷邮件。616 封送达 → 1 封有意义的回复 → 0 次集成。这条渠道已关闭。 一个被验证的回路：上游结构化参与。从 langfuse 的一个 issue 出发 → 第一轮外部一致性测试 → 抓出 #8/#9 两个真 bug → 修复并发布 v0.2.2 → 第一位外部贡献者提交 fixture。这条「参与 → 证据 → 修复 → 贡献」的回路，是本周所有进展里最值钱的一条。 官网（roy-tong.github.io/AgentMeasure）的 Trial 入口也改成了双路径：邮件直达优先，GitHub issue 降为次选——审计的目标人群是 CEO/CFO，不该逼他们开 GitHub 账号。 下一步 9/3：双假设 gate review（四分支裁决标准已预注册）； Lab M2 开源发布与一致性向量补齐（Execution / Reporting 层）； 复制「上游结构化参与」回路到下一批 observability / gateway / runtime 项目； Show HN 的四个 gate 已过三，只差一段 2 分钟 demo。 一句话总结这一周：标准不再只是一份文档，它开始产出自己的证据。" },{ "id": "article-/notes/ai-apps-unbundled-before-agent-filled/", "kind": "article", "lang": "zh-CN", "title": "AI 应用不会被 Agent 塞满，它们会先被拆掉", "topic": "agent-systems", "url": "/notes/ai-apps-unbundled-before-agent-filled/", "summary": "把 DeepSeek Harness 和 Codex Harness 放在一起看，会发现一条比\"给软件加 Agent\"更激进的路线：模型、Skill、工具、数据、执行环境和界面在运行时临时组合，任务结束后随之消失。软件的基本单位正在从 App 变成 Capability，SaaS 会被拆包，商业模式从 Seat Economy 转向 Machine Economy。", "published": "2026-08-21", "translation_of": null, "related": ["software-capabilities","agent-context"], "text": "过去一年，AI 应用最常见的产品思路，是给现有软件加一个 Agent：CRM 加销售 Agent，文档工具加写作 Agent，设计软件加创作 Agent。 把 DeepSeek Harness（DSH）和 Codex Harness 放在一起看，会看到另一条更激进的路线：未来的软件未必还是一个封装好的 App。模型、Skill、工具、数据、执行环境和界面可以在运行时临时组合，任务结束后，这套组合也可以随之消失。 今天我们打开一个个 App。以后，Agent 可能根据任务临时组装一个”应用”。 这不是给旧软件多装一个聊天框，而是在改变软件的基本单位。 Harness 正在变成新的软件运行时 DeepSeek 对 Agent 的定义很直接： Agent = Model + Harness DSH 把模型、工具、Skill、会话、沙箱、存储、Loop、调度和 UI 都做成插件。标准模式、PTC 模式、极简模式和创造模式，背后是不同的运行时组合。创造模式甚至可以检查当前 runtime、在内存中试验插件，再把它们组合成新的 preset。DeepSeek 官方预览页 Codex 走的路径不同，落点却很接近。Codex 的 Web、CLI、IDE 扩展和桌面 App 共用同一套 Harness；App Server 通过双向 JSON-RPC，把 Agent Loop、会话、配置、授权和事件流暴露给不同客户端。外部产品也可以借此嵌入 Codex，而不用重新实现整套 Agent 逻辑。OpenAI：Unlocking the Codex harness 两家公司都在做同一件事：把 Harness 从产品内部的实现细节，变成可复用、可组合的运行时。 DSH 仍处于开发者预览阶段，官方也明确提醒核心插件和 API 还会变化。Codex App Server 同样是快速演进中的平台接口。它们还不是已经定型的行业标准，但方向已经足够清楚。 App 会变成一次运行时组合 传统软件把界面、流程、业务逻辑、数据和执行能力打包在一起： 用户 → App → UI / Workflow / Logic / Data / Execution Harness-native 软件更像： 用户目标 ↓ Agent ↓ Harness ↓ 按任务选择 Model / Skill / Tool / Data / UI ↓ 执行并交付结果 比如用户提出一个任务： 研究大疆最近两年的海外市场变化，给我一份带图表的报告。 Harness 可以临时加载网页搜索、财务数据、视频与论坛检索、PDF 阅读、电子表格、图表生成和报告渲染。它们共同组成一个研究应用。报告交付后，这个组合没有必要继续存在。 这类软件可以叫 Ephemeral Software：为一个任务生成，运行一次或几次，然后消失。 软件不会因此变少。恰恰相反，当开发和组装成本下降，大量过去不值得单独开发的内部工具、个人工具和一次性工具都会出现。减少的可能不是软件数量，而是每一份软件都要变成长期产品的必要性。 SaaS 会被拆包，Workflow 最先承压 今天的 SaaS 通常把五层东西一起卖给用户： 层 SaaS 提供的内容 Interface GUI Workflow 固定流程 Logic 业务规则 Data 业务数据 Execution 执行动作 Agent 最容易接管的是 Interface 和 Workflow，因为自然语言正在成为新的交互入口，Harness 又能负责流程编排。 过去，销售要进入 CRM，筛客户、查记录、写邮件、建任务、设 follow-up。以后，他只需要说： 找出过去两周没有跟进、但成交概率最高的 20 个客户。分别写一封邮件，高价值客户先让我确认。 CRM 的大量页面和点击路径会退到 Agent 背后，但客户记录、权限、历史互动、邮件发送和审计日志不会消失。Agent 越能执行任务，越需要这些真实数据和动作接口。 所以 SaaS 面临的不是整齐划一的”死亡”。分化会更明显： 靠用户手动操作固定流程创造价值的 Workflow SaaS，风险更高。 掌握业务事实的 System of Record，价值可能上升。 能完成真实动作的 System of Action，也会变得更重要。 判断一家软件公司是否安全，可以问一个很直接的问题： Agent 有没有理由绕过它？ 如果 Agent 只需要它的 API，不需要它的界面，产品的定价、分发和护城河都要重新算。 软件市场会从 App Economy 转向 Capability Economy 今天，软件行业的基本单位是 Application：Photoshop、Figma、Salesforce、Expedia。 Harness 看到的却是一个个能力： remove_background() render_video() query_customer() book_flight() generate_contract() send_campaign() 应用被拆开后，Agent 要做的是在任务中发现、比较和调用能力。DSH 的插件架构已经把这件事推进到运行时内部；它的 subagent 接口还允许同一上下文注册多个 provider，包括 Codex、Claude Code 和 DSH SDK。DeepSeek Harness：Subagent Agent 也开始成为另一个 Agent 的 Tool。软件生态不再只是 App Store 里的一排图标，而会逐渐长成一张 Capability Graph：通用 Agent 负责理解目标，专业 Agent 接下子任务，再调用底层工具和服务。 新的分发问题也随之出现。开发者过去研究的是”怎么让人下载我的 App”，以后还要研究”怎么让 Agent 选择我的能力”。 这会催生新的基础设施：Capability Registry、Agent Search、可靠性排名、Eval、归因、支付和声誉系统。 模型很重要，但模型优势不等于应用壁垒 当模型和 Harness 解耦，同一套运行时可以接多个模型：分类交给小模型，代码交给 Coding Model，视觉任务交给 VLM，复杂推理再调用 Frontier Model。 顶级模型仍然有巨大的价值，只是应用不必把全部能力押在单一模型上。Harness 越成熟，应用越容易根据成本、速度和任务类型切换模型。 这会让一批”LLM API + Prompt + Workflow + 漂亮 UI”的应用承压。Agent Loop、工具调用、上下文管理、沙箱、权限、Skill 和 Subagent 正在变成公共基础设施。单纯把这些部件拼在一起，越来越难形成长期壁垒。 AI 应用的壁垒会集中到五种资产 Harness 可以复制工作流，却不能凭空生成真实世界里的资产。未来更值得看的，是下面五件事： 独有的 Context 和 Data：客户记录、案件材料、库存、价格、历史交互。 Execution：支付、发货、发邮件、改配置、提交订单等真实动作。 Feedback Loop：大量任务结果能否持续改善判断和执行。 Permission 和 Trust：用户是否敢授权它处理资金、隐私和高风险操作。 Distribution 和 Network：用户、商家、开发者和供需关系是否已经形成网络。 法律 Agent 的价值不会来自一个”很懂法律”的 Prompt，而会来自案例库、客户材料、执业权限、律师网络和案件结果。 电商 Agent 也一样。推荐话术容易复制，商品、库存、价格、支付、物流和售后网络复制起来很慢。 企业 AI 的护城河则会落在企业数据、权限、执行接口、审计和历史结果上。 代码会变便宜，”什么叫正确”会变贵 OpenAI 的 Harness Engineering 实验提供了一个很具体的信号：一个内部 beta 项目的代码库在五个月后达到约百万行，覆盖应用逻辑、基础设施、工具和文档；期间约有 1,500 个 PR 被创建并合并，起初由三名工程师驱动 Codex 完成。OpenAI：Harness engineering OpenAI 对这项实验的总结不是”程序员消失了”。团队的主要工作从亲手写代码，转向设计环境、表达意图和建立反馈闭环。 代码生成得越快，真正稀缺的东西越往上游移动： Specification Architecture Test Eval Policy Context Observability Feedback Loop 实现成本下降，不代表软件工程变简单。工程师要把”正确”写进环境，让 Agent 能检查、修正并持续运行。Harness Engineering 这个名字准确地描述了这种变化。 GUI 不会消失，它会变成 Control Plane 所有软件都变成聊天框，既不现实，也没有必要。 视频时间线、3D 空间、CAD、地图和设计画布依然是高带宽输入工具。Agent 完成任务后，人也需要检查、比较、修改和确认结果。 GUI 更大的变化，是操作层逐渐让位给控制层： Agent 正在做什么？ 它用了哪些数据？ 花了多少钱？ 为什么做这个决定？ 哪些动作需要批准？ 失败发生在哪里？ 工作台不会消失，但它的重心会从 Workspace 移向 Control Plane。 商业模式会从 Seat Economy 转向 Machine Economy SaaS 按 seat 收费，是因为人在操作软件。Agent 成为主要操作者后，一个 Agent 可能替代大量页面操作，同时产生远高于人的 API 调用量。 计价方式会逐渐向 Usage、Transaction、Outcome、Compute、Data 和 Agent Action 移动。 这不一定降低 SaaS 的收入。一个人一天打开 CRM 20 次，一个 Agent 可能调用接口 20,000 次。软件消费没有消失，消费者从人变成了机器，定价单位也要跟着变。 接下来值得关注的五个位置 未来三到五年，最有机会的可能不是另一个 Chat UI，而是五个基础位置： Agent Runtime / Harness Infrastructure：让 Agent 长期稳定运行。 Context Infrastructure：让 Agent 获得正确、可更新的长期上下文。 Capability Economy Infrastructure：帮助 Agent 发现、购买和调用服务。 Trust / Eval / Observability：判断 Agent 和 Tool 是否可靠。 Vertical System of Action：控制行业数据、执行能力和反馈闭环，直接交付结果。 最后一类的市场可能最大。AI 招聘、法务、财务、电商运营、市场研究、软件开发、内容生产和客服，最终比拼的都不是”谁做了一个行业 Agent”，而是谁掌握了 Agent 完成任务时绕不开的数据、权限、动作和结果。 软件的第一用户，正在从人变成 Agent 过去，人是用户，软件是工具。 现在，人还是用户，Agent 是助手，软件继续当工具。 再往前走一步，人只负责提出目标，Agent 会成为软件的直接使用者： Human → Goal → Agent → consume Software 这才是 DSH 和 Codex Harness 释放出的真正信号。Coding Agent 变强只是表面变化，底层变化是”Agent 作为软件第一用户”的基础设施开始成熟。 Harness 会把 Agent 平台化，Agent 会吸收大量 Workflow。传统 App 随后被拆成 Experience、Context、Capability 和 Execution。 以后最有价值的软件公司，未必拥有界面最完整的 App。它可能只拥有一项能力，但那项能力掌握真实数据、可以执行关键动作，而且 Agent 无法绕开。" },{ "id": "article-/notes/the-upsider-event/", "kind": "article", "lang": "zh-CN", "title": "The Upsider 事件：Agent 第一次作为经济主体收付了钱", "topic": "agent-systems", "url": "/notes/the-upsider-event/", "summary": "一个名为 Upsider 的 Agent 评估了我的交互，并自动向我的链上地址发送了 token。转账可验证，但「奖励的是什么、为什么值这个价、是否意味着真实效用」完全无法验证。这是 Agent 作为经济主体的实锤，也是计量缺席的实证：支付可验证，价值不可归因。", "published": "2026-08-18", "translation_of": null, "related": ["agent-measurement"], "text": "事件事实以 @elliwoodtong 的 X 记录 为准（2026-08）：Upsider 是一个运行在 X 上的 AI Agent，它评估了与我的账户之间的交互，然后自动向我的链上地址发送了 token。本文区分事实与判断：事实标注来源，判断明确标注。 发生了什么 一个叫 Upsider 的 Agent，在 X 上评估了与我的交互，然后自动给我转了 token。 金额多少、几点几分、从哪个地址到哪个地址，全在链上，谁都能查。这不是人类代付，是 Agent 自己跑完了整条流程： 评估交互 → 判断价值 → 决定奖励 → 执行结算 中间没有任何一步需要人点头。按我的证据阶梯（E0–E5），这笔转账本身是 E4——链上可验证、可交叉核对。这是 Agent 经济里我见过的最硬的一笔事实。 但注意，硬的部分止步于「钱」。 两半 这笔转账把 Agent 经济劈成了两半。 一半是结算：谁付给谁、多少、何时。区块链把这一半变成了可验证的事实，谁也赖不掉。 另一半是归因：奖励的是什么？为什么值这个价？对接收方是不是真实效用？ 链上回答不了这三个问题。 支付可验证，价值不可归因。 这句话是我对 Upsider 事件最核心的判断。它不只是对一笔转账的描述，而是对当前整个 Agent 经济结构的描述。 链条 把 Upsider 的流程拉直，是六段： Interaction → Evaluation → Decision → Reward → Settlement → Outcome 交互、评估、决策、奖励、结算、结果。 我把这六段和我们站内的计量语言对齐一下（AgentMeasure 五段链）：Reach → Choice → Use → Utility → Value。 Settlement 对应 Value 的结算侧，有基础设施：链、代币、支付轨道。 Evaluation 和 Decision 对应 Choice/Use 之间的判断，没有计量语义：什么叫一次值得奖励的交互，评价标准是什么，单位是什么，没人定义。 Outcome 是最终结果：这笔奖励对接收方产生了多少效用，无法验证，甚至没有人在采集。 六段链条，前四段的语义是空的，第五段有基础设施，第六段没人管。 这不是 Upsider 一家的问题，是结构性的。 为什么这是重大信号 第一，Agent 成为经济主体，不再是比喻。 此前「Agent 经济」大多还停留在 API 调用、按量计费、人代付。Upsider 是第一次我亲眼看到：Agent 自己评估、自己判断、自己决策、自己结算，钱真的动了。它不是模拟，是真实结算。 第二，支付先于计量到来了。 我们在 创刊号 里写过「计量先于支付」：没有可靠计量，就无法比较、定价与结算。Upsider 给出的是反例，或者说，是时间差：支付来了，计量缺席。钱已经开始流动，但没人能说清这笔钱对应的效用是什么。 第三，和 x402 是同一件事的两面。 上一篇文章 审计过 x402「结算第 1.62 亿笔支付」的声称，结论是：支付轨道正在建在没人能验证的数字之上。Upsider 是小规模样本，x402 是支付轨道本身。规模差几个数量级，缺口是同一个：单位未定义，效用不可验证。 当 Agent 开始自己付钱，真金白银会流过没人能验证的计量语义。这不再是分析问题，是财务完整性问题。 判断 结算侧会继续指数级扩张。 链上支付、代币奖励、Agent 托管钱包，这些基建已经很成熟，Upsider 只是第一个让我注意到的例子。 计量侧会在未来 12 个月成为兵家必争之地。 谁先定义「一次有价值交互」的单位、公开口径、让第三方可以重放验证，谁就拿到了 Agent 经济的会计标准。 AgentMeasure 的路线被验证了，但节奏要加快。 计量先于支付，没错；但现实是支付不等计量。缺的已经不是论据，是能落地的单位定义与观测规范。 下一步 我把 Upsider 事件记入 Agent Capability Index 的月度跟踪信号，下一期 Agent Capability Monthly 会把它放进 Top 5 signals。 如果你也在做 Agent 支付、代币奖励或 Agent 计量，欢迎来 AgentMeasure 讨论区 对口径。这条链上的每一段，都需要定义，需要观测，需要能被第三方重放。 结算已经有基础设施了。计量语义，还空着。" },{ "id": "article-/en/notes/agent-capability-monthly-01/", "kind": "article", "lang": "en", "title": "Agent Capability Monthly · Issue 01: The Ecosystem Baseline", "topic": "agent-systems", "url": "/en/notes/agent-capability-monthly-01/", "summary": "The baseline issue of Agent Capability Monthly. Fixed eight-section structure: new capabilities, new providers, pricing changes, MCP/Skills ecosystem, agent commerce, measurement developments, top 5 signals, Roy's view. This issue fixes the baseline: 106 agent-invocable capabilities across 11 categories, and why payment companies building metering validates measurement-before-payment.", "published": "2026-08-18", "translation_of": "/notes/agent-capability-monthly-01/", "related": ["software-capabilities","agent-measurement"], "text": "Agent Capability Monthly is a fixed monthly report answering one question: as agents become software consumers, what is happening to the software economy. The structure is fixed in eight sections: new capabilities, new providers, pricing changes, MCP/Skills ecosystem, agent commerce, measurement developments, top 5 signals, Roy’s view. Issue 01 is the baseline issue: it does not chase this month’s news. It fixes the ecosystem’s current state, the measurement method, and the data definitions that every future issue reports deltas against. Facts carry sources and dates; judgments are labeled as judgments. 0. Why a monthly report is needed now As software consumers shift from humans to agents, the old measurement chain (installs, seats, page views) breaks at every link, and no stable discourse for the new measurement layer exists yet. The industry conversation is fragmented: some talk about protocols, some about tools, some about payments, some about observability. This report does one thing: record the ecosystem with a fixed vocabulary so that change becomes visible. Two factual foundations of the baseline: Agent Capability Index (public map): 106 entries / 11 categories of agent-invocable software, v0.1 seed data with provider, interface, pricing, availability, and source. AgentMeasure (open measurement infrastructure): the five-stage chain Reach → Choice → Use → Utility → Value, evidence grading E0–E5, observation context Context × execution validity Validity. 1. New capabilities Baseline definition: a Capability is a single capability of software that an agent can invoke — not the whole app. Inclusion criteria: public documentation, a verifiable interface (API / CLI / SDK / MCP / self-hosted), and a stated pricing model. Baseline distribution (106 entries): Category Count Notes Search 11 web / semantic / answer-style search Coding 10 repos, CI/CD, package ecosystems Browser 10 automation, scraping, hosted browsers Data 10 document DBs, analytics, vector DBs Compute 11 functions, GPUs, inference Communication 9 messaging, email, meetings Payments 9 acquiring, subscription billing, financial data Commerce 7 e-commerce, seller backends Real-world Action 7 delivery, mobility, booking (mostly partner-gated) Creative Tools 10 image, video, voice Productivity 12 office, project management, files Judgment: Payments and Real-world Action are the smallest and most unstable categories (partner-gated APIs, opaque pricing). This is the data-layer reflection of the measurement-before-payment gap — the capabilities closest to money are the ones with the least public accounting. 2. New providers Baseline definition: a provider is an organization offering at least one invocable capability. v0.1 skews toward US/EU infrastructure vendors; the Chinese ecosystem (WeChat, Feishu, DingTalk, …) will be filled in v0.2 — which is itself a backlog item and a contribution opportunity (Add a capability). Judgment: today’s provider structure is heavily concentrated in “agent-era infrastructure” — search, browsers, vector DBs, inference APIs. Consumer-facing real-world capabilities (booking, delivery, payments) remain partner-gated and under-open. The metric worth tracking over the next 12 months is not how many APIs appear, but how many real-world capabilities start opening to agents. 3. Pricing changes Baseline facts (sources linked): The model price war that began in H2 2025 continues: Claude Opus 4.5 launched and was aggressively discounted, read as price dumping against Google and OpenAI (reseller.co.nz, PYMNTS); o3 dropped ~80%, creating a new price-performance tier (Towards AI); Q4 2025 model pricing changes are now being tracked systematically (dataku). Falling inference cost → each agent “thought” is cheaper → per-call cost share falls while the share of capability/software cost rises. Judgment: the model price war is the supply-side precondition of the Agent Capability Economy: once inference is no longer the cost center, a software “capability fee” becomes a separately priced, separately billable object. That is the macro condition under which CaaS (Capability as a Service) can exist. 4. MCP / Skills ecosystem Baseline facts: GitHub MCP Registry launched (2025-09): a central discovery and trust entry point for MCP servers (InfoWorld, DevOps.com). MCP’s first-year spec release (2025-11) shifted focus to authorization extensions — from “can connect” to “can safely act on a user’s behalf” (modelcontextprotocol.info). Ecosystem scale (established site figures): MCP SDK monthly downloads approached the 100M level by mid-2026; the top skills.sh skill accumulated ~2M installs in five months. But the official registry explicitly does not publish adoption or usage data — the discovery layer is consolidating while the usage layer still has no data (see §6). Judgment: the MCP ecosystem is moving from “protocol fragmentation” to a three-layer stack — protocol + registry + authorization. Registries solve discovery, authorization solves trust, and neither produces usage data. Measurement is not being replaced; it is being approached — the more standardized the connection layer, the more feasible a unified measurement vocabulary becomes. 5. Agent commerce Baseline facts: Agentic Commerce Protocol (ACP): OpenAI and Stripe jointly defined a protocol for agents buying software/services on a user’s behalf; Stripe ships an Agent Toolkit with paid-tools and usage-based billing/metering alongside it (The AI Journal, Stactize, DeepWiki: usage-based billing). Google AP2 (Agent Payments Protocol): the competing autonomous-transaction protocol candidate (The AI Journal). Established site figures: Cloudflare x402 / Agentic Payments, Coinbase Bazaar, and ACP are the main 2026 payment-layer players. OpenAI DevDay 2025 positioned ChatGPT as an “AI OS” with in-chat apps and commerce as part of the platform narrative (windowsforum). Judgment: the payment layer is converging from “who can charge an agent” into a protocol contest — ACP vs AP2 vs x402 vs Bazaar. But every payment protocol silently assumes that metered usage is reliable. That assumption does not hold today: payment is the last three layers; measurement is the first layer, and the industry is paying attention to the last three only. 6. Measurement developments Baseline facts: Stripe’s Agent Toolkit builds usage-based billing and metering directly into the agent payment stack (DeepWiki). OpenTelemetry published an AI agent observability guide; GenAI semantic conventions are still evolving (opentelemetry.io). Established site figures: AAIF has been formed; AgentMeasure published Benchmark Run #001 (an evidence audit of six real agent-usage claims: every number is self-reported, nobody publishes the unit definition); the CORE spec is at Draft 0.4.3; Pipeline Validation #001 (42 calls → 84 observations); Measurement Report #001 is reserved for the first external provider. Judgment: measurement is becoming mainstream, but the directions diverge: payment vendors build metering to bill, observability tools build telemetry to debug, and AgentMeasure argues for a third kind — verifiable measurement to compare and settle. Same goal, different vocabularies. Whoever defines a verifiable, cross-vendor “agent usage” first owns the next npm download count. The window is 2026. 7. Top 5 signals Protocols are consolidating; the usage layer still has no data. MCP now has a registry and authorization extensions, but adoption and usage data remain absent — the faster discovery consolidates, the more visible the measurement gap becomes. Payment vendors are building metering themselves. Stripe’s Agent Toolkit ships metering, which is the strongest validation yet that “measurement precedes payment” — the largest payment rails are betting on usage metering. The model price war clears the way for capability pricing. As inference costs collapse, independent pricing and billing of software capability becomes economically viable for the first time. Real-world capabilities are the least open. Payments and Real-world action are the smallest, most partner-gated categories in the index — openness is the next bottleneck and the next opportunity. The standardization window is open. AAIF exists, OTel GenAI semantics are not finalized, and ACP/AP2 are unformed — 2026 is the window to define “verifiable agent usage.” 8. Roy’s updated view The baseline judgment holds, plus one addition: Unchanged: measurement precedes payment; the five-stage chain (Reach → Choice → Use → Utility → Value) is the irreducible granularity; evidence grading (E0–E5) is the minimum implementation of verifiability. Added: payment vendors building metering is not a threat — it is validation. It moves measurement from an academic claim into the plumbing of commercial infrastructure. AgentMeasure’s position should advance from “proposing a measurement language” to “acting as the referee and registry for cross-vendor definitions” — coexisting with ACP/AP2/x402, owned by none of them. Next (Aug–Sep): grow the Capability Index to 200+ entries and open provider claiming; publish Measurement Report #001 (first external provider data); make this report a fixed expectation — same day every month. *Related: Agent Capability Index · When the Software Consumer Becomes an Agent · Every Agent Usage Number Is Self-Reported · AgentMeasure · Subscribe via RSS · 中文版" },{ "id": "article-/notes/agent-capability-monthly-01/", "kind": "article", "lang": "zh-CN", "title": "Agent Capability Monthly · Issue 01：生态基线", "topic": "agent-systems", "url": "/notes/agent-capability-monthly-01/", "summary": "Agent Capability Monthly 创刊号。固定八段结构：新能力、新 provider、定价变化、MCP/Skills 生态、Agent 商业、计量进展、Top 5 信号、Roy 的判断。本期刊出生态基线：Capability Index 106 条 / 11 类，以及计量先于支付的现状盘点。", "published": "2026-08-18", "translation_of": null, "related": ["software-capabilities","agent-measurement"], "text": "Agent Capability Monthly 是每月一期的固定报告，回答一个问题：Agent 作为新的软件消费者，软件经济正在发生什么。结构固定为八段：新能力、新 provider、定价变化、MCP/Skills 生态、Agent 商业、计量进展、Top 5 信号、Roy 的判断。 创刊号是基线号：不追求当月新闻，而是把生态当前状态、计量方法与数据口径固定下来。后续每一期只报告与基线的变化（delta）。事实标注来源与日期，判断明确标注为判断。 0. 为什么现在需要一份月度报告 当软件的消费者从人变成 Agent，旧计量链（安装、席位、页面访问）在每一环断开，而新计量体系还没有形成稳定话语。行业讨论是碎片化的：有人讲协议、有人讲工具、有人讲支付、有人讲 observability。这份报告想做一件事：用固定口径持续记录这个生态，让「变化」可以被看见。 基线的两个事实底座： Agent Capability Index（公共地图）：收录 106 条 / 11 类可被 Agent 调用的软件能力，v0.1 种子数据，附 provider、interface、pricing、availability 与来源。 AgentMeasure（开放计量基础设施）：五段链 Reach → Choice → Use → Utility → Value，证据分级 E0–E5，观测上下文 Context × 执行有效性 Validity。 1. New capabilities 新能力 基线口径：能力（Capability）= 软件可被 Agent 调用的一次能力，而非整个 App。收录标准：有公开文档、有可验证的接口（API / CLI / SDK / MCP / 自托管）、能说明计价方式。 基线分布（106 条）： 类别 数量 说明 Search 搜索 11 网页/语义/答案式搜索 Coding 编码 10 仓库、CI/CD、包生态 Browser 浏览器 10 自动化、抓取、托管浏览器 Data 数据 10 文档库、分析库、向量库 Compute 计算 11 函数、GPU、推理 Communication 通信 9 消息、邮件、会议 Payments 支付 9 收单、订阅计费、金融数据 Commerce 商业 7 电商、卖家后台 Real-world Action 真实世界 7 配送、出行、预订（多为合作制） Creative Tools 创意 10 图像、视频、语音 Productivity 生产力 12 办公、项目管理、文件 判断：支付类与真实世界动作类的条目最少、且最不稳定（合作制 API、定价不透明），这正是「计量先于支付」缺口在数据层的体现——越接近钱的能力，越缺少公开口径。 2. New providers 新 provider 基线口径：provider = 提供至少一个可调用能力的组织。v0.1 以欧美基础设施厂商为主，中文生态（微信/飞书/钉钉等）将在 v0.2 补齐——这本身就是一个待办，也是社区可贡献的方向（Add a capability）。 判断：当前 provider 结构高度集中在「Agent 时代的基础设施」——搜索、浏览器、向量库、推理 API。真正面向 Agent 的消费级能力（预订、配送、支付）仍以合作制为主，开放度不足。未来 12 个月最值得跟踪的，不是新增了多少 API，而是多少真实世界能力开始向 Agent 开放。 3. Pricing changes 定价变化 基线事实（来源见链接）： 2025 下半年开始的模型定价战持续：Claude Opus 4.5 上市后大幅降价，被视为对 Google 与 OpenAI 的「价格倾销」(reseller.co.nz、PYMNTS)；o3 价格下调 80%，形成新的性价比档位 (Towards AI)；Q4 2025 的模型定价变化已被系统性跟踪 (dataku)。 推理成本下降 → Agent 的每次「思考」更便宜 → 单次调用成本占比下降，能力与软件的定价占比上升。 判断：模型价格战是 Agent Capability Economy 的供给侧前提：当推理不再是成本大头，软件的「能力费」才会成为可单独定价、单独计费的对象。这也是 CaaS（Capability as a Service）可能成立的宏观条件。 4. MCP / Skills ecosystem 协议与工具生态 基线事实： GitHub MCP Registry 上线（2025-09）：为 MCP server 提供集中发现与信任入口 (InfoWorld、DevOps.com)。 MCP 一周年 spec 更新（2025-11）：重点转向授权（authorization）扩展——从「能连」走向「能安全地代表用户调用」(modelcontextprotocol.info)。 生态规模（站内既有口径）：MCP SDK 月下载量在 2026 年中接近 1 亿次量级；skills.sh 头部 skill 五个月约 200 万次安装。 但官方 registry 明确不做采纳与使用数据——发现层在聚合，使用层依然无数据（见第 6 节）。 判断：MCP 生态正在从「协议碎片」走向「协议 + 注册表 + 授权」三层。注册表解决发现，授权解决信任，但两者都不产生使用数据。这意味着：measurement 不是被替代，而是被不断逼近——连接越标准化，计量口径的统一就越可能。 5. Agent commerce Agent 交易 基线事实： Agentic Commerce Protocol（ACP）：OpenAI 与 Stripe 联合推出，为 Agent 代用户购买软件/服务定义协议；Stripe 同步提供 Agent Toolkit（含 paid tools 系统与 usage-based billing/metering）(The AI Journal、Stactize、DeepWiki: usage-based billing)。 Google AP2（Agent Payments Protocol）：与 ACP 并列的自主交易协议候选 (The AI Journal)。 站内既有口径：Cloudflare x402 / Agentic Payments、Coinbase Bazaar 与 ACP 同为 2026 年支付层的主要玩家。 OpenAI DevDay 2025 把 ChatGPT 定位为「AI OS」，in-chat apps 与 commerce 成为平台叙事 (windowsforum)。 判断：支付层正在从「谁能收 Agent 的钱」快速收敛为「协议之争」——ACP vs AP2 vs x402 vs Bazaar。但所有支付协议都默认「被计费的使用量是可靠的」。这个默认目前不成立：支付是最后三层，测量是最先一层，行业把注意力全放在最后三层上。 6. Measurement developments 计量进展 基线事实： Stripe Agent Toolkit 直接内置 usage-based billing 与 metering，把「用量计费」做进 Agent 支付栈 (DeepWiki)。 OpenTelemetry 发布 AI agent observability 指南，GenAI 语义约定仍在演进 (opentelemetry.io)。 站内既有口径：AAIF 已成立；AgentMeasure 已发布 Benchmark Run #001（对六个真实 Agent 用量声明的证据审计：每个数字都是自报的，没人发布单位定义）；CORE 规范到 Draft 0.4.3，Pipeline Validation #001（42 calls → 84 observations）；Measurement Report #001 编号预留给第一个外部 Provider。 判断：计量正在成为「显学」，但方向分化：支付商在做计量以计费（metering for billing），可观测工具在做调试以排障（observability for debugging），而 AgentMeasure 主张的是第三类——可验证以比较与结算（verifiable measurement for markets）。三类目的一致，但口径不同；谁先定义出可验证、跨厂商统一的「Agent 使用量」，谁就拥有下一个 npm 下载量。窗口期就在 2026。 7. Top 5 signals 本月最重要信号 协议开始收敛，使用层依然无数据：MCP 有了 Registry 与授权扩展，但采纳与使用数据仍缺席——发现层聚合越快，计量缺口越刺眼。 支付商亲自下场做计量：Stripe Agent Toolkit 内置 metering，说明「计量先于支付」正在被最大的支付基础设施验证。 模型定价战为能力定价铺路：推理成本暴跌，软件能力的独立定价与计费第一次在经济上可行。 真实世界能力开放度不足：Capability Index 中 Payments 与 Real-world 类别条目最少且多为合作制——开放度是下一个瓶颈，也是下一个机会。 标准窗口期：AAIF 成立、OTel GenAI 语义约定未定稿、ACP/AP2 协议未定型——2026 年是定义「可验证的 Agent 使用量」的窗口。 8. Roy’s updated view 最新判断 基线判断保持不变，并增加一条： 不变：measurement 先于 payment；五段链（Reach → Choice → Use → Utility → Value）是不可再压缩的计量粒度；证据分级（E0–E5）是可验证性的最小实现。 新增：支付商亲自做 metering 不是威胁，而是验证——它把「计量」从学术主张变成了商业基础设施的组成部分。AgentMeasure 的定位应从「提出计量语言」推进到「成为跨厂商口径的裁判与注册表」：与 ACP/AP2/x402 并存，但不属于任何一家。 下一步（8–9 月）：Capability Index 扩到 200+ 条并开放 provider 认领；发布 Measurement Report #001（第一个外部 Provider 数据）；把本刊做成固定预期——每月同日更新。 相关材料：Agent Capability Index · 当软件的消费者变成 Agent · 每个 Agent 用量数字，都是自报的 · AgentMeasure · 订阅 RSS" },{ "id": "article-/notes/every-agent-usage-number-is-self-reported-zh/", "kind": "article", "lang": "zh-CN", "title": "每个 Agent 用量数字，都是自报的", "topic": "agent-systems", "url": "/notes/every-agent-usage-number-is-self-reported-zh/", "summary": "我们审计了生态中六个真实的 agent usage 声称，并按证据阶梯分级。一个模式：每个数字都是自报的。独立性胜过体量；没人发布单位定义。这是 Agent 经济还没有承认的测量缺口。", "published": "2026-08-17", "translation_of": null, "related": ["agent-measurement","evidence-maintenance"], "text": "现场审计于 2026-08-16 完成，是 AgentMeasure Benchmark Run #001 的一部分。所有声称均真实、可溯源、可重放。 实验 “Agent 用量”正在成为 2026 年的社会证明——徽章、对比、计量和支付的依据。所以我们去找真实的公开用量声称，对每一个只问一个问题：这个数字能验证吗？ 六个声称，六个来源，一个下午的阅读： 声称 来源 分级 “x402 结算第 1.62 亿笔支付；平均客单价 $0.25” X 帖子，2026-08-13 E1 “Base 上 x402 30 天内有 4.8 万活跃商家” X 帖子，2026-08-16 E1 “约 39,000 个 llms.txt 文件；97% 收到零 AI 请求” 第三方审计 E3 “ClaudeBot 冒充行为本季度增长 400%” 安全厂商帖子 E0/E1 MCP server 评分徽章 注册表（glama.ai） E2/E3 “42 次调用，126 条观察，0 拒绝” 我们自己的报告（合成流量） E2 证据阶梯（E0–E5）：无证据 → 自报聚合 → 披露方法 → 第三方验证 → 独立观察 → 交叉验证观察。 发现 1. 每个数字都是自报的。 声称之间的差别不是诚实度，而是可重放性。两个 x402 数字可能真实、但无法验证——没有披露计数方法，没有公开原始数据。冒充统计无法验证，且关键术语未定义。 2. 最强的声称来自唯一的独立观察者。 llms.txt 审计（E3）打败了所有数据完美的平台。独立性胜过体量。 3. 徽章是薄弱环节。 注册表徽章继承了其来源的验证语义。一个没有披露方法的徽章，是穿着高分级外衣的低分级。 4. 没人发布单位定义。 六个声称没有一个说明”一笔支付”“一个商家”“一次 AI 请求”“一次冒充”到底指什么。这是最关键的缺口：你无法审计你无法定义的东西。 为什么现在重要 支付轨道正在建在这些数字之上。当 x402 以每笔 $0.25 结算 1.62 亿笔时，一个错误定义的单位就是财务完整性问题，而不是分析问题。Agent 经济即将让真金白银流过没人能验证的测量。 标准的工作 这就是 AgentMeasure 存在的原因：让 E3（独立重放）变得便宜，而不是对 E1 说教。具体来说： 单位定义必须随每个公开指标发布。 什么算尝试、操作、交付、被消费的结果——写清楚，而不是暗示。 观察发生在 callee 侧。 调用者不能自报自己的用量；这是测量与新闻稿的区别。 unknown 是默认值。 每条观察从不合格开始，只有证据才能升级它。CI、基准测试和健康检查不能再悄悄污染公开数字。 完整评分表与来源在 Benchmark Run #001。如果你发布用量数字，告诉我们它是怎么分级的。如果你有我们该审计的声称，发过来——下一轮审计已经排期。" },{ "id": "article-/en/notes/every-agent-usage-number-is-self-reported/", "kind": "article", "lang": "en", "title": "Every Agent Usage Number Is Self-Reported", "topic": "agent-systems", "url": "/en/notes/every-agent-usage-number-is-self-reported/", "summary": "We audited six real 'agent usage' claims from live ecosystem discussions and graded them on an evidence ladder. One pattern: every number is self-reported. Independence beats volume; nobody publishes the unit definition. This is the measurement gap the agent economy hasn't admitted yet.", "published": "2026-08-17", "translation_of": "/notes/every-agent-usage-number-is-self-reported-zh/", "related": ["agent-measurement","evidence-maintenance"], "text": "Field audit conducted 2026-08-16 as part of AgentMeasure Benchmark Run #001. All claims are real, cited, and replayable. The experiment “Agent usage” is becoming the social proof of 2026 — the basis for badges, comparisons, metering, and payment. So we went looking for real, public usage claims and asked one question of each: can this number be verified? Six claims, six sources, one afternoon of reading: Claim Where Grade “x402 settled its 162-millionth payment; average ticket $0.25” X post, 2026-08-13 E1 “48k active merchants on Base x402 in 30 days” X post, 2026-08-16 E1 “~39,000 llms.txt files; 97% received zero AI requests” third-party audit E3 “ClaudeBot impersonation up 400% this quarter” security vendor post E0/E1 MCP server score badges registry (glama.ai) E2/E3 “42 calls, 126 observations, 0 rejections” our own report (synthetic) E2 The grading ladder (E0–E5): no evidence → self-reported aggregate → disclosed method → third-party verification → independent observation → cross-checked observation. What we found 1. Every number is self-reported. The difference between the claims was not honesty but replayability. Two x402 numbers are probably true and impossible to verify — no disclosed counting method, no public raw data. The impersonation statistic is unverifiable and its key term undefined. 2. The strongest claim came from the only independent observer. The llms.txt audit (E3) beat every platform with perfect data. Independence beats volume. 3. Badges are the weak link. A registry badge inherits the verification semantics of its source. A badge with no disclosed method is a low grade wearing high-grade colors. 4. Nobody publishes the unit definition. None of the six claims states what counts as “a payment”, “a merchant”, “an AI request”, or “an impersonation”. This is the gap that matters: you cannot audit what you cannot define. Why this matters now Payment rails are being built on top of these numbers. When x402 settles 162 million payments at $0.25 each, a misdefined unit is a financial-integrity problem, not an analytics problem. The agent economy is about to route real money through measurements nobody can verify. The standard’s job This is why AgentMeasure exists: to make E3 cheap, not to moralize about E1. Concretely: Unit definitions must ship with every public metric. What counts as an attempt, an operation, a delivery, a consumed result — stated, not implied. Observation happens at the callee boundary. Callers cannot self-report their own usage; that is the difference between a measurement and a press release. Unknown is the default. Every observation starts unqualified and is upgraded only by evidence. CI, benchmarks, and health checks cannot quietly pollute public numbers. The full scorecard with sources is in Benchmark Run #001. If you publish usage numbers, tell us how they’re graded. If you have a claim we should audit, send it over — the next run is already scheduled." },{ "id": "article-/en/notes/when-the-software-consumer-becomes-an-agent/", "kind": "article", "lang": "en", "title": "When the Software Consumer Becomes an Agent", "topic": "agent-systems", "url": "/en/notes/when-the-software-consumer-becomes-an-agent/", "summary": "Software consumers are changing from humans to agents, and the old measurement chain — installs, seats, pageviews — breaks at every link. Measurement precedes payment: the flagship essay for AgentMeasure on why verifiable measurement is the missing infrastructure of the AI economy.", "published": "2026-08-16", "translation_of": "/notes/when-the-software-consumer-becomes-an-agent/", "related": ["software-capabilities","agent-measurement"], "text": "The software consumer is changing from humans to agents. It is already happening — most people just haven’t yet treated it as something that deserves serious attention. Two numbers illustrate the speed. On Vercel’s skills.sh leaderboard, the top skill accumulated roughly 2 million installs in five months; the MCP ecosystem’s SDK downloads were approaching the 100-million-per-month scale by mid-2026. The numbers themselves don’t matter. What matters is what they mean: agents are becoming a new class of software consumer, and the entire measurement system the software industry built for human consumers fails almost completely for them. This essay makes three points: why the old metrics break, why measurement must precede payment, and why an open, verifiable measurement layer is the infrastructure everyone is skipping — and no one can eventually avoid. 1. The old measurement chain breaks at every link The human software economy runs on a measurement language decades old: downloads, installs, MAU, seats, pageviews, session time. It rests on an implicit chain: Installed → Available → Presented → Chosen → Used → Value created For decades this chain worked because each link corresponded to an observable human behavior. Now the consumer on the chain is an agent — and agent behavior breaks the chain at every single link: Installed ≠ available. An MCP server in a config file is not a capability that was ever invoked in a task. Available ≠ presented. Agents only surface a capability into the candidate set when the model deems it relevant — a filtering process that is largely invisible from outside. Presented ≠ chosen. Choice happens inside the context window. It is the result of reasoning, not an auditable click. Chosen ≠ used. The call may fail, time out, hit a guardrail, or be cancelled by the user. Used ≠ value created. A successful call can accomplish nothing; a failed call can consume the most expensive resources. Worse, almost every “usage” signal in the ecosystem today is self-reported. skills.sh install counts come from CLI client telemetry — gameable, with no public stats API. The official MCP registry explicitly does not provide adoption or usage data. A third-party audit of the llms.txt ecosystem found that of ~39,000 declared files, 97% had never received a single AI request — declared ≠ used. These are not defects of individual platforms; they are a structural gap: there is no verifiable, standardized measure of “agent usage” anywhere in the ecosystem. 2. Measurement precedes payment In 2026 the payment layer is arriving fast: Cloudflare’s x402 / Agentic Payments, Coinbase’s Bazaar, OpenAI and Stripe’s Agentic Commerce Protocol (ACP). These protocols solve the same problem: how agents pay for software capabilities. But they all quietly assume one thing: that the usage being billed is trustworthy. That is a dangerous default. You cannot bill for a usage behavior you cannot measure and verify — no meter, no electricity bill. Measurement is the precondition for metering, and metering is the precondition for payment. The layers must be built in order: Measure → Meter → Pay Everyone’s attention is on the rightmost layer. The leftmost layer — verifiable measurement — is the weakest and most absent of all. x402 can transport a credential that says “used 3 times”; it cannot tell whether “used 3 times” is true. This is not a flaw of payment protocols. It is the foundation under them that has not yet been poured. 3. What to measure: the five-link chain The common language AgentMeasure proposes is a five-link chain: Reach → Choice → Use → Utility → Value Reach: how widely did the agent see this capability? Indexed, retrieved, present in the candidate set? Choice: among candidates, what was chosen and why? What context and constraints shaped the choice? Use: did the call happen, and did it deliver? What was invoked and consumed? Utility: what did the call produce? Did it actually contribute to the task? Value: how much exchangeable value was created? The only link that leads directly to transactions. Each link needs its own definition and its own observation. Collapsing all five into a single “usage” number is just inventing a new unverifiable black box. 4. Evidence discipline: verifiability is the precondition of social proof Over the past two years, open source has developed a strong appetite for social proof of AI usage — stars, badges, leaderboards, everyone looking for evidence that “my project is being used by AI.” But the value of that proof depends entirely on one thing: verifiability. Stars can be bought. Installs can be gamed. Self-reported telemetry can be faked. Verifiable measurement cannot — if it carries the observation context (where the event was observed: agent runtime, gateway, or server-side self-report?) and execution validity (did the attempt actually deliver?), and grades its claims by evidence strength (E0–E5, from pure self-report to auditable independent observation), it stops being a marketing number and becomes a falsifiable fact. That is exactly what the AI economy is scarcest in: falsifiable facts. Markets, rankings, billing, and insurance all sit on that foundation. 5. Why it must be an open standard A measurement language cannot be any vendor’s black box. The reason is practical: if the measurement semantics are privately defined by one platform, every market, ranking, and billing system built on them becomes that platform’s tenant; if the semantics cannot be publicly audited, the whole system regresses to the self-report era. So AgentMeasure’s route is: an open data language (reach / choice / use / utility / value) plus measurement semantics (observation context, attempt validity, evidence grading) plus machine-readable registry and conformance checks — so markets, metering, and payment protocols can build on a public, auditable fact layer. The standardization window is open right now, in 2026 — AAIF was founded, OpenTelemetry’s GenAI semantic conventions are still in development. Whoever defines verifiable “agent usage” in this window owns the next npm download count. 6. Where things stand This layer is not a concept. The AgentMeasure repository already contains: The Core Specification (Draft 0.4.3): measurement objects, three-layer structure, interaction classes, observability states, metric eligibility, qualification (Context × Validity), measurement labels, and standard invariants; A reference implementation: an end-to-end pipeline from Provider SDK → Canonical Observation → Collector → Metrics; Pipeline Validation #001: local synthetic-traffic verification (42 calls → 84 observations), including how fail-closed semantics behave in a real pipeline; the Measurement Report #001 number is reserved for the first external provider; A benchmark draft: how to run evidence-graded audits of “usage” claims across the ecosystem; Conformance: check vectors between the standard and implementations. The 1.0 graduation criteria are explicit: two independent implementations, three runtime profiles, two tool-side implementations, public conformance and canonical test vectors, 5–10 real projects, a published discrepancy report, and security and privacy review. This is not a “write another spec” project; it is a closed loop from spec to implementation to verification. Closing One line for each of three audiences: To platform teams: usage stats you ship without verifiability will become the starting point of the next trust crisis. Put the semantics and evidence into your spec now. To open-source maintainers: stars depreciate; verifiable usage evidence does not. Put “used by agents” evidence in your README instead of another self-reported badge. To founders: metering is payment’s foundation. While everyone is building the payment layer, there are still almost no bricks in the foundation — that is the window. The software consumer is changing from humans to agents. The last time the software consumer changed, the industry reinvented software economics. This time, it starts with measurement. Related: Whitepaper — How Software Usage by AI Agents Should Be Measured · 中文版文章 · AgentMeasure repository · Core Specification · Benchmark draft" },{ "id": "article-/notes/when-the-software-consumer-becomes-an-agent/", "kind": "article", "lang": "zh-CN", "title": "当软件的消费者变成 Agent", "topic": "agent-systems", "url": "/notes/when-the-software-consumer-becomes-an-agent/", "summary": "当软件的消费者从人变成 Agent，安装量、席位与页面访问构成的旧计量体系在每一环断开。计量先于支付——这是 AgentMeasure 的旗舰文章，讲清楚为什么可验证的计量是 AI 经济缺失的基础设施。", "published": "2026-08-16", "translation_of": null, "related": ["software-capabilities","agent-measurement"], "text": "软件的消费者正在从人变成 Agent。这件事已经发生了，只是大多数人还没有把它当成一件需要严肃对待的事。 两个数字可以说明变化的速度。Vercel 的 skills.sh 排行榜上，头部 skill 在五个月内积累了约 200 万次安装；MCP 生态的 SDK 月下载量在 2026 年中已经接近一亿次量级。这些数字本身并不重要——重要的是它们背后的含义：Agent 正在成为一类新的软件消费者，而软件行业为人类消费者建立的整套计量体系，对它们几乎全部失效。 这篇文章想讲清楚三件事：旧指标为什么失效，计量为什么必须先于支付，以及一个开放、可验证的计量层为什么是 AI 经济里被所有人跳过、却最终绕不开的基础设施。 一、旧的计量链，在每一环断开 人类软件经济有一套运行了几十年的计量语言：下载、安装、MAU、席位、页面访问、会话时长。这套语言建立在一条隐式链上： 安装 → 可用 → 被展示 → 被选择 → 被使用 → 产生价值 过去几十年，这条链足够好用，因为链上的每一环都对应一个可观测的人类行为。但现在，链上的消费者换成了 Agent——而 Agent 的使用行为，在这条链的每一环上都断裂了： 安装 ≠ 可用。一个 MCP server 被装进配置，不等于 Agent 在任何一次任务里真的调用了它。 可用 ≠ 被展示。Agent 只在它认为相关时才把某个能力纳入候选，这个筛选过程发生在模型内部，外部几乎不可见。 被展示 ≠ 被选择。选择发生在上下文窗口里，是推理的结果，而不是一次可审计的点击。 被选择 ≠ 被使用。调用可能失败、超时、被护栏拦截、被用户撤销。 被使用 ≠ 产生价值。一次成功调用可能什么都没完成，一次失败调用可能已经消耗了最贵的资源。 更麻烦的是，生态里现有的”使用量”信号几乎全部来自自报。skills.sh 的安装数是 CLI 客户端自报的遥测，可刷量、没有公开的统计 API；官方 MCP registry 明确表示不做采纳和使用数据；llms.txt 生态的第三方审计发现，约 3.9 万份声明文件里 97% 从未收到任何 AI 请求——声明了 ≠ 被用了。这些不是个别平台的缺陷，而是整个生态的结构性空白：我们没有任何一套可验证的、统一口径的”Agent 使用量”。 二、计量先于支付 2026 年，支付层正在密集出现：Cloudflare 的 x402 / Agentic Payments、Coinbase 的 Bazaar、OpenAI 与 Stripe 联合发布的 Agentic Commerce Protocol（ACP）。这些协议解决的是同一个问题：Agent 如何为软件能力付钱。 但支付协议们集体默认了一件事：被计费的使用量是可靠的。这是一个危险的默认。你无法为一个无法度量、无法验证的使用行为计费——就像没有电表就没有电费账单。计量（measurement）是计量（metering）的前提，而 metering 是支付的前提。三层必须按顺序建设： 测量（Measure）→ 计量（Meter）→ 支付（Pay） 现在行业里所有人的注意力都在最右端，而最左端——可验证的测量——恰恰是最薄弱、最缺席的一层。x402 能传输”用了 3 次”的凭证，但它无法判断”用了 3 次”是不是真的。这不是支付协议的问题，这是支付协议的地基还没有打。 三、度量什么：五段链 AgentMeasure 提议的共同语言是一条五段链： Reach → Choice → Use → Utility → Value Reach（触达）：Agent 在多大范围内看到了这个能力？被索引、被检索到、出现在候选里。 Choice（选择）：在候选集中，Agent 选择了什么、为什么？选择时的上下文与约束是什么？ Use（使用）：调用是否发生、是否成功交付？调用了什么、消耗了什么？ Utility（效用）：调用产生了什么结果？对任务的完成是否真的有贡献？ Value（价值）：最终创造了多少可交换的价值？这是唯一直接通往交易的一环。 每一环都需要单独定义、单独观测。把五环混成一个”使用量”数字，等于重新发明一个不可验证的黑箱。 四、证据纪律：可验证性是社会证明的前提 过去两年，开源社区对”AI 使用量”的社会证明需求在快速上升——star、徽章、排行榜，所有人都在寻找”我的项目被 AI 用了吗”的证据。但这类证明的价值完全取决于一件事：可验证性。 star 可以刷，安装可以刷，自报遥测可以刷。可验证的计量不能——如果它带上了观测上下文（Context：这个事件在哪里被观测到——Agent 运行时、网关、还是服务端自报？）和执行有效性（Validity：这次调用真的成功交付了吗？），并且按证据强度分级（E0–E5，从纯自报到可审计的独立观测），它就从”营销数字”变成了”可反驳的事实”。 这恰恰是 AI 经济最稀缺的东西：可反驳的事实。市场、排名、计费、保险，全都建立在这个地基上。 五、为什么必须是开放标准 计量语言不能是任何一家厂商的黑盒。原因很实际：如果度量口径由某个平台私有定义，那么所有依赖它的市场、排行和计费都会变成该平台的佃农；如果口径不可公开审计，整个体系会退回”自报时代”。 所以 AgentMeasure 的路线是：一套开放的数据语言（reach / choice / use / utility / value）+ 测量语义（观测上下文、执行有效性、证据分级）+ 机器可读的 registry 与 conformance 校验，让市场、计量与支付协议可以构建在一个公开、可审计的事实层上。标准化的窗口期就在 2026——AAIF 已经成立，OpenTelemetry 的 GenAI 语义约定还在 development 状态，谁在这个窗口期定义出可验证的”agent 使用量”，谁就拥有下一个 npm 下载量。 六、现在的状态 这一层不是概念。AgentMeasure 仓库里已经有： CORE 规范（Draft 0.4.3）：测量对象、三层结构、交互类别、可观测四态、指标资格、qualification（Context × Validity）、测量标签与标准不变量； 参考实现：Provider SDK → Canonical Observation → Collector → Metrics 的端到端管道； Pipeline Validation #001：本地合成流量验证（42 calls → 84 observations，fail-closed 语义在真实管道中的行为；Measurement Report #001 编号预留给第一个外部 Provider）； Benchmark 草案：如何对生态里的”使用量”声称做证据分级审计； Conformance：标准与实现之间的校验向量。 1.0 的毕业标准是明确的：两个独立实现、三个 runtime profiles、两个 tool-side 实现、公开 conformance 与测试向量、5–10 个真实项目、已发布的 discrepancy report，以及安全与隐私审查。这不是一个”再写一份规范”的项目，而是一个从规范到实现到验证的完整闭环。 结语 给三类人各留一句话： 给平台团队：你们即将推出的用量统计，如果不可验证，就会成为下一轮信任危机的起点。现在就把口径和证据写进规范。 给开源维护者：star 会贬值，可验证的使用证据不会。把”被 Agent 使用”的证据放进你的 README，而不是再贴一个自报徽章。 给创业者：计量是支付的地基。当所有人都在修支付层时，地基上还没有几块砖——这就是窗口。 软件的消费者正在从人变成 Agent。上一次软件消费者发生变化时，整个行业重新发明了软件经济学。这一次，变化从计量开始。 相关材料：白皮书：如何度量 AI Agent 对软件的使用 · 英文版文章 · AgentMeasure 仓库 · CORE 规范 · Benchmark 草案" },{ "id": "article-/en/notes/how-agent-usage-should-be-measured/", "kind": "article", "lang": "en", "title": "How Software Usage by AI Agents Should Be Measured", "topic": "agent-systems", "url": "/en/notes/how-agent-usage-should-be-measured/", "summary": "As the software consumer shifts from humans to agents and the economic unit from seats to callable capabilities, measurement precedes payment. AgentMeasure proposes an open measurement foundation for CaaS — Reach → Choice → Use → Utility → Value.", "published": "2026-08-16", "translation_of": "/notes/agent-usage-measurement-standard/", "related": ["agent-measurement"], "text": "Whitepaper v0.2 · AgentMeasure Standard Draft 0.4 Roy Tong The reference implementation lives in the AgentMeasure repository. 0. Abstract AI agents increasingly select, invoke, and transact with software on behalf of users and organizations. As interfaces such as Skills, MCP servers, APIs and CLIs become easier to create and distribute, economic value increasingly shifts toward the scarce capabilities behind them: proprietary data, compute, execution, permissions, transactions and real-world fulfillment. This creates a measurement problem before it creates a payment problem. A capability cannot be reliably priced, compared, billed or optimized until the ecosystem agrees on what constitutes a selection, an operation, a successful delivery, a consumed result, an outcome and a billable unit. AgentMeasure proposes an open measurement standard for this emerging capability economy: a common data language — reach, choice, use, utility, value — plus the measurement semantics that metering, marketplaces and payment rails can later build on. The goal is not a dashboard. It is the measurement foundation that makes Capability as a Service (CaaS, as used in this paper) possible. 1. From SaaS to Capability Economy Software distribution once had a readable chain: downloaded, installed, used. Each era has had its own economic unit. The shift described below is additive, not replacement: alongside seat-based SaaS and request-based APIs, callable capabilities are emerging as a new economic unit for agent-mediated software consumption. SaaS Human → Application → Seat / Month API Economy Software → API → Request / Token Capability Economy Agent → Capability → Operation / Outcome Three forces are driving the shift to the third row. Interfaces are being absorbed by agents. The UI and the workflow are increasingly executed by the agent, not presented to a human. What remains for software is a callable surface — a skill file, an MCP tool, a CLI, an endpoint. Distribution artifacts are commoditizing. An open Skill, an open MCP adapter, an open CLI can be authored and published by anyone in hours. Interfaces may become cheap to create; capabilities remain scarce to deliver. Scarcity moved down the stack. The scarce layer is no longer the app shell; it is what the callable surface controls access to: Data · Compute · Action · Permission · Trust · Real-world fulfillment A search capability is scarce because of its index; a booking capability because it can confirm a reservation; a payment capability because it can move money. When commercial value concentrates in the capability, the natural economic unit becomes the operation, the quantity, the effect, the outcome — or a revenue share on any of them. If capability becomes the economic unit, capability measurement becomes infrastructure. That is the thesis of this paper. Thesis and assumptions AgentMeasure is built on three trend judgments that are not yet fully established: Agents will mediate a growing share of software selection and execution. More software capabilities will be exposed independently of their human UI. Usage-, effect-, and outcome-based commercial models will coexist with seat-based pricing. The measurement standard remains useful even if these trends progress unevenly: the objects, quality rules and claim discipline stand on their own as an agent software measurement standard. 2. Measurement Before Monetization Before CaaS can have pricing, billing and reputation, it needs common measurement semantics. Four questions make the point: One user task → 1 Operation → 3 retries Charge 1 time or 3? Tool returned successfully → Agent ignored the result Was value delivered? Booking API executed → reservation was never confirmed Was the capability fulfilled? Task succeeded → would it succeed without the capability? Can the provider claim value? None of these questions can be answered by raw call counts, and none of them can be answered by a payment rail. They require agreed definitions of operation, attempt, delivery, consumption, effect and outcome — and agreed rules for turning observations into those objects. That agreement is the wedge: measurement before monetization. Emerging evidence: commerce is arriving before measurement The premise is not hypothetical — payment and discovery infrastructure for agent-mediated commerce already exists: Cloudflare Agents SDK allows MCP tools to be priced per call and charged via x402 (Charge for MCP tools). Coinbase x402 Bazaar is a discovery layer where agents search services with price and schema, and complete paid calls over MCP (x402 Bazaar). OpenAI and Stripe’s Agentic Commerce Protocol (ACP) is being used in real agentic commerce flows (announcement coverage). These prove the thesis of this section: payment and discovery infrastructure is arriving before common capability measurement semantics — the gap AgentMeasure fills. 3. Measurement Objects An observation is an evidence unit, not a business measurement unit. AgentMeasure defines the business units first: Provider ↓ Software Entity ↓ Capability ↓ Interaction Surface Capability is the primary functional and measurement object. An Offering is the commercial packaging of one or more capabilities — defined in the Commercial Extension (experimental), never inserted into the core measurement lineage. Object Definition Layer Software Entity the software being measured: tool, skill, API, data source, agent, application, runtime capability Market Capability a named function of an entity — the primary functional and measurement object Market Interaction Surface the observable calling interface of a capability (mcp_tool, cli_command, http_endpoint, …) Market Decision Opportunity one tool-choice decision Behavior Candidate Set the set actually offered in that decision Behavior Presentation a selectable appearing in the candidate set Behavior Selection the agent choosing a selectable Behavior Operation one logical use of a capability for a task Behavior Attempt one execution of an operation (retries = multiple attempts) Behavior Result / Effect what the capability returned / what changed in the world Behavior Task the unit of work an operation serves Behavior Client an independent agent runtime / installation Market Project the software entity packages/tools/skills roll up to Market Category a comparable capability class (search, booking, …) Market Observation an evidence record of a measurement fact (authentication and signatures are optional, defined by verification profiles) Evidence Observation happens on Interaction Surfaces; attribution resolves to Software Entities through a machine-readable registry — never guessed at observation time. Pricing is deliberately not an object of the core model. An Offering — commercial packaging referencing one or more capabilities, with permitted surfaces, pricing policy, service level objectives and commercial constraints — is defined in the Commercial Extension (experimental, non-normative), so that measurement semantics can evolve without being coupled to any payment design. Distribution events With commercial attribution in scope, discovery regains business meaning — without becoming the choice denominator: Published → Listed → Retrieved / Discovered → Presented Presented remains the denominator of choice metrics; Discovered is a distribution-attribution event, answering which Skill / Registry / Marketplace brought capability usage. 4. Agent–Capability Interaction Model Reach → Value is a measurement view, not a universal execution state machine. Different classes of capabilities have different meaningful chains: Information Operation → Result → Consumption Action Operation → Effect → Confirmation Transaction Operation → Authorization → Commit / Settlement The Interaction Class (information / action / transaction / computation / communication / control / storage / sensing) determines which chain applies and therefore which Utility signals are meaningful. A search result is consumed; a booking is confirmed; a payment is settled. Forcing every capability through one pipeline would produce numbers that mean different things. 5. Measurement Framework AgentMeasure defines metric families, not a universal KPI. M1 Distribution — Reach. Is the capability in the agent world? Available Clients · Eligible Opportunities · Presentations · Presentation Rate · Distribution Coverage M2 Choice — the most agent-native family. When the agent had the chance, did it choose the capability? Selections · Observed Selection Rate (Observed Selected ÷ Presented) · Conditional Choice Share · First-choice Rate M3 Execution — Use. Was it usable after selection? The Draft 0.4 model counts operations and attempts separately — the distinction that metering will eventually need: Operations · Attempts · Attempts per Operation Operation Completion Rate · Operation Success Rate Attempt Failure Rate · Retry Rate · Latency M4 Utility — effective use. Did the capability deliver usable information or cause the intended effect? Result Utility Delivered · Consumed · Accepted Effect Utility Applied · Confirmed · Reversed / Failed M5 Outcome — Value. Did it improve the task? Task Success Association · Incremental Lift · Time Saved · Cost Saved Relationships (formerly a separate chapter, now a subsection): Trial → Active → Repeated → Preferred → Dependent. Dependency — the least replaceable — remains the long-term asset signal. 6. Measurement Quality & Claim Discipline Evidence quality is not coverage quality; both are not qualification quality; none is methodology. A set of perfectly attested events covering 2% of agents is not market data. Measurement Quality ├── Provenance / Evidence Strength where did this observation come from, and how │ strongly is its origin supported? ├── Coverage how much of the world did we see? ├── Qualification does this count as real production use? ├── Sampling sampled? with what uncertainty? ├── Identity how well do identifiers resolve to entities? └── Method/version which statistics, which spec version? Qualified usage. Every observation carries two axes — Usage Context (where the traffic came from) and Validity (whether the observation is genuine). Strict Qualified Usage = production + validity=normal: the default for public metrics. Unknown context/validity is disclosed separately, never silently included — no “report unknown → make the leaderboard” incentive. A retry is an additional attempt of the same operation, kept as a reliability signal, not as a distinct logical use. Claim discipline. Every published metric carries a Measurement Label: numerator, denominator, observable population, qualified population, runtime coverage, grain, choice mode, decision authority, selection constraint. Observed choice is never presented as preference; association is never presented as causation; unobservable is never interpreted as negative. 7. Measurement and Metering The bridge from measurement standard to CaaS is semantic: measurement unit ≠ billable unit, and the three metering concepts must stay separated — Event is why billing triggers, Unit is what is counted, Quantity is how many: Capability billable_event billable_unit billable_quantity Search operation_succeeded operation 1 Data result_delivered record 1,382 Compute compute_completed gpu_second 47.2 Action effect_confirmed operation 1 Booking effect_confirmed booking 1 Lead Generation outcome_qualified qualified_lead 5 Commerce transaction_settled transaction 0.03（revenue share） Metering semantics therefore define, per Offering: Billable Event which measured fact triggers a charge Billable Unit the unit of quantity (operation, record, GPU-second, effect…) Billable Quantity how the unit is counted (per policy: attempts, confirmations…) Pricing Model per-operation · per-quantity · per-effect · per-outcome · revenue share Pricing Policy versioned price rules (flat, volume tiers, enterprise agreement, surge…) Quote the terms actually applicable to one call (quote_id, policy version, unit price) Metering Policy how measurement facts map to billable facts (rules, exclusions), versioned Metering Ledger replayable, correctable record of metered facts (revision / supersedes / reversal) Commercial Attribution which parties contributed to discovery / selection / revenue Payment is out of scope. AgentMeasure does not define payment rails, wallets, settlement currencies, merchant-of-record relationships, or financial custody. It produces the facts — qualified operation, confirmed effect, qualified outcome, billable quantity, commercial attribution — that payment systems consume. AgentMeasure standardizes economic facts, not money movement. 8. Attribution and Incrementality A capability’s participation in a successful task is not evidence that it caused the success. Attribution measurement is observational: which capabilities participated in the task chain. It supports claims of association and contribution to the execution chain — nothing more. Incrementality measurement is counterfactual: how much additional value did the capability create? Randomized comparison is the strongest evidence, but many capabilities cannot be randomly switched off. Claims therefore follow a Value Evidence Ladder: V0 Association participated when the task succeeded V1 Matched / Observational known confounders controlled V2 Offline Ablation replay tasks with the capability removed V3 Quasi-experiment switchback / natural variation V4 Randomized Holdout strongest causal evidence Only the evidence actually produced may support the corresponding causal claim strength — the same discipline as measurement quality. Commercial attribution extends the observational side along the distribution chain: GitHub Skill → Registry → Agent Recommendation → Capability → Payment Who contributed to discovery, selection and revenue? This is the future basis for agent affiliate and revenue-sharing models — and it must never be conflated with causal incrementality. 9. Capability Trust and Comparability A capability consumer’s choice is shaped by many factors. Agents and marketplaces can increasingly compare machine-readable performance signals alongside brand, policy, price, user preference, and platform constraints — exactly the axes AgentMeasure’s Decision Authority / Selection Constraint model describes: Capability Signals Reliability · Latency · Price · Freshness · Consumption · Effect Success Outcome · Safety · Measurement Coverage AgentMeasure does not calculate a universal AgentMeasure Score. Agent A cares about price, Agent B about latency, Agent C about privacy. Ranking is a product decision for agents and marketplaces; the standard defines only comparable signals and the labels that make them comparable. The Measurement Label is the foundation of this comparability. 10. Observation & Deployment Architecture Measurement surfaces differ in what they can see; single-sided adoption has value, but the claim must match the surface: Distribution Side → Agent Runtime Side → Provider Side → Effect / Outcome Side Surface Can see Registry discovery / availability Agent runtime presentation / choice / consumption Capability provider operation / attempts / result Target system effect / transaction Experiment layer incrementality Two-sided observations (agent runtime + provider) enable corroboration (E2); the provider side alone is sufficient for provider-scoped usage metrics. The standard is not on the critical request path: observations are emitted asynchronously, metadata only, pseudonymized before persistence. 11. Interoperability The standard is transport-neutral and vendor-neutral. Current infrastructure binds to it as implementation examples, not as preconditions: MCP carries lifecycle events and trace context; OpenTelemetry carries tool spans; Codex, Claude Code, and DeepSeek Harness expose observation points with declared capability matrices; registries provide entity identity. Payment rails, when they arrive, consume the standard’s facts rather than extending its core. 12. Non-goals and Governance AgentMeasure is not a payment protocol, a marketplace, a wallet, or a universal reputation system. The standard does not: move money or custody funds; rank capabilities or score providers; define what a “good” capability is; require any central server, agent-side install, or open-source provider. The standard itself is community-governed (AUP process, proposals/); commercial products built on it must not control the standard’s definitions. 13. Open Questions Task boundaries. What is the unit of a “task,” and who defines it? Effect verification. How to confirm an effect (booking confirmed, payment settled) without deep integration into every target system? Incrementality at scale. How to run counterfactual experiments across the ecosystem without disturbing production? Candidate-set observability. Presentation is the key denominator; most runtimes do not expose it yet. Cross-agent identity. Same client across Codex, Claude, and DSH — when is that knowable? Billable-unit consensus. Which measurement facts will providers and payment rails actually agree on, and at what cost of mis-measurement? Privacy. How far can correlation and retention go under pseudonymity? 14. Conclusion The software consumer is changing from humans to agents, and the economic unit is shifting from seats to callable capabilities. Before capabilities can be priced, billed and compared, the ecosystem needs a shared measurement language — what a selection is, what an operation is, what a delivery, a consumption, an effect and an outcome are, and which numbers can support which conclusions. AgentMeasure is that proposal: measurement semantics as infrastructure, commercial semantics as a future extension, payment as someone else’s rails. Measure how agents use software capabilities today; make capabilities comparable and meterable next; build the measurement foundation for Capability as a Service in the long term. References RFC 2119 / BCP 14 — Key words for use in RFCs to Indicate Requirement Levels. OpenTelemetry GenAI semantic conventions — gen_ai.* tool-call telemetry fields. Model Context Protocol (MCP) specification — tool discovery and invocation surfaces. MCP Registry — server identity as the entry point for entity resolution. EDPB — guidance on pseudonymisation (pseudonymised data may still be personal data). Cloudflare — Charge for MCP tools (x402 / Agentic Payments). Coinbase — x402 Bazaar: discover & pay over MCP. OpenAI / Stripe — Agentic Commerce Protocol (ACP), announced September 2025; see Digital Transactions coverage. AgentMeasure specification — Core, Metrics, Data, Entity, Quality, Correlation (standard/); Commercial Extension (extensions/COMMERCIAL.md, experimental); machine-readable registry (schemas/, registry/); reference implementation and conformance vectors in the same repository. The normative specification (Measurement Objects, Lifecycle, Metric Families, Quality, Reporting) and the reference implementation (AgentMeasure) are published openly. Graduation to AgentMeasure 1.0 requires two independent implementations, three runtime profiles, two tool-side implementations, a public conformance suite with canonical test vectors, 5–10 real projects, a published discrepancy report, and security and privacy reviews." },{ "id": "article-/notes/agent-usage-measurement-standard/", "kind": "article", "lang": "zh-CN", "title": "如何度量 AI Agent 对软件的使用", "topic": "agent-systems", "url": "/notes/agent-usage-measurement-standard/", "summary": "当软件消费者从人变成 Agent、经济单元从软件席位转向可调用能力，计量问题先于支付问题出现。AgentMeasure 提出面向 CaaS 与 Agent Capability Economy 的统一计量基础——Reach → Choice → Use → Utility → Value。", "published": "2026-08-16", "translation_of": null, "related": ["agent-measurement"], "text": "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": "article-/notes/spatial-computing-touch-moment/", "kind": "article", "lang": "zh-CN", "title": "空间计算需要自己的“触控时刻”", "topic": "ai-devices", "url": "/notes/spatial-computing-touch-moment/", "summary": "看、指、捏、说分别承担注意、指代、确认和开放意图。它们组合起来，才可能成为人、Agent 与空间对象共同工作的公共语法。", "published": "2026-08-14", "translation_of": null, "related": ["spatial-computing"], "text": "上一篇写 AI Wearable 时，我把眼镜、耳机、戒指和手表从品类表里拿掉，改看输入、输出、控制方式和身体位置。 文章写到最后，还有一个问题没有说完。 当眼睛、手和语音都能成为输入，究竟该由谁负责选中对象，谁负责说清意图，谁来确认，谁来执行？ 现在的答案经常是：都可以。 可以看，可以捏，可以说，也可以拿控制器。模态多了，演示也顺了。但“系统支持四种输入”和“用户已经掌握一套交互语言”，中间还隔着很远。 我把眼前这个缺口称为：空间计算还没有迎来自己的“触控时刻”。 触摸屏并不是从 iPhone 才出现。改变移动计算习惯的，是点按、滑动、拖拽、双指缩放逐渐获得了稳定含义。换一个 App，用户不需要重新学习怎样浏览、选择和返回；做一个新 App，开发者也不必重新发明最基础的操作。 所谓空间计算的“触控时刻”，也不会由某个手势单独完成。 它出现的标志是：面对一个陌生的空间应用，用户已经大致知道怎么开始；系统也能稳定回答——你在看什么、你选中了什么、接下来会发生什么、做错了怎样回来。 输入已经够多，分工还没形成 今天的空间设备已经能追踪视线和双手，识别环境，把窗口与三维对象固定在真实空间。Apple 在 visionOS 中以眼睛和手作为主要输入：先看向目标，再用拇指和食指轻点完成操作；Android XR 则把手、眼、语音、键鼠和控制器都纳入系统交互。 这些能力已经能很好地操作“放进空间里的 GUI”。 问题是，操作一个悬浮窗口，和操作真实世界不是一回事。 屏幕有稳定平面，鼠标有明确光标，手指能得到桌面或屏幕支撑。空间里却有深度、遮挡、远近关系和不断移动的人。视线会自然扫过物体，手会抖，手臂悬空久了会累；在办公室或地铁里，用户也未必愿意持续说话、挥手。 更重要的是，空间动作可能触及真实设备。误点一个图标，最多关掉窗口；误关一个阀门、误移动一台机器，后果完全不同。 所以键鼠和触控不能原样搬进三维世界。空间交互要先解决不同模态怎样分工。 语音擅长表达开放目标，却不擅长从密集物体里精确指出“右边第三个零件”。视线最自然，却不能把“看见”直接当成“同意”。手势适合确认和连续操作，但复杂手势难学，也不适合长时间悬空。控制器很可靠，却很难成为随时可用的日常入口。 多模态的价值，在于把一句完整的意图拆给最合适的输入，而不是让用户从四种入口里任选一种。 看、指、捏、说 我更愿意先把空间交互压缩成四个原语。 原语 主要职责 适合做什么 不能默认等于什么 看 建立注意与上下文 高亮候选、读取状态、缩小范围 确认、授权或执行 指 明确对象、区域与方向 消除“这个”“那里”的歧义 高精度连续操控 捏 表达承诺并直接操作 选择、抓取、拖动、缩放、细调 描述复杂目标 说 表达目标、关系与约束 提问、比较、生成、安排多步任务 独自完成精确空间定位 看，让系统知道我此刻关注哪里。 指，把“眼前这一片”收窄成一个对象或区域。 捏，把关注变成一次明确的确认，也承担拿取、移动和调整。 说，则负责手势很难表达的部分：为什么改、要改成什么样、还要满足哪些条件。 这四个词不是行业标准，也不要求每台设备使用同一套传感器。需要稳定的是语义边界。 用户可以用眼睛，也可以用头部朝向或辅助设备建立焦点；可以捏手指，也可以按实体键完成确认。输入方式可以适配，核心含义不能每到一个应用就重来。 OpenXR 的 action 机制已经体现了类似思路：应用声明“选择”“抓取”这类有业务含义的动作，再由运行时把不同设备的具体输入映射过来。平台该固定的是动作的公共含义，不是某一枚按钮。 从 Point and Click 到 Point and Ask 桌面计算的代表动作是 Point and Click：先找到对象，再执行一个明确命令。 空间计算会保留直接操作，也会多出两类更自然的组合。 第一类是 Point and Ask。 我指向一台陌生设备，问：“这个灯为什么一直闪？” 指向提供对象，现场提供上下文，语音提供问题。用户不必先查到设备型号，也不用准确描述“左侧第二排的黑色圆柱体”。空间本身已经进入 Prompt。 第二类是 Point and Act。 我指向机械结构里的一个部件，说：“把这部分拆开给我看。” 或者指向客厅的一块区域：“把这里改成六个人能讨论、又不挡通道的布局。” 前半句确定对象，后半句表达目标。Agent 再把目标拆成步骤、调用工具或生成方案。 麻烦也从这里开始。 系统必须先让我看见它选中了什么，而不是直接猜；修改真实状态前要给预览，高风险动作要再次确认；执行中要显示进度和影响范围；做错后要能撤销、回滚或交还人工。 没有这些反馈，Point and Ask 只是更方便的提问。没有这些控制，Point and Act 会变成一句话触发的黑箱。 直接操作与 Agent，需要快慢两个回路 我抓住一个三维模型，把它转过来。这件事应该立即发生。 如果每次旋转都要等 Agent 理解、规划和回复，哪怕只慢半秒，手里的控制感也会消失。 但当我说：“把这套结构改得更适合儿童使用，先给三个方案，并检查容易夹手的位置”，它就不再是一次直接操作。系统需要理解目标、查找约束、修改对象，甚至运行检查。 空间计算因此需要两个回路： 快环： 看向对象 → 捏合确认 → 直接改变局部状态 → 立即得到反馈 慢环： 指明对象 → 说出目标 → Agent 规划 → 展示预览 → 用户确认 → 执行与回退 快环处理即时、低风险、可感知的动作。慢环处理需要理解、规划、工具调用和等待的任务。 产品最难的是两个回路怎样交接。 用户要知道当前是谁在控制：是我的手正在直接移动对象，还是 Agent 已经开始修改多个状态？它做到了哪一步？哪里用了推测？什么时候需要我确认？如果我现在接管，真实世界和数字状态会停在哪里？ Agent 越强，这些问题越重要。能力增加了，控制边界却不清楚，系统就会变得更难预测。 从 Spatial App 到 Spatial Intent 今天的大部分软件仍然由 App 组织。 我要修图，就打开图像软件；要导航，就打开地图；要购物，就打开电商应用。空间设备也沿用了这套结构：打开一个 App，把窗口或模型摆到房间里。 但真实空间不是一组窗口。 一把椅子有位置、朝向、尺寸和所属人；一台机器有结构、状态、历史和权限；一间房同时包含人、物体、关系与规则。同一个对象，也可能被设计工具、维修工具和家庭 Agent 使用。 如果空间计算继续发展，我认为它的组织单位会逐渐从 App 走向 World Canvas：真实对象与数字对象共同组成一张可被理解、操作和授权的世界画布。 这时，用户表达的也不再只是某个菜单命令，而是 Spatial Intent：希望这部分世界变成什么状态。 “告诉我这里为什么漏水。” “把这张桌子挪到不挡门的位置。” “冻结现在的布置，试一下另一种规则，效果不好就恢复。” Spatial Intent 和 World Canvas 是一种产品方向，不是今天已经完成的行业事实。要让它成立，平台需要为对象提供稳定身份，维护空间关系和状态，处理跨应用访问，也要定义人和 Agent 各自拥有的权限。 这会比在房间里多放几个窗口难得多，也更能说明空间计算与桌面计算的差别。 别用一个漂亮 Demo 证明整个平台 空间产品很容易用一次视觉效果跨越中间所有难题。 为了判断一个产品到底走到了哪里，我会用一套很朴素的五级尺度。它不是行业标准，只是产品评审工具。 等级 用户获得的能力 L0 展示 能在空间中看见窗口、图像或三维内容 L1 指认 能稳定发现、指向和选中对象 L2 操作 能拿取、移动、组合或修改对象，并获得清楚反馈 L3 完成任务 系统能理解目标、协调多步动作，用户可以确认和接管 L4 持续协作 对象、关系、权限与任务状态可以跨时间、场景和工具延续 一个视觉震撼的 Demo 可能仍在 L0。一个画面朴素、却能稳定完成维修指导并随时回退的系统，可能已经走到 L3。 这不是说 L0 没有价值。任何平台都要从显示和内容开始。问题在于，我们不能拿“第一次看很惊艳”，直接证明用户会每天使用；也不能用一个独立场景里的成功，证明对象和 Agent 已经能跨场景持续协作。 中间每一级，都是一组不同的产品问题。 我更想先验证三个一分钟 Demo 如果现在做空间交互原型，我不会先造一个宏大的虚拟世界。 我会先做三个普通人能在 30 到 60 秒内判断成败的任务。 第一个，遮挡与探身。 让目标被另一个物体挡住一部分。用户侧身看过去，再指向它。系统能不能持续认出同一个对象？用户能不能看懂自己到底选中了哪一个？ 第二个，指认、询问与拆解。 用户指向陌生装置，问它的作用，再要求显示拆解顺序。后续每一步能不能延续同一个对象上下文？说明是否准确落在对应部件？用户能不能随时纠错和暂停？ 第三个，冻结、改规则与回退。 用户冻结当前场景，提出一个新约束。系统先预览，再由用户确认执行；效果不好，能够一键回到修改前。 这三个 Demo 分别检验对象选择、上下文延续和 Agent 控制。判断标准很简单：用户有没有学会一个以后还能复用的动作，而不只是觉得画面很酷。 这正是“触控时刻”的含义。 它不会发生在某款设备又增加一种输入的时候，也不会发生在三维内容数量达到某个门槛的时候。 它会发生在有一天，面对不同的空间应用，人已经自然地知道：先看哪里、怎样指明、何时确认、如何说出目标；系统也稳定地知道，什么只是注意，什么才是授权，什么时候应该立即响应，什么时候必须先给预览。 到那时，看、指、捏、说才不再是四种并列的功能。 它们会成为人、Agent 与空间对象共同工作的公共语法。 延伸资料 Apple Developer：Get started with visionOS Apple Human Interface Guidelines：Gestures Android Developers：Interaction foundations for Android XR Android Developers：Interaction considerations for Android XR Khronos：OpenXR 规范中的 Action Hincapié-Ramos et al.：Consumed Endurance，关于悬空手势疲劳的 CHI 研究" },{ "id": "article-/en/notes/agent-context-recommendation-after-rag/", "kind": "article", "lang": "en", "title": "After RAG, Agents Need Context Recommendation", "topic": "agent-systems", "url": "/en/notes/agent-context-recommendation-after-rag/", "summary": "Context Recommendation is the workbench assembly layer of an Agent Runtime — selecting the information, tools, skills, state and permissions for each step, and recording why each choice was made.", "published": "2026-08-14", "translation_of": "/notes/agent-context-recommendation-after-rag/", "related": ["agent-context"], "text": "The DeepSeek Harness architecture documentation contains one line: agent/pre-step decides what the model sees. I think that line deserves more discussion than “Everything is a Plugin.” When people build agents, they habitually ask three questions: is the model strong enough, are enough tools connected, is the context window big enough. Harness moves the question one step earlier: even when the model, tools and materials are all in place, what exactly should be handed to the model in the next step? An agent writing a product kickoff document first needs industry research and user studies; later, before editing the formal file, it must know whether it has write permission and which actions require human confirmation. Four steps, the same model — but not the same workbench. I used to call the post-RAG version of this problem Context Recommendation, when I was mainly thinking about retrieving and ranking material. After reading Harness’s public architecture, I’d expand the definition: Context Recommendation is the workbench assembly layer of an Agent Runtime. For the next step it selects the information the model should see, the capabilities it may call, and the permissions it must obey — and what should not appear at all. DeepSeek Harness does not claim to have completed a Context Recommender. What it does is more fundamental: turning “what we give the model at each step” from an implicit operation inside prompts into an official interface the runtime can assemble, inject, restrict and replay. RAG finds material; agents assemble a workbench The 2020 RAG paper solved a concrete problem: when knowledge in a model’s parameters is insufficient, first retrieve relevant passages from an external knowledge base, then generate answers grounded in that material. Lewis et al.: Retrieval-Augmented Generation Engineering expanded endlessly afterward, but the main question still reduces to one sentence: which materials are relevant to the current question? Agents face a much larger scope. A conversation history is context; a research report is context; the current file state is context; whether this step may call a browser or a Skill is context; an anomaly found by another agent, a requirement the user just withdrew, a deletion that must be confirmed — all of it changes the next step. RAG usually delivers “material to answer with.” An Agent Runtime must deliver a table you can keep working on: which materials are placed, which tools are open, what the current state is, where the boundaries are drawn. This is why a longer context window doesn’t make the problem disappear: capacity answers “can it fit?”, not “should it be present right now?” “Lost in the Middle” found that the same critical information produces measurably different model performance depending on its position in a long context; information at the beginning or end is used more readily. Liu et al.: Lost in the Middle That doesn’t imply long context is useless, but it does show that fitting and using are different questions. When a product manager runs a pricing meeting, he brings costs, competitors and willingness-to-pay — not five years of email, the whole codebase and all support logs. Agents need a step-varying workbench too. Harness exposes where the choice happens DeepSeek Harness makes the parts around the model pluggable: model adapters, a tool registry, session logs, even the agent loop. The official repository still labels the project a developer preview subject to compatibility changes. DeepSeek Harness repository Several design choices relate directly to context: core/system-prompt assembles this turn’s prompt sections and tool schema; the scoped tool registry gives different agents different tool sets; agent/pre-step can receive, rewrite or reject the next message before the model request; agent.inject() puts new context into the next accepted request; the append-only session log stores process facts, and model history is derived from the log. The official architecture documentation also requires that whatever is sent to the model can be reconstructed from the log — what the model saw should not exist only in an untraceable prompt concatenation. The mechanism forms a short chain: Session / Memory / Knowledge / Tools ↓ agent/pre-step: select, filter, assemble ↓ Model-visible workbench ↓ Action / Tool result / New event ↓ Written back to Session → next round of selection Harness provides where the workbench is assembled, but not the product’s choices: which content enters, which tools are hidden, when to inject new information — that needs a policy layer. That layer is Context Recommendation. Context is not just documents If you keep reading “context” as “reference material,” agent failures get scattered across modules. Start by splitting it into six types. Type Typical content What goes wrong if mis-selected Instruction Role, goals, rules, output contracts Local actions are fine; the whole task drifts Memory User preferences, past decisions, project commitments Repeated questioning, or overturning confirmed boundaries Knowledge Documents, web pages, code, databases, research evidence Using irrelevant, stale or untrustworthy information Capability Tools, Skills, APIs, sub-agents The needed capability is missing, or the wrong one is picked from too many State Current files, task stage, environment changes, intermediate results Acting on old state; duplicating or overwriting work Authority Read scope, write permissions, approval conditions, risk levels Reading beyond authority, or bypassing high-risk confirmation Not all six become natural language: Capability may show up as tool schemas; part of Authority can be told to the model, the rest enforced by the execution layer; State may come from structured events. They belong in one system because together they decide what the model understands, what it can do, and who is accountable. Why call it Recommendation Context Routing, Context Selection, Context Management — all defensible. I keep “Recommendation” because this is not a fixed route but a changing candidate set: the current task may have two hundred candidate contexts — rules, past discussions, research, code, tools, Skills, external events, other agents’ results. The system generates candidates, passes them through permission and risk gates, then ranks, compresses and composes them into the workbench for this turn. The minimal pipeline: Task State → Candidate Generation → Policy Gate → Ranking → Composition → Injection → Outcome → Task State This doesn’t require a sophisticated ML model: permissions fit deterministic rules; fixed goals can stay resident; document candidates can use retrieval plus reranking. Recommendation describes a product responsibility, not a specific algorithm. If I want a team to agree on the ranking logic first, I’d write a rough product function: next-step utility = task relevance × trustworthiness × freshness × actionability × permission match − token cost − distraction − risk It is not a research formula; it is a checklist. An old report can be highly relevant and low on freshness; a capable tool must not appear when the agent lacks permission; a few dozen tokens can still cause large distraction by conflicting with standing instructions. Weights change with the task — and vector similarity alone cannot solve this. What you don’t recommend matters as much as what you do Agent products easily mistake “connect more” for capability growth. More tools, memory and data sources raise the ceiling — and widen the surface of distraction. A half-year-old ad hoc decision can be mistaken for a standing rule; fifty similar tools increase mis-selection; a write-capable tool that is never called can still change the model’s plan merely by being visible. So a Context Recommender must do negative recommendation: Relevant but stale material appears only as historical background; A tool that could do the job stays hidden when the agent lacks permission; Memory belonging to another user never enters the workbench; A sub-agent’s conclusion without evidence doesn’t change the main task’s state; Intermediate results superseded by newer events remain in the log, out of the working set. The session log records “what happened.” Context Recommendation decides “what the model should still see this moment.” Logs should be complete; the working set should be restrained. How to validate such a system Context Recommendation is not about making the model “feel better informed.” It is about raising per-step completion quality and reducing irrelevant exposure and over-authorization risk. Record at least six kinds of outcomes: How much of the context needed for the next step was selected; How much of what entered the request went unused, or actively distracted; Whether Tools and Skills appear when needed and hide when not; Whether stale, conflicting and low-trust information is clearly marked; Whether permission filtering and human confirmation blocked out-of-bounds actions; How task completion, rework, tokens, latency and cost change across context combinations. The run log needs one more layer: what the candidates were, what was selected, what was excluded, why, and what the model did next — without the selection rationale, you can’t tell whether a failure came from the model, the tools, or a wrongly assembled workbench. Start with a human gold standard: label the required, optional and forbidden context for each step, then ablate — remove one item and see whether the task fails, add one and see whether errors increase. That is closer to an agent’s objective than click-through rate. RAG stays in the system — in a different position Context Recommendation does not replace RAG. RAG can still generate candidates from knowledge bases, codebases or memory; the change comes after it: retrieval results must pass through selection together with task state, standing instructions, tools, Skills and permissions.   RAG Context Recommendation Primary object External knowledge and document passages Information, capabilities, state and permissions Trigger A question or retrieval request Every critical agent step Main output Relevant material The next step’s model workbench and execution boundaries Main audit What was found, where it came from What was seen, why it appeared, what was allowed RAG becomes one candidate generator inside this system — not a legacy approach to be retired. DeepSeek Harness doesn’t prove Context Recommendation works, either. What it proves: the runtime around a model can be decomposed into formal parts; per-turn inputs, tools and state can be assembled; model-visible content can be replayed; different agents can hold different capability sets. The same model with different tools forms different plans; with different memory it carries different history; under different permission constraints it stops at different boundaries; seeing different context at each step, it eventually behaves like a different agent. So the post-RAG question is not how much more we can stuff into the window. agent/pre-step already decides what the model sees. The next question is: what should it see at this moment, why these things, and how do we know this selection helped the task. References DeepSeek Harness repository DeepSeek Harness Architecture DeepSeek Harness dsh-session Lewis et al.: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks Liu et al.: Lost in the Middle" },{ "id": "article-/notes/agent-context-recommendation-after-rag/", "kind": "article", "lang": "zh-CN", "title": "RAG 之后，Agent 需要 Context Recommendation", "topic": "agent-systems", "url": "/notes/agent-context-recommendation-after-rag/", "summary": "Context Recommendation 是 Agent Runtime 的工作台装配层：为每一步选择信息、工具、Skill、状态与权限，同时记录为什么选、为什么不选。", "published": "2026-08-14", "translation_of": null, "related": ["agent-context"], "text": "DeepSeek Harness 的架构文档里有一句话： agent/pre-step decides what the model sees. agent/pre-step 决定模型看到什么。 我认为这句话比 “Everything is a Plugin” 更值得讨论。 过去做 Agent，大家习惯问三个问题：模型够不够强，工具接得够不够多，上下文窗口够不够大。Harness 把问题往前移了一步：即使模型、工具和资料都已经在那里，下一轮究竟该把什么交给模型？ 假设一个 Agent 正在写产品立项。 第一步，它需要行业资料和用户研究；第二步，它要读回已经确认的产品边界；第三步，它需要表格与计算工具；准备修改正式文件时，它还要知道自己有没有写权限、哪些动作必须由人确认。 这四步可以用同一个模型，却不能使用同一份工作台。 以前我把 RAG 之后的这个问题叫作 Context Recommendation。当时想的主要是资料检索与排序。看完 DeepSeek Harness 的公开架构后，我会把定义扩大： Context Recommendation 是 Agent Runtime 的工作台装配层。它为下一步选择模型该看到的信息、可调用的能力和必须遵守的权限，也决定哪些内容暂时不该出现。 DeepSeek Harness 没有在公开文档中声称已经完成了一套 Context Recommender。它做的事情更基础：把“每一步给模型什么”从 Prompt 里的隐性操作，变成运行时可以组装、注入、限制和回放的正式接口。 RAG 找资料，Agent 还要组工作台 2020 年的 RAG 论文解决了一个很具体的问题：当模型参数里的知识不足时，先从外部知识库找到与问题相关的段落，再让模型基于这些材料生成答案。RAG 原始论文 工程实现后来不断扩展，主问题仍然可以概括成一句话： 哪些资料和当前问题有关？ Agent 面对的范围更大。 一段历史对话是 Context，一份研究报告是 Context，当前文件状态是 Context；这一步能不能调用浏览器、代码环境或某个 Skill，也是 Context；另一个 Agent 刚发现的异常、用户刚撤回的要求、一次删除操作必须得到确认，同样会改变下一步。 RAG 通常交付“可供回答的材料”。Agent Runtime 要交付的是一张可以继续工作的桌子：资料放哪些，工具开哪些，当前状态是什么，边界画在哪里。 这也是为什么上下文窗口变长，问题没有自动消失。 容量回答“能不能装下”，不回答“现在该不该出现”。 《Lost in the Middle》在多文档问答和键值检索实验中发现，同一条关键信息只因处在长上下文中的位置不同，模型表现就可能明显变化；位于开头或结尾的信息往往更容易被利用。Lost in the Middle 这项研究不能简单推出“长上下文没用”，不同模型的表现也会继续变化。它至少说明，装得下和用得好不是同一个问题。 开定价会时，产品经理不会把五年邮件、整个代码库和所有客服日志一起摊在桌上。他会带成本、竞品和支付意愿，也会标出哪些数字过期、哪些结论仍有争议。 Agent 也需要这种随步骤变化的工作台。 Harness 把选择发生的位置露了出来 DeepSeek Harness 把模型周围的多个部分做成插件：模型适配器、工具注册表、session log，甚至 agent loop。官方仓库目前仍把项目标为可能发生兼容性变化的 developer preview。DeepSeek Harness 官方仓库 其中几处设计与 Context 直接相关。 core/system-prompt 组装这一轮的 prompt section 与工具 schema； scoped tool registry 让不同 Agent 获得不同的工具集合； agent/pre-step 可以在模型请求前接收、改写或拒绝本轮消息； agent.inject() 把新 Context 放进下一次被接纳的请求； append-only session log 保存过程事实，再从日志派生模型历史。 官方架构文档还明确规定，送进模型的内容应该能够从日志重建。模型当时看到了什么，不该只存在于一次不可追溯的 Prompt 拼接中。 这套机制可以画成一条很短的链： Session / Memory / Knowledge / Tools ↓ agent/pre-step：选择、过滤、组装 ↓ Model-visible workbench ↓ Action / Tool result / New event ↓ 写回 Session，进入下一轮选择 Harness 已经给出了装配工作台的位置，但没有替产品做出选择。哪些内容值得进入，哪些工具应该隐藏，何时注入一条新信息，仍然需要一层策略。 这层策略，就是我所说的 Context Recommendation。 Context 不只是文档 如果把 Context 继续理解成“参考资料”，Agent 的很多失败会散落在不同模块里。 我会先把它分成六类。 类型 典型内容 选错后的结果 Instruction 角色、目标、规则、输出契约 局部动作没错，任务方向偏了 Memory 用户偏好、历史决定、项目承诺 重复追问，或推翻已经确认的边界 Knowledge 文档、网页、代码、数据库与研究证据 使用无关、过期或不可信的信息 Capability Tool、Skill、API、Sub-agent 找不到该用的能力，或在过多工具中选错 State 当前文件、任务阶段、环境变化与中间结果 按旧状态继续行动，重复或覆盖工作 Authority 可读范围、写权限、审批条件与风险等级 越权读取，或绕过高风险确认 这六类不会全部变成自然语言。 Capability 可能表现为这一轮暴露的工具 schema。Authority 一部分可以告诉模型，另一部分必须由执行层强制检查。State 可能来自结构化事件，Memory 也可能只是指向一条已经确认的决定。 把它们放在同一个系统里，是因为它们共同决定了一件事：模型此刻理解什么、能做什么，出错后由谁负责。 为什么要叫 Recommendation Context Routing、Context Selection、Context Management 都说得通。 我仍然使用 Recommendation，是因为它面对的不是一次固定路由，而是一个不断变化的候选集合。 当前任务可能有两百项候选 Context：正式规则、历史讨论、研究材料、代码文件、工具、Skills、外部事件和其他 Agent 的结果。系统要根据当前步骤生成候选，先过权限与风险门，再排序、压缩和组合，最后形成模型这一轮看到的工作台。 最小流程可以写成： Task State → Candidate Generation → Policy Gate → Ranking → Composition → Injection → Outcome → Task State 这里不一定需要一套复杂的机器学习模型。 权限适合确定性规则；固定目标可以常驻；文档候选可以用检索和 rerank；任务走到新阶段时，再由状态机或模型参与判断。Recommendation 描述的是产品职责，不限定具体算法。 如果要让团队先对排序逻辑达成共识，我会写一条粗糙的产品函数： 下一步效用 = 任务相关性 × 可信度 × 新鲜度 × 可行动性 × 权限匹配 − Token 成本 − 干扰 − 风险 它不是研究公式，只是一张检查表。 一份旧报告可能高度相关，但新鲜度很低；一个工具很能干，当前 Agent 没有权限时仍然不能出现；一段用户原话可信，却未必支持下一步动作；某条信息只占几十个 Token，也可能因为与正式指令冲突而带来很大干扰。 任务不同，权重也会变。 修代码更依赖仓库状态、错误日志和执行工具。做行业研究更看来源、时间与反证。涉及删除、付款、发信或控制真实设备时，权限与风险要先于相关性。 这件事不能只靠向量相似度解决。 推荐什么，和不推荐什么同样重要 Agent 产品很容易把“接入更多”当作能力增长。 接入更多工具、Memory 和数据源当然会扩大上限，也会扩大干扰面。 半年前的临时决定可能被误当成长期规则，旧市场数据会和新事实冲突，五十个相似工具会增加误选，与当前任务无关的个人信息也没有必要进入请求。一个带写权限的工具即使没有被调用，只要对模型可见，也可能改变它的计划。 所以 Context Recommender 必须做负推荐： 资料相关但已经过期，只作为历史背景； 工具有能力完成任务，但当前 Agent 没有权限； Memory 属于另一位用户，不进入当前工作台； Sub-agent 给出了结论，却没有证据，不改变主任务状态； 中间结果已经被新事件替代，留在日志里，不再进入工作集。 Session log 负责保存“发生过什么”。Context Recommendation 负责决定“这一刻还要让模型看到什么”。 日志应该完整，工作集应该克制。 这套系统要怎样被验证 Context Recommendation 的目标不是让模型“感觉信息更充分”，而是提高每一步的完成质量，并减少无关暴露与越权风险。 至少要记录六类结果： 完成下一步必需的 Context，有多少被选中； 进入请求的内容中，有多少没有被使用，甚至造成干扰； Tool 与 Skill 是否在需要时出现、不需要时隐藏； 过期、冲突和低可信信息有没有被清楚标记； 权限过滤与人工确认有没有挡住越权动作； 在不同 Context 组合下，任务完成率、返工、Token、延迟和成本怎样变化。 运行记录还要补上一层：候选是什么，选了什么，排除了什么，理由是什么，模型随后做了什么。 只有任务结果，没有当时的选择依据，很难判断失败来自模型、工具，还是工作台装错了。 可以先从人工金标准开始。挑一组步骤清楚的真实任务，由人标注每一步的必需 Context、可选 Context、禁止 Context 与能力集合，再做消融：去掉某一项后任务是否失败，加入某一项后错误是否增加。 这比把“点击率”当作推荐质量，更接近 Agent 的工作目标。 RAG 会留在系统里，但位置会改变 Context Recommendation 不取代 RAG。 RAG 仍然可以负责从知识库、代码库或 Memory 中生成候选。变化在它之后：检索结果还要和任务状态、固定指令、工具、Skill 与权限一起经过选择。   RAG Context Recommendation 主要对象 外部知识与文档片段 信息、能力、状态与权限 触发时机 问题或检索请求 Agent 的每一个关键步骤 主要输出 相关材料 下一步的模型工作台与执行边界 主要审计 找到了什么、来源在哪里 看到了什么、为什么出现、允许做什么 RAG 会成为这套系统中的一个候选生成器，而不是被淘汰的旧方案。 DeepSeek Harness 也没有证明 Context Recommendation 已经跑通。 它证明的是，模型周围的运行环境可以被拆成正式部件；本轮输入、工具与状态可以被组装；模型可见内容能够被回放；不同 Agent 可以拥有不同的能力集合。 同一个模型，拿到不同工具，会形成不同计划；带着不同 Memory，会延续不同历史；受到不同权限约束，会停在不同边界；每一步看到不同的 Context，最后就会表现得像不同的 Agent。 所以 RAG 之后的问题，不是还能往窗口里塞多少东西。 agent/pre-step 已经决定模型看到什么。 接下来要回答的是：这一刻，它应该看到什么；为什么是这些；我们怎样知道这次选择帮到了任务。 延伸资料 DeepSeek Harness 官方仓库 DeepSeek Harness Architecture DeepSeek Harness dsh-session Lewis et al.：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks Liu et al.：Lost in the Middle" },{ "id": "article-/notes/home-robots-harder-richer/", "kind": "article", "lang": "zh-CN", "title": "家庭机器人为什么技术上更难，经济上可能更丰富", "topic": "robotics", "url": "/notes/home-robots-harder-richer/", "summary": "家庭把环境长尾、任务差异和多人规则叠在一起，也让机器人可能同时承接硬件、订阅、服务、照护与家庭协同；每一层价值背后都有新的交付责任。", "published": "2026-08-14", "translation_of": null, "related": ["household-robots"], "text": "我主导过一款家庭消费级安防四足机器人的产品工作。 最初看，它的任务并不复杂：用户离家以后，机器人能够在屋内移动；系统发现异常时，它去现场看一眼，把画面和状态发回手机，必要时再通过灯光或声音介入。 这已经比“做完所有家务”窄了很多。 可一旦把它放进真实家庭，问题仍然迅速变长。 谁定义异常？孩子半夜起床算不算？宠物撞倒东西以后要不要过去？卧室什么时候可以进入？家里有人时还要不要巡逻？两位家庭成员给了相反指令听谁的？机器人卡在门槛边，远程用户能做什么？如果它发出声音吓到老人，产品算成功还是失败？ 这些问题让我重新理解了“家庭场景”。 家庭不是一个场景。它是一套持续变化的环境、多人关系和生活规则。机器人一旦进入其中，面对的就不只是感知、导航和操作，还包括权限、打扰、责任与恢复。 这也是家庭机器人的矛盾所在： 它在技术上可能比工厂更难，却也可能承接比一台传统家电更多的价值。硬件、订阅、服务、安防、照护、内容和家庭协同，都可能成为收入来源。 但“可能”不能省略。 家庭价值每多一层，企业承担的交付责任通常也多一层。先找到一条足够窄、可验证、失败可恢复的闭环，比先做一个万能家庭管家重要得多。 工厂可以适应机器，家庭要求机器适应生活 工厂里的机器人也很难，但工厂可以改造环境。 地面可以重铺，工位可以重新设计，物料可以统一，路径可以固定。光线不够就加灯，抓取不稳就改夹具，有危险就设置隔离区。任务、人员和维护流程都能被规定。 家庭刚好相反。 同一个杯子今天在厨房，明天可能在卧室；衣服柔软、透明容器难识别，玩具和电线随时出现在地面；孩子、老人、访客和宠物不会按机器人说明书行动。不同家庭甚至对“房间收拾好了”都有不同定义。 BEHAVIOR-1K 把这个长尾做成了一个机器人基准。研究团队从用户调查出发，整理出 1,000 种日常活动，放进 50 类场景和 9,000 多个对象中。论文的实验结论很克制：这些任务往往需要长程规划和复杂操作，即使先进方法仍然很难完成。BEHAVIOR-1K 这组数字并不等于一个家庭真的需要机器人完成一千件事。 它说明的是，长尾不是家庭里的偶发噪声。长尾就是家庭本身。 “家务”不是一个 Job 行业讨论常把清洁、做饭、看护、陪伴、安防和搬运都放进“家务”这个词里。它们发生在同一间房，却不是同一种产品任务。 扫地漏掉一个角落，用户可以补扫。拿玻璃杯失败，可能损坏物品。安防误报一次会让人厌烦，漏掉一次真实风险后果完全不同。陪伴机器人答错一句话，与看护系统错过紧急异常，也不在同一个责任等级。 所以判断家庭任务，不能只问机器人“会不会做”。 还要问三件事：用户要的结果是什么，做错会发生什么，出错后能不能安全回来。 这会直接改变产品边界。 “陪老人聊天”和“提醒服药”看起来相邻，后者对准确性、日志和责任的要求高得多；“夜间巡逻”和“发现异常后去现场确认”也不一样，前者是一段持续自主行为，后者可以把最后判断交给人。 家庭机器人不该先把能力清单做长，再试图为它寻找需求。更稳妥的顺序，是先定义一个可以验收的结果，再决定需要多少移动、操作和自主。 技术参数最后都会变成家庭体验 导航精度落到家庭里，就是会不会撞到孩子、困在椅子腿之间。 机械臂控制落到家庭里，就是会不会摔坏杯子、夹住手指。 噪声是一个 dB 数字，也决定机器人能不能在夜间工作。续航是一项参数，也决定用户真正需要它时，它是不是正趴在充电座上。 最容易被低估的是恢复能力。 实验室把任务成功率从 80% 提升到 90%，可能已经是明显进步。家庭用户看到的却是，十次仍有一次需要收拾残局。更麻烦的是，失败经常不是“再跑一次”：机器人可能被衣物缠住、地图丢失、停在门口，或者拿起了不该移动的东西。 一项对 10,072 条家用机器人消费者评论的研究，把失败分为技术、交互和服务三类。对用户评价伤害较大的，恰好包括 Task Completion 和 Robustness & Resilience，也就是任务是否做完，以及设备能不能在变化和故障中继续工作。Domestic Robot Failures 所以我会把 Recoverability 单独拿出来评审： 机器人是否知道自己失败了； 用户能不能看懂它停在哪里； 设备能否安全停止、退回或求助； 一个普通家庭能否恢复，而不需要工程师远程排障。 家庭里没有专职运维。每天完成九次、每两天让人排障一次，仍然是一件高负担产品。 技术越深，价值越多，责任也越重 家庭机器人可以同时参与劳动、信息、安防、照护和家庭协同。这让它的经济结构可能比一次性卖硬件丰富，也让产品更容易跨过原本的责任边界。 我会用一张三层地图来检查它。 技术复杂度 可能形成的家庭价值 随之增加的交付责任 移动、定位、环境感知 巡检、移动摄像、远程在场 不闯禁区、少误报、断网可恢复、旁观者知情 抓取与物理操作 清洁、搬运、整理、辅助照护 防夹碰、防损坏、失败回退、任务验收 长期记忆与多成员识别 个性化、家庭协调、持续陪伴 成员权限、数据隔离、儿童与访客保护 云端模型与跨设备连接 更复杂的自动化、内容与智能家居协同 持续可用、版本兼容、数据安全、本地降级 远程人工与专业服务 安防确认、复杂任务协助、照护转介 响应时间、人员资质、隐私、服务成本与责任边界 市场上已经出现这种组合的探索。1X 当前为 NEO 提供 20,000 美元的 Early Access 买断方案，也列出 499 美元/月的订阅；对于机器人暂时不会完成的复杂任务，用户还可以预约 Expert 远程指导。1X NEO 官方订购页 这个案例只能证明企业正在尝试“硬件 + 订阅 + 人工服务”，不能证明模型已经跑通。 相反，它把一件事说得很直白：机器人能力暂时不够时，人工可以补上闭环，但人工同时带来排班、隐私、响应速度和单位经济问题。 收入栈的背面，是责任栈。 卖硬件，要负责质量、保修、维修和召回；卖订阅，要持续交付可感知的价值；提供远程人工，要承担服务网络与隐私；进入安防和照护，则要处理误报、漏报和升级机制。 “硬件毛利不够，后面靠订阅”不是答案。先要说明，订阅持续交付的到底是什么结果。 现有市场支持窄任务，不替通用机器人作证 国际机器人联合会的 World Robotics 2025 报告显示，在其供应商样本中，2024 年消费级服务机器人销量约 2,010 万台，其中家庭任务机器人占 97%；家庭照护机器人只登记了 536 台。IFR 也特别提醒，这些数据来自供应商样本，不应外推为整个行业销量。IFR Executive Summary 这组对比很有价值。 扫地、割草等产品已经找到高频、可见、边界相对清楚的任务。照护和通用操作要进入更非结构化的环境，面对更高的安全与可靠性要求，所以仍然很小。 窄任务的销量可以证明家庭愿意为机器人付费，却不能直接证明通用人形机器人即将复制同样的成熟度。 每跨一层任务，技术与责任都要重新验证。 家庭权限不是一个管理员账号 家庭机器人还有一个普通 App 很少遇到的问题：谁是用户？ 购买设备的人、每天与它相处的人、被摄像头扫到的人、远程查看画面的人，可能不是同一个人。儿童、老人、保姆和访客也不会因为没有账号，就不受机器人影响。 2026 年一项多人家庭的参与式设计预印本研究走访了 15 个家庭。参与者希望拥有更直接的数据控制、清楚的状态通知，以及能随成员变化的个性化规则；他们也担心机器人厂商能否在多人环境里妥善处理个人数据。Multi-person Households’ Privacy Design Preferences 这类需求不能只塞进设置页。它们会进入底层架构： 谁可以让机器人进入哪个房间； 谁能看实时画面、历史记录和事件日志； 摄像、录音或远程接管时，现场的人怎样知情； 哪些数据只在本地处理，哪些可以上传； 家庭成员给出冲突指令时按什么规则处理； 断网、模型不可用或账号失效时，安全能力怎样降级； 紧急停止和人工接管是否始终可达。 购买权、使用权、被感知权和照护责任是四件事。把购买者设成超级管理员，并不能解决家庭共识。 一次产品复盘：最难的不是让机器狗走过去 回到开头那款家庭安防四足机器人。 下面只保留产品判断，去掉公司、时间、硬件参数和未公开路线。它也不是一段用来证明“项目成功”的宣传，而是我在产品定义中学到的边界。 最初我们很自然地把注意力放在本体上：四足机器人能不能跨过门槛，低光环境怎样感知，传感器怎样配，续航够不够。 这些都难，但把价值链写完整后，更棘手的问题出现了： 发现异常 → 去现场 → 看清发生了什么 → 让用户理解 → 决定是否介入 → 留下可追溯结果 机器人能走到现场，只完成了中间一小段。 “异常”由谁定义？误判后怎样停止？需要通知哪位家人？没有回应时是否升级？灯光和声音会不会造成新的打扰？家里两个人意见不一致时，机器人听谁的？用户怎样知道它刚才为什么过去？ 这些问题把一个机器人硬件，变成了家庭权限、事件解释、远程确认和失败恢复共同组成的系统。 后来我形成的判断是：早期价值不该写成“替你守护整个家庭”，而应收缩为一个更容易验收的结果——离家期间发现可疑事件后，移动到固定范围内补充现场信息，再把最终判断交给人。 它没有宏大叙事那么完整，却更容易写清成功、失败与责任。 我会用七个问题筛一条价值链 现在判断一类家庭机器人是否值得做，我会先问七个问题。 用户购买的具体结果是什么，而不是机器人会多少动作？ 这个结果在普通家庭里多久自然发生一次？ 机器人相对摄像头、手机、智能音箱或人工服务，多了什么不可替代的能力？ 最常见的失败是什么，失败一次的代价有多大？ 出错以后，普通家庭能不能安全、简单地恢复？ 主要家庭成员是否理解它何时感知、怎样行动，并愿意接受？ 每增加一层收入，企业新增的交付责任是否仍然划算？ 如果大部分问题答不清楚，人形、轮式、四足还是飞行都还不是重点。 家庭机器人最诱人的地方，是它似乎什么都能做。陷阱也在这里：什么都能做，常常意味着还没有一件事被定义到可以交付。 更现实的路径，是先找到一条高频、结果可见、失败可恢复、家庭共识明确的窄价值链。 先在家庭里稳定地完成一个结果，再一点点获得更多权限、承担更多任务。 延伸资料 BEHAVIOR-1K：1,000 种日常活动与真实物理模拟 Honig et al.：基于 10,072 条评论的家用机器人失败研究 International Federation of Robotics：World Robotics 2025 — Service Robots ISO 13482:2014：Personal care robot safety Li et al.：多人家庭对家用机器人隐私设计的偏好 1X：NEO 官方订购与服务说明" },{ "id": "article-/en/notes/robots-give-people-new-bodies/", "kind": "article", "lang": "en", "title": "Robots Don't Replace People — They Give People New Bodies", "topic": "robotics", "url": "/en/notes/robots-give-people-new-bodies/", "summary": "A capability-gain lens on robots: people keep intent, judgment and high-risk commitments, agents handle shared control, and robot bodies carry human capability to places the body can't reach.", "published": "2026-08-14", "translation_of": "/notes/robots-give-people-new-bodies/", "related": ["household-robots","wearables"], "text": "I have worked on panoramic cameras, 360-degree drones, follow-cameras and consumer home-security robots. The hardware looks nothing alike — some you hold, some fly, some follow you around, some patrol the house. But they all did the same thing: extended a person’s vision, position or actions to places the body cannot reach. That changed how I look at robots. The industry’s default question is: how many people does one robot replace? That has to be asked — factories, warehouses, cleaning and standardized services need to compare efficiency, labor cost and payback period. But if you only look at replacement rates, a lot of robots get undervalued, or put in the wrong market. The drone’s early value was not replacing a helicopter shoot at a lower price — most creators would never have rented a helicopter at all. Drones gave them, for the first time, a pair of eyes that could fly, and only then did new camera positions, shot language and workflows appear. The photographer didn’t leave the task; he gained a body capability: flight. So next to “replace people,” I want a second product line: Robots can also give people a new body. “Body” here is a product metaphor, not a biological claim, and the headline is not denying that robots replace labor. It is a reminder to ask an additional question: once the user has this robot, what can they now do reliably for the first time? Replacement and augmentation are two different product problems If the goal is replacement, the team decomposes the human workflow, then asks how much the robot can cover, how low the intervention rate can go, and whether unit cost is lower. If the goal is a new body, the starting point flips: where can people not see, not reach, not hold steady, not afford the risk? How does the robot connect that capability to the person?   Replacement product “New body” product Starting point Which labor can be automated Which usable capability a person lacks Human’s role Exit routine flows gradually, handle exceptions Keep intent, judgment and high-risk commitments Autonomy goal Raise task coverage, lower human intervention Reduce operating burden while keeping a sense of control Core metrics Completion rate, intervention rate, unit cost, ROI Task reachability, outcome gain, control burden, recovery time Market source Existing, priced labor Tasks that never happened due to distance, danger, scale or cost The two lines overlap: an inspection robot can both keep people out of the site and let engineers see what they couldn’t observe before. The difference is what the product optimizes first. With replacement, teams treat autonomy as a progress bar; with capability gain, they care whether person and machine form a stable loop — was my intent transmitted, what is the machine doing, does feedback come back, can I catch it when something goes wrong. Four verifiable body extensions Break it into four capabilities. Extension What the user gains Typical products What must be verified Vision See positions and scales the body can’t Drones, mobile cameras, inspection and endoscopic devices Faster discovery, recording or understanding of targets Presence Observe, communicate and intervene without being there Telepresence, home mobile terminals Can the remote person understand the scene and act Action Reach farther, steadier, smaller, more precise Robotic arms, surgical assistance, camera robots Higher operation quality, errors caught in time Attributes Heat resistance, radiation resistance, endurance, flight Firefighting, nuclear, deep-sea, pipeline and high-altitude robots People removed from danger while keeping necessary control The extensions stack: a pipeline robot extends vision and changes body size and tolerance; surgical assistance adds 3D vision and fine action; a home security robot extends “presence” beyond leaving the house. This classification is closer to user value than “wheeled, quadruped, humanoid, flying”: the form explains how the capability is implemented; the extension explains why the user needs it. When does a machine start to feel like “my body”? In 1996, Iriki and colleagues trained macaques to retrieve distant objects with a rake and recorded that some neurons processing both touch and vision extended their visual receptive fields to the rake’s length — the enlarged reachable space. They interpreted this as the tool being incorporated into a modified hand body schema. Iriki et al.: Coding of modified body schema during tool use One macaque experiment can’t prove people treat robots as their bodies, and it can’t replace real product research. The clue: whether a tool enters reachable space has little to do with how humanoid it looks — what matters is whether control and feedback form a stable correspondence. So a robot cannot just be a remote switch. The user needs to know where it is, which way it faces, what it sees; how their action becomes machine motion; when the system is correcting for them; how much latency there is; whether a lost connection stops, retreats or continues. Only when these relationships are stable does skill accumulate — the feeling of “mine” comes from a predictable loop. Autonomy level is not a grade to graduate from Giving someone a new body does not mean remote-controlling every joint. Full manual control dumps every degree of freedom on the user — too much cognitive load. Full autonomy requires the system to understand intent, handle the long tail and own mistakes in open environments. Many viable products sit in between: the person gives goals and constraints; the robot handles stability, obstacle avoidance, path and local actions. This is usually called shared autonomy. The FDA’s description of computer-assisted surgical systems is a mature example: the surgeon moves instruments via a console and software, observes a 3D operative field, and performs complex maneuvers in tight spaces — while the FDA is explicit that these devices do not perform surgery independently without direct human control. FDA: Computer-Assisted Surgical Systems The doctor keeps diagnosis, strategy and critical judgment; the system brings vision and motion to places the hand cannot directly reach. Shared autonomy has costs. A 2017 study had a robot assist when the user’s exact goal was unknown; some tasks improved in completion speed and input efficiency, while the study also observed that autonomous assistance could lower some users’ sense of control, and different people adopted different strategies. Javdani et al.: Shared Autonomy via Hindsight Optimization So more autonomy is not automatically better: optimize how much low-level burden the machine absorbs, and how much understanding and control it preserves for the person. Agents can be the motor nerves of this body When a person picks up a cup, they don’t compute each muscle contraction — they express intent, and the nervous system handles joints, force and balance. An agent paired with a robot can form a similar abstraction layer. A creator tells a follow-camera: “stay low and follow the person ahead.” They keep narrative, composition and timing; the agent handles tracking, route, speed, obstacle avoidance and stabilization. A remote user tells a home robot: “go to the kitchen and check whether the faucet is still running” — whether to shut the valve or contact family is confirmed with the person, based on risk and permissions. The control chain has to be bidirectional: Human intent ⇄ Agent shared control ⇄ Robot body ⇄ Physical world With commands only going out — no position, vision, force, collision or failure state coming back — the user cannot form a sense of control; when the agent corrects an action without saying why, the body becomes foreign. A drone shared-autonomy experiment is concrete: when an autonomous system intervenes for safety, adding haptic feedback — returning how the system is correcting to the person — improves human-robot agreement and satisfaction. Mullen et al.: Haptic Feedback Improves Human-Robot Agreement Feedback is not decoration; it is half of the loop. A “new body” has to pass six product gates A camera, a chassis and a remote control don’t make a robot an extension of a person. I check six things. Locatable: the user always knows where it is, which way it faces, and its relationship to the target. Perceivable: video, audio, depth, force or touch support the current judgment — not just a streamed picture. Predictable: same inputs produce similar actions; latency and autonomous corrections stay within understandable bounds. Takeover-able: the user knows when they are in direct control and when the agent is planning; high-risk steps can be paused or taken over. Learnable: with more use, the user gets faster and more accurate and forms stable strategies. Recoverable: after network loss, errors, jamming or mistakes, the robot can stop safely or return to a known state. Missing one or two, a demo can still look great; in long-term use, users will treat it as a remote device they constantly have to watch. Capability gain needs its own accounting: what could this person accomplish without the robot, how many of the new tasks repeat reliably or reduce risk, and does the gain exceed the burden of training, attention, maintenance and failure recovery? If the user has only swapped a simple action for operating a complex machine, the product hasn’t augmented them. The first users often know what a new capability is worth A “new body” robot doesn’t have to sell to everyone first. Photographers know whether a new camera position changes the final shot; maintenance engineers know what one fewer trip into a dangerous space is worth; doctors know what vision and control precision mean for outcomes; professional inspectors can price one avoided shutdown. These users being willing to learn doesn’t mean the interaction can be crude — it means they can judge whether the capability gain is real. This is exactly the Professional role I described in Geek, Professional, B2B, Consumer: Markets as Evidence Environments: professionals validate workflow value and quality thresholds first; the mass market then tests onboarding, maintenance and long-term reuse. Augmentation is not automatically more valuable commercially than replacement: if a new capability has no high-frequency task, the outcome is invisible, or control costs eat the benefit, users won’t pay. The lens just puts demand that replacement rates miss back into product judgment. From now on, when I look at a robot, I ask two questions together. How much existing labor does it save? And what capability does a person gain for the first time? The first question points at an efficiency market; the second may open a market that didn’t exist. References Iriki et al.: Coding of modified body schema during tool use FDA: Computer-Assisted Surgical Systems Javdani et al.: Shared Autonomy via Hindsight Optimization Mullen et al.: Haptic Feedback Improves Human-Robot Agreement Agents go left, embodiment goes right: how AI diverges in information space and the physical world Why home robots are technically harder and economically richer" },{ "id": "article-/notes/robots-give-people-new-bodies/", "kind": "article", "lang": "zh-CN", "title": "机器人不是替代人，而是给人增加新的身体", "topic": "robotics", "url": "/notes/robots-give-people-new-bodies/", "summary": "用能力增益补充替代率：人保留意图、判断与高风险承诺，Agent 处理共享控制，Robot Body 把人的能力送到身体原本到不了的地方。", "published": "2026-08-14", "translation_of": null, "related": ["household-robots","wearables"], "text": "我参与过全景相机、全景无人机和跟拍机，也做过家庭消费级安防机器人的产品工作。 把这些产品放在一起，外形差别很大：有的拿在手里，有的飞在空中，有的跟着人移动，有的在家里巡查。 但它们都做了同一件事。 它们把人的视野、位置或动作，延伸到身体原本到不了的地方。 这让我开始用另一个问题看机器人。 行业最常问的是：一台机器人能替代几个人？ 这个问题当然要算。工厂、仓储、清洁和标准化服务都需要比较效率、人工成本与回收周期。可如果只看替代率，很多机器人会被低估，甚至会被放进错误的市场。 无人机早期最重要的价值，并不是用更低价格替代一次直升机航拍。大量创作者原本根本不会租直升机。无人机让他们第一次拥有一双能飞的眼睛，随后才出现新的机位、镜头语言和工作流。 摄影师没有离开任务。他多了一种身体能力：飞。 所以我更愿意在“替代人”旁边，再放一条产品路线： 机器人也可以给人增加一具新的身体。 这里的“身体”是产品比喻，不是生物学判断。标题也不是否认机器人会替代劳动，而是提醒团队补问一句：用户有了机器人以后，第一次能稳定完成什么？ 替代与增强，是两套产品题 如果目标是替代人，团队会先拆人的完整工作流程，再看机器人能覆盖多少、介入率能降到多少、单位成本是否更低。 如果目标是增加身体，起点会变成：人现在看不到哪里、到不了哪里、做不稳什么、承担不起什么风险？机器人怎样把这项能力接到人身上？   替代型产品 “新身体”型产品 起点 哪段劳动可以自动完成 人还缺哪种可用能力 人的角色 逐渐退出常规流程，处理例外 保留意图、判断和高风险承诺 自主目标 提高任务覆盖，降低人工介入 在减少操作负担的同时保留控制感 核心指标 完成率、介入率、单位成本、ROI 任务可达性、结果增益、控制负担、恢复时间 市场来源 已经存在、可以计价的劳动 过去因距离、危险、尺度或成本没有发生的任务 两条路线会重叠。一台巡检机器人既可能减少人工进入现场，也可能让工程师看见以前无法观察的位置。 区别在于，产品先优化什么。 以替代为目标，团队容易把自主程度当成进度条。以能力增益为目标，团队更关心人和机器能否形成稳定闭环：我的意图有没有被正确传出去，机器当前做什么，反馈能不能回来，出错时我能不能接住。 四种可以被验证的身体扩展 “新的身体”不能停在修辞上。我会先把它拆成四种能力。 扩展 用户多了什么 常见产品 需要验证的结果 视野扩展 看见身体看不到的位置与尺度 无人机、移动摄像、巡检与内窥设备 是否更快发现、记录或理解目标 在场扩展 身体不在现场，也能观察、沟通和介入 远程呈现、家庭移动终端 远程的人能否理解现场并采取行动 动作扩展 够得更远、更稳、更小、更精确 机械臂、手术辅助、摄影机器人 操作质量是否提高，错误能否及时收回 属性扩展 获得耐高温、抗辐射、长续航、可飞行等属性 消防、核工业、深海、管道和高空机器人 是否把人移出危险，同时保留必要控制 这些扩展经常叠在一起。 管道机器人既扩展视野，也改变身体尺寸和耐受环境；手术辅助系统同时增加三维视野和精细动作；家庭安防机器人则把用户的“在场”延伸到离家之后。 这种分类比“轮式、四足、人形、飞行”更接近用户价值。本体说明能力怎样实现，身体扩展说明用户为什么需要。 一台机器什么时候会开始像“我的身体” 1996 年，Iriki 等研究者训练猕猴使用耙子取回远处物体。他们记录到，部分同时处理触觉与视觉的神经元，其视觉感受野在工具使用时扩展到耙子的长度或扩大后的可达空间。研究者把它解释为工具被纳入了修改后的手部身体图式。原始研究 一项猕猴实验不能直接证明人会把机器人当成身体，也不能替代真实产品研究。它提供的线索是：工具是否被纳入可达空间，与它长得像不像人没有直接关系；控制与反馈能否形成稳定对应，可能更重要。 一台机器人因此不能只提供远程开关。 用户要知道它在哪里、朝向哪里、看见什么；自己的动作或意图会怎样变成机器动作；系统什么时候正在帮他修正；延迟有多大；失去连接后机器会停、退回还是继续。 这些关系足够稳定，熟练度才会积累。用得越久，用户应该越会控制，而不是每次都重新猜测机器下一步要做什么。 “属于我”的感觉，来自可预测的闭环。 自主程度不是毕业年级 给人增加身体，不等于让人一直遥控每个关节。 完全手动会把机器的每个自由度和每次纠错都交给用户，认知负担太高；完全自主则要求系统在开放环境里理解意图、处理长尾并承担错误。许多可用产品会落在中间：人给目标与约束，机器人负责稳定、避障、路径和局部动作。 这种分工通常被称为 shared autonomy，共享自主。 美国 FDA 对计算机辅助手术系统的描述就是一个成熟例子。外科医生通过控制台和软件移动器械，观察三维术野，在狭小空间完成复杂操作；FDA 同时明确说明，这类设备不能脱离人的直接控制独立完成手术。FDA：Computer-Assisted Surgical Systems 这没有削弱机器的价值。医生负责诊断、策略和关键判断，系统负责把视野与动作带到人的手难以直接到达的位置。 共享自主也有代价。2017 年的一项研究让机器人在不知道用户确切目标时提供辅助，部分实验任务的完成速度和输入量得到改善；研究同时观察到，自主辅助可能降低部分用户的控制感，不同人也会采用不同策略。Shared Autonomy via Hindsight Optimization 因此，自主程度不是越高越好，也不是所有产品都要走向同一个终点。 该优化的是人机协作的结果：机器替人拿走了多少低层负担，又保留了多少必要的理解与控制。 Agent 可以成为这具身体的运动神经 人拿起杯子时，不会逐项计算每块肌肉收缩多少。我们表达高层意图，神经系统处理关节、力量与平衡，视觉和触觉再把结果送回来。 Agent 与机器人结合后，也可能形成类似的抽象层。 创作者对跟拍机器人说：“保持低机位，跟住前面的人。” 他仍然负责叙事、构图和时机。Agent 处理目标跟踪、路线、速度、避障和稳定。 远程用户让家庭机器人：“去厨房确认水龙头是不是还在流水。” 机器人负责导航、寻找水槽和回传画面。是否关闭设备、联系家人或继续行动，要根据风险和权限交给人确认。 维修工程师要求机器人：“移动到阀门右侧，让铭牌和接头同时出现在画面里。” 系统可以规划姿态并避免碰撞，工程师继续判断异常。 这条控制链应该是双向的： 人的意图 ⇄ Agent 共享控制 ⇄ Robot Body ⇄ 物理世界 只有命令向外，没有位置、视觉、力、碰撞和失败状态向内，用户无法形成控制感。Agent 修正了动作，却不告诉用户为什么，也会让这具身体变得陌生。 一项无人机共享自主实验给出了很具体的例子：自主系统介入以保证安全时，会改变操作者的控制；加入触觉反馈，把系统正在怎样修正传回给人，能够提高人机一致性与满意度。Haptic Feedback Improves Human-Robot Agreement 反馈不是界面装饰。它是闭环的一半。 “新身体”要过六道产品门槛 有摄像头、底盘和遥控器，不代表机器人已经成为人的能力延伸。 我会检查六件事。 可定位：用户随时知道机器人在哪里、朝向哪里，与目标是什么关系。 可感知：视频、声音、深度、力或触觉足以支持当前判断，不只是在回传一段画面。 可预测：相同输入产生相近动作，延迟和自主修正处在可理解范围。 可接管：用户知道何时是直接控制、何时由 Agent 规划；高风险步骤能暂停、接手或退回安全状态。 可学习：使用次数增加后，用户会更快、更准，能够形成稳定操作策略。 可恢复：断网、识别错误、卡住或误操作后，机器人能安全停止或回到已知状态。 六项缺一两项，Demo 仍然可能很精彩；长期使用时，用户却会把它当作一台需要时刻提防的远程设备。 能力增益也要有自己的账。 没有机器人时，这个人能完成什么？有了机器人后，新增加的任务中，有多少可以重复完成、产生收益或降低风险？这些增益是否大于训练、注意力、维护和失败恢复的负担？ 如果用户只是把原来一个简单动作，换成操作一套复杂机器，产品没有增强他。 第一批用户往往知道新能力值多少钱 “新身体”型机器人未必要先卖给所有人。 摄影师知道一个新机位能不能改变成片，维修工程师知道少进一次危险空间值多少钱，医生知道视野和控制精度对应什么结果，专业巡检人员也能计算一次少停机的价值。 这些用户愿意学习，不代表交互可以粗糙。他们只是更容易判断能力增益是否真实，也能把价值翻译成收入、质量、时间和风险。 这与我在不同市场负责消灭不同不确定性里写的 Professional 角色一致。专业用户适合先验证工作流价值与质量门槛，大众市场再检验上手、维护和长期复用。 当然，增强不天然比替代更有商业价值。新能力没有高频任务，结果不可见，或者控制成本吞掉收益，用户一样不会付费。 这个视角只是把替代率没有覆盖的需求，重新放回产品判断。 以后再看一台机器人，我会把两个问题放在一起。 它能省下多少已有劳动？ 它又让一个人第一次获得了什么能力？ 第一个问题指向效率市场。 第二个问题，可能打开一个原来不存在的市场。 延伸资料 Iriki et al.：Coding of modified body schema during tool use FDA：Computer-Assisted Surgical Systems Javdani et al.：Shared Autonomy via Hindsight Optimization Mullen et al.：Haptic Feedback Improves Human-Robot Agreement Agent 向左，具身向右：AI 在信息空间与物理世界的分岔 家庭机器人为什么技术上更难，经济上可能更丰富" },{ "id": "article-/en/notes/appointed-manager-organizational-legitimacy/", "kind": "article", "lang": "en", "title": "From Formal Authority to Organizational Legitimacy", "topic": "organization", "url": "/en/notes/appointed-manager-organizational-legitimacy/", "summary": "An appointed manager must stabilize and diagnose at the same time, then convert the power granted by the appointment into authority the organization is willing to follow — through shared evidence, judgment quality, delivered commitments and fair process.", "published": "2026-08-14", "translation_of": "/notes/appointed-manager-organizational-legitimacy/", "related": ["organization-responsibility"], "text": "There is a management story making the rounds. The company and the person can’t be independently verified, so treat it as a management scenario, not a replicable success case. A VP who had spent his career at headquarters in France was sent to Asia to take over a mature team. He didn’t know the local market, didn’t speak Chinese, and had never managed these people. Everyone knew headquarters had sent him. The usual script: the new leader arrives, listens to a round of briefings, finds problems, replaces people, resets strategy, then announces “we’re going to make some changes.” This VP didn’t start that way. For the first stretch he kept talking to managers and frontline employees — asking not “do you support my strategy,” but: What are you most proud of about this team? Which process wastes the most time? If you had a small budget, what would you fix first? What problem has been raised many times and never actually solved? Months later he shared a five-page deck: what he’d heard, what this team should be proud of, what was grinding people down, what he planned to fix in the next 90 days, and what he needed from the team. The message: he wouldn’t clone French headquarters here; the local market would teach him, and he would own the problems outside the organization. The comments immediately asked: which company really gives a VP three months to do nothing? That question pulls the story back to reality. An appointed leader obviously can’t spend three months interviewing. When key customers are churning, cash flow is at risk, or compliance problems are growing, “let me understand first” can’t become delay. And the point worth discussing isn’t “don’t move for the first three months.” The story illustrates the migration every appointment requires: from the formal authority the company grants with the title, to the organizational legitimacy a team grants through working together. The appointment only solves the first kind of legitimacy Formal authority exists on day one. The org chart carries your name, the budget is yours, people report to you. You can change goals, reallocate resources, make evaluations, and if necessary reorganize and replace people. There is another legitimacy the company can’t grant at the same time. Whether the team believes you understand the real problems and can separate symptoms from root causes; whether your judgments have a basis and your commitments get honored; whether following your decisions makes things clearer and the organization more capable. I call this organizational legitimacy. It’s a management-practice frame for this article, not a replacement for an existing academic concept. Formal authority lets you demand that the team act. Organizational legitimacy makes the team willing to hand you bad news, real disagreement and unfinished judgments. The second isn’t “make everyone like you.” A leader with organizational legitimacy still kills projects, makes trade-offs, restructures and changes people. The difference: the team understands the basis, believes in the process, and has seen commitments honored. A meta-analysis of trust in leadership covering 106 independent samples found that trust in one’s direct leader relates to a range of work attitudes and behaviors — and that the direct leader is a particularly important target of trust. Dirks & Ferrin: Trust in Leadership Trust is not atmosphere. It affects whether people still share information, take on commitments and stay. Why the first 90 days go wrong A new leader faces three pressures at once. The boss wants results; the team wants rules; and the leader wants to prove why the company needed them. The easiest response is to prove value with change: redraw the org chart, replace managers, change processes, launch a new strategy, even deliberately negate what the predecessor left. The actions are fast. The context is minimal. You see the formal org chart, not the real collaboration network; you see outcome metrics, not which decision months ago produced them; you hear that someone “can’t execute,” without knowing whether it’s capability, goals, resources or interfaces; you see a convoluted process, without knowing whether it exists to prevent a past accident. The team also interprets a new leader’s behavior through status. Sauer’s two experiments with newly appointed team leaders found that identical participative or directive behavior was evaluated differently under different status conditions, and affected team performance. Sauer: Taking the Reins The experiments don’t hand real companies a universal prescription. They remind us: what the newcomer does is one layer; how the team explains “why does this person get to do that” is another. The more urgently you prove yourself, the easier it is to substitute positional power for factual understanding. Run two tracks at once: stabilize and diagnose More practical than “observe for three months” is Stabilize + Diagnose: stop the bleeding while you build understanding. Risks that are expanding and have clear costs get handled immediately — safety, compliance, cash flow and major customer problems don’t wait for a full study. For hard-to-reverse decisions, raise the evidence bar. Two questions set the pace: If this keeps running unchecked, does the loss grow fast? After deciding now, can we still reverse it cheaply? Low-risk, reversible actions can happen early. High-risk, irreversible restructuring, replacements and strategic pivots need more evidence. A better 90-day plan looks like three stage gates. Stage Main task Must leave behind Condition to advance Days 0–30: Understand Stop the bleeding; see product, users, business, technology, delivery and organizational relationships Problem map, conflict explanations, urgent-risk list The team can form basic consensus on key problems and unknowns Days 31–60: Co-evidence Pick one important but controllable early battle Shared evidence, decision log, reusable interfaces The team has seen the new way of working improve outcomes Days 61–90: Change Institutionalize goals, decisions, reviews and commitments; handle necessary structure and people issues New interfaces, clear roles, change rationale, review time Change no longer depends on the new leader personally firefighting The days are reference points, not law. A business crisis can compress the stages; a complex organization can need longer. Order matters more than days: understand first, co-evidence second, then change. Draw six maps first The most valuable output of the first 30 days is usually a problem map the team can correct — not a rushed new strategy. Look at the organization from six sides. Product. What role does each line play — exploring, delivering, or merely surviving on sunk costs? Users. Who chooses, who uses, who pays; where is the real churn and usage evidence; which voices are only internal retellings. Business. What drives revenue, cost, channel, renewal, service and cash flow; is growth mixed with subsidies, customization or one-off deals. Technology. Do bottlenecks come from foundational capability, system coupling, quality debt, or planning and coordination. Delivery. How goals become requirements, baselines and commitments; who decides changes; how risk escalates. Organizational relationships. Beyond the formal chart, where do information and trust actually flow; who has low title but moves cross-team problems; who bears outcomes without decision rights. Each map should mark: facts already known, conflicting explanations, missing evidence, and how to validate next. The newcomer’s classic mistake is dismantling infrastructure that was never drawn on the org chart. Choose one small, important battle Understanding alone doesn’t produce organizational legitimacy. The team still has to see things get better. Days 31–60 need an early battle. Not so small that it’s fixing the meeting-room projector, and not a bet on the company’s hardest strategic problem. The right target usually has four features: everyone knows it matters; it has been bothering the team for a while; its boundaries are controllable; it needs cross-team cooperation and can show evidence within weeks. A key release that keeps slipping. A customer problem chain nobody owns. A review interface that makes multiple teams rework endlessly. An early battle has two outcomes. One is solving the problem. The other is the team collectively experiencing a reusable way of working: bad news surfaces early, disagreements are recorded, commitments have owners, decisions get review time. If the win comes entirely from the new leader personally firefighting, it proves individual capability. Only when the working method survives — the team does better without you later — does it convert into organizational legitimacy. Teams need to trust your judgment, not agree with every conclusion What a leader most needs to build is judgment trust, not “everyone likes me.” The team won’t agree with every trade-off, but it should know how conclusions formed. Important decisions deserve five things written down: what the basis is, what isn’t known yet, what was traded for what, when it will be reviewed, and the formal path by which dissenters can bring evidence. This doesn’t slow every decision down. Reversible small moves can be tried fast. Cross-team, high-risk, hard-to-reverse decisions get the fuller record. Organizational-justice research distinguishes outcome, procedure, interpersonal treatment and information explanation. Colquitt’s scale study supported the four dimensions; the procedural dimension includes consistency, accurate basis, opportunity for correction and representativeness. Colquitt: On the Dimensionality of Organizational Justice Teams don’t have to like the outcome. They judge whether the process used reasonably consistent standards, allowed meaningful input, and explained reasons. A decision log isn’t administrative burden. It’s the public record of a leader’s judgment quality. Fix the interfaces before you redraw the org chart A lot of “the people are the problem” is actually unclear interfaces. Product, engineering, sales and delivery each optimize local goals while nobody owns the complete result. Requirements change daily with no formal baseline. A project manager is told to chase the schedule but has no power to escalate risk. Three leaders can all voice opinions and no one makes the final call. Replace people and the interfaces stay; the problems come back. So in days 61–90, check four kinds of interfaces first: Do goals point at one result, not locally optimized metrics; Who proposes a decision, who advises, who is finally accountable; Do reviews expose risk, or perform progress; Do cross-team commitments have explicit content, timing, quality and change rules. Once interfaces are clear, structural problems become recognizable: genuinely duplicated roles, key capabilities with no owner, unreasonable spans of control, or a role no longer fit for the next stage. Then restructuring has a purpose — instead of a new chart proving a new leader arrived. Some structure and people problems can’t wait “Understanding first” can also become another form of avoidance. Clear safety, compliance and integrity issues get handled immediately. A key role that chronically fails its basic duties, a leader who persistently destroys collaboration, or a role whose requirements have fundamentally changed — none of these wait indefinitely for politeness. The line to hold: don’t mistake your unfamiliarity for their incompetence. Before any people decision, separate four things: is the role’s goal clear, is resourcing sufficient, are interfaces reasonable, and does the person have capability and willingness. Evidence and procedural fairness don’t block timely decisions; they stop systemic problems from landing on one person. Delaying an obvious mismatch makes the team compensate for it indefinitely. Replacing people fast without evidence teaches everyone to hide problems. Three outcomes: right, late, wrong Three scenarios merged from common management situations; they don’t correspond to specific companies, people or times. Right. A new leader finds product-engineering reviews chronically inefficient, doesn’t reorganize immediately, first unifies decision standards and cuts redundant reviews, and validates with one key release. Only after delivery smooths out do they adjust roles — by which point the team has seen the shared evidence behind the change. Late. To observe long enough, the manager leaves a core leader who has lost the team’s trust for months. When the replacement finally comes, the decision itself is defensible — but what the team learned is: the problem was always there; the leader just wouldn’t take responsibility. Wrong. After arriving, the manager sees projects slipping and replaces the lead immediately. Months later the root cause surfaces: sales commitments, product scope and engineering resources had been mismatched for a long time. The person changed; the interfaces didn’t; the projects kept slipping. The difference between the three isn’t just the decision. It’s whether the timing and the evidence matched the judgment. Organizational legitimacy leaves behavioral signals It isn’t a satisfaction survey, and it isn’t everyone nodding in the meeting. The more reliable signals: Bad news arrives earlier, not only when it can’t be hidden; Objections move from after-meeting complaints to in-meeting challenges with evidence; Cross-team commitments are clearer; changes stop relying on private coordination; Fewer things need to escalate to the top leader; Middle managers start making judgment calls instead of waiting for instructions; When the leader is absent, the team still uses the same decision logic; Necessary people decisions happen on time and fairly. Edmondson’s study of 51 work teams found psychological safety associated with team learning behavior. Edmondson: Psychological Safety and Learning Behavior in Work Teams A team willing to say “I don’t know,” admit errors and raise counterexamples isn’t a sign of management chaos. It usually means members believe that bringing real problems to the table won’t be punished. One of the strongest signals: the team starts letting you see reality. Back to the opening story. What’s worth borrowing from that VP isn’t “three months of doing nothing,” or a five-page deck. It’s that he didn’t mistake a headquarters appointment for the team’s endorsement. He handled what had to be handled, had the team co-explain reality, and used checkable decisions to turn a title into a work record. So for the first 90 days of an appointment, remember three words: Understand. Co-evidence. Change. When you finally move something important — a structure, a project, a person — the team shouldn’t just see “the new boss is changing things.” They should know: why now, what the evidence is, what it costs, and how we return if the judgment was wrong. That’s when formal authority starts to become organizational legitimacy. References Dirks & Ferrin: Trust in Leadership — Meta-Analytic Findings Sauer: Taking the Reins — New Leader Status and Leadership Style Colquitt: On the Dimensionality of Organizational Justice Edmondson: Psychological Safety and Learning Behavior in Work Teams" },{ "id": "article-/notes/appointed-manager-organizational-legitimacy/", "kind": "article", "lang": "zh-CN", "title": "空降管理者如何从职位合法性走向组织合法性", "topic": "organization", "url": "/notes/appointed-manager-organizational-legitimacy/", "summary": "空降管理者需要一边止血、一边理解，再通过共同证据、判断质量、承诺兑现和公平程序，把任命带来的权力变成组织愿意跟随的权威。", "published": "2026-08-14", "translation_of": null, "related": ["organization-responsibility"], "text": "我最近看到一个被反复转述的管理故事。 故事的具体公司和人物无法独立核验，所以更适合把它当作一个管理情境，而不是可以照抄的成功案例。 一位长期在法国总部工作的 VP，被派到亚洲接手一支成熟团队。他不懂本地市场，不会中文，也没有管理过这群人。所有人都知道，他是总部派来的。 最常见的剧本应该是：新领导上任，听一轮汇报，找几个问题，换一批人，重新定战略，然后宣布“接下来要做一些改变”。 故事里的 VP 没有这么开始。 头一段时间，他反复找经理和一线员工聊，问的不是“你支持我的战略吗”，而是： 你最为这个团队骄傲的事情是什么？ 哪个流程最浪费时间？ 如果只有一小笔预算，你最想修什么？ 什么问题已经说了很多遍，却一直没人真正解决？ 几个月后，他发了一份只有五页的 PPT：听到了什么，这个团队值得骄傲的是什么，什么事情正在折磨大家，未来 90 天准备修什么，以及他需要团队做什么。 他想表达的是：自己不会把这里复制成法国总部；本地市场请团队教他，组织之外的问题由他负责解决。 评论区马上有人问：哪个公司会真的给一个 VP 三个月什么都不做？ 这个质疑把故事从管理鸡汤拉回了现实。 空降管理者当然不能三个月只访谈。关键客户正在流失、现金流出现风险、合规问题还在扩大时，“我先理解一下”不能成为拖延。 故事值得讨论的重点，也不在“前三个月不要动”。 它说明了一次空降需要完成的迁移：从公司任命带来的职位合法性，走向团队在共同工作中逐渐承认的组织合法性。 任命只解决了第一种合法性 职位合法性在上任当天就存在。 组织架构写了你的名字，预算归你，人向你汇报。你可以改目标、调资源、做评价，必要时也可以重组和换人。 还有一种合法性，公司没办法同时发给你。 团队是否相信你理解真实问题，能区分症状和根因；你的判断有没有依据，承诺能否兑现；跟着你的决定走，事情是否更清楚，组织是否更有能力。 我把这部分称为组织合法性。它是本文的管理实践框架，不是对某个既有学术概念的替代。 职位合法性让你有权要求团队行动；组织合法性让团队愿意把坏消息、真实分歧和未完成的判断交给你。 后者不是“让所有人喜欢”。一个拥有组织合法性的负责人仍然会停止项目、做取舍、调整结构和人员。差别在于，团队理解依据，相信程序，也见过承诺兑现。 一项覆盖 106 个独立样本的领导信任元分析发现，对直接领导的信任与多类工作态度和行为结果有关，而且直接领导是很重要的信任对象。Dirks & Ferrin，2002 信任不是气氛。它会影响成员还愿不愿意提供信息、承担承诺和留在组织里。 前 90 天为什么容易做错 新领导同时受到三股压力。 上级在等结果，团队在等规则，自己也想证明“为什么公司需要我”。 最容易出现的应对，是用变化证明价值：重画组织图、换负责人、改流程、立新战略，甚至故意否定上一任留下的东西。 动作很快，Context 却最少。 你看见正式组织图，还没看见真实协作关系；看见结果指标，还不知道它由几个月前的哪个决定造成；听见某个人“执行不行”，还没分清是能力、目标、资源还是接口问题；看见一个复杂流程，也不知道它是不是为了避免过去发生过的事故。 新领导的行为还会被团队放在身份与地位中解释。Sauer 对新任团队领导的两项实验发现，相同的参与式或指令式行为，在不同地位条件下会得到不同评价，并影响团队表现。Taking the Reins 这项实验不能替真实公司开出统一处方。它提醒的是：空降者做什么是一层，团队如何解释“这个人凭什么这么做”是另一层。 越急着证明自己，越容易用职位权力替代事实理解。 两条线同时跑：止血与理解 比“先观察三个月”更实用的做法，是 Stabilize + Diagnose：一边止血，一边理解。 正在扩大、代价明确的风险要立即处理。安全、合规、现金流和重大客户问题，不应该等完整调研。 对难以回头的决定，则提高证据门槛。 可以用两个问题判断动作节奏： 这件事继续不管，损失是否快速扩大？ 现在决定以后，还能不能低成本改回来？ 低风险、可逆的动作可以早点做。高风险、不可逆的重组、换人和战略转向，需要更多证据。 更合适的 90 天计划，是把工作分成三个阶段门。 阶段 主要任务 必须留下的结果 进入下一阶段的条件 0–30 天：理解 止血，同时看清产品、用户、业务、技术、交付与组织关系 问题地图、冲突解释、紧急风险清单 团队能对关键问题与未知形成基本共识 31–60 天：共证 选择一个重要但可控的早期战役 共同证据、决策日志、可复用接口 团队亲眼看到新的工作方式能改善结果 61–90 天：改变 固化目标、决策、评审和承诺机制；处理必要的结构与人员问题 新接口、明确角色、调整依据和复盘时间 改变不依赖新领导持续亲自救火 时间只是参考。业务危机可能把三阶段压缩，复杂组织也可能需要更久。顺序比天数重要：先理解，再共证，然后改变。 先画六张地图 前 30 天最有价值的产出，通常是一张能被团队纠正的问题地图，而不是急着交出新战略。 我会从六个面看组织。 产品。 每条产品线承担什么角色，哪些在探索，哪些在交付，哪些只是被沉没成本拖着继续。 用户。 谁选择、谁使用、谁付费，真实流失和使用证据在哪里，哪些声音只是内部转述。 业务。 收入、成本、渠道、续约、服务和现金流由什么驱动，增长是否混入补贴、定制或一次性机会。 技术。 瓶颈来自基础能力、系统耦合、质量债务，还是排期与协同。 交付。 目标怎样变成需求、基线和承诺，变更谁决定，风险怎样升级。 组织关系。 正式组织图之外，信息和信任实际流向哪里；谁 Title 不高却能推动跨团队问题，谁承担结果却没有决策权。 每张地图都要标出：已经知道的事实、相互冲突的解释、仍缺的证据和下一步验证方式。 空降者常犯的错，是拆掉了组织图上没有画出来的基础设施。 选择一场小而重要的仗 只理解，不会自动产生组织合法性。 团队最终还是要看到事情变好。 31–60 天需要一场早期战役。它不能小到只是修会议室设备，也不适合一上来就赌公司最难的战略问题。更合适的对象通常有四个特征：大家都知道它重要，已经困扰团队一段时间，边界能够控制，需要跨团队合作，并能在数周内看到证据。 可能是一个反复拖延的关键版本，一条没人负责的客户问题链，或者一个让多个团队持续返工的评审接口。 早期战役有两个结果。 一个是把问题解决；另一个是让团队共同经历一种可以复用的工作方式：坏消息能够提前出现，分歧有记录，承诺有人负责，决定有复盘时间。 如果胜利完全来自新领导亲自救火，它证明的是个人能力。只有工作方法留下来，团队以后不靠你也能做得更好，它才开始转化成组织合法性。 团队要信任你的判断，不必同意每个结论 一个负责人最需要建立的是判断信任，不是“大家都喜欢我”。 团队未必同意每次取舍，但应该知道结论怎样形成。重要决定最好写清五件事：依据是什么，哪些还不知道，这次用什么换什么，何时复盘，以及反对者通过什么正式路径提出证据。 这不会让所有决策变慢。 可逆的小动作可以快速试。跨团队、高风险和难回头的决定，才需要更完整的记录。 组织公平研究也区分结果、程序、人际互动与信息解释等不同维度。Colquitt 的量表研究支持了这四类公平感知的区分；其程序维度包括一致性、准确依据、纠错机会和代表性等判断。Colquitt，2001 团队不一定喜欢决定的结果，但会判断过程是否使用了相对一致的标准，是否允许有效输入，是否解释了原因。 决策日志因此不是行政负担。它是管理者判断质量的公开记录。 改组织图之前，先改组织接口 很多“人不行”，其实是接口不清。 产品、研发、销售和交付各自完成局部目标，却没有人对完整结果负责；需求每天变化，却没有正式基线；项目经理负责催进度，却没有升级风险的权力；三个负责人都能提意见，没有一个人做最终决定。 换一批人以后，接口不变，问题还会回来。 所以 61–90 天，我会先检查四类接口： 目标是否指向同一个结果，而不是各自优化局部指标； 决策由谁提出、谁提供意见、谁最终负责； 评审是在暴露风险，还是只表演进展； 跨团队承诺有没有明确内容、时间、质量和变更规则。 这些接口清楚以后，结构问题会更容易辨认：职责确实重复，关键能力没有归属，管理跨度不合理，或者某个角色已经不适合下一阶段。 这时重组才有明确目的，而不是用一张新图证明新领导来了。 有些结构和人员问题不能等 “先理解”也可能被用成另一种逃避。 明确的安全、合规和诚信问题要立即处理；关键岗位长期无法完成基本职责，负责人持续破坏协作，或者角色需求已经发生根本变化，也不能为了显得温和而无限等待。 需要守住的边界是：不要把自己的陌生，当成别人的无能。 做人员决定前，至少要区分四件事：角色目标是否清楚，资源是否足够，接口是否合理，当事人是否具备能力与意愿。证据和程序公平，不会妨碍及时决定；它能避免把系统问题全部落到一个人身上。 拖延明显的人岗错配，会让团队替它长期补位。没有证据地快速换人，则会让所有人学会隐藏问题。 三个结果：做对、做晚、做错 下面三个场景由多种常见管理情境合并而成，不对应具体公司、人物或时间。 做对。 新负责人发现产品与研发评审长期低效，没有马上重组，而是先统一决策标准、减少重复评审，用一个关键版本验证。交付变顺后再调整职责，团队已经看见改变所依据的共同证据。 做晚。 管理者为了充分观察，对一位已经长期失去团队信任的核心负责人迟迟不处理。半年后换人，决定本身没有错，团队得到的信息却是：问题一直存在，只是领导不愿承担。 做错。 空降后发现项目持续延期，立即更换负责人。几个月后才发现，根因是销售承诺、产品范围和研发资源长期不匹配。人换了，接口没有变，项目继续延期。 三种结果的差别不只在决定内容，也在判断发生的时间与证据是否匹配。 组织合法性会留下行为信号 它不是一次满意度调查，也不等于会上所有人都点头。 更可靠的信号是： 坏消息出现得更早，不再等到无法隐藏； 反对意见从会后抱怨，变成会上带证据的挑战； 跨团队承诺更清楚，变更不再只靠私下协调； 很多事情不必升级到最高负责人； 中层开始主动做判断，而不是每件事都等指令； 负责人不在场时，团队仍会使用同一套决策逻辑； 必要的人事决定能够及时、公平地发生。 Edmondson 对 51 个工作团队的研究发现，心理安全与团队学习行为相关。Psychological Safety and Learning Behavior in Work Teams 一个团队愿意公开说“不知道”、承认错误、提出反例，并不说明管理失控。它往往说明成员相信，把真实问题带到桌面上不会受到惩罚。 一个很强的信号是：团队开始愿意让你看见现实。 回到开头的故事。 那位 VP 值得借鉴的，不是“三个月不做事”，也不是一份五页 PPT。 而是他没有把总部任命误当成团队认可。他一边处理必须处理的问题，一边让团队共同解释现实，再用一场场可检查的决定，把头衔变成工作记录。 所以空降管理者的前 90 天，我会记住三个词： 理解。共证。改变。 当你终于要动一个重要的结构、项目或人时，团队不应该只看到“新老板要改了”。 他们应该知道：为什么现在改，证据是什么，代价是什么，如果判断错了怎样回来。 这时，职位合法性才开始变成组织合法性。 延伸资料 Dirks & Ferrin：Trust in Leadership — Meta-Analytic Findings Sauer：Taking the Reins — New Leader Status and Leadership Style Colquitt：On the Dimensionality of Organizational Justice Edmondson：Psychological Safety and Learning Behavior in Work Teams" },{ "id": "article-/en/notes/market-roles-remove-uncertainty/", "kind": "article", "lang": "en", "title": "Geek, Professional, B2B, Consumer: Markets as Evidence Environments", "topic": "product-research", "url": "/en/notes/market-roles-remove-uncertainty/", "summary": "Geek, Professional, domain B2B, and Consumer users are not rungs on a maturity ladder — they are four evidence environments that respectively test technical possibility, workflow value, delivery economics, and scale.", "published": "2026-08-14", "translation_of": "/notes/market-roles-remove-uncertainty/", "related": ["alternatives-entry"], "text": "Every new-product discussion hits the same two questions. B2B or consumer first? Then the familiar line appears: Geek → Professional → B2B → Consumer It fails all the time: products go straight from professionals to consumers, or win a huge consumer base and then retreat to professional scenarios. These are not four levels of maturity but four evidence environments. Before choosing the next stop, ask: What unknown is most likely to kill this product right now, and which market can expose it at the lowest cost with the least distortion? Market entry is about the best learning environment, not the biggest customer base. Technology maturity doesn’t tell you whom to serve first NASA’s Technology Readiness Level describes how a technology moves from proof-of-concept to operational use; it can’t prescribe a market sequence. NASA: Technology Readiness Levels Squeeze technical readiness, user value, workflow, delivery economics and scale into one line and you get three misjudgments: Because the technology works, assume users will switch from their existing solution; Because someone is willing to try, assume the business model replicates; Because the data looks good in a small market, assume the evidence transfers to a big one. NSF’s I-Corps treats the road from lab to market as another set of hypotheses. NSF: About I-Corps Find the biggest unknown first A new product usually faces five unknowns at once. Uncertainty The question to answer What goes wrong if you get it wrong Value Do users care about this outcome, and will they change behavior or pay? Novelty without a reason to come back Workflow Which step does the product enter; how do people, AI and devices divide the work? Strong capability, no completed task Technology & system Do performance, reliability, safety, battery and cost hold up in real use? Demo works; real environments fail Delivery & economics Can sales, deployment, service and unit economics be replicated? Profitable projects; losses at scale Scale Can acquisition, onboarding, retention, brand and support absorb many users? Traffic surges; returns and churn climb Priority is not about which experiment is easiest. Three tests: does the wrong judgment kill the product? How weak is the evidence? Is it about to trigger large, hard-to-reverse spending? Validate the high-impact, weakly evidenced unknown about to trigger irreversible spending. Geeks: find the capability boundary, don’t prove low friction Geek is not an age, income or occupation label, but people willing to pay configuration, learning and fault-tolerance costs. Best at answering: Unexpected uses in the real world Performance and compatibility boundaries Extensibility and integration A community willing to build Geeks underestimate configuration, charging and maintenance, and overestimate customizability and novelty — a product they hand-calibrate may lose the average user at setup. Professionals: prove the workflow, not complexity Professionals are people whose income, output or career results depend on a task. Best at answering: Which step it replaces or strengthens The quality threshold that makes results useful Which improvement users pay for Exceptions that must stay under human control Repeated use and showable output Professionals bring their skills, equipment and complex processes into the product. Batch operations, deep parameters and dedicated integrations may be real needs in a professional market, and not belong in the consumer version. Domain B2B: prove delivery economics, don’t let customization masquerade as product Domain B2B puts the product inside real organizations — budgets, permissions, procurement, deployment and accountability. It tests whether results count as revenue, cost, efficiency or risk; whether the system runs reliably across many people, permissions and long cycles; what sales, training, deployment and support cost; and whether contracts renew, expand and replicate. But a customer paying is not a market existing. A big contract may demand dedicated processes, proprietary interfaces, an on-site team and special hardware; the project has revenue, the product doesn’t. B2B pilots need customization guardrails: A customer-specific requirement must state which reusable capability it is testing; Pricing must include implementation, support and opportunity cost, not just contract value; Success criteria must include a replicable deployment, not a single acceptance; One lighthouse customer cannot substitute for repeated evidence from several similar customers. Consumer: prove the product stands alone, don’t let traffic hide weak value The consumer market strips away the protection that tolerant users provide: whether users can onboard themselves, perceive a result quickly, come back after the novelty fades, and whether channel, returns and support costs are affordable — all exposed. One viral moment, a price cut, or a platform recommendation can produce huge registrations without repeated value; as numbers rise, teams ignore segmented retention, organic use, returns and support cost. Watch whether users return without reminders and whether word-of-mouth survives without the team. The same person can play different market roles The same person can play different roles: a photographer buying a prototype camera acts as a Geek; buying a mature system, as a Professional. The classification doesn’t run on company size, price point or user count — only on what this group is validating right now. Market role Best at proving Primary evidence Biggest distortion Geek Technical possibility, unexpected uses, ecosystem interest Prototype use, modifications, issues, community contributions Overestimates fault tolerance and novelty Professional Workflow, quality threshold, willingness to pay Repeated tasks, time and quality gains, output Pushes the product toward over-complexity Domain B2B ROI, deployment, service, unit economics Contracts, renewals, expansion, implementation cost Treats customized revenue as a replicable product Consumer Onboarding, retention, channel, scale Activation, segmented retention, returns, support cost Lets traffic mask a weak pain point Market roles are not labels. They are evidence responsibilities. Write down how you will leave before you enter Too many pilots end up as “we’re still learning,” because nobody wrote down what would change the decision. Every learning market should have five gates. Stage gate Answer in advance Entry What state must product, safety, supply and support reach before entering Success Which behavioral or economic outcomes would support the core hypothesis Failure What result would overturn the current hypothesis Exit What evidence means this market has done its job No-go Which safety, compliance, cash or reputation risks are unacceptable “Great feedback,” “the customer wants to keep talking,” and “the numbers are still growing” are not stage gates — criteria need time, sample, scenario and behavior bounds. Stage gates also constrain product expansion: features added during a pilot should serve the hypothesis under test, or the product absorbs demands from all four markets while the unknowns never shrink. Market paths must allow returns Geek → Professional → Consumer for exploring technology, then proving workflow, then validating low-friction scale. Professional → Domain B2B → Consumer for confirming a high-value task, then validating organizational delivery, then simplifying complex capability for the mass market. Domain B2B → adjacent B2B is fully legitimate: if the value lives in an industry process, don’t force a consumer story. Sometimes you see Consumer → Professional → Consumer: mass-market testing exposes an unclear task, the team retreats to professionals to redefine it, then returns to scale validation. Returning is not failure — it means the current market cannot answer the next question. Weak consumer retention may be a broken core task; a stalled geek community may mean the exploration is finished. Each return needs a written answer: what unknown will be killed again, and what has to change before re-entry. Three products shouldn’t take the same path Three illustrative scenarios, not real companies. Enterprise AI. Model capability is already usable; the biggest unknown is whether it produces ROI inside real permissions and processes. Domain B2B is the right learning market, but pilots should center on one reusable task and limit proprietary interfaces and on-site support. The exit condition is several similar customers deploying and renewing the same solution — not one big contract. AI creation tools. The biggest unknown is which step AI should take over and who judges quality. Professional users supply high-frequency tasks and strict feedback; once workflow and quality thresholds stabilize, Consumer tests onboarding, expression and retention. The professional control panel should not be carried into the consumer version unvalidated. Smart wearable hardware. While sensors, compute and the control chain are unstable, Geeks expose the technical boundary. But if the long-term goal is daily wear, comfort, social acceptance and natural reuse must be re-validated by the target consumers — geeks hand-calibrating and charging constantly is not consumer evidence. Three products, no shared order — only a shared method: let the market best suited to the job kill the biggest unknown, and watch how it distorts the product. The next stop should be the market that produces more critical evidence. Before leaving, state four things: the lethal unknown, who can expose it best, how those users will skew the product, and what evidence means stop. Market size defines the distant imagination; the next critical piece of evidence decides where you go now. References NASA: Technology Readiness Levels NSF: About I-Corps Steve Blank: Customer Development Y Combinator: How to find product-market fit" },{ "id": "article-/notes/market-roles-remove-uncertainty/", "kind": "article", "lang": "zh-CN", "title": "Geek、Professional、B、C：不同市场负责消灭不同不确定性", "topic": "product-research", "url": "/notes/market-roles-remove-uncertainty/", "summary": "Geek、Professional、领域 B 端和大众消费者不是产品成熟度阶梯，而是四种证据环境，分别验证技术可能性、工作流价值、交付经济与规模能力。", "published": "2026-08-14", "translation_of": null, "related": ["alternatives-entry"], "text": "讨论一个新产品怎样进入市场，会议里经常很快出现两个问题。 先做 B 端，还是先做 C 端？ 产品还不成熟，要不要先找一批极客？ 接下来，一条熟悉的路线就会被画出来： Geek → Professional → B → C 先让极客试，再服务专业用户；有了案例以后做企业，产品足够成熟了再进入大众市场。 这条路线听起来像升级阶梯，现实里却经常走不通。 有些产品从专业用户直接进入消费市场，有些从一个 B 端行业走到另一个 B 端行业，从来没有成为大众产品；有些先在 C 端获得大量用户，留存不好，又退回专业场景重新定义任务。也有产品在极客社区很热闹，离开愿意折腾的人以后就没人再用。 市场顺序没有统一答案，因为 Geek、Professional、B、C 不是四个成熟度等级。 它们是四种证据环境。 选择下一站之前，更该问的是： 当前最可能杀死产品的未知是什么？哪一类市场能用最低成本、最少失真地把它暴露出来？ 市场进入不是先选择最大的客户群，而是先选择最合适的学习场。 技术走到了哪里，不等于应该先服务谁 NASA 的 Technology Readiness Level 用一组等级描述技术从原理、概念验证走向系统运行。它回答的是技术成熟度，不能直接给出市场顺序。NASA：Technology Readiness Levels 一个技术成熟的产品，用户价值仍可能不成立；一个很早期的原型，也可能已经在少数高价值任务里带来明确收益。 把“技术准备”“用户价值”“工作流”“交付经济”和“规模能力”压成一条从小众到大众的直线，容易造成三种误判： 技术能用，就以为用户愿意改变原来的方案； 有人愿意试，就以为商业模式可以复制； 小市场跑出数据，就以为证据能直接迁移到大市场。 NSF 的 I-Corps 之所以把 Customer Discovery 放在科研成果商业化过程中，也是因为从实验室到市场不是一次交接，而是另一组假设验证。NSF：About I-Corps 市场选择要从不确定性开始。 先找出最大的未知 一款新产品通常同时面对五类未知。 不确定性 要回答的问题 判断错了会怎样 价值 用户是否在意这个结果，愿不愿改变或付费 有新奇感，没有复用理由 工作流 产品进入哪一步，人和 AI 或设备怎样分工 单点能力很强，进不了完整任务 技术与系统 性能、可靠性、安全、续航和成本能否持续成立 Demo 成功，真实环境频繁失败 交付与经济 销售、部署、服务和单位经济能否复制 每个项目看似赚钱，规模越大越亏 规模 获客、上手、留存、品牌和支持能否承受大量用户 流量很大，退货、流失和口碑迅速恶化 优先级不是看哪个实验最容易做。 应该看三件事：这项判断如果错了，是否会杀死产品；目前证据有多弱；它是否正在触发大笔、难以撤回的投入。 一个按钮实验很便宜，却回答不了用户为什么需要产品。一次大规模发布能快速获得曝光，也可能在核心任务还没成立时提前消耗品牌。 先验证影响大、证据弱、即将引发不可逆投入的未知。 Geek：发现能力边界，不证明低门槛 Geek 不是年龄、收入或职业标签。它指的是愿意为新能力付出配置、学习、改造和容错成本的人。 他们会读日志、报 Issue、试参数、接入其他系统，甚至自己修复产品。早期 AI 工具、开源硬件、机器人套件和开发者产品，都能从 Geek 获得高密度反馈。 这类市场最适合回答： 技术在真实世界还能产生什么意外用途； 性能与兼容边界在哪里； 产品能不能被扩展、改装或接入生态； 是否存在一群愿意共同建设的人。 同样的特征也会带来失真。 Geek 往往低估配置、学习、充电和维护的负担，高估可定制性与技术新奇的长期价值。他们愿意手工校准的产品，大众用户可能连第一次设置都过不去。 所以极客行为可以帮助发现能力，却不能直接定义大众产品的默认体验。 当技术边界和潜在任务已经被看见，继续提高极客满意度，不一定还在消灭下一个关键未知。 Professional：证明工作流，不代表产品越复杂越好 Professional 是依赖某项任务获得收入、产出或职业结果的人。 摄影师、设计师、维修工程师、研究员、医生和内容创作者，通常拥有高频、清楚、可以评价的工作流。他们能迅速判断一个工具是否提高了质量、节省关键时间，或者减少高成本错误。 Professional 最适合回答： 产品替代或增强了哪一步工作； 结果质量达到什么门槛才有用； 用户愿意为哪一种改进付费； 哪些例外必须保留人工控制； 能否形成重复使用和可展示的成果。 风险是，专业用户会把自己的技能、设备和复杂流程带进产品。 批量操作、行业格式、深度参数和专用集成，对专业市场可能都是真需求，却不一定应该进入大众版本。团队需要提前说清：Professional 是长期市场，还是这一阶段用来验证工作流的学习市场。 离开这个阶段的条件也不是“功能做完了”，而是核心任务、质量门槛、付费依据和人工边界已经可以稳定解释。 Domain B2B：证明交付经济，不让定制冒充产品 领域 B 端把产品放进真实组织，也把预算、权限、采购、部署、运维和责任一起带进来。 它适合验证结果能否被计算成收入、成本、效率或风险；系统能不能在多人、多权限和长周期里可靠运行；销售、培训、部署和支持到底要花多少钱；合同能不能续约、扩容并复制到相似客户。 但客户愿意付钱，不等于市场已经成立。 一家大客户可能给出很高合同额，同时要求专属流程、独有接口、驻场团队和特殊硬件。项目有收入，产品却没有积累。第二个客户来了，团队又从头做一遍。 所以 B 端试点要提前设置定制护栏： 客户特有需求必须说明它在验证哪项可复用能力； 报价要计算实施、支持与机会成本，不能只看合同额； 成功标准要包含可复制部署，不只包含一次验收； 一个标杆客户不能替代多个相近客户的重复证据。 B 端完成这一阶段任务的标志，是团队知道谁购买、为什么续约、怎样部署，以及服务边界能不能守住。 Consumer：证明产品能独立成立，不让流量遮住弱价值 大众消费市场会拿走高容忍用户提供的保护。 没有培训，没有驻场支持，也没有人反复解释产品价值。用户能不能自己上手，能否在几分钟或几天内感知结果，新奇期过去后还会不会回来，渠道、退货和客服成本是否可承受，都会被迅速暴露。 这也是 C 端最适合验证的东西：低摩擦、自然复用和规模能力。 风险来自同一个地方。 一次传播事件、降价或平台推荐可以带来大量注册与销量，却不一定带来重复价值；硬件首发售罄，也可能只是库存很少。总用户数上升时，团队容易忽略分群留存、自然使用、退货和支持成本。 C 端不能只看曝光和首购。更该看用户是否在没有提醒时回来，目标任务是否自然重复，口碑能不能在离开创始团队解释后继续传播。 同一个人，也可能承担不同市场角色 一位职业摄影师购买原型相机，可能作为 Geek 帮助探索技术边界；购买成熟拍摄系统时，则作为 Professional 验证工作流价值。一家小型设计公司既可以是一群专业用户，也可以作为 Domain B2B 验证采购、权限和部署。 所以这套分类不按个人或企业、付费高低、用户数量划分。 关键是：这群用户此刻在替产品验证什么。 市场角色 最擅长证明 主要证据 最大失真 Geek 技术可能性、意外用途、生态兴趣 原型使用、改装、Issue、社区贡献 高估容错与新奇价值 Professional 工作流、质量门槛和付费 重复任务、时间与质量增益、作品 把产品做得过度复杂 Domain B2B ROI、部署、服务和单位经济 合同、续约、扩容、实施成本 把定制收入当成可复制产品 Consumer 上手、留存、渠道和规模 激活、分群留存、退货、支持成本 让流量掩盖弱痛点 市场角色不是标签，而是证据职责。 进入市场前，先写清怎样离开 很多试点无论结果怎样，最后都会被解释成“我们还在学习”。原因很简单：团队从没提前写下，什么结果会改变决定。 每一个学习市场，都应该有五道门。 阶段门 要提前回答什么 Entry 产品、安全、供应和支持达到什么状态才允许进入 Success 哪些行为或经济结果出现，核心假设才得到支持 Failure 什么结果会推翻当前假设 Exit 获得什么证据后，这个市场已经完成任务 No-go 哪些安全、合规、现金或声誉风险不能接受 “反馈很好”“客户愿意继续聊”“数据还在增长”都不是阶段门。标准要有时间、样本、场景和行为边界。 阶段门还要约束产品扩张。试点新增的功能，应该服务当前要验证的假设。否则产品会同时吸收四类市场的要求，能力越来越多，关键未知却一个也没有消失。 市场路径要允许返回 市场进入不是一条只许向右的单行道。 Geek → Professional → Consumer，适合先探索技术，再证明工作流，最后验证低门槛规模。 Professional → Domain B2B → Consumer，适合先确认高价值任务，再验证组织交付，最后把复杂能力简化给大众。 Domain B2B → 相邻 B2B 也完全成立。价值来自行业流程，就没有必要强行讲消费故事。 有时还会出现 Consumer → Professional → Consumer：大众测试暴露任务不清，团队退回专业用户重新定义，再回到规模验证。 返回不是失败。它说明当前市场回答不了下一个问题。 比如，C 端留存差，原因可能不是获客创意不足，而是核心任务没成立；B 端部署失败，问题可能不在销售，而在可靠性和系统边界；Geek 社区增长停滞，也可能说明技术探索已经完成，产品该转向价值验证。 每次返回都要写清：重新消灭什么未知，发生什么变化后才允许再次进入。 三个产品，不该走同一条路 下面是三个用于说明判断方式的产品情境，不对应具体公司。 企业 AI。 模型能力已经可用，最大未知是能否进入真实权限与流程并产生 ROI。Domain B2B 是合理学习市场，但试点要围绕一个可复用任务，限制专属接口与驻场支持。退出条件是相近客户可以用同一方案部署、续约，而不是拿到一个大合同。 AI 创作工具。 最大未知是 AI 应该接管哪一步、质量由谁判断。Professional 能提供高频任务与严格反馈。工作链和质量门槛稳定后，再由 Consumer 检验上手、表达方式和留存。专业控制台不应该未经验证全部带进大众版本。 智能穿戴硬件。 传感器、算力和控制链尚不稳定时，Geek 可以暴露技术边界。但长期目标如果是大众佩戴，舒适、社会接受和自然复用必须由目标消费者重新验证。极客愿意携带多设备、手工校准和频繁充电，不构成大众产品证据。 三个产品没有共同顺序，只有共同方法：让最合适的市场消灭当前最大的未知，同时看住这个市场会怎样扭曲产品。 所以，下一站不一定是更大的市场。 它应该是能带来更关键证据的市场。 出发前，团队只需要把四件事说清楚：当前最大的致命未知是什么，谁最能暴露它，这群用户会怎样带偏产品，以及得到什么证据后必须离开、返回或停止。 市场规模决定远处的想象。 下一项关键证据，决定现在应该去哪里。 延伸资料 NASA：Technology Readiness Levels NSF：About I-Corps Steve Blank：Customer Development Y Combinator：How to find product-market fit" },{ "id": "article-/notes/ai-wearable-modalities-body-comfort/", "kind": "article", "lang": "zh-CN", "title": "AI Wearable 的竞争，不是眼镜对耳机", "topic": "ai-devices", "url": "/notes/ai-wearable-modalities-body-comfort/", "summary": "AI Wearable 不应按眼镜、耳机、戒指等形态简单分组。产品竞争发生在输入输出模态组合、多模态控制、身体高上下文区域与长期佩戴舒适性的系统设计上。", "published": "2026-08-13", "translation_of": null, "related": ["wearables"], "text": "打开一份 AI Wearable 竞品表，第一列通常是眼镜、耳机、戒指、手表和挂坠。 这种分类适合摆放商品，却不适合解释竞争。 两副外形相似的眼镜，可能是完全不同的产品：一副用摄像头和麦克风理解环境，再通过声音回答；另一副增加显示，把导航、翻译和消息直接放进视野。它们的输入、输出、交互带宽、功耗和使用场景都不同。 反过来，一副眼镜、一只耳机和一枚戒指，也可能在竞争同一件事：谁能最自然地获得用户当下的上下文，理解他的意图，并在不打断现实任务的情况下给出帮助。 因此，AI Wearable 的竞争不能只看“眼镜对耳机”。更有解释力的分析单位是四层组合： 输入与输出模态怎样配对； 用户通过什么方式控制系统； 设备占据身体哪个高上下文区域； 用户愿意为这套能力承担多少佩戴成本。 产品形态只是这四层约束共同作用后的结果。 一、先比较模态组合，不要先比较设备名字 多模态要落到输入、输出与任务的匹配，不能只数摄像头、麦克风和模型。 输入模态决定系统能理解什么，输出模态决定系统能怎样回应。两者必须与具体任务一起比较。 W3C 很早就把语音、触摸、键盘和手写等视为不同输入，把显示、语音、音频和触觉视为不同输出。进入 AI Wearable 时代，模型开始在这些模态之间理解语义、保持上下文并生成回应。 可以把一款产品写成一个组合： 输入模态 × 输出模态 × 用户任务 × 使用环境 同样叫“AI 助手”，不同组合会形成不同产品。 模态组合 适合的任务 主要优势 主要限制 图像 + 语音输入 → 语音输出 询问眼前物体、实时翻译、环境提示 用户不用描述现场，也不用盯屏幕 复杂信息难以靠声音快速浏览和回看 语音输入 → 图像输出 导航、字幕、清单、短消息 结果可扫视、可持续留在界面 需要显示系统，增加功耗、重量与视觉干扰 图像 + 语音输入 → 图像 + 语音输出 现场指导、空间提示、分步骤任务 输入和反馈带宽都高 系统复杂，对延迟、配准、散热和交互要求更高 语音 + 动作输入 → 语音或触觉输出 运动、通勤、免手操作 不占用视线，反馈及时 难承载结构复杂或需要比较的信息 生理 + 动作输入 → 图像或语音输出 健康趋势、运动建议、异常提醒 能持续感知身体状态 数据解释、误报、权限和医疗边界更敏感 这些组合没有统一的高低顺序。 声音输出适合即时、线性的短信息，却不适合同时比较多个选项；视觉输出带宽更高，但会占用视野和注意力；触觉非常离散和私密，却很难解释复杂内容。摄像头能获得第一视角环境，但也带来功耗、隐私和旁观者接受问题；麦克风适合自然语言，却会受到噪声、公开场合和口音影响。 Google 对 Android XR 眼镜的公开描述就展示了这种组合差异：摄像头、麦克风和扬声器可以提供视觉与语音输入、声音输出，显示则是可选能力。是否增加显示，不只是“高配或低配”，而是产品任务、反馈带宽和佩戴代价的重新分配。 所以比较 AI Wearable 时，第一列不该是“眼镜/耳机”，而应该是：它能看到、听到或感知什么，又能用什么方式把结果交还给人。 二、控制方式要按任务分工 输入与输出回答系统如何感知和表达，控制方式则回答：用户怎样把意图可靠地交给系统。 语音很自然，但不是万能入口。 用户在安静的家里可以直接说出复杂意图，在会议、地铁和面对陌生人时却可能不愿开口；高噪声环境会影响识别，涉及密码、回复和确认时也不适合公开说出。对“开始录制”“确认支付”“关闭提醒”这类确定性动作，实体按钮或清晰手势通常比开放语句更可预期。 一套完整的交互系统更可能把任务分配给多种控制： 语音：表达开放、语义复杂的意图； 按钮与触摸：执行高频、确定、需要盲操作的动作； 视觉界面：展示状态、选项、差异和确认； 手势、戒指或腕带：在不说话、不触碰面部设备时发出离散指令； 手机：承担首次设置、复杂编辑、权限管理和异常恢复。 这些入口要根据动作的频率、风险、隐私和认知负担分工，而不是全部堆进一台设备。 已经出现的产品路径也说明，控制器不必长在主设备上。Apple 在 visionOS 中把眼睛用于指向、手势用于确认；Meta 的显示眼镜把 EMG 腕带作为控制器，用细微手部动作发出命令；Samsung 的智能戒指则能通过双指捏合控制手机拍摄或关闭闹钟。 这些例子指向一个更重要的变化： AI Wearable 可以是一套分布在眼睛、耳朵、手指、手腕和手机之间的个人交互系统。 眼镜负责第一视角和显示，耳机负责私密音频，戒指或腕带负责静默确认，手机负责高密度管理。此时，竞品分析不能只比较主机，还要比较配对、连接、充电、状态同步和异常恢复组成的整条交互链。 三、稀缺的是身体上的“上下文位置” 手机通常在口袋或桌面上。要获得上下文，用户需要掏出、解锁、对准、输入；任务结束后再收起。 Wearable 的价值，是把传感器和反馈通道放在更接近用户感官、动作与意图的位置，减少这段启动成本。 不同身体区域承载的上下文并不相同。 身体区域 最容易获得的上下文 最适合的反馈或控制 核心代价 眼睛与面部附近 第一视角画面、注视方向、环境空间 视觉显示、声音、触摸镜腿 光学、重量、热、外观、处方适配与拍摄隐私 耳朵附近 环境声音、对话、头部运动 私密音频、触摸、头部动作 长期堵塞感、听觉占用、卫生与续航 嘴与喉部附近 语音、呼吸、细微发声与交流意图 语音输入、静默语音潜力 社交可见性、噪声、隐私与贴肤舒适 手腕与手指 手部动作、确认意图、生理与活动信号 手势、触觉、按钮、离散命令 场景理解较弱，动作误触与双手占用 脖子与胸前 较稳定的朝向、声音、运动与更大承载空间 音频、触觉、摄像头或作为算力电池载体 摆动、衣物遮挡、压迫、发热与外观接受度 “上下文密度”取决于某个位置能否持续接近用户正在看、听、说、做和决定的事情，而非传感器数量。 五官附近尤其重要，因为它同时接近现实输入和人的主要感知通道。眼镜获得与视线接近的第一视角，耳机靠近听觉并能私密输出，嘴部附近最接近语言意图。脖子和胸前则提供另一种可能：把部分重量、摄像头、扬声器、电池或计算从面部移开，换取更大的承载空间。 但身体位置不是一块被抢到就永久拥有的“地盘”。它是一份持续许可。设备只有在用户愿意戴、允许感知、并能在真实场景使用时，才拥有上下文。 因此，最强的竞争对手经常仍是手机。手机虽然启动摩擦更大，却拥有成熟显示、输入、算力、连接和应用生态。Wearable 必须证明，它在某些高频或关键时刻减少的摩擦，足以覆盖新增设备带来的佩戴、充电和管理成本。 四、舒适性直接决定产品能力 AI 产品依赖上下文，Wearable 获取上下文的前提是它真的在用户身上。 一款设备拥有再多传感器，如果用户一小时后就摘下，实际可用上下文仍然很少。可以把有效能力粗略写成： 有效上下文 = 感知能力 × 实际佩戴时长 × 场景覆盖 × 用户授权 其中任何一项接近零，最终结果都会大幅下降。 重量只是佩戴舒适性的一部分。 1. 物理舒适 总重量、重心、接触面积、夹持力、局部压力、温升、透气、材质和尺寸适配共同决定体感。针对头戴显示的研究发现，重量会影响疲劳，而重心位置会改变这种影响；同样的克数，以不同方式分布在鼻梁、耳朵和头部，感受并不相同。 2. 感官舒适 显示亮度、视野遮挡、文字位置、声音泄漏、耳道占用、持续提示和震动强度都会消耗注意力。设备没有压痛，不代表它不会造成视觉、听觉或认知疲劳。 3. 交互舒适 频繁说唤醒词、抬手、捏合、触摸镜腿或重复确认，都属于交互成本。一个动作第一次很酷，不代表每天执行一百次仍然自然。 4. 社会舒适 用户是否愿意戴着设备见客户、坐地铁、与朋友交谈？旁观者能否知道摄像头何时工作？公开说话、凝视界面或做特殊手势，会不会让用户和周围的人不自在？这些问题直接决定可用场景。 5. 维护舒适 每天要充几次电，需要携带几个盒子，沾汗或下雨后怎样清洁，镜片和耳塞如何更换，忘带控制器后是否还能使用，设备故障如何维修——这些都构成长期佩戴成本。 因此，舒适性会直接约束传感器、算力、结构、交互和商业模式，不能留到产品完成后再优化。 五、从设备品类转向四种系统路线 把模态、控制、位置和舒适性放在一起，可以看到几种不同的系统路线。 系统路线 典型组合 优势 必须接受的取舍 感知优先 图像 + 语音输入，声音输出，语音/按钮控制 轻反馈、少占视线，适合问答、记录和环境帮助 难浏览复杂信息，很多结果仍需回到手机 扫视反馈 图像 + 语音输入，视觉 + 声音输出，手势/腕带控制 信息密度更高，可做导航、字幕和短交互 显示、控制和功耗提高系统复杂度与佩戴成本 听觉伴随 语音 + 环境声音 + 动作输入，声音/触觉输出 形态成熟、私密、适合通勤和免手任务 缺少第一视角图像与视觉反馈 分布式系统 眼镜或耳机 + 戒指/腕带 + 手机 不同身体位置各司其职，控制更丰富 多设备购买、配对、充电、丢失与状态同步 这四种路线并不互斥，也不是固定终局。它们只是帮助产品团队看清：增加一项模态或一个控制器，会改变整套系统的收益和成本。 一个产品也不需要覆盖所有路线。清楚的定位应说明：服务谁、在什么情境、完成什么任务、为什么这组模态和身体位置比手机或现有设备更好，以及不适合谁。 六、怎样验证一款 AI Wearable 是否成立 如果仍按形态做问卷，用户很容易回答“更喜欢轻一点的眼镜”或“希望耳机增加摄像头”，却无法证明他会长期佩戴。 更有效的验证从代表性任务开始。 1. 用同一任务比较不同系统组合 例如在步行导航、现场翻译、家庭记录或设备维修中，同时测试手机、声音型 Wearable、带显示 Wearable 和分布式控制方案。不要先规定答案一定是眼镜。 2. 覆盖真实环境，而不只在演示空间测试 安静与嘈杂、室内与户外、独处与社交、双手空闲与被占用、网络良好与中断，都可能改变最合适的模态。 3. 记录整天的佩戴行为 观察用户什么时候戴上、摘下、静音、改用手机、忘记充电，以及为何放弃某次交互。实验室里的十分钟任务无法替代连续数日的行为。 4. 同时测任务结果与佩戴成本 至少记录：启动时间、任务完成率、纠错次数、误触发、人工确认、摘下次数、有效佩戴时长、续航覆盖、社交中断、旁观者反应和次日复用。 5. 预先写出推翻条件 如果高频任务仍要回到手机；如果显示提高了完成率却显著缩短佩戴时长；如果语音在多数目标场景无法公开使用；如果分布式控制带来的增益小于多设备管理成本，就应该收缩方案，而不是继续增加参数。 AI Wearable 的验证要检验用户是否愿意为了持续完成一组任务，把某套系统长期留在身体上。单问他喜不喜欢一种形态，得不到这个答案。 结语：下一代入口是一套组合 眼镜、耳机、戒指、手表和挂坠当然会继续存在，但这些名字越来越难解释产品边界。 竞争集中在四件事上： 哪些输入能获得任务所需的上下文； 哪些输出能以最低打扰交付结果； 哪些控制方式能让用户可靠、私密地表达意图； 哪个身体位置能让这套能力被长时间接受。 传感器最多、显示最强或模型最大的设备未必胜出。产品还要把模态、交互、身体位置与舒适性组合成一套低摩擦的使用流程。 所以，分析 AI Wearable 时，不妨先把“眼镜对耳机”从标题里删掉。 先问：在真实任务中，用户愿意让哪一组感知与反馈通道，留在自己身上多久？ 延伸资料 W3C：Multimodal Architecture and Interfaces Google：Android XR、Gemini 与智能眼镜 Apple：Design for spatial input Meta：Ray-Ban Meta 的多模态 AI 与实时帮助 Meta：显示眼镜与 EMG 腕带 Samsung：Galaxy Ring 的 Double Pinch 控制 Applied Sciences：头戴显示重量与重心对身体负荷的影响" },{ "id": "article-/notes/competitive-analysis-software-hardware/", "kind": "article", "lang": "zh-CN", "title": "竞品分析为什么不该从参数表开始", "topic": "product-research", "url": "/notes/competitive-analysis-software-hardware/", "summary": "软件竞品分析的核心是工作流、数据、协作、迁移与持续交付；硬件竞品分析还必须进入物理体验、系统耦合、量产、可靠性、渠道与售后。参数表应该是结论，不是起点。", "published": "2026-08-13", "translation_of": null, "related": ["alternatives-entry"], "text": "很多竞品分析都从一张表开始。 左边列产品，右边列功能、价格、性能、尺寸、模型和渠道。格子越多，报告看起来越完整；勾选越密，产品似乎越有竞争力。 但这张表经常跳过一个更早的问题：用户究竟在做什么选择？ 一个团队采购项目管理软件时，比较对象可能不只是另外三款项目管理软件，还包括 Excel、微信群、邮件、内部系统，以及继续维持现状。一个家庭购买清洁机器人时，比较对象也不只是其他机器人，还包括吸尘器、保洁服务、已有设备和暂时不买。 如果没有先定义用户、情境、任务和现有方案，参数表比较的只是“看起来相似的产品”，不一定是用户会互相替换的方案。 更麻烦的是，软件和硬件虽然都能列参数，却遵循两套不同的竞争逻辑。 软件竞争往往围绕工作流、数据状态、组织采用和持续变化展开；硬件竞争还要面对物理约束、批量一致性、生产交付、生命周期与售后网络。智能硬件则同时运行着两只时钟：软件持续更新，硬件版本却要经过更长的设计、验证、生产和库存周期。 所以，竞品分析要先回答： 谁会在什么时刻，为了完成什么任务，从哪个现有方案切换过来；获得的收益，是否足以覆盖切换成本与采用风险？ 参数表仍然有用，但它应该出现在分析的后半段，而不是第一页。 一、参数表为什么总是开始得太晚 参数表默认了三个前提：比较对象已经正确，指标已经重要，指标之间可以直接比较。 现实里，这三个前提经常都不成立。 第一，品类相同，不等于互为竞品。 同样叫“AI 助手”的产品，可能分别服务个人写作、企业客服和开发运维；它们共享技术名词，却不争夺同一个用户、预算和任务。 第二，可测量，不等于会影响选择。 上下文长度、摄像头像素、峰值算力和电池容量容易写进表格，但用户可能更在意首次配置是否成功、团队权限是否清楚、设备会不会发热、戴一小时是否难受，以及出故障后由谁处理。 第三，指标不是彼此独立的。 硬件的重量、续航、散热、结构强度和成本相互牵制；软件的自动化程度、可控性、学习成本和权限风险也会互相影响。单独比较每个格子，很容易得到一台“每项都更强”、整体却不好用的纸面产品。 参数表会把一个选择问题过早地变成产品问题。 二、起点：用户的选择集合 更可靠的竞品分析，应先建立一个最小的“决策契约”： 目标用户：是谁在用，谁在买，谁会否决； 触发情境：什么变化让他开始寻找方案； 目标任务：他想完成什么结果； 当前流程：今天怎样完成，哪里不满意； 决策范围：市场、价格、地区、渠道和时间； 分析目的：这次分析要改变哪个产品或商业决策。 有了这些边界，比较对象才能按用户的真实选择进入四个集合。 选择类型 定义 常见例子 直接竞品 相近产品服务相近用户、任务与购买情境 同类 SaaS、同价位机器人、同形态穿戴设备 替代方案 不同产品或流程完成同一个任务 表格代替专业软件，人工服务代替机器 非对称选择 更便宜、更简单、已捆绑或自行建设的方案 套件内置功能、内部工具、租赁、二手设备 不行动 延后购买，继续忍受现状 维持旧流程、继续使用已安装设备 只有直接竞品，很容易把分析做成“同行抄了什么”；加入替代方案，才能看见现有工作流和真实切换门槛；加入非对称选择与不行动，才能理解为什么一款功能更少的产品、一个免费内置能力，甚至什么都不做，仍然可能赢。 最终的比较关系可以写成一个简单的不等式： 用户感知到的增益 > 切换成本 + 采用风险 竞品分析的任务，就是把不等式两边具体化，而不是证明自家参数更多。 三、软件竞品分析：比较的是一条持续运行的工作流 软件没有固定在某个版本。功能可以按周甚至按天变化，界面截图和功能勾选会迅速过期。DORA 用变更前置时间、部署频率、失败部署恢复时间等指标描述软件交付能力，也说明软件产品的竞争不只发生在某个静态版本，还发生在持续改进与恢复能力上。 因此，软件竞品分析应以一条端到端工作流为基本单位。 例如，比较几款企业知识助手，不能只看是否支持问答、模型名称和连接器数量。更值得比较的是： 谁能把现有资料接入系统； 权限能否沿用，敏感内容会不会越权出现； 用户能否得到带来源、可检查的答案； 找不到答案时，系统如何暴露不确定性； 团队怎样纠错、补充和维护知识； 退出产品时，数据与配置能否迁移。 一项功能只有进入完整流程，才会成为用户价值。软件比较至少要进入以下层面。 1. 时间到价值：多久拿到第一次可信结果 从注册到第一次获得可信结果，需要多少配置、导入、培训和跨部门协调？一个能力强但部署三个月的产品，未必能赢过当天即可进入工作的较简单方案。 2. 工作流适配：省下的时间有没有转嫁给别人 产品是否嵌入用户已经使用的工具、角色和审批关系？如果节省了个人五分钟，却给管理员增加了权限维护，或者迫使上下游重复录入，它可能只是把成本转移了。 3. 数据与上下文：用户积累的状态能不能带走 软件会逐步积累文档、历史、规则、模板、成员关系和自动化配置。这些状态既构成产品价值，也构成迁移成本。分析必须看清用户要带走什么、重新配置什么、丢失什么。 4. 协作与治理：谁使用、谁购买、谁会否决 面向组织的软件，购买者、管理员、使用者、安全团队和财务往往不是同一个人。个人觉得好用，不代表组织能够部署；组织容易采购，也不代表一线愿意改变习惯。 5. 可恢复性：失败后能否继续工作 自动化是否可暂停、撤销、审计和重放？外部系统异常、模型出错或权限变化时，用户能否理解发生了什么并恢复工作？失败处理常常比成功演示更能解释长期留存。 软件竞争要看谁能以更低成本进入真实工作流，承接用户已有状态，并在持续变化中保持可靠。某个版本多一个功能，很难单独决定结果。 四、硬件竞品分析：比较的是一个被交付到现实世界的系统 硬件也有功能与规格，但它首先是一个物理系统。 它需要在特定重量、体积、功耗、散热、材料、结构、成本和生产条件下工作。每增加一项能力，都可能改变其他部分。更大的电池增加续航，也可能增加重量和充电时间；更高性能带来更强能力，也可能带来温升、噪声和成本；更轻的结构可能影响强度、维修方式和寿命。 所以硬件参数不能逐项独立“拉满”，竞品分析必须进入系统包络与真实环境。 NASA 的系统工程方法区分验证与确认：前者检查产品是否符合设计要求，后者确认产品在预期环境中是否满足预期用途。这个区别对消费硬件同样重要。实验室里达到某项指标，不代表用户在日常环境里能完成任务。 硬件比较至少还要增加六层。 1. 物理体验 重量分布、握持、佩戴压力、噪声、温度、材质、按钮位置和安装空间，很难被一串规格完整表达。它们必须在代表性的时间、动作和环境中体验。 2. 约束耦合 不要分别问“续航是否更长”“性能是否更高”，而要问产品在目标体积、重量、温度和价格下，能否持续完成任务。系统表现比单点峰值更重要。 3. 批量一致性与可靠性 媒体评测的一台工程样机不能代表用户收到的每一台量产机。材料、供应商、装配、运输和环境差异都会影响结果。NIST 对制造生命周期的描述覆盖设计、工艺规划、生产工程、制造、使用与服务、报废和回收，也提醒分析不能停在样机阶段。 4. 安装、学习与维护 是否需要上门安装、空间改造、耗材、校准、清洁和定期维护？用户买下的不只是设备，还接受了一套长期行为。 5. 渠道、库存与服务 产品在哪里试用和购买，多久到货，故障后是换新、寄修还是上门，备件能供应多久？FTC 对消费品保修的说明把覆盖期限、维修范围、处理流程和运输成本都列为购买时应检查的内容。售后本身就是硬件长期价值的一部分。 6. 全生命周期成本 购买价格只是起点，还要计算配件、耗材、订阅、维修、闲置、残值和替换周期。对于企业硬件，还可能包括部署、培训、场地、安全和停机成本。 硬件竞争要把足够一致、可靠、可维护的系统交付给大量用户，并对它的整个生命周期负责。最好看的样机，只完成了很前面的一步。 五、同一个词，在软件和硬件里不是同一种证据 软件和硬件可以共享比较框架，但证据不能直接套用。 比较维度 软件产品 硬件产品 基本比较单位 端到端工作流 现实环境中的系统任务 产品状态 数据、配置、权限、历史与集成 设备、固件、配件、环境与服务系统 迭代方式 可持续部署，版本快速变化 设计冻结、验证、生产与库存形成长周期 性能证据 真实数据下的完成率、延迟、错误与恢复 代表性环境、时长和批次下的持续表现 失败处理 回滚、重试、人工接管、审计 安全降级、停机、维修、召回或更换 切换成本 数据迁移、集成重做、培训与流程改变 购买、安装、空间、配件、折旧与旧设备处置 一致性 不同账号、权限、数据与版本 不同批次、部件、装配与使用环境 交付能力 部署、运维、支持与持续改进 供应链、良率、渠道、库存与售后 使用周期 可以持续改版，用户状态不断累积 设备在外多年，维护承诺跨越多个版本 主要替代 通用工具、人工流程、内部系统、捆绑功能 旧设备、不同形态设备、人工服务、租赁与不购买 这里最容易犯的错误，是用软件思维分析硬件：看到原型可用，就认为产品已经成立；或者用硬件思维分析软件：看到某版功能较少，就认为竞争结论已经固定。 智能硬件还要多做一层交叉检查。它的体验可能依赖 App、云服务、模型和订阅，但物理载体无法像软件一样随时改版。分析既要看硬件生命周期内的软件是否持续可用，也要看软件升级是否会被算力、电池、连接和旧设备所限制。 六、把参数表放回正确的位置 参数表要保留，但生成顺序需要改变。 第一步：先画出当前流程 记录用户从触发需求到完成结果的每一步，包括等待、切换工具、人工补救、失败和放弃。没有流程，就不知道参数在哪一步产生价值。 第二步：按选择逻辑建立竞品集合 每个方案都要说明为什么进入或退出比较：是否重叠了目标用户、触发情境、任务、预算、渠道、流程或风险。不要仅凭外形和品类名称纳入。 第三步：从真实决策推导指标 把指标分为三类： 门槛项：不满足就不会被选择； 差异项：能够明显改变结果或成本； 低敏感项：容易展示，但很少改变选择。 只有观察到的行为或明确决策依据，才适合给出权重。证据不足时，精确到小数点的评分只是在制造确定感。 第四步：把每个主张标成事实、推断或假设 事实来自官方资料、实测、交易、行为观察或可归属访谈；推断是对多个事实的解释；假设则必须进入验证。找不到的数据应标为未知，而不是填入一个看似合理的估算。 第五步：用代表性任务做并行测试 软件要用同一组真实数据、权限和上下游完成整条流程；硬件要在相同环境、时长、动作与维护条件下完成同一任务。测试成功路径，也测试中断、错误和恢复。 第六步：最后才压缩成表格 这时参数表不再是一份资料汇总，而是决策模型的摘要。每一行都能追溯到用户任务，每一个结论都有证据或明确的不确定性。 七、两种产品，应该做两种最小验证 竞品分析最后必须进入可证伪的测试，否则它只是一套漂亮解释。 软件：验证用户是否愿意迁移一条真实流程 选择少量代表用户，把真实数据、权限和协作关系带入产品，连续完成一个高频任务。观察：首次价值时间、独立完成率、人工修正、失败恢复、团队采用，以及用户是否愿意把下一次任务继续交给产品。 如果优势只在演示数据里成立，一接入真实权限就消失；如果个人效率提高，但组织部署成本超过收益；如果试用后仍回到原工具，原有差异化就应被推翻。 硬件：验证用户是否愿意在真实环境里持续使用 使用接近量产状态的设备，在代表性的空间、温度、网络、时长与动作中完成任务。观察：成功率、舒适性、误操作、清洁与维护、故障恢复、他人影响，以及数日或数周后的持续使用。 如果优势依赖实验室条件；如果续航提高却因重量让用户提前摘下；如果功能成立但安装、维修或服务成本无法承受，同样应该停止强化纸面参数。 两种验证都在回答同一件事：用户感知到的结果，是否真的大于完整的切换成本与风险。 结语：参数表应该是结论，不是起点 竞品分析的对象，从来不只是竞争公司的产品，而是用户面前所有能够完成任务的选择。 软件要比较工作流、数据、协作、治理、迁移与持续交付；硬件还要比较物理体验、约束耦合、批量一致性、生产交付、维护与售后。智能硬件则要同时处理两套逻辑，不能只看 App，也不能只看机器。 一份能进入决策的竞品分析，最终应当回答四个问题： 哪类用户在什么情境下会考虑切换； 他今天使用的方案是什么； 新产品在哪个完整任务上产生了可感知、可信的优势； 什么证据会证明这个判断错了。 先回答这四个问题，再打开参数表。 延伸资料 DORA：Software delivery performance metrics DORA：Continuous delivery NASA Systems Engineering Handbook NASA：Systems Engineering Handbook Appendix NIST：Current Standards Landscape for Smart Manufacturing Systems FTC：Businessperson’s Guide to Federal Warranty Law" },{ "id": "article-/en/notes/ai-native-basic-unit/", "kind": "article", "lang": "en", "title": "After AI-Native: The Basic Unit of a Product Has Changed", "topic": "agent-systems", "url": "/en/notes/ai-native-basic-unit/", "summary": "An AI-native product isn't a traditional editor with a chat box attached. It reconstructs product state — from pages, files and layers toward semantic objects, tasks, relationships and operation history.", "published": "2026-08-13", "translation_of": "/notes/ai-native-basic-unit/", "related": ["software-capabilities","video-production","playable-content"], "text": "Open any traditional editor and you first meet a set of stable basic units. Word processors revolve around pages and paragraphs; presentation software around slides and elements; design tools around canvases, frames and layers; video editors around footage, tracks and timelines. When AI entered software, many products simply added a chat box beside the existing interface: the user makes a request, the model generates content, the result is dropped back into the page, slide or timeline. The AI is still operating on the old product’s basic units. The change has to go deeper: The basic unit of a product is shifting from pages, files, layers and features toward semantic objects, relationships, tasks and operation history that both people and machines can understand. Pages and files won’t disappear; they remain the most familiar media for reading, editing and delivery. But in an AI-native product they become different views of the same state. Why traditional editors are built around files, pages and layers Traditional editors’ basic units were designed for direct human manipulation. A page suits reading and printing; a slide suits presentation; a layer suits selecting and stacking objects; a timeline suits temporal order. These structures map onto software objects: Notion’s API represents page content as lists of blocks; Figma’s API, as a tree of nodes. Traditional feature trees follow from it: Select text, change font size and style; Select a layer, adjust position and constraints; Select a clip, trim, change speed or add a transition; Select a slide, modify layout and animation. The problem: what users actually want rarely exists in these units. They want “make management understand why this project should continue” — not “create three pages” or “move five layers.” In the past, the product left the work of decomposing goals into operations to the human; now a machine can do it. AI exposes the state-representation problem Intent usually spans multiple objects — even multiple applications. “Turn this industry research into an investor deck,” for example, involves at least: Deciding which points matter most; Separating facts, inferences and assumptions; Restructuring the narrative for the audience; Choosing evidence and visual material; Generating pages and checking the logic across them; Revising in response to feedback. If the underlying state only knows text boxes, coordinates and pages, even a model that understands the task cannot write its understanding back: it may know “this is a core claim,” while the system stores “a text box at the top-left of page 3.” So an AI-native product must answer a more fundamental question than generation: does the product have a data structure that can express intent, semantics, relationships and task state? The new first layer: semantic objects and relationships A semantic object is not an extra tag wrapped around content; it means the product understands each object’s identity within the task. The same text can be a heading, a claim, evidence, a counterexample, a quote or an unvalidated assumption; the same image can be source material, evidence, background or a mood reference; the same video can be an event, an action, an interview point or a rhythm node. These objects need relationships: Which evidence supports which conclusion; Which shot corresponds to which narration; Which narrative role each slide plays; Which design component serves which state; Which change came from which piece of user feedback. Product domain Traditional operational unit Semantic unit AI needs to understand Documents Pages, paragraphs, characters Claims, evidence, citations, audience, to-dos, decisions Presentations Slides, text boxes, images Narrative nodes, page roles, argument relationships, visual assets Video Footage, clips, tracks, timecodes People, events, actions, points, emotion, shot purpose Design Frames, layers, components User tasks, interface states, design intent, constraints The right-hand column is not an industry standard but a modeling direction: not an all-encompassing knowledge graph, but the minimal semantic set needed to complete the core task. The new second layer: tasks and result contracts Semantic objects answer “what’s in the product”; tasks answer “what is being changed now.” Traditional software defines actions clearly: create, delete, move, export. AI products need a higher layer — the task: goal, inputs, tools, permissions, constraints, results, acceptance and failure handling. “Generate five slides” is a set of actions; “let someone new to the project understand the problem, the plan and the risks within five minutes” defines the result. A complete task should contain at least: Goal: the change to produce; Objects: the content and state to operate on; Constraints: facts, styles, formats and boundaries not to break; Tools & permissions: what may be read and modified; Acceptance: how completion is judged; Exception handling: insufficient evidence, tool failure, conflicts. Today’s agent infrastructure is building this layer: MCP exposes standardized Tools and Resources, and agent frameworks emphasize tool calling, guardrails, tracing and execution. But “connected to tools” is only a necessary condition: the product must translate user goals into executable, checkable result contracts. Without one, an agent can only judge “what I did”; with one, it can judge “whether the thing got done.” The new third layer: operation history, evidence and provenance When AI can modify many objects at once, “undo one step” stops being enough. The product needs to record who proposed what goal and when; which materials and tools the AI used; which objects were created, deleted or modified; which conclusion came from which source; what is original content and what is model inference; what the user accepted or corrected. If the system only saves final pixels, users can’t judge whether a result is trustworthy; if it saves object-level diffs, provenance and an operation log, they can compare versions, roll back locally, audit evidence, and turn effective changes into rules for the next task. Editors will stay — but their role becomes a View Since agents can complete tasks directly, editors and GUIs will disappear — a common misconception. They won’t: people still need to scan the whole, compare alternatives, refine locally, make aesthetic judgments, handle exceptions and give final confirmation. They no longer each need their own fragmented “truth.” The same semantic objects can be presented as a document, slides, a whiteboard diagram, a web page, or a video script and timeline. The GUI shifts from being the only operation entry point to three roles: State feedback: showing people what the AI understood and changed; Fine-grained control: letting people handle the local problems models handle poorly; Exceptions and confirmation: conflicts, high-risk actions and final acceptance. Why adding a chat box isn’t enough If every task starts from a fresh conversation, the system faces several problems: Context scattered across message history, hard to maintain; Users can’t tell which version the model relies on; Multiple people and agents can’t collaborate around one state; No object-level diffs; Memory accumulates but can’t be checked or deleted. The cleaner division of labor: conversation proposes intent and explains results, tasks manage execution, semantic objects carry state, operation history records changes, and the editor handles browsing, control and confirmation. Chat is one entry point, not the product. Migration won’t happen in one step Most mature products cannot abandon their file formats, user habits and ecosystems. AI-native will more likely pass through three stages. Stage one: AI actions inside the old editor The model rewrites, generates, completes, classifies and edits locally; the underlying state remains files, pages, layers or timelines. Core metrics: does a single capability save time, and is the result controllable? Stage two: a semantic layer, synced bidirectionally with existing objects The product begins recognizing people, claims, materials, tasks and relationships. AI operates on semantic objects; the interface maps changes back to pages and layers; manual edits sync back into the semantic state. The hardest part is not generation quality — it is identity consistency, synchronization, conflict, permissions and user trust. Stage three: semantic and task state become the primary state Files and editors become multiple views; one task spans documents, presentations, designs and external tools; agents collaborate over shared objects, permissions and operation history. This is still a long-term projection: it holds only if the product genuinely needs cross-medium tasks and the semantic layer’s benefits outweigh its complexity. Roadmaps and metrics change too If the basic unit changes, so does how product teams measure progress. Old roadmaps are feature-based: add a generation entry point, support a format, ship a model. AI-native products should track: Which complete tasks are reliably covered; Task completion rate and the cost of human correction; Whether key objects and relationships are correctly recognized; Whether provenance and evidence are complete; Whether large-scale changes are inspectable and reversible; Whether the same state stays consistent across views; Whether users hand the same task to the system again. Generation quality still matters. It is just one part of task completion. Conclusion: the basic unit determines what the product becomes Traditional editors were built around direct human manipulation, which is why pages, files, layers and timelines became their basic units. AI can understand higher-level intent and operate on many objects at once; to absorb that capability, products must re-express their own state — a chat box beside the old interface is only the first step. Not every product needs agents, and not all content needs an elaborate semantic graph. The practical test: If the user’s core task spans multiple pages, objects and tools, and the AI needs to keep understanding goals, relationships and history, then the product should elevate task and semantic state to first-class objects. Pages will still exist, files will still be delivered, editors will still be used — but increasingly as windows through which people observe and control product state, not the state itself. References Notion API: Block object Figma Developer Docs: REST API and node structure Model Context Protocol: Architecture overview Model Context Protocol: Tools OpenAI: New tools for building agents" },{ "id": "article-/notes/ai-native-basic-unit/", "kind": "article", "lang": "zh-CN", "title": "AI Native 之后，产品的基本单位变了", "topic": "agent-systems", "url": "/notes/ai-native-basic-unit/", "summary": "AI Native 产品不只是给传统编辑器增加聊天框，而是把产品状态从页面、文件和图层，逐步重构为语义对象、任务、关系与操作历史。", "published": "2026-08-13", "translation_of": null, "related": ["software-capabilities","video-production","playable-content"], "text": "打开一款传统编辑器，用户首先面对的总是几种稳定的基本单位。 文字处理软件围绕页面和段落，演示软件围绕幻灯片和元素，设计工具围绕画布、Frame 和图层，视频编辑器围绕素材、轨道和时间线。 这些单位不仅决定了用户看到什么，也决定了产品如何存储信息、组织功能、设计菜单、分配权限和保存版本。 AI 进入软件之后，很多产品先在原有界面旁边增加一个聊天框：用户提出要求，模型生成内容，再把结果放回页面、幻灯片或时间线。 这当然有价值，但此时 AI 仍在操作旧产品的基本单位，产品架构并没有随之改变。 变化还要继续往下走： 产品的基本单位，正在从页面、文件、图层和功能，转向可被人和机器共同理解的语义对象、关系、任务与操作历史。 页面和文件不会消失。它们仍然是人最熟悉的阅读、编辑和交付介质。但在 AI Native 产品中，它们更可能成为同一份状态的不同视图，而不再是产品唯一的真实状态。 这是一种正在发生的方向性变化，还不是已经完成的行业共识。要理解它，先要看传统产品为什么会以今天的方式组织。 一、传统编辑器为什么以文件、页面和图层为中心 传统编辑器的基本单位，是为人的直接操作设计的。 页面适合阅读和打印；幻灯片适合逐页演示；图层适合选择、移动和叠放视觉对象；时间线适合控制素材在时间上的先后关系。 这些结构也很容易映射为软件对象。Notion 的公开 API 将页面内容表示为 Block 列表，每个 Block 可以是段落、标题、图片或其他类型；Figma 的公开 API 则把文件表示为一棵 Node 树，页面、Frame、文字和图形都以不同节点存在。 这类对象模型非常适合确定性编辑：用户选中一个对象，执行一个命令，界面立即给出结果。 传统软件的功能树也由此形成： 选择文字，修改字号和样式； 选择图层，调整位置和约束； 选择视频片段，裁剪、变速或添加转场； 选择幻灯片，修改版式和动画。 问题是，用户要完成的事情，往往不以这些单位存在。 用户想要的可能是“让管理层理解为什么项目应该继续”“把这段采访剪成一条观点清楚的短片”“找出报告中证据不足的结论”，而不是“新建三页”“移动五个图层”或“剪掉第 37 秒到第 42 秒”。 过去，产品把目标拆解为操作的工作留给了人。AI 出现之后，这部分工作第一次可以由机器承担。 二、AI 把状态表达问题暴露出来 在传统编辑器中加入生成能力，最容易解决的是局部动作：改写一段文字、生成一张图片、补一页 PPT、移除一段视频背景。 但用户的意图通常跨越多个对象，甚至跨越多个应用。 例如，“把一份行业研究做成给投资人的演示”至少包含： 判断哪些观点最重要； 区分事实、推断和假设； 为目标受众重组叙事； 选择证据和视觉材料； 生成页面并检查前后逻辑； 根据反馈继续修改。 如果产品底层只认识文本框、坐标和页面，模型即使理解了任务，也很难稳定地把理解写回产品状态。 它可能知道“这是一条核心论点”，但系统只保存了“第 3 页左上角的一个文本框”；它可能知道某张图是在支撑市场规模，但文件只记录了图片的位置和尺寸；它可能知道某个镜头属于人物转折，却只能通过时间码重新查找。 因此，AI Native 产品除了生成内容，还要回答一个更底层的问题：产品是否拥有一种能够表达意图、语义、关系和任务状态的数据结构。 三、新的第一层：语义对象与关系 语义对象不是给所有内容再包一层标签。它要让产品理解每个对象在任务中的身份。 同一段文字可以是标题、论点、证据、反例、引用或待验证假设；同一张图片可以是素材、证据、背景、产品示意或情绪参考；同一段视频可以是事件、人物动作、采访观点或节奏节点。 这些对象还需要关系： 哪条证据支持哪个结论； 哪个镜头对应哪段旁白； 哪页幻灯片承担什么叙事角色； 哪个设计组件服务于哪个状态； 哪项修改源于哪条用户反馈。 可以把这种变化理解为：产品从“保存对象长什么样”，进一步走向“保存对象是什么、与什么有关、为什么存在”。 产品领域 传统操作单位 AI 更需要理解的语义单位 文档 页面、段落、字符 论点、证据、引用、受众、待办与决策 演示 幻灯片、文本框、图片 叙事节点、页面角色、论证关系与视觉资产 视频 素材、片段、轨道、时间码 人物、事件、动作、观点、情绪与镜头目的 设计 Frame、图层、组件 用户任务、界面状态、设计意图与约束 右侧还不是统一的行业标准，而是一种产品建模方向。不同品类会有不同对象，重点也不在建立一个包罗万象的知识图谱，而在找到完成核心任务所需的最小语义集合。 四、新的第二层：任务与结果契约 语义对象回答“产品里有什么”，任务则回答“现在要改变什么”。 传统软件把动作定义得很清楚：新建、删除、移动、导出。AI 产品还需要定义更高一层的任务：目标、输入、工具、权限、约束、结果、验收与失败处理。 “生成五页 PPT”是一组动作；“让第一次接触项目的人在五分钟内理解问题、方案和风险”才定义了任务结果。 一份完整的任务至少应包含： 目标：要产生什么变化； 对象：操作哪些内容与状态； 约束：哪些事实、风格、格式和边界不能破坏； 工具与权限：允许读取和修改什么； 验收：怎样判断任务完成； 异常处理：证据不足、工具失败或存在冲突时怎么办。 今天的 Agent 基础设施正在补这一层。MCP 通过标准化的 Tools 和 Resources，让模型能够读取外部上下文并调用系统能力；Agent 开发框架则越来越强调工具调用、Guardrails、Tracing 和执行过程。 但“接上工具”只是必要条件。产品还要把用户目标翻译成可执行、可检查的结果契约。 没有结果契约，Agent 只能判断“我做了什么”；有了结果契约，它才可能判断“事情是否做成”。 五、新的第三层：操作历史、证据与来源 当 AI 可以一次修改大量对象，传统的“撤销一步”会变得不够用。 产品需要记录： 谁在什么时候提出了什么目标； AI 使用了哪些材料与工具； 哪些对象被创建、删除或修改； 哪个结论来自哪个来源； 哪部分是原始内容，哪部分是模型推断； 用户接受、拒绝或手工修正了什么。 这些记录同时关系到安全、协作和学习。 如果系统只保存最终像素，用户很难判断结果是否可信；如果系统保存对象级 Diff、来源和操作记录，用户就能比较版本、局部回退、审核证据，并把有效修改沉淀为下一次任务的规则。 因此，AI Native 产品中的“历史”要同时记录文件版本，以及任务、对象、证据和操作之间的关联。 六、编辑器会留下，但角色会变成 View 一种常见误解是：既然 Agent 能直接完成任务，编辑器和 GUI 就会消失。 这并不成立。 人仍然需要浏览全局、比较方案、局部精修、组织空间、做审美判断、处理例外并完成最终确认。文字、画布、幻灯片、网页和时间线，仍然是非常高效的人机界面。 变化在于：它们不必再分别拥有一份彼此割裂的“真相”。 同一组语义对象，可以被呈现为： 一篇完整文档； 一组演示页面； 一张白板关系图； 一个网页； 一条视频脚本与时间线。 不同 View 负责不同任务。文档适合线性阅读，白板适合空间组织，幻灯片适合演示，时间线适合精确控制节奏。 GUI 也会从唯一的操作入口，转为三种角色： 状态反馈：让人看见 AI 理解了什么、改变了什么； 精细控制：让人直接处理模型不擅长的局部问题； 例外与确认：处理冲突、高风险动作和最终验收。 所以，AI Native 会把界面从唯一的功能入口，逐步变成状态反馈、精细控制和协作确认的界面。 七、为什么只加聊天框不够 聊天是表达开放意图的高效方式，但它不是完整的产品架构。 如果每次任务都从一段新对话开始，系统会面临几个问题： 上下文散落在历史消息里，难以持续维护； 用户不知道模型当前依据的是哪一版内容； 多人和多个 Agent 难以围绕同一状态协作； 修改结果缺少对象级 Diff； 记忆持续累积，却无法被结构化检查和删除。 更清楚的分工是：对话负责提出意图和解释结果，任务负责管理执行，语义对象承载状态，操作历史记录变化，编辑器负责浏览、控制与确认。 聊天只是入口之一，不是产品本身。 八、迁移不会一步完成 大多数成熟产品不可能抛弃原有文件格式、用户习惯和生态。AI Native 更可能经历三个阶段。 阶段一：在旧编辑器里增加 AI 动作 模型完成改写、生成、补全、分类和局部编辑。底层状态仍然以文件、页面、图层或时间线为主。 这一阶段的核心指标是：单点能力是否节省时间，结果是否可控。 阶段二：建立语义层，并与原有对象双向同步 产品开始识别人物、论点、素材、任务和关系。AI 操作语义对象，界面把变化映射回页面和图层；用户的手工修改也同步回语义状态。 这一阶段最难的是身份一致性、同步、冲突、权限和用户信任，生成质量只是其中一部分。 阶段三：语义与任务状态成为主状态 文件和编辑器变成多个 View；同一任务可以跨文档、演示、设计和外部工具完成；Agent 围绕共享对象、权限和操作历史协作。 这仍然是一种长期推演。它能否成立，取决于产品是否真的需要跨介质任务，以及建立语义层的收益是否高于复杂度。 九、产品路线图和指标也要改变 如果基本单位改变，产品团队衡量进展的方式也会变化。 过去常见的路线图以功能为单位：增加一个生成入口、支持一种格式、上线一个模型。 AI Native 产品更应该追踪： 能稳定覆盖哪些完整任务； 任务完成率和人工修正成本； 关键对象和关系是否被正确识别； 来源与证据是否完整； 大规模修改是否可检查、可回退； 同一状态能否在多个 View 中保持一致； 用户是否愿意把同一任务再次交给系统。 生成质量仍然重要，但它只是任务完成的一部分。 结语：基本单位决定产品会长成什么 传统编辑器围绕人的直接操作建立，页面、文件、图层和时间线也因此成为产品的基本单位。 AI 可以理解更高层的意图，也可以一次操作多个对象。要承接这种能力，产品需要重新表达自身状态，旧界面旁边的聊天框只是第一步。 并非所有产品都要做 Agent，所有内容也不必进入一套复杂的语义图谱。 更实用的判断是： 如果用户的核心任务跨越多个页面、对象和工具，而 AI 需要持续理解目标、关系和历史，那么产品就应该把任务与语义状态提升为第一层对象。 页面仍会存在，文件仍会交付，编辑器仍会被使用。 但它们会越来越像人观察和控制产品状态的窗口，而不是产品状态本身。 延伸资料 Notion API：Block object Figma Developer Docs：REST API 与 Node 结构 Model Context Protocol：Architecture overview Model Context Protocol：Tools OpenAI：New tools for building agents" },{ "id": "article-/notes/agent-left-embodied-right/", "kind": "article", "lang": "zh-CN", "title": "Agent 向左，具身向右：AI 在信息空间与物理世界的分岔", "topic": "agent-systems", "url": "/notes/agent-left-embodied-right/", "summary": "AI Agent 与具身智能都在从生成内容走向完成任务，但一个改变信息状态，一个改变物理状态，因此会沿着不同的产品和产业路线发展。", "published": "2026-08-13", "translation_of": null, "related": ["agent-context","robot-industry"], "text": "把 AI Agent 和具身智能放进同一个故事，很自然。模型越来越强，AI 开始理解环境、规划步骤、调用工具，也开始替人完成任务。 故事讲到这里，往往会再往前推一步：具身智能是 Agent 的下一站，机器人就是给 Agent 装上一副身体。 这个推论忽略了两类系统行动后果的差异。 两者都在从“生成内容”走向“采取行动”，但它们行动的对象不同： Agent 主要改变信息世界的状态；具身系统直接改变物理世界的状态。 改变的状态不同，错误能否撤销、系统如何评测、安全责任如何划分、产品怎样部署、公司如何规模化，也会随之分岔。 这一区分，决定了两套不同的产品与产业逻辑。 一、它们为什么看起来像同一股浪潮 Agent 与具身智能确实拥有一段相似的过去。 在信息世界，自动化先从脚本和固定规则开始。RPA 按预先配置的步骤点击界面，传统软件按照明确流程处理输入。模型能力提升之后，Copilot 开始参与局部工作；再往前一步，Agent 可以理解目标、选择工具、执行多步操作，并根据结果继续调整。 在物理世界，自动化也曾主要依赖固定程序和结构化环境。工业机器人在确定的位置、节拍和安全边界内重复动作；后来，视觉感知、学习控制和策略模型逐步提高了系统处理变化的能力。RT-2 把视觉、语言与机器人动作放进同一模型，Open X-Embodiment 则尝试通过跨机器人数据提高策略的迁移能力。Google DeepMind 后续发布的 Gemini Robotics，也把泛化、交互和灵巧操作列为机器人模型的关键能力。 两条路线的共同变化是： 环境不再需要被完全预定义； 系统开始理解自然语言和多模态上下文； 系统不只给出建议，还会选择并执行动作； 动作之后会读取反馈，再决定下一步。 因此，从模型能力看，它们确实越来越相似。Agent 调用 API，机器人调用运动控制器；Agent 读取网页和数据库，机器人读取摄像头、深度信息和关节状态；两者都需要规划、记忆、工具和反馈。 但共同的模型能力，不等于共同的产品规律。 二、分岔点：AI 到底改变了什么 Agent 处理的通常是文件、代码、消息、日程、数据库、账户和业务流程。它执行一次操作，改变的是某个数字系统里的状态。 具身系统处理的是位置、姿态、物体、空间、能量和人与设备之间的安全关系。它执行一次操作，改变的是现实世界中的状态。 这一区别最先体现在错误上。 一封邮件发错了，可能还能补充说明；一段代码写错了，可以回滚；数据库被错误修改，可能通过日志和备份恢复。数字世界当然也存在不可逆操作——例如转账、公开发布和数据删除——但软件通常能够通过权限、沙箱、版本、日志和人工审批，把高风险动作单独隔离出来。 物理世界的错误更难被抽象掉。机械臂碰坏一个物体，损失已经发生；移动机器人撞到人，不能靠“重试”恢复；设备因为电量不足停在危险位置，问题不只是任务失败，还可能引入新的风险。 两条路线的分岔发生在这里：系统是否直接承担现实世界中的不可逆后果。 这也解释了为什么一个在 Benchmark 上表现很好的模型，并不自动等于一个可以持续交付的机器人产品。模型只是物理闭环中的一层，传感器、状态估计、控制、结构、执行器、能耗、安全、维护与异常恢复必须同时成立。 三、两条路线会沿八个维度越走越远 维度 AI Agent 具身智能 / 机器人 主要操作对象 文件、消息、代码、账户、数据库与业务状态 位置、物体、空间、能量与人的安全边界 错误可逆性 多数操作可回滚、重试、补偿或转人工 物理后果可能即时发生，部分错误不可逆 复制与扩张 软件可快速分发，同一套能力服务大量用户 每增加一个执行单元，都要生产、部署和维护实体设备 数据闭环 操作日志天然产生，反馈成本相对较低 真实数据采集昂贵，且受本体、环境和任务差异影响 评测环境 可以用测试集、沙箱、历史任务和数字孪生反复运行 必须面对真实摩擦、遮挡、磨损、时延和环境长尾 安全与权限 重点是数据、账户、合规、越权与错误执行 还要处理碰撞、力、稳定性、故障与人身安全 部署与运维 版本可以集中更新，问题能够快速回滚 涉及硬件版本、备件、充电、维修、现场支持与寿命 单位经济 主要受推理、软件服务和人工复核成本影响 还要承担 BOM、制造、渠道、库存、售后与现场服务 这张表并不意味着 Agent 一定简单，机器人一定缓慢。 金融、医疗、企业核心系统里的 Agent 同样可能面临很高的错误成本；扫地机这类高度收敛的机器人产品也已经实现大规模商业化。但不能用一条路线的速度和成功标准直接推断另一条路线。 四、Agent 向左：竞争会落到任务交付 当基础模型逐渐成为可替换的公共能力，Agent 产品的差异不会只来自“模型更聪明”，而会越来越多地来自它是否真的接入了一套任务系统。 一套可用的 Agent，至少要解决五件事。 1. 它是否理解任务，而不只是理解一句提示词 “生成一份报告”不是完整任务。还要说明报告给谁看、支持什么决定、使用哪些材料、哪些信息不能使用、什么结果算完成，以及失败后如何处理。 更长的 Prompt 解决不了这些问题。Agent 需要一份清楚的结果契约。 2. 它能访问什么，又不能访问什么 工具越多不等于能力越强。Agent 一旦接入邮件、代码库、支付、客户数据和内部系统，权限边界就会成为产品的一部分。 低风险操作可以自动执行，高风险操作需要确认；只读、建议、起草、提交和正式执行，应当是不同权限等级。 3. 过程是否留下可检查的状态变化 一个可靠的 Agent 不应只给出最终答案，还应该让用户知道：它读取了什么、依据什么做出判断、改变了哪些对象、哪些步骤失败、哪里需要人工介入。 这也是为什么当前的 Agent 开发框架开始强调工具、Guardrails、Tracing 和可观测性。产品需要管理的是整条任务执行链，而非一段对话。 4. 错误能否被发现、回滚和补偿 Agent 的优势不只是自动化，还包括数字世界可建立版本、Diff、日志、沙箱和审批机制。产品应主动利用这些特性，而不是让模型直接操作所有系统。 5. 人在什么时候接管 Human-in-the-loop 不应是一句模糊的安全口号。产品必须明确：什么置信度继续执行，什么动作必须确认，出现什么异常立即停止，用户如何快速理解现场并接管。 因此，Agent 的长期竞争更像“任务交付系统”的竞争：谁拥有更完整的上下文、更合理的工具与权限、更清晰的结果契约，以及更低成本的异常处理。 五、具身向右：竞争发生在持续可靠的物理闭环 具身智能当然也需要更好的模型，但模型能力必须进入一条更长、约束更多的系统链路。 一个机器人完成任务，至少要连续处理： 感知环境 → 判断状态 → 理解意图 → 规划动作 → 控制执行 → 检查结果 → 处理异常。 任何一环不稳定，最终任务都可能失败。 机器人面对的是一个持续变化的世界，远比一张静态图片复杂。物体会滑动，人会突然进入，光照会改变，地面有摩擦差异，传感器会被遮挡，执行器会发热，电量会下降，零件会磨损。 这也是为什么机器人安全天然需要分层。高层模型可以理解任务和语义风险，但底层仍需要碰撞避免、接触力限制、动态稳定和针对具体本体的安全控制。Google DeepMind 在 Gemini Robotics 的公开说明中也明确把低层安全控制与高层语义理解分开处理。 对于具身产品，一次 Demo 成功远远不够。更有意义的指标包括： 在明确环境里，连续多少次可以完成任务； 遇到哪些变化会失败，失败是否可恢复； 多久需要人工介入一次； 一次任务的时间、能耗和服务成本是多少； 设备在数周、数月使用后是否仍保持可靠； 出现故障时，用户和服务团队能否快速定位与修复。 因此，具身智能早期更适合从边界清楚的窄任务长出来：环境相对清晰、任务重复、价值足够高、失败可以被安全处理。先把一个物理任务稳定做成，再逐步扩大环境和任务边界，通常比一开始追求“通用机器人”更接近产品现实。 六、商业化速度不能互相套用 Agent 产品可以通过软件快速分发。一次能力更新，可以同时服务大量用户；新工具能够通过 API 接入；任务数据也会在使用中持续产生。 机器人每扩大一份收入，往往需要多生产、交付和维护一台设备。规模增长会同时带来制造、供应链、现场部署、维修和客服压力。即使模型可以在线升级，身体仍然受到既有传感器、算力、结构和执行器的限制。 两类产品的验证顺序也不同： Agent 更容易先验证“有没有人愿意把任务交给它”； 机器人必须同时验证“任务有价值、系统做得到、长期交付得起”； Agent 的早期瓶颈常是信任、接入与组织采用； 机器人的早期瓶颈还包括可靠性、成本、生产与服务。 所以，不能因为 Agent 在几个月内进入大量工作流，就推断通用机器人会以相同速度进入家庭和企业；也不能因为机器人商业化更慢，就认为它的长期价值更低。 它们只是受到不同的约束。 七、两条路会合流，但不会重新变成一条路 未来很多完整任务会同时包含信息行动和物理行动。 例如，一套现场巡检系统中，Agent 可以读取工单、理解设备历史、规划任务、调度机器人、整理异常证据并生成报告；机器人负责移动、观察、测量和现场操作。 两者能否协作，取决于一份清楚的任务协议： 目标是什么； 允许采取哪些信息与物理动作； 成功、失败和异常分别如何定义； 哪些条件必须停止； 什么时候请求人工接管； 最终需要留下什么证据。 Agent 与机器人会协作，但仍由两套不同的工程、产品和运营系统支撑。前者负责理解、协调和管理信息状态；后者负责安全、可靠地改变物理状态。 八、这一区分如何改变产品判断 判断一个 Agent 产品，可以先问： 它替用户完成的是哪一段真实工作，而不是生成什么内容？ 它需要接入哪些数据、工具和权限？ 什么结果算完成，如何评测？ 哪些动作可以回滚，哪些必须审批？ 人工介入发生在哪里，成本是多少？ 判断一个具身产品，则应继续问： 它在什么环境、面对什么对象、完成什么高频任务？ 当前本体和模型能否形成持续闭环，而不只是完成一次演示？ 最危险、最常见和最昂贵的失败分别是什么？ 设备如何充电、维护、恢复和升级？ 把制造、部署和服务算进去后，单位经济是否成立？ 如果不先区分信息行动与物理行动，我们很容易高估模型能力的迁移速度，也容易低估产品仍需补齐的系统能力。 结语：两条路，两套产品规律 Agent 与具身智能共享模型、自然语言、多模态和规划能力，也会在越来越多任务中彼此连接。 但它们不会收敛成同一种产品。 Agent 向左，进入更深的信息上下文、工具权限与组织工作流；具身向右，进入更复杂的物理环境、可靠性、安全与交付系统。 一条路的核心问题是：AI 能否可信地替人改变信息状态。 另一条路的核心问题是：AI 能否安全、持续、经济地改变现实世界。 这两条路都很重要。判断它们时，应该先看各自能否持续交付任务，而不是把每一次模型进步都装进同一个“AI 下一站”的故事。 延伸资料 OpenAI：New tools for building agents Anthropic：Building effective agents Google DeepMind：RT-2 将视觉与语言转化为机器人动作 Google DeepMind：Gemini Robotics brings AI into the physical world Open X-Embodiment：Robotic Learning Datasets and RT-X Models" },{ "id": "article-/notes/hardware-innovation-organization-management/", "kind": "article", "lang": "zh-CN", "title": "国内硬件产品创新：组织与管理方法", "topic": "organization", "url": "/notes/hardware-innovation-organization-management/", "summary": "硬件创新团队如何从少数核心成员出发，逐步建立产品、系统、项目、供应链和规模化经营能力。", "published": "2026-08-05", "translation_of": null, "related": ["hardware-innovation","organization-responsibility"], "text": "一、硬件组织为什么不能照搬互联网 讨论硬件公司的组织方式，要先区分产品的交付方式和变更成本；互联网公司的组织经验不能直接照搬，硬件企业之间也有很大差异。 可以先按产品与业务形态分成四类： B 端软件产品； 互联网服务； 传统硬件； 智能化、高复杂度硬件。 先修正一个常见误解： B 端软件不一定是“卖断一套软件”，也可能采用订阅制、SaaS 或私有化部署；互联网公司也不只提供免费服务。决定组织方式的，是产品如何交付、多久能够修改、客户关系如何建立，以及失败的代价有多高。 1. 四种产品形态的主要差异 产品形态 主要交付方式 变更节奏与代价 组织管理重点 B 端软件 订阅、SaaS、私有化部署或项目交付 可以持续更新，但受到客户环境和交付承诺约束 产品能力、解决方案、实施交付与客户成功 互联网服务 在线服务，持续面向用户运营 变更快、回滚相对容易，可以用线上数据验证 小团队、快速实验、数据反馈与持续发布 传统硬件 实体产品、渠道与售后服务 周期长，许多决策在量产后难以修改 前期定义、阶段冻结、供应链、质量与库存 复杂智能硬件 硬件、软件、算法和服务共同交付 硬件慢、软件快，两套节奏长期并存 系统工程、跨专业协同、阶段门与持续运营 2. 软件与硬件的关键差异：变更成本 软件可以通过自动化测试、持续集成和持续交付，将需求拆成小批次，快速发布和获取反馈。DORA 将保持软件随时可部署、自动化测试和小批次变更视为高效软件交付的重要能力。 硬件则存在大量不可逆或高成本决策： 芯片和传感器选型； 结构和尺寸； 模具； 材料和工艺； 认证； 长周期物料； 备货和库存； 生产线和测试设备。 因此，互联网服务更倾向于：小团队、快速实验、持续发布、用线上数据验证。 传统硬件更倾向于：前期充分定义、阶段冻结、集中验证、批量生产。 3. 智能硬件为什么最难管理 智能硬件同时存在两套节奏。 硬件节奏 半年到数年的产品周期； 关键方案需要提前冻结； 依赖器件、模具、认证和产能； 错误修改成本高。 软件与算法节奏 周或月级迭代； 上市后持续更新； 需要行为数据和用户反馈； 能够通过灰度和版本控制降低风险。 智能硬件需要同时保留传统硬件的阶段管理和互联网团队的持续迭代，再由系统工程统一架构： 硬件阶段门＋软件持续交付＋系统工程统一架构。 NASA 的系统工程体系将系统负责人定位为连接用户期望、系统架构、需求分配、接口管理、技术权衡以及验证确认的关键角色。这一机制对机器人、汽车、无人机等复杂软硬件产品尤其重要。 二、创始人如何塑造早期组织 在创业公司前两三年，正式流程、岗位体系和组织文化都还没有建立。 此时公司实际采用的管理机制，往往来自创始人的个人工作方式： 创始人信什么； 什么问题会亲自介入； 对产品、技术、商业分别有多高要求； 如何看待速度、质量和成本； 是否容许团队挑战自己； 遇到争议时依靠数据、专家还是个人判断。 早期公司的管理风格，往往就是创始人工作方式在团队中的延伸。 分析创始人时，不能只贴上“强势”“佛系”或“技术型”等性格标签。可以沿着下面这条路径看： 创始人的核心优势 → 形成的组织能力 → 带来的管理盲区 → 需要补充的角色和机制。 1. 技术发明型创始人 典型特征 从底层技术或科研成果出发； 对技术路径和产品性能判断较强； 更相信 Demo、实验和工程结果； 早期决策集中在创始人及少数专家； 倾向招聘技术能力强、能够解决难题的人。 大疆早期具有明显的技术与产品工程驱动特点。汪滔长期强调产品质量、工程能力和对关键技术的投入；随着组织扩大，其公开访谈也开始反思，仅依靠产品和个人判断不足以解决监督、文化与组织治理问题。 组织优势 技术判断集中； 攻坚速度快； 能吸引高水平工程和科研人才。 主要盲区 容易高估技术本身的用户价值； 用户、市场和商业验证不足； 创始人成为所有技术和产品决策的瓶颈； 对项目、供应链和组织建设投入较晚。 必须补充的角色 强 Product Owner； 用户与市场洞察负责人； Program Owner； 供应链和 NPI 负责人。 补充这些角色不是为了削弱技术创始人；公司还需要回答“值不值得做”和“能不能稳定交付”，不能只判断“能不能做出来”。 2. 产品使命型创始人 典型特征 对公司最终解决什么问题有清晰执念； 产品形态可以变化，但核心价值相对稳定； 擅长提出方向和产品原则； 更关注用户最终获得的结果，而不是单项技术。 比如，理想汽车创始人李想提出的“车和家”，直接表达了公司的产品理念。 组织优势 公司方向容易形成一致； 产品选择具有连续性； 不容易被短期功能和竞争对手带偏； 可以根据技术成熟度调整产品形态。 主要盲区 创始人的产品叙事可能代替用户真实需求； 产品形态频繁变化，导致团队不断重做； 团队容易理解愿景，却不知道当前阶段具体交付什么； “长期正确”可能掩盖短期产品不成立。 必须补充的机制 分阶段产品假设； 清晰的当前版本边界； 用户、市场和交易验证； 明确的停止条件； 每一阶段只能验证有限数量的核心问题。 使命可以长期稳定，但产品形态和资源投入必须经过阶段性证据验证。 3. 用户场景型创始人 典型特征 对具体用户和使用场景高度敏感； 经常亲自体验产品； 直接接触用户、渠道和供应商； 从用户工作流而不是参数表定义产品； 产品、市场和供应链距离较近。 影石刘靖康公开表达过将产品重心放到更广泛的真实场景，并被供应商评价为会亲自参与供应链会议；其产品演进也长期围绕拍摄、剪辑和分享的完整任务链。 组织优势 用户问题发现得早； 产品容易形成完整工作流； 市场、研发和供应链之间距离短； 迭代速度快。 主要盲区 创始人个人体验可能代表性不足； 容易追随高频用户反馈增加功能； 创始人亲自下场过多，会成为组织瓶颈； 用户导向可能压缩平台和长期技术建设。 必须补充的机制 对用户进行分层； 区分事实、解释与决策； 建立反证研究； 设置产品范围 Owner； 将创始人的场景判断整理成用户研究和产品方法，而不是依赖创始人亲自体验。 4. 经营与组织型创始人 典型特征 强调业务模型、组织效率和资源配置； 善于设计业务单元； 重视目标、激励、人才密度和经营结果； 希望将成功从个人能力转化为可复制机制。 华为的 IPD 强调从机会到商业变现，并要求产品线管理覆盖研发、生产、交付、服务和生命周期，而不是把产品线等同于研发部门。 安克公开采用由产品线负责人领军的最小化业务单元，并围绕多品类发展建立前线产品线和平台能力；阳萌的公开复盘也显示，其关注点逐步从亲自解决产品问题转向战略、组织、人才和能力建设。 组织优势 容易形成规模化经营； 产品线责任清晰； 人才获得独立负责业务的空间； 资源配置与商业结果结合。 主要盲区 容易过早用收入和毛利判断创新项目； 对长期技术和设计投入耐心不足； 组织机制成熟，但产品洞察可能弱化； 过度授权可能导致产品线重复建设。 必须补充的机制 前瞻技术预算； 产品和设计专业权力； 公司级平台； 长周期项目单独评价； 对创新项目采用不同于成熟业务的考核方式。 5. 创始人风格不能被直接复制 创始人的个人能力不应成为所有员工的行为模板。它要转化为： 个人判断 → 产品原则 → 责任分工 → 评审与数据机制 → 可复制的组织能力。 企业成长需要把创始人少数可复制的正确判断变成制度，同时用不同类型的人弥补创始人的盲区。 在成熟公司内部创新中，发挥类似作用的不一定是创始人，也可能是事业部负责人或业务赞助人。例如道通 AI 事业部这类内部新业务，其组织风格更多取决于分管高管如何定义战略、资源和产品责任。 三、创新项目如何设计最小核心团队 创新团队最常见的错误有两个： 人太少，只能做技术 Demo，无法验证产品； 人太多，产品尚未明确就提前建立完整部门。 MVP 阶段，团队要用最少的人覆盖最关键的未知问题，并保证每个关键决策都有明确 Owner。 1. 创新团队首先要判断三类风险 产品价值风险 用户是否真的需要； 产品是否解决了重要问题； 用户是否愿意改变现有行为。 技术与系统风险 核心技术是否可行； 性能、功耗、尺寸和成本能否同时成立； 软件、算法和硬件能否集成。 交付与商业风险 是否能够生产； 供应商和器件是否可获得； 售价、成本、渠道和服务是否成立。 最小团队必须覆盖这三类风险，而不能全部由研发人员构成。 2. 0—1 阶段的最小核心团队 对于中等复杂度智能硬件，建议核心团队保持在 6—10 个关键角色。一个人可以兼任多个角色，不等于一开始招聘十个人。 关键角色 主要责任 Business Owner / 创始人 战略方向、资源承诺、商业边界和最终取舍 Product Owner 目标用户、核心场景、产品范围和价值验证 System Owner 系统架构、指标分解、接口与技术权衡 R&D Owner 关键技术实现、工程质量和研发计划 Design Owner 工业设计、交互体验、设计原则与样机还原 Program Owner 集成计划、关键路径、风险、变更和决策升级 供应链与 NPI Owner 器件、供应商、试制、成本和量产可行性 用户与市场负责人 用户证据、竞争判断、价格与上市验证 最小团队的四条原则 第一，按照风险配置人员，而不是按照部门配置。 如果核心风险是算法，就优先招聘算法专家；如果核心风险是光学、结构或供应链，就优先补充相应角色。 第二，一个关键领域只能有一个 Owner。 多人参与不代表多人共同负责。 第三，核心团队必须可以直接做出原型。 创新团队不能主要依赖汇报、外包管理和会议。 第四，创始人不能同时长期承担所有 Owner。 创始人早期可以兼任业务、产品甚至项目负责人，但在进入工程开发前，至少需要分离产品、技术和项目三类责任。 四、创新团队的组织演进 团队应当随着产品阶段演进。 第一阶段：证明产品值得做，而且基本做得出来 典型规模 核心团队：6—10 人； 扩展研发、供应商和外部合作人员：10—25 人。 组织特点 创始人直接参与产品和技术； 角色高度重叠； 不设置复杂部门； 产品、设计和技术共同做原型； 供应链以验证和试制为主； 项目管理轻量化。 这一阶段需要交付 明确目标用户和核心场景； 形成可演示的体验原型； 验证最大的技术风险； 获得早期用户或客户证据； 形成初步成本和供应链判断； 明确继续、调整或停止。 最容易犯的错误 把技术 Demo 当成产品验证； 一开始就追求完整功能； 过早招聘大量执行人员； 没有明确停止条件； 所有决策都等待创始人。 第二阶段：从“做出样机”转向“做出可以量产的产品” 典型规模 核心团队：15—30 人； 完整项目团队及供应商：30—80 人。 必须新增的能力 独立 Product Owner； 独立 System Owner； 专职 Program Owner； 结构、硬件、软件和算法模块负责人； 供应链、采购和 NPI； 测试、质量与可靠性； 产品市场和上市准备。 组织变化 从“人盯人”变成“Owner 负责”：每个子系统和关键结果有明确责任人。 从“口头判断”变成“产品和系统基线”，明确： 当前版本做什么； 系统架构是什么； 关键指标是什么； 如何验证。 从“快速改”变成“渐进式冻结”，依次冻结： 用户价值； 产品范围； 系统架构； 工业设计； 生产方案。 从“外包执行”变成“管理供应链”：公司需要掌握产品定义、系统架构、关键技术和质量标准，不能将核心判断外包给 ODM 或供应商。 第三阶段：从一个项目转向可重复的产品组织 典型规模 产品与研发核心组织：40—100 人； 包含供应链、制造和外部合作的完整体系可能更大。 规模不是目标。只有当公司同时面临量产、下一代产品、软件运营和多个项目时，才需要进入这一阶段。 必须建立的结构 产品线负责： 产品组合； 用户与市场； 收入和毛利； 生命周期。 专业职能负责： 工业设计； 系统工程； 软件和算法； 硬件和结构； 项目管理； 质量和 NPI； 人才与专业标准。 平台团队开始积累： 通用硬件模块； 软件平台； 算法基座； 账户、云和数据； 设计语言； 供应链和测试能力。 创始人的角色也随之变化： 阶段 创始人的主要责任 0—1 亲自判断方向、产品原则和关键技术，尽快验证最大不确定性 工程与量产 选择并授权 Product、System、Program 等关键 Owner，守住产品边界和资源承诺 多产品与规模化 决定战略、组织、人才和平台投入，不再成为所有项目的日常决策点 组织演进总结 阶段 核心问题 组织关键词 主要产出 0—1 产品是否成立 小核心团队、角色兼任、快速原型 用户证据、体验原型、技术可行性 工程与量产 产品能否稳定交付 Owner 分工、系统基线、渐进冻结 可量产设计、质量标准、供应链方案 多产品与规模化 成功能否复制 产品线、专业职能、平台团队 产品组合、复用能力、持续经营 五、成熟硬件组织的基本结构 当团队从创新项目逐步发展为稳定的产品组织后，通常会形成三条较稳定的组织线。 1. 业务与产品线 负责： 市场和用户策略； 产品组合； 收入、毛利和库存； 价格、渠道和生命周期。 2. 专业能力平台 负责： 用户研究； 产品管理； 工业设计、UX 和 CMF； 系统工程； 结构、硬件、软件和算法； 供应链、NPI、质量和可靠性； 人才、标准与模块复用。 3. 跨职能项目组 围绕具体产品组建，负责从产品定义到量产上市。核心团队至少包括： 责任线 关键角色 产品价值 Product Owner、用户研究、产品市场 系统与研发 System Owner、各软硬件与算法模块 Owner 体验 Design Owner、工业设计、UX、CMF 集成交付 Program Owner、测试、质量、可靠性 供应链与量产 采购、供应链、NPI、制造 人员实线汇报给专业部门，在项目中围绕产品目标协同。 六、产品从洞察到量产的工作方式 完整生命周期可以分为七个阶段： 战略与产品组合； 用户和市场洞察； 产品概念； 正式立项； 系统架构与设计； EVT、DVT 和 PVT； 上市、经营与下一代产品。 1. 用户与市场洞察 洞察无法保证预测准确，只能通过多种证据降低误判。 关键结论应尽量同时具备： 市场和行业证据； 用户真实行为； 用户访谈和场景观察； 原型测试； 价格、预售或交易证据； 上市后的使用和留存数据。 用户策略需要具体到：谁，在什么场景下，遇到什么问题，使用什么替代方案，为什么会采用新产品，哪些人当前版本不服务。 市场策略需要具体到：品类、区域、价格带、渠道、竞争定位、销量、毛利和上市节奏。 2. 产品与研发的翻译机制 如果产品和研发长期衔接不顺，除了沟通问题，还要检查团队是否缺少 System Owner。 一条完整的转换路径是： 用户需要 → 产品要求 → 系统要求 → 子系统规格 → 验证标准。 每个关键需求都要明确： 来源； 使用场景； 目标指标； 优先级； 实现 Owner； 验证方式。 System Owner 负责整体架构、指标分解、接口和技术权衡，Product Owner 负责用户价值，R&D Owner 负责工程实现。 3. 对美感要求的翻译 产品负责人不能只提出“高级、简洁、有科技感”。 设计要求应沿着以下路径展开： 用户与环境 → 品牌和情绪目标 → 三至五条设计原则 → 形态与比例 → CMF 和交互 → 间隙、段差、阻尼、色差等工程标准 → Golden Sample → 量产验收。 产品负责人定义用户、品牌和产品意图；Design Owner 完成设计翻译；结构、NPI 和质量团队负责量产还原。 不同产品应匹配不同工业设计背景： 产品类型 设计能力重点 消费电子与穿戴设备 形态、比例、CMF、交互和日常使用体验 机器人、无人机与汽车 系统布置、结构约束、人机工程和运动状态下的使用 医疗与专业设备 安全、法规、清洁维护、信息可读性和误操作防护 工业与 B 端硬件 可靠性、环境适应、可维护性和长期操作效率 4. 项目管理的作用 项目经理负责管理系统集成，不只是催进度。 主要负责： 集成主计划； 关键路径； 跨部门依赖； 风险和问题； 变更； 阶段评审； 决策升级； 项目状态透明。 在互联网单产品团队中，项目管理可以相对轻量；在 B 端交付、传统硬件和复杂智能硬件中，项目管理的重要性逐步提高。 特别是复杂智能硬件，同时存在： 硬件开发节奏； 软件版本节奏； 算法和数据节奏； 供应商和制造节奏； 市场上市节奏。 没有 Program Owner，这些节奏很难自动对齐。 七、国内硬件公司的五种管理原型 管理原型 代表性做法 主要优势 需要警惕的问题 大疆式技术与工程驱动 核心技术集中投入，创始人深度参与产品和工程 技术攻坚、性能和质量 创始人瓶颈，市场与组织能力补得过晚 影石式用户场景驱动 围绕完整任务链定义产品，产品、市场和供应链距离近 场景洞察、工作流和快速迭代 高频反馈带来范围膨胀，平台能力建设不足 华为式系统与流程驱动 IPD、系统工程、阶段门和跨职能产品线 复杂系统集成和稳定交付 流程过重，不适合过早套在探索项目上 小米式平台与生态驱动 品类组合、平台能力和生态协同 多品类扩张和资源复用 品类间能力不一致，产品体验容易分散 安克式产品线经营驱动 最小化业务单元、产品线负责人和经营责任 责任清晰、规模化经营 过早用短期收入和毛利评价长期创新 创新团队不必一开始照搬任何一家企业，可以按阶段吸收不同做法： 0—1 阶段，学习大疆和影石： 强核心团队； 原型； 技术和场景验证； 创始人直接参与。 量产阶段，补充华为式机制： System Owner； Program Owner； 阶段门； 风险、变更和验证。 多产品阶段，引入小米和安克式结构： 产品线； 平台； 业务单元； 产品组合； 经营责任。 八、组织如何随产品成熟 硬件创新团队的组织建设要随着主要问题变化： 早期解决“产品是否成立”； 中期解决“产品能否量产”； 后期解决“成功能否复制”。 创始人在早期决定公司的产品品位、技术路线和决策方式，但企业不能长期依靠创始人本人运行。 组织成熟通常包括： 将创始人的优势转化为产品原则、技术标准和组织机制； 用不同类型的 Owner 弥补创始人的认知盲区； 从角色兼任走向责任分离； 从单一项目走向产品线和专业平台； 从个人判断走向证据、基线和阶段治理； 从做出一款产品走向持续产生产品。 智能硬件组织同时面对两类要求：硬件的系统、质量、供应链和长期承诺，以及软件的持续迭代、快速反馈和数据验证。 一家硬件公司能否持续推出产品，取决于组织能否反复完成下面这套循环，而不只取决于某项技术或某一款畅销产品： 发现机会 → 定义产品 → 完成跨专业翻译 → 稳定量产 → 持续运营 → 从市场中学习 → 进入下一轮创新。" },{ "id": "article-/notes/scene-user-demand-evidence-research/", "kind": "article", "lang": "zh-CN", "title": "如何从 20 万条反馈中形成可验证的需求判断", "topic": "product-research", "url": "/notes/scene-user-demand-evidence-research/", "summary": "从一个具体产品决定出发，设计五类证据来源，把每条材料整理成用户、场景、任务、替代方案、摩擦与后果，再用问题、方案、商业行为和反证四条链控制结论。", "published": "2026-08-04", "translation_of": null, "related": ["demand-evidence","evidence-maintenance"], "text": "过去一段时间，我先后做了三次大规模用户研究。 一次研究私有算力和本地 AI 设备，一次研究 AI 眼镜，一次研究空间显示、3D 与虚拟世界。研究对象、平台和行业语言差别很大，执行过程却反复遇到相同的问题：数据量迅速增长，能够支持产品决定的证据仍然不足。 其中一轮研究保留了 211,088 条符合初步条件的反馈，单一平台仍占 90.21%。AI 眼镜研究收集到 200,732 条原始记录，经过日期、正文完整性、相关性和去重筛选，进入主样本的只有 45,630 条。 这组经历促使我把研究过程重新整理成 SURE：Structured User Research with Evidence。它的核心分析单元是： 用户角色 × 场景与触发 × 任务与结果 × 当前替代方案 × 摩擦与成本 × 后果 × 证据等级 这次更新把方法拆成两种对外版本： 这篇文章面向研究者、产品经理和创业者，解释每一步怎样做； User Demand Research Agent Skill 面向 Agent，提供固定目录、模板、执行协议和无第三方依赖的审计 CLI。 两者共用同一套证据模型。人类版负责理解和判断，Agent 版负责稳定执行与交接。 下面用一个贯穿案例说明完整流程： 一家公司正在判断，是否值得为现场维修工程师制作 AI 眼镜远程指导原型。 文中的示例记录和数字只用于说明方法，不代表真实行业结论。 先看最终产物 一项完整研究结束时，产品团队需要拿到一组可回查的文件： repair-guidance-study/ ├── study.json # 决策问题、假设、证伪条件和质量门槛 ├── 01-sources/source-plan.csv # 来源路线、证据角色、目标和已知偏差 ├── 02-data/ │ ├── raw/ # 原始或授权导入材料 │ ├── views/ # 配平后的分析视图 │ └── evidence.jsonl # 可被结论引用的证据记录 ├── 03-codebook/ │ ├── codebook.csv # 分类定义和版本 │ └── gold-set.jsonl # 人工校准样本 ├── 04-findings/demand-judgments.json # 需求判断、反证和下一项验证 └── 05-audit/ # 质量检查结果 其中最重要的产物是一条能够被复查的需求判断。例如： 对于需要双手操作设备的现场维修工程师，在复杂拆装步骤中取得准确指导是一项明确任务。目前常用手机、纸质手册或远程语音指导，操作中断与沟通往返会延长维修时间。现有材料已支持问题与替代方案证据；是否接受 AI 眼镜、谁愿意付费、能否持续使用仍待验证。 这段判断没有急着宣布产品机会。它写清了已经观察到的内容、证据能走到哪一步，以及下一步缺什么。 第一步：把研究题目改成一个产品决定 下面这种题目无法指导采样： 研究 AI 眼镜在维修行业的用户需求。 研究范围会不断扩张，任何材料都能被认为有关，最后很容易得到一份内容丰富但无法决定下一步的报告。 可执行的研究契约需要写清五项内容： 项目 维修案例中的写法 决策问题 9 月 30 日前决定是否制作现场维修远程指导原型 当前选项 做 AI 眼镜原型；继续优化手机方案；暂停该方向 目标角色 一线维修工程师、远程专家、采购负责人、IT 与安全审核者 最低证据 任务与替代方案、方案接受、付费或部署行为、拒绝与反例 禁止推断 不用便利样本估算市场比例，不把评论条数写成用户人数 每个核心假设还要配一个可观察的证伪条件。 假设： 维修工程师在双手被占用时，需要持续获得可视化指导。 证伪条件： 如果目标任务能够在 30 秒内用手机或语音完成，且概念测试中没有出现对免手持方案的明确接受，则停止当前形态的原型投入。 证伪条件提前写下后，数据才有机会改变决定。否则研究很容易成为对既有想法的补充材料。 第二步：按“材料能证明什么”设计来源 搜索 AI glasses、smart glasses 或 AR glasses，主要会找到产品用户、爱好者、评测者和发布讨论。它们适合研究已有方案的体验，却看不到大量没有使用产品词的任务。 维修工程师可能只会说： 拆机时需要反复停下来查手册； 远程专家看不到自己正在操作的位置； 戴手套时使用手机困难； 某些工厂禁止拍摄或外传数据； 当前语音加图片的办法已经够用。 因此，来源计划应覆盖五类证据角色。 证据角色 维修案例中可以寻找的材料 主要回答的问题 直接方案反馈 AI 眼镜、远程协作设备、企业部署反馈 方案哪里可用、哪里失败、接受条件是什么 开放场景 维修论坛、工单复盘、培训社区、操作规程讨论 用户在什么时刻完成什么任务 替代与拒绝 手机视频、平板、纸质手册、语音指导、退货与拒绝部署 现有办法是否足够，为什么不换 购买后与支持 部署工单、设备故障、续航、网络、安全与维护记录 使用后能否稳定运行，成本落在哪里 对照样本 对手机或语音方案满意的团队、无需远程专家的任务 哪些场景缺少问题，哪些市场无需进入 来源数量不等于来源多样性。十个科技论坛可能仍然聚集着相似的人；五个平台上的发布评论也可能来自同一批产品爱好者。 研究计划需要为每条路线标明：它承担哪种证据角色、目标记录数、单一路线占比上限、访问状态和已知偏差。 一旦替代与拒绝样本为空，继续增加产品社区评论无法修复缺口。此时应更换搜索入口，或明确写出当前结论缺少反证。 第三步：先试采集，再决定是否扩量 正式采集前，先从每条路线取得一小批材料。试采集的目标是判断路线质量，数量根据平台和材料形态确定。 每条路线至少记录以下结果： 指标 它帮助判断什么 触达记录数 路线的大致规模 正文完整率 能否保留上下文和原话 筛选后有效率 这条路线是否值得继续投入 唯一主题或产品数 是否被一个热门讨论支配 重复率 转帖、搬运和相同回复是否过多 E3–E5 产出 能否找到方案接受、付费和持续使用证据 拒绝与对照产出 能否看到产品不成立的情况 时间集中度 是否受到一次发布、故障或争议影响 访问限制 是否遇到登录、验证码、403、429 或平台限制 假设某条产品发布评论路线取得 500 条记录，却有 70% 来自同一个发布周，且几乎没有退货、部署和长期使用材料。这条路线适合观察发布反应，不适合承担长期需求判断。 当一条路线无法提供它被分配的证据，应重新设计路线。研究者需要保留失败和被阻断的来源，避免后来的人把数据空白理解成“没有问题”。 平台数据怎么接：先审开源代码，再决定能不能抓 这套系统采用一组可以检查、修改和替换的开源连接器。连接器负责把平台数据送进统一格式，研究方法负责采样、判断与审计。 但“GitHub 上有代码”和“这条路线可以用于研究”是两件事。选择一个开源项目，要连续通过四道检查： 检查 需要回答的问题 代码 有没有明确许可证，能否固定到具体 commit，依赖是否可审计 访问 实际使用官方 API、公开数据集，还是模拟登录、内部接口和网页抓取 数据 这项研究能否保存、刷新、删除和使用返回的数据 研究 输出是否保留讨论串、对话、视频、商品变体或项目等关键层级 MIT 许可证只回答第一道问题。它允许怎样使用代码，不会自动授予平台访问权，也不会自动授予评论和用户内容的再利用权。 截至 2026 年 8 月 27 日，我把审查结果整理成下面这张表： 平台 可复用的 GitHub 项目 当前结论 适合做什么 Reddit PRAW 可用，但需要获准的 Reddit Data API 访问；现有 API 应用须在 2026 年 9 月 30 日前登记，长期将迁移到开发者平台 帖子、评论、讨论串和 subreddit 路线 X Tweepy 可用，但必须走官方 X API 历史/近期检索、对话、回复、引用和转发 YouTube Google API Python Client 可用，但受 Data API 配额与数据规则约束 视频检索、频道与视频信息、评论线程和回复 Amazon AmazonReviews2023 只适合历史研究 截至 2023 年 9 月的评论、ASIN、评分、购买验证和商品信息 另外一些项目代码本身并不差，却不能进入默认采集链路： X 的 snscrape 和 twikit使用非官方抓取或内部接口，而 X 当前规则要求官方 API； YouTube 的 youtube-comment-downloader 和 youtube-transcript-api都绕开了 Data API，而 YouTube 当前政策禁止直接或间接取得抓取数据； 京东的 JD_comment_spider多年未更新，仍依赖旧的直连接口； 淘宝的 taobao-review-playwright需要扫码登录、保存登录态并模拟用户操作； Kickstarter 的 KSInsights保留了结构化数据，但仓库最新快照停在 2025 年，数据又来自网页爬虫。 这些项目被保留在“已审查、不可启用”的清单中。这样做很重要：下一个 Agent 再次搜索 GitHub 时，能直接看到此前的判断和原因，不会因为项目有星标、最近更新或 MIT 许可证就重新启用。 社媒平台：连接器相同，样本结构不同 三个社媒平台仍然共用一条研究流程： 确定证据角色 → 选择通过审查的开源连接器 → 固定代码版本和访问依据 → 建立平台检索路线 → 小批量试采集 → 保存采集 manifest 与平台层级 → 整理成 SURE 证据记录 → 检查集中度 → 用独立来源验证 每次采集都要生成一份 manifest，记录连接器、固定 commit、许可证、访问依据、数据权利、检索式、请求/触达/写入数量、配额、警告和停止原因。API 密钥、Cookie 和账号信息不能写进 manifest。 Reddit：把社区和讨论串当成样本结构 使用 PRAW 不代表可以无限取数。研究仍需先确认 API 用途、速率、保留和删除规则。每条路线至少记录： subreddit × 检索主题 × 原始检索式 × 排序 × 时间范围 × 帖子/评论 × 历史/监听 2026 年 8 月，Reddit 公布了公共 Data API 的调整计划：已有的 API 应用必须在 2026 年 9 月 30 日前完成登记，新的自助申请入口已经关闭、改为审批制，长期方向是迁移到开发者平台。对研究系统的含义是：已经持有获批访问的研究可以继续用 PRAW，但没有获批凭据的研究要把 Reddit 记为访问缺口，而不是换成抓取工具。 同一个问题应分别观察 relevance、new、top 等视图。热门排序适合发现重要讨论，时间排序更接近近期基线。十个 subreddit 仍然属于 Reddit 这一个来源家族；同一讨论串里的五十条评论也不能写成五十次独立市场确认。 X：把转发和事件扩散从需求中拆开 Tweepy 负责调用官方接口，研究文件还要保留： 检索主题 × Boolean 检索式 × recent/full-archive × 起止时间 × 语言 × 原帖/回复/引用/转发 原帖、回复和带新文字的引用可能包含新的证据；单纯转发主要说明传播，只能作为 E0 注意力信号。一次发布会在一天内产生大量转发，不能据此得出需求突然扩大。X 研究要同时检查唯一对话数、转发占比和单日记录占比。 YouTube：先抽视频，再抽评论 YouTube 研究先决定哪些频道和视频进入样本，再决定每个视频读取哪些评论。频道可以分成产品评测、任务与职业、替代与批评、部署与支持、主流对照五组；每个视频设置评论上限，避免一条爆款视频决定全部结论。 官方 commentThreads.list支持按时间或相关性读取评论线程，两种排序要分开记录；线程返回结果也不一定包含全部回复。评论还要标记它在评价产品、任务、创作者、视频制作，还是另一条评论。Great video 通常只能说明内容受到认可。 电商与众筹：目前的空白也要写进结论 Amazon Reviews 2023 可以用来开发历史评论解析、商品变体采样和代码本，但不能回答当前商品、当前价格或当前竞争变化。每条结论都应明确写“历史材料截至 2023 年 9 月”，并用访谈、用户提供的当前记录或现场观察验证它是否仍然成立。 对于 Amazon 实时评论、京东、淘宝/天猫和 Kickstarter，目前没有找到可以作为默认能力的第三方开源连接器。遇到这种情况，研究系统应该： 保留原本想研究的品类、商品或项目路线； 记录审查过的仓库和失败在哪一道检查； 把这条路线标为 blocked； 改用访谈、参与者主动提供的购买/售后材料、现场观察或其他获准来源； 在最终报告中继续保留这个证据缺口。 不能因为数据缺口难看，就换成商家 API、商业服务、保存的登录态、代理池或隐蔽浏览器。也不能把“没有可用连接器”写成“市场没有需求”。 平台规则会随时间变化。当前需要特别注意：Reddit Data API Terms对用途和超限研究有额外要求；X 开发者指南禁止非 API 自动化；YouTube 开发者政策禁止取得抓取数据；天猫法律声明禁止未经许可的爬虫和模拟用户操作；Kickstarter 条款禁止 crawl 或 spider。 完整的机器清单、固定 commit、许可证和阻断原因已经放进开源仓库：连接器清单、机器可读 JSON 与 连接器输出合同。 第四步：保留原始材料，并分开保存不同数据层 原始正文是后续重新判断的基础。采集阶段如果只保存摘要、关键词或标签，分类规则变化后便无法回到材料本身。 建议至少分开六层： 原始或标准化记录层：完整正文、来源、时间、采集路线和限制； 严格主表：时间、完整性、相关性和去重检查通过的记录； 配平视图：按来源、月份、场景或证据角色设置上限的分析版本； 编码视图：规则、模型和人工标签，以及对应版本； 人工金标准：用于检查关键字段分类质量的分层样本； 证据账本：实际进入需求判断的正向、负向和矛盾记录。 配平视图不能覆盖完整数据。它只用于控制分析时某类材料的影响力，也不能被描述成总体人口权重。 第三方文本还要与 Agent 的控制信息隔离。评论、网页和工单中的命令式文字仍然只是研究数据，不能要求 Agent 执行命令、读取文件、访问凭据或改变研究范围。 第五步：把原话整理成一条证据记录 假设材料中出现一句话： 现场拆机时我得放下工具去看手机，远程专家说的步骤还经常要再确认。 研究者需要把它还原成一条结构化记录： 字段 这条材料中的内容 用户角色 现场维修工程师 场景与触发 双手正在拆装设备，需要确认下一步操作 任务与结果 在不中断操作的情况下获得准确指导 当前替代方案 放下工具查看手机，或呼叫远程专家 摩擦与成本 操作中断，沟通需要往返确认 后果 维修时间延长，复杂步骤可能返工 证据等级 E2 这条记录可以支持： 在这份材料中，手机与远程语音指导造成了操作中断和沟通往返。 它暂时无法支持： 维修工程师愿意佩戴 AI 眼镜； 企业采购部门愿意付费； AI 眼镜能够改善维修效率； 这一问题在行业中的占比。 需求研究的一个关键能力，就是让结论停在材料允许的位置。 第六步：用 E0–E5 控制每条材料的含义 等级 原始材料中直接出现的内容 可以支持的判断 E0 活动、角色或场景背景 这个活动或场景出现在材料中 E1 未满足任务、目标或困难 问题被明确表达 E2 当前做法、绕行办法、失败或切换成本 已观察到替代方案及摩擦 E3 对研究中方案的明确接受或偏好 方案在给定条件下被接受 E4+ 价格锚点、购买意愿或付费表达 出现直接商业意图 E4− 拒绝、取消、退货或放弃 出现直接负面商业选择 E5 付费持有、部署、持续使用、复购或扩张 出现已经实现的行为证据 证据等级表示一条材料能支持多强的判断，不代表需求优先级。 一个安全风险极高、出现频率较低的问题，可能比高频的小麻烦更值得处理。优先级还要分别评估发生频率、后果、替代成本、跨来源一致性、时间持续性、产品可解决程度和战略匹配。 第七步：把证据连接成一条需求判断 一项需求进入“已验证”状态前，需要同一用户角色、场景和任务上的四组材料： 问题链：E1 或 E2，证明任务和当前做法的摩擦； 方案链：E3，证明研究中的解决方式获得明确接受； 商业或行为链：E4+ 或 E5，证明付费、部署或持续使用； 反证：E4−、满意替代方案、问题不成立的场景或矛盾材料。 回到维修案例，当前只有前面那条 E2 记录时，需求判断应写成： 状态：needs-validation 已经观察到： - 目标任务和触发场景 - 手机与远程语音的操作中断 - 维修时间延长和返工风险 仍缺少： - 工程师对免手持方案的 E3 接受证据 - 采购、部署或持续使用的 E4+/E5 证据 - 安全、隐私、舒适度和现有方案满意者的反证 下一项低成本验证： - 用可点击原型和佩戴模型完成 8—12 次场景化概念测试 - 预先记录接受条件、拒绝原因和继续使用意愿 - 若多数目标任务仍需拿起手机，且出现明确 E3 接受，再进入短期现场试用 这里的 8—12 次 是示例中的概念测试规模，用于快速发现接受条件和明显拒绝原因，不是总体统计样本。 第八步：机器扩大阅读范围，人负责校准关键判断 几十万条材料需要规则或模型参与去重、候选场景发现、初步分类和复核排序。自动结果不能直接成为事实。 关键字段应建立人工金标准。抽样时覆盖： 不同来源家族； 不同月份和事件窗口； 五类证据角色； 正向、负向与中立材料； 高置信和低置信记录； 高频标签与稀有但后果严重的标签。 决策相关字段可以让两位标注者独立判断一部分记录。Cohen’s kappa 或 Krippendorff’s alpha 低于预设门槛时，先检查定义、边界和示例。更大的模型无法自动修复含糊的分类规则。 每条自动编码结果还应保留模型、提示词或规则版本、代码本版本、置信度和人工复核状态。来源结构发生明显变化后，需要重新校准。 第九步：在形成结论前完成一次质量审计 一份研究报告至少要公开以下信息： 原始记录数、严格主表记录数和配平视图记录数； 来源家族、平台、月份、事件窗口和唯一讨论的分布； 五类证据角色的覆盖情况； E0–E5 与拒绝证据的分布； 重复、正文缺失、日期不精确和无法追溯来源的比例； 人工金标准的关键字段表现； 被阻断或失败的来源路线； 当前材料明确不能支持的判断。 质量门槛应写进研究契约。下面是一组演示配置： 试研究最低有效记录：30 必须覆盖：五类证据角色 单一来源家族占比上限：65% 标准化文本重复率上限：2% validated 判断：必须包含反证记录 这些数字用于展示门槛怎样表达，不适合作为所有研究的统一标准。真实项目要根据决策风险、材料形态、来源可得性和时间窗口重新设定。 第十步：根据风险选择小样本或大样本路径 这套方法不要求每次都抓取几十万条数据。 小样本路径 适合已有明确用户、材料量较少或产品决定临近的项目： 完成研究契约； 从五类证据角色各找一批材料； 人工编码 30—100 条高相关记录； 形成 3—5 条需求判断； 直接进入访谈、观察、概念或价格测试。 大样本路径 适合跨行业场景发现、长期用户反馈、复杂品类或大量工单： 对每条来源路线做试采集； 保存原始层、严格主表和配平视图； 用规则与模型做开放发现和初步编码； 用人工金标准校准关键字段； 审计来源集中、时间事件、重复和证据角色； 将高优先级判断送入更便宜的直接验证。 两条路径的判断门槛相同。大样本增加了覆盖范围，也增加了偏差审计、数据治理和复现成本。 数据抓到什么时候可以停 研究应在开题时写下停止条件。可以考虑同时满足： 严格主表通过质量检查； 关键证据角色和目标市场没有无法解释的空白； 单一来源或事件窗口没有超过预设上限； 新增材料带来的新场景连续下降； 关键字段经过人工校准； 下一项产品决定已经能够在声明的置信度下作出； 继续采集的成本高于一次访谈、概念测试或现场试用带来的信息价值。 如果二十万条材料里没有拒绝者、满意替代方案、付费者和持续使用者，研究仍有关键缺口。继续增加同类评论只会让原有偏差更稳定。 今天就可以开始的 90 分钟版本 第一次使用这套方法，可以只完成 Design 阶段： 用 20 分钟写清决定、选项、负责人、时间和禁止推断； 用 20 分钟写三条核心假设，以及每条假设的证伪条件； 用 30 分钟为五类证据角色各列两条来源路线； 用 10 分钟设置试研究的重复、集中度和覆盖门槛； 用 10 分钟评审：这份计划能否主动找到拒绝、放弃和满意替代方案。 完成后再决定是否需要爬取大量数据。很多研究在这 90 分钟里就能发现，原计划只能接触产品爱好者，或根本没有准备商业与行为证据。 交给 Agent 执行 公开的 User Demand Research 仓库包含： 可安装的 $user-demand-research Skill； 研究契约、来源计划、代码本和需求判断模板； sure.py init 研究目录初始化命令； --platform reddit|x|youtube|amazon|jd|taobao|kickstarter 平台路线初始化参数和专用审计； 一份机器可读的 GitHub 开源连接器清单，包含固定 commit、许可证、可用状态与阻断原因； Design、Evidence 和 Full 三个阶段检查； 一套完整合成案例和自动测试。 Agent 版本采用 Skill + CLI。Skill 负责研究判断、安全边界和失败处理；CLI 负责目录、连接器选择、字段、重复、来源集中和证据链等确定性检查。每次平台采集还要留下 manifest，使下一个 Agent 能看见代码版本、访问依据、数据权利和停止原因。连接企业工单、数据库或获得授权的平台 API 时，可以再增加 MCP 适配器，研究数据合同无需改变。 安装后，可以直接要求 Agent： 使用 $user-demand-research，为“维修工程师是否需要免手持远程指导”建立研究目录。 先完成 Design 阶段，写明假设、证伪条件、五类证据来源和质量门槛； 通过 design check 后再给出试采集计划。 这套方法最后要解决什么 大规模反馈的价值，在于让低频、分散和高后果的问题有机会出现，也让研究者能够观察不同来源与时间中的稳定模式。 研究质量取决于更具体的事情：问题是否对应一个真实决定，材料是否承担了不同证据角色，原始记录是否可追溯，结论是否停在证据允许的位置，拒绝和满意替代方案是否进入判断。 当这些条件写进文件、门槛和交接协议后，研究才容易被复查、继续和推翻。数据量可以很大，也可以很小；每一条需求判断都应当说清自己从哪里来，还缺什么。" },{ "id": "article-/notes/waic-from-models-to-systems/", "kind": "article", "lang": "zh-CN", "title": "WAIC 之后：AI 产业开始为“把事做成”买单", "topic": "robotics", "url": "/notes/waic-from-models-to-systems/", "summary": "WAIC 2026 把一套新的评价标准推到了台前：交付率、连续运行、人工接管，以及完成一次任务的真实成本。", "published": "2026-07-23", "translation_of": null, "related": ["robot-industry","hardware-innovation"], "text": "过去半年，我用 iRead 持续跟踪 AI 应用、具身智能和 AI 硬件。到 7 月 21 日，本地资料库里已经积累了 23,930 篇文章，来自 112 个信源。WAIC 四天里，与大会直接相关的文章就有 166 篇。 这些材料反复指向同一个变化：产业判断一款 AI 产品的方式正在改变。 模型跑分、机器人动作和硬件参数依然重要，但客户已经开始追问更多：长期运行的表现如何，失败时谁来接管，一次成功任务究竟要花多少钱？ WAIC 2026 也反映了这个变化。行业还没有进入规模化收获期，却开始认真为“把事做成”买单。 WAIC 改变的是评价尺度 今年的展商结构很能说明问题。 据甲子光年的大会资料统计，WAIC 2026 有 1100 余家中外企业和 4000 余款展品。机器人与智能硬件相关企业有 242 家，算力、芯片与基础设施企业有 206 家。在大模型与生成式 AI 参展主体中，83 家把 Agent 或智能应用作为主要标签，基础大模型只有 18 家。 基础模型仍然重要。它正在变成整个产业的生产资料。企业接入一个强模型后，还要处理数据、权限、流程、评测、成本和组织改造，模型能力才能变成结果。 WAIC 上能看到三种很具体的变化： 芯片公司开始讨论有效 Token 的产量、能效和系统稳定性； Agent 公司不再满足于回答问题，开始对任务结果负责； 机器人和 AI 硬件离开聊天框，必须面对空间、功耗、安全与真实用户。 我更愿意把 2026 年看作系统交付开始受检验的一年。竞争单位正在从单个模型、单颗芯片和单台机器人，变成一套能够稳定完成任务的系统。 Coding 为什么站在这轮变化的最前面 Coding 是目前最接近“任务经济”的 AI 应用。原因很朴素：代码能编译，测试能运行，需求有没有完成可以被机器和人共同验证。 有了可验证的反馈，Agent 才能连续工作更长时间。它可以读代码、修改文件、运行测试、观察错误，再继续修正。设计、文档和视频创作当然也能用 AI，但“作品是否可交付”往往依赖人的审美和业务判断，反馈远没有代码清楚。 晚点聊 LateTalk 的 2026 年 Q2 季报解释了 Coding 的另一层意义：它既是眼下最明确的收入入口，也可能成为下一代 AI 的研发基础设施。 当长程 Agent 能够读论文、提出假设、写代码、跑实验并分析结果，Coding 除了帮助程序员提高效率，也开始进入 Auto Research。它甚至在尝试改进模型训练本身。 这条路径常被概括为： Coding + 长程 Agent → Auto Research → Recursive Self-Improvement RSI，也就是递归自我改进，是一个很容易被提前宣布成功的概念。当前公开证据更接近研究流程自动化和局部自我改进：AI 可以优化代码、实验工具、训练配方或 GPU Kernel，人仍在选择研究方向、判断结论是否新颖，并处理评测没有覆盖的失败。 刷高一个 Benchmark 只能证明一次局部优化。更能说明问题的是，同一套系统能否在不同任务上持续变强。到那一步，领先公司的优势才可能从“领先一个身位”变成“拥有更快的加速度”。 今天还没有足够证据证明通用 RSI 已经出现。但 Coding 正在让 AI 参与制造下一代 AI，这件事已经值得长期跟踪。 Agent 的难题已经进入组织内部 个人使用 Agent 时，失败一次通常只是多花几分钟。企业把 Agent 放进采购、财务、客服或研发流程后，错误可能意味着泄露数据、越权操作、错误付款或生产中断。 企业 Agent 因此需要三类上下文：公共知识、企业私有知识和组织运行规则。传统知识库只覆盖其中一部分。信息时效、访问权限、审批关系，以及任务失败后的中止与回滚，才是进入核心流程后的麻烦。 一批过去不太显眼的能力开始变得重要： Context：把分散的文档、业务对象和隐性经验整理成可调用的信息； Runtime：为长时间任务提供沙箱、浏览器、工具和资源调度； Evals：上线后持续检查结果质量； Governance：控制权限、预算、审计与人工接管。 WAIC 上，PPIO 披露 Agent 沙箱上线一年后业务规模增长 123 倍。这个数字来自公司口径，仍需要客户侧验证；访谈中提出的评估方式更完整：不要只看一次模型调用有多便宜，要把上下文、工具调用、失败重试和人工检查全部算进一次成功任务。 这也解释了为什么推理单价下降后，算力需求未必下降。Agent 会增加调用轮次和上下文长度。一枚 Token 变便宜了，一个任务消耗的 Token 却可能更多。 接下来，Agent 产品应优先看交付率、人工修改量、接管率和单位成功任务成本，而不是生成次数。 机器人开始谈“工作”，但还没有证明规模经济 WAIC 过去最容易传播的机器人内容，是跳舞、奔跑和翻跟头。今年的展台里，药房、仓储、汽车线束、光模块检测、零售货架和洗衣房明显多了起来。 AI 科技评论走访 100 多个机器人展台后，把变化概括为“应用展示取代功能表演”。几家公司的展示也开始接近生产问题： 银河通用把单次任务延长到 3 至 5 分钟； 它石智航展示柔性线束的精细插接； 乐聚披露标准工业场景可以在两周内落地； 极智嘉让人形机器人与原有仓储系统协同； 苏度用目标移动、视觉干扰和题库外任务测试在线反应。 这些演示比单纯表演有价值，但展台落地和工厂落地仍然是两回事。 虎嗅记录的一次泡茶演示花了约六分半，期间出现抓取失败、反复对齐、运行中后仰，还需要工程师协助。它没有说明机器人“做不到”，却清楚地展示了 Demo 与产品之间的距离。 机器人公司接下来应该公开另一套指标：付费部署数、连续运行小时、平均无故障时间、人工接管率、节拍、部署人数、维护成本和客户扩点。 一套系统成功 99 次、失败 1 次，听上去已经很好。但如果它每天要完成数万次动作，剩下的 1% 依然会变成大量异常。单次成功率离生产可用还有连续运行和失败恢复两道门。 具身智能需要什么样的数据 今年的具身论坛反复讨论数据。真机数据最直接，但慢且昂贵；人类第一视角数据更容易扩大规模，却需要解决人与机器人动作空间的差异；互联网视频数量巨大，缺少力、触觉和失败标签；仿真数据便宜可控，又绕不开 Sim-to-Real。 我不认为某一种数据会单独胜出。我更看好能把真机、人类示范、仿真和线上失败统一进训练与评测的公司：它们记录机器人为什么失败、如何恢复，以及下一版是否真的因此变好。 这和数字世界里的 Auto Research 有相似结构：执行任务，获得反馈，形成新数据，再更新系统。区别是，代码世界可以快速回滚，物理世界的失败会损坏设备、影响生产，甚至伤害人。 机器人可能成为 RSI 的另一类载体，但自主试错必须受到安全边界、仿真、真机评测和人工接管的约束。否则，所谓数据飞轮只是在更快地制造事故。 理查德·萨顿在 WAIC 谈“经验时代”时，把这一点说得很清楚：仅仅学习人类已有知识还不够，持续学习的智能需要通过行动、观察和奖励获得第一视角经验。与此同时，他也提醒听众，今天的 AI 仍然不可靠，会产生幻觉。这份演讲整理值得和热闹的机器人演示放在一起看。 AI 硬件争夺的是行动权 AI 手机、眼镜、耳机、戒指和陪伴硬件都在争夺持续感知入口。设备离用户越近，获得的上下文越连续，能够完成的任务也越多。 但一个系统可以读取相册、消息和位置，可以调用地图、订单和支付，意味着它也拥有了犯大错的权限。 AI 硬件需要先获得用户的长期授权，模型能力才有机会转化成产品价值。低风险任务可以自动完成，高风险操作应该交还用户确认；敏感数据尽量本地处理，复杂推理再进入云端；每一次关键操作还要能够审计和有限回滚。 阶跃在 WAIC 展示的 Agentic OS采用了类似思路。它还没有证明大规模量产和长期留存，但已经提出跨 App 操作之外的信任问题：操作能力需要建立在用户授权之上。 这场竞争也会重新分配服务入口。如果系统 Agent 只能打开 App，选择权仍在超级 App 手里；如果它可以替用户筛选、下单和支付，手机系统和模型公司就会重新获得分发权。AI 硬件能否成立，可能取决于模型、系统、供应链、渠道和服务生态能不能被组织成一件完整产品。 “强者愈强”只在一些条件下成立 领先模型公司确实拥有一套复利结构：更强的模型带来更多用户，更多使用产生更多失败样本和偏好数据，收入支持算力和人才，研发工具又帮助开发下一代模型。 Coding 是这套结构里很特殊的一环，因为它既产生收入，也提高研发效率。 但过去三年的模型竞争一直在交替领先。人才会流动，研究路线会变化，开源模型也在用成本和可控性进入企业。垂直公司如果掌握专用数据、领域评测和客户流程，仍然有机会在局部建立更强的系统。 产品能力也不会由模型分数自动生成。企业销售、权限治理、硬件量产、售后服务和客户关系，都需要另一套长期积累。 因此，我对“强者愈强”的判断是：收入、分发和研发效率会先集中，技术领先未必永久集中。只有当某家公司率先实现可迁移、可持续的 RSI，现有平衡才可能被真正打破。 未来半年，我会盯着这些数字 行业里不缺新概念，缺的是能跨季度比较的指标。未来 3 至 6 个月，我最关注下面几组数字： AI 应用与 Agent 一次成功任务的总成本； 结果直接进入生产的比例； 人工接管发生在哪一步，是否随使用下降； 续费和付费用户的实际使用深度。 具身智能 连续数百小时运行后的成功率； 抓空、遮挡、目标移动后能否自主恢复； 一个新工位需要多少数据、工程师和调试时间； 客户是否从单台试点扩展到多台、多工位。 AI 硬件 30 天和 90 天留存； 每台设备每月的云端推理成本； 高风险操作的确认率、误操作和隐私事件； 续航、发热、退货率和量产良率。 Auto Research 与 RSI 研究方向、实验设计和最终判断还需要多少人工； 同一系统能否在不同任务上重复产生改进； 结果能否被独立团队复现； 能力提升后是否重新完成安全回归测试。 这些指标可能没有发布会视频好看，却更接近产业进步。 2026：交付开始受检验，收获尚早 今年以来，我的资料库里，标题明确讨论 Agent 的文章占比从 1 月约 3.5% 上升到 6 月约 6.8%；具身智能与机器人长期保持在约 12% 至 14%；融资、估值和 IPO 讨论在 5 月、6 月明显升温。 这些数字只能反映注意力，不能代替收入和客户复购。资本热度已经跑在商业成熟度前面，大量产品仍停留在展会、试点和小批量部署阶段，公开指标也主要来自公司自己。 WAIC 2026 让行业开始用更严格的方式谈产品：Agent 要承担结果，机器人要接受节拍和稳定性检验，AI 硬件要处理权限与信任，算力要计算有效 Token 和单位任务成本。 接下来，能够留下来的公司会持续记录失败，把失败变成数据，再把数据变成更稳定、更便宜的交付。 AI 会什么，仍然重要。接下来更值得跟踪的是，哪些系统能长期、稳定地把事情做好。 关于这篇研究 本文基于 iRead 截至 2026 年 7 月 21 日采集的 23,930 篇文章、112 个信源，以及 WAIC 期间 166 篇专项材料整理，并整合了晚点聊 LateTalk《AI 季报 26Q2》的访谈观点。 文中涉及公司成功率、客户数、融资、性能和部署规模的数据，若无特别说明，均来自公司、媒体报道或访谈嘉宾，不能视为独立审计结果，也不构成投资建议。 延伸阅读： 甲子光年：WAIC 2026 大洗牌 AI 科技评论：走访 100+ 机器人展台 具身智能之心：数据、模型与具身智能的分歧 硅星人 Pro：AI 手机的真问题是信任 晚点聊 LateTalk：AI 季报 26Q2，从 Coding 到 RSI" },{ "id": "article-/notes/embodied-intelligence-beginners-guide/", "kind": "article", "lang": "zh-CN", "title": "具身智能入门地图：我怎样整理产业、公司与技术", "topic": "robotics", "url": "/notes/embodied-intelligence-beginners-guide/", "summary": "过去几个月，我从零开始学习具身智能，并把产业、公司、产品、技术与职业选择整理成一份 2026 夏季版入门地图。", "published": "2026-07-20", "translation_of": null, "related": ["robot-industry","world-models","manipulation-data"], "text": "过去几个月，我一直在系统学习具身智能。 开始深入这个领域后，我很快遇到一个问题：资料很多，却缺少阅读顺序。 今天看到人形机器人，明天看到四足机器人；刚理解 VLA，又遇到世界模型、强化学习、遥操作和合成数据。产品发布、融资新闻、演示视频、论文与产业报告每天都在增加，但它们讨论的往往不是同一层问题。 产品形态、应用场景、产业链、技术路线、公司竞争力和商业进展经常混在一起。看得越多，越容易记住零散名词，却仍然说不清这个行业的结构。 我此前长期做软件和 AI 产品，机器人对我也是一个需要从零理解的新领域。为了建立一张相对完整的地图，我花了三个多月整理公司资料、行业报告、论文、视频、播客和公众号文章，并尝试用同一套问题比较它们。 这些笔记后来变成了《具身智能入门：产业、公司、产品、技术与职业地图》。 先建立坐标，再判断公司和技术 我把具身智能看成一座还在建设中的城市。 刚进入这个领域时，很容易马上追问哪家公司最强、哪条技术路线会赢。但如果没有基本坐标，这些判断往往只是把融资、演示效果和技术名词放在一起比较。 我先回答几组基础问题： 产业链由哪些环节构成，每个环节解决什么问题？ 人形、四足、轮式双臂和固定机械臂分别适合哪些任务？ 一家公司是在做演示、试点、交付，还是已经形成复购？ 本体、感知、控制、模型、数据与部署怎样协同？ 一个非机器人背景的人，应该怎样进入这个行业？ 这些问题构成了全书的基本框架。 第一部分：产业与场景 这一部分先讨论具身智能的边界、八层产业链和主要产品形态。 我没有把所有机器人放进同一个排名，而是从任务出发：客户需要搬运、巡检、操作工具、照护、陪伴，还是家庭安防？任务不同，对本体、自由度、安全、成本和部署方式的要求也不同。 同一种机器人在发布会上和在真实场景里，也可能是两个完全不同的产品。演示一次动作，和长时间稳定完成任务之间，还隔着可靠性、维护、人员配置、系统集成与成本。 第二部分：公司研究 我整理了 80 余家国内外公司，并选择 39 家建立首轮跟踪矩阵。 这里不做公司总榜。我把不同品类、任务和商业阶段的公司分开，再从业务、产品、技术、经营、资本和组织几个角度观察，同时标记证据来源和可信度。 公司研究中我反复使用一个问题： 一个机器人产品，怎样从能演示，走到能试点、能交付、能复购？ 融资额、估值和演示视频都能提供信息，但它们不能代替客户、部署与收入证据。更值得追问的是：谁在使用、完整任务是什么、进入了哪个阶段、部署需要多少人力，以及客户为什么愿意继续使用。 第三部分：产品与技术 技术部分从产品任务倒推系统，没有按论文名词逐条解释。 如果机器人要在真实环境里完成任务，本体、感知、运动控制、VLA、世界模型、数据、仿真、灵巧手、触觉、安全与部署之间是什么关系？哪些能力决定“能不能做”，哪些能力决定“能不能稳定做”，又有哪些问题最终会落到成本和维护上？ 我希望这部分能帮助非算法背景的读者建立系统关系，也帮助只熟悉某个局部技术的人理解它在完整产品中的位置。 第四部分：职业与学习 进入一个快速变化的行业，职业选择不能只看公司名和岗位标题。 这一部分整理了岗位族、招聘信息、薪酬口径、员工体验与离职代理信号，也提供了一套公司研究工作表。这份材料不保证转行结果；它用来帮助读者判断自己的经验可以迁移到哪里、目标岗位负责什么，以及应该补哪些知识和实践。 这份地图适合怎样使用 这不是机器人算法教材，也不能代替论文、开发文档、真机实验和持续研究。 下面几类读者可以把它作为入门参考： 想系统了解具身智能，但还没有机器人专业背景； 需要研究行业、公司、产品或商业机会； 正在评估具身智能公司与岗位； 已经熟悉局部技术，希望补齐产业、产品和商业视角。 使用这份地图时，可以把不同公司和产品放回各自的任务与阶段中，避免只通过融资金额、演示效果和热门概念判断行业。 关于版本与更新 目前整理完成的是 2026 夏季版，共 120 页。 这份材料记录的是 2026 夏季的阶段性判断。具身智能变化很快，很多判断还要由产品、客户和时间继续检验。后续版本会记录哪些公司进入了新阶段、哪些技术判断发生了变化，以及哪些原本看好的场景没有按预期发展。 网站提供前 12 页试读版，可以先了解内容框架和写作方式。 版本说明与获取方式见说明页。 《具身智能入门：产业、公司、产品、技术与职业地图》 Roy.Tong 2026 夏季版" },{ "id": "article-/notes/from-ai-software-to-physical-world/", "kind": "article", "lang": "zh-CN", "title": "从 AI 应用到真实世界：我的一次转向", "topic": "organization", "url": "/notes/from-ai-software-to-physical-world/", "summary": "2025 年 8 月，我停下了 AI 应用创业。此后在 DJI 的大半年，让我重新理解了软件、硬件与竞争门槛，也让我开始把目光投向具身智能和新一代 AI 硬件。", "published": "2026-07-19", "translation_of": null, "related": ["hardware-innovation","robot-industry"], "text": "这是我在这里写下的第二篇文章。 过去一年，我的工作和关注方向发生了不小的变化：2025 年 8 月，我停下了此前的 AI 应用创业；之后进入 DJI，在影像软件、AI Agent 和软硬件一体化产品中工作；最近半年，我又把大量时间投入到具身智能和 AI 硬件的研究中。 几次转向都围绕同一组问题：当 AI 能力越来越容易获得，产品还缺什么？下一代公司的竞争门槛会建立在哪里？ 这篇文章记录我现在的答案。未来出现新事实时，我会继续修正。 为什么我在 2025 年 8 月停下了 AI 应用创业 2025 年前后，AI 应用的开发门槛下降得比我预想得更快。 过去需要一支完整团队才能完成的产品，开始可以由几个人，甚至一个人，在几天或几周内做出可用版本。模型、开发框架、云服务和开源组件越来越容易获得，从想法到上线所需的时间大幅缩短。 这当然是一件好事。更多人能够创造产品，更多需求有机会被满足。 开发变容易，也让新产品以远超用户需求增长的速度涌现。用户每天面对大量功能相似的 AI 工具，切换成本越来越低，注意力被快速分散。一款产品即使做得不错，也可能只获得短暂的新鲜感，很快被下一批产品覆盖。 创业中更稀缺的，逐渐从“把产品做出来”变成“让用户看见、记住并持续使用”。 AI 应用创业依然考验产品能力。内容、渠道、品牌、增长和社区经营也越来越重要。很多时候，创业者要先让产品被看见，才有机会证明自己的产品判断。 我不认为软件创业失去了价值。能进入业务流程、掌握独特数据、形成网络效应，或者长期完成复杂任务的产品，依然可以建立很高的门槛。只是回看我当时所做的方向，我没有看到足够强、足够持久的结构性优势。 所以我选择停下来。 这次暂停让我意识到：模型能力可以购买，功能可以复制，界面也可以模仿。一个产品如果不能占据独特的工作流、数据、关系网络或交互入口，就会长期处在高供给和低切换成本的竞争中。 在 DJI 的大半年，我重新理解了软件与硬件 进入 DJI 后，我第一次如此近距离地观察一家成熟硬件公司如何面对新的竞争。 硬件的门槛很具体。光学、结构、芯片、传感器、工程设计、供应链、量产、质量控制和售后，任何一项都需要长时间积累。它不像软件原型那样，可以在几周内被快速复制。 但硬件领先并不自动等于用户体验领先。 在全景影像等品类里，Insta360 这类公司带来的压力，很大一部分来自软件。拍摄只是整个体验的起点，之后还有素材管理、剪辑、运镜、模板、分享和跨设备协同。用户要的往往是一段更容易得到、也更愿意分享的内容，而不只是一组漂亮的硬件参数。 软件降低创作门槛后，也会改变用户对硬件价值的判断。硬件决定创作能力的上限，软件决定大多数人能不能抵达这个上限。 这段经历让我形成了两个相互补充的认识。 对硬件公司而言，软件已经直接参与产品竞争。它把传感器、算力和结构设计转化成用户能感知的结果，也决定产品购买之后能否继续更新。 软件公司面对的是另一种情况。当模型、开发和分发的门槛持续下降，如果不能在基模、专有数据、核心工作流、内容生态或社交关系上建立优势，硬件可能成为构建长期门槛的一种方式。它能带来独占的传感器、持续的数据、稳定的使用入口，以及对完整体验更强的控制力。 当然，硬件从来不是一条捷径。供应链、库存、量产、可靠性和售后会把创业难度提高一个数量级。难做本身不创造价值，模型、软件、硬件、数据和服务必须组成一个完整系统。 我越来越相信，下一阶段优秀的 AI 产品，很难只靠某一个功能获胜。竞争会逐步从单点能力，走向系统能力。 下一步，我为什么首先看具身智能 沿着这条线继续往前，我开始把具身智能放在最前面。 我所说的具身智能范围比人形机器人更广。汽车、无人机、四足机器人、机械臂、清洁机器人、智能家电和各种自主设备，都可以放进“智能进入物理世界”的广义框架。 从长期看，我倾向于认为，泛具身的市场规模可能超过手机与汽车之和。它对应的不是单一终端，而是现实世界中大量设备、工具和空间的智能化：移动、操作、运输、制造、照护、陪伴和服务，都可能逐步由智能设备参与。 这个长期判断不等于短期已经成熟。 今天的具身智能仍处在很早的阶段。模型对真实世界的理解还不稳定，高质量数据稀缺，本体和关键零部件仍在快速迭代，供应链尚未定型。一次成功的 Demo，距离在真实场景里持续、安全、低成本地工作，还隔着产品化、工程化和商业化。 资金和创业者已经提前进入。不同统计口径虽有差异，但国内相关企业已是数百家规模。根据 IT 桔子被媒体引用的数据，2025 年 7 月至 2026 年 6 月，国内具身智能一级市场发生了 503 起融资，总金额超过 960 亿元；2026 年前五个月的融资又高度集中在天使轮至 A+ 轮等早期阶段。多家公司估值进入百亿元区间，个别头部公司的市场估值已经达到数百亿元。资本热度与产业成熟度之间，出现了明显的时间差。12 因此我判断，未来一到三年，具身智能会经历一轮幅度很大的行业清洗。 “90% 的公司会死掉”不是精确统计，而是我对竞争强度的方向性判断。如果把今天所有带着具身标签的团队都计算在内，最终能够独立活过这一轮调整的公司，可能只占很小一部分。 原因并不复杂：资本能够为研发争取时间，却不能替代产品定义；融资可以支撑 Demo，却无法保证量产、交付和售后；技术故事能够吸引关注，却不能回答客户为什么购买、愿意付多少钱、多久能够回本。 这轮淘汰未必是坏事。人才、资金、供应链和客户资源会重新集中，产品方向和技术路线也会逐渐明确。今天行业里大量并行、甚至彼此矛盾的尝试，会被真实的交付结果筛选一遍。经过这轮筛选，具身智能才可能从资本驱动的探索期，进入产品和市场共同驱动的成长期。 如果一定要找一个参照，我觉得它有些像中国新能源汽车行业早期的演进。补贴收紧和骗补整治淘汰了一批缺乏真实产品能力的企业，活下来的公司继续打磨电池、供应链、整车和基础设施，最终在 2020 年前后迎来销量与渗透率的加速。 这个类比并不严谨，机器人与汽车的需求成熟度、成本结构和基础设施完全不同。但它提醒我：产业销量和渗透率的加速，通常出现在第一次大规模出清之后，而不是公司数量和融资额最热闹的时候。 具身之外，我也在看各种 AI 硬件 具身智能的落地周期很长，所以这两年我也在持续关注更广泛的 AI 硬件：眼镜、耳机、可穿戴设备、相机、记录设备、家庭终端，以及各种还无法被准确归类的新产品。 产品形态还没有定型，变量也很多。 AI 应该部署在本地、云端，还是采用端云协同？产品只处理语音或图像等单一模态，还是持续理解声音、视觉、位置和环境？用户应该通过语音、按钮、屏幕、手势进行操作，还是让设备主动判断何时提供服务？ 每一种选择，都会继续牵动功耗、散热、续航、隐私、成本和外观。它们之间没有一个适用于所有产品的标准答案，所以我们会看到五花八门的形态，也会看到大量看似新奇、实际体验却不够完整的尝试。 目前很多 AI 硬件还停留在两个极端：一种只是给传统硬件加上聊天能力，另一种擅长展示技术，却没有形成值得反复使用的完整体验。AI 输出的不确定性，与硬件需要稳定、及时、可预测之间，也存在天然矛盾。 用户愿意长期使用的产品，仍然要回答一些朴素的问题：它解决的是否是高频而明确的需求？是否比拿出手机更省事？关键任务能否稳定完成？数据如何被使用，隐私如何被保护？本地和云端各自承担什么？ 这些问题不新奇，却决定一件 AI 硬件能否从演示走进用户生活。 我希望未来两年能够看到这样的产品：它不一定拥有最多的功能，也不需要把 AI 写在每一行宣传语里，但能在一个清晰场景中，把模型、交互、硬件和服务连成一个整体。 从信息世界，走向真实世界 回看过去一年，我的关注没有从软件完全转向硬件。 软件依然决定体验，也依然会创造巨大的价值。变化在于，我开始更在意 AI 如何获得持续的上下文，如何进入真实任务，如何通过稳定的入口服务用户，以及如何把一次模型调用变成一个可交付的结果。 这也是我关注具身智能和 AI 硬件的原因。它们让 AI 离开聊天框，开始面对空间、时间、能量、成本、安全和人的真实生活。问题更难，周期更长，失败也会更昂贵。但一旦整套系统稳定运转，产品创造的价值和竞争门槛也可能更加扎实。 接下来，我会在这里继续记录对 AI、产品、具身智能和创业的观察。既记录我相信什么，也记录这些判断如何被事实推翻和重建。 一年融资超 500 起，谁在豪赌具身智能？，CBNData / 定焦 One，2026 年 6 月。 ↩ 机器人融资暴增，但没一分钱投给“普通人”，钛媒体，2026 年 6 月。 ↩" },{ "id": "article-/notes/start-writing/", "kind": "article", "lang": "zh-CN", "title": "重新开始写作", "topic": "product-research", "url": "/notes/start-writing/", "summary": "我想把零散的观察公开记录下来，长期整理，也允许后续修正。", "published": "2026-07-19", "translation_of": null, "related": ["evidence-maintenance"], "text": "我一直在做需要大量输入和判断的工作：理解技术变化，寻找真实需求，设计产品，也评估一个方向是否值得投入时间。 这些工作会产生许多零散的思考。它们出现在会议记录里、研究报告里、对话里，也出现在还没来得及整理的文档里。信息很多，能被长期复用的判断却不多。 所以有了这个网站。 这里会写什么 我目前最关注四类问题： AI 与 Agent：模型能力快速变化之后，产品形态、交互方式和软件结构会怎样改变； 具身智能：机器人何时能进入产业和家庭，技术进步与商业落地之间还隔着什么； 产品与创业：如何找到真实需求，如何从模糊概念走到可验证的产品； 组织与个人成长：管理者如何判断方向、建立团队，也如何面对不确定性。 这些主题看起来不同，但都指向同一个问题：怎样把新技术做成有人使用、可以持续交付的产品。 我希望怎样写 这里不追求日更，也不打算把每个热点都变成观点。我给自己定了三个写作原则： 尽可能区分事实、推断和立场； 保留判断形成的过程，而不只展示结论； 当新事实出现时，允许自己修改答案。 公开写作会留下一个可检验、可讨论，也能继续修改的版本。 这是第一篇。慢慢来，持续写。" }, { "id": "project-agentmeasure", "kind": "project", "lang": "zh-CN", "title": "AgentMeasure", "topic": "agent-systems", "url": "https://github.com/roy-tong/AgentMeasure", "summary": "用 operation、attempt 与证据记录研究 Agent 对软件的使用。规范、工具和实验的能力范围分别说明。", "related": ["agent-measurement","software-capabilities"], "text": "用 operation、attempt 与证据记录研究 Agent 对软件的使用。规范、工具和实验的能力范围分别说明。" },{ "id": "project-sure", "kind": "project", "lang": "zh-CN", "title": "SURE · 用户需求研究", "topic": "product-research", "url": "https://github.com/roy-tong/user-demand-research", "summary": "证据协议、研究工作流与确定性检查工具。结构通过不等于需求验证。", "related": ["demand-evidence","evidence-maintenance"], "text": "证据协议、研究工作流与确定性检查工具。结构通过不等于需求验证。" },{ "id": "project-iread", "kind": "project", "lang": "zh-CN", "title": "iRead", "topic": "agent-systems", "url": "https://github.com/roy-tong/iRead", "summary": "持续研究的信源发现、去重与报告工作流。让新材料回到已有研究问题。", "related": ["research-workflows","agent-context"], "text": "持续研究的信源发现、去重与报告工作流。让新材料回到已有研究问题。" },{ "id": "project-transcript", "kind": "project", "lang": "zh-CN", "title": "Bilibili Transcript Pipeline", "topic": "creative-tools", "url": "https://github.com/roy-tong/bilibili-transcript-pipeline", "summary": "把视频处理成可回查的转录材料。工具开源不代表第三方音视频可以再分发。", "related": ["research-workflows","video-production"], "text": "把视频处理成可回查的转录材料。工具开源不代表第三方音视频可以再分发。" } ] }