AI 赋能，不是 1 -> 2 -> 3，而是 1 + 2 + 3

AI 赋能，不是 1 -> 2 -> 3，而是 1 + 2 + 3

这是我的一周随笔。

核心观点：AI 时代的生产力提升不是线性的替代关系（1→2→3），而是能力的叠加（1+2+3）。人负责架构、方向、验证；AI 负责实现、细节、扩展。只有掌握各阶段能力，才能实现指数级的效率增长。

起因

大模型时代，自己搭建博客的成本更低了。大模型存在规模效应，量变引起质变。我也相信时间的复利。

一、AI 的定位与局限

AI 没有目的，这是最大的缺陷

AI 拥有丰富的世界知识，能够帮助个人成长。但深度使用 AI 后，我发现：你必须站在一个和 AI 差不多的高度后，才能让 AI 帮助你不断地成长。你必须知道你要做什么，知道关键词，AI 才能够帮助你。

AI 和人最大的区别：AI 没有目的，而人为了生存有目的。AI 比 99% 的人知识都要广都要强了，但是它并没有改变世界。AI 的缺陷就是不知道自己想要什么。

如果把人类身上那些看似"神秘"的能力，一条条拆掉、外包、模拟、工程化——到底哪一条是"不可删的"？

这个想法很惊艳我，就是把可复制的能力一层层外包掉。如果把模型也放到"人类这个运行环境"里，那它还缺什么？有没有一个"最后的、无法外包的承担者"？

Taste 越来越重要

大模型越来越强，taste（品味/判断力）越来越重要。这就是人的目的之一——判断什么是有价值的。

二、人机协作模式

Show, Don't Tell

教学，show 比 tell 来得更好。LLM prompt engineering 同样适用。

Context is All You Need

Garbage In, Garbage Out。上下文质量决定了 AI 输出的质量。

分层协作：人负责架构，AI 负责实现

UI 只是数据的投影，数据才是本质。

AI 用来辅助需求理解和方案设计。新项目的正确流程：

  1. 自己先搭脚手架：定好模型等核心架构
  2. 有了骨架限制后：再对具体的小函数或组件使用 Vibe Coding
  3. 避免的陷阱：Vibe Coding 倾向于"把功能跑通就行"。在复杂项目中，这会导致代码缺乏抽象，充满了重复和硬编码，导致后期维护成本指数级上升。

核心原则：把实现部分外包给 AI，但是架构和验证必须自己来。

大模型辅助设计的分层

大模型辅助设计的时候，让大模型：

  1. 头脑风暴
  2. 收敛为需求
  3. 方案设计
  4. 收敛为代码

这也是大模型使用的分层。

正确的 AI 辅助开发流程

一开始他们也试过偷懒，直接扔一句"这是功能需求，这是相关文件，你去实现"。结果代码能跑，但歪得厉害，完全不符合架构预期。

后来他们改了流程。任何复杂功能，第一步不是让 AI 写代码，而是让 AI 先理解系统。比如让它读一组相关文件，总结数据是怎么从 API 流到 Repository 再到 ViewModel 最后到 UI 的。然后人来纠正它的理解。

理解对了，再让 AI 出一份实现计划，像个迷你设计文档。哪些文件要改，要引入什么新状态，逻辑怎么流转。人确认计划没问题，AI 才开始动手。

所以 spec-kit 也是，描述需求之后，要先 review 一遍大模型的复述。

Prompt as Scripts

Prompt as scripts。把提示词当作脚本，可以复用和版本化。

模仿思维模型

和大模型对话，发现一个大模型的绝佳用法：让大模型模仿人或者某种思维模型分析问题。

Few-shot 学习降低成本

在实际应用中，用户可以通过 Few-shot 学习的方式，来提升模型的输出效果。所谓 Few-shot 学习，是指在请求中提供一些示例，让模型学习到特定的模式。由于 Few-shot 一般提供相同的上下文前缀，在硬盘缓存的加持下，Few-shot 的费用显著降低。

交叉验证

使用 AI，最好做一下交叉验证。

选择 AI 擅长的技术栈

根据 AI 的原理，使用 AI 生成前，调研 AI 擅长的开源技术栈来构建，出错概率更低，因为训练的材料多。

工作流优化

工作流不能打断。以后基于验证通过的工作流能够加速 AI，目的就是能够让 AI 顺滑地在舒适区执行。

AI 工具对比

充值了 Gemini 和 GPT 会员，写文章的这个月，我觉得从对话角度讲，Gemini 比 GPT 好很多。GPT 太空太泛了，很消耗认知精力。而且 Gemini 了解我的信息，存储为长期记忆更准确。

三、思维与方法论

双系统理论

