一 隅 记 事

关于能力

AI 时代里，真正变得更重要的，可能不是会不会用工具，而是能不能稳定地判断

很多人第一次接触 AI，会明显感觉到“执行”这件事变快了。写一段文案、整理一份结构、起一个页面、查一个报错，都比以前更容易迈出第一步。但越往后我越感觉，速度不是最难的，判断才是。因为当生成内容变得很便宜之后，真正稀缺的反而是：我能不能判断哪一段是靠谱的，哪一段只是看起来顺；我能不能分辨这次该继续展开，还是该停下来先重新定义问题。

这也是为什么我现在越来越看重几种看起来不那么“炫”的能力。比如界定问题的能力，因为问题一旦定义错了，后面生成得再快也是在错的方向上加速；比如核对和验证的能力，因为模型越会说，越容易让我误以为它已经替我想完整了；再比如把零散信息接回当前场景的能力，因为真正做项目时，从来都不是一个漂亮答案单独存在，而是要接进已有代码、已有目录、已有约束里。

所以如果问我 AI 时代什么能力反而变得更重要，我现在会答：不是“会不会用某个模型”，而是能不能在大量看起来都差不多的答案里，持续保住自己的判断力。这个东西听起来慢，但它才决定了我最后是被工具推着走，还是能真正把工具用在自己要去的方向上。

关于项目

从“会用工具”到“能做项目”，中间真正缺的往往不是一步大招，而是一整套收口能力

这是我最近做这个站时感受特别深的一点。很多单点动作我其实都不是完全不会，比如改页面、写文案、配 Nginx、申请证书、传文件、看报错。这些东西拆开看，好像每一项都能学、也都能跟着做出来。但真正把它们串成一个项目的时候，困难不是突然出现一个特别高的门槛，而是每一步都需要收口：页面改完了要不要考虑移动端，部署上去了要不要检查权限，Nginx 配好了要不要继续想缓存和流量，证书申请完了要不要记得续期。

我后来慢慢明白，项目感其实就藏在这些收口里。工具教会我的，常常是“怎么把某件事做出来”；项目真正要求我的，是“怎么把很多件事接起来，并且让它们不要互相打架”。这中间缺的往往不是再会一个新命令，而是能不能把上下游关系想完整，能不能想到后面的维护，能不能在每个小节点上多做一次确认。

所以现在我看“会用 AI”这件事，也不太会只看它会不会马上给结果。我更在意的是，它有没有帮我把项目往前推进一小步，有没有帮我补上那些我原本容易漏掉的收尾，有没有让我慢慢建立起一套从想法到落地的连接能力。因为对我来说，真正让一个人从“会用工具”变成“能做项目”的，从来都不是某一个瞬间突然开窍，而是一次次把事情做完、做顺、再做得更稳。

关于焦虑

我现在怎么看 AI 带来的“取代感”：真正让我不安的，常常不是它太强，而是我自己还没有形成稳定的方法

说完全没有过焦虑，那肯定不真实。第一次明显感觉到这种情绪，是发现很多原本觉得要学很久的事，AI 现在几分钟就能给出一个看起来还不错的版本。那时候很容易冒出一个念头：如果它这么快，那我还要花这么久学这些干什么。这个念头不算夸张，很多人可能都会有，只是以前我没有特别认真地去拆开它。

后来慢慢做项目，我才发现让我真正不安的，不是 AI 本身有多强，而是当它把“起步”这件事变得很容易之后，我自己的方法感还不够稳定。比如我能不能判断一段代码该不该用，能不能看出一个方案后面会不会留下坑，能不能在结果很多的时候依然知道自己这次最重要的目标是什么。AI 的出现不是把这些问题消掉了，反而把它们照得更亮了。

所以我现在对“取代感”的理解，已经慢慢从恐慌变成了提醒。它提醒我，真正值得补的不是某个零散技能，而是方法、判断和收口这些更底层的东西。因为工具越强，越容易让表面的差距缩小；但一个人能不能持续把事情做对、做稳、做得越来越完整，最后还是得回到这些更慢、也更不容易被替代的能力上。

关于学习方式

为什么我越来越相信，小项目比看很多教程更能让人真正进步

以前我也很依赖教程，因为教程会给人一种很明确的路径感：先看这里，再做那里，最后就能得到一个结果。它的好处当然很明显，尤其是在刚入门的时候，会比自己摸索轻松很多。但我后来越来越清楚地感觉到，看懂教程和真的进步，中间还是隔着很长一段路。因为教程通常帮我处理掉了很多不稳定的部分，而项目恰恰相反，它会把这些不稳定的东西一个不剩地摆到我面前。

