Wubuntu Tech & Life

结语 这本书写到这里，该说的都说完了。 回顾一下全书的核心观点： AI 协作的问题根源不在模型，不在工具，在于上下文。 对话不是上下文，Prompt 不是上下文，聊天记录不是上下文。上下文是一个结构化的、可持久化的、可跨任务复用的信息资产。 AI Context Workspace 是一个解决方案的尝试。 它用三层结构（背景、约定、状态）、路由机制（按需加载不搞全量注入）、机器契约（JSON 管状态，Markdown 管说明）和标准工作流（七阶段 + L0-L3 流程等级）来组织上下文。 它不是银弹，不是框架，不是平台。 它只是一个目录结构、一套约定、一个工作流。任何人都可以用，任何项目都可以适配，任何 AI 客户端都可以支持。 最有价值的部分不是技术本身，而是思维方式： 把上下文从对话中剥离出来，独立管理 以 AI 为第一读者设计文档结构 按路由索引，按需加载，不搞全量注入 机器状态用 JSON，人类说明用 Markdown 流程为任务服务，不是反过来 这些思维方式不依赖于任何特定技术，不会因为模型更新而失效，不会因为工具迭代而过时。 最后说一句个人感受。 我写这本书是基于一个判断：当前的 AI 协作方式还处于非常早期的阶段，就像 1990 年代的个人电脑——硬件有了，但软件和服务还在探索中。AI Context Workspace 是我对这个"AI 协作的 Windows 95 时刻"的提前准备。 我不确定这个方向是否正确，但我知道： 把上下文管好，无论如何都不会错。 如果你读到这里，觉得"这个思路有意思"，那我的目的就达到了。如果你在实践中用了这套方法，欢迎告诉我——哪些地方好用，哪些地方需要改进。 这本书永远不会有"完成版"，就像 AI 协作本身一样，还在进化中。

AI Context Workspace 目前是一个"自用"的设计。但它的核心理念——上下文只是文件、按路由索引、按需加载——是通用的，可以成为开放生态的基础。 如果 AI Context Workspace 是一个开放规范，会怎么样？ 不同的 AI 客户端可以互相操作。 你在 OpenCode 中创建的任务上下文，可以在 Codex 中继续，可以在 Cursor 中查看。所有客户端都遵循同一个上下文结构，上下文在不同工具间自由流动。 不同的工具可以围绕它构建生态。 可视化工具可以展示工作区的任务状态图。分析工具可以统计上下文的覆盖率和更新频率。集成工具可以自动从 Issue 导入任务。插件可以自动生成背景文档。 模板市场。 不同领域的上下文模板可以共享和复用。一个前端项目的标准上下文模板，一个数据科学项目的标准上下文模板，一个创业公司的标准上下文模板。用户不需要从零开始，直接从模板市场初始化。 自动化流水线。 CI/CD 可以集成上下文检查。提交代码时自动检查 Artifact 状态，确保没有未完成的活跃任务。发布前自动检查 Review 状态，确保所有任务已通过检查。 这不是空想，这是已经在发生的趋势。 OpenCode 和 Codex 已经支持自定义指令和 Skill 机制 一些团队已经开始用文件系统管理 AI 上下文 社区中出现了各种上下文模板和 Skill 分享 开放生态的关键是协议，不是平台。 AI Context Workspace 不依赖于任何特定平台实现。它是一套文件结构约定和工作流规范。任何实现这个约定的工具都可以互相协作。平台会变化，但文件和目录是操作系统最稳定的抽象。 一个乐观的未来： 五年后，你开始一个新项目，不再需要选择"用什么 AI 工具"。你只需要初始化一个工作区，选择你想要的模板，然后开始工作。你可以用任何 AI 客户端来处理任务，上下文在文件系统中统一管理。你的上下文积累不只是对当前工具有效，而是对所有工具有效。 这就是"上下文优先"的未来。 不是工具决定上下文，是上下文决定工具。工具可以换，上下文不能丢。

2026 年 9 月中旬，一个叫 Jev 的模型在 AI 圈刷屏。它来自创业公司 TypeSafe AI，创始人之一是 ChatGPT 的共同发明人。而它最反常识的地方是：不生成任何文本。 传统大模型的接口是消息进、文本出，Jev 是材料进、判断出：state 加 questions 进，类型化答案、概率和置信度出。一次请求可以带多个问题，并行求值，互不干扰。 问题只有三种原语：noul 是非题，返回 0 到 1 的概率；choice 从固定选项里选一个；score 按有序标尺评分。比如三档低中高返回 1.97，对应分布是低 0、中 0.03、高 0.97，所以真正该读的是概率分布，不是那个分值。 把它的每一块拆开，都是旧的：判别式分类、概率校准、风控的拒绝推断、zero-shot 分类、意图识别，它没有发明任何一块。唯一可辩护的新位置是：把判定标准从训练资产变成请求参数。 过去这两件事是互斥的：要可靠就训分类器，标准冻结在标签里；要灵活就调大模型，标准变成 prompt，代价是延迟和成本。Jev 赌它们可以不互斥——名字里的杰文斯，说的就是判断更便宜，不是模型更聪明。 官方站点还在白名单，但 OpenRouter 已经上架，用现有账号就能调。我实测多次：端到端延迟 303、395、946 毫秒，含跨境网络往返；单次成本约 $0.00002，1 美元大约能跑 5 万次判定。 一次真实的客服工单判定里，urgency 是 0.98，department 选中 technical。confidence 和 probabilities 是两件事：前者是判断有多可靠，后者是选项怎么分布，自动化阈值通常看 confidence。 两个实测发现。语言上，官方文档说主训练语言是英文，CJK 可用但准确率较低，稳妥做法是材料保留原文、判定标准用英文写。确定性上，同一输入两次跑出 0.06 和 0.05，所以阈值不要卡在 0.5，要么留缓冲带，要么多次采样。 state 支持三种形态：string、object 和 array。object 是官方推荐的默认形态，因为命名字段本身就是信息，问题可以用反引号写路径，精确指向具体字段。我实测确认：数字、布尔、null 和三层嵌套路径都支持。 设计原则有三条：判断标准放 instructions，被比较的事实放 state...

