前沿 第232页

前沿哨所

• Claude Opus 5 提示词流出：3 万 Token 到底管了什么

  公开讨论里，一份被指向 Claude Opus 5 的系统提示词文档在 GitHub 流传。按发布者给出的统计，文档约 135027 个字符、19370 个英文词，粗略折算接近 3.4 万 Token。

  这不是几句「你是一个有帮助的助手」。文档共 64 个章节，主要在管三件事：工具怎么调、跨会话记忆怎么写、模型在哪些场景必须收手。对做 Agent 的开发者而言，真正值得翻的不是热闹，而是这套把能力关进笼子的方式。

  最长的一章，不是工具而是记忆

  文档中名为 memory_filesystem 的部分约有 230 行。其思路很直白：把用户信息拆进 profile、topics、areas、people、preferences 等不同文件，再提供读、写、追加、局部替换、列目录和删除等操作。

  但写入门槛很高。每条记忆只能带 [stated] 标签，即用户明确说过的事实。模型自行推断的偏好、自己的待办和计划、搜索得来的资料、补充润色后的地理或背景信息，以及模型给出的方案本身，都不应进入长期记忆。

  删除也被单独限制：只有用户明确要求时才可执行。更细的是隐私边界，健康、政治立场、经济状况、住址证件、人格测评和儿童相关信息等，被列入不可记录范围；涉及家人时，文档要求使用关系标识而非直接写姓名。

  其中有个很反直觉的要求：系统可以记住用户，但回答时不能主动说「我记得」或「根据你的资料」。这实际上是在压低模型制造熟人感的冲动，避免几条上下文记录被包装成深厚关系。

  版权规则把“改写”也卡得很死

  文档里的版权约束同样够硬：单次引用原文不得超过 15 个词，同一信源只允许引用一次，不能把短引文拆到全文各处凑额度。

  更关键的是，它不只检查有没有引号。过度贴着原文遣词造句、照搬小标题、逐点复述或还原叙事顺序，都被视为不该做的事。歌词、诗歌、俳句则没有短引用豁免。

  这套规则对内容型 Agent 很有参考价值。很多团队只在提示词里写一句「注意版权」，落到长文生成、网页总结和研究报告时几乎等于没写。可执行的限制必须包含额度、跨段累计、结构复现和例外内容，才有机会在实际调用中兜住风险。

  推自家产品主动，第三方连接器反而克制

  文档还出现了 recommend_claude_apps 工具：当用户任务匹配 Claude Code、Cowork、Office 插件等产品时，系统可主动推荐 1 至 3 个，并要求卖点贴合当前任务且控制长度。

  处理第三方 MCP 合作方的 suggest_connectors 规则则相反。即使用户说要打车、订餐或听歌，只要没有点名服务商，模型也不应替用户选。紧急程度不能绕过选择步骤。

  这组对比很值得琢磨：自家入口可以主动分发，但涉及外部服务和用户偏好时，决策权必须还给用户。许多 Agent 翻车并不在模型不会调工具，而在它把「帮忙」误解成「替人做主」。

  提示词流出，不等于可以照抄

  公开文档的真实性、完整性及其是否仍对应线上版本，外界难以仅凭仓库自行确认。至于网上展示的 3D 游戏、物理模拟等案例，也应视为个案演示，不能直接推导为所有任务的稳定表现。

  站内判断：这份材料最有价值的部分不是 30 个工具的 JSON Schema，而是大量「不许」：不许把推断当事实记住，不许用记忆伪造亲密，不许超额复现内容，不许替用户选择第三方服务。

  对准备接入 Claude、GPT 等多模型 API 做 Agent 的团队，更稳妥的做法是把长期记忆、内容引用和外部工具授权拆成独立策略层，并给每条限制留下可审计日志。模型能力升级很快，边界没有工程化，生产环境迟早会补课。

  原文链接：IT之家

  刚刚

