## Claude 上下文模式:延长 AI 会话时长 Claude 代码使用 MCP 工具时,常常会迅速填满其 200K 上下文窗口,例如,Playwright 快照会占用 56KB,20 个 GitHub issue 占用 59KB。这限制了会话时长,仅 30 分钟后便会损失 40% 的上下文。**上下文模式** 通过充当 Claude 与工具输出之间的服务器,大幅减少数据大小——从 315KB 减少到仅 5.4KB(减少 98%)来解决这个问题。 它通过一个安全的 **沙箱** 实现这一点,在隔离的进程中执行工具调用。只有 *输出* (stdout) 会传递给 Claude,从而防止大型原始数据(如日志或 API 响应)膨胀上下文。支持十种语言运行时,包括通过 Bun 优化的 JavaScript/TypeScript。 内置的 **知识库** 使用 BM25 搜索索引 markdown 和网页内容,返回精确的代码块——而不是摘要——而无需将原始页面内容发送到上下文。 在实际场景中的测试表明,输出大小显著减少(例如,56KB 快照减少到 299B)。这使可用会话时间从约 30 分钟延长到约 3 小时,45 分钟后保留 99% 的上下文。上下文模式易于安装为插件或直接通过 MCP,并且不需要更改现有工作流程。
与一位747飞行员的对话引发了对职业发展本质的思考。这位飞行员精通他的技艺,但感叹经过数十年后,“没有进步”——他已经掌握了关于驾驶747的一切知识。这引起了作者(一位软件工程师)的共鸣,因为人工智能编码代理正在迅速改变他们的工作环境。
这些代理最初被用作高级搜索工具,现在通常在极少的人工干预下完成整个功能。虽然提高了生产力,但这种转变带来了一个挑战:与传统编码不同,依赖人工智能并不能培养对系统和问题解决的相同深度理解。作者发现,随着每个任务的完成,他们学到的东西越来越少,可能面临着与飞行员停滞不前的相似的未来。
尽管承认人工智能辅助的好处和必然性,作者强调了继续重视基础知识的重要性。提示代理很容易,但真正的成功依赖于*理解*问题领域——随着人工智能处理更多实现工作,这项技能正变得可选。他们建议有意识地练习手工编码,以保持和建立这种关键的专业知识。
## Woxi:一个快速的 Wolfram 语言解释器
Woxi 是一个使用 Rust 构建的新的 Wolfram 语言解释器,专为 CLI 脚本和 Jupyter Notebook 设计。它的目标是实现 Wolfram 语言的一个重要子集,通过消除内核启动和许可开销,提供比 WolframScript 更快的替代方案。
目前,Woxi 拥有完整的 Jupyter Notebook 支持,包括图形,以及不断增长的已实现函数库(跟踪在 `functions.csv` 中)。安装过程简单,克隆 GitHub 仓库后使用 Rust 的 `cargo` 即可。
用户可以通过命令行直接执行代码 (`woxi eval '...'`) 或运行脚本 (`woxi run script.wls`)。还提供了一个 Jupyter 内核,用于无缝的笔记本集成,以及一个独立的基于浏览器的 JupyterLite 实例。
Woxi 优先考虑与 WolframScript 的兼容性,要求两个解释器都通过所有测试。鼓励通过 Pull Request 贡献代码——提供了一个全面的测试套件用于开发和验证。
## AI 编码的双刃剑
人工智能工具如今在软件开发中无处不在,极大地提高了生产力。然而,这种收益伴随着隐藏的代价——开发者基本技能可能因此流失。编码的范围从完全人工到完全人工智能自动化,开发者目前处于两者之间。
早期的 AI 工具辅助编码,但承诺自主工作流程的“智能体”往往未能实现,需要范式转变且容易出错。更新、更强大的模型,如 Opus 4.5,正在兑现部分承诺,将工程师的角色转变为监督而非创造。
虽然高管们设想完全自动化,但人们对“认知债务”的担忧日益增加——当开发者*过度*依赖人工智能时,理解力会丧失。研究表明,被动的人工智能辅助会显著降低概念理解和调试技能。这并非关于避免人工智能,而是关于保持认知参与度;仅仅审查人工智能的输出而不进行主动问题解决会导致技能萎缩和倦怠。
风险不仅仅是个体衰退。通往高级工程师的传统路径——建立在实践经验和挣扎之上——正在被绕过,可能造成技能差距。成功整合人工智能需要仔细校准,侧重于增强而非替代,并优先考虑理解而非单纯的速度。忽视这些风险可能导致开发者专业知识的悄然下降,被积极的指标所掩盖,最终阻碍长期创新。