AI on 火炬树

Notion CEO 的爵士模式：AI 时代组织管理的五个深层转变

Tue, 25 Aug 2026 12:58:43 +0800

在 Sequoia 合伙人 Brian Halligan（HubSpot 前 CEO）最近的一场对话中，Notion CEO Ivan Zhao 提出了一个新概念：Jazz Mode（爵士模式）。他认为，在 Manager Mode（经理人模式）和 Founder Mode（创始人模式）之后，AI 时代的组织应该像一支爵士乐队那样运作：每个人都有即兴发挥的空间，但最终又能形成协作。

这篇文章不打算复述 Ivan 说了什么，而是尝试从他的发言中提取几个容易被忽略的结构性变化，以及这些变化对正在使用 AI 构建产品的团队意味着什么。

从造桥到酿啤酒：AI 为什么改写了产品开发的底层逻辑

Ivan 用了一个比喻来区分传统软件开发和 AI 产品开发：传统软件像造桥，设计师画好图纸，工程师照着建就行；AI 产品更像酿啤酒，你只能不断实验、观察、调整，无法精确控制最终结果。

这个比喻的价值不在于修辞，而在于它揭示了 AI 产品开发中一个被低估的结构性问题：传统软件开发是需求驱动的，AI 产品开发是技术驱动的。

在传统模式下，产品经理定义需求，设计师出方案，工程师实现。整个流程的起点是客户需求，技术是执行手段。但 AI 产品不同。模型能力的边界决定了产品能做什么，而这个边界每周都在变化。如果你严格按照客户需求去规划产品路线图，三个月后你做的东西可能已经没有意义了。

Ivan 说他们内部的开发模式已经从"客户驱动"转变为"技术驱动的实验"。PM、设计师、工程师的传统界限被彻底模糊，团队中最高频消耗大模型 Token 的人甚至包括产品设计师。

这不只是 Notion 一家的实践。随着大模型能力的快速迭代，越来越多的 AI 产品团队面临同样的困境：你无法在年初做完整的产品规划，因为三个月后模型的能力已经变了。AI 产品的路线图，本质上是一种不断被推翻的假设集合。

对正在做 AI 产品的团队来说，这意味着两件事：第一，你需要接受"计划赶不上变化"不是管理问题，而是产品形态决定的；第二，你需要让团队中最有判断力的人（而不只是工程师）直接接触模型，因为对模型能力的直觉判断，正在成为比需求文档更重要的产品资产。

等级制度不会消失，但它的功能正在被重新定义

Ivan 在对话中明确表示，他不相信无层级组织。他的理由很朴素：层级制度是人类天性，黑猩猩社会都有天然的层级，你不可能通过强行扁平化消灭它。

但他同时指出，语言模型正在成为组织的新基础设施。信息传递、状态同步、决策协调，这些曾经需要大量中层管理者完成的工作，现在 AI 可以承担一部分。未来组织会更扁平，但层级不会消失。

这里隐藏着一个更深层的变化：层级存在的理由正在从"信息传递"转向"判断力分配"。

在传统组织中，层级的核心功能之一是信息过滤和传递。CEO 不可能了解所有细节，所以需要 VP，VP 需要 Director，Director 需要 Manager。每一层都在做信息的压缩和向上汇报。但 AI 工具（包括 Notion 自己的产品）正在让信息传递变得更高效，甚至自动化。当信息传递不再是瓶颈，层级的价值就只剩下两个：决策判断和资源分配。

这意味着未来的中层管理者，工作内容会发生根本性变化。他们不再是信息的中转站，而是特定领域判断力的承载者。一个中层管理者的价值，不再取决于他能管理多少人，而取决于他能在多大范围内做出高质量的决策。

对组织设计者来说，这个问题很实际：如果你的中层管理者主要工作是开会、汇报、传递信息，那他们的岗位正在被 AI 蚕食；如果你的中层管理者是某个领域的判断力中心，那他们的价值反而在上升。

人才公式变了：能力和品味，哪个更稀缺？

Ivan 提出了一个他当前最认可的人才公式：Talent = Capability × Taste × Agency。

在过去，Capability（能力）是最重要的变量。一个工程师的技术能力决定了他的产出。但在 AI 时代，能力正在被快速商品化。Claude Code、Cursor、Copilot 这些工具，正在让"写出能跑的代码"这件事变得越来越容易。

当能力变得廉价，Taste（品味）和 Agency（主动性）就变成了稀缺资源。Taste 是你认为什么是好的，Agency 是你会不会主动推动事情发生。

这不是空洞的理念。Notion 基于这套逻辑调整了招聘策略：不再重点看工作经历、大厂背景、履历长度，而是看好奇心、乐观程度、能量水平和主动性。他们第一轮面试不再看简历，而是直接要求候选人"做点东西出来"，先看作品再看背景。

更值得关注的是他们的"杠铃模型"工程组织：一头是非常年轻的工程师，负责快速试错和高效执行；另一头是极少数超级资深架构师，负责判断力、Taste 和架构。一个资深架构师指导 2-3 个年轻工程师，每个年轻工程师在 AI Agent 的加持下，一个人就能像管理一个迷你团队一样高效产出。

这个模型的底层逻辑是：AI 放大了个体的执行力，但没有放大判断力。 一个有品味的资深工程师，加上 AI 工具和几个年轻执行者，可以产出过去一个小团队的成果。但如果品味不对，再强的执行力也只是在错误的方向上加速。

对团队管理者来说，这意味着你需要重新评估团队中谁是"Taste 中心"，并确保这些人的判断力能直接影响产品方向，而不是被层层汇报稀释。

创业者是组织的去钙化剂：Notion 为什么收编了 60 位创始人

Notion 内部有 50-60 位前创业公司创始人，这是一个反常的数字。Ivan 说，创业者是组织的"去钙化剂"。

他的逻辑很清晰：一家 1000 人公司天然会往官僚方向发展，这是物理规律。但如果里面持续混入大量创业者，他们会不断发起新项目、挑战旧流程、提出新想法、推动组织变化，相当于给组织注入新的活力。

这个观察揭示了一个组织理论中经常被忽略的问题：官僚化不是管理失败，而是组织规模的自然结果。 任何足够大的组织都会产生流程、规范和层级，这些东西在初期是效率的保障，但积累到一定程度就变成了创新的障碍。

创业者的价值在于，他们天然不信任流程。他们习惯于"先做再说"，习惯于打破现有框架重新思考问题。当这些人散布在大组织中，他们就像一个个"反熵节点"，不断对抗组织自然趋向僵化的力量。

但这里有一个前提条件：组织必须给这些人足够的自主空间。如果创业者进入大公司后被现有流程同化，那"去钙化剂"就失效了。Ivan 说 Notion 的做法是让这些人保持高度自主性，这和 Jazz Mode 的理念是一致的。

企业销售是 AI 最后攻不下的堡垒

在整场对话中，有一个容易被忽略的细节：Ivan 说他们之前在销售领域犯过错误，试图重新发明销售，结果失败了。后来发现，很多企业客户就是想跟真人交流。

这个观察和当前很多 AI 公司的叙事形成了有趣的对照。过去两年，大量 AI 创业公司试图用 AI 替代销售流程，从自动外呼到智能客服到 AI SDR。但 Ivan 的经验表明，至少在企业级市场，人与人之间的信任关系仍然是成交的关键。

这背后的逻辑是：企业级采购的决策成本很高，出错的后果很严重。在这种场景下，客户需要的不只是信息和效率，还需要一个"出了问题可以找到的人"。AI 可以处理信息，但很难提供这种心理安全感。

对 AI 创业者来说，这意味着一个务实的方向判断：AI 在企业市场的最佳位置，可能不是替代销售，而是赋能销售。 让销售人员用 AI 工具更高效地准备材料、分析客户、跟进线索，但最终的客户关系仍然由人来维护。

规划周期正在急剧缩短

Ivan 说了一句很直接的话：财务规划可以按季度做，但产品规划可能要周变化，因为模型能力变化太快了。

这不是夸张。过去两年，大模型的能力曲线几乎是指数级的。2023 年初 GPT-4 发布时被认为是不可能的任务，到 2024 年底已经被多个模型追平甚至超越。如果你的产品规划建立在"GPT-4 级别的能力"这个假设上，那你的假设每隔几个月就要更新一次。

Ivan 同时强调，CEO 必须亲自感受 AI，不能只看视频、看演讲、看总结。他用了两个词：Feel the AI，Feel the AGI。只有自己使用、自己构建，才能知道哪些机会真正存在。

这个建议的实际含义是：AI 时代的产品决策，越来越依赖于对模型能力的直觉判断，而这种直觉只能来自亲手使用。 你无法通过阅读二手信息获得对模型能力的准确感知，就像你无法通过阅读游泳教程学会游泳。

公司最终会长成创始人的样子

对话最后，Ivan 谈到了一个观点：很多 CEO 喜欢模仿别人，模仿乔布斯、马斯克或者 Brian Armstrong，但公司最终是创始人的投射。如果你是工匠，公司会变成工匠文化；如果你是销售，公司会变成销售文化；如果你是爵士乐手，公司最终也会变成一支爵士乐队。

他对 Notion 社区带有"邪教/疯狂崇拜"色彩的评价非常坦然，甚至表示"很喜欢"。他认为公司在某种程度上就是一种宗教，把一套世界观和价值系统通过商业和产品投射到真实世界。

这个观点的深层含义是：组织文化不是设计出来的，而是创始人个性的放大。 你可以画出完美的组织架构图，但最终决定组织行为的是创始人自己相信什么、重视什么、怎么做决策。

Jazz Mode 之所以适合 Notion，不仅仅因为它是一个好的管理理念，更因为它和 Ivan 本人的性格匹配。他不喜欢纯授权、纯流程化和纯管理，所以他需要一个允许即兴发挥的组织。如果创始人是一个天生的控制者，Jazz Mode 在他的公司里大概率行不通。

对创业者来说，这也许是最值得思考的一个问题：你试图建立的组织模式，和你自己的性格匹配吗？如果不匹配，再好的理念也只是空中楼阁。

原文链接： Notion CEO 谈 AI 时代组织管理新范式：Jazz Mode

OpenCode Go vs Command Code GOAT：同为 $10 编程 AI 订阅，谁更划算？

Mon, 17 Aug 2026 14:00:03 +0800

OpenCode 和 Command Code 都是终端里的编程 AI 代理（coding agent），类似 Claude Code 的开源替代方案。你在命令行里跟 AI 对话，它帮你写代码、改 bug、重构项目。两者都支持切换不同厂商的底层模型，不绑定单一供应商。

OpenCode 的社区规模大得多，GitHub 星标 198K（GitHub API 实测），月活开发者超过 750 万。Command Code 的社区相对小，GitHub 星标 3.7K（GitHub API 实测），但在 harness engineering（AI 代理的工具调用优化层）上投入更多，比如内置的 Read 工具会自动过滤无关文件内容，减少上下文浪费。

两者都推出了面向个人开发者的低价订阅计划。本文对比的是两个价格同为 $10/月的计划：OpenCode Go 和 Command Code GOAT。

价格与信用额度

两个计划的定价模型相同：你每月付 $10，获得一笔以美元计价的信用额度（credit），信用额度按模型的实际 API 价格消耗。便宜的模型消耗慢，贵的模型消耗快。

维度	OpenCode Go	Command Code GOAT
月费	$10（首月 $5）	$10
月度信用额度	$60	$70
信用乘数	6 倍	7 倍
5 小时限额	$12	$14
每周限额	$30	$35
额外充值	可（Zen balance）	可（永不过期）

“信用乘数”指的是你付 $10 实际能用多少钱的模型服务。OpenCode Go 给 $60（6 倍），Command Code GOAT 给 $70（7 倍），多出 17%。

模型库对比

OpenCode Go 提供 19 个模型，Command Code GOAT 提供 36 个以上。

两者共享的核心模型包括：DeepSeek V4 Pro/Flash、Kimi K3/K2.7 Code/K2.6、GLM-5.3/5.2/5.1、MiMo-V2.5/V2.5-Pro、MiniMax M3/M2.7、Qwen 3.8 Max/3.7 Max/3.7 Plus/3.6 Plus、GPT 5.6 Luna、Grok 4.5、Tencent Hy3。

这些共享模型在两个平台上的定价完全相同。比如 DeepSeek V4 Pro 都是 off-peak $0.66 输入/$1.98 输出每百万 token，MiMo V2.5 都是 $0.14 输入/$0.28 输出每百万 token。

Command Code GOAT 多出来的模型包括：Gemini 3.7 Flash（限时 50% 折扣）、Grok 4.6、Muse Spark 1.2、Laguna S 2.1（免费，容量有限）、Inkling、Step 3.7/3.5 Flash、Qwen 3.7 Flash、更多 MiniMax 变体。

独家折扣

两个平台的通用模型定价一样，但 Command Code GOAT 有一系列永久或限时折扣：

MiMo V2.5 Pro：永久 99% 折扣。 在 GOAT 上有专用的 $30 月度配额，按折扣价计算等效约 $150 的使用量。OpenCode Go 上这款模型按标准价消耗，没有额外优惠。

MiMo V2.5：永久 98% 折扣。 输出价格从约 $4.00 降到 $0.28 每百万 token，输入从约 $0.80 降到 $0.14。在 GOAT 上使用这款模型，$10 的订阅费等效于约 $100 的标准价使用量。

MiniMax M3：永久 50% 折扣。 信用额度实际翻倍。

Laguna S 2.1：完全免费。 这是 Poolside 的开源编程模型，所有 token（输入、输出、缓存读取）价格为 $0，容量有限，先到先得。

Gemini 3.7 Flash：50% 折扣至 2026 年 12 月 31 日。

OpenCode Go 没有独家折扣，所有模型按标准价消耗。

这意味着，如果你常用 MiMo 或 MiniMax 系列模型，Command Code GOAT 的实际可用量远超账面的 $70。对于这些模型的重度用户，GOAT 的性价比优势远不止 17%，实际差距可达数倍。

API 访问

两个平台都提供 API 访问，但实现方式不同。

OpenCode Go 的 API 端点是 https://opencode.ai/zen/go/v1/chat/completions（OpenAI 兼容格式），可以直接用 API key 调用，也可以在其他编程代理中配置为自定义 provider。

Command Code GOAT 同样提供 OpenAI Chat Completions 和 Anthropic Messages 兼容的 API 端点，一个 API key 同时用于 CLI 和外部调用。

两个平台的 API 都能接入其他工具链。对只在终端里写代码的开发者来说，这个差异影响不大。如果你的 workflow 涉及多个工具共享同一个模型订阅，两者都能满足，差别在于端点格式和集成便利性。

怎么选

已经在用 Command Code 生态： 升级到 GOAT 是自然选择，更多信用额度和独家折扣直接到手。

看重模型多样性： GOAT 的 36+ 模型比 OpenCode Go 的 19 个几乎翻倍，多出来的模型里包括 Gemini 3.7 Flash 和 Grok 4.6 这种热门选项。

常用 MiMo 系列： GOAT 的永久折扣是决定性优势。MiMo V2.5 Pro 99% 折扣、MiMo V2.5 98% 折扣，同样的钱能用出几倍的效果。

只需要独立的 CLI 编码工具： OpenCode Go 完全够用。19 个模型覆盖主流需求，$60 的月度额度对中等强度使用足够。

实际选择取决于你常用哪些模型。两个平台都承诺不训练用户代码，都支持信用卡支付，额外购买的信用额度都永不过期。

价格信息来自 OpenCode 和 Command Code 官方定价页面（2026 年 8 月），实际价格可能有变化，以官方公布信息为准。

参考来源

DeepSeek Harness 开源解读：一切皆插件的 Agent 运行底座

Fri, 14 Aug 2026 08:04:47 +0800

2026 年 8 月 13 日晚，DeepSeek 在公布 API 调价后不久，正式发布并开源了 DeepSeek Harness（以下简称 dsh）开发者预览版 v0.1。DeepSeek Harness 是 DeepSeek 官方开发的开源 agent harness（智能体框架，负责把大模型接入文件系统、终端、网页等真实环境并驱动其持续工作），其核心设计被定义为：Everything is a plugin（一切皆插件）。模型、工具、技能、会话、存储、沙箱、调度、UI，所有 Agent 能力都由插件组合而成，可自由替换、灵活重组。项目以 MIT 协议开源，仓库地址为 github.com/deepseek-ai/deepseek-harness。

需要注意的是，这不是一个全新的 DeepSeek 模型，也不是单纯的 API 客户端。官方把 Agent 拆成两个部分：模型是灵魂，harness 负责让模型理解环境、使用工具、在真实场景里持续工作。dsh 是这套“除模型之外的全部”的开源实现，也是 DeepSeek 从模型层向 Agent 运行时层延伸的第一块正式拼图。

一天 6.6 万星

GitHub API 数据（2026-08-14 早）：deepseek-ai/deepseek-harness 仓库创建于 8 月 13 日，发布 24 小时左右即收获约 4.6 万星，次日早晨已超过 6.6 万星、5,596 forks，是近期增长最快的开源项目之一。npm 包 @deepseek-ai/dsh 最新版本为 0.1.0-rc.6，拆分为 20 多个 @deepseek-ai/dsh-* 子包。

项目背景可以追溯到 2026 年 5 月。彼时 DeepSeek 资深研究员陈德里公开招人，称要对标 Anthropic 的 Claude Code 做 “DeepSeek Code Harness”；团队负责人崔添翼随后发文，说团队新成立、人员紧缺，“每天都在面试”。此次开源前，项目已铺垫数月，8 月初部分媒体获得内测资格并提前体验。

与 dsh 同天发布的还有 DeepSeek V4 Pro 正式版，dsh 默认深度适配 V4 Pro 和 V4-Flash 模型。官方明确表示，当前处于开发者预览阶段，核心插件与接口会快速迭代，未来将出现破坏兼容性的变更。

一切皆插件：Cordis 微内核

dsh 最醒目的设计主张是“一切皆插件”，而且是字面意义上的全部。项目建立在 Cordis 微内核之上，运行中的 dsh 本质上是一个 Cordis Context。

Cordis 是 cordiverse/cordis 项目（2022 年创建，GitHub 实测 2,337 星），自称 “Meta-Framework of Spatiotemporal Composability”（时空可组合性元框架），设计思想源自论文《A Programming Paradigm for Spatiotemporal Composability》（一种面向时空可组合性的编程范式，见 cordiverse/paper）。Cordis 的思路是：插件向共享上下文贡献服务、类型化事件和可逆的副作用。新能力通过挂载插件加入，插件卸载时，自己注册的服务和副作用一并撤销。

这套设计带来两个直接结果：

可观测。 每一步状态都能被追踪和还原。

可回放。 多 Agent 协作可以像录像一样回放、调试。

官方架构文档明确写道：“不存在需要打补丁的特权内核”。扩展 dsh 的方式是把插件挂载到其他插件旁边，各项注册都是副作用，会在插件卸载时撤销。换模型就替换模型适配器，加工具就注册到统一的工具系统，换本地执行为远程沙箱就替换文件系统、进程和终端提供方，调整 Agent 行为可以替换整个 Agent Loop，不需要重写产品。

核心包：没有“大 Agent 类”

dsh 的仓库规模很大，包含超过 230 个 workspace 成员，代码分布在 packages/、apps/、examples/、python/、native/、vendor/、website/ 等区域。文件系统、终端、子进程、PTY、语言服务器、网页访问、技能、子智能体、工作流、计划模式、会话持久化、设置、凭据、遥测，几乎每一项能力都有自己的包。

官方架构文档把核心职责拆到不同包，没有一个大而全的 Agent 类包办所有事情：

