---
id: what-remains-for-programmers
title: 程序员还剩下什么
summary: 从提示词、上下文到工程约束与验证循环，讨论代码生成越来越容易之后程序员需要做哪些判断。
tags:
  - AI
  - 软件工程
publishedAt: 2026-11-05T06:56:17.250Z
updatedAt: 2026-11-05T06:56:17.250Z
originalPublishedAt: 2026-06-23T19:19:00+08:00
wechatUrl: https://mp.weixin.qq.com/s/7EZPqA4TwwJtKEh06fQxrA
url: https://wuyanji.datiaomao.com/articles/what-remains-for-programmers/
markdownUrl: https://wuyanji.datiaomao.com/articles/what-remains-for-programmers/index.md
---

![图片](https://wuyanji.datiaomao.com/media/what-remains-for-programmers/640d6822b77d1dc3d1026647.png)

  

# 程序员还剩下什么？

你有没有发现，写代码这件事正在悄悄改变。

以前我们写代码，像是翻译官——把业务需求翻译成机器能懂的指令。这个"翻译能力"就是程序员的核心价值。

但现在，这项能力要失业了。

AI已经能直接听懂需求、写出代码。你给它一个模糊的意图，它能给你一个完整的功能。代码本身正在变成一次性的东西——用完即弃，不需要维护。

那问题来了：程序员还剩下什么？

* * *

## 技术演进：从提示词到循环工程的四次跃迁

### 提示词工程（2023年）：学会说话

2023 年，ChatGPT 出来，那时候我们在研究的是"怎么让模型听懂人话"。

关键发现是：添加`let's think step by step`可增强推理能力，Few-shot 示例能稳定输出格式，按场景分类的提示词模板体系形成。

隐含假设是：模型够聪明，你不会问而已。

但很快发现局限性：无法处理复杂任务（如完整项目开发），提示词无法承载大量上下文信息。

这个阶段，上下文的重要性已经隐含其中——你让模型写一个完整的项目，它需要知道项目结构、依赖关系、技术栈偏好、现有代码长什么样，这些东西不能方便的塞进一句提示词里。

### 上下文工程（2024-2025年）：学会选信息

接下来核心转变就从"如何写指令"转向了"如何管理推理信息"。

上下文是有限资源，需优化token使用效率；目标是在有限窗口内最大化信号、最小化噪音。

关键洞察是：错误上下文会导致模型产生"看似正确实则离谱"的结果——模型会非常认真地基于错误的上下文，产出一个看起来很对、实际上离谱的结果。

技术背景是：上下文窗口从4K扩展至百万token，RAG、工具调用、MCP（多模态内容处理）技术普及。

上下文工程的核心是：模型推理质量是上下文质量的函数，而上下文窗口是有限资源。

### Harness工程（2025-2026年）：学会约束

再然后是出现了 Agent，它可以多次对话直到完成任务。但即使信息正确，Agent仍会出现"一次性做完所有事"或"提前收工"等问题。

关键实践是：可通过 Codex、ClaudeCode 交付百万行代码产品，工程师角色从写代码转变为设计约束。

架构优化是：将`AGENTS.md`和`CLAUDE.md`从超长文件拆分为100行目录+独立文档，按需加载。

约束机制是：严格的分层依赖规则（业务代码单向调用，越界即被系统切断）、三角色分工（规划师拆需求、生成器写代码、评估器做验收）。

核心思想是从"主动指导"转变为"被动约束"，人定义边界而非具体步骤。Harness的本质是包裹模型运行的基础设施，将LLM的"大脑"转化为Agent的"身体"（无状态推理→可控行动系统）。

### 循环工程（2026年）：学会设计系统

核心变化是：从人作为"循环本身"（通过回合制提示词调度AI）到人设计自主系统（循环），由系统自动完成"找活→派活→检查→记录→决策下一步"的全流程，从而抽身成为监督者。

标志性事件：

*   Boris Cherny（Claude Code之父）：2025年11月卸载IDE，通过Claude Code完成259个PR且无需手动编码；2026年6月提出"不再写提示词，只写循环"的观点
*   Peter Steinberger（OpenClaw之父、OpenAI）：2026年6月8日在X平台发文强调"不应再向编码代理发送提示，而应设计提示代理的循环"
*   Addy Osmani（Google资深工程主管）：2026年6月7日在博客中正式提出"循环工程（Loop Engineering）"概念

核心技术组件：

*   自动化（Automations）：定时触发任务，自动发现并分诊需求
*   隔离工作区（Worktrees）：为每个智能体提供独立代码检出环境
*   技能（Skills）：将项目惯例、构建步骤等写入SKILL.md，解决AI"金鱼记忆"问题
*   连接器（Connectors）：基于MCP协议连接外部系统（issue、数据库、Slack）
*   子智能体（Sub-agents）：分离"写代码"与"检查"角色，由独立模型验收成果
*   记忆（Memory）：通过Markdown文件记录进度、规则和历史

核心命令与运行机制：

*   `/loop`：按设定间隔反复执行提示词（如每5分钟检查PR状态）
*   `/goal`：让AI持续工作直至预设条件满足，由独立小模型判断任务完成度
*   提示词并未消失，而是被写入循环命令中反复复用，形成"提示词→循环→AI执行→验证→更新提示词"的闭环  
    

![图片](https://wuyanji.datiaomao.com/media/what-remains-for-programmers/c579bb8e4bd5e0ad28bd01df.png)

* * *

## 程序员的价值问题：从"写代码"到"设计系统"

### 过去价值：卖代码 = 卖「需求→指令」的翻译能力

软件的核心作用是"站在人和机器中间，把人想做的事翻译成机器能执行的步骤"。早期是科学家自己写汇编，后来有了操作系统、图形界面、浏览器、App Store。每一次形态变化，都是在降低「翻译」的门槛，让更多人能把自己的意图交给机器。

### 现在挑战：AI可替代翻译过程

AI带来的三个跨越：从明确操作到模糊意图、从固定输出到开放结果、从单步功能到多步任务。

代码和软件本身趋向一次性：Agent可临时生成子软件（如临时网页、批处理工具），存在时间短，用完即弃。

当软件本身变成一次性的，很多卖软件的方法就不成立了。

### 未来方向：构建更持久的上下文系统

让软件更深入客户的关系（更懂思考、生活、工作）。

软件个性化从「给你推荐什么」升级成了「学会你如何做事」。

从"操作者"到"管理者"：循环工程本质是设计数字团队的工作流程，开发者需像管理员工一样配置AI系统。  

![图片](https://wuyanji.datiaomao.com/media/what-remains-for-programmers/e908d0d7059d8c800c812ecb.png)

* * *

## 答案：上下文系统是程序员真正的价值点

### 上下文决定AI的本质

AI的能力边界、输出问题及实际用法，本质上均由上下文决定。用户请求与AI可获取的所有材料共同构成完整上下文，模型基于此循环生成结果。

生成原理：上下文→预测概率→选中结果→放回上下文→重复生成。

产品形态差异：ChatBot、周报生成器等产品外壳不同，但内核都是上下文驱动的概率生成。

Agent的进化：从依赖人工投喂上下文（被动接收材料）到具备自主上下文构建能力（搜索网页、读取文档、调用工具、动态写入上下文）。

### 模型是租来的，上下文才是资产

纠结「该用哪个 AI」已经过时了，真正该想的是任务怎么在不同模型间分工，以及最关键的一点：模型只是租来的工具，上下文才是你自己的核心资产。

### 上下文系统的本质：知识资产

上下文系统不是技术架构（像微服务、DDD那样），而是知识资产——独属于某一个项目的知识沉淀。它跟通用文档的区别在于：

通用知识（写代码的套路、调试的方法）大模型已经具备。

特定知识（这个项目的业务逻辑、那个团队的独特工作流）只能靠人踩坑、记录。

这些高阶知识（因果型、时空型）难以从模型获得，需团队积累。

### 上下文系统的价值：能积累，有效果

<strong>能积累</strong>：知识资产可以复用、迭代、沉淀。每次遇到新问题，都能基于已有的上下文系统快速响应，而不是从头开始。

<strong>有效果</strong>：模型推理质量是上下文质量的函数。错误上下文会导致模型产生"看似正确实则离谱"的结果，而精心设计的上下文系统能让AI输出更符合业务需求、更高质量的代码。

### 程序员的核心竞争力迁移

从"代码能力"迁移到了"上下文系统能力"——因为前者很难积累（每次写新代码都得从头来），后者能积累（知识资产可以复用、迭代、沉淀）。

具体体现在：

*   循环设计：设计数字团队的工作流程，配置AI系统
*   技能沉淀（SKILL.md）：将专家经验、工作流、工具调用封装为可分发、可复用、可迭代的Agent能力单元
*   规则蒸馏（CLAUDE.md）：将项目规则、约束条件、最佳实践沉淀为可复用的规则集

![图片](https://wuyanji.datiaomao.com/media/what-remains-for-programmers/fd609aed790741d187831b05.png)

### 变化的本质：渐进式迁移

有些程序员还在写代码。

有些程序员开始搭上下文系统。

有些程序员已经完全转向循环工程。

就像当年从"瀑布到敏捷"，不是一夜之间全行业切换，是有些团队先尝试，有些团队后跟上。大多数程序员，可能是"80%的时间写代码，20%的时间搭上下文系统"，慢慢变成"50%写代码，50%搭上下文系统"，最后变成"20%写代码，80%搭上下文系统"。

### 程序员标签的消亡

"程序员"这个词本身就会过时。未来可能没有"程序员"这个职位，只有"AI系统设计师"、"上下文工程师"、"循环架构师"这些新角色。

这些角色的核心能力是"让AI执行长任务的能力"，不只是写代码，还包括让AI写调研报告、设计营销方案、管理项目等。而长期完成这些任务都需要"搭上下文系统"。

* * *

## 结论

未来程序员真正的价值点，体现在搭建的上下文系统中。

这个系统是知识资产（不是技术架构），独属于某一个项目，能积累、有效果。它决定了AI输出的质量，是模型无法替代的核心竞争力。

从"手写代码"到"设计让AI写代码的系统"——这就是AI时代程序员的价值迁移。
