当 AI 开始承担执行工作，人还需要负责什么？

这是一篇比较杂乱，内容未经整理的文章。想到什么就往上写什么了。

认知转变

在 GPT-3.5 刚横空出世时，我把它理解为一本掌握了大量人类通识知识的百科全书，也将它视作新时代的搜索引擎。那时候，大模型的产品形态大多还是一个对话框。人们发现，在许多日常问题上向它提问，无论准确度还是效率，体验都比当时的百度或者论坛好太多了，而且没有烦人的广告。

很多人觉得，有了大模型之后，谣言难以澄清的现状将会被打破。不过我恰恰认为，当大家都开始使用 LLM 检索信息之后，辟谣的成本可能反而更高了。

那时，我认为 LLM 即使学习了大量人类已有的文献和知识，它依然是人类经验的集合，本质上仍然是文本续写，无法脱离训练语料的限制。越偏门的知识，在语料中所占的比重越低，模型也越不容易给出正确答案。

因此，对于编程这类高度依赖具体应用场景、项目上下文和私有开发资料的工作，我一直保持着较大的怀疑。

当时还没有成熟的 AI Coding 工具，只有一些 IDE 插件能够借助 LSP 做小范围、相对简单的编码工作，大规模代码生成尚未流行。

真正让我转变看法的，是一次复杂项目的开发任务。

简单地说，它是一个智能化的工作流编排系统：用户通过 AI 对话描述需求，前端以 function calling 的方式向模型提供工作流编排能力，再由后端 Agent 负责调度和执行。那时也正是 ReAct Agent 逐渐兴起的阶段。

这个项目很有意思。一方面，Agent 接入了大量项目私有知识，当时主要通过 RAG 提供；另一方面，我也近距离实现了复杂场景下的 function calling 调度。这些机制扩展了 Agent 的能力边界，也在一定程度上缓解了幻觉问题。

同时，由于项目工期紧张，我开始大量使用 AI Coding 提高编程效率。虽然当时只做了一些相对简单的代码审查，但最终效果仍然相当不错，至少比完全手动敲代码快了许多。

这也是我正式脱离“古法编程”、迈向“蒸汽时代”的开始。

后来，越来越多面向 AI 时代的编程工具出现，我也逐渐从敲键盘写代码，变成了敲键盘对话。

这不禁让人思考：为什么一个本质上仍在进行文本续写的大模型，能够做这么多事情？

下面是我个人的一些发散性思考。

1. 是智能催生了语言，还是语言本身就是智能的表现？

大模型学习了大量人类知识后，表现出了某种逻辑推理能力。这是很有趣的一点：模型基于海量经验，通过文本续写的方式，也能够回答训练材料中未必直接出现过的具体问题。

我曾经问过大模型一些可能不会有第二个人以完全相同方式提出的情景题，它给出的答案仍然是正确的。这至少说明，它并非只能机械复述已有文本，而是能够结合上下文，对已有经验进行组合和推演。

至于这种表现能否被称为真正的“推理”，以及自注意力机制在其中究竟扮演了什么角色，可能仍然值得讨论。

而人类的智能到底是什么？在某些时刻，我们自己的思考过程似乎也像是在逐字“生成”语言，最后组成一个完整的想法。那么，究竟是智能产生了语言，还是语言本身就是智能的一种表现？

2. 编程一定困难吗？

这个问题乍一看，答案似乎是肯定的。从大学开始，我身边就有很多人最终没有走上开发道路，其中一个常见原因就是觉得编程太难。

但事实一定如此吗？可能也不见得。

编程语言虽然不是自然语言的简单子集，却可以被自然语言描述。几乎一切能够用编程语言表达的意图，也都能先用自然语言说明。区别在于，编程语言具有更严格的语法、语义和执行约束，而自然语言允许模糊和省略。

从这个角度来看，LLM 能够胜任一部分编程工作并不令人意外。它擅长理解自然语言，也学习了大量代码和技术资料，再配合执行环境、工具和测试反馈，就可以逐渐把一个模糊的自然语言目标转化为可运行的程序。

3. 在效率面前，质量一定最重要吗？

质量当然重要，但在一些低风险、生命周期较短的场景下，质量可以适当地向效率妥协。

例如，前端工程中可能存在一些短期活动页面、快速原型或一次性展示内容。对于这些内容来说，继续提高代码质量带来的收益，未必能覆盖开发成本，而效率提升产生的价值可能更加明显。

况且，令人有些扎心的是：在具备明确约束和验证机制的情况下，大模型输出的代码质量未必比手写代码差，有时甚至可能更好。

问题因此不再是“质量是否重要”，而是：在什么场景下，需要哪一种质量，以及我们愿意为它付出多少成本。

AI 与工作

在我看来，AI 应用的工程关注点大致经历了这样一条变化路径：

                                **Prompt 工程 → Context 工程 → Harness 工程**

这并不是三个相互取代的严格阶段，而是在不断深入使用和应用 AI 时，为了解决不同层次的问题逐渐形成的方法。