做小项目的时候，我没办法只停留在“这个我知道”。页面怎么组织、内容怎么收、部署怎么做、端口怎么开、证书怎么配、线上为什么又和本地不一样，这些问题一旦串起来，就会逼着我把很多原本分散的知识真的接到一起。它会让我暴露出自己到底哪里只是见过，哪里才是真的会。这种暴露有时候挺挫败，但也正是它，让学习不再只是停留在“输入很多”，而是开始慢慢变成“我真的能把东西做出来了”。

所以我现在会更愿意给自己留一些可以反复做完的小项目。它们不一定很大，甚至很多都只是一个页面、一段接口、一套部署流程，但只要它能让我从想法走到上线，中间再把那些细碎的问题都碰一遍，我就会觉得这次学到的东西比单纯多看几篇教程更扎实。因为项目本身，就是最诚实的反馈。

关于方法

做这个站的过程中，我真正补上的不只是技术，而是一种把事情往下推进的方法感

这件事我一开始其实没有那么强的意识。最早只是想把页面做出来，后来慢慢加了文案、动画、发布、Nginx、HTTPS、备案，再到压缩和缓存，才发现自己在补的好像不只是某个具体技术点。更重要的是，我开始学会怎么面对一件并不完全熟悉的事，然后一步一步把它拆开、落地、修正，再继续推进。

这种方法感对我来说很重要，因为以前我一遇到稍微复杂一点的事，很容易在脑子里先被它吓散。可这次做下来，我慢慢知道原来可以先不追求一下子全会，而是先确定现在卡在哪一层，再决定这一步是该改页面、查文档、问 AI，还是先去确认服务器环境。很多时候，事情之所以推进不下去，不一定是因为太难，而是因为我没有把它拆成可以一层层处理的样子。

所以如果要说这个站目前给我最大的收获，我可能不会只说“学会了部署”或者“会配 HTTPS 了”。我更想说的是，它让我慢慢建立起一种信心：遇到陌生问题时，我不一定马上会，但我开始知道该怎么把它往前推了。对我来说，这种感觉比单独学会一条命令更重要，因为它会让我后面做别的项目时，也更愿意真的去动手。

关于安全

如果真想防止 AI 被坏人利用，最核心的不是“相信模型会自觉”，而是把权限关在足够小的笼子里

我现在越来越觉得，讨论“怎么防止 AI 被滥用”时，最容易犯的错，就是把希望放在模型自己会不会乖上。可只要一个系统真的接上了文件、命令、数据库、外部 API 或用户数据，它面对的就已经不是单纯的聊天问题，而是权限问题。也就是说，真正决定风险上限的，不是模型说得多像安全专家，而是它手里到底握了什么能力，这些能力有没有被严格限制。

所以如果让我用最直白的话总结，我会说第一原则就是最小授权。能只读就不要可写，能写某个目录就不要给整个文件系统，能调用一个固定接口就不要给它任意外连，能只允许几条明确命令就不要让它拿到完整 shell。很多系统之所以后面会出事，不是因为模型突然变坏了，而是因为一开始就给了它过大的活动空间，结果只要遇到恶意提示、越权输入或者被人故意诱导，风险就会被一下子放大。

第二层我现在会特别看重的是工具白名单和动作分级。不是所有动作都应该同一个权限等级。像“总结内容”“整理文案”“读取某个公开文档”这种事情，风险和“执行命令”“删文件”“发请求”“改配置”完全不是一个量级。前者可以更自动化，后者就应该强制加确认、人审、审批或者延迟执行。真正稳的系统，往往不是靠一句“请安全行事”，而是从架构上就明确哪些动作永远不能自动过，哪些动作必须留痕，哪些动作必须有人兜底。

第三层是审计和限速。我现在会把它理解成“就算它哪一步真的走偏了，也不能让问题悄无声息地扩大”。所以日志、请求留痕、操作回放、异常告警、频率限制、配额控制这些东西，看起来不像模型能力本身那么亮眼，但它们才是真正能把事故挡在小范围里的东西。因为现实里很多风险不是一步爆炸，而是先小规模试探、再慢慢放大。如果系统对这种行为完全没有记录和刹车，那后面就很容易出大问题。

最后我越来越相信，真正能把风险压下来的，不是一条万能提示词，而是一整套组合拳：权限最小化、工具白名单、敏感动作人审、数据隔离、输出校验、日志审计、速率限制，再加上默认拒绝而不是默认放行。说到底，防止 AI 被坏人利用，和防止任何自动化系统被滥用，本质上是一回事。不要先问“模型会不会听话”，而要先问“就算它不听话，或者有人故意诱导它，它到底还能做出多大的事”。这层想清楚了，防护设计才算真的站住。