为什么我建议起步阶段All-in上下文工程？-育师

为什么我建议起步阶段All-in上下文工程？

本文共 2714 字，阅读预计需要 5 分钟。

Hi，你好，我是Carl，一个本科进大厂做了2年+AI研发后，裸辞的AI创业者。

同样是小团队AI创业，为什么有人18个月估值暴涨25倍，有人却创始人出走、团队动荡？

答案藏在一个选择里：你是造船，还是插杆子？

这篇文章会用三个真实案例告诉你，为什么起步阶段应该All-in上下文工程，而不是自研模型或微调。

一个估值暴涨25倍，一个创始人出走

先说两个真实故事。

2024年8月，一家叫Cursor的AI编程公司完成6000万美元A轮融资，估值4亿美元。16个月后的2025年底，它的估值飙升到99亿美元，ARR突破5亿美元，超过半数财富500强企业在用。

同一个月，另一家明星公司Character.AI的创始人Noam Shazeer宣布离开自己创办的公司，回归Google。这家公司曾在2023年估值10亿美元，被视为AI社交的未来。但高昂的基础设施成本和激烈的竞争让它陷入困境，最终以"技术授权"的形式被Google变相收购。

两家公司都做AI，都拿了大钱，为什么结局天差地别？

核心差异在于技术路线。Cursor从第一天起就选择调用OpenAI、Anthropic、Google的API，把精力放在代码库索引、上下文理解、工作流优化上。而Character.AI选择自研大模型，试图从底层做起。

如果大模型是水，那么他们一个造了船，一个插了杆子。

模型是水，上下文工程是船

这里需要解释一个比喻。

如果把大模型的能力比作水，那上下文工程就是船。水在涨，船也在涨。GPT-3到GPT-5.2，Claude 2到Claude 4.5，基础模型的能力每隔几个月就上一个台阶。如果你的产品建立在"如何更好地使用这些模型"之上，你会自动享受到能力提升的红利。

什么是上下文工程？简单说，就是在调用大模型时，精心设计你给它的信息环境。包括系统提示词怎么写、模型记忆怎么处理、多agent架构怎么设计、工具调用结果怎么组织等等等等。Anthropic在2024年底发布的Agent最佳实践中，把这总结为三个层面：指令上下文、知识上下文、工具上下文。

Andrej Karpathy——前OpenAI研究总监、特斯拉AI负责人——在2025年中期提出了一个观点：在每个严肃的LLM应用中，上下文工程是一门精妙的艺术与科学，核心任务是在正确的时间为每一步填充正确的信息。

造船的逻辑是：我不需要自己造水，我只需要让船能更好地利用水。水涨了，船自然就高了。

自研模型是"杆子"，早晚被淹

那什么是杆子？

杆子是固定在河床上的木桩。水浅的时候，它能露出水面，看起来挺高。但水一涨，它就被淹没了。

自研大模型就是典型的杆子。

Sam Altman公开确认过，GPT-4的训练成本超过1亿美元。这还只是算力成本，不包括数据采集、清洗、标注，不包括顶尖研究员的薪资，不包括试错和迭代。对于绝大多数创业公司来说，这是一个无法企及的数字。

更要命的是，模型在快速迭代。2024年7月，OpenAI发布GPT-4o mini，价格比GPT-4 Turbo便宜了约60倍，性能却更强。你花半年时间、几百万预算训出来的模型，可能在发布那天就被一个API更新打败了。

这就是杆子的命运。水位在涨，你的杆子高度是固定的。

LoRA微调呢？门槛确实低一些，消费级显卡就能跑。但它仍然需要技术团队、需要标注数据、需要调试。更重要的是，你微调出来的模型是绑定在某个基座上的。基座一升级，你的微调可能就不兼容了。

上下文工程不一样。一套好的提示词体系、RAG检索架构、工具调用流程，可以近乎无缝地迁移到下一代模型。这是几近零成本的能力升级。

三个成功案例：Cursor、Perplexity、v0

让我们看看"造船派"都在怎么做。

Cursor：这家公司不训练模型，而是把精力放在"如何让大模型更好地理解代码"。它会索引整个代码仓库，理解文件之间的依赖关系，在你提问时自动检索相关上下文。这就是上下文工程的典型应用。结果是：18个月，估值从4亿美元涨到99亿美元，翻了25倍。

Perplexity：这家AI搜索公司同样不训练基础模型。它的核心能力是RAG——检索增强生成。当你问一个问题，它会先从互联网检索相关信息，再把信息组织成上下文喂给大模型。2025年6月，它的月查询量达到7.8亿次，与Snap达成4亿美元合作，被集成到Firefox、Safari等主流浏览器。

v0.dev：Vercel做的UI代码生成工具。它采用agentic架构，把任务分解成规划、执行、验证多个步骤，每一步都精心设计上下文。从一个想法到一个可运行的React组件，只需要几秒钟。Vercel累计融资超过3亿美元。

这三家公司有一个共同点：它们都没有从零训练自己的基础模型。它们的护城河不是"我有一个别人没有的模型"，而是"我能比别人更好地使用模型"。

风险与盲区：上下文工程不是万能药

说了这么多好处，也得谈谈风险。我并非完全否定微调和自研，而是强调起步阶段应该优先上下文工程。

第一，API依赖风险。把核心能力建立在第三方API上，意味着你被供应商绑架。OpenAI突然涨价、Claude服务宕机、模型能力意外退化——这些都可能让你的产品瘫痪。

规避动作：设计多模型切换架构，同时支持2-3家供应商的API。关键路径做好降级预案。

第二，数据隐私和合规。医疗诊断、金融风控、企业内部文档——这些敏感数据不能上传到第三方API。上下文工程在这些场景下无法施展。

规避动作：敏感场景必须考虑本地部署或私有化方案。可以先用上下文工程验证需求，再针对性地部署本地模型。

第三，深度定制需求。有些垂直领域需要模型深度理解特定术语、格式、逻辑。纯粹靠上下文工程可能效果有限。阿里前阵子开源的smartResume，就是用通义千问0.6B微调做简历优化，效果比纯prompt工程好得多。这种场景下，微调是更优解。

规避动作：跑一段时间数据，发现某个高频场景上下文工程效果不理想时，再针对性微调。关键还是时机和场景。

第四，端侧部署需求。如果你的产品需要在手机、IoT设备上运行，或者对延迟要求极高（<100ms），API调用肯定不行。这时候需要小模型+微调/蒸馏。

规避动作：区分云端和端侧场景。云端优先上下文工程，端侧需要本地模型时，用云端数据做训练集。