这直接对应了丹尼尔·卡尼曼的《思考，快与慢》。

  • 系统 1 (快思考)：直觉、潜意识、情绪化。比如看到老虎就跑，看到"2+2"就喊"4"。这是省能模式。
  • 系统 2 (慢思考)：逻辑、推演、计算。比如算"17 x 24"，或者规划职业生涯。这是耗能模式。

了解自己：

  • 为什么我们经常做后悔的决定？因为我们在该用"系统 2"的时候，偷懒用了"系统 1"。
  • "写下来"不仅仅是记录，而是思考本身。AI 界的发现证明了：语言不是思维的包装，语言就是思维的脚手架。当你心里乱糟糟的时候，强制自己拿笔写下来（哪怕只是碎碎念），其实是强制大脑启动 System 2，通过线性的文字整理网状的思维。

策略学习与世界模型

策略学习，在世界中学习。意识就是知道我是我，知道我的决策会改变了我可行动的空间。必须在世界中学习，学习有方向性。这是我和 AI 的区别。

跟大模型很像，思维模型和非思维模型，可能你忘了某个东西，但是如果你继续输入，输入变了，说不定就能检索到相关的。——这就是 prompt engineering 技巧。

新学习的思维模型

这周学习的新概念：长尾效应、双钻模型、精益画布、格式塔心理学、多元思维模型。

四、实践与洞察

工具选型判断

使用工具前判断工具的前景，个人和团队技术选型都是。

技术细节积累

负载均衡、一致性 hash，这是一次 SSE 请求会中断时学习到的。负载均衡可能把两次请求打到两个后端服务实例，就会出现这个问题。

职业角色变化

以后就存在两种岗位：

  • 产品工程师（产品经理 + 工程师）
  • 云工程师（后端服务 + 云）

老板拿我当 agent 使，没错，这就是 agent。

技术成本降低

AI 有了，技术的成本进一步降低，现在营销和分销渠道的专家，是很难得的。

从知识的广度讲

从知识的广度讲，从原理理解，LLM 确实会取代搜索引擎。

克制与复杂性

克制，能减少复杂性就减少复杂性，复杂性是 MVP 的敌人。但是要考虑架构设计，所以要内化架构。

避免技术膨胀错觉

我自己都有一种技术膨胀错觉，总是觉得技术等于用户，但是不关注真实用户体验。一定要始终提醒自己。

快速失败，快速学习

想了好久自己实现 web mcp server，最后发现已经有人有非常完整的设计了。https://docs.mcp-b.ai/concepts/architecture

而且要知道要快点丢掉我曾经自己做过的，知道承认自己是个缓慢的失败者然后认清，然后赶紧学习项目，继续开发。

人的不可替代性

接到线上 bug，赶紧打开一个个文档，找需求文档和技术方案。有惊无险地解决完，最后一个个关掉 tab，好爽。

AI 永远替代不了人。人要背锅。

Coding 的瓶颈

Coding 的瓶颈是我不知道怎么准确清楚地描述需求为 LLM 理解的语言，另一个瓶颈是审核与人精力的瓶颈。

数据资产的重要性

后人再追大模型就很难了，首先数据就是问题。现在一起起步，所以没有差距。后续清理的数据就是资产，再后面就是增量，但是新公司是全量，所以现在就要抢占。

信息密度的变化

纯文本到 AG-ui 等，很像终端到多媒体，但没这么夸张。多的信息用来做渲染了，信息密度降低了。

写文档的新考虑

写文档不仅得考虑自己，还得考虑 AI 了。害，我的一人公司小员工。

书签管理策略

书签管理应该放弃长尾内容。太复杂了，入口层级很深，不一定能找到。只要考虑使用频率很高的方便。

总结

这一周的思考，让我对 AI 时代的生产力提升有了更清晰的认识。

不是 1 → 2 → 3，而是 1 + 2 + 3

这不是线性的替代关系，不是让 AI 直接替代我们完成工作。而是能力的叠加：

  • 1 是人的架构能力：理解问题、设计方案、判断方向、承担责任
  • 2 是 AI 的实现能力：快速编码、生成内容、提供方案、扩展细节
  • 3 是验证反馈循环：review 输出、迭代优化、积累经验、形成工作流

只有掌握这三个阶段，才能实现指数级的效率增长。

我们需要做的：

  1. 理解 AI 的局限：AI 没有目的，人必须提供方向和品味
  2. 掌握协作模式：架构和验证由人主导，实现和细节由 AI 辅助
  3. 运用正确的方法：双系统思考、思维模型、工作流优化
  4. 保持人的价值：判断力、责任感、创造性，这些都是 AI 无法替代的

AI 越强，人越要强。这不是威胁，而是机遇。