LLM 在开发中：为什么不是程序员的替代品

开发中的生成式 AI：专业人士的迷思与现实

生成式语言模型（LLM）承诺简化开发流程，但在实际应用中，它们仅限于常规任务。Pandas 早在聊天机器人出现前，就能一行代码聚合 Excel 数据。同样，CMS 和无代码平台早已无需自然语言就能搞定网页开发。

df = pd.read_excel("tmp.xlsx", index_col=0)
df.agg(["sum", "min"])

这些工具一直都存在。LLM 只是通过 API 让它们更易访问，但本质不变：代码必须可预测运行，而不是基于模糊描述。

智能体场景：理论 vs. 实践

基于 LLM 的智能体在理想条件下能迭代执行计划。但真实项目需要精确的行为规范。直接写出可运行代码，往往比用模糊自然语言描述每个细节更简单。

Python 或 JavaScript 的语法本就简洁明了。精细的提示工程往往让提示词比代码本身还长。对于中高级开发者，Stack Overflow 搜索和微调是标准流程——LLM 只是复制了这一套。

认知差距：开发者 vs. 管理者

管理者钟爱快速原型和“代码生成”。开发者清楚，原型需要大量精炼，审核 LLM 输出同样耗时。没有真正的效率指标，只有 token 计数。

• 管理者获益： 视觉化进度，GitHub 仓库塞满代码行。
• 团队痛点： 代码无人理解、架构缺陷、测试/部署难题。
• 现实： 瓶颈不在敲代码，而在需求和集成。

自上而下的 AI 工具强制推行忽略专业判断：有用的话，团队自然会采用。

氛围式编码的实际陷阱

像为游戏生成 4 万行代码，却不直接 fork 开源克隆（如 agar.io）这样的案例，暴露了低效本质。Anthropic 等服务瞄准新手赚钱，而非专业生产流程。

生成书籍或知识纯属垃圾信息。要高质量输出（Pelegrino 风格）的提示词，往往比文本本身还长。电子书市场已充斥无价值 AI 垃圾。

专业人士的实用场景

LLM 能加速琐碎工作：

• 样板代码生成。
• 文档搜索。
• 重构思路。

但需精确提示和验证。语音输入和自然语言在消费级应用（如照片背景移除）大放异彩。

API 演进（如为 AI 智能体定制的 Visa）将简化集成，但数据和 CLI 工具比单纯模型解决更多问题。

核心要点

• LLM 脱离专业知识无法创造价值：专注验证和集成。
• 效率源于熟练掌握工具，而非盲目生成。
• 对高级开发者，这是武器库补充，而非技能替代。
• 避开垃圾：用 AI 原型，手工打磨。
• 未来在于 API 和数据，而非万能智能体。

理解你编写或生成的代码。这是金科玉律。

— Editorial Team