AI 时代，我们是在写代码，还是在“写知识”？—— 极客时间 8x 课程笔记

本文是极客时间 8x 课程的读书笔记。我本想取名 G8 (Geekbang 8x)，但听起来不太对劲，所以就有了现在这个标题。

“软件的价值，最终由其承载的知识决定。代码，只是这些知识的可执行形态。”

引言：从“构建者”到“知识工程师”的身份转变

我们习惯于将软件开发看作一种“建造”活动，谈论“构建”软件、“编写”代码。

但随着 AI 大语言模型（LLM）的普及，我们或许需要换个角度审视自己的工作。

如果说编码是软件开发的“最后一公里”，那在此之前的需求讨论、架构设计和技术选型，又是什么呢？

这些过程，更像是一种知识的传递、提炼与组织。

本文想探讨一个观点：在 AI 时代，软件工程的核心正从“构造软件”转向“管理知识”。

这一转变，对我们的日常工作意味着什么？

一、软件：一种可执行的知识

让我们暂时抛开代码，思考软件的本质。

• 软件是知识的载体：真正的“产品”，是软件中蕴含的业务逻辑、领域规则和架构决策。代码只是这些知识的最终表现形式。
• 软件是知识的“可执行”形态：它让抽象的知识能够在现实世界中产生具体影响。
• 软件开发的核心，是知识的获取、学习与传递：编码只是这一漫长知识旅程的最终环节。

代码是最终产物，但真正的价值在于其背后的业务逻辑、领域规则和架构决策。这些才是软件的核心“知识”。

LLM：认知杠杆，而非认知替代

LLM 在这个新范式中扮演什么角色？它是一个强大的认知杠杆，极大地提升了知识转化为代码的效率，但它并未替代人类的认知过程。

• 人的认知水平是协作的上限：人与 LLM 协作的最终产出质量，取决于人对问题的理解深度和判断力。
• LLM 的核心能力是基于上下文的理解与生成：通过提供精准的上下文，我们可以将其“调教”为特定领域的辅助专家。
• LLM 存在固有技术限制：
  • 上下文与 Token 限制，使其难以一次性处理庞杂的系统。
  • “幻觉”现象，意味着其产出需要严格验证。

因此，将 LLM 视为无所不能的“代码生成器”是一种误解。

它的真正价值在于成为知识传递链条中的高效“处理器”，而我们则需要成为高效的“知识管理者”。

二、知识工程：一种新的工作模式

如果软件开发是知识工作，我们该如何实践？

知识工程，可以理解为：将软件开发视为一个“提取、组织知识，使其能被 LLM 理解，并最终通过 LLM 将这些知识转化为可工作软件”的完整过程。

这里的关键瓶颈，不再是编码速度，而是知识传递的效率与保真度。

1. 知识与任务分离：与 LLM 精准对话

与 LLM 交互时，清晰地分离**知识（背景信息）与任务（具体指令）**至关重要。这能帮助 LLM 建立正确的上下文，形成明确的关注点。

例如，与其直接说“写一个登录函数”，不如先提供知识：

• 知识（Context）：“系统使用 JWT 认证，密码采用 bcrypt 加密，用户信息存储在 users 表中。”
• 任务（Task）：“基于以上信息，编写一个 login(username, password) 函数，验证成功后返回 JWT。”

有趣的是，敏捷开发中的用户故事（User Story），恰好是一种优秀的知识管理工具。它天然地侧重于定义问题（“我是谁”、“我想要什么”、“为什么”），而非预设解决方案，这使其成为向 LLM 传递需求的理想形式。

2. 通过反馈迭代：提炼隐性知识

知识工程并非单向传递，而是一个双向的、迭代的探索过程。

通过 LLM 的反馈来反思并修正我们对知识的描述，是知识工程的核心循环。

这个过程的本质，是消除误解、对齐思路。它的最终目标是**“校准人”的理解**，而非仅仅“修复代码”。当 LLM 对你的描述产生“误解”时，或许我们首先要反思的是，自己对知识的表达是否足够清晰、准确。

3. 驾驭不同类型的知识

软件开发涉及的知识远非单一类型，我们必须学会驾驭它们：

• 显式知识（Explicit Knowledge）：能够被清晰表达、记录和传播的”know-what”，如技术文档、业务规则。
• 隐式知识（Implicit Knowledge）：尚未被记录，但可以通过交流和文档化转为显式知识。
• 默会知识（Tacit Knowledge）：这是最宝贵也最难处理的部分。它是个人经验、直觉、技能的核心，是难以形式化的”know-how”。例如，一位资深架构师在众多方案中做出权衡的直觉，或是一位高级工程师对代码“坏味道”的敏锐嗅觉。定义问题通常比解决问题更难，而对问题的敏锐感知，正是默会知识的体现。

为何同样的技术文档（显式知识）在不同人手中，会产生天壤之别的实现？