当 AI 上下文管理从个人扩展到团队，再从团队扩展到组织，它就不再只是一个效率工具，而是一种 组织知识资产 。 想象一下一个组织积累了五年 AI 上下文后的样子： 每一个项目都有完整的背景文档，记录了当时的业务环境、技术选型、关键决策 每一个任务都有 Artifact，记录了从需求到交付的完整过程 每一次失败都有 Review 记录，分析了失败原因和教训 每一次成功都有摘要，总结了关键因素和可复用的经验 这是比 Wiki 更强大的知识库。 Wiki 里的知识是"人主动写的"，而 AI Context Workspace 里的知识是"做事过程中自然产生的"。前者需要额外投入，后者是工作副产物。副产物通常比主动产出的知识更真实、更完整——因为它记录的是实际发生了什么，而不是人回忆起来应该写什么。 组织级别的上下文管理面临几个挑战： 第一，规模。 一个组织可能有成百上千个项目，每个项目有几十个 Artifact。如何让 AI 在这么大的上下文中找到需要的部分？答案还是路由——分层索引，按需加载。组织级路由索引项目级路由，项目级路由索引任务级路由。 第二，权限。 不是所有上下文都对所有人开放。财务相关的背景、人事相关的决策，需要访问控制。文件系统的权限模型天然支持这一点——目录级别、文件级别的读写权限。 第三，标准化。 组织需要统一的上下文结构规范，否则不同团队产生的上下文无法互操作。A 团队用的工作流阶段定义和 B 团队不同，AI 就无法统一理解。标准化的程度决定了上下文的可复用程度。 第四，生命周期。 项目结束后，上下文应该保留多久？保留在哪里？归档策略在组织层面需要更明确的规则。不是所有上下文都需要永久保存，也不是所有上下文都可以随时删除。 当这些挑战被解决后，组织拥有的是一个"AI 可读的组织记忆"。 新员工加入时，不需要花两个月理解项目背景。新 AI 接入时，不需要从头开始了解组织。所有的信息都在上下文里，按需读取，随取随用。 组织知识管理一直以来的难题是"如何让人愿意写文档"。 AI Context Workspace 的答案是： 让人不需要专门写文档，文档是工作的副产物。 你做事，AI 记录上下文；你完成，AI 归档上下文；你回顾，AI...

一个人用 AI 做事，和十个人用 AI 协作，复杂度不是一个数量级。 个人的上下文管理相对简单。 你一个人决定背景怎么写、约定怎么定、任务怎么排。没有冲突，没有分歧，不需要同步。一个人用 AI Context Workspace，核心是"让 AI 理解我的项目"。 团队协作要让 AI 理解"我们"的项目。 "我们"意味着：背景知识需要共享，约定规范需要一致，任务分配需要透明。AI 需要知道每个成员的角色、当前的工作状态、团队的决策惯例。 团队场景下的 AI Context Workspace 需要增加几个维度： 共享背景。 团队背景由多个人共同维护。背景文档不再是"我的理解"，而是"团队的共识"。任何变更需要沟通和协调。这可以通过 Git 的 Pull Request 流程来实现——修改背景文档，提 PR，review 后合并。 一致约定。 团队约定需要明确对齐。代码风格、工作流、质量标准，这些在个人场景中可能靠默契，在团队场景中必须显式化。约定文档是团队的"宪法"。 任务透明。 团队中每个人都在做自己的任务，但 AI 需要了解全局。 artifacts/index.json 在团队场景中变得更重要——它不仅是任务列表，也是团队协作的仪表盘。谁在做什么？哪个任务被阻塞了？哪些任务即将完成？一眼可见。 角色感知。 不同角色需要不同的上下文。后端开发者不需要前端的详细背景，反之亦然。但所有角色需要共享"这个项目在做什么"的顶层理解。路由机制可以按角色分类上下文，让每个 AI session 只加载和角色相关的部分。 从个人到团队，不是简单地把一个人的工作区复制给多个人。 团队协作需要解决冲突、同步、权限、分工等问题。AI Context Workspace 目前的设计主要面向个人场景，但它的结构天然支持团队化——因为所有内容都是文件，文件可以被 Git 管理，可以被多人编辑，可以被权限控制。 一个可能的团队协作场景： 团队有一个共享的 Git 仓库，包含工作区的所有文件 每个成员在自己的分支上工作，创建自己的 Artifact 共享背景在 main 分支上，由核心成员维护 任务完成后，提交...

