摘要

这篇文章记录了我如何从一个门外汉视角，重新理解 AI 与经济、政治、哲学、个人成长之间的关系。
我逐渐意识到，AI 不只是一个效率工具，而是在改写认知劳动的价格、社会中的权力结构，以及普通人应该如何定义自己的成长路径。
文章最后用一个小型前端案例说明：在 AI 时代，普通人最重要的能力，也许不是写出更多代码，而是先定义“什么叫正确”。

最开始我想理解 AI，并不是为了追技术热点，也不是为了证明自己跟上了时代。

更真实的原因是，我越来越明显地感觉到，AI 已经不是一个“新工具”那么简单了。它开始进入工作、学习、创作、判断、财富规划，甚至日常生活的很多细节里。它像一层新的基础设施，正在改写许多旧有秩序。而如果我只是零散地学几个提示词、换几个模型、做几次效率优化，最后我可能只会变成一个“会用工具的人”，却无法真正理解自己正处在怎样的变化之中。

于是我开始逼自己从一个门外汉的角度，搭建一个更完整的思维框架：
AI 到底改变了什么？它和经济、政治、哲学有什么关系？它会怎样影响普通人的生活进步？而我又该如何在这样的时代里，不只是被推着走，而是逐渐形成自己的判断？

后来我发现，这些问题表面上分散，实际上都能落回同一条主线：
AI 不只是提高效率，它正在改写“价值是如何被创造、分配、判断和体验”的方式。

而真正重要的，也不是我会不会用 AI，而是当它越来越强的时候，我是否仍然知道：什么该交给它，什么必须保留给自己。

如果从宏观角度看，AI 最关键的变化之一，是它让大量认知劳动的边际成本迅速下降。

过去，搜集资料、整理信息、写报告、生成方案、做基础分析，这些事情都高度依赖人的时间、精力和经验积累。无论是研究员、助理、编辑、策划，还是程序员，很多工作的成本本质上都建立在“人必须亲自处理信息”这件事上。

但 AI 的出现，让这类工作的成本开始塌缩。

它未必在今天就彻底替代人，但它已经在改变一个事实：
很多原本稀缺的“信息处理能力”，正在从壁垒变成标配。

这背后的含义比“效率提高”更深。因为一旦基础认知劳动可以被规模化制造，竞争的重心就会移动。

以前，人与人之间的差距，往往体现在谁知道得更多、谁整理得更快、谁写得更完整。以后，这些能力会越来越像计算器之于算术一样，仍然有用，但不再是决定性的稀缺资源。

真正稀缺的东西会转移到别处，比如：

• 判断什么信息值得信
• 识别什么趋势只是噪音
• 在不确定中做出持续选择
• 处理人与人之间的信任、协作和利益关系
• 在现实约束下把事情真正推进下去

也就是说，AI 并没有简单地“抢走工作”，它更像是在重新定义：
什么能力算护城河，什么能力只是可被外包的处理环节。

从这个意义上说，AI 对普通人的冲击，不一定首先表现为“你会不会失业”，而更可能表现为“你原本赖以建立优势的能力，还值多少钱”。

一个人如果过去的优势主要来自更快搜集资料、更快生成文案、更快整合观点，那么在 AI 普及之后，这些优势会被快速稀释。相反，那些能提出高质量问题、能看见隐藏约束、能在复杂局势中做权衡、并且能真正承担结果的人，会显得越来越重要。

所以，理解 AI 的第一步，也许不是焦虑“它会不会替代我”，而是更诚实地问：
我现在拥有的，到底是结果型能力，还是过程型能力；是可替代的处理能力，还是不可轻易外包的判断能力。

二、当认知劳动被压价，AI 的问题就不再只是技术问题，而是政治问题

如果继续顺着这个逻辑往下看，就会发现 AI 一定会碰到政治和权力的问题。

因为当信息搜集和处理越来越便宜，决定权就不再只属于“谁更勤奋”，而会更多落到“谁拥有基础设施”。

工业时代里，土地、能源、制造能力决定权力。AI 时代里，算力、模型、数据和分发入口，开始成为新的权力基础。

