AI时代最值得学的技能：从手写代码到驾驭编程智能体

当「氛围编程」（vibe coding）让一个人能在周末做出一个可演示的产品时，程序员的核心竞争力到底还剩下什么？在 B 站广泛传播的一期访谈中，拥有约十年手写代码经验的开发者 Matt（aihero.dev 创始人）给出了一个反直觉的答案：真正稀缺的不是写代码的速度，而是把意图清晰传达给智能体、并为它们搭建良好运行环境的能力。

转折点：从怀疑到"不再手写一行代码"

Matt 坦言自己长期是 AI 编程的怀疑者。他有约十年业余加八年职业的编码经历，在很长一段时间里认为大模型写代码"只是又一个泡沫"。真正的转折发生在他所称的某个模型能力跃升节点之后——从那时起，他开始相信"我再也不会自己写一行代码"。

这个判断的背后不是对模型的盲目乐观，而是他发现自己职业生涯中真正擅长的事——帮助同事、改善团队的工作环境、把经验传递给他人——恰好可以迁移到智能体身上。当模型足够强，这些"软技能"开始直接转化为产出。

据他在访谈中给出的数据，如今他同时运行四个智能体处理不同项目的长期任务，GitHub 上每天推送的提交量达到 200 到 300 次，而手写代码时期"一天 20 次就算不错"。他自己也承认这种差距"完全不可比"。

核心论点：代码库就是智能体的工作环境

整期访谈最有价值的部分，是 Matt 对"环境决定产出"的反复强调。他用一个形象的比喻：如果让一只狗坐在着火的房子里，它不可能表现出正常行为。同理，把一个强大的模型放进一个从未被认真维护、只追求输出结果的"垃圾代码库"里，得到的只能是垃圾结果。

他提出的思维实验是：假设你管理着一百名人类程序员，你会用什么策略来提高"最差那位程序员"的下限？软件工程领域为此积累了几十年的答案——写好测试、增加检查点、阻止整类 bug 的发生、让代码库随时间推移越来越容易修改。这些书"读起来像是上周才写的"，因为它们讨论的正是当下智能体开发最需要的东西。

这也解释了为什么他坚持认为软件工程基础在 AI 时代"更重要而非更不重要"。非技术背景的人同样可以受益：关键不在于你是否能亲手写代码，而在于你是否愿意关心代码库的质量，并学会用工程原则去约束智能体的行为。

软件工程中的“下限”概念指的是通过工程实践确保即使团队中最缺乏经验的成员也不会产出灾难性代码。常见手段包括：自动化测试（尤其是单元测试和集成测试）作为安全网，代码审查（Code Review）阻止明显错误，静态分析工具（如 linter）在提交前捕获常见缺陷，以及持续集成（CI）在合并前验证变更。这些实践的核心逻辑是“预防优于修复”——通过约束和检查点阻止整类 bug 的发生，而不是依赖个人能力。在 AI 智能体场景下，同样的逻辑适用：智能体的输出质量高度依赖环境中的反馈信号和约束条件。一个拥有完善测试覆盖和清晰模块边界的代码库，能让智能体在修改代码时快速获得“对/错”信号，从而自我纠正；反之，缺乏测试和文档的代码库会让智能体在黑暗中摸索，错误不断累积。因此，软件工程基础在 AI 时代不是过时了，而是从“对人”的约束转变为“对智能体”的约束，其重要性不降反升。

沟通才是真正的护城河

Matt 反复提到一个被低估的事实：人与智能体之间的沟通障碍，远比人们想象的大。模型再聪明，也不知道你在意什么，除非你一遍又一遍地告诉它。因此他设计了名为 Grill Me 的技能——让智能体反过来对用户进行"无情采访"，把需求、边界、隐性偏好全部逼问出来。

他引用《程序员修炼之道》中的一句话：没有人确切知道自己想要什么。所谓"未知的未知"——安全、部署方式、你根本没想到的细节——如果不主动暴露，智能体就会自行编造，最终产出与你设想完全不同的东西。

在观察自己的学员时，他发现表现最顶尖的人无一例外都是极佳的沟通者：他们提交代码变更时会写清晰详尽的说明，思路的清晰度直接体现在产品里。反过来，产出差的人往往不是技术不行，而是无法向智能体说清问题，也无法描述哪里出了错。用他的话说，思考的质量和语言的质量是关键——不仅是对客户说话时，也是对智能体转述客户需求时。

他还引入领域驱动设计（DDD）中的"通用语言"概念：代码里的术语、数据库里的字段、界面上的文案、你和客户交谈时的用词，应该是同一套。他甚至为此改造出 Grill with Docs 技能，帮助用户在开发过程中逐步建立这套领域语言。

领域驱动设计（DDD）中的“通用语言”（Ubiquitous Language） 是 Eric Evans 在《领域驱动设计》一书中提出的核心实践。其要点是：开发团队与领域专家（业务方）必须共同构建一套严谨、无歧义的术语体系，并确保这套语言在代码、数据库、界面、文档和日常沟通中保持一致。例如，在电商系统中，“订单”不应在代码里叫 Order、在数据库里叫 purchase_record、在界面上叫“购物单”——这种不一致会导致理解偏差和实现错误。在 AI 辅助开发中，通用语言的意义被放大：智能体没有隐含的领域知识，它完全依赖你提供的词汇和上下文来理解需求。如果你在提示词、代码命名和文档中使用同一套精确术语，智能体就能更准确地推断意图；反之，术语混乱会让智能体“自行编造”含义，产出偏离预期。Matt 的 Grill with Docs 技能正是为了在对话中逐步固化这套语言，让智能体在后续任务中有一致的参照系。

一次失败实验：规格驱动开发为何没走通