本文是「AI 低成本」系列的第 8 篇（共 8 篇）。 先问自己：哪些任务会被接管 普通人关心 AI，最直接的念头不是模型有多少参数，也不是 GPU 卖多贵，而是自己的饭碗会发生什么变化。 这个问题没法用“取代”或“不取代”这种非黑即白的结论来回答。技术变革的逻辑通常是： 先改变具体任务，再改变岗位职能，最后重塑整个行业结构。 一个职业不会在某一天突然消失，但其中的许多工作任务会先被软件接管、压缩，或者被重新定价。 那些最容易受影响的任务，往往有几个共同特征：重复性高、规则明确、结果易于检查，且交付物主要是文字、图片、表格或代码。 比如基础文案撰写、简单翻译、会议纪要整理、资料搜集、标准客服、低复杂度的设计、初级代码编写、基础财务核对、简历筛选以及报表生成，这些都属于 AI 容易切入的领地。这些活儿未必会彻底消失，但市场价格和用工需求肯定会发生变化。 相对安全的工作，特征也同样清晰。那些需要现场负责、复杂沟通、跨部门协调、真实世界操作、合规签字、非标准判断以及建立长期信任的工作，短期内很难完全交给 AI。医生、教师、律师、工程师、销售、管理者、维修人员和项目负责人，未来都会把 AI 当成工具，但 最终对结果负责的人依然不可替代 。 真正的区别在于：擅长使用 AI 的人会处理更多任务，而不碰 AI 的人可能只剩下那些低价值的环节。 切入点不是算法，是工作流 很多人有个误区，觉得进入 AI 时代就得去学算法、练模型、写底层代码。事实上，对大多数人来说，切入点不在于研究模型本身，而在于学会用模型来重组自己的工作流。 一个财务人员如果能用 AI 整理凭证说明、生成报表草稿、排查异常数据，再结合专业经验进行复核，效率会大幅提升； 一个销售如果能用 AI 分析客户背景、生成沟通方案、管理跟进记录，就能从重复劳动中解脱出来。 AI 素养的四件事 谈到 AI 素养，得把它落到实处： 学会拆解任务。 别总扔给 AI 一个大而化之的问题，得把目标、背景、条条框框、输出格式还有评价标准都交代清楚。 有校验意识。 AI 吐出来的东西不一定全对，尤其在法律、医疗、财务或专业技术这些硬核领域，必须核实出处。 管理好资料。 给 AI 喂什么质量的料，它就出什么水平的活。企业内部文档、历史案例和数据表整理得越顺，AI 就越好使。 设计好流程。 ...

本文是「AI 低成本」系列的第 3 篇（共 8 篇）。 一次震动，和一个老问题 2025 年前后，全球 AI 圈子里最剧烈的一次震动，莫过于低成本模型的崛起。随着 DeepSeek-R1 等模型走进大众视野，外界开始重新审视一个老观点：想要拥有高端 AI 能力，是否一定得靠天量资金和顶级 GPU 集群去堆？ 这个问题引发的连锁反应，远比单个产品本身要深远得多。 DeepSeek 之所以能引起这么大的关注，原因有这么几点： 它在推理、数学、代码等硬核任务上，已经逼近了国际顶尖水平； 部分模型开放了权重，让开发者和企业能直接拿来研究、部署甚至改造； 它的 API 调用价格明显比许多闭源竞品便宜； 技术报告里披露的训练成本，远低于大家对头部闭源模型的一贯估算。 先把三个概念理清楚 讨论“AI 到底贵不贵”之前，得先分清三件常被混为一谈的事： 概念 含义 发生时间 训练成本 模型从海量数据里学本领时花的计算开销 模型上线前 推理成本 用户每问一次、模型每答一回所消耗的算力 产品运行中 API 价格 服务商向用户收的钱 与真实成本有关，但不等同于全部成本 完整的账单里，还得算上研发人员工资、数据采购、带宽运维、办公折旧，以及安全合规等各项支出。 557.6 万美元为什么成了焦点 DeepSeek-V3 的技术报告曾提到，其训练成本大约是 557.6 万美元。这个数字一下子成了舆论焦点，因为外界对那些头部闭源模型训练成本的估算，动辄就是几千万美元甚至更高。 与此同时，DeepSeek 对外提供的调用价格也显著低于 OpenAI、Anthropic、Google 等大厂的主力模型。官方还曾披露过，在某次 24 小时推理系统的测算中，理论收入明显高于租用 GPU 的成本。 虽然这不算一份完整的财报，但它指明了一个重要方向： 模型服务的单位经济效益正在出现新的可能。 低成本到底从哪儿来 答案是算法选择、模型结构、训练流程、通信优化、显存管理以及工程调度等一系列环节优化组合后的结果。 MoE：让每次计算只激活一部分参数 稀疏混合专家模型（MoE）提供了一个非常关键的思路。传统的大模型在每次计算时，往往需要调动全身的参数，这背后的成本极其高昂。而混合专家模型则像是把任务分包给多个专家子网络，...

本文是「AI 低成本」系列的第 7 篇（共 8 篇）。 绕不开的中国话题 聊 AI 竞争，中国是一个绕不开的话题。这不仅仅是因为我们市场大、科技公司多，更关键的是，当 AI 从实验室的科研成果转向复杂的产业系统时，中国拥有一套独特的“组合拳”： 规模庞大的工程人才； 成熟的制造供应链； 海量的互联网用户； 丰富的数字化场景； 电力与新能源的基建优势； 政策的推力； 极其残酷的商业竞争环境。 当然，我们面临的限制也摆在明面上。 限制：高端芯片的约束 高端 GPU 长期受出口管制，在先进制程、先进封装、高带宽显存以及软件生态上，我们确实还有差距。像 H100、A100 这些顶级芯片没法自由购买，部分“特供版”芯片性能又打了折扣。 虽然国产 AI 芯片在追赶，但硬件性能、开发工具的易用性、生态兼容性以及大规模运行的稳定性，这些都需要时间去磨。 但这种限制也逼出了一项本事，那就是中国 AI 公司对“效率”近乎执着的追求。既然没法无限量地挥霍顶级芯片，那就只能在算法效率、工程调度和硬件利用率上死磕。DeepSeek 之所以能引起这么大的关注，正是因为它证明了在有限的约束条件下，依然能跑出高产出的路径。这条路走起来并不轻松，它背后靠的是顶尖的研究能力、深厚的工程积累和对开源生态的利用。 人才、市场、制造：三个关键变量 人才 人才其实是中国 AI 版图里最重要的变量。全球的 AI 研究圈子，华人和中国背景的研究者占比极高，无论是在 Google、OpenAI、Meta、Anthropic，还是英伟达和各大高校实验室，到处都有他们的身影。 AI 从来不是关起门来就能搞定的技术，它高度依赖全球范围内的论文分享、开源框架、学术交流和跨国协作。中国拥有如此规模的研究者和工程师储备，这意味着在这一轮技术大潮中，我们注定不会缺席。 市场 中国拥有海量的用户基础、丰富的应用场景以及极高强度的商业竞争。无论是电商、短视频、移动支付，还是外卖、物流、网约车，亦或是智能汽车、工业制造和在线教育，这些领域都积累了庞大的数字化数据和成熟的业务流程。 在这样的环境下，一项 AI 能力只要能降低成本，企业很快就会拿来测试；只要能提升转化率或效率，竞争对手立马就会跟进。 制造 AI 产业的版图里不只有大模型，还涵盖了服务器、机柜、光模块、PCB、电源、储能...

