全部分类
热门标签
文章
深度文章，助力AI学习成长
字节跳动技术副总裁洪定坤：AI Coding 的实践与探索
 6 月 23 日，火山引擎 Force 原动力大会在北京举行。现场，字节跳动技术副总裁洪定坤进行了《 AI Coding 的实践与探索》主题分享。 过去一年，字节跳动的 AI 代码贡献率增长了 6 倍多，...
Claude Code 的第一攻击面，可能就是 CLAUDE.md
每一次 Claude Code 会话开始时，都会先读取一个文件：CLAUDE.md。 在你的第一条提示词之前，在任何代码执行之前，在一切正式开始之前，Claude 会先读取这个文件，并把它当成整个会话的“事实基础”。 这句话本身不复杂，但从安全和合规视角看，信息量不小。 这不是不能用，而是要先回答：谁能改这个文件？ 如果 CLAUDE.md 会被默认读取，并且对后续会话有持续影响，那它就不只是一个普通说明文档。 它更像是项目里的“启动配置”： 里面写什么，模型就可能优先相信什么； 它可能影响后续代码建议、操作路径、判断标准； 如果被恶意修改，它可能变成隐蔽的提示注入入口。 所以第一个问题不是“Claude Code 好不好用”，而是： 谁有权限修改 CLAUDE.md？ 修改之后有没有审计？ 使用者是否知道当前会话读到了什么内容？ 很多团队会认真管生产密钥、CI/CD 配置、部署权限，但对这种“模型上下文文件”的权限边界还没形成肌肉记忆。 风险点拆开看 1. 提示注入不一定来自聊天框 大家谈提示注入，常常盯着用户输入、网页内容、第三方文档。 但这里的问题是：如果每个会话都会先读 CLA
一个开源工具把 Claude Code 会话成本降到三分之一
这条信息很短，但我觉得值得单独拎出来记一笔： 有人做了一篇完整拆解：一个开源工具可以把 Claude Code 的会话成本降低约 3 倍，而且不需要修改 CLAUDE.md、日常输入方式或模型选择。内容还包含安装配置指南，以及它为什么有效的解释。 目前原始信息没有给出工具名称、具体仓库、实现机制和测试样本，所以不能直接把它当成确定性结论。但这个方向本身挺有投研价值，尤其是放在开发者工具和基础设施成本优化这条线上看。 先拆一下这个信号 如果这条描述成立，关键点不在“省钱”两个字，而在于它强调了三个“不改”： 不改 CLAUDE.md 不改使用习惯 不改模型 这意味着它大概率不是靠“让用户写得更短”“换更便宜的模型”“重构工作流”来降成本，而更可能是在会话层、上下文管理、缓存、请求组织或中间层调度上做优化。 对 Claude Code 这类工具来说，成本通常不是单次调用那么简单，真正容易膨胀的是会话持续时间、上下文累积、重复信息传递和多轮交互里的冗余消耗。一个开源工具如果能在不动用户侧工作流的情况下压掉这些冗余，确实有可能出现比较明显的成本差异。 但这里要打个问号：所谓“3x”到底是单个案
不用会写代码，也可以开始搭 AI Agent
这句话我觉得可以先单独拎出来： You do not need to know how to code to build an AI agent. 你不需要会写代码，也可以构建一个 AI Agent。 原文后面其实没有给完整，只停在了“很多人读到这句话会点头，但内心深处仍然相信 agent building is……”这里。也就是说，它想反驳的应该是一个常见默认前提：做 Agent 一定等于写代码、接 API、搭框架、调工具链。 但就目前这段信息能支持的结论，只有一个比较明确： Agent 构建这件事，正在从纯工程门槛，部分转向工作流设计、任务拆解和工具编排。 需要注意的是，这不等于“代码不重要”，也不等于“不会写代码就能做出稳定可上线的复杂 Agent”。它真正变化的是：入门路径和验证方式变了。 它真正变化的是：从“写程序”到“描述任务系统” 以前我们说做一个自动化系统，通常默认要懂： 后端逻辑 API 调用 状态管理 数据库 异常处理 权限和部署 这些当然还在，尤其到了生产环境，不可能凭一句提示词就全解决。 但现在很多 Agent 原型，确实可以先从非代码层面开始： 定义它要完成什
应用层还没死，但问题不能问得太粗
最近反复被创始人和准备加入创业公司的人问到一个问题： AI 应用层还有东西可做吗？还是 OpenAI 和 Anthropic 会把这一层都吃掉？ 我觉得这个问题本身值得拆开看。它不是一个简单的“能不能做应用”的问题，更像是一个关于边界、依赖和风险承担的问题。 这不是不能做，而是要先回答：你到底在做哪一层应用？你的关键能力是不是随时会被底层模型厂商覆盖？你的用户数据、流程权限和合规责任，最后由谁来兜底？ “应用层会不会死”不是一个好问题 如果只问“应用层还在不在”，答案很容易变成情绪判断。 乐观一点的人会说，所有新平台都会长出新应用；悲观一点的人会说，模型公司往上做一点，很多壳应用就没了。两个说法都不算错，但都太粗。 更有用的问法是： 你的产品是不是只是把模型能力包了一层界面？ 你的差异化来自工作流、数据、分发，还是只是提示词？ 如果 OpenAI 或 Anthropic 明天发布类似功能，你还能留下什么？ 企业客户使用你时，安全、隐私、审计和责任边界怎么划？ 你是否掌握不可轻易迁移的上下文、权限体系或业务闭环？ 如果这些问题答不上来，那风险不在于“应用层死了”，而在于这个应用本来就没有
每天一个新框架，怎么判断是不是真信号
每天都有新框架。 新 benchmark。 新“10x”发布。 一开始大家问的是： 我怎么才能跟上？ 但跟着跟着就会发现，这个问题不太对。 真正该问的是： 这里面什么是真信号？ 什么只是披着热闹外衣的噪音？ 我现在看这类东西，会先降速。 不是不看更新，而是不马上搬进工作流。 我会先问三个问题 1. 它解决的是我已经有的痛点吗？ 如果一个工具或框架，只是在演示里很顺。 但我手头没有对应问题。 那它暂时就是收藏夹素材，不是当天要试的东西。 尤其是小团队，最怕为了“跟上”多加一层配置。 最后不是提效，是多了一个人专门维护新玩具。 2. 它能不能当天验证？ 我比较喜欢这种测试方式： 拿一个真实任务 控制在 30 分钟到 2 小时内 看它能不能少一步、少一次复制粘贴、少一个来回确认 不行就先放下 别一上来就迁移整套流程。 太重。 容易把试用变成项目。 3. 它的收益是不是稳定出现？ 有些发布看起来很猛。 但只在 demo 场景里猛。 真实流程里一接 API、一接权限、一接多人协作，立刻掉速。 我更关心的是： 每天重复的事能不能少一点 异常情况能不能处理 团队里不爱折腾的人能不能用 出问题时能不能
GTA 6 定档 2026 年 11 月 19 日，生态已经先跑起来了
GTA 6 的发售日是 2026 年 11 月 19 日。 原文里说，距离现在还有 7 个月。 但有意思的不是发售日本身。 是现在已经有人在围着这个生态赚钱了： 有开发者正在 Cfx Marketplace 上卖定制 Lua 脚本 标价 389 美元 还有人在运营 FiveM RP 相关的东西 这类信号我一般会单独记一笔。 因为它说明一件事： 大游戏还没上线，外围工作流、工具、脚本、服务器运营、社区玩法，已经开始提前形成市场。 这不是“等游戏发售”的生意 很多人会盯着游戏本体。 但社区生态里，最早动起来的往往是这些东西： 服务器搭建 脚本定制 角色扮演规则 付费插件 管理工具 内容模板 玩家社群运营 这些东西看起来碎。 但它们很实际。 一个 FiveM RP 服务器要跑起来，不只是开个房间这么简单。 你要处理权限、经济系统、职业系统、规则、管理、玩家反馈。 最后就会变成一堆重复劳动。 重复劳动一多，就有人卖脚本。 脚本能省时间，就有人愿意付费。 389 美元这个价格，也不算离谱。 如果它能让一个服务器少折腾几天，对运营者来说就有账可算。 可以马上试的观察方法 如果你也想看这类早期机会，
我试了 500 多条提示词，真正有用的往往不是“通用模板”
很多提示词合集都有点太泛了。 比如： “帮我写一篇博客文章。” “总结这段文字。” 这类提示词不是不能用，但如果你真的长期拿它们做内容、分析或开发辅助，会很快发现一个问题：输出质量太依赖运气，也太依赖后续反复追问。 原文里提到，作者测试了 500 多条提示词，最后筛出了 40 条几乎每次都能产出专家级结果的提示词，并提醒大家可以保存下来。 我比较认同这里隐含的判断：真正有价值的提示词，不是把任务说出来就完事，而是要把上下文、目标、约束和输出标准讲清楚。 为什么通用提示词不够用 “写一篇博客文章”这种说法，问题在于它没有告诉工具： 写给谁看； 要解决什么具体问题； 语气应该正式还是口语； 需要多长； 要不要引用案例； 输出应该偏观点、教程，还是复盘。 这就像在 GitHub issue 里只写一句“它坏了”，维护者当然也能猜，但猜出来的结果大概率不是你想要的。 在开发者工具和开源项目里，好的问题描述本身就是协作成本的一部分。提示词也是类似的东西：你写得越清楚，后续返工越少。 真正有用的提示词，更像任务规格 我会更关注这种提示词背后的结构，而不是单纯收藏“40 条神奇句子”。 如果一个提示
40 个大多数用户不知道的 Claude Cowork 命令、工作流与自动化玩法——完整清单
40 个大多数用户不知道的 Claude Cowork 命令、工作流与自动化玩法——完整清单 自从 Claude Cowork 发布以来，我几乎每天都在用它。 先收藏起来 :) 下面这 40 个命令和工作流，真的改变了我的工作方式。 很多人打开 Cowork，只会输入一句：“帮我整理文件。”然后就以为它只能做这些。 这就像你买了一把瑞士军刀，最后只拿它来开瓶盖。 Cowork 其实还有一整层...