halcight · 系统设计与 AI 编程

AI 时代，如何招聘工程师

Fri, 13 Nov 2026 00:00:00 GMT

传统的技术面试以编码能力为核心：候选人熟悉哪些语言和框架，能否在白板上写出算法题的解法。

在 AI 时代，这已不再是筛选人才的有效标准。一个人即使不熟悉某种编程语言，也能借助 AI 交付有价值的产品。

更值得考察的是两项能力。

其一是对系统的整体理解：一个完整的系统应当包含哪些部分，各部分如何协作，上线后如何确认它在正常运行。缺少这种理解，就无法评估 AI 给出的方案。

其二是求知欲：主动追踪新知识，尤其是 AI 领域。工具和模型更新很快，今天的最佳实践，半年后可能已经过时。是否愿意持续学习、尝试并反思新技术，会直接影响一名工程师的长期成长。

当下最重要的六项能力

1. 向 AI 准确表达意图。 AI 只能基于给定的信息工作。目标、约束、完成标准，哪些已经确定、哪些尚未确定，表达得越清楚，产出就越接近预期。表达含糊，得到的往往是看似合理、实则偏离需求的结果。

2. 理解 AI 的意图。 AI 交回一份计划或一段代码时，工程师要能读懂它的思路：它如何理解需求，做了哪些假设，哪些地方是在推测。能识别 AI 的误解，比能亲手写出同样的代码更重要。

3. 面对模糊目标，形成预判。 需求在初期通常是模糊的。优秀的工程师在动手之前，会先对系统形成一个初步判断：大致由哪些部分组成，难点可能在哪里，并随着新信息不断修正。有了这个预判，才能判断 AI 的方案是否方向正确。（我的做法见现在我怎么设计系统。）

4. 设计测试。 代码生成得再快，验证也不能省略。哪些部分必须测试，采用什么方式，测试是否真正覆盖了要验证的行为，这些都需要工程师判断。

5. 设计监测。 测试在上线前验证关键行为、降低缺陷风险；监测在上线后观察运行状态、及时发现异常。两者都不能保证系统始终正确，但缺一不可。需要哪些日志和指标，故障发生时由谁、在多长时间内发现，这些应当在设计阶段就纳入考虑，而不是在事故之后补救。

6. 管理 AI 工作流。 无论使用一个还是多个 agent，如何分工，如何评审产出，如何保留上下文，如何避免自己成为瓶颈，这本身就是一项工程能力。（我的做法见我怎么同时管十几个 AI agent。）

面试中如何考察

用 grill-me 考察判断力和表达能力

grill-me 是一个 AI skill：给定一个计划，AI 会按决策之间的依赖关系分轮提问，并为每个问题附上推荐答案，直到所有决策都有结论。

面试时，给候选人一个模糊的需求，请候选人通过 grill-me 与 AI 对话，把需求整理成明确的方案。开始对话前，先请候选人简述系统边界、关键假设和待验证的问题；对话结束后，再请候选人说明哪些判断改变了，以及为什么。这一步考察的是第 3 项能力：在 AI 给出建议之前，候选人自己的判断是什么。

对话过程中，面试官重点观察两点：

是否有独立判断。 标准不是是否反对 AI，而是候选人能否说明接受或否定每条建议的依据，以及准备如何验证。完全依赖 AI 的人，在 AI 出错时也很难察觉。
表达是否准确。 回答是否清晰，是否提供了必要的上下文和理由；AI 理解有误时，能否及时发现并纠正。

与白板题相比，这种方式更接近候选人的日常工作。

系统设计题：是否主动考虑测试和监测

系统设计题依然有价值，但考察重点已经改变。画出组件和数据流，AI 同样能做到。更值得关注的是，候选人是否主动提到：系统如何测试，上线后如何监测，故障如何发现。主动提到只是线索，还应追问一个具体的故障场景：测试如何暴露问题，上线后靠什么信号发现，由谁响应。这些回答能为判断候选人是否理解系统整体提供依据，但不能仅凭一个场景就下结论。

了解候选人日常如何管理 AI agent

最后，请候选人介绍日常使用 AI 的方式：同时使用几个 agent，如何分工，如何评审产出，遇到过哪些问题，最近尝试了哪些新工具，为什么保留或放弃。

具体的经历和教训是进一步追问的依据，但不能只凭叙述是否流畅来判断实际能力。这个问题同时也在考察求知欲：一个人最近在尝试什么，比简历上的技能列表更能说明问题。

保证公平

面试方应提供统一的 AI 工具、模型和账号，预先装好所需的 skill，留出熟悉环境的时间，并统一任务、时限和评价标准。不按 agent 的数量或付费工具的使用经历加分：没有机会使用这些工具的候选人，同样可以在现场任务中展示如何组织工作、验证结果和学习新方法。

