AI时代别做John Henry：从拼体力到拼指令的工程实践

John Henry 的故事美国劳工阶层几乎人人知晓他是一名铁路隧道掘进工人靠一柄大锤和自己的身体与新发明的蒸汽钻孔机比赛凿岩。他赢了那场比赛然后力竭倒下。这个一百多年前的民间传说在 AI 时代被反复提起原因很简单当大模型已经能写代码、写文案、画图、配乐、剪辑视频、做数据分析时大量工程师和内容创作者开始不自觉地把自己代入 John Henry 的角色——跟 AI 比手速、比产量、比谁更能“肝”。但问题恰恰就在这里John Henry 的结局不是胜利后的荣光而是体力耗尽。这篇文章不是讲民间故事而是想把这个寓言当作一条工程实践的线索来用。AI 时代的正确姿势不是用自己的血肉之躯去和“蒸汽机”硬碰硬而是学会驾驶蒸汽机。放到今天就是学会用 AI 编程工具、理解大模型的能力边界和幻觉风险、搭建属于自己的 AI 工作流甚至把本地模型部署、API 调用、批量任务变成普通工程师也能掌握的日常技能。下面会分几个部分展开先解读 John Henry 寓言在 AI 时代的技术含义再谈从“拼体力”到“拼指令”的能力转向然后重点讲 AI 编程、AI 工程落地、接口服务和批量任务的实际做法最后给一份合规边界、常见误区排查和行动清单。建议收藏备用后面按步骤实操。1. John Henry 寓言与 AI 时代的技术隐喻1.1 故事原型与三个教训原版传说中John Henry 是隧道工程的钻孔工蒸汽钻孔机被引入工地后工人们担心失业。John Henry 接受挑战用自己的锤子与机器对凿最终他领先机器完成钻孔但自己也因过度劳累倒下。这个故事第一次提出一个技术伦理模型当自动化工具进入生产流程时人的位置在哪里把这个模型映射到 2025 年的 AI 时代可以提炼出三个教训。第一个教训是“不要拿自己最弱的部分去比机器最强的部分”。John Henry 用血肉之躯和机器比持久力这本身就是一场不对称战争。今天的工程师如果试图用纯手写代码的速度去对抗 AI 生成代码的速度同样是在打一场必输的仗。第二个教训是“工具的推广不可逆”。蒸汽钻孔机不会因为 John Henry 赢了就退出工地。同样AI 编程工具不会因为部分开发者抵触就从 IDE 里消失。与其停留在情绪层面不如把精力放在如何让工具为人服务。第三个教训是“比赛规则是可以被改写的”。John Henry 的悲剧在于他接受了别人设定的赛道。放到 AI 时代赛道不是“谁写代码更快”而是“谁能定义问题、拆解任务、验证结果、守住质量底线”。这些能力恰恰是大模型短期难以完整替代的。1.2 人机关系的三种模式从实际操作看人和 AI 的关系可以分为三种模式替代模式AI 直接完成原本由人执行的重复性任务例如批量整理文本、图像分类、字幕转录。这个模式下人主要是验收者。辅助模式AI 提供初稿、建议、代码片段人来决策、修改、负责最终质量。这是当前大多数内容生产和软件开发的主流模式。协同模式AI 作为团队中的“初级员工”人负责拆解目标、分配子任务、审核中间产物、迭代优化。这个模式更接近 AI Agent 的工作方式。三种模式不是迭代关系而是按任务复杂度和风险等级选择的。写一篇内部会议纪要可以用替代模式写一段对外发布的合同条款就必须用辅助甚至协同模式由专业的人做终审。1.3 为什么现在重提 John Henry现在重提 John Henry直接原因是 AI 编程工具和 AI Agent 的可用性已经进入“工程化”阶段。过去 AI 只能聊天现在它能通过 API 被集成到业务系统里能批量处理文件能在明确指令下完成多步骤任务。这个变化意味着它不是聊天玩具而是一个可以进生产环境的生产力组件。真正的风险不是 AI 取代人类而是“会使用 AI 的人”逐步取代“不会使用 AI 的人”。这和 John Henry 故事的本质高度一致杀死他的不是蒸汽机而是他拒绝理解蒸汽机的运行逻辑只把它当成一个必须打败的对手。2. 从“拼体力”到“拼指令”AI 时代的能力转向2.1 能力的重新定价十年前技术面试考的是“你会不会写某个算法”五年前考的是“你知不知道某个框架”现在很多团队在悄悄考察“你能不能通过 AI 快速产出高质量原型并且发现它哪里错了”。这不是说基础知识不重要。恰恰相反基础越扎实越能判断 AI 输出是否正确。AI 时代的能力模型中指令设计能力、结果验证能力、工程落地能力正在追上纯粹的编码速度成为新的定价因子。2.2 核心能力速览能力项说明门槛典型工具/方法提示词编写把模糊需求转成清晰指令低但不等于没技巧结构化 Prompt、Few-shot 示例AI 编程协作让模型生成代码、修改代码、写测试中需要代码评审能力AI 编程插件、AI 编程助手API 集成把模型封装成服务供业务调用中需要接口开发经验REST API、Python SDK本地模型部署在自有机器上跑开源模型中高关注显存与推理速度推理框架、模型量化批量任务设计大量文件/文本/图片的自动处理中需要队列与容错设计脚本、任务队列、失败重试结果评估判断模型输出是否可信高依赖领域知识人工审核、自动评测集表中每一项都不是“会按按钮”就行核心都在工程化能不能稳定复现、能不能处理异常、能不能控制成本、能不能守住合规底线。2.3 没有机器不可怕可怕的是不会开机器回到 John Henry 的隐喻蒸汽钻孔机本身不淘汰工人淘汰工人的是“会用蒸汽钻孔机的包工头”。AI 时代也一样大模型本身不会让程序员集体失业但大量愿意学习 AI 编程工具的初级开发者会在产出效率上明显超过不愿意学习的人。这里的建议很直接不要在家里囤教程先在一台机器上把环境跑通。无论是调用云端 API还是本地部署一个开源模型先让第一行代码产生输出。3. AI 编程实践让大模型当你的“结对程序员”3.1 先明确 AI 编程能做什么AI 编程工具的能力边界可以从四个维度看代码生成根据自然语言描述生成函数、脚本、配置文件。代码解释阅读别人写的代码输出结构说明。代码修改针对已有代码做重构、加注释、修 bug。测试生成根据需求生成单元测试和 mock 数据。这四个能力里最值得在日常工作中反复使用的是“代码修改”和“测试生成”。因为生成全新代码容易引入隐蔽错误而修改和测试往往有明确上下文结果更容易验证。3.2 完整示例用 AI 生成一个批量重命名脚本假设我现在有一批文件需要把文件名中的日期格式从20250101_report.txt改成2025-01-01_report.txt。我可以用下面的提示词让 AI 生成脚本我有一批文件放在 ./data 目录下文件名格式是 20250101_report.txt 需要改成 2025-01-01_report.txt即把 8 位日期中间加上横线。 请写一个 Python 脚本支持 dry-run 模式 只打印将要修改的文件名不实际重命名。 要求使用 pathlib 和 re 模块不要安装额外依赖。AI 可能会输出类似下面的脚本import re from pathlib import Path def rename_files(data_dir: str ./data, dry_run: bool True): pattern re.compile(r^(\d{4})(\d{2})(\d{2})_(.*)$) for filepath in Path(data_dir).iterdir(): if not filepath.is_file(): continue match pattern.match(filepath.name) if not match: continue year, month, day, rest match.groups() new_name f{year}-{month}-{day}_{rest} new_path filepath.with_name(new_name) print(f{filepath.name} - {new_name}) if not dry_run: filepath.rename(new_path) if __name__ __main__: rename_files(dry_runTrue)注意我不能保证 AI 在所有情况下都会输出这段精确代码不同模型、不同上下文会产生不同结果。但无论输出什么都需要人工检查三点正则是否覆盖边界情况、目录遍历是否正确、dry-run 逻辑是否能防止误操作。3.3 提示词里的工程化思维要让 AI 生成更可靠的结果提示词应该包含以下信息任务目标要做什么输入是什么输出是什么。技术约束语言、框架、是否允许额外依赖。运行环境操作系统、Python 版本、路径结构。异常处理文件不存在、格式不符时怎么办。验证方式是否需要 dry-run、是否需要日志。一个常见误区是只写一句话“帮我写一个重命名脚本”AI 会假设一堆默认条件结果往往不能直接运行。把约束写清楚看起来多花了 30 秒实际能省下半小时的调试时间。3.4 人机协作的正确闭环AI 编程不是“AI 写人提交”而是一个迭代闭环人拆解需求定义验收条件。AI 生成初稿。人在本地运行观察报错和输出。把报错信息原样回传给 AI要求修复。重复 2 到 4 轮直到功能符合要求。人补充测试用例验证边界条件。代码评审后合入主分支。这个流程里AI 扮演的是“响应速度很快的初级工程师”而你是“架构师 测试 评审”。质量责任始终在人这一侧。4. AI 工程落地从原型到稳定流程4.1 先跑通最小闭环不管是做内容生成工具还是做代码助手第一次接入大模型的时候不要一上来就设计复杂架构。先跑通一个最小闭环拿一条输入调用模型拿到输出打印出来。如果调用的是云端 API最简示例大概是这样的import requests url https://your-endpoint.example.com/v1/chat/completions headers { Authorization: Bearer YOUR_API_KEY, Content-Type: application/json } payload { model: your-model-name, messages: [ {role: user, content: 用一句话解释什么是线程池} ], temperature: 0.7 } response requests.post(url, jsonpayload, timeout60) print(response.status_code) print(response.json())这段代码里的接口地址、模型名、API Key 都需要按实际服务替换。不要照抄就跑更不要把自己真实的 API Key 提交到公开仓库。4.2 本地模型部署的思路如果数据敏感、离线运行、或者需要长期高频调用本地部署开源模型是更稳的方案。本地部署需要关注的几个维度硬件GPU 显存大小决定能跑多大的模型没有 GPU 也可以跑小模型但速度会慢很多具体占用需按实际模型版本测试。推理框架不同框架对模型格式和量化支持不同启动命令也完全不同。模型文件从模型托管平台下载后需要放到约定目录路径不要有中文和空格。端口管理WebUI 或 API 服务默认端口可能冲突启动前先确认端口占用。一个通用的启动思路是# 示例命令具体参数以项目文档为准 python run_model_server.py \ --model_path /models/your-model \ --port 8000 \ --device cuda无论用哪个框架都要先读项目文档里的“Quick Start”不要凭经验猜测。4.3 接口 API 与批量任务模型服务启动后通常会暴露一个 HTTP 接口接受请求并返回推理结果。批量任务的核心不是“把文件循环跑一遍”而是要考虑输入来源从目录读取、从数据库读取、还是从消息队列消费。并发控制同时发送多少个请求避免把显存打满或触发限流。失败重试网络超时、模型报错、输出格式不符合预期都需要重试策略。结果落盘每条任务完成后输出文件、日志、状态都要有记录。一个相对稳妥的批量任务伪代码如下import time from pathlib import Path input_dir Path(./inputs) output_dir Path(./outputs) output_dir.mkdir(exist_okTrue) max_retries 3 for input_file in input_dir.glob(*.txt): result None for attempt in range(max_retries): try: result call_model_api(input_file.read_text(encodingutf-8)) break except TimeoutError: print(ftimeout: {input_file.name}, attempt{attempt 1}) time.sleep(2 ** attempt) if result is None: print(ffailed: {input_file.name}) continue output_file output_dir / f{input_file.stem}_result.txt output_file.write_text(result, encodingutf-8) print(fdone: {input_file.name})这段代码体现了批量任务最基本的三个要素遍历输入、失败重试、结果落盘。实际生产环境会更复杂但这个骨架足够作为起点。4.4 生产环境的几条红线不要让 API Key 出现在前端页面或公开代码库里。接口服务要限制访问范围至少加上简单的鉴权不能裸奔在公网。涉及用户隐私数据时优先本地化处理不要随意把数据发给第三方模型服务。批量任务要加日志任务失败时能定位到具体输入和具体原因。5. 合规与安全边界John Henry 不能踩的线5.1 版权风险用 AI 生成代码和内容时版权问题必须提前考虑。开源模型、商用模型的授权协议不同训练数据里可能包含受版权保护的内容生成结果也可能与已有内容高度相似。发布或商用前要做必要的效果复核。5.2 隐私与肖像、声音授权涉及人脸、声音、私人信息的内容必须确认授权。比如给人换脸、克隆声音、用他人形象做数字人这些动作如果没有明确授权可能同时涉及肖像权、声音权、个人信息保护等多重法律风险。测试环境里自己合成自己的形象可以但不要随意拿他人素材做类似实验。5.3 数据安全不要把身份证号、银行卡、病历、企业未公开代码等敏感信息直接粘贴到在线 AI 对话框里。正确的做法是先脱敏再喂给模型或者直接在本地部署模型让数据不出内网。5.4 内容发布责任AI 生成内容不代表发布者可以免责。无论内容由人写还是由 AI 生成发布者都要对内容的真实性、合法性负责。AI 出现幻觉、编造引用来源、生成虚假新闻时发布者不能以“这是 AI 说的”为理由推卸责任。6. 常见误区与排查思路6.1 三个典型认知误区误区一AI 能完全替代程序员。实际情况是AI 能生成代码但很难独立承担需求分析、架构设计、故障排查和责任归属。把 AI 当结对程序员用效率提升明显把 AI 当“不要工资的全栈员工”用大概率会翻车。误区二模型越大越好。大模型效果通常更好但硬件成本、推理延迟、部署复杂度也会成倍增加。先想清楚业务场景内部知识库问答、代码生成、文本分类、语音转写需求不同最优模型选择也不同。不要为了参数数量而忽略成本。误区三不想学提示词直接躺平。提示词不是玄学它只是一种用自然语言描述需求的能力。这种能力可以通过刻意练习获得同样也需要不断迭代。认为自己“不需要学”的人实际上是把判断和试错成本都转嫁给了 AI结果往往不可控。6.2 常见问题排查表问题现象可能原因排查方式解决方案接口调用报 401API Key 缺失、过期或权限不足检查请求头中的鉴权信息重新生成 Key确认环境变量已正确配置请求超时输入过长、服务负载过高、网络不稳查看服务日志和访问记录缩短输入文本增加超时时间做重试生成内容出现明显事实错误模型幻觉或上下文信息不足对比原始材料检查 Prompt 是否包含足够事实补充背景信息要求模型基于给定材料回答本地模型推理很慢CPU 推理、显存不足、模型未量化查看 GPU 利用率与显存占用换推理框架启用量化或降低输入长度WebUI 页面打不开端口被占用或服务未启动检查日志和监听端口换端口或重启服务批量任务中途卡住某个文件格式异常、接口返回异常查看任务日志定位失败文件增加异常捕获和失败重试代码生成不能直接运行环境依赖缺失或需求描述不完整阅读报错信息回传给 AI安装依赖补充运行环境信息输出质量不稳定随机采样参数设置不当对比多次结果降低 temperature固定随机种子使用确定性参数这张表不是万能药核心思路是先定位是输入问题、环境问题、还是模型问题再对症下药。6.3 如何判断 AI 输出是否可靠一个实用技巧是让 AI 给出“它能被验证的理由”。比如生成代码时要求它同时输出测试用例和预期运行结果生成文案时要求它列出事实来源做数据清洗时要求它对异常数据做统计输出。越是可以被自动或手动验证的任务越适合交给 AI越是依赖主观判断和责任的环节越要留给人来把控。7. 给不同角色的 AI 行动清单7.1 开发者的行动清单选一个主流 AI 编程助手在真实项目里用一周重点体验代码补全和代码解释。建立自己的提示词模板库把重复性任务的优秀 Prompt 沉淀下来。学会看模型输出的错误信息并把它反馈给 AI 进行迭代修复。在本地搭建一个最小模型推理环境跑通一次完整的文本生成流程。7.2 产品与技术负责人的行动清单先梳理业务链路里哪些环节是“高重复、低风险”的优先用 AI 提效。为团队制定 AI 工具使用规范和敏感数据边界。建立“人工复核”机制尤其是对外发布的内容。关注 AI 应用的真实成本不只看效果还要看失败率、返工率和运维成本。7.3 内容创作者的行动清单用 AI 做选题扩展、大纲整理、初稿润色但最终表达和观点必须自己负责。涉及真实人物、真实事件时用可靠的资料交叉验证。图片、视频、声音类内容确认素材来源和授权情况。保留创作过程中的修改记录便于复盘和版权证明。7.4 管理者的行动清单不要把“团队是否用 AI”当作 KPI而是看“产出质量和人效是否真实提升”。为团队购买合规的工具和模型服务避免让个人偷偷用不明渠道的工具。组织内部培训和经验分享把成功案例复制到其他项目。接受 AI 时代的流程变化把人力重新配置到更需要判断力的岗位。8. 总结成为驾驭机器的人重新回到 John Henry他最大的遗憾不是输给机器而是把自己定位成机器的对手。AI 时代也是如此真正值得投入的方向不是和模型的生成速度较劲而是学会定义问题、设计指令、验证结果、守住质量和合规底线。最先应该验证的功能是在你的日常工作中找一件重复性强、规则明确的小事比如批量格式整理、代码补全、摘要生成把它用 AI 完整跑一遍。最容易踩的坑是拿到 AI 输出后不做验证就发布或提交等到出了问题才发现责任无法推卸。后续的扩展方向可以从单次调用走向稳定服务封装接口、增加鉴权、设计批量任务队列、接入监控和日志。当你不再把 AI 当成聊天窗口里的一个“回复”而是当成一个可以被工程化调用的组件时你就已经走出了 John Henry 的赛道站在了驾驶座这一侧。