前言
最近读到一篇标题挺有意思的文章：Prove You’re Better Than a Mac Mini。翻译过来，大概是证明你比一台 Mac Mini 更有价值。
原文作者是 Craig Li，一位创业公司的 CTO，文章发表在 Medium 的 Binome 专栏。先把链接放在这里，感兴趣的朋友可以看看：
Prove You’re Better Than a Mac Mini
这个标题还是有点唬人的，程序员读到，可能会想，怎么现在连一台小电脑都要拿来跟自己比较了？
但顺着读下去，作者讨论的其实是一个很实际的问题：当 AI 越来越擅长完成别人交代清楚的任务，人应该把精力放在哪里？
这个问题也值得刚开始学 AI、想借助 AI 做点东西的人想一想。
1. 那台 Mac Mini 上，跑着什么
作者介绍，他用三台苹果电脑运行七个编程 Agent，分别负责功能开发、基础设施、技术债清理、可靠性改进和测试。自己通过管理工具查看进度，补充指令，审查这些助手的工作。
这里的编程 Agent，可以理解为能读取项目、修改代码、运行命令和测试的 AI 编程助手。相比在聊天框里回答一段代码，它能参与的开发步骤更多。
有了这样的工具，作者对初级工程师提出了一个问题：如果你的主要价值，是拿到一张写得很清楚的任务单，然后把它实现出来，那么你还能提供哪些额外价值？
他给出的方向有两个：主动发现值得解决的问题，以及学会组织 AI 工作。
我觉得，读这篇文章最值得关注的，就是这两点。至于几台电脑、几个助手，可以先当成作者的工作配置，不必照着买一套。
2. 第一件事：知道什么值得做
AI 接到明确任务之后，可以帮助完成很多实现工作。但在实际工作里，任务常常没有那么清楚。
用户说用起来麻烦，究竟是哪一步麻烦？一个功能偶尔卡住，应该优先修，还是先做新功能？系统里有很多可以优化的地方，哪个最值得投入时间？
这些问题需要理解使用者、业务目标和现有系统，才能做出判断。
原文里，作者举了几个从日常使用中发现问题的例子。有的是调试时发现缺少观察消息完整过程的图表，有的是发现切换模型要修改太多配置，于是想到增加一层稳定的模型别名，让切换更方便。
这些想法来自接触产品、注意到不顺手的地方，再往下追问原因。
把这个思路放到普通人的工作里，也很好理解。你可能不负责架构设计，但你知道每周哪件事最重复，哪张表最难整理，哪个操作最容易出错。这些具体感受，往往就是一个小工具或一次流程改进的起点。
对于我的日常和AI打交道也是，很多时候我让AI去执行一个任务它确实完成了，但是如果你不审核它做的事情（或者多个agent相互review），你会发现有时候它过度设计了很多东西，有时候很简单的一个问题，它弄出来一堆新的表和代码去处理一些你认为可能概率非常小的事情。这种时候就需要人工跟它说清楚哪些事情可以不要做，很多时候我会在提示词里面再跟它说一下制作必要的修改，不要过度设计。
以前古法编程的时候，有了想法还可能卡在不会实现。现在，可以借助 AI 先做出一个小版本，再看它是否真的能解决问题。
不过前提是，先弄清楚自己遇到了什么麻烦，而不要做了很多没必要的事情，或者做了错误的选择，了解真正的问题来自哪里，仍然值得花时间观察。
3. 第二件事：让 AI 在一个能检查结果的流程里工作
作者还提出了一个面试设问：如果给你几台电脑，希望每天交付几个质量不错的代码改动，你会怎样安排？
多打开几个 AI 会话，确实很容易。接下来才会碰到具体问题：任务怎么分，助手需要读哪些资料，几份改动有没有冲突，完成之后怎样检查？
作者把这类工作称作 harness engineering。这个词有点抽象，我把它理解为，给 AI 安排好工作所需的条件和反馈。
目标要说清楚，资料和工具要准备好，做出来之后还要能验证。发现问题，再把反馈交回去修订。
如果几个助手都在同一份代码上修改，很容易互相影响，因此要考虑隔离工作目录。如果一个功能会影响原有行为，就要检查受影响的场景。即使测试通过，还要确认测试检查的是用户真正关心的结果。
对刚开始使用 AI 的人来说，可以先掌握更简单的一层：告诉它要交付什么、给它必要材料，并提前想好自己怎样判断结果。
比如，让它整理一张表，交付要求就可以包括保留哪些字段、怎样处理重复项、遇到缺失数据怎么办。结果出来以后，拿原始记录抽查，而不只是看排版整不整齐。
这块让AI留档，留证据是很有必要的，因为有些时候模型会胡说，真的，可能大部分时候模型都正常的，偶然有些时候它会胡说，说一些不存在的事情，而且它也没有去检查代码。所以我的工作流或者说给AI的提示词里面就有查明事实必须留下证据和文件，不能在没有数据支撑的时候给出确定性的建议。
工作流程可以从一个助手开始。等到一个任务能够做完、结果也能检查，再考虑增加工具和并行任务，会更容易知道自己缺的到底是什么。
4. 还有一个容易忽略的问题：做得快了，自己学会了吗
原文后半段，我觉得尤其值得刚入门的人读一读。
过去，初级工程师会在实现、报错、调试和修改的过程中积累经验。现在，这些步骤里有不少都能由 AI 帮忙完成。如果只是不断接受结果，交付速度可能提高了，自己却没有理解其中的设计和取舍。
这会留下一个问题：下一次遇到更复杂的情况，或者 AI 给出一个看起来合理却有缺陷的方案时，自己能不能判断？
作者建议，有意识地把使用 AI 的过程变成学习过程。问它为什么这样设计，让它提出其他方案，讨论各自的代价，以及在什么条件下可能失败。
这些问题不用等到研究复杂架构时才问。
哪怕只是合并表格，也可以继续追问：它按哪个字段判断重复？同一个订单出现在两张表里，会保留哪一行？如果某一行缺少编号，它会怎么处理？
然后用几条自己看得明白的数据去试。理解了规则，再看结果是否符合规则。
这样做会比直接接受输出慢一些，但下次再处理类似问题时，你会更清楚该怎么描述，也更容易发现错误。
5. 普通人可以怎样开始
顺着作者的思路，我觉得可以从一件自己熟悉的小事开始，不必一上来就搭建一套多 Agent 系统。
假设你每周都要把几张订单表合并成汇总表。下面只是一个说明思路的例子。
先把麻烦说具体：是复制粘贴太多，容易漏数据，还是不同表里的字段名字不一致？如果这些问题没有分清，给 AI 一句帮我做个自动化工具，它也只能根据自己的理解来补。
接着，把第一版要做的事缩小。例如，先只处理一种格式，列清保留的字段、重复记录的判断方法，以及遇到异常时要怎样提示。让 AI 先整理处理方案，确认规则，再实现。
做出来以后，拿少量数据核对。检查总行数、重复项和几条原始记录，看看结果能不能对上。遇到问题，把实际输入、预期结果和实际结果一起交给它，比只说有 Bug 更容易定位。
等这一小段能用，再逐步增加其他格式、导出方式或界面。过程中也留一点时间，弄懂它怎样处理数据，哪些地方依赖你的假设。
这个例子虽然简单，但已经包含了原文讨论的几项能力：发现问题，把模糊想法说清楚，借助 AI 实现，再判断结果是否可靠。
如果你本来就在学编程，可以进一步阅读它修改的代码，尝试自己解释关键逻辑。如果暂时不写代码，也可以先把需求描述和结果核对做好。具体的工作经验，在这里仍然有用。
6. 标题很有冲击力，但比较时还要算上人的投入
我对原文里电脑成本与工程师价值的比较，还是有所保留。
作者那几台电脑背后，有一位 CTO 在选择任务、理解架构、补充背景和审查结果。文章介绍的是他的工作方式，没有给出足以判断人员替代比例的对照实验。
所以我感觉这个更像看作一位实践者对能力要求变化的观察。它提醒我们，代码实现以外，还有需求判断、系统理解和质量把关；但不能据此简单得出初级工程师不再需要，或者每个人都应该每天交付多少份代码改动。
不同人的起点和工作环境不一样。对个人更有用的做法，是找到自己能理解、也能验证的一件事，认真把它做完。
总结
读完这篇文章，我觉得那个有点挑衅的标题，最后落到了一个很具体的问题上：有了 AI，我们能不能更主动地发现问题，把想法说清楚，并对结果做出判断？
对于普通人，可以先从自己熟悉的一件小事开始。把需求缩小，借助 AI 做出第一版，亲自检查结果，再追问它是怎样工作的。随着理解加深，再承担更复杂的任务。
工程师也好，其他岗位也好，使用工具的同时，自己的判断需要继续积累。这样，做得更快才有机会变成做得更好。
