技术探索不是炫技，是解决问题的耐心
上周五晚上十点半，我还在公司调一个线上诡异的内存泄漏问题。新来的实习生小张在 Slack 上发了个“哥，你咋还没走？”，我回了句“等这个 Pod 稳住就撤”。他秒回：“35 岁还写代码，太卷了吧！”——我差点笑出声，但转念一想，这不就是我现在的状态吗？
入职这家新公司刚满两个月，从上一家大厂裸辞后，本以为能躺平一阵子，结果发现创业公司节奏更快。老板嘴上说“我们要做技术驱动”，实际上每天都在催 MVP 上线。更离谱的是，产品需求文档里居然写着“用 AI 自动化所有运营流程”——行吧，反正我这几年早和 ChatGPT、Claude 成了“数字工友”，Prompt 写得比代码还溜。
今天这篇文章，就想聊聊我对技术探索与实践的真实看法。不是那种“AI 将颠覆一切”的鸡汤，而是作为一个还在敲键盘的老程序员，在求职、架构、日常开发中踩过的坑、攒下的经验。
问题从来不在技术本身，而在“人怎么用”
刚入职那周，CTO 丢给我一个任务：把客服系统的工单处理流程自动化。当前流程是运营同事手动查数据库、复制用户 ID、粘贴到内部工具、再发邮件——一天重复几百次。产品说“我们要用 AI 做智能客服”，但其实他们连基础数据都没结构化。
我第一反应是：别急着上 LLM，先理清楚业务流。于是花了三天时间，和运营小姐姐对齐了 12 种常见工单类型，画了状态机，定义了输入输出格式。这时候我才意识到，真正的瓶颈不是算法，而是 Prompt 工程没做好。
比如，我们最初让模型直接读用户聊天记录，结果它经常把“取消订单”理解成“确认收货”。后来改成结构化输入：
{
"user_id": "u12345",
"last_message": "我不想买了，能退吗？",
"order_status": "paid",
"refund_policy": "7天无理由"
}
再配合精心设计的 system prompt：
“你是一个客服助手，只根据提供的上下文判断是否满足退款条件。若满足，输出 {'action': 'refund', 'reason': '...'}；否则输出 {'action': 'deny', 'reason': '...'}。禁止自行推测或编造信息。”
效果立竿见影。准确率从 60% 提升到 92%。这让我想起去年面试时，有家公司问我：“你怎么看 Prompt 工程？”我当时脱口而出：“它是新时代的接口文档。”现在看来，一点没错。
Moltbot：一个小工具，解决大问题
说到工具，不得不提最近我们团队自研的 Moltbot。名字是我起的，取自“molting”（蜕皮），寓意系统要能不断进化。它的核心目标很朴素：让非技术人员也能安全地使用 AI 能力。
背景是这样的：运营团队想用 AI 生成促销文案，但每次都要找我改 prompt，效率低不说，还容易出错。于是我拉了个小项目，用 FastAPI + LangChain 搭了个 Web 界面，前端用 Vue3（毕竟老前端出身，手痒）。关键设计点：
- 模板化 Prompt：运营只能选预设模板，不能自由输入，避免 prompt injection。
- 输出沙箱：所有 AI 生成内容必须经过规则引擎校验（比如不能包含“最便宜”“绝对”等违禁词）。
- 版本快照：每次生成都记录 prompt + output + model version，方便回溯。
# moltbot/core/engine.py
def generate_copy(template_id: str, variables: dict) -> str:
template = get_template(template_id)
prompt = template.render(**variables) # Jinja2 渲染
# 加入安全围栏
safe_prompt = f"【安全模式】{prompt}\n\n请严格遵守以下规则：..."
response = claude_client.messages.create(
model="claude-3-sonnet",
max_tokens=300,
messages=[{"role": "user", "content": safe_prompt}]
)
return sanitize_output(response.content) # 过滤敏感词
上线两周，运营自己生成了 200+ 条文案，审核通过率 85%。产品经理终于不用半夜微信我“能不能改个 prompt”了。技术探索的价值，不在于用了多新的模型，而在于是否真正嵌入了业务流程。
求职时，别被“AI 工程师”头衔忽悠了
最近帮几个朋友内推，发现一个现象：很多公司 JD 里写着“熟悉 LLM 应用开发”“有 Prompt 工程经验优先”，但实际工作内容还是 CRUD。甚至有家公司，所谓“AI 团队”就是用 OpenAI API 包一层，前端填个表单就叫“智能系统”。
作为过来人，我想说：求职时，一定要问清楚“AI”在你们业务中的真实角色。 是噱头？还是核心链路？有没有数据闭环？模型迭代机制？
我自己跳槽前就列了三个红线：
- 不能只是调 API，要有模型微调或 RAG 的空间；
- 必须有可观测性，不能“黑盒跑就行”；
- 团队得有工程规范，不能全靠 prompt 玄学。
幸运的是，现在这家公司虽然小，但 CTO 本人就是 NLP 博士出身，对技术债零容忍。上周 Code Review 时，他直接 comment：“这段 prompt 逻辑太复杂，拆成两步，加单元测试。”——这种氛围，值了。
架构设计：平衡“快”与“稳”
说到工程规范，就不得不提我们在做 Moltbot 时的架构权衡。初期为了赶 Demo，我直接用 SQLite + 内存缓存，结果压力测试时一并发就崩。运维大哥在群里吐槽：“你这玩意儿上线，K8s 集群怕是要哭。”
痛定思痛，我们做了三件事：
- 异步化：所有 AI 调用走 Celery 队列，前端轮询结果；
- 降级策略：当 Claude 响应超时，自动 fallback 到本地 tinyLLM（量化后的 Phi-2）；
- 监控埋点：记录每个 prompt 的 token 消耗、响应时间、错误率。
下面是性能对比表：
| 方案 | P99 延迟 | 错误率 | Token 成本/千次 |
|---|---|---|---|
| 同步直连 | 2.1s | 8.7% | $12.5 |
| 异步 + 降级 | 1.4s | 1.2% | $9.8 |
| 全本地模型 | 3.8s | 0.3% | $0.0 |
最终我们采用混合方案：简单任务走本地模型，复杂任务走云端。技术探索不是追求“全用最新”，而是找到成本、性能、可靠性的甜点。
写给还在路上的你
有时候我会想，35 岁还在写代码，是不是该焦虑？但看到 Moltbot 被运营用起来，看到自己写的 Prompt 成了公司标准模板，又觉得挺踏实。技术这行，深度比热度重要，解决问题比追新框架重要。
别被“AI 取代程序员”的言论吓到。真正危险的，不是会写代码的人，而是只会写代码、不懂业务、不愿沟通的人。而像我们这样，既懂 Prompt 工程，又能和运营对需求，还能在架构上做权衡的老兵，反而越来越稀缺。
最后送大家一句我贴在显示器边的话：“代码是手段，不是目的。用户的问题，才是你的 KPI。”
下周我要开始搞 A/B 测试模块了，如果顺利，Moltbot 会支持自动对比不同 prompt 的转化率。到时候再写篇续集。哦对了，实习生小张昨天问我：“哥，Prompt 工程要不要学？”我回他：“先学会怎么问问题，再学怎么让 AI 回答问题。”
—— 一个还在加班的 35 岁程序员，凌晨 1 点于工位
评论 0