起因：一个看起来很合理的优化
SayCraft 的核心能力是把用户的对话变成可运行的 Web 应用。背后干活的是一个跑在 E2B 沙箱里的 Claude Code 进程——每次会议启动，它从零开始，读项目结构、理解规则、然后写代码。
问题在于"从零开始"这四个字。Claude Code 每次都要花时间去 Read 那些文件，理解项目骨架，搞清楚哪些组件已经存在。我盯着日志看了几天，觉得这里有油水可榨：如果启动时直接把项目快照塞给它，省掉那些 Read 调用，应该能快不少。
两条路
Claude Code 给了两种注入上下文的方式。一种是 --append-system-prompt，spawn 进程时写死一段字符串，之后改不了。另一种是 SessionStart hook 配合 additionalContext，在每次会话边界动态执行，可以实时生成内容。
我选了 hook 方案。原因很简单：沙箱里的项目状态是变化的，用户说到一半可能已经改了好几个文件，冻结的静态字符串跟不上。
additionalContext 的脾气
这个机制有个好处：注入的内容进 system reminder 区，不挤占对话历史的空间。官方说前 10KB 直接进 context，超出的溢出到磁盘按需加载。
但本地测试的时候出了怪事。我塞了 49KB 的项目快照进去，结果模型只看到了前面大约 2KB。排查了一圈才搞明白：本地开发机上全局 ~/.claude 目录下挂着一堆别的 hook，它们也在抢 additionalContext 的预算。10KB 的总额度被瓜分后，留给我的快照的空间就只剩那么点。
换到干净的 E2B 沙箱环境，没有其他 hook 竞争，30k tokens 的内容全部到达。这个差异差点让我在本地得出"这方案不行"的结论。环境干净与否直接决定了测试结果的可信度，这是第一个教训。
startup 还是 startup|resume
hook 可以配置触发时机。startup 是新会话启动时触发，resume 是恢复已有会话时触发。一开始我两个都配了，想着多多益善。
后来想明白了：resume 的时候，对话历史里已经包含了之前所有 Edit 和 Write 操作的完整内容。再灌一遍项目快照纯粹是浪费 token，还会加速上下文压缩。砍掉 resume，只保留 startup。
差点毁掉产品的盲点
到这里一切看起来都在朝好的方向走。快照注入成功，Claude Code 拿到了完整的项目结构和文件内容，理论上可以直接开始写代码。
然后生产环境炸了。
Claude Code 内部有一个安全检查：写文件之前必须先调过 Read 工具读这个文件。这是硬性要求，没有例外。但我的 hook 把文件内容直接塞进了上下文，模型"觉得"自己已经看过了，就跳过 Read 直接调 Write。Write 被安全检查拦下，报错，重试，再报错，再重试。用户那边看到的就是界面卡死两三分钟，什么反应都没有。
这个 bug 的恶心之处在于它不是每次都触发。有时候模型恰好先 Read 了再 Write，一切正常；有时候它觉得没必要读，直接写，就挂了。间歇性故障，最难排查的那种。
用户发现后要求全部回滚。
回滚之后的意外发现
回滚的过程中我顺手重新测了一下启动时间链路。之前一直以为从用户开口到看见第一行代码的 28 秒延迟里，Claude Code 的冷启动占了大头。
拆开一看：ASR 语音识别收尾 10 秒，coordinator 判断意图并生成计划 4 秒，Claude Code 启动 14 秒。Claude Code 只占一半，另一半的时间花在了上游。就算把 Claude Code 的启动优化到零，用户也还是要等 14 秒。我之前的优化方向从一开始就建立在错误的归因上。
deepseek 的代价
还有一个后续发现值得记录。在用 deepseek-v4-flash 作为模型的时候，2-8KB 的 additionalContext 快照注入直接把首 token 时间从 30 秒拉到了 130-180 秒。三个生产会议都是这样，不是偶发。
不同模型对注入上下文的敏感度完全不同。Claude 吃得下的量，deepseek 可能消化不了。这种差异不测不知道。
我学到的
整件事的教训很朴素：
- 优化之前先确认瓶颈在哪。我以为是 Claude Code 启动慢，实际上有一半时间在上游。
- 本地测试环境和生产环境的差异会让你得出完全相反的结论。那个 10KB budget 被瓜分的问题，差点让我放弃一个本来可行的方案。
- 模型"知道"一个信息和模型"通过工具获取"一个信息，在 Claude Code 的安全模型里是两回事。前者不能替代后者。
- 不同模型对上下文注入的容忍度天差地别。一定要在目标模型上测。
这次优化最终没有上线。但排查过程暴露了启动链路的真实耗时分布，也让我对 Claude Code 的内部机制理解更深了一层。有些弯路，走过才知道路在哪。
SayCraft 还在持续迭代中，欢迎体验：saycraft.ai