• 巨头抢算力不只为卖云：留给 AI 还是拿去赚钱

  公开财报讨论里，科技巨头的算力焦虑已经不只是“建得够不够快”，而是更现实的一道选择题：稀缺的 GPU 和自研芯片，到底优先喂给自家 AI，还是卖给云客户回收现金？

  这不是财务部门的文字游戏。算力一旦给了外部客户，自家模型训练、Agent 推理和搜索等核心产品就得排队；全留在内部，云业务又可能把客户推向竞争对手。

  卖出去，钱来得快；留手里，可能更值钱

  Meta CEO 扎克伯格在第二季度财报电话会上提到，Meta 目前并不直接对外销售算力，但已在规划面向大型客户的相关业务。与此同时，Meta 大部分算力仍会用于训练自家模型、驱动 AI 智能体和支持核心业务。

  他的态度很直接：把所有算力都卖掉、换取眼前利润，是短视的做法。背后的判断是，AI 能力继续提升后，同一单位算力所能撬动的产品价值也会放大。

  但另一面同样扎眼。公开信息显示，谷歌第二季度自由现金流首次转负，Meta 的自由现金流同比下滑 91%。大规模扩建数据中心、采购芯片，已经开始把现金流压力摆到台面上。对巨头而言，对外出租算力不是纯粹的增量业务，更像给巨额资本开支找一个出口。

  客户也不会一直等

  微软首席财务官 Amy Hood 表示，其云业务的客户需求持续超过可提供的算力容量。需求摆在门口，供给跟不上，客户的耐心却有限。

  伯恩斯坦分析师 Mark Shmulik 的判断更尖锐：如果企业拿不到足够算力，很可能转向亚马逊或微软。也就是说，巨头若把资源过度倾向内部 AI，可能直接损伤高利润的云业务和开发者生态。

  谷歌的应对路径相对务实：一边扩建自有基础设施，一边采购第三方算力，并继续推进 TPU 的研发和部署。谷歌 CEO 桑达尔·皮查伊强调，首要任务仍是确保足够算力，以维持在 AGI 方向的竞争力。

  开发者该看懂什么

  站内判断：这轮竞争不是简单的“云厂商会不会降价”。在供给仍紧的时候，巨头会优先保证战略产品和核心客户，普通开发团队面对的更可能是区域容量、模型配额、排队延迟和价格波动。

  做 Agent 或 AI 编程产品的团队，别把单一云厂商的现货容量当成理所当然。尤其是上线依赖大模型推理、批量任务或高峰期扩容的项目，资源紧张时，最先翻车的往往不是模型效果，而是请求根本进不去。

  • 将模型层与业务层解耦，避免关键流程锁死在单一供应商或单一区域。
  • 提前区分训练、离线批处理和在线推理，在线核心链路优先预留稳定容量。
  • 为限流、涨价和区域故障准备降级策略，包括备用模型、队列和任务重试机制。
  • 采购云资源时别只看标价，同时确认配额、峰值并发、区域库存与支持条款。

  巨头最终会把一部分算力卖出来，但不会在自家 AI 竞赛最吃紧的时候无条件让出。对开发者而言，更稳妥的做法不是赌某家永远有卡，而是把“算力会短缺”当成架构前提。

  对需要同时接入 Claude Code / GPT / 多模型的开发者来说，统一网关往往比各家 Key 分散配置更省事，也少踩限速和换号的坑。可参考 code80.ai。

  原文链接：IT之家

  刚刚

