如果 harness 只是替当前模型补它暂时做不好的事，比如帮它数草莓里有几个 r，那模型一升级，这层脚手架就白搭了⁠1。真正留下来的 harness 解决的是模型升级本身解决不了的问题：怎么拿到更好的用户输入、怎么理解用户意图、怎么积累记忆，以及一个行业里什么是好、什么是常见错误⁠2,1。所以判断标准不是“这层东西会不会被模型吃掉”，而是“它依赖的是模型能力，还是依赖只有你才有的业务知识和上下文”。前者是短期的，后者会随模型变强而水涨船高。

一个更稳的做法是把业务经验、任务标准和上下文放在模型与 harness 之外单独积累，让模型和 harness 都可以随时替换⁠2。这样模型变强你受益，harness 变强你也受益，而不是押注某一个工具或某一代模型。写 skill 时也是这个逻辑：告诉 AI 什么是好的、什么是容易犯的错误，少教它具体怎么做，因为步骤写太多反而把模型限制在人能想到的做法里⁠2。

模型能力不会无限提升，至少在小众领域会遇到数据不够、只能记住而无法泛化的问题⁠3。而且应用层要解决的是限定问题域里的最优化，模型能力提升会让最终效果跟着提升，但不会替你定义问题域本身⁠4。所以 agentic 的一切不会因为模型变强而失去意义——被替代的是那些只靠模型能力就能完成的部分，剩下的是定义问题、判断好坏、积累上下文这些模型不会自动替你做的事。

判断标准可以简化成一句：这个 harness 处理的问题，是不是模型升级后自己就能解决。戴雨森在对话里把这条讲得很直白——不要做那些因为模型现在不够好、所以替它搭脚手架的事，比如帮它数草莓里有几个 r；要做的是提前为六到十二个月后可能出现的模型能力做准备⁠1。按这个标准，凡是靠“模型暂时做不到”来立身的环节，都只是租来的时间，模型一升级就归零。反过来，用户意图、用户记忆、怎么拿到更好的输入，这些不是模型变强就能自动解决的，所以能留下来⁠1。

你提到进步幅度难以估计，这恰好是判断的前提。查晟在访谈里说，他见过的重度使用者会自己攒几个例子当小 benchmark，新模型来了就试一遍，看能力对不对、跟自己是否相关；他不太看公开 benchmark，因为那更多是各家做 marketing 的工具，有些数据本身错误率就很高，刷分高反而说明有问题⁠2。所以与其猜模型什么时候变强，不如先固定一组你真实工作里的任务，每次新模型出来跑一遍。如果新模型一上来就把你 harness 里某个环节做对了，那个环节就是会被吃掉的；如果反复试还是不行，说明它卡在别的地方。

这确实有长期短期两层，但不是假议题。有一期对话里讲，短期大家看到的是用新技术去解决已经存在的问题、提升效率，命题没变，所以提升有限，甚至一开始还会降；新技术的真正意义在于解决原来根本没被解决的问题⁠3。放到 harness 上：如果它只是把现有流程做得快一点，那模型一强就被抹平；如果它承载的是原来没人解决过的问题——比如某个行业的合规、私有部署、行业 know-how，那模型越强反而越值钱，因为模型公司做的是高度泛化的工具，做不了行业纵深⁠4。

大廠分享的困難，多半不在模型能不能寫程式，而在寫完之後的整合與驗證。有研究發現，經驗豐富的開發者用 AI 後反而多花時間，因為大量時間耗在把生成程式碼接進既有系統、再驗證對不對；問題被歸為工作流沒有為 AI 重新設計，而不是 AI 不行⁠1。同樣地，AI 讓個人寫得更快，但 code review 排隊、審批流程沒變快，一個人的效率被整條流水線的瓶頸抹平⁠1。所以「連大廠都沒解決」反映的是組織與流程的滯後，不是這個題目沒有價值。

Agent 框架常被批評過度抽象：跑最簡單的 demo 很方便，一旦要接企業既有介面或改執行方式，就得追進層層抽象去改底層，反而更慢⁠2。這類「替你規定問題怎麼拆」的框架，正是模型變強後最容易被取代的部分。相對地，模型拿不到的是你團隊的偏好、驗收標準、歷史取捨，讀不到就等於不存在，AI 只能猜⁠3；而這些經驗若散在 Slack、文件、會議紀要裡沒有結構，人一走就蒸發，下次又從頭摸索⁠4。把標準與決策寫成 AI 可讀的素材，本身就是模型再強也繞不開的累積。

如果目標是「寫出能跑的程式」，這部分確實越來越容易被模型補上；但如果目標是對業務結果負責，價值就轉移到理解需求、建立信任、做判斷、定義成功標準⁠5。一個可試的做法：挑一件你最近用 AI 寫的程式，記錄它接進既有系統時卡在哪裡、你補了哪些模型不知道的規則，觀察這些卡點是模型升級能解決的，還是來自你對系統與標準的理解。這能幫你判斷自己該累積的是框架知識，還是判斷與素材。