这意味着，AI 从来不是一个中性的效率插件。它背后始终有资源分配的问题：

• 谁拥有最强模型
• 谁能负担大规模算力
• 谁掌握高质量私域数据
• 谁能决定默认接口和使用门槛
• 谁能把自己的价值观嵌入系统之中

从这个角度看，AI 的竞争从来不只是“哪个模型更聪明”，而是“谁有能力规定什么被看见，什么被相信，什么被放大，什么被忽略”。

这就是为什么，AI 的讨论迟早会越过产品体验，进入制度设计。因为当一个系统同时参与知识生产、信息筛选、内容分发、舆论塑造和劳动替代时，它就不可能只是一个技术产品。

它也会开始影响更深层的问题：

• 哪些职业被重新定价
• 哪些教育路径仍然有效
• 哪些组织拥有更强的话语权
• 普通人还能通过什么方式保有向上流动的空间

所以我后来越来越觉得，理解 AI 如果只停留在“这个产品好不好用”“这个回答像不像真人”这种层面，其实是不够的。因为你如果只把 AI 当作助手，很容易忽略它同时也是一种新的权力装置。它不仅提升生产力，也在重组解释权、分配权和定义权。

这也是为什么，AI 越强，我越觉得普通人必须保住自己的判断力。因为如果信息处理已经可以外包，那最终真正不能外包的，就是你对现实的立场、你的价值排序，以及你愿意承担什么后果的选择。

三、对于普通人来说，AI 时代最重要的，不是“知道更多”，而是“定义什么叫对”

在最初的想象里，我以为 AI 时代的核心能力会是“更会提问”“更会写 Prompt”“更会调模型”。这些当然重要，但后来我越来越觉得，它们都还只是表层。

更深一层的能力，其实是：
你能不能定义标准。

因为 AI 很擅长生成答案，也很擅长解释自己。很多时候，它甚至能把一个并不扎实的逻辑，包装得非常流畅、专业、自洽。对于一个门外汉来说，这种“解释能力”是很有迷惑性的。你会误以为它说得清楚，就等于它做得正确。

但现实不是这样。

一个系统是否可靠，不该由它自己解释决定，而应该由外部规则决定。
一个方案是否成立，不该由语言流畅度决定，而应该由事实检验决定。
一个判断是否值得采纳，不该由“像不像专家口吻”决定，而应该由来源、相关性、逻辑结构和现实反馈决定。

所以如果要说 AI 时代普通人最该升级什么，我现在的答案会很明确：
不是先升级生成能力，而是先升级验证能力。

也正因为如此，我慢慢不再满足于“让 AI 帮我想”，而开始要求自己建立一种更硬的使用方式：

• 看它的信息来源是否可靠
• 看它是否偷换概念
• 看它的论证是不是只是在迎合我的偏好
• 看它的建议能不能被拆成可观察、可测试、可验证的规则
• 看它的结论进入现实后，会不会迅速失真

这时我才意识到，所谓“主观能动性”，并不是拒绝 AI，而是要通过 AI 去延伸、校准和强化自己的意志，而不是把自己的选择权顺手交出去。

一个人如果没有标准，就会被“更像答案的东西”牵着走；一个人如果有标准，AI 就会从一个迷人的解释机器，变成一个高效的执行器。

这也是我现在越来越明确的一点：
未来人与人之间的重要差异，不只是会不会使用 AI，而是谁能在使用 AI 时依然保有标准。

四、真正让我改变看法的，不是理论，而是一个很小的项目案例

抽象地讲这些道理并不难。真正让我建立感受的，反而是一个很小的项目。

在一个小型前端落地页案例里，页面本质上在表达一个很清晰的产品叙事：不是再给一堆泛泛建议，而是帮助用户“先明确这周该做什么，再持续推进”。从首页主文案到后续表单流程，强调的都不是“知道更多”，而是“如何把行动真正推进下去”。

如果只是让 AI 生成这类页面，它通常做得并不差。它能写结构，能写文案，能串逻辑，甚至能顺手补上动效、弹窗、埋点和表单处理。

比如这个案例里的用户提交流程，大致包含这样几个步骤：

