Scra AtlasScra AtlasScra Atlas

我开始用 Codex，是在意识到 AI 已经能承担大量重复实现之后。越是开发，越觉得真正稀缺的不是把一段重复逻辑手写出来，而是能不能把一个系统想清楚。

很多简单开发本来就是重复的复制、拼接和调试。把这些落地实现交给 Codex，我并不排斥。我的工作会因此前移：想清楚系统的边界、架构和方向，再判断一段实现究竟是不是我要的。

这不是说代码从此不重要，而是我不再把“亲手敲完每一行”当成唯一的专业证明。对个人开发者来说，真正拉开差距的往往是能否把一个模糊的想法变成可执行的系统：哪些问题值得解决，数据怎么流动，模块如何取舍，出了问题该由谁负责。重复实现可以被加速，工程判断不能外包。

我负责方向，Codex 负责给我新的可能

我把 Codex 当成搭档。通常我先给出思想、目标和系统层面的判断，它负责把方案推进成可运行的东西，也会给出我没想到的反馈。

但我不总是把答案说得很完整。有时我明明知道自己会怎么做，还是会故意只描述问题，让 Codex 去猜。目的不是考它，而是避免自己被第一个方案困住。一个不同的回答、一个不一样的拆法，都可能把思路撞开。

反过来，我也不会把它的话当结论。如果我一味坚持自己的方案，或者一味听从它的建议，很容易形成新的思维定式。更麻烦的是，很多 AI 会迎合提问者：你越强调一个方向，它越容易顺着你说“对”。所以我的分工很简单：Codex 做，我评审方案。

这里的“评审”不是等它写完以后挑几个语法错误。我更在意的是：它理解的问题是不是我真正想解决的问题？它把复杂度放在了哪里？这个方案以后还能不能继续改？如果它写出一段能运行的代码，但答案已经偏离最初的目标，那么运行成功也没有意义。

因此，我和 Codex 的关系不是“我下命令，它交作业”。我会给方向，也会保留问题；我会接受它的建议，也会否决它的建议。它提供速度和视角，我保留判断和责任。这种来回拉扯，才是我想要的协作。

一次算法方向的变化

在 Urban Sidequest 里，我最初想用 MLP 训练一组参数，去筛选合适的 POI 点位。这个方案能做，但在不断推演需求和实现方式时，我意识到真正的问题不只是“哪些点值得去”，而是“怎样的一条路线更好”。

于是我把算法方向调整为：不再让 MLP 只筛点位，而是尝试让它学习路线数据，寻找更优的路线。最终决定仍然由我判断，但这个转向来自一次协作中的思路碰撞，逼我重新定义了问题。

对我来说，重要的不是“AI 想到了一个更聪明的答案”，而是它把原来的设想推到了足够具体的程度，让我发现自己问错了问题。只做 POI 筛选，可能是在优化一个局部动作；把路线作为学习对象，才更接近产品真正想交付的体验。

这也是我认为 AI 编程最有价值的地方：它可以很快把一个想法变成可以讨论、可以反驳、也可以推翻的东西。很多方向在脑子里看起来合理，只有真正落到方案、接口和实现层面，问题才会暴露出来。

能运行，不代表方向正确

Codex 经常能写出“跑得起来”的代码，但这不意味着它和我的实现思路一致。当我们的方向有冲突时，它并不擅长自己发现并化解这种冲突。最后仍然要有人判断：这是一个值得继续迭代的实现，还是从一开始就走偏了？

它也能弥补我作为后端开发者在前端上的短板，让页面从无到有、从能用到更完整；但如果我要特别高级的视觉效果，仍然不能指望它一次做好。AI 改善了起点，不会自动替代设计能力。

这也是我不相信“把需求扔给 AI，就能直接得到产品”的原因。它可以帮我把页面搭出来、把组件串起来、把功能接上，但一个真正好的界面仍然依赖审美、层级、交互节奏和一次次取舍。对于我不熟悉的前端领域，Codex 是很有价值的补偿，但不是免思考的捷径。

个人项目可以大胆，企业系统不能失去边界

对个人开发者来说，我愿意把更多执行工作交给 AI，甚至让 AI 工具（如 Hermes）参与维护自己的服务器。但企业环境不是这样。AI 仍然是未知的，它会犯错，也需要可追责的流程。把个人项目里的大胆委托原样搬到企业里，并不成熟。

个人项目里，我可以根据自己的风险承受能力快速试错；企业系统里，影响范围、数据安全和责任归属都不同。AI 能参与得很深，不代表它应该拥有不受约束的权限。越是把它当成能力强的搭档，越需要把边界、验证和最终责任说清楚。

Codex 没有让我少思考。它只是让我把时间从重复实现里拿回来，放到更值得负责的地方：定义问题、判断方向、接受或否决一个方案。

对我而言，用 AI 写代码的核心从来不是让它替我成为工程师，而是让它成为一个足够快、足够愿意提供不同答案的搭档。代码可以由它来生成，问题必须由我来定义；方案可以一起推演，责任最终仍然在我这里。