小白用Codex和Claudecode也能做产品，程序员的出路在哪里？

最近用 Codex 和 Claude Code 写项目时，我越来越明显地感受到一种割裂：一边是效率真的变高了，一个想法可以很快变成能跑的产品；另一边是焦虑也变强了，因为“能跑”开始变得不再稀缺。真正刺痛我的问题不是 AI 能不能写代码，而是当一个项目大部分代码都由 AI 生成后，我还能不能解释它、修改它、验证它、回滚它，并在它出问题时真正负责？如果不能，这个项目看起来再完整，也更像是 AI 的产物，而不是我的工程能力。

1.能做出产品，但不等于完全具备工程能力

小白能用AI做产品，但开发的时候他是否知道什么场景用什么技术栈，架构如何设计，如何用工作树和Git提交或回滚代码，如果一个系统真的上线，并发怎么处理？数据库事务边界在哪里？缓存失效怎么办？权限绕过怎么防？日志怎么设计？成本异常怎么定位？AI 改了鉴权逻辑但测试没覆盖怎么办？线上出错谁回滚？这些问题不是“生成代码”本身，而是工程责任。

未来最危险的岗位不是“程序员”，而是“只会接明确需求、写普通 CRUD、不会判断架构、不懂测试、不懂安全、不懂业务的人”。因为这类工作最适合被AI批量生成。

AI 让代码产出变快，必然让review、测试、安全和治理变成瓶颈。

AI 时代的高阶程序员价值链变成：定义问题 → 拆解任务 → 设计架构 → 给 AI 上下文 → 审查 diff → 写测试和评测 → 控制权限和安全边界 → 监控线上行为 → 复盘成本和质量 → 长期维护系统。

AI 时代越往后，“能生成代码”越不稀缺，“能证明代码可信”越稀缺。

我所做的项目：

PatchBrake 不是为了再做一个代码扫描器，而是盯住 AI-generated diff 里的工程风险：删测试、放大权限、弱化鉴权、修改规则文件、引入危险脚本。

Token Studio ROI 不是为了记 token，而是把 AI 编程从“感觉效率很高”变成可复盘的工作证据：不同项目、不同模型、不同任务到底消耗了多少，产出了什么，值不值得继续。

OmniMerchant 不是客服 demo，而是在跨境电商场景里处理 RAG、tool calling、多租户、流式响应、fallback、成本和权限边界。

简喵不是泛泛的简历评分器，而是证据约束型岗位竞争力诊断：JD里哪些能匹配，哪些有证据，哪些不能硬补，改写后能不能经得起面试追问。

这些项目表面不同，底层是同一个问题： AI 生成之后，如何留下证据、边界和责任？ 我把它叫作可信交付。 它至少包含五件事：

• 生成结果有证据。
• 系统行为有边界。
• 质量风险可验证。
• 线上问题可追溯。
• 长期演进可复盘。

在AI应用工程中：

RAG系统不是接一个向量库。 它要评估retrieval recall、context precision、faithfulness、answer relevance。

Agent系统不是让模型调用工具。 它要设计tool permission、approval flow、audit log、failure fallback。

AI observability不是看一眼 token 数。 它要记录模型、延迟、成本、trace、tool call、错误、用户反馈和版本变化。 这些才是AI应用开发的真实壁垒。

所以AI时代真正的出路是：能把AI生成的软件纳入一套可验证、可审计、可交付的工程流程，建立一套自己的AI工作流。AI时代不缺代码生成，缺的是可信交付。

2.小白也能做产品，程序员的出路在哪里？

（1）做 AI 应用工程，而不是“套壳应用”。

用上Codex和Claude Code确实可以做一个“看起来不错”的工具，但多数人做不出稳定的 AI 应用。因为 AI 应用真正难的地方不是页面，也不是调 API，而是这些问题：

• 模型输出不稳定怎么办？
• 结构化 JSON 解析失败怎么办？
• RAG 检索到错误证据怎么办？
• 用户输入包含 prompt injection 怎么办？
• tool calling 调错工具怎么办？
• 多租户数据串了怎么办？
• token 成本失控怎么办？
• 流式响应中途失败怎么办？
• 模型降级后质量怎么保证？

AI 生成内容如何可追溯、可解释、可复盘？ 这些才是AI应用开发的真实壁垒。

普通小白能上线 demo，但很难建立一套 evidence、eval、observability、guardrail、fallback、audit trail。 出路不是“我也会用 Claude Code 做项目”，而应该是：“我能把 Claude Code、Codex 生成的软件纳入一套可验证、可审计、可交付的工程流程。”

