AI 编码正在变成一套工作系统
AI 编码工具最近的变化，表面上看是功能越来越多：能看屏幕，能读窗口内容，能记住上下文，能在后台持续执行，甚至能操作本地环境。
但这些功能真正指向的，不是一个更会补全代码的编辑器。
它指向的是另一件事：
AI 编码正在从“生成代码的工具”，变成“可以被托管一段工作的执行系统”。
这个变化比单次模型能力升级更重要。因为它改变的不是代码怎么写，而是工作怎么被组织。
以前的 AI 编码，本质上是对话
早期用 AI 写代码，大多数时候还是一问一答。
你把需求说给它听，它给你一段代码。你把报错贴过去，它再修一版。你补充一点上下文，它再调整一轮。
这个模式能显著提速，但人仍然是整个流程的主循环：
人提供上下文
人描述下一步
人复制报错
人判断方向
人决定是否继续AI 很强，但它没有真正进入工作流。它更像一个能力很强、但每十分钟需要你喂一次信息的人。
所以过去一段时间，我最在意的不是“哪个模型更会写代码”，而是另一个问题：
能不能把一段工程任务，交给一个有上下文、有边界、有验证、有反馈的系统去跑？
如果答案是可以，AI 编码就不再只是聊天框里的生产力工具，而会变成工作系统的一部分。
关键变化一：上下文从“人喂”变成“系统看”
写代码最贵的部分，很多时候不是敲键盘，而是上下文传递。
一个真实任务通常不只需要一段 prompt。它需要知道：
- 当前项目结构是什么
- 哪个文件正在报错
- 浏览器里看到的页面状态是什么
- 测试失败在哪里
- 之前为什么做过某个决策
- 哪些地方不能碰
- 什么证据能证明已经完成
过去这些都要人手动整理。复制代码、贴日志、截图、解释背景、补充前因后果。
当工具开始能看屏幕、读窗口、理解当前环境时，交互结构就变了：人不再把所有上下文搬运给 AI，系统开始自己获取上下文。
这听起来只是少复制几段文字，但实际意义很大。
因为上下文获取一旦自动化，AI 才有可能从“回答一个问题”变成“接住一段工作”。
关键变化二：记忆从“会话缓存”变成“工作资产”
单轮上下文还不够。
真正的工作不是一次性发生的。一个项目会持续几周、几个月，甚至更久。今天的 bug、昨天的架构判断、上周的临时约束、上次踩过的坑，都会影响下一次执行。
如果每次打开新会话都要重新解释一遍，AI 的能力再强，也会被失忆拖住。
这也是我做 distill-vault 时一直坚持的方向：知识库不能只是 storage，它应该成为 runtime。
也就是说，知识不只是被存起来，而是能在下一次检索、判断、执行和构建时继续参与工作。
在我的系统里，Distill 负责把输入变成有类型、有生命周期、有关系的知识对象：来源、项目、概念、决策、约束、输出。Hermes 需要用这些对象时，不是去读一堆散落的 Markdown，而是通过搜索、对象上下文、图谱关系、影响分析这些运行面拿到更可靠的上下文。
AI 需要的不是更多文本，而是更可靠的上下文。
记忆真正有价值，不是因为它“记得很多”，而是因为它能在下一次执行时减少重新解释、减少重复犯错、减少从零开始。
关键变化三：执行从“逐步遥控”变成“目标托管”
当 AI 能理解上下文、保留记忆之后，下一步就是持续执行。
这也是我在 《从 Grill 到 Goal：AI 编码的完整工作流》 里写过的那条线：
Grill → Goal → Loop → Evidence先 grill，把需求、边界、假设和验收问清楚。再写成 goal，让 agent 在明确目标下自主循环。执行过程中不断读取现状、做有界动作、运行验证、根据结果调整。最后用外部证据判断是否完成。
这和“让 AI 写一段代码”不是一个层级的问题。
代码生成关心的是一次输出。目标托管关心的是一段过程。
一个弱 prompt 是：
帮我修一下搜索问题一个可托管目标是：
修复中文搜索“机器学习”返回空结果的问题。
验收标准：搜索相关测试通过，且中文搜索能返回可解释结果。
边界：只改搜索链路，不重构无关模块。
阻塞条件：如果问题来自第三方分词库，停止并报告依赖版本和可选方案。差别不在措辞，而在系统能不能接住。
真正进入工作流的 agent，不能只会动手。它还要知道什么时候继续，什么时候验证，什么时候停下来让人做判断。
关键变化四：环境操作让 AI 从“建议者”变成“执行者”
AI 如果只能在聊天框里返回建议，它仍然停留在建议层。
进入真实工作流，必须接触环境：文件、终端、浏览器、测试、日志、Git、API、定时任务、消息平台。
这也是 Hermes 对我重要的地方。
它不是一个单纯的聊天界面，而是一个执行层：能读文件，能跑命令，能调用浏览器，能发起定时任务，能把结果送回 Telegram，能把经验沉淀成 skill，也能在需要时把任务拆给子 agent。
这类能力看起来杂，但它们共同解决的是同一个问题：
AI 要想承担工作，就必须能接触工作发生的地方。
只会生成答案，不能验证；只会建议修改，不能运行测试；只会总结计划，不能落到文件；只会对话，不能长期调度。
这些都还只是“聪明的建议者”。
当 agent 能在边界内操作环境，并把结果反馈回来，它才开始具备执行系统的形态。
这套变化，最终会落到 harness 上
很多人会把未来想象成一个“数字分身”：它看见你看见的东西，记住你的习惯，在你不在的时候继续工作。
这个比喻有吸引力，但我更愿意把它拆开看。
所谓数字分身，真正有用的不是拟人感，而是五层能力：
- 上下文获取：它能自己看见当前发生了什么。
- 长期记忆：它能记住项目、偏好、约束和历史判断。
- 目标托管：它能围绕一个明确目标持续推进。
- 环境操作：它能接触真实工具链，而不是只停在文本建议。
- 证据验收：它能用测试、日志、截图、diff、响应结果证明完成。
这五层能力不会靠一个模型自然长出来。它们需要外部系统承载。
这个外部系统，就是 harness。
模型负责推理和生成，harness 负责上下文、工具、权限、记忆、调度、验证和沉淀。没有 harness，AI 很聪明，但仍然漂浮在对话里。有了 harness，AI 才能进入真实工作流。
我自己的系统怎么接这件事
我现在更愿意把自己的系统分成三层：
1. Distill：知识运行层
Distill 负责把输入变成可维护知识对象。
它处理的是：什么值得记，什么该晋升，什么已经过时，哪些对象互相依赖，哪次改动会影响哪些结论。
这解决的是长期记忆和可靠上下文问题。
2. Technical Knockout：外部参考层
Technical Knockout 负责把优秀开源项目拆成可复用的架构模式、实现路径和关键取舍。
它不是为了“看过很多项目”，而是为了让下一次构建有更好的参考坐标。
这解决的是判断质量问题：agent 可以执行，但人需要知道什么方向值得执行。
3. Hermes / Agent Workflow：执行层
Hermes 和 Agent Workflow 负责把判断变成动作：读上下文、拆任务、调用工具、跑验证、汇报证据、沉淀经验。
这解决的是执行闭环问题。
单独看，每一层都只是一个工具或项目。接起来之后，它们才变成一套一人工作系统：
Distill 提供可靠上下文
→ Technical Knockout 提供外部参考
→ Hermes / Agent Workflow 执行任务
→ 产出产品、文章、自动化和经验
→ 再回流 Distill这也是我现在看 AI 编码演进时最关心的部分：不是某个工具多了一个按钮，而是这些按钮背后正在逼近一套完整的工作系统。
人的价值会更靠前
当 agent 越来越能执行，人并不会消失。
人的位置会前移。
以前人的价值经常体现在“我能写这段代码”。现在更重要的是：
- 我知道该解决什么问题
- 我知道什么不该做
- 我知道怎样定义完成
- 我知道哪些风险不能交给自动化硬闯
- 我知道结果是否真的有价值
AI 越能执行，人越不能只停在执行层。
人要负责目标、边界、取舍和验收。Agent 负责在清楚边界内放大执行。
这不是把判断交出去，而是把执行托管出去。
如果只记一件事
AI 编码的下一阶段，不是更快地产生代码，而是更稳定地接住工作。
真正值得构建的，也不是一个越来越像人的聊天对象，而是一套能把知识、参考、工具、验证和沉淀连接起来的工作系统。
模型会继续变强，工具会继续更新，功能会越来越像“数字分身”。
但决定它能不能真正进入你的工作流的，仍然是那套外部结构：
上下文 → 记忆 → 目标 → 执行 → 验证 → 沉淀把这条链路接起来，AI 才不只是帮你写代码。
它开始帮你承担工作。