最开始是 Prompt 工程。大模型刚登上舞台时，对输入内容和表达方式非常敏感。即使目标相同，使用不同的描述方式，也可能产生质量差异很大的结果。于是，人们开始设计和固化 Prompt 模板，希望提高输出的稳定性。

但 Prompt 显然不能解决所有问题。进入实际项目后，输入内容会不断变化，前后多轮对话需要保持关联，知识量也可能大到无法一次性提供。于是，检索、记忆、知识库、Skill 等机制逐渐出现。Context 工程所关心的，就是如何在有限的上下文中，为模型提供当前任务真正需要的信息。

即使有了这些机制，大模型仍然可能出错。在质量要求较高的场景中，结果没有达到标准，本身就是一种错误。

于是，工程关注点继续向 Harness 延伸：除了向模型提供信息，还要为它提供清晰的目标、工具、运行环境和反馈机制，持续监控执行过程，在发现错误后进行纠正，使结果逐渐收敛到一个可以接受的质量水平。

这种变化不仅发生在 AI 应用的运行阶段，也发生在软件开发过程中。

通过 AI 完成开发工作是会上瘾的。一旦体验过，就很难再回到过去的方式。

这是一种非常特别的体验，像是神兵天降、机械飞升，真正拥有了“三头六臂”。以前做不到的事情，或者完全不了解、无从下手的领域，在大模型帮助下也能够开始尝试，而且速度比完全依靠自己敲键盘快了太多。理论上，它甚至可以持续运行，不受人的作息限制。

IT 开发本身是一种创造性工作：先确定目标、设计路线，再一点点填海造陆。在大模型的帮助下，尝试一个想法并把它落地的成本大幅降低了。

从我自己的工作感受来看，具体编码在全部工作中的占比已经逐渐降低，甚至很少需要亲自参与。更多时间被分配给了架构讨论、技术方案设计、实现路径选择，以及思考与 AI 协作时还存在哪些问题。

细节正在逐渐从工作中淡化，宏观结构则成为我思考更多的内容。我不确定这是否完全是一件好事。

常规软件开发中，确实存在大量重复性的细节工作。但与此同时，也有一小部分棘手问题，只有真正参与解决，才能积累对应的经验。

例如，在开发公共库时，一些基于语言特性的巧妙实现，可能同时改善库的体积和性能。如果长期不再接触这些细节，我们也可能错过积累这类经验的机会。甚至在某一天，当某个细节问题超出了 AI 的解决能力时，开发工作可能因此停滞，例如一些深入的性能优化问题。

思考碎片

1. 权衡的艺术

LLM 的输出带有概率性，而传统信息系统通常追求可复现、可验证的确定性。将两者结合形成 AI Agent 应用，就需要同时处理这两种看似矛盾的属性：既不能约束得过死，也不能任由结果过度发散而无法收敛。

如果过于确定，产品就可能变成一个传统程序，只是在外面套了一层 Agent 调用；如果过于不确定，Agent 又可能无法稳定解决问题，最终失去实际意义。

从目前的经验来看，传统程序更适合承担底层基座和确定性的基础能力；AI Agent 则更适合承担部分或全局规划、任务串联，以及处理不断变化的外部交互，尤其是人机交互。

但 Agent 自身的设计同样需要大量确定性机制，例如意图识别、路由分发和 function calling 的接口设计。总体而言，我们仍然需要花费大量精力设计这些确定性部分。每个 AI Agent 都必须结合具体应用场景，解决对应细分领域的问题。

带有主观性的问题往往更难解决。例如在 PPT 生成应用中，美观程度和布局自由度都很难通过单一标准衡量，用户通常还希望得到个性化结果。

为了缓解这些问题，我们可能需要提供主题色配置、元素碰撞检测、大量模板参考，或者使用基于 HTML/CSS 的前端渲染环境来辅助生成和展示。这些措施会牺牲一部分个性化能力，是一次个性化与稳定性之间的权衡。

但在工程上，这种权衡通常是值得的：稳定、合格的产出，往往比偶尔出现一次的高质量结果更值得优先解决。

2. 不同岗位在当前的差异与变化

可以简单地将常见软件开发团队中的成员分为产品、设计、开发和测试。这里暂时不讨论运维，而是看看这些角色在 AI 时代各自依赖的能力发生了什么变化。

对于产品人员而言，重要能力在于熟悉业务，对产品的应用场景和所在行业有深入理解，并据此判断什么样的产品形态符合发展需要。

产品承担着方向指引的责任。如果完全由 AI 代替这部分工作，可能带来难以控制的风险。

不过，并非所有方向都必须由人独立决定。例如产品缺陷发现、改进建议和用户行为分析等场景，就很适合借助 AI 的能力，这也会消解一部分原有的产品工作。

对于美术与 UI/UX 设计人员而言，重要能力是对视觉和体验的整体把控。这并不是一件简单的事情，因为设计具有较强的主观性，通常还伴随着团队内部的大量讨论和反复修订。

