在同一个市场中，两家公司于同一个月成立，却走向了截然不同的运营轨迹。

早上九点，第一家公司运营负责人正在处理过去遗留的客户支持工单，分析师们匆忙重建上周出现问题的数据面板，创始人则主持着一场三天前就已启动、但至今仍未找到解决方案的客户投诉晨会。

同一时间，第二家公司的创始人已经进入了产品迭代的节奏。

当夜幕降临，智能体自动完成了工单分类，更新了数据面板，并从通话录音中精准识别出潜在的客户流失风险。创始人次日一早审阅简报时，所有问题已被妥善处理，他开始将精力投入到下一步战略规划中。

这是 Stepan Gershuni 在 cyber.fund 上发布的创业指南中的开篇引言。他的论点直指核心：企业间的真正差距，不在于谁雇佣了更多员工，而在于哪家公司能够更快地学习、更高效地迭代。每天进步一点点，几周后差距便开始显现；几个月内，其中一家公司将脱颖而出，而另一家则可能难以为继。

How to Build an AI-Native Startup — cyber.fund 创始人指南封面

传统创业 vs AI 原生创业的组织结构对比：前者是创始人与多人的全网格协调，后者是少数人通过 Context·Agents·Evals·Skills 驱动

01 先画地图

第一步并非寻找工具或挑选模型，而是绘制一份清晰的业务工作地图。

将过去两周内公司里所有重复性工作逐一列出：客户通话整理、线索调研、支持工单分类、产品测试、候选人初筛、发片审核、竞品监控……创始人的日程中通常包含 20 到 40 项此类任务。当你诚实地记录下来，会发现其中有 10 到 15 项工作，你甚至没有意识到它们已经变成了例行公事。

接着，根据自主程度对这些工作进行分级。

最底层的任务是纯人工操作——如战略决策、关键招聘、法律签字等，这些必须亲自处理。往上一层，可采用AI 起草人来审批的模式，例如投资人更新、合同审阅、定价页改写。再往上，则是AI 执行人来监督的环节，如入站分类、会议记录路由、线索丰富等。最高层级是在明确限制内自主运行——包括竞品监控、夜间报告生成、简单异常检测。

这里有一个反直觉的规律：工作频率往往比其重要性更具决定性。

这就好比健身房里最有效的训练计划，不一定是理论最科学的，而是你能坚持每天执行的那个。每周撰写一次的投资人更新，一年只有 52 次机会去发现自己的不足；而每天运行十次的工单分类系统，一年则拥有 3650 次机会让评估机制捕捉到失败模式。即便低频工作看起来更为关键，你永远无法积累足够的样本来判断自己做得好不好。

那些看似无聊但高频的工作流通常更值得优先处理。频率胜过光鲜。

他还提及 C.H. Robinson 的案例，颇具警示意义：他们尝试将每天 10,000 封邮件的入站分类完全自动化，结果却不得不退回到 AI 起草人审批的模式。因为工作量太大，单条错误路由的代价看似微小，但却被淹没在海量的数据中，难以被及时察觉。

简单来说：如果团队自身都无法清晰定义什么算是“做得好”，那么这个流程就尚未达到可以完全交由机器处理的阶段。

「优先自动化」区域：横轴为每月所耗时间，纵轴是复利适配度。测试生成与通话整理处于高优先级区域，而董事会备忘录和战略招聘则仍需人工处理

02 把记忆装进代码库

这部分是整篇文章中最具启发性的内容之一。

他将 context 定义为“AI 原生创业公司的操作记忆”——即公司对自身所有业务的理解，并放置在智能体能够读取的位置。

观察一位老厨师烹饪，便能深刻理解这一概念。他使用的锅、灶、油、盐与隔壁新开业的餐馆完全相同。但他深知这口锅的哪个位置火候最旺，也清楚今天的姜水分偏大，需要多煸炒一会儿。这些并非“技巧”，而是他与这些食材、这口锅之间长期积累的默契。

Gershuni 所说的 context 正是这种默契。模型是锅，context 是你与业务之间积累的“默契库”。一个读取了你三个月客户通话提炼内容的模型，与一个刚接入 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%。如此显著的成本节省，足以让财务部门欣喜不已。

Context 系统架构：来自 CRM/日历/支持工单等外部系统的连接器，加上内部生成文件（决策、教训、规格文档），以及数据库/数据流，经过权限·规范化·溯源处理，输出为「Agents Content Bundle」