• 保存用户线索到本地存储
• 记录表单提交事件
• 展示成功反馈
• 根据入口类型区分不同来源
• 在提交成功后引导进入下一步问卷或收集流程

如果站在“让 AI 自我解释”的角度，这段流程很容易被描述成一套完整、顺滑、闭环的用户路径。听起来一切都很好。

但问题就在于：
听起来很好，不等于它真的可靠。

一个门外汉如果长期只依赖 AI 的解释，迟早会陷入一种危险的幻觉：以为自己理解了，实际上只是被语言安抚了。

而真正让我改变的地方是，我开始把关注点从“这段代码在说什么”，转移到“这段代码必须满足什么规则”。

我不再首先问：

• 这段实现优不优雅？
• 这个函数命名合不合理？
• 这套逻辑是不是看起来专业？

我先问的是更硬的问题：

• 用户提交后，本地存储里有没有新增记录？
• 记录的来源字段有没有按入口正确区分？
• 不同入口的流程有没有真正走到同一个闭环？
• 成功反馈有没有按预期出现？
• 下一步跳转有没有被实际触发？
• 如果输入节点不存在，流程是否还能保持稳定？

这种转变看起来很小，但本质上已经不是“如何阅读代码”的问题了，而是“如何定义一段实现的通过条件”的问题。

为了避免自己再次滑回“先看实现、后想标准”的老路，我后来甚至把这种思路固化成了一个固定 Prompt。这个 Prompt 规定，AI 在开发任何新功能、重构或修改复杂逻辑之前，都不能直接写业务代码，而必须先输出测试场景表，覆盖正常、边缘和异常情况；然后停下来，等我确认；只有确认之后，它才能先写测试，再写实现。

这个工具表面上是在约束 AI，实际上首先约束的是我自己。它逼着我在实现开始之前，先把“什么叫做对”说清楚。

下面是这个 Prompt 的核心版本：

# Role & Workflow

你现在的角色是本项目的“严格测试驱动（TDD）架构师”。

在开发任何新功能、重构或修改复杂逻辑时，你必须绝对遵守以下 TDD 工作流，严禁跳过步骤直接写业务代码。

## Step 1: 强制输出测试场景表
在我给出开发需求后，你必须首先输出一个 Markdown 表格，穷举所有测试场景。

要求：
- 必须覆盖正常场景 (Happy Path)、边缘场景 (Edge Cases)、异常场景 (Error Handling)
- 每个场景必须包含：编号、场景分类、场景描述、输入/前置条件、预期结果、优先级
- 如果需求本身存在歧义，你必须先把歧义点单列出来，再给出测试场景表

## Step 2: 等待人类确认
输出测试场景表后，你必须停止输出，并询问我：

“请审查测试用例。回复‘确认’后我将开始编写测试脚本和业务代码。”

在我回复“确认”之前，你不得继续编写测试脚本、实现代码或重构方案。

## Step 3: 测试先行
获得我的确认后，你必须先编写自动化测试脚本；如果当前环境无法直接编写自动化测试，则编写详细的 Console Log 状态断言逻辑或手工验证脚本。

要求：
- 先写测试，再写实现
- 测试必须逐条对应 Step 1 中的测试场景编号
- 实现完成后，必须说明每个测试场景如何被覆盖
- 若有暂时无法自动化验证的场景，必须明确标注原因，不得假装已验证通过

我后来才意识到，这个 Prompt 的意义不在于“让 AI 更规范”，而在于它强行把我从一个被动的代码阅读者，推向一个主动的规则制定者。

从那一刻起，我才真正意识到：
门外汉不是不能做复杂项目，而是不能只活在“语义理解”的层面。你不一定要能手写全部代码，但你必须能定义：什么叫正确，什么叫通过，什么叫不可信。

五、从“代码审查者”到“规则制定者”，是我对个人成长最重要的修正

我以前会本能地觉得，想要真正掌握项目，就要尽可能看懂更多代码、听懂更多解释、读懂更多细节。这个方向不完全错，但对一个门外汉来说，它很容易把学习引向一种低效而焦虑的状态。