对于品牌化要求较高的产品，团队往往希望设计具有很强的辨识度和个性化特征，这仍然是大模型相对薄弱的部分。此外，一款产品的 UI/UX 设计通常需要形成完整体系。

“体系化”与“个性化”的组合，意味着设计中存在大量细密且相互关联的规则，而当前让 AI 长时间稳定遵守这类规则仍然比较困难。

不过，对于常规软件开发，AI 已经具备使用和设计通用样式的能力。毕竟，市场上直接使用开源 UI 组件库的软件也数不胜数，尤其是在 B2B 业务中。

对于开发人员而言，很多人认为他们受到的冲击最大，因为 AI 在软件开发领域展现出的能力非常直观，似乎任何人都可以借助 AI 开始一段软件开发之旅。

我认为，其中一个重要原因是：程序通常具有相对明确的输入、输出和验收方式。只要愿意投入足够的算力、时间和反馈，让 AI 不断生成、运行和修正，就有很大机会得到一个能够运行的版本，无论实现过程优雅还是狼狈。

目前，很多 AI Coding 工作流都开始依赖测试或其他可执行的验收标准。有些采用 TDD，有些则是在实现过程中持续运行已有测试，通过反馈确保程序能够运转。

这种方式非常适合 AI 时代的快速迭代，也能高效推动任务目标达成，但仍然存在几个需要考虑的问题：

1. 测试容易让 Agent 陷入局部视角。所有局部任务顺利完成，并不代表总体问题得到了妥善解决。
2. 验收标准的制定非常重要，却又很容易被忽视。
3. 部分场景很难由 AI 自动验收，例如视觉表现等带有主观性的内容。

我认为，开发与设计所处的境况有些相似：简单、局部的任务，AI 已经能够完成；复杂且需要形成完整体系的任务，仅凭 AI 仍然很难解决。

开发人员具备程序设计能力，了解技术及其生态，也拥有长期积累的编码和调试经验。AI 工具剥离了大量繁重、枯燥的编码工作，让开发人员可以把更多精力投入架构和程序设计。

但这些工作仍然需要经验。它和产品人员需要业务与行业经验、设计人员需要审美和设计经验是相似的。经验决定了角色之间的差异，也决定了一个人是否具备判断工作的品味，能否正确指引 AI，以及能否借助 AI 产出真正有价值的内容。

举一个具体的例子：一名产品人员想开发某个网站，于是开始不断与 AI 对话，最终得到一个包含几千甚至上万行代码的 HTML 文件。

他不了解技术栈及其生态，也不了解程序设计。这份 HTML 虽然满足了当前需求，但在下一次功能迭代或者与其他系统合并时，因为长期积累的问题而变得难以维护。

后来，他吸取了教训，在一次次实践中逐渐理解 HTML、CSS、JavaScript 分别是什么，Vue、React 这类现代 UI 框架解决了什么问题，如何 Debug，以及怎样划分代码模块才能让自己和 AI 更容易阅读。

到这个时候，我认为他已经不仅仅是一名产品人员了。开发经验赋予了他一部分开发者的角色，或者说，他此时就是一名开发者。

当然，这个过程并不容易，因为它本身就是开发人员曾经走过的学习之路。

从更宏观的角度看，岗位之间的差异，是否本来就主要来自知识、经验与能力？一个人具备了这些条件，是否就可以承担相应岗位的角色？

当前岗位边界的扩张，可能在很大程度上是因为一些边缘业务并不需要非常深入的知识和经验，而 AI 恰好补齐了一部分能力缺口，使人们感觉自己的边界被拓宽了，与其他岗位之间的界线也开始模糊。

例如，前端和后端能够逐渐合并为“全栈”，本身就是因为它们的一部分能力基础相似。AI 又能在人们探索新边界时，快速帮助其增长知识和积累经验，从而进一步缩小岗位之间的距离。

这像是一个循环：为了提升效率，社会分工将人们划分为不同岗位；而 AI 带来的生产力提升，又开始模糊这些岗位之间的差异。

最后是测试人员。在软件开发领域，我认为这一角色也可能受到很大的冲击。

随着开发流程越来越依赖测试和可执行验收标准，开发、产品乃至设计人员都可以在前期设计阶段，参与产出对应的测试用例。与此同时，自动生成测试用例的成本也在持续降低。

未来，测试人员的工作重心可能更多转向评估测试覆盖情况、评审测试和验收标准、审查自动化测试，以及识别工具难以发现的业务风险，而不是投入大量时间重复执行测试。

完善且可靠的自动化测试，通常会更加稳定、经济和高效。但自动生成测试并不等于自动获得质量：测试什么、为什么测试，以及什么结果才算真正正确，仍然需要人来判断。

最后

它带来的变化不只是写代码更快，也在改变工作的重心：人开始减少直接执行，把更多精力放在定义目标、提供上下文、设计约束、验证结果和作出判断上。

AI 模糊了岗位之间的边界，却没有让知识和经验失去价值。恰恰相反，当执行成本不断下降，如何提出正确的问题、建立合理的体系，并判断结果是否真正有价值，可能会变得更加重要。