结语

AI 时代需要的，不是编码最快的人，而是能与 AI 协作，把模糊的目标落实为完整、可测试、可监测的系统，并且持续学习的工程师。

我怎么同时管十几个 AI agent

Sat, 07 Nov 2026 00:00:00 GMT

我同时推进八个项目，高峰时有 17 个 agent 在运行。

我用 Herdr 管理它们。Herdr 是面向编程 agent 的终端工作区：每个 agent 占一个窗格，Herdr 能识别它处于工作、阻塞、完成还是空闲状态；agent 之间也可以读取彼此的输出、互发消息。

但工具只解决了可见性。真正的瓶颈是我的注意力：逐个窗格切换，每次都要重建这个项目的上下文。agent 越多，我越会成为整个系统里最慢的一环。

我的做法是两层结构，再加一个专门替我巡检的 agent。

和主 agent 深谈，对所有 agent 浅读

我和主 agent 深谈、对齐
编排 agent 读取、通知、转达
提醒我
主 agent 启动子 agent 并验收

同时存在两种对话：

我和主 agent：深度对话。 每个项目有一个主 agent，掌握该项目的完整上下文。设计、计划和待决事项，我直接和它对齐。
编排 agent 和所有 agent：浅层读取。 编排 agent 不负责任何项目。它每 5 分钟读取所有 agent 的最新输出，只把需要我处理的事报告给我。

这样我不必逐个切换项目也能掌握全局；需要深入时，只进入一个项目，只和一个主 agent 对话。

结构只有两层。 主 agent 可以启动子 agent，例如评审、某个 PR 的实现者，或几个并行的小组；子 agent 不再启动下一层。这样每个 agent 与掌握上下文的主 agent 最多相隔一层，产出由主 agent 验收。层级再深，责任边界会变得模糊，上下文也会逐层流失。

四种角色

我：和各主 agent 确定方向；处理需要我决策的问题、审批对话框，以及只能由我在网页上完成的操作。写云资源、改基础设施这类高风险操作，由我亲自确认。
主 agent： 对一个项目负责：上下文、计划、PR，以及一份记录当前状态的文件。自己开的 PR 负责到合并为止，包括 CI、评审意见和冲突。可以启动子 agent，并验收其产出。
子 agent： 为主 agent 完成一项边界明确的任务，例如实现一个 PR、评审一份设计、做一轮清理。向主 agent 汇报，完成后关闭。
编排 agent： 不负责任何项目或 PR。每 5 分钟巡检所有 agent，报告需要我处理的事，通知工作重叠的双方，并把我的答复原样转达。

每 5 分钟：先查重叠，再查待处理

编排 agent 每一轮都按固定顺序执行：重叠检查、待处理检查、报告。

这两项检查是整套做法的核心。agent 多了以后，常见的问题往往不是某个 agent 做错了，而是两个 agent 各自都对、合在一起却冲突；或者某个 agent 已经阻塞在等我，而我并不知道。

重叠检查：同一区域，只有一个方向

主 agent 之间看不到彼此的上下文。

重叠指两个 agent 都在修改或决策的同一区域：一个模块、一份文档或设计决策记录（ADR）、一个接口约定、一个 PR、一次部署。编排 agent 按语义而不只是按路径匹配，比如 services/foo 和 docs/spec/foo 属于同一区域。

发现重叠后，编排 agent 同时通知双方。任何一方再次修改这个区域之前，双方都必须了解对方的计划并达成一致。

以下情况不算重叠：

主 agent 和它自己的子 agent，它们共享同一份任务说明；
只读或只做评审的 agent；
一方的改动已经合并。

24 小时内已经通知过、之后又没有新改动的组合，不再重复通知。

示例：两个前端 PR 改了同样的文件

项目 B 和项目 E 在同一个前端仓库里开发各自的应用。

前一天，编排 agent 首次通知双方仓库里的共享部分（组件库、模拟后端、接口约定），双方约定了各自可以修改哪些共享文件。
10:11，项目 E 的一个 PR 修改了开发指南和 lock 文件，排在下一个合并；项目 B 新开的骨架 PR 也改了这两个文件。编排 agent 的判断是：方向一致（是不同的应用），但后合并的一方会冲突。它通知了双方，并记录下这一组合。
10:12，两个 agent 直接沟通，约定 E 先合并、B 随后 rebase，并各自写入状态文件。
10:16，E 的 PR 合并，部署到开发环境。
10:36，B 完成 rebase：开发指南保留了双方的改动，lock 文件没有变化，类型检查、lint、测试和构建全部通过。

整个过程没有找我。我的报告里只多了一行：“已通知……方向一致”。

发给项目 B 的通知大致如下，项目 E 收到的是立场对调的版本：

