“追赶焦虑驱动的动力，往往比战略驱动的动力死得更难看。”
前几天偶然听到这句话，挺扎人的。
这两年做 AI，多少都有点追赶焦虑。模型更新了，要试；新工具出来了，要装；别人又做出一个 Agent，也得琢磨自己是不是慢了。每天都很忙，但真要问一句到底在追什么，往往说不清楚。
我以前也不知道该怎么处理这种焦虑。最近翻了翻这半年做过的东西，才发现答案不是少看新闻，也不是劝自己放松，而是把注意力从“又出了什么”移到“我拿它做过什么”。
AI 时代，很多认知没有脱离具体实践单独存在的价值。没亲手做过，知道得再多，也很难判断哪些东西能留下。
三个月前能用的方法，今天未必还对
年初做 Jarvis 时，我最早的思路是写一个大的 Skill，把身份、能力、个人信息和工具调用全塞进去。逻辑上没什么问题，跑起来却不是那么回事。
Claude Code 和 OpenCode 对长指令的遵循并不稳定，尤其任务继续拆给子指令之后，越跑越容易偏。后来我把 Jarvis 改成固定工作区：身份放身份文件，长期记忆放 MEMORY.md，日常记录按日期保存，具体能力再拆进独立 Skill。
这次调整并不是换了一个更时髦的文件名。真正变化的是我对上下文的理解：上下文不是给得越多越好，信息放在哪里、什么时候加载，比把所有内容一次性告诉模型更重要。
如果当时只停留在“Skill 是个好东西”这层认识，这段经验现在已经过时了。真正留下来的，是一条更朴素的判断：模型开始跑偏时，先别急着补指令，看看是不是上下文的组织方式出了问题。
模型不会替你补上工程现场
后面做 E2E 测试，这个感受更明显。
最初让 AI 写测试，大家很自然地把精力放在 Prompt 上。需求描述得再清楚一点，页面信息再多给一点，选择器规则再强调一遍。模型生成代码很快，但第一次跑通率只有大约 30%。大量时间还是花在修选择器、补页面状态和定位失败原因上。
继续调 Prompt 已经很难解决问题。AI 缺的不是一句更聪明的提醒，而是它根本没看过真实页面。
后来才有了 Recon、Capture 和 Coverage：写用例前先采集页面结构，执行过程中记录步骤快照，跑完再看代码覆盖盲区。AI 不再猜按钮叫什么、页面现在是什么状态，而是读取结构化数据再动手。几个模块跑下来，首次通过率从约 30% 提到了 75%。
模型当然也在变强，但这个项目真正往前走，并不是因为等到了更强的模型。我们只是把工程师原本靠眼睛观察、靠经验补齐的东西，变成了 AI 可以读取的数据。
这也是动手和围观最大的区别。围观模型升级，很容易把问题都归到能力强弱上。真正接进项目，才会看到不少所谓的模型问题，其实是感知缺失、数据不全，或者流程里根本没有反馈。
熟悉的场景，也得重新做一遍
有些场景看起来很熟，真用 AI 重做一遍，原来的经验也只能用一半。
前阵子我做了一个手机语音遥控 Claude Code 的小工具。第一反应很直接：语音识别成文字，再把文字送进终端。做出来一用就发现不对。
终端不只接收文本。说“回车”时，我要的是一个 Enter 按键；说“中断”时，要的是 Ctrl+C；只有“把测试也跑一下”这种话，才应该作为 Prompt 送给 Agent。
于是语音管道被拆成两条：短控制词走正则，直接映射按键；自然语言先清理口语，再注入终端。另一个关键设计，是把 PTY 进程和手机连接分开。手机锁屏、切应用、网络抖动，Agent 都继续运行，回来后再补上期间的输出。
这些都不是多高深的技术。麻烦在于，不真正躺到沙发上用几次，很难想到交互边界应该画在哪里。以前做 Web、做终端积累的经验还在，但到了“人通过语音指挥 Agent”这个场景，输入、连接和任务生命周期都得重新看。
AI 带来的变化不只是编码更快。它会改变工作中一些原本默认成立的关系：人不再持续盯着任务，输入也不一定来自键盘，一次会话断开更不代表任务结束。老经验没有作废，只是不能原样套用。
能留下来的，通常不是那份代码
回头看这几个项目，具体实现都可能过时。
Jarvis 的文件结构还会调整，E2E 使用的模型和工具链会升级，语音终端也可能被新的客户端能力取代。今天觉得合适的 Prompt，过三个月大概还要重写。
但有些判断会留下来：上下文要按任务组织，不能靠堆；AI 缺少现场信息时，要补数据通道，不能只补措辞；新的交互方式进来后，要重新划分输入和任务的边界。
这些判断不是看发布会看出来的，也不是和模型聊出来的。它们都来自一个个不大的东西：一个助手、一套测试工具、一个手机遥控器。先做出第一版，再在使用中发现原来的思路哪里不够。
所以现在再看到新模型、新框架，我还是会关注，但没那么急着判断它会改变什么。先找一个手边真实的问题，让它跑进去。跑不通的地方，通常比跑分更有东西。
AI 变化很快，具体做法当然会过时。真正值得沉淀的，是你亲手碰过边界之后留下的那点分寸感。