本文是「AI 低成本」系列的第 2 篇（共 8 篇）。 GPU 和 CPU，干的不是一种活 高端 GPU 之所以卖得贵，首先是因为它干的活儿跟普通计算设备完全不同。 CPU 像是个全能管家，擅长处理复杂逻辑和通用任务，运行操作系统、数据库和各种业务程序都不在话下；GPU 更像是一个超级方阵，擅长同时处理海量的相似计算，非常适合图形渲染、科学计算和大模型训练。 大模型训练本质上是对海量矩阵进行枯燥的重复运算，GPU 这种并行计算的天赋就成了胜负手。 拿英伟达的 H100 来说，它是专门为数据中心和 AI 训练而生的。它的核心价值不只是单张卡的峰值算力，更在于显存容量、显存带宽、张量计算单元、互联能力，以及那套护城河般的软件生态。虽然消费级显卡也能凑合算，但在高精度计算、长时间稳定性、多卡互联以及数据中心管理这些“硬指标”上，跟企业级 GPU 完全不是一个量级。 模型训练从来不是单打独斗，最烧钱的地方其实在于： 成千上万张卡如何像一支军队那样高效协同。 3.5 万到 4 万美元，贵在哪里 一张高端 GPU 能卖到 3.5 万到 4 万美元，这个价格里包含了先进制程、复杂封装、昂贵显存、板卡设计、散热方案以及供应链的稀缺性。 它的芯片面积巨大，塞满了计算单元，还必须配上高带宽显存。对 AI 训练而言，高带宽显存是命门，因为模型参数和中间结果需要极速读写，一旦带宽跟不上，训练速度就会被活生生拖慢。 不过，买到 GPU 仅仅是个开始。 从一张卡到一座智算中心 企业把卡买回来后，还得配齐 CPU、主板、内存、存储、网络交换机、配电设备、机柜、散热系统、监控系统以及调度软件。 规模是这么堆起来的： 八张 GPU 才能凑成一台 AI 服务器； 几十台服务器才能填满一个机柜区； 更多的机柜组合在一起，才叫智算中心。 到了这一步，问题已经不再是简单的买硬件，而是一场复杂的系统建设工程。 四笔隐形账单 电力 在数据中心的世界里，电力是最让人无法忽视的存在。GPU 全速运转时功耗惊人，多卡服务器没日没夜地工作，散发出的热量简直像个大火炉。 为了伺候这些“电老虎”，电力供应必须稳如泰山。机房里通常要配齐不间断电源（UPS）、储能设备和一套极其复杂的配电系统，就怕电压抖一下影响了计算。毕竟，训练任务一旦中途断掉，损失的不只是时间，还有大把的真金...

本文是「AI 低成本」系列的第 6 篇（共 8 篇）。 演示效果惊艳，不等于能用进业务 很多人初次接触大模型时，都会被它写文案、画图、改代码、做总结的本事惊艳到。但在新鲜感过后，企业往往会抛出一个更现实的问题：这套能力能不能融入每天的业务流程，能不能实实在在地帮我省钱或者多赚钱？ AI 应用的难点，往往就卡在这里。 一个模型在演示时效果惊艳，并不意味着它能直接搬进公司的系统。企业级应用需要考虑权限管理、数据安全、结果审核、流程衔接，还有员工培训和责任划分。 错误代价也是分级的： AI 写一段营销文案，写错了代价也不大； 如果 AI 是去生成一份合同意见，出错的成本就太高了； 要是 AI 参与到医疗诊断、金融授信、自动驾驶或工业控制中，任何失误都可能引发法律纠纷或安全事故。 应用扎得越深，门槛就越高。 落地的三个判断条件 AI 应用能否真正落地，通常要看三个条件： 条件 决定什么 任务是否高频 省下的成本够不够明显 流程是否相对标准 模型处理起来稳不稳定 结果是否容易验证 企业能不能控制住风险 像客服、销售线索整理、文档摘要、会议纪要、知识库问答、代码辅助以及质检标注这些任务，之所以能率先落地，正是因为它们足够高频、重复，而且结果好坏一眼就能看出来。 谁先被改变 办公软件：最容易感知的切入口 员工每天都要写邮件、做 PPT、整理会议纪要、查询资料或者分析表格，AI 的介入能大幅缩短打初稿的时间，免去那些枯燥的重复劳动。 它虽然不会直接让某个岗位消失，但会重塑岗位内部的任务结构。以前一个助理可能要花半天时间去翻找和整理材料，现在 AI 能先把框架搭好，人只需要负责校验、补充和最后拍板。 软件开发：高频中的高频 大模型现在能补全代码、解释报错原因、生成测试用例，还能帮忙迁移脚本和整理文档。 对于那些经验丰富的工程师，AI 提升的是检索信息和写初稿的速度；但对于初级程序员来说，它减少了大量练手的重复编码机会，无形中也拉高了入行的门槛。未来，企业会更看重那些能定义问题、审查代码质量、理解底层架构并敢于对结果负责的人。 内容和设计：低难度环节在贬值 AI 生成图片、视频、配音、海报、分镜图和产品草图的能力进化得太快了，这导致大量低难度的制作环节变得不再值钱。 客户对交付速度的要求越来...