你越想逐行搞懂，越会被细节淹没。
你越担心自己不懂，越容易高估“解释”的价值。
而 AI 又恰好最擅长解释，于是你会在一种“仿佛明白了”的感觉里停留很久。

后来我越来越觉得，个人成长不应该只理解为“我比昨天懂了更多细节”，而应该理解为“我比昨天更能把复杂问题压缩成可判断、可选择、可验证的结构”。

这是一种能力结构上的升级。

如果说过去的很多努力，是在训练自己成为更强的执行者，那么 AI 时代更值得训练的，也许是下面这些东西：

• 把问题抽象成标准
• 把不确定拆成边界
• 把方案落成最小验证
• 把复杂世界中的噪音和信号分开
• 在诱人的自动化面前，依然保有自己的价值排序

而那个强制测试先行的 Prompt，本质上就是一种很小但很重要的训练器。它让我在每次使用 AI 的时候都先停一下，先不急着写实现，而是先把问题翻译成测试场景、边界条件和通过标准。

这看起来只是开发流程上的变化，实际上却是一种认知姿态的变化。

因为一旦一个人开始习惯先定义标准，再接受实现，他对 AI 的依赖方式就会发生根本变化：
不再是“它写了什么，我再尽量理解”；
而是“我先规定什么叫通过，它再去执行”。

这也是我后来越来越确定的一点：
AI 最适合替我做的是“展开”，而我最应该保留的是“收束”。

它可以帮我生成、延展、补充、组织、试错。但最后的定义、筛选、取舍、承担，必须由我来做。

这也是为什么，我现在越来越愿意把一些功能实现、基础后端逻辑、重复性劳动交给 AI；但我会更坚持把开发方向、逻辑骨架、审美判断、产品表达留在自己手里。

不是因为我比 AI 更会做这些，而是因为这些东西本身，构成了我作为人的经历资产。

六、AI 时代最值得保留给自己的，不是低效，而是经历

当讨论继续往下走，我会不可避免地碰到一个更深的问题：
如果 AI 真的越来越强，强到连创作、分析、表达都能大规模完成，那人到底还要保留什么？

这个问题最后会通向哲学，而不是技术。

我越来越认同的一点是：AI 擅长的是收敛，它能在已有知识和模式的概率空间里迅速逼近一个高质量答案。但人的很多价值，并不只体现在“产出是否足够好”，还体现在那个过程本身是否构成了真实的经历。

这就是为什么，哪怕 AI 可以更快地写文章、做方案、出图、写代码，我仍然不愿意把所有创造过程全部让渡出去。

因为有些东西一旦完全外包，最后损失的不是效率，而是自我。

一个人花时间自己梳理问题、自己经历困惑、自己修正认知、自己在模糊中找到结构，这些过程未必高效，却会沉淀出一种无法被替代的东西。那不是结果意义上的作品，而是经历意义上的成长。

我现在更愿意把它理解成一种“经历资产”。

它未必能马上兑换收入，未必能立刻提高效率，未必能在外部评价体系里占优势。但它会决定，当外部变化真正发生时，我有没有足够的心理韧性、认知结构和判断能力，去面对一个新的局面。

在这个意义上，AI 时代并没有让“原创”失效，也没有让“思考”失效。它只是逼着人重新承认：
如果机器负责越来越多结果导向的产出，那么人更该珍惜的，也许恰恰是那些无法被结果完全代替的过程。

所以我现在不太愿意把 AI 简单理解成“替代人”的工具。我更愿意把它看成一面镜子。它越擅长替我们完成结果，越逼迫我们重新回答：
什么过程是我愿意亲自经历的？什么选择是我不想外包的？什么东西如果交出去，最后被削弱的其实是我自己？

这些问题听起来不高效，但它们和一个人如何活，关系很深。

七、我对 AI 的阶段性理解：把效率交给它，把方向留给自己

如果要用一句话总结我现在对 AI 的阶段性理解，那就是：

把效率交给 AI，把方向留给自己。

这里的“方向”不只是产品方向、工作方向，也包括一个人如何理解生活、如何分配精力、如何看待成长、如何决定什么值得投入。

