https://codexer.com/tags/%E8%87%AA%E5%BE%8B/Recent content in 自律 on CodexerHugozh-cnWed, 02 Sep 2026 09:00:00 +0800https://codexer.com/posts/2026-09-02-codex-ai-boundaries/Wed, 02 Sep 2026 09:00:00 +0800https://codexer.com/posts/2026-09-02-codex-ai-boundaries/<p>最近我注意到一个很有意思的转变。两三年前，人们讨论 AI 编程助手，问的都是「它能做什么」：能补全代码吗？能改 bug 吗？能写测试吗？而现在，Codex 这样的 agent 已经能独立把一个需求从 issue 一路做到合并请求，问题的重心悄悄变了。真正值得问的，反而变成了「我们该让它做什么，又不该让它做什么」。</p> <p>前几天读到一位开发者 anukin 写的文章《To bot or not to bot》，他把自己和 AI 打交道的这些年梳理了一遍，最后落到一个相当反直觉的结论上：比起炫耀自己用 AI 做了什么，他更愿意清楚地划出哪些事坚决不让 AI 碰。这篇文章让我很有共鸣，今天就借他的框架，聊聊 AI 时代的「边界感」。</p> <h2 id="一条快速演进的曲线">一条快速演进的曲线</h2> <p>作者把这段旅程分成了几个阶段，回顾起来能清楚地看到工具和人之间的关系是怎么一步步松动的。</p> <p>最早是 GPT-3 的 API 时代，那时要自己调 temperature、top_p 这些参数，模型还叫 Davinci、Curie、Ada。大家用它写点文案、改改邮件、生成点简单的页面，本质上是个更聪明的自动补全。</p> <p>接着是 ChatGPT 时代，人和模型开始对话，把代码贴进去让它纠错、让它写测试。Aider 这类工具在那个时候很受欢迎。</p> <p>再到 agentic 时代，事情就完全不同了。模型背后多了一套 harness（执行外壳），能自己读文件、跑命令、跨多轮推进一个半长的任务。人从「写代码的人」变成了「给方向的人」，把精力花在架构、数据建模和产品判断上。AGENTS.md、CLAUDE.md 这类上下文文件也是这时候流行起来的。</p> <p>而现在是作者所说的「后 harness 时代」，RLM、各种自定义 harness，还有 omnigent 这类 meta-harness 开始出现，编排多个 agent 并行干活成了一件正经事。</p> <p>这条曲线最值得玩味的地方在于：AI 每进步一档，人和它的关系就松动一分，直到现在，人的核心价值几乎完全落在了「判断」和「边界」上，而不是「动手」。</p> <h2 id="我的日常工具箱">我的日常工具箱</h2> <p>作者总结了自己现在的几块核心工作方法，我挑几个最有共鸣的展开说说。</p> <p><strong>测试与评测。</strong> TDD（测试驱动开发）对引导模型特别管用，先写测试，再让模型去满足它，输出就被牢牢框住了。如果你做的是 AI 产品，eval（评测集）能给你那一点点宝贵的确定性。</p> <p><strong>上下文管理。</strong> 他把上下文比作一个收拾得井井有条的衣柜，找衣服很快；如果乱成一团，翻半天都找不到。上下文污染会直接拖累压缩（compaction）的效果。他还提了一个很具体的观察：Claude Code 比 Codex 更容易因为压缩而掉性能。这个对比值得长期留意。</p> <p><strong>并行验证。</strong> 他习惯让多个 agent 并行干活，再并行验证、合并。核心问题是判断哪里需要人类介入。他用一种「基于副作用的测试」，让应用本身记录足够多的日志，用日志来验证结果，这能大大降低问题溜出去的概率。</p>