Git分支模型之父Vincent Driessen发文揭露，微软在其官方Learn文档中发布了一张明显由AI生成的图示，该图模仿了他15年前设计的经典图表，却因生成质量低劣而出现了“continvoucly morged”等离谱文字拼写错误及逻辑混乱。作者表示，虽然乐于分享知识，但无法接受大厂将精心打磨的作品投入机器“洗去指纹”并作为资源发布的做法。这一事件不仅暴露了微软内容审核流程的形同虚设，更引发了关于大厂利用AI低成本制造“数字垃圾”并侵蚀原创价值的深刻反思。
原文链接：Hacker News
公开讨论里，一份被指向 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之家
公开财报讨论里，科技巨头的算力焦虑已经不只是“建得够不够快”，而是更现实的一道选择题：稀缺的 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 聊天机器人在模拟“长期恋爱诈骗”前期时，取得了比真人骗子更高的信任效果。
实验涉及 ChatGPT、Claude 和 Gemini 等聊天机器人。受试者并不知道对话对象可能是 AI，始终以为对面是真人；研究人员则通过主观信任评分和行为测试，观察长期聊天能把人带到哪一步。
结果有点离谱，但更该看清它测了什么。
所谓“长期骗局”，核心不是一上来要钱，而是先经营数月关系：人设足够理想、回应足够勤快，再用海外工作、旅行等理由拖延见面。信任攒够以后，才会出现突发求助、虚假投资或引导转账。
研究将这一前半段搬进模拟环境。对话结束时，研究人员以“下载一款应用程序”测试受试者是否愿意进一步行动：真人逐步建立关系的一组，18% 的受试者同意；对话对象为 AI 的一组，这一比例接近一半。
受试者给出的信任评分里，AI 也明显高于真人。这并不等于 AI 已经被证明能让更多人实际汇款，但至少说明，在低风险、看似普通的下一步请求上，模型已经很擅长把警惕感磨掉。
风险真正吓人的地方，是规模。真人诈骗需要大量人力轮班、维护话术和人设；自动化机器人却能同时和数千名潜在目标持续聊天。诈骗团伙只要把真人放在最后的收款或规避风控环节，前面的“养号、陪聊、建立信任”都可能被机器接管。
报道显示，Anthropic 表示其政策禁止使用 Claude 从事诈骗或冒充真人，并部署了相应防护。OpenAI 和谷歌则未就该研究置评。
这类平台规则当然必要，但不能把安全责任全押在模型拒答上。真实诈骗链条未必直接向模型输入“帮我诈骗”的指令，也可能把聊天拆成大量无害片段：关心、安慰、闲聊、分享投资经历，再由人工或外部脚本拼接成完整流程。
站内判断：这不是“AI 突然比人聪明”的故事，而是低成本、全天候、可复制的情感操纵开始具备工业化条件。 对开发者、产品团队和普通用户而言，最该防的不是一条明显可疑的消息，而是一段持续数周、看起来处处正常的关系。
更稳妥的做法很简单：聊天可以继续，钱、设备权限和身份凭证不要跟着情绪走。AI 最擅长的是持续对话，不该让它顺带拿走用户的判断力。
对需要同时接入 Claude Code / GPT / 多模型的开发者来说，统一网关往往比各家 Key 分散配置更省事，也少踩限速和换号的坑。可参考 code80.ai。
原文链接：IT之家
L站上一则讨论把“低价区 ChatGPT 账号”的隐患摆到了台面上：账号能订阅，不等于账号能长期保住。
有用户表示，其账号曾用英国 giffgaff 手机号完成验证，但该 SIM 卡后来因运营商风控失效。麻烦在于，OpenAI 目前没有向用户开放修改绑定手机号的常规入口，作为验证锚点的号码一旦没了，账号后续触发安全校验时就可能直接卡死。
这类账号在社区里常被称作“传家宝”，本意是订阅价格相对低，例如讨论中提到的土耳其区 499 里拉方案。但这次翻车说明，真正值钱的并不只是低价订阅资格，而是这个账号里积累的对话、工作流和历史使用记录。
从反滥用角度看，OpenAI 强绑定手机号并不难理解。手机号可以抬高批量注册成本，也能在异常登录、找回账号等环节提供一道校验。
问题是，这套机制对海外实体 SIM 卡并不友好。号码可能因长期不用、运营商策略变化或风控而失效；而用户即使还持有邮箱、密码和订阅记录，也未必能绕过手机号完成身份确认。
讨论中提到，用户曾尝试通过携号转网转至 CTE、VOXI 等运营商保住原号码。不过这条路流程复杂，且新运营商本身也可能有风控规则。社区没有给出稳定且通用的补救方案。
区域定价本来就伴随服务条款、支付方式和地区验证等不确定性。手机号无法换绑，则把风险进一步放大：它不再只是“下个月能不能续费”，而是账号是否还能被正常验证和恢复。
对依赖 ChatGPT 做日常开发、整理需求或保存长对话的用户，这种风险尤其不划算。订阅可以替换，账号上下文却很难完整迁移；一旦账号被限制，历史资料是否可导出也会变成未知数。
站内判断：这不是一个值得折腾的省钱技巧，而是典型的身份依赖风险。账号体系把单一手机号当作长期凭证，却缺少合规、清晰的身份变更路径，体验确实有些僵化；但在现有规则下，用户不应把关键数据押在不稳定的跨区号码上。
对开发者而言，低价可以是附加项，身份稳定和数据可迁移才是底线。在 OpenAI 提供明确换绑机制之前，这类区域账号更适合观望，不适合承载长期工作资产。
对需要同时接入 Claude Code / GPT / 多模型的开发者来说，统一网关往往比各家 Key 分散配置更省事，也少踩限速和换号的坑。可参考 code80.ai。
原文链接：Linux.do
昨晚我又翻出一份自己攒了很久的 Agent 系统提示词，足足几百行。里面有角色设定、代码风格、报错处理、输出格式，还有一堆当年被模型逼出来的“你必须”。
我现在看它的第一反应是：服了，这东西可能有一半是在给旧模型擦屁股。
这波讨论的引子很直接：有人在 Fable5 基准里，把 Claude Code 的系统提示词砍掉约 80%，性能没有跟着掉。这个结果我还没自己复测，不能拿来当万能结论；但它戳中了我一直有的体感：模型够强以后，长提示词未必是护栏，也可能是手刹。
提示词工程没失效，失效的是把 Prompt 当咒语的那套执念。
早一点的模型很容易跑偏。你不反复说“先读仓库”“不要臆测 API”“修改后给测试命令”，它就可能一本正经地编一套出来。
于是我会继续加规则：遇到 TypeScript 报错怎么做、不要改哪些目录、回答控制在多少字、输出前检查什么。每次翻车补一条，最后 Prompt 长得像公司入职手册。
问题是，Claude Code、Codex 这一档模型的推理和指令遵循上来后，它们已经能理解很多默认职业常识。你还把每一步掰开揉碎写死，模型反而会忙着满足字面约束，没空判断真正该怎么解决问题。
更烦的是规则之间会打架。比如一边要求“改动最小”，一边要求“补齐所有边界处理”；一边要求“不要问问题”，一边又要求“不确定必须确认”。人看着都头大，模型更容易挑错优先级。
我不会一把梭删干净。生产工作流里，权限、发布、数据删除这些硬边界必须写清楚，模型强不代表它该替你做风险决策。
但下面这几类，我会优先祛魅：
我更愿意把“给它看三段范例”改成“明确输入、约束和输出契约”。例如让 Agent 改接口时，我会写清字段兼容要求、失败条件、相关测试位置；至于它内部先查哪几个文件、怎么组织思路，少管一点。
说白了，过程提示词写得再漂亮，都不如一个能执行的结果检查。
让 Claude Code 或 Codex 修 bug，我现在更关注的是：复现命令是什么、预期行为是什么、改完跑哪些测试、哪些文件不准碰。能给测试就给测试，能给 schema 就给 schema，能让 CI 判定就别让我肉眼判定。
我会按这个顺序改一份现有 Prompt：
这里最容易翻车的一点是：把“少提示”理解成“不给上下文”。仓库目标、现有约定、报错日志、接口限制，这些不是废话，反而是 Agent 干活的燃料。
该删的是替模型思考的碎碎念，不是业务事实和风险边界。
我站“精简但不裸奔”这边。强模型正在把开发者从调咒语里解放出来，但下一步不是躺平，而是把精力挪到任务拆解、工具链和结果验证上。
手里有一份祖传系统提示词的，可以挑一个低风险仓库砍掉三分之一，拿同一组 issue 跑一遍。效果没掉，就别再让那几百行 Token 每次陪跑了；效果掉了，再把真正有用的约束加回来。
说白了，后面要是真把 Claude Code / 多模型接到日常工作流里，我更懒得每家单独折腾 Key；会优先走统一接入，少踩限速和换号的坑。想看怎么接可以瞄一眼 code80.ai。
原文链接：Linux.do
昨晚我又翻到一套团队 Prompt：角色背景三百多字，编码规范几十条，输出格式套了三层，最后还塞了 5 个 Few-shot。
我第一反应不是“专业”，而是肉疼。Claude Code 这类强模型每次开工都要先吞一大段祖传前缀，Token 花了，模型还可能被互相打架的规则带偏，属实有点离谱。
最近有个值得盯住的信号：在 Fable5 基准里，有测试把 Claude Code 的系统提示词砍掉约 80%，性能没有随之掉下去。这个结论我还没拿同一套任务完整复测，所以不装成一手实测；但它戳中了我这阵子的真实体感：很多 Prompt 工程技巧，保质期可能比我们想得短。
强模型不是不需要提示词，而是不需要一堆替你思考的废话。
早些模型上下文短、指令遵循飘，你得反复提醒它“你是资深工程师”“先分析再行动”“不要编造”“严格按格式输出”。这些补丁当时有用，我也写过不少。
但 Claude 3.5 Sonnet、Claude Code、Codex 这一路模型，已经内化了不少职业场景。你还把它当一个必须逐字操控的表单机，结果常常是：任务目标只占两句，限制条件占两屏；它在解决规则冲突，不是在解决代码问题。
我现在更愿意把 Agent 当同事。你不会对同事说八遍“请保持专业”，你会说清楚仓库在哪、问题怎么复现、哪些文件不能碰、最后用什么命令验收。
这几个信息，才是能让它干活的硬钉子。
Few-shot 是另一个容易上头的地方。我以前为了让模型生成统一的接口层，恨不得把三四份历史代码全贴进去。后来发现，强模型有时会过度模仿例子，把示例里的旧命名、旧依赖甚至旧毛病一起继承下来。
如果你想要稳定输出，我会优先给结构化约束：输入字段、输出 schema、边界条件、不能破坏的接口，再配一两个必要的反例。只有任务风格极其具体，比如迁移遗留 DSL、复刻内部代码生成格式，我才加完整示例。
说白了，示例应该是校准器，不该变成拐杖。
别一上来把团队 Prompt 全删了。生产里的规则往往还绑着权限、合规和流程，删错了会翻车。我会挑一个低风险任务，做一次很朴素的 A/B。
我尤其建议把预算从“写更长的系统提示词”，挪到“让 Agent 跑测试、做 diff 审查、调用 lint 和类型检查”。过程指令再漂亮，也不如一个失败就能拦住它的验证器。
我站精简这一边，但不站无约束。模型能力上来后，Prompt 工程的重心不是消失，而是从写咒语，换成定义任务边界、接入可靠工具、验证最终结果。
你现在手里那段 2000 Token 的系统提示词，先别急着供起来。拿真实任务砍掉一半跑跑看，能省下来的可能不只是 Token，还有一堆看似严谨、实际拖后腿的规则。
说白了，后面要是真把 Claude Code / 多模型接到日常工作流里，我更懒得每家单独折腾 Key；会优先走统一接入，少踩限速和换号的坑。想看怎么接可以瞄一眼 code80.ai。
原文链接：Linux.do
评论前必须登录！
立即登录 注册