本文是「AI 低成本」系列的第 1 篇（共 8 篇）。 聊天框背后，是一场重资产投入 普通人接触 AI，通常就是面对一个简单的聊天框。随手打个问题，几秒钟答案就出来了。 但对企业来说，每一次对话背后，都有服务器在疯狂运转；每一张图片或视频的生成，都在实打实地消耗显卡寿命、电力、存储和网络带宽；而每一次模型的迭代升级，都意味着训练、数据和工程成本的又一轮激增。 这正是 2024 年以后，大众对 AI 最容易产生误解的地方： 用户这一端的操作体验越来越傻瓜化，产业那一端的投入筹码却越来越沉重。 很多人想当然地觉得，AI 不就是一个应用软件吗？下载注册、输入指令不就能用了。但对模型公司和云服务商而言，AI 本质上是一套超高强度的计算系统，它的成本会随着用户规模、模型体量以及生成内容的长度而不断波动。 算力到底指什么 所谓算力，通俗点讲就是计算的能力。大模型想要搞定语言理解、画图、写代码或者数学推理，就得在海量参数之间进行高速运算。 可以把参数看作模型在“闭关修炼”中总结出来的变量，它们记录了语言、图像、声音和知识逻辑里的各种规律。参数规模越大，模型的表达潜力就越强，训练和运行它所耗费的计算量也就越惊人。 在大模型竞争的早期，业内有一条被反复验证的“金科玉律”： 只要模型规模、训练数据和计算量同步增长，模型的能力通常就会水涨船高。 这个规律让全球科技公司达成了一个共识： 谁手里攥着的先进 GPU 更多，谁就能更快练出更大的模型； 谁能盖起更庞大的算力集群，谁的产品迭代就能更频繁； 谁能扛得住高昂的电费和云计算开支，谁就能在用户服务上撑得更久。 训练成本和上线后的持续消耗 这种判断并非空穴来风。自从 ChatGPT 火遍全球，顶级模型的训练成本就开始一路狂飙。 模型从只会写文章、搞翻译、陪聊天，进化到能写代码、解数学题、做科学问答，甚至实现多模态生成和复杂推理，每一步进阶背后都是对计算资源的巨大渴求。练一次模型可能要耗时数周甚至数月，动用成千上万张高端 GPU。 而且模型上线后还没完：用户每天的每一次调用，都在持续烧掉算力。 这也解释了为什么 GPU 会一夜之间从电子产品变成战略资源。以前，显卡大多出现在游戏玩家、图形工作站或者科研机构的谈资里；而现在，高端 GPU 直接决定了 AI 模型的训练速度、推理成本、产品稳不稳定以及企业能...

本文是「AI 低成本」系列的第 5 篇（共 8 篇）。 决定天花板的是数据 AI 模型的学习能力再强，也得有“燃料”。 没有数据，模型就摸不到语言、视觉和行业的门道； 数据质量太差，模型学到的全是错误、废话和噪声； 数据权属要是扯不清楚，训练和商业化迟早会撞上法律的高墙。 虽然算力和算法总是占领新闻头条，但真正决定模型天花板能有多高的，其实是数据。 过去这几年，大模型基本是靠着互联网上的公开文本、代码、网页、书籍、论文，还有各种论坛问答给“喂”出来的。这种海量数据的灌溉，确实让模型变得博学多才。但问题也随之而来：高质量的公开文本并不是取之不尽的。有研究机构曾预测，按照现在这个扩张速度，AI 训练可能在几年内就会触碰到公共在线文本的供应上限。 虽然这个时间点未必精准，但大趋势很明确： 公开文本数据的边际价值正在不断缩水。 为什么公开数据不够用了 数据边界的出现，有三个原因： 内容重复。 模型已经读过太多雷同的网页，再往里塞类似的东西，能力的提升微乎其微。 质量问题。 互联网上充斥着错误信息、牛皮癣广告、低质的洗稿文和机械重复的内容，如果不经过严苛清洗，反而会带偏模型的判断。 版权和隐私红线。 无论是书籍、新闻、图片、音乐，还是代码和个人数据，都涉及复杂的权利边界。 当公共文本的增长慢下来，AI 必须寻找新的水源。 四个新方向 多模态数据 第一个突破口是文字之外的图像、音频、视频、传感器以及行为数据。如果模型想要真正理解现实世界的任务，光靠读文字是远远不够的。 医疗影像、工业质检图、自动驾驶的视频流、机器人的传感器读数、课堂上的互动音频，甚至是金融交易记录，这些都将成为下一阶段模型进化的关键养料。 高质量行业数据 通用模型聊聊常识还行，但真要问它某家医院的诊疗细节、某个工厂的设备参数、某家银行的风控逻辑，或者某所学校的教学进度，它就未必懂了。 这些行业数据通常不公开，格式杂乱，权限极严，清洗起来成本很高。未来，谁能合法、安全且持续地整合这些深层数据，谁就能训练出真正好用的行业模型。 交互产生的数据 当模型投入实际应用后，它会收到用户的反馈，记录任务的成败，从而积累新的样本。 比如，客服模型能根据用户满意度来优化话术，自动驾驶系统能根据复杂路况更新策略，工业机器人则能根据生产线的反馈调整动作。这时候，数据不...