访谈中 Matt 难得地分享了一段挫败经历。受"规格即新代码"这一流行观点影响，他曾试图把自己最珍视的项目——一个带 AI 写文案、设计封面等功能的定制视频编辑器——整理成一份庞大的规格文档，再让智能体据此生成代码。

结果持续了数月都不理想：代码越改越糟，智能体的产出也越来越差。他最终放弃规格、把注意力转回代码本身，因为他意识到代码才是智能体真正运行的环境，而"好代码"的定义是——容易修改、改一处不会破坏别处。转向这个目标后，他才感觉"开始真正有进展"。

这段经历对当下流行的规格驱动开发框架是一个有价值的反向证据：规格文档不是万能药，可维护的代码环境才是根基。

规格驱动开发（Spec-Driven Development） 是近年来伴随 AI 编程兴起的一种方法论，主张先编写详尽、形式化的规格文档（描述功能、接口、数据流、边界条件等），再让智能体依据规格生成代码。其吸引力在于将“意图”与“实现”分离，理论上允许非技术人员通过规格驱动开发。然而，Matt 的失败实验揭示了该方法的局限：规格文档容易变得庞大且难以维护，且无法完全捕捉代码库中的隐式约束（如性能特征、模块耦合、第三方依赖行为）。更重要的是，规格与代码之间存在“语义鸿沟”——智能体在生成代码时仍需做大量解释和假设，而这些假设往往与规格的初衷偏离。当代码库本身质量低下时，规格再详细也无法阻止智能体在糟糕的环境中产出糟糕的代码。因此，规格驱动开发更适合作为辅助手段（如用于澄清需求），而非替代可维护代码库的根基。当前一些框架（如 GitHub 的 Spec Kit）试图通过工具化降低规格维护成本，但核心挑战依然存在。

给非技术者的路径：先学会踩刹车

对于"全职工作、非技术背景、想用 AI 改变职业轨迹"的人，Matt 的建议是先想清楚哪些技能在未来有用，路径自然会浮现。他认为智能体存在被严重低估的学习曲线——模型变强并不会消除这条曲线，只是把它藏得更深。需要掌握的问题包括：什么能信任、如何组织多个智能体、如何控制它们接收的信息、如何把流程转化为智能体可执行的形态。

他引用 Lauren Tan 提出的"信任阶梯"：学开车时先学的是刹车而不是油门。刚开始应该盯着智能体的一举一动，理解它的每个动作和工具链提供的每项能力，再逐步扩展到两个智能体、编写自定义技能、接入 Slack、Gmail 等数据源。他自己就有一个处理待办事项的智能体：对着手表口述，系统接收后由智能体分诊归类。

他还给出一个与主流叙事相反的观点：不要让模型去做你最宏大的任务，而是交给它最枯燥、最琐碎的工作——起草回复、处理杂事。理由是这类任务容易衡量输出质量、出错也容易纠正，而这正是当前 AI 最能稳定创造价值的地方。

“信任阶梯”（Trust Ladder） 是 Lauren Tan 提出的一个渐进式采用框架，用于描述人类如何逐步将控制权交给自动化系统。其核心思想是：信任不能一步到位，必须通过可验证的小步骤积累。阶梯的典型层级包括：（1）观察——完全手动操作，理解系统每个动作；（2）辅助——系统建议，人类决策；（3）监督——系统执行，人类抽查；（4）委托——系统自主执行，人类仅处理异常；（5）完全自治——系统端到端负责，人类设定目标。在 AI 智能体场景中，这意味着用户应从“盯着智能体每一步”开始，逐步扩展到多智能体协作、自定义技能和外部数据源集成。每一级都需要建立相应的检查点和回滚机制（如版本控制、测试套件），确保错误可被发现和纠正。Matt 强调“先学刹车”正是这个道理：没有安全网的速度是危险的，而信任阶梯提供了一条结构化的路径。

落地建议：环境优先于模型选择

在被问到最喜欢的工具链时，Matt 的回答出人意料地"不卷"：他用 Claude Code 搭配某个 Opus 版本，并且刻意使用比多数人更低的推理强度，因为在他已经把智能体运行环境"抬高下限"之后，模型不需要那么费力就能写出通过测试的代码，低强度反而带来更好的 token 效率和响应速度。

他更愿意把精力投在环境建设上。举例来说，他的视频编辑器依赖本地运行的 OBS 等第三方组件，此前智能体无法真正启动并点击测试这个应用。当他解决了这个问题、让智能体能够截图并实际运行应用后，产出质量出现了大幅提升——他相信即便换回更老的模型，效果也会接近。

这种思路对普通开发者的启示是：与其追逐每一次模型发布和跑分榜单，不如先把测试、可运行性、可观测性这些基础设施补上。模型和工具链固然重要，但回报率最高的投入往往在环境一侧。

下一步：软件工厂与长期主义智能体

Matt 自称是"老师而非预言家"，他拒绝大多数产品预览邀请，因为他只关心"现在能不能用起来"。谈到未来，他最兴奋的是"软件工厂"——能够自主发起工作、持续改进代码库的自动化体系。

他认为当前智能体的一大短板是不擅长从长期角度思考代码库，他想要的是那种"讨人厌但正确"的资深开发者：坚持做对的事而非快的事，为后来者考虑。如何组织大量智能体协同工作，至今没有令他信服的方案，这正是他眼中最大的空白与机会。同时他也期待开源模型追平顶级闭源模型，因为"我不需要模型强到离谱，一个够用且高效的开放模型就很好"。

所有这些判断最终回到同一个朴素的结论：在人人都有能力快速造东西的时代，能脱颖而出的是最会沟通、最懂得为智能体营造环境、并且愿意从枯燥任务开始一步步建立信任的人。