AI 编程感悟
三个月没手写代码之后，我重新理解了 AI 编程。说实话刚开始其实有点焦虑。
以前一天不碰代码，就觉得自己可能会落后。框架在更新，工具在变化，新的 AI 编程产品也层出不穷。好像只要停下来，就会被别人甩在后面。
但这三个月过去，我发现真正让我焦虑的，可能不是“不会写代码了”，而是以前对编程的理解太单一了。
过去我认为，程序员的核心能力就是写代码。需求来了，分析一下，然后开始敲代码。代码写得越快，解决的问题越多，似乎就越有价值。
但现在看来，写代码只是软件开发里比较具体、也比较容易被替代的一部分。
真正困难的事情，往往不是把某个函数写出来，而是判断到底要做什么、为什么这样做、改动会影响什么，以及最后交付的东西是否真的解决了问题。
这也是我感触最深的地方。AI 编程已从“帮我补几行代码”，变成“替我完成一个完整任务或者项目”。AI 不只是生成代码，还要理解项目、查找上下文、修改文件、运行测试、处理错误，最后交付一个可以使用的结果。这意味着，未来的编程方式可能会发生变化。
以前是：人负责拆解任务，AI 辅助写代码。未来的工作模式正在变成：人负责定义目标和边界，AI 负责完成具体工程过程。
当然，这并不意味着程序员可以什么都不懂了。恰恰相反，越是依赖 AI，越需要具备判断力。
如果没有基本的工程能力，就很难判断 AI 写出的代码是否合理；如果不了解业务，就无法发现需求理解错了；如果没有测试和验收意识，AI 可能只是很快地制造出一堆看起来能运行、实际上很难维护的代码。所以我现在越来越觉得，AI 编程最重要的不是提示词技巧，而是上下文管理。当 AI 缺乏对项目结构、代码规范、业务规则、历史决策和运行方式的了解时，它的能力就会大打折扣。你告诉它一句“帮我加一个功能”，它可能真的会加，但未必加在正确的位置，也未必符合原来的设计。
而实现这一点，关键在于上下文的持续建设与管理。
好的 AI 编程环境，应该让 AI 逐渐知道：
- 这个项目是做什么的；
- 代码应该遵循什么规则；
- 哪些地方不能随便修改；
- 遇到问题应该查哪些资料；
- 修改完成后如何验证；
- 过去犯过哪些错误。
从这个角度看，AI 编程并不是简单地把程序员替换掉，而是在重新定义软件开发的工作流。
程序员需要从“代码生产者”，逐渐变成“任务设计者、智能体管理者和结果验收者”。
这对我来说也是一个提醒。
三个月没写代码，并不代表这段时间完全没有积累。如果只是机械地敲代码，可能每天都很忙，但未必真的在进步。相反，停下来重新思考软件开发的流程、项目的结构、人与 AI 的协作方式，也许同样重要。
现在做需求时不会再一上来就打开编辑器，然后直接开干。
我会先把需求说清楚，把目标、约束和验收标准写下来；然后让 AI 先理解项目、分析方案，再开始修改；完成之后，再通过测试、代码审查和实际运行去验证结果。
这可能就是 AI 时代更适合我的编程方式：
- 少一点机械敲代码，多一点目标设计；
- 少一点一味追求速度，多一点对结果负责；
- 少一点“让 AI 帮我写”，多一点“让 AI 和我一起完成”。
这并没有让我觉得编程变得不重要了。相反，我开始意识到，真正重要的从来不只是代码本身，而是通过代码持续解决真实问题的能力。
而 AI，正在让我重新思考：一个程序员，究竟应该把时间花在哪里。
嗨 👋 今天是植树节，大家有没有种树。在这个特别的日子里，尽管我们的脚步无法踏足田野，亲手种下一棵绿树，但我们可以在知识的土壤中埋下一颗技术的种子。今天，我们将探讨一个开源项目——LibreTranslate，它是一个自由、开源的翻译服务工具，可以帮助我们搭建属于自己的本地化翻译服务。
某 SVIP 用户充值 5 万后卡在终极关卡，反馈 2 小时未处理，次日退款流失——直接损失= 1 个月流水。以下是一个例子哈，当然如果内部搭建了通知服务，可以跳过本章。