本文是「AI 低成本」系列的第 4 篇（共 8 篇）。 训练和推理，先分清 想要看清 AI 未来的成本走向，得先分清“训练”和“推理”： 训练 是模型学习的过程； 推理 是它回答问题的过程。 过去，大家的目光总盯着训练，毕竟动辄投入海量算力去练个大模型，听起来就很震撼。但现在，推理正变得愈发关键，甚至会成为许多企业账单上最沉重的那一笔。 推理模型改变了计算逻辑 传统的大语言模型在回答问题时，逻辑比较直接：根据你输入的内容，利用训练时形成的知识储备，快速预测下一个词或片段。你问它一个事实，它给你答案；你让它写段文案，它吐出文本。这个过程虽然也费算力，但单次计算的消耗相对还在掌控之中。 而现在的推理模型引入了全新的计算逻辑：面对复杂难题，模型不再急于给答案，而是在开口前先进行多步中间计算——拆解问题、尝试路径、校验结果，最后才输出。这种能力通常和链式思考、强化学习以及自我校验挂钩。 用户在界面上可能只看到最终结果，或者一段简化的思考路径，但在看不见的后台，模型其实已经疯狂计算了很久。 这种转变意义重大。以前，算力大头都花在模型“出厂”前的训练阶段，一旦练好，用户调用起来并不贵。但推理模型出现后， 算力消耗的一部分转移到了用户交互的过程中 。问题越复杂、推理步数越长、输出内容越多，推理成本就越高。 如果一家企业大规模用推理模型来处理合同、写代码、分析财务或者搞科学计算，那日常的运营成本会显著攀升。 一个请求，可能触发一串计算 拿办公场景举个例子。普通模型接到“总结会议纪要”的任务，可能只是压缩一下文字，列出要点。但推理型系统接到“根据纪要生成项目计划并检查风险”的任务时，它会： 先读懂纪要，识别出任务、负责人、时间点和依赖关系； 再去检索历史资料，判断资源是否冲突； 生成计划； 最后自查有没有遗漏。 这一个请求背后，可能触发了多次模型调用、检索和工具操作。每走一步，都是在烧钱。 这正是为什么 AI 智能体现在这么火。智能体不只是陪你聊天，它能根据目标自己规划步骤、调用工具、读文件、写代码、翻数据库，甚至操作软件，并根据反馈随时调整。它的能力越强，后台的计算量就越大。一个智能体忙活十分钟完成一项任务，背后可能调用了模型几十次。 当 AI 从简单的问答工具深度嵌入工作流，推理成本就不再是单次回答的小钱，而是整套任务的巨额开支...

在当前的 AI 生态中，上下文是"prompt 的一部分"。你写 Prompt，AI 回复。上下文混在 Prompt 里，用完就丢，下次重新写。 未来，上下文应该从 Prompt 中独立出来，成为一等公民。 什么是"一等公民"？就是它有自己的生命周期、自己的格式、自己的管理方式，而不是依附于某个对话或某个 Prompt。 可以类比的是代码和注释的关系。 早期编程，代码和注释写在一起，注释散落在代码行间。后来人们发现，代码需要独立的版本管理、独立的组织结构、独立的测试。注释也演化出了 Javadoc 之类的独立文档系统。没有人在写代码时把文档手打进代码里——那是不可维护的。 上下文也一样。现在"把上下文手打进 Prompt"就是那个不可维护的阶段。 上下文作为一等公民意味着什么？ 第一，可组合。 上下文不再是"一块"，而是"多块"。一个任务需要背景 A、约定 B、当前状态 C。你可以组合这三块，而不需要把 A、B、C 合并成一大段文本。组合是灵活的，按需的。 第二，可版本化。 上下文变了，你有记录。上一次的背景和这一次的背景有什么不同？谁改的？为什么改？这些问题有迹可循。 第三，可复用。 同一个上下文可以在多个任务中使用。不需要每次重复。项目 A 的背景和项目 B 的背景不同，但同一个项目内的所有任务共享同一个背景。 第四，可移交。 上下文可以在不同的 AI 客户端之间传递，可以在不同的人之间传递，可以在不同的时间点之间传递。人换了、AI 换了、时间过了，但上下文还在。 AI Context Workspace 是这个趋势的早期实践。 它把上下文从"对话的附属品"变成了"文件系统的结构"。文件系统是操作系统中最基础、最稳定、最通用的抽象。任何能运行操作系统的设备都能读文件。把上下文放在文件系统里，就是给了它最广泛的可移植性。 这不是终点，这是起点。 当越来越多的人和组织采用类似的方法，上下文的结构、格式、交换协议可能会标准化。到那时，你可以在不同的 AI 平台之间自由迁移上下文，就像今天在不同 IDE 之间自由迁移代码一样。 上下文作为一等公民，这个趋势刚刚开始。

