如何理解harness

立正署名文章把上下文管理拆成三层记忆：工作记忆是当前任务直接需要的，项目记忆是这个项目积累的经验和决策，组织记忆是跨项目的长期知识。原始会议纪要、Slack 讨论、设计文档属于 raw context，需要定期提炼成有效经验、踩过的坑和判断标准。文章还强调渐进式加载：不能把所有东西一股脑塞进窗口，而要建索引、做分类、设计加载策略，让 AI 自动找到需要的那部分，不多不少⁠1。

同一篇里还有一层概念图，用来标出团队的上下文现在散落在哪里、哪些该被日常调用、哪些该长期沉淀、哪些需要定期更新。作者把它比作给客户看的 marketing calendar：先看清现状，再谈技术落地⁠1。

立正在课程更新里把可积累的资产归成五类：工作空间、可复用的 skill、结构化知识资产、多 agent 组织和个人判断。具体组织方式是用 facts（事实）、skills（做法）、perspectives（判断）区分私有上下文，用 progressive disclosure 按需加载，用 backflow 把每次纠正沉淀回系统⁠2。

他在对话里也表达过相近的区分：文件是 what，即有什么信息；skill 是 how，即这件事怎么做；再往上是 resolver，遇到任务时决定调用哪些东西。他还说，人类积累的 context 往往严重不足，散在聊天工具、会议和文档里，把它们组织好、沉淀好本身就是很重要的一环⁠3。这些是他本人在节目中的陈述，不是对某位嘉宾观点的转述认可。

如果目标是积累自己的上下文资产，可以先做两件成本低的事。一是把值得回看的材料落成 Markdown 存在自己的目录里，能搜索、能修改、能换模型继续加工；立正谈录音整理时明确说，工具可以换，这些积累要跟着自己走，不能被工具绑架⁠4。二是写结果类 skill 而不是风格类 skill：把该给的工具、对结果的要求、边界和案例交给 AI，而不是教它一步步做事⁠5。

判断是否值得投入时，可以问一句：这一步具体让哪一段变好了？是材料更容易找到，还是纠正能被记住？如果答不上来，可能只是多买了一件要维护的东西⁠4。这是 AI 基于上述材料做的应用推演，不是原文给出的检查清单。

立正在谈 AI 写脱口秀段子时说，大家写 prompt 太懒，只写“你是一个优秀的脱口秀演员，帮我写个段子”是不够的；要先讲清想要的风格、参考的人、原则，再把平时沉淀的故事和想法交给它⁠1。他还提出一个检验办法：把 AI 当成一个聪明但对你的工作一无所知的人，问自己“要完成这件事，我需要告诉他什么”，多数时候问题出在关键信息没给到⁠1。这是 AI 对“人味从哪来”的综合判断：人味首先来自只有你才有的观点、经历和取舍，而不是来自形容词。

老冒讲过一个实验：一篇文章每行字都是 AI 写的，但观点是他的、也是他认可的，结果进了 Hacker News 前十；他随后照同样模式又写了几篇，都没有效果⁠2。他自己的解释是，AI 帮他把观点组织得更好，而不是替他产生观点⁠2。这提示一个可操作的边界：让 AI 承担“把想法写好”的部分，把“想说什么、为什么在意”留给自己。不过这只是他一次实验的观察，重复失效也说明光有模式不够。

署名立正的文章谈 taste 时建议：找“相似但质量不同”的样本放在一起比较，问哪个更好、为什么，差异才是判断力的入口；同时先保留第一反应，再解释，别让解释压过感受⁠3。同一篇还强调要动手做并反复改，因为只有做才会遇到真实约束⁠3。把这套方法用到 AI 写作上（以下是 AI 的应用推演）：与其笼统要求“更有人味”，不如拿两版稿子对比，指出哪句假、哪句空、哪句是你真会说的话，再让 AI 按这个差异改。这样你给的是可核对的判断，而不是一个形容词。