• 不只是我的项目能跑，而是我能解释核心链路和关键实现。
• 不只是我的技术栈很丰富，而是我选择了有取舍、有边界、有替代方案。
• 不只是我用了 Claude Code / Codex，而是我能审查、约束、验证 AI 产物。
• 不只是我做了几个单元测试，而是我的测试覆盖了异常、边界、回归和 CI。
• 不只是我实现了登录鉴权，而是我能处理越权、注入、敏感信息和多租户隔离。
• 不只是我本地运行成功，而是我有日志、错误码、重试、回滚和监控。
• 不只是我的README很漂亮，而是我有 changelog、benchmark、failure cases 和复盘。
• 不只是我会背项目介绍，而是我能现场改需求、debug、解释取舍。

（2）掌握领域，而不是只掌握工具。

AI 最擅长的是通用模式。越通用，越容易被生成；越需要领域判断，越不容易被替代。

比如跨境电商客服系统，不只是写一个聊天框。它涉及订单、物流、售后、退换货政策、多语言、商家规则、平台合规、用户情绪、风控和成本。求职材料生成也不是“润色简历”，而是 JD → 证据 → 改写 → 风险控制 → 面试可追问。AI 可以帮你写代码，但它不知道你的产品到底要对谁负责。

所以程序员的长期出路之一，是变成“某个领域里的工程师”，而不是“只会某个技术栈的人”。Java 后端、Spring AI、RAG、Agent 都只是武器；真正值钱的是你能把它们用于一个真实问题，并且知道哪些地方不能乱生成。

AI 可以生成代码、README、测试样例、架构图，但很难伪造你对系统的真实理解、取舍过程、排障能力和长期维护能力。

3.AI 时代，项目本身会贬值，工程证据会升值

（1）设计取舍证据。

面试官问：

• “为什么用这个架构？”
• “为什么不用更简单的方案？”
• “这个模块的边界在哪里？”
• “如果用户量扩大10倍，哪个地方先出问题？”
• “这个设计最失败的地方是什么？”

真正做过工程的人，回答里会有取舍：性能、复杂度、开发时间、可维护性、安全、成本、团队能力。只靠 AI 堆出来的人，通常只能复述架构名词，比如“用了 Redis、用了 MQ、用了 RAG、用了微服务”，但说不出为什么。

（2）debug 证据。

AI 能生成新代码，但真实工程能力很大一部分体现在出问题后能不能定位。

面试官会问：

• “线上接口变慢，你怎么排查？”
• “Redis 缓存命中率下降，你看什么指标？”
• “数据库偶发死锁，你怎么复现？”
• “用户说 AI 回答错了，你怎么判断是 prompt 问题、检索问题、模型问题还是数据问题？”
• “流式响应中途断了，前后端分别怎么处理？”

这类问题很难靠背诵解决。因为它考的是排查路径：日志、traceId、metrics、SQL explain、异常栈、请求链路、复现条件、最小化变量、回滚策略。

所以项目里要有日志、错误码、traceId、监控截图、故障复盘。哪怕是个人项目，也可以写一份“线上事故排查文档”。

（3）测试和验证证据。

未来 AI 生成代码越多，测试越重要。面试官会越来越看重你有没有能力验证 AI 产物。

他会问：

• “你怎么证明这个功能是对的？”
• “边界条件测了哪些？”
• “单测、集成测试、端到端测试分别覆盖什么？”
• “AI 生成代码你怎么 review？”
• “你怎么防止修改 A 功能时破坏 B 功能？”

小白做项目通常是“能跑就行”。工程师要回答的是“为什么我相信它长期能跑”。

项目需要的东西：

单元测试、集成测试、异常测试、边界测试、benchmark、CI、测试覆盖范围说明、失败用例说明。

除此之外还应该有 AI eval：比如 RAG 回答是否引用了正确证据、简历改写是否夸大事实、客服 Agent 是否越权调用工具、AI 生成 diff 是否删除测试或放大权限。

（4）代码审查证据。

面试官不一定只让你写代码，可能直接给你一段AI生成代码，让你 review。

他会看你能不能发现：

• 并发问题。
• 权限绕过。
• 事务边界错误。
• N+1 查询。
• 空指针和异常吞噬。
• SQL 注入。
• 缓存穿透/击穿/雪崩。
• 日志泄露敏感信息。
• 测试只测 happy path。
• 代码过度抽象。

AI 最容易写出“看起来完整，但边界很脆”的代码。会工程的人，能看出这些脆点。

我会把 PatchBrake 这类项目继续往“AI diff 风险审查”方向做。它不只是一个工具，而是能力定位的证据：你不是只会用 AI 写代码，你还能审计 AI 写出来的代码。