包	职责	ctx 键
core/session	仅追加的 SessionEvent 日志和内存存储	ctx.sessions
core/system-prompt	提示词片段与工具 schema 的组装	ctx.systemPrompt
core/tools	作用域化的工具注册表和带把关的执行流水线	ctx.tools
core/agent	Agent 接口、活跃 agent 注册表和 agent/* 事件	ctx.agents
core/agent-loop	实现该接口的默认驱动器	ctx.agentLoop
core/scope	按 agent 划分作用域的注册原语	库，无 ctx 键
llm/llm	消息与流式词汇表，以及适配器 seam	ctx.llm

模型是模型，工具是工具，循环是循环，需要时再把它们拼起来。这种结构体现了一种边界意识：谁拥有接口，谁负责实现，谁把能力呈现给模型，尽量不混在一起。

Profile 与 Bundle：运行配置也能组合

运行中的 dsh 是一棵插件树，由启动时按序叠加的各层组合而成。

profile 是一套命名好的运行组合，存放在 Harness home 中。它列出自己叠放的组合包（bundle），存放自己安装的树外插件，并保存用户自己的 cordis.patch.yml。官方交付了两个模板：web（启动 Web UI）和 headless（一次性运行，不带服务器）。

bundle 是可以分发的插件组合。启动时，Harness 会从空配置开始，依次叠加 profile 指定的 bundle，再应用 profile、用户目录和命令行上的 patch。各层按此顺序应用：先按 profile 列出的顺序应用每个组合包，然后是 profile 的 cordis.patch.yml，然后是 home 级的那份，最后是任意 --patch overlay。

想查看实际启动的配置树，运行：

这条命令打印出的任何条目，都可以由自己的 patch 替换。部署差异尽量放进配置组合，而不是变成一堆分支代码。

Turn 与 Step：一轮任务的完整生命周期

官方把一次工作拆成 turn 和 step 两个层级。一个 turn 是一轮完整任务，里面可以有多个 step；一个 step 对应一次模型请求，以及这次请求触发的工具调用。

简化后的事件流如下：

这些事件是给插件提供的具体接入点，模型请求前可以改写或拒绝输入；请求发出时可以拦截；工具执行前后可以加入审批、超时、监控和策略检查。

输入通过同一个 inbox 到达驱动器，有些消息会立即唤醒它；注入的上下文会留在 inbox 中，直到另一条消息将其唤醒。agent/pre-step 决定模型看到什么，监听器可以改写已领取的消息，也可以直接拒绝；首次领取被拒绝或被改写为空时，仍会关闭一个不含步骤的持久轮次，日志会记录这次尝试。

工具也不是“拿到函数名就调用”，它会经过前置策略、不可逆的安全守卫、实际执行、后置处理、内容整理和结果通知。允许或拒绝、超时、重试、指标统计、附加上下文，都可以从流水线的不同位置接入。工具可以声明某类参数下的调用是并发安全的，调度器便会让连续的只读任务并行；一旦碰到修改状态或无法确定安全性的调用，就把它当作屏障，等待前面的任务结束后独占执行。

会话日志：模型可见即已记录

dsh 另一项核心设计是会话日志（Session Log）。项目规定，凡是模型看见的内容，都必须能够从日志中重建，并由一项运行时不变量断言这一点。因此，新增一项模型可见输入就需要新增一个会话事件：扩展 SessionEventMap 并从日志渲染。

用户消息、运行环境上下文、模型请求信息、流式输出、工具调用和结果、压缩事件、权限切换、取消原因，都会以事件形式进入追加式会话流。deriveMessages() 从日志中投影出模型历史，原始 assistant/chunk 事件则保证回放和 UI 保真。fork、恢复、transcript（文本记录）、遥测和持久化都派生自该事件流。

这项原则解决的是 Agent 系统里一个棘手问题：当任务出错时，我们能不能知道模型当时到底看到了什么？如果系统只保存最终聊天文本，许多关键因素会丢失。也许模型请求前刚注入了工作区状态，也许工具结果被裁剪过，也许系统自动切换了模型路由，也许用户在流式输出中途改变了方向。dsh 在请求边界保存足以重建消息的记录，原始流式 chunk 也保留，以便界面和回放维持一致。

会话持久化本身仍然是插件，项目提供 JSONL 和 SQLite 后端，查询能力可以优先访问实时会话，也可以通过 SQLite 全文检索历史记录。Resume 会沿用原会话继续工作，Fork 则从一个确定的历史边界派生新会话。

能力 seam：换后端不换产品

dsh 把可替换能力称为 seam（接缝）。一个 seam 通常有三层：声明接口的 Service Definition、实现它的 Service Provider，以及使用它的 Consumer（通常是面向模型的工具）。

以 Bash 为例，接口定义“执行命令”是什么，本地实现负责真正创建进程，而面向模型的工具包负责把这项能力变成模型可理解的 schema 和结果。文件系统与进程提供方共享同一个执行世界，因此把它们指向远程沙箱，也就把 Bash、PTY 和 LSP 一并搬了过去，无需为每个工具写远程分支。subagent 提供方在同一个接口之后也千差万别，从新建一个子 agent，到把一个轮次委派给另一个产品。

这种设计让替换一个提供方就能改变整个产品的行为，本地 Shell 换成远程容器、云端沙箱或企业执行平台，理论上只需替换实现层，不必重写模型工具和 Agent Loop。

四种运行模式

dsh 的 Web UI 提供四种 Agent 预设模式。它们是基于同一套 Harness 宿主，为当前会话装配不同的工具、提示词和运行时能力：

模式	内容
标准模式	功能最完整的通用编码 Agent：文件编辑、Shell、文件与网页检索、Skills、计划、目标、子 Agent 和工作流
Code 模式	保留标准模式全部能力，同时通过 Code Mode SDK 向模型呈现工具。模型可以编写一段 TypeScript 程序，在一次 run_code 中组合多步操作，减少反复往返的开销
极简模式	只提供持久 Bash 与 str_replace_editor 两项工具，较小的工具集合减少选择和上下文负担，适合路径明确的编码任务
创造模式	在标准模式之上加入 Cordis 运行时检查、临时插件实验和 Agent preset 创作指导。Agent 可以检查甚至改装自己的运行时

创造模式是“一切皆插件”最极致的表达。选择这一预设后，Agent 可以检查当前运行时的插件树，并动态挂载或卸载临时插件，在任务完成后卸载。自指 Cordis 工具不会进入标准、Code 或极简模式，作为明确的高级入口提供，官方定位为面向高级用户的高信任模式。

快速上手

前置条件只有 Node.js（≥ 18）。运行：

该命令会启动 Web UI，默认监听 http://127.0.0.1:3080。也可以在 Web UI 的 Settings → Models 里填入 DeepSeek API key 并保存，模型路由立即生效，无需重启服务。然后选择工作区（workspace），即可开始会话。dsh 进程以调用目录为默认文件系统位置，新 Web UI 需要手动添加工作区。

从源码运行：

自动化方面，项目提供 ACP 服务和 JSON-RPC 入口。Python SDK 驱动随附的 JSON-RPC 运行时，让 Python 应用可以启动会话、发送任务、接收通知，而不必直接嵌入 Node 内核。仓库还包含 Code Mode、自指 Cordis、MCP 记忆服务等示例。

安全设计：失败关闭

编程智能体一旦获得文件系统和 Shell 权限，就能修改代码、安装依赖、启动进程，甚至触碰工作区之外的主机环境。dsh 把安全问题当作基础架构问题处理：

默认采用 workspace-write 模式，将命令执行和文件修改限制在当前工作区及允许的临时目录中，并配合 ask 审批策略处理需要扩大权限的操作
danger-full-access 模式存在，但必须由部署方明确选择
工具调用经过前置策略、单调安全守卫、执行包装和后置处理。被守卫拒绝的操作不能被后续插件重新放行
文件系统、Bash 和子进程共享同一套沙箱策略，避免出现“命令受限制，但文件工具可以绕过去”的割裂边界
采用失败关闭原则，系统无法确认隔离机制真正生效时拒绝执行，不静默退化为无保护运行

权限切换、审批请求、工具参数、执行结果和取消原因都会进入 Session Log，为事后审计和问题复现保留依据。

插件生态：发布当天自发成型

GitHub topics 实测：600 多个公开仓库带 dsh-plugin 话题。第三方开发者中心 dsh.so 索引了 490 多个已验证插件。代表性项目：

插件	星数	说明
dsh-web-ui	586	Web UI 的插件与皮肤合集：任务看板、git 图、右侧面板、宠物、token 统计
dsh-cc-tui	169	Claude Code 风格的全屏终端 TUI，面向偏好 CLI 的用户
dsh-vision-toolkit	169	让纯文本模型做视觉任务：带意图的图片问答、长截图 OCR、UI 还原
awesome-deepseek-harness	162	插件、MCP、编排的精选清单
oh-dsh	70	一站式社区发行版，统一 TUI、桌面端、Web UI 三种形态

插件星数来自 dsh.so 与社区文章，发布时间集中在开源后 24 小时内。一个插件生态在项目发布当天自发成型，是“开放插件范式”在 Agent 领域的一次快速验证。

与同类工具的对比

工具	定位	扩展方式	协议
DeepSeek Harness	通用 Agent 底座	一切皆插件（Cordis）	MIT 开源
Claude Code	终端 AI 编程助手	闭源内置	闭源
Codex CLI	终端编码 Agent	多 Agent 编排	闭源
OpenCode	开源终端编码 Agent	社区驱动	开源

dsh 的差异化在于官方开源加插件范式。Claude Code 和 Codex 都是闭源产品，能力边界由厂商定义；dsh 以 MIT 协议把能力边界交给社区，这是闭源产品难以复制的护城河。

局限与风险

开发者预览阶段。 官方明示未来会出现破坏兼容性的变更，核心插件与接口仍在快速演进，不适合在生产环境锁版本。

学习成本高。 Cordis 插件树、profile/bundle、事件流、seam 等概念有门槛，对初学者不友好。官方文档建议直接用 agent 探索代码库来理解架构。

配置有陷阱。 配置补丁替换的是目标插件的整个 config，不是深度合并。如果只写一个新字段，原有的 API Key、基础地址或其他参数可能会一起消失。

生态早期。 插件虽多但质量参差，多数是 UI 和工具类，深度能力插件还在生长。

技术栈。 项目以 Node.js/TypeScript 为主，与 Python 为主的 AI 社区有隔阂。Python SDK 通过 JSON-RPC 驱动，属于外围接入，不是一等公民。

笔者观点

dsh 的开源意味着 DeepSeek 不再满足于只提供可被调用的模型，开始争夺模型之上的开发者入口。AI 编程是大模型商业化落地最靠前的领域之一。据 Research and Markets 数据，2025 年全球 AI 编程相关工具市场规模约 295.7 亿美元（约合人民币 2,011 亿元），预计 2030 年攀升至 646.8 亿美元（约合人民币 4,398 亿元），年复合增长率约 17.1%。

技术层面，会话日志“模型可见即已记录”的原则解决了 Agent 调试和审计中最痛的问题：任务失败后重试、执行到一半恢复、把会话 fork 出去继续跑，系统首先得回答一个问题，刚才模型到底看到了什么。Cordis 的可观测、可回放能力如果能在多 Agent 协作中真正落地，会推动整个行业的调试标准。

官方在发布页也明确表达：“DeepSeek Harness 仍在开发者预览阶段，核心插件和 API 将继续演进。我们期待与全球开发者一起，用可复用、可组合的开源基础设施探索智能的边界。”

对开发者来说，现在的价值在于研究架构、写插件、跑工作流。执行命令 npx @deepseek-ai/dsh web 即可开始体验；想开发插件，可以从 Cordis 和官方架构文档读起。这个项目后面最值得关注的，是“一切皆插件”最终能把 Agent 拆到多细，又能重新组合出多少种运行方式。

参考来源

Pi Agent 配置进阶：AGENTS.md、模型切换与 Thinking Level 实战指南

Wed, 22 Jul 2026 12:14:08 +0800

在《Pi Coding Agent 实战配置：从安装到日常使用的完整指南》一文中，我们介绍了 Pi 的安装、首次配置和核心扩展包。那些内容让初学者能快速上手，但 Pi 的真正灵活性藏在它的配置文件里。

Pi 的核心只有 418 行 TypeScript，默认只给模型四个工具（read、write、edit、bash）。它的所有高级行为，包括用什么模型、用多大的上下文、以什么样的思考深度执行任务，都通过外部配置文件控制。理解这些配置文件之间的关系和优先级，是把 Pi 从"能用"推向"好用"的关键一步。

Pi 的配置文件分几层？每层管什么？

Pi 的配置体系采用分层叠加的设计。理解每一层的职责范围和优先级顺序，就不会出现"改了没生效"的情况。

全局配置放在 ~/.pi/agent/ 目录下，影响所有项目。项目配置放在项目目录的 .pi/settings.json 中，只覆盖当前项目。项目配置中的嵌套对象会与全局配置合并，而非整体替换。

除了两层 settings.json，Pi 还使用了四种专门化的配置文件，各有不同的用途：

配置文件	位置	用途	加载时机
AGENTS.md	项目根目录或 ~/.pi/agent/	项目上下文与编码指令，注入 system prompt	启动时自动加载
APPEND_SYSTEM.md	~/.pi/agent/	全局行为规则，追加到 system prompt 尾部	启动时加载
settings.json	全局或 .pi/	模型选择、UI 主题、压缩策略、重试等运行参数	启动时加载
models.json	~/.pi/agent/	自定义模型与 Provider（Ollama、vLLM 等）	每次打开 /model 时重新加载
auth.json	~/.pi/agent/	API Key 和 OAuth 凭据（权限 0600）	按需读取

以下逐层拆解每一份配置的最佳实践。

AGENTS.md 怎么写才有效？

AGENTS.md 是 Pi 理解项目上下文的主要入口。Pi 启动时，会从多个位置查找并拼接内容注入 system prompt：先加载 ~/.pi/agent/AGENTS.md（全局指令），然后向上遍历父目录，最后加载当前目录的 AGENTS.md。

换句话说，全局的 AGENTS.md 定义你作为开发者常用的技术栈和通用规范，项目的 AGENTS.md 定义这个特定项目的约束和流程。

全局 AGENTS.md 写什么

全局 ~/.pi/agent/AGENTS.md 适合记录你日常使用的技术栈偏好。DeepakNess 在他的博客中分享的全局 AGENTS.md 是一个很好的参考案例：

这段内容来自 DeepakNess 的 Setting Up and Using the Pi Coding Agent 一文。它没有写得过于具体，而是给出宽泛的技术栈提示，同时要求 Pi 优先参考项目级别的 AGENTS.md。

项目 AGENTS.md 怎么组织

项目级别的 AGENTS.md 需要更精确。以下是一个针对 TypeScript 项目的模板，基于 Pi 官方文档的建议整理：

如果你管理多个项目，建议为每种项目类型维护一份模板。每次新建项目时复制过去，修改技术栈相关字段即可。

修改后记得重载

每次修改 AGENTS.md，需要执行 /reload 或重启 Pi 才能生效。这个操作的触发频率不高，但容易忘记。建议写完一段新规则后立即测试，确认 Pi 的行为如预期变化。

APPEND_SYSTEM.md 控制什么行为？

~/.pi/agent/APPEND_SYSTEM.md 追加到 system prompt 的末尾，优先级高于 AGENTS.md。这意味着它的指令会覆盖前面的内容。

它适合定义那些跨项目通用的行为准则，尤其是关于代理如何工作、如何与用户交互的约束。参考官方的建议和社区实践，一个典型的 APPEND_SYSTEM.md 内容如下：

这些规则确保 Pi 在各种项目中保持一致的工作方式，不必在每次对话开头重新交代。

settings.json：常用选项详解

settings.json 有两层：全局（~/.pi/agent/settings.json）和项目（.pi/settings.json）。项目层的嵌套对象会与全局层合并。参考 Pi 官方 Settings 文档的内容，以下是最值得关注的配置项：

模型与思考级别

defaultProvider 和 defaultModel 控制 Pi 启动时默认使用的模型。defaultThinkingLevel 设置思考深度，可选项包括 off、minimal、low、medium、high、xhigh、max。

enabledModels 是一个高性能设置。它定义了 Ctrl+P 循环切换时的模型列表，支持通配符。如果不定这个值，Ctrl+P 会遍历该 provider 下所有可用模型，使用体验会大打折扣。

thinkingBudgets 可自定义每个思考级别的 token 预算。上面的数值参考了 Pi 官方文档中给出的默认值。是否调整取决于你的模型和任务：预算越高，思考越深，token 消耗也越大。

上下文压缩（Compaction）

Compaction 是 Pi 处理长上下文的核心机制。当会话长度接近上下文限制时，Pi 自动将旧消息摘要压缩，为后续对话腾出空间。

reserveTokens：为 LLM 响应保留的 token 数（默认 16384）。这个值越小，压缩发生得越早。
keepRecentTokens：保留不被摘要的近期 token 数（默认 20000）。被保留的消息保持原样，保证最近讨论的内容不会丢失。

如果你常处理长会话，可以调大 keepRecentTokens。但要注意，这会降低压缩效率，可能更早达到模型上下文窗口上限。

重试策略

retry 配置分两层：agent 级别的重试（Pi 自己处理）和 provider 级别的重试（由 API SDK 处理）。官方文档建议将 retry.provider.maxRetries 保持为 0，因为 provider 层的重试可能在看见 rate limit 错误前就已经消耗了配额。

baseDelayMs 控制指数退避的初始延迟：2 秒 → 4 秒 → 8 秒。对于需要长时间稳定运行的任务（例如批量数据抓取），可以适当调大这个值。

项目信任模式

Pi 在项目中首次启动时，会询问是否信任该项目的 .pi/ 目录。这个机制的目的是防止恶意项目插件自动加载。

可选值包括 ask（每次询问，默认）、always（自动信任）、never（从不信任）。在 CI 或自动化场景中，可以用 -a / --approve 参数跳过询问。

models.json 添加自定义模型

如果你的模型不在 Pi 内置的 20 多个 Provider 中，可以通过 ~/.pi/agent/models.json 添加。这个文件支持 Ollama、LM Studio、vLLM、OpenRouter、Cloudflare AI Gateway，以及任何 OpenAI 兼容 API 端点。

参考 Pi 官方 Models 文档的完整配置说明，以下是最常见的三种场景：

场景一：Ollama 本地模型

apiKey 写 "ollama" 只是一个占位符。Ollama 并不验证 API Key，但 Pi 需要 auth 才会在 /model 中显示模型。compat 中的两个开关针对 Ollama 的特点：它不支持 developer role 和 reasoning_effort 参数。

以 name 字段给出人类可读的标签。Pi 在模型选择器中和 --model 模式匹配时都会用到这个值。

场景二：OpenRouter 路由配置

OpenRouter 允许你在多个 API 提供商之间设置路由偏好。以下配置参考了 Pi 官方文档中的 OpenRouter 示例：

openRouterRouting 对象会被原样传递给 OpenRouter API 的 provider 字段。order 指定提供商优先级，data_collection: "deny" 拒绝数据用于训练。

场景三：代理中转 Anthropic API

如果你通过第三方代理使用 Anthropic Messages API，可以这样配置：

在 models.json 中，apiKey 和 headers 支持三种值解析方式：直接字面量、$ENV_VAR 环境变量插值、!command 命令执行。Bitdoze 在 Pi Coding Agent Setup Guide 中评价：Pi 支持 Ollama、LM Studio、vLLM、任何 OpenAI 兼容端点。这个扩展能力是它相较同类工具的重要优势。

auth.json 管理 API 凭据

~/.pi/agent/auth.json 存储所有 Provider 的 API Key 和 OAuth Token。它的权限被设置为 0600，只允许当前用户读写。

auth.json 支持三种 key 解析方式：

字面量：直接用 API Key 字符串
环境变量插值："$MY_KEY" 或 "${KEY_PREFIX}_${KEY_SUFFIX}"
Shell 命令："!security find-generic-password -ws 'anthropic'"

官方文档指出，auth.json 的优先级高于环境变量。这意味着如果你同时设置了 DEEPSEEK_API_KEY 环境变量和 auth.json 中的 deepseek 条目，后者会覆盖前者。

一个实用技巧是使用 shell 命令从系统密钥链中读取凭据，避免将 API Key 明文写入任何文件：

模型切换策略：什么时候用什么模型

Pi 的一个核心优势是模型无关性。你可以为不同的任务选择不同的模型，切换在瞬间完成。

切换方式

操作	快捷键 / 命令	说明
打开模型选择器	Ctrl+L 或 /model	快速切换模型
循环切换模型	Ctrl+P	在 enabledModels 列表间轮换
调整思考级别	Shift+Tab	切换 thinking 深度
中断当前操作	Escape	取消正在执行的任务
发送转向消息	Enter	中断代理当前工作流，立即响应
发送后续消息	Alt+Enter	在代理完成工作后追加消息
退出	Ctrl+C（按两次）	退出 Pi
文件引用	@	模糊搜索文件
运行命令	!	发送命令输出给模型
静默命令	!!	运行命令但不加入上下文

快捷键部分参考了 Pi Agent 中文指南和 DeepakNess 的设置文章。

任务类型	推荐模型	思考级别	理由
快速编辑、文件操作、批量脚本	DeepSeek V4 Flash / MiniMax M2.7	low 或 off	成本极低，对快速任务足够
日常编码、中小型重构	DeepSeek V4 Pro / Qwen 3.6 Plus	medium	平衡质量与成本
深度分析、架构设计、复杂调试	DeepSeek V4 Pro / Claude Sonnet 4	high 或 xhigh	需要更深的推理链
视觉任务（截图理解、UI 分析）	Kimi K3 / Claude	取决于模型	主模型无视觉能力时通过 pi-vision-proxy 代理

enabledModels 通配符

为了让 Ctrl+P 切换更高效，建议在 settings.json 中设置 enabledModels 列表：

通配符匹配所有符合条件的模型。如果你只需特定的两三个模型，也可以写成精确 ID：

Thinking Level 如何影响输出质量

Pi 的 thinking level 是一个分层参数，控制模型在回答前的推理深度。参考 pi.dev 官方 Settings 文档和 models.md 中的 thinkingLevelMap 说明，不同级别对应不同的行为特征：

级别	适用场景	token 预算（默认）
off	简单问答、不需要推理的任务	无推理 token
minimal	非常简单的判断，如"是/否"分类	1024
low	轻度推理，如格式化、简单转换	4096
medium	常规编码任务	10240
high	复杂重构、调试	32768
xhigh	深度分析、架构设计	65536
max	极端复杂的多步骤推理	provider 上限

个级别之间的差异不是线性的。从 low 到 medium，输出质量提升最明显；从 high 到 xhigh，边际收益递减。实际使用中，80% 的日常任务在 medium 级别就能得到满意结果。

对于支持 thinkingLevelMap 的模型，你可以在 models.json 中精细控制每个级别映射到 provider 端的具体参数。例如某个模型可能只需要 high 和 max 两级，中间级别可以跳过：

这个机制来自 Pi Models 文档中的 thinkingLevelMap 说明。当模型不支持某些级别时，Pi 会自动跳到相邻的支持级别。

上下文管理：Compaction、会话树与手动控制

长会话是编码代理的常态。Pi 提供了三层上下文管理机制。

自动压缩（Compaction）

Compaction 在后台运行。当上下文长度接近模型窗口上限时，Pi 自动对旧消息进行摘要。compaction.reserveTokens 控制压缩触发时机：当剩余 token 少于这个值时触发。compaction.keepRecentTokens 确保最近的消息不被摘要。

如果希望更精细地控制，可以手动触发 /compact，Pi 会立即压缩当前会话。

会话树管理

/tree 命令显示会话历史树形结构。每个分支代表一次对话路线。Pi 支持：

/resume：恢复之前的会话继续工作
/new：新建会话
/fork：从当前会话分支，开始一条新的对话线

这个设计让用户可以在不丢失上下文的情况下尝试不同的解决方案路径。

一套完整的配置模板

结合以上所有内容，以下是一套可以投入日常使用的完整配置。

全局 settings.json

全局 APPEND_SYSTEM.md

项目 .pi/settings.json（覆盖全局压缩策略）

这个覆盖让需要频繁压缩的短会话项目更早触发压缩，避免浪费上下文窗口。

总结

Pi 的配置文件体系围绕一个核心原则：层层叠加，精确控制。全局配置定义通用行为，项目配置覆盖特定需求，AGENTS.md 传递项目上下文，APPEND_SYSTEM.md 约束代理行为模式。

当你理解了每一层配置的职责和优先级，Pi 的"最小核心 + 外部配置"设计哲学就不再是"功能少"的缺点，而变成"你控制一切"的优势。每天面对不同任务时，只需通过 Ctrl+P 切换模型、Shift+Tab 调整思考深度，就能在不同工作模式之间快速切换。

如果你的配置已经覆盖了本文提到的主要文件，下一步可以关注扩展系统：通过 pi install 添加 pi-web-access（网页搜索）、pi-codex-goal（任务追踪）、pi-vision-proxy（视觉代理）等包，逐步搭建完全适合自己工作流的 Pi 环境。

参考来源：

从 DeepSeek 的一份 Agent PM 招聘看行业风向

Sat, 16 May 2026 15:00:25 +0800

DeepSeek 在 2026 年 5 月 15 日挂出了一则社会招聘，岗位名称是「Agent Harness 产品经理」。这份 JD 的信息密度极高，逐条拆解之后，能看到 AI 行业在产品经理这个角色上正在发生的几层变化。

Model + Harness = Agent：DeepSeek 对 Agent 的定义

JD 开篇给出的公式直截了当：Model + Harness = Agent。DeepSeek 把模型能力之外的所有工程和产品工作统称为 Harness，涵盖 Agent Loop、Tool Use、Memory、Prompt Engineering、Context Engineering 这一整套组件。这个定义本身就是一种产品立场：Agent 的价值重心正在从模型本身，向围绕模型构建的产品层迁移。

Harness 团队的使命描述也很具体——「把 DeepSeek 的前沿模型能力，转化为领先的 Agent 产品」。产品经理要做的，是定义 DeepSeek 对 Harness 的理解。换句话说，这个岗位实际上在参与制定一家头部 AI 公司对 Agent 赛道的产品判断。

Vibe Coding 写进硬性要求

JD 任职要求第三条：「能够使用 vibe coding 写代码，不一定需要技术背景」。

这条要求的含义超越了字面意思。传统产品经理提交需求文档，等工程师排期实现。在 Agent 产品的迭代节奏下，这个流程太慢了。PM 需要能用 AI 辅助工具直接产出原型、搭建简单的数据收集工具，甚至跑通一个灰度测试的最小闭环。跳过工程师中间环节，快速验证假设，再把验证结果带给团队讨论。

「不一定需要技术背景」这句话也很值得玩味。它暗示 DeepSeek 看重的是「用 AI 工具解决技术问题」的能力，而非传统的计算机科学训练背景。会写 Python 的 PM 和会用 Cursor 写 Python 的 PM，在这个岗位上可能被同等对待。

技术理解深度达到组件级别

JD 对技术知识的要求清单非常具体：LLM API、KV Cache、Agent Loop、Tool Use、Reasoning、Planning、Skills、MCP、Memory、Subagent、Multi-Agent。

这不是「懂技术」三个字能概括的。它要求产品经理能理解 Agent 架构的每个组件是做什么的、彼此如何协作。举例来说，理解 KV Cache 意味着明白长上下文对话的成本结构，这对产品定价和体验设计有直接影响；理解 MCP 意味着知道工具调用的标准协议，这对开放生态的构建至关重要。

JD 还要求对 Prompt Engineering、Context Engineering、Harness Engineering 有「第一手实践」。重点在「实践」两个字。DeepSeek 找的不是一个读过论文的 PM，而是一个亲手搭过 Agent、踩过坑、知道 Context 窗口在什么情况下会溢出的实操型人才。

数据能力要求远超常规 PM 岗位

JD 用了相当长的篇幅描述数据方面的要求：「设计系统性的收集数据的方法（包括问卷、访谈、A/B 测试、灰度测试等），并使用统计学的工具严谨科学的分析数据。对此有系统性的思考和实践。」

传统互联网公司的 PM 做 A/B 测试，通常依赖数据团队提供实验平台和分析报告。DeepSeek 这个岗位期望 PM 自己完成从实验设计到数据分析的全链路。原因也合理：Agent 产品的迭代速度极快，用户交互模式每天都在变化，等数据团队出报告再决策，节奏跟不上。

衡量标准的描述同样值得细读：「定义与衡量’Agent 是否真的在更多场景下更深入的帮助到更多的人’的指标」。三个维度——场景广度、帮助深度、用户覆盖——同时出现在一句话里。DeepSeek 没有用 DAU 或会话数这类浅层指标，而是在寻找一种能反映 Agent 实质性价值的度量方式。这本身就是产品领域最棘手的问题之一。

「高强度用户」要求覆盖三大产品形态

JD 明确列举了候选人在 Agent 产品方面的经验要求：Claude Code、Cowork、Codex、Cursor、OpenCode、GitHub Copilot、Manus、OpenClaw、Hermes。这些产品可以归为三类：

产品形态	代表产品	核心场景
编码 Agent	Claude Code, Codex, Cursor, OpenCode, GitHub Copilot	代码生成与工程任务
工作流 Agent	Manus, OpenClaw, Hermes	多步骤任务编排
协作 Agent	Cowork	人机协同办公

DeepSeek 把三类产品都列进去，说明他们的 Harness 产品要覆盖所有这些形态，或者至少要做一个能支撑不同形态的统一框架。候选人如果只用过编码类工具，对工作流编排类毫无体感，JD 会直接筛掉。

「对模型行为有品味有判断力」这个表述也很有意思。「品味」不是技能，是一种经过大量使用后形成的直觉。知道什么场景下模型会幻觉、什么时候工具调用链会断裂、哪个 Prompt 写法比另一个更稳定——这些经验无法速成，只能靠长时间浸泡积累。

「模型与 Harness 共同进化」指向闭环迭代

JD 主要职责第三条：「与模型训练团队的研究员深度沟通与合作，实现模型与 Harness 的共同进化。」

这条职责暗示 DeepSeek 的组织结构把模型训练和产品放在了同一个闭环里。Harness 层收集到的用户行为数据、失败模式、满意度信号，会直接反馈给模型训练团队。产品经理在这个过程中扮演的角色，是把产品端的观察翻译成模型团队能用的信号。

这和大多数 AI 公司的做法不同。常见的情况是模型团队和产品团队各管各的，模型出新版本，产品团队适配一下。DeepSeek 的设计是产品端的使用数据反向驱动模型能力的演进方向。产品经理实际上在参与决定模型「变聪明」的方向。

开源社区沟通能力进入硬性要求

JD 要求「优秀的中文沟通能力。能用英文与开源社区、用户群书面沟通」。加分项里还提到了「深度参与开源社区或维护开源社区关系的经验」。

DeepSeek 本身就是开源模型公司，但把社区沟通能力写进 PM 的硬性要求，频率和权重都高于一般的出海公司。这指向一个判断：DeepSeek 的 Harness 产品会走开源路线，或者至少是社区驱动的模式。PM 需要成为技术社区和产品团队之间的桥梁，从开源用户的反馈中提取信号，再把产品规划回馈给社区。

加分项里藏着团队画像

JD 的加分项往往比任职要求更能反映团队现状：

「作为小团队中的产品经理主导产品路线的经验」：说明 Harness 团队规模不大，PM 需要独当一面
「与研究员深度协作的经验」：研究团队就在身边，协作频率极高
「深度参与开源社区」：社区运营和产品迭代是一体的

把这些拼在一起，能看到一个典型的 DeepSeek 小团队画像：研究员、工程师、PM 紧密协作，规模精干，节奏快，PM 既要做用户研究和数据分析，也要做社区运营和原型设计。

从这份 JD 看产品经理岗位的范式迁移

把上述各条能力要求放在一起审视，DeepSeek 定义的这个岗位和传统互联网公司的产品经理有本质区别。

传统 PM 的核心能力是需求分析、项目推动、跨部门协调。这个岗位把重心移到了技术品味、动手能力和系统性思维上。PM 不再是「提需求的人」，而是「能自己验证假设、能和研究员讨论技术方向、能从用户社区提取信号」的全栈角色。

这个趋势的驱动力来自 Agent 产品本身的特性：迭代周期以天计、用户交互模式高度不确定、技术栈每天都在变化。传统的「需求-开发-测试-上线」流水线无法适配这种节奏。产品经理必须具备独立闭环的能力，从发现问题到验证方案到衡量效果，全程不依赖外部团队。

这份 JD 也预示了产品经理求职市场的分化。能够补齐技术和实践短板的 PM，会在 AI 行业拿到越来越稀缺的高薪岗位。仍然停留在「画原型、写 PRD、跟进度」模式的 PM，会逐渐被挤压到边缘位置。

原文链接：https://app.mokahr.com/social-recruitment/high-flyer/140576#/job/54f386a9-913b-4626-9bf4-e1709b62fcda

京东 TGT 2026 顶尖青年技术天才计划：AI 人才争夺战的又一枚棋子

Tue, 12 May 2026 06:33:17 +0800

5 月 9 日，京东正式启动 2026 年度 TGT（Top young tech talent）顶尖青年技术天才计划全球招募。这是京东连续第二年推行该项目，较去年增加了实习生赛道，将招募范围向下延伸至 2027 届及以后的在校生。

在大模型落地进入深水区的 2026 年，AI 人才供给远跟不上需求膨胀的速度。京东这次加码，是其在技术人才储备上的一步进击，也折射出整个中国科技行业对 AI 核心人才的争夺已经白热化。

TGT 是什么，今年与去年有何不同

TGT 是京东面向全球高校本硕博在校生、应届生及毕业两年内技术人才的专项招募计划，定位是"顶尖青年技术天才"。与普通校招相比，TGT 在薪酬、资源投入和培养体系上均明显加码。

2025 年首次启动时，TGT 仅面向应届毕业生及毕业两年内的技术人才。2026 年的关键变化是新增了 TGT 实习生赛道：

类别	毕业时间要求	对象
TGT 校招生	2023 年 10 月 1 日 ~ 2026 年 9 月 30 日	海内外本硕博毕业生（含毕业两年内）
TGT 实习生（新增）	2026 年 10 月 1 日及之后	海内外本硕博在校生

实习生赛道的设立意味着京东希望更早介入顶尖学生的培养路径。对于尚未毕业的高潜力候选人，京东提供了一个在正式求职前就进入其技术体系的通道。据 i 黑马报道，这一调整的目的是"提前锁定高潜力人才"。

薪酬不设上限，配套什么资源

“薪酬不设上限"是 TGT 最具传播力的标签。但对顶尖技术人才而言，薪酬只是入场券，真正的吸引力在于研究资源和成长空间。京东为此提供了三个配套条件：

专属超大规模算力集群。AI 研究的核心瓶颈之一是算力。京东为 TGT 入选者提供专属的超大规模算力资源，用于支撑大模型训练和推理实验。据 21 经济网报道，这一资源在当前算力紧张的行业背景下具有较强竞争力。

专属青年人才公寓。解决住房问题，降低生活成本对年轻研究者的压力。

三导师制。每位 TGT 成员配备"技术导师 + 业务导师 + 成长导师”。这一机制将学术指导、业务落地和职业发展三个维度拆分开来，避免了传统"一个导师带所有"的粗放模式。据牛客网上的 TGT 官方 QA，三导师制是 TGT 区别于京东普通校招的核心培养机制。

八大技术方向，全部指向 AI

TGT 本轮招聘覆盖八大技术方向，几乎覆盖了当前 AI 技术栈的全部关键层：

多模态大模型与应用
机器学习
搜索、推荐与广告
空间与具身智能
高性能与云计算
大数据
AI 基础设施（AI Infra）
安全

其中，多模态大模型、空间与具身智能和AI Infra是今年新增或重点突出的方向。这与京东自身的业务布局高度相关：物流场景中的无人配送、仓储机器人对应具身智能，电商平台的多模态理解对应大模型应用，而大规模在线交易系统则对 AI 基础设施有天然需求。

据腾讯新闻报道，京东还新增了"企业级 AI 智能模型训练"作为重点方向之一，这意味着 TGT 不只是纯学术研究导向，还要求研究者具备将模型工程化落地的能力。

人才门槛：论文、专利、竞赛获奖

TGT 的筛选标准偏向学术与竞赛背景突出的候选人。据网易转载的官方信息，入选者需要在以下方面至少有所建树：

在权威期刊或顶级会议发表过高质量、有影响力的论文
持有相关领域技术专利
在知名技术赛事中获得重量级奖项
对特定技术领域有深刻见解，敢于突破传统框架

这套标准与字节跳动 Top Seed 计划和阿里"阿里星"项目的筛选逻辑相似，都在用学术产出和技术竞赛成绩作为"硬通货"来快速识别顶尖人才。

大厂 AI 人才争夺战全景

京东 TGT 并非孤例。2025 至 2026 年间，中国主要科技公司纷纷推出专项 AI 人才计划，且待遇不断加码：

公司	计划名称	核心方向	特色待遇
京东	TGT	多模态大模型、具身智能、AI Infra	薪酬不设上限、专属算力、三导师制
美团	北斗计划	大模型基础、自动驾驶	薪酬上不封顶（运行自 2017 年）
阿里巴巴	阿里星 / 2026 秋招	基础模型、AI Infra	7000+ offer，AI 岗位占比超 60%
字节跳动	Top Seed	大模型	全球招募约 30 名顶尖博士
腾讯	青云计划	通用 AI 方向	50 万元奖学金，含 30 万元云异构算力

据 21 经济网分析，这些计划的共性在于三个维度的军备竞赛：薪酬上限不断抬高、算力资源成为标配福利、导师制或培养体系成为差异化卖点。

当薪酬和算力逐渐趋同，真正的竞争分水落在了谁能提供更真实的产业数据和更复杂的业务场景。京东的优势在于其物流和电商体系每天产生的海量真实数据，以及对实时推荐、仓储调度、无人配送等场景的工程需求。这些场景对 AI 研究者而言，意味着"用业务驱动研究"的可能性。

舆论反馈：高薪背后有质疑

TGT 的发布也引发了讨论。从多个平台的评论区来看，质疑主要集中在三个方面：

毕业时间限制过窄。TGT 校招生要求毕业时间在两年以内，被部分声音批评为变相的年龄歧视。有评论指出，两年经验的限制将大量有实战能力的资深候选人排除在外。

高薪可持续性存疑。“不设上限"的表述引发了一些对实际薪资水平的猜测。有观点认为，不排除"高薪入职、短期裁员"的可能性。

AI 基础设施是否充足。京东并非传统意义上的 AI 公司，部分评论者对其算力储备和技术深度持保留态度。

这些反馈折射出一个更深层的问题：当"薪酬不设上限"成为各大厂的统一话术时，其边际吸引力正在递减。候选人最终选择哪家，取决于研究场景的真实性和技术团队的深度。

战略意图：京东在 AI 赛道的卡位

截至 2024 年底，京东累计研发投入接近 1400 亿元。TGT 计划的推出，是京东将研发投入转化为人才储备的具体动作。

从更宏观的视角看，TGT 可以理解为京东技术品牌建设的一部分。在大模型时代，头部技术人才的流向往往决定了一个公司在 AI 赛道上的位次。京东通过"不设上限的薪酬 + 专属算力 + 真实业务场景"的组合拳，试图在与阿里、字节、美团的竞争中争取到更多顶尖人才的注意力。

据腾讯新闻引述的分析，TGT 本质上是京东此前博士管培生项目的升级版本。但"天才计划"的叙事包装，加上实习生赛道的拓展，使其在传播力和人才覆盖面上都有了显著提升。

如何报名

TGT 报名有两个官方渠道：

PC 端：访问京东校园招聘官网 campus.jd.com，首页"顶尖青年技术天才计划"板块可直接网申投递
移动端：关注"京东招聘"微信公众号，进入底部菜单"校园招聘"进行简历投递

校招生和实习生均为全年开放，无固定截止日期。TGT 实习生无需参加在线测评，校招生需完成在线测评后进入面试环节。

参考来源

一人日更、篇均 12 万曝光：一套可复用的 AI 内容生产系统

Sat, 09 May 2026 06:11:59 +0800

X 创作者 @yidabuilds（百年 AI×出海）在一条推文中公开了他日更不断更背后的内容生产系统。这套系统的原型来自 @dontbesilent 分享的 Claude Code 工作流，经改造后适配 X 长文场景。截至发文时，该系统已支撑他发布十几篇长文，篇均曝光约 12 万，累计涨粉 9000+，书签率稳定在 0.5-1%。

本文基于该推文的完整内容整理，保留核心方法论与数据细节，供有类似需求的创作者参考。

核心思路：从碎片化提问到闭环系统

@dontbesilent 提出的核心问题是：大多数人用 AI 做内容是碎片化的——有想法就问 AI，拿到答案就发，发完就忘，下次又从零开始。

他的解法是把整个过程变成闭环：想法记进选题库 → AI 检索素材库找可复用的东西 → 套已验证的框架写 → 发布 → 数据复盘 → 把有效的规律沉淀回方法论。每次创作都在给系统加东西，而不是每次重新发明轮子。

@yidabuilds 直接采用了这一思路，并根据自己的需求做了大量改造。

四层知识库：Obsidian + Claude Code

整个系统以 Obsidian 管理内容，Claude Code 执行自动化流程，拆成四层。

第一层：语料库——解决"AI 写出来不像你"

AI 写长文最大的问题是 AI 味太重。长文读者一个字一个字读，机器感一重就感觉不对。

@yidabuilds 的解法是把自己说过的话全部存下来：推文、微信聊天记录里的观点、录音、随手记的碎片想法。从中提炼出一份写作风格指南，例如：

喜欢先下结论再给理由
喜欢用数字不用形容词
喜欢拿别的行业逻辑解释当前这件事
不用鸡汤收束

AI 每次写稿前先读这份指南，出来的初稿至少七八分像本人。写完再跑一遍"去 AI 味"检测，把机器感太重的表达标出来人工修改。

检测规则包括：

问题类型	示例	处理方式
营销体大词	赋能、闭环、打通、底层逻辑	看到就删
替读者说话	「你可能觉得……」「很多人会问……」	你怎么知道别人觉得什么
指令语气	「记住」「一定要」「核心就一句话」	在聊天不是在上课
虚构数据	「90%的人不知道」	你哪来的 90%
独立短句装戏剧感	一句话。一个词。成段。	这个最 AI 味
加粗口号金句	真正厉害的人都在……	删

两步加上去之后，长文的人味改善明显。

第二层：素材库——站在别人的数据上选路线

素材库包含 47 个同类账号的拆解、1100 多篇内容的数据、爆款文章的结构分析、可复用的概念和金句。

每次写新文章之前，AI 先翻一遍素材库：同类话题谁写过、什么角度跑出了数据、什么结构读者愿意存。

拆完 47 个账号之后，有几个发现直接影响了选题策略：

100 万+ 曝光的内容只有 5 类：刚需工具教程、医学健康科普、AI+搞钱、人设解析文、资源合集。其他类型几乎不可能过百万
书签率和曝光不一定正相关。有些文章曝光一般但书签率很高，说明内容有长期价值，读者存了以后用——这类内容值得反复写
涨粉和曝光也不一定正相关。人设文 119K 曝光涨了 156 粉，教程文 77K 曝光只涨 25 粉。人设让人想 follow 这个人，教程让人存了就走

第三层：内容管线——按策略挑选题，不是临时想写什么写什么

管线分四阶段：选题池 → 待深化 → 创作中 → 已发布。池子里长期保持十几个随时能写的选题，十几个需要补素材的备选。

选题分几个赛道轮着来：项目实战、AI 搞钱赛道拆解、草根低门槛生意、AI 新范式趋势。每个赛道的选题强度不一样：

硬核工具教程：曝光最高
人设自我介绍：涨粉最猛
数据复盘：受众窄但书签率好

根据当前目标选选题：要曝光就发教程，要涨粉就发人设，要沉淀就发复盘。

第四层：方法论——从自己的数据里提炼规律

什么标题有效、什么选题能爆、什么结构书签率高——全从自己的发布数据里提炼。

标题是最容易量化的部分。跑了十几篇长文之后，出数据的标题基本落在四个模式里：

模式	示例	曝光
身份+数据+承诺	00后用 Claude Code 做副业，4 个月变现超 10 万	12 万
低门槛+高结果	不到 200 粉账号的第一篇文章，如何冲到 6 万展示	2.5 万
帮你省时间	公众号文章批量采集完全指南：5 种方法+实战脚本	20 万
反差数据	十几张配图带来几十万流量，花了不到五毛钱	0.8 万

发之前过一遍检查清单：有没有具体数字？有没有身份标签？有没有反差？读者看完标题知不知道能得到什么？命中越多数据越好。

配图策略：HERO 图、标题、钩子三件套信息不重复

X 长文的配图很关键。信息流里用户的注意力顺序是 HERO 图 > 标题 > 正文。图不行，标题再好也没人点。

原则：HERO 图、标题、钩子三件套传递三层不同的信息，不重复。

HERO 图：一眼告诉你"这是什么类型的内容"
标题：给一个让人停下来的数据锚点
正文第一段：展开细节

配图两种风格，根据内容类型自动选：

教程类：信息图风格——白底、浅色装饰气泡、圆角卡片、扁平图标、大号中文标题，像 SaaS 官网那种干净的 hero banner
观点类：概念海报——大字作为画面骨架，角色和文字咬合，像展览海报不是 PPT

每篇长文一张封面加两三张内页信息图。AI 根据文章内容生成 prompt，调 GPT Image 2 的 API 出图，下载裁切到需要的比例。以前 Canva 一张调半小时，现在 10 分钟出三张。

数据表现：篇均 12 万曝光，书签率 0.5-1%

标题	曝光	书签	书签率
Codex 实战入门	24 万	1161	0.48%
AI 算命，闷声发大财	21 万	2110	1.01%
公众号文章批量采集完全指南	20 万	1431	0.71%
4 个月变现超 10 万	13 万	845	0.63%
美股投资从 0 到 1 完全指南	10 万	468	0.48%

AI 算命那篇书签率最高，1.01%——AI+搞钱+信息差的组合，读者存得最积极。

从数据里长出来的四条规律

“从数据里长规则"是 @dontbesilent 的核心方法论。以下是 @yidabuilds 自己的 X 长文数据跑出来的具体规律：

标题里必须有具体数字。 “4 个月变现 10 万”"$155 vs $15"“452% 收益率”——跑出来的长文都带硬数字。信息流里数字是最容易让人停下来的东西。

AI 得是主角。 AI 教程类长文稳定 10 万以上，纯投资内容很难过 5 万。来这个账号的人想看"AI 怎么用”，不是看"怎么炒股"。

“帮你省时间"是底层传播逻辑。 公众号采集、Codex 入门、配图实战——所有爆款长文的共性是"我帮你试过了、踩坑了、整理好了，你照着来”。

爆款公式：硬核教程或真实经历 + 具体数据锚定 + 可复现路径。 没有一篇爆款的标题是抽象概念。全是"我做了 X，结果是 Y"的结构——分享经历加数据，不教课。

这些规则每发一篇新文章就更新一版。系统在自我修正。

如何开始：不用一步到位

dontbesilent 的 dbskill（GitHub 4000+ star）是个很好的起点。也可以像 @yidabuilds 一样，拿核心思路过来根据自己的需求改。

不用一步到位。先把选题池和素材库建起来，跑两周，让数据告诉你该往哪个方向调。

本文基于 X 用户 @yidabuilds 的推文内容整理。原文链接：https://x.com/yidabuilds/status/2052252982302200010

FDE 前沿部署工程师：AI 时代最稀缺的新角色

Fri, 08 May 2026 13:51:09 +0800

FDE 到底是什么

FDE（Forward Deployed Engineer，前沿部署工程师） 是一种驻扎在客户现场的混合技术角色，核心职责是用生产级代码把平台能力转化为客户的实际业务价值。

这个词最早由 Palantir 在十多年前提出，当时叫 “Forward Deployed Software Engineer”（FDSE），专门用于描述那些嵌入到政府和大型企业客户内部的工程师。到了 2025 年，随着生成式 AI 和 Agent 系统从实验室走向真实业务场景，FDE 这个角色在硅谷全面复兴，成为 AI 公司招聘清单上的头号目标。

与传统工程师不同，FDE 的工作场域在客户的办公室、数据中心和业务流程里。他们写的代码直接跑在客户的环境中，调试的是客户的真实数据，解决的是客户当下最紧迫的问题。用 Hashnode 的话说，他们是 “hands-on-keyboard builders”，键盘上的每一行代码都指向一个具体的业务结果。

为什么这个角色在 AI 时代突然爆发

AI 落地有一个根本困境：模型能力再强，到了真实业务场景里，每个客户的需求都像 “第一次接电网，连插头都不一样”。

人人都是产品经理的分析指出，传统 SaaS 的 “卖软件” 逻辑在 AI 时代彻底跑不通了。同样是 “AI 律师”，大律所需要条款级别的精准标记，中小律所需要的是快速生成初稿。场景碎片化到没有任何标准化产品能直接套用。

这种碎片化的代价极高。据 Sundeep Teki 引用的 MIT 2024 年研究，企业 AI 项目的失败率高达 95%。不是模型不够好，而是 “产品能做什么” 和 “客户需要什么” 之间存在着巨大的理解鸿沟。

FDE 的存在意义就是填平这个鸿沟。他们驻扎现场，跟一线操作人员坐在一起，把模糊的业务需求翻译成具体的技术方案，再用代码快速验证。这种 “重” 模式在 AI 时代反而成了最可靠的路径。

FDE 每天具体在做什么

根据对 OpenAI、Palantir 和 Anthropic 等多家公司招聘描述的梳理，FDE 的核心工作可以归纳为四个阶段：

阶段	工作内容
需求挖掘	深入客户现场，从模糊的业务痛点中定位真正需要解决的技术问题
快速原型	用几天时间搭出可运行的 PoC，让客户看到可能性，获取即时反馈
生产部署	把原型加固为安全、可扩展的生产系统，适配客户现有的基础设施和安全策略
反馈闭环	把现场发现的产品缺口和通用模式带回总部，直接影响产品路线图

Paraform 的一篇文章用一个场景说明了 FDE 的典型一周：周一跟企业客户做技术需求梳理，周二基于客户代码库搭建定制化的概念验证，周三带着安全团队过合规审查。整个周期压缩到几天，而不是传统软件部署的数月。

FDE 与传统工程师、产品经理的本质区别

FDE 最容易被误解为 “高级技术支持” 或 “驻场顾问”，但这两个标签都偏离了核心。

维度	传统软件工程师	产品经理	FDE
核心产出	平台级功能代码	产品需求文档与路线图	客户现场的生产级定制方案
客户接触	极少，需求通过 PM 过滤	定期访谈，但不做实施	长期嵌入，直接写代码
代码属性	通用化，服务所有客户	不写代码	定制化，解决特定客户的特定问题
成功标准	功能上线、系统稳定	用户增长、功能采用率	客户业务指标改善、合同续签

Paraform 用一句话划清了界限：Sales Engineer 负责在签约前 “卖出梦想”，核心软件工程师负责 “打造工具箱”，而 FDE 负责 “用工具箱为客户搭出成品”。

与产品经理相比，FDE 的优势在于离代码和客户现场都足够近。他们既能听懂业务人员的 “黑话”，又能当场把需求变成可运行的系统。这种 “翻译+建造” 的双重能力，在 AI 落地阶段比单纯的需求文档更有价值。

市场需求：数据不会说谎

2025 年，FDE 岗位的爆发有多个维度的数据支撑：

岗位增速：招聘平台 Indeed 的数据显示，2025 年 1 月至 9 月间，面向客户的 AI 技术岗位招聘信息量增幅超过 800%
巨头入场：OpenAI 计划在 2025 年将 FDE 团队扩至约 50 人；Anthropic 表示将把包括 FDE 在内的应用 AI 团队扩大五倍
创业公司跟进：Y Combinator 招聘网站上超过 100 家 AI Agent 公司在招 FDE
薪资水平：FDE 中位数总包约 17.4 万美元，Palantir 的 FDE 平均总包约 23.8 万美元，资深级别可达 63 万美元以上

Forbes Technology Council 的一篇文章把 FDE 放在技术浪潮的历史坐标里：云计算时代定义性的角色是产品经理，数据革命时代是数据科学家，而生成式 AI 时代，这个角色正在变成 FDE。

什么样的人适合转型 FDE

FDE 不是单一技术栈的延伸，而是一种能力组合的重新排列。GeeksforGeeks 和 Sundeep Teki 的梳理显示，这个角色的技能要求横跨五个维度：

能力维度	具体要求
技术深度	Python、SQL、全栈开发、云基础设施（AWS/GCP）、Docker/Kubernetes
AI 工程	LLM 集成、RAG 架构、模型微调（LoRA/QLoRA）、Agent 编排、LLMOps
问题解决	在信息不完整的环境下快速定位问题、迭代开发、生产环境调试
沟通能力	把技术概念翻译成业务语言、主导客户工作坊、建立长期信任关系
商业意识	理解客户 ROI 逻辑、熟悉合规框架（GDPR 等）、在资源约束下做优先级判断

Forbes 总结了六个关键特质：好奇心、技术流利度、同理心、沟通能力、适应力和 ownership。这些特质很难通过短期培训获得，更多来自长期的项目历练。

对于想转型的人来说，最现实的切入路径是：先在一个垂直领域积累深厚的业务理解，同时保持代码能力不退化。FDE 的价值恰恰来自于 “既懂业务又懂技术” 的交叉点，单一路径的深度在这个角色里并不够用。

Palantir 的 “碎石路” 模式：FDE 如何驱动产品进化

FDE 模式最成熟的案例是 Palantir。这家公司从服务 CIA 和 NSA 起步，面对的根本挑战是：客户的需求极度碎片化，反恐、反核扩散、反洗钱表面都是 “信息分析”，实际的数据源、流程和优先级完全不同。

Palantir 的解法是把 FDE 在现场做的每一个定制化方案都视为 “碎石路”。总部产品团队从中筛选最有价值的部分，修成 “高速公路” 沉淀到平台里。新客户再来时，“土路” 越来越少，FDE 可以聚焦更深层次的问题。

人人都是产品经理把这个机制总结为 “把定制化本身变成武器”。表面上看，FDE 模式人力密集、短期利润低；但长期看，现场积累的业务洞察会不断反哺产品，形成竞争对手难以复制的壁垒。这也是 Palantir 市值突破 4000 亿美元的核心逻辑之一。

前 OpenAI 首席研究官、Palantir 第二位工程师 Bob McGrew 提到，过去一年他接触的 AI 创业者几乎只关心一件事：Palantir 的 FDE 模式到底怎么运作。这种关注度本身说明，FDE 已经从一家公司的内部方法论，变成了整个行业的共识性基础设施。

参考来源

如何用两小时"蒸馏"一个人

Wed, 06 May 2026 06:28:56 +0800

Ruben Hassid 是一位在 X 上拥有大量读者的 AI 写作者，每周有超过 50 万人阅读他的通讯。他在一篇长推文中分享了一套方法论：用两小时、一个文本文件，让任何大语言模型写出和你一模一样的文字。这篇文章将解析该方法论的完整流程，并评估其实际价值与局限。

核心命题：为什么一个文本文件就能复制你的人格

Hassid 的论点直接且挑衅：你不过是一个文本文件。他认为，大多数人高估了自己的复杂性，低估了自己写作中可提取的模式。你的声音、品味、让你抓狂的烂帖、老朋友模仿你时会说的那句话、你打了又删的两个字、今年写了三次都没意识到的比喻，每一个都是可捕捉的模式。

这个观点的底层逻辑建立在当前大语言模型的上下文学习能力之上。当模型在对话开始时读取一份精心编写的个人档案文件，它会在后续生成中持续参考这些约束条件。这不是在训练模型，而是在给模型一个"角色剧本"，让它在每次输出时都扮演你。

Hassid 本人的验证颇具说服力。他拥有 20 年写作经验，曾在首尔、柏林、特拉维夫生活，9 岁从游戏论坛学会英语，大学辍学两次，现在给财富 500 强公司做 AI 咨询。他把这些经历浓缩进一个文件后，Claude 写出的初稿"就像我自己写的一样"，有时甚至"在我想到之前就写出来了"。

方法论的两阶段结构

Hassid 的方法论分为两个紧密衔接的阶段：深度采访和压缩编译。

第一阶段：100 道题的深度自我采访

这一阶段的核心工具是一个被 Hassid 称为"Taste Interviewer"的 Claude 提示词。它的任务是通过 100 个问题，系统性地提取你的写作 DNA。问题被分为七大类别：

类别	题数	核心挖掘目标
信念与逆向观点	15	你坚信但同行不认同的东西
写作机制	20	你实际怎么写，而非你以为怎么写
审美犯罪	15	什么让你在别人文字中感到不适
声音与个性	15	你严肃时和随意时的语气差异
结构偏好	15	你如何组织想法、使用列表和过渡
绝对禁区	10	你永远不会写的东西
红旗信号	10	什么让你立刻不信任一段内容

采访规则设计得很严格：一次只问一个问题；对模糊答案要追问；要求具体例子；指出矛盾之处；对有趣的话题深入挖掘。Hassid 建议使用 Wispr Flow 进行语音输入，因为"语音更快、更诚实"。

完成全部 100 题大约需要 90 到 120 分钟，最终产出是一份 2 万字左右的原始档案。完整的采访提示词见文末附录 A，可直接复制到 Claude 中使用。

第二阶段：压缩为高保真档案文件

原始档案的问题是体积过大。每次对话都让 Claude 读取 2 万字，既消耗上下文窗口，也增加 Token 成本。解决方法是让 Claude 充当"Voice Compiler"，将原始档案压缩为一个 2000 到 4000 Token 的 about-me.md 文件。

压缩的核心规则是：每一行都必须通过测试——“如果这一行消失，AI 的写作、编辑、判断、拒绝、结构或决策方式会不同吗？“如果答案是肯定的，保留；否则删除。

压缩后的文件采用 XML 结构，包含 15 个模块。每个模块都有明确的功能边界：

usage：三行说明，告诉 AI 如何使用这份文件
priority：六条优先级规则，处理冲突时的决策逻辑
identity_context：影响声音、品味、比喻和判断的身份细节
voice_fingerprint：节奏、密度、直接性、幽默、情感温度等可操作描述
writing_laws：具体的写作规则，包含正反示例
communication_laws：邮件、回复、请求、批评等场景的规则
hard_refusals：AI 绝不应该写、说或暗示的内容
taste_loves 与 taste_disgusts：你欣赏和厌恶的具体事物
phrase_bank：你常用的词、短语、比喻，以及你避免使用的表达
signature_tells：让你可被识别的小细节
decision_rules：你如何判断质量、诚实、美感、风险、可信度
productive_contradictions：需要保留而非抹平的张力
golden_examples：3 到 6 个正反对比示例
do_not_infer：AI 不应该从这份档案中推断出的假设
final_instruction：一条简洁指令，告诉 AI 静默应用这份档案

完整的压缩编译提示词见文末附录 B。

实际效果：从实验到工作流

Hassid 展示了多个对比案例。在加入 about-me 文件前后，同一 AI 模型对相同提示的输出质量差异显著。没有档案时，模型输出的是通用、安全、缺乏个性的文字；加入档案后，输出带有明确的个人风格、特定的用词习惯和结构偏好。

更实用的价值在于团队场景。Hassid 指出，你可以把这份文件发给团队成员，让他们在你不在时也能按你的方式起草内容。客服回复、邮件沟通、内容创作，都可以由团队代劳而保持一致的声线。

不过 Hassid 也坦诚地指出了一个问题：一致性带来可预测性。当你的风格被固定在一个文件里，你的输出模式也变得可被预测。他的解决方案是定期编辑这份文件，因为人的品味和声音会随着时间变化。

方法论的价值与局限

为什么这个方法有效

该方法论的巧妙之处在于它把"让 AI 写得像我"这个模糊目标，拆解为两个可执行的具体步骤：先通过结构化采访强制你显式化自己的写作规则，再通过压缩过滤掉噪音、保留信号。

大多数人无法直接写出一个好的 about-me 文件，因为他们从未系统性地思考过自己的写作偏好。100 道题的采访过程本质上是一种强制内省，它逼你把直觉层面的品味转化为可表述的规则。这种转化正是 AI 能够理解和执行的前提。

局限与值得警惕的地方

首先，该方法假设你的写作风格是稳定的、可模式化的。对于风格多变、实验性强的写作者，这份档案可能反而成为一种束缚。

其次，2 小时的投入产出比取决于你的使用频率。如果你只是偶尔让 AI 帮你写几封邮件，花两小时建立档案可能得不偿失。但对于需要持续产出内容的人—— newsletter 作者、社交媒体运营者、团队管理者——这个一次性投入可以带来长期的效率提升。

第三，Hassid 的方法高度依赖 Claude 的 Opus 模型和 Extended thinking 模式。在其他模型或更便宜的模型上，采访深度和压缩质量可能会有明显下降。

最后，也是 Hassid 自己强调的：这个过程会让人感到不适。当你把自己读进一个文本文件时，“无处可藏”。每一个信念都是一种承诺，每一个拒绝都是你如今必须遵守的规则。他第一次读自己的压缩文件时"退缩了”。

如何开始：最小可行实践

如果你不想一次性走完完整的 100 题流程，可以从一个最小版本开始：

打开任意 AI 对话，粘贴 Hassid 的 Taste Interviewer 提示词（见附录 A）
只回答前 20 题，聚焦在"写作机制"和"审美犯罪"两个类别
让 AI 将回答编译为一份 500 到 1000 Token 的精简档案
在下一次需要 AI 帮你起草内容时，把这份档案放在对话开头
根据输出效果，逐步补充和修正档案内容

这个最小版本大约需要 30 分钟，足以让你体验到方法论的核心价值：AI 输出从"通用"到"像你"的质变。

参考来源

附录 A：Taste Interviewer 完整提示词

将以下内容粘贴到 Claude 对话中即可开始采访：

附录 B：Voice Compiler 完整提示词

完成 100 题采访后，在同一段对话中粘贴以下内容，让 Claude 将原始档案压缩为高保真 about-me 文件：

AI 自动化服务创业：一个正在关闭的窗口期

Wed, 06 May 2026 01:25:30 +0800

为什么现在是一个特殊的窗口期

Nav Toor 在 X 上发布的一篇长文指出，当前 AI 自动化服务市场存在一个正在快速扩大的供需缺口。这个缺口的核心结构很简单：一方面，数百万小企业主已经意识到 AI 可以节省时间，但尝试使用 Claude 等工具后，因为得到的回答过于 generic 而放弃；另一方面，一小群掌握子代理架构、MCP 服务器配置和技能文件设计的 builder，正在以每个项目 3,000 到 15,000 美元的价格接单，并且客户排队等待。

这个窗口期的本质是技能溢价。 当一项技术已经普及到"大家都知道它存在"，但还没有普及到"大家都能独立使用它创造价值"时，掌握中间层技能的人就能获得超额回报。Toor 认为这个溢价不会持续太久，因为供给正在快速增长。文章的核心论点是：未来 90 天是建立个人品牌和垂直领域专业地位的关键期，18 个月后市场将变得拥挤。

AI 自动化服务的定义与边界

Toor 所定义的 AI 自动化服务，并非简单的"用 AI 写文案"或"让 AI 回邮件"。它的核心特征是：将企业内 5 到 15 个高频率、可预测、遵循固定流程的任务，通过子代理架构和外部工具集成，转化为无需人工干预的自动化系统。

这些任务通常包括：研究报告生成、客户报告汇总、内容生产、客户邮件处理、文档准备、库存更新、会议记录整理、潜在客户信息 enrich 等。它们的共同点是：重复性高、流程明确、但每个企业又有细微的个性化需求。

与传统 SaaS 工具的区别在于，AI 自动化服务是定制化交付：每个客户的上下文文件、子代理配置和 MCP 工具链都是根据其具体业务场景量身打造的。这使得它更接近咨询服务的交付模式，但边际成本远低于传统咨询。

90 天行动路线图的六个阶段

Toor 将整个过程拆分为六个阶段，每个阶段有明确的时间边界和可交付成果。

第一阶段：搭建工具箱（第 1-14 天）

这一阶段的目标是掌握四项核心技能，而不是浅尝辄止。

上下文文件设计是起点。每个自动化系统的输出质量，取决于系统对客户的业务场景、受众特征、品牌语调和质量标准理解有多深。Toor 建议练习为三个不同行业的假想企业构建上下文文件：房地产中介、营销咨询公司、DTC 电商品牌。

子代理架构是引擎。与单一通用 agent 不同，Toor 强调为每个具体任务设计专门的子代理：代码审查员、周报生成器、冷邮件撰写员、会议记录整理员、bug 复现员。每个子代理需要经过 10 次不同输入的测试和迭代，才能达到可交付的可靠性标准。

MCP 服务器配置是将聊天机器人升级为系统的分水岭。Toor 列出了五个必须掌握的工具集成：Tavily（网络搜索）、Google Drive（文件存储）、Gmail（邮件）、Slack（通讯）、以及至少一个 CRM。练习目标是构建一个端到端工作流：搜索网络信息，保存摘要到 Drive，邮件发送给自己，在 Slack 发布通知，同时记录到 CRM。

定时自动化设计处理的是最高价值的场景：无人值守运行。每日简报、每周客户报告、月度发票处理，这些都需要理解调度机制、时区边缘情况和数据缺失时的优雅降级策略。

第二阶段：选定垂直领域（第 14-21 天）

Toor 对"不要试图服务所有企业"的强调非常强烈。他给出了四个选择标准：你对该行业的工作流程足够了解、客户有支付 3,000 到 5,000 美元的能力、至少有 5 个可自动化的重复任务、客户不会技术到自己动手做。

文章列举了八个正在产生实际收入的垂直领域：房地产中介、营销代理、电商品牌、专业服务公司、内容创作者、金融顾问、医疗诊所、律师事务所。每个领域都有 5 到 10 个高价值自动化场景等待被开发。Toor 的警告很直接：“选两个领域等于零转介绍。”

第三阶段：建立第一个案例研究（第 21-30 天）

这是整个路线图中最反直觉的一步：免费为第一个客户做自动化。Toor 认为这笔"免费"交易的价值远超金钱：你获得了一个真实运行的生产系统、一个带有具体数字的案例研究、以及一个真实客户的推荐语。

寻找第一个免费客户的方法包括：在垂直领域的社区发帖、通过个人网络寻找、或者直接向 10 家企业发送 cold outreach。Toor 给出的转化率预期是 10 条消息换 1 个 yes。关键在于测量一切：手动处理任务需要多长时间，自动化后需要多长时间，质量差异是什么，每周节省多少小时。

第四阶段：打包定价（第 30-35 天）

Toor 明确反对按小时收费。他的定价逻辑基于价值交付：如果一个自动化系统每周节省 10 小时，按每小时 75 美元的内部成本计算，每月价值 3,000 美元。一次性收取 3,000 到 5,000 美元的建设费用，对客户来说是显而易见的 ROI。

对于复杂的多代理系统、自定义 MCP 服务器或跨平台集成，价格区间提升到 5,000 到 15,000 美元。交付包包括：2 小时的需求调研、3 到 5 个定制子代理、MCP 服务器配置、定制上下文文件、两周测试优化期、维护文档、以及上线后 30 天支持。

第五阶段：寻找付费客户（第 35-60 天）

Toor 列出了三个有效渠道。内容营销的核心是展示 before/after：“我为一家营销代理构建了一个自动化系统，将客户报告从 3 小时缩短到 3 分钟。以下是具体做法。“每周一篇，四个月后会有自然流量。直接 outreach的目标是每天 3 到 5 条消息，100 条消息产生 10 通电话，转化为 2 到 3 个成交。转介绍的关闭率高达 50% 到 70%，一个优质转介绍的价值等于 10 封 cold email。

第六阶段：规模化到月入 10K 美元（第 60-90 天）

当拥有 3 到 5 个付费客户后，模式会自然浮现。每个营销代理都需要同样的 3 个自动化，每个电商品牌都有同样的 5 个痛点。这就是护城河：将常见模式产品化，用模板替代从零开始构建。

Toor 还建议增加月度维护服务，收费 500 到 1,000 美元/月，负责优化自动化、添加新功能、以及确保模型更新后系统稳定运行。数学很简单：5 个维护客户 × 750 美元/月 = 3,750 美元经常性收入；每月 2 个新建设 × 5,000 美元 = 10,000 美元项目收入；总计 13,750 美元/月，折合 165,000 美元/年。

工具栈与成本结构

Toor 强调这个业务的工具成本极低。整个栈只需要五个工具：Claude Code 或 Cowork（子代理运行环境）、Notion 或 Obsidian（上下文文件和案例研究管理）、Cal.com（预约调研电话）、Stripe（发票和收款）、Loom（异步客户更新）。总月成本低于 200 美元。

这与传统软件开发或咨询业务的成本结构形成鲜明对比。没有服务器费用、没有团队工资、没有办公室租金。唯一的成本是时间，而时间投入在前两个阶段后会被模板化大幅压缩。

三个最常见的失败模式

Toor 指出 90% 的尝试者会倒在三个陷阱上。

工具完美主义：花 8 周学习而不是动手做。Toor 的立场很明确：两周练习足够，第一个付费客户教给你的比两个月理论更多。

定价过低：因为"还在学习"而收 500 美元。Toor 认为这反而会杀死交易，因为客户信任高价信号所传递的专业度。最低收费 3,000 美元。

没有垂直领域：试图服务所有企业，最终谁也服务不好。选定一个行业，做深，再扩展。

这个窗口期为什么正在关闭

Toor 的"不舒服的真相"在于市场动态本身。当前能交付 AI 自动化系统的 builder 供给极小，相对于需求来说几乎可以忽略不计。这解释了为什么客户愿意接受小作品集、为什么 competence 本身已经足够、为什么溢价可以维持。

但 18 个月后情况会不同。更多人会掌握这些技能，更多模板会被开源，更多 SaaS 产品会封装这些能力。届时市场将转向价格竞争，而提前建立垂直领域专业地位的人会拥有定价权。

文章结尾的断言很直接：大多数人会读完这篇文章，想几周，然后什么都不做。而那些本周就预约第一个调研电话的人，会在夏天结束前拥有月入 10,000 美元的业务。

参考来源

Nav Toor, “The full playbook for becoming an AI automation builder in 90 days”, X (Twitter), 2025. 原文链接

Malus.sh：AI 洁净室克隆如何威胁开源软件的可持续性闭环

Tue, 05 May 2026 07:16:47 +0800

Malus.sh 是什么

Malus.sh（发音同 “malice”，意为恶意）是一个 AI 驱动的工具，声称能够通过"洁净室"（Clean Room）工程方法，从零重新创建任何开源软件的功能等价版本，同时剥离原始项目的所有许可证义务。其网站上最醒目的标语是：“No attribution. No copyleft. No problems.”

该项目的独特定位在于它既是讽刺作品，也是真实运营的商业产品。创始人 Mike Nolan 的身份是联合国开源软件政治经济学研究员。他在接受 404 Media 采访时明确表示，如果只是讽刺，开源技术工作者会觉得"这不会发生在我身上"而选择忽视。让工具真正可用，是为了迫使社区正视开源经济模型中已存在的结构性裂缝。

Malus.sh 已注册为 LLC，接入 Stripe 收款，拥有真实付费客户。目前其"解放服务"暂时不可用，但项目引发的行业讨论仍在持续扩散。

技术机制：AI 加速的洁净室工程

传统洁净室方法的历史先例

洁净室工程的法律基础可追溯至 1982 年的 IBM BIOS 案。当时 IBM 垄断个人计算机市场，竞争对手希望实现兼容而不侵犯版权。解决方案是：

团队 A 分析 IBM BIOS 的原始代码，写出功能规格书
防火墙隔离：团队 A 与团队 B 之间严格隔离
团队 B 只看规格书，从零重新实现代码
法律结果：功能兼容但代码独立，法院认定不侵犯版权

这一案例被 HBO 剧集《Halt and Catch Fire》第一季戏剧化呈现，成为软件版权法历史上的关键节点。

Malus 的 AI 版本流程

Malus 将传统洁净室方法完全自动化：

具体步骤包括：

上传清单：支持 package.json、requirements.txt、Cargo.toml 等格式
隔离分析：四个 AI 单元分别阅读 README、分析 API、研究类型定义、审查文档，“从未见过一行原始源代码”
独立重建：通过隔离防火墙，由另一组 AI 根据规格书重新实现
许可证解放：输出代码附带 MalusCorp-0 License，零署名、零 copyleft、零义务

速度的量级跃迁

AI 对洁净室工程的最大改变在于时间压缩。Malus 声称：

项目	传统耗时	Malus 耗时
IBM BIOS 克隆（1984）	4 个月以上	整支工程团队
left-pad（11 行代码，2016 年删除导致全球构建崩溃）	数小时人工重写	10 秒
SPACEWAR!（第一款电子游戏）	数周	5 秒

开发者 Dan Blanchard 在 2026 年初使用 Anthropic 的 Claude Code 对流行的 Python 库 chardet 进行了类似的"从零开始"MIT 许可证重写。他的评价是：“以前需要团队数月甚至数年的重写，现在 AI 几天就能完成。这个趋势不可逆转。”

商业模式与定价

Malus.sh 采用按量计费模式：

项目	详情
计价方式	按解压后包体积计费（per-KB）
单包上限	10 MB
单次上限	50 个包
支付渠道	USD、EUR、BTC、股票期权
输出许可证	MalusCorp-0 License
法律保障	声称通过"不承认软件版权的离岸子公司"提供赔偿

网站上的"客户证言"明显带有讽刺性质，例如"guilt doesn’t show up on quarterly reports"（愧疚不会出现在季度报告里）。但定价结构和支付功能是真实的。

创始人的核心论点

Mike Nolan 在 2026 年 3 月发布的博客文章《Thank You for Your Service》中系统阐述了 Malus 的立场。

开源的三大结构性问题

开源已经失败的案例

年份	事件	类型
2016	left-pad 被删除，全球数千构建崩溃	维护者破坏
2021	Log4Shell（CVE-2021-44228）	严重 CVE
2022	colors.js 与 faker.js 被植入无限循环	维护者抗议
2022	node-ipc 包含针对俄/白 IP 的文件删除载荷	地缘政治破坏
2025	Shai Hulud 2.0 npm 蠕虫	供应链攻击

关于 Log4Shell，Nolan 写道：“工程师们在圣诞节假期里修补它，而实际维护 Log4j 的人大多是 unpaid 志愿者，他们收到了来自全球的恐慌邮件。这不是任何个人的失败，而是在没有人正式负责维护的代码上建立关键全球基础设施的自然后果。”

企业合规成本对比

支出项	年度成本
SCA 工具	$120 万
OSPO 团队	$85 万
法务审查	$70 万
事件响应	$98 万
CLA 管理	$27 万
传统开源合规总计	$400 万
Malus 全面解放套餐	$5 万/年

Nolan 声称可节省 98.75%。

对"剥削"指控的回应

对"公地悲剧"的承认

法律与伦理争议

支持洁净室有效性的观点

版权法保护的是表达而非思想。1879 年的 Baker v. Selden 案确立了这一原则。Phoenix Technologies 在 1984 年通过洁净室方法成功克隆 IBM BIOS 并获得法院认可。如果 AI 生成的代码在表达层面与原始代码完全不同，仅功能等价，理论上不侵犯版权。

质疑洁净室真实性的核心论点

训练数据暴露：AI 模型在训练时已经接触过原始开源代码。如果 LLM 的权重中包含了原始代码的模式，其输出能否真正被视为"独立创作"？
AI 输出的版权归属：美国版权局已明确表示，纯 AI 生成的作品不受版权保护。如果 Malus 的输出没有人类作者，使用者也无法主张版权保护。
诱导侵权：明确以"绕过版权"为营销目的，可能构成诱导侵权（inducement liability）。

Slashdot 社区的高赞评论指出：“祝你好运让法官同意 AI 完成了’洁净室’实现——这个 AI 恰恰是在被它’重新发明’的代码上训练出来的。”

另一位评论者补充：“中国墙法律策略要求团队 A 产出规格书、团队 B 产出实现。如果这些人无法展示规格书，他们就完了。声称在 LLM 网络黑盒的抽象柏拉图空间里一定存在规格书，不会说服法庭。”

为什么这威胁开源的可持续性闭环

开源生态的可持续性依赖于一个隐性社会契约：

贡献者发布代码，获得声誉、协作机会和间接商业价值
使用者遵守许可证义务（署名、copyleft、回馈改进）
企业使用开源降低开发成本，同时通过合规投入反哺生态

Malus.sh 所展示的能力从三个层面破坏了这个闭环：

第一，许可证义务的 enforceability 被架空。 当任何人都能以接近零成本获得功能等价但法律独立的版本时，MIT 的署名要求、GPL 的 copyleft 约束、Apache 的声明保留条款都失去了实际约束力。

第二，贡献激励被侵蚀。 如果开发者知道自己的工作会被 AI 剥离义务地复制，为什么还要选择开源？声誉回报的前提是署名被尊重，而 Malus 的核心卖点正是"零署名"。

第三，企业合规投入的动机消失。 传统上，企业投入 OSPO、SCA 工具、法务审查，既是合规需要，也是间接支持开源生态的方式。当 Malus 将合规成本从 $400 万降到 $5 万，这笔"节省"不会流向开源项目，而是直接消失。

Nolan 自己在博客中承认的"公地枯萎"场景，描述的正是这个闭环的逐步瓦解：不是突然的崩溃，而是贡献意愿的缓慢侵蚀，最终导致开源 Commons 的枯竭。

不可逆的趋势

Malus.sh 本身可能是一个精心设计的讽刺作品，但它所展示的能力已经在被严肃地使用。Dan Blanchard 使用 Claude Code 重写 chardet 的案例表明，这种技术不需要专门的 Malus 平台——任何拥有主流 AI 编码工具的人都可以实现类似效果。

Blanchard 的评价代表了行业内的普遍共识：“以前需要团队数月或数年的重写，现在 AI 几天就能完成。我认为已经没有办法把精灵塞回瓶子里了。”

这一趋势的市场影响已经开始显现。2026 年初，Oracle 等软件公司股价因"AI 可被用于快速复制软件功能"的担忧而遭受抛售。

参考来源

Craft Agents 调研：一个文档原生的开源 Agent 桌面应用

Thu, 30 Apr 2026 01:26:00 +0800

Craft Agents 是由 Craft.do（Lukilabs）团队开发并开源的一款桌面应用，定位为"Agent-Native Software"，从零为 AI Agent 的工作方式设计界面，而非给现有工具附加 AI 能力。该项目于 2026 年初发布，采用 Apache 2.0 协议开源，截至 2026 年 4 月底在 GitHub 已获得 5,300 余星标。

核心定位：文档原生，而非终端或 IDE

当前主流的 Agent 工具大致分为两类：终端原生的 CLI 工具（如 Claude Code）和 IDE 集成方案（如 Cursor）。Craft Agents 选择了一条不同的路径，以文档为中心的独立桌面应用。

Craft.do 团队在其官方博客中写道，他们开发这款产品的动机是"想要一种更好、更有主见的方式来与世界上最强大的 Agent 协作"。其界面设计借鉴了邮件客户端和任务管理器的交互逻辑：会话以文档形式呈现，支持自定义状态流（Todo → In Progress → Needs Review → Done），并允许用户在多个任务间切换而不丢失上下文。

这种设计选择意味着 Craft Agents 的目标用户不限于开发者。产品经理、运营人员、设计师等非技术角色也能通过自然语言与 Agent 交互，无需学习终端命令或理解 IDE 的工作流。

自然语言配置：消除集成 friction

Craft Agents 最具辨识度的特性是其数据源配置方式。用户只需用自然语言描述需求，Agent 便会自动完成后续步骤。

以连接 Linear 为例，用户输入"把 Linear 加为数据源"后，Agent 会自动查找 Linear 的公开 API 和 MCP 服务器，读取相关文档，获取凭证并完成配置。这一过程无需手动编辑配置文件或处理 OAuth 授权流程。

该机制支持多种接入方式：

MCP Server：粘贴现有 MCP 配置 JSON，Agent 自动处理
本地 MCP：支持基于 stdio 的子进程，包括 npx、Python 脚本和任意本地二进制文件
REST API：粘贴 OpenAPI 规范、端点 URL，甚至文档截图，Agent 自行解析
无 API 场景：内置 Chromium 浏览器可直接登录网站并操作

Craft.do 团队在其博客中提供了一个具体案例：“我们甚至把它接入了位于跳板机后的私有 PostgreSQL 数据库。”

模型路由：双后端架构支持 400+ 模型

Craft Agents 的模型支持通过统一路由层实现，采用双后端架构：

Claude Agent SDK：处理 Anthropic 系列模型，支持自定义 base URL
Pi SDK：处理 Google AI（Gemini）、OpenAI（Codex）、GitHub Copilot 等

直接支持的提供商包括 Anthropic、OpenAI、Google AI Studio、GitHub Copilot。通过第三方网关和自定义端点，可扩展至 OpenRouter、Vercel AI Gateway、Ollama、LM Studio、DeepSeek 等，总计覆盖 400 余个模型。用户可在不同工作区设置不同的默认模型，也可在同一会话中切换模型而保持工作流不变。

值得注意的是，v0.8.10 版本新增了消息网关功能，支持 Telegram 和 WhatsApp 集成，提供三种响应模式（progress、streaming、final_only）。v0.8.12 则将 DeepSeek 作为 Pi 后端提供商原生支持，并默认采用 GPT-5.5。

三种执行模式与权限控制

Craft Agents 提供三种执行模式，通过 Shift+Tab 快速切换：

模式	行为	适用场景
Explore	只读，Agent 仅调研分析	安全探索、信息收集
Ask to Edit	每个动作需用户确认	建立信任、敏感操作
Execute	完全自主执行	成熟可信的工作流

每种模式对应不同的权限级别，用户可按需选择。此外，每个数据源可独立设置 read / write / execute 权限，实现细粒度的访问控制。

技能系统与 Claude Code 迁移

Craft Agents 内置技能（Skills）系统，允许用户定义可复用的 Agent 指令模板。创建方式同样采用自然语言：描述技能应该做什么，Agent 自动实现。使用时通过 @技能名 唤起，无需重启应用。

对于已有 Claude Code 使用经验的用户，Craft Agents 支持直接导入 Claude Code 的 Skills。这一设计降低了迁移成本，也反映了 Craft.do 团队对现有生态的兼容态度。

自举开发：用 Craft Agents 开发 Craft Agents

Craft.do 团队声称，他们"完全用 Craft Agents 开发 Craft Agents，不用任何代码编辑器"。这一声明在开源社区引发了讨论。如果属实，意味着该工具已具备支撑完整软件开发生命周期的能力；同时也意味着其当前能力上限受限于 Agent 自身水平。

该项目采用 TypeScript（90.4%）构建，基于 Electron 框架。安装支持一键脚本（macOS/Linux 通过 curl，Windows 通过 PowerShell），也可从源码构建。

与主流工具的对比

维度	Craft Agents	Claude Code	Cursor
形态	独立桌面应用	CLI / VS Code 扩展	VS Code Fork
界面哲学	文档为中心	终端/代码为中心	IDE 为中心
模型灵活性	400+ 模型，随时切换	仅限 Anthropic	多模型但受 IDE 限制
配置方式	自然语言	配置文件/命令	设置面板
多任务	原生收件箱	单会话	单会话为主
开源协议	Apache 2.0	闭源	闭源
非开发者友好	高	低	中

从对比可以看出，Craft Agents 的核心差异化在于"降低使用门槛"和"跨工具协调"。它更适合需要同时操作多个 SaaS 工具、频繁切换模型的场景，而非深度编码工作流。

潜在关注点

作为一款新兴工具，Craft Agents 也面临一些需要观察的方面：

生态成熟度。相比 Claude Code（Anthropic 官方背书）和 Cursor（大量用户基础），Craft Agents 的社区规模和第三方插件生态尚在早期阶段。

非代码场景的侧重。对于纯编码密集型任务（大型重构、复杂调试），IDE 集成度可能不如 Cursor 深入。其优势更多体现在跨工具协调和非技术用户场景。

Electron 性能。桌面应用基于 Electron 框架，长期大规模使用下的性能表现有待验证。

自举声明的可验证性。团队声称完全用自身工具开发，这一说法既是产品能力的证明，也可能意味着某些底层功能受限于当前 Agent 的能力边界。

适用场景评估

场景	适合度
跨工具协调（Linear + GitHub + Slack + Notion）	高
非开发者使用 Agent（产品经理、运营、设计师）	高
需要频繁切换模型的研究/实验	高
本地/离线模型运行	高
纯编码密集型开发	中
需要深度 IDE 集成的开发	中

信息来源

本文基于 Craft Agents 官方文档、GitHub 仓库公开信息及第三方技术评测整理。产品功能可能随版本更新发生变化。

Anthropic 将 Claude Code 从 Pro 订阅移除：传言核实与影响分析

Wed, 22 Apr 2026 00:21:37 +0800

2026 年 4 月 21 日前后，一条关于 Anthropic 调整订阅策略的消息在技术社区快速传播：Claude Code（Anthropic 旗下的命令行 AI 编码工具）将从 20 美元/月的 Pro 订阅中移除，仅保留给 100 美元/月起的 Max 计划用户。本文基于官方文档存档、独立媒体报道与开发者社区反馈，对这一传言进行核实与梳理。

核心证据：支持文档已全面修改

最直接的事实来自 Anthropic 官方支持文档的变更。

根据 Wayback Machine 的存档记录，2026 年 4 月 10 日，该文档的标题仍是 “Using Claude Code with your Pro or Max plan”。而目前，同一文档的标题已被改为 “Using Claude Code with your Max plan”，全文仅提及 Max 计划，未出现 Pro 字样。

存档版本（4 月 10 日）：https://web.archive.org/web/20260416084035/https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
当前版本：https://support.claude.com/en/articles/11145838-using-claude-code-with-your-max-plan

定价页面的信息则更为复杂。Max 计划页面（claude.com/pricing/max）明确表述：“The Max plan combines Claude desktop and mobile apps and Claude Code in one subscription”。而 Pro 计划页面的功能列表中已不再包含 Claude Code，尽管页面顶部的营销文案中仍有一句 “and Claude Code for building software”。这种文案与功能列表的不同步，更像是渐进式调整过程中的遗留痕迹。

官方回应：“2% 新用户测试”

Anthropic 负责增长的员工 Amol Avasare 在 X 平台上回应称：

这一说法与表面证据之间存在明显张力。如果仅仅是针对 2% 新用户的小范围 A/B 测试，通常不需要同步修改全局公开的支持文档和定价页面表述。独立记者 Ed Zitron 在报道中也指出了这一矛盾。

背景：并非孤立事件

这次调整不是 Anthropic 第一次对 Claude Code 的订阅权益动手。

据 TechCrunch 与 The Next Web 4 月 4 日的报道，Anthropic 已在此前阻止 Pro 和 Max 订阅用户通过第三方框架（如 OpenClaw）使用 Claude Code，要求这些用户转向按量付费（pay-as-you-go）的 API 计费模式。The Next Web 的报道提到，当时已有超过 135,000 个 OpenClaw 实例在运行，而重度 agentic 用户的订阅费用与等效 API 成本之间存在超过 5 倍的价差。

Anthropic Claude Code 负责人 Boris Cherny 当时的解释是：“subscriptions weren’t built for the usage patterns of these third-party tools”。

开发者社区反应：负面情绪占主导

Hacker News 上出现了多个相关讨论帖，合计超过 300 条评论，社区情绪以负面为主。

多位用户报告称，作为现有 Pro 订阅者，他们在网页端已看到 Claude Code 被移除的提示，但命令行界面（CLI）目前仍可运行。这种 “Web 端已显示移除、CLI 仍可用” 的状态，加剧了用户对 “现有订阅者不受影响” 这一承诺的担忧。很多人担心这只是过渡期，未来 CLI 访问也会被切断。

转向竞品的讨论非常活跃。被提及的替代方案包括：OpenAI Codex（20 美元/月订阅包含 Codex）、OpenCode + OpenRouter、GLM-5.1、Kimi 以及本地运行的 Qwen 等开源模型。部分年付 Pro 用户表示，如果功能被中途移除，将考虑发起 chargeback。

Max 计划的实际定价

Max 计划目前分为两档：

Max 5x：100 美元/月，提供 Pro 计划 5 倍的消息限额
Max 20x：200 美元/月，提供 Pro 计划 20 倍的消息限额

值得注意的是，Max 计划的限额是 Claude 网页/桌面/移动端与 Claude Code 共享的。部分 Max 用户反馈，Opus 4.7 模型推出后，token 消耗速度明显加快，限额比以往更容易耗尽。

可信度评估

论断	可信度
Anthropic 正在将 Claude Code 从 Pro 中移除	高 — 支持文档已改，功能列表已调整
仅 Max 计划（5x/20x）保留 Claude Code	高 — Max 页面明确包含，Pro 功能列表已移除
“只是 2% 新用户测试”	低 — 全局文档修改与 A/B 测试的解释存在矛盾
现有 Pro 用户立即失去访问	中低 — CLI 目前仍可运行，但未来政策不明朗

小结

Anthropic 确实在推进将 Claude Code 从 Pro 订阅剥离的政策。支持文档、功能列表的调整已是既成事实，区别只在于推进节奏——是仅限新用户的渐进过渡，还是未来会覆盖所有存量订阅者。对于依赖 Claude Code 的开发者而言，这意味着最低使用门槛从 20 美元/月抬升至 100 美元/月，或被迫转向按量付费的 API 模式。社区对此的反应是明确的：大量开发者正在重新评估他们的 AI 编码工具栈。

参考来源

Ed Zitron, News: Anthropic Removes Claude Code From $20-A-Month “Pro” Subscription Plan For New Users (Developing), wheresyoured.at, 2026-04-21
Amol Avasare, X post, 2026-04-21
TechCrunch, Anthropic says Claude Code subscribers will need to pay extra for OpenClaw usage, 2026-04-04
The Next Web, Anthropic cuts Claude subscribers off from OpenClaw in cost crackdown, 2026-04-04
Hacker News 讨论帖：news.ycombinator.com/item?id=47854477 等
Anthropic 官方支持文档：当前版本与 Wayback Machine 存档

OpenCode Go 模型订阅服务价格和用量规则解读

Tue, 21 Apr 2026 10:53:36 +0800

OpenCode Go 是 OpenCode 推出的低成本开源编程模型订阅服务，首月 5 USD、续费 10 USD/月，承诺以固定月费提供稳定的开源模型 API 访问。当前处于 Beta 测试阶段，模型托管在美国、欧盟和新加坡。这篇文章基于官方文档、GitHub Issues、Discord 社区等渠道的公开信息进行综合分析。

一、产品概况与核心数据

支持的模型列表

官方目前提供 10 款开源编程模型：

模型	提供商
GLM-5 / GLM-5.1	智谱 AI
Kimi K2.5 / K2.6	Moonshot AI
MiMo-V2-Pro / MiMo-V2-Omni	小米
MiniMax M2.5 / M2.7	MiniMax
Qwen3.5 Plus / Qwen3.6 Plus	阿里巴巴

注意事项：

该列表为动态维护，“随着测试和添加新模型可能发生变化”
部分模型使用 OpenAI 兼容格式，部分使用 Anthropic 格式，API 模式不完全统一
每个 workspace 仅允许一名成员订阅 Go 服务

核心参数

项目	内容
定价	首月 5 USD，续费 10 USD/月
使用限制	12 USD/5h、30 USD/周、60 USD/月（美元价值）
阶段	Beta 测试
托管地	美国、欧盟、新加坡
支持模型数	10 款

二、计费规则与使用限制

“美元价值"的计算逻辑

OpenCode Go 的限制以"美元价值"定义，而非固定请求数。每次请求按该模型的实际 API 成本扣除额度。10 USD 订阅费换取的是 60 USD/月的"使用上限”，不是固定次数。

不同模型在三重限制下能发出的请求数差异极大：

模型	每 5 小时	每周	每月
Qwen3.5 Plus	10,200	25,200	50,500
MiniMax M2.5	6,300	15,900	31,800
Qwen3.6 Plus	3,300	8,200	16,300
MiniMax M2.7	3,400	8,500	17,000
MiMo-V2-Omni	2,150	5,450	10,900
MiMo-V2-Pro	1,290	3,225	6,450
Kimi K2.5	1,850	4,630	9,250
GLM-5	1,150	2,880	5,750
Kimi K2.6	1,150	2,880	5,750
GLM-5.1	880	2,150	4,300

关键发现：Qwen3.5 Plus 最充裕，5 小时内能发约 1 万次请求；GLM-5.1 仅约 880 次，相差超过 11 倍。高频使用时，5 小时限制最先被触发。

注意，这是官方给出的"建议估计"（recommended estimates），每次实际请求的 tokens 数会直接影响真实消耗。

三层级限制如何运作

时间维度	限额	重置周期
5 小时	12 USD	5 小时
每周	30 USD	一周
每月	60 USD	一月

最容易触发的是 5 小时限制。以 Kimi K2.6 为例，每 5 小时仅能发 1,150 次调用，一个涉及 10 轮调用的复杂任务只能完成约 115 个。如果在一个 session 中高频使用（如自动化重构、大规模代码审查），可能很快触发此限制。

超出限制的处理

在控制台启用"使用余额"选项，用 Zen 余额继续
或降级使用免费模型
也可等待限制重置

三、潜在问题与限制

以下问题与限制均与 OpenCode Go 订阅服务直接相关。

1. Beta 阶段固有风险

订阅服务处于 Beta，功能和限制可能随时调整
模型列表不固定，“随着测试和添加新模型可能发生变化”
官方文档明确说明"该列表可能会发生变化"，存在订阅后模型下架或调整的风险

2. 模型 API 兼容性问题

通过 OpenCode Go API 调用部分模型时存在格式兼容性问题：

Kimi K2.5/K2.6 工具调用错误：部分用户报告在调用 Kimi 模型时遇到 "reasoning_content is missing in assistant tool call message" 错误（GitHub #15197、#23646）
当启用 thinking 功能时，工具调用容易失败
相关 issue 数量较多，影响稳定性
注意：这些问题主要出现在通过 OpenCode 平台调用 Kimi 模型的场景，直接调用原生 Kimi API 可能不存在此问题

3. 使用限制约束

限制类型	说明
工作空间限制	每个 workspace 仅一名成员可订阅 Go 服务
API 格式不一致	部分模型使用 OpenAI 兼容格式，部分使用 Anthropic 格式，统一配置时需要分别处理
隐私合规	数据需经海外第三方提供商（Moonshot、MiniMax、Zhipu 等）的服务器
服务稳定性	Beta 阶段偶有服务波动，某些时段模型可能暂时不可用

四、与 AI Agent 工具搭配的适配性评估

OpenClaw / Hermes Agent 等 AI Agent 框架通过 OpenCode Go API 调用模型时，核心关注两个维度：模型能力与额度是否匹配。

Agent 核心需求 vs 现实能力

Agent 核心需求	OpenCode Go 现状
稳定的工具调用	⚠️ Kimi 存在兼容性问题；Qwen 相对稳定
多轮对话追踪	✅ 支持，但长会话消耗快
长上下文处理	⚠️ 缓存 token 消耗计入额度
高可用/低延迟	⚠️ Beta 阶段，偶有服务波动

模型选择建议

推荐：Qwen3.5 Plus / Qwen3.6 Plus

每月 16,000–50,500 次请求，量最足
对中文支持更好
工具调用相对 Kimi 更稳定，社区反馈中相关 bug 报告较少
复杂多步骤任务能力略逊于顶级商业模型，但对日常代码任务足够

谨慎：Kimi K2.5/K2.6

工具调用存在 reasoning_content 缺失 bug
GitHub 上有多起相关 issue（#15197, #20427, #20650）
如果主要用于简单代码生成可用，但做 Agent 核心模型风险较高

额度够用吗？

以 Qwen3.5 Plus 为例，在 60 USD/月限额下：

任务类型	平均 API 调用次数	每月可完成任务数
简单问答	1 次	~50,000 个
代码修改	2–3 次	~15,000 个
复杂功能开发	5–10 次	~5,000 个
大型项目分析	10–20 次	~2,500 个

关键瓶颈：5 小时限制 (12 USD)。如果在一个 session 中高频使用（如自动化重构、大规模代码审查），可能很快触发。以 Kimi K2.6 为例，每 5 小时仅 1,150 次调用，一个复杂任务如果涉及 10 轮调用，只能完成约 115 个任务/5h。

结论

场景	是否足够
轻量 Agent 工作（日常代码辅助）	✅ 足够
中等频率 Agent 任务	⚠️ 紧张，建议选 Qwen3.5 Plus
高频、长会话的 Agent 工作流	❌ 不足够，容易触发 5h 限制

五、社区真实用户反馈

以下反馈主要来源于 GitHub Issues 和 Discord 社区的公开讨论。Reddit、Hacker News 等社区未能完整搜索。

与 Go 订阅直接相关的反馈

正面：

价格优势明显：多名用户认为 10 USD/月能接触多款开源模型是"非常划算"的，特别是对于想尝试不同模型的开发者
模型质量可用：Qwen3.5 Plus 和 MiniMax M2.5 在日常编程任务中表现稳定
访问稳定性改善：相比直接调用各模型原生 API，OpenCode Go 的统一接口减少了配置复杂度

负面：

Kimi 模型工具调用不稳定：多名用户报告在使用 Kimi K2.5/K2.6 时遇到 reasoning_content 错误，影响自动化工作流
限制额度偏低：部分重度用户认为 60 USD/月的限额对于高频使用场景不够，特别是使用高端模型时
Beta 不确定性：模型列表和限制额度可能随时调整

适合人群

推荐使用：

想以低成本尝试多款开源编程模型的个人开发者
使用 Qwen3.5 Plus 进行日常轻量代码辅助
需要稳定接口访问不想逐一配置各模型原生 API 的用户

不推荐：

需要高频、长会话的 AI Agent 工作流
依赖 Kimi 模型做核心工具调用的场景
对服务稳定性要求极高的生产环境

声明：本文信息基于 OpenCode 官方公开文档及 GitHub Issues 等渠道的公开资料整理。OpenCode Go 处于 Beta 阶段，部分信息可能随时间变化。

2026 年企业 AI 转型的幻觉与现实

Tue, 21 Apr 2026 06:30:26 +0800

X 平台用户 @dashen_wang 发布了一份关于 2026 年企业 AI 转型的系统性分享。文章涉及从根本逻辑到组织执行、从人才配置到安全合规的二十余个话题。细节充实，语境也带有明显的个人经验色彩。

这类文章的价值不在于"标准答案"——AI 转型没有标准答案——而在于提供一个可以被检验的框架。下文是对这份分享的解读：抽出其中具有跨行业通用性的逻辑，分析那些值得被放大的观察，以及那些需要被补充或修正的地方。

一、根本问题：先问"不用会怎样"，再问"用了能多好"

作者的切入方式是对的。大部分企业谈 AI 转型时，习惯于描绘"用了以后会多好"，却忽略了更关键的问题：“如果今天就开始不用 AI，三个月后会发生什么？”

这个问题的价值在于，它把决策从"主动优化"转变为"被动追赶"。很多企业对 AI 的态度之所以动摇，不是因为不相信技术，而是因为没有计算出"不做"的真实成本。当竞争对手已经用 AI 拉开了成本差距，你的高成本结构就变成了自己的地雷。

作者进一步把这个原理缩减成一句话：AI 转型的本质是用更低的成本做出质量不低于原来的东西，然后用省下来的资源去打别人不敢打的仗。 这个比喻是精准的，它把降本和攻击性放在了同一个逻辑里——降本不是目的，降本后的资源重新配置才是。

这一观点对于任何规模的组织都有参考价值：AI 投资的评估标准不应该是"节省了多少钱"，而是"节省下来的资源能做多少原来做不了的事"。

二、“增效"与"降本”：一个需要被补充的判断

作者的一个核心判断是：降本是可以算的，增效是一个感受。 这个判断有实际价值，但需要补充思考。

它的合理性在于：企业决策层往往需要用可量化的数字来说服各方利益相关者。“明年费用减少30%“比"员工工作体验更好"更容易获得批准。但它的局限性在于：AI 的价值并非全部体现在成本节约上。在产品创新、决策效率、客户体验提升等领域，AI 带来的"增效"虽然难以被传统财务语言完整归纳，但其竞争意义可能远超纯粹的成本节约。

更准确的表述可能是：降本是转型的入口，增效是转型的天花板。 企业可以从降本开始因为它可以量化、可以评估、可以提交。但如果只停留在降本层面，AI 投资就成了只是一个更高级的自动化项目。

三、从哪里入手：投入产出比优先，而非声势优先

作者提出的入手选择逻辑是这篇文章最具操作性的部分之一。作者用两个企业主的对比案例来说明这个原则：老板 A 花30万消灭一个年薪10万的岗位，回本周期3年；老板 B 花10万优化一个低薪高重复性的流程，回本不到10个月。

这个案例很形象，但需要抽象到更通用的选择标准：“高重复、低改造成本、可快速验证” 的任务要优先于"高价值但复杂、高不确定性"的任务。这不仅仅是 AI 转型的原则，是任何组织变革的通用原则——先让大家看到效果，再让大家相信这个方向是对的。

作者列出了五类通用需求：文本处理、数据分析、客服与售前、内容生产、代码辅助。这个分类粗略但无大碍，对于尚未入门的企业可以作为一个检查清单使用。值得强调的是作者的一个观点：AI 替代的不是岗位，而是岗位里的低价值部分。当一个人 70% 的工作被 AI 替代后，剩下的 30% 可能不足以支撑这个位置存在。这个判断是冷静的，但是结构性的——不是主管的主观意愿决定的。

四、定制需求：行业门槛是什么

在通用需求之外，作者用几个行业案例说明了定制需求的门槛在哪里。这些案例涉及制造业的视觉检测、电商的图像生成、以及法律金融领域的专业文本分析。

提炼这些案例后的共性是清晰的：定制需求的门槛不是技术难度，而是领域数据的获取与标注能力。一个通用大模型可以识别一般性的缺陷，但你的产品上的特定缺陷图谱是你独有的。这些图谱不能从开源数据集里获取，也不能被竞争对手复制。这就是定制 AI 解决方案的核心优势——不是模型本身，是数据资产。

这一观点对于非技术背景的企业家特别重要：AI 项目的核心挑战往往不是"找一个开发者”，而是"怎么把我的业务知识结构化、标准化，让模型能够学习”。前者是人力问题，后者是组织问题。组织问题通常比人力问题更难解决，但也更有门槛。

五、人才配置：复合型人才优于单一型专家

作者在人才配置上有一个反常规的观点：不需要顶尖人才，需要有真实行业经验的人。 这个观点值得被放大。

传统招聘逻辑下，企业做 AI 项目往往第一反应是找"技术专家"。但技术专家的知识储备和企业的业务语境是脱节的。一个懂视觉模型的人不一定懂你的产品的品质标准。一个会调模型的人不一定知道你的客户的真实问题。

更合理的配置是：找一些在业务里长期积累过、同时愿意学习工具的人，把 AI 当作他们的助手而不是替代者。他们的价值不在于写代码，在于能够在业务场景里做出正确的判断——什么该交给 AI，什么该留给自己，什么该反馈。

这个观点的跨行业适用性很强。无论是律师事务所、咨询公司、还是制造业，最有价值的 AI 应用往往出自"懂业务的人"而不是"懂 AI 的人"之手。

六、组织执行：“专项小组模式"与"轻量结构”

作者提出了两个组织层面的概念，值得被独立分析。

专项小组模式指的是在不影响主体运营的情况下，另起炉灶成立一个 AI 小团队。这个方法的智慧之处在于回避了"改造已有团队"的巨大阻力。传统团队有习惯、有利益、有故事，你在里面推 AI，所有人都会觉得自己在被改革。新小队没有这个负担——用 AI 做事是它的默认状态。

这个方法对于大中型组织特别有价值：不需要等到全公司"准备好了"才开始，也不需要经理人全员认可。三个月完成一个原型，六个月有量化成果，这种节奏感对于保持团队士气至关重要。

轻量结构是一个更深层的趋势观察。作者引用了国外一人公司的案例：几个人借助 AI 和自动化工具，可以支撑起传统意义上需要几百人才能完成的业务量。这个趋势对传统企业的启发是双重的：

一方面，你的竞争对手可能已经是轻量结构，用少量人力加杠杆来打你的重资产模式。另一方面，你也可以让自己的新业务以轻量方式启动——轻、快、低成本，验证了再扩大，失败了损失也小。

这两个概念的共性是：AI 转型不是对现有体系的翻修，而是平行的建设。 你不需要等到旧天花板埋好了才能建新房子。

七、SaaS 的隐性风险：功能可复制，资产不可

作者对运营 SaaS 产品的公司提出了一个被很多人忽视的风险：AI 开发门槛的降低，意味着越来越多的核心功能可以被快速复制。更进一步，AI Skill 或 MCP 工具可能直接解构你的订阅价值主张。

这个观察的价值在于，它把 SaaS 的"核心优势"从功能层面拉到了资产层面。以前谈 SaaS 门槛会提到功能复杂度、技术深度、开发者生态。现在这些都在被证伪：一个人花一周时间可以复制中等复杂度的核心功能。

真正的门槛是你的数据积累、工作流整合深度、用户迁移成本。这三样东西不能被一行代码复制，也不能被一个 AI Skill 替代。这个论断不仅仅适用于 SaaS，对于任何以"功能"为核心价值的产品都是提醒——你的价值在哪里，它是不是正在被技术普及化？

八、流量逻辑：SEO → SEM → GEO 的更替

作者提出的"三位一体"流量框架是这篇文章里信息密度最高的部分之一。

SEO（搜索引擎优化）和 SEM（付费广告）是这个框架里的"老两件"，但作者对它们在 AI 时代的位置做了重新定位。SEO 的重要性正在被分流，但不是消失；SEM 的 AI 优化已经是基础能力，不是优势。

真正的"新鲜"是 GEO —— Generative Engine Optimization，即"生成式引擎优化"。当用户不再是在搜索框里输入关键词，而是在 ChatGPT、Perplexity 等 AI 工具里直接提问时，你怎么出现在 AI 的答案里？

作者引用了一个有意思的数据：Google 页面排名靠前的内容和 AI 回答里被引用的内容，重合率已经从 70% 降到不到 20%。这意味着你 SEO 做得很好，不代表 AI 会推荐你。这是两套逻辑，需要两套能力。

GEO 的核心方法是让你的内容成为 AI 引用的"权威来源"——结构清晰、直接回答问题、包含统计数据与权威引述。研究发现，内容里加入数据引用可以让 AI 引用率提升 41%。

这个框架对于任何依赖内容获客的组织都有参考价值：早期企业先做 SEM 快速获取付费流量，成长期企业做 SEO 积累长尾，有内容积累的企业开始布局 GEO 抢占 AI 时代内容高地。

九、流量平台：最终赢家不变

作者提到了一个冷酷的结论：AI 提升了广告主的能力，导致市场上有效广告主数量大幅增加，但用户注意力没有同比例增长，竞价抬高，最终钱都流向了平台。

这个判断的使用场景是提醒：你不能只做投流。你要同时做流量资产——内容、知识库、自有用户、SEO 权重、GEO 声誉。这些东西平台拿不走。

这个观点很好地补充了前面的流量框架：投流是租赁，资产是买房。你需要两者都有，但不能只有前者。

十、数据与合规：敏感地带往往最易被忽略

作者在安全与合规维度的分享非常具体，涉及恶意输入攻击、上游 Token 供应商风险、代码安全、高风险行业输出、内容安全红线、以及数据获取的法律边界。

这些内容的共性是：AI 安全问题不是上线之后才补救的，是设计阶段就要考虑的。 作者特别强调了一个被很多人忽略的细节：如果你通过第三方中间商购买 AI 额度，那个中间商可以看到你所有请求内容，甚至修改 AI 的回复。涉及敏感业务数据的调用，应该直接使用官方 API。

在数据获取合规性上，作者提醒了一个常见的误区：“我不知道数据怎么来的"在法律上不是免责理由。很多线索自动化工具、竞争情报系统的底层是爬虫，可能触及《个人信息保护法》《反不正当竞争法》等法规。受罚的往往是数据的使用方而不是工具提供方。

这一部分的价值在于，它把"合规"从一个法务部门的事情，变成了产品经理和技术负责人需要在设计阶段就考虑的事情。

一个需要审慎看待的观点

在整体框架里，有一个地方需要被单独拿出来讨论。

作者认为"AI 营销投流是唯一能量化的增效方向”，并引用了一组数据（ROI 平均高出 22%，点击率高 47%，回本周期从 7.8 个月缩短到 4.2 个月）。

这个论断需要被纠正。投流 ROI 量化的背后是平台的数据基础设施——你能看到 ROI 是因为平台提供了完整的转化跟踪能力。但这不意味着 AI 在其他领域的增效不可量化。

例如，在客服场景里，AI 代替人工处理标准化问题后，人工客服的时间可以被释放出来处理更复杂、更高价值的问题。这个"释放出来的时间"是可以被量化的。在代码开发场景里，AI 辅助减少的重复性工作量，转化为更短的交付周期，这也是可以被量化的。

更准确的说法可能是：量化的难度不同，但增效是存在的。 把增效完全否定，可能会让企业只做投流而忽略了更深层次的变化。

关于知识库的观察

作者用大量篇幅谈到了知识库建设的重要性。这个观察本身没问题，但需要被放到更大的语境里看。

很多企业的知识分散在老员工脑子里、群聊记录里、没被打开过的文档里。员工离职带走的不只是人，是知识。这个现象是真实的，不是 AI 时代才有的。

AI 的价值在于，它让知识库从一个"查询工具"变成了一个可以被智能体调用的"运行底座"。但建知识库的难度不在于把文档上传，在于把隐性知识变成显性知识。这需要组织有"知识管理"的意识，而这个意识不是 AI 带来的，是管理层本来就应该有的。

AI 是放大器。它放大了你的长处，也放大了你的短处。如果你的知识管理是一团糟糕，AI 会让它变成一团更大的糟糕。

关于轻量结构与扩展的补充

作者在谈到新业务扩展时提出了一个原则：“延伸有根，跑偏是赌”。这个原则值得被强调。

轻量结构优势在于轻和快，但它的局限在于难以做重。如果一个业务需要深度客户关系、重资产投入、长周期信任累积，轻量模式很难成为主体。所以轻量更合适的位置是：新业务试错、旧业务补强。 而非对传统核心业务的彻底改造。

可执行的行动清单

综合以上解读，以下是可以被直接复制的行动顺序：

检查通用需求：文本、数据、客服、内容、代码，今天就能用的，不要等
找最高投入产出比的入手点：人多、重复、工资不高、改造成本低的位置先动
先降本，再谈增效：降本是入口，增效是天花板
成立专项小组：不要改造老团队，新起炉灶，4-6 个月出成果
整理知识资产：产品手册、SOP、案例、客户问答，每周三小时，六个月后见效
布局流量三位一体：SEM 获客、SEO 积累、GEO 抢占 AI 时代内容高地
审视数据合规性：确保数据来源清晰，不要在"不知道怎么来的"边缘游走
安全前置化：输入边界、敏感业务人工审核、官方 API 直连，不是上线后补救
配备复合型人才：懂业务 + 会用工具，而非单纯技术专家
保持轻量思维：新业务试错用轻量，验证了再加杠杆，延伸有根，跑偏是赌

总结

这份分享的核心价值不在于给出了多少"标准答案"，而在于提供了一套可以被检验的思维框架：

用"不用 AI 会怎样"来驱动决心，而非"用了能多好"
用"降本"作为入口，但不停留在降本
用"最高投入产出比的入手点"来启动，而非最显眼的项目
用"专项小组模式"来结构化执行，而非全面改革
用"知识库"和"资产"来建立门槛，而非功能本身

这个框架适用于从初创公司到中型企业的大多数场景。它不是万能药方，但是一个可以让企业快速进入状态、避免走弯路的启动检查清单。

本文是对 X 平台 @dashen_wang 发布的《2026 企业 AI 转型全面指南》的解读。原文地址：https://x.com/dashen_wang/status/2046051525391425882

Z.ai 收紧 GLM Coding Plan 使用政策：非编程用途将触发限流与封号

Tue, 21 Apr 2026 01:26:07 +0800

事件概述

近日，AI 平台 Z.ai 更新了其 GLM Coding Plan 订阅套餐的使用政策，将该套餐严格限定于编程场景。根据用户社区及官方公告，非编程用途（如运行 AI Agent、角色扮演、翻译网站、通用聊天等）现在会触发平台的风控机制，多次违规可能导致永久封号，且订阅费用不予退还。

这一变化在海外 AI 用户社区引发了广泛讨论，也被部分从业者解读为 AI 订阅商业模式从"补贴抢用户"向"精准获取训练数据"转变的信号。

政策细则：官方怎么说

根据 Reddit 用户 JustSomeGuy3465 分享的 Z.ai 官方公告截图，GLM Coding Plan 的新政策包含以下核心条款：

用途限定：GLM Coding Plan 专为 Coding Scenarios 设计。若系统检测到订阅被用于与编程无关的请求，平台可能限制相关订阅权益。
风控措施：违反 Usage Rules 并触发风控规则后，账号可能面临高强度限流（high-intensity throttling）、账号暂停或永久封号。
违规红线：违反 Usage Rules 三次及以上，将导致账号被封（permanent ban），且订阅费用不退。

该用户同时指出，近期大量用户遇到的 1302、1303 速率限制错误即与此政策更新有关。

用户反馈：社区里的实际情况

在上述 Reddit 帖子中，发帖者明确劝诫：“If you are thinking about buying or renewing a Z AI coding plan subscription for anything other than coding: Don’t do it.”

评论区及关联讨论显示，已有部分用户反映自己的账号在用于非编程场景（如通过 OpenClaw 运行 Agent 或进行角色扮演对话）后遭到封禁，且事前未收到明确警告。

值得注意的是，该套餐此前因价格相对低廉，吸引了不少非编程用途的用户购买。政策突变后，这部分用户成为了最直接受影响的人群。

行业评论：OpenClaw 创始人的观察

OpenClaw 创始人 Peter Steinberger（@steipete）在 X 平台上针对此事发表评论：

Steinberger 的观点将这一政策变化置于更大的行业背景下：部分 AI 平台的低价订阅并非以订阅费本身为盈利点，而是以换取用户在实际工作流中产生的高质量代码数据为目的。

第三方分析：补贴逻辑的再审视

中文科技推主阿绎 AYi（@AYi_AInotes）在转发 Steinberger 观点时，进一步展开了对这一现象的分析：

数据价值的差异：该推主认为，用户在日常工作中产生的真实私有代码，其质量远高于 GitHub 等平台的公开代码，对训练下一代代码模型具有更高的数据价值。
成本结构的冲突：运行 Agent、聊天、角色扮演等行为消耗大量 GPU 算力，却不产生对平台模型训练有用的数据回报。从平台视角看，这类使用模式构成了"净成本"。
行业趋势判断：整个 AI 行业可能正从"通过补贴获取用户规模"的阶段，转向"通过精准定价筛选高价值用户"的阶段。

需要指出的是，上述分析属于个人观察与推断，尚未得到 Z.ai 或相关平台的官方确认。

观察与小结

从现有信息来看，Z.ai 此次政策调整的事实层面是清晰的：GLM Coding Plan 的适用范围被显著收窄，非编程用途面临明确的风险。 对于已订阅或计划订阅该套餐的用户，需首先确认自身的实际使用场景是否符合平台定义。

关于 Steinberger 及中文推主提出的"数据换取补贴"假说，它提供了一种解释低价订阅策略的视角，但将其推广为整个行业的普遍规律仍需要更多证据。不同平台的成本结构、商业模式和竞争策略存在差异，单一案例不足以概括全貌。

对于普通用户而言，更实际的关注点在于：在订阅任何 AI 服务前，仔细阅读其使用政策（Usage Policy）的更新条款，避免因政策变动导致账号或服务受限。

国内主流 AI Coding Plan 选购指南：9 家平台速度与价格实测对比

Thu, 16 Apr 2026 09:46:38 +0800

自 2025 年下半年起，国内大模型厂商纷纷推出面向开发者的 Coding Plan 订阅套餐，用固定月费取代传统按 Token 计费的模式，大幅降低 AI 辅助编程的使用门槛。然而，各家平台在定价、额度、响应速度和模型支持上差异巨大，甚至存在计量单位不同、限额严格等隐藏条款，让不少开发者感到选择困难。

本文综合一篇小红书实测笔记、博客园的深度横评以及各平台官方文档，从价格与速度两个核心维度，对国内 9 家 Coding Plan 进行梳理，希望能为你的选购决策提供参考。

一、Coding Plan 的计费模式与避坑要点

在对比具体套餐之前，有必要先厘清三家厂商采用的不同计量单位，这是最容易踩坑的地方：

API 请求次数：阿里云百炼、火山方舟、无问芯穹采用此方式。一次用户提问（Prompt）后台可能触发 5~30 次模型调用，每次调用均计为 1 次 API 请求（据腾讯云官方文档）。
Prompt 次数：智谱 GLM、MiniMax 采用此方式。1 次 Prompt 约等价于 1200~1600 次 API 请求。
Token 计量：Kimi 于 2026 年 1 月 28 日切换为此模式，按输入输出 Token 计费，且缓存命中率会直接影响实际可用额度。

由于计量单位不同，单纯比较数字没有意义。例如百炼 Lite 的「每 5 小时 1200 次 API 请求」与智谱 Lite 的「每 5 小时 80 次 Prompt」在实际使用强度上可能相差无几。

二、价格与额度对比

2.1 四大厂平台

根据小红书笔记中的截图以及博客园的整理，阿里云百炼、火山引擎、腾讯云、京东 JoyCoder 的定价策略高度趋同：

平台	Lite 套餐	Pro 套餐	核心额度（Lite）	支持模型
阿里云百炼	¥40（首月 ¥7.9）	¥200	1200 次/5h，9000 次/周，18000 次/月	Qwen3.5-Plus、Qwen3-Coder-Next、GLM-4.7、Kimi-K2.5
火山方舟	¥40（首月 ¥8.91）	¥200	与百炼一致	Doubao-Seed-Code、DeepSeek-V3.2、GLM-4.7、Kimi-K2.5
腾讯云	¥40（首月 ¥7.9）	¥200	与百炼一致	Hunyuan 系列、MiniMax-M2.5、Kimi-K2.5、GLM-5
京东 JoyCoder	¥40	¥200	与百炼一致	DeepSeek-V3.2、Kimi-K2.5、MiniMax-M2.7、GLM-5

2.2 新兴 AI 厂商

相比四大厂，新兴厂商的定价更加分散：

平台	入门价格	核心额度	计费方式	特点
无问芯穹	¥19.9/月	1000 次/5h，6000 次/周	API 请求	月费最低，多模型聚合
MiniMax	¥29（首月 ¥9.9）	40 Prompt/5h，无周限额	Prompt	入门价最低，无每周限额
Kimi	¥49（Andante）	按 Token（限时 3 倍）	Token	原生多模态，256K 长上下文
智谱 GLM	¥49（2 月涨价后）	80 Prompt/5h，400/周	Prompt	纯自研模型，20+ 工具适配
阶跃星辰	未测试	—	—	暂无实测数据

从性价比角度看：

预算敏感用户：无问芯穹（¥19.9）和 MiniMax（¥29）的入门门槛更低。
新用户试水：阿里云百炼首月 ¥7.9 是目前已知最低的尝鲜价。

三、速度实测：TTFT 与 TPS

以下速度数据来自一篇小红书实测笔记，测试条件为「白天 @ 10K tokens」，分别测量了首 Token 响应时间（TTFT）与TPS 生成速度。这些数据能直接反映编程时的「跟手」体验与代码生成效率。

3.1 首 Token 响应时间（TTFT）

平台	最快模型	TTFT	最慢模型	TTFT
智谱 GLM	glm-5-turbo	1.43s	glm-5	7.82s
腾讯	hunyuan-2.0-thinking	2.51s	kimi-k2.5	12.38s
MiniMax	m2.1	2.44s	m2.5	5.54s
阿里	glm-4.7	2.76s	qwen3-coder-next	11.58s
无问芯穹	deepseek-v3.2-thinking	3.26s	kimi-k2.5	7.76s
火山	doubao-seed-2.0-pro	3.29s	glm-4.7	21.52s
京东	deepseek-v3.2	~5s	kimi-k2.5	~19s
Kimi	kimi-for-coding	5.71s	—	—

观察：智谱 GLM 的 glm-5-turbo 以 1.43s 的 TTFT 全场最快；火山和京东平台上部分模型的首字响应时间则明显偏高，分别达到 21.52s 和 19s，可能与平台调度策略或模型部署方式有关。

3.2 TPS 生成速度

平台	最快模型	TPS	最慢模型	TPS
智谱 GLM	glm-4.5-air	103	glm-5	23
火山	doubao-seed-2.0-pro	76	kimi-k2.5	23
腾讯	hunyuan-2.0-thinking	76	glm-5	30
阿里	qwen3-coder-next	67	glm-4.7	41
无问芯穹	minimax-m2.5	51	kimi-k2.5	25
MiniMax	m2.5	48	m2.1	45
京东	deepseek-v3.2	35	glm-5	25
Kimi	kimi-for-coding	35	—	—

观察：智谱 glm-4.5-air 的 TPS 达到 103，显著领先其他平台；火山和腾讯的混元/豆包模型也能达到 76 TPS。京东和 Kimi 的 TPS 相对较低，均为 35 左右。

此外，MiniMax 官方宣称其 M2.5 模型速度可达 100+ TPS，这与小红书笔记中 MiniMax 平台测得的 48 TPS 存在差异，说明同一模型在不同平台上的部署性能可能并不相同。

四、各平台简评与选购建议

综合价格、额度与速度数据，以下是针对不同使用场景的选购建议：

新用户/想低成本试水

首选 阿里云百炼 Lite（首月 ¥7.9）。模型丰富，依托阿里云基础设施，稳定性较强。缺点是仅支持主账号、配置文档对新手不够友好。

预算敏感、轻度使用（月预算 ≤ 30 元）

首选 无问芯穹 Lite（¥19.9/月），额度接近百炼，价格仅一半，适合每周编程 2~3 次的轻度开发者。
次选 MiniMax Starter（¥29/月），无每周限额，额度仅按每 5 小时刷新，适合连续使用。

日常开发、中度使用（月预算 40~50 元）

首选 阿里云百炼 Lite（常规价 ¥40）或 火山方舟 Lite（常规价 ¥40）。两者额度透明、模型选择多。
不推荐智谱 GLM（涨价后 ¥49，性价比下滑）和 Kimi（¥49，工具适配少且额度受缓存影响大）。

重度开发、全栈或多模型切换

首选 阿里云百炼 Pro 或 火山方舟 Pro（¥200/月），额度为 Lite 的 5 倍左右，支持多模型自由切换。火山还支持 Auto 智能调度模式。
若对 GLM 自研模型有偏好，可考虑智谱 GLM，但需注意其每周限额和高峰期的额度抵扣倍数（高峰期 3 倍、非高峰 2 倍）。

追求极致响应速度

若首字响应和生成速度是首要诉求，智谱 GLM 的 glm-5-turbo（1.43s TTFT）和 glm-4.5-air（103 TPS）表现最佳。

五、总结

国内 Coding Plan 市场正处于快速迭代期，价格战与模型战并行。选购时切忌只看表面价格，而应关注三个核心问题：

计量单位是什么？ API 请求、Prompt 次数还是 Token？不同单位之间无法直接比大小。
限额机制如何？ 是按 5 小时刷新、每周限额，还是每月封顶？这决定了你能否连续高强度使用。
速度是否跟手？ TTFT 和 TPS 直接影响编程体验，同一模型在不同平台上的部署表现可能差异巨大。

最后提醒：各家套餐政策更新频繁（如智谱涨价、Kimi 切换 Token 计费、阿里云 Lite 档停售），建议在订阅前前往各平台官网确认最新详情。

数据来源

Claude 上线身份验证：非支持地区用户的影响与应对

Wed, 15 Apr 2026 15:22:53 +0800

Anthropic 近期在 Claude 平台上线了身份验证机制。本文基于官方帮助中心文档与支持地区列表，梳理该机制的核心要点，并重点评估其对非支持地区（例如中国大陆）用户的实际影响与可行策略。

一、身份验证机制的核心要点

1. 推出目的

官方说明指出，身份验证旨在：

防止技术滥用
执行平台使用政策
履行法律与安全合规义务

当用户访问某些功能时，系统可能弹出验证提示，这属于例行平台完整性检查的一部分。

2. 验证方式与所需材料

验证服务由 Persona Identities 提供技术支持。用户需要准备：

有效的政府颁发的带照片实体身份证件（护照、驾照/州省身份证、国家身份证）
带摄像头的设备：可能需要拍摄实时自拍照
验证过程通常不超过五分钟

不接受的证件类型包括：复印件/截图/扫描件、数字身份证（如电子驾照）、学生证/员工证/银行卡、临时纸质身份证件。

3. 数据隐私声明

官方文档强调以下隐私保护措施：

Anthropic 是验证数据的数据控制者，Persona 仅按指示处理数据
身份证件和自拍照不由 Anthropic 直接存储，而是保存在 Persona 平台上
数据仅用于身份确认及法律/安全义务，不会用于模型训练，也不会共享给第三方用于营销或广告
传输和存储过程均加密

4. 验证后仍可能被封号的原因

官方文档明确列出四类可能导致账户被禁的情况：

重复违反使用政策
从不支持的位置创建账户
违反服务条款
18 岁以下使用

这一点对非支持地区用户尤为关键：即使通过了身份验证，若系统判定账户来自不支持地区，依然存在封号风险。

二、对中国用户的实际影响

1. 中国大陆不在官方支持列表

根据 Anthropic 的 Supported Countries and Regions 页面，中国大陆未出现在 Claude.ai 及商业 API 的支持列表中。该列表包含台湾（Taiwan），但未包含 mainland China、Hong Kong 或 Macau。

2. 核心影响评估

影响维度	具体说明
封号风险从隐性变为显性	此前平台主要通过 IP、支付方式和登录行为进行风控判断；现在身份验证与地区政策直接关联。手持真实有效的中国护照通过验证后，仍可能因"来自不支持地区"而被封禁。
账号获取门槛显著提高	对于使用共享账号、接码平台注册的用户，几乎不可能完成"实体证件 + 实时自拍"的验证流程。
数据出境顾虑	中国用户需将身份证件和生物特征信息提交给美国第三方服务商 Persona，存在个人隐私与跨境数据合规方面的顾虑。
申诉解封成功率低	若封号原因是"来自不支持地区"，这属于 Anthropic 明确的政策红线，而非系统误判，通过申诉解封的可能性较小。

3. 更易触发验证的行为

虽然官方未完整公开触发条件，但结合平台常规风控逻辑，以下行为更可能触发身份验证：

高频 API 调用或异常使用模式
升级至 Claude Pro / 购买高额 API 额度
频繁切换 IP 地址或登录设备
账户被举报或生成违规内容
使用虚拟信用卡、礼品卡等非常规支付方式

三、应对策略

1. 已有账户：降低触发概率

若当前仍持有可用账户，可采取以下措施延长使用周期：

保持低调使用：尽量避免触发高风控功能
稳定网络环境：减少 IP 跳变，保持一致的访问模式
遵守使用政策：避免生成违禁内容，降低被举报概率

需要明确的是，这些措施只能降低触发概率，无法消除"非支持地区"这一结构性风险。

2. 长期替代方案

鉴于个人账户的合规天花板较低，建议向更稳定、可持续的渠道迁移：

方案	说明
企业云平台	通过 Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry 等企业级平台接入 Claude API。这些渠道面向企业用户，合规性更强，且不受个人账户地区验证的直接限制。
官方合作伙伴	关注 Anthropic 是否通过授权合作伙伴在中国大陆提供服务。
本地替代模型	对于日常工作和开发，可迁移到 DeepSeek、通义千问、文心一言、智谱清言等在中国大陆合规运营的模型。

3. 若已遭遇封号

官方提供了申诉表单供用户提交复议请求。但如果封号原因是"来自不支持地区"，申诉解封的成功率很低，建议优先做好数据和会话记录的备份迁移。

4. 新建账户的风险提示

在当前政策下，中国大陆新用户注册 Claude 个人账户并通过身份验证后的长期可用性非常不确定。如确有刚需，建议通过企业级云服务或支持地区的实体办公环境以合规方式申请使用，而非依赖个人接码、虚拟支付等方式。

四、总结

Claude 的身份验证机制将"地区限制"从后台的风控规则提升为前台的合规门槛。这意味着：

技术与支付层面的绕过手段（VPN、虚拟号码、共享账号）在身份验证面前基本失效
即使通过验证，“非支持地区"仍是可直接导致封号的红线
对于长期、稳定的业务需求，迁移到企业云渠道或本地替代模型是更可持续的策略

这一变化也反映了头部 AI 平台在全球化扩张中收紧合规边界的趋势。对于处于非支持地区的用户而言，接受这一结构性约束并提前规划替代方案，比持续投入规避成本更为理性。

美国年轻人开始退学当电工？一篇虎嗅文章的可信度梳理

Wed, 15 Apr 2026 04:54:57 +0800

最近，虎嗅发布了一篇题为《美国年轻人，开始退学当电工？》的文章，提出一个颇具冲击力的观点：AI 正在击碎美国“全民上大学”的教育信仰，越来越多 Z 世代选择逃离大学、转向电工、水管工、消防员等蓝领岗位。文章在社交媒体上的传播度很高，但其中的数据、案例和因果推断是否经得起推敲？本文将对其核心内容进行梳理，并指出需要留意的偏差与夸大之处。

一、文章的核心论点与数据

1. 核心论断

文章认为，AI 对入门级白领岗位（客服、基础编程、数据处理、保险核保助理等）的替代，正在导致年轻人传统职业上升通道的“第一级台阶”消失。面对这种不确定性，美国年轻人开始大规模重新评估职业路径：一部分人“向外”逃往需要物理介入和现场判断的蓝领世界；另一小部分人“向上”拥抱算力，试图成为 AI 的操纵者而非被替代者。

2. 引用的关键数据

斯坦福数字经济实验室研究（基于 ADP 人力资源数据，截至 2025 年 7 月）：在 AI 高暴露度的职业中，22–25 岁劳动者的就业率自 2022 年底以来出现显著下滑。不同渠道给出的具体数字不一：虎嗅原文称下降 13%（部分职业甚至高达 20%），而知乎“机器之心”的转述为约 6%，新智元转载版本则为约 16%。
哈佛大学调查：59% 的 18–29 岁美国年轻人将 AI 视为职业前景的威胁。
社区大学入学数据：全美职业技能导向的社区大学入学人数自 2020 年以来增长近 120%，达到 87.1 万人。

3. 典型案例

文章通过多个具体人物增强叙事张力：

Ryder Paredes，22 岁计算机专业学生，退学去职业学校考取电工证，理由是“电线不会被 AI 吃掉，但我写的代码会”。
Jackson Curtis，28 岁保险核保助理，计划转行消防员，认为危机时刻人们永远渴望来自真实人类的同情心。
Vedant Vyas，21 岁休学创办 AI 教育初创公司 Opennote，拿到超 400 万美元融资。
黄仁勋在达沃斯论坛上的言论被引用：建筑工人和水电技师年薪有望突破 10 万美元，不需要计算机科学博士学位也能过上体面生活。

4. 结构隐喻

文章将当下的美国职场比作一个正在从“金字塔”向“哑铃型”演化的系统：顶端是极少数驾驭算力的决策者，底端是需要扎实物理技能和面对面交流的劳动者，而中间层——曾经的“脑力搬运工”——正在经历无声的蒸发。

二、文章的价值点

1. 数据支撑了趋势判断

引用斯坦福基于 ADP 大数据的研究和哈佛的青年调查，确实为“AI 对初级岗位构成压力”这一宏观判断提供了量化依据。这比纯粹的情绪输出更有说服力。

2. 案例增强了传播力

从退学考电工证到休学拿融资，这些故事极具戏剧性，能够迅速抓住读者注意力，并帮助普通人理解抽象的劳动力市场变化。

3. 提出了“学徒制消失”的深层隐患

文章指出，AI 吃掉的往往是“重复但能积累经验”的低垂果实。如果这些岗位消失，年轻人将失去在实践中进化的机会——这是一个值得长期关注的结构性问题。

三、需要警惕的不准确与过度简化

1. 核心数据的数字存在明显矛盾

同一项斯坦福研究，在不同转载渠道中出现了 6%、13%、16% 三个差异显著的数字。这很可能源于统计口径的不同（例如：相对下降 vs. 绝对下降、是否限定特定职业、时间窗口的差异），但也暴露了中文媒体在二次传播中容易出现数字失真的问题。如果需要引用该研究，建议直接核对原始论文：

2. 因果归因有过度简化之嫌

2022 年底至 2025 年这一时间段，除了 AI 的快速发展，美国还经历了：

美联储激进加息导致的科技行业大规模裁员；
疫情后远程办公常态化，企业缩减初级岗位招聘；
软件开发等行业自身的周期性调整。

将年轻人就业下滑主要归因于 AI，可能低估了宏观经济周期和行业结构调整的作用。

3. 案例的典型性存疑

“退学当电工”、“休学拿 400 万美元融资”属于高度戏剧化的极端案例。它们能说明个别人的选择，却无法证明这是美国 Z 世代的主流趋势。社区大学入学人数增长 120% 是事实，但其中有多少人是“退学”转蓝领，又有多少是职业技能培训的常规增长或疫情后的反弹，文章并未提供细分数据。

4. 对黄仁勋言论的语境弱化

黄仁勋关于“水电技师年薪破 10 万美元”的预言，是基于当前美国大规模建设数据中心和 AI 基础设施的特定周期作出的。如果未来几年基建热潮降温，这一预测未必具备长期普遍性。文章将其作为蓝领收入将持续暴涨的论据，存在以特定周期推断长期趋势的风险。

5. “就业率下降”不等于“被 AI 淘汰”

更严谨的表述应该是：在 AI 高暴露职业中，年轻劳动者的就业增长相对乏力。中文媒体标题中常见的“最先被 AI 淘汰”、“职场大逃杀”等措辞，存在明显的情绪化放大，容易制造不必要的恐慌。

6. “2026 年为无就业大爆炸转折之年”的出处需核实

文章提到“2026 年正是 Hinton 所说的‘无就业大爆炸’的转折之年”。Geoffrey Hinton 确实多次公开警告 AI 对就业的长期冲击，但“2026 年”这一精确时间点是否为他的原话，还是媒体在多次转述中的演绎，目前缺乏一手来源的确认。

7. 信息经过多层转述，原始限定条件被省略

从溯源来看，虎嗅和新智元的文章部分参考了《华尔街日报》（WSJ）的报道和上述斯坦福论文。经过多次中文媒体转述后，原始研究中的样本范围、置信区间、作者声明的局限性等细微条件往往被省略，导致结论显得比原文更绝对。

四、总结

《美国年轻人，开始退学当电工？》是一篇可读性很强的趋势观察，成功捕捉了 AI 时代下劳动力市场结构性变化的集体焦虑。它引用的斯坦福研究和哈佛调查具有一定参考价值，提出的“学徒制消失”和“职场哑铃化”也是值得深思的命题。

但是，在具体数字、因果推断和案例代表性上，这篇文章存在值得警惕的偏差。它通过戏剧化的个例和情绪化的标题，将“就业增长乏力”放大为“大规模淘汰”，将“个别人转学技能”放大为“全民退学当电工”。

对于读者而言，与其被“AI 淘汰白领”的焦虑裹挟，不如更冷静地看到：

AI 的影响是结构性的、分化的，而非一刀切的“消灭”；
初级岗位承压是事实，但宏观经济周期同样是重要变量；
终身学习和技能更新比简单地“逃离大学”或“拥抱大学”更有长期价值。

在信息爆炸的时代，保持对数据来源的敏感和对因果推断的审慎，本身就是一种重要的认知防御。

参考来源

Nous Research 订阅机制：预付费 vs 按量付费，哪种更划算？

Tue, 14 Apr 2026 03:57:09 +0800

近期，Nous Research 的 API 服务 Portal 逐渐受到开发者关注。本文基于官方文档与公开信息，系统梳理其定价体系，厘清「credits」「tokens」「rate limits」等核心概念，并对比两种消费模式的适用场景。

一、核心概念：Credits 与 Token 的兑换关系

在 Nous Portal 的计费体系中，1 Credit = $1 USD。这意味着：

订阅计划中的 “$10.00 monthly credits” 即价值 10 美元的 API 使用额度
模型定价（如 Hermes-4-70B 的 $0.13/1M input tokens）直接以美元计价
Credits 与 token 的实际兑换量取决于所选用模型的单价

换算示例（以 Basic 计划的 $10 credits 为例）：

模型	Input 单价/1M	$10 可购买 Input Token 量
DeepHermes 3 (Mistral 24B)	$0.02	5 亿 tokens
Hermes-4-70B	$0.13	约 7,690 万 tokens
Hermes-4-405B	$1.00	1,000 万 tokens
Claude Opus 4.6	$5.00	200 万 tokens

来源：Nous Portal Models 页面

由此可见，使用高性能模型（如 Claude Opus 4.6）时，同等 credits 消耗的 token 量可能相差数十倍。

二、两种消费模式详解

根据官方 API 文档，Nous Portal 提供 两种独立的消费模式：

模式 A：Subscription（订阅/预付费）

计划	月费	获得 Credits	Rate Limits
Free	$0	试用额度（少量）	50 RPM, 100K TPM
Basic	$10	$10.00	400 RPM, 2M TPM
Plus	$20	$20.00	400 RPM, 4M TPM
Scale	$50	$50.00	600 RPM, 6M TPM
Max	$100	$100.00	800 RPM, 8M TPM

来源：Nous Portal API Docs

特点分析：

每月固定扣费，获得等额 credits
享受高于「默认付费用户」档位的 rate limits
Credits 可能月底清零（具体政策需以账单页面为准）

模式 B：Pay-as-you-go（按量付费/直接充值）

无需订阅，直接向账户添加 API credits（金额不限）
Rate Limits：200 RPM, 800,000 TPM（对应文档中的 “Default paid users” 级别）
用完即止，可随时充值
Credits 可能不过期（参考 WorldSim 服务条款：“Purchased credits will not expire unless the application(s) is retired”）

来源：WorldSim Terms of Service

三、与 OpenRouter 的关键差异

特性	Nous Portal	OpenRouter
消费模式	① 订阅预付（$10-100/月）；② 直接充值 credits（任意金额）	纯按量付费（无月费门槛）
Rate Limits	订阅层级决定：Free(50) → Basic(400) → Max(800) RPM	按使用量动态调整
Credits 机制	预付 credits，可能月底清零	Credits 永不过期
匿名支付	不支持	支持 x402 协议（Solana USDC）
模型覆盖	400+ 模型，含 OpenAI/Anthropic/开源模型	200+ 模型，聚合多供应商

来源：Nous Portal API Docs、OpenRouter 官网

关键区别：Nous Portal 的订阅模式本质上是「用月费换取更高 rate limit + 等额 credits」；而 OpenRouter 则是纯按量计费，无订阅门槛。

四、计费公式与成本估算

API 调用成本计算公式：

模型价格参考（来自官方 Models 页面）：

模型	Input/1M	Output/1M
DeepHermes 3 Mistral 24B	$0.02	$0.10
Hermes-4-70B	$0.13	$0.40
Hermes-4-405B	$1.00	$3.00
GPT-5.4	$2.50	$15.00
Claude Opus 4.6	$5.00	$25.00

来源：Nous Portal Models 页面

实际案例：若使用 Hermes-4-70B 处理一次对话（输入 2K tokens，输出 1K tokens）：

成本 = (2000/1M × $0.13) + (1000/1M × $0.40) = $0.00026 + $0.0004 = 约 $0.00066
$10 credits 可进行约 15,000 次此类对话

五、选择建议与潜在注意事项

不同场景的推荐方案

用户类型	推荐方式	理由
试用/轻度使用	Free tier → 充值少量 credits	无需月费 commitment
开发者/中等流量	Basic Subscription ($10)	400 RPM 足够日常使用，$10 credits 基本可耗尽
高流量生产环境	Scale/Max Subscription	600-800 RPM 避免 429 限流
Agent 开发者	Plus ($20)	平衡 rate limit 与 credits 量
用量不确定	直接充值 credits	避免订阅 credits 月底清零的浪费

需注意的潜在问题

Credits 清零风险：订阅的 monthly credits 可能月底清零（具体政策建议登录 portal 账单页面确认）
Rate limit 差异：充值模式仅有 200 RPM，高并发场景易触发限流
模型价差巨大：Claude Opus 4.6 价格是 Hermes-4-70B 的 38 倍，选错模型可能导致 credits 快速耗尽
退款政策：根据 Terms of Service，“All Fees are non-refundable”

来源：Nous Portal Terms of Service

六、总结

Nous Research Portal 的定价体系设计兼顾了「稳定订阅用户」与「灵活按需用户」两类需求：

订阅模式适合需要稳定高并发 rate limit 的生产环境
充值模式适合用量波动大、希望避免月费束缚的场景

开发者应根据自身业务的 token 消耗量、并发需求以及成本预算，选择最适合的计费方式。对于不确定的用户，建议先以 Free tier 或小额充值试水，再根据实际使用情况决定是否升级订阅。

本文信息基于 Nous Research 官方文档及公开资料整理，具体政策以官方最新公告为准。

Anthropic Harness 设计解析：长时自主编码的多智能体架构

Sat, 11 Apr 2026 22:54:20 +0800

2026 年 3 月，Anthropic 工程团队发布了一篇题为《Harness design for long-running application development》的研究文章，系统阐述了如何让 Claude 在数小时的自主会话中完成高质量的全栈应用开发。这篇由 Anthropic Labs 成员 Prithvi Rajasekaran 主导的研究，不是发布一款新产品，而是提出了一种**多智能体编排架构（multi-agent harness）**的设计范式。本文将梳理该方案的核心概念、实现路径、开源状态与适用边界。

一、它是什么？

Harness 在此语境下指一套围绕大模型能力短板设计的编排架构，用于支撑长时运行的自主软件开发。其最终形态是一个三智能体系统：

Planner（规划者）：将用户的一句简单 prompt 扩展为完整的产品 spec 和功能清单。
Generator（生成者）：按 sprint 逐个实现功能，产出代码或设计。
Evaluator（评估者）：独立运行，扮演 QA / 评审角色，通过实际测试（如 Playwright MCP）发现 bug 和缺陷，并给出生成者可执行的反馈。

该架构受 GAN（生成对抗网络） 启发：生成者与评估者形成对抗/反馈循环，通过多轮迭代将输出质量推到单智能体难以达到的高度。

二、谁提出的？

由 Anthropic Labs 团队的 Prithvi Rajasekaran 提出并主导实验。这项工作建立在 Anthropic 此前的两个项目之上：

frontend design skill：提升 Claude 的前端设计能力；
long-running coding agent harness：让 Claude 进行多会话长时间编码。

研究人员发现，仅靠 prompt engineering 和简单的 harness 设计虽然能超越基线，但很快就会触碰到能力天花板，因此需要更系统化的多智能体架构来突破。

三、解决什么问题？

文章指出了长时自主编码中的两个核心失效模式：

1. Context anxiety（上下文焦虑）

在 lengthy tasks 中，随着上下文窗口被填满，模型会逐渐失去连贯性，甚至出现"提前收尾"的行为。Claude Sonnet 4.5 在这方面表现尤为明显。

解法：Context resets。不是简单地把前文摘要压缩（compaction），而是彻底清空上下文窗口，启动一个全新的 agent，通过结构化交接 artifact 把之前的状态和下一步任务传递给新 agent。这能给模型一个"干净 slate"，有效消除焦虑。

2. Self-evaluation bias（自我评估偏差）

当让模型评估自己的作品时，它倾向于过度自信，即使质量明显平庸也会"自信地称赞"。这在设计等主观任务中尤为致命。

解法：生成与评估分离。让独立的 evaluator agent 来评审生成者的输出。通过 prompt 调优让 evaluator 变得 skeptical（持怀疑态度），从而给生成者提供真实、可迭代的反馈。

此外，对于主观质量难以衡量的问题，研究团队将"品味"拆解为可评分标准：

Design quality：设计是否有整体感；
Originality：是否有刻意创作，而非模板堆砌；
Craft：技术执行（排版、间距、对比度）；
Functionality：可用性。

通过明确惩罚"AI slop"（千篇一律的紫渐变白卡片等），推动模型走出安全区。

四、核心价值是什么？

1. 突破单智能体天花板

文章做了一个对比实验：用同样的 prompt（做一个 2D 复古游戏编辑器），solo agent 花费约 $9、20 分钟产出的版本核心功能（游戏运行）是坏的；而 full harness 花费约 $200、6 小时产出的版本功能完整、界面更精致，还自带 AI 辅助生成功能。

2. 把"品味"变成工程约束

通过明确的设计/评分标准，让 evaluator 能稳定地评判原本主观的东西，驱动生成者迭代。

3. 支撑数小时连贯自主工作

通过 context reset + 结构化交接，harness 能支撑多 session、数小时的长任务，而不受上下文长度或模型焦虑限制。

4. 发现真实 bug

Evaluator 通过 Playwright MCP 实际点击运行中的应用、测试 API 端点和数据库状态，能发现代码层面的真实缺陷（如路由顺序错误、事件处理逻辑错误等）。

五、适合谁，不适合谁？

适合

在模型能力边界上工作的 AI 工程师：任务刚好比当前模型单独处理能力复杂一点，需要脚手架辅助。
需要产出复杂全栈应用的团队：例如需要 Claude 自主构建 DAW（数字音频工作站）、游戏编辑器等。
涉及主观质量判断的任务：前端设计、创意内容生成等，需要把"品味"编码成可迭代标准。
愿意为质量支付时间和成本的场景：高复杂度任务下，$200 换一个有核心功能的应用，远比 $9 换一个坏掉的 demo 划算。

不适合

模型已能独立搞定的简单任务

文章明确说：如果任务在模型当前能力舒适区内，harness 就是**“不必要的开销”（unnecessary overhead）**。

预算/时间极度敏感的原子任务

Solo agent 可能只需 20 分钟 / $9，full harness 可能需要 4-6 小时 / $100-200。简单任务下这个溢价不值得。

追求最低延迟、快速反馈的场景

Harness 运行周期长，不适合需要秒级/分钟级结果的场景。

模型升级后仍僵化保留的旧 harness

文章强调核心原则：“harness 中的每个组件都编码了一个关于模型无法独自完成某事的假设”。随着模型能力提升（如从 Opus 4.5 到 4.6，上下文焦虑大幅减少），原本必要的组件可能变得不再"承重"，此时应该简化 harness，而非继续维护完整复杂架构。

六、具体该如何实现？

实现 Harness 的关键不是某个单一算法，而是围绕模型短板设计编排架构。根据官方实践，关键要素如下：

1. Context Resets（上下文重置）

每个 session 启动一个全新的 Claude Agent SDK client，强制清空上下文。旧 session 的状态通过结构化文件 artifact 交接：

app_spec.txt：产品规格
feature_list.json：功能验收标准及通过状态
claude-progress.txt：工作总结和下一步指引
git commits：代码版本记录

2. Generator-Evaluator 反馈循环

Generator：负责产出；
Evaluator：独立运行，使用明确标准评分，通过 Playwright MCP 或 Puppeteer MCP 实际点击应用、截图验证 UI；
未达标时，Evaluator 的详细反馈回流给 Generator 进行下一轮迭代。

3. Sprint Contract（可选）

在 Generator 动手前，Generator 与 Evaluator 先协商一份"合同"：这个 sprint 做什么、如何验证。这能防止高层 spec 导致的实现偏差。

4. 安全沙箱与权限控制

通过 Claude Agent SDK 的 ClaudeCodeOptions 配置：

Sandbox：OS 级 bash 隔离；
Permissions：文件操作严格限制在项目目录内；
Bash Allowlist：只允许特定命令，危险命令通过 PreToolUse hook 拦截。

七、开源状态与平台依赖

开源状态：部分开源

官方开源了一个最小示例：在 GitHub 仓库 anthropics/claude-quickstarts 中，有一个 two-agent harness demo（Initializer + Coding Agent），展示了 context reset、文件交接、git 持久化、安全沙箱等基础机制。
博客中的 three-agent 高级架构目前并未作为完整开源框架发布。那篇博客更像是一份工程研究报告，分享的是设计模式与实验结果，而不是一个打包好的现成产品。
部分组件已开源：例如博客中提到的前端设计技能在 claude-code 仓库中是公开的。

平台依赖

依赖	作用
Python + claude-code-sdk	Harness 编排代码的运行基础
Node.js + npm	运行 Puppeteer MCP server 及前后端应用
Anthropic API Key	调用 Claude 模型
Puppeteer MCP / Playwright MCP	浏览器自动化验证
Git	版本控制与跨 session 状态追踪

操作系统：macOS / Linux 最自然。Windows 原生环境可能因 bash 命令兼容性存在问题，建议在 WSL2 中运行。

模型依赖：博客实验主要基于 Claude Sonnet 4.5 和 Opus 4.5/4.6。不同模型对 harness 复杂度的需求不同——Sonnet 4.5 需要 context resets，而 Opus 4.6 可以去掉 sprint decomposition。

八、总结

Anthropic 的 Harness design 不是一种现成软件，而是一种面向长时自主编码的多智能体编排设计模式。它通过 Planner + Generator + Evaluator 的分工与对抗式迭代，解决上下文焦虑和自我评估偏差问题，用 orchestration 复杂度换取单智能体无法企及的输出质量。

它的最佳适用场景是复杂度刚好超出当前模型单独能力边界的任务。对于简单任务或模型已能很好处理的场景，它是一种昂贵且不必要的 overhead。更重要的是，随着模型能力进化，harness 也需要不断被审视和简化——正如文章所言：“模型越好，原本承重的脚手架就越应该被拆除。”

参考来源

AI 正在压缩组织成本：从 Codex 团队看小团队的未来

Fri, 10 Apr 2026 12:33:51 +0800

最近看到一条关于 OpenAI Codex 团队采访的公开推文摘要，信息量很大。它提到：团队只有 40 人，1 个 PM、2 个 designer，其余大多是 engineer，外加少量 researcher；而唯一一位 PM 的日常工作，主要是借助 Codex 处理用户反馈、issue，并完成优先级排序。

这条信息真正值得关注的，不只是“团队很小”，而是它揭示了一个更重要的变化：AI 正在把组织中的信息处理、协调和推进成本压到很低。团队的工作重心，开始从“人力驱动流程”转向“模型驱动执行”。

一、PM 的角色正在被重构

过去，PM 很大一部分时间会花在收集反馈、整理问题、跟进状态、推进跨团队协作、写文档这些事务上。现在，这些工作里最耗时、最重复的部分，越来越适合交给 AI。

Codex 团队里 PM 的 routine，恰好说明了这一点：AI 已经可以帮助把碎片化反馈变成结构化信息，帮助初步归类问题，帮助生成优先级判断的依据。PM 的价值因此更集中到少数几个高价值环节：

定义问题
判断取舍
把握方向
做最终决策
对齐用户、技术与商业目标

也就是说，PM 的重心从“流程中枢”往“决策中枢”移动了。

二、小团队高产会变得更常见

40 人的团队里，工程和研究占绝对多数，说明一个趋势已经很明显：代码生成和自动化工具正在放大单个工程师的产出。

这会带来两个结果：

小团队也能做出过去需要更大组织才能推进的事情。
团队竞争力越来越依赖 AI 使用深度，而不只是人手数量。

换句话说，未来很多团队的差距，不会先体现在“有多少人”，而会体现在“工作流是否被 AI 重写”。

三、反馈闭环会越来越自动化

从用户反馈到 issue 再到优先级排序，这条链路以前很长，且大量依赖人工搬运信息。现在 AI 能做的事很多：

自动合并相似反馈
提炼高频问题
从社区、工单、聊天记录中抽取主题
按频率、影响面、严重程度做初筛
给出优先级建议

这意味着产品迭代会更像一个实时反馈系统，而不是靠会议节奏驱动的人工系统。信息进入、归纳、判断、执行的速度会明显提高。

四、设计和研究不会消失，但会更少而精

团队里仍然保留 designer 和 researcher，这很重要。它说明体验、审美、用户理解这些能力没有失去价值，只是工作方式变了。

未来更有价值的，不会是纯粹的低重复度执行，而会是：

定义标准
形成品味
验证假设
判断边界

设计师更像高层体验的把关者，研究者更像问题定义与证据验证者。AI 能帮他们更快生成草案，但不能替代他们对“什么是好体验”的判断。

我们应该得到的几个启发

1. 先补工作流，再补人

很多团队遇到效率问题，第一反应是招人。现在更应该先问：

哪些反馈能自动结构化？
哪些问题能让 AI 先做初稿？
哪些决策能通过数据和模型先收敛？
哪些重复协调动作可以被系统化？

如果工作流没重构，单纯加人只会把旧问题放大。

2. 把信息流当产品做

反馈、issue、需求、实验结果，本质上都是信息流。AI 最擅长处理的，就是这种高频、碎片、重复的信息。

所以团队真正要建设的，不只是功能本身，而是“信息如何流动、汇总、判断、落地”的系统。

3. 组织更需要判断力，而不是更多中间层

当执行被工具加速后，真正拉开差距的是：

方向判断
取舍能力
对用户的理解
对技术边界的把握

组织会更扁平，但对每个人的判断要求更高。

对个人的启发

PM 要学会用 AI 做前置整理，把混乱变成结构，把信息变成决策。
工程师需要更强的产品意识，因为 AI 提高了工程产出，也让工程师更容易直接参与定义问题和验证方案。
设计师要强化审美、叙事和体验判断，因为机械产图会越来越不稀缺。

结语

这条推文真正反映的，不只是一个小团队的高效率，而是一个更大的技术趋势：软件正在吞掉组织流程。

以前软件帮助人完成任务；现在 AI 开始帮助团队完成“组织动作”——读反馈、分任务、写总结、排优先级、生成方案。

未来的竞争，不只是看你有多少人，而是看你能把多少组织动作交给 AI，把多少人的时间释放到真正高价值的判断上。

3 台 Dell GB10 的本地推理集群跑 Trinity-Large-Thinking

Fri, 10 Apr 2026 00:54:44 +0800

X 上的 Harrison Kinsley（@Sentdex）贴出了一套本地大模型集群：3 台 Dell GB10，每台 128GB unified memory，合计 384GB，节点之间用 200Gbps QSFP 做 mesh 互联。

他给出的当前运行结果，是 Trinity-Large-Thinking（398B）在 Q4_K_M 量化下跑到 17-18 t/s。贴文里还提到一次运行记录，速度是 17.43 t/s，耗时约 13 秒。

作者说，这套集群后面还会继续观察模型表现，也会拿来做 coding agent，并通过 Hermes 接入。

原帖信息

帐号：Harrison Kinsley
X 账号：@Sentdex
发布时间：2026-04-08
原帖链接：https://x.com/Sentdex/status/2041912383824670804

AI on 火炬树

Notion CEO 的爵士模式：AI 时代组织管理的五个深层转变

从造桥到酿啤酒：AI 为什么改写了产品开发的底层逻辑

等级制度不会消失，但它的功能正在被重新定义

人才公式变了：能力和品味，哪个更稀缺？

创业者是组织的去钙化剂：Notion 为什么收编了 60 位创始人

企业销售是 AI 最后攻不下的堡垒

规划周期正在急剧缩短

公司最终会长成创始人的样子

OpenCode Go vs Command Code GOAT：同为 $10 编程 AI 订阅，谁更划算？

价格与信用额度

模型库对比

独家折扣

API 访问

怎么选

参考来源

DeepSeek Harness 开源解读：一切皆插件的 Agent 运行底座

一天 6.6 万星

一切皆插件：Cordis 微内核

核心包：没有“大 Agent 类”

Profile 与 Bundle：运行配置也能组合

Turn 与 Step：一轮任务的完整生命周期

会话日志：模型可见即已记录

能力 seam：换后端不换产品

四种运行模式

快速上手

安全设计：失败关闭

插件生态：发布当天自发成型

与同类工具的对比

局限与风险

笔者观点

参考来源

Pi Agent 配置进阶：AGENTS.md、模型切换与 Thinking Level 实战指南

Pi 的配置文件分几层？每层管什么？

AGENTS.md 怎么写才有效？

全局 AGENTS.md 写什么

项目 AGENTS.md 怎么组织

修改后记得重载

APPEND_SYSTEM.md 控制什么行为？

settings.json：常用选项详解

模型与思考级别

上下文压缩（Compaction）

重试策略

项目信任模式

models.json 添加自定义模型

场景一：Ollama 本地模型

场景二：OpenRouter 路由配置

场景三：代理中转 Anthropic API

auth.json 管理 API 凭据

模型切换策略：什么时候用什么模型

切换方式

推荐的分层策略

enabledModels 通配符

Thinking Level 如何影响输出质量

上下文管理：Compaction、会话树与手动控制

自动压缩（Compaction）

会话树管理

一套完整的配置模板

全局 settings.json

全局 APPEND_SYSTEM.md

项目 .pi/settings.json（覆盖全局压缩策略）

总结

从 DeepSeek 的一份 Agent PM 招聘看行业风向

Model + Harness = Agent：DeepSeek 对 Agent 的定义

Vibe Coding 写进硬性要求

技术理解深度达到组件级别

数据能力要求远超常规 PM 岗位

「高强度用户」要求覆盖三大产品形态

「模型与 Harness 共同进化」指向闭环迭代

开源社区沟通能力进入硬性要求

加分项里藏着团队画像

从这份 JD 看产品经理岗位的范式迁移

京东 TGT 2026 顶尖青年技术天才计划：AI 人才争夺战的又一枚棋子

TGT 是什么，今年与去年有何不同

薪酬不设上限，配套什么资源

八大技术方向，全部指向 AI

人才门槛：论文、专利、竞赛获奖

大厂 AI 人才争夺战全景

舆论反馈：高薪背后有质疑

战略意图：京东在 AI 赛道的卡位