决定内置 AI 功能前，先证明它有不可替代的价值楔子
一套面向创始人的原生 AI 功能决策门槛：用真实构建案例、价值矩阵、完整成本、对照试验和停止规则，判断该做内置工作流还是先交付 AI 接口包。
创始人看到竞品加了一个 AI 按钮，转头就让应用构建器“做个一样的”，周末还没结束，一个颇有说服力的演示已经跑起来了。此时最危险的问题是“这个功能能不能用”，真正有价值的问题则是：把 AI 放进自家产品后，用户得到的东西，是否明显优于在旁边打开一个通用 AI 助手？
本文的核心判断是：在一个有边界的对照试验还没有证明“原生价值楔子”之前，不要继续重金投入内置 AI 功能。所谓价值楔子，是产品自身拥有、外部助手难以轻易替代的优势，例如实时业务状态、受约束的执行能力、团队共享流程、结果反馈闭环，或者更好的交付经济性。如果内置版本只是套用同一类模型、增加一层差价，交付物仍然需要大量返工，那么先提供一套“AI 接口包”，很可能既能帮到用户，又能保留以后再集成的选择权。
读完后，你可以直接复用四项产物：公平的基线对照、五维价值楔子矩阵、单个验收结果的完整成本算法，以及可版本化的决策回执。它适合正在考虑内置文案、分析、配置、客服、建站等模型工作流的创始人。它不主张所有原生 AI 都浪费钱，也不主张任何数据都适合交给外部助手，更不会用一个创始人的案例预测所有产品。涉及敏感数据或高影响操作时，即使底层模型可替换，产品自有的控制层仍可能不可或缺。
一个真实案例：做出来却没有上线的 AI 建站器
2026 年 8 月，Webround 创始人 Luca Siviero 发布了一篇亲历复盘：《我为 Webround 做了一个 AI 建站器，然后把它停掉了》。标题很抢眼，实际决策却相当克制：他不是因为做不出来而放弃，而是在完成集成后，仍决定暂停上线。
Webround 本来就同时提供可视化编辑器和 React 环境。这个 AI 建站器把规划与执行拆开：第一段提示收集需求，整理成多步计划；后续提示逐项接收明确操作，并拿到足够的产品上下文来修改网站。生成的组件 JSON 如果不符合结构，还会被校验器丢弃。这不是给按钮接一段提示词，而是做了实质性的工程控制。
复盘里出现了两种不同结果。AI 生成的无代码结构大多能够通过格式校验，但视觉表现不稳定：布局有时缺少多端配置，组件都在，却拼不出连贯的页面。改成生成 React 后，成品漂亮了许多。恰恰是这次成功暴露了产品问题：如果给通用助手一些 Webround 上下文，它本来就能生成不错的 React 代码，那么更贵的私有集成到底增加了什么独特价值？
Siviero 提到，在他当时测试的 Gemini 配置下，生成一整个网站可能先消耗约 1–2 欧元，用户继续迭代还会增加成本，而且结果仍需清理。这个数字只能视为某个配置下的单点观察，不能当成行业基准。文章没有公布受控用户研究、留存数据、完整成本账本，也没有对所有现行模型做系统比较。它就是一位构建者对一个产品、一次实现的自述。
真正值得借鉴的，是他最后交付的替代方案。他没有把领域知识继续藏在私有编辑器里，而是发布了三份面向 AI 的上下文文档，分别说明平台概念、API 和前端约定，同时提供机器可读的 API 与类型定义。现有的 Webround AI 文档 展示了这种接口的形态。被替换掉的不是“做点什么”，而是一条更贵、更封闭的路径；用户仍然得到了一条更便携的完成路径。
先把选择说清楚：内置工作流，不等于 AI 的唯一入口
把选择理解成“做 AI”或“不做 AI”，很容易误导决策。至少要区分三个概念。
原生 AI 功能，是运行在产品内部的模型工作流。产品负责选择模型路径、提供上下文、展示中间状态、执行权限控制、记录结果、承担推理成本与售后责任。 外部助手工作流，是让客户在产品之外使用通用助手或编码代理，再把指令、文件或生成结果搬进搬出。它可能很强，但状态传递、安全边界、配置和执行会比较零散。 AI 接口包，是由产品方维护、连接两者的一层。它是一套有版本的精简概念、结构定义、示例、能力边界、测试用例和变更说明，帮助获准的 AI 助手正确使用产品。交付形态可以是 Markdown、OpenAPI、SDK、CLI、只读资源或严格限权的工具。Model Context Protocol 的介绍把资源数据、工具和可复用工作流分开，这套词汇很适合拿来梳理边界，但你并不一定非要采用 MCP。所以真正的决策是：为了让用户明显做得更好，此刻有哪些环节必须由你的产品拥有？答案有时是完整的原生工作流，有时只是接口包。很多团队更合理的顺序是：先发布接口包，观察真实用法，再围绕摩擦最大的那一步做一个原生薄切片。
用五类价值楔子判断内置 AI 是否站得住
“更方便”太模糊，不足以支撑一条长期路线。原生功能至少要证明下面五种优势中的一种，最好能同时形成两种。它们是 YBuild 提出的决策分类，不是行业统一标准。
| 价值楔子 | 产品原生拥有的能力 | 算得上证据的结果 | 常见伪证据 |
|---|---|---|---|
| 实时状态 | 当前租户、对象、权限、版本与流程状态 | 过期输入更少，不必手动导出，对象选择正确 | “用户把所有内容复制过去就好” |
| 受约束执行 | 校验、预览、审批、幂等、回滚与结果确认 | 验收完成率更高，无关改动和有害改动更少 | “提示词已经让模型小心了” |
| 团队共享流程 | 角色、评论、交接、历史和持久产物 | 重复劳动减少，审核留在原有工作流里 | 私聊中的一份对话记录 |
| 结果反馈闭环 | 产品可以观察成功、纠正、拒绝及后续结果 | 知道哪些产物被采纳、为什么被改 | 一个不关联任务状态的赞或踩 |
| 交付经济性 | 验收结果的总成本、延迟、配置和支持更优 | 在代表性用量下，单个验收结果更划算 | 只看最便宜的每 token 单价 |
当复制上下文既麻烦又容易出错时，实时状态才构成价值。比如，内置在计费产品里的客服助手可以看到已认证账户、当前发票状态、正在生效的政策版本和既有操作回执。通用助手可以分析一张粘贴过去的发票，却无法安全推断复制之后发生了什么变化。
受约束执行通常更强。模型可以提出网页修改方案，而产品可以校验组件类型、展示响应式预览、要求确认、原子化应用一个版本，并在需要时恢复上一版。原生能力的价值来自对后果的控制，而不是聊天框上印着你的品牌。
当交付物属于一个团队时，共享流程会变得重要。私人助手可能答得很好，但同事看不到基线、评论、审批和状态。原生集成能减少协作中的信息损耗。
只有产品能观察到有意义的结果，才算形成反馈闭环。“已经生成”不等于“已经验收”，“用户复制了”也不等于“问题解决了”。配置助手应该知道校验是否通过、用户是否保留改动、目标流程后来是否完成，以及客服有没有把结果撤回。
交付经济性也远不只是模型账单。提示缓存可以降低重复输入成本——OpenAI 当前的模型使用指南建议分别追踪缓存写入与读取，而 Gemini 文档则说明了隐式与显式上下文缓存——但缓存不会让一个没有差异化的工作流突然产生价值。原生版本仍必须在研发、清理、支持和失败尝试全部计入后，胜过公平基线。
在做原生演示之前，先把外部助手基线做强
团队常把精心打磨的内置原型，与一个故意做弱的基线比较：空白聊天框，没有任何产品上下文。这最多证明“给文档有帮助”，证明不了“必须做内置功能”。
先建立公平基线。把预计提供给原生功能的产品概念、字段定义、示例与允许任务范围，同样交给一个有能力的外部助手。只能使用测试账户、合成数据或已获批准的数据，不能为了方便比较就导出真实客户隐私。
每类代表性任务至少保留以下信息：
- 用户目标与验收条件；
- 应用的起始状态；
- 接口包版本；
- 模型与助手配置；
- 所有手动搬运和纠正动作；
- 生成的产物或拟议改动；
- 校验结果与人工验收；
- 总耗时与可归属成本。
模型输出会波动，因此同一个案例要重复。Anthropic 关于定义成功标准与构建评测的官方指南建议把标准写得具体、可衡量，并按判断类型选择代码、人工或模型评分。结构和状态尽量用确定性校验；有用性、设计判断和需要协商的结果交给人；模型评分器要先用人工判断校准，才能扩大使用。
如果没有可靠随机分组，就不要把小规模比较包装成“用户 A/B 测试”。创始人早期可以做配对对照试验：相同任务族、冻结的输入、重复尝试、条件允许时对产物做盲审，并明确写出不确定性。方法叫什么，应当与实际设计一致。
先过硬门槛，再打分；致命失败不能被平均掉
决策分两层。第一层是硬门槛，第二层才对剩余价值评分。隐私泄露、越权写入，或高影响操作无法回滚，都不能靠其他维度的高分冲抵。
硬门槛
- 功能不需要未披露的数据访问，也不会走一条比已批准基线更弱的隐私路径。
- 每次状态变更都经过服务端授权、参数校验，并能观察到实际结果。
- 每个测试结果都能对应到模型、提示/上下文、工具和产品版本。
- 关键任务失败没有越过预先定义的后果边界。
- 人可以立即停止试点，并恢复到一个已知状态。
加权价值矩阵
每个价值楔子按 0–5 分打分，再乘以与用户任务相关的权重。权重必须在看到结果前设定。
| 分数 | 含义 |
|---|---|
| 0 | 相比有文档支持的外部基线，没有显示出任何优势 |
| 1 | 只有界面或便利性变化，结果基本不变 |
| 2 | 有小幅改善，但配置、清理或支持负担仍重 |
| 3 | 在代表性任务上可以重复看到改善，但限制明显 |
| 4 | 验收结果显著提升，或实质降低了风险 |
| 5 | 缺少这项产品原生能力时，该任务不现实或不安全 |
例如，一个配置工作流可将实时状态设为 25%、受约束执行 30%、团队共享 10%、结果闭环 20%、交付经济性 15%。不要套用统一及格线，而应在试验前写好规则，比如：所有硬门槛通过；受约束执行至少 4 分；加权分达到 3.2；并且在团队预设用量下，成本优势的保守估计不能为负。
分数旁边必须保留原始数量。“4/5”如果没有任务数量、任务难度、评审分歧和失败分布，证据很弱。
算单个验收结果的成本，不算单次生成的成本
模型账单只是其中一行。创始人可以用下面这个公式：
单个验收结果成本 =
（模型 + 工具 + 基础设施 + 审核 + 纠正 + 支持 + 分摊研发成本）
/ 验收结果数量
没有产生可用结果的尝试也要计入。重新生成、整理上下文、手动复制、视觉清理、校验失败和客服时间都要算。原生功能的研发和维护成本应按一个写明的使用场景分摊，不能因为已经投入就当成免费。外部方案同样不能因为用户已经订阅通用助手，就把配置和搬运劳动算成零。
让质量和成本同时可见：
| 指标 | 外部基线 | 原生薄切片 |
|---|---|---|
| 尝试的合格任务 | 数量 | 数量 |
| 无需修改即验收 | 数量/比例 | 数量/比例 |
| 修改后验收 | 数量/比例 | 数量/比例 |
| 关键失败 | 按类型计数 | 按类型计数 |
| 每个验收结果的人工中位分钟数 | 时间 | 时间 |
| 提供商和工具总成本 | 货币 | 货币 |
| 分摊产品/维护成本 | 货币 | 货币 |
| 单个验收结果成本 | 货币 | 货币 |
缓存只有在提示存在稳定的可复用前缀，而且流量发生在相应复用条件内时，才会改变这笔账。Anthropic 的提示缓存文档说明，缓存命中依赖完全一致的提示前缀，写入、读取、有效期和失效的计价也不同。应读取实际用量字段，而不是默认“开了缓存就省钱”。除非代表性测试证明净收益，否则不要只为跨过缓存门槛而给上下文灌水。
长上下文也不能替代内容整理。Anthropic 的上下文窗口指南明确指出，更多上下文不一定更好，内容增长时召回与准确性可能下降。接口包的任务，是让相关契约更容易被找到，而不是把全部内部文档塞进每一次请求。
价值楔子尚未成立时，先交付一套 AI 接口包
接口包要小到可以认真审核，又要完整到足以阻止模型凭空猜测。它是产品产物，不是营销页面。第一个可用版本可以包含：
ai-interface/
README.md # 支持的任务、排除项、配置方法和信任边界
concepts.md # 稳定术语、对象关系和生命周期
schemas/ # 带版本号的 OpenAPI、JSON Schema 或类型
examples/ # 合法输入、输出和失败示例
evals/ # 代表性任务与验收检查
CHANGELOG.md # 破坏性变更、迁移和废弃行为
如果用户反复需要读取实时但不敏感的状态，可以再加只读 CLI 或资源端点。只有身份、授权、校验、审批、幂等、审计和恢复都准备好时，才开放写工具。“助手能调用 API”不等于已经证明执行安全。
OpenAI 的向量存储文档展示了文件如何分块、附加属性、过滤并检索相关片段。这有助于找资料，却无法证明取回的段落仍是最新、权威版本。因此，版本、适用范围、生效时间和替代关系应直接写进来源，并测试过期指引不会被选中。
接口包必须有负责人和兼容承诺。文档与结构定义要一起版本化。行为变化时，增加迁移示例和一个能让旧用例明确失败的测试。还要公开数据边界：哪些内容可以提交给第三方助手，哪些必须留在产品内，哪些账户或环境适合测试。
这条路线本身也会产生发现证据。记录客户在用哪些文件、哪些任务重复出现、他们在哪里需要实时状态、哪些手动搬运容易出错，以及哪些动作无法安全完成。这些模式会指出最值得原生化的最小价值楔子。
具体场景：为排班 SaaS 决定要不要做设置助手
设想一家四人排班 SaaS，叫 SlotHarbor。创始人想做一个 AI 设置助手，让用户用自然语言描述业务后，自动生成服务类型、时长规则、员工分配、取消政策、提醒消息和可发布的预约页。
周末原型能写出漂亮文案，也能生成看似正确的配置，团队一开始把它判为成功。公平基线改变了结论：有一套六文件接口包后，通用助手已经能很好地起草服务目录、政策和提醒文案。原生生成只快一点，修改时间差不多，没有形成内容生成价值楔子。
失败日志却暴露出一个更窄、更真实的问题：用户会粘贴过期的员工可用时间，把缓冲时间和预约时长混淆，也看不出建议规则是否冲突。手动应用配置还会产生半完成状态——员工排班还没补齐，预约页可能已经发布。
于是 SlotHarbor 改写假设。原生功能不再承诺“一键搭好整个预约业务”，而是接收一份拟议配置，结合当前租户状态找冲突、展示差异、模拟可预约时段，并以一个经过批准的原子版本应用。文案起草继续保持可移植。
试点现在验证的是一个真正的价值楔子：
- 两个方案使用相同的十类代表性设置任务；
- 当前员工与服务状态只能通过已批准的产品访问获取；
- 重叠、缺失可用时间、非法时长和发布状态用确定性规则校验；
- 人工判断最终预约体验是否符合业务描述；
- 对一个无害试点变更执行回滚；
- 完整成本包含创始人的支持时间。
用一份原生 AI 决策回执保存证据
只有表格分数、没有测试版本，很快会变成团队传说。把下面这类回执与试验产物放在一起：
decision_id: nai-2026-08-24-setup-copilot
user_job: configure_and_publish_booking_flow
decision_owner: product_founder
baseline:
type: external_assistant_plus_interface_kit
kit_version: 0.3.0
candidate:
native_revision: setup-copilot-0.2.1
model: provider-model-version
context_revision: setup-context-17
hypothesis:
wedge: constrained_execution
claim: reduces_invalid_or_partial_publications
test:
dataset: setup-cases-v4
repetitions: 3
synthetic_only: true
hard_gates:
authorization: pass
validation: pass
rollback: pass
critical_failures: 0
outcomes:
accepted_without_correction: "填写原始数量"
median_human_minutes: "填写数值"
cost_per_accepted_outcome: "填写数值与币种"
limits:
- one product tier
- no payment or medical scheduling
decision: pilot_continue | ship | interface_kit_only | stop
recheck_trigger:
- model_change
- schema_change
- pricing_change
- new_sensitive_data_class
机器可读的字段不会让主观评分自动客观。回执的作用，是让未来的团队看清当时比较了什么，可以重跑试点，也能在模型能力、提供商价格、用户习惯或产品架构变化时重审决策。
在把功能写进路线图前，先逐项验证这些失败模式
把 FOMO 当成策略。竞品的 AI 按钮变成了需求。控制方法：先写用户任务、基线与价值楔子，再给功能起名。 演示获得了特权。原生版本拿到内部文档，基线只拿到一个空白提示。控制方法：给双方等价的领域知识，明确记录哪些优势被有意扣留。 最好的一次结果藏住了分布。发布视频只展示最漂亮的一次。控制方法：每个案例都重复，保留失败，报告验收数量与关键失败类型。 把结构合法误当成结果有价值。JSON 通过校验，页面或业务规则却很差。控制方法：分别评估结构校验、领域正确性、用户判断和后续业务结果。 封装层藏住了溢价。用户为模型成本、平台加价、重试和清理买单，得到的结果在别处也能获得。控制方法：两个路径都按单个验收结果算总成本。 用上下文倾倒代替接口设计。类型、API、政策和全部历史被塞进每次请求。控制方法：保留精简稳定的概念，按任务检索引用，并测量缓存命中和上下文失败。 接口包逐渐过期。外部助手拿到旧字段或旧政策。控制方法：文档和结构一起版本化，公布生效日期，持续测试旧示例，并明确负责人。 把“外部”当成隐私捷径。为了少做原生功能，团队让客户把真实记录粘贴进个人助手。控制方法：公布允许的数据类别，提供合成示例，把敏感流程留在获批系统里。 把停止描述成失败。沉没成本逼团队上线。控制方法：预先把interface_kit_only 和 stop 都定义成成功的试验结果。能避免未来的支持与维护债，本身就是价值。
用 48 小时跑一次原生价值练习
这是一轮发现练习，不足以批准高影响生产上线。
第 0–4 小时：明确任务。挑一个反复出现的客户任务，写清起始状态、验收结果、禁止后果，以及谁来判断是否验收。 第 4–10 小时：制作接口包。只写足以阻止助手猜测的概念、结构、示例和边界，并给它一个版本号。 第 10–18 小时：跑基线。使用合成数据或批准数据，至少尝试五类任务，包括歧义和非法输入，记录设置、搬运、纠正、成本与耗时。 第 18–26 小时：只隔离一个价值楔子。找出基线最大的损失，只做解决它所需的产品能力：实时状态读取、校验器、预览、原子应用、共享审核或结果捕获。 第 26–36 小时：重复对照。冻结案例集与起始状态，两个版本都重复运行。先用确定性检查，条件允许时再做盲审。 第 36–42 小时：给验收结果定价。把重试、人工、支持和明确的维护分摊都算进去，并写出用量假设。 第 42–46 小时：主动攻击结论。测试过期文档、模型不可用、非法结构、用户意图不清、写入后响应丢失、权限变化与回滚。 第 46–48 小时：写决策回执。选择继续试点、做原生薄切片、仅保留接口包或停止，并写出什么新证据会让你改判。明确这套框架何时适用、何时不适用
当功能的主要主张是“AI 让现有产品任务更容易、更快或更好”时，可以使用这套门槛。特别是通用助手已经能起草同类产物，而创始人正在判断集成便利性是否值得承担长期产品复杂度时，它最有帮助。
不能拿加权矩阵去平均掉法律、隐私、安全、无障碍和人身安全义务。健康、金融、就业或身份场景可能需要专家审核及特定司法辖区的控制。原生产品即使认证了用户，也不会因此自动获得执行权限。
如果政策禁止把必要数据转移给外部助手，或者任务依赖无法安全表达的私有实时状态，那么外部工作流不是合格基线。此时应与人工操作流程或非生成式自动化比较，并记录外部路径为何不合格。
也不要把 Webround 案例简化成“所有 AI 构建器都是套壳”。作者发现的是：在他的产品中，一条私有路径当时并未超过上下文充分的通用助手。你的产品可能拥有独特数据、交互界面、模拟、审批、团队协作或结果信号，从而形成决定性优势。是否如此，只能用自己的用户和约束来证明。
上线前使用这份最终检查清单
- [ ] 用户任务和验收结果不依赖模型术语也能说清。
- [ ] 已公平运行带文档的外部助手或人工基线。
- [ ] 原生假设明确指出五种价值楔子中的一种。
- [ ] 数据类别和合格测试环境已经写明。
- [ ] 高影响操作有确定性的授权与校验。
- [ ] 代表性案例包括歧义、拒绝、失败与恢复。
- [ ] 保留多次尝试，没有只挑演示最好的一次。
- [ ] 结构合法、用户有用和后续结果是不同指标。
- [ ] 成本包含推理、工具、审核、纠正、支持与维护。
- [ ] 接口包有负责人、版本、边界、示例与变更记录。
- [ ] 停止、仅接口包和原生薄切片都是可接受结论。
- [ ] 回执保留版本、原始数量、限制和重审触发条件。
参考资料
- Luca Siviero / Webround，I built an AI website builder for Webround. Then I killed it
- Webround，AI 平台上下文文档
- Model Context Protocol，什么是 MCP？
- Anthropic，定义成功标准并构建评测
- Anthropic，提示缓存
- Anthropic，上下文窗口
- Google AI for Developers，Gemini 上下文缓存
- OpenAI，向量存储
- OpenAI，模型使用指南
- NIST，AI 风险管理框架核心
- Google Search Central，创建实用、可靠、以人为本的内容