逐浪 · 第二篇：AI把人放大：从半天到一杯咖啡，我不再做“码农”

Hector_zh
0 阅读8分钟

从“码农”到“系统价值设计师”：vibe-coding帮我把LLM调用开发从半天压缩到一杯咖啡

引言

上个月某一天，我还在为容器启动后端口没监听熬到凌晨翻日志；现在，我用vibe-coding在Trae里搭完骨架，剩下的时间都在思考“用户真正需要什么”。

这篇文章记录了我在JiuwenClaw项目中使用AI编程工具的真实体验——不是技术评测，而是一个普通开发者从“写代码”到“设计系统”的转变过程。

核心价值：通过vibe-coding，我将“从0到1实现需求”的时间压缩了80%，从而有更多精力关注系统架构、用户体验和工程规范。

一、vibe-coding改变了什么？

效率的跃迁：从“翻译需求”到“定义意图”

以前做LLM应用，我需要：

  1. 读需求 → 写配置解析 → 封装API调用 → 处理错误重试 → 写单元测试
  2. 这个过程中80%的时间花在“搭架子”上

现在用vibe-coding这种新的开发范式：

  1. 告诉Trae“帮我生成一个Qwen模型调用的配置类，支持环境变量注入”
  2. 它生成代码骨架，包含完整的DashScope SDK调用逻辑
  3. 我花20%时间检查、调整、加业务prompt

最直观的感受：以前从零写LLM调用要半天，现在一杯咖啡的功夫就能搭完。

实际代码示例（AI生成后稍作调整）：

AI_MODEL_NAME = os.getenv("AI_MODEL", "qwen-plus")
AI_API_BASE = os.getenv(
    "AI_API_BASE", "https://dashscope.aliyuncs.com/compatible-mode/v1"
)
AI_DASHSCOPE_API_KEY = os.getenv("DASHSCOPE_API_KEY")
AI_TEMPERATURE = float(os.getenv("AI_TEMPERATURE", 0.0))

核心变化：从“实现者”到“决策者”

vibe-coding不是帮我写代码，而是帮我节省时间去做更有价值的事。

省下来的时间，我用来思考这些问题：

  • 架构层面：容器化部署时，前端服务为什么起不来？是host绑定问题，还是启动脚本根本没调用？
  • 体验层面：科学家用ScienceClaw做实验，流程卡在哪一步？是反馈太慢，还是错误提示看不懂？
  • 安全层面：API Key怎么轮换才不会让正在跑的长任务断掉？
  • 长期演化：今天写的这个Skill，三个月后还能被别的团队复用吗？

这些问题，AI没法替我回答。因为它们不是“代码怎么写”，而是**“系统怎么为人服务”**。

二、我每天的工作流：vibe-coding + agent.md

工具组合

我现在的标配是：

  • Trae/Qoder：快速生成代码骨架
  • vibe-coding：一种轻量级的快速编码方式
  • agent.md：定义AI的行为准则和约束
  • Claude.md：项目级的提示词和规范

实战案例：容器化部署中的“端口迷局”

背景：将JiuwenClaw打包成容器镜像，部署到ARM64服务器。

步骤1：用AI快速生成Dockerfile 在Trae中输入：“帮我生成一个JiuwenClaw的Dockerfile，基于Python 3.11”。

AI生成的Dockerfile用了jiuwenclaw-start作为启动命令——看起来没问题，build成功，容器run起来了。

步骤2：验证时发现问题

curl http://localhost:5174/
Connection reset by peer

步骤3：排查——这里AI帮不了我

# 进入容器检查
docker exec -it jiuwenclaw-container /bin/bash

# 检查端口监听状态
netstat -tulpn | grep 5174
# 输出为空，说明5174端口根本没监听

# 查看进程状态
ps aux | grep python
# 只看到后端进程，前端app_web进程不存在

# 手动执行启动命令观察
jiuwenclaw-start
# 发现只输出了后端和WebSocket启动日志，前端被跳过

根因分析：AI生成的jiuwenclaw-start脚本在容器环境中会检测终端交互性，非交互式环境下会跳过前端服务启动——这是AI不理解"容器环境vs裸机环境"差异的典型表现。

步骤4：解决问题 把Dockerfile的CMD改成显式分别启动前后端：

CMD ["/bin/bash", "-c", "source .venv/bin/activate && python -m app & python -m app_web --host 0.0.0.0 --port 5174 & wait"]

步骤5：用agent.md固化规范 把这次的经验写入agent.md：

# 容器化部署规范
- 禁止直接使用框架提供的“一键启动”脚本
- 必须显式启动所有服务进程
- 必须指定`--host 0.0.0.0`确保容器外可访问
- 容器必须配置健康检查（HEALTHCHECK）

