AI insight

用 AI 做会议纪要，本质上在做什么？

把一个小时的会议录音，变成一份文字摘要。以前要半小时，现在十分钟。确实快了。 但你有没有想过 —— 这份会议纪要，是给谁看的？怎么用的？

大概率是这样的：发到群里，你扫一眼，记住几个关键点，其他的全忘了。下次开会，大家又从头开始对齐，“上次说到哪了？那个问题有没有跟进？”

信息经过了人类的眼睛、大脑这个极度低带宽的通道，从一个丰富的多维度文档，退化成了你脑子里残存的十分之一。然后再退化，再退化。

AI 在这里做了什么？它替代的，是原来的助理、书记员、秘书。省的是记录的时间成本。

但组织协调的根本问题，一点没变。

真正的 AI 化，是组织共享一个被持续维护的事实库

你们有没有一个关于某个项目的 “总文档”，每次开完会，这个项目的进展、决策、待跟进事项，会自动更新进去？下次开会，大家是基于这个文档来开，还是靠各自脑子里的残存记忆来开？

如果是后者，那不管你们用了多少 AI 工具，本质上还是 1985 年波音工程间的状态 —— 每个人都有 CAD，但图还是打印出来开会。

真正的 AI 化不是每人一份会议纪要，而是整个组织共享一个被持续维护的事实库。会议是一个更新这个事实库的节点，不是一个独立的、被总结然后被遗忘的事件。

当 AI 真的接管了信息共享这一层，开会就会变成另一个样子：每个人只接收和自己相关的那部分，异步同步信息，只有真正有分歧的地方才需要大家坐在一起

• LLM 驱动开发的魅力在于它理应消除摩擦。拥护者们编造着开发团队一天内交付数十个功能的故事，他们指挥着多个自主运行的智能体团队，以越来越奇特的拓扑结构协同工作。我理解，软件开发有时确实繁琐且令人沮丧。能够以相对惊人的速度产出代码，并摆弄那些打磨精美的产品而非原型，这种感觉一定令人无比兴奋。

• 不过我需要这种摩擦。

• 当我初次学习一门新语言或框架时，即使是最基本的任务也会让我感到举步维艰。这感觉糟透了！而当我面对一个陌生且不熟悉的代码仓库或数据源时，我需要花上几个小时仔细审视。我常常会进行细致的研读，调出特定文件逐行查看，直到理解它们的上下文以及开发者做出的选择。我知道我可以直接让 LLM 帮我总结项目来节省时间，但我发现我需要这个过程来真正沉浸到代码中。我需要的不只是理解开发者做了哪些选择，更是理解他们为何做出这些选择，以及这些选择如何体现所用语言的约束或惯用法。我在失败中学习，如果 LLM 替我完成了这部分工作，我就无法真正理解自己在做什么。

• 如果编写提示词的工程师缺乏判断好坏的能力，他们就会陷入反复让 AI 硬编码来消除摩擦的循环。这可能导致一团混乱的抽象层，而留给未来团队的唯一设计文档，只是一份为几年前使用的 AI 模型写的 Markdown 指令。

• 也许我不使用 LLMs 的最简单原因就是，我实在是太热爱编程了，以至于我不想把它交给机器。就像如果我是艺术家或音乐家，我不会求助于 AI 一样，编程是我表达创造力的一种方式，我不会放弃这种快乐。尽管有时会极其令人沮丧，但从一个模糊的想法塑造出一个真实的系统，尤其是涉及优雅的实现或有趣的问题时，会带来深沉的喜悦。有些晚上，我合上工作笔记本，打开个人笔记本，去探索一些我想构建的有趣新东西。

• 编程也一直是我在困难时期的慰藉。有研究表明，玩俄罗斯方块是避免创伤后应激障碍的有效方法。其理论依据是，调动大脑中负责排列和旋转形状的部分，会妨碍创伤记忆的形成。幸运的是，我没有患 PTSD（我也并非轻视那些受其困扰的人），但确实能理解这一概念。编程就像解复杂的谜题，有时是我黑暗时刻的慰藉。