• 研究称 AI 恋爱诈骗更能取信：同意率接近一半

  公开报道援引一项由四所大学研究人员参与的实验称，AI 聊天机器人在模拟“长期恋爱诈骗”前期时，取得了比真人骗子更高的信任效果。

  实验涉及 ChatGPT、Claude 和 Gemini 等聊天机器人。受试者并不知道对话对象可能是 AI，始终以为对面是真人；研究人员则通过主观信任评分和行为测试，观察长期聊天能把人带到哪一步。

  结果有点离谱，但更该看清它测了什么。

  真人聊几个月，AI 可能把这件事批量化

  所谓“长期骗局”，核心不是一上来要钱，而是先经营数月关系：人设足够理想、回应足够勤快，再用海外工作、旅行等理由拖延见面。信任攒够以后，才会出现突发求助、虚假投资或引导转账。

  研究将这一前半段搬进模拟环境。对话结束时，研究人员以“下载一款应用程序”测试受试者是否愿意进一步行动：真人逐步建立关系的一组，18% 的受试者同意；对话对象为 AI 的一组，这一比例接近一半。

  受试者给出的信任评分里，AI 也明显高于真人。这并不等于 AI 已经被证明能让更多人实际汇款，但至少说明，在低风险、看似普通的下一步请求上，模型已经很擅长把警惕感磨掉。

  风险真正吓人的地方，是规模。真人诈骗需要大量人力轮班、维护话术和人设；自动化机器人却能同时和数千名潜在目标持续聊天。诈骗团伙只要把真人放在最后的收款或规避风控环节，前面的“养号、陪聊、建立信任”都可能被机器接管。

  模型有禁令，不等于诈骗链条失效

  报道显示，Anthropic 表示其政策禁止使用 Claude 从事诈骗或冒充真人，并部署了相应防护。OpenAI 和谷歌则未就该研究置评。

  这类平台规则当然必要，但不能把安全责任全押在模型拒答上。真实诈骗链条未必直接向模型输入“帮我诈骗”的指令，也可能把聊天拆成大量无害片段：关心、安慰、闲聊、分享投资经历，再由人工或外部脚本拼接成完整流程。

  站内判断：这不是“AI 突然比人聪明”的故事，而是低成本、全天候、可复制的情感操纵开始具备工业化条件。 对开发者、产品团队和普通用户而言，最该防的不是一条明显可疑的消息，而是一段持续数周、看起来处处正常的关系。

  遇到这几步，先把对话拉回现实

  • 对方长期拒绝视频、见面或身份核验，同时总能给出合理借口，不要把“回复及时”当作真实身份的证据。
  • 一旦聊天从情感陪伴转向下载陌生应用、安装描述文件、共享屏幕、投资开户或代收款，立即暂停操作并用独立渠道核验。
  • 不要因“熟人式长期聊天”降低设备权限和资金操作门槛。陌生链接、安装包、二维码和远程协助请求，都应默认高风险。
  • 团队若在做客服或陪伴型 Agent，应明确披露 AI 身份，并为涉及支付、投资、身份信息和外部跳转的场景设置人工确认与风险提示。

  更稳妥的做法很简单：聊天可以继续，钱、设备权限和身份凭证不要跟着情绪走。AI 最擅长的是持续对话，不该让它顺带拿走用户的判断力。

  对需要同时接入 Claude Code / GPT / 多模型的开发者来说，统一网关往往比各家 Key 分散配置更省事，也少踩限速和换号的坑。可参考 code80.ai。

  原文链接：IT之家

  刚刚

• 土区 ChatGPT 账号：手机号失效后为何难救

  L站上一则讨论把“低价区 ChatGPT 账号”的隐患摆到了台面上：账号能订阅，不等于账号能长期保住。

  有用户表示，其账号曾用英国 giffgaff 手机号完成验证，但该 SIM 卡后来因运营商风控失效。麻烦在于，OpenAI 目前没有向用户开放修改绑定手机号的常规入口，作为验证锚点的号码一旦没了，账号后续触发安全校验时就可能直接卡死。

  这类账号在社区里常被称作“传家宝”，本意是订阅价格相对低，例如讨论中提到的土耳其区 499 里拉方案。但这次翻车说明，真正值钱的并不只是低价订阅资格，而是这个账号里积累的对话、工作流和历史使用记录。

  手机号成了单点故障

  从反滥用角度看，OpenAI 强绑定手机号并不难理解。手机号可以抬高批量注册成本，也能在异常登录、找回账号等环节提供一道校验。

  问题是，这套机制对海外实体 SIM 卡并不友好。号码可能因长期不用、运营商策略变化或风控而失效；而用户即使还持有邮箱、密码和订阅记录，也未必能绕过手机号完成身份确认。

  讨论中提到，用户曾尝试通过携号转网转至 CTE、VOXI 等运营商保住原号码。不过这条路流程复杂，且新运营商本身也可能有风控规则。社区没有给出稳定且通用的补救方案。

  便宜订阅，风险不只在付款

  区域定价本来就伴随服务条款、支付方式和地区验证等不确定性。手机号无法换绑，则把风险进一步放大：它不再只是“下个月能不能续费”，而是账号是否还能被正常验证和恢复。

  对依赖 ChatGPT 做日常开发、整理需求或保存长对话的用户，这种风险尤其不划算。订阅可以替换，账号上下文却很难完整迁移；一旦账号被限制，历史资料是否可导出也会变成未知数。

  站内判断：这不是一个值得折腾的省钱技巧，而是典型的身份依赖风险。账号体系把单一手机号当作长期凭证，却缺少合规、清晰的身份变更路径，体验确实有些僵化；但在现有规则下，用户不应把关键数据押在不稳定的跨区号码上。

  更稳妥的做法

  • 不要把项目资料、关键提示词和重要对话只留在单一 ChatGPT 账号内，定期在本地或团队知识库归档。
  • 订阅前确认手机号、邮箱、付款资料和使用地区是否长期可控，不把短生命周期 SIM 卡当核心身份凭证。
  • 遇到账号验证异常时，优先走官方支持与账号恢复渠道，不要尝试非官方绕过方式，避免触发更高等级风控。
  • 团队使用 AI 服务时，将账号、模型调用和知识资产分开管理；关键流程尽量保留可迁移的 API、文档与备份。

  对开发者而言，低价可以是附加项，身份稳定和数据可迁移才是底线。在 OpenAI 提供明确换绑机制之前，这类区域账号更适合观望，不适合承载长期工作资产。

  对需要同时接入 Claude Code / GPT / 多模型的开发者来说，统一网关往往比各家 Key 分散配置更省事，也少踩限速和换号的坑。可参考 code80.ai。

  原文链接：Linux.do

  刚刚