（5）系统边界和安全证据。

AI 写代码后，最容易被忽视的是边界。 面试官问：

• “用户输入恶意内容怎么办？”
• “多租户数据怎么隔离？”
• “普通用户能不能越权访问别人的资源？”
• “tool calling 有没有权限控制？”
• “模型输出不合法怎么办？”
• “敏感信息会不会进日志？”
• “AI 生成内容错了，系统怎么兜底？”

（6）长期维护证据。

很多 AI 项目是一次性 demo。面试官会越来越警惕这种“短期堆出来”的项目。 更关注：

• 有没有版本演进记录。
• 有没有 changelog。
• 有没有 issue/roadmap。
• 有没有重构记录。
• 有没有测试随功能增长而增长。
• 有没有配置说明。
• 有没有部署说明。
• 有没有已知问题。
• 有没有从 v1 到 v2 的设计变化。

真正的工程能力不是“做出来”，而是“维护得住”。一个项目连续迭代 3 个月，比 5 个一次性AI demo更有说服力。

（7）表达和复盘证据。

AI 能帮你写项目介绍，但很难替你讲清楚真实经历。面试官会通过追问判断你是不是 owner。 面试官问：

• “这个项目里你最难的一个 bug 是什么？”
• “你做过最错误的设计是什么？”
• “哪一部分后来推翻了？”
• “你最不满意的地方是什么？”
• “如果再做一遍，你会怎么改？”
• “这个项目真正服务了谁？”
• “有没有用户反馈？”

这些问题非常关键。因为没真正做过的人，通常只会讲正面包装，不会讲失败、返工、妥协和权衡。

所以文章里可以考虑主动写失败点。不是自曝缺点，而是证明你真的经历过工程过程。

能力	低质量证据	高质量证据
写代码	项目能跑	能解释核心链路和关键实现
架构设计	技术栈很丰富	有取舍、有边界、有替代方案
AI 使用	用 Claude Code/Codex 做项目	能审查、约束、验证 AI 产物
测试	有几个 happy path 单测	覆盖异常、边界、回归、CI
安全	登录鉴权	越权、注入、敏感信息、多租户隔离
可靠性	本地运行成功	日志、错误码、重试、回滚、监控
项目深度	README 很漂亮	有 changelog、benchmark、复盘、失败案例
面试可信度	会背项目介绍	能现场改需求、debug、解释取舍

这些都是我后面做内容和产品会坚持的方向。

4.关于我个人对AI时代的思考

我不会把自己的产品和文章做成“手把手复制一个爆款项目”的流量模板。

更不会承诺“学完某个项目就能找到工作”。

这种话听起来很有吸引力，但很多时候只是另一种自我安慰。

AI 应用开发不是背几个框架名词，也不是照着教程部署一个项目。

真正重要的是：你有没有在一个具体问题里做过判断，踩过坑，推翻过方案，修过错误，理解过边界，并且能把这些过程沉淀成自己的工程认知。

我更在意长期品牌，而不是短期热点。

热点可以带来流量，但很难带来信任。

真正能让别人相信你的，不是你追上了多少话题，而是你是否长期围绕一个方向持续输出，是否能在项目、代码、文章和复盘里看见稳定的判断力。

我现在做的事情很简单：

记录自己从 0 到 1 学习 AI 应用开发的过程。

记录项目踩坑、架构取舍、错误判断、重构过程和复盘。

记录我如何从一个学生慢慢建立起对 AI 应用工程、可信交付、证据链、评测、安全和长期产品判断的理解。

这不是速成路线。

也不是求职捷径。

它更像是一条长期训练路径。

我希望我的内容不是让人看完以后产生虚假的兴奋，而是让真正愿意思考的人看到：一个项目为什么这样做，哪里容易错，哪些地方不能骗自己，什么才算真正有工程价值。

我相信，一个人需要在某个领域建立足够稳定的判断，才不会被网上的情绪、热点和速成叙事随意带偏。

我也相信，真正有判断力的人，最终会通过长期内容找到彼此。

不是因为标题足够刺激。

而是因为文字里有真实经历，有取舍，有问题意识，有持续迭代的痕迹。

我不会只做“看起来很热”的内容。

我会继续做有我自己工程路径、成长痕迹和判断密度的深度内容。

短期流量会过去。

长期品牌会留下。

我是 Ryan，一个专注于可信 AI 应用工程的开发者，个人技术博客：yanxai.com，研究如何让 AI 生成从“看起来对”走向“有证据、可追溯、可验证”。