AI 客户端市场正在快速变化。ChatGPT、Claude、Gemini、Cursor、Copilot、Codex、OpenCode……每个客户端都有自己的优势，但没有一个能覆盖所有场景。 AI Context Workspace 的立场很简单：不绑定任何客户端。 因为上下文只是文件，任何能读文件的 AI 客户端都能用。不需要插件，不需要集成，不需要适配。 不同客户端的用法： 支持自定义指令的客户端（如 OpenCode、Codex）。 这些客户端允许你配置入口文件路径。你把 AGENTS.md 的路径配进去，客户端启动时自动读取，AI 自动理解工作区结构。这是最深的集成方式，几乎无感。 支持文件系统的客户端（如 Cursor、Copilot）。 这些客户端可以直接读取项目目录。你打开工作区目录，AI 能看到所有文件。你可以手动引导 AI 读取入口文件，效果一样好。 对话型客户端（如 ChatGPT、Claude Web）。 这些客户端不直接访问文件系统，但你可以把入口文件的内容粘贴到对话中。AI 读完路由表后，你可以按需把 background/ 或 conventions/ 的内容粘贴给它。虽然不如文件系统集成方便，但上下文结构还是一样有效。 不绑定客户端的好处： 首先， 你不需要为了工作区换客户端。 你现在用 Cursor，可以继续用 Cursor。你明天想换 OpenCode，工作区不需要任何改动。 其次， 你可以同时使用多个客户端。 同一个工作区，早上用 ChatGPT 做头脑风暴，下午用 Cursor 写代码，晚上用 Codex 做自动化。每个客户端读到的是同一个上下文，输出保持一致。 最后， 你不用担心客户端倒闭。 今天最好的 AI 客户端，三年后可能就没了。但你的工作区只是文件，只要文件系统还在，上下文就还在。 "上下文优先于客户端"是这个设计的基本态度。 大多数人选择 AI 客户端时，考虑的是模型、功能、价格。这些当然重要，但更重要的是： 这个客户端能不能让我的上下文持续积累？ 如果一个客户端不能让你积累上下文，做得再好也是暂时的。下一次对话、下一次换工具，一切归零。而 AI Context Workspace 不会让你归零。不管你用什么客户端，上下文都在文件里，一直在那里。

Obsidian 是个人知识管理工具，AI Context Workspace 是项目上下文管理工具。它们解决不同的问题，但可以互相补充。 Obsidian 管"我学过什么"。 你用 Obsidian 记笔记、做知识整理、建立双向链接。笔记按你的认知结构组织，按你理解世界的方式连接。Obsidian 是"人的大脑的外挂"。 AI Context Workspace 管"AI 现在需要知道什么"。 工作区按项目任务组织，按 AI 的读取方式结构。每个文件只包含当前项目需要的信息，按路由索引，按需加载。工作区是"AI 的上下文的外挂"。 两者可以互相引用。 一个典型的场景：你在 Obsidian 里有一篇笔记，记录了某个技术方案的调研结果。现在你在做一个项目，需要 AI 理解这个方案。你不需要把笔记内容复制到工作区里，只需要在工作区的 background/ 中引用 Obsidian 笔记的路径。 <!-- background/tech-decision.md --> ## 技术方案：选择 Meilisearch 作为搜索引擎 详细调研记录见：[[obsidian-vault://projects/search-engine-research]] AI 读取这个路径后，可以找到对应的 Obsidian 笔记，读取详细内容。这样，Obsidian 笔记仍然是你的知识资产，工作区只需要引用它。 职责分离，但信息互通。 Obsidian 里放的是"你学到的东西"——知识，跨项目的，长期积累的 工作区里放的是"AI 需要知道的东西"——上下文，项目相关的，按任务组织的 两者重叠的部分是"当前项目相关的知识"。这些知识在 Obsidian 里有一份完整版，在工作区里有一份精炼版。完整版适合人类学习，精炼版适合 AI 快速理解。 如果你不想维护两份，也不用担心。 工作区的背景文档可以直接用 Obsidian 格式写（Markdown 双链语法），然后让 AI 在工作区里读取。你不需要在 Obsidian 和工作区之间做选择，它们可以共存。 一个更高级的用法： 用 Obsidian 作为你的...

AI Context Workspace 和 Git 不冲突，它们解决的是不同的问题。 Git 管历史。 Git 记录的是"谁在什么时候改了什么、为什么改"。每次 commit 是一个快照，记录了文件从一种状态到另一种状态的变迁。Git 回答的是"怎么变成这样的"这个问题。 AI Context Workspace 管现场。 工作区记录的是"AI 在当前任务中需要知道什么"。它回答的是"现在是什么情况、接下来该做什么"这个问题。 两者可以共存于同一个 Git 仓库。 工作区里的文件—— background/ 、 conventions/ 、 artifacts/ ——都是普通文本文件，可以被 Git 跟踪。你提交代码时，顺带提交了上下文的变化。别人（或另一个 AI）克隆仓库时，既拿到了代码，也拿到了上下文。 一个典型的协作流程： 你在工作区开始一个任务，创建 Artifact，写需求文档 AI 执行任务，修改代码，更新 Artifact 状态 你审查结果，确认通过，归档 Artifact 你用 git add 和 git commit 提交所有变更——包括代码修改和上下文更新 别人（或别的 AI）克隆仓库，打开工作区，看到归档的 Artifact，知道"这个任务完成了，做了这些事" Git 不管理上下文，但 Git 可以管理上下文文件。 这个区别很重要。Git 不会帮你理解项目，但 Git 可以帮你版本化管理描述项目的文件。AI Context Workspace 负责生成和维护这些描述文件，Git 负责给它们做版本控制。 用 Git 管理上下文文件的好处： 你有完整的历史记录。可以回溯到任何时间点，看当时的上下文是什么 你可以分支。在 feature 分支上试验新的上下文结构，不影响主分支 你可以协作。多人共用一个 Git 仓库，上下文同步更新 所以，不要把 AI Context Workspace 和 Git 对立起来。 它们是互补的。Git 提供了底层的版本管理，AI Context Workspace 提供了上层的上下文组织。你可以用 Git 管理整个工作区，包括代码和上下文。也可以把上下文放在单独的仓库里...