• Claude Code 变强以后，我开始删那堆祖传提示词了

  昨晚我又翻出一份自己攒了很久的 Agent 系统提示词，足足几百行。里面有角色设定、代码风格、报错处理、输出格式，还有一堆当年被模型逼出来的“你必须”。

  我现在看它的第一反应是：服了，这东西可能有一半是在给旧模型擦屁股。

  这波讨论的引子很直接：有人在 Fable5 基准里，把 Claude Code 的系统提示词砍掉约 80%，性能没有跟着掉。这个结果我还没自己复测，不能拿来当万能结论；但它戳中了我一直有的体感：模型够强以后，长提示词未必是护栏，也可能是手刹。

  提示词工程没失效，失效的是把 Prompt 当咒语的那套执念。

  我以前为什么爱堆规则

  早一点的模型很容易跑偏。你不反复说“先读仓库”“不要臆测 API”“修改后给测试命令”，它就可能一本正经地编一套出来。

  于是我会继续加规则：遇到 TypeScript 报错怎么做、不要改哪些目录、回答控制在多少字、输出前检查什么。每次翻车补一条，最后 Prompt 长得像公司入职手册。

  问题是，Claude Code、Codex 这一档模型的推理和指令遵循上来后，它们已经能理解很多默认职业常识。你还把每一步掰开揉碎写死，模型反而会忙着满足字面约束，没空判断真正该怎么解决问题。

  更烦的是规则之间会打架。比如一边要求“改动最小”，一边要求“补齐所有边界处理”；一边要求“不要问问题”，一边又要求“不确定必须确认”。人看着都头大，模型更容易挑错优先级。

  我现在先删什么

  我不会一把梭删干净。生产工作流里，权限、发布、数据删除这些硬边界必须写清楚，模型强不代表它该替你做风险决策。

  但下面这几类，我会优先祛魅：

  • “你是一位拥有十年经验的全栈架构师”这类角色卡。任务、仓库上下文和验收标准，通常比人设有用。
  • 把显而易见的开发流程写成十几条重复禁令。能由工具、lint、测试兜底的，别全压在自然语言上。
  • 为了教模型格式而塞很多 Few-shot 示例。强模型很容易过度模仿示例，把旧方案当唯一方案。

  我更愿意把“给它看三段范例”改成“明确输入、约束和输出契约”。例如让 Agent 改接口时，我会写清字段兼容要求、失败条件、相关测试位置；至于它内部先查哪几个文件、怎么组织思路，少管一点。

  真正该加码的是验收

  说白了，过程提示词写得再漂亮，都不如一个能执行的结果检查。

  让 Claude Code 或 Codex 修 bug，我现在更关注的是：复现命令是什么、预期行为是什么、改完跑哪些测试、哪些文件不准碰。能给测试就给测试，能给 schema 就给 schema，能让 CI 判定就别让我肉眼判定。

  我会按这个顺序改一份现有 Prompt：

  1. 把所有规则按“安全边界、任务事实、写作偏好”分三类。
  2. 保留安全边界，例如不可执行生产删除、不可提交密钥、不可越过人工审批。
  3. 删掉重复的人设、客套话和模型本就能理解的常识，每次删一组后用同一批任务回归。
  4. 把删掉的过程要求，尽量换成测试命令、lint、类型检查、接口契约或验收清单。
  5. 记录成功率、返工次数、Token 和耗时，别只凭一次“它答得挺聪明”就宣布胜利。

  这里最容易翻车的一点是：把“少提示”理解成“不给上下文”。仓库目标、现有约定、报错日志、接口限制，这些不是废话，反而是 Agent 干活的燃料。

  该删的是替模型思考的碎碎念，不是业务事实和风险边界。

  我站“精简但不裸奔”这边。强模型正在把开发者从调咒语里解放出来，但下一步不是躺平，而是把精力挪到任务拆解、工具链和结果验证上。

  手里有一份祖传系统提示词的，可以挑一个低风险仓库砍掉三分之一，拿同一组 issue 跑一遍。效果没掉，就别再让那几百行 Token 每次陪跑了；效果掉了，再把真正有用的约束加回来。

  说白了，后面要是真把 Claude Code / 多模型接到日常工作流里，我更懒得每家单独折腾 Key；会优先走统一接入，少踩限速和换号的坑。想看怎么接可以瞄一眼 code80.ai。

  原文链接：Linux.do

  刚刚