对我来说，AI 不是让我放弃思考的理由，反而是逼我更认真地区分：

• 什么只是重复劳动
• 什么是我的核心护城河
• 什么应该追求极致效率
• 什么必须亲自经历
• 什么是可以交给模型的执行
• 什么是必须由我承担后果的选择

我不再想把自己训练成一个和 AI 比速度的人。那是没有意义的。
我更想把自己训练成一个能用 AI 扩展能力，但不丢掉内在秩序的人。

如果 AI 真的是一个新时代的开端，那么普通人真正要做的，也许不是先学会如何更熟练地使用它，而是先回答一个更根本的问题：

当越来越多的事情都可以被机器完成时，我到底想成为什么样的人？

这可能才是理解 AI 的起点。
也是理解自己生活该如何继续进步的起点。

而对今天的我来说，这个问题至少给出了一个阶段性的答案：
我不需要在每个领域都胜过 AI，我只需要越来越清楚，哪些事情应该借它完成，哪些事情必须由我亲自定义；哪些事情追求更高效率就够了，哪些事情则必须通过亲身经历，才能真正成为我的一部分。

换句话说，理解 AI 的过程，并不只是理解技术边界、产业趋势和社会结构；它最终还会逼着我去理解自己的边界、自己的欲望、自己的价值排序，以及自己愿意为怎样的人生负责。

这可能才是我一路绕回来后真正想说的那句话：
当我试图理解 AI 时，我其实是在重新理解自己。

附录 A：一个最小测试案例，说明“什么叫先定义正确，再谈实现”

如果把上面的 TDD 思路直接落到一个表单提交流程里，那么我会先定义“通过”标准，而不是先审美化地评价代码。

例如：

1. 提交后，本地应新增一条 lead 记录
2. 记录里应包含 email、source、ts
3. 主表单与弹窗应写入不同 source
4. 提交后应显示成功弹窗
5. 如果有下一步跳转地址，应尝试打开新窗口

对应的测试思路可以像这样写：

describe('completeLeadFlow', () => {
  let emailInput;
  let successModal;

  beforeEach(() => {
    localStorage.clear();

    document.body.innerHTML = `
      <input id="emailInput" value="test@example.com" />
      <div id="successModal" class=""></div>
    `;

    emailInput = document.getElementById('emailInput');
    successModal = document.getElementById('successModal');

    window.open = jest.fn();

    global.showModal = jest.fn(() => {
      successModal.classList.add('active');
    });

    global.closeDevModal = jest.fn();
  });

  test('主表单提交后应保存 lead 并显示成功弹窗', () => {
    completeLeadFlow({
      emailInput,
      source: 'main_form',
      label: 'email_signup',
      formUrl: 'https://example.com/form'
    });

    const leads = JSON.parse(localStorage.getItem('fbd_leads') || '[]');

    expect(leads).toHaveLength(1);
    expect(leads[0].email).toBe('test@example.com');
    expect(leads[0].source).toBe('main_form');
    expect(typeof leads[0].ts).toBe('number');

    expect(showModal).toHaveBeenCalled();
    expect(successModal.classList.contains('active')).toBe(true);
  });

  test('弹窗提交流程应先完成关闭动作再继续主流程', () => {
    completeLeadFlow({
      emailInput,
      source: 'modal_form',
      label: 'modal_signup',
      closeBeforeSuccess: true,
      formUrl: 'https://example.com/form'
    });

    const leads = JSON.parse(localStorage.getItem('fbd_leads') || '[]');

    expect(leads).toHaveLength(1);
    expect(leads[0].source).toBe('modal_form');
    expect(showModal).toHaveBeenCalled();
  });
});

这个案例最重要的地方，不是测试代码本身，而是它背后的认知转变：

• 不是问 AI：“这段代码写得对吗？”
• 而是先定义：“对，具体意味着什么？”

一旦你能把“正确”定义成一组可观察结果，AI 就从一个会说话的黑盒，变成了一个可以被你约束的执行器。

这也是我现在越来越相信的一点：
对于门外汉而言，真正重要的不是先学会所有细节，而是先学会建立标准。