Wubuntu Tech & Life

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）提供了一个非常关键的思路。传统的大模型在每次计算时，往往需要调动全身的参数，这背后的成本极其高昂。而混合专家模型则像是把任务分包给多个专家子网络，...