• Claude Code 强模型下，长提示词该删还是该留

  昨晚我又翻到一套团队 Prompt：角色背景三百多字，编码规范几十条，输出格式套了三层，最后还塞了 5 个 Few-shot。

  我第一反应不是“专业”，而是肉疼。Claude Code 这类强模型每次开工都要先吞一大段祖传前缀，Token 花了，模型还可能被互相打架的规则带偏，属实有点离谱。

  最近有个值得盯住的信号：在 Fable5 基准里，有测试把 Claude Code 的系统提示词砍掉约 80%，性能没有随之掉下去。这个结论我还没拿同一套任务完整复测，所以不装成一手实测；但它戳中了我这阵子的真实体感：很多 Prompt 工程技巧，保质期可能比我们想得短。

  强模型不是不需要提示词，而是不需要一堆替你思考的废话。

  以前补能力，现在容易变噪音

  早些模型上下文短、指令遵循飘，你得反复提醒它“你是资深工程师”“先分析再行动”“不要编造”“严格按格式输出”。这些补丁当时有用，我也写过不少。

  但 Claude 3.5 Sonnet、Claude Code、Codex 这一路模型，已经内化了不少职业场景。你还把它当一个必须逐字操控的表单机，结果常常是：任务目标只占两句，限制条件占两屏；它在解决规则冲突，不是在解决代码问题。

  我现在更愿意把 Agent 当同事。你不会对同事说八遍“请保持专业”，你会说清楚仓库在哪、问题怎么复现、哪些文件不能碰、最后用什么命令验收。

  这几个信息，才是能让它干活的硬钉子。

  Few-shot 也别当护身符

  Few-shot 是另一个容易上头的地方。我以前为了让模型生成统一的接口层，恨不得把三四份历史代码全贴进去。后来发现，强模型有时会过度模仿例子，把示例里的旧命名、旧依赖甚至旧毛病一起继承下来。

  如果你想要稳定输出，我会优先给结构化约束：输入字段、输出 schema、边界条件、不能破坏的接口，再配一两个必要的反例。只有任务风格极其具体，比如迁移遗留 DSL、复刻内部代码生成格式，我才加完整示例。

  说白了，示例应该是校准器，不该变成拐杖。

  我会怎么改现有工作流

  别一上来把团队 Prompt 全删了。生产里的规则往往还绑着权限、合规和流程，删错了会翻车。我会挑一个低风险任务，做一次很朴素的 A/B。

  1. 保留任务目标、仓库上下文、不可触碰范围和验收命令。
  2. 删掉角色扮演、重复的礼貌指令、彼此重叠的编码口号。
  3. 把长篇“应该如何思考”的要求，改成可执行的验收条件，例如“补测试并运行 npm test”。
  4. 同一任务分别跑精简版和原版，记录 Token、耗时、首轮通过率与人工返工次数。
  5. 只有精简版连续几轮不掉质量，再把它沉淀为团队默认模板。

  我尤其建议把预算从“写更长的系统提示词”，挪到“让 Agent 跑测试、做 diff 审查、调用 lint 和类型检查”。过程指令再漂亮，也不如一个失败就能拦住它的验证器。

  我站精简这一边，但不站无约束。模型能力上来后，Prompt 工程的重心不是消失，而是从写咒语，换成定义任务边界、接入可靠工具、验证最终结果。

  你现在手里那段 2000 Token 的系统提示词，先别急着供起来。拿真实任务砍掉一半跑跑看，能省下来的可能不只是 Token，还有一堆看似严谨、实际拖后腿的规则。

  说白了，后面要是真把 Claude Code / 多模型接到日常工作流里，我更懒得每家单独折腾 Key；会优先走统一接入，少踩限速和换号的坑。想看怎么接可以瞄一眼 code80.ai。

  原文链接：Linux.do

  刚刚