为何有经验的工程师能在看似平静的代码中，直觉性地感知到潜在的设计缺陷？

这些都体现了默会知识的核心价值。

三、研发流程重塑：从代码管理到知识管理

在新范式下，现有研发流程需要重构为以知识为中心的管理过程，其核心目标是从流程中捕获关键知识，并通过 LLM 有效沉淀。

围绕“默会知识”的传递来构建流程，是实现知识工程的关键。

1. 应用与提取“默会知识”

• 应用知识：对于成熟的、有明确解决方案的问题（例如，为新项目搭建 CI/CD 流水线），我们可以通过提示词模板对成熟的任务流程进行建模，高效应用那些已被充分学习的默会知识。
• 提取知识：默会知识的提取，本质上是**提炼“思维链”（Chain of Thought, CoT）**的过程。通过鼓励 LLM 解释其推理过程，我们可以反向形式化那些隐性的专家经验。RAG（检索增强生成）等模式，同样有助于新知识的学习与提取。

2. 应对认知偏差：先对齐思路，再写代码

认知偏差是团队协作中的巨大障碍：不同成员对同一问题可能持有完全不同的假设和理解，导致共识难以形成。

这种分歧的后果是：团队难以形成统一共识，讨论陷入循环，新人培养周期延长，系统设计出现不一致，引入大量隐蔽的质量缺陷。我们是否曾困惑，为何同样的技术讨论，有些团队能迅速聚焦并达成一致，而有些团队却在表面问题上争论不休？认知偏差往往是根源。

知识工程强调先对齐思路，再动手编码。

• 推行任务审查（Task Review）：将审查的重心从代码（Code Review）上移至任务本身，在编码前，就通过讨论、文档或图表，确保团队对“做什么”和“为什么做”达成一致。
• 建立认知行为基线：管理者应着力于建立团队统一的认知与行为基线，确保对问题的理解和处理方式有一致的标准。

3. 混乱中的清醒：及时止损

当个体或团队对问题感到混乱（Chaotic）——即无法理解问题、被恐慌驱动而盲目行动时，任何试图“解决”问题的努力都可能加剧混乱。

此时，理性地及时止损，暂停行动，回归问题的澄清与理解，是避免大量返工的明智选择。

四、任务划分与质量内建：新范式下的交付关键

1. 任务划分：与 LLM 协作的“接口”

由于 LLM 的技术限制，需求必须被分解为足够小的、原子化的任务，才能转化为高质量的提示词。这个过程并非随意的拆分，而需同时兼顾软件架构与测试策略。

可测试性（Testability）是进程内架构最重要的属性之一。一个好的任务划分，本身就应该导向一个易于测试的实现。

2. 质量控制优先于生成效率

在 LLM 辅助开发中，我们的精力分配需要发生根本转变：将更多精力投入质量控制，而非一味追求生成效率。

反馈循环的瓶颈在于如何高效验证 LLM 生成结果的正确性与有效性。因此，我们必须大力倡导**内建质量（Build Quality In）**的理念，通过测试驱动（TDD/BDD）来提炼需要给予 LLM 的精准反馈，而非仅仅依赖于编码后的手动调试。

我们应当转变思维，从”如何修复 LLM 生成的错误代码”到”如何设计流程，使 LLM 更容易生成正确代码”。

当我们过于关注生成速度时，往往因大量调试修复而降低总体效率；而当我们专注于质量时，整体进度反而可能加快。

这是否意味着，在 AI 时代，“慢即是快”可能成为新的工程法则？

五、工程师的转型：从“编码者”到“知识工程师”

这场范式转型，最终将重塑工程师的核心价值。

• 角色转变：从专注于编码实现的**“编码者”（Coder），转向侧重于知识管理、任务分解与验证的“知识工程师”（Knowledge Engineer）。对纯粹编码技能的要求或许会降低，但对知识提炼、系统思考、质量保障**等能力的要求将显著提升。

  技能重组正在发生：

  • 知识提炼能力：从复杂、模糊的业务需求中提取清晰、结构化的知识。
  • 系统性思考：在碎片化任务中保持整体视角，确保局部解决方案符合全局最优。
  • 元认知水平：对自身思考过程的觉察、监控与调整能力。
  • 跨学科整合：将技术、业务、用户体验等多维度知识有机融合。

• 核心价值：工程师的核心价值，在于为 LLM 提供足够丰富且精准的上下文信息——这包括功能需求、业务知识、架构决策、测试策略等一切关乎“生产正确代码”的关键信息。

我们的关注点，正从“如何构造软件”，历史性地转向**“如何提取和组织知识，让知识变成 LLM 能够理解的形式”**。

从这个角度看，“提示词工程”的本质，是如何精准地组织与表达知识。

因此，“知识工程”，或许是一个更合理、也更深刻的名称。

结语

AI 时代的软件开发，核心挑战从编码转向了知识管理。掌握好知识提炼、任务分解和质量控制这些技能，将是工程师适应新环境的关键。