重叠检查（来自编排 agent）：你和项目 E 都在修改前端仓库的共享文件：开发指南和 lock 文件。
- 你：骨架 PR 修改了这两个文件。
- 对方：一个 PR 也修改了这两个文件，即将合并。
- 判断：方向一致（不同的应用），但后合并的 PR 会冲突。
再次修改之前，先用一条消息说明你的计划，读对方的回复，约定由谁 rebase，并把约定写入状态文件。
如果无法达成一致，或者这个选择应该由人来做，就停止修改这些文件，并在回复里说明。

最后一句是关键：谈不拢的冲突，或者本该由我做的决定，不会被两个 agent 私下处理。相关工作会暂停，作为“需要你处理的冲突”进入我的报告。

待处理检查：什么算“需要我”

重叠检查之后，编排 agent 逐一判断每个 agent 是否在等我。关键在于把“需要我”定义清楚：定义太宽，报告充满噪音，我很快就会忽略它；定义太窄，真正阻塞的 agent 会被漏掉。

需要我：

阻塞在审批或提问对话框上。报告会引用对话框原文。
最后一条回复要求我决策、选择或执行某个操作，且尚未得到答复。被权限检查拒绝的操作也算。
报告了自己无法修复的失败。
主机异常：磁盘剩余不足 30 GiB，或 Docker 无响应。所有 agent 的构建和端到端测试都依赖它们。
负责交接的监视进程超过 10 分钟没有轮询。

不需要我：

在等同事审批或等 CI，归入“等待中”。
agent 输入框里的文字。那是我还没发送的输入或建议，不是提问。
已经通过转达的答复解决了的问题。

不需要我的 agent，各自只出现在一行里：工作中、等待中或空闲。空闲的 agent 会注明最近的工作领域，方便我决定是分配新任务还是关闭它。

报告

报告的结构是固定的：先是重叠，然后是需要我的事，最后工作中、等待中、空闲各一行。下面是某天上午的一份，名称已经替换：

重叠：没有需要你处理的冲突。已通知：前端仓库的开发指南和 lock 文件（项目 B ↔ 项目 E，方向一致）。

需要你：
1. 项目 B（新应用骨架）：为前端仓库开通一个内部 npm 包的读取权限。
2. 项目 A（性能）：将一个服务降到 1 vCPU 的基础设施变更，保留还是关闭？

工作中：项目 B 的实现 agent（应用骨架）；项目 C 的小组 c（16 个端到端场景）
等待中：项目 C 的小组 a（审批 1/2）；项目 D（审批 1/2）
空闲：  杂务（Docker 和磁盘清理）；一次测试覆盖审查
主机：  剩余 313 GiB，Docker 正常

几秒钟就能读完，然后我回到自己的工作。

当天上午的三次提醒

09:45 Docker 停止运行，项目 C 的小组 c 无法执行 16 个端到端场景，主 agent 弹出对话框询问。我选择“启动 Docker”，编排 agent 启动后回复了对话框。场景执行完毕，小组 c 提交了 PR。
09:53 项目 B 需要一个只能由我在 GitHub 网页上完成的操作：为前端仓库开通一个内部包的读取权限。完成后，编排 agent 转达“已完成”，项目 B 随即开始第一个前端 PR。
09:53 项目 A 测完早上启动时的突发负载，询问一个将服务降到 1 vCPU 的基础设施变更是保留还是关闭。我回复“保留并开始”，几分钟后它提交了 PR，Terraform plan 里只有预期的变更。

如果没有编排 agent，Docker 停止运行这件事，要等我想起去看项目 C 时才会发现。

注意力只留给决策

这套做法的重点不在 agent 的数量，而在注意力的分配：

方向和取舍只有我能定，所以我和主 agent 深度对话；
“谁在等我”“谁和谁冲突”可以明确定义、定期检查，所以交给编排 agent；
两层结构保证每个 agent 的产出都有掌握上下文的主 agent 验收。

agent 可以并行运行很多个，做决策的人只有一个。把这个人的注意力留给决策，其余的交给流程。

日本的 IT 落后吗？

Wed, 04 Nov 2026 00:00:00 GMT

常有人说日本的 IT 落后。我的回答是：是，也不是。

不缺优秀的工程师

日本工程师对 IT 业界的贡献并不小。QR 码是 Denso Wave 的原昌宏主持开发、1994 年发布的；Ruby 是松本行弘在 1995 年发布的；软件开发里的 Lean 和看板，也源自丰田生产方式。日本从来不缺优秀的工程师。

当然，这些例子说明不了平均水平。我认为日本 IT 工程师的平均水平确实不如美国和中国，这和大学教育有很大关系：软件工程这门学科在日本的普及和重视都不够。但我觉得重点不在这里。美国也有不少工程师是从别的专业转行过来的，专业出身并没有挡住他们。