有一个容易被忽略的要点：务必将原始数据与提炼数据分开存储。通话录音属于原始数据；而基于那次通话所做的决策、客户提出的反对意见、续约风险等——这些是关键提炼数据，是智能体真正需要查询的内容。若将两者混合，你将被淹没在录音中，永远无法构建出那一层真正有价值的提炼信息。

此外，追溯来源至关重要。每个智能体所生成的摘要，都必须能够追溯到明确的源头——是哪条录音、哪张工单、或哪个数据库记录。缺乏溯源，公司里将充斥着无法核实、看似可信的总结。一旦有人发现某个自信满满的答案其实是错误的，整个智能体层的信任体系便会崩塌。

有了溯源机制，任何争议都能在一秒内解决——点击链接，查看源头证据。

03 选最轻的那个

完成 context 构建后，很容易产生将所有工作都交由智能体处理的冲动。

但千万不要这样做。

他直言不讳：并非所有流程都需要智能体。最佳 AI 原生系统，是脚本、AI 辅助人工、确定性工作流与智能体的混合体，核心原则是使用最轻量级的工具来完成当前的工作。

对于步骤明确的任务，使用脚本即可——例如导出报告、转换 CSV 格式、运行测试、校验 JSON 格式，无需浪费智能体的算力。对于需要经过判断才能输出的内容，如投资人更新和定价文案，应让AI 辅助人工来完成。对于步骤已知但链条较长的流程，可以使用工作流串联起来。只有在路径确实无法预设的情况下，才需要智能体介入：例如排查生产环境故障、进行市场调研、处理复杂客户案例。

自动化选择矩阵：纵轴表示风险高低，横轴表示路径是否已知。高风险+已知路径 = 工作流；低风险+未知路径 = 智能体；HARNESS 六步贯穿所有路径

每个智能体都必须配备一个防护层（harness），包含六个阶段：预检（在消耗 token 前检查权限）→ 计划（拆解任务，暴露具体步骤）→ 审批（由人工或评判模型把关）→ 执行 → 验证 → 记录。

防护规则必须写入代码和配置中，不能仅依赖提示词。在提示词里写上“不要删除生产数据”并非真正的安全边界。

2025 年发生的一起 Replit 事件便是深刻的教训：一个编程智能体在运行过程中清空了生产数据库。这提醒我们：提示词指令不是安全边界，只有代码层面的限制才是真正的保障。

04 什么叫做对了

技能与评估（evals）构成了整个系统的核心驱动。前面的所有工作只是铺垫，这里才是真正产生复利效应的所在。

技能是一套可复用的指令和示例组合，用于完成某个重复性任务。先手动运行两遍，然后将重复性的部分编码化。每个技能需要明确：范围、输入、需要加载的 context、具体步骤、输出格式、示例、升级规则、负责人、以及运行日志。

如果一份文件没有说明它接受什么输入、返回什么输出、在什么情况下需要求助、由谁来维护，那么它只是一个冗长的提示词，而不是一个规范化的技能。

评估则是让技能产生复利的关键工具。一旦拥有了可用的 eval，提示词的调整就变成了可选项：一个小型反思模型会提出修改建议，eval 对这些改动进行排名，最优的方案会自动上线。如果没有 eval，每一次迭代都将沦为一场主观的口味之争。

他以客户通话整理为例：选取 30 个历史通话，由业务负责人标注每个通话中应提取哪些关键信息。机械检查——如姓名是否正确、金额与合同是否匹配、跟进日期是否在合理的周次内——这些是确定性的，可以直接判断。LLM 评判则负责处理其余部分：这份通话简报是否准确反映了那次通话的内容？

在运行大约 50 次之后，你通常会发现两个固定的失败模式，往往是你之前未曾预料到的问题，而非你最初担心的那些。

需要持续监测的核心指标是：接受率。如果低于约 70%，说明该技能尚未做好提升自主程度的准备。当接受率较低时，直觉反应往往是修改提示词——但这几乎从来不是根本原因。真正的问题通常源于以下四个方面：运行时加载了更多的 context、技能的覆盖范围过于宽泛、文件中缺乏更多已完成示例、或者为智能体不应处理的任务制定了更清晰的升级规则。

05 创始人先上

要让整个团队适应新的工作方式，最快捷的路径是创始人自己率先做出表率。

不是在会议室里展示 PPT，而是在公司的真实业务背景下进行现场演示。可以展示从日历、收件箱、Slack 凌晨拉取生成的晨间简报；展示昨日通话的客户合成分析；展示智能体根据需求文档自动开具的测试 PR；展示基于最新指标包自动生成的投资人更新草稿。

