最近用 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 生成从“看起来对”走向“有证据、可追溯、可验证”。
