跳转至

How to Build an AI-Native Startup

Ch04.262 How to Build an AI-Native Startup

📊 Level ⭐⭐ | 9.3KB | entities/ai-native-startup-cyberfund-2026.md

How to Build an AI-Native Startup

摘要

本文来自 cyber.fund 创始人 Stepan Gershuni 的创始人指南，系统阐述了 AI 原生创业公司的核心操作系统：Context · Agents · Evals · Skills。文章的核心论点是：真正拉开差距的不是谁雇了更多人，而是谁的公司学得更快、迭代得更快。每天快一点，几周后差距开始拉开，几个月后只有一家会活下来。

核心要点

一、先画地图：频率胜过重要性

把过去两周公司里重复发生的所有工作列出来——客户通话整理、线索调研、支持工单分类、产品测试、候选人初筛、发票审核、竞品监控。创始人的日历里通常有 20-40 项这样的工作，诚实列下来会发现有 10-15 项已不知不觉变成例行工作。

按自主程度分级： - 纯人工：战略决策、关键招聘、法律签字——不碰 - AI 起草/人审批：投资人更新、合同红线、定价页改写 - AI 执行/人监督：入站分类、会议记录路由、线索丰富 - 全自主：竞品监控、夜间报告、简单异常检测

反直觉规律：频率胜过重要性。低频工作即使看起来更重要，你永远攒不够样本来知道自己做得好不好。C.H. Robinson 的案例验证了这一点——每天 10,000 封邮件的入站分类推到全自主后又退回 AI 起草人审批，因为单条错误路由的代价藏在总量里根本发现不了。

二、把记忆装进代码库

Context 定义为「AI 原生创业公司的操作记忆」——公司对自己的一切了解，放在智能体能读到的地方。同一个模型，读了你三个月客户通话提炼的公司，和一个刚接入 API 的公司，输出质量差的不是一个级别。模型会换代，但「知道客户说再考虑考虑其实意思是价格太高」的提炼，是跟着你走的。

实践建议： - 从 Git 仓库开始——有版本历史，可比较差异，人和智能体都能读 - 第七天的工作区只需几个文件：CLAUDE.md、context/company.md、context/product.md、context/customers.md、context/lessons.md - 控制在 40-60 行手写内容，紧凑的「应该避免什么」清单比 400 行 AI 生成内容更有用 - 关键数字：Anthropic 的 MCP 代码执行工作展示了「服务器文件夹」加载方式，把 context 占用从约 15 万 token 降到约 2000 token——削减了 98.7%

原始数据与提炼数据必须分开：通话录音是原始数据；那次通话里做的决定、客户提出的反对意见、续约风险——这些是提炼数据。混在一起会淹在录音里。每个智能体的总结都必须能追溯到源头。

三、选最轻的工具

不是所有流程都需要智能体。最好的 AI 原生系统是脚本、AI 辅助人工、确定性工作流和智能体的混合体：

工具类型 适用场景
脚本 步骤确定：导出报告、转 CSV、跑测试、校验 JSON
AI 辅助人工 输出需要判断：投资人更新、定价文案
工作流 步骤已知但链条长
智能体 路径无法预设：排查生产 bug、调研市场、处理复杂客户案例

每个智能体外面必须套一个防护层（harness）。六个阶段：预检 → 计划 → 审批 → 执行 → 验证 → 记录。

安全边界必须写进代码和配置，不能只写在提示词里。2025 年 Replit 事件：一个编程智能体在会话途中清空了生产数据库。提示词指令不是安全边界，只有代码层面的限制才是。

四、什么叫做对了：Skills 与 Evals

技能是一套可复用的指令加示例，用于重复性任务。每个技能需要：范围、输入、需要加载的 context、步骤、输出格式、示例、升级规则、负责人、运行日志。如果文件没说它接受什么、返回什么、什么时候求助、谁来维护，那它是个很长的提示词，不是一个技能。

评估是让技能复利的东西。一旦有了可用的 eval，提示词调整就变成可选项：一个小型反思模型提出改动，eval 给改动排名，最好的自动上线。没有 eval，每次迭代都是口味之争。

核心指标：接受率。低于约 70%，技能还没准备好提升自主程度。接受率低的时候，直觉是改提示词——几乎从来不是这个问题。通常是：运行时加载更多 context、收窄技能范围、加更多已完成的示例、为智能体不该接的任务写更清楚的升级规则。

五、创始人先上 + 每周进化

让团队转向新运作方式的最快路径是创始人自己先展示：晨简报、客户合成、测试 PR、投资人更新草稿——不是 PPT，是真实 context 下的现场演示。Jack Dorsey 在 Block 据报道每天早上花几小时亲自使用这些工具。

入职也要变：每个新成员在第一次会话结束时都要有一个当天可用的输出。招聘门槛也高了——测的不是知识，是判断力：给候选人一个人工做不完的任务，看他们怎么指挥智能体做完。

AI 原生创业公司每周改进一次操作系统，分内环和外环： - 内环：让现有工作更好——降成本、缩短周期、减少事故 - 外环：寻找下一步——新客户群、产品方向、竞争对手动态

硬规则：任何代码都不能自动合并，没有智能体可以直接写入生产环境。

深度分析

Context 即护城河

Gershuni 的核心洞察是：模型是锅，context 是你和你业务之间的默契库。每家公司都有相同的模型，但 context 不同——那些从真实交互中提炼出的隐性知识（「客户说再考虑考虑其实意思是价格太高」）才是真正的护城河。这与 Context Engineering 的理念高度一致：context 的质量决定了 AI 系统的输出质量。

Harness 的必要性

文章中提到的「每个智能体外面必须套一个防护层」直接呼应了 Harness Engineering 的核心原则。六个阶段的 harness 流程（预检→计划→审批→执行→验证→记录）与 Claude Code 的内部机制异曲同工。Replit 事件则是一个典型的反面案例——提示词层面的安全约束在实际工程中是不可靠的。

评估驱动的复利增长

文章对 Evals 的强调体现了 AI 原生系统与传统软件工程的根本区别：传统系统通过代码测试保证质量，AI 原生系统通过评估保证技能的持续改进。接受率作为核心指标，本质上是一个信号——它告诉你技能是否已经「理解」了任务的边界。这与 Karpathy 关于 Agentic Engineering 的观点相呼应：评估系统是 AI 原生公司的质量基础设施。

评论者的补充

深思圈的评论者补充了两个重要观点： 1. Gershuni 把问题框定成「执行纪律」，但漏掉了更根本的东西：判断什么值得编码，本身就是一种稀缺能力，这个能力没法被方法论覆盖 2. 大多数创始人高估自己做的事的战略含量。瓶颈不是纪律，是自我认知的诚实度 3. 如果操作系统真的是护城河，先跑起来的公司每天比你多学一点，学习速度还在加速——这不是线性差距，是指数差距

实践启示

  1. 从审计开始：诚实列出过去两周的所有重复性工作，按自主程度分级，从最高频的开始自动化
  2. Context 先行：在写任何 agent 代码之前，先建立 context 仓库——40-60 行手写内容比 400 行 AI 生成内容更有价值
  3. 用最轻的工具：不要对所有流程都上智能体，脚本和确定性工作流往往是更好的选择
  4. Evals 是真正的引擎：没有评估系统的 AI 原生公司无法实现复利增长，每个技能都需要可量化的质量指标
  5. 安全边界写进代码：提示词层面的约束在工程上不可靠，所有安全规则必须在代码层面强制执行

相关实体

→ 原文存档