重点是公司的结构

真正的问题是，公司的结构没有跟上时代。

这一点从数据上也看得出来。根据 IPA（信息处理推进机构）的统计，2020 年日本的 IT 人才有 73.6% 在 IT 企业工作，在其他行业公司里的只有约四分之一；美国正好相反，2021 年在 IT 企业的只有 35.1%，大多数在使用 IT 的其他行业公司里。也就是说，很多日本公司自己没有工程团队，系统交给 SIer 去做，常常还要层层外包。做决定的人离写代码的人很远，工程师也很难影响产品本身。

2026 年 11 月 2 日，GMO 互联网集团就旗下「お名前.com デスクトップクラウド」的非法访问事件召开记者会。攻击者从客户使用的远程桌面服务器入手，盗取了管理员账号；集团旗下的安全公司早在 2024 年就指出过系统的问题。但让我印象最深的不是这个安全失误本身，而是会上的一幕：负责人开始向记者说明情况时，集团代表打断了他，指责他西装的扣子没有扣上：“在道歉的场合，怎么能开着扣子？”

很难想象 Satya Nadella 或者 Elon Musk 会因为扣子打断下属，无论是在公开场合还是私下。大多数人大概也会觉得这很荒唐，可当事人显然不觉得有什么问题。在我看来，这正是很多日本 IT 公司落后的原因：严格的、以权力为中心的层级，和软件工程需要的开放、平等的环境是不相容的。

我说的层级不是工作上的汇报关系。微软和 Amazon 当然也有层级和汇报线，但那是按工作内容的分工，不是命令的层级。在那里，很多项目是自下而上诞生的；在日本公司，这种自下而上的传导很少见。根本原因是否和日本的社会、文化有关，超出了这篇文章的范围，这里不展开。可以确定的是，在强权力层级的环境里，复杂的软件工程很难展开。

理性的讨论，以及通过讨论检验知识，都需要平等的环境。Google 的 Project Aristotle 研究了 180 个团队，发现在这些团队里，决定团队效能的五个因素中，最重要的是心理安全感：成员相信，在团队里承认错误、提出问题或者新想法，不会被嘲笑或惩罚。多样性同样重要：《哈佛商业评论》上的一篇文章总结过相关研究，多元的团队更关注事实，更常重新检查事实，犯的事实错误也更少。这些正是很多日本公司缺少的。

领导者懂不懂技术

另一个区别是团队的领导者是否熟悉技术。在日本的 IT 公司里，项目经理（PM）往往处在层级的上游。美国和中国的 IT 公司不一样。在微软，我看到很多 PM（program manager）想转成写代码的工程师，却很少有工程师想转成 PM；team manager 大多也是工程师出身。

怎样理解责任

还有一点是对责任的理解。在很多日本公司里，做决策时一个重要的考虑是：这样做能不能让组织免于担责。“如果我这样做了，出了问题就不用担责任。”这可以理解，但在美国的 IT 公司里，我很少感受到这样的决策因素。

日本擅长什么

反过来看日本的强项。文化产业里，个人的贡献影响很大；重工业，比如汽车，看重团队对规则的严谨执行。软件工程需要的却是第三种东西：平等的讨论和快速的迭代。

日本 IT 业也有个人和小团队的创新。比如 Preferred Networks 开发的深度学习框架 Chainer，2015 年提出了 define-by-run 的写法，这种思路后来被深度学习研究界广泛采用。但整体要进步，团队的观念需要更新。

日本 IT 企业应该怎么做

第一，向美国顶尖的科技公司学习，组建自己的工程师团队，减少外包。系统是公司的核心能力，不应该全部交给别人。工程师在公司内部，才能离业务和产品更近，也才能对结果负责。

第二，积极吸纳海外的高技术人才，而且要明白：花高薪请来的聪明人，不是为了告诉对方该怎么做，而是为了让对方告诉我们该怎么做。

第三，也是最重要的：拥抱开放、平等的职场环境，弱化以权力为中心的层级。在职场上只关注工作本身，而不是像 GMO 集团代表那样，在道歉的记者会上关注扣子这类无关紧要的事。

第四，让懂技术的人做技术决策。给工程师一条和管理岗平行的晋升路线，让资深工程师不必转去做管理，也能得到相应的职级和待遇；技术团队的负责人，最好也是工程师出身。

第五，出了问题，复盘时不追究个人。Google 的 SRE 实践里有一条叫 blameless postmortem：复盘只找导致事故的原因，不指责任何个人或团队，并且假设每个人都是出于好意、用当时掌握的信息做了正确的事。要修的是系统和流程，不是人。大家不再害怕担责，决策才会回到“怎样做最好”，而不是“怎样做最不会出错”。

我写这些不是为了指责，而是想指出可以改进的地方。