从实务角度整理 Web 开发、基础设施与 AI 编程工具的技术博客。 除了步骤，也会记录失败案例、选型标准，以及线上运行中发现的限制。
周五下午，一个包含 50 个文件更改的 Pull Request (PR) 被提交。其中涉及大规模重构，是功能实现所必需的，因此更改内容很多。同事们只留下“周一再看”的评论，最终，下周的发布计划也遥遥无期地延迟了。评审人员不知道从何处着手，而 PR 作者则在解决因评审延迟而产生的冲突中浪费时间。
这种情况的根本原因是上下文不足。评审人员需要消耗大量的认知资源来理解更改代码的整体上下文。追踪所有函数调用关系并评估潜在副作用的过程既枯燥又困难。最终，评审可能只停留在表面的代码风格上，或者在未能充分理解核心逻辑的情况下留下“LGTM”。
本文将以 Before/After 的形式，比较如何利用基于 AI 的代码编辑器 Cursor 解决这个问题。我们将探讨如何利用 AI 理解并总结整个代码库上下文的功能，从而减轻评审人员的负担，并实现更深入的评审。
一位新加入项目的同事负责重构遗留模块。为了理解这份包含数千行代码的文件，他将整个代码复制粘贴到像 Claude 3 Opus 这样的高性能模型中，并开始提问。结果令人满意，但其他做类似工作的团队成员却使用了不同的模型或提问方式，得到了截然不同的答案。
到了月底，结算账单让所有人大吃一惊。他们发现某些特定任务的成本比预期高出数十倍，原因就是无节制地输入了长上下文。尽管个人生产力可能暂时提高了，但从整个团队来看，这导致了成本无法预测，且产出一致性缺失的问题。
本文将探讨在团队引入 Anthropic 模型时，技术负责人或高级开发人员应提前制定的一些规则和基本设置。这有助于可预测地管理成本，并确保团队成员的输出质量保持在一定水平。
我在遗留服务迁移工作中首次引入了 Antigravity CLI。最初几天一切顺利，但随着文件数量的增加，CLI 开始重复修改“已修改的文件”。经检查发现，是会话之间上下文被重置，导致 CLI 在完全不了解之前决策的情况下继续执行后续操作。结果，同一个函数的签名被修改了两次，期间编写的测试也因此两次都失效了。
本文将探讨 Antigravity CLI 如何处理上下文、上下文丢失发生在哪里，以及如何确保意图跨会话持续存在的模式。如果你正在经历“CLI 随意修改代码”的症状，那么原因很可能不是工具本身的 bug。
阅读本文，你将了解 Antigravity CLI 在跨越会话边界时上下文为何会中断，以及应采用何种文件结构和调用模式来防止这种情况发生。
最近，我们团队使用的商业LLM API月度费用开始超出预期。考虑到数据安全方面的顾虑，我们开始研究在本地直接运行模型的替代方案。碰巧我的开发设备配备了M2 Max芯片，而且LM Studio无需复杂设置，只需几次点击就能运行像Llama 3这样的高性能模型，这非常有吸引力。
最初的体验是成功的。我无需担心API密钥管理或token费用，可以自由地生成代码和提问。它对编写简单脚本或生成样板代码提供了即时帮助。然而，在大约一周深入应用于实际工作后，我意识到除了硬件规格和模型性能之外，还产生了意想不到的“成本”。虽然这不是显性的金钱成本，但它确实消耗了我的时间和精神能量。
在本文中，我将结合具体案例，探讨使用LM Studio运行本地模型时，隐藏在硬件规格之外、容易被忽视的三种成本（探索、一致性、上下文）。
在冲刺中期，一位团队成员将 Copilot 生成的代码原封不动地提交到了 PR 中。评审者花费了比平时多一倍的时间来验证逻辑，最终以“这代码是你自己写的，还是 Copilot 写的？”这个问题开始了审查。当时，该团队引入 Copilot 已有三周，但没有任何标准。
这种情况并非工具本身的问题。Copilot 被设计为个人生产力工具，但在团队中使用时，会同时带来审查标准、上下文共享和许可证管理等问题。如果没有任何准备就“先用起来”，那么在生产力提升之前，摩擦会先出现。
本文将讨论领导者在团队引入 Copilot 之前，应根据团队规模（1人 → 3人 → 10人）决定的事项及其原因。重点在于团队共识点，而非安装方法。