最近我注意到一个很有意思的转变。两三年前，人们讨论 AI 编程助手，问的都是「它能做什么」：能补全代码吗？能改 bug 吗？能写测试吗？而现在，Codex 这样的 agent 已经能独立把一个需求从 issue 一路做到合并请求，问题的重心悄悄变了。真正值得问的，反而变成了「我们该让它做什么，又不该让它做什么」。

前几天读到一位开发者 anukin 写的文章《To bot or not to bot》，他把自己和 AI 打交道的这些年梳理了一遍，最后落到一个相当反直觉的结论上：比起炫耀自己用 AI 做了什么，他更愿意清楚地划出哪些事坚决不让 AI 碰。这篇文章让我很有共鸣，今天就借他的框架，聊聊 AI 时代的「边界感」。

一条快速演进的曲线#

作者把这段旅程分成了几个阶段，回顾起来能清楚地看到工具和人之间的关系是怎么一步步松动的。

最早是 GPT-3 的 API 时代，那时要自己调 temperature、top_p 这些参数，模型还叫 Davinci、Curie、Ada。大家用它写点文案、改改邮件、生成点简单的页面，本质上是个更聪明的自动补全。

接着是 ChatGPT 时代，人和模型开始对话，把代码贴进去让它纠错、让它写测试。Aider 这类工具在那个时候很受欢迎。

再到 agentic 时代，事情就完全不同了。模型背后多了一套 harness（执行外壳），能自己读文件、跑命令、跨多轮推进一个半长的任务。人从「写代码的人」变成了「给方向的人」，把精力花在架构、数据建模和产品判断上。AGENTS.md、CLAUDE.md 这类上下文文件也是这时候流行起来的。

而现在是作者所说的「后 harness 时代」，RLM、各种自定义 harness，还有 omnigent 这类 meta-harness 开始出现，编排多个 agent 并行干活成了一件正经事。

这条曲线最值得玩味的地方在于：AI 每进步一档，人和它的关系就松动一分，直到现在，人的核心价值几乎完全落在了「判断」和「边界」上，而不是「动手」。

我的日常工具箱#

作者总结了自己现在的几块核心工作方法，我挑几个最有共鸣的展开说说。

测试与评测。 TDD（测试驱动开发）对引导模型特别管用，先写测试，再让模型去满足它，输出就被牢牢框住了。如果你做的是 AI 产品，eval（评测集）能给你那一点点宝贵的确定性。

上下文管理。 他把上下文比作一个收拾得井井有条的衣柜，找衣服很快；如果乱成一团，翻半天都找不到。上下文污染会直接拖累压缩（compaction）的效果。他还提了一个很具体的观察：Claude Code 比 Codex 更容易因为压缩而掉性能。这个对比值得长期留意。

并行验证。 他习惯让多个 agent 并行干活，再并行验证、合并。核心问题是判断哪里需要人类介入。他用一种「基于副作用的测试」，让应用本身记录足够多的日志，用日志来验证结果，这能大大降低问题溜出去的概率。

编排。 把大任务切成 implementer 和 verifier 的配对循环，每个单元有自己的验收标准，跑在各自的 git 分支上，最后合并。项目管理里的 epic、story 拆分经验，在这里意外地好用。

工具层面，他偏爱终端工具，Codex、Claude、opencode、pi 混着用，套在 omnigent 或 hermes 下面。记忆系统帮他在这几个 harness 之间无缝切换，沙箱（本地和云端）让他敢放手让 agent 跑，而当 Codex 或 Claude 的周额度用完了，本地模型 qwen 还能顶上。

主动放弃的两样东西#

比「用什么」更有信息量的，是「不用什么」。他明确放弃了两个东西。

一个是 factory（软件工厂）这类玩法，他的评价很直白：token 黑洞，相比维护良好的编排系统，没有可衡量的收益。不过他承认 gas town、factorio 这些变体也许能产出有价值的反馈，未来自己可能重新考虑。

另一个是 agentic IDE。他的理由很朴素也很实在：代码库有些部分需要认真读，有些部分可以交给模型生成（vibe coding），而 Cursor、Windsurf 这类工具会打断他的阅读过程，让他没法连贯地组织思路。他更愿意用 IntelliJ、Zed 把「读代码」和「生成代码」两件事分开。

我拒绝交给 AI 的四件事#

整篇文章最有分量的部分，是他列出的一份「反向清单」：哪些事坚决不让 AI 代劳。这四条，比任何「我用 AI 做了什么」都更能说明一个人对工具的理解。

第一条，博客和一切原创思考。 他说自己以前会用 AI 大改博客，现在决定不这么做了。这个选择挺反主流。他意识到，有些事 AI 做得再好，也应该留给自己。写作、阅读、学一门新技能，正是他想保留、不想外包出去的部分。

第二条，私人消息和情书。 这是他最早尝试外包的东西之一，但很快发现，需要真诚的连接一旦交给 AI，很快就变得机械、失去温度。他认识到这对一个人来说至关重要。

第三条，架构。 AI 有时候表现得很懂行，但也会一本正经地唬你（bluff）。一旦被带偏，做出一个糟糕的架构，后面改起来极其痛苦。架构决定了代码怎么组织，这事他留给自己。

第四条，数据建模。 AI 在这个环节能帮上忙，能很快发现设计里的漏洞，但完全把这个决策交给 AI 是有问题的。据他观察，RL 这类后训练手段并没有在这一块带来明显改善。

这四条放在一起，其实是一条很清晰的原则：凡是涉及「判断」「品味」「真诚」和「长期代价」的事情，都自己扛；凡是机械、重复、可验证的事情，才交给 AI。这个分法，比我见过的很多「AI 提效指南」都要诚实。

边界感，是 AI 时代的新素养#

读完这篇文章，我最深的感受是，边界感正在成为 AI 时代一项新的核心素养。

工具越强，「会用它」的门槛越低，「用好它」的门槛反而越高。当 Codex 能把任何一个需求一键变成代码的时候，人和人之间的差距，就不再是谁打字快、谁熟悉框架，而是谁更清楚自己该把注意力放在哪里，谁更敢于对 AI 说不。

那份「反向清单」的意义正在于此。它不是保守，而是一种清醒：知道 AI 的边界，也守住自己的边界。技术会继续变，harness 会继续演进，factory 和 agent swarm 也许明天就成熟了，但「哪些事值得亲手做」这个问题，答案大概会长久地跟随着我们。

参考来源：To bot or not to bot: My personal rules of engagement with AI，作者 anukin。