聊聊我最近折腾的一些技术探索与实践
凌晨两点半，刚把今天公司的需求提完测，顺手把行测题刷了二十道。灌了第三杯美式，脑子反而越来越清醒——这大概就是我这种夜猫子程序员的通病，白天被各种会、各种需求撕扯得稀碎，只有深夜这段时间才真正属于自己。
说来也巧，最近一边准备跳槽一边在公司扛需求，反而逼着我去折腾了不少新东西。今天不聊八股文，也不聊算法题，就随便唠唠我这段时间在技术探索上的一些实践和踩坑经历。
被产品经理逼出来的"全栈梦"
事情要从上个月说起。产品经理跑过来说："哥，能不能搞个内部工具的原型，快速验证一下想法？不用太精细，能跑就行。"
我当时心里一万头草泥马奔腾——我后端都写不完，你让我搞前端原型？但转念一想，这不正好试试最近很火的那个 AI 编程工具嘛。
于是我开始研究 Lovable 这个东西。说实话，一开始我是带着怀疑态度的。作为一个喜欢扒底层原理的人，我对这种"一句话生成应用"的工具天然不信任。但你别说，实际用下来还真有点东西。
我的场景是这样的：需要一个内部的数据看板原型，能展示一些业务指标，支持简单的筛选和导出。传统做法是拉个前端同事一起搞，排期少说两周。但用 Lovable，我大概花了两个小时就弄出了一个能跑的 demo。
// 我给 Lovable 的 prompt 大概是这样的：
// 帮我创建一个数据看板页面
// 顶部是四个指标卡片：日活、留存率、转化率、GMV
// 中间是一个折线图展示近7天趋势
// 底部是一个数据表格，支持按日期筛选和导出CSV
// 风格参考 Ant Design，配色用蓝色系
它直接给我生成了一套 React + Tailwind 的页面代码，组件拆分得还算合理。我拿过来微调了一下接口对接的部分，基本就能用了。
但这里要说说我踩的坑。Lovable 生成的代码，说实话"能看但不能完全看"。有几个问题让我这个代码洁癖患者很难受：
- 状态管理比较随意：它喜欢用一堆
useState堆在一起，没有做合理的拆分和抽象 - 样式有冗余：Tailwind 的 class 经常重复，有些可以提取成公共组件的地方没提取
- 类型定义不够严谨：很多地方用了
any，这在 TypeScript 项目里是不能忍的
所以我的实践心得是：Lovable 适合快速出原型、验证想法，但别直接把它生成的代码丢到生产环境。正确的姿势是拿它生成的代码当"脚手架"，然后自己重构一遍。这也算是物尽其用了。
| 场景 | 推荐度 | 说明 |
|---|---|---|
| 快速原型验证 | ⭐⭐⭐⭐⭐ | 真的快，小时级别出 demo |
| 内部小工具 | ⭐⭐⭐⭐ | 需要自己改改细节 |
| 正式业务项目 | ⭐⭐ | 代码质量和架构都需要大改 |
| 学习新技术栈 | ⭐⭐⭐ | 可以当参考，但别全信 |
深夜写代码的最佳搭档
说完 Lovable，再聊聊我最近离不开的另一个工具——Continue。
作为一个习惯深夜写代码的人，效率就是我的命。之前用 Copilot 用得好好的，但公司网络环境你懂的，有时候连 GitHub 都费劲，更别提 Copilot 那种需要持续连接的服务了。
后来在掘金上看到有人推荐 Continue，说是可以本地部署、支持多种模型、还能接入公司内部的代码库。我一听就来劲了——这不就是为我这种喜欢折腾底层的人量身定做的嘛。
花了半个晚上把 Continue 装好，接入了本地的 Ollama 跑 CodeLlama，又配了一下公司的 GitLab 让它能读取项目上下文。第二天上班一试，好家伙，代码补全的准确率比 Copilot 还高，因为它能理解我们项目的业务逻辑和命名规范。
// continue 的核心配置，放在 .continue/config.json
{
"models": [
{
"title": "CodeLlama Local",
"provider": "ollama",
"model": "codellama:13b",
"apiBase": "http://localhost:11434"
},
{
"title": "GPT-4 via Company Proxy",
"provider": "openai",
"model": "gpt-4",
"apiBase": "https://internal-proxy.company.com/v1",
"apiKey": "sk-xxxx"
}
],
"tabAutocompleteModel": {
"title": "StarCoder Local",
"provider": "ollama",
"model": "starcoder:7b",
"apiBase": "http://localhost:11434"
},
"contextProviders": [
{ "name": "code" },
{ "name": "docs" },
{ "name": "git" }
],
"customCommands": [
{
"name": "review",
"description": "Review selected code",
"prompt": "Please review the following code for potential bugs, performance issues, and code style problems:\n\n{{{CODE}}}"
},
{
"name": "explain",
"description": "Explain selected code",
"prompt": "Explain the following code in detail, including the design patterns used and potential improvements:\n\n{{{CODE}}}"
}
]
}
这里分享几个我摸索出来的最佳实践：
第一，本地模型和云端模型混着用。 简单的代码补全、自动填充这种高频低延迟的需求，用本地跑的 StarCoder，响应快、不费钱。但遇到复杂的代码生成、架构设计这种需要深度理解的需求，切到 GPT-4，质量明显高一截。
第二，善用自定义命令。 我配了 review 和 explain 两个命令，选中一段代码直接调用。尤其是 review，上周帮我抓出来一个隐蔽的空指针问题——那个 bug 要是上线了，周五晚上的 oncall 电话能把我的美梦打碎。
第三，让它读你的项目文档。 Continue 支持把项目文档作为上下文，我把团队的编码规范、API 文档都喂进去了。现在它生成的代码风格跟我们团队高度一致，省了我不少 review 的时间。
深夜 debug 的一个小插曲
说到这，想起上周四凌晨的一个事。
那天晚上我在研究一个并发问题，线上偶尔会出现数据不一致的情况。排查了两个小时没头绪，心态有点崩。然后我灵机一动，把相关的代码段丢给 Continue，让它帮我分析可能的并发问题。
它居然真的指出来了——是一个 HashMap 在并发场景下没加锁的问题。我当时的反应是："就这？我咋没想到？"
后来仔细一想，其实我不是不知道 HashMap 非线程安全，而是连续看了两小时代码，脑子已经糊了，形成了思维盲区。AI 这时候就像一个不知疲倦的旁观者，能帮你跳出自己的思维定式。
最终我把 HashMap 换成了 ConcurrentHashMap，又加了一些必要的同步逻辑，问题解决了。提测通过的那天早上，我难得睡了个好觉。
一些掏心窝子的话
折腾了这么多，说点我的感悟。
作为程序员，我们很容易陷入一种"工具焦虑"——今天出个新框架，明天出个新工具，不学就感觉要被淘汰。但我觉得，工具永远只是工具，核心还是你对问题的理解和解决能力。
Lovable 再强大，它也不懂你们公司的业务逻辑；Continue 再智能，它也不能替你做架构决策。这些工具的价值在于，它们能帮你把那些重复的、机械的工作自动化掉，让你把精力集中在真正需要思考的地方。
就像我，白天要应付各种需求、开会、对接口，晚上还要刷题准备跳槽。时间是真的不够用。但这些工具确实帮我提了不少效——原型出得快了，代码写得顺了，debug 也有帮手了。多出来的时间，我可以多刷几道题，多看看源码，为跳槽多做点准备。
对了，说到跳槽，最近面试了几家，发现面试官对候选人的"技术视野"越来越看重了。不是要你精通多少框架，而是看你能不能快速学习新东西、能不能把合适的工具用在合适的场景。所以平时多折腾折腾这些新工具，面试的时候也能多些谈资。
行了，快三点了，明天还得早起开晨会。最后把今天的 LeetCode 每日一题刷了就去睡。希望这篇文章对正在折腾类似工具的朋友有点帮助，少走点弯路。
共勉，打工人。
评论 0