John Henry 的故事发生在 19 世纪的美国铁路工地他是凿岩工人靠一把大锤和蒸汽钻孔机竞赛赢了机器却在胜利后力竭倒下。这个传说放在今天看几乎是为 AI 时代预写的寓言。只是剧情反过来了——我们不再担心机器抢体力活而是开始担心 AI 抢代码活、抢文案活、抢设计活。问题不在于“要不要和 AI 竞赛”而在于怎么比、比什么、用哪只手举锤子。这篇文章不讨论宏大叙事直接从工程角度拆开讲今天的 AI 到底能承担哪部分工作量哪些环节必须由人来定夺以及把两者组合成一条可落地工作流时环境怎么搭、输出怎么验证、风险怎么控制。内容会覆盖 AI 编程助手、AI Agent、本地模型部署、接口调用、批量任务、性能观察和常见问题排查适合正在做 AI 工程实践、想接入 AI 工具但还没找到稳定工作流的开发者。读完你会得到一套能直接参考的人机协作方法和验证清单而不是一堆口号。1. John Henry 的寓言重写了什么John Henry 在传说里赢了一场比赛但铁路公司最终还是选择了蒸汽钻。这个细节才是重点个别任务上人或许能赢但系统一旦确认机器工具的效率就会大规模重组。放到今天开发者面临的不是“AI 会不会写代码”这种非黑即白的问题而是“任务会怎么重新分配”。现在的 AI 在文本生成、代码生成、文档整理、初稿创作等知识型任务上确实表现出了类似“蒸汽钻”的效率。但从工程系统看胜利不是单点比赛。AI 能快速产出一段代码但它不了解业务上下文、不知道团队约定、不承担线上事故责任。一个稳定可维护的系统仍然依赖人来做需求定义、架构设计、代码审查和最终决策。用一张表看当前的分工现状任务类型人类优势AI 工具现状建议主导方需求梳理与目标定义懂上下文、能追问、能决策能整理信息无法代替人确认目标人架构设计与技术选型权衡约束、预判演进能生成方案初稿需人校核人主导AI 辅助代码初稿生成慢但可控速度快覆盖常见模式AI 初稿人审查单元测试与回归测试设计用例、解读失败可生成用例初稿人设计AI 辅助代码审查判断业务耦合、安全风险能做静态扫描和提示人文档与注释容易遗漏质量不稳高效产出初稿AI 初稿人校对重复性批量任务疲劳且慢稳定执行需要监控AI 执行人监控这张表的核心不是“谁强谁弱”而是每一行都设计了一个判断节点。判断节点必须由人掌控否则 AI 的输出会加速风险扩散。2. 这个时代AI 的真实工程能力边界2.1 AI 编程能出初稿扛不了最终判断当前主流的 AI 编程助手普遍具备代码生成、补全、解释、重构和单测生成能力。它们在一个明确的小范围任务上表现很好比如“写一个把 CSV 转成 JSON 的函数”或“给这段代码补充类型标注”。原因是这类任务在训练数据里出现过大量相似模式模型容易对齐。但 AI 编程有几个很实际的坑。第一是幻觉 API模型会生成根本不存在的库函数或参数尤其在版本较新或小众的框架上。第二是上下文窗口限制项目一大模型很难记住所有模块的约定容易生成风格不一致或者调用错误接口的代码。第三是正确性责任链断裂AI 只负责给出候选方案最终的逻辑正确性、边界处理和安全性判断仍然在人的手里。实际建议是把 AI 当作一个写初稿的同事而不是直接提交代码的作者。让它生成小块功能代码配合人工 review 后合入。不要让它直接在没有任何测试的情况下修改生产代码更不要把它生成的安全审计结论当作最终结论。2.2 AI Agent能拆任务扛不了全流程AI Agent 是当前应用层比较热的方向。它的通用架构是大模型作为决策大脑接收目标后拆解计划调用外部工具获取信息观察结果后继续下一步行动。比如一个自动化运维 Agent 可以读取日志、定位关键词、执行命令、汇总报告。这种能力在任务边界清晰、失败可回滚的场景里很有价值。问题同样明显。目标模糊时 Agent 容易迷路会反复生成偏离需求的子任务工具返回不稳定时可能陷入重试循环消耗大量 token 和时间日志和状态追踪也比传统程序复杂出错时很难定位是哪一步决策导致的。所以 Agent 更适合那些流程清晰、允许失败重来的任务比如批量文件处理、信息收集整理、定时报告生成。涉及生产环境变更必须保留人工确认步骤。2.3 多模态与内容生成能产出需审核现在的 AI 模型还能直接处理图像、音频和视频输入文生图、图生视频、语音合成、OCR 等领域的能力已经很成熟。这给内容生产带来了明显的效率提升。但这类能力的使用边界更严格生成图片可能涉及风格抄袭合成语音可能涉及声音权处理人脸内容可能涉及肖像权。任何用于外部发布或商业用途的多模态素材都要先确认素材来源和授权链条。2.4 本地部署的硬件门槛与成本边界接入 AI 有两条路线调用云服务接口或者本地部署模型。云服务接口的好处是省事按量付费显存和运维都不用管风险是敏感数据会发送到外部服务。本地部署的好处是数据不出内网可定制性强但需要准备 GPU、显存、磁盘和运维精力。硬件门槛取决于目标模型大小和任务类型。显存大小决定能否加载目标模型加载后上下文长度、batch size、输出长度都会带来额外占用。没有一张通用的“4G 够用、8G 不够”的表必须按实际模型版本和推理参数测试。如果本机显存不足可以降低上下文长度、减小 batch、使用量化模型或者退到 CPU 推理但速度和显存占用需要实测确认。3. 开发者手里的锤子人机协作工作流设计3.1 工作流总览把 John Henry 的锤子换成一套人机协作流程建议按这个五阶段推进需求澄清人负责把模糊想法变成明确任务包括输入、输出、边界条件。方案设计人主导做技术选型和架构设计AI 可以生成候选方案供参考。代码生成AI 基于清晰任务生成代码初稿人补充约束条件。人工审查与自动化测试人审查逻辑、边界和安全性再跑一遍自动化用例。集成发布人确认变更范围执行集成和发布观察线上表现。这五个阶段的共同点是每一步都有一个判断节点AI 的输出要先经过判断再进入下一步。3.2 提示词模板示例给 AI 编程助手写任务描述时最忌讳一句话需求。一个有效的提示词模板应该包含任务背景、输入输出格式、限制条件和验收标准。请实现一个 Python 函数功能是批量重命名指定目录下的文件。 背景输入目录里有大量 .log 文件需要按日期前缀重命名例如 20250101.log - task_20250101.log。 要求 1. 只处理扩展名为 .log 的文件。 2. 如果目标文件名已存在自动追加序号不允许覆盖。 3. 支持递归处理子目录。 4. 函数签名保持 rename_logs(input_dir: str) - int返回成功重命名的数量。 5. 提供必要的日志输出方便观察进度。 6. 不要依赖第三方库。 请先给出函数实现再列出你认为可能存在边界问题的地方。这个模板把任务细节都写清楚了模型生成的结果会稳定很多。注意如果你使用的是公开的在线 AI 服务不要把包含敏感信息的代码原样贴进去输入前先做脱敏。3.3 代码生成与审查示例给模型上面这个提示词它很可能给出类似下面的实现import os import re def rename_logs(input_dir: str) - int: renamed 0 for root, dirs, files in os.walk(input_dir): for filename in files: if not filename.endswith(.log): continue match re.match(r^(\d{8})\.log$, filename) if not match: print(fskip: {filename}) continue date_str match.group(1) new_name ftask_{date_str}.log new_path os.path.join(root, new_name) if os.path.exists(new_path): seq 1 while True: new_path os.path.join(root, ftask_{date_str}_{seq}.log) if not os.path.exists(new_path): break seq 1 old_path os.path.join(root, filename) os.rename(old_path, new_path) renamed 1 print(frenamed: {filename} - {os.path.basename(new_path)}) return renamed这个初稿看起来能跑但人工审查会发现几个问题。第一重名时只处理了“目标文件已存在”没有处理“新文件名恰好与另一个待重命名的源文件同名”的情况某些顺序下会重复改名。第二os.walk 在遍历时修改文件名可能导致遍历结果不稳定。第三正则只匹配了纯数字日期前缀如果输入文件是 task_20250101.log它的逻辑就直接跳过了。这些问题不是模型偷懒而是它不掌握你的真实目录结构和命名约定。人审的价值就在这一层。你可以让 AI 根据这些反馈继续修改也可以自己动手调整直到逻辑符合实际场景。3.4 代码审查清单无论生成的代码是 AI 写的还是人写的落地前都要过下面这张清单审查维度检查要点功能正确性是否满足需求中所有输入输出条件边界条件空目录、重复文件、无权限文件、超大文件是否处理异常处理文件不存在、磁盘满、依赖缺失时是否有报错信息安全性是否使用了不安全的命令拼接、路径穿越、硬编码密钥性能是否存在不必要的循环、重复读取、内存暴涨依赖版本依赖库和 API 是否在当前版本下可用可维护性函数是否单一职责、命名是否清晰、异常分支是否有日志这张清单可以打印出来贴在工位上每次 AI 生成代码后照着过一遍。4. 验证 AI 输出把“看着像对的”变成“真的对”4.1 通用验证流程验证 AI 生成代码或文档不能只看“能不能跑通主路径”。五步验证法可以覆盖大多数情况通读一遍逻辑确认模型理解的需求和你理解的一致。跑通最小用例先做冒烟测试。写边界测试覆盖空输入、异常输入、超大输入。对比预期输出确认数据格式和字段含义正确。让另一个同事 review或者隔一段时间再回看。这一步最大的价值是让 AI 的错误被控制在测试环境里而不是直接进入生产。4.2 自动化测试示例针对上面批量重命名函数可以补一组 pytest 用例import os import tempfile from collection import rename_logs def test_rename_normal(): with tempfile.TemporaryDirectory() as tmp: for name in [20250101.log, 20250102.log]: open(os.path.join(tmp, name), w).close() result rename_logs(tmp) assert result 2 assert os.path.exists(os.path.join(tmp, task_20250101.log)) assert os.path.exists(os.path.join(tmp, task_20250102.log)) def test_rename_duplicate(): with tempfile.TemporaryDirectory() as tmp: open(os.path.join(tmp, 20250101.log), w).close() open(os.path.join(tmp, task_20250101.log), w).close() result rename_logs(tmp) assert result 1 assert os.path.exists(os.path.join(tmp, task_20250101_1.log)) def test_rename_empty_dir(): with tempfile.TemporaryDirectory() as tmp: result rename_logs(tmp) assert result 0运行测试pytest test_rename.py -v如果测试没有通过先看失败的用例是模型代码的问题还是用例本身的问题。不要为了让测试通过而改断言那是自欺欺人。4.3 性能与资源观察观察 AI 服务的资源占用要用工具而不是靠感觉。Linux 下看显存占用nvidia-smi重点关注显存使用率、功耗和温度。GPU 显存不足时程序通常会报 CUDA out of memory这个时候优先降低上下文长度、batch size 或输入分辨率而不是盲目换更大模型。如果你在做 CPU 推理注意观察内存占用和单条推理耗时不要一次性提交大量任务先跑小批量测试峰值性能。上下文长度、批量数、输出长度、采样步数这些参数都会直接影响延迟和显存。第一次部署时建议用一个最小的输入跑一遍记录耗时和占用再逐步加大规模找到当前硬件的稳定阈值。5. 本地部署 AI 服务的通用路径5.1 环境准备如果你要在本地部署一个开源模型或推理服务建议按下面的清单检查环境操作系统Linux 更常见Windows 和 macOS 也可以但后续依赖兼容性需要额外确认。Python 环境建议用虚拟环境管理避免污染系统 Python。GPU 驱动和 CUDA如果使用 NVIDIA GPU先确认驱动已经安装PyTorch 等框架的 CUDA 版本与驱动匹配。磁盘空间模型文件体积较大预留足够空间。依赖管理安装项目要求的依赖不要全局安装。具体版本号要按你选择的项目文档来不同项目对 Python、CUDA、PyTorch 的要求不一样。5.2 启动推理服务的通用模板不同项目的启动命令差异很大下面这条命令是常见本地推理服务的启动方式实际使用时需要按项目文档调整路径和端口python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --host 127.0.0.1 \ --port 8000如果你没有 GPU可以尝试 CPU 模式但要注意速度会慢很多。启动后观察日志确认服务监听端口正常。Windows 下注意端口占用如果 8000 被占用换一个端口再试。5.3 接口调用示例本地推理服务启动后通常会暴露一个 HTTP 接口。这里给出一个通用的调用示例以常见的 OpenAI 风格接口为例import requests url http://127.0.0.1:8000/v1/chat/completions payload { model: local-model, messages: [ {role: user, content: 请帮我总结下面这段文字的重点。} ], temperature: 0.3, max_tokens: 512 } response requests.post(url, jsonpayload, timeout120) print(response.status_code) print(response.json())如果服务接口不是这个风格需要按实际项目的 API 文档调整请求路径和参数。先用 curl 测一遍再写代码调用能省很多排查时间curl -X POST http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: local-model, messages: [{role: user, content: hello}]}接口能通后面就可以把服务接进自己的工具链了。5.4 批量任务设计接入批量任务时最忌讳把所有输入一次性塞进内存然后等着一个循环跑完。批量任务建议按目录管理project/ ├── inputs/ # 原始输入文件 ├── outputs/ # 处理结果 ├── logs/ # 运行日志 └── failed/ # 失败文件每次批量任务生成一个带时间戳的子目录运行过程中记录每条任务的开始时间、结束时间、状态和错误信息。遇到失败的文件先把它移动到 failed 目录不要中断整体任务。成功处理完的文件可以从 inputs 移动到 done 目录这样即使中断也能从断点继续。批量任务一定要加日志和失败重试。日志是你排查问题的唯一线索失败重试策略要固定重试次数避免死循环。6. 风险边界与合规底线6.1 内容安全使用 AI 生成图片、视频、语音或文本时不能生成违规内容不能绕过平台的安全限制更不能把工具用于侵权、诈骗或干扰他人系统的用途。技术能力越强越需要克制地划定使用边界。6.2 版权与授权AI 生成代码时可能复制训练数据中的开源代码片段商用前要核对许可证。AI 生成的图片、文档和视频素材如果用作商业发布要确认素材不侵犯第三方版权。涉及人脸、名人肖像、他人声音时必须获得明确授权不能直接拿来生成或修改。6.3 数据隐私不要把包含客户隐私、密钥、内部业务数据的文本直接粘贴到公开的在线 AI 工具里。敏感场景优先选择本地部署或经过审批的内部服务。即使本地部署也要限制服务访问范围不要把推理服务直接暴露到公网不然后续会面临大量恶意请求。6.4 模型输出幻觉大模型生成的 SQL、API 路径、命令参数、参考文献都可能存在幻觉。凡是关键事实都要用官方文档或实际运行结果验证。AI 生成的安全审计、合规判断更不能直接作为最终结论必须由专业人员复核。7. 给开发者的实践建议7.1 先从成本账开始决定要不要在项目里引入某个 AI 工具先算一笔账。人工操作需要 2 小时AI 生成需要 10 分钟但人审和修复可能需要 20 分钟到底省不省时间对于探索型的核心算法人工成本高AI 帮助有限对于批量文档整理、代码补全、初稿生成这类任务AI 的效率优势就很明显。7.2 先搭一套最小可运行工作流不要一开始就追求复杂的 Agent 编排。先用一个 AI 编程助手、一个测试框架、一份审查清单把“AI 生成 → 人审 → 自动化测试 → 合入”这条最小链路跑起来。稳定后再加入更多工具和流程。7.3 保持“判断节点”意识不管 AI 多强每个关键节点都要留一个人工确认步骤。这个确认不是走形式而是要有明确的验证标准。需求定义是否清晰、代码逻辑是否满足边界条件、模型输出是否通过测试、发布范围是否可控这些节点都确认过了再谈效率。7.4 学习路线建议如果刚接触这个方向不要把时间全部花在写 prompt 上。更值得深入学习的是 AI 工程实践的几个支柱模型部署与推理优化、Agent 架构设计、输出评估方法、安全合规意识、以及工程化的批量任务管理。这些能力组合起来才能让 AI 在真实项目中稳定创造价值。在 John Henry 的传说里他赢了比赛但世界仍然选择了蒸汽钻。在 AI 时代真正重要的不是单次任务的胜负而是谁在设计那套人与工具协作的系统。搞清楚 AI 的能力边界搭好人机分工的流程做好验证和合规你就不是那个和机器拼体力的凿岩工而是决定锤子怎么用、工程怎么走的那个角色。建议把本文的工作流和验证清单直接拿到项目里跑一遍尤其是第一次用 AI 生成代码时先过一遍审查清单再决定要不要合入。