来源

AI 交付需要一条可验证的证据链

这期 Community Wisdom 的四组讨论看似分散，实际都在处理同一个变化：AI 大幅压低了产出代码、界面和内部工具的成本，真正稀缺的部分随之转向意图传递、结果验证和责任承担。实现速度可以由模型放大，可信度仍要靠一条外部可检查的证据链建立。

背景：有人把 Claude Design 中已经迭代到像素级精度的原型交给 Claude Code，最终实现只有预期的六到七成。问题集中在两处：交接文件允许模型自行解释，组件内部的空态、加载、悬停、激活、聚焦等状态也没有显式呈现。

导出文件的默认 README 直接要求 Claude Code 解释设计，相当于公开邀请它自行发挥。空态、加载、悬停、激活和聚焦等不可见状态，只存在于组件逻辑内部，因此在交接链路中会被重新发明，或者直接遗漏。

解决办法是删掉允许解释和探索的指令，在 README 中加入组件映射表，让每个页面显式渲染空态、加载态、错误态和完整数据态，再用 Playwright 生成截图，让模型检查自己的输出是否发生偏移。

如果 Claude Design 能看到真实代码库，而不只看到抽象设计系统，它就会用现有组件制作原型。组件名称和状态也更容易沿着交接链路保留下来。

兴趣匹配度极高。这里提供了一个可以直接迁移到 Agent 工程的交付协议：把隐含状态展开，把自由解释改成明确映射，给执行者接入真实约束，再加入可运行的视觉回归。高保真实现依靠闭环，而非更长的提示词。

背景：B2B 客户问产品是否由 Claude Code 快速生成，表面上关心代码生产方式，底层关心的是系统能否持续运行、团队是否长期存在，以及凌晨两点出现故障时谁来负责。

客户问这是不是 vibe coded、为什么值得信任时，真正提出的是一个穿着代码外衣的风险问题。他们想知道产品能否扛住真实环境，你一年后是否还在，以及凌晨两点出问题时由谁负责。

严谨开发与一次性生成之间确实存在差别，但只讲自己的过程很难建立信任。客户无法验证过程，每个创始人都会声称自己很严谨，于是更完整的开发故事仍可能被理解为营销。

把问题从相信我转成现场验证：让客户在购买前用自己的混乱数据运行产品，看它如何处理真实边界情况；同时明确支持响应、故障处理和责任人。这些枯燥的责任机制很难被一次性生成者伪造，却正是客户真正想确认的内容。

兴趣匹配度很高。AI 产品的信任来自可观察行为，而非生产工具声明。测试覆盖率、问题追踪、变更可见性、真实客户背书、边界数据试运行和支持承诺，构成了一套比我们如何使用 AI 更有效的证据。

背景：讨论者把当下的怀疑类比为早期企业对开源软件的质疑。市场需要时间形成新的尽调模式，团队则需要主动展示自己处于成熟开发光谱的哪一端。

使用 AI 生产软件，与依靠 AI 可持续运营一个任意规模的产品之间存在很宽的距离。软件由人还是 AI 编写，都需要领域专家确保产品意图明确，并通过充分测试和评估证明结果与意图一致。

旧有 SaaS 启发式已经难以判断 AI 驱动的小团队。新的模式需要回答怎样评估团队、公司和合作风险。现阶段，所有团队都要准备一套能够说明自身成熟度的证据。

保留收据，尤其是模型无法替你编造的收据。会议里声称自己做了哪些事，与展示持续做过这些事的记录，价值完全不同。

兴趣匹配度很高。这可以压缩成一条工程判断：生成能力越普及，过程资产的区分度越高。决策记录、测试结果、发布历史、事故复盘和客户使用证据，会从内部管理材料演化为产品可信度的一部分。

背景：个人 CRM 的讨论最后回到一个产品机制。记录联系人的系统很容易搭建，定期提醒很久没联系的人却缺少自然动机。真正有价值的时刻，是系统能把关系数据接入正在发生的任务。

能记录你和谁交谈过，只是一个方便的数据库；提醒你联系很久没聊的人，在缺少触发条件时会显得生硬。当你正在找工作，系统能发现匹配岗位位于熟人所在的公司，关系数据才转化成了具体行动。

对个人使用场景，与其先购买一个功能繁多的 CRM，不如先围绕自己的触发场景，用 Claude Code 或 Codex 快速做一个小系统。

兴趣匹配度高。它把产品价值从保存多少数据改写为在什么情境下促成什么动作。知识管理和第二大脑也遵循同一机制：收集层可以很轻，真正需要设计的是任务出现时，相关信息如何进入决策现场。

这期最值得留下的主线是：AI 让实现能力逐渐商品化以后，可信交付依赖外部化的状态、验证和责任。设计交接要把不可见状态写出来，代码实现要让 Agent 看见真实约束并检查偏移，商业信任要用客户数据和运营承诺验证，内部专业性则要靠持续留下的收据证明。模型负责加速产出，证据链负责让产出进入生产环境。