从裸辞到重拾键盘：一个前大厂码农的技术探索手记
去年十月，我做了一个让全家人都觉得“脑子进水”的决定——裸辞了。在某大厂卷了三年半，每天通勤两小时（去程一小时，回程一小时），写不完的需求、改不完的bug、开不完的对齐会……终于在一个秋雨绵绵的周五晚上，看着IDE里一行又一行被产品经理临时砍掉的功能代码，我点了“提交离职申请”。
Gap这半年，说躺平吧，其实也没真躺。毕竟北京房租不等人，技术圈更新又快得吓人。我一边刷LeetCode保持手感，一边疯狂补AI相关的知识——不是为了立刻找工作，而是真的被大模型的能力震撼到了。尤其是当我发现，以前要花三天调通的微服务链路，现在用Claude Code辅助，两小时就能跑起来时，我意识到：时代变了，再不用AI工具，怕是要被时代甩下车。
最近重新投简历、面试，聊到技术栈，很多面试官都会问：“你这段时间在做什么？” 我就如实说：在用Claude和OpenCode折腾一些小项目，顺便重新思考“程序员到底该怎么做技术探索”。这篇文章，就是想聊聊这段“脱离生产环境”后的实践感悟——没有KPI绑架，反而让我看清了一些东西。
被Claude Code救过命的深夜
事情得从去年12月说起。当时我在复现一个开源的LLM推理框架，本地跑起来没问题，但部署到云服务器后死活报错：
OSError: [Errno 12] Cannot allocate memory
我当时第一反应是：内存不够？可我明明开了32G RAM的实例啊！查了一晚上文档，翻遍GitHub Issues，甚至怀疑是不是CUDA驱动版本不对。凌晨三点，咖啡喝到心悸，脑子里只剩一个念头：要不直接删库跑路算了？
最后实在扛不住，把整个错误日志、Dockerfile、启动脚本一股脑丢给Claude，问它：“兄弟，救我，为啥本地能跑，线上崩？”
不到十秒，Claude Code插件直接高亮出问题所在：
你在
docker run命令里用了--shm-size=64m，但你的模型加载需要至少256MB共享内存。建议设为--shm-size=2g。
我当场石化。原来罪魁祸首是Docker的共享内存限制，而不是模型本身或硬件资源。改完配置，一次跑通。那一刻我差点给Claude磕一个——这玩意儿简直是赛博华佗！
这件事让我意识到：技术探索不能只靠蛮力，得学会“借力”。以前在大厂，遇到问题第一反应是“自己查”，因为团队文化讲究“独立解决问题能力”。但现实是，很多坑根本没必要自己踩，尤其是当AI已经能精准定位问题时。
OpenCode：不只是代码生成，更是思维外挂
说到OpenCode，可能很多人还不熟悉。它其实是国内某大模型团队推出的代码理解与生成工具（名字就不点破了，懂的都懂），主打“上下文感知+工程级理解”。和通用大模型不同，OpenCode更擅长处理真实项目结构——比如你丢给它一个包含多个模块的Git仓库，它能快速理清依赖关系、接口定义，甚至推断出业务逻辑。
我拿它试了一个“地狱级”任务：重构一个两年前写的、注释稀烂、没人敢动的Node.js旧服务。这个服务当年是我接手的一个遗留项目，里面充斥着callback地狱、硬编码的IP地址、以及各种魔法数字。原本我以为至少得花一周才能理清楚，结果用了OpenCode后，三天搞定。
具体操作是这样的：
- 把整个项目目录拖进OpenCode；
- 提示词写：“分析此项目的入口、核心模块、数据流，并指出潜在的性能瓶颈和安全风险”；
- 它返回了一份带行号的问题清单，比如：
src/utils/db.js:45使用明文密码连接数据库routes/api.js:112存在未校验的用户输入，可能导致SQL注入- 全局使用
var而非let/const，作用域混乱
更绝的是，它还能根据我的需求生成重构方案。比如我说：“我想把所有数据库操作迁移到Prisma ORM”，它不仅给出了迁移步骤，还自动生成了对应的Prisma schema和DAO层代码模板。
当然，也不是完全没坑。有一次它推荐我把一个高频调用的同步函数改成异步，结果导致事件循环阻塞加剧（因为没加await）。这提醒我：AI是助手，不是替身。它的输出必须经过人工验证，尤其是在涉及并发、状态管理这类敏感逻辑时。
技术探索的三大误区，我都踩过
Gap期间，我最大的收获不是学了多少新框架，而是看清了自己过去在技术探索上的几个致命误区。
误区一：追求“新技术”，忽视“真问题”
刚裸辞那会儿，我一度沉迷于追新：Llama 3刚发布就急着微调，Sora出来当天就研究视频生成API，LangChain火了就立马搭Agent系统……结果呢？折腾半个月，除了朋友圈发个Demo链接，啥也没留下。
后来我才明白：技术探索的价值不在“用了什么”，而在“解决了什么”。现在我会先问自己三个问题：
- 这个技术能解决我当前某个具体痛点吗？
- 如果不用它，现有方案成本高在哪里？
- 我愿意为它承担维护成本吗？
比如我最近在做的一个个人项目——一个基于向量检索的读书笔记助手。一开始想上全套RAG pipeline，但后来发现，对于单用户场景，直接用SQLite的FTS5全文搜索 + 简单嵌入向量比对就够了。省去了部署Milvus、管理ChromaDB的麻烦，性能也完全够用。
误区二：闭门造车，拒绝协作工具
在大厂时，总觉得用Copilot、Tabnine是“作弊”，只有纯手写代码才叫真本事。结果呢？写个React组件要翻半天文档，配个Webpack能折腾一天。
现在？我恨不得把Claude Code焊在IDE里。它不仅能补全代码，还能解释为什么这么写。比如我写了个防抖函数，它会主动提醒：“你这里没处理this绑定，考虑用箭头函数或.bind(this)”。
更夸张的是，我现在写测试用例都让它先生成草稿。虽然有时候会漏掉边界条件，但至少80%的常规case它能覆盖，我只需要补充剩下的20%。效率提升不止一倍。
误区三：只重实现，不重验证
最惨的一次教训，是我用Claude生成了一个Flask API接口，本地测试完美，结果上线后被安全扫描扫出XSS漏洞——因为它默认没对用户输入做转义。
那次之后，我给自己立了规矩：任何AI生成的代码，必须过三关：
- 静态检查：ESLint / Pylint / SonarQube 扫一遍；
- 单元测试：覆盖率至少80%，关键路径100%；
- 人工走查：特别是涉及IO、权限、加密的部分，必须逐行看。
实战对比：传统开发 vs AI辅助开发
为了量化AI工具带来的改变，我做了个小实验：用两种方式实现同一个功能——一个支持文件上传、OCR识别、结果导出的Web服务。
| 维度 | 传统开发（纯手动） | AI辅助开发（Claude Code + OpenCode） |
|---|---|---|
| 需求分析时间 | 2小时（查文档、画流程图） | 30分钟（让AI总结OCR API文档） |
| 核心编码时间 | 1.5天 | 4小时 |
| 调试时间 | 6小时（各种环境问题） | 1.5小时 |
| 单元测试编写 | 3小时 | 1小时（AI生成初稿） |
| 文档撰写 | 1小时 | 20分钟（AI根据代码生成） |
| 总耗时 | ≈3天 | ≈7小时 |
当然，这个对比有点“不公平”——毕竟我对传统开发流程太熟了。但即便如此，AI在降低认知负荷上的优势是碾压级的。它让我从“如何实现”中解放出来，更多思考“是否值得实现”。
写在最后：技术探索的本质是“保持好奇”
重新找工作这一个月，面了七八家公司，聊得最多的话题不是“你会不会Transformer”，而是“你怎么看待AI对开发者角色的影响”。
我的回答一直是：工具越强大，人的判断越重要。
Claude Code可以帮我写代码，但它无法决定这个功能该不该做；OpenCode能分析项目风险，但它不懂业务背后的权衡。技术探索的终极目标，从来不是掌握多少工具，而是培养一种持续提问、快速验证、勇于推翻的思维习惯。
裸辞这半年，我没挣一分钱，但我觉得值。因为我找回了写代码最初的快乐——不是为了交付需求，而是因为“这个想法很酷，我想试试看”。
下周就要入职新公司了，岗位是AI应用工程师。临走前，我把这半年折腾的小项目打包传到了GitHub，README里写了一句：
“代码或许粗糙，但每行都是亲手敲下的思考。”
共勉。
评论 0