# 「清楚的模糊」：AI 写完八成代码之后，人还剩什么？人和 AI 的能力边界到底在哪里？
学弟发来一句话。
> 没有当时和哥学快排那种对代码逻辑的掌控感了。
他过年的时候用 vibecoding 做了一个项目。里面流程贼多，跑一遍要调用五六个模型、四五十次。然而过了一段时间后，再打开那个仓库，他记不住任何一环在干什么。
我回他：正常，未来都这样，八成的代码会用 AI 来写。
这句话是真的。但我回答的不是他的问题。他问的是「**我还剩什么**」，我答的是「**你少了什么**」。
> [!tips]先把问题问准。有两个方向我不打算谈。
一是 **要不要用 AI 写代码**？这个问题基本结束了，你用或者不用，都不改变它正在替你生成代码这件事。
二是 **AI 会不会取代程序员**？那是个流量问题，不是个能验证的问题。
{{< center-quote >}}
我只问一件事：代码被 AI 生成出来之后，你 **凭什么** 说这个项目是你的。
{{< /center-quote >}}
说实话，这个问题先扎到的是我自己。我在抖音发过一条图文，标题就是「AI 如此强大，人类能力边界应该延伸到哪」。那会儿它对我来说还是个提问，不是答案。学弟这句话把它按到了实处：他手里有一个真的仓库，真的记不住，真的在慌。
所以这篇文章不是来安慰谁的。先把「记不住」这件事本身看清楚。
## 一、记不住的不是代码，是你没做过的那些决定 {#not-memory}
先把一个事实摆出来：你手写的代码，也不是每一行都记得住。三个月前写的那份快排，现在让你默写，多半会在边界条件上卡一下。
学弟怀念的那个状态，可以换个说法：**他能自己把逻辑推出来**。快排的每一行他都能从分区逻辑推回去，所以细节忘掉也不要紧。
而 vibecoding 出来的那个项目，他连「**这个模块为什么摆在这儿**」都推不出来。
同样是「记不住」，底下欠的东西完全不一样：
| | 你手写的快排 | vibecoding 出来的项目 |
| --- | --- | --- |
| 细节 | 忘了 | 从没看过 |
| 结构 | 还在 | 从来没进去过 |
| 现在让你做什么 | 能从分区逻辑推回去 | 说不清这个模块为什么摆在这儿 |
{caption="两处都是「记不住」，差别在结构有没有进去过"}
一处是细节忘了、结构还在；另一处是结构从来就没进去过。
但「记不住」还只是症状。往下再问一层：**他为什么推不出来？**
**因为那些决定不是他做的**。模型决定用哪个库、决定流程怎么串、决定出错怎么兜底。==他参与的是「点确定」，不是「做选择」==。
这两件事在过程上差得很远。你自己写的时候，每个分叉点都会在你眼前停一下：
- 用现成的库还是自己写？
- 数据放内存还是落盘？
- 出错是重试还是直接把异常丢给上游？
这些问题你未必想得清楚，可能也就犹豫三秒钟，但**你经过了那个点**。
但AI 写的时候，同样的分叉点会在一瞬间被它走完，走的是默认那条。默认那条通常还都挺合理，不然它也成不了默认。
所以问题不在于它选错了。问题在于**代码只记录结果，不记录分叉**。三个月后你打开那个仓库，看到的是一串很顺的代码，每一个分叉点都合上了，看不出这里当初还有过别的选项。
> [!note] 这里值得停一下
> 为什么「做决定」这件事这么要紧？因为一个项目说白了，就是一串决定的集合
- 用哪个库？
- 数据存在哪儿？
- 这里要不要用状态机？
- 用单例模式还是依赖注入？
- 出错了怎么兜底？
- 以后要扩到什么规模？
- …………
这些决定每一个都拖着一句「为什么」。**谁做的决定，那些「为什么」就在谁手里**。学弟推不出来，不是因为忘了，是他手里从来就没拿到过它们。
**那 AI 做的决定，算不算你的**？
{{< center-quote >}}
**判断依据是：出了事，谁担？**
{{< /center-quote >}}
线上挂了 AI 不会接电话，面试官追问「为什么这么选」也不会去问模型，所有后果最后都落在同一个人身上。
**「拥有」** 这个词可以换个更准确的说法：
它说的不是「东西是我做的」，而是「它的后果落在我头上」。
而承担后果有个前提，那就是==你参与过那些决定==；不然你连「当初为什么这么选」都答不出，也就无从判断这次该怪谁、该改哪儿。
于是同一件事，得拆成两件来看：
| | 生成 | 拥有 |
| --- | --- | --- |
| 是什么 | 东西被做出来了 | 它出事时，找的是你 |
| 靠什么成立 | 劳动 | 决定，以及为决定担后果 |
| 能不能交出去 | 可以全部交出去 | **一步都不行** |
| 出问题的时候 | 它不知道出事了 | 你得知道怎么办 |
AI 把「生成」变得几乎免费，「拥有」却没有被减免一个字。
> [!question] 那我不学不就行了
> 能。代价有三个，而且都出现在「生成」结束之后：
>
> - 线上挂了你不知道该从哪儿查，只能把整段丢回给 AI 重写一遍
> - 面试官追问「为什么这么选」，你只能现场编一个
> - 三个月后打开这个仓库，等于打开一个陌生人的项目
>
> 三件事没有一件发生在你敲代码的时候。所以它们最容易被忽略。
{{< center-quote >}}
**生成可以外包，但拥有不行。责任没有代理机制。**
{{< /center-quote >}}
那么下一个问题就是，我凭什么知道自己有没有拥有它。
这个问题不能靠感觉答。代码跑通的那一刻没人会觉得自己不懂，**真正的分界要等它坏掉、或者等你被人问起的时候才显形**。
## 二、拥有了，是什么样：清楚的模糊 {#clear-vague}
那晚聊出来的第一句结论，就是这个。
{{< auto-dark >}}
{{< /auto-dark >}}
> [!info] 清楚的模糊
> 一个技术细节，你不知道它内部是怎么实现的，但你答得出三件事：**它是干什么用的**、**它能到什么效果**、**当初为什么选它**。
> 「模糊」说的是细节，「清楚」说的是边界。
我接着举了个例子，把整件事说透了。
> 就比如，让你开发一个聊天软件消息已读的功能。如果你自己知道「客户端、服务器模式」，那么你就会知道肯定是对方读了消息之后发送一个请求到服务器，然后服务器再发送一个信息给另一个用户，根据用户规模的不同，中间肯定会加一些缓存、为了保存一致性而加入的各种中间件等等，但这个整体的流程却一定是这样的。
这段代码你一行都没看过。可它的流程你能推出来：
```mermaid
sequenceDiagram
autonumber
participant A as A 的客户端
participant S as 服务器
participant B as B 的客户端
A->>S: 发送消息
S->>B: 转发消息
B->>S: 已读回执
S->>A: 推送「对方已读」
```
这张图里没有一条是别人告诉你的，全是从「客户端、服务器模式」这一条知识上长出来的。换成三年后新出的某个框架，只要这条模式没变，你照样推得出来。
把那段话拆开，它正好回答了上面那三个问题：
| 三问 | 在「消息已读」这道题上，答的是 |
| --- | --- |
| 干什么用 | 让对方知道这条消息被看见了；它是发给发送方的回执，不是给接收方看的内容 |
| 到什么效果 | 秒级送达，丢一条不致命，大面积延迟就等于这个功能废了 |
| 为什么选它 | A、B 两头未必同时在线，又各自躲在网络后面，所以只能由服务器中转，不能直连 |
三行答案你都写得出来，靠的还是你自己推。**这就是「拥有」的样子**：细节是模糊的，边界是清楚的。
>[!note]这里有两个方向得说清楚，因为它们正好是这把尺子的两头。
- 一头是完全的「模糊」：注意「清楚的模糊」的重心在**清楚**两个字上：说不出它做什么、到什么效果，那就只是模糊，跟「我没看过」是同一个意思。
- 另一头是极端的「清楚」：也就是以为越往下钻越好，把「能把每一行实现都背下来」当成懂的最高级。
{{< auto-dark >}}
{{< /auto-dark >}}
假设你真把某个库的源码逐行背下来了。它发个新版本，或者项目换个框架，你手上那点东西立刻打折。花掉的时间是成倍的，能带走的很少。
所以这把尺子真正好用的地方，是它**同时砍掉两头**：往下，砍掉「不知道它干什么」；往上，砍掉「非要背下实现」。
> [!warning] 「清楚」是硬指标，不是态度
> 说不出它做什么、到什么效果，那就只是模糊，跟「我没看过」是一个意思。这一头没有折扣可打。
> 另一头它也不许你无限往下钻：**能背下每一行实现**不算更高的段位，它只是更耗精力，学习起来的性价比更低。
**它不是给偷懒留的位置。** 它是一条门槛线：线以下不算拥有，线以上是浪费。
但尺子只回答了「知道到什么程度算数」，没回答「知道之后每天要干什么」。学弟那句「这让我很不安全」，卡的就是这个位置。
## 三、拥有不是一种感觉，是三件能验收的事 {#maintain-is-control}
聊到一半，学弟说了另一句话：“这让我很不安全”
我的回答是：
{{< center-quote >}}
**你会维护，就等于掌控。**
{{< /center-quote >}}
这话听着像安慰。它其实是一条挺硬的判据，往下推一层就清楚了。
先问：掌控感到底从哪儿来？三个答案里，前两个看着都挺合理。
```mermaid
flowchart LR
Q["掌控感从哪儿来"] --> A["我记得每一行"]
Q --> B["我能重写一遍"]
Q --> C["知道坏了该动哪里"]
A -->|"✗"| A1["快排也记不全
可你没失控"]
B -->|"✗"| B1["重写近乎免费
可你没更安心"]
C -->|"✓"| C1["面对后果"]
```
你手写的快排也记不全了，可你没觉得失控。AI 让重写的成本低到可以忽略，可重写一遍也没让你更安心。
剩下那个更窄的能力才管用：**你知道它坏了的时候，该动哪里。**
:(fa-solid fa-wrench fi-c-teal): 维护这个词听着像打杂，拆开看是三件硬活：
| | 要做的事 | 具体到动作 |
| --- | --- | --- |
| :(fa-solid fa-magnifying-glass fi-c-blue): | **定位** | 线上出问题，你能知道该去哪个文件、哪个函数看 |
| :(fa-solid fa-pen-to-square fi-c-teal): | **修改** | 改完敢发，因为你清楚这次改动会牵到谁 |
| :(fa-solid fa-clock-rotate-left fi-c-amber): | **回滚** | 万一改错了，你知道退到哪一版，以及退回去会丢什么 |
这三件事都不要求你记得实现细节。它们要求的是你清楚**结构**：谁依赖谁、边界划在哪儿、哪一段是命门。
三件里最容易被看轻的是回滚。定位和修改还能靠技术硬啃，回滚不行，它逼你回答一个 AI 不会主动问的问题：**上一版为什么是对的**。
你可能连上一版长什么样都记不住，但你得知道两件事：退回去要丢什么，以及丢了之后谁会先发现。你的库里有半张表的记录是用户昨天才填进去的，回滚就远不止一句 `git revert`。
{{< auto-dark >}}
{{< /auto-dark >}}
还有一个容易滑过去的点：这三件事 AI 都能帮你做一部分，所以它们看起来不像非你不可。
- 定位它可以替你读代码、列出可疑的几处；
- 修改它可以照描述写；
- 回滚它可以告诉你上一个版本改了什么。
**它给不出的是那个选择**：先动哪儿、能丢什么、什么时候停手。这三个问题后面站着同一个人，就是那个要接后果的人。
> [!abstract]再往下推一层：为什么偏偏是这三件事能换来掌控感？
> 因为它们全都指向同一个动作：**面对后果**。
> - 定位是在面对「已经出事了」
> - 修改是在面对「我这个决定会牵到别人」
> - 回滚是在面对「我可能错了，而我得知道退到哪儿」
掌控感从来不是「我什么都懂」，而是「错了我也知道怎么收场」。而这三件事，正好是收场能力的全部。
所以「清楚的模糊」是干维护活的入场券：你对一个细节「模糊」的那部分，正好是 AI 能替你填上的那部分；你「清楚」的那部分，正好是它填不了的那部分。
我那晚说的那句「AI 写的代码，我能维护，能保证线上少出甚至不出 bug」，分量全在后半句。:(fa-solid fa-circle-check fi-c-green): **能维护**才是你对外承诺的底气，写得多快从来都不是。
不过「维护得住」的前提是你自己已经知道的事，已经掌握的知识。
它没有证书，也没有界面。面试官看不见它，同事看不见它，连三个月后的你自己都拿不出证据。所以还缺最后一块：**你怎么证明自己拥有它**。
## 四、拥有的证据：你能把它的理由讲给第三个人听 {#explain-your-choice}
那晚的聊天记录里，有一段我后来反复回看。
{{< auto-dark >}}
{{< /auto-dark >}}
我把话点到了另一个场景上：AI 丢过来一版选型，随手挑一个，代码跑起来没报错，这事就算过去了。
**不行。**
同一个要求换到面试桌上，躲都躲不掉。他面试的时候，对面几乎都在跟他聊业务逻辑，他答不上来，只能每次现想。他答不上来的不是知识，是路径。面试官问「为什么这么选」，问的不是答案，是你当初有没有走到那个分叉点上。答一句「AI 建议的，跑通了」，等于告诉他这段代码的作者不在场，他后面所有关于业务细节的追问，都会落在同一个空处。
回头看，我之前那几句几乎是把答案提前给他了：
> 你得能说出个依据来，我为什么选这个，这里为什么这么写，有什么考量。
顺着这个思路，我整理出四个问题。你手上如果也有 AI 写完的代码，可以拿这四条过一遍：
> [!tip] 交出去之前，先问自己四个问题
> - [ ] 这个模块是干什么的，一句话能不能说清
> - [ ] 它在什么情况下会崩，崩了会怎样
> - [ ] 换个方案行不行，为什么没换
> - [ ] 真出事，第一刀切在哪儿
四个问题里最难的是第三个。前两个通读一遍代码基本能补上，第三个不行：代码里只有它选中的那一种写法，没有另一种。你翻遍那个仓库也找不到被否决掉的分叉点，因为**没被选上的选项根本不会留在代码里**。
这里有个更朴素、也更好用的判据，是我后来才想清楚的：
{{< center-quote >}}
**你能不能把它的理由，讲给第三个人听。**
{{< /center-quote >}}
不是讲给 AI 听，它不需要你的解释。是讲给一个完全不了解这个项目的人听：为什么这么选、为什么这么写、当初考虑过什么。讲得出来，说明这段逻辑已经落到你身上；讲不出来，它就还停在对话记录里。
> [!note]费曼学习法
> 费曼学习法是一种由理查德·费曼启发的高效学习方法，其核心是“以教促学”，通过用最简单的语言讲解知识来检验理解程度。
>
> **如果你不能把你已经掌握的知识教会给一个 8 到 12 岁的小孩。那就证明你还没有完全掌握它。**
前面那个场景和这个场景，落在同一份代码上会走向两条完全不同的路：
| 同一份 AI 写的代码 | 只问「跑通了吗」 | 加上那四个问题 |
| --- | --- | --- |
| 交付速度 | 快 | 慢一点 |
| 出 bug 时 | 回头再问一遍 AI | 知道从哪儿查起 |
| 三个月后 | 整块重写 | 还能改 |
| 面试被追问 | 说不出来 | 说得出依据 |
{caption="两份代码长得一样，差别在接下来半年"}
看到这里，有件事该不合常理了：AI 明明能把代码写得又对又快，为什么偏偏在最关键的「依据」上给不出东西。它连实现都能推出来，解释一句「为什么这么设计」有这么难吗。
## 五、为什么 AI 给了你代码，却给不了你依据 {#why-ai-cannot}
要理解这件事，得看一眼模型训练时到底在优化什么。
:(fa-solid fa-robot fi-c-violet): 一个语言模型被训练时，目标只有一条：让它预测的**下一个 token 的概率分布**，尽量贴近真实语料里出现的分布。它优化的是「像不像」。至于「对不对」，没有人把这个目标写进损失函数。
所以你要它给依据的时候，它给出的依据和它给出的答案，是同一个机制吐出来的两个结果，都是概率高的续写。它读起来像因果，是因为人类写下的文本里本来就塞满了因果句式。
> [!question] 那让另一个模型来审它呢
> 有点用，但有限。两个模型吃的是同一批语料，优化的目标也都是「像不像」，出错的偏好往往重叠。它们能挑出对方的低级错误，挑不出双方都当成常识的那部分。而真正的坑，通常就在那儿。
「独立」这两个字是这件事的关键。验证的前提是拿一个跟被验证者无关的东西去对照：量身高得用尺子，尺子不能就是你要量的那个人。让 AI 复核它自己写的东西，得到的是同一台机器吐出来的第二遍，不算两票。
严格说，这只说明「它训练时没把因果写进目标」，不等于它内部什么结构都没有。但对使用者来说，推论是一样的：==从它那里拿不到独立的验证==。
### 中文房间实验
关于「看起来懂了」和「真的懂了」的差别，哲学家早就问过一遍。
{{< details summary="中文房间实验的原文设定" >}}
1980 年，哲学家 John Searle 在《Minds, Brains, and Programs》里设想自己被关在一间屋子里。屋里有一本厚厚的规则手册，全是「收到这种形状的纸条，就送出那种形状的纸条」的对照规则。
屋外的人递进来一张写着中文的纸条。他照着手册查、照着拼，递出去一张中文纸条。屋外的人看来，屋里的人中文流利。
但屋里的人一个中文字也不认识。他手里有的是符号和符号之间的关系，缺的是这些符号指向的东西。
{{< /details >}}
{{< auto-dark >}}
{{< /auto-dark >}}
> [!info] 能指、所指、指涉物
> 索绪尔把符号拆成两半：**能指**是那个音响形象（「苹果」这两个字），**所指**是它在你脑子里唤起的那个概念。后来奥格登和理查兹又补上第三角，**指涉物**，也就是现实里那个真的苹果。
> 模型手里有前两样，而且比谁都熟。它缺的是第三角：那个能被咬一口、有汁水、闻起来有香味的苹果。
中文房间这个论证本身有争议，塞尔想用它证明的东西也比「AI 会不会写代码」大得多。但对写代码的人来说，它有个很好用的推论：**行为上通过测试，不等于过程里有理解。**
所以下次你想验证一个模型有没有真帮你把事弄明白，别拿「它答得像不像」当标准。它答得像，是它的本职工作。
**你能从它那里拿到的，是它的答案，不是它的依据。两者出自同一个机制。**
那就剩最后一个问题：依据从哪儿来？答案是
{{< center-quote >}}
**它只可能来自你自己。**
{{< /center-quote >}}
## 六、所以人站在哪 {#human-position}
那晚我引了一段腾讯技术公众号里的总结，它把分工切得很干净。
> 模型决定能力上限；上下文和 Harness 决定这个上限能否稳定落地。
>
> 人负责选择方向、定义标准并承担责任；Agent 负责执行、验证和加速迭代。
前一句意味着上限可以买：换更强的模型，是选型问题。难的是后半句。上下文和 Harness 说的是你把任务拆成什么样、给它什么材料、规定它按什么流程走、拿什么标准验收。这些全是工程活，一件都不会因为模型变强而自动消失。
但这段总结里有一件事它没说，而这件事恰恰最要紧：
**人管的那三个动作，没有一个是技术动作。**
| | 人 | Agent |
| --- | --- | --- |
| 管什么 | 选择方向 / 定义标准 / 承担责任 | 执行 / 验证 / 加速迭代 |
| 是哪种动作 | ==判断== | ==技术== |
| 模型变强能解决吗 | 不能，只能你自己想清楚 | 能，而且一直在变好 |
{caption="同一件事的两半，只有一半在随着模型变强而变好"}
选择方向、定义标准、承担责任，它们不要求你比 AI 更懂技术，只要求你比它更清楚自己要什么。而这正是它们最难的地方：技术有文档可查，「自己要什么」没有文档。
那它从哪儿来？只有一个来源，那就是：**你已经掌握的知识**。
上一节那条损失函数，在这儿正好接上。模型被优化的目标是「像不像真实语料」，所以它给出的建议天然偏向语料里最常见的做法。你要的却是另一件东西：
| | AI 给的 | 你要的 |
| --- | --- | --- |
| 依据什么选 | 语料里最常见的做法 | 在你这套约束下站得住的做法 |
| 看得见什么 | 所有项目加起来的平均情况 | 你那台 2G 内存的服务器、你的用户、三个月后接手的人 |
| 判据 | 像不像 | 适不适用 |
{caption="同一个问题，两边给出的答案不一样，因为两边知道的条件不一样"}
这些约束没有一条写在语料里，模型不知道它们存在，除非你开口告诉它。而你能不能想到「该告诉它什么」，又取决于你已经知道多少。于是有一类错最容易发生：**答案是对的，场景不对。**
这也解释了为什么「不会就去问 AI」这条路会在最关键的地方断掉：你没法判断它的回答对不对，因为你手里没有那把关尺子。
{{< center-quote >}}
**什么都不懂就去做决策，那与赌博无异。**
{{< /center-quote >}}
## 七、AI 越强，就越不需要懂底层吗 {#need-to-learn}
第一节里我摆出过一句「那我不学不就行了」，给了它三个代价。那三个代价是结果，这套说法还有个更精细的版本，值得单独拆一次：**AI 都这么强了，人根本不需要了解底层发生了什么。**
它给的理由是这样的。写 C 的人不需要懂汇编，写 Python 的人不需要懂 C，写网页的人不需要懂 TCP。每一代抽象层都会变厚一层，人往上走一台阶，底下的东西就被封起来。AI 只是下一个台阶。照这么推下去，知道得越少反而越安全。
这个推理的前半段是真的。你确实不用懂汇编，也确实不用懂 TCP 的三次握手。但它漏掉了一个条件：
{{< center-quote >}}
**抽象层能让你安心忘掉下面那层，不是因为那层被藏起来了，而是因为那层被写成了规格。**
{{< /center-quote >}}
规格的意思是：HTTP 有一份 [RFC](https://www.ietf.org/process/rfcs/)，C 有一份语言标准，它们有版本号、有明确的行为边界、有一份谁都能查的文档。所以你可以信任它，也可以追究它。出问题的时候你下得去，报错说 `502`，你知道去查网关；报 `ETIMEDOUT`，你知道去查网络。阶梯不是「永远不往下看」，是「想往下看的时候下得去」。
| | 以前每往上一层 | AI 这一层 |
| --- | --- | --- |
| 下面那层是什么 | 一份写下来的规格（RFC、语言标准） | 一个概率分布 |
| 能不能信它 | 能，它有版本号和行为边界 | 只能但愿它这次对 |
| 出事的时候 | 变成一条报错，能一层层往下翻 | 不报错，也翻不下去 |
| 你「不懂」这件事 | 有信号，它会喊 | 没信号，它不响 |
{caption="同样是往上走一层，底下有没有规格，决定了你还能不能往回走"}
AI 这层没有规格。它给你的不是一个契约，是一个分布。「它大概会这么答」不是规格，是概率。所以问题不是底层会不会被藏起来，是这一层有没有一份能查的文件。前面每一层都有，这一层没有。
再往下推一层，代价就出来了。分层抽象有一条隐含的保险：你压在下面没学会的那些东西，真出问题的时候会变成一条**报错**回来找你。报错是可搜的、可以贴给 AI 的、可以被解决的。所以「不懂」在下层是有信号的，它会喊。
AI 这一层不会喊。它替你做决定的时候，不会顺便提醒你「这里本来有一个决定」。你错过的地方，恰好都落在不产生任何信号的位置上。
你的下单接口没做幂等，同一个请求送来两次它就下两次单。用户手抖点两下就多出一条订单，要等到下个月对账才有人发现。而发现的人不是你。
==AI 时代要学的不是更少，是更深。==
你原来的位置是生产者，现在变成了验收者。验收比生产难：生产只需要有一条走得通的路，验收得知道哪些路走不通。一个只会生产的人验不了收，尤其当被验收的东西语法正确、风格整洁、跑得通，只是有一处不该那样。
所以再听到「不用懂底层」这句话，先别急着同意，拿一件事去试它：**这个错会不会自己报出来。** 会自己报出来的，交给 AI 没太大问题；不会自己报出来的，就得有人提前想到它。而提前想到它的前提，是你知道那一层里本来有什么。
会崩的错会自己撞到你面前；不会崩的错，得你自己去找它。
## 写在最后
回到最开始那个问题：AI 时代，人的能力边界该延伸到哪。
我的答案很小：
{{< center-quote >}}
**延伸到「能对它负责」为止。**
{{< /center-quote >}}
这个答案的推论不太好听。你现在会的那点东西，不是即将被替掉的部分，它是你和 AI 之间的**接口**。你会得越多，它能接上的地方越深。一个连进程和端口是什么都答不出的人，AI 给他的也只有一句「不能那样上线」，而他没法判断这句话在什么情况下不成立。
换个说法：把你会的东西乘上 AI，得到的确实更大。但零乘任何数还是零。
最后再把线划一次：上面说的这一切，都不针对那些本来就不打算长期维护的东西。一次性的脚本、试完就扔的 demo，做完就结束了，没什么可拥有的。
但只要有一行代码要长期活着，有句话你就得知道：
> 上线一个网站不能用 127.0.0.1。
这句话没有任何技术含量，可它是那种 AI 不会替你想、你想不到就要出事的知识。
为什么想不到就要出事？因为**AI 回答的是你问出来的问题。它不会在你没想到要问的时候，提醒你漏了一个问题。** 拥有、依据、那把尺子，说的最后都是同一件事：你得先知道有哪些问题该问。人的边界，大概就是这一类事情的集合。
如果你手上还没有这样的知识，那就得从最底下那条线补起来。:(fa-solid fa-arrow-right fi-c-violet): [先装好编译器，把第一个程序跑通]({{< relref "posts/new-to-c" >}}#install-mingw)。
这篇的起点是我在抖音发的一条图文，原帖在这里：
{{< link href="https://www.douyin.com/note/7669706454839856485" content="抖音 · AI 如此强大，人类能力边界应该延伸到哪" title="原帖，个人观点仅供参考" card=true card-icon="fa-brands fa-tiktok" >}}
---
> 作者: [青梧](https://zzzheng.com)
> URL: https://zzzheng.com/posts/3f7c9a2/