背着房贷的我，靠AI写作和工具调用搞出了一套技术探索方法论
凌晨两点半，成都的夜风从窗户缝里钻进来，有点凉。我揉了揉发酸的眼睛，看了一眼屏幕右下角的时间，又瞥了一眼手机上的房贷还款提醒——距离下次扣款还有8天。
叹了口气，灌了口已经凉透的咖啡，继续敲代码。
先自我介绍一下吧，我是一个在成都某中型互联网公司做后端的程序员，主攻云原生和K8s方向。去年咬牙在天府新区买了套小三居，从此背上了三十年的房贷。为了还房贷，我基本上告别了所有娱乐活动，唯一的爱好就是深夜写代码——没办法，白天要开会、要对需求、要跟产品经理扯皮，只有夜深人静的时候才能安安静静写点自己想写的东西。
今天这篇文章，想跟大家聊聊技术探索与实践这个话题。为什么聊这个？因为上周五我们组开技术复盘会，leader说了一句让我印象深刻的话："你们不能天天只写业务代码，要有自己的技术探索和实践输出。"
当时我心里是有点抵触的——房贷都快还不上了，哪有时间搞技术探索？但后来仔细想想，不搞技术探索，过两年是不是就真被淘汰了？到时候房贷怎么办？
所以这篇文章，算是我给自己的一份"技术探索方法论"，也希望能给同样在挣扎的兄弟们一些参考。
被逼出来的技术探索
说实话，我以前对"技术探索"这四个字是有点抵触的。
你想啊，白天要写业务代码，晚上要处理线上告警，周末还要陪女朋友看房子（虽然已经买了但总想置换），哪有时间探索？而且说实话，很多技术探索最后都变成了"写个demo然后扔在GitHub上吃灰"，投入产出比太低了。
但转折点发生在去年双11。
当时我们有个核心服务需要重构，leader让我调研一下新的方案。我花了一周时间，看了无数博客、论文、开源项目，最后写了一份50页的PPT。结果评审会上，隔壁组的架构师问了一个问题："你在生产环境跑过吗？"
我愣住了。没有。
那份PPT最后被打回来重做。这件事给了我很大的触动——技术探索不能只停留在纸面上，必须落地实践。
从那以后，我给自己定了一个规矩：每次技术探索，必须有一个可运行的demo，最好能跑在真实的K8s集群里。
我的技术探索三板斧
经过大半年的摸索，我总结了一套自己的技术探索方法论，姑且叫它"三板斧"吧。
第一斧：用AI写作快速建立知识框架
这里说的AI写作，不是让AI帮你写文章去骗流量，而是用AI工具辅助你快速学习和整理知识。
举个真实的例子。上个月我想研究一下K8s的Gateway API，发现官方文档又长又散，社区博客质量参差不齐。如果从头到尾自己啃，至少得两三天。
我的做法是：先把官方文档喂给AI（别问我用的什么工具，反正不是某度），然后让它帮我梳理出核心概念、关键流程、与传统Ingress的对比。大概半小时，我就对整个Gateway API有了一个比较清晰的认知框架。
然后我会基于这个框架，去源码里验证。这一步很关键——AI给你的知识可能是有偏差的，必须自己验证。
// 这是我写的一个简单的Gateway API验证demo
// 用来测试HTTPRoute的路由规则
package main
import (
"context"
"fmt"
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
gatewayv1 "sigs.k8s.io/gateway-api/apis/v1"
gatewayClient "sigs.k8s.io/gateway-api/pkg/client/clientset/versioned"
)
func createHTTPRoute(ctx context.Context, client gatewayClient.Interface) error {
route := &gatewayv1.HTTPRoute{
ObjectMeta: metav1.ObjectMeta{
Name: "test-route",
Namespace: "default",
},
Spec: gatewayv1.HTTPRouteSpec{
CommonRouteSpec: gatewayv1.CommonRouteSpec{
ParentRefs: []gatewayv1.ParentReference{
{
Name: "my-gateway",
},
},
},
Rules: []gatewayv1.HTTPRouteRule{
{
Matches: []gatewayv1.HTTPRouteMatch{
{
Path: &gatewayv1.HTTPPathMatch{
Type: pathPrefixPtr(),
Value: strPtr("/api"),
},
},
},
BackendRefs: []gatewayv1.HTTPBackendRef{
{
BackendRef: gatewayv1.BackendRef{
BackendObjectReference: gatewayv1.BackendObjectReference{
Name: "api-service",
Port: portPtr(8080),
},
},
},
},
},
},
},
}
_, err := client.GatewayV1().HTTPRoutes("default").Create(ctx, route, metav1.CreateOptions{})
return err
}
这段代码本身不复杂，但通过写这个demo，我真正理解了HTTPRoute的spec结构、ParentRefs的引用关系、以及BackendRef的配置方式。这比看十篇博客都管用。
第二斧：工具调用打通全链路
光有知识框架还不够，技术探索的另一个关键是能跑起来。
这里我特别想说说"工具调用"这个概念。在技术探索中，我说的工具调用不是指LLM的function calling（虽然那个也很重要），而是指如何高效地调用各种工具链来完成端到端的验证。
比如我要探索一个微服务治理的方案，我的工具链是这样的：
| 环节 | 工具 | 用途 |
|---|---|---|
| 代码编写 | VSCode + Copilot | 写代码、补全、解释 |
| 本地调试 | kind/minikube | 本地K8s集群 |
| 镜像构建 | buildah | 无daemon构建 |
| 部署 | kubectl + kustomize | 声明式部署 |
| 监控 | Prometheus + Grafana | 可观测性 |
| 链路追踪 | Jaeger | 分布式追踪 |
| 压测 | hey/vegeta | 性能测试 |
关键是要把这些工具串起来，形成一条自动化的pipeline。我写了一个简单的Makefile来管理这个过程：
# 技术探索项目的标准Makefile
.PHONY: setup test deploy observe clean
# 一键拉起本地K8s环境
setup:
@echo "==> 创建kind集群..."
kind create cluster --name tech-explore --config kind-config.yaml
@echo "==> 安装基础组件..."
kubectl apply -k ./manifests/base/
@echo "==> 等待组件就绪..."
kubectl wait --for=condition=ready pod -l app=jaeger -n observability --timeout=120s
# 构建并部署测试服务
deploy:
@echo "==> 构建镜像..."
buildah bud -t tech-explore/app:latest .
@echo "==> 加载到kind集群..."
kind load docker-image tech-explore/app:latest --name tech-explore
@echo "==> 部署服务..."
kubectl apply -k ./manifests/overlays/dev/
# 运行测试
test:
@echo "==> 运行单元测试..."
go test ./... -v -cover
@echo "==> 运行集成测试..."
go test ./test/integration/... -v
# 启动可观测性面板
observe:
@echo "==> 端口转发Grafana..."
kubectl port-forward -n observability svc/grafana 3000:3000 &
@echo "==> 端口转发Jaeger..."
kubectl port-forward -n observability svc/jaeger-query 16686:16686 &
# 清理环境
clean:
kind delete cluster --name tech-explore
有了这套工具链，我每次技术探索的效率提升了至少一倍。以前搭个环境要大半天，现在一条命令搞定。省下来的时间，就可以更深入地去研究核心问题了。
第三斧：输出倒逼输入
这一条其实是最重要但也最容易被忽略的。
很多程序员（包括以前的我）都有一个毛病：学了新东西，觉得自己懂了，然后就扔一边了。过两个月再遇到，又得重新学。
我的做法是：每次技术探索结束后，必须输出一篇技术文章或者一个可复用的脚手架项目。
这里又回到AI写作了——我会用AI工具帮我整理文章结构、润色表达、检查技术术语的准确性。但核心观点、代码示例、踩坑记录，必须是自己写的。AI是辅助，不是替代。
举个实际的例子。上个月我研究K8s的Operator开发，最后输出了一篇8000字的技术文章和一个基于kubebuilder的脚手架项目。这篇文章发在团队内部的知识库里，后来成了新人入职的必读材料。leader在季度评审的时候还专门提了一嘴，说我这个"技术沉淀做得不错"。
嘿嘿，虽然没涨工资，但至少年终绩效多拿了0.1，算下来也能多还几个月房贷了。
踩过的坑，都是交过的学费
说了这么多方法论，也得跟大家分享一下我踩过的坑，免得兄弟们重蹈覆辙。
坑一：贪多嚼不烂
刚开始搞技术探索的时候，我恨不得把所有热门技术都学一遍。今天看Rust，明天搞WebAssembly，后天又去研究eBPF。结果一个月下来，啥都没学明白。
后来我想通了——技术探索要聚焦。我给自己定了一个原则：每个季度只深入一个方向。比如这个季度就是K8s的网络模型，下个月可能是Service Mesh。
坑二：只看不练
这个坑前面其实已经提过了，但还是要强调。看十遍文档不如写一遍代码。尤其是云原生这个领域，很多概念（比如CNI、CSI、CRI）光看文档是理解不了的，必须自己动手写一写、调一调。
我之前研究CNI的时候，自己写了一个简单的CNI插件，虽然功能很简陋，但通过这个过程，我真正理解了容器网络是怎么配置的。那种"哦原来如此"的感觉，是看多少博客都换不来的。
坑三：忽视生产环境
这一点是很多技术探索者容易忽略的。你在本地kind集群里跑得欢，不代表上了生产环境就没问题。
我有一次探索K8s的HPA（水平自动伸缩），在本地测试一切正常。结果推到预发环境，发现因为资源quota的限制，HPA根本扩不出来。当时差点酿成线上事故，还好被运维老哥及时发现了。
从那以后，我每次技术探索都会尽量在接近生产环境的条件下进行。没有条件？那就自己搭一个。反正kind集群又不花钱（好吧，花的是我的时间和头发）。
一些实用的建议
最后，给想做技术探索但又觉得没时间（或者被房贷压得喘不过气）的兄弟们一些建议：
1. 利用碎片时间
我每天早上会提前半小时到公司，利用这段时间看看技术文章、整理笔记。晚上回家等女朋友看完剧，我再花一个小时写代码。周末？周末我要陪女朋友，别想了。
2. 跟工作结合
最好的技术探索是跟工作结合的。比如你工作中需要用到消息队列，那就可以深入研究一下Kafka的底层原理，然后输出一个最佳实践文档。这样既提升了工作质量，又完成了技术探索，一举两得。
3. 找搭子
一个人搞技术探索很容易放弃。我拉了组里两个同事一起，每周搞一次技术分享，轮流做主讲。有了社交压力（不是），就有了持续输出的动力。
4. 别追求完美
技术探索不是写论文，不需要面面俱到。把一个点讲透，比泛泛而谈十个点有价值得多。我很多文章都是"半成品"，但我觉得把核心问题讲清楚了就行。
写在最后
写到这里，已经凌晨四点了。窗外的成都已经安静下来，偶尔能听到远处传来的几声狗叫。
说实话，背着房贷搞技术探索确实挺累的。有时候我也会想，这么拼到底值不值？但每次解决了一个技术难题、写出一篇满意的文章、或者在团队分享时看到同事们点头认可的眼神，我就觉得——还行，没那么亏。
技术这条路，不进则退。与其焦虑被淘汰，不如主动去探索、去实践。哪怕每天只进步一点点，一年后回头看，也会发现自己已经走了很远。
好了，不说了，我得把这个demo跑通，明天还要给leader演示呢。如果跑不通的话……那就今晚通宵吧，反正房贷又不会等我睡醒了再扣。
共勉。
评论 0