AI 协作中最让人头疼的场景之一：你做了一个项目，放了半年，回来继续做，发现 AI 什么都不记得了。 你打开一个新的对话，说"我们继续做之前的项目"——AI 一脸茫然。你开始复述项目背景、技术选型、之前做了什么、接下来要做什么。复述了半小时，AI 终于进入了状态。 AI Context Workspace 就是为了解决这个问题而设计的。 半年后，你回来，打开工作区，AI 读取： AGENTS.md ——工作区结构，每个目录是干什么的 background/ ——项目背景，技术选型，领域知识 conventions/ ——工作规范，代码风格，质量标准 artifacts/index.json ——当前活跃任务列表 每个活跃任务的 artifact.json ——做到哪了，什么状态 已归档的 archive/summary.md ——之前完成了什么，关键决策是什么 整个过程不需要你说一句话。AI 读完这些文件，就恢复了所有的上下文，可以无缝继续工作。 这就是"上下文可持久化"的价值。 你不需要记忆，AI 不需要重训。工作区里的文件就是持久化的上下文。任务暂停了，状态写在 artifact.json 里。任务完成了，摘要写在 summary.md 里。背景变化了，更新在 background/ 里。 交接也是一样。 如果你需要把项目交接给另一个人（或另一个 AI），直接把工作区给他。他打开工作区，读一遍文件，就获得了你当时的所有上下文。不需要开会，不需要写交接文档，不需要口头解释。 这种"交接"甚至不需要人在场。 你可以把工作区放在 Git 仓库里，新的 AI 客户端克隆下来，就能开始工作。这就是 AI 时代的"交接"——不是把人叫来开会，是把上下文交给文件系统。 上下文管理最好的状态是：你觉得它不存在。 当你习惯了工作区的工作方式，你不会觉得"我在管理上下文"，你只是"在做项目"。上下文的管理是自动的、无感的。你写文件，AI 读文件，上下文自然流动。 这就是为什么 AI Context Workspace 最终可以让你放下半年，拿起来继续。因为上下文不在你的脑子里，也不在 AI 的对话历史里，它在文件里。

一个任务太大怎么办？比如"重构整个项目的前端架构"。这个任务如果作为一个 Artifact 来做，会非常痛苦：上下文太长，AI 会迷失，检查无从下手，完成遥遥无期。 解决方案：拆。 把一个大的任务拆成多个小的子任务，每个子任务有自己的 Artifact，独立推进，独立检查。 怎么拆？ 看两个维度： 依赖关系 和 风险等级 。 依赖关系：A 必须在 B 之前做。比如"先定义组件接口"才能在"重构具体页面"时使用。 风险等级：高风险的部分先做，因为一旦发现不可行，可以及时调整方向，不至于白费功夫。 拆好之后，用父任务来编排。 父任务不直接执行，它的职责是： 1. 定义总目标，拆成子任务 2. 确定子任务的执行顺序 3. 在每个子任务完成后，检查是否符合整体设计 4. 所有子任务完成，总体 Review 子任务各自独立，上下文互不干扰。子任务 A 不需要知道子任务 B 的细节，只需要知道 B 的输出是什么。 上下文隔离的好处： 当一个子任务在进展时，AI 只需要加载那个子任务相关的上下文。不需要知道整个重构项目的所有细节。上下文精简，AI 专注，效率高。 拆的粒度怎么把握？ 拆得太细，管理成本高。拆得太粗，任务仍然太大。一个实用的经验： 每个子任务应该在 1-3 次对话内完成。 如果预计需要更多，继续拆。 另外，拆不是一次性完成的。你可以在执行过程中发现某个子任务太大，再把它拆成更小的。Artifact 的 parentArtifactId 字段就是用来记录这种层级关系的。 一个拆分的例子： 父任务：重构前端架构 子任务 1：定义组件分层和接口规范 子任务 2：迁移核心业务组件 子任务 3：替换路由系统 子任务 4：更新测试用例 子任务 5：验证和清理旧代码 五个子任务，每个独立推进。父子任务之间有明确的关系记录，但执行时互不干扰。

"搭好了工作区，然后呢？"然后就是做任务。一个典型的日常任务是怎么运转的。 场景：你要给项目加一个搜索功能。 第一步：raw。 你把需求描述放到 Artifact 里："用户需要一个搜索框，可以搜索文章标题和内容。" 也可能你放的是一段对话记录、一个 Issue 链接、一封邮件。不管是什么，先记录下来，不加工。 第二步：requirements。 你（或者 AI）把需求细化为完成标准： - 搜索框在页面顶部 - 输入关键词后，实时显示搜索结果 - 搜索范围包括文章标题和正文 - 搜索结果按相关度排序 - 搜索响应时间不超过 500ms 这些标准是后续 Review 的检查依据。 第三步：design。 方案设计。用前端搜索还是后端搜索？用全文索引还是 LIKE 查询？搜索引擎选 Elasticsearch 还是 Meilisearch？做设计时，记录关键决策和理由。 第四步：spec。 具体怎么做。API 接口定义、组件结构、数据流图。这些写出来，执行的时候就清楚每一步要做什么。 第五步：execution。 写代码。建索引、写 API、做前端组件。每一步完成时，记录进展。 第六步：review。 已经完成了，检查是否满足完成标准。搜索框有没有？搜索结果是否实时？搜索范围是否覆盖标题和正文？响应时间达标吗？逐项检查，记录证据。 第七步：archive。 全部通过，归档。记录摘要："添加了文章搜索功能，使用 Meilisearch 做全文索引，前端实时搜索，响应时间 200ms。" 这个流程看起来步骤多，但实际执行中，大部分步骤是 AI 自动完成的。 你只需要在第一步说"加个搜索功能"，然后审核一下需求和方案，最后检查一下结果。中间的 design、spec、execution，AI 会帮你完成。你不需要写文档，不需要画图，不需要自己写代码。 日常任务的核心是：让 AI 帮你做琐事，你只负责决策。 但要让 AI 做好琐事，它需要知道项目的背景、技术栈、代码风格、架构约定。这些信息不是在任务中说一遍就行，而是应该提前放在工作区里。这样 AI 在执行每个任务时，不需要问"你们用什么数据库"，直接去 background/ 里找就行了...