据报道，Jack Dorsey 在 Block 围绕这些工具进行重组之前，每天会花数小时亲自使用这些工具。正是由于领导层的亲身实践，才最终促成了那次影响深远的效率重组决策。

入职流程也需要相应变革。每个新成员在第一次会话结束时，都应产生一个当天即可使用的实际输出——例如清理后的客户简报、支持宏、测试 PR、或定价页评审结果。Ramp 公司的 Glass 工具正是依靠这一规则，从每天 20 个日活跃用户，在三个月内增长到了 700 个。不产生真实工作成果的培训，到下周就会被遗忘。

招聘的门槛也随之提高——因为一些原本需要人力的工作，现在已经被转化为一个技能。招聘时，考察的不再是知识储备，而是判断力。可以给候选人一个在给定时间内仅靠人工无法完成的任务，观察他们如何指挥智能体来高效完成。你真正招聘的是判断力、品味、以及在智能体出现偏离时的纠错能力。

这些能力在过去就已经非常宝贵，而在今天，它们的价值更加凸显。

06 每周进化

AI 原生创业公司需要每周都对自身的操作系统进行一次改进。

市场学习外环：通话·产品使用·工单·竞品·账单数据 → 市场信号 → 假设 → 智能体实验 → 人工决策 → 产品/流程变化 → 循环

他将这个循环分为内环和外环。内环致力于优化现有工作——降低每次运行的成本，缩短周期，减少事故，缩短审查时间。外环则负责探索新方向——寻找新客户群体、发现产品新方向、监控竞争对手动态、识别客户流失风险。后台的智能体全天候为外环输送候选方案，由人来最终决定哪个方向值得跟进。

有一条硬性规则：任何代码都不能自动合并到生产环境，也不允许智能体直接写入生产环境。就连 Cursor 在 2026 年初大规模运行云端自主智能体时，合并之前也仍然保留了人工审查的门槛。这个门槛，是保障其他所有功能能够安全扩展的前提。

真正的天花板在哪里？他明确指出：并非模型的能力，而是能否构建出有效的 eval。如果你能将“什么是好的输出”编码为二元标签、评分标准或几个核心业务指标，那么整个循环就能在公司规模上顺畅运行。如果不能，即便拥有再强大的模型也无法填补这一空白。

智能体的能力很少是真正的瓶颈。只要你能够将优质输出编码成标签、评分标准或业务指标，循环就可以在整个公司的规模上持续运转。反之，再强的模型也无济于事。编码能力固然有帮助，但并非瓶颈所在；一个能够可靠评估输出优劣的领域专家，完全可以推动整个循环的顺利进行。

07 护城河是什么

这篇文章的最后一句话，值得我们反复品味。

“每个人都拥有相同的模型；操作系统才是真正的秘密武器。”

这句话非常精炼。但读完后的第一反应，并不是“对，我要赶紧去做”，而是——事情真的这么简单吗？

Gershuni 认为，护城河在于纪律——绘制工作地图、构建 context、编写 eval、每周坚持运行循环。对此，我并不完全认同。他将问题框定为“执行纪律”，却遗漏了一个更核心的要素：判断什么值得被编码化本身，就是一种极其稀缺的能力，而这种能力是无法被任何方法论所覆盖的。

大多数创始人往往高估了自己所做工作的战略含量。他们并非不了解 L1 到 L4 的分级方法，而是不愿意承认自己 80% 的时间其实都在做 L3 级别的工作。真正的瓶颈不是纪律，而是对自我认知的诚实度。

而这一点，是没有任何框架能够替代你完成的。

另一个值得深思的问题是：如果操作系统真的是护城河，那么这是否意味着——一旦某家公司的 context 和 eval 积累到了临界点，后来的竞争者便永远无法追赶？这不再是赢家通吃市场份额，而是赢家通吃学习速度本身。先跑起来的公司，每天比你多学一点，而且学习的速度还在不断加速。这不是线性的差距，而是指数级的差距。

历史上，每一个关于“指数差距不可逆”的论断，最终都被某种范式跳跃所打破。这次是否有所不同，目前还很难下定论。

但有一点可以肯定：如果你今天还在争论“要不要使用 AI”，那么你所争论的已经不再是工具选择的问题。不参与的成本，每周都在不断增加——直到某个时间点，你甚至可能连这个代价有多大都感受不到了。

资料来源：cyber.fund · Stepan Gershuni (@cyntro_py) · How to Build an AI-Native Startup · May 2026