Dockerfile示例（可参考）：

FROM python:3.11-slim

WORKDIR /app

# 安装系统依赖
RUN apt-get update && apt-get install -y --no-install-recommends \
    net-tools \
    && rm -rf /var/lib/apt/lists/*

# 安装Python依赖
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 复制应用代码
COPY . .

# 激活虚拟环境并启动服务
CMD ["/bin/bash", "-c", "source .venv/bin/activate && python -m app & python -m app_web --host 0.0.0.0 --port 5174 & wait"]

# 健康检查
HEALTHCHECK --interval=30s --timeout=3s \
  CMD curl -f http://localhost:5174/health || exit 1

这件事给我的启发：AI可以帮你写Dockerfile，但它不理解“容器环境 vs 裸机环境”的区别。知道哪里可能出问题、怎么排查、怎么把经验固化成规范，才是我的价值。

三、AI的局限性：我踩过的坑

坑1：AI不懂环境差异

场景：让AI生成容器启动命令

问题：AI给的方案在裸机没问题，在容器里就“偷工减料”——因为AI不知道“容器是干净环境，没有交互式终端”。

解决方案：先在本地手动跑通一次，理解每一步在做什么，再让AI生成。AI是你的副驾驶，不是自动驾驶。

坑2：AI生成的代码维护成本高

场景：AI生成了一个复杂的配置解析函数

问题：三个月后我自己都看不懂了——变量命名不一致，错误处理缺失。

解决方案：要求AI遵循统一的命名规范，关键函数必须加注释，并在agent.md里写清楚规范。

坑3：排查问题AI无能为力

场景：Connection reset by peer

问题：AI会说是“网络问题”或“端口被占用”，但实际是启动逻辑缺陷。

解决方案：这时候需要IDE连进容器、看日志、手动执行命令、对比不同环境的差异——IDE的调试能力和工程经验是AI替代不了的。

四、我的竞争力在哪里？

对比：AI vs 我

能力维度AI能做我来做
生成代码片段✅❌
设计系统架构❌✅
排查未知问题❌✅
理解环境差异❌✅
制定工程规范❌✅

核心竞争力：知道AI的边界，并把经验沉淀为规范

我不是“会调AI的人”，而是“懂业务、懂工程、懂环境差异”的系统架构师在驾驭AI。

具体体现在：

  1. 设计边界：用agent.md定义AI的行为准则和约束
  2. 质量兜底：遇到问题能独立排查，不依赖AI的“猜测”
  3. 经验沉淀：把踩坑经历固化成SOP，让整个团队受益

五、给勇于尝试者的行动清单

入门指南

  1. 先学基础：别上来就依赖AI，先掌握基本的编程、调试、容器知识——这是你的底气
  2. 定义规范：在agent.md里写清楚你的代码风格、命名规则、安全约束——这是你的框架
  3. 从小事开始：先用AI生成简单的配置类或API调用代码，慢慢过渡到复杂系统——这是你的起点
  4. 保持怀疑：AI生成的代码一定要在真实环境验证——这是你的底线
  5. 专注价值：把省下来的时间用在思考架构、体验、安全上——这是你的价值

心态转变

从“交付需求”到“交付价值”——而价值，永远是为用户服务的。
勇于尝试不是鲁莽，而是带着敬畏和方法的探索。

总结

vibe-coding改变的不是“写代码的速度”，而是“写代码的意义”。

AI帮我把“从0到1实现需求”的时间压缩到几乎可以忽略，于是我第一次真正成为了一个“系统价值设计师”。

我的竞争力，不在于“会写代码”，而在于：

  • 能看清问题本质：知道哪里可能出问题，而不是等AI告诉你
  • 能独立排查解决：AI帮不了你的时候，你能自己搞定
  • 能沉淀工程规范：把个人经验变成团队资产

最后想说：工具再强大，最终还是要回归到人。技术的进步，应该让我们更专注于创造价值，而不是被工具牵着走。AI是你的副驾驶，但方向盘永远在你手里。

互动时间

你在使用AI编程工具时遇到过哪些坑？欢迎在评论区分享你的故事。

下一篇我计划写「AI生成代码的十大坑及避坑指南」，你最想了解哪类问题？

选题方向简介
环境适配坑Docker/华为云CCE环境差异导致的部署问题
代码质量坑AI生成代码的命名、注释、可维护性问题
安全漏洞坑API Key管理、权限控制、敏感信息泄露
调试排查坑AI无法解决的复杂问题排查思路

请在评论区告诉我你的选择（可以多选），我会根据热度优先写